Bitwarden CLI, चल रहे Checkmarx सप्लाई चेन अभियान में समझौता-ग्रस्त

 (socket.dev)
1 पॉइंट द्वारा GN⁺ 7 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • npm के लिए Bitwarden CLI पैकेज को चल रहे Checkmarx सप्लाई चेन हमले के हिस्से के रूप में समझौता-ग्रस्त किया गया, और अभी तक पुष्टि किया गया प्रभाव दायरा @bitwarden/cli 2026.4.0 बिल्ड तक सीमित है
  • पैकेज में शामिल bw1.js मैलवेयर वही इन्फ्रास्ट्रक्चर और obfuscation तकनीक इस्तेमाल करता है, जैसे audit.checkmarx[.]cx/v1/telemetry, और यह समझौता-ग्रस्त GitHub Action के जरिए CI/CD compromise के संकेतों से भी मेल खाता है
  • संग्रह का दायरा सिर्फ GitHub tokens तक सीमित नहीं है, बल्कि AWS, Azure, GCP credentials, .npmrc, SSH keys, environment variables, और Claude/MCP config files तक फैला हुआ है
  • चुराई गई जानकारी का इस्तेमाल सार्वजनिक GitHub repositories बनाने और commits करने, npm token के जरिए दोबारा वितरण फैलाने, और workflow injection के लिए किया जाता है; इसमें ~/.bashrc और ~/.zshrc में बदलाव जैसी persistence क्षमताएं भी शामिल हैं
  • Bitwarden CLI इस्तेमाल करने वाले संगठनों को इस घटना को credentials exposure और CI/CD compromise के रूप में लेना चाहिए, और CI logs की समीक्षा व संभावित रूप से उजागर हुए secrets को बदलना महत्वपूर्ण है

अवलोकन

  • Bitwarden CLI npm पैकेज को चल रहे Checkmarx सप्लाई चेन हमले के हिस्से के रूप में समझौता-ग्रस्त किया गया, और पुष्टि किया गया लक्षित संस्करण @bitwarden/cli2026.4.0 है
    • मैलिशियस कोड पैकेज में शामिल bw1.js में मौजूद था
    • हमले का रास्ता Bitwarden की CI/CD pipeline के भीतर समझौता-ग्रस्त GitHub Action के उपयोग के संकेतों से मेल खाता है, और अन्य repositories में देखे गए अभियान पैटर्न से भी समानता रखता है
  • अब तक पुष्टि की गई सीमा Bitwarden CLI बिल्ड तक सीमित है, और यह समझौता बड़े Checkmarx campaign में पहचाने गए GitHub Actions सप्लाई चेन vector का अनुसरण करता है
    • केवल npm के लिए CLI पैकेज प्रभावित है
    • Chrome extension, MCP server, और अन्य आधिकारिक distributions पर अभी तक प्रभाव की पुष्टि नहीं हुई है
  • जांच अभी जारी है, और पूर्ण तकनीकी विश्लेषण, प्रभावित versions, compromise indicators, और response guidance बाद में जारी किए जाएंगे
  • यदि आप Bitwarden CLI का उपयोग करते हैं, तो CI logs की समीक्षा और संभवतः उजागर हुए secrets को बदलना आवश्यक है

