Google टू-फैक्टर ऑथेंटिकेशन बायपास

एक हमलावर Google सेवाओं पर दो-कारक प्रमाणीकरण (2FA) को बायपास कर सकता है, उपयोगकर्ता पासवर्ड रीसेट कर सकता है और केवल तथाकथित प्राप्त करके खाते पर पूर्ण नियंत्रण प्राप्त कर सकता है। एप्लिकेशन पासवर्ड - ASP (एप्लिकेशन-विशिष्ट पासवर्ड)।


(Google के विज्ञापन अभियान के सभी उचित सम्मान के साथ, "अच्छा पता है" )

Google ऐप पासवर्ड का दुरुपयोग

2FA Google विभिन्न समस्याओं के अध्ययन के लिए सामग्री प्रदान करता है जो निश्चित रूप से इतने बड़े पैमाने पर विश्वसनीय प्रमाणीकरण प्रणाली में उत्पन्न होती हैं।
सभी उपयोगकर्ताओं के लिए इस तरह के प्रमाणीकरण को संभव बनाना (और इसे मौजूदा पारिस्थितिकी तंत्र में मूल रूप से एकीकृत करना), Google इंजीनियरों को कुछ समझौता करना पड़ा। जैसे, उदाहरण के लिए, एप्लिकेशन पासवर्ड ।
कुछ महीने पहले, हमने Google खाते पर पूर्ण नियंत्रण पाने के लिए सॉफ़्टवेयर का उपयोग करने का एक तरीका पाया, पूरी तरह से 2FA को दरकिनार कर दिया। हमने अपने खोज के बारे में Google सुरक्षा को बताया और हाल ही में उनकी ओर से प्रतिक्रिया मिली कि उन्होंने हमारे द्वारा खोजे गए सबसे गंभीर खतरों को बेअसर करने के लिए कुछ कदम उठाए। और इसलिए, यहाँ है कि हम क्या पाया:

एप्लिकेशन पासवर्ड

जैसे ही आप 2FA सक्षम करते हैं, Google आपसे आपके द्वारा उपयोग किए जाने वाले प्रत्येक एप्लिकेशन के लिए एक अलग पासवर्ड बनाने के लिए कहेगा (इसलिए "एप्लिकेशन पासवर्ड" नाम), जो 2FA का समर्थन नहीं करता है। आप अपने प्राथमिक के बजाय इस पासवर्ड का उपयोग करें। अधिक विशेष रूप से, आप अधिकांश अनुप्रयोगों के लिए सॉफ़्टवेयर बनाते हैं जो वेब फ़ॉर्म से लॉगिन का उपयोग नहीं करते हैं: IMAP और SMTP (Apple मेल, थंडरबर्ड, आदि) का उपयोग कर ई-मेल क्लाइंट; XMPP चैट क्लाइंट (Adium, Pidgin, आदि), साथ ही विभिन्न कैलेंडर CalDAV (iCal, आदि) का उपयोग करके सिंक्रनाइज़ किए जाते हैं।
यहां तक ​​कि Google के कुछ सॉफ़्टवेयर आपको सॉफ़्टवेयर का उपयोग करने के लिए मजबूर करते हैं - उदाहरण के लिए, Chrome में सिंक्रनाइज़ेशन सक्षम करने या Android डिवाइस पर अपना खाता सेट करने के लिए। हाल ही में, अधिकांश ग्राहक OAuth के माध्यम से प्राधिकरण में बदल गए। इस मॉडल में, जब आप पहली बार अपने नए डिवाइस या एप्लिकेशन में लॉग इन करते हैं, तो आपको एक वेब फॉर्म में प्राधिकरण के लिए अनुरोध प्राप्त होता है जो 2FA का उपयोग करता है। सफल प्राधिकरण के बाद, सर्वर एक सीमित पहुंच टोकन लौटाता है, जो तब आपके डिवाइस / एप्लिकेशन को प्रमाणित करने के लिए उपयोग किया जाता है।
वास्तव में, OAuth टोकन और पीपी बहुत समान हैं - अंत में, यह सभी समाप्त होता है प्रत्येक डिवाइस / एप्लिकेशन के लिए एक अद्वितीय प्राधिकरण टोकन बनाना जो आप अपने Google खाते से संलग्न करते हैं। इसके अलावा, प्रत्येक व्यक्तिगत टोकन को रद्द किया जा सकता है, बाकी को पूर्वाग्रह के बिना: यदि आप अपना स्मार्टफोन खो देते हैं, तो आप यह सुनिश्चित कर सकते हैं कि कोई भी आपके पासवर्ड के बिना मेलबॉक्स तक नहीं पहुंच सकता है।
और इसलिए, OAuth टोकन और सॉफ़्टवेयर के बीच मुख्य अंतर निम्नानुसार हैं:

