Shai-Hulud ने डेवलपर मशीनों को संक्रमित कर GitHub ऑर्गनाइज़ेशन एक्सेस चुरा लिया: पोस्टमॉर्टम विश्लेषण

 (trigger.dev)
4 पॉइंट द्वारा GN⁺ 2025-12-15 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Shai-Hulud 2.0 malicious npm package ने डेवलपर मशीनों को संक्रमित करके Trigger.dev के GitHub organization access को चुरा लिया
  • संक्रमण तब शुरू हुआ जब डेवलपर ने pnpm install चलाया और malicious package का preinstall script execute हुआ; TruffleHog tool का इस्तेमाल कर credentials चुराए गए
  • हमलावर ने 17 घंटे तक 669 repositories clone कीं, और फिर 10 मिनट के दौरान 199 branches पर force push तथा 42 PR बंद करने की कोशिश की
  • Packages और production systems प्रभावित नहीं हुए, और हमला 4 मिनट के भीतर detect होकर account access block कर दिया गया
  • घटना के बाद npm scripts disable करना, pnpm 10 upgrade, OIDC-आधारित npm deployment, branch protection का पूर्ण लागूकरण जैसी security measures मजबूत की गईं

हमले का अवलोकन

  • 25 नवंबर 2025 को, internal Slack debugging के दौरान कई repositories में Linus Torvalds के नाम से “init” commit बनने जैसी असामान्य गतिविधि दिखी
  • जांच में पता चला कि Shai-Hulud 2.0 supply-chain worm ने डेवलपर मशीन को संक्रमित कर GitHub credentials चुरा लिए थे
  • रिपोर्ट के अनुसार इस worm ने 500 से अधिक npm packages को संक्रमित किया और 25,000 से अधिक repositories को प्रभावित किया
  • Trigger.dev के official npm packages (@trigger.dev/*, CLI) संक्रमित नहीं हुए

हमले की टाइमलाइन

  • 24 नवंबर 04:11 UTC: malicious package का वितरण शुरू
  • 20:27 UTC: जर्मनी में एक डेवलपर मशीन संक्रमित
  • 22:36 UTC: हमलावर की पहली पहुंच और बड़े पैमाने पर repository cloning शुरू
  • 15:27~15:37 UTC (25 नवंबर): 10 मिनट तक destructive attack
  • 15:32 UTC: असामान्य गतिविधि detect हुई और 4 मिनट के भीतर access block
  • 22:35 UTC: सभी branches की recovery पूरी

संक्रमण की प्रक्रिया

  • जब डेवलपर ने pnpm install चलाया, malicious package का preinstall script execute हुआ, जिसने TruffleHog को download और run किया
  • TruffleHog ने GitHub tokens, AWS credentials, npm tokens, environment variables आदि scan करके बाहर exfiltrate किए
  • संक्रमित मशीन में .trufflehog-cache directory और उससे जुड़े files मिले
  • संक्रमण का कारण बना package delete कर दिया गया था, इसलिए tracing संभव नहीं रही

हमलावर की गतिविधियां

  • संक्रमण के बाद 17 घंटे तक reconnaissance activity जारी रही
    • अमेरिका और भारत-आधारित infrastructure का उपयोग करके 669 repositories clone की गईं
    • डेवलपर गतिविधियों की monitoring करते हुए GitHub token access बनाए रखा गया
    • “Sha1-Hulud: The Second Coming” नाम की repository बनाई गई, जिसका उपयोग credentials store करने के लिए हुआ माना गया
  • इसके बाद 10 मिनट तक destructive actions की गईं
    • 16 repositories में 199 branches पर force push की कोशिश
    • 42 PR बंद किए गए, जिनमें कुछ branch protection settings के कारण block हो गए
    • सभी commits “Linus Torvalds <email> / init” के रूप में दिखे

detection और response

  • Slack alerts के जरिए असामान्य गतिविधि real time में detect हुई
  • 4 मिनट के भीतर संक्रमित account का GitHub access block किया गया, और उसके बाद AWS·Vercel·Cloudflare सहित सभी services की access revoke की गई
  • AWS CloudTrail log analysis में सिर्फ read-only API calls मिले, production data access नहीं मिला
  • AWS ने अलग से Shai-Hulud से जुड़ी संदिग्ध गतिविधि detect कर warning भेजी

नुकसान और recovery

  • 669 repositories clone, 199 branches पर force push, 42 PR बंद
  • GitHub में server-side reflog न होने से recovery कठिन थी, लेकिन event API और local reflog की मदद से 7 घंटे में पूरा restore कर लिया गया
  • npm packages और production infrastructure प्रभावित नहीं हुए

GitHub App key exposure

  • जांच के दौरान डेवलपर laptop के trash में GitHub App private key मिली
  • इस key के पास customer repositories पर read/write permission थी, इसलिए इसे तुरंत rotate किया गया
  • database (installation ID storage) प्रभावित नहीं हुआ, इसलिए customer repository access का कोई प्रमाण नहीं मिला, हालांकि इसे पूरी तरह नकारा नहीं जा सकता
  • GitHub support team से अतिरिक्त logs मांगे गए और customers को email notice भेजा गया

Shai-Hulud का तकनीकी विश्लेषण

  • setup_bun.js चलने पर Bun runtime install होता है और background में bun_environment.js execute होता है
  • TruffleHog का उपयोग कर $HOME directory के credentials इकट्ठा किए जाते हैं
  • इकट्ठा किया गया data (contents.json, cloud.json, truffleSecrets.json आदि) random GitHub repositories पर triple base64 encoding के रूप में upload किया जाता है
  • अगर npm token मौजूद हो, तो संक्रमित account के packages को modify और republish कर worm फैलाया जाता है
  • अगर credentials न मिलें, तो home directory delete करने की कोशिश की जाती है
  • infection indicators: setup_bun.js, bun_environment.js, .trufflehog-cache/ आदि

security hardening measures

  • npm scripts पूरी तरह disable (ignore-scripts=true)
  • pnpm 10 upgrade: scripts default रूप से disabled, minimumReleaseAge (3 दिन) सेट कर नए packages की install delay
  • OIDC-आधारित npm Trusted Publishers अपनाकर long-lived tokens हटाए गए
  • सभी repositories पर branch protection लागू
  • AWS SSO में Granted लागू, session tokens encrypt किए गए
  • GitHub Actions में external contributor workflows चलाने के लिए approval अनिवार्य किया गया

अन्य टीमों के लिए सबक

  • npm install के दौरान होने वाला arbitrary code execution model स्वयं एक attack surface है
  • ignore-scripts=true सेट करना और सिर्फ जरूरी packages को whitelist करना आवश्यक है
  • pnpm minimumReleaseAge से नए packages की installation delay की जा सकती है
  • branch protection और OIDC-आधारित deployment आवश्यक security controls हैं
  • local machine पर long-lived credentials store नहीं करने चाहिए; deployment सिर्फ CI के जरिए होना चाहिए
  • Slack alert noise ही detection की key साबित हुई

मानवीय पहलू

  • संक्रमित डेवलपर की कोई गलती नहीं थी; सिर्फ npm install चलाने से यह नुकसान हुआ
  • हमले के दौरान उस account से सैकड़ों random repositories को अपने-आप ‘star’ किए जाने के संकेत मिले
  • इस घटना ने किसी एक व्यक्ति की गलती नहीं, बल्कि ecosystem की structural vulnerability को उजागर किया

सारांश मेट्रिक्स

  • पहली infection से पहले attack तक: लगभग 2 घंटे
  • हमलावर का access बना रहने का समय: 17 घंटे
  • destructive activity की अवधि: 10 मिनट
  • detection तक 5 मिनट, block तक 4 मिनट
  • पूरी recovery में 7 घंटे
  • cloned repositories: 669 / प्रभावित branches: 199 / बंद PR: 42

संदर्भ संसाधन

  • Socket.dev: Shai-Hulud Strikes Again V2
  • PostHog, Wiz, Endor Labs, HelixGuard की analysis reports
  • npm Trusted Publishers, pnpm onlyBuiltDependencies, minimumReleaseAge, Granted documentation

संबंधित पढ़ाई

3 टिप्पणियां

 
click 2025-12-15

लगता है कि pnpm की संरचना ऐसी थी जिसमें default रूप से post-install को अलग-अलग अनुमति देनी पड़ती थी, लेकिन आखिरकार developers भी अनजाने में इसे allow करने लगते हैं।
 
lamanus 2025-12-16

मेरी समझ में, npm डिफ़ॉल्ट रूप से चलने के लिए सेट होता है, इसलिए pnpm पर स्विच करके डिफ़ॉल्ट रूप से उसे disable कर दिया गया, ताकि सुरक्षा मज़बूत की जा सके।
 
GN⁺ 2025-12-15
Hacker News टिप्पणियाँ

  • npm install चलाना लापरवाही नहीं है
    समस्या यह है कि package install प्रक्रिया में मनमाना code execution स्वीकार करने वाला ecosystem मौजूद है
    लेकिन मूल security failure यह है कि हम ऐसे package manager का उपयोग कर रहे हैं जिसमें कोई third party बिना किसी verification के मेरे product में code ठूंस सकता है
    आखिरकार हम package managers और उनके operators की नीयत और क्षमता पर असीम रूप से निर्भर हैं
    और ऐसा भी लगता है कि OP ने credentials को file system में plain text के रूप में store किया था

    • मुझे लगता है कि दोनों ही समस्याएँ हैं
      language स्तर पर ऐसी संरचना बनाई जा सकती है जो code को input पढ़ने, resources consume करने, और सिर्फ type-correct output generate करने तक सीमित करे
      यह supply chain समस्या का पूरा समाधान नहीं है, लेकिन exposure का दायरा काफी कम हो जाएगा
    • यह तर्क बहुत circular है
      मतलब, “एक व्यक्ति का ऐसे tools इस्तेमाल करना गलत नहीं है, लेकिन जब सब इस्तेमाल करें तो ecosystem समस्या बन जाता है”
      यह बात कई बार साबित हो चुकी है कि बहुत से developer tools security-vulnerable हैं
      अगर सच में परवाह है, तो उसे व्यवहार में दिखाना होगा
    • IDE plugins पर भी यही बात लागू होती है
      VS Code इस्तेमाल करते समय, एक छोटा सा feature जोड़ने के लिए भी किसी अज्ञात व्यक्ति का plugin install करना पड़े, यह मुझे असुविधाजनक लगा
    • मैं सोच रहा हूँ कि third-party code execution को रोकने वाला package manager कैसे design किया जा सकता है
      आखिरकार क्या हमें ऐसा code चलाना ही नहीं पड़ेगा जिस पर भरोसा करना मजबूरी हो?
    • कुछ tools HTTP authentication के लिए सिर्फ netrc file को support करते हैं
      अगर git को HTTP पर इस्तेमाल करें, तो plain-text credential exposure path लगभग हमेशा मौजूद रहता है

  • pnpm maintainer ने एक साल पहले “post-install scripts को default रूप से block करें” का प्रस्ताव दिया था
    user के लिए यह असुविधाजनक होता, लेकिन लंबी अवधि में सब इसके लिए आभारी होते, ऐसा उनका मानना था
    संबंधित PR: pnpm/pnpm#8897

    • फिर भी वही समस्या बार-बार दोहराई जा रही है
      आखिरकार यह convenience ने security को हरा दिया वाला एक और मामला है

  • उन्होंने कहा कि “database प्रभावित नहीं हुआ”, लेकिन अगर attacker ने AWS और secrets तक पहुँच बना ली थी, तो मेरे हिसाब से वह पहले ही compromise हो चुका था
    अगर access की संभावना थी, तो उसे compromise मानना चाहिए

    • अगर AWS resource access logs मौजूद हैं, और permissions revoke होने से पहले access के कोई निशान नहीं मिले, तो data को सुरक्षित माना जा सकता है

  • malware चलने के बाद origin trace करना लगभग असंभव हो जाता है
    pnpm install भी सामान्य रूप से पूरा हो जाता है, इसलिए इसे detect करना मुश्किल है
    अगर Sentinel One या CrowdStrike जैसे EDR होते, तो investigation के लिए ज्यादा clues मिल सकते थे

    • अगर EDR मौजूद होता, तो संभव है कि वह Trufflehog attack chain को detect या block कर देता

  • “कुल 669 repo clone किए गए” वाला हिस्सा ध्यान खींचता है
    100 से कम कर्मचारियों वाली कंपनी के पास 600 से अधिक repo होना सामान्य है या नहीं, यह जानने की जिज्ञासा है

    • बिल्कुल सामान्य है। repo पालतू जानवर नहीं, livestock हैं
    • हमारी organization में 7 लोग हैं, लेकिन GitHub पर 365 repo हैं
      repo की संख्या पर team size से ज्यादा company की उम्र और projects की lifespan असर डालती है
    • अगर microservices पसंद करने वाला architect हो, तो ऐसा नतीजा आता है

  • pnpm ने पहले ही preinstall जैसे lifecycle scripts के automatic execution को बंद कर दिया है, इसलिए लगता है कि उन्होंने पुराना version इस्तेमाल किया था
    संबंधित PR देखें

    • लेख के अंत में यह उल्लेख है कि उन्होंने latest major version में update किया
    • मुझे लगा था कि pnpm इस्तेमाल करने की यही मुख्य वजह है, इसलिए भ्रम हो रहा है
    • अगर आखिरकार उन्होंने पुराने package manager से dependency update किया, तो यह उनकी जिम्मेदारी है
    • यह भी हो सकता है कि project में खुद postinstall script रही हो
      pnpm dependencies की scripts को block करता है, लेकिन project-level scripts अभी भी चलाता है

  • इतनी पारदर्शी post-mortem साझा करने के लिए धन्यवाद
    ऐसे मामले पूरे industry के लिए महत्वपूर्ण हैं
    यह जानने की जिज्ञासा है कि attack traffic सामान्य developer traffic से अलग पहचान में आता था या नहीं
    हम भी dev environment में egress filtering मजबूत करने की कोशिश कर रहे हैं, लेकिन npm install बार-बार टूट जाता है, इसलिए दिक्कत हो रही है

    • GitHub organization की IP allow list feature का उपयोग ऐसे हमलों से बचाव में मददगार हो सकता है

  • मैं व्यक्तिगत laptop पर git security के बारे में सोच रहा हूँ
    अभी local में SSH key रखकर push करता हूँ
    admin privileges भी हैं, इसलिए जोखिम है। इसे और सुरक्षित कैसे बनाया जाए, यह जानना चाहता हूँ

    • 1Password का उपयोग करके SSH keys और Git signing manage करें, और GitHub OAuth या CLI login से push/pull करने की configuration की सिफारिश है
      इससे signing key और access key को अलग किया जा सकता है, और admin account को अलग से manage किया जा सकता है
      संबंधित दस्तावेज़: 1Password SSH Agent, Git Commit Signing, GitHub OAuth, GitHub CLI Login
    • मैं SSH private key को TPM में store करता हूँ और PKCS11 के जरिए SSH agent में इस्तेमाल करता हूँ
      इसका लाभ यह है कि key बाहर leak नहीं हो सकती, लेकिन अगर malware मेरी machine पर चल रहा हो, तब भी जोखिम बना रहता है
      Linux उदाहरण, macOS उदाहरण
    • अगर laptop infect हो जाए, तो बचाव का कोई तरीका नहीं
      TPM या Yubikey से इसे थोड़ा मुश्किल बनाया जा सकता है, लेकिन पूरी सुरक्षा असंभव है
      admin काम अलग dedicated machine पर करना ज्यादा सुरक्षित है
    • Yubikey में GPG key रखकर gpg-agent से SSH authentication करने का तरीका भी है
      push या commit के समय PIN डालकर unlock किया जाता है
    • main branch पर direct push रोक दें, और MFA अनिवार्य करें, तो attacker के लिए तुरंत deploy branch तक पहुँचना कठिन होगा

  • Torvalds नाम वाला commit infection के बाद अक्सर दिखने वाला signature था
    Microsoft की आधिकारिक analysis post में भी इसका उल्लेख है
    यह worm बहुत noisy था, और कुछ attackers ने exposed credentials का उपयोग करके private repo को public कर दिया या readme बदलकर प्रचार के लिए दुरुपयोग किया

  • अगर attacker बिना तोड़फोड़ किए चुपचाप सिर्फ data exfiltrate करता, तो क्या ऐसी detection संभव होती, इस पर संदेह है