Shai-Hulud की वापसी: 300 से अधिक NPM पैकेज संक्रमित

 (helixguard.ai)
17 पॉइंट द्वारा GN⁺ 2025-11-25 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • NPM रजिस्ट्री में 1,000 से अधिक कंपोनेंट्स कुछ ही घंटों में एक ही तरीके से संक्रमित हुए और malicious code वाले नए versions वितरित किए गए
  • malicious packages ने Bun runtime install script का रूप धारण करके setup_bun.js और obfuscated bun_environment.js जोड़ा, और execution के समय TruffleHog का उपयोग कर local credentials चुरा लिए
  • एकत्र की गई AWS/GCP/Azure·GitHub·NPM tokens जैसी sensitive information को SHA1HULUD नाम के GitHub Action runner के जरिए बाहर भेजा गया
  • malicious script ने npm publish अपने आप चलाकर worm-शैली self-replication किया, जिसके परिणामस्वरूप 27,000 से अधिक GitHub repositories संक्रमित हो गईं
  • इसे open source ecosystem में फैले supply chain security threat को फिर से उजागर करने वाली घटना के रूप में देखा जा रहा है

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

  • 24 नवंबर 2025 को HelixGuard ने NPM रजिस्ट्री में 1,000 से अधिक पैकेजों को कुछ घंटों के भीतर एक ही तरीके से संक्रमित पाया
    • नए versions ऐसे छिपाए गए थे मानो वे Bun runtime जोड़ रहे हों, और उनमें preinstall: node setup_bun.js script शामिल थी
    • साथ में वितरित bun_environment.js फ़ाइल obfuscated malicious code थी, जो चलने पर TruffleHog को डाउनलोड करके execute करती थी
  • TruffleHog local environment में NPM tokens, AWS/GCP/Azure credentials, environment variables आदि को scan करके चुरा लेता था
  • चुराई गई जानकारी को GitHub Action runner SHA1HULUD बनाकर, Sha1-Hulud: The Second Coming. विवरण वाले GitHub repository के जरिए बाहर भेजा गया
  • HelixGuard ने संकेत दिया कि यह हमला सितंबर 2025 में हुई “Shai-Hulud” घटना के उसी हमलावर द्वारा किया गया हो सकता है

malicious code के व्यवहार का विश्लेषण

  • उदाहरण के तौर पर @asyncapi/specs पैकेज के विश्लेषण में पाया गया कि NPM पर वितरित version संक्रमित था, लेकिन GitHub का मूल repository सुरक्षित था
  • हमलावर ने package.json में बदलाव कर setup_bun.js जोड़ा, और उसे bun_environment.js को call करने के लिए configure किया
  • bun_environment.js 10MB से अधिक आकार की उच्च स्तर पर obfuscated JavaScript file थी, जिसके मुख्य कार्य इस प्रकार थे
    • environment variables से cloud credentials और tokens एकत्र करना
    • TruffleHog का उपयोग करके secret key scan करना
    • GitHub Actions के जरिए data exfiltration करना
  • इसके अलावा package.json में बदलाव कर infection code डाला गया और npm publish अपने आप चलाकर worm-शैली propagation की गई

GitHub संक्रमण और data exfiltration

  • malicious script ने .github/workflows/formatter_123456789.yml फ़ाइल बनाई और SHA1HULUD runner को register किया
  • उस workflow ने repository के secrets को double Base64 encoding के साथ actionsSecrets.json फ़ाइल में package किया
  • इसके बाद Sha1-Hulud: The Second Coming. विवरण वाले random नाम के GitHub repositories बनाकर data upload किया गया
  • HelixGuard ने पुष्टि की कि 27,000 से अधिक GitHub repositories संक्रमित हुईं
  • चुराए गए secret data में AWS_ACCESS_KEY_ID, SLACK_WEBHOOK_URL, CODECOV_TOKEN, WEBFLOW_TOKEN सहित कई services के credentials शामिल थे

संक्रमित पैकेजों की सूची

  • HelixGuard ने बताया कि सैकड़ों NPM पैकेज संक्रमित हुए
    • प्रमुख रूप से @asyncapi, @ensdomains, @posthog, @zapier, @postman, @voiceflow जैसे संगठनों के पैकेज शामिल थे
    • प्रत्येक पैकेज के कई versions (जैसे @asyncapi/specs@6.8.2, @postman/csv-parse@4.0.5) संक्रमित हुए
  • अधिकांश संक्रमित पैकेज सामान्य open source projects का रूप धारण किए हुए थे, और automated deployment process में malicious code डाले जाने के रूप में पाए गए

