Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

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

@@ -0,0 +1,21 @@
+# Gitblit Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Gitblit ni nini
+
+Gitblit ni server ya Git inayojitegemea imeandikwa kwa Java. Inaweza kuendeshwa kama JAR huru au katika servlet containers na inaambatanisha huduma ya SSH iliyojengwa ndani (Apache MINA SSHD) kwa Git over SSH.
+
+## Mada
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Marejeo
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Muhtasari
+
+CVE-2024-28080 ni authentication bypass kwenye huduma ya embedded SSH ya Gitblit kutokana na kushughulikia vibaya state ya session wakati wa kuunganisha na Apache MINA SSHD. Ikiwa akaunti ya mtumiaji ina angalau ssh public key moja ilyosajiliwa, mwadui anayeijua jina la mtumiaji na moja ya public keys zao anaweza ku-authenticate bila private key na bila password.
+
+- Yaliyoathiriwa: Gitblit < 1.10.0 (observed on 1.9.3)
+- Imerekebishwa: 1.10.0
+- Mahitaji ya kutumia udhaifu:
+- Git over SSH imewezeshwa kwenye instance
+- Akaunti ya mwathirika ina angalau SSH public key moja iliyosajiliwa katika Gitblit
+- Mwadui anajua jina la mtumiaji wa mwathirika na moja ya public keys zao (mara nyingi inaweza kupatikana, kwa mfano, https://github.com/<username>.keys)
+
+## Sababu ya mzizi (state leaks between SSH methods)
+
+Kwenye RFC 4252, public‑key authentication hufanyika kwa awamu mbili: server kwanza huangalia kama public key iliyotolewa inakubalika kwa username, na tu baada ya changamoto/majibu yenye signature ndiyo inamthibitisha mtumiaji. Katika MINA SSHD, PublickeyAuthenticator huitwa mara mbili: wakati wa kukubaliwa kwa key (bado hakuna signature) na baadaye baada ya client kurudisha signature.
+
+PublickeyAuthenticator ya Gitblit ilibadilisha session context kwenye mwito wa kwanza, kabla ya signature, kwa kuambatisha UserModel iliyo authenticated kwenye session na kurudisha true ("key acceptable"). Wakati authentication baadaye ilipopungua hadi password, PasswordAuthenticator ilimtegemea state ya session iliyobadilishwa na kukata mzunguko, ikirudisha true bila kuthibitisha password. Matokeo yake, password yoyote (ikiwa ni pamoja na tupu) ilikubaliwa baada ya "kukubaliwa" kwa public‑key hapo awali kwa mtumiaji huyo huyo.
+
+Mtiririko wa juu ulio na kasoro:
+
+1) Client inapendekeza username + public key (bado hakuna signature)
+2) Server inatambua key kuwa ya mtumiaji na kwa mapema inaambatisha mtumiaji kwenye session, inarudisha true ("acceptable")
+3) Client hawezi kusaini (hakuna private key), hivyo auth inarudi nyuma hadi password
+4) Password auth inaona mtumiaji tayari amepo kwenye session na bila masharti inarudisha mafanikio
+
+## Utekelezaji hatua‑kwa‑hatua
+
+- Kusanya jina la mtumiaji wa mwathirika na moja ya public keys zao:
+- GitHub inaonyesha public keys kwenye https://github.com/<username>.keys
+- Server za umma mara nyingi zinaonyesha authorized_keys
+- Sanidi OpenSSH kuonyesha nusu ya umma pekee ili uzalishaji wa signature usifanye kazi, ukasababisha kuanguka hadi password ilhali bado ukisababisha njia ya kukubaliwa kwa public‑key kwenye server.
+
+Mfano wa config ya SSH client (hakuna private key inapatikana):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+Unganisha kisha bonyeza Enter kwenye onyo la nenosiri (au andika mfuatano wowote):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Authentication inafanyika kwa sababu awamu ya mapema ya public‑key ilibadilisha session kuwa mtumiaji aliyeidhinishwa, na password auth inaamini kwa makosa hali hiyo.
+
+Note: Ikiwa ControlMaster multiplexing imewezeshwa katika usanidi wako wa SSH, amri za baadaye za Git zinaweza kutumia tena muunganisho uliothibitishwa, ikiongeza athari.
+
+## Athari
+
+- Kupangiliwa kikamilifu kwa mtumiaji yeyote wa Gitblit ambaye ana angalau public key moja iliyosajiliwa
+- Ufikiaji wa kusoma/kuandika kwenye repositories kulingana na ruhusa za mwathirika (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Inaweza kuwa na athari za usimamizi ikiwa mtumiaji wa admin atalengwa
+- Pure network exploit; hakuna brute force au private key inahitajika
+
+## Mawazo ya kugundua
+
+- Pitia logi za SSH kwa mfululizo ambapo jaribio la publickey linafuatwa na password authentication iliyofanikiwa na password tupu au fupi sana
+- Tafuta mtiririko: publickey method inayotoa unsupported/mismatched key material ikifuatwa na mafanikio ya mara moja ya password kwa username ileile
+
+## Uzuiaji
+
+- Sasisha hadi Gitblit v1.10.0+
+- Hadi usasisho ufanyike:
+- Zima Git over SSH kwenye Gitblit, au
+- Zuia ufikiaji wa mtandao kwa huduma ya SSH, na
+- Fuatilia mifumo ya kushukiwa iliyoelezewa hapo juu
+- Badilisha credentials za watumiaji walioathirika ikiwa kushukiwa kwa kompromisi
+
+## General: kutumia vibaya SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Mfano: Ikiwa public‑key authenticator ya server inabadilisha user/session state wakati wa awamu ya pre‑signature "key acceptable" na authenticators wengine (mfano, password) wanaamini hali hiyo, unaweza kupitisha authentication kwa:
+
+- Kutoa public key halali kwa mtumiaji lengwa (hakuna private key)
+- Kulazimisha client kushindwa kusaini ili server irudi kwa password
+- Kutoa password yoyote wakati password authenticator inakata mzunguko kutokana na leaked state
+
+Vidokezo vya vitendo:
+
+- Public key harvesting kwa wingi: vunja public keys kutoka vyanzo vya kawaida kama https://github.com/<username>.keys, directory za shirika, kurasa za timu, leaked authorized_keys
+- Kulazimisha kushindwa kwa saini (client‑side): elekeza IdentityFile kwa .pub tu, weka IdentitiesOnly yes, na ushikilie PreferredAuthentications ijiunge publickey kisha password
+- Mapungufu ya integrasiyo ya MINA SSHD:
+- PublickeyAuthenticator.authenticate(...) haipaswi kuambatisha user/session state hadi njia ya post‑signature verification ithibitishe signature
+- PasswordAuthenticator.authenticate(...) haipaswi kubaini mafanikio kutokana na hali yoyote iliyobadilishwa wakati wa njia ya awali ya authentication ambayo haikuwa kamili
+
+Vidokezo na fasihi zinazohusiana na itifaki/usanifu:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Majadiliano ya kihistoria kuhusu early acceptance oracles na auth races, mfano CVE‑2016‑20012 kuhusu tabia ya OpenSSH
+
+## 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)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

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

@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS inamaanisha **Version Control System**, hizi mifumo inawawezesha waendelezaji **kusimamia msimbo wao wa chanzo**. Mmoja wa kawaida ni **git** na kawaida utaona kampuni zikilitumia katika moja ya **majukwaa** yafuatayo:
+VCS inamaanisha **Version Control System**, mfumo huu unawawezesha watengenezaji **kusimamia msimbo wao wa chanzo**. Ile inayotumika sana ni **git** na kawaida utapata kampuni zikitumia moja kati ya **platforms** zifuatazo:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Watoa huduma wa wingu (wanatoa majukwaa yao ya VCS)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
+
 
 ## CI/CD Pipelines
 
-CI/CD pipelines zinawawezesha waendelezaji **kujiandaa kutekeleza msimbo** kwa madhumuni mbalimbali, ikiwa ni pamoja na kujenga, kujaribu, na kupeleka programu. Mifumo hii ya kiotomatiki inachochewa na **vitendo maalum**, kama vile kusukuma msimbo, maombi ya kuvuta, au kazi zilizopangwa. Zinasaidia katika kuboresha mchakato kutoka kwa maendeleo hadi uzalishaji.
+CI/CD pipelines zinawawezesha watengenezaji **kuunda utekelezaji wa code kwa njia ya otomatiki** kwa madhumuni mbalimbali, ikijumuisha kujenga, kujaribu, na ku-deploy applications. Mifumo hii ya kazi za otomatiki huanzishwa kwa **vitendo maalum**, kama vile pushes za code, pull requests, au kazi zilizopangwa. Zinasaidia kurahisisha mchakato kutoka development hadi production.
 
-Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kawaida kwa **akidi za kibali ili kupeleka msimbo au kufikia taarifa nyeti**.
+Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kawaida kwa **credentials zenye ruhusa za juu ili ku-deploy code au kufikia taarifa nyeti**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Hata kama baadhi ya majukwaa ya VCS yanaruhusu kuunda pipelines kwa sehemu hii tutachambua tu mashambulizi yanayoweza kutokea kwenye udhibiti wa msimbo wa chanzo.
+> 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.
 
-Majukwaa yanayoshikilia msimbo wa mradi wako yana taarifa nyeti na watu wanahitaji kuwa makini sana na ruhusa zinazotolewa ndani ya jukwaa hili. Haya ni baadhi ya matatizo ya kawaida katika majukwaa ya VCS ambayo mshambuliaji anaweza kutumia:
+Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanapaswa kuwa makini sana na ruhusa zinazopewa ndani ya jukwaa hili. Hapa kuna matatizo ya kawaida kwenye VCS platforms ambayo mshambuliaji anaweza kuyatumia:
 
-- **Leaks**: Ikiwa msimbo wako una leaks katika commits na mshambuliaji anaweza kufikia repo (kwa sababu ni ya umma au kwa sababu ana ufikiaji), anaweza kugundua leaks.
-- **Access**: Ikiwa mshambuliaji anaweza **kufikia akaunti ndani ya jukwaa la VCS** anaweza kupata **nadharia zaidi na ruhusa**.
-- **Register**: Baadhi ya majukwaa yataruhusu tu watumiaji wa nje kuunda akaunti.
-- **SSO**: Baadhi ya majukwaa hayataruhusu watumiaji kujiandikisha, lakini yataruhusu mtu yeyote kufikia kwa SSO halali (hivyo mshambuliaji anaweza kutumia akaunti yake ya github kuingia kwa mfano).
-- **Credentials**: Jina la mtumiaji + Pwd, alama za kibinafsi, funguo za ssh, alama za Oauth, cookies... kuna aina kadhaa za alama ambazo mtumiaji anaweza kuiba ili kufikia kwa njia fulani repo.
-- **Webhooks**: Majukwaa ya VCS yanaruhusu kuunda webhooks. Ikiwa hazijalindwa na siri zisizoonekana mshambuliaji anaweza **kuzitumia vibaya**.
-- Ikiwa hakuna siri iliyowekwa, mshambuliaji anaweza kutumia vibaya webhook ya jukwaa la tatu
-- Ikiwa siri iko katika URL, jambo hilo linaweza kutokea na mshambuliaji pia ana siri hiyo
-- **Code compromise:** Ikiwa mhusika mbaya ana aina fulani ya **kuandika** ufikiaji juu ya repos, anaweza kujaribu **kuingiza msimbo mbaya**. Ili kufanikiwa anaweza kuhitaji **kuzidi ulinzi wa tawi**. Vitendo hivi vinaweza kufanywa kwa malengo tofauti:
-- Kuathiri tawi kuu ili **kuathiri uzalishaji**.
-- Kuathiri tawi kuu (au matawi mengine) ili **kuathiri mashine za waendelezaji** (kama kawaida wanatekeleza majaribio, terraform au mambo mengine ndani ya repo kwenye mashine zao).
-- **Kuathiri pipeline** (angalia sehemu inayofuata)
+- **Leaks**: Ikiwa msimbo wako una leaks katika commits na mshambuliaji anaweza kupata repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks.
+- **Access**: Ikiwa mshambuliaji anaweza **kupata akaunti ndani ya VCS platform** anaweza kupata **uwazi zaidi na ruhusa**.
+- **Register**: Baadhi ya platforms zitamruhusu mtumiaji wa nje kuunda akaunti tu.
+- **SSO**: Baadhi ya platforms hazitiruhusu watumiaji kujisajili, lakini zitamruhusu mtu yeyote kuingia kwa SSO halali (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 kufikia repo kwa njia fulani.
+- **Webhooks**: VCS platforms zinaruhusu kuunda webhooks. Ikiwa hazilindwa na secrets zisizoonekana mshambuliaji anaweza kuzivitumia.
+- 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 mhalifu ana aina yoyote ya **write** access kwenye repos, anaweza kujaribu **kuingiza malicious code**. Ili kufanikiwa anaweza kuhitaji **kukaidi branch protections**. Hili linaweza kufanywa kwa malengo tofauti:
+  - Kufanya compromise ya main branch ili **kuathiri production**.
+  - Kufanya compromise ya main (au matawi mengine) ili **kuathiri mashine za developers** (kwa kuwa mara nyingi wanatekeleza tests, terraform au vitu vingine ndani ya repo kwenye mashine zao).
+- **Compromise the pipeline** (angalia sehemu ifuatayo)
 
 ## Pipelines Pentesting Methodology
 
-Njia ya kawaida zaidi ya kufafanua pipeline, ni kwa kutumia **faili ya usanidi wa CI iliyohifadhiwa katika hazina** ambayo pipeline inajenga. Faili hii inaelezea mpangilio wa kazi zinazotekelezwa, masharti yanayoathiri mtiririko, na mipangilio ya mazingira ya kujenga.\
-Faili hizi kwa kawaida zina jina na muundo wa kawaida, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na faili za YAML za GitHub Actions zilizo chini ya .github/workflows. Wakati inachochewa, kazi ya pipeline **inavuta msimbo** kutoka chanzo kilichochaguliwa (k.m. commit / branch), na **inaendesha amri zilizotajwa katika faili ya usanidi wa CI** dhidi ya msimbo huo.
+Njia inayotumika zaidi kuainisha pipeline ni kwa kutumia **CI configuration file iliyohifadhiwa kwenye repository** ambayo pipeline inajenga. Faili hii inaelezea mpangilio wa jobs zinazotekelezwa, masharti yanayoathiri mtiririko, na mipangilio ya mazingira ya build.\
+Faili hizi mara nyingi zina majina na muundo uliokuwapo, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizomo chini ya .github/workflows. Wakati zinapoanzishwa, job ya pipeline **huchukua code** kutoka chanzo kilichochaguliwa (mfano commit / branch), na **hutekeleza amri zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo.
 
-Hivyo lengo kuu la mshambuliaji ni kwa namna fulani **kuathiri faili hizo za usanidi** au **amri wanazotekeleza**.
+Kwa hivyo lengo kuu la mshambuliaji ni kwa namna fulani **kufanya compromise kwa configuration files** hizo au **amri zinazotekelezwa**.
 
 ### PPE - Poisoned Pipeline Execution
 
-Njia ya Poisoned Pipeline Execution (PPE) inatumia ruhusa katika hazina ya SCM ili manipulative pipeline ya CI na kutekeleza amri hatari. Watumiaji wenye ruhusa zinazohitajika wanaweza kubadilisha faili za usanidi wa CI au faili nyingine zinazotumiwa na kazi ya pipeline ili kujumuisha amri mbaya. Hii "inasababisha sumu" pipeline ya CI, ikisababisha kutekelezwa kwa amri hizi mbaya.
+The Poisoned Pipeline Execution (PPE) path hutumia ruhusa katika SCM repository kuathiri CI pipeline na kutekeleza amri hatarishi. Watumiaji wenye ruhusa zinazohitajika wanaweza kubadilisha CI configuration files au faili nyingine zinazotumiwa na job ya pipeline ili kujumuisha amri za uharifu. Hii "inafanya toxic" pipeline, na kusababisha utekelezaji wa amri hizo hatarishi.
 
-Ili mhusika mbaya afanikiwe kufanya shambulio la PPE anahitaji kuwa na uwezo wa:
+Ili mhalifu afanikiwe kufanikisha shambulio la PPE anapaswa:
 
-- Kuwa na **ufikiaji wa kuandika kwenye jukwaa la VCS**, kwani kawaida pipelines zinachochewa wakati kusukuma au ombi la kuvuta linafanywa. (Angalia metodolojia ya pentesting ya VCS kwa muhtasari wa njia za kupata ufikiaji).
-- Kumbuka kwamba wakati mwingine **PR ya nje inachukuliwa kama "ufikiaji wa kuandika"**.
-- Hata kama ana ruhusa za kuandika, anahitaji kuwa na uhakika anaweza **kubadilisha faili ya usanidi wa CI au faili nyingine ambazo usanidi unategemea**.
-- Kwa hili, anaweza kuhitaji kuwa na uwezo wa **kuzidi ulinzi wa tawi**.
+- 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 ruhusa za kuandika, anahitaji kuwa ameweza **kubadilisha CI config file au faili nyingine ambayo config inategemea**.
+- Kwa hili, anaweza kuhitaji kukabiliana na **branch protections**.
 
-Kuna ladha 3 za PPE:
+Kuna aina 3 za PPE:
 
-- **D-PPE**: Shambulio la **Direct PPE** linatokea wakati mhusika anapobadilisha faili ya usanidi wa CI ambayo itatekelezwa.
-- **I-DDE**: Shambulio la **Indirect PPE** linatokea wakati mhusika anapobadilisha **faili** ambayo faili ya usanidi wa CI ambayo itatekelezwa **inategemea** (kama faili ya kutengeneza au usanidi wa terraform).
-- **Public PPE au 3PE**: Katika baadhi ya matukio pipelines zinaweza **kuchochewa na watumiaji ambao hawana ufikiaji wa kuandika katika repo** (na ambao huenda hata si sehemu ya shirika) kwa sababu wanaweza kutuma PR.
-- **3PE Command Injection**: Kawaida, pipelines za CI/CD zitakuwa **kweka mabadiliko ya mazingira** na **taarifa kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na mshambuliaji (kama kichwa cha PR) na inatumika katika **mahali hatari** (kama kutekeleza **amri za sh**), mshambuliaji anaweza **kuingiza amri hapo**.
+- **D-PPE**: A **Direct PPE** attack hutokea wakati muhusika **anabadilisha CI config** file ambayo itatekelezwa.
+- **I-DDE**: A **Indirect PPE** attack hutokea wakati muhusika **anabadilisha** faili ambayo CI config inategemea (kama make file au terraform config).
+- **Public PPE or 3PE**: Katika baadhi ya matukio pipelines zinaweza **kuanzishwa na watumiaji ambao hawana write access kwenye repo** (na ambao huenda hata sio 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 mshambuliaji (kama title ya PR) na inatumika katika sehemu hatarishi (kama kutekeleza sh commands), mshambuliaji anaweza **kuingiza amri ndani yake**.
 
 ### Exploitation Benefits
 
-Kujua ladha 3 za sumu pipeline, hebu tuangalie ni nini mshambuliaji anaweza kupata baada ya uhalifu wa mafanikio:
+Kutambua aina 3 za ku-poison pipeline, tuchunguze kile mshambuliaji anaweza kupata baada ya kufanikisha udukuzi:
 
-- **Secrets**: Kama ilivyotajwa hapo awali, pipelines zinahitaji **privileges** kwa kazi zao (kurejesha msimbo, kuujenga, kupeleka...) na ruhusa hizi kwa kawaida **zinatolewa katika siri**. Siri hizi kwa kawaida zinapatikana kupitia **mabadiliko ya mazingira au faili ndani ya mfumo**. Hivyo mshambuliaji daima atajaribu kuhamasisha siri nyingi kadri inavyowezekana.
-- Kulingana na jukwaa la pipeline mshambuliaji **anaweza kuhitaji kutaja siri katika usanidi**. Hii inamaanisha kwamba ikiwa mshambuliaji hawezi kubadilisha pipeline ya usanidi wa CI (**I-PPE** kwa mfano), anaweza **tu kuhamasisha siri ambazo pipeline hiyo ina**.
-- **Computation**: Msimbo unatekelezwa mahali fulani, kulingana na mahali unatekelezwa mshambuliaji anaweza kuwa na uwezo wa kuhamasisha zaidi.
-- **On-Premises**: Ikiwa pipelines zinatekelezwa kwenye premises, mshambuliaji anaweza kuishia katika **mtandao wa ndani wenye ufikiaji wa rasilimali zaidi**.
-- **Cloud**: Mshambuliaji anaweza kufikia **mashine nyingine katika wingu** lakini pia anaweza **kuhamasisha** alama za IAM/akaunti za huduma **tokens** kutoka kwake ili kupata **ufikiaji zaidi ndani ya wingu**.
-- **Platforms machine**: Wakati mwingine kazi zitatekelezwa ndani ya **mashine za jukwaa la pipelines**, ambazo kwa kawaida ziko ndani ya wingu bila **ufikiaji zaidi**.
-- **Select it:** Wakati mwingine **jukwaa la pipelines litakuwa limepanga mashine kadhaa** na ikiwa unaweza **kubadilisha faili ya usanidi wa CI** unaweza **kuashiria wapi unataka kutekeleza msimbo mbaya**. Katika hali hii, mshambuliaji labda atakimbia shell ya kurudi kwenye kila mashine inayowezekana kujaribu kuifanyia kazi zaidi.
-- **Compromise production**: Ikiwa uko ndani ya pipeline na toleo la mwisho linajengwa na kupelekwa kutoka kwake, unaweza **kuathiri msimbo ambao utaishia kutekelezwa katika uzalishaji**.
+- **Secrets**: Kama ilivyotajwa hapo juu, pipelines zinahitaji **privileges** kwa ajili ya jobs zao (kupata code, kuijenga, ku-deploy...) na privileges hizi mara nyingi huwekwa kama **secrets**. Secrets hizi kawaida zinapatikana kupitia **env variables au files ndani ya mfumo**. Hivyo mshambuliaji atajaribu kila mara ku-exfiltrate secrets nyingi iwezekanavyo.
+- Kulingana na jukwaa la pipeline, mshambuliaji **anaweza kuhitaji kubainisha secrets ndani ya config**. Hii ina maana kwamba ikiwa mshambuliaji hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **kutoa tu secrets ambazo pipeline hiyo inazo**.
+- **Computation**: Code inatekelezwa mahali fulani; kutegemea wapi inatekelezwa mshambuliaji anaweza kuweza kuendelea ku-pivot.
+- **On-Premises**: Ikiwa pipelines zinaendeshwa on-premises, mshambuliaji anaweza kuingia kwenye **internal network na upatikanaji wa rasilimali zaidi**.
+- **Cloud**: Mshambuliaji anaweza kufikia **mashine nyingine katika cloud** lakini pia anaweza **ku-exfiltrate** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**.
+- **Platforms machine**: Wakati mwingine jobs zinaendeshwa ndani ya **machines za pipelines platform**, ambazo kawaida ziko ndani ya cloud na zina **access ndogo zaidi**.
+- **Select it:** Wakati mwingine **pipelines platform itakuwa imepangwa kuendesha kwenye machines mbalimbali** na ukibadilisha CI configuration file unaweza **onyesha wapi unataka kuendesha code ya uharibifu**. Katika hali hii, mshambuliaji kawaida ataweka reverse shell kwenye kila machine inayowezekana ili kujaribu kuuza udhaifu zaidi.
+- **Compromise production**: Ikiwa uko ndani ya pipeline na version ya mwisho inajengwa na ku-deploy kutoka kwake, unaweza **kuathiri code itakayokwenda kuendesha production**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni zana ya chanzo wazi kwa ajili ya kukagua mnyororo wa usambazaji wa programu yako kwa ajili ya kufuata usalama 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). Ukaguzi unalenga mchakato mzima wa SDLC, ambapo unaweza kufichua hatari kutoka wakati wa msimbo hadi wakati wa kupeleka.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni zana ya open-source ya kukagua software supply chain stack yako kwa ulinganifu wa usalama 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). Ukaguzi unazingatia mchakato mzima wa SDLC, ambapo unaweza kufichua hatari kutoka wakati wa kuandika code hadi wakati wa ku-deploy.
 
 ### Top 10 CI/CD Security Risk
 
-Angalia makala hii ya kuvutia kuhusu hatari 10 bora za CI/CD 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 kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Kwenye kila jukwaa ambalo unaweza kukimbia kwa ndani utaona jinsi ya kulizindua ndani ili uweze kulipanga kama unavyotaka kulijaribu
+- Kwenye kila platform ambayo unaweza kuendesha kwa local utapata maelezo ya jinsi ya kuiendesha local ili uweze kuiweka 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 zana ya uchambuzi wa msimbo wa statiki kwa ajili ya miundombinu kama msimbo.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni zana ya static code analysis kwa ajili ya infrastructure-as-code.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}