Pentesting CI/CD Methodology

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

VCS

VCS, Version Control System anlamına gelir; bu sistemler geliştiricilerin kaynak code’larını yönetmesini sağlar. En yaygın olanı git’tir ve genelde şirketlerde aşağıdaki platformlardan birinde kullanılır:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines geliştiricilerin uygulamaları build, test ve deploy etmek gibi amaçlar için code yürütmeyi otomatikleştirmesini sağlar. Bu otomatik iş akışları, code push’ları, pull request’ler veya zamanlanmış görevler gibi belirli aksiyonlarla tetiklenir. Geliştirmeden üretime geçiş sürecini düzene koymak için faydalıdır.

Ancak bu sistemlerin bir yerde çalıştırılması gerekir ve genelde deploy yapmak veya hassas bilgilere erişmek için ayrıcalıklı credentials ile çalışırlar.

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 source code’unun bulunduğu platformlar hassas bilgiler içerir ve bu platform içinde verilen izinlere çok dikkat edilmelidir. Saldırganların kötüye kullanabileceği VCS platformları genelinde görülen bazı yaygın problemler şunlardır:

  • Leaks: Eğer code’unuz commit’lerde leaks içeriyorsa ve saldırgan repoya erişebiliyorsa (çünkü repo public veya erişimi varsa) bu leaksleri 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 izin elde edebilir.
  • 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 verir (örneğin bir saldırgan github hesabını kullanarak girebilir).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… kullanıcıların repoya herhangi 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’lerle korunmuyorsa bir saldırgan bunları kötüye kullanabilir.
  • Eğer herhangi bir secret yoksa, saldırgan üçüncü taraf platformun webhook’unu kötüye kullanabilir
  • Eğer secret URL içinde ise, aynı durum geçerlidir ve saldırgan secret’a da sahip olur
  • Code compromise: Eğer kötü niyetli bir aktör repolarda bir tür write erişimine sahipse, zararlı code enjekte etmeye çalışabilir. Başarılı olmak için çoğunlukla branch protections’ı bypass etmesi gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir:
  • Main branch’i ele geçirerek production’ı compromise etmek.
  • Main (veya diğer) branch’leri ele geçirerek geliştiricilerin makinelerini compromise etmek (çünkü genelde test, terraform veya repo içindeki diğer şeyleri kendi makinelerinde ç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 yürütülen job’ların sırasını, akışı etkileyen koşulları ve build ortamı ayarlarını açıklar.
Bu dosyalar genelde tutarlı bir ad ve formatta olur; ö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’ı seçilen kaynaktan (ör. commit / branch) code’u çeker ve CI configuration file içinde belirtilen komutları bu code’a karşı çalıştırır.

Bu yüzden saldırganın nihai amacı bir şekilde bu configuration dosyalarını ya da çalıştırdıkları komutları compromise etmektir.

Tip

Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., “..”) to ingest host files during build and exfiltrate secrets. See:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) yolu, bir SCM repository içindeki izinleri kötüye kullanarak bir CI pipeline’ını manipüle etmeyi ve zararlı komutlar çalıştırmayı hedefler. Gerekli izinlere sahip kullanıcılar CI configuration dosyalarını veya pipeline job tarafından kullanılan diğer dosyaları değiştirerek kötü amaçlı komutlar ekleyebilir. Bu durum CI pipeline’ını “poison” eder ve bu kötü amaçlı komutların çalışmasına yol açar.

Bir saldırganın PPE saldırısında başarılı olabilmesi için:

  • VCS platformunda write accesse sahip olması gerekir; çünkü genelde pipeline’lar bir push veya pull request gerçekleştiğinde tetiklenir. (Erişim elde etme yolları için VCS pentesting methodology bölümüne bakın).
  • Bazen bir external PR’in “write access” sayıldığı unutulmamalıdır.
  • Write izinleri olsa bile, CI config dosyasını veya config’in rely ettiği diğer dosyaları değiştirebileceğinden emin olması gerekir.
  • Bunun için branch protections’ı bypass edebilmesi gerekebilir.

3 PPE çeşidi vardır:

  • D-PPE: Bir Direct PPE saldırısı, aktörün yürütülecek CI config dosyasını direkt olarak değiştirdiği durumdur.
  • I-DDE: Bir Indirect PPE saldırısı, aktörün CI config dosyasının rely ettiği (ör. make file veya terraform config gibi) bir dosyayı değiştirdiği durumdur.
  • Public PPE or 3PE: Bazı durumlarda pipeline’lar repo içinde write access’i olmayan kullanıcılar tarafından (ve hatta org üyesi olmayanlar tarafından) gönderilen PR’lerle tetiklenebilir.
  • 3PE Command Injection: Genelde CI/CD pipeline’ları PR hakkında bilgi içeren environment variable’lar ayarlar. Eğer bu değer bir saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı gibi) ve tehlikeli bir yerde (ör. sh komutları çalıştırılan bir yerde) kullanılıyorsa, saldırgan oraya komut enjekte edebilir.

Exploitation Benefits

Bir pipeline’ı zehirlemenin 3 çeşidini bildiğimize göre, saldırganın başarılı bir exploitation sonrasında neler elde edebileceğine bakalım:

  • Secrets: Daha önce de bahsedildiği gibi, pipeline job’ları code’u almak, build etmek, deploy etmek vb. için privileges gerektirir ve bu ayrıcalıklar genelde secrets içinde saklanır. Bu secrets genelde env variables veya sistem içindeki dosyalar aracılığıyla erişilebilir. Bu nedenle bir saldırgan mümkün olduğunca çok secrets exfiltrate etmeye çalışacaktır.
  • Pipeline platformuna bağlı olarak saldırgan secret’ları config içinde belirtmek zorunda olabilir. Bu, eğer saldırgan CI configuration pipeline’ını değiştiremiyorsa (I-PPE gibi), sadece o pipeline’ın sahip olduğu secrets’ları exfiltrate edebileceği anlamına gelir.
  • Computation: Code bir yerde çalıştırılır; çalıştırıldığı yere bağlı olarak saldırgan daha fazla pivot yapabilir.
  • On-Premises: Pipeline’lar on-premises çalıştırılıyorsa, saldırgan daha fazla kaynağa erişimi olan internal bir ağa ulaşabilir.
  • Cloud: Saldırgan diğer cloud makinelerine erişebileceği gibi IAM roles/service accounts token’larını exfiltrate ederek cloud içinde daha fazla erişim elde edebilir.
  • Platforms machine: Bazen job’lar pipeline platform makineleri içinde çalıştırılır; genelde bunlar cloud içinde olup başka erişime sahip değildir.
  • Select it: Bazı pipeline platformlarında çeşitli makineler yapılandırılmış olur ve eğer CI configuration dosyasını değiştirebiliyorsanız kodu nerede çalıştırmak istediğinizi belirtebilirsiniz. Bu durumda saldırgan, her mümkün makinede reverse shell çalıştırıp onlardan daha fazla exploit denemesi yapabilir.
  • Compromise production: Eğer pipeline içindeyseniz ve final versiyon pipeline’dan build edilip deploy ediliyorsa, production’da çalışacak olan code’u compromise edebilirsiniz.

More relevant info

Tools & CIS Benchmark

  • Chain-bench açık kaynak bir araçtır ve yeni bir CIS Software Supply Chain benchmark temelinde yazılım tedarik zinciri yığınıınızı güvenlik uyumluluğu açısından 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 top 10 CI/CD risklerini anlatan ilginç makaleyi inceleyin: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov, infrastructure-as-code için statik kod analiz aracı.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin