9.6 KiB
Pentesting CI/CD Metodolojisi
{{#include ../banners/hacktricks-training.md}}
VCS
VCS açılımı Version Control System'dir; bu sistemler geliştiricilerin kaynak kodlarını yönetmesine olanak tanır. En yaygın olanı git ve genellikle şirketlerde aşağıdaki platformlardan birini göreceksiniz:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD Pipelines
CI/CD pipelines, geliştiricilerin kodun yürütülmesini; build, test ve deploy gibi amaçlarla otomatikleştirmesini sağlar. Bu otomatik iş akışları, kod push'ları, pull requests veya zamanlanmış görevler gibi belirli aksiyonlarla tetiklenir. Geliştirmeden production'a geçiş sürecini düzene koymak için faydalıdır.
Ancak bu sistemlerin bir yerde çalıştırılması gerekir ve genellikle kod deploy etmek veya hassas bilgilere erişmek için ayrıcalıklı kimlik bilgileri kullanılır.
VCS Pentesting Methodology
Note
Bazı VCS platformları pipeline oluşturmaya izin verse bile bu bölümde yalnızca kaynak kodunun kontrolüne yönelik olası saldırıları analiz edeceğiz.
Projenizin kaynak kodunu içeren platformlar hassas bilgi barındırır ve platform içindeki izinlerle çok dikkatli olunmalıdır. Saldırganların kötüye kullanabileceği VCS platformlarında yaygın bazı problemler şunlardır:
- Leaks: Eğer kodunuz commit'lerde leak içeriyorsa ve saldırgan repo'ya erişebiliyorsa (çünkü public veya erişimi varsa), leak'leri keşfedebilir.
- Access: Eğer bir saldırgan VCS platformu içinde bir hesaba erişim sağlayabilirse daha fazla görünürlük ve yetki kazanabilir.
- Register: Bazı platformlar dış kullanıcıların hesap oluşturmasına izin verir.
- SSO: Bazı platformlar kullanıcı kaydına izin vermez, fakat geçerli bir SSO ile herhangi birinin erişmesine izin verebilir (örneğin saldırgan kendi github hesabını kullanarak giriş yapabilir).
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kullanıcıların bir repoya erişmek için çalabilecekleri çeşitli token türleri vardır.
- Webhooks: VCS platformları webhook oluşturulmasına izin verir. Eğer bunlar görünür olmayan secrets ile korunmuyorsa, bir saldırgan bunları kötüye kullanabilir.
- Eğer hiçbir secret yoksa, saldırgan üçüncü taraf platformun webhook'unu kötüye kullanabilir.
- Eğer secret URL'de ise aynı durum geçerlidir ve saldırgan bu secret'e de sahip olur.
- Code compromise: Eğer kötü niyetli bir aktör repo üzerinde bir tür write erişime sahipse, kötü amaçlı kod enjekte etmeye çalışabilir. Başarılı olabilmek için branch protections'ı atlatması gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir:
- Ana branch'i ele geçirerek production ortamını tehlikeye atmak.
- Ana (veya diğer) branch'leri ele geçirerek geliştiricilerin makinelerini tehlikeye atmak (çünkü genellikle test, terraform veya repo içindekileri makinelerinde çalıştırırlar).
- Pipeline'ı ele geçirmek (bir sonraki bölüme bakın)
Pipelines Pentesting Methodology
Bir 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ı tanımlar.
Bu dosyalar genelde tutarlı bir isim ve formatta olur; ö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 (ör. commit / branch) kodu çeker ve CI configuration file'da belirtilen komutları bu koda karşı çalıştırır.
Dolayısıyla saldırganın nihai hedefi bir şekilde bu konfigürasyon dosyalarını veya bunların çalıştırdığı komutları ele geçirmek olacaktır.
PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) yolu, bir SCM repository'deki izinleri suistimal ederek bir CI pipeline'ını 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ı düzenleyerek kötü amaçlı komutlar ekleyebilir. Bu, CI pipeline'ını "poison" ederek bu kötü amaçlı komutların çalıştırılmasına yol açar.
Bir kötü niyetli aktörün başarılı bir PPE saldırısı gerçekleştirebilmesi için şunlara sahip olması gerekir:
- Genellikle pipeline'lar bir push veya pull request yapıldığında tetiklendiği için VCS platformunda write erişimi olmalıdır. (VCS pentesting methodology kısmında erişim elde etme yolları özetlenmiştir).
- Bazen bir external PR'in "write access" olarak sayıldığını unutmayın.
- Write izinleri olsa bile, CI config dosyasını veya config'in dayandığı diğer dosyaları değiştirebildiğinden emin olmalıdır.
- Bunun için branch protections'ı atlatabilmesi gerekebilir.
3 PPE çeşidi vardır:
- D-PPE: Bir Direct PPE saldırısı, aktörün çalıştırılacak CI config dosyasını doğrudan değiştirdiği durumlarda gerçekleşir.
- I-DDE: Bir Indirect PPE saldırısı, aktörün CI config dosyasının dayandığı bir dosyayı (ör. make file veya terraform config) değiştirdiği durumlarda gerçekleşir.
- Public PPE or 3PE: Bazı durumlarda pipeline'lar repo'da write erişimi olmayan (hatta org içinde olmayan) kullanıcılar tarafından gönderilen PR'ler sayesinde tetiklenebilir.
- 3PE Command Injection: Genellikle CI/CD pipeline'ları PR hakkında bilgi içeren environment variable'lar ayarlar. Eğer bu değer saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı gibi) ve tehlikeli bir yerde (ör. sh komutları çalıştırma) kullanılıyorsa, saldırgan buraya komut enjekte edebilir.
Exploitation Benefits
3 PPE çeşidini bildiğimize göre, başarılı bir istismardan sonra saldırganın neler elde edebileceğine bakalım:
- Secrets: Daha önce bahsedildiği gibi, pipeline job'larının kodu çekmesi, build etmesi, deploy etmesi vb. için privilege gerekir ve bu yetkiler genelde secrets olarak sağlanır. Bu secrets genelde env variable'lar veya sistem içindeki dosyalar aracılığıyla erişilebilir. Bu yüzden saldırgan mümkün olduğunca çok secret'i exfiltrate etmeye çalışacaktır.
- Pipeline platformuna bağlı olarak saldırgan secret'leri config içinde belirtmesi gerekebilecek pipeline'ların yetkilerini yalnızca sınırlı şekilde exfiltrate edebilir. Yani saldırgan CI konfigürasyon dosyasını değiştiremiyorsa (I-PPE gibi), yalnızca o pipeline'ın sahip olduğu secret'leri çalabilir.
- Computation: Kod bir yerde çalıştırılır; nerede çalıştığına bağlı olarak saldırgan daha ileri pivotlar yapabilir.
- On-Premises: Eğer pipeline'lar on-premises çalışıyorsa, saldırgan dahili bir ağa erişip daha fazla kaynağa ulaşabilir.
- Cloud: Saldırgan buluta diğer makinelerden erişebilir ve ayrıca IAM rollerinden/service account'lardan token'lar exfiltrate edip bulut içinde daha ileri erişimler elde edebilir.
- Platforms machine: Bazı job'lar pipeline platform makineleri içinde çalıştırılır; bu makineler genelde bulut içindedir ve daha fazla erişime sahip olmayabilir.
- Select it: Bazen pipeline platformu birkaç farklı makine yapılandırmış olur ve eğer CI configuration file'ını değiştirebilirseniz kötü amaçlı kodu hangi makinede çalıştırmak istediğinizi belirtebilirsiniz. Bu durumda saldırgan muhtemelen her olası makinede reverse shell açıp daha fazla istismar deneyecektir.
- Compromise production: Eğer pipeline içinde bulunur ve son sürüm pipeline'dan build edilip deploy ediliyorsa, production'da çalışacak kodu compromise edebilirsiniz.
More relevant info
Tools & CIS Benchmark
- Chain-bench bir açık kaynak aracıdır ve yazılım tedarik zinciri yığınıınızı yeni bir CIS Software Supply Chain benchmark temelinde güvenlik uyumluluğu için denetler. Denetim, kod zamanından 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 riski hakkında ilginç makaleyi inceleyin: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- Yerelde çalıştırabileceğiniz her platform için nasıl yerelde başlatılacağı gösterilmiştir; 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 statik kod analizi yapan bir araçtır.
References
{{#include ../banners/hacktricks-training.md}}