OAuth to Account takeover

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

अगर आप चाहते हैं कि आपकी कंपनी HackTricks में विज्ञापित हो या HackTricks को PDF में डाउनलोड करें तो सब्सक्रिप्शन प्लान्स देखें!
आधिकारिक PEASS और HackTricks स्वैग प्राप्त करें
हमारे विशेष NFTs कलेक्शन The PEASS Family खोजें
शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।
अपने हैकिंग ट्रिक्स साझा करें, हैकट्रिक्स HackTricks और HackTricks Cloud github repos को PRs जमा करके।

मौलिक जानकारी

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 ढांचा के भीतर निम्नलिखित घटकों को समझना महत्वपूर्ण है:

संसाधन स्वामी: आप, जैसे उपयोगकर्ता/संस्था, अपने संसाधन, जैसे कि आपके सोशल मीडिया खाते के पोस्ट्स, तक पहुंच की अधिकृति देते हैं।
संसाधन सर्वर: प्रमाणित अनुरोधों का प्रबंधन करने वाला सर्वर जब एप्लिकेशन ने संसाधन स्वामी के पक्ष में एक्सेस टोकन प्राप्त कर लिया हो, उदाहरण के लिए, https://socialmedia.com।
क्लाइंट एप्लिकेशन: संसाधन स्वामी से अधिकृति मांगने वाला एप्लिकेशन, जैसे कि https://example.com।
अधिकरण सर्वर: संसाधन स्वामी की सफल प्रमाणीकरण और अधिकरण के बाद क्लाइंट एप्लिकेशन को एक्सेस टोकन प्रदान करने वाला सर्वर, उदाहरण के लिए, https://socialmedia.com।
client_id: एप्लिकेशन के लिए एक सार्वजनिक, अद्वितीय पहचानकर्ता।
client_secret: एक गोपनीय कुंजी, जिसे केवल एप्लिकेशन और अधिकरण सर्वर जानते हैं, एक्सेस टोकन उत्पन्न करने के लिए उपयोग की जाती है।
response_type: कोड जैसे टोकन के प्रकार को निर्दिष्ट करने वाला मान।
scope: संसाधन स्वामी से क्लाइंट एप्लिकेशन द्वारा मांगी जा रही पहुंच का स्तर।
redirect_uri: उस URL को जिस पर उपयोगकर्ता को प्रमाणीकरण के बाद पुनर्निर्देशित किया जाता है। यह सामान्यत: पूर्व-पंजीकृत पुनर्निर्देशित URL के साथ मेल खाना चाहिए।
state: एक पैरामीटर जो उपयोगकर्ता के पुनर्निर्देशन के बीच डेटा को बनाए रखने के लिए है। इसकी अद्वितीयता CSRF संरक्षण तंत्र के रूप में काम करने के लिए महत्वपूर्ण है।
grant_type: ग्रांट प्रकार और वापस किए जाने वाले टोकन के प्रकार को निर्दिष्ट करने वाला एक पैरामीटर।
code: अधिकरण सर्वर से अधिकृति कोड, जिसे क्लाइंट एप्लिकेशन द्वारा एक्सेस टोकन प्राप्त करने के लिए client_id और client_secret के साथ उपयोग किया जाता है।
access_token: संसाधन स्वामी के पक्ष से क्लाइंट एप्लिकेशन द्वारा API अनुरोधों के लिए उपयोग किया जाने वाला टोकन।
refresh_token: एप्लिकेशन को नए एक्सेस टोकन प्राप्त करने की स्वीकृति देता है बिना उपयोगकर्ता को फिर से प्रश्नित किए।

फ्लो

वास्तविक OAuth फ्लो निम्नलिखित प्रक्रिया के रूप में आगे बढ़ता है:

आप https://example.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

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

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

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"}

अंत में, प्रक्रिया https://example.com आपके access_token का उपयोग कर Social Media को एपीआई कॉल करने के लिए करती है

सुरक्षा दोष