• OAuth टोकन स्वचालित रूप से बनाए जाते हैं, जबकि PPs को मैन्युअल रूप से बनाने की आवश्यकता होती है। इसे बनाने के लिए आपको Google खाता सेटिंग्स पर जाने की आवश्यकता है, और फिर इसे एप्लिकेशन पर कॉपी करें।
• OAuth टोकन एक अधिक लचीला प्राधिकरण मॉडल प्रदान करते हैं और इसका उपयोग केवल आपके खाते में कुछ डेटा या सेवाओं तक पहुंच को प्रतिबंधित करने के लिए किया जा सकता है। दूसरी ओर, एप्लिकेशन पासवर्ड, पूरी तरह से सटीक होने के लिए, केवल अनुप्रयोगों के लिए पूरी तरह से नहीं हैं!

आइए हम दूसरे बिंदु पर अधिक विस्तार से ध्यान दें। यदि आप XMPP चैट क्लाइंट के लिए एक सॉफ्टवेयर बनाते हैं, तो इसी पासवर्ड का उपयोग IMAP के माध्यम से मेल पढ़ने या CalDAV कैलेंडर से घटनाओं की सूची प्राप्त करने के लिए किया जा सकता है। जो वास्तव में ऐसा कोई आश्चर्य नहीं है। वास्तव में, Google के एरिक गोरस और मयंक उपाध्याय ने Google के 2FA पर अपने लेख में इस कमजोरी को पहले ही बताया है:

"सॉफ्टवेयर की एक और कमजोरी यह भ्रामक धारणा है कि वे किसी खाते तक पूर्ण पहुंच के बजाय एक विशिष्ट एप्लिकेशन तक पहुंच प्रदान करते हैं।"

IEEE एस एंड पी पत्रिका वॉल्यूम से स्केल पर प्रमाणीकरण । 11, नहीं। 1

यह पता चला है कि पीपी बहुत कुछ कर सकता है, आपके मेल तक पहुंच प्राप्त करने की तुलना में बहुत अधिक। वास्तव में, उन्हें 2FA को दरकिनार करके अधिकांश Google सेवाओं पर प्रमाणीकरण के लिए उपयोग किया जा सकता है!

क्रोम ऑटो-लॉगिन

Android और ChromeO के नवीनतम संस्करणों में, Google ने अपने ब्राउज़रों में Google खातों में एक ऑटो-लॉगिन तंत्र शामिल किया है। अपने डिवाइस को किसी खाते से जोड़ने के बाद, ब्राउज़र मौजूदा प्राधिकरण का उपयोग करेगा और वेब फॉर्म के माध्यम से अनुरोध करना बंद कर देगा। (क्रोम के डेस्कटॉप संस्करण में इस कार्यक्षमता के लिए प्रायोगिक समर्थन भी है, आप इसे "क्रोम: // झंडे / /" खोलकर सक्षम कर सकते हैं)।

