Palo Alto Networks की Unit 42 के सुरक्षा शोधकर्ताओं ने हमले की तीन नई तकनीकों का पता लगाया है, जिनकी मदद से मैलवेयर Google Password Manager में संग्रहीत passkeys से सुरक्षित खातों का नियंत्रण हासिल कर सकता है—और इसके लिए fingerprint, facial recognition या PIN prompts ट्रिगर होने की आवश्यकता नहीं होती। ये निष्कर्ष device enrollment, cloud synchronisation और synced passkeys को encrypt करने वाले master secret को Google द्वारा संभालने जैसे प्रमुख क्षेत्रों की कमजोरियों को उजागर करते हैं।
—
## Passkeys कैसे काम करने चाहिए
Passkeys पारंपरिक passwords की जगह asymmetric cryptography का इस्तेमाल करते हैं: public key सेवा के पास रहती है, जबकि private key—जो कभी साझा नहीं की जाती—यूज़र के authenticator द्वारा सुरक्षित रखी जाती है। लॉगिन के दौरान one-time challenge पर उसी private key से हस्ताक्षर किए जाते हैं। इस डिजाइन के कारण phishing attacks या सेवाओं के databases से credential theft काफी कम प्रभावी हो जाते हैं।
Passkeys को अलग-अलग devices पर sync करने से सुविधा बढ़ती है, लेकिन इसके लिए अतिरिक्त infrastructure की भी आवश्यकता होती है: encryption, cloud-based key recovery और enrollment processes। जहां core WebAuthn और FIDO protocols private keys को सुरक्षित रखते हैं, वहीं Unit 42 का शोध दिखाता है कि Google के implementation में इसके आसपास मौजूद mechanisms कमजोर हैं।
—
## Exploit Techniques: Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key
इन तीनों attacks के लिए आवश्यक है कि malware पहले से किसी compromised Windows device पर चल रहा हो। इसके बाद ये techniques जोखिम को काफी बढ़ा देती हैं:
### Pass-ta-key
– यह device identity key का इस्तेमाल करता है—यह Chrome द्वारा managed और TPM में sealed hardware-backed key होती है—ताकि user verification के बिना login challenges पर हस्ताक्षर किए जा सकें।
– जब compromised device से हस्ताक्षर किए जाते हैं, तो fingerprint, PIN या biometric check देना आवश्यक नहीं होता।
– Web server को server side पर user verification (UV bit) लागू करना चाहिए। कुछ sites, जैसे GitHub, ने इस तरह के attack को अस्वीकार कर दिया; वहीं अन्य sites, जैसे eBay (testing के समय), ने login attempts स्वीकार कर लिए क्योंकि उन्होंने UV flag की सही तरह जांच नहीं की।
### Silver Pass-ta-key
– यह Chrome की deferred enrolment state को target करता है, जो तब होती है जब किसी नए device को register कर लिया गया हो, लेकिन user-verification key (जैसे Windows Hello या PIN) अभी पूरी तरह बनाई न गई हो।
– Malware इस enrolment state में हेरफेर करके अपनी ऐसी verification key उपलब्ध कराता है, जिस पर उसका नियंत्रण होता है। Cloud authenticator द्वारा इस proxy key को स्वीकार किए जाने के बाद attacker UV flag वाले assertions generate कर सकता है।
– इससे उस site को bypass करना संभव हो जाता है, जो उचित user verification की मांग करती है। Enrolment के बाद attacker को victim के device तक पहुंच की आवश्यकता शायद न रहे।
### Golden Pass-ta-key
– यह सबसे गंभीर technique है: यह system के Security Domain Secret (SDS) को target करती है। SDS एक 32-byte master key है, जो सभी synchronized passkey private keys को encrypt करती है।
– शोधकर्ताओं ने पाया कि enrolment के दौरान Chrome के FIDO diagnostic logs के जरिए SDS plaintext में exposed थी। हालांकि Google ने उस specific logging को हटा दिया है, फिर भी device recovery या re-enrolment के दौरान SDS कुछ समय के लिए Chrome की process memory में दिखाई देती है।
– Malware enrolment workflows को force कर सकता है, memory से SDS capture कर सकता है, उसे encrypted key database के साथ combine कर सकता है, private key material निकाल सकता है और attacker के infrastructure पर authenticate कर सकता है—infected device को साफ किए जाने के बाद भी।
—
## Chrome और Google Password Manager में उन्हें क्या मिला
– TPM support वाले Windows computers पर Chrome device को Google के “cloud authenticator” के साथ enrol करता है। इस प्रक्रिया में एक device identity key और Windows Hello या PIN से जुड़ी user-verification key generate होती है।
– `passkey_enclave_state` नाम की enrolment file स्थानीय रूप से stored होती है और इसमें wrapped device identity keys, user-verification key का public portion, wrapped SDS और PIN recovery के लिए इस्तेमाल होने वाला data शामिल होता है।
– Synced WebAuthn credentials से जुड़ा metadata—usernames, relying-party (site) IDs, credential IDs और encrypted key data—Chrome के profile के अंतर्गत LevelDB database में stored रहता है। यूज़र के account के तहत पहले से चल रहा malware administrator privileges के बिना metadata तक पहुंच बना सकता है।
—
## Practical Implications & Limitations
– **Pre-condition**: ये post-compromise attacks हैं। Target की user session में malware पहले से execute हो रहा होना चाहिए, जो phishing, software vulnerabilities या supply-chain attacks के जरिए संभव हो सकता है।
– **No confirmed real-world exploitation yet**: Unit 42 को इन techniques के वास्तविक दुनिया में इस्तेमाल किए जाने का कोई evidence नहीं मिला। Report के साथ कोई CVE identifiers disclose नहीं किए गए और प्रभावित Chrome releases की पूरी सूची भी catalogued नहीं की गई।
– **Sites’ Mitigation Role**: Relying parties को केवल `userVerification: “required”` का अनुरोध करने से आगे भी कदम उठाने होंगे—उन्हें authenticator के returned data में UV bit को भी validate करना होगा। जो sites यह जांच नहीं करतीं, वे Silver Pass-ta-key जैसे attacks के प्रति vulnerable रहती हैं।
—
## What Can Be Done
### Website Operators के लिए
– सख्त server-side checks लागू करें: केवल उन्हीं WebAuthn assertions को स्वीकार करें, जिनमें UV flag स्पष्ट रूप से set हो।
– Identity और user-verification keys के registration या replacement के दौरान attestation या इसी तरह के cryptographic proof की आवश्यकता रखें।
– Enrollment और recovery workflows को डिफॉल्ट रूप से sensitive मानें। अतिरिक्त verification steps लागू करें या changes की पुष्टि के लिए trusted existing devices की आवश्यकता रखें।
### Endpoint Security / Users के लिए
– `passkey_enclave_state` file में होने वाले बदलावों, Chrome के sync database तक संदिग्ध access या TPM-backed cryptographic functions के असामान्य इस्तेमाल पर नजर रखें।
– Critical accounts—जैसे finance, developers और administrators—के लिए hardware-bound passkeys (जैसे अलग FIDO2 security keys) इस्तेमाल करने पर विचार करें।
– यदि compromise का संदेह हो: systems को known-clean images से rebuild करें, Google-account device list की समीक्षा करें और critical services से passkeys revoke करें। नई credentials बनाने के लिए secure systems का इस्तेमाल करें।
—
## Key Take-aways: Passkeys खराब नहीं हैं—लेकिन Implementation मायने रखता है
Passkeys अब भी कई पारंपरिक खतरों के खिलाफ मजबूत सुरक्षा प्रदान करते हैं: phishing, credential reuse या बड़े पैमाने पर होने वाले data breaches। उनका cryptographic foundation—local private keys और device intent के जरिए verification—अब भी मजबूत है।
हालांकि, इससे जुड़े infrastructure—keys को कैसे sync किया जाता है, enrollment कैसे manage किया जाता है और master secrets को कैसे संभाला जाता है—जोखिम के नए vectors पैदा करते हैं। ये research findings दिखाती हैं कि “passwordless” होने का अर्थ अपने-आप impermeable होना नहीं है।
This article is AI-generated content. Please verify the information independently before taking any action based on this article.
