GitLab ने व्यापक NPM सप्लाई चेन हमला खोजा

 (about.gitlab.com)
1 पॉइंट द्वारा GN⁺ 2025-11-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • npm ecosystem में विनाशकारी malware variant तेज़ी से फैल रहा है, और GitLab security team ने इसे डिटेक्ट किया है
  • malware, Shai-Hulud का विकसित रूप है, जिसमें संक्रमित डेवलपर के दूसरे packages तक अपने-आप संक्रमण फैलाने वाली worm-जैसी propagation structure है
  • GitHub·AWS·GCP·Azure आदि से credentials की चोरी के बाद, attacker-controlled GitHub repository में data exfiltration किया जाता है
  • GitHub और npm access दोनों एक साथ ब्लॉक होने पर user data को तुरंत delete करने वाला ‘deadman switch’ इसमें शामिल है
  • GitLab ने पुष्टि की कि उसके अपने systems संक्रमित नहीं हुए, और Dependency Scanning तथा GitLab Duo Chat के ज़रिए detection और response के उपाय दिए

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

  • GitLab Vulnerability Research team ने npm ecosystem में बड़े पैमाने पर सप्लाई चेन हमला डिटेक्ट किया
    • internal monitoring system ने कई संक्रमित packages खोजे
    • malware को Shai-Hulud का variant पाया गया
  • malware, worm-जैले propagation के ज़रिए संक्रमित डेवलपर के दूसरे packages तक अपने-आप फैलता है
  • GitLab ने पुष्टि की कि उसने अपने यहाँ malicious package का उपयोग नहीं किया, और security community के साथ जानकारी साझा की

हमले की आंतरिक संरचना

  • internal monitoring system द्वारा पकड़े गए malicious npm packages ये काम करते हैं
    • GitHub, npm, AWS, GCP, Azure के credentials इकट्ठा करना
    • चुराया गया data attacker-controlled GitHub repository में भेजना
    • पीड़ित के दूसरे packages को अपने-आप संक्रमित करना
    • infrastructure access रुकने पर destructive payload चलाना
  • कई संक्रमित packages की पहचान हुई है, और जांच अभी जारी है

तकनीकी विश्लेषण: हमला कैसे आगे बढ़ता है

प्रारंभिक संक्रमण वेक्टर

  • malware, multi-stage loading process के ज़रिए system में घुसता है
    • संक्रमित package के package.json में setup_bun.js script जोड़ी जाती है
    • ऊपर से यह Bun JavaScript runtime install करने वाले script की तरह दिखती है
    • लेकिन वास्तव में यह bun_environment.js (10MB, obfuscated payload) चलाती है
  • छोटा loader file और बड़ा obfuscated payload मिलाकर detection से बचने की कोशिश की गई

credentials संग्रह

  • execute होते ही यह कई sources से tokens और secrets इकट्ठा करता है
    • GitHub tokens(ghp_, gho_)
    • AWS, GCP, Azure credentials
    • npm tokens(.npmrc और environment variables)
    • Trufflehog tool से पूरे home directory को scan करके API keys, passwords, Git history आदि खोजे जाते हैं

data exfiltration network

  • चुराए गए GitHub token से “Sha1-Hulud: The Second Coming.” विवरण वाला public repository बनाया जाता है
    • यह repository data dropbox की भूमिका निभाती है
    • persistence के लिए GitHub Actions runner install किया जाता है
  • अगर permissions पर्याप्त न हों, तो वही marker वाले दूसरे repositories खोजकर दूसरे systems के tokens का पुन: उपयोग किया जाता है
    • इससे distributed token-sharing network बनता है

सप्लाई चेन propagation

  • चुराए गए npm token की मदद से पीड़ित के सभी packages को संक्रमित किया जाता है
    1. original package डाउनलोड करना
    2. setup_bun.js को preinstall script के रूप में insert करना
    3. bun_environment.js payload जोड़ना
    4. version number बढ़ाना
    5. संक्रमित package को npm पर फिर से publish करना