कुछ समय पहले तक, यह तंत्र एक Google खाते के सबसे महत्वपूर्ण भाग के लिए भी काम करता था - सेटिंग्स पेज। इसमें एक पासवर्ड रिकवरी पेज शामिल है जहां आप ई-मेल पते और फोन नंबर जोड़ सकते हैं और जिस पर आपको पासवर्ड रीसेट करने के लिए आवश्यक जानकारी भेजी जाएगी। संक्षेप में, यदि आप इस पृष्ठ पर पहुँच सकते हैं, तो आप इसके वास्तविक स्वामी से एक खाते का चयन कर सकते हैं।

तकनीकी विवरण

अपने उत्कृष्ट ब्लॉग एंड्रॉइड एक्सप्लोरेशन में, निकोलाई एलेनकोव ने एंड्रॉइड में ऑटो-लॉगिन तंत्र का एक व्यापक अध्ययन प्रकाशित किया। यह एक शानदार शुरुआती बिंदु था, लेकिन इसमें वह सभी जानकारी नहीं थी जिसकी हमें ज़रूरत थी। हम यह जानना चाहते थे कि एंड्रॉइड डिवाइस या क्रोमबुक के बिना इस तंत्र का उपयोग कैसे किया जाए।
ऐसा करने के लिए, हमने एंड्रॉइड एमुलेटर और Google सर्वर के बीच यातायात की निगरानी के लिए एक अवरोधन प्रॉक्सी स्थापित किया है। Google खाता जोड़ते समय, हमने निम्नलिखित अनुरोध देखा:

पोस्ट / HTTP HTTP / 1.1
होस्ट: android.clients.google.com
...
खाता टाइप करें = HOSTED_OR_GOOGLE और ईमेल = उपयोगकर्ता% 40domain.com और has_permission = 1 और add_account = 1 और एन्क्रिप्ट किया गया Passwd = AFcb4 ... \
& सेवा = ac2dm और स्रोत = android और androidId = 3281f33679ccc6c6 और device_country = us & operCountry = us & lang = en & sdk_version = 17


अन्य बातों के अलावा, उत्तर में निम्नलिखित शामिल थे:

टोकन = 1 / f1Hu ...

इस तथ्य के बावजूद कि URL और कुछ मापदंडों को प्रलेखित नहीं किया गया है, यह Google ClientLogin API के समान है। इस तरह के अनुरोध को स्वयं को फिर से बनाने के लिए, हमें यह समझने की ज़रूरत है कि "एनक्रिप्टेडपास" और "एंड्रॉइड" मापदंडों में क्या मान पारित किए जाने चाहिए। दूसरे के साथ, सब कुछ सरल हो गया - यह एंड्रॉइड एपीआई डॉक्स में उल्लिखित "ANDROID_ID" पैरामीटर है - एक यादृच्छिक रूप से उत्पन्न 64-बिट मान जो किसी एंड्रॉइड डिवाइस की विशिष्ट पहचान करने का इरादा है।
एलेनकोव की एक अन्य पोस्ट ने हमें इस आशा के साथ प्रेरित किया कि "एनक्रिप्टेडपासस्वाड" हमारा सॉफ्टवेयर हो सकता है, जिसे एक सार्वजनिक 1024-बिट आरएसए कुंजी के साथ एन्क्रिप्ट किया गया है, जो एंड्रॉइड प्लेटफॉर्म में शामिल है। EncryptedPasswd 130 बाइट्स लंबा बाइनरी डेटा (बेस 64 एनकोडेड) था, इसलिए यह बहुत संभव है कि यह हो। हालांकि, आगे बढ़ने से पहले, हमने इस पैरामीटर को प्रलेखन से "पासवार्ड" पैरामीटर (एक एन्क्रिप्टेड पासवर्ड नहीं) के साथ बदलने का प्रयास करने का फैसला किया और इसके लिए मूल्य निर्धारित किया - हमारा सॉफ्टवेयर:

पोस्ट / HTTP HTTP / 1.1
होस्ट: android.clients.google.com
...
accountType = HOSTED_OR_GOOGLE और ईमेल = उपयोगकर्ता% 40domain.com और has_permission = 1 और add_account = 1 और Passwd = xxxxxxxxxxxxxxxx \
& सेवा = ac2dm और स्रोत = android और androidId = 3281f33679ccc6c6 और device_country = us & operCountry = us & lang = en & sdk_version = 17


और यह काम किया! हमें एक उत्तर मिला जिसमें एक मान्य टोकन के समान कुछ था। Android.clients.google.com सर्वर द्वारा बनाया गया यह टोकन, हमारे खाते के "कनेक्टेड साइट्स, ऐप्स और सेवाओं" अनुभाग में दिखाई देता है और हमें खाते में पूर्ण पहुंच प्रदान करता है:


ट्रैफ़िक की निगरानी करना जारी रखते हुए, हमने ब्राउज़र में ऑटो-लॉगिन से संबंधित 2 अलग-अलग प्रक्रियाओं पर ध्यान दिया। सबसे सरल एक अगला ग्राहक लॉगिन अनुरोध था, लेकिन हमारे टोकन का उपयोग किया:

पोस्ट / HTTP HTTP / 1.1
होस्ट: android.clients.google.com
...
खाता टाइप करें = HOSTED_OR_GOOGLE और ईमेल = उपयोगकर्ता% 40domain.com और has_permission = 1 & टोकन = 1% 2Ff1Hu ... & \ _
सेवा = weblogin% 3Acontinue% 3Dhttps% 253A% 252F% 252Facounts.google.com% 252FManageAccount \
& source = android & androidId = 3281f33679ccc6c6 & app = com.android.browser & client_sig = 61ed377e85d386a8dfee6b864b8585b0bfaa5af81 और \
device_country = us & operCountry = us & lang = en & sdk_version = 17


इस अनुरोध ने प्रतिक्रिया निकाय को लौटा दिया, साथ ही साथ निम्नलिखित पंक्ति:

Auth = https: //accounts.google.com/MergeSession; Args =% 3Dhttps% 253A% 252F% 252Facounts.google.com% 252FManageAccount और uberauth / AP ... & source = Android =ebLogin पर जारी रखें
अवसान = ०


इस अनुरोध से, हमने पाया कि "सेवा" पैरामीटर के लिए प्रारूप वेबलॉगिन है: जारी = url_encode (डेस्टिनेशन_रोड) । हमने टोकन के बजाय पीपी के साथ अपने प्रारंभिक अनुरोध के लिए इस पैरामीटर को निर्दिष्ट करने का प्रयास करने का फैसला किया (बजाय समझदार पैरामीटर "client_sig" की उत्पत्ति को समझने की कोशिश करने के लिए):

पोस्ट / HTTP HTTP / 1.1
होस्ट: android.clients.google.com
...
device_country = us & accountType = HOSTED_OR_GOOGLE & androidId = 3281f33679ccc6c6 ईमेल = उपयोगकर्ता% 40domain.com और lang = en & \
सेवा = weblogin% 3Acontinue% 3Dhttps% 253A% 2F% 2Faccounts.google.com% 2FManageAccount & \
source = android & Passwd = xxxxxxxxxxxxxxxx & operCountry = us & sdk_version = 17 और has_permission = 1


और उन्हें एक उत्तर मिला जो पिछले एक को पूरी तरह से दोहराता है:

Auth = https: //accounts.google.com/MergeSession; Args =% 3Dhttps% 253A% 252F% 252Facounts.google.com% 252FManageAccount और uberauth / AP ... & source = Android =ebLogin पर जारी रखें
Expiry0


यहां मुख्य पैरामीटर "मर्जसेशन" है। यदि आप अनुरोध पूरा करने के बाद इस URL को अनधिकृत ब्राउज़र में खोलते हैं (यह बहुत जल्दी किया जाना चाहिए), तो आपको तुरंत अपने खाते में लॉग इन किया जाएगा!

