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 applicationद्वाराaccess_tokenप्राप्त करने के लिएclient_idऔरclient_secretके साथ किया जाता है।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 (और न कि कोड) प्राप्त करने की अपेक्षा करते हैं, यदि वे यह नहीं जांचते कि टोकन ऐप का है, तो वे कमजोर हो सकते हैं।
यह इसलिए है क्योंकि एक हमलावर एक ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है (उदाहरण के लिए) अपने स्वयं के ऐप्लिकेशन में। फिर, जब एक पीड़ित फेसबुक में हमलावर के ऐप्लिकेशन में लॉगिन करता है, तो हमलावर उपयोगकर्ता के OAuth टोकन को प्राप्त कर सकता है जो उसके ऐप्लिकेशन को दिया गया है, और इसका उपयोग पीड़ित OAuth ऐप्लिकेशन में पीड़ित के उपयोगकर्ता टोकन का उपयोग करके लॉगिन करने के लिए कर सकता है।
इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप्लिकेशन तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्लिकेशनों में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो टोकन की अपेक्षा कर रहे हैं और यह जांच नहीं कर रहे हैं कि टोकन उनके ऐप आईडी को दिया गया था या नहीं।
Two links & cookie
इस लेख के अनुसार, यह संभव था कि एक पीड़ित एक पृष्ठ खोले जिसमें returnUrl हमलावर के होस्ट की ओर इशारा करता है। यह जानकारी एक कुकी (RU) में स्टोर की जाएगी और बाद के चरण में प्रॉम्प्ट उपयोगकर्ता से पूछेगा कि क्या वह उस हमलावर के होस्ट को एक्सेस देने के लिए तैयार है।
इस प्रॉम्प्ट को बायपास करने के लिए, यह संभव था कि एक टैब खोला जाए ताकि Oauth प्रवाह को आरंभ किया जा सके जो इस RU कुकी को returnUrl का उपयोग करके सेट करेगा, प्रॉम्प्ट दिखाए जाने से पहले टैब को बंद कर दें, और बिना उस मान के एक नया टैब खोलें। फिर, प्रॉम्प्ट हमलावर के होस्ट के बारे में जानकारी नहीं देगा, लेकिन कुकी को इसके लिए सेट किया जाएगा, इसलिए टोकन हमलावर के होस्ट पर पुनर्निर्देशन में भेजा जाएगा।
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 में लॉगिन करने की अनुमति देता है। यदि इस सरल प्रवाह के दौरान एक टोकन लौटाया जाता है जिसमें सभी क्रियाओं तक पहुंच होती है जो उपयोगकर्ता कर सकता है, तो उस टोकन का उपयोग करके 2FA को बायपास करना संभव है।
ATO on web page redirecting based on open redirect to referrer
यह ब्लॉगपोस्ट बताता है कि कैसे एक ओपन रीडायरेक्ट का उपयोग करके रेफरर के मान से OAuth का दुरुपयोग करके ATO किया जा सकता है। हमला था:
पीड़ित हमलावर के वेब पृष्ठ पर पहुंचता है
पीड़ित दुर्भावनापूर्ण लिंक खोलता है और एक ओपनर Google OAuth प्रवाह को
response_type=id_token,code&prompt=noneके रूप में अतिरिक्त पैरामीटर के साथ आरंभ करता है, रेफरर के रूप में हमलावर की वेबसाइट का उपयोग करते हुए।ओपनर में, जब प्रदाता पीड़ित को अधिकृत करता है, तो यह उन्हें
redirect_uriपैरामीटर (पीड़ित वेब) के मान पर वापस भेजता है जिसमें 30X कोड होता है जो अभी भी हमलावर की वेबसाइट को रेफरर में रखता है।पीड़ित वेबसाइट रेफरर के आधार पर ओपन रीडायरेक्ट को ट्रिगर करती है जो पीड़ित उपयोगकर्ता को हमलावर की वेबसाइट पर पुनर्निर्देशित करती है, क्योंकि
respose_typeid_token,codeथा, कोड हमलावर को URL के फ़्रैगमेंट में वापस भेजा जाएगा जिससे वह पीड़ित साइट पर Google के माध्यम से उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।
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 प्रदाता है संभावित रेस कंडीशंस के लिए इसे पढ़ें.
