OAuth to Account takeover
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Basic Information
OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी OAuth 2.0 दस्तावेज़ पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले OAuth 2.0 प्राधिकरण कोड अनुदान प्रकार पर केंद्रित है, जो एक प्राधिकरण ढांचा प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुँचने या उस पर क्रियाएँ करने की अनुमति देता है (प्राधिकरण सर्वर)।
एक काल्पनिक वेबसाइट https://example.com पर विचार करें, जिसे आपके सभी सोशल मीडिया पोस्ट प्रदर्शित करने के लिए डिज़ाइन किया गया है, जिसमें निजी पोस्ट भी शामिल हैं। इसे प्राप्त करने के लिए, OAuth 2.0 का उपयोग किया जाता है। https://example.com आपकी अनुमति मांगेगा आपके सोशल मीडिया पोस्ट तक पहुँचने के लिए। इसके परिणामस्वरूप, https://socialmedia.com पर एक सहमति स्क्रीन दिखाई देगी, जिसमें अनुमतियाँ और अनुरोध करने वाला डेवलपर का विवरण होगा। आपकी अनुमति मिलने पर, https://example.com को आपकी ओर से आपके पोस्ट तक पहुँचने की क्षमता मिलती है।
OAuth 2.0 ढांचे के भीतर निम्नलिखित घटकों को समझना आवश्यक है:
resource owner: आप, उपयोगकर्ता/संस्थान, अपनी संसाधन, जैसे आपके सोशल मीडिया खाते के पोस्ट, तक पहुँच की अनुमति देते हैं।
resource server: सर्वर जो प्रमाणित अनुरोधों का प्रबंधन करता है जब एप्लिकेशन ने
access tokenकोresource ownerकी ओर से सुरक्षित किया है, जैसे कि https://socialmedia.com।client application: अनुमति प्राप्त करने के लिए एप्लिकेशन जो
resource ownerसे अनुरोध करता है, जैसे कि https://example.com।authorization server: सर्वर जो
access tokensजारी करता हैclient applicationकोresource ownerके सफल प्रमाणीकरण और प्राधिकरण प्राप्त करने के बाद, जैसे कि https://socialmedia.com।client_id: एप्लिकेशन के लिए एक सार्वजनिक, अद्वितीय पहचानकर्ता।
client_secret: एक गोपनीय कुंजी, जो केवल एप्लिकेशन और प्राधिकरण सर्वर को ज्ञात होती है, जिसका उपयोग
access_tokensउत्पन्न करने के लिए किया जाता है।response_type: एक मान जो अनुरोधित टोकन के प्रकार को निर्दिष्ट करता है, जैसे
code।scope: पहुँच का स्तर जो
client applicationresource ownerसे अनुरोध कर रहा है।redirect_uri: URL जिस पर उपयोगकर्ता प्राधिकरण के बाद पुनर्निर्देशित होता है। यह आमतौर पर पूर्व-रजिस्टर्ड पुनर्निर्देशित URL के साथ मेल खाना चाहिए।
state: एक पैरामीटर जो उपयोगकर्ता के प्राधिकरण सर्वर पर जाने और लौटने के दौरान डेटा बनाए रखने के लिए है। इसकी विशिष्टता CSRF सुरक्षा तंत्र के रूप में कार्य करने के लिए महत्वपूर्ण है।
grant_type: एक पैरामीटर जो अनुदान प्रकार और लौटाए जाने वाले टोकन के प्रकार को इंगित करता है।
code:
authorization serverसे प्राधिकरण कोड, जिसका उपयोगclient_idऔरclient_secretके साथaccess_tokenप्राप्त करने के लिए किया जाता है।access_token: टोकन जो
client applicationresource ownerकी ओर से API अनुरोधों के लिए उपयोग करता है।refresh_token: एप्लिकेशन को उपयोगकर्ता को फिर से प्रॉम्प्ट किए बिना एक नया
access_tokenप्राप्त करने की अनुमति देता है।
Flow
वास्तविक OAuth प्रवाह इस प्रकार है:
आप https://example.com पर जाते हैं और “सोशल मीडिया के साथ एकीकृत करें” बटन का चयन करते हैं।
साइट फिर https://socialmedia.com पर आपके प्राधिकरण के लिए अनुरोध भेजती है ताकि https://example.com के एप्लिकेशन को आपके पोस्ट तक पहुँचने की अनुमति मिल सके। अनुरोध इस प्रकार संरचित है:
आपको फिर एक सहमति पृष्ठ प्रस्तुत किया जाता है।
आपकी स्वीकृति के बाद, सोशल मीडिया
redirect_uriपरcodeऔरstateपैरामीटर के साथ एक प्रतिक्रिया भेजता है:
https://example.com इस
codeका उपयोग करता है, इसकेclient_idऔरclient_secretके साथ, आपके पक्ष मेंaccess_tokenप्राप्त करने के लिए एक सर्वर-साइड अनुरोध करने के लिए, जिससे आपको उन अनुमतियों तक पहुँचने की अनुमति मिलती है जिन पर आपने सहमति दी थी:
अंत में, प्रक्रिया समाप्त होती है क्योंकि https://example.com आपके
access_tokenका उपयोग करके सोशल मीडिया पर API कॉल करता है।
Vulnerabilities
Open redirect_uri
redirect_uri OAuth और OpenID कार्यान्वयन में सुरक्षा के लिए महत्वपूर्ण है, क्योंकि यह संवेदनशील डेटा, जैसे कि प्राधिकरण कोड, को प्राधिकरण के बाद भेजने के लिए निर्देशित करता है। यदि गलत तरीके से कॉन्फ़िगर किया गया, तो यह हमलावरों को इन अनुरोधों को दुर्भावनापूर्ण सर्वरों पर पुनर्निर्देशित करने की अनुमति दे सकता है, जिससे खाता अधिग्रहण संभव हो जाता है।
शोषण तकनीकें प्राधिकरण सर्वर की मान्यता लॉजिक के आधार पर भिन्न होती हैं। ये सख्त पथ मिलान से लेकर निर्दिष्ट डोमेन या उपनिर्देशिका के भीतर किसी भी URL को स्वीकार करने तक हो सकती हैं। सामान्य शोषण विधियों में ओपन रीडायरेक्ट, पथ यात्रा, कमजोर regex का शोषण, और टोकन चोरी के लिए HTML इंजेक्शन शामिल हैं।
redirect_uri के अलावा, अन्य OAuth और OpenID पैरामीटर जैसे client_uri, policy_uri, tos_uri, और initiate_login_uri भी पुनर्निर्देशन हमलों के प्रति संवेदनशील हैं। ये पैरामीटर वैकल्पिक हैं और इनका समर्थन सर्वरों में भिन्न होता है।
जो लोग OpenID सर्वर को लक्षित कर रहे हैं, उनके लिए खोज बिंदु (**.well-known/openid-configuration**) अक्सर मूल्यवान कॉन्फ़िगरेशन विवरण जैसे registration_endpoint, request_uri_parameter_supported, और "require_request_uri_registration" सूचीबद्ध करता है। ये विवरण पंजीकरण बिंदु और सर्वर के अन्य कॉन्फ़िगरेशन विशिष्टताओं की पहचान करने में मदद कर सकते हैं।
XSS in redirect implementation
जैसा कि इस बग बाउंटी रिपोर्ट में उल्लेख किया गया है https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html यह संभव हो सकता है कि पुनर्निर्देशित URL सर्वर के उत्तर में परिलक्षित हो रहा है उपयोगकर्ता के प्रमाणीकरण के बाद, XSS के प्रति संवेदनशील। परीक्षण के लिए संभावित पेलोड:
CSRF - Improper handling of state parameter
OAuth कार्यान्वयन में, state parameter का दुरुपयोग या अनुपस्थिति Cross-Site Request Forgery (CSRF) हमलों के जोखिम को काफी बढ़ा सकती है। यह भेद्यता तब उत्पन्न होती है जब state parameter उपयोग नहीं किया जाता, स्थिर मान के रूप में उपयोग किया जाता है, या सही तरीके से मान्य नहीं किया जाता, जिससे हमलावर CSRF सुरक्षा को बायपास कर सकते हैं।
हमलावर इसको अधिकृत प्रक्रिया को इंटरसेप्ट करके पीड़ित के खाते के साथ अपने खाते को लिंक करने के लिए उपयोग कर सकते हैं, जिससे संभावित खाते पर कब्जा हो सकता है। यह विशेष रूप से उन अनुप्रयोगों में महत्वपूर्ण है जहाँ OAuth का उपयोग प्रमाणीकरण उद्देश्यों के लिए किया जाता है।
इस भेद्यता के वास्तविक दुनिया के उदाहरण विभिन्न CTF चुनौतियों और हैकिंग प्लेटफार्मों में दस्तावेजीकृत किए गए हैं, जो इसके व्यावहारिक प्रभावों को उजागर करते हैं। यह समस्या Slack, Stripe, और PayPal जैसे तीसरे पक्ष की सेवाओं के साथ एकीकरण तक भी फैली हुई है, जहाँ हमलावर सूचनाओं या भुगतानों को अपने खातों में पुनर्निर्देशित कर सकते हैं।
state parameter का सही तरीके से प्रबंधन और मान्यता CSRF के खिलाफ सुरक्षा और OAuth प्रवाह को सुरक्षित करने के लिए महत्वपूर्ण है।
Pre Account Takeover
खाते के निर्माण पर ईमेल सत्यापन के बिना: हमलावर पीड़ित के ईमेल का उपयोग करके पूर्व-निर्मित खाता बना सकते हैं। यदि पीड़ित बाद में लॉगिन के लिए किसी तीसरे पक्ष की सेवा का उपयोग करता है, तो अनुप्रयोग अनजाने में इस तीसरे पक्ष के खाते को हमलावर के पूर्व-निर्मित खाते से लिंक कर सकता है, जिससे अनधिकृत पहुंच हो सकती है।
OAuth ईमेल सत्यापन की लापरवाही का लाभ उठाना: हमलावर OAuth सेवाओं का लाभ उठा सकते हैं जो ईमेल की पुष्टि नहीं करती हैं, अपनी सेवा के साथ पंजीकरण करके और फिर खाते के ईमेल को पीड़ित के ईमेल में बदलकर। यह विधि भी अनधिकृत खाता पहुंच का जोखिम उठाती है, पहले परिदृश्य के समान लेकिन एक अलग हमले के वेक्टर के माध्यम से।
Disclosure of Secrets
गुप्त OAuth पैरामीटर की पहचान और सुरक्षा महत्वपूर्ण है। जबकि client_id को सुरक्षित रूप से प्रकट किया जा सकता है, client_secret को उजागर करना महत्वपूर्ण जोखिम पैदा करता है। यदि client_secret से समझौता किया जाता है, तो हमलावर उपयोगकर्ता के access_tokens और निजी जानकारी को चोरी करने के लिए अनुप्रयोग की पहचान और विश्वास का लाभ उठा सकते हैं।
एक सामान्य भेद्यता तब उत्पन्न होती है जब अनुप्रयोग गलती से ग्राहक-पक्ष पर access_token के लिए अधिकृत code के आदान-प्रदान को संभालते हैं, न कि सर्वर-पक्ष पर। यह गलती client_secret के उजागर होने का कारण बनती है, जिससे हमलावर अनुप्रयोग के बहाने access_tokens उत्पन्न कर सकते हैं। इसके अलावा, सामाजिक इंजीनियरिंग के माध्यम से, हमलावर OAuth अधिकृत में अतिरिक्त स्कोप जोड़कर विशेषाधिकार बढ़ा सकते हैं, जिससे अनुप्रयोग की विश्वसनीय स्थिति का और लाभ उठाया जा सकता है।
Client Secret Bruteforce
आप सेवा प्रदाता के पहचान प्रदाता के साथ client_secret को bruteforce करने का प्रयास कर सकते हैं ताकि खातों को चुराने की कोशिश की जा सके। BF के लिए अनुरोध इस प्रकार दिख सकता है:
Referer Header leaking Code + State
एक बार जब क्लाइंट के पास कोड और स्टेट हो, यदि यह Referer हेडर के अंदर परिलक्षित होता है जब वह किसी अन्य पृष्ठ पर जाता है, तो यह कमजोर है।
Access Token Stored in Browser History
ब्राउज़र इतिहास में जाएं और जांचें कि क्या एक्सेस टोकन वहां सहेजा गया है।
Everlasting Authorization Code
अधिकार कोड को केवल कुछ समय के लिए जीवित रहना चाहिए ताकि हमलावर द्वारा इसे चुराने और उपयोग करने के लिए समय की खिड़की को सीमित किया जा सके।
Authorization/Refresh Token not bound to client
यदि आप अधिकार कोड प्राप्त कर सकते हैं और इसे एक अलग क्लाइंट के साथ उपयोग कर सकते हैं, तो आप अन्य खातों पर नियंत्रण कर सकते हैं।
Happy Paths, XSS, Iframes & Post Messages to leak code & state values
AWS Cognito
इस बग बाउंटी रिपोर्ट में: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ आप देख सकते हैं कि टोकन जो AWS Cognito उपयोगकर्ता को वापस देता है, उसमें उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं। इसलिए, यदि आप एक अलग उपयोगकर्ता ईमेल के लिए उपयोगकर्ता ईमेल बदल सकते हैं, तो आप अन्य खातों पर काबू पाने में सक्षम हो सकते हैं।
For more detailed info about how to abuse AWS cognito check:
Abusing other Apps tokens
जैसा कि इस लेख में उल्लेख किया गया है, OAuth प्रवाह जो token (और न कि कोड) प्राप्त करने की अपेक्षा करते हैं, वे कमजोर हो सकते हैं यदि वे यह नहीं जांचते कि token ऐप का है।
यह इसलिए है क्योंकि एक हमलावर एक ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है (उदाहरण के लिए) अपने स्वयं के ऐप्लिकेशन में। फिर, जब एक पीड़ित हमलावर के ऐप्लिकेशन में फेसबुक के साथ लॉगिन करता है, तो हमलावर उपयोगकर्ता के OAuth token को प्राप्त कर सकता है जो उसके ऐप्लिकेशन को दिया गया है, और इसका उपयोग पीड़ित OAuth ऐप्लिकेशन में पीड़ित के उपयोगकर्ता token के साथ लॉगिन करने के लिए कर सकता है।
इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप्लिकेशन तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्लिकेशनों में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो token की अपेक्षा कर रहे हैं और यह नहीं जांच रहे हैं कि token उनके ऐप ID को दिया गया था।
Two links & cookie
इस लेख के अनुसार, यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें returnUrl हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी एक कुकी (RU) में स्टोर की जाएगी और बाद के चरण में prompt उपयोगकर्ता से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए तैयार है।
इस prompt को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि Oauth प्रवाह को शुरू किया जा सके जो इस RU कुकी को returnUrl का उपयोग करके सेट करेगा, prompt दिखाए जाने से पहले टैब को बंद कर दें, और बिना उस मान के एक नया टैब खोलें। तब, prompt हमलावर के होस्ट के बारे में जानकारी नहीं देगा, लेकिन कुकी को इसके लिए सेट किया जाएगा, इसलिए token हमलावर के होस्ट को पुनर्निर्देशन में भेजा जाएगा।
Prompt Interaction Bypass
जैसा कि इस वीडियो में समझाया गया है, कुछ OAuth कार्यान्वयन prompt GET पैरामीटर को None (&prompt=none) के रूप में इंगित करने की अनुमति देते हैं ताकि उपयोगकर्ताओं से दिए गए एक्सेस की पुष्टि करने के लिए नहीं पूछा जाए यदि वे पहले से ही प्लेटफॉर्म में लॉगिन कर चुके हैं।
response_mode
जैसा कि इस वीडियो में समझाया गया है, यह संभव हो सकता है कि पैरामीटर response_mode को इंगित किया जाए कि आप अंतिम URL में कोड कहां प्रदान करना चाहते हैं:
response_mode=query-> कोड एक GET पैरामीटर के अंदर प्रदान किया जाता है:?code=2397rf3gu93fresponse_mode=fragment-> कोड URL के फ्रैगमेंट पैरामीटर के अंदर प्रदान किया जाता है#code=2397rf3gu93fresponse_mode=form_post-> कोड एक POST फॉर्म के अंदर प्रदान किया जाता है जिसमें एक इनपुट होता है जिसेcodeकहा जाता है और मानresponse_mode=web_message-> कोड एक पोस्ट संदेश में भेजा जाता है:window.opener.postMessage({"code": "asdasdasd...
OAuth ROPC flow - 2 FA bypass
इस ब्लॉग पोस्ट के अनुसार, यह एक OAuth प्रवाह है जो उपयोगकर्ता नाम और पासवर्ड के माध्यम से OAuth में लॉगिन करने की अनुमति देता है। यदि इस सरल प्रवाह के दौरान एक token लौटाया जाता है जिसमें सभी क्रियाओं तक पहुंच होती है जो उपयोगकर्ता कर सकता है, तो उस token का उपयोग करके 2FA को बायपास करना संभव है।
SSRFs parameters
इस शोध की जांच करें इस तकनीक के आगे के विवरण के लिए।
OAuth में डायनामिक क्लाइंट पंजीकरण सुरक्षा कमजोरियों के लिए एक कम स्पष्ट लेकिन महत्वपूर्ण वेक्टर के रूप में कार्य करता है, विशेष रूप से सर्वर-साइड अनुरोध धोखाधड़ी (SSRF) हमलों के लिए। यह एंडपॉइंट OAuth सर्वरों को क्लाइंट ऐप्लिकेशनों के बारे में विवरण प्राप्त करने की अनुमति देता है, जिसमें संवेदनशील URLs शामिल हैं जिन्हें शोषित किया जा सकता है।
मुख्य बिंदु:
डायनामिक क्लाइंट पंजीकरण अक्सर
/registerपर मैप किया जाता है और इसमेंclient_name,client_secret,redirect_uris, और लोगो या JSON वेब कुंजी सेट (JWKs) के लिए URLs जैसे विवरण POST अनुरोधों के माध्यम से स्वीकार किए जाते हैं।यह सुविधा RFC7591 और OpenID कनेक्ट पंजीकरण 1.0 में निर्धारित विनिर्देशों का पालन करती है, जिसमें पैरामीटर शामिल हैं जो SSRF के प्रति संवेदनशील हो सकते हैं।
पंजीकरण प्रक्रिया अनजाने में कई तरीकों से सर्वरों को SSRF के प्रति उजागर कर सकती है:
logo_uri: क्लाइंट ऐप्लिकेशन के लोगो के लिए एक URL जो सर्वर द्वारा लाया जा सकता है, SSRF को ट्रिगर कर सकता है या यदि URL को गलत तरीके से संभाला गया तो XSS का कारण बन सकता है।jwks_uri: क्लाइंट के JWK दस्तावेज़ के लिए एक URL, जिसे यदि दुर्भावनापूर्ण तरीके से तैयार किया गया हो, तो यह सर्वर को हमलावर-नियंत्रित सर्वर पर आउटबाउंड अनुरोध करने का कारण बन सकता है।sector_identifier_uri:redirect_urisके JSON एरे का संदर्भ देता है, जिसे सर्वर लाने की संभावना है, जिससे SSRF का अवसर बनता है।request_uris: क्लाइंट के लिए अनुमत अनुरोध URIs की सूची, जिन्हें यदि सर्वर इन URIs को प्राधिकरण प्रक्रिया की शुरुआत में लाता है तो शोषित किया जा सकता है।
शोषण रणनीति:
SSRF को
logo_uri,jwks_uri, याsector_identifier_uriजैसे पैरामीटर में दुर्भावनापूर्ण URLs के साथ नए क्लाइंट को पंजीकृत करके ट्रिगर किया जा सकता है।जबकि
request_urisके माध्यम से सीधे शोषण को व्हाइटलिस्ट नियंत्रणों द्वारा कम किया जा सकता है, एक पूर्व-पंजीकृत, हमलावर-नियंत्रितrequest_uriप्रदान करना प्राधिकरण चरण के दौरान SSRF को सुविधाजनक बना सकता है।
OAuth providers Race Conditions
यदि आप जिस प्लेटफॉर्म का परीक्षण कर रहे हैं वह एक OAuth प्रदाता है संभावित रेस कंडीशंस के लिए इसे पढ़ें.
