mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 12:51:33 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -9,7 +9,7 @@
|
||||
Google Workspace का डोमेन-वाइड डेलीगेशन एक पहचान वस्तु, या तो एक **बाहरी ऐप** जो Google Workspace मार्केटप्लेस से है या एक आंतरिक **GCP सेवा खाता**, को **उपयोगकर्ताओं की ओर से Workspace में डेटा तक पहुंचने** की अनुमति देता है।
|
||||
|
||||
> [!NOTE]
|
||||
> इसका मतलब यह है कि **GCP परियोजनाओं** के भीतर **सेवा खाते** एक संगठन के Workspace उपयोगकर्ताओं की **नकल** कर सकते हैं (या यहां तक कि किसी अन्य से भी)।
|
||||
> इसका मतलब यह है कि **GCP परियोजनाओं** के अंदर **सेवा खाते** एक संगठन के **Workspace उपयोगकर्ताओं** की नकल कर सकते हैं (या यहां तक कि किसी अलग संगठन के भी)।
|
||||
|
||||
इसकी कार्यप्रणाली के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
@@ -19,14 +19,14 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### मौजूदा डेलीगेशन का समझौता
|
||||
|
||||
यदि एक हमलावर ने **GCP पर कुछ पहुंच का समझौता किया** और **कंपनी के एक मान्य Workspace उपयोगकर्ता का ईमेल** (अधिमानतः **सुपर एडमिन**) जानता है, तो वह **सभी परियोजनाओं की सूची बना सकता है** जिन तक उसे पहुंच है, **परियोजनाओं के सभी SAs की सूची बना सकता है**, यह जांच सकता है कि उसे **कौन से सेवा खातों तक पहुंच है**, और **हर SA के साथ इन सभी चरणों को दोहरा सकता है** जिसे वह नकल कर सकता है।\
|
||||
उसके पास **सभी सेवा खातों की एक सूची** और **Workspace** **ईमेल** की सूची होने पर, हमलावर **प्रत्येक सेवा खाते के साथ उपयोगकर्ता की नकल करने** की कोशिश कर सकता है।
|
||||
यदि एक हमलावर ने **GCP पर कुछ पहुंच का समझौता किया** और **कंपनी के एक मान्य Workspace उपयोगकर्ता ईमेल** (अधिमानतः **सुपर एडमिन**) को जानता है, तो वह **सभी परियोजनाओं की सूची बना सकता है** जिन तक उसे पहुंच है, **परियोजनाओं के सभी SAs की सूची बना सकता है**, यह जांच सकता है कि उसे **कौन से सेवा खातों तक पहुंच है**, और **हर SA के साथ इन सभी चरणों को दोहरा सकता है** जिसे वह नकल कर सकता है।\
|
||||
एक **सेवा खातों की पूरी सूची** और **Workspace** **ईमेल्स** के साथ, हमलावर **प्रत्येक सेवा खाते के साथ उपयोगकर्ता की नकल करने** की कोशिश कर सकता है।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि डोमेन वाइड डेलीगेशन को कॉन्फ़िगर करते समय किसी Workspace उपयोगकर्ता की आवश्यकता नहीं होती है, इसलिए बस जान लें कि **एक मान्य उपयोगकर्ता नकल के लिए पर्याप्त और आवश्यक है**।\
|
||||
> ध्यान दें कि डोमेन वाइड डेलीगेशन को कॉन्फ़िगर करते समय किसी Workspace उपयोगकर्ता की आवश्यकता नहीं होती है, इसलिए बस जानें कि **एक मान्य उपयोगकर्ता नकल के लिए पर्याप्त और आवश्यक है**।\
|
||||
> हालाँकि, **नकली उपयोगकर्ता के विशेषाधिकारों का उपयोग किया जाएगा**, इसलिए यदि यह सुपर एडमिन है तो आप सब कुछ एक्सेस कर सकेंगे। यदि इसके पास कोई पहुंच नहीं है तो यह बेकार होगा।
|
||||
|
||||
#### [GCP जनरेट डेलीगेशन टोकन](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
यह सरल स्क्रिप्ट **नियुक्त उपयोगकर्ता के रूप में एक OAuth टोकन उत्पन्न करेगी** जिसे आप फिर अन्य Google APIs तक पहुंचने के लिए उपयोग कर सकते हैं, चाहे `gcloud` के साथ हो या बिना:
|
||||
```bash
|
||||
@@ -41,17 +41,17 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
यह एक उपकरण है जो निम्नलिखित चरणों का पालन करके हमले को अंजाम दे सकता है:
|
||||
|
||||
1. **GCP प्रोजेक्ट्स की गणना करें** Resource Manager API का उपयोग करके।
|
||||
2. प्रत्येक प्रोजेक्ट संसाधन पर इटरेट करें, और **GCP सेवा खाता संसाधनों की गणना करें** जिन तक प्रारंभिक IAM उपयोगकर्ता की पहुंच है _GetIAMPolicy_ का उपयोग करके।
|
||||
3. **प्रत्येक सेवा खाता भूमिका पर इटरेट करें**, और लक्षित सेवा खाता संसाधन पर _**serviceAccountKeys.create**_ अनुमति के साथ अंतर्निहित, बुनियादी, और कस्टम भूमिकाएँ खोजें। यह ध्यान रखना चाहिए कि संपादक भूमिका स्वाभाविक रूप से इस अनुमति को रखती है।
|
||||
4. प्रत्येक सेवा खाता संसाधन के लिए एक **नया `KEY_ALG_RSA_2048`** निजी कुंजी बनाएं जो IAM नीति में प्रासंगिक अनुमति के साथ पाया गया है।
|
||||
5. **प्रत्येक नए सेवा खाते पर इटरेट करें और इसके लिए एक `JWT`** **ऑब्जेक्ट** बनाएं जो SA निजी कुंजी क्रेडेंशियल्स और एक OAuth स्कोप से बना है। एक नया _JWT_ ऑब्जेक्ट बनाने की प्रक्रिया **oauth_scopes.txt** सूची से सभी मौजूदा OAuth स्कोप के संयोजनों पर **इटरेट** करेगी, ताकि सभी प्रतिनिधित्व संभावनाओं को खोजा जा सके। सूची **oauth_scopes.txt** को उन सभी OAuth स्कोप के साथ अपडेट किया गया है जो हमने Workspace पहचानियों का दुरुपयोग करने के लिए प्रासंगिक पाया है।
|
||||
6. `_make_authorization_grant_assertion` विधि एक लक्षित कार्यक्षेत्र उपयोगकर्ता, जिसे _subject_ के रूप में संदर्भित किया गया है, को JWTs उत्पन्न करने के लिए घोषित करने की आवश्यकता को प्रकट करती है। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि **DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है**। परिणामस्वरूप, **किसी भी डोमेन उपयोगकर्ता** के लिए JWT बनाना उस डोमेन में सभी पहचानों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है।\
|
||||
इस उपयोगकर्ता को DeleFriend के _config.yaml_ फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह ध्यान रखना महत्वपूर्ण है (फिर से) कि JWTs डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।
|
||||
2. प्रत्येक प्रोजेक्ट संसाधन पर पुनरावृत्ति करें, और **GCP सेवा खाता संसाधनों की गणना करें** जिन तक प्रारंभिक IAM उपयोगकर्ता की पहुंच है _GetIAMPolicy_ का उपयोग करके।
|
||||
3. **प्रत्येक सेवा खाता भूमिका पर पुनरावृत्ति करें**, और लक्षित सेवा खाता संसाधन पर _**serviceAccountKeys.create**_ अनुमति के साथ अंतर्निहित, बुनियादी, और कस्टम भूमिकाएँ खोजें। यह ध्यान रखना चाहिए कि संपादक भूमिका स्वाभाविक रूप से इस अनुमति को रखती है।
|
||||
4. प्रत्येक सेवा खाता संसाधन के लिए **नया `KEY_ALG_RSA_2048`** निजी कुंजी बनाएं जो IAM नीति में प्रासंगिक अनुमति के साथ पाया गया है।
|
||||
5. **प्रत्येक नए सेवा खाते पर पुनरावृत्ति करें और इसके लिए एक `JWT`** **ऑब्जेक्ट** बनाएं जो SA निजी कुंजी क्रेडेंशियल्स और एक OAuth स्कोप से बना होता है। नए _JWT_ ऑब्जेक्ट को बनाने की प्रक्रिया **oauth_scopes.txt** सूची से सभी मौजूदा OAuth स्कोप के संयोजनों पर पुनरावृत्ति करेगी, ताकि सभी प्रतिनिधित्व संभावनाओं को खोजा जा सके। सूची **oauth_scopes.txt** को उन सभी OAuth स्कोप के साथ अपडेट किया गया है जो हमने Workspace पहचानियों का दुरुपयोग करने के लिए प्रासंगिक पाया है।
|
||||
6. `_make_authorization_grant_assertion` विधि एक लक्षित कार्यक्षेत्र उपयोगकर्ता, जिसे _subject_ के रूप में संदर्भित किया गया है, को घोषित करने की आवश्यकता को प्रकट करती है, ताकि DWD के तहत JWT उत्पन्न किए जा सकें। जबकि यह एक विशिष्ट उपयोगकर्ता की आवश्यकता प्रतीत हो सकती है, यह समझना महत्वपूर्ण है कि **DWD एक डोमेन के भीतर हर पहचान को प्रभावित करता है**। परिणामस्वरूप, **किसी भी डोमेन उपयोगकर्ता** के लिए JWT बनाना उस डोमेन में सभी पहचानियों को प्रभावित करता है, जो हमारे संयोजन गणना जांच के अनुरूप है। सीधे शब्दों में कहें, एक मान्य Workspace उपयोगकर्ता आगे बढ़ने के लिए पर्याप्त है।\
|
||||
इस उपयोगकर्ता को DeleFriend के _config.yaml_ फ़ाइल में परिभाषित किया जा सकता है। यदि लक्षित कार्यक्षेत्र उपयोगकर्ता पहले से ज्ञात नहीं है, तो उपकरण GCP प्रोजेक्ट्स पर भूमिकाओं के साथ डोमेन उपयोगकर्ताओं को स्कैन करके मान्य कार्यक्षेत्र उपयोगकर्ताओं की स्वचालित पहचान की सुविधा प्रदान करता है। यह फिर से ध्यान देने योग्य है कि JWT डोमेन-विशिष्ट होते हैं और हर उपयोगकर्ता के लिए उत्पन्न नहीं होते; इसलिए, स्वचालित प्रक्रिया प्रति डोमेन एक अद्वितीय पहचान को लक्षित करती है।
|
||||
7. **प्रत्येक JWT के लिए एक नया बियरर एक्सेस टोकन की गणना करें और टोकन को tokeninfo API के खिलाफ मान्य करें।**
|
||||
|
||||
#### [Gitlab का Python स्क्रिप्ट](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
|
||||
Gitlab ने [यह Python स्क्रिप्ट](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) बनाई है जो दो चीजें कर सकती है - उपयोगकर्ता निर्देशिका को सूचीबद्ध करना और SA क्रेडेंशियल्स और अनुकरण करने के लिए उपयोगकर्ता के साथ एक नया प्रशासनिक खाता बनाना। यहाँ बताया गया है कि आप इसका उपयोग कैसे करेंगे:
|
||||
Gitlab ने [यह Python स्क्रिप्ट](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) बनाई है जो दो चीजें कर सकती है - उपयोगकर्ता निर्देशिका की सूची बनाना और SA क्रेडेंशियल्स और अनुकरण करने के लिए उपयोगकर्ता के साथ एक नया प्रशासनिक खाता बनाना। यहाँ इसका उपयोग कैसे करें:
|
||||
```bash
|
||||
# Install requirements
|
||||
pip install --upgrade --user oauth2client
|
||||
@@ -73,32 +73,32 @@ pip install --upgrade --user oauth2client
|
||||
--domain target-org.com \
|
||||
--account pwned
|
||||
```
|
||||
### एक नई प्रतिनिधित्व बनाएँ (Persistence)
|
||||
### एक नई प्रतिनिधित्व बनाएँ (स्थायीता)
|
||||
|
||||
यह संभव है कि **Domain Wide Delegations की जांच करें** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
|
||||
यह संभव है कि **डोमेन वाइड प्रतिनिधित्व की जांच करें** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
|
||||
|
||||
एक हमलावर जिसके पास **GCP प्रोजेक्ट में सेवा खातों को बनाने की क्षमता** और **GWS के लिए सुपर एडमिन विशेषाधिकार** है, वह एक नई प्रतिनिधित्व बना सकता है जो SAs को कुछ GWS उपयोगकर्ताओं का अनुकरण करने की अनुमति देती है:
|
||||
एक हमलावर जिसके पास **GCP प्रोजेक्ट में सेवा खातों को बनाने की क्षमता** और **GWS के लिए सुपर एडमिन विशेषाधिकार** है, वह कुछ GWS उपयोगकर्ताओं का अनुकरण करने के लिए SAs को अनुमति देने वाला एक नया प्रतिनिधित्व बना सकता है:
|
||||
|
||||
1. **एक नई सेवा खाता और संबंधित कुंजी जोड़ी उत्पन्न करना:** GCP पर, नई सेवा खाता संसाधनों को या तो इंटरैक्टिव रूप से कंसोल के माध्यम से या सीधे API कॉल और CLI उपकरणों का उपयोग करके प्रोग्रामेटिक रूप से उत्पन्न किया जा सकता है। इसके लिए **भूमिका `iam.serviceAccountAdmin`** या किसी भी कस्टम भूमिका की आवश्यकता होती है जिसमें **`iam.serviceAccounts.create`** **अनुमति** हो। एक बार सेवा खाता बन जाने के बाद, हम एक **संबंधित कुंजी जोड़ी** उत्पन्न करने के लिए आगे बढ़ेंगे (**`iam.serviceAccountKeys.create`** अनुमति)।
|
||||
2. **नई प्रतिनिधित्व का निर्माण**: यह समझना महत्वपूर्ण है कि **केवल सुपर एडमिन भूमिका के पास Google Workspace में वैश्विक Domain-Wide प्रतिनिधित्व स्थापित करने की क्षमता है** और Domain-Wide प्रतिनिधित्व **प्रोग्रामेटिक रूप से स्थापित नहीं किया जा सकता,** इसे केवल Google Workspace **कंसोल** के माध्यम से **हाथ से** बनाया और समायोजित किया जा सकता है।
|
||||
- नियम का निर्माण **API controls → Manage Domain-Wide delegation in Google Workspace Admin console** पृष्ठ के तहत पाया जा सकता है।
|
||||
3. **OAuth स्कोप विशेषाधिकार संलग्न करना**: एक नई प्रतिनिधित्व को कॉन्फ़िगर करते समय, Google केवल 2 पैरामीटर की आवश्यकता होती है, क्लाइंट आईडी, जो **GCP सेवा खाता** संसाधन का **OAuth ID** है, और **OAuth स्कोप** जो परिभाषित करता है कि प्रतिनिधित्व को कौन से API कॉल की आवश्यकता है।
|
||||
1. **एक नया सेवा खाता और संबंधित कुंजी जोड़ी उत्पन्न करना:** GCP पर, नए सेवा खाता संसाधनों को या तो कंसोल के माध्यम से इंटरैक्टिव रूप से या सीधे API कॉल और CLI उपकरणों का उपयोग करके प्रोग्रामेटिक रूप से उत्पन्न किया जा सकता है। इसके लिए **भूमिका `iam.serviceAccountAdmin`** या किसी भी कस्टम भूमिका की आवश्यकता होती है जिसमें **`iam.serviceAccounts.create`** **अनुमति** हो। एक बार सेवा खाता बन जाने के बाद, हम एक **संबंधित कुंजी जोड़ी** उत्पन्न करने की प्रक्रिया में आगे बढ़ेंगे (**`iam.serviceAccountKeys.create`** अनुमति)।
|
||||
2. **नए प्रतिनिधित्व का निर्माण**: यह समझना महत्वपूर्ण है कि **केवल सुपर एडमिन भूमिका के पास Google Workspace में वैश्विक डोमेन-वाइड प्रतिनिधित्व स्थापित करने की क्षमता है** और डोमेन-वाइड प्रतिनिधित्व **प्रोग्रामेटिक रूप से स्थापित नहीं किया जा सकता,** इसे केवल Google Workspace **कंसोल** के माध्यम से **हाथ से** बनाया और समायोजित किया जा सकता है।
|
||||
- नियम का निर्माण **API नियंत्रण → Google Workspace Admin कंसोल में डोमेन-वाइड प्रतिनिधित्व प्रबंधित करें** पृष्ठ के तहत पाया जा सकता है।
|
||||
3. **OAuth स्कोप विशेषाधिकार संलग्न करना**: एक नए प्रतिनिधित्व को कॉन्फ़िगर करते समय, Google केवल 2 पैरामीटर की आवश्यकता होती है, क्लाइंट आईडी, जो **GCP सेवा खाता** संसाधन का **OAuth आईडी** है, और **OAuth स्कोप** जो परिभाषित करता है कि प्रतिनिधित्व को कौन से API कॉल की आवश्यकता है।
|
||||
- **OAuth स्कोप की पूरी सूची** [**यहाँ**](https://developers.google.com/identity/protocols/oauth2/scopes) पाई जा सकती है, लेकिन यहाँ एक सिफारिश है: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
|
||||
4. **लक्षित पहचान के पक्ष में कार्य करना:** इस बिंदु पर, हमारे पास GWS में एक कार्यशील प्रतिनिधित्व वस्तु है। अब, **GCP सेवा खाता निजी कुंजी का उपयोग करके, हम API कॉल कर सकते हैं** (OAuth स्कोप पैरामीटर में परिभाषित स्कोप में) इसे सक्रिय करने और **Google Workspace में मौजूद किसी भी पहचान के पक्ष में कार्य करने के लिए।** जैसा कि हमने सीखा, सेवा खाता अपनी आवश्यकताओं के अनुसार और REST API अनुप्रयोगों के लिए उसके पास मौजूद अनुमति के अनुसार एक्सेस टोकन उत्पन्न करेगा।
|
||||
- इस प्रतिनिधित्व का उपयोग करने के लिए कुछ **उपकरणों** के लिए **पिछले अनुभाग** की जांच करें।
|
||||
|
||||
#### क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व
|
||||
|
||||
OAuth SA ID वैश्विक है और इसका उपयोग **क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व** के लिए किया जा सकता है। क्रॉस-वैश्विक प्रतिनिधित्व को रोकने के लिए कोई प्रतिबंध लागू नहीं किया गया है। सरल शब्दों में, **विभिन्न GCP संगठनों के सेवा खातों का उपयोग अन्य Workspace संगठनों पर डोमेन-व्यापी प्रतिनिधित्व कॉन्फ़िगर करने के लिए किया जा सकता है।** इसका परिणाम होगा कि **Workspace के लिए केवल सुपर एडमिन पहुंच की आवश्यकता है**, और न कि उसी GCP खाते तक पहुंच की, क्योंकि प्रतिकूलता अपने व्यक्तिगत रूप से नियंत्रित GCP खाते पर सेवा खातों और निजी कुंजी बना सकता है।
|
||||
OAuth SA ID वैश्विक है और इसका उपयोग **क्रॉस-ऑर्गनाइजेशनल प्रतिनिधित्व** के लिए किया जा सकता है। क्रॉस-ग्लोबल प्रतिनिधित्व को रोकने के लिए कोई प्रतिबंध लागू नहीं किया गया है। सरल शब्दों में, **विभिन्न GCP संगठनों के सेवा खातों का उपयोग अन्य Workspace संगठनों पर डोमेन-वाइड प्रतिनिधित्व कॉन्फ़िगर करने के लिए किया जा सकता है।** इसका परिणाम होगा कि **Workspace के लिए केवल सुपर एडमिन पहुंच की आवश्यकता है**, और उसी GCP खाते तक पहुंच की आवश्यकता नहीं है, क्योंकि प्रतिकूल व्यक्ति अपने व्यक्तिगत रूप से नियंत्रित GCP खाते पर सेवा खातों और निजी कुंजी बना सकता है।
|
||||
|
||||
### Workspace को सूचीबद्ध करने के लिए एक प्रोजेक्ट बनाना
|
||||
|
||||
**डिफ़ॉल्ट** रूप से Workspace **उपयोगकर्ताओं** को **नए प्रोजेक्ट बनाने** की अनुमति होती है, और जब एक नया प्रोजेक्ट बनाया जाता है तो **निर्माता को उस पर मालिक की भूमिका मिलती है।**
|
||||
|
||||
इसलिए, एक उपयोगकर्ता **एक प्रोजेक्ट बना सकता है**, **APIs** को सक्षम कर सकता है ताकि वह अपने नए प्रोजेक्ट में Workspace को सूचीबद्ध कर सके और इसे **सूचीबद्ध** करने की कोशिश कर सके।
|
||||
इसलिए, एक उपयोगकर्ता **एक प्रोजेक्ट बना सकता है**, अपने नए प्रोजेक्ट में Workspace को सूचीबद्ध करने के लिए **APIs** को **सक्षम** कर सकता है और इसे **सूचीबद्ध** करने का प्रयास कर सकता है।
|
||||
|
||||
> [!CAUTION]
|
||||
> एक उपयोगकर्ता के लिए Workspace को सूचीबद्ध करने के लिए, उसे पर्याप्त Workspace अनुमतियाँ भी चाहिए (हर उपयोगकर्ता निर्देशिका को सूचीबद्ध करने में सक्षम नहीं होगा)।
|
||||
> एक उपयोगकर्ता के लिए Workspace को सूचीबद्ध करने के लिए, उसे पर्याप्त Workspace अनुमतियों की भी आवश्यकता होती है (हर उपयोगकर्ता निर्देशिका को सूचीबद्ध करने में सक्षम नहीं होगा)।
|
||||
```bash
|
||||
# Create project
|
||||
gcloud projects create <uniq-projec-name> --name=proj-name
|
||||
@@ -124,10 +124,10 @@ gcloud beta identity groups preview --customer <org-cust-id>
|
||||
|
||||
### Gcloud क्रेडेंशियल्स का दुरुपयोग
|
||||
|
||||
आप लॉगिन के लिए `gcloud` प्रवाह के बारे में और जानकारी पा सकते हैं:
|
||||
आप लॉगिन के लिए `gcloud` प्रवाह के बारे में अधिक जानकारी पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
जैसा कि वहां समझाया गया है, gcloud स्कोप **`https://www.googleapis.com/auth/drive`** का अनुरोध कर सकता है जो एक उपयोगकर्ता को उपयोगकर्ता के ड्राइव तक पहुंचने की अनुमति देगा।\
|
||||
@@ -140,7 +140,7 @@ gcloud auth login --enable-gdrive-access
|
||||
<figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
> [!WARNING]
|
||||
> इसलिए, अगली बार जब उपयोगकर्ता लॉग इन करेगा, तो वह **ड्राइव तक पहुंच के साथ एक टोकन बनाएगा** जिसका उपयोग हमलावर ड्राइव तक पहुंच प्राप्त करने के लिए कर सकता है। स्पष्ट रूप से, ब्राउज़र यह संकेत देगा कि उत्पन्न टोकन को ड्राइव तक पहुंच प्राप्त होगी, लेकिन चूंकि उपयोगकर्ता स्वयं **`gcloud auth login`** करेगा, इसलिए वह शायद **कुछ भी संदेह नहीं करेगा।**
|
||||
> इसलिए, अगली बार जब उपयोगकर्ता लॉग इन करेगा, तो वह **ड्राइव तक पहुंच के साथ एक टोकन बनाएगा** जिसका उपयोग हमलावर ड्राइव तक पहुंच प्राप्त करने के लिए कर सकता है। स्पष्ट रूप से, ब्राउज़र यह संकेत देगा कि उत्पन्न टोकन ड्राइव तक पहुंच रखेगा, लेकिन चूंकि उपयोगकर्ता स्वयं **`gcloud auth login`** करेगा, वह शायद **कुछ भी संदेह नहीं करेगा।**
|
||||
>
|
||||
> ड्राइव फ़ाइलों की सूची बनाने के लिए: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**
|
||||
|
||||
|
||||
@@ -39,22 +39,22 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
## Google Calendar Phishing
|
||||
|
||||
आप **एक कैलेंडर इवेंट** बना सकते हैं और जितने भी ईमेल पते हैं उन सभी को जोड़ सकते हैं जिनका आप हमला कर रहे हैं। इस कैलेंडर इवेंट को **वर्तमान समय से 5 या 15 मिनट** में शेड्यूल करें। इवेंट को वैध दिखाएं और **एक टिप्पणी और एक शीर्षक डालें जो यह संकेत करता है कि उन्हें कुछ पढ़ना है** (साथ में **फिशिंग लिंक**).
|
||||
आप **एक कैलेंडर इवेंट** बना सकते हैं और जितने भी ईमेल पते हैं उन सभी को जोड़ सकते हैं जिनका आप हमला कर रहे हैं। इस कैलेंडर इवेंट को **वर्तमान समय से 5 या 15 मिनट** में शेड्यूल करें। इवेंट को वैध दिखाने के लिए बनाएं और **एक टिप्पणी और एक शीर्षक डालें जो यह संकेत करे कि उन्हें कुछ पढ़ना है** (साथ में **फिशिंग लिंक**).
|
||||
|
||||
यह वह चेतावनी है जो ब्राउज़र में "Firing People" शीर्षक के साथ दिखाई देगी, इसलिए आप एक अधिक फिशिंग जैसा शीर्षक सेट कर सकते हैं (और यहां तक कि अपने ईमेल से जुड़े नाम को भी बदल सकते हैं)।
|
||||
यह वह चेतावनी है जो ब्राउज़र में "Firing People" मीटिंग शीर्षक के साथ दिखाई देगी, इसलिए आप एक अधिक फिशिंग जैसा शीर्षक सेट कर सकते हैं (और यहां तक कि अपने ईमेल से जुड़े नाम को भी बदल सकते हैं)।
|
||||
|
||||
<figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
इसे कम संदिग्ध दिखाने के लिए:
|
||||
|
||||
- इसे इस तरह सेट करें कि **प्राप्तकर्ता अन्य आमंत्रित लोगों को न देख सकें**
|
||||
- **ईवेंट के बारे में सूचित करने वाले ईमेल न भेजें**। फिर, लोग केवल 5 मिनट में एक बैठक के बारे में अपनी चेतावनी देखेंगे और उन्हें उस लिंक को पढ़ने की आवश्यकता है।
|
||||
- स्पष्ट रूप से API का उपयोग करके आप सेट कर सकते हैं कि **लोगों ने** ईवेंट को **स्वीकृत** किया है और यहां तक कि उनके पक्ष में **टिप्पणियाँ भी बना सकते हैं**।
|
||||
- **ईवेंट के बारे में सूचनाएं न भेजें**। फिर, लोग केवल 5 मिनट में एक मीटिंग के बारे में अपनी चेतावनी देखेंगे और उन्हें उस लिंक को पढ़ने की आवश्यकता होगी।
|
||||
- स्पष्ट रूप से API का उपयोग करके आप **सत्य** सेट कर सकते हैं कि **लोगों ने** इवेंट को **स्वीकृत** किया है और यहां तक कि उनके पक्ष में **टिप्पणियाँ भी बना सकते हैं**।
|
||||
|
||||
## App Scripts Redirect Phishing
|
||||
|
||||
यह संभव है कि [https://script.google.com/](https://script.google.com/) में एक स्क्रिप्ट बनाई जाए और **इसे एक वेब एप्लिकेशन के रूप में उजागर किया जाए जो सभी के लिए सुलभ हो** जो वैध डोमेन **`script.google.com`** का उपयोग करेगा।\
|
||||
कुछ कोड के साथ जैसे कि निम्नलिखित, एक हमलावर इस पृष्ठ में मनमाने सामग्री को लोड करने के लिए स्क्रिप्ट बना सकता है बिना डोमेन तक पहुंच को रोके:
|
||||
इसके साथ कुछ कोड जैसे निम्नलिखित एक हमलावर को इस पृष्ठ में मनमाने सामग्री को लोड करने के लिए स्क्रिप्ट बनाने की अनुमति दे सकता है बिना डोमेन तक पहुंच को रोके:
|
||||
```javascript
|
||||
function doGet() {
|
||||
return HtmlService.createHtmlOutput(
|
||||
@@ -71,7 +71,7 @@ return HtmlService.createHtmlOutput(
|
||||
|
||||
## ऐप स्क्रिप्ट OAuth फ़िशिंग
|
||||
|
||||
ऐसे ऐप स्क्रिप्ट बनाना संभव है जो दस्तावेज़ों से जुड़े होते हैं ताकि पीड़ित के OAuth टोकन तक पहुँच प्राप्त करने की कोशिश की जा सके, अधिक जानकारी के लिए देखें:
|
||||
ऐप स्क्रिप्ट बनाना संभव है जो दस्तावेज़ों से जुड़े होते हैं ताकि पीड़ित के OAuth टोकन तक पहुँच प्राप्त करने की कोशिश की जा सके, अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
gws-app-scripts.md
|
||||
@@ -79,26 +79,26 @@ gws-app-scripts.md
|
||||
|
||||
## OAuth ऐप्स फ़िशिंग
|
||||
|
||||
पिछले किसी भी तकनीक का उपयोग उपयोगकर्ता को एक **Google OAuth एप्लिकेशन** तक पहुँचने के लिए किया जा सकता है जो उपयोगकर्ता से कुछ **एक्सेस** **अनुरोध** करेगा। यदि उपयोगकर्ता **स्रोत** पर **विश्वास** करता है तो वह **ऐप्लिकेशन** पर भी **विश्वास** कर सकता है (भले ही यह उच्च विशेषाधिकार प्राप्त अनुमतियों के लिए पूछ रहा हो)।
|
||||
पिछले किसी भी तकनीक का उपयोग उपयोगकर्ता को एक **Google OAuth एप्लिकेशन** तक पहुँचने के लिए किया जा सकता है जो उपयोगकर्ता से कुछ **एक्सेस** **अनुरोध** करेगा। यदि उपयोगकर्ता **स्रोत** पर **विश्वास** करता है तो वह **एप्लिकेशन** पर भी **विश्वास** कर सकता है (भले ही यह उच्च विशेषाधिकार प्राप्त अनुमतियों के लिए पूछ रहा हो)।
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि Google कई मामलों में एक भद्दा प्रॉम्प्ट प्रस्तुत करता है जो चेतावनी देता है कि एप्लिकेशन अविश्वसनीय है और Workspace प्रशासक यहां तक कि लोगों को OAuth एप्लिकेशन स्वीकार करने से रोक सकते हैं।
|
||||
|
||||
**Google** ऐसे एप्लिकेशन बनाने की अनुमति देता है जो कई **Google सेवाओं** के साथ **उपयोगकर्ताओं की ओर से बातचीत** कर सकते हैं: Gmail, Drive, GCP...
|
||||
**Google** उपयोगकर्ताओं की ओर से कई **Google सेवाओं** के साथ **संवाद करने** के लिए एप्लिकेशन बनाने की अनुमति देता है: Gmail, Drive, GCP...
|
||||
|
||||
जब किसी एप्लिकेशन को **अन्य उपयोगकर्ताओं की ओर से कार्य करने** के लिए बनाया जाता है, तो डेवलपर को **GCP के अंदर एक OAuth ऐप** बनाना होगा और उन स्कोप (अनुमतियों) को निर्दिष्ट करना होगा जिनकी ऐप को उपयोगकर्ताओं के डेटा तक पहुँचने की आवश्यकता है।\
|
||||
जब एक **उपयोगकर्ता** उस **ऐप्लिकेशन** का **उपयोग** करना चाहता है, तो उन्हें **स्वीकृति** देने के लिए **प्रॉम्प्ट** किया जाएगा कि एप्लिकेशन उनके डेटा तक पहुँच प्राप्त करेगा जो स्कोप में निर्दिष्ट है।
|
||||
जब एक **उपयोगकर्ता** उस **एप्लिकेशन** का **उपयोग** करना चाहता है, तो उन्हें **स्वीकृति** देने के लिए **प्रॉम्प्ट** किया जाएगा कि एप्लिकेशन उनके डेटा तक पहुँच प्राप्त करेगा जो स्कोप में निर्दिष्ट है।
|
||||
|
||||
यह **फिशिंग** गैर-तकनीकी उपयोगकर्ताओं को **संवेदनशील जानकारी तक पहुँचने वाले एप्लिकेशन** का उपयोग करने के लिए एक बहुत ही आकर्षक तरीका है क्योंकि वे परिणामों को नहीं समझ सकते। हालाँकि, संगठनों के खातों में, इसे होने से रोकने के तरीके हैं।
|
||||
|
||||
### अविश्वसनीय ऐप प्रॉम्प्ट
|
||||
|
||||
जैसा कि उल्लेख किया गया था, Google हमेशा उपयोगकर्ता को **अनुमतियों को स्वीकार करने के लिए प्रॉम्प्ट** करेगा जो वे ऐप्लिकेशन को अपनी ओर से दे रहे हैं। हालाँकि, यदि एप्लिकेशन को **खतरनाक** माना जाता है, तो Google पहले **प्रॉम्प्ट** दिखाएगा जो यह संकेत देगा कि यह **खतरनाक** है और उपयोगकर्ता के लिए ऐप को अनुमतियाँ देने में **अधिक कठिनाई** पैदा करेगा।
|
||||
जैसा कि उल्लेख किया गया था, Google हमेशा उपयोगकर्ता को **अनुमतियों को स्वीकार करने के लिए प्रॉम्प्ट** करेगा जो वे एप्लिकेशन को अपनी ओर से दे रहे हैं। हालाँकि, यदि एप्लिकेशन को **खतरनाक** माना जाता है, तो Google पहले **प्रॉम्प्ट** दिखाएगा जो यह संकेत देगा कि यह **खतरनाक** है और उपयोगकर्ता के लिए ऐप को अनुमतियाँ देने में **अधिक कठिनाई** पैदा करेगा।
|
||||
|
||||
यह प्रॉम्प्ट उन ऐप्स में दिखाई देता है:
|
||||
|
||||
- कोई भी स्कोप जो निजी डेटा (Gmail, Drive, GCP, BigQuery...) तक पहुँच सकता है
|
||||
- 100 से कम उपयोगकर्ताओं वाले ऐप्स (100 से अधिक उपयोगकर्ताओं वाले ऐप्स के लिए अविश्वसनीय प्रॉम्प्ट दिखाना रोकने के लिए एक समीक्षा प्रक्रिया भी आवश्यक है)
|
||||
- 100 से कम उपयोगकर्ताओं वाले ऐप्स (100 से अधिक उपयोगकर्ताओं वाले ऐप्स के लिए एक समीक्षा प्रक्रिया भी आवश्यक है ताकि अविश्वसनीय प्रॉम्प्ट दिखाना बंद किया जा सके)
|
||||
|
||||
### दिलचस्प स्कोप
|
||||
|
||||
@@ -113,12 +113,12 @@ gws-app-scripts.md
|
||||
|
||||
1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) पर जाएं और सहमति स्क्रीन को कॉन्फ़िगर करने पर क्लिक करें।
|
||||
2. फिर, आपसे पूछा जाएगा कि **उपयोगकर्ता प्रकार** **आंतरिक** (केवल आपके संगठन के लोगों के लिए) है या **बाहरी**। उस विकल्प का चयन करें जो आपकी आवश्यकताओं के अनुसार हो
|
||||
- आंतरिक तब दिलचस्प हो सकता है जब आपने पहले ही संगठन के एक उपयोगकर्ता को समझौता कर लिया है और आप दूसरे को फ़िश करने के लिए यह ऐप बना रहे हैं।
|
||||
3. ऐप को एक **नाम** दें, एक **समर्थन ईमेल** (ध्यान दें कि आप खुद को थोड़ा अधिक गुमनाम बनाने के लिए एक गूगल ग्रुप ईमेल सेट कर सकते हैं), एक **लोगो**, **अधिकृत डोमेन** और **अपडेट्स** के लिए एक और **ईमेल**।
|
||||
- आंतरिक तब दिलचस्प हो सकता है जब आपने पहले ही संगठन के एक उपयोगकर्ता को समझौता कर लिया है और आप इस ऐप को दूसरे को फिश करने के लिए बना रहे हैं।
|
||||
3. ऐप को एक **नाम** दें, एक **समर्थन ईमेल** (ध्यान दें कि आप खुद को थोड़ा और अनाम करने के लिए एक गूगल ग्रुप ईमेल सेट कर सकते हैं), एक **लोगो**, **अधिकृत डोमेन** और **अपडेट्स** के लिए एक और **ईमेल** दें।
|
||||
4. **OAuth स्कोप** का **चयन** करें।
|
||||
- यह पृष्ठ गैर-संवेदनशील अनुमतियों, संवेदनशील अनुमतियों और प्रतिबंधित अनुमतियों में विभाजित है। हर बार जब आप एक नई अनुमति जोड़ते हैं, तो यह उसकी श्रेणी में जोड़ी जाती है। अनुरोधित अनुमतियों के आधार पर उपयोगकर्ता को विभिन्न प्रॉम्प्ट दिखाई देंगे जो यह संकेत देते हैं कि ये अनुमतियाँ कितनी संवेदनशील हैं।
|
||||
- दोनों **`admin.directory.user.readonly`** और **`cloud-platform`** संवेदनशील अनुमतियाँ हैं।
|
||||
5. **परीक्षण उपयोगकर्ताओं को जोड़ें।** जब तक ऐप की स्थिति परीक्षण में है, केवल ये उपयोगकर्ता ऐप तक पहुँच पाने में सक्षम होंगे इसलिए सुनिश्चित करें कि **उस ईमेल को जोड़ें जिसे आप फ़िश करने जा रहे हैं**।
|
||||
5. **परीक्षण उपयोगकर्ताओं को जोड़ें।** जब तक ऐप की स्थिति परीक्षण में है, केवल ये उपयोगकर्ता ऐप तक पहुँचने में सक्षम होंगे इसलिए सुनिश्चित करें कि **उस ईमेल को जोड़ें जिसे आप फिश करने जा रहे हैं**।
|
||||
|
||||
अब हम **पिछले बनाए गए OAuth क्लाइंट आईडी** का उपयोग करके **वेब एप्लिकेशन के लिए क्रेडेंशियल्स प्राप्त करें**:
|
||||
|
||||
@@ -135,14 +135,14 @@ cd gcp_oauth_phishing_example
|
||||
pip install flask requests google-auth-oauthlib
|
||||
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
|
||||
```
|
||||
**`http://localhost:8000`** पर जाएं, Google के साथ लॉगिन बटन पर क्लिक करें, आपको इस तरह का एक संदेश **प्रदर्शित** किया जाएगा:
|
||||
**`http://localhost:8000`** पर जाएं और Google के साथ लॉगिन बटन पर क्लिक करें, आपको इस तरह का एक संदेश **प्रदर्शित** किया जाएगा:
|
||||
|
||||
<figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
ऐप्लिकेशन **एक्सेस और रिफ्रेश टोकन** दिखाएगा जिसे आसानी से उपयोग किया जा सकता है। **इन टोकनों का उपयोग कैसे करें, इसके बारे में अधिक जानकारी के लिए देखें**:
|
||||
ऐप्लिकेशन **एक्सेस और रिफ्रेश टोकन** दिखाएगा जिसे आसानी से उपयोग किया जा सकता है। **इन टोकनों का उपयोग कैसे करें, इसकी अधिक जानकारी के लिए देखें**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### `glcoud` का उपयोग करना
|
||||
|
||||
Reference in New Issue
Block a user