तकनीकी विश्लेषण

  • मैलिशियस payload bw1.js पिछले दिन विश्लेषित Checkmarx के mcpAddon.js के साथ मुख्य इन्फ्रास्ट्रक्चर साझा करता है
    • यह समान C2 endpoint audit.checkmarx[.]cx/v1/telemetry का उपयोग करता है, और __decodeScrambled तथा seed 0x3039 के साथ obfuscate किया गया है
    • यह GitHub API के जरिए commit-आधारित exfiltration और npm registry के जरिए token theft व redistribution भी करता है
  • एम्बेडेड payload संरचना भी उसी परिवार की है
    • gzip+base64 संरचना के भीतर GitHub Actions Runner.Worker memory को scrape कर GitHub tokens को निशाना बनाने वाली Python script शामिल है
    • redistributed npm packages के लिए setup.mjs loader, GitHub Actions workflow YAML, hardcoded RSA public key, और वैचारिक घोषणा-संबंधी strings भी शामिल हैं
  • credentials collection का दायरा बहुत व्यापक है
    • GitHub tokens को Runner.Worker memory scraping और environment variables से एकत्र किया जाता है
    • AWS credentials को ~/.aws/ files और environment variables से खोजा जाता है
    • Azure tokens को azd से, और GCP credentials को gcloud config config-helper के जरिए एकत्र किया जाता है
    • .npmrc, SSH keys, environment variables, और Claude/MCP config files भी लक्षित हैं
  • GitHub के जरिए exfiltration का तरीका भी स्पष्ट रूप से देखा गया है
    • पीड़ित खाते के अंतर्गत Dune-थीम naming rule {word}-{word}-{3digits} का पालन करने वाली public repositories बनाई जाती हैं
    • encrypted results को commit किया जाता है, और commit message में LongLiveTheResistanceAgainstMachines marker के साथ token डाला जाता है
  • इसमें सप्लाई चेन propagation mechanism भी शामिल है
    • चुराए गए npm tokens से write-access वाले packages खोजकर preinstall hook जोड़कर दोबारा प्रकाशित किया जाता है
    • GitHub Actions workflow inject कर repository secrets को अतिरिक्त रूप से एकत्र किया जाता है
  • रूसी locale kill switch मौजूद है
    • यदि system locale "ru" से शुरू होता है, तो यह चुपचाप समाप्त हो जाता है
    • यह Intl.DateTimeFormat().resolvedOptions().locale और LC_ALL, LC_MESSAGES, LANGUAGE, LANG environment variables की जांच करता है
  • runtime Bun v1.3.13 है और इसे GitHub Releases से डाउनलोड किया जाता है

Checkmarx घटना से अलग बिंदु

  • bw1.js में अतिरिक्त compromise indicators हैं जो Checkmarx incident दस्तावेज़ में नहीं थे
    • hardcoded lock file /tmp/tmp.987654321.lock के जरिए concurrent execution रोका जाता है
    • ~/.bashrc और ~/.zshrc में payload inject कर shell profile persistence हासिल की जाती है
    • repository description को Shai-Hulud: The Third Coming पर सेट करना और debug string में "Would be executing butlerian jihad!" शामिल करना जैसी स्पष्ट branding का उपयोग किया गया है
  • साझा tooling एक ही malware ecosystem से मजबूत जुड़ाव का संकेत देती है, लेकिन operational signatures attribution को और कठिन बनाते हैं
    • Checkmarx हमले के सामने आने के बाद TeamPCP ने @pcpcats social account के जरिए इसकी जिम्मेदारी लेने का दावा किया था
    • संबंधित मैलवेयर ने सामान्य दिखने वाले description से खुद को छिपाने की कोशिश की थी
  • इस payload का सार्वजनिक रवैया अलग है
    • Shai-Hulud repository names, "Butlerian Jihad" घोषणा, और machines के खिलाफ resistance का दावा करने वाले commit messages जैसे वैचारिक चिह्न सीधे मैलवेयर के भीतर शामिल हैं
    • साझा इन्फ्रास्ट्रक्चर का उपयोग करने वाले किसी दूसरे operator, अधिक वैचारिक उप-समूह, या अभियान के सार्वजनिक रवैये में बदलाव—इन सभी संभावनाओं को अभी नकारा नहीं जा सकता

