hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth to Account takeover

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

{% embed url="https://websec.nl/" %}

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: सर्वर जो client application को access tokens जारी करता है जब resource owner की सफल प्रमाणीकरण और प्राधिकरण सुरक्षित हो, जैसे कि https://socialmedia.com।
• client_id: एप्लिकेशन के लिए एक सार्वजनिक, अद्वितीय पहचानकर्ता।
• client_secret: एक गोपनीय कुंजी, जो केवल एप्लिकेशन और प्राधिकरण सर्वर को ज्ञात होती है, जिसका उपयोग access_tokens उत्पन्न करने के लिए किया जाता है।
• response_type: एक मान जो अनुरोधित टोकन के प्रकार को निर्दिष्ट करता है, जैसे code।
• scope: उपयोगकर्ता से अनुरोधित पहुँच का स्तर जो client application द्वारा resource owner से मांगा जा रहा है।
• redirect_uri: URL जिस पर उपयोगकर्ता प्राधिकरण के बाद पुनर्निर्देशित होता है। यह आमतौर पर पूर्व-रजिस्टर्ड पुनर्निर्देशित URL के साथ मेल खाना चाहिए।
• state: एक पैरामीटर जो उपयोगकर्ता के प्राधिकरण सर्वर पर जाने और लौटने के दौरान डेटा बनाए रखने के लिए होता है। इसकी विशिष्टता CSRF सुरक्षा तंत्र के रूप में कार्य करने के लिए महत्वपूर्ण है।
• grant_type: एक पैरामीटर जो अनुदान प्रकार और लौटाए जाने वाले टोकन के प्रकार को इंगित करता है।
• code: authorization server से प्राधिकरण कोड, जिसका उपयोग client application द्वारा access_token प्राप्त करने के लिए client_id और client_secret के साथ किया जाता है।
• access_token: टोकन जो client application resource owner की ओर से API अनुरोधों के लिए उपयोग करता है।
• refresh_token: एप्लिकेशन को बिना उपयोगकर्ता को फिर से प्रॉम्प्ट किए एक नया access_token प्राप्त करने की अनुमति देता है।

Flow

वास्तविक OAuth प्रवाह इस प्रकार है:

1. आप https://example.com पर जाते हैं और “सोशल मीडिया के साथ एकीकृत करें” बटन का चयन करते हैं।
2. साइट फिर https://socialmedia.com पर आपके पोस्ट तक पहुँचने के लिए https://example.com के एप्लिकेशन को अनुमति देने के लिए आपकी अनुमति मांगने वाला अनुरोध भेजती है। अनुरोध इस प्रकार संरचित है:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. फिर आपको एक सहमति पृष्ठ प्रस्तुत किया जाता है।
4. आपकी स्वीकृति के बाद, सोशल मीडिया redirect_uri को code और state पैरामीटर के साथ एक प्रतिक्रिया भेजता है:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com इस code का उपयोग करता है, इसके client_id और client_secret के साथ, आपके पक्ष में access_token प्राप्त करने के लिए एक सर्वर-साइड अनुरोध करने के लिए, जिससे आपको उन अनुमतियों तक पहुँचने की अनुमति मिलती है जिन पर आपने सहमति दी थी:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. अंत में, प्रक्रिया समाप्त होती है क्योंकि 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 के प्रति संवेदनशील। परीक्षण के लिए संभावित पेलोड:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

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

1. खाते के निर्माण पर ईमेल सत्यापन के बिना: हमलावर पीड़ित के ईमेल का उपयोग करके पूर्व-निर्मित खाता बना सकते हैं। यदि पीड़ित बाद में लॉगिन के लिए किसी तीसरे पक्ष की सेवा का उपयोग करता है, तो अनुप्रयोग अनजाने में इस तीसरे पक्ष के खाते को हमलावर के पूर्व-निर्मित खाते से लिंक कर सकता है, जिससे अनधिकृत पहुंच हो सकती है।
2. 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 के लिए अनुरोध इस प्रकार दिख सकता है:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

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

Check this post

AWS Cognito

इस बग बाउंटी रिपोर्ट में: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ आप देख सकते हैं कि टोकन जो AWS Cognito उपयोगकर्ता को वापस देता है, उसमें उपयोगकर्ता डेटा को ओवरराइट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं। इसलिए, यदि आप एक अलग उपयोगकर्ता ईमेल के लिए उपयोगकर्ता ईमेल बदल सकते हैं, तो आप अन्य खातों पर काबू पाने में सक्षम हो सकते हैं।

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

For more detailed info about how to abuse AWS cognito check:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

Abusing other Apps tokens

जैसा कि इस लेख में उल्लेख किया गया है, OAuth प्रवाह जो token (और न कि कोड) प्राप्त करने की अपेक्षा करते हैं, वे कमजोर हो सकते हैं यदि वे यह नहीं जांचते कि token ऐप का है।

यह इसलिए है क्योंकि एक हमलावर एक ऐप्लिकेशन बना सकता है जो OAuth का समर्थन करता है और फेसबुक के साथ लॉगिन करता है (उदाहरण के लिए) अपने स्वयं के ऐप्लिकेशन में। फिर, जब एक पीड़ित हमलावर के ऐप्लिकेशन में फेसबुक के साथ लॉगिन करता है, तो हमलावर उपयोगकर्ता के OAuth token को प्राप्त कर सकता है जो उसके ऐप्लिकेशन को दिया गया है, और इसका उपयोग पीड़ित OAuth ऐप्लिकेशन में पीड़ित के उपयोगकर्ता token के साथ लॉगिन करने के लिए कर सकता है।

{% hint style="danger" %} इसलिए, यदि हमलावर उपयोगकर्ता को अपने OAuth ऐप्लिकेशन तक पहुंच प्राप्त करने में सफल हो जाता है, तो वह उन ऐप्लिकेशनों में पीड़ित के खाते पर नियंत्रण प्राप्त कर सकेगा जो token की अपेक्षा कर रहे हैं और यह जांच नहीं कर रहे हैं कि token उनके ऐप ID को दिया गया था। {% endhint %}

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=2397rf3gu93f
• response_mode=fragment -> कोड URL के फ्रैगमेंट पैरामीटर के अंदर प्रदान किया जाता है #code=2397rf3gu93f
• response_mode=form_post -> कोड एक POST फॉर्म के अंदर प्रदान किया जाता है जिसमें एक इनपुट होता है जिसे code कहा जाता है और मान
• response_mode=web_message -> कोड एक पोस्ट संदेश में भेजा जाता है: window.opener.postMessage({"code": "asdasdasd...

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 प्रदाता है संभावित रेस कंडीशंस के लिए इसे पढ़ें。

References

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors

{% embed url="https://websec.nl/" %}

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}