ओपन रीडायरेक्ट_यूआरआई

redirect_uri OAuth और OpenID कार्यान्वयनों में सुरक्षा के लिए महत्वपूर्ण है, क्योंकि यह अधिकृति कोड जैसी संवेदनशील डेटा को पोस्ट-अधिकृति प्रेषित करता है। यदि गलती से कॉन्फ़िगर किया गया है, तो यह आक्रमणकर्ताओं को इन अनुरोधों को दुरुपयोग करने की अनुमति देता है, जिससे खाता हासिल किया जा सकता है।

शोधन तकनीक अधिकृति सर्वर की मान्यता तर्क पर निर्भर करती है। ये कठिन पथ मैचिंग से लेकर निर्दिष्ट डोमेन या सबडायरेक्टरी के भीतर किसी भी URL को स्वीकार करने तक हो सकते हैं। सामान्य शोधन विधियों में ओपन रीडायरेक्ट्स, पथ ट्रावर्सल, कमजोर रेजेक्स का दुरुपयोग, और टोकन चोरी के लिए एचटीएमएल इंजेक्शन शामिल हैं।

redirect_uri के अलावा, अन्य OAuth और OpenID पैरामीटर जैसे client_uri, policy_uri, tos_uri, और initiate_login_uri भी पुनर्निर्देशन हमलों के लिए संवेदनशील हैं। ये पैरामीटर वैकल्पिक हैं और उनका समर्थन सर्वर्स के बीच भिन्न हो सकता है।

ओपनआईडी सर्वर को लक्षित करने वालों के लिए, डिस्कवरी एंडपॉइंट (**.well-known/openid-configuration**) अक्सर मूल्यवान कॉन्फ़िगरेशन विवरणों जैसे registration_endpoint, request_uri_parameter_supported, और "require_request_uri_registration सूचीत करता है। ये विवरण पंजीकरण अंतबिंदु और सर्वर के अन्य कॉन्फ़िगरेशन विशेषताओं की पहचान में मदद कर सकते हैं।

रीडायरेक्ट कार्यान्वयन में एक्सएसएस

जैसा कि इस बग बाउंटी रिपोर्ट में उल्लेख किया गया है https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html ऐसा हो सकता है कि रीडायरेक्ट URL सर्वर के प्रतिक्रिया में प्रतिबिम्बित हो रहा हो, उपयोगकर्ता की प्रमाणीकरण के बाद, एक्सएसएस के लिए विकल्प हो। परीक्षण के लिए संभावित पेलोड:

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

CSRF - राज्य पैरामीटर के गलत हैंडलिंग

OAuth कार्यान्वयनों में, state पैरामीटर का दुरुपयोग या उपेक्षण क्रॉस-साइट रिक्वेस्ट फ़ॉर्ज़री (CSRF) हमलों के जोखिम को काफी बढ़ा सकता है। यह सुरक्षा दोष उत्पन्न होता है जब state पैरामीटर या तो उपयोग नहीं किया जाता है, स्थिर मान के रूप में उपयोग किया जाता है, या सही ढंग से सत्यापित नहीं किया जाता है, जिससे हमलावर CSRF सुरक्षा को छलना देने की अनुमति मिलती है।

हमलावर इसे इस्तेमाल करके अधिकारी के खाते को अपने खाते से जोड़ने के लिए अधिकारीकरण प्रक्रिया को अंतर्विराम कर सकते हैं, जिससे संभावित खाता अधिकार हो सकता है। यह विशेष रूप से ऐप्लिकेशनों में गंभीर है जहाँ OAuth का उपयोग प्रमाणीकरण उद्देश्यों के लिए किया जाता है।