सिफारिशें

  • जिन संगठनों ने मैलिशियस Bitwarden npm पैकेज इंस्टॉल किया है, उन्हें इस घटना को credentials exposure और CI/CD compromise घटना के रूप में मानना चाहिए
  • डेवलपर systems और build environments से प्रभावित पैकेज को तुरंत हटाएं, और उन environments में उजागर हुए हो सकने वाले सभी credentials बदलें
    • इसमें GitHub tokens, npm tokens, cloud credentials, SSH keys, और CI/CD secrets शामिल हैं
  • GitHub में unauthorized repository creation और असामान्य workflows की जांच करें
    • .github/workflows/ के अंतर्गत अप्रत्याशित files, संदिग्ध workflow runs, artifact downloads, और Dune-थीम name pattern {word}-{word}-{3digits} का पालन करने वाली public repositories की जांच करें
    • यदि प्रभाव की संभावना हो, तो नए प्रकाशित repositories में नीचे दिए गए keywords की जांच करें
      • atreides
      • cogitor
      • fedaykin
      • fremen
      • futar
      • gesserit
      • ghola
      • harkonnen
      • heighliner
      • kanly
      • kralizec
      • lasgun
      • laza
      • melange
      • mentat
      • navigator
      • ornithopter
      • phibian
      • powindah
      • prana
      • prescient
      • sandworm
      • sardaukar
      • sayyadina
      • sietch
      • siridar
      • slig
      • stillsuit
      • thumper
      • tleilaxu
  • npm में unauthorized publishing की audit करें
    • अनधिकृत publish, version changes, और नए जोड़े गए install hooks की जांच करें
  • cloud environments में access logs की दोबारा समीक्षा करें
    • असामान्य secret access, token use, और नए जारी किए गए credentials को ट्रैक करने की आवश्यकता है
  • endpoints और runners पर देखे गए exfiltration infrastructure तथा file access traces को खोजें
    • audit[.]checkmarx[.]cx के लिए outbound connections की जांच करें
    • यह देखें कि सामान्य रूप से उपयोग न होने वाले environments में Bun execution हुआ था या नहीं
    • .npmrc, .git-credentials, .env, cloud credential stores, gcloud, az, azd access traces की समीक्षा करें
    • /tmp/tmp.987654321.lock की मौजूदगी और ~/.bashrc, ~/.zshrc में संशोधन भी जांचें
  • GitHub Actions में unauthorized workflow creation की समीक्षा करें
    • यह जांच जरूरी है कि क्या workflow किसी temporary branch में बनाया गया था
    • format-results.txt जैसे artifact बनाए गए या डाउनलोड किए गए थे या नहीं, यह भी देखें
  • लंबी अवधि में भविष्य के सप्लाई चेन incidents के blast radius को कम करना आवश्यक है
    • token permissions का दायरा घटाएं और जहां संभव हो short-lived credentials का उपयोग करें
    • package creation और publishing permissions सीमित करें और GitHub Actions permissions को सख्त करें
    • अनावश्यक artifact access बंद करें, और सामान्य release प्रक्रिया के बाहर बने public repositories या workflow changes की निगरानी करें

compromise indicators

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