इस प्रकार, केवल एक उपयोगकर्ता नाम, सॉफ्टवेयर होने और android.clients.google.com/auth के अनुरोध को निष्पादित करने के बाद, दो-चरणीय सत्यापन को दरकिनार करके खाता सेटिंग पृष्ठ पर लॉग इन करना संभव है!

Google को ठीक करें

जैसा कि पहले उल्लेख किया गया है, यह विधि सबसे महत्वपूर्ण Google खाता अनुभाग - सेटिंग्स के लिए भी काम करती है। एक हमलावर पीड़ित के पीपी का उपयोग करके एक खुश कार्रवाई कर सकता है:

• यह API अनुरोध में url के रूप में " account.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=oz " पास कर सकता है। प्रतिक्रिया में प्राप्त मर्जसेशन URL इसे सीधे पासवर्ड रिकवरी पेज पर ले जाएगा, जहां यह मुख्य पासवर्ड रीसेट कर सकता है।
• इसी तरह, एक हमलावर अनुरोध के लिए url " accounts.google.com/b/0/SmsAuthConfig?hl=en " पर भेज सकता है, जो उसे 2FA सेटिंग्स के साथ पृष्ठ पर ले जाएगा, जहां वह सॉफ़्टवेयर जोड़ या हटा सकता है या 2FA को अक्षम कर सकता है।

यह अब 21 फरवरी से शुरू होना संभव नहीं है, जब Google इंजीनियरों ने छेद बंद कर दिया था। जहां तक ​​हम बता सकते हैं, Google अब कुछ अतिरिक्त स्थिति का समर्थन करता है जो आपको यह निर्धारित करने की अनुमति देता है कि आपने मर्जसेशन URL का उपयोग करके और 2FA का उपयोग करके एक सामान्य उपयोगकर्ता नाम और पासवर्ड का प्रमाणीकरण कैसे किया। सेटिंग्स पृष्ठ केवल बाद के मामले में उपलब्ध होगा। यदि आपने मर्जसेशन URL का उपयोग करके लॉग इन किया है, तो आपको 2FA पृष्ठ पर पुनर्निर्देशित किया जाएगा, जिसे मिस नहीं किया जा सकता।

कितना बुरा था?

हम मानते हैं कि यह प्रमाणीकरण प्रणाली का एक बड़ा छेद है, अगर उपयोगकर्ता के पास पासवर्ड दर्ज करने के लिए कोई रूप है, जो खाते पर पूर्ण नियंत्रण की अनुमति देगा। लेकिन इसके बावजूद, हम अभी भी इस बात से सहमत हैं कि Google द्वारा अपना फिक्स रोल करने से पहले ही, आपके खाते में 2FA चालू करना, ऐसा न करने से बहुत बेहतर है।

आजकल, एक हमलावर के पास अभी भी एक खाते पर नियंत्रण पाने के लिए अपने शस्त्रागार में तरीकों का एक सेट है। उदाहरण के लिए:

• उपयोगकर्ता को अपना पासवर्ड देने के लिए बाध्य करने के लिए फ़िशिंग साइट का निर्माण।
• इस तथ्य का उपयोग करना कि उपयोगकर्ता अक्सर विभिन्न साइटों पर एक ही पासवर्ड का उपयोग करते हैं। एक असुरक्षित साइट के पासवर्ड के साथ डेटाबेस को क्रैक करने के बाद, एक हमलावर अन्य साइटों पर खातों तक पहुंच प्राप्त करने का प्रयास कर सकता है।

ये दोनों उदाहरण एक प्रकार के हमले हैं जिन्हें सरल नियमों और डिजिटल स्वच्छता का पालन करके रोका जा सकता है। उदाहरण के लिए, विभिन्न साइटों पर एक ही पासवर्ड का उपयोग न करें और ई-मेल संदेशों में संदिग्ध लिंक पर क्लिक न करें। दुर्भाग्य से, ऐसे "उपयोगकर्ताओं के लिए शैक्षिक कार्यक्रम" शायद ही कभी अभ्यास में अच्छी तरह से काम करते हैं (और आर्थिक दृष्टिकोण से व्यावहारिक नहीं हो सकते हैं)।