इस सुरक्षा दोष के वास्तविक-जीवन उदाहरणों को विभिन्न CTF चैलेंजेस और हैकिंग प्लेटफॉर्मों में दर्ज किया गया है, जिससे इसके व्यावहारिक प्रभाव को हाइलाइट किया गया है। इस मुद्दे का विस्तार भी Slack, Stripe, और PayPal जैसी तृतीय-पक्ष सेवाओं के साथ एकीकरणों तक फैलता है, जहाँ हमलावर सूचनाएं या भुगतानों को अपने खातों पर पुनर्निर्देशित कर सकते हैं।

state पैरामीटर का सही हैंडलिंग और सत्यापन CSRF के खिलाफ सुरक्षा उपायों के लिए महत्वपूर्ण है और OAuth फ्लो को सुरक्षित बनाने के लिए।

पहले खाता अधिकार

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

रहस्यों का खुलासा

गोपनीय OAuth पैरामीटरों की पहचान और सुरक्षित रखना महत्वपूर्ण है। client_id सुरक्षित रूप से खुला जा सकता है, लेकिन client_secret का खुलासा करना महत्वपूर्ण जोखिम लेकर आता है। अगर client_secret का संकट हो जाता है, तो हमलावर आवेदन की पहचान और विश्वास का शोषण करके उपयोगकर्ता access_tokens और निजी सूचना चुरा सकते हैं।

एक सामान्य सुरक्षा दोष उत्पन्न होता है जब एप्लिकेशन गलती से अधिकारी तरफ access_token के लिए अधिकृति code का विनिमय संभालती है बजाय सर्वर-तरफ। यह गलती client_secret का प्रकट होने का कारण बनती है, हमलावर को आवेदन के रूप में access_tokens उत्पन्न करने की अनुमति देती है। इसके अतिरिक्त, सामाजिक इंजीनियरिंग के माध्यम से, हमलावर OAuth अधिकृति में अतिरिक्त स्कोप जोड़कर अधिकारों को बढ़ा सकते हैं, आवेदन की विश्वसनीय स्थिति का और भी शोषण करते हुए।

क्लाइंट सीक्रेट ब्रूटफ़ोर्स

आप सेवा प्रदाता के क्लाइंट_सीक्रेट का ब्रूटफ़ोर्स करने की कोशिश कर सकते हैं जो पहचान प्रदाता के साथ खातों की चोरी करने की कोशिश कर सकते हैं। 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 लीक कोड + स्थिति

जब क्लाइंट के पास कोड और स्थिति होती है, और वह किसी अलग पेज पर ब्राउज़ करते समय Referer हेडर में प्रतिबिम्बित होती है, तो यह वंशानुक्रमित होता है।

ब्राउज़र इतिहास में एक्सेस टोकन संग्रहीत

ब्राउज़र इतिहास में जाएं और देखें कि एक्सेस टोकन वहाँ सहेजा गया है या नहीं।

अनंत अधिकृति कोड

अधिकृति कोड को केवल कुछ समय तक जीवित रहना चाहिए ताकि हमलावार उसे चुरा और उसका उपयोग कर सके का समय खिड़की सीमित करने के लिए।

अधिकृति/ताजगी टोकन क्लाइंट से नहीं बाँधा गया

अगर आप अधिकृति कोड प्राप्त कर सकते हैं और उसे एक अलग क्लाइंट के साथ उपयोग कर सकते हैं तो आप अन्य खातों को ले सकते हैं।

खुश पथ, XSS, आइफ्रेम्स और पोस्ट मैसेजेस कोड और स्थिति मानों को लीक करने के लिए

इस पोस्ट की जाँच करें

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"
}
]
}

अन्य ऐप्स टोकन का दुरुपयोग

इस लेख में उल्लिखित के अनुसार, ओआथ फ्लो जो टोकन (और न कोड) प्राप्त करने की उम्मीद करते हैं, वे संकेत नहीं करते कि टोकन ऐप्लिकेशन का है या नहीं, वे संकेत हो सकते हैं यदि वे यह नहीं जांचते कि टोकन ऐप्लिकेशन का है।

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

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

दो लिंक और कुकी

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

