Translated ['src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Gitblit Güvenlik
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Gitblit Nedir
+
+Gitblit, Java ile yazılmış kendi barındırdığınız bir Git sunucusudur. Tek başına bir JAR olarak veya servlet konteynerlerinde çalışabilir ve Git over SSH için gömülü bir SSH servisi (Apache MINA SSHD) ile birlikte gelir.
+
+## Konular
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Referanslar
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Özet
+
+CVE-2024-28080, Apache MINA SSHD ile entegrasyon sırasında oturum durumu işleme hatası nedeniyle Gitblit’in embedded SSH servisinde bir kimlik doğrulama atlatmasıdır. Bir kullanıcı hesabında en az bir SSH public key kayıtlıysa, kullanıcı adını ve o kullanıcının herhangi bir public key'ini bilen bir saldırgan, private key veya parola olmadan kimlik doğrulaması yapabilir.
+
+- Etkilenen: Gitblit < 1.10.0 (1.9.3 üzerinde gözlemlendi)
+- Düzeltilen sürüm: 1.10.0
+- Sömürmek için gereksinimler:
+- Git over SSH örnekte etkin olmalı
+- Hedef hesabında Gitblit’te en az bir SSH public key kayıtlı olmalı
+- Saldırgan hedef kullanıcı adını ve kullanıcıya ait public key'lerden birini bilmeli (çoğunlukla keşfedilebilir, örn. https://github.com/<username>.keys)
+
+## Kök neden (state leaks between SSH methods)
+
+RFC 4252’ye göre, public‑key authentication iki aşamada ilerler: sunucu önce verilen public key’in bir kullanıcı adı için kabul edilebilir olup olmadığını kontrol eder ve ancak bir challenge/response ile imza gerçekleştiğinde kullanıcıyı doğrular. MINA SSHD’de PublickeyAuthenticator iki kez çağrılır: key kabulünde (henüz imza yok) ve daha sonra istemci bir imza döndüğünde.
+
+Gitblit’in PublickeyAuthenticator’ı imzadan önceki ilk çağrıda session bağlamını değiştirerek authenticated UserModel’i session’a bağladı ve true döndürerek ("key acceptable") anahtarı kabul etti. Daha sonra kimlik doğrulama parola yöntemine düştüğünde, PasswordAuthenticator bu değiştirilmiş session durumuna güvenip kısa devre yaptı ve parolayı doğrulamadan true döndürdü. Sonuç olarak, aynı kullanıcı için önceki bir public‑key "acceptance" sonrası herhangi bir parola (boş olan dahil) kabul edildi.
+
+Yüksek seviyede hatalı akış:
+
+1) İstemci kullanıcı adı + public key sunar (henüz imza yok)  
+2) Sunucu anahtarın kullanıcıya ait olduğunu tanır ve oturuma kullanıcıyı erken bağlar, true döndürür ("acceptable")  
+3) İstemci imzalayamaz (private key yok), bu yüzden kimlik doğrulama parola yöntemine düşer  
+4) Parola doğrulaması oturumda zaten bir kullanıcı olduğunu görür ve koşulsuz olarak başarılı döner
+
+## Adım adım istismar
+
+- Hedefin kullanıcı adını ve public key'lerinden birini topla:
+- GitHub public key'leri şu adreste sunar: https://github.com/<username>.keys
+- Public sunucular genellikle authorized_keys’i açığa çıkarır
+- İmza oluşturma başarısız olacak şekilde OpenSSH’yi sadece public half’ı sunacak biçimde yapılandırarak, sunucuda public‑key kabul yolunu tetiklerken imzalama başarısızlığı nedeniyle kimlik doğrulamanın parola yöntemine düşmesini sağla.
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Bağlanın ve parola isteminde Enter tuşuna basın (veya herhangi bir dize yazın):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
+
+## Etki
+
+- Herhangi bir Gitblit kullanıcısının (en az bir kayıtlı SSH public key ile) tam taklidi
+- Hedef kullanıcının izinlerine göre depolara okuma/yazma erişimi (source exfiltration, yetkisiz pushes, supply‑chain riskleri)
+- Hedeflenen kullanıcı bir admin ise potansiyel yönetici etkisi
+- Tamamen ağ üzerinden sömürü; brute force veya private key gerektirmez
+
+## Tespit fikirleri
+
+- SSH logslarını inceleyin: bir publickey denemesi sonrası boş veya çok kısa bir parola ile başarılı bir password authentication olması durumlarını arayın
+- Aşağıdaki akışları arayın: unsupported/mismatched key material sunan publickey method’dan hemen sonra aynı kullanıcı adı için anında password başarısı
+
+## Önlemler
+
+- Gitblit'i v1.10.0+ sürümüne yükseltin
+- Yükseltilene kadar:
+- Gitblit üzerinde Git over SSH'yi devre dışı bırakın, veya
+- SSH servisine ağ erişimini kısıtlayın, ve
+- Yukarıda tanımlanan şüpheli desenleri izleyin
+- İhlal şüphesi varsa etkilenen kullanıcı kimlik bilgilerini değiştirin
+
+## Genel: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
+
+- Presenting a legitimate public key for the target user (no private key)
+- Forcing the client to fail signing so the server falls back to password
+- Supplying any password while the password authenticator short‑circuits on leaked state
+
+Practical tips:
+
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
+- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## Referanslar
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS, **Versiyon Kontrol Sistemi** anlamına gelir, bu sistemler geliştiricilerin **kaynak kodlarını yönetmelerine** olanak tanır. En yaygın olanı **git**'tir ve genellikle şirketlerin aşağıdaki **platformlardan** birinde kullandığını göreceksiniz:
+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
-- Bulut sağlayıcıları (kendi VCS platformlarını sunarlar)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
 
