Ledger के NPM खाते को हैक कर लिया गया है
Ledger की JavaScript “Connect Kit” library on npm, एक पूर्व कर्मचारी के npm खाते की फ़िशिंग के बाद, समझौता कर ली गई, जिससे दुर्भावनापूर्ण संस्करण प्रकाशित हुए और injected wallet-draining code के माध्यम से अनुमानित $600,000 निकालने में उपयोग किए गए। टिप्पणीकार Ledger की बार-बार होने वाली सुरक्षा विफलताओं, CDNs और automated publishing पर निर्भरता जो मजबूत 2FA को bypass करती है, और JavaScript supply chain की व्यापक नाज़ुकता की आलोचना करते हैं; साथ ही LavaMoat, Socket, और Phylum जैसे tools, तथा मजबूत signing और hardware practices, को आंशिक mitigations के रूप में देखते हैं। यह घटना hardware wallets के मूल्य पर बहस को भी फिर से जीवित करती है, जब उपयोगकर्ता नियमित रूप से जटिल transactions पर blind-signing करते हैं और फिर भी crypto के आसपास बड़े centralized ecosystems पर भरोसा करना पड़ता है.
घटना का अवलोकन
- Ledger का NPM खाता
@ledgerhq/connect-kitके लिए, एक पूर्व कर्मचारी के NPM क्रेडेंशियल्स की फ़िशिंग के माध्यम से, समझौता किया गया था। - दुर्भावनापूर्ण संस्करण 1.1.5–1.1.7 प्रकाशित किए गए; उन्होंने एक “drainer” इंजेक्ट किया जिसने एक दुष्ट WalletConnect प्रोजेक्ट के माध्यम से धन को पुनर्निर्देशित किया।
- Ledger का कहना है कि दुर्भावनापूर्ण फ़ाइल लगभग 5 घंटे तक लाइव रही, और 2 घंटे से कम समय तक सक्रिय draining हुआ, जिससे लगभग $600k प्रभावित हुआ।
- संस्करण 1.1.8 को एक स्वच्छ प्रतिस्थापन के रूप में पुश किया गया; NPM अनुमतियों को लॉक डाउन किया गया और publishing secrets को रोटेट किया गया।
- हमले ने उन dApps को निशाना बनाया जो किट को CDN के माध्यम से डायनामिक रूप से लोड करते थे; कई downstream प्रोजेक्ट्स पर अप्रत्यक्ष रूप से असर पड़ा।
Ledger की सुरक्षा प्रतिष्ठा और hardware wallet मॉडल
- कई टिप्पणीकारों का कहना है कि Ledger के साथ “बहुत अधिक” घटनाएँ हुई हैं (data breach, key-export जैसी विवादास्पद सुविधाएँ, phishing ecosystem), और वे Coldcard, Trezor, SeedSigner आदि विकल्पों की ओर चले गए हैं।
- अन्य लोगों का तर्क है कि मूल सुरक्षा मॉडल फिर भी कायम रहा: उपकरणों पर private keys बाहर नहीं निकाली गईं; उपयोगकर्ताओं को draining transactions पर हस्ताक्षर करने के लिए धोखा दिया गया।
- ज़िम्मेदारी पर बहस: कुछ लोग Ledger की प्रक्रिया और supply-chain विकल्पों को दोष देते हैं; अन्य लोग users को blind-signing करने और seed backups बनाए न रखने के लिए दोषी ठहराते हैं।
Blind signing और UX विफलताएँ
- Ethereum transactions अक्सर जटिल और छोटे hardware screens पर human-readable नहीं होतीं, जिससे blind signing व्यवहार में मानक बन गया है।
- कुछ लोगों का कहना है कि जब तक transactions को device पर लगातार स्पष्ट text में render नहीं किया जाता, hardware wallets “security theater” हैं।
- अन्य ecosystems (जैसे Cosmos) को human-readable signing के लिए बेहतर बताया जाता है।
NPM, CI, और supply-chain सुरक्षा
- चर्चा में कहा गया कि NPM 2FA को “force” करता है या “optionally enforce” करता है, लेकिन automation tokens और CI pipelines interactive 2FA को bypass कर सकते हैं।
- चिंता यह है कि एक high-value package phishable auth, ex-employee access, और GitHub Actions से automated publishing पर निर्भर था।
- NPM की ज़िम्मेदारी पर बहस: कुछ लोग NPM को negligent मानते हैं (weak signing, past integrity regressions); अन्य कहते हैं कि maintainers को security सही ढंग से configure करनी चाहिए।
- लंबे समय से चल रही बहस: पारंपरिक PGP-style maintainer signing बनाम नए centralized provenance systems; कुछ लोग decentralised PGP-style keys को दृढ़ता से पसंद करते हैं।
Detection tools और mitigations
- कई security tools का उल्लेख किया गया है (LavaMoat, Packj, Socket, Phylum, sandboxed installers) जिनका उद्देश्य malicious dependencies या obfuscation का पता लगाना है।
- बताया गया कि कुछ tools ने इस package को flag किया; अन्य gaps स्वीकार करते हैं, खासकर जब payloads CDNs से fetch किए जाते हैं।
Centralization बनाम crypto ideals
- Tether द्वारा attacker के USDT को freeze करना उपयोगी माना गया है (नुकसान कम करने के लिए) और साथ ही मूल decentralization ethos के विपरीत भी।
- टिप्पणियाँ इस बात पर ज़ोर देती हैं कि fiat-backed stablecoins (USDT, USDC) centrally controlled और programmable हैं (blacklists, freezes), base assets जैसे BTC/ETH के विपरीत।