इसके बावजूद, PP के साथ भी, Google का 2FA इन दोनों प्रकार के हमलों को कम कर सकता है, भले ही उपयोगकर्ता बेवकूफ़ बातें करते रहें। पीपी Google द्वारा उत्पन्न किए जाते हैं और इसमें उपयोगकर्ता का संस्मरण शामिल नहीं होता है, अर्थात यह संभावना नहीं है कि वह किसी अन्य साइट पर ठीक उसी पासवर्ड का उपयोग करता है। यहां तक ​​कि अगर एक हमलावर एक फ़िशिंग साइट बनाता है और सॉफ़्टवेयर को बाहर निकालता है, तो इसकी सफलता की संभावना नियमित रूप से पासवर्ड की तुलना में काफी कम होगी (संभवतः परिमाण के आदेशों से)।

हालांकि, पीपी का व्यापक उपयोग अभी भी एक संभावित खतरे को वहन करता है। यदि कोई हमलावर उन्हें मैलवेयर इंस्टॉल करने के लिए मजबूर कर सकता है, तो वे उपयोगकर्ता सिस्टम में कहीं सॉफ्टवेयर ढूंढ सकते हैं और निकाल सकते हैं (उदाहरण के लिए, लोकप्रिय पिजिन चैट क्लाइंट एक्सएमएल फाइल में स्पष्ट टेक्स्ट में पासवर्ड स्टोर करता है )। इसके अलावा, "मोटी-क्लाइंट" एप्लिकेशन, सॉफ़्टवेयर का मुख्य उपयोगकर्ता, अक्सर कमजोर एसएसएल प्रमाणपत्र सत्यापन की बल्कि अच्छी तरह से ज्ञात समस्या से अवगत कराया जाता है, जो संभावित रूप से आपको एमआईएम हमले का उपयोग करके सॉफ़्टवेयर चोरी करने की अनुमति देता है।

Google को ठीक करें इस स्थिति में बहुत मदद करता है। इस तथ्य के बावजूद कि सॉफ्टवेयर अभी भी उपयोगकर्ता को महत्वपूर्ण नुकसान पहुंचा सकता है, वह अपने खाते पर नियंत्रण बनाए रखने में सक्षम होगा और कुछ गलत होने पर सॉफ्टवेयर को वापस लेने की क्षमता। फिर भी, हम दृढ़ता से न्यूनतम विशेषाधिकारों के सिद्धांत में विश्वास करते हैं और व्यक्तिगत सॉफ़्टवेयर के विशेषाधिकारों को प्रतिबंधित करने के उद्देश्य से Google द्वारा आगे के कदम देखना चाहेंगे।


अपडेट # 1
संभावित जोखिम की चेतावनी देने वाले सॉफ़्टवेयर को बनाते समय Google ने अपनी चेतावनी अपडेट की:


अद्यतन # 2
क्रेग यंग ने nCircle से एक समान मुद्दे पर RSA के साथ BSides के सम्मेलन में एक प्रस्तुति दी!

घटनाओं की समय सीमा:
2012/07/16: डुओ के शोधकर्ताओं ने सॉफ्टवेयर कमजोरियों की उपस्थिति की पुष्टि की।
2012/07/18: समस्या का विवरण सुरक्षा@google.com को भेजा गया था।
2012/07/20: विवरण को स्पष्ट करने के लिए Google सुरक्षा के साथ चर्चा।
2012/07/24: Google द्वारा "अपेक्षित व्यवहार" के रूप में समस्या की पुष्टि और वर्गीकृत किया गया है।
2013/02/21: Google ने एक फ़िक्स जारी किया है जो पीपी सत्रों के लिए महत्वपूर्ण जानकारी तक पहुँच को प्रतिबंधित करता है।
2013/02/25: डुओ ने समस्या का वर्णन करते हुए एक लेख प्रकाशित किया।