-## CI/CD Boru Hatları
 
-CI/CD boru hatları, geliştiricilerin çeşitli amaçlar için **kodun yürütülmesini otomatikleştirmelerine** olanak tanır; bunlar arasında uygulamaların inşası, test edilmesi ve dağıtılması yer alır. Bu otomatik iş akışları, **belirli eylemler** tarafından tetiklenir; örneğin kod itmeleri, çekme istekleri veya planlanmış görevler. Geliştirme sürecinden üretime geçişi kolaylaştırmak için faydalıdırlar.
+## CI/CD Pipelines
 
-Ancak, bu sistemlerin **bir yerde yürütülmesi** gerekir ve genellikle **kod dağıtmak veya hassas bilgilere erişmek için ayrıcalıklı kimlik bilgileri** ile çalışır.
+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.
 
-## VCS Pentesting Metodolojisi
+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]
-> Bazı VCS platformları bu bölüm için boru hatları oluşturulmasına izin verse de, yalnızca kaynak kodunun kontrolüne yönelik potansiyel saldırıları analiz edeceğiz.
+> 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 bilgiler barındırır ve insanlar bu platformda verilen izinlerle çok dikkatli olmalıdır. Saldırganların kötüye kullanabileceği bazı yaygın sorunlar şunlardır:
+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:
 
-- **Sızıntılar**: Kodunuzda taahhütlerde sızıntılar varsa ve saldırgan repo'ya erişebiliyorsa (çünkü kamuya açıktır veya erişimi vardır), sızıntıları keşfedebilir.
-- **Erişim**: Eğer bir saldırgan **VCS platformunda bir hesaba erişim sağlayabiliyorsa**, **daha fazla görünürlük ve izin** kazanabilir.
-- **Kayıt**: Bazı platformlar yalnızca dış kullanıcıların bir hesap oluşturmasına izin verir.
-- **SSO**: Bazı platformlar kullanıcıların kayıt olmasına izin vermez, ancak geçerli bir SSO ile erişim sağlar (bu nedenle bir saldırgan örneğin github hesabını kullanarak girebilir).
-- **Kimlik Bilgileri**: Kullanıcı adı+Şifre, kişisel tokenlar, ssh anahtarları, Oauth tokenları, çerezler... bir kullanıcının bir repo'ya erişmek için çalabileceği çeşitli token türleri vardır.
-- **Webhooks**: VCS platformları webhook'lar oluşturulmasına izin verir. Eğer bunlar **görünmeyen gizli anahtarlarla korunmuyorsa**, bir **saldırgan bunları kötüye kullanabilir**.
-- Eğer gizli bir anahtar yoksa, saldırgan üçüncü taraf platformun webhook'unu kötüye kullanabilir.
-- Eğer gizli anahtar URL'de ise, aynı şey olur ve saldırgan da gizli anahtara sahip olur.
-- **Kodun tehlikeye atılması:** Eğer kötü niyetli bir aktörün repo'lar üzerinde bir tür **yazma** erişimi varsa, **kötü niyetli kod enjekte etmeye** çalışabilir. Başarılı olmak için **dal korumalarını aşması** gerekebilir. Bu eylemler farklı hedeflerle gerçekleştirilebilir:
-- Ana dalı tehlikeye atmak, **üretimi tehlikeye atmak**.
-- Ana dalı (veya diğer dalları) tehlikeye atmak, **geliştirici makinelerini tehlikeye atmak** (çünkü genellikle test, terraform veya diğer şeyleri kendi makinelerinde repo içinde çalıştırırlar).
-- **Boru hattını tehlikeye atmak** (bir sonraki bölüme bakın).
+- **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)
 