deadman switch

  • malware, GitHub (data exfiltration) और npm (propagation) access को लगातार monitor करता है
    • अगर दोनों channels ब्लॉक हो जाएँ, तो तुरंत data destruction execute करता है
  • Windows: user files delete करना और disk sectors overwrite करना
  • Unix-आधारित: shred command से files overwrite करने के बाद delete करना
  • GitHub repositories को bulk में delete करने या npm tokens को बड़े पैमाने पर revoke करने पर, संक्रमित systems द्वारा एक साथ data delete करने का खतरा मौजूद है

compromise indicators (IoC)

  • मुख्य detection indicators
    • file: bun_environment.js (malicious post-install script)
    • directory: .truffler-cache/, .truffler-cache/extract/
    • process: del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
    • commands: curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"

GitLab की detection और response support

  • GitLab Ultimate users built-in security features से तुरंत exposure जांच सकते हैं
    • Dependency Scanning enable होने पर, package-lock.json या yarn.lock में संक्रमित packages अपने-आप डिटेक्ट हो जाते हैं
    • infected packages शामिल होने वाले merge request पर warning दिखाई जाती है
  • GitLab Duo Chat के साथ integration के ज़रिए तेज़ query-based detection संभव है
    • उदाहरण: “Shai-Hulud v2 campaign से प्रभावित dependencies हैं क्या?”
    • Security Analyst Agent project vulnerability data देखकर तुरंत जवाब देता है
  • कई repositories मैनेज करने वाली teams के लिए CI/CD-आधारित automated detection और agent-based rapid response साथ में अपनाने की सिफारिश की गई है

आगे की दिशा

  • इस हमले को attack infrastructure की सुरक्षा के लिए पीड़ित के data destruction का उपयोग करने वाले नए तरह के supply chain attack के रूप में देखा जा रहा है
  • GitLab, community के साथ मिलकर safe recovery strategy विकसित कर रहा है, और automated detection system से variants की लगातार निगरानी कर रहा है
  • शुरुआती जानकारी साझा करके deadman switch से होने वाले secondary damage को रोकना इसका लक्ष्य है

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

