OAuth to Account takeover

Reading time: 17 minutes

Basic Information

OAuth विभिन्न संस्करणों की पेशकश करता है, जिनकी मौलिक जानकारी OAuth 2.0 documentation पर उपलब्ध है। यह चर्चा मुख्य रूप से व्यापक रूप से उपयोग किए जाने वाले OAuth 2.0 authorization code grant type पर केंद्रित है, जो एक प्राधिकरण ढांचा प्रदान करता है जो एक एप्लिकेशन को किसी अन्य एप्लिकेशन में उपयोगकर्ता के खाते तक पहुंचने या उस पर क्रियाएँ करने की अनुमति देता है (प्राधिकरण सर्वर)।

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

Flow

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

1. आप https://example.com पर जाते हैं और “Integrate with Social Media” बटन का चयन करते हैं।
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. आपकी स्वीकृति के बाद, Social Media 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:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Abusing other Apps tokens

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

यह इसलिए है क्योंकि एक हमलावर एक ऐप्लिकेशन बना सकता है जो 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=2397rf3gu93f
• response_mode=fragment -> कोड URL के फ़्रैगमेंट पैरामीटर #code=2397rf3gu93f के अंदर प्रदान किया जाता है
• response_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 किया जा सकता है। हमला था:

1. पीड़ित हमलावर के वेब पृष्ठ पर पहुंचता है
2. पीड़ित दुर्भावनापूर्ण लिंक खोलता है और एक ओपनर Google OAuth प्रवाह को response_type=id_token,code&prompt=none के रूप में अतिरिक्त पैरामीटर के साथ शुरू करता है, रेफरर के रूप में हमलावर की वेबसाइट का उपयोग करते हुए।
3. ओपनर में, जब प्रदाता पीड़ित को अधिकृत करता है, तो यह उन्हें redirect_uri पैरामीटर (पीड़ित वेब) के मान पर वापस भेजता है जिसमें 30X कोड होता है जो अभी भी हमलावर की वेबसाइट को रेफरर में रखता है।
4. पीड़ित वेबसाइट रेफरर के आधार पर ओपन रीडायरेक्ट को ट्रिगर करती है जो पीड़ित उपयोगकर्ता को हमलावर की वेबसाइट पर पुनर्निर्देशित करती है, क्योंकि respose_type id_token,code था, कोड हमलावर को URL के फ़्रैगमेंट में वापस भेजा जाएगा जिससे वह पीड़ित साइट पर उपयोगकर्ता के खाते पर नियंत्रण प्राप्त कर सके।

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