1 टिप्पणियां

 
GN⁺ 7 일 전
Hacker News की राय

  • सोच रहा हूँ कि minimum release wait period रखने से बेहतर कोई बचाव है भी या नहीं
    अगर .npmrc में सिर्फ min-release-age=7 भी रखा होता, तो करीब 19 घंटे पहले अपलोड होकर बाद में malicious निकले @bitwarden/cli 2026.4.0 को पाने वाले 334 लोग शायद बच जाते
    यही बात axios, ua-parser-js, node-ipc जैसे मामलों पर भी काफ़ी फिट बैठती है, और event-stream जैसे लंबे समय तक छिपे रहने वाले मामलों को भले न रोके, लेकिन ज़्यादातर acute supply-chain attacks पर असरदार लगती है
    npm/pnpm/bun/uv में wait time जोड़ने के config examples हैं, और one-click से जांचकर लागू करने वाला कोई tool नहीं मिला, इसलिए मैंने खुद https://depsguard.com बनाया
    अभी-अभी इसी तरह के आइडिया वाला https://cooldowns.dev भी देखा

    • मैं Aikido safe-chain इस्तेमाल कर रहा हूँ
      यह सिर्फ minimum release wait period नहीं लगाता, बल्कि npm/uv आदि को wrap करने वाले wrapper की तरह install से पहले हर dependency को commercial vulnerability database से मिलाकर known issues या suspicious signals की जांच करता है
    • cooldown का आइडिया अच्छा है, लेकिन अगर किसी ने तुरंत update ही न किया होता, तो क्या यह attack पकड़ा भी जाता, इस पर भी सोचता हूँ
      असल दुनिया में कोई न कोई हमेशा तुरंत update करेगा, लेकिन ऐसे incidents सामने आने की प्रक्रिया खुद fast-update users पर कुछ हद तक निर्भर लगती है
    • बेहतर होगा कि शुरुआत ही backend या CLI tools को NPM पर न रखने से की जाए
    • नई install के लिए तो ठीक है, लेकिन existing dependencies के लिए patch version पर pin करके sha fix कर देना काफ़ी नहीं है क्या?
    • ऐसे attacks आम तौर पर upstream source तक नहीं पहुँचते, इसलिए https://www.chainguard.dev/libraries की तरह source से build करने पर लगभग 98% रोके जा सकते हैं
      अगर registry binaries को वैसे ही pull करना पड़े, तो cooldown से risk थोड़ा कम किया जा सकता है
      GitHub तक घुसपैठ वाले long-tail cases के लिए commit·maintainer heuristics और AI-based code change analysis चलाकर, anomaly दिखने पर human review की ज़रूरत लगती है
      संदर्भ के लिए, मैं यहीं काम करता हूँ

  • इस incident का मूल बिंदु यह है कि build pipeline compromise हो गई थी और उसी से दूषित package deploy हुआ
    फिर भी अगर आप काम के लिए अहम चीज़ npm पर चला रहे हैं, तो dependencies को pinning करना बेहतर है
    बहुत से developers मानते हैं कि lockfile काफ़ी है, लेकिन अगर ^ range बची हो, तो lockfile update के समय ऐसा नया version आ सकता है जिसे मैंने explicitly चुना ही नहीं
    अगर system से कंपनी के अस्तित्व पर असर पड़ सकता है, तो यह झंझट उठाना भी ठीक है

    • उल्टा सोचें तो, बाद के version में जब security vulnerability fix हो, तब system का उसे अपने-आप ले लेना भी आदर्श ही है

  • https://github.com/doy/rbw Bitwarden CLI का Rust alternative है
    Rust ecosystem भी धीरे-धीरे npm की तरह बड़े और गहरे dependency tree वाला लगने लगा है, लेकिन फिर भी JavaScript में आम तौर पर जितने authors पर भरोसा करना पड़ता है, उससे यह काफ़ी कम है

    • https://github.com/doy/rbw/blob/main/Cargo.toml#L16 देखें तो यहाँ भी dependencies काफ़ी ज़्यादा हैं
      फिर भी कम से कम versions pin किए हुए हैं
    • सोच रहा हूँ कि Firefox built-in password manager इस्तेमाल करने में कोई downside है क्या
    • लोग Rust को ज़्यादा सुरक्षित मानते हैं, लेकिन dependencies के ज़रिए malware खिंच आने का risk बहुत बढ़ गया है, इसे बहुत आसानी से नज़रअंदाज़ कर देते हैं
    • rbw + vaultwarden का combination self-hostable Rust version of Bitwarden की तरह काम करता है, इसलिए काफ़ी अच्छा है
    • ऐसी घटनाओं की वजह से शायद ज़्यादा software .Net जैसे stack की ओर जाएँ, जहाँ third-party dependencies के बिना भी ज़्यादातर काम हो जाता है
      या फिर भाषाओं की standard library में और ज़्यादा functionality जोड़ी जाए

  • Bitwarden CLI का अनुभव बहुत खराब रहा
    मैंने bw list चलाया और सोचा था कि सिर्फ password names दिखेंगे, लेकिन असल में passwords और current TOTP codes तक सब दिखा दिए
    और भी डरावनी बात यह थी कि server पर ssh करके tmux के अंदर weechat खोला, तो bw command का पूरा content weechat input history में accessible था
    क्यों हुआ, इसका मुझे बिल्कुल पता नहीं, और यह tmux और weechat sessions के पार भी बना रहा; server reboot करने पर ही गया
    उसके बाद मैंने bw CLI तुरंत हटा दिया और दोबारा install करने का कोई इरादा नहीं
    संदर्भ के लिए, terminal के तौर पर ghostty इस्तेमाल करता हूँ

    • यह असल विषय से असंबंधित शिकायत के करीब है
    • CLI आज़माने वाला था, लेकिन देखा कि यह JavaScript-based है, तो वहीं छोड़ दिया
    • यह वाकई अजीब है
      सोच रहा हूँ कि क्या weechat में कोई bwcli extension है; और मुझे तो अभी इस incident से ही पता चला कि Bitwarden का CLI भी है
      मैं local में keepass इस्तेमाल करता हूँ

  • CLI नहीं इस्तेमाल किया, लेकिन browser plugin इस्तेमाल करता हूँ
    अगर यह compromise हो जाए तो बहुत बड़ी मुसीबत होगी, लेकिन इसे रोकने के लिए क्या करना चाहिए समझ नहीं आता
    सोच रहा हूँ कि क्या verified पुराना version चलाते रहना ही जवाब है
    यह बात फिर अजीब लगती है कि मेरी ज़िंदगी का बड़ा हिस्सा इस पर निर्भर है कि ये secrets, secrets ही बने रहें

    • जितने ज़्यादा integration points होंगे, attack surface उतना बढ़ेगा
      इसलिए मैं password manager browser extensions बिल्कुल नहीं इस्तेमाल करता
      पहले browser integration में security problems वाला product देखने के बाद से मैं इन्हें पूरी तरह avoid करता हूँ; iOS integration पर अपेक्षाकृत ज़्यादा भरोसा है, फिर भी सावधान रहता हूँ
    • मेरा मानना है कि cooldown default के रूप में हर जगह होना चाहिए
      developer package managers, OS package managers, browser extensions, यहाँ तक कि standalone apps के auto-updates तक सबमें
      Socket जैसी कंपनियों को malicious updates पकड़ने का समय मिलना चाहिए; अगर सब लोग publish के कुछ ही मिनटों में download कर लें, तो ऐसी detection का मतलब ही नहीं बचेगा
    • मेरी digital संपत्तियों में सबसे अहम email और Bitwarden account हमेशा शरीर पर रहने वाली एक Yubikey और दूसरे स्थान पर रखी backup key से सुरक्षित हैं
      मैं इस setup की ज़ोरदार सिफारिश करता हूँ
      शीर्षक देखकर थोड़ा घबरा गया था, लेकिन paranoia की हद तक जाए बिना भी जो कुछ तर्कसंगत रूप से किया जा सकता है, वह मैं कर रहा हूँ, ऐसा लगता है
    • browser plugin की जगह desktop app या web vault सीधे इस्तेमाल किया जा सकता है
    • इसे रोकने के तरीके संक्षेप में ये दो हैं
      https://cooldowns.dev
      https://depsguard.com
      दूसरा वाला मैं maintain करता हूँ, और अगर पहले वाले के बारे में पहले पता होता तो शायद इसे बनाता ही नहीं
      दोनों लगभग एक जैसा काम करते हैं, बस मेरा वाला Rust में है इसलिए थोड़ा overkill है

  • यहाँ सबसे अहम बात यह है कि सिर्फ npm install ही काफ़ी था
    अगर compromise point preinstall हो, तो install के बाद inspect करने की पारंपरिक सोच तुरंत ढह जाती है
    क्योंकि तब तक payload को execute होने का मौका मिल चुका होता है
    यह बात agents, CI, ephemeral sandbox environments में और दिलचस्प हो जाती है; exposure time छोटा हो तब भी, अगर installs अपने-आप बार-बार होते रहें, तो compromise होना आसान है
    एक और ध्यान देने वाली बात यह है कि यह payload सिर्फ secrets पर नहीं, बल्कि AI tooling settings पर भी निशाना साध रहा था
    shell profile tampering ऐसा रास्ता बन सकती है जिससे अगला coding assistant पढ़ने वाला context दूषित हो जाए
    इस नज़रिये पर AgentSH के काम के साथ https://www.canyonroad.ai/blog/the-install-was-the-attack/ में ज़्यादा विस्तार से लिखा है

    • install के बाद package inspect करने वाले लोग लगभग होते ही नहीं, और npm install scripts को अलग से समस्या कहना बार-बार खंडित किया जा चुका दावा लगता है
      आखिरकार आप real binary तो चलाने वाले ही हैं
      और सख्ती से देखें तो install से पहले package को manually download करके inspect भी किया जा सकता है; अगर install program के behavior और scope की गहरी समझ नहीं है, तो malicious code को download और unpack करने की प्रक्रिया पर यूँ ही भरोसा करना और भी अजीब है

  • Russian locale kill switch — यह एक साथ साहसी भी लगता है और डरपोक भी

    • इससे भी बुरा यह है कि पता ही नहीं चलता कि यह सचमुच सुराग है या false flag
    • Discretion is the better part of valor जैसी हर तरह की कहावत याद आ जाती है
      कुल मिलाकर यह अपने ही पैर पर कुल्हाड़ी न मारने वाला रवैया लगता है
    • यह अपने-आप में निर्णायक सबूत नहीं है
      Vault7 leak में भी यह था कि NSA और CIA source छिपाने के लिए ऐसे traces जानबूझकर छोड़ते हैं, और दूसरे state actors भी यह technique आसानी से इस्तेमाल कर सकते हैं
    • यह किसी दूसरे देश की धमकी भरी चाल जैसा भी लग सकता है
    • npm publish GitHub CI job में कोई locale ऐसा set करेगा, यह मानना मुश्किल है
      बहुत खुला हुआ misdirection trace लगता है, लेकिन साथ ही यह धारणा भी मज़बूत करता है कि कोई state actor शामिल था

  • KeePass user बनकर रहो तो ऐसा stress काफ़ी कम हो जाता है
    पिछले 5 सालों में भी local infra पर KeePass इस्तेमाल करके मैंने कई security incidents से बचाव किया है

    • इस बार दिक्कत vault खुद नहीं, बल्कि access tool में थी
      ऐसा नहीं कि KeePass access tool में यह असंभव हो, तो फर्क आखिर क्या है, यह साफ़ नहीं है
    • passwords को infra और phone दोनों से access करना है; KeePass में यह कैसे करते हैं, जानना चाहता हूँ
      अब तक मानता रहा कि यह संभव नहीं होगा, लेकिन सच कहूँ तो मैंने गहराई से देखा नहीं
    • जो लोग अपना infra चला सकते हैं, उनके लिए ठीक होगा, लेकिन stress free कहना औसत user पर लागू करना मुश्किल है
    • single-file approach समझ में आती है, लेकिन व्यवहार में sync और conflict resolution कैसे होता है, यह जानना चाहता हूँ
      अगर दो devices offline रहते हुए अलग-अलग password जोड़ें और बाद में फिर online हों, तो क्या होता है?
    • KeePass में जो बात अब तक समझ नहीं आई, वह cloud backup है
      backup encrypt करते हैं तो उसका password कहाँ रखें, और cloud provider का password कहाँ रखें?

  • इस attack में खास तौर पर प्रभावशाली बात यह है कि attackers को GitHub down न होने वाले timing से बिल्कुल मेल बैठाना पड़ा

  • इसलिए मैं third-party password managers इस्तेमाल ही नहीं करता
    क्योंकि आपको लगातार भरोसा करना पड़ता है कि वे security, updates, backups जैसी चीज़ें सही से संभालेंगे
    मैंने खुद एक stateless password generator बनाया है, इसलिए devices के बीच data backup या sync की ज़रूरत ही नहीं पड़ती
    इसमें बहुत लंबा और मजबूत master password, service name और username देकर उपयुक्त parameters के साथ scrypt hash चलाया जाता है, जिससे brute force व्यावहारिक रूप से असंभव हो जाता है
    अहम accounts पर 2FA भी साथ में इस्तेमाल करता हूँ