-## Boru Hatları Pentesting Metodolojisi
+## Pipelines Pentesting Methodology
 
-Bir boru hattını tanımlamanın en yaygın yolu, boru hattının inşa edildiği **repo'da barındırılan bir CI yapılandırma dosyası** kullanmaktır. Bu dosya, yürütülen işlerin sırasını, akışı etkileyen koşulları ve yapı ortamı ayarlarını tanımlar.\
-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, boru hattı işi **seçilen kaynaktan kodu çeker** (örneğin taahhüt / dal) ve **CI yapılandırma dosyasında belirtilen komutları** o kod üzerinde çalıştırır.
+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 yapılandırma dosyalarını** veya **yürüttükleri komutları tehlikeye atmaktı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 - Zehirli Boru Hattı Yürütmesi
+### PPE - Poisoned Pipeline Execution
 
-Zehirli Boru Hattı Yürütmesi (PPE) yolu, bir SCM deposundaki izinleri kullanarak bir CI boru hattını manipüle etmek ve zararlı komutlar yürütmek için kullanılır. Gerekli izinlere sahip kullanıcılar, CI yapılandırma dosyalarını veya boru hattı işinin kullandığı diğer dosyaları kötü niyetli komutlar eklemek için değiştirebilir. Bu, CI boru hattını "zehirler" ve bu zararlı komutların yürütülmesine yol açar.
+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.
 
-Kötü niyetli bir aktörün PPE saldırısını başarılı bir şekilde gerçekleştirebilmesi için:
+Bir saldırganın PPE saldırısını başarılı şekilde gerçekleştirebilmesi için şunlara sahip olması gerekir:
 
-- **VCS platformuna yazma erişimine sahip olması** gerekir, çünkü genellikle boru hatları bir itme veya çekme isteği gerçekleştirildiğinde tetiklenir. (Erişim elde etme yolları için VCS pentesting metodolojisine bakın).
-- Bazen bir **dış PR'nin "yazma erişimi" olarak sayıldığını** unutmayın.
-- Yazma izinlerine sahip olsa bile, **CI yapılandırma dosyasını veya yapılandırmanın dayandığı diğer dosyaları değiştirebileceğinden emin olması** gerekir.
-- Bunun için **dal korumalarını aşabilmesi** gerekebilir.
+- 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.
 
-Üç PPE çeşidi vardır:
+3 PPE çeşidi vardır:
 
