Microsoft के open source tools हैक हुए, AI developers के passwords चुराने में दुरुपयोग

(techcrunch.com)

3 पॉइंट द्वारा GN⁺ 5 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें

GitHub पर होस्ट किए गए दर्जनों open source projects से हैकरों ने समझौता किया और कोड में password-stealing malware inject कर दिया, जिसके बाद Microsoft ने उन projects की access block कर दी और जांच शुरू की
प्रभावित projects में से कई cloud service Azure और Claude Code, Gemini CLI, VS Code जैसे AI developer apps में coding के दौरान इस्तेमाल होने वाले tools से जुड़े हैं
जब user किसी AI coding app में संक्रमित tool खोलता है, तो यह passwords और sensitive credentials चुराने के लिए काम करता है
GitHub के अनुसार कम से कम 70 projects disable किए गए, और Microsoft ने कुछ repositories को अस्थायी रूप से हटाकर review के बाद restore किया
यह मामला लोकप्रिय open source code को निशाना बनाने वाले supply chain attack का हालिया उदाहरण है, और बताया गया है कि कुछ ही हफ्तों में Microsoft के open source projects के compromise होने की यह दूसरी घटना है

घटना का सार और Microsoft की प्रतिक्रिया

इस बात के संकेत मिले कि हैकरों ने projects से समझौता कर कोड में password-stealing malware inject किया, जिसके बाद Microsoft ने GitHub पर मौजूद दर्जनों open source projects की access block कर दी और compromise के तरीके की जांच कर रहा है
प्रभावित projects में से कई Azure cloud service और Claude Code, Gemini का command-line interface, VS Code जैसे AI developer apps में coding के लिए इस्तेमाल होने वाले tools से जुड़े हैं
प्रभावित tools को वास्तव में कितने लोगों ने download किया, यह तुरंत स्पष्ट नहीं हो सका
Microsoft ने repositories हटाने की पुष्टि की, जिसकी पहली रिपोर्ट 404 Media ने दी
- Microsoft spokesperson Ben Hope: "संभावित malicious content की जांच के दौरान कुछ repositories को अस्थायी रूप से हटाया गया"
- कुछ repositories review के बाद restore कर दी गईं, जबकि कुछ पर काम जारी रहने तक offline रह सकती हैं
- Microsoft ने कम संख्या में उन customers को सूचित किया हो सकता है जिन्होंने प्रभावित repositories से content download किया हो, और अगर अतिरिक्त कार्रवाई की जरूरत वाली बातें सामने आती हैं तो मौजूदा support channels के जरिए सीधे संपर्क किया जाएगा
TechCrunch के सवाल पर प्रभावित customers की सटीक संख्या तुरंत नहीं बताई गई

malware कैसे काम करता है

security company Cloudsmith और community-based malware analysis site OpenSourceMalware उन पहले स्रोतों में थे जिन्होंने इस hack की ओर ध्यान दिलाया
malware इस तरह काम करता है कि जब user किसी AI coding app में संक्रमित tool खोलता है, तो यह passwords और अन्य sensitive credentials चुरा लेता है
Microsoft के स्वामित्व वाली code hosting site GitHub पर project pages देखते समय कम से कम 70 projects पर "disabled" status दिखा
- प्रदर्शित संदेश: "GitHub Terms of Service के उल्लंघन के कारण इस repository की access GitHub staff द्वारा disable की गई है"

supply chain attack का संदर्भ

यह हाल के महीनों में सामने आए उन मामलों की ताज़ा कड़ी है जिनमें व्यापक रूप से इस्तेमाल होने वाले open source projects से समझौता कर, वह code install करने वाले कई users तक malware पहुंचाया गया
ऐसे hacks को "supply chain" attack कहा जाता है, और इनका निशाना ऐसा code होता है जो कई software products में व्यापक रूप से इस्तेमाल होता है या किसी खास user group द्वारा उपयोग किया जाता है
- ऐसे targets हैकरों के लिए फायदेमंद हो सकते हैं क्योंकि इनके पास cloud systems और बड़ी मात्रा में customer data तक access हो सकती है
open source projects के अकेले developers का निशाना बनना असामान्य नहीं है, और कुछ मामलों में यह developers का भरोसा जीतने की लंबी कोशिश का हिस्सा होता है
लेकिन Microsoft जैसी बड़ी tech company, जिसके पास ऐसे attacks से बचाव के संसाधन हैं, उसका compromise होना असाधारण है