इस प्रॉम्प्ट को अनदेखा करने के लिए, एक ऐसा ओआथ फ्लो आरंभ करने के लिए एक टैब खोलना संभव था जो इस आरयू कुकी को सेट करेगा उस returnUrl का उपयोग करके, प्रॉम्प्ट दिखाई नहीं देगा, और एक नया टैब खोलेगा जिसमें उस मान के बिना। फिर, प्रॉम्प्ट हमलावर के होस्ट के बारे में सूचित नहीं करेगा, लेकिन कुकी उसे सेट कर देगी, इसलिए टोकन हमलावर के होस्ट में भेजा जाएगा पुनर्निर्देशन में।

SSRF पैरामीटर

इस अनुसंधान की जांच करें इस तकनीक के अधिक विवरण के लिए।

ओआथ में डायनामिक क्लाइंट रजिस्ट्रेशन SSRF हमलों के लिए एक कम अवधारणात्मक लेकिन महत्वपूर्ण वेक्टर के रूप में काम करता है, विशेष रूप से सर्वर-साइड रिक्वेस्ट फॉर्जरी (SSRF) हमलों के लिए। इस एंडपॉइंट की ओआथ सर्वर को क्लाइंट ऐप्लिकेशन के बारे में विवरण प्राप्त करने की सेवा प्रदान करती है, संवेदनशील यूआरएल जिन्हें शोषित किया जा सकता है।

मुख्य बिंदु:

डायनामिक क्लाइंट रजिस्ट्रेशन अक्सर /रजिस्टर के लिए मैप किया जाता है और client_name, client_secret, redirect_uris, और लोगो या जेसन वेब कुंज (JWKs) के लिए यूआरएल जैसे विवरण स्वीकार करता है POST अनुरोधों के माध्यम से।
यह सुविधा RFC7591 और OpenID Connect Registration 1.0 में निर्धारित विनिमयों का पालन करती है, जिसमें SSRF के लिए संभावित बाधापूर्ण पैरामीटर शामिल हैं।
पंजीकरण प्रक्रिया कई तरीकों से अनजाने में सर्वर को SSRF के लिए उजागर कर सकती है:
logo_uri: क्लाइंट ऐप्लिकेशन के लोगो के लिए एक URL जो सर्वर द्वारा प्राप्त किया जा सकता है, SSRF को ट्रिगर कर सकता है या यदि यूआरएल को गलत ढंग से संभाला जाता है तो XSS में ले जा सकता है।
jwks_uri: क्लाइंट के JWK दस्तावेज़ के लिए एक URL, जो यदि दुरुपयोग से तैयार किया गया है, तो सर्वर को एक हमलावर नियंत्रित सर्वर को आउटबाउंड अनुरोध करने के लिए कारण बना सकता है।
sector_identifier_uri: redirect_uris के एक JSON अर्राय का संदर्भ देता है, जिसे सर्वर शोषित कर सकता है, एक SSRF अवसर बना सकता है।
request_uris: क्लाइंट के लिए अनुमत अनुरोध यूआरआई की सूची, जिसे यदि सर्वर अधिकृत करता है, तो उन यूआरआई का उपयोग करने के दौरान SSRF को उत्पन्न किया जा सकता है।

शोषण रणनीति:

SSRF को नए क्लाइंट को दर्ज करके विनाशकारी यूआरएल के साथ पैरामीटर जैसे logo_uri, jwks_uri, या sector_identifier_uri में दर्ज करके ट्रिगर किया जा सकता है।
request_uris के माध्यम से सीधा शोषण को सफलतापूर्वक किया जा सकता है यदि सर्वर अधिकृत कंट्रोल्स के द्वारा रोका जाता है, एक पूर्व-पंजीकृत, हमलावर नियंत्रित request_uri प्रदान करने से अधिकृत किया जा सकता है जो प्रमाणीकरण चरण के दौरान SSRF को सुविधाजनक बना सकता है।

PreviousNoSQL injection NextOpen Redirect

Last updated 6 days ago