मालवेयर Google OAuth endpoint का दुरुपयोग करके cookies को 'revive' करता है, खातों पर कब्ज़ा करता है
मालवेयर लेखक कथित तौर पर एक undocumented Google OAuth feature का उपयोग करके expired authentication cookies को “revive” कर रहे हैं, जिससे user द्वारा password बदलने के बाद भी persistent account hijacking संभव हो जाती है। टिप्पणीकारों का तर्क है कि यह Google द्वारा long-lived sessions और token revocation को संभालने के तरीके में एक गहरी समस्या को उजागर करता है, जिससे उपयोगकर्ताओं की अपेक्षा (“password बदलो तो attacker बाहर”) और वास्तविक security behavior के बीच अंतर बनता है। यह चर्चा Gmail, Workspace, और cloud services के लिए Google accounts पर अत्यधिक निर्भरता को लेकर व्यापक असुविधा को भी उजागर करती है, क्योंकि recovery प्रक्रियाएँ कठिन हैं, account lockouts होते हैं, और session lifetimes पर user control सीमित है.
मुख्य मुद्दा: OAuth के जरिए “zombie” Google sessions
- मालवेयर कथित तौर पर एक undocumented Google OAuth2 endpoint / Chrome extension behavior का उपयोग करके expired Google auth cookies को “revive” कर सकता है और खातों पर कब्ज़ा कर सकता है।
- मुख्य चिंता: password बदलने के बाद भी session cookies valid रहती हैं, जिससे compromise के बाद सामान्य “change your password” सलाह कमजोर पड़ जाती है।
- कुछ लोगों का कहना है कि हमलावर को फिर भी local cookies चुरानी पड़ती हैं (जैसे Chrome/Windows पर malware के जरिए; संभवतः Mac/Android पर भी)।
Password change, session invalidation, और “security theater”
- कई टिप्पणीकारों का तर्क है कि अगर password rotation sessions को invalidate नहीं करती, तो यह एक मौलिक security failure है, और वे इसे unrevoked TLS cert/private-key reuse से जोड़ते हैं।
- दूसरों का कहना है कि जटिल SSO/OAuth systems में सभी sessions समाप्त करना कठिन है; कई services across bearer tokens revoke करना एक “eventually consistent” / open-loop समस्या है।
- सुझाई गई best practice: कम से कम password change के दौरान उपयोगकर्ताओं से पूछें कि क्या सभी अन्य devices को log out करना है।
Non-expiring sessions: सुविधा बनाम जोखिम
- कुछ उपयोगकर्ता लंबे समय तक चलने वाली या non-expiring sessions को पसंद करते हैं और browser cookie stores को पर्याप्त रूप से सुरक्षित मानते हैं; उनका तर्क है कि अगर cookies चोरी हो जाती हैं, तो lifetime का बहुत कम फर्क पड़ता है।
- अन्य लोग जवाब देते हैं कि:
- server-side sessions को client cookies से अधिक समय तक नहीं चलना चाहिए।
- password changes, logouts, और account deactivation को पुराने sessions को भरोसेमंद तरीके से खत्म करना चाहिए।
- लंबे समय तक चलने वाली sessions विशेष रूप से high-value targets के लिए खतरनाक हैं (banks, cloud consoles, ex-employees)।
Google account lockouts, recovery, और trust
- कई anecdotes बताते हैं कि password, recovery email/phone, codes, या active sessions होने के बावजूद access वापस पाना मुश्किल होता है; प्रक्रियाओं को opaque और बदलती हुई बताया गया है।
- कुछ लोगों का कहना है कि backup codes और Advanced Protection / paid Workspace accounts अधिक reliably काम करते हैं; अन्य लोग रिपोर्ट करते हैं कि paid accounts भी “can’t verify it’s you” बाधाओं में फँस सकते हैं।
- उपयोगकर्ता रणनीतियाँ बताते हैं: पुराने logged-in devices को संभाल कर रखना, backup codes प्रिंट करना, अपने domains का उपयोग करना, providers को diversify करना, या पूरी तरह Google से हट जाना।
Controls और options
- वर्तमान behavior को लेकर असहमति है: कुछ का दावा है कि Google password बदलने से सभी logins sign out हो जाते हैं; अन्य कहते हैं कि old sessions security portal के जरिए manually revoke किए बिना बने रहते हैं।
- Workspace admins session-length policies enforce कर सकते हैं; नियमित Gmail users के पास कथित रूप से ऐसा कोई configurable control नहीं है।
संदेह और missing details
- कुछ लोग शुरुआती रिपोर्टिंग में technical detail की कमी के कारण exploit की गंभीरता पर संदेह करते हैं, जबकि अन्य अधिक विस्तृत write-ups और non-expiring Google sessions से जुड़े पहले के bug reports का हवाला देते हैं।
- एक टिप्पणीकार का सुझाव है कि Google sessions को tracking के लिए जानबूझकर बनाए रख सकता है; अन्य इसे अनावश्यक बताते हैं और सबूत मांगते हैं।