बार-बार compromise के संकेत

Ars Technica के अनुसार, हाल के कुछ हफ्तों में Microsoft के open source projects के compromise होने का यह दूसरा ज्ञात मामला है
मई के मध्य में, security researchers ने कहा कि developers को apps बनाने में मदद करने वाला Microsoft open source project Durable Task हैक हुआ प्रतीत होता है
OpenSourceMalware ने इस ताज़ा घटना को Durable Task project का "re-compromise" बताया
- इससे संकेत मिलता है कि Microsoft पहली कोशिश में हैकरों को पूरी तरह नहीं हटा सका, या फिर यह एक बिल्कुल अलग नया compromise हो सकता है

2 टिप्पणियां

brainer 1 시간 전

क्या यह शायद वही वजह हो सकती है कि पासवर्ड बदलने के बाद भी मुझे लगातार MS अकाउंट लॉगिन कोशिशों की सूचनाएँ आ रही हैं?

GN⁺ 5 시간 전

Hacker News की राय

यह पूरी तरह अटकल और निजी अवलोकन है, लेकिन पुराना RBAC मॉडल पहले ही लगभग टूट चुका था और अब तो पूरी तरह बिखरा हुआ लगता है
coding assistants और engineers एक-दूसरे से असंबंधित कई projects पर एक साथ काम कर रहे हैं, और खासकर पहले समय की कमी की वजह से जो experiments नहीं हो पाते थे वे भी अब होने लगे हैं, इसलिए कंपनियों के भीतर supply chain risk बहुत बढ़ गया है
मैं यह नहीं कह रहा कि इसका सीधा संबंध है, लेकिन असर ज़रूर लगता है, और आजकल कई जगह developers और managers को अपनी personal devices पर बस जैसे-तैसे AI coding करने के लिए उकसाया जा रहा है, यह भी जल्द समस्या बनेगा
हाल की supply chain घटनाओं के बीच कोई साझा पैटर्न नहीं है, यह मानना मुश्किल है, और ऐसे हमलों में विशेषज्ञ hacking groups मौजूद हैं क्योंकि इनका reward बड़ा है
- साफ़ कर दूँ, मूल टिप्पणी ने यह निश्चित नहीं कहा था कि यह संबंधित है, लेकिन इसका AI या vibe coding से बिल्कुल संबंध नहीं है
  यह लंबे समय से मौजूद developer dependency installation security की कमी और Shai Halud worm की ही निरंतरता है
  hackers ने समझ लिया है कि developers को कुछ install करवाने के लिए फुसलाना आसान है, और developer machines पर credentials, cloud CLI, MCP जैसी संवेदनशील जानकारी बहुत होती है, इसलिए वे आदर्श target हैं
- हमारी कंपनी में भी यही हाल है। “अगर AI से जितना हो सके उतना नहीं किया, तो हम पीछे रह जाएँगे” जैसी सोच फैल गई है
  security की परवाह किए बिना सबसे पहले दौड़ने की कोशिश, बिल्कुल पुराने IoT hype की पुनरावृत्ति लगती है
- मैं कई साल से कह रहा था कि कुल projects की संख्या के मुकाबले लोग बहुत कम हैं, लेकिन management का कहना था कि ज़्यादातर projects idle हैं, इसलिए एक व्यक्ति को बहुत कुछ देना ठीक है
  नतीजा यही होना था
- क्या इसका मतलब यह है कि role-based access control, यानी RBAC, को किसी और चीज़ से बदलना चाहिए, या यह कि अभी इस्तेमाल हो रहे कुछ खास RBAC models टूट चुके हैं?
  व्यक्तिगत रूप से, नाम थोड़ा उलझाने वाला है, लेकिन मुझे लगता है कि capability-based security model ही भविष्य है