सुरक्षा संबंधी संकेत

  • यह हमला supply chain security की कमजोरी का दुरुपयोग कर बड़े पैमाने पर open source ecosystem को संक्रमित करने का मामला है
  • इससे NPM·GitHub·cloud credentials सहित पूरे development infrastructure में security management को मजबूत करने की जरूरत सामने आई
  • HelixGuard ने संक्रमित पैकेजों की installation तुरंत रोकने और संबंधित tokens व credentials को तुरंत revoke करने की सिफारिश की

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

5 टिप्पणियां

 
ahwjdekf 2025-11-27

js इकोसिस्टम वाकई पूरी तरह बिखरा हुआ कचरा है।
 
developerjhp 2025-11-25

मैंने एक real-time scanner script बनाकर देखा है।

संदिग्ध repository के path में
npx sha1-hulud-scanner
दर्ज करें।

Source code : https://github.com/developerjhp/sha1-hulud-scanner
 
GN⁺ 2025-11-25
Hacker News टिप्पणियाँ

  • एक टिप साझा कर रहा हूँ: NPM की जगह PNPM इस्तेमाल करना बेहतर है
    PNPM 10.x कई attack vectors को ब्लॉक करता है
    1️⃣ डिफ़ॉल्ट रूप से post-install scripts नहीं चलाता, और manual approval चाहिए
    2️⃣ इसे ऐसे configure किया जा सकता है कि नया release publish होने के कुछ समय बाद ही install हो, जैसे 4 दिन
    production CLI environment में NPM बहुत अस्थिर है
    publisher keys को least privilege तक सीमित रखना चाहिए, उन्हें सिर्फ़ खास packages से bind करना चाहिए, और IP को CI/CD runners से बाँधना चाहिए
    publish keys को local में न रखें, और ज़रूरत हो तो OIDC Trusted Publisher या token-based access पर विचार करें

    • NPM ऐसा लगता है जैसे technical debt बहुत ज़्यादा जमा होने का नतीजा हो
      सिर्फ़ lockfile पर ही पाँच बार कोशिश की गई, फिर भी वह अब तक पूरी तरह सही नहीं है
      structure और commit history देखें तो टीम मेहनत से सुधार कर रही है, लेकिन लगता है शुरुआत बहुत गहरे गड्ढे से हुई थी
      अब भी यह file transfer के दौरान early EOF detect नहीं कर पाता, और cache में अधूरी files छोड़ देता है, इसलिए धीमे internet environment में update fail होने पर बहुत समय बर्बाद होता है
    • मैं HashiCorp Vault / OpenBao के dynamic secrets management तरीके को पसंद करता हूँ
      शुरुआत में यह जटिल लगता है, लेकिन secrets को lease के concept से manage किया जा सकता है
      हर CI build के लिए lease बनाई जा सकती है और खत्म होने पर यह अपने-आप revoke हो जाती है, साथ ही TTL और automatic rotation भी मिलता है
      इससे long-term credentials छिपाए जा सकते हैं, और सिर्फ़ build के समय short-lived token जारी किए जा सकते हैं
      ऐसे हमलों की वजह से कंपनी के भीतर असली security discussions सक्रिय होना एक सकारात्मक बात है
    • बस npm ci इस्तेमाल करें
      यह केवल package-lock.json में दिए गए versions install करता है, इसलिए automatic updates से होने वाले हमले का जोखिम घटाया जा सकता है
      सिर्फ़ intentional updates करने की आदत महत्वपूर्ण है
    • Python ecosystem में pip install --only-binary=:all: option से ऐसी ही protection मिल सकती है
      यह source distributions को पूरी तरह ब्लॉक कर देता है और सिर्फ़ wheel install करता है
      हालाँकि version constraints की समस्या हो सकती है
      uv में --exclude-newer option से PNPM के ‘minimum release age’ feature जैसा व्यवहार पाया जा सकता है
    • हाल में “dependency cooldown” पर एक लेख देखा, और उससे बहुत सहमति हुई
      मैं सभी dependencies को pin करता हूँ और dependabot alerts को manually review करता हूँ
      यह ज़्यादा सतर्कता है या सही आदत, इस पर अब भी सोच रहा हूँ

  • आज ख़ास तौर पर एक प्रासंगिक लेख है: “We should all be using dependency cooldowns”
    automatic dependency updates एक दिन की vulnerability से भी ज़्यादा खतरनाक हो सकती हैं
    क्योंकि हज़ारों lock files में फैल चुके infected packages को वापस हटाना कहीं ज़्यादा कठिन होता है

    • मुझे लगता है कि update केवल ज़रूरत पड़ने पर ही करना बेहतर है
      अगर सब ठीक चल रहा है, तो उसे छेड़ने की कोई वजह नहीं है
    • लेकिन ऐसा करने पर भी bugs किसी और को ठीक करने पड़ेंगे, और अगर सब cooldown इस्तेमाल करें तो अंत में सब वहीं के वहीं रह सकते हैं
    • Python के uv में uv lock --exclude-newer $(date --iso -d "24 hours ago") command से मिलता-जुलता असर पाया जा सकता है
      इससे जुड़ी चर्चा issue #14992 में है
    • npm-check-updates से भी यह आसानी से किया जा सकता है
      npx npm-check-updates -c 7 command से 7 दिन का cooldown सेट किया जा सकता है
      npm-check-updates docs देखें
    • मैं इस तर्क से सहमत नहीं हूँ
      cooldown 0-day vulnerabilities के फैलाव का समय बढ़ा सकता है
      अगर सब एक ही cooldown अपनाएँ, तो बस detection delay होगा

  • मैं PostHog का सह-संस्थापक हूँ
    हम इस हमले के पीड़ितों में थे
    संक्रमित versions थे posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
    हमने सभी keys और passwords बदल दिए हैं, और नए versions release कर दिए हैं
    हम root cause analysis कर रहे हैं और status.posthog.com पर updates देंगे

    • मैं recommend करूँगा कि अगर नया package release किसी CI/CD run से जुड़ा न हो, तो alarm बजना चाहिए
    • जिज्ञासा है कि क्या संक्रमित JS ने वास्तव में end users को प्रभावित किया
      अगर किसी website ने संक्रमित version deploy किया था, तो जानना चाहूँगा कि क्या visitors को नुकसान पहुँचा
    • अगर कारण अभी तक पता नहीं है, तो संभव है कि हमला अब भी फैल रहा हो
    • latest version फिर से संक्रमित हो सकता है, तो लोग इस बार इस पर भरोसा क्यों करें, यह सवाल जायज़ है
    • अच्छा है कि X पर की गई घोषणा के बजाय यहाँ update ज़्यादा साफ़ दिख रही है। उम्मीद है recovery अच्छी तरह हो

  • एक गंभीर सवाल: क्या Node में नया project शुरू करना सही है
    मैं Astro से SaaS frontend बना रहा हूँ, और हर dependency update पर बेचैनी होती है
    npm ecosystem में security की कमी बहुत गंभीर लगती है

    • समस्या Node या JS नहीं, बल्कि packaging model है
      Rust जैसे ecosystems, जो असंख्य subpackages पर निर्भर हैं, वे भी कभी न कभी यही झेलेंगे
      C, C++, Odin की तरह package manager न होना सुरक्षा के लिहाज़ से शायद ज़्यादा समझदारी हो सकती है
    • मेरे हिसाब से यह Node से ज़्यादा npm की समस्या है
      हाल में मैं Deno के JSR पर ज़्यादा भरोसा करता हूँ
      JSR-based packages npm पर भी cross-publish होते हैं, और कुछ packages सिर्फ़ Deno के लिए भी हैं
      उदाहरण के लिए Lume धीमा है, लेकिन एक स्थिर SSG के रूप में प्रभावशाली लगा
    • यह सिर्फ़ Node की समस्या नहीं है
      npm सबसे बड़ा repository है, इसलिए attackers के लिए इसकी value ज़्यादा है
      RubyGems या Cargo में भी यह पूरी तरह हो सकता है
    • Node से बचने की राय कुछ ज़्यादा ही है
      बस यह सबसे ज़्यादा इस्तेमाल होने वाला ecosystem है, इसलिए हमले यहीं केंद्रित होते हैं
      dependencies को सावधानी से manage करें, और रोज़ update न करें, बस इतना काफ़ी है
    • हमने product security analysis platform PHP में बनाया है
      इसका एक फ़ायदा यह है कि page rendering के लिए 100 से ज़्यादा dependencies की ज़रूरत नहीं पड़ती
      project link देखें

  • आजकल मैं सारा development सिर्फ़ Podman containers के अंदर करता हूँ
    जो code मैंने नहीं पढ़ा, उसे हमेशा isolated environment में चलाता हूँ
    यह perfect नहीं है, लेकिन कम से कम एक बुनियादी security habit तो है

    • ज़्यादातर लोगों को 99.99% मामलों में कोई समस्या नहीं होती, इसलिए उनका जोखिम-बोध सुस्त हो जाता है
      security अक्सर experts को सौंपा गया क्षेत्र बन जाता है, इसलिए व्यवहार में बदलाव लाना कठिन है
    • npm packages की dependency tree बहुत गहरी होती है; ऐसे में container isolation कैसे काम करता है, यह जानना चाहूँगा
    • PostHog SDK जैसे npm packages को container के अंदर कैसे handle किया जाता है, इस पर ठोस तरीका जानना चाहता हूँ
    • Docker की तुलना में Podman ज़्यादा सुरक्षित है, और ज़रूरत पड़े तो QEMU जैसी अतिरिक्त isolation पर भी विचार किया जा सकता है
    • मैं तो अलग local user से SSH करके tmux में development करता हूँ

  • 12 साल पहले NPM एक बार पूरी तरह डाउन हो गया था
    तब वह सिर्फ़ एक open source project था, लेकिन अब यह Microsoft के पास है
    अगर दुनिया की सबसे बड़ी कंपनियों में से एक इसके पीछे है, तो क्या उसे ऐसी समस्याएँ हल नहीं करनी चाहिए?
    लेकिन अब भी बहुत कुछ बदला हुआ नहीं दिखता

    • MS तो Windows तक को ठीक से manage नहीं कर पाता
      enterprise licensing से सीधा पैसा न बने तो चीज़ों को छोड़ देता है
      इसलिए Windows 11 एक marketing package जैसा लगता है

  • हम फिलहाल हमलावर गतिविधि को monitor कर रहे हैं, और संक्रमित packages की सूची Wiz ब्लॉग पर अपडेट कर रहे हैं
    हम malicious payload का reverse engineering कर रहे हैं, और कुछ घंटों में नतीजे साझा करेंगे

  • PostHog का “Talk to a human” chat वास्तव में robot response दे रहा था, जो काफ़ी परेशान करने वाला था
    emergency support link भी ठीक से नहीं दिखाया गया
    इसलिए मैं पूछना चाहता हूँ — किन versions से बचना चाहिए?

    • मैं सह-संस्थापक हूँ। main thread और status.posthog.com पर पहले ही पोस्ट कर चुका हूँ
      संक्रमित versions थे posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
      latest version पर update कर लेने से आप सुरक्षित हैं
    • Slack channel में भी मुझे यही versions list साझा की गई थी

  • मुझे हैरानी है कि ऐसी package-level अव्यवस्था हमेशा Node ecosystem में ही क्यों दिखती है
    समझ नहीं आता कि यह community जटिल install hooks और automatic updates को अच्छी engineering क्यों मानती है
    अब समझ आता है कि Node के creator ने इसे क्यों छोड़ दिया

    • Node नया PHP बन गया है
      विशाल ecosystem, नए developers की भरमार, security awareness की कमी, और छोटे-से feature के लिए भी library dependency
    • अगर कोई ecosystem गंभीर है, तो package maintainers होने चाहिए
      Debian की तरह भरोसेमंद maintainers को verification करना चाहिए, लेकिन JS community इसे gatekeeping कहकर ठुकरा देती है
      इसलिए ऐसी स्थितियाँ बार-बार दोहराई जाती हैं
    • दूसरों को नीचा दिखाकर श्रेष्ठता महसूस करना बस थोड़ी देर का सुख है
      उस रवैये से कुछ भी नहीं बदलेगा

  • थोड़ा विषय से हटकर, लेकिन जानना चाहता हूँ कि HelixGuard कौन है
    उसकी website बुरी हालत में है, और जानकारी भी लगभग नहीं के बराबर है
    कहा जा रहा है कि उसके clients crypto exchanges हैं, जो कुछ संदिग्ध लगता है

    • X (Twitter) account के मुताबिक यह Singapore/Japan आधारित है
      HelixGuard X account
 
laeyoung 2025-11-25

2️⃣ नया release deploy होने के बाद एक तय अवधि (जैसे: 4 दिन) बीतने पर ही install होने के लिए सेट किया जा सकता है

यह तो बहुत बढ़िया फीचर है। Google भी कभी-कभी bug की वजह से काम न करने वाला version NPM पर upload कर देता है, इसलिए कभी-कभी मुझे लगता है कि क्या यह मेरी ही bug है, और मैं घबरा जाता हूँ।