gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 14:47:17 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c

Browse Source
This commit is contained in:
Translator
2026-07-06 15:54:51 +00:00
parent d94ccc1f64
commit 864abda729
2 changed files with 272 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-ci-cd/argocd-security.md
+219
View File
@@ -0,0 +1,219 @@
# Argo CD Güvenliği
{{#include ../banners/hacktricks-training.md}}
## Temel Bilgiler
[Argo CD](https://argo-cd.readthedocs.io/) Kubernetes için bir GitOps sürekli teslim platformudur. Git repository’lerini izler, Helm, Kustomize, Jsonnet veya config management plugins gibi araçlarla Kubernetes manifest’lerini oluşturur ve canlı cluster durumunu Git’te saklanan istenen durumla eşleştirir.
Bir attacker açısından Argo CD’yi **Kubernetes credentials’ı olan bir deployment engine** olarak değerlendirin. Başarılı bir Argo CD compromise şunlara yol açabilir:
- Private Git repository’lerine ve repository credentials’ına erişim.
- Argo CD tarafından kullanılan Kubernetes cluster secrets’ına erişim.
- `argocd-repo-server` içinde manifest generation code execution.
- Trusted Git repository’leri, Argo CD applications veya cache manipulation üzerinden yetkisiz Kubernetes object deployment.
## Mimari ve İlginç Bileşenler
Yaygın Kubernetes object’leri ve services:
```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
```
İlginç services:
- **`argocd-server`**: public API, web UI, CLI API, authentication ve authorization.
- **`argocd-application-controller`**: desired ve live state'i karşılaştırır, ardından resources'ları Kubernetes'e uygular.
- **`argocd-repo-server`**: repositories'leri clone eder, Git data'yı cache'ler ve manifests üretmek için Helm/Kustomize/Jsonnet/plugins çalıştırır. Default gRPC portu **8081**'dir.
- **`argocd-redis`**: application, manifest ve Git reference data için cache. Default Redis portu **6379**'dur.
- **`argocd-applicationset-controller`**: Git, SCM, clusters ve pull requests gibi generators'lardan Argo CD `Application` objects üretir.
Compromised bir pod veya internal network segmentinden, internal reachability'yi kontrol edin:
```bash
nc -vz <argocd-server> 443
nc -vz <argocd-repo-server> 8081
nc -vz <argocd-redis> 6379
```
## Public API / UI Saldırıları
Eğer Argo CD credentials veya exposed bir instance varsa, normal API surface ile başlayın:
```bash
argocd login <argocd-server>
argocd account get-user-info
argocd account list
argocd proj list
argocd app list
argocd repo list
argocd cluster list
argocd admin settings rbac can <subject> <action> <resource> <object>
```
Faydalı attack paths:
- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin ayarları veya sync options değiştirerek Argo CD’nin attacker-controlled manifests deploy etmesini sağlamak.
- **Project misconfiguration**: `AppProject` nesneleri geniş `sourceRepos`, geniş `destinations`, güvensiz `clusterResourceWhitelist` veya zayıf namespace restrictions içerebilir.
- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys ve tokens, trusted repos’a push yapmayı veya malicious dependencies eklemeyi mümkün kılabilir.
- **Cluster credential abuse**: cluster secrets, Argo CD’nin target clusters içine deploy etmek için kullandığı bearer tokens veya exec-provider configuration içerebilir.
- **Local admin / project tokens**: uzun ömürlü Argo CD tokens, revoke edilmedikçe veya expire olmadıkça API üzerinden yeniden kullanılabilir.
Cluster read access olduğunda Kubernetes’ten configuration enumerate edin:
```bash
kubectl get applications.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
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
Eğer Argo CD tarafından trusted olan bir repository’ye push yapabiliyorsanız, genellikle neyin deployed edileceğini etkileyebilirsiniz. Etki, `AppProject` sınırlarına ve application controller tarafından kullanılan service account yetkilerine bağlıdır.
Yaygın payload konumları:
- Bir application path altında raw Kubernetes YAML.
- Helm chart templates ve `values.yaml`.
- Kustomize overlays, remote bases ve generators.
- Jsonnet veya config management plugin girişi.
- `Application` objects oluşturan veya güncelleyen ApplicationSet generator dosyaları.
App’in automated sync, pruning, self-heal, sync windows veya manual approvals kullanıp kullanmadığını kontrol edin:
```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'
```
## Doğrudan `argocd-repo-server` Abuse
Genel Argo CD API'nin tek attack surface olduğunu varsaymayın. Dahili Argo CD bileşenleri, `argocd-repo-server` ile gRPC üzerinden iletişim kurar. Eğer arbitrary pod'lar repo-server'a erişebiliyorsa, attacker-controlled dahili istekler normalde `argocd-server` tarafından enforced edilen kontrolleri bypass edebilir.
Practical checks:
```bash
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
```
İlginç işaretler:
- repo-server gRPC endpoint'ine non-Argo CD pod'larından erişilebiliyor.
- NetworkPolicies yok veya sadece allow-list egress var, ingress engellenmiyor.
- repo-server, custom config management plugins, decryption tools veya birden fazla tenant'tan repository content'e erişebiliyor.
- Redis, non-Argo CD pod'larından erişilebilir; credentials mevcutsa veya gerekmezse cache inspection ya da tampering'e izin verir.
## Kustomize Options üzerinden Authentication gerektirmeyen Repo-Server RCE
Temmuz 2026'da Synacktiv, bir attacker internal gRPC service'e ulaşabildiğinde Argo CD'nin `repo-server` bileşeninde authentication gerektirmeyen bir code execution chain açıkladı. Attack, `/repository.RepoServerService/GenerateManifest`'e doğrudan erişimi ve attacker-controlled `KustomizeOptions` kullanımını kötüye kullanır.
Tehlikeli primitive, repo-server'ı attacker-controlled repository content'i clone etmeye zorlamak ve Helm support ile Kustomize çalıştırmaktır:
```bash
kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
```
Helm processing'i tetiklemek için gereken minimal malicious Kustomize girdisi:
```yaml
helmCharts:
- name: pwn
version: 0.0.1
```
Neden bu çalışır:
- `argocd-repo-server` render etmeden önce repository’yi clone eder.
- `--helm-command ./payload.sh`, clone edilen repository’ye göre resolve edilir.
- Attacker, rendered repository ve Kustomize build options üzerinde control sağlayabiliyorsa, code execution için shell metacharacter injection gerekmez.
Synacktiv’in 1 Temmuz 2026 disclosure zamanında, issue için resmi bir fix veya CVE olmadığını bildirdiler. Bunu önce bir network-exposure issue olarak değerlendirin: exploitation, internal repo-server gRPC portuna erişilebilirlik gerektirir.
## Redis Cache Poisoning to Deploy Manifests
`argocd-repo-server` içinde code execution’dan sonra veya valid credentials ile Redis’e direct access sonrası, Redis-backed cache entries’yi inspect edin. Argo CD genellikle gzip-compressed JSON values store eder.
İlginç 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 tarafından açıklanan cache poisoning saldırısı iki durum bilgisini kötüye kullanır:
1. İlgili `mfst|...` manifest cache girdisini, saldırgan tarafından kontrol edilen bir Kubernetes manifesti içerecek şekilde değiştirin.
2. İlgili `git-refs|...` eşlemesini değiştirin; böylece Argo CD branch’in taşındığını düşünür ve ardından cached revision’a geri reconcile eder.
Etkisi:
- Auto Sync etkinse, Argo CD poisoned cached manifesti otomatik olarak uygulayabilir.
- Auto Sync olmadan da, bir kullanıcı application’ı manuel olarak sync ettiğinde payload yine uygulanabilir.
- Nihai etki, hedef application’ın destination’ı ve Argo CD’ye उपलब्ध Kubernetes permissions ile sınırlıdır.
## ApplicationSet Attacks
ApplicationSet özellikle hassastır çünkü generator output’undan `Application` objects oluşturur veya günceller.
Review:
```bash
kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
```
İlginç patterns:
- app names, paths, projects veya destinations kontrol eden attacker-writable dosyaları okuyan Git generators.
- Güvenilmeyen contributors’ın generated applications üzerinde etki edebildiği public repositories için pull request generators.
- Geniş destination clusters/namespaces'e izin veren template fields.
- `sourceRepos: ["*"]` veya geniş `destinations`'a izin veren AppProjects.
- automated sync ve pruning miras alan generated applications.
## Post-Exploitation
Bir Argo CD pod shell’inden, öncelik verin:
```bash
env
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'
```
Faydalı hedefler:
- `REDIS_PASSWORD` veya Redis TLS/client materyalini çal.
- Mount edilmiş secrets veya Argo CD Kubernetes secrets içinden repository credentials çıkar.
- Argo CD tarafından kullanılan cluster credentials’ı belirle.
- Enjekte edilmiş secrets içerebilecek generated manifests ve plugin output’u oku.
- Custom plugins, SOPS, Helm secrets, Vault plugins veya cloud CLIs’in decryption keys ve cloud credentials açığa çıkarıp çıkarmadığını kontrol et.
## Tespit & Sertleştirme
Önemli kontroller:
- `argocd-repo-server` port **8081** ve Redis port **6379** erişimini, sadece beklenen Argo CD bileşenleri ulaşabilecek şekilde NetworkPolicies ile kısıtla.
- Helm deployments içinde, network policies’nin gerçekten oluşturulduğunu doğrula. Argo CD Helm chart değerleri historically component network policy creation’ı disabled olarak varsayılan yapmıştır.
- `argocd-server`’ı authenticated entry point olarak tut. Internal services rastgele workloads tarafından erişilebilir olmamalı.
- Kullanılmayan config management tools ve plugins’i devre dışı bırak.
- `AppProject` `sourceRepos`, `destinations`, namespace permissions ve cluster-scoped resources erişimini kısıtla.
- Düşük yetkili bir Argo CD kullanıcısının yeniden kullanılmasına neden olabileceği geniş repository credentials saklamaktan kaçın.
- Repo-server requests, Kustomize build options, plugin executions, Redis writes ve `mfst|` / `git-refs|` keys’e beklenmeyen erişimi izle.
- Compromise sonrası Argo CD local users, project tokens, repository credentials ve cluster credentials’ı rotate et.
Faydalı komutlar:
```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
```
## CodeQL'de Static Analysis Notu: Typed API Requests
gRPC/REST handler'ları kullanan Go servislerinde, ham input typed request objects içine unmarshaled edildikten sonra default CodeQL remote sources akışları kaçırabilir. Argo CD tarzı servisler için faydalı bir model şudur:
- `Server` veya `Service` gibi receiver type.
- İlk parametre `context.Context`.
- İkinci parametre typed bir request object.
O ikinci parametreyi remote source olarak modelleyin ve `exec.Command` / `exec.CommandContext` argümanları için custom sink'ler ekleyin. Bu, internal API request alanlarından command execution yardımcılarına giden akışları bulmaya yardımcı olur.
## 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)
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+53 -52
View File
@@ -6,7 +6,7 @@
## VCS
VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **source code’larını yönetmesine** olanak tanır. En yaygın olanı **git**’tir ve şirketlerin bunu genellikle aşağıdaki **platformlardan** birinde kullandığını görürsünüz:
VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **source code'larını yönetmesine** olanak sağlar. En yaygın olanı **git**'tir ve şirketlerin bunu genellikle aşağıdaki **platformlardan** birinde kullandığını görürsünüz:
- Github
- Gitlab
@@ -18,39 +18,39 @@ VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin
## CI/CD Pipelines
CI/CD pipelines, geliştiricilerin uygulamaları build etmek, test etmek ve deploy etmek dahil çeşitli amaçlar için **code execution’ı otomatikleştirmesine** olanak tanır. Bu otomatik iş akışları, code pushes, pull requests veya scheduled tasks gibi belirli eylemlerle **tetiklenir**. Development sürecini production’a kadar sadeleştirmek için faydalıdırlar.
CI/CD pipelines, geliştiricilerin uygulamaları build etmek, test etmek ve deploy etmek dahil olmak üzere çeşitli amaçlarla **code execution'ı otomatikleştirmesine** olanak sağlar. Bu otomatik iş akışları, code push'ları, pull request'ler veya planlanmış görevler gibi belirli eylemlerle **tetiklenir**. Development'tan production'a giden süreci sadeleştirmek için kullanışlıdırlar.
Ancak, bu sistemlerin **bir yerde çalıştırılması** gerekir ve genellikle code deploy etmek veya sensitive information’a erişmek için **privileged credentials** ile çalıştırılırlar.
Ancak bu sistemlerin **bir yerde çalıştırılması** gerekir ve genellikle code deploy etmek veya hassas bilgilere erişmek için **privileged credentials** ile çalışırlar.
## VCS Pentesting Methodology
> [!NOTE]
> Bazı VCS platformları bu bölüm için pipeline oluşturulmasına izin verse de, burada yalnızca source code kontrolüne yönelik olası saldırıları analiz edeceğiz.
> Bazı VCS platformları bu bölüm için pipeline oluşturulmasına izin verse de burada yalnızca source code kontrolüne yönelik olası saldırıları analiz edeceğiz.
Projenizin source code’unu barındıran platformlar sensitive information içerir ve insanların bu platform içinde verilen permissions konusunda çok dikkatli olması gerekir. Bunlar, attacker’ın kötüye kullanabileceği VCS platformları genelindeki bazı yaygın problemlerdir:
Projenizin source code'unu barındıran platformlar hassas bilgiler içerir ve insanların bu platform içinde verilen izinlere karşı çok dikkatli olması gerekir. Bunlar, attacker'ın istismar edebileceği VCS platformlarındaki bazı yaygın sorunlardır:
- **Leaks**: Eğer code’unuz commit’lerde leaks içeriyorsa ve attacker repo’ya erişebiliyorsa (çünkü public’tir ya da erişimi vardır), leaks’i keşfedebilir.
- **Access**: Eğer bir attacker VCS platformu içindeki bir account’a **erişebilirse**, **daha fazla görünürlük ve permission** elde edebilir.
- **Leaks**: Eğer code'unuz commit'lerde leak içeriyorsa ve attacker repo'ya erişebiliyorsa (public olduğu için ya da erişimi olduğu için), leak'leri keşfedebilir.
- **Access**: Eğer attacker VCS platformu içindeki bir account'a **erişebilirse**, **daha fazla görünürlük ve izin** elde edebilir.
- **Register**: Bazı platformlar dış kullanıcıların sadece account oluşturmasına izin verir.
- **SSO**: Bazı platformlar kullanıcıların register olmasına izin vermez, ancak geçerli bir SSO ile herkesin erişmesine izin verir (örneğin attacker kendi github account’unu kullanabilir).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... bir kullanıcının bir repo’ya erişmek için bir şekilde çalabileceği birçok token türü vardır.
- **Webhooks**: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünmeyen secrets ile **korunmuyorsa**, bir **attacker bunları kötüye kullanabilir**.
- Eğer secret yoksa, attacker üçüncü taraf platformun webhook’unu kötüye kullanabilir
- Eğer secret URL içindeyse, aynı şey olur ve attacker secret’a da sahip olur
- **Code compromise:** Eğer kötü niyetli bir aktörün repo’lar üzerinde bir tür **write** erişimi varsa, **zararlı code enjekte etmeyi** deneyebilir. Başarılı olmak için **branch protections’ı aşması** gerekebilir. Bu eylemler mid içinde farklı hedeflerle yapılabilir:
- main branch’i ele geçirerek **production’ı ele geçirmek**.
- main (veya diğer branch’ler)i ele geçirerek **developer makinelerini ele geçirmek** (çünkü genellikle makinelerinde repo içinde test, terraform veya başka şeyler çalıştırırlar).
- **Pipeline’ı ele geçirmek** (sonraki bölüme bakın)
- **SSO**: Bazı platformlar kullanıcıların register olmasına izin vermez, ancak geçerli bir SSO ile herkese erişim izni verir (örneğin attacker kendi github account'unu kullanarak giriş yapabilir).
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... bir repo'ya bir şekilde erişmek için bir kullanıcının çalabileceği çeşitli token türleri vardır.
- **Webhooks**: VCS platformları webhooks oluşturulmasına izin verir. Eğer bunlar görünmeyen secret'larla **korunmuyorsa**, **attacker bunları abuse edebilir**.
- Eğer secret yoksa, attacker üçüncü taraf platformun webhook'unu abuse edebilir
- Eğer secret URL'de ise, aynı şey olur ve attacker secret'a da sahip olur
- **Code compromise:** Eğer kötü niyetli bir aktör repos üzerinde herhangi bir tür **write** erişimine sahipse, **malicious code inject** etmeye çalışabilir. Başarılı olmak için **branch protections'ı bypass** etmesi gerekebilir. Bu eylemler mid'de farklı hedeflerle yapılabilir:
- Ana branch'i compromise ederek **production'ı compromise etmek**.
- Ana branch'i (veya diğer branch'leri) compromise ederek **developer machine'lerini compromise etmek** (çünkü genellikle makinelerinde repo içinde test, terraform veya başka şeyler çalıştırırlar).
- **Pipeline'ı compromise etmek** (bir sonraki bölüme bakın)
## Pipelines Pentesting Methodology
Pipeline tanımlamanın en yaygın yolu, pipeline’ın build ettiği repository’de barındırılan bir **CI configuration file** kullanmaktır. Bu dosya, çalıştırılan job’ların sırasını, akışı etkileyen koşulları ve build environment ayarlarını açıklar.\
Bu dosyalar genellikle tutarlı bir isim ve formata sahiptir; örneğin Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) ve .github/workflows altında bulunan GitHub Actions YAML dosyaları. Tetiklendiğinde, pipeline job seçilen kaynaktan (örn. commit / branch) **code’u çeker** ve o code’a karşı CI configuration file içinde belirtilen komutları **çalıştırır**.
Pipeline tanımlamanın en yaygın yolu, pipeline'ın build ettiği repository içinde barındırılan bir **CI configuration file** kullanmaktır. Bu dosya, çalıştırılan job'ların sırasını, akışı etkileyen koşulları ve build ortamı ayarlarını açıklar.\
Bu dosyalar genellikle tutarlı bir ada ve formata sahiptir; örneğin — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) ve .github/workflows altındaki GitHub Actions YAML dosyaları. Tetiklendiğinde pipeline job'u seçilen kaynaktan (ör. commit / branch) **code'u çeker** ve **CI configuration file'da belirtilen komutları** o code'a karşı çalıştırır.
Bu nedenle attacker’ın nihai hedefi somehow bu **configuration file’ları ele geçirmek** veya onların çalıştırdığı **komutları** ele geçirmektir.
Bu nedenle attacker'ın nihai amacı bir şekilde bu **configuration file'ları** veya **çalıştırdıkları komutları** compromise etmektir.
> [!TIP]
> Bazı hosted builders, contributor’ların Docker build context ve Dockerfile path seçmesine izin verir. Eğer context attacker-controlled ise, build sırasında host dosyalarını almak ve secrets’i exfiltrate etmek için bunu repo dışına ayarlayabilirsiniz (örn. ".."). Bakın:
> Bazı hosted builder'lar contributor'ların Docker build context ve Dockerfile path seçmesine izin verir. Eğer context attacker-controlled ise, build sırasında host dosyalarını almak ve secret'ları exfiltrate etmek için bunu repo dışına (ör. "..") ayarlayabilirsiniz. Bkz:
>
>{{#ref}}
>docker-build-context-abuse.md
@@ -58,53 +58,54 @@ Bu nedenle attacker’ın nihai hedefi somehow bu **configuration file’ları e
### PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) yolu, bir SCM repository’deki permissions’ı kullanarak bir CI pipeline’ı manipüle etmeyi ve zararlı komutlar çalıştırmayı sömüren bir yöntemdir. Gerekli permissions’a sahip kullanıcılar, CI configuration file’larını veya pipeline job’unun kullandığı diğer dosyaları zararlı komutlar içerecek şekilde değiştirebilir. Bu, CI pipeline’ını “zehirler” ve bu zararlı komutların çalışmasına yol açar.
Poisoned Pipeline Execution (PPE) yolu, bir SCM repository'sindeki izinleri kullanarak bir CI pipeline'ını manipüle etmeyi ve zararlı komutlar çalıştırmayı hedefler. Gerekli izinlere sahip kullanıcılar, CI configuration file'larını veya pipeline job tarafından kullanılan diğer dosyaları kötü niyetli komutlar içerecek şekilde değiştirebilir. Bu, CI pipeline'ını "zehirler" ve bu kötü niyetli komutların çalışmasına yol açar.
Bir malicious actor’ın PPE saldırısında başarılı olabilmesi için şunları yapabilmesi gerekir:
Kötü niyetli bir aktörün PPE saldırısında başarılı olabilmesi için şunları yapabilmesi gerekir:
- Genellikle pipeline’lar bir push veya pull request yapıldığında tetiklendiği için **VCS platformunda write access** sahibi olmak. (Access elde etme yollarının özeti için VCS pentesting methodology bölümüne bakın).
- Bazen bir **external PR write access** olarak sayılabilir.
- Write permissions’ı olsa bile, CI config file’ını veya config’in dayandığı diğer dosyaları **değiştirebildiğinden emin olması** gerekir.
- Bunun için **branch protections’ı aşabilmesi** gerekebilir.
- **VCS platformunda write access** sahibi olmak; çünkü pipeline'lar genellikle bir push veya pull request yapıldığında tetiklenir. (Erişim elde etme yollarının özeti için VCS pentesting methodology'ye bakın).
- Bazen bir **external PR'nin "write access" olarak sayıldığını** not edin.
- Write izinleri olsa bile, **CI config file'ı veya config'in dayandığı diğer dosyaları değiştirebildiğinden** emin olması gerekir.
- Bunun için **branch protections'ı bypass** edebilmesi gerekebilir.
3 PPE çeşidi vardır:
3 PPE türü vardır:
- **D-PPE**: Bir **Direct PPE** saldırısı, aktörün yürütülecek **CI config** dosyasını **değiştirmesi** durumunda gerçekleşir.
- **I-DDE**: Bir **Indirect PPE** saldırısı, aktörün yürütülecek CI config dosyasının **dayandığı** bir **dosyayı** (make file veya terraform config gibi) **değiştirmesi** durumunda gerçekleşir.
- **Public PPE or 3PE**: Bazı durumlarda pipeline’lar, repo’da write access’i olmayan kullanıcılar tarafından (hatta org’un parçası olmayanlar tarafından bile) bir PR gönderebildikleri için **tetiklenebilir**.
- **3PE Command Injection**: Genellikle CI/CD pipeline’lar PR hakkında **bilgi içeren environment variables** ayarlar. Bu değer bir attacker tarafından kontrol edilebiliyorsa (PR başlığı gibi) ve **tehlikeli bir yerde** kullanılıyorsa (**sh commands** çalıştırmak gibi), attacker buraya **command enjekte edebilir**.
- **D-PPE**: Bir aktör çalıştırılacak olan **CI config** dosyasını **değiştirdiğinde** oluşan **Direct PPE** saldırısıdır.
- **I-DDE**: Bir aktör çalıştırılacak olan **CI config file'ın dayandığı** bir **dosyayı** (örneğin bir make file veya terraform config) **değiştirdiğinde** oluşan **Indirect PPE** saldırısıdır.
- **Public PPE or 3PE**: Bazı durumlarda pipeline'lar repo'da write access'i olmayan kullanıcılar tarafından (hatta org'un parçası olmayanlar tarafından bile) bir PR gönderebildikleri için **tetiklenebilir**.
- **3PE Command Injection**: Genellikle CI/CD pipelines, PR hakkında **bilgi içeren environment variables** ayarlar. Eğer bu değer attacker tarafından kontrol edilebiliyorsa (örneğin PR başlığı) ve **tehlikeli bir yerde** kullanılıyorsa (örneğin **sh commands** çalıştırmak gibi), attacker buraya **komut enjekte edebilir**.
### Exploitation Benefits
Bir pipeline’ı zehirlemenin 3 çeşidini bildiğimize göre, başarılı bir exploitation sonrasında attacker’ın neler elde edebileceğine bakalım:
Pipeline'ı zehirlemenin 3 türünü bildiğimize göre, başarılı bir exploitation sonrası attacker'ın neler elde edebileceğine bakalım:
- **Secrets**: Daha önce de belirtildiği gibi, pipeline’lar job’ları için **privileges** gerektirir (code’u almak, build etmek, deploy etmek...) ve bu privileges genellikle **secrets içinde** verilir. Bu secrets’e genellikle **env variables veya sistem içindeki dosyalar** üzerinden erişilebilir. Bu nedenle attacker her zaman mümkün olduğunca çok secret exfiltrate etmeye çalışacaktır.
- Pipeline platformuna bağlı olarak attacker’ın **secrets’i config içinde belirtmesi gerekebilir**. Bu, attacker CI configuration pipeline’ını değiştiremiyorsa (**örneğin I-PPE**), sadece o pipeline’ın sahip olduğu **secrets’i exfiltrate edebileceği** anlamına gelir.
- **Secrets**: Daha önce de belirtildiği gibi, pipeline'lar işlerini (code'u çekmek, build etmek, deploy etmek...) yürütmek için **privileges** gerektirir ve bu privileges genellikle **secrets** içinde verilir. Bu secrets'a genellikle **env variables** veya sistem içindeki dosyalar üzerinden erişilebilir. Bu nedenle attacker her zaman mümkün olduğunca çok secret exfiltrate etmeye çalışacaktır.
- Pipeline platformuna bağlı olarak attacker'ın **config içinde secrets belirtmesi gerekebilir**. Bu, attacker CI configuration pipeline'ını (**örneğin I-PPE**) değiştiremiyorsa, **yalnızca o pipeline'ın sahip olduğu secrets'ı exfiltrate edebileceği** anlamına gelir.
- **Computation**: Code bir yerde çalıştırılır; nerede çalıştırıldığına bağlı olarak attacker daha ileri pivot yapabilir.
- **On-Premises**: Eğer pipeline’lar on premises üzerinde çalışıyorsa, attacker daha fazla resource erişimi olan bir **internal network** içinde sona erebilir.
- **Cloud**: Attacker **cloud içindeki diğer makinelere** erişebilir, ayrıca daha fazla cloud erişimi elde etmek için buradan IAM roles/service accounts **tokens** exfiltrate edebilir.
- **Platforms machine**: Bazen job’lar **pipelines platform makineleri** içinde çalıştırılır; bunlar genellikle cloud içinde olur ve **başka erişimleri yoktur**.
- **Select it:** Bazen **pipelines platformu birkaç makineyi yapılandırmış olur** ve CI configuration file’ı **değiştirebilirseniz**, zararlı code’u nerede çalıştırmak istediğinizi **belirtebilirsiniz**. Bu durumda attacker muhtemelen daha fazla exploit etmeye çalışmak için her olası makinede bir reverse shell çalıştırır.
- **Compromise production**: Eğer pipeline içindeyseniz ve son sürüm oradan build edilip deploy ediliyorsa, production’da çalışacak code’u **ele geçirebilirsiniz**.
- **On-Premises**: Pipeline'lar on premises çalıştırılıyorsa, attacker **daha fazla kaynağa erişimi olan iç bir network** içinde kalabilir.
- **Cloud**: Attacker cloud içindeki **diğer makinelere** erişebilir, ayrıca cloud içinde **daha fazla erişim** elde etmek için buradan IAM roles/service accounts **tokens** exfiltrate edebilir.
- **Platforms machine**: Bazen job'lar **pipelines platform machine'leri** içinde çalıştırılır; bunlar genellikle cloud içindedir ve **daha fazla erişimi yoktur**.
- **Select it:** Bazen **pipelines platform birden fazla machine konfigüre etmiş olur** ve eğer **CI configuration file'ı değiştirebiliyorsanız**, zararlı code'u nerede çalıştırmak istediğinizi **belirtebilirsiniz**. Bu durumda attacker muhtemelen her olası machine üzerinde bir reverse shell çalıştırarak daha fazla istismar etmeye çalışacaktır.
- **Compromise production**: Eğer pipeline'ın içindeyseniz ve final version buradan build edilip deploy ediliyorsa, **production'da çalışacak code'u compromise edebilirsiniz**.
### Dependency & Registry Supply-Chain Abuse
Bir CI/CD pipeline’ı ele geçirmek veya ondan credentials çalmak, attacker’ın dependencies ya da release tooling’i backdoor’layarak **pipeline execution**’dan **ecosystem-wide code execution**’a geçmesine izin verebilir:
Bir CI/CD pipeline'ını compromise etmek veya ondan credentials çalmak, attacker'ın dependency'leri ya da release tooling'i backdoor'layarak **pipeline execution**'dan **ecosystem-wide code execution**'a geçmesine izin verebilir:
- **Install-time code execution via package hooks**: `preinstall`, `postinstall`, `prepare` veya benzeri hook’lar ekleyen bir package version yayınlayın; böylece payload dependency installation sırasında developer workstation’larında ve CI runners’da otomatik olarak çalışır.
- **Secondary execution paths**: Hedefler `--ignore-scripts` ile kurulum yapsa bile, kötü niyetli bir package `bin` alanında **yaygın bir CLI name** kaydedebilir; böylece attacker-controlled wrapper `PATH` içine symlink edilir ve komut kullanıldığında daha sonra çalışır.
- **Runtime bootstrapping**: Küçük bir installer, kurulum sırasında ikinci bir runtime veya toolchain indirebilir (örneğin Bun veya paketlenmiş bir interpreter) ve ardından ana payload’u onunla başlatabilir; böylece local dependency requirements’tan kaçınır.
- **Credential harvesting from build environments**: Code CI içinde çalıştıktan sonra environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs ve `gh auth token` gibi local tooling’i kontrol edin. GitHub Actions’ta ayrıca runner-specific secrets ve artifacts’e bakın.
- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions’a sahip bir token, bir branch oluşturmak, `.github/workflows/` içine zararlı bir dosya commit etmek, onu tetiklemek, üretilen artifacts/logs’u toplamak ve ardından geçici branch/workflow run’ı silerek izleri azaltmak için yeterlidir.
- **Wormable registry propagation**: Çalınan npm tokens’ların **publish** permissions ve 2FA’yı bypass edip etmedikleri doğrulanmalıdır. Eğer ediyorlarsa, yazılabilir package’ları enumerate edin, tarball’larını indirin, `setup.mjs` gibi bir loader enjekte edin, çalıştırmak için `preinstall` ayarlayın, patch version’ı artırın ve yeniden publish edin. Bu, bir CI compromise’ını diğer ortamlarda downstream auto-execution’a dönüştürür.
- **Install-time code execution via package hooks**: `preinstall`, `postinstall`, `prepare` veya benzeri hook'lar ekleyen bir package version yayınlayın; böylece payload dependency installation sırasında developer workstation'larında ve CI runner'larda otomatik çalışır.
- **Secondary execution paths**: hedefler `--ignore-scripts` ile install etse bile, kötü niyetli bir package `bin` field'ında **yaygın bir CLI name** kaydedebilir; böylece attacker-controlled wrapper `PATH` içine symlink'lenir ve command kullanıldığında daha sonra çalışır.
- **Runtime bootstrapping**: küçük bir installer, installation sırasında ikinci bir runtime veya toolchain indirebilir (örneğin Bun veya packed bir interpreter) ve ardından ana payload'ı onunla başlatabilir; bu da local dependency gereksinimlerinden kaçınır.
- **Credential harvesting from build environments**: code CI içinde çalıştığında, environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs ve `gh auth token` gibi local tooling'i kontrol edin. GitHub Actions'ta ayrıca runner'a özgü secrets ve artifacts'e bakın.
- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** izinlerine sahip bir token, bir branch oluşturmak, `.github/workflows/` içine kötü niyetli bir dosya commit etmek, onu tetiklemek, üretilen artifact/log'ları toplamak ve ardından izleri azaltmak için geçici branch/workflow run'u silmek için yeterlidir.
- **Wormable registry propagation**: çalınan npm token'ları **publish** izinleri ve 2FA'yı bypass edip etmediği açısından doğrulanmalıdır. Eğer ediyorlarsa, yazılabilir package'ları enumerate edin, tarball'larını indirin, `setup.mjs` gibi bir loader enjekte edin, çalıştırmak için `preinstall` ayarlayın, patch version'ı artırın ve yeniden publish edin. Bu, tek bir CI compromise'ını diğer ortamlarda downstream auto-execution'a dönüştürür.
#### Practical checks during an assessment
#### Pratik kontrol noktaları
- `package.json` içine eklenmiş package-manager hook’ları, beklenmeyen `bin` girişleri veya yalnızca release artifact’ini değiştiren version bumps için release automation’ı inceleyin.
- CI’nin uzun ömürlü registry credentials’ı kısa ömürlü OIDC veya trusted publishing yerine `~/.npmrc` gibi plaintext dosyalarda saklayıp saklamadığını kontrol edin.
- CI’de mevcut GitHub tokens’ın workflow dosyaları yazıp yazamadığını veya branch/tag oluşturup oluşturamadığını doğrulayın.
- Eğer compromised bir package’tan şüpheleniliyorsa, yalnızca Git repository’yi değil published tarball’ı da inceleyin; çünkü kötü niyetli loader/runtime yalnızca published artifact içinde bulunabilir.
- CI içinde `npm install` yerine `npm ci`, beklenmeyen Bun indirme/çalıştırma işlemleri veya transient branch’lerden üretilen yeni workflow artifacts gibi beklenmeyen package-manager execution’larını araştırın.
- Release automation'ı, `package.json` içine eklenmiş package-manager hook'ları, beklenmedik `bin` entries veya yalnızca release artifact'ini değiştiren version bump'lar için inceleyin.
- CI'nin uzun ömürlü registry credentials'ı `~/.npmrc` gibi düz metin dosyalarda saklayıp saklamadığını, kısa ömürlü OIDC veya trusted publishing yerine bunu kullanıp kullanmadığını kontrol edin.
- CI'de bulunan GitHub token'larının workflow dosyaları yazıp yazamadığını veya branch/tag oluşturup oluşturamadığını doğrulayın.
- Eğer bir package'ın compromise edildiğinden şüpheleniliyorsa, yalnızca Git repository'yi değil published tarball'ı da inceleyin; çünkü kötü niyetli loader/runtime sadece published artifact içinde bulunabilir.
- CI içinde beklenmedik package-manager execution olup olmadığını, örneğin `npm install` yerine `npm ci`, beklenmedik Bun download/execution veya transient branch'lerden üretilen yeni workflow artifact'ları gibi durumları araştırın.
- GitOps deployment engine'lerini de CI/CD hedefleri olarak inceleyin. Argo CD'ye özgü enumeration, repo-server abuse ve Redis cache poisoning saldırıları [Argo CD Security](argocd-security.md) içinde ele alınmıştır.
## More relevant info