mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -1,10 +1,10 @@
|
||||
# Gitblit Güvenlik
|
||||
# Gitblit Güvenliği
|
||||
|
||||
{{#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.
|
||||
Gitblit, Java ile yazılmış kendi barındırılan bir Git sunucusudur. Tek başına bir JAR olarak veya servlet containers içinde çalıştırılabilir ve Git over SSH için gömülü bir SSH servisi (Apache MINA SSHD) ile birlikte gelir.
|
||||
|
||||
## Konular
|
||||
|
||||
|
||||
+40
-40
@@ -4,34 +4,34 @@
|
||||
|
||||
## Ö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.
|
||||
CVE-2024-28080, Apache MINA SSHD ile entegrasyon sırasında oturum durumunun yanlış işlenmesinden kaynaklanan Gitblit’in embedded SSH servisi içinde bir authentication bypass’ı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 public key’lerinden herhangi birini bilen bir saldırgan, private key ve parola olmadan authenticate olabilir.
|
||||
|
||||
- Etkilenen: Gitblit < 1.10.0 (1.9.3 üzerinde gözlemlendi)
|
||||
- Düzeltilen sürüm: 1.10.0
|
||||
- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
|
||||
- Fixed: 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)
|
||||
- Git over SSH örnekte etkinleştirilmiş olmalı
|
||||
- Hedef hesabın Gitblit üzerinde en az bir SSH public key’i kayıtlı olmalı
|
||||
- Saldırgan hedefin kullanıcı adını ve anahtarlarından birini bilmeli (çoğunlukla keşfedilebilir, ör. 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.
|
||||
RFC 4252’ye göre, public‑key authentication iki aşamada ilerler: sunucu önce sağlanan public key’in bir kullanıcı adı için kabul edilebilir olup olmadığını kontrol eder ve yalnızca bir challenge/response ile signature alındıktan sonra kullanıcıyı authenticate eder. MINA SSHD’de, PublickeyAuthenticator iki kere çağrılır: key acceptance aşamasında (henüz signature yok) ve daha sonra client signature’ı gönderdiğinde.
|
||||
|
||||
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.
|
||||
Gitblit’in PublickeyAuthenticator’ı ilk, imza öncesi çağrıda session bağlamını değiştirerek authenticate edilmiş UserModel’i session’a bağladı ve true döndürerek ("key acceptable") anahtarı kabul etti. Kimlik doğrulama daha sonra password’a döndüğünde, PasswordAuthenticator bu değiştirilmiş session durumuna güvendi ve parolayı doğrulamadan işlemi kısalttı, true döndürdü. Sonuç olarak, aynı kullanıcı için önceki bir public‑key "acceptance" sonrası herhangi bir parola (boş dahil) kabul edildi.
|
||||
|
||||
Yüksek seviyede hatalı akış:
|
||||
Yüksek seviyeli 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
|
||||
1) Client kullanıcı adı + public key sunar (henüz signature yok)
|
||||
2) Sunucu anahtarın kullanıcıya ait olduğunu tanır ve erken şekilde kullanıcıyı session’a iliştirir, true döner ("acceptable")
|
||||
3) Client sign yapamaz (private key yok), bu yüzden kimlik doğrulama password’a döner
|
||||
4) Password auth session’da zaten bir kullanıcı olduğunu görür ve koşulsuz olarak başarı döndürür
|
||||
|
||||
## Adım adım istismar
|
||||
## Adım‑adım exploitation
|
||||
|
||||
- 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.
|
||||
- Hedefin kullanıcı adını ve public key’lerinden birini topla:
|
||||
- GitHub public key’leri https://github.com/<username>.keys adresinde sunar
|
||||
- Genel sunucular sıklıkla authorized_keys’i açığa çıkarır
|
||||
- OpenSSH’i sadece public yarıyı sunacak şekilde yapılandırın, böylece signature üretimi başarısız olur; bu, server tarafında public‑key acceptance yolunu tetiklerken kimlik doğrulamanın password’a geri dönmesini zorlar.
|
||||
|
||||
Example SSH client config (no private key available):
|
||||
```sshconfig
|
||||
@@ -54,48 +54,48 @@ Authentication succeeds because the earlier public‑key phase mutated the sessi
|
||||
|
||||
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
|
||||
|
||||
## Etki
|
||||
## Etkiler
|
||||
|
||||
- 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)
|
||||
- En az bir kayıtlı SSH public key'e sahip herhangi bir Gitblit kullanıcısının tam taklidi
|
||||
- Kurbanın izinleri doğrultusunda depolara okuma/yazma erişimi (source exfiltration, unauthorized pushes, supply‑chain risks)
|
||||
- Hedeflenen kullanıcı bir admin ise potansiyel yönetici etkisi
|
||||
- Tamamen ağ üzerinden sömürü; brute force veya private key gerektirmez
|
||||
- Tamamen ağ üzerinden istismar; brute force veya private key gerekmez
|
||||
|
||||
## 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ı
|
||||
- SSH loglarını, publickey denemesinin ardından boş veya çok kısa bir parola ile başarılı bir password authentication görülen dizileri inceleyin
|
||||
- Aynı kullanıcı adı için publickey method'un unsupported/mismatched key material sunduğu ve hemen ardından parola ile doğrudan başarılı olunduğu akışları arayın
|
||||
|
||||
## Önlemler
|
||||
|
||||
- Gitblit'i v1.10.0+ sürümüne yükseltin
|
||||
- Yükseltilene kadar:
|
||||
- Yükseltme yapılana 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)
|
||||
## Genel: SSH auth method state‑leakage (MINA/OpenSSH‑based services) kötüye kullanımı
|
||||
|
||||
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:
|
||||
Desen: Eğer bir sunucunun public‑key authenticator'ı pre‑signature "key acceptable" aşamasında kullanıcı/oturum durumunu değiştirir ve diğer authenticators (ör. password) bu duruma güvenirse, kimlik doğrulamayı şu şekilde atlayabilirsiniz:
|
||||
|
||||
- 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
|
||||
- Hedef kullanıcı için meşru bir public key sunmak (private key yok)
|
||||
- İstemciyi imzalama başarısızlığına zorlayarak sunucunun password'a geri dönmesini sağlamak
|
||||
- Password authenticator, leaked state nedeniyle kısa devre yaparken herhangi bir password sunmak
|
||||
|
||||
Practical tips:
|
||||
Pratik ipuçları:
|
||||
|
||||
- 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
|
||||
- Büyük ölçekli public key toplama: https://github.com/<username>.keys, organizasyon dizinleri, takım sayfaları, leaked authorized_keys gibi yaygın kaynaklardan public key'leri çekin
|
||||
- İmzalama başarısızlığına zorlamak (istemci‑tarafı): IdentityFile'ı sadece .pub dosyasına işaret edin, IdentitiesOnly yes olarak ayarlayın, PreferredAuthentications'ın publickey sonra password'u içerecek şekilde kalmasını sağlayın
|
||||
- MINA SSHD entegrasyon tuzakları:
|
||||
- PublickeyAuthenticator.authenticate(...) signature doğrulama sonrası yol imzayı teyit edene kadar kullanıcı/oturum durumunu eklememelidir
|
||||
- PasswordAuthenticator.authenticate(...) önceki, tamamlanmamış bir authentication method sırasında değiştirilen herhangi bir durumdan başarı çıkarsaması yapmamalıdır
|
||||
|
||||
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
|
||||
İlgili protokol/tasarım notları ve literatür:
|
||||
- SSH userauth protokolü: RFC 4252 (publickey method iki‑aşamalı bir süreçtir)
|
||||
- Erken kabul oraklları ve auth yarışları üzerine tarihsel tartışmalar, örn. OpenSSH davranışı etrafındaki CVE‑2016‑20012 çekişmeleri
|
||||
|
||||
## Referanslar
|
||||
## References
|
||||
|
||||
- [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)
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## 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:
|
||||
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
|
||||
@@ -18,86 +18,86 @@ VCS, **Version Control System**'in kısaltmasıdır; bu sistemler geliştiricile
|
||||
|
||||
## 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.
|
||||
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 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.
|
||||
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]
|
||||
> 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.
|
||||
> 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 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:
|
||||
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 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.
|
||||
- **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 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)
|
||||
- **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'ı 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**.
|
||||
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**.
|
||||
|
||||
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.
|
||||
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'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.
|
||||
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 saldırganın PPE saldırısını başarılı şekilde gerçekleştirebilmesi için şunlara sahip olması gerekir:
|
||||
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 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.
|
||||
- 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 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.
|
||||
- **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
|
||||
|
||||
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:
|
||||
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 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**.
|
||||
- **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**](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.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/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**](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 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 riskini anlatan ilginç makaleye bakın: [**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 riski hakkında ilginç makaleyi inceleyin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](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
|
||||
- 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](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** infrastructure-as-code için bir static code analysis aracıdır.
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**, infrastructure-as-code için statik kod analizi yapan bir araçtır.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
ECS hakkında daha fazla **bilgi** için:
|
||||
Daha fazla **ECS hakkında bilgi** için:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,7 +12,7 @@ ECS hakkında daha fazla **bilgi** için:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
ECS'te `iam:PassRole`, `ecs:RegisterTaskDefinition` ve `ecs:RunTask` izinlerini kötüye kullanan bir saldırgan, metadata kimlik bilgilerini çalan **zararlı container** içeren **yeni bir task definition** oluşturup bunu **çalıştırabilir**.
|
||||
ECS'de `iam:PassRole`, `ecs:RegisterTaskDefinition` ve `ecs:RunTask` izinlerini kötüye kullanan bir saldırgan **yeni bir task definition oluşturabilir**, metadata kimlik bilgilerini çalan **kötü amaçlı bir container** ile bunu **çalıştırabilir**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
webhook oluşturmak için webhook.site gibi bir site kullanın
|
||||
webhook.site gibi bir site ile bir webhook oluşturun
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Doğrudan farklı bir ECS role privesc.
|
||||
**Olası Etki:** Farklı bir ECS role doğrudan privesc.
|
||||
|
||||
### `iam:PassRole`,`ecs:RunTask`
|
||||
Bir saldırgan `iam:PassRole` ve `ecs:RunTask` izinlerine sahipse, değiştirilmiş **execution role**, **task role** ve konteynerin **command** değerleriyle yeni bir ECS task başlatabilir. `ecs run-task` CLI komutu `--overrides` bayrağını içerir; bu bayrak, task definition'ı değiştirmeden çalışma zamanında `executionRoleArn`, `taskRoleArn` ve konteynerin `command` değerlerini değiştirmeye izin verir.
|
||||
`iam:PassRole` ve `ecs:RunTask` izinlerine sahip bir saldırgan, **execution role**, **task role** ve konteynerin **command** değerleri değiştirilmiş yeni bir ECS task'ı başlatabilir. `ecs run-task` CLI komutu `--overrides` flag'ini içerir; bu flag task definition ile oynamadan çalışma zamanında `executionRoleArn`, `taskRoleArn` ve konteynerin `command` değerlerini değiştirmeye izin verir.
|
||||
|
||||
Belirtilen IAM rollerinin `taskRoleArn` ve `executionRoleArn` için trust policy'sinde `ecs-tasks.amazonaws.com` tarafından üstlenilmesine izin vermesi gerekir.
|
||||
`taskRoleArn` ve `executionRoleArn` için belirtilen IAM rolleri, trust policy'lerinde `ecs-tasks.amazonaws.com` tarafından assume edilmesine izin verecek şekilde trust/allow içermelidir.
|
||||
|
||||
Ayrıca, saldırganın bilmesi gerekenler:
|
||||
- ECS cluster adı
|
||||
Ayrıca saldırganın bilmesi gerekir:
|
||||
- ECS cluster name
|
||||
- VPC Subnet
|
||||
- Security group (Eğer security group belirtilmezse varsayılan olan kullanılacaktır)
|
||||
- Task Definition adı ve revizyonu
|
||||
- Konteynerin adı
|
||||
- Security group (Belirtilmezse varsayılan security group kullanılacaktır)
|
||||
- Task Definition Name and revision
|
||||
- Name of the Container
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
Yukarıdaki kod kesitinde bir saldırgan yalnızca `taskRoleArn` değerini geçersiz kılıyor. Ancak, saldırının gerçekleşmesi için saldırganın komutta belirtilen `taskRoleArn` ve task tanımında belirtilen `executionRoleArn` üzerinde `iam:PassRole` iznine sahip olması gerekir.
|
||||
Yukarıdaki kod parçasında saldırgan yalnızca `taskRoleArn` değerini değiştirir. Ancak, saldırının gerçekleşmesi için saldırganın komutta belirtilen `taskRoleArn` ve task tanımında belirtilen `executionRoleArn` üzerinde `iam:PassRole` iznine sahip olması gerekir.
|
||||
|
||||
Eğer saldırganın pass edebildiği IAM rolünün ECR imajını çekmek ve ECS task'ını başlatmak için yeterli ayrıcalıkları varsa (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) saldırgan `ecs run-task` komutunda hem `executionRoleArn` hem de `taskRoleArn` için aynı IAM rolünü belirtebilir.
|
||||
Eğer saldırganın pass edebildiği IAM rolü ECR imajını çekmek ve ECS task'ını başlatmak için yeterli ayrıcalıklara sahipse (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) o zaman saldırgan `ecs run-task` komutunda hem `executionRoleArn` hem de `taskRoleArn` için aynı IAM rolünü belirleyebilir.
|
||||
```sh
|
||||
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
|
||||
{
|
||||
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
|
||||
]
|
||||
}'
|
||||
```
|
||||
**Olası Etki:** Herhangi bir ECS task role'a doğrudan privesc.
|
||||
**Potential Impact:** Herhangi bir ECS task role üzerinde doğrudan privesc.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Önceki örnekte olduğu gibi, bir saldırgan ECS'deki **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** izinlerini kötüye kullanarak metadata kimlik bilgilerini çalan bir **kötü amaçlı container** içeren yeni bir task definition **oluşturabilir** ve **çalıştırabilir**.\
|
||||
Ancak, bu durumda kötü amaçlı task definition'ı çalıştırmak için bir container instance'ın bulunması gerekir.
|
||||
Önceki örnekte olduğu gibi, ECS'te **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** izinlerini kötüye kullanan bir saldırgan, metadata kimlik bilgilerini çalan bir **malicious container** ile **yeni bir task definition oluşturabilir** ve **çalıştırabilir**.\
|
||||
Ancak, bu durumda, kötü amaçlı task definition'ı çalıştırmak için bir container instance gereklidir.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -144,9 +144,9 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
**Olası Etki:** Herhangi bir ECS rolüne doğrudan privesc.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Önceki örnekte olduğu gibi, ECS'de **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** veya **`ecs:CreateService`** izinlerini kötüye kullanan bir saldırgan, metadata kimlik bilgilerini çalan **zararlı bir container** içeren **yeni bir task definition** oluşturabilir ve **bunu en az 1 task çalışacak şekilde yeni bir service oluşturarak çalıştırabilir.**
|
||||
Önceki örnekte olduğu gibi, ECS'te **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** veya **`ecs:CreateService`** izinlerini kötüye kullanan bir saldırgan, **yeni bir task definition** oluşturup içinde metadata kimlik bilgilerini çalan **kötü amaçlı bir container** barındırabilir ve bunu **en az 1 task çalıştıracak şekilde yeni bir service oluşturarak çalıştırabilir.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
--service <SERVICE NAME> \
|
||||
--task-definition <NEW TASK DEFINITION NAME>
|
||||
```
|
||||
**Olası Etki:** Herhangi bir ECS rolüne doğrudan privesc.
|
||||
**Potential Impact:** Herhangi bir ECS rolüne doğrudan privesc.
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Aslında, sadece bu izinlerle overrides kullanarak herhangi bir role sahip bir container içinde rastgele komutları çalıştırmak mümkün; şöyle bir şeyle:
|
||||
Aslında, sadece bu izinlerle overrides kullanarak herhangi bir rol ile bir konteyner içinde keyfi komutlar çalıştırmak mümkün; şöyle bir şeyle:
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -181,16 +181,16 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**Potansiyel Etki:** Herhangi bir ECS rolüne doğrudan privesc.
|
||||
**Potential Impact:** Doğrudan herhangi bir ECS rolüne privesc.
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Bu senaryo önceki olanlara benzer fakat **`iam:PassRole`** izni **olmaksızın**.\
|
||||
Bu hâlâ ilginç çünkü role sahip olmasa bile rastgele bir container çalıştırabiliyorsanız, **run a privileged container to escape** yaparak node'a ulaşabilir ve **steal the EC2 IAM role** ile node üzerinde çalışan **other ECS containers roles**'ı çalabilirsiniz.\
|
||||
Hatta ele geçirdiğiniz EC2 instance içinde diğer görevleri çalıştırmaya **force other tasks to run inside the EC2 instance** zorlayarak onların kimlik bilgilerini çalabilirsiniz (detaylar [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) kısmında tartışıldığı gibi).
|
||||
Bu senaryo önceki olanlara benzer ancak **`iam:PassRole`** izni olmadan.\
|
||||
Bu hâlâ ilginç çünkü eğer rastgele bir container çalıştırabiliyorsanız, role olmadan olsa bile node'a kaçmak için **run a privileged container to escape** çalıştırıp node üzerinde çalışan **EC2 IAM role** ve diğer **ECS containers roles**'u çalabilirsiniz.\
|
||||
Hatta ele geçirdiğiniz EC2 instance içinde diğer task'ları çalıştırmaya **force other tasks to run inside the EC2 instance** zorlayarak onların kimlik bilgilerini çalabilirsiniz (detaylar için bkz. [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Bu saldırı yalnızca **ECS cluster is using EC2** instance'ları kullanıyorsa ve Fargate değilse mümkündür.
|
||||
> Bu saldırı yalnızca **ECS cluster is using EC2** instances ve Fargate yerine EC2 kullanılıyorsa mümkündür.
|
||||
```bash
|
||||
printf '[
|
||||
{
|
||||
@@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
**`ecs:ExecuteCommand`, `ecs:DescribeTasks`** izinlerine sahip bir saldırgan, çalışan bir konteyner içinde **komut çalıştırabilir** ve ona bağlı IAM rolünü exfiltrate edebilir (bunu yapmak için `aws ecs execute-command` komutunu çalıştırmak gerektiğinden describe izinlerine ihtiyaç vardır).\
|
||||
Ancak bunu yapabilmek için konteyner örneğinin **ExecuteCommand agent**'ı çalıştırıyor olması gerekir (varsayılan olarak çalışmaz).
|
||||
**`ecs:ExecuteCommand`, `ecs:DescribeTasks`** izinlerine sahip bir saldırgan, çalışan bir container içinde **komutlar çalıştırabilir** ve ona bağlı IAM rolünü dışarı aktarabilir (describe izinlerine ihtiyaç vardır çünkü `aws ecs execute-command` komutunu çalıştırmak için gereklidir).\
|
||||
Ancak bunu yapabilmek için, container örneğinin **ExecuteCommand agent**'ı çalıştırıyor olması gerekir (varsayılan olarak çalışmaz).
|
||||
|
||||
Bu nedenle saldırgan şunları deneyebilir:
|
||||
Bu yüzden saldırgan şunları deneyebilir:
|
||||
|
||||
- **Her çalışan konteynerde bir komut çalıştırmayı denemek**
|
||||
- **Her çalışan container'da bir komut çalıştırmayı denemek**
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -256,18 +256,18 @@ aws ecs execute-command --interactive \
|
||||
--cluster "$CLUSTER_ARN" \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- Eğer yetkide **`ecs:RunTask`** varsa, `aws ecs run-task --enable-execute-command [...]` ile bir task çalıştırın.
|
||||
- Eğer yetkide **`ecs:StartTask`** varsa, `aws ecs start-task --enable-execute-command [...]` ile bir task çalıştırın.
|
||||
- Eğer yetkide **`ecs:CreateService`** varsa, `aws ecs create-service --enable-execute-command [...]` ile bir service oluşturun.
|
||||
- Eğer yetkide **`ecs:UpdateService`** varsa, `aws ecs update-service --enable-execute-command [...]` ile bir service güncelleyin.
|
||||
- Eğer **`ecs:RunTask`** iznine sahipse, `aws ecs run-task --enable-execute-command [...]` ile bir task çalıştırın
|
||||
- Eğer **`ecs:StartTask`** iznine sahipse, `aws ecs start-task --enable-execute-command [...]` ile bir task çalıştırın
|
||||
- Eğer **`ecs:CreateService`** iznine sahipse, `aws ecs create-service --enable-execute-command [...]` ile bir service oluşturun
|
||||
- Eğer **`ecs:UpdateService`** iznine sahipse, `aws ecs update-service --enable-execute-command [...]` ile bir service güncelleyin
|
||||
|
||||
Bu seçeneklere ait **örnekleri** önceki **ECS privesc bölümlerinde** bulabilirsiniz.
|
||||
Bu seçeneklerin örneklerini **önceki ECS privesc bölümlerinde** bulabilirsiniz.
|
||||
|
||||
**Potansiyel Etki:** containers'a bağlı farklı bir role Privesc.
|
||||
**Potansiyel Etki:** Konteynerlere bağlı farklı bir role privesc.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
**ssm privesc page** üzerinde bu izni nasıl kötüye kullanarak **privesc to ECS** yapabileceğinizi kontrol edin:
|
||||
Bu izni nasıl kötüye kullanarak **ECS'e privesc** yapabileceğinizi görmek için **ssm privesc sayfasına** bakın:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
**ec2 privesc page** üzerinde bu izinleri nasıl kötüye kullanarak **privesc to ECS** yapabileceğinizi kontrol edin:
|
||||
Bu izinleri nasıl kötüye kullanıp **ECS'e privesc** yapabileceğinizi görmek için **ec2 privesc sayfasına** bakın:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
@@ -283,16 +283,16 @@ aws-ec2-privesc.md
|
||||
|
||||
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
|
||||
|
||||
Bu izinlere sahip bir saldırgan potansiyel olarak bir EC2 instance'ını bir ECS cluster'ına kaydedebilir ve üzerinde task'lar çalıştırabilir. Bu, saldırganın ECS task'larının bağlamı içinde keyfi kod çalıştırmasına izin verebilir.
|
||||
Bu izinlere sahip bir saldırgan, bir EC2 instance'ını bir ECS cluster'ına kayıt ettirip üzerinde task'lar çalıştırabilir. Bu, saldırganın ECS task'ları bağlamında rastgele kod yürütmesine izin verebilir.
|
||||
|
||||
- TODO: Farklı bir AWS hesabından bir instance kaydetmek ve böylece task'ların saldırganın kontrolündeki makineler üzerinde çalıştırılması mümkün mü??
|
||||
- TODO: Farklı bir AWS hesabından bir instance kaydetmek mümkün mü, böylece task'lar saldırganın kontrolündeki makineler üzerinde mi çalıştırılır??
|
||||
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Bunu test et
|
||||
> TODO: Test this
|
||||
|
||||
Bu izinlere sahip bir saldırgan **mevcut bir ECS servisi için kötü niyetli bir task set oluşturabilir ve primary task set'i update edebilir**. Bu, saldırganın servis içinde **keyfi kod çalıştırmasına** olanak tanır.
|
||||
Bu izinlere (`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, ve `ecs:DescribeTaskSets`) sahip bir saldırgan, mevcut bir ECS service için **zararlı bir task set oluşturup primary task set'i güncelleyebilir**. Bu, saldırganın **service içinde rastgele kod yürütmesine** olanak tanır.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -318,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
|
||||
# Update the primary task set for the service
|
||||
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
|
||||
```
|
||||
**Potential Impact**: Etkilenen hizmette keyfi code yürütülebilir; bu, hizmetin işlevselliğini etkileyebilir veya hassas verilerin exfiltrating yoluyla alınmasına neden olabilir.
|
||||
**Olası Etki**: Etkilenen serviste keyfi kod çalıştırılabilir; bu, işlevselliğini etkileyebilir veya hassas verilerin sızdırılmasına yol açabilir.
|
||||
|
||||
## Referanslar
|
||||
|
||||
|
||||
Reference in New Issue
Block a user