1 टिप्पणियां

 
GN⁺ 2025-11-29
Hacker News राय

  • लगभग एक महीने पहले मुझे एक झंझट वाला काम करना था, इसलिए मैंने एक NPM पैकेज ढूंढा
    brew install npm चलाते ही dependency waterfall टूट पड़ी, और मैं रुककर risk और benefit के बारे में सोचने लगा, फिर आखिरकार brew uninstall npm करके वापस लौट आया
    इसकी जगह मैंने पुराने Unix utility pipeline और awk से काम पूरा किया, और अब सोचता हूँ कि वही सबसे अच्छा फ़ैसला था

    • सबक साफ़ है — local scripting के लिए web tech का इस्तेमाल नहीं करना चाहिए
      NPM ऐसा टूल है जो browser compatibility की समस्या हल करने के लिए बना था, इसलिए browser के बिना वाले environment में यह बेवजह की complexity लाता है
    • इसी वजह से containerization या virtualization की ज़रूरत होती है
      Node या Python जैसे dependency-heavy ecosystem के code को main system पर सीधे चलाने से supply chain attack का जोखिम बढ़ता है
      इसलिए मैं तो Python या JS interpreter को base system पर install ही नहीं करता
    • मैं भी पहले npm को सिर्फ Docker container के अंदर चलाता था, लेकिन forums में लोग अक्सर उसका मज़ाक उड़ाते थे
      आखिर में मैंने छोड़ दिया, लेकिन अब लगता है कि मैं सही था
    • मेरा भी ऐसा ही अनुभव रहा। artillery जितनी dependencies खींचना चाहता था, उसे देखकर मैंने तुरंत छोड़ दिया
    • विडंबना यह है कि developers हमेशा कहते हैं कि “common sense ही सबसे अच्छी security है”, लेकिन फिर एक ही command से अनगिनत unverified packages install कर लेते हैं

  • किसी ने कहा था, “अगर GitHub malicious repositories को बड़े पैमाने पर delete कर दे, तो हज़ारों systems एक साथ user data नष्ट कर सकते हैं”
    यह किसी hostage situation जैसा लगता है — इसलिए “hostage को गोली मार दो” वाला मज़ाक भी आया

    • लेकिन hostage (user) खुद ही उस ख़तरे में गया था, इसलिए आखिरकार यह उसकी अपनी पसंद का नतीजा है

  • मैं भी इस npm attack का शिकार हूँ
    यह जानकर झटका लगा कि GitHub CLI HOME directory में plain text OAuth token स्टोर करता है
    अगर attacker वहाँ पहुँच जाता, तो वह मेरे account से लगभग सब कुछ कर सकता था

    • असल में GitHub CLI token को सिर्फ तब plain text में स्टोर करता है जब keyring मौजूद न हो
      macOS पर यह OS keychain में सुरक्षित रहता है — संबंधित चर्चा
    • सही है, लेकिन browser cookie files में भी लगभग यही समस्या होती है
      Chrome OS protection का उपयोग करता है, लेकिन Firefox अभी नहीं
      आखिरकार sandbox-based access control ही मूल समाधान है
    • सभी tokens को protected keychain में होना चाहिए
      लेकिन platforms के बीच कोई consistent solution नहीं है, और macOS पर भी कोई पूरी तरह perfect तरीका नहीं है
    • मैं भी victim हूँ। Backstage install करने के बाद infection हुआ
      ~/.dev-env directory बन गई और मेरा laptop GitHub runner में बदल गया
      Bluefin Linux के read-only file system की वजह से शायद नुकसान कम हुआ

  • सब लोग सिर्फ npm को दोष दे रहे हैं, लेकिन GitHub की ज़िम्मेदारी भी बड़ी है
    वह malicious repositories को जल्दी detect नहीं कर पाया, और malware repositories की समस्या पहले से ही गंभीर है

    • फिर भी, GitHub पर upload होने की वजह से कुछ लोगों को नुकसान का जल्दी पता चल गया
      अगर यह चुपचाप किसी external server पर भेजा गया होता, तो स्थिति और भयानक होती
    • Microsoft सब कुछ filter नहीं कर सकता
      community level के tools और practices की ज़रूरत है
    • GitHub, Microsoft के ownership में है, इसलिए यह GoLang package repository से भी जुड़ा हुआ है
      अगर commercial regulation या build workflow restrictions आएँ, तो यह बड़ी समस्या बन सकती है
    • यह मानने से इनकार नहीं किया जा सकता कि दोनों कंपनियों का security level औसत है
    • यह malware एक ही pattern से repositories बनाता है, इसलिए आसान rules से भी इसे detect किया जा सकता था

  • मैं सोच रहा था कि सिर्फ NPM ही attack target क्यों बनता है
    Python और Java भी बहुत लोकप्रिय हैं, लेकिन हाल में वे अपेक्षाकृत शांत रहे हैं

    • NPM में post-install hook arbitrary commands चला सकता है,
      और version range dependency की culture की वजह से infection बहुत तेज़ी से फैलता है
      Java में आम तौर पर specific versions pin की जाती हैं, इसलिए ऐसी घटना कम होती है
    • Node की standard library छोटी है और community dependency बहुत ज़्यादा है
      इसलिए एक package दर्जनों sub-dependencies खींच लाता है
    • JS, GitHub पर सबसे लोकप्रिय language है, इसलिए attack surface बड़ा है
      और कम अनुभव वाले developers भी ज़्यादा हैं, जिससे security कमजोर पड़ती है
    • JS community में “latest version obsession” बहुत ज़्यादा है
      दूसरे language ecosystem verification के बाद update करते हैं, लेकिन JS में लोग तुरंत upgrade कर देते हैं
    • NPM की security boundary कमजोर है
      install के समय scripts को खुलकर चलाने देता है, जबकि JVM या Python में ऐसा नहीं है

  • .npmrc में

    ignore-scripts=true

    जोड़ने से attack vector कम किया जा सकता है
    संबंधित लेख

    • जानना चाहता हूँ कि install से पहले preinstall/postinstall hook वाले packages को पहले से जाँचने का कोई तरीका है या नहीं
    • अगर “ignore scripts” सुरक्षित है, तो फिर यह option मौजूद ही क्यों है,
      और क्या इसे disable करने पर dependency टूटने का जोखिम नहीं होगा?
    • लेकिन आखिरकार Node environment में JS चलाने पर environment variables या files तक access को रोका नहीं जा सकता
    • या फिर बस pnpm इस्तेमाल करना भी एक तरीका है

  • इस attack में सबसे बड़ी चिंता credentials theft है
    अगर आपने infected package install किया है, तो environment variables या .npmrc tokens लीक हो चुके हो सकते हैं
    तुरंत tokens और API keys rotate करनी चाहिए
    नियमित rotation, compromise के बाद की प्रतिक्रिया नहीं बल्कि पहले से किया गया preventive measure है

    • अगर developer password reuse करते हैं, तो यह सचमुच बहुत गंभीर समस्या है
      credentials को environment variables या files में store नहीं करना चाहिए; security key या encrypted file का उपयोग करना चाहिए
    • अगर infection हुआ या नहीं, यह पता नहीं है, तो पहले infection detection → cleanup → token rotation के क्रम में आगे बढ़ना चाहिए
    • यह attack सिर्फ infection नहीं है, बल्कि पूरे ecosystem को hostage बनाने वाला रूप है, इसलिए और भी ख़तरनाक है
      यह कुछ-कुछ distributed ledger में malicious transaction डालने जैसा है
    • secrets को हमेशा secure storage (secret locker) में रखना चाहिए
      समस्या यह है कि अब भी कई services plain text storage को default बनाए रखती हैं
    • और यह malware propagation रुकने पर data destruction की भी कोशिश करता है

  • ऐसे attacks बार-बार हो रहे हैं, फिर भी समझ नहीं आता कि AI-based detection system काम क्यों नहीं कर रहे
    Microsoft AI को इतना बढ़ावा देता है, लेकिन GitHub security में उसका इस्तेमाल होता नहीं दिखता

    • लेकिन “AI ने attack detect किया” अब security marketing का घिसा-पिटा जुमला बन चुका है
      जैसे उस दौर में, जब firewall द्वारा रोके गए हर प्रयास को attack कहा जाता था, उसका मतलब भी फीका पड़ गया था
    • हमारी company SonaType Lifecycle इस्तेमाल करती है, और उनका दावा है कि वह AI के आधार पर ऐसे attacks रोकती है
      अंदर से इसे SonaType IQ Server support करता है
    • मौजूदा “AI” असल में generative model है, इसलिए उसका focus evaluation से ज़्यादा generation पर है
      वास्तव में curl project को AI-generated security report spam झेलना पड़ा है

  • सोचता हूँ कि postinstall scripts को लगातार allow करने की कोई वजह बचती भी है या नहीं
    क्या users से यह पूछना बेहतर नहीं होगा कि उन्हें इसे चलाना है या नहीं?

    • लेकिन ज़्यादातर users “हाँ” ही दबाएँगे,
      और CI servers में non-interactive installation चाहिए होती है, इसलिए व्यवहार में यह मुश्किल लगता है

  • लेख बहुत insightful था, लेकिन अंत में यह GitLab security features के प्रचार पर खत्म हुआ, जो थोड़ा खटका

    • GitLab users के लिए शायद वह उपयोगी रहा हो
    • फिर भी इससे लेख की insight खुद कम नहीं होती