Bitwarden Heist – बिना पासवर्ड उपयोग किए पासवर्ड वॉल्ट्स में कैसे घुसें
Security researchers ने Bitwarden के Windows client में एक अब ठीक की जा चुकी खामी का वर्णन किया, जिससे user के रूप में चल रहा कोई भी process बिना password या biometrics के DPAPI के जरिए biometrically unlocked vault को decrypt करने वाली key निकाल सकता था। टिप्पणीकारों का कहना है कि इस हमले के लिए local access चाहिए थी और यह compromised Active Directory environments में सबसे प्रभावी था, लेकिन इसे Windows की app isolation, legacy protocols, और `%AppData%` जैसी filesystem conventions की व्यापक कमजोरियों को उजागर करने के लिए भी इस्तेमाल किया गया। यह thread password managers के वास्तविक जोखिमों और फायदों पर बहस में भी बदल जाता है, क्योंकि वे “single point of failure” हैं, जबकि password reuse की समस्या बहुत व्यापक है।
Bitwarden समस्या का दायरा
- यह कमज़ोरी केवल Windows पर थी, और Bitwarden के Windows पर biometric unlock से जुड़ी थी।
- मूल खामी: same low-privileged user के रूप में चल रहा कोई भी process एक JSON फ़ाइल पढ़ सकता था और vault को decrypt करने के लिए DPAPI से “biometric key” मांग सकता था, बिना Windows Hello prompt, बिना अतिरिक्त privileges के।
- कुछ pentest scenarios में, domain admin access का उपयोग Active Directory से DPAPI backup keys निकालने और vaults को offline decrypt करने के लिए किया गया; दूसरे मामलों में, केवल local user access की ज़रूरत थी।
- बताया गया कि Bitwarden ने v2023.4.0 में design ठीक किया और defaults बदल दिए ताकि Windows Hello का उपयोग करते समय startup पर कम-से-कम एक बार master password दर्ज करना पड़े।
बहस: गंभीर कमज़ोरी या ज़्यादा बढ़ा-चढ़ाकर?
- कुछ लोग इस blog और title को clickbait मानते हैं, और कहते हैं कि:
- इसके लिए local access चाहिए (और कभी-कभी domain compromise भी), जो अक्सर वैसे भी “game over” होता है।
- हमला विशेषीकृत है और पहले ही patch किया जा चुका है।
- दूसरे तर्क देते हैं कि यह फिर भी ध्यान देने लायक है क्योंकि:
- यह ज़्यादा शोर करने वाली तकनीकों (keyloggers, memory dumping) से बचता है और कुछ endpoint defenses को bypass कर सकता है।
- Local access compromised coworkers या untrusted software से भी आ सकती है, सिर्फ़ स्पष्ट “physical attack” से नहीं।
Biometrics, DPAPI, और Platform Differences
- आलोचना: Bitwarden ने शुरू में Windows Hello का उपयोग सिर्फ़ यह पुष्टि करने के लिए किया कि “user is present,” फिर एक symmetric vault key को DPAPI में store किया, जिसे कोई भी same-user process (या AD backup keys के ज़रिए domain admin) निकाल सकता था।
- सुझाया गया सही pattern: Windows Hello को एक asymmetric key रखनी चाहिए; उसकी private key (जो biometrics से guarded हो) vault key को encrypt करे, फिर उसे DPAPI में रखा जाए।
- Android/iOS को app sandboxing और keychain models की वजह से secure करना आसान माना गया; thread में वहाँ ऐसी किसी similar समस्या की जानकारी नहीं है।
- macOS/App Store version में biometrics और Keychain के व्यवहार का ज़िक्र है, लेकिन विवरण अभी भी स्पष्ट नहीं हैं।
Windows AppData, Sandboxing, और Security Model
- %AppData% और सामान्य “user के रूप में चलने वाला कोई भी process user के किसी भी app data को पढ़ सकता है” मॉडल की कड़ी आलोचना हुई।
- दूसरे जवाब देते हैं कि यह design by design है: AppData कभी secure store के लिए नहीं था; अगर आप user के रूप में code चला सकते हैं, तो आप उनके secrets निकाल सकते हैं।
- Windows बनाम mobile OSes में strong default app isolation की कमी पर व्यापक चर्चा हुई।
- UWP, AppContainer, MSIX, और आने वाली filesystem-based isolation जैसी कोशिशों का भी ज़िक्र हुआ, जिन्हें backward compatibility और developer resistance ने बाधित किया।
Password Managers एक Single Point of Failure के रूप में
- कुछ लोग password vaults पर भरोसा नहीं करते, क्योंकि उनमें “all your secrets” का obvious SPOF होता है।
- बहुत से लोग जवाब देते हैं कि:
- इनके बिना users कमज़ोर passwords दोहराते हैं, जो व्यवहार में और भी बुरा है।
- एक vault के साथ strong master password और 2FA/MFA अच्छा समझौता है।
- पहले से unlocked vault का compromise बुरा है, लेकिन local malware अक्सर active sessions चुरा सकता है या keystrokes keylog कर सकता है।
- चर्चा किए गए mitigations:
- कुछ महत्वपूर्ण passwords याद रखना और vault से बाहर रखना।
- hardware tokens (जैसे security keys) और अलग 2FA storage का उपयोग करना।