9.8 KiB
Pentesting CI/CD Metodolojisi
{{#include ../banners/hacktricks-training.md}}
VCS
VCS, Version Control System'in kısaltmasıdır; bu sistemler geliştiricilerin kaynak kodlarını yönetmesine olanak tanır. En yaygın olanı git'tir ve genellikle şirketlerin aşağıdaki platformlardan birini kullandığını görürsünüz:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD Pipelines
CI/CD pipeline'ları geliştiricilerin uygulamaları derleme, test etme ve deploy etme dahil olmak üzere kod yürütme işlemlerini otomatikleştirmesine olanak tanır. Bu otomatik iş akışları, kod push'ları, pull request'ler veya zamanlanmış görevler gibi belirli aksiyonlarla tetiklenir. Geliştirmeden üretime olan süreci düzene sokmak için faydalıdır.
Ancak bu sistemlerin bir yerlerde çalıştırılması gerekir ve genellikle kodu deploy etmek veya hassas bilgilere erişmek için ayrıcalıklı kimlik bilgilerine ihtiyaçları vardır.
VCS Pentesting Methodology
Note
Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
Projenizin kaynak kodunu içeren platformlar hassas bilgi barındırır ve bu platform içindeki izinlerle ilgili çok dikkatli olunmalıdır. Saldırganın kötüye kullanabileceği VCS platformlarında görülen bazı yaygın problemler şunlardır:
- Leaks: Eğer kodunuz commit'lerde leaks içeriyorsa ve saldırgan repoya erişebiliyorsa (çünkü repo public ya da onun erişimi olduğu için), leaks keşfedilebilir.
- Access: Bir saldırgan VCS platformu içinde bir hesaba erişim elde edebilirse, daha fazla görünürlük ve izin kazanabilir.
- Register: Bazı platformlar dış kullanıcıların hesap oluşturmasına izin verir.
- SSO: Bazı platformlar kullanıcı kaydına izin vermez ama geçerli bir SSO ile herkesin erişmesine izin verebilir (örneğin saldırgan kendi github hesabını kullanarak girebilir).
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... bir kullanıcının repoya bir şekilde erişmek için çalabileceği çeşitli token türleri vardır.
- Webhooks: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünmeyen secret'larla korunmuyorsa, bir saldırgan bunları kötüye kullanabilir.
- Eğer herhangi bir secret yoksa, saldırgan üçüncü parti platformun webhook'unu kötüye kullanabilir
- Eğer secret URL içinde ise aynı şey olur ve saldırgan ayrıca secret'a da erişir
- Code compromise: Kötü niyetli bir aktör repolar üzerinde bir tür write erişimine sahipse, zararlı kod enjekte etmeye çalışabilir. Başarılı olabilmek için branch korumalarını atlatması gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir:
- Üretimi kompromize etmek için main branch'i ele geçirmek.
- Geliştiricilerin makinelerini kompromize etmek için main (veya diğer) branch'leri ele geçirmek (çünkü geliştiriciler genellikle test, terraform veya diğer şeyleri repoda kendi makinelerinde çalıştırır).
- Pipeline'ı kompromize etmek (bir sonraki bölüme bakın)
Pipelines Pentesting Methodology
Bir pipeline tanımlamanın en yaygın yolu, pipeline'ı inşa eden repository'de barındırılan bir CI konfigürasyon dosyası kullanmaktır. Bu dosya yürütülen job'ların sırasını, akışı etkileyen koşulları ve build ortamı ayarlarını açıklar.
Bu dosyaların genellikle tutarlı isimleri ve formatları vardır; örneğin — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) ve GitHub Actions YAML dosyaları .github/workflows altında bulunur. Tetiklendiğinde pipeline job'ı, seçilen kaynaktan (ör. commit / branch) kodu çeker ve bu CI konfigürasyon dosyasında belirtilen komutları o kod üzerinde çalıştırır.
Bu nedenle saldırganın nihai hedefi bir şekilde bu konfigürasyon dosyalarını veya çalıştırdıkları komutları ele geçirmek olacaktır.
PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) yolu, bir SCM repository'sindeki izinleri kullanarak bir CI pipeline'ı manipüle etmeyi ve zararlı komutlar çalıştırmayı hedefler. Gerekli izinlere sahip kullanıcılar CI konfigürasyon dosyalarını veya pipeline job tarafından kullanılan diğer dosyaları değiştirerek kötü amaçlı komutlar ekleyebilir. Bu, CI pipeline'ını "poison" eder ve bu kötü amaçlı komutların çalıştırılmasına yol açar.
Bir saldırganın PPE saldırısını başarılı şekilde gerçekleştirebilmesi için şunlara sahip olması gerekir:
- Genellikle pipeline'lar bir push veya pull request gerçekleştiğinde tetiklendiğinden, VCS platformunda write erişimi olması gerekir. (Erişim elde etme yolları için VCS pentesting methodology bölümüne bakın).
- Bazı durumlarda bir external PR "write access" olarak değerlendirilir.
- Write izinleri olsa bile, CI konfigürasyon dosyasını ya da konfigürasyonun dayandığı diğer dosyaları değiştirebileceğinden emin olmalıdır.
- Bunun için branch korumalarını atlatabilmesi gerekebilir.
3 PPE çeşidi vardır:
- D-PPE: Bir Direct PPE saldırısı, aktörün çalıştırılacak CI konfigürasyon dosyasını doğrudan değiştirdiği durumlarda gerçekleşir.
- I-DDE: Bir Indirect PPE saldırısı, aktörün CI konfigürasyon dosyasının dayandığı bir dosyayı (örneğin makefile veya terraform konfigürasyonu) değiştirdiği durumlarda gerçekleşir.
- Public PPE or 3PE: Bazı durumlarda pipeline'lar repo içinde write erişimi olmayan (ve hatta organizasyonun parçası olmayan) kullanıcılarca tetiklenebilir çünkü onlar PR gönderebilir.
- 3PE Command Injection: Genellikle CI/CD pipeline'ları PR ile ilgili bilgileri içeren environment variable'lar ayarlar. Bu değer, saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı gibi) ve tehlikeli bir yerde kullanılıyorsa (ör. sh komutları çalıştırma gibi), saldırgan burada komut enjeksiyonu yapabilir.
Exploitation Benefits
Pipeline'ları zehirlemenin 3 çeşidini bildiğimize göre, başarılı bir istismardan sonra saldırganın neler elde edebileceğine bakalım:
- Secrets: Daha önce belirtildiği gibi, pipeline job'ları (kodu almak, build etmek, deploy etmek...) için ayrıcalıklara ihtiyaç duyar ve bu ayrıcalıklar genellikle secrets olarak verilir. Bu secret'lar genellikle env değişkenleri veya sistem içindeki dosyalar aracılığıyla erişilebilir. Bu nedenle bir saldırgan mümkün olduğunca çok secret'ı exfiltrate etmeye çalışır.
- Pipeline platformuna bağlı olarak saldırgan secret'ları konfigürasyonda belirtmek zorunda olabilir. Bu, eğer saldırgan CI konfigürasyon dosyasını değiştiremiyorsa (I-PPE gibi), sadece pipeline'ın sahip olduğu secret'ları exfiltrate edebileceği anlamına gelir.
- Computation: Kod bir yerde çalıştırılır; nerede çalıştırıldığına bağlı olarak saldırgan daha ileri pivot'lar yapabilir.
- On-Premises: Pipeline'lar şirket içi ortamda çalışıyorsa, saldırgan daha fazla kaynağa erişimi olan iç ağa erişebilir.
- Cloud: Saldırgan bulut içindeki diğer makinelerle erişim sağlayabilir ve ayrıca IAM rollerinden/service account'larından token exfiltrate ederek bulut içinde daha fazla erişim elde edebilir.
- Platforms machine: Bazen job'lar pipeline platform makineleri üzerinde çalıştırılır; bu makineler genellikle bulut içinde olup daha fazla erişime sahip olmayabilir.
- Select it: Bazı durumlarda pipeline platformu birden fazla makine yapılandırmış olabilir ve CI konfigürasyon dosyasını değiştirebiliyorsanız kötü amaçlı kodu nerede çalıştırmak istediğinizi belirtebilirsiniz. Bu durumda saldırgan muhtemelen her bir mümkün makinede ters shell çalıştırarak daha fazla istismar deneyecektir.
- Compromise production: Pipeline içinde iseniz ve final versiyon buradan build edilip deploy ediliyorsa, üretimde çalışacak kodu kompromize edebilirsiniz.
More relevant info
Tools & CIS Benchmark
- Chain-bench bir açık kaynaklı araçtır ve yeni bir CIS Software Supply Chain benchmark temelinde yazılım tedarik zinciri yığını için güvenlik uyumluluğu denetimi yapar. Denetim, koddan deploy zamanına kadar tüm SDLC sürecine odaklanır ve riskleri ortaya çıkarabilir.
Top 10 CI/CD Security Risk
Cider'a göre en önemli 10 CI/CD riskini anlatan ilginç makaleye bakın: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- Her platform için yerelde çalıştırabileceğiniz nasıl başlatılacağını bulacaksınız, böylece istediğiniz gibi yapılandırıp test edebilirsiniz
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov infrastructure-as-code için bir static code analysis aracıdır.
References
{{#include ../banners/hacktricks-training.md}}