शीर्षक की भाषा से ही पक्षपात दिखता है, और लेख का मुख्य भाग भी ऐसे लिखा गया है मानो गलती open source की हो
फिर attempted supply chain attack की ज़िम्मेदारी Microsoft पर डालने की शैली इसे और भी अजीब बनाती है
Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch. लिखा है, लेकिन TechCrunch यह नहीं समझाता कि open source मूल रूप से ऐसे ही काम करता है
मुझे Microsoft की आलोचना करने में कोई हिचक नहीं, लेकिन इस मामले में मुझे लगता है कि Microsoft ने सुरक्षित और सही कदम उठाए
लेख इसे ऐसे पेश करता है मानो सब कुछ Microsoft की गलती हो, और breach के दायरे को सीमित रखना भी जैसे शर्म की बात हो
steal passwords of AI developers जैसी अभिव्यक्ति भी यह अस्पष्ट संकेत छोड़ती है कि मतलब “AI developers” है या “AI इस्तेमाल करने वाले developers”
supply chain attack की व्याख्या भी उसके वास्तविक अर्थ की जगह सिर्फ परिणाम और attack surface के कारणों तक सीमित है, इसलिए यह रिपोर्टिंग बहुत खराब लगती है
- TechCrunch बहुत लापरवाह है और उस पर भरोसा करना मुश्किल है
  मैंने उन्हें उस काम पर रिपोर्ट करते देखा है जिसमें मैं खुद शामिल था, और उन्होंने search optimization के लिए तथ्य गढ़ लिए थे, जबकि सुधार करवाने का कोई तरीका भी नहीं था
- मुझे समझ नहीं आता कि उस वाक्य में समस्या क्या है
  Microsoft में organizational security problems हैं, और GitHub Actions को ठीक से लॉक न कर पाना तथा merge requests को CI/CD bypass करने देना, इस समस्या को बढ़ाता है या उजागर करता है
  यह AI से पहले से मौजूद Microsoft की समस्या है, और यह कोई विवाद की बात भी नहीं है: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
  AI युग में यह समस्या स्थानिक रोग की तरह फैल गई है और weaponize की जा रही है
- फिर आप postmortem को कैसे देखते हैं?
  असल में क्या हुआ था, और इसे कैसे पढ़ा जाना चाहिए?
ये संबंधित लगने वाली पोस्ट्स हैं
https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
https://news.ycombinator.com/item?id=48416155
https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)
- संक्रमित सभी repositories में worm को ठीक करने या हटाने के लिए एक mitigation tool बनाया गया है, और इस पर एक पोस्ट भी लिखी गई है
  सोमवार को Hades campaign ने Composer, Go, Pip support जोड़ा। उससे पहले यह सिर्फ NPM और AI assistant editors को support करता था, और Ruby भी था, लेकिन आजकल Rubygems इस्तेमाल करने वाले लोग शायद ही दिखते हैं
  Microsoft भी जिस बात को मिस कर रहा है, वह यह है कि यह code ecosystem के सभी platforms पर चलने वाला पहला worm है। यह developer hosts, servers और CI/CD runners सभी पर चलता है, और उन machines की पहुंच में आने वाली हर repository तक worm फैला देता है
  इस worm को हराने के लिए सभी computers और AWS EC2, Google Cloud Platform, Azure, Kubernetes clusters को एक ही समय पर 100% बंद करना होगा। यह सचमुच पूरे infrastructure में फैलता है
  APT28 malware की तरह ही, इसका kill switch host language को ru_RU.KOI8-R पर सेट करना है, यानी LANG environment variable सेट करना। इससे propagation mechanism निष्क्रिय हो जाता है
  mitigation tool: https://github.com/cookiengineer/antimiasma
  blog post: https://cookie.engineer/weblog/articles/malware-insights-mia...
मुझे काफ़ी मज़बूती से शक है कि यह पारंपरिक personal access token के गंदे इस्तेमाल का मामला होने की संभावना ज़्यादा है
अगर आप किसी अजीब openclaw device पर AI agent को token देने वाले हैं, तो fine-grained token इस्तेमाल करना चाहिए
मेरा GitHub account तीन organizations में फैला है, जिनकी policies पूरी तरह अलग हैं, इसलिए यह बात अब भी थोड़ा चौंकाती है कि classic token अभी भी allowed हैं
कम से कम इसे ऐसा बनाया जाना चाहिए कि हर organization के लिए इसे अलग से manually allow करना पड़े
- मेरी राय में AI agents अलग security principals होने चाहिए, और उन्हें सिर्फ़ ज़रूरी repositories या organizations के लिए dedicated access tokens जारी होने चाहिए
  मानव account के लिए “minted” access token को AI agent को सौंपना नए ज़माने के “password को Post-it पर लिखकर छोड़ देने” जैसा लगता है
- बात सही है, लेकिन fine-grained tokens का permission management लगभग एक दुःस्वप्न है
  यह तय करना आसान नहीं होता कि किस काम के लिए ठीक-ठीक क्या चाहिए और क्या सही है
  ऊपर से software developers अक्सर permissions की बजाय code पर ध्यान देना ज़्यादा ज़रूरी मानते हैं, और permissions को किसी और की ज़िम्मेदारी समझ लेते हैं
- अगर classic PAT वजह है, तो क्या इसका मतलब यह नहीं कि हाल की GitHub repositories के अलावा और private repositories भी जोखिम में हो सकती हैं?
- public repository scraping के लिए मैं low-privilege account का classic token इस्तेमाल कर रहा हूँ
  organization-level permission मेरी ज़रूरत के लिए काफ़ी ठीक बैठेगी
कल मुझे अपना personal Microsoft account password reset करना पड़ा। क्योंकि Romania से login attempt होने की 2FA alert आई थी
password उन्हें कैसे मिला, यह मुझे नहीं पता। मेरे पास Microsoft का सिर्फ़ Xbox ही है
AI से पहले भी Microsoft मुझे छलनी जैसा लगता था, और अच्छा होता अगर company Microsoft से दूर जा पाती, लेकिन अब हम पहले से बँधे हुए हैं
- personal Microsoft account में passwordless login allow न हो, ऐसा सेट करना लगभग असंभव है
  इसलिए असल में account शायद वैसे ही configured है, और जो MFA request मिली वह 2FA नहीं बल्कि सिर्फ़ account access की कोशिश भी हो सकती है
  मुझे भी दिन में कई बार ऐसे requests मिले हैं, और जब phone पर Microsoft Authenticator app सेट किया तो पता चला कि अगर face, fingerprint, PIN जैसी कोई lock enabled हो, तो यह ज़बरदस्ती passwordless mode में बदल देता है
  इससे बचने के लिए Authenticator app में account सेट करते समय ऐसी सभी locks बंद करनी पड़ती हैं
  मैं Microsoft account ज़्यादा इस्तेमाल नहीं करता, इसलिए अब Authenticator की बजाय अलग email से verify करता हूँ
  यह अपने-आप में पागलपन है कि यह चीज़ ऐसे काम करती है, लेकिन शायद Microsoft के अंदर कोई passwordless login KPI पूरा कर रहा होगा
- जिन कुछ organizations में मैंने काम किया, वहाँ password सही हो या नहीं, MFA prompt फिर भी दिखाया जाता था। मकसद attacker का और समय बर्बाद करवाना था
  Microsoft भी ऐसा करता है या नहीं, यह पक्का नहीं कह सकता
काश कोई समझाता कि इतने सारे repositories में obfuscated files कैसे जोड़ दी गईं। क्या code review होता ही नहीं है?
शीर्षक भी भ्रामक है। setup ऐसा config जोड़ता है जिसे repository पर काम करने वाले लोग अपने-आप चलाने लगते हैं, और उन लोगों को VSCode, Cursor, Claude, Gemini इस्तेमाल करना होता है
Codex, opencode, और दूसरे execution harnesses इस्तेमाल करने वाले लोग शायद सुरक्षित हों
ज़्यादा जानकारी: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...
- मेरा एक करीबी दोस्त एक बड़ी company में काम करता है। कौन-सी company है यह नहीं बता सकता, लेकिन वह S&P 500 कंपनी है
  काफ़ी समय से वहाँ काम कर रहा है, फिर भी उसने कभी यह नहीं देखा कि जिस project पर वह है वह वास्तव में कैसा दिखता है; repository clone करके रखी है और बस language जानता है, उससे ज़्यादा कुछ नहीं
  सब कुछ लगभग AI से जोड़-तोड़ कर चिपकाया जा रहा है। वह project पूरी company के product के authentication और authorization system का है
  उसके शब्दों में, “मैं पूरे दिन बस Tab दबाता हूँ और review में ‘intended behavior’ लिख देता हूँ। Review भी पूरा AI करता है, इंसान दखल नहीं देते। CEO और CTO सच में यही करने को कहते हैं। अगर कुछ टूट जाए तो किसी ने असली code देखा ही नहीं होता, इसलिए किसी को नहीं पता कि वह कैसे काम करता है। Performance evaluation इस पर नहीं होती कि हमने क्या किया, बल्कि इस पर होती है कि हमने कितने tokens इस्तेमाल किए”
  संभव है कि अभी बहुत-सी companies ऐसी ही हों, और यह मानना ग़लत नहीं होगा कि असली code review नहीं हो रहा
- कई malicious commits में author github-actions दिख रहा है
  इसका मतलब है कि authentication अंदरूनी GitHub CI/CD side से हो रहा है, और ऐसे commits इतने ज़्यादा हैं कि किसी भी automation tool के लिए भूसे के ढेर में ज़हर ढूँढना मुश्किल होगा
  इसलिए यह 2025 के सितंबर वाले GitHub security breach से जुड़ा है
  “पाँच repositories के GitHub stars मिलाकर 1,459 हैं, और उनमें से mantine-datatable अकेले 1,225 का हिस्सा है। Stars इस बात का एक मोटा proxy हैं कि कितने developers ने source को local में checkout किया होगा, और यही वह समूह है जिसे यह हमला निशाना बनाता है।”
  “सभी commits unsigned थे, identity github-actions थी, और message chore: update dependencies [skip ci] था, साथ में वही छह files का footprint मिला। 49 सेकंड में पाँच repositories को scan करना इंसान का commit करना नहीं, automation है। यह Shai-Hulud self-propagation से मेल खाता है, जो पहले के infection में write permission वाले GitHub tokens इकट्ठा करने के बाद उन tokens की पहुँच वाली हर repository में persistence payload push करता है।”
  https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
  असली mechanism: https://safedep.io/config-files-that-run-code/
  मेरा उन लोगों से कोई संबंध नहीं है, लेकिन अभी क्या हो रहा है इसकी सबसे सरल और विस्तार से समझाने वाली व्याख्या मुझे यही मिली
- एक सहकर्मी ने गंभीरता से पूछा, “अगर अब ज़्यादातर code generate हो रहा है, तो उसे वास्तव में पूरा पढ़ कौन रहा है?”
  हमारी company छोटी है, लेकिन कुछ लोगों में AI पर ट्रस्ट की तरह भरोसा करने की प्रवृत्ति लगभग धार्मिक लगती है
  मैं अपने generate किए गए code का 90% से ज़्यादा हिस्सा ऐसे पढ़ता हूँ जैसे किसी junior developer का code review कर रहा हूँ
  इस समय मैं एक नई feature पर काफ़ी ज़ोर से vibe coding कर रहा हूँ, लेकिन जैसे ही GitHub PR फिर से काम करने लगेंगे, मैं उसे अच्छी तरह पढ़ूँगा
- अगर किसी ऐसे account से compromise हुआ हो जो repository में push कर सकता था, तो PR review की ज़रूरत ही नहीं रही होगी
क्या हम ऐसे लोगों को Secure Boot के root CA certificate सौंप रहे हैं?
- क्या आप उस company की बात कर रहे हैं जो 2023 security review में fail हुई थी? [0]
  “ऊपर बताई गई हर कमी को अलग-अलग देखें तो शायद समझा जा सकता है। लेकिन सबको साथ रखें तो वे Microsoft के organizational controls, governance, और security के बारे में corporate culture की विफलता की ओर इशारा करती हैं।”
  Microsoft के products और services हर जगह हैं। यह दुनिया की सबसे महत्वपूर्ण technology companies में से एक है, शायद सबसे महत्वपूर्ण भी। इस स्थिति के साथ विश्व-स्तरीय सर्वोच्च ज़िम्मेदारी आती है। इसके लिए CEO से शुरू होने वाली ज़िम्मेदार, security-first corporate culture चाहिए, ताकि financial या go-to-market कारण cyber security और Microsoft customers की सुरक्षा को कमज़ोर न करें।
  “दुर्भाग्य से, इस review के दौरान committee ने operational और strategic decisions की एक श्रृंखला पहचानी, जो यह दिखाती है कि Microsoft ने corporate security investment और कठोर risk management दोनों को कम प्राथमिकता दी। इन निर्णयों ने दुनिया भर में Microsoft customers के लिए भारी लागत और नुकसान पैदा किया।”
  “Committee आश्वस्त है कि Microsoft को अपनी security culture दुरुस्त करनी होगी।”
  [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
- Secure Boot का trust root आमतौर पर Microsoft certificate नहीं बल्कि OEM certificate होता है, और वह शायद इससे भी बुरा हो सकता है: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
  वैसे भी Microsoft certificate हटाकर अपना certificate register करने की आज़ादी है
- “trust” से ज़्यादा यह “मजबूरी में स्वीकार करना” है
  यह घटना भी बस उसी रिकॉर्ड की अगली कड़ी है जिसमें Microsoft कोई security-conscious company कम और security problem itself ज़्यादा रही है
- security के मामले में Microsoft पर भरोसा करना मूर्खता है
  पिछले 40 सालों में उन्होंने कई बार दिखाया है कि उन्हें परवाह नहीं है
शायद मुझे यह बात देर से समझ आई, लेकिन मैं कुछ समय से कह रहा हूँ कि भले ही आप “कोड खराब है” जैसी वजहों से AI का इस्तेमाल न करना चाहें, security audit के लिए AI के इस्तेमाल पर ज़रूर विचार करें
कम से कम कोड में vulnerabilities स्कैन करने वाले tools तो इस्तेमाल करने ही चाहिए
attack vectors सिर्फ data चुराने वाले plugins तक सीमित नहीं हैं; इनमें आपके इस्तेमाल के लगभग हर software की 0-day vulnerabilities, और LLM लेकर घूमने वाले script kiddies द्वारा आपकी web service पर हमले भी शामिल हैं
hacking बढ़ेगी और और भी बदतर होगी, इसलिए जो जगहें cyber security audits और audit tools में निवेश नहीं कर रही हैं, उन्हें दोबारा सोचना चाहिए
किसी को भी अपनी मशीन पर npm install या pip install नहीं चलाना चाहिए
अगर आप सही sandboxing(https://github.com/ashishb/amazing-sandbox) लगातार इस्तेमाल करें, तो इस तरह के हमलों के blast radius को काफी कम किया जा सकता है
- क्या Docker backend commands को rootless containers में चलाता है?
  मैंने code थोड़ा देखा, लेकिन इसकी पुष्टि करने लायक कुछ नहीं मिला
- Docker कोई गंभीर sandboxing strategy नहीं है
- अगर बात यह है कि अपनी मशीन पर npm install या pip install न करें, तो फिर विकल्प क्या है?
  क्या मतलब यह है कि sandbox के बाहर install न करें?
- क्या इसमें कोई detection component भी है?
  sandbox में development करना अच्छा है, लेकिन अगला कदम production deployment है
  आपको कैसे पता चलेगा कि sandbox के अंदर malicious behavior हुआ था, ताकि आप उस malware को आगे deploy न कर दें?
यह बात हद से ज़्यादा मज़ेदार है कि Microsoft के Github ने terms of service violation की वजह से Microsoft Azure और बाकी सभी users की Microsoft codebase तक पहुंच बंद कर दी
इससे उस org chart का अहसास सच में होता है: https://www.businessinsider.com/big-tech-org-charts-2011-6