-- **D-PPE**: **Doğrudan PPE** saldırısı, aktörün **yürütülecek CI yapılandırma** dosyasını **değiştirdiği** durumdur.
-- **I-DDE**: **Dolaylı PPE** saldırısı, aktörün **yürütülecek CI yapılandırma dosyasının** **dayandığı** bir **dosyayı** **değiştirdiği** durumdur (örneğin bir make dosyası veya terraform yapılandırması).
-- **Halka Açık PPE veya 3PE**: Bazı durumlarda, boru hatları **repo'da yazma erişimi olmayan kullanıcılar tarafından tetiklenebilir** (ve bu kullanıcılar belki de organizasyonun bir parçası bile değildir) çünkü bir PR gönderebilirler.
-- **3PE Komut Enjeksiyonu**: Genellikle, CI/CD boru hatları **PR hakkında bilgi içeren ortam değişkenleri** **ayarlar**. Eğer bu değer bir saldırgan tarafından kontrol edilebiliyorsa (örneğin PR'nin başlığı gibi) ve **tehlikeli bir yerde** (örneğin **sh komutları** yürütmek gibi) **kullanılıyorsa**, bir saldırgan **orada komut enjekte edebilir**.
+- **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.
 
-### Kötüye Kullanım Faydaları
+### Exploitation Benefits
 
-Bir boru hattını zehirlemenin 3 çeşidini bildiğimizde, başarılı bir kötüye kullanım sonrasında bir saldırganın elde edebileceği şeylere bakalım:
+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:
 
-- **Gizli Bilgiler**: Daha önce belirtildiği gibi, boru hatları işlerinin (kodu almak, inşa etmek, dağıtmak...) **ayrıcalıklara** ihtiyaç duyar ve bu ayrıcalıklar genellikle **gizli bilgilerle** verilir. Bu gizli bilgiler genellikle **ortam değişkenleri veya sistem içindeki dosyalar** aracılığıyla erişilebilir. Bu nedenle, bir saldırgan her zaman mümkün olduğunca çok gizli bilgi sızdırmaya çalışacaktır.
-- Boru hattı platformuna bağlı olarak, saldırgan **gizli bilgileri yapılandırmada belirtmek zorunda kalabilir**. Bu, saldırgan CI yapılandırma boru hattını değiştiremiyorsa (**I-PPE** örneğin), yalnızca o boru hattının sahip olduğu gizli bilgileri **sızdırabileceği** anlamına gelir.
-- **Hesaplama**: Kod bir yerde yürütülür, nerede yürütüldüğüne bağlı olarak bir saldırgan daha ileriye geçebilir.
-- **Yerinde**: Eğer boru hatları yerinde yürütülüyorsa, bir saldırgan **daha fazla kaynağa erişimi olan bir iç ağa** girebilir.
-- **Bulut**: Saldırgan **buluttaki diğer makinelere** erişebilir, ancak ayrıca **IAM rolleri/hizmet hesapları** **tokenlarını** sızdırarak **bulut içinde daha fazla erişim** elde edebilir.
-- **Platform makineleri**: Bazen işler **boru hattı platform makineleri** içinde yürütülür, bu makineler genellikle **daha fazla erişim** olmadan bir bulut içindedir.
-- **Seçin:** Bazen **boru hattı platformu birkaç makineyi yapılandırmış olabilir** ve eğer **CI yapılandırma dosyasını değiştirebilirseniz**, kötü niyetli kodu nerede çalıştırmak istediğinizi **belirtebilirsiniz**. Bu durumda, bir saldırgan muhtemelen her olası makinede bir ters kabuk çalıştırarak daha fazla kötüye kullanmaya çalışacaktır.
-- **Üretimi tehlikeye atmak**: Eğer boru hattı içindeyseniz ve nihai versiyon buradan inşa edilip dağıtılıyorsa, **üretimde çalışacak kodu tehlikeye atabilirsiniz**.
+- **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**.
 
-## Daha Fazla İlgili Bilgi
+## More relevant info
 
-### Araçlar & CIS Benchmark
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench), yeni bir [**CIS Yazılım Tedarik Zinciri benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) temelinde güvenlik uyumluluğu için yazılım tedarik zinciri yığınınızı denetlemek için açık kaynaklı bir araçtır. Denetim, kod zamanından dağıtım zamanına kadar riskleri ortaya çıkarabileceği tüm SDLC sürecine odaklanır.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) bir açık kaynaklı araçtır ve yeni bir [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 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.
 
-### En İyi 10 CI/CD Güvenlik Riski
+### Top 10 CI/CD Security Risk
 
-Cider'a göre en iyi 10 CI/CD riski hakkında bu ilginç makaleyi kontrol edin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Cider'a göre en önemli 10 CI/CD riskini anlatan ilginç makaleye bakın: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
-### Laboratuvarlar
+### Labs
 
-- Yerel olarak çalıştırabileceğiniz her platformda, test etmek için istediğiniz gibi yapılandırabileceğiniz şekilde nasıl başlatılacağını bulacaksınız.
-- Gitea + Jenkins laboratuvarı: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- 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](https://github.com/cider-security-research/cicd-goat)
 
-### Otomatik Araçlar
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**, altyapı olarak kod için statik kod analizi aracıdır.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** infrastructure-as-code için bir static code analysis aracıdır.
 
-## Referanslar
+## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}