Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Metodologie
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars toe om **hulle bronkode te bestuur**. Die mees algemene een is **git** en jy sal gewoonlik maatskappye vind wat dit gebruik in een van die volgende **platforms**:
+VCS staan vir weergawebeheerstelsel (Version Control System); hierdie stelsels laat ontwikkelaars toe om hul bronkode te bestuur. Die mees algemene is **git** en jy sal gewoonlik maatskappye vind wat dit op een van die volgende **platforms** gebruik:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Wolkverskaffers (hulle bied hul eie VCS-platforms aan)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
 
-## CI/CD Pypelines
 
-CI/CD pypelines stel ontwikkelaars in staat om **die uitvoering van kode te outomatiseer** vir verskeie doeleindes, insluitend bou, toets en ontplooi van toepassings. Hierdie geoutomatiseerde werksvloei word **geaktiveer deur spesifieke aksies**, soos kode stoot, trek versoeke, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na produksie te stroomlyn.
+## CI/CD Pipelines
 
-Egter, hierdie stelsels moet **ergens uitgevoer word** en gewoonlik met **bevoorregte akrediteer om kode te ontplooi of toegang tot sensitiewe inligting te verkry**.
+CI/CD pipelines stel ontwikkelaars in staat om die uitvoering van kode te outomatiseer vir verskeie doeleindes, insluitende build, testing en deployment van toepassings. Hierdie geoutomatiseerde workflows word **getrigger deur spesifieke aksies**, soos code pushes, pull requests, of geskeduleerde take. Hulle help om die proses van development na production te stroomlyn.
 
-## VCS Pentesting Metodologie
+Hierdie stelsels moet egter **eers ergens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te deploy of sensitiewe inligting te bereik**.
+
+## VCS Pentesting Methodology
 
 > [!NOTE]
-> Alhoewel sommige VCS-platforms toelaat om pypelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode analiseer.
+> Selfs al laat sommige VCS platforms toe om pipelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle ontleed wat op die beheer van die bronkode fokus.
 
-Platforms wat die bronkode van jou projek bevat, bevat sensitiewe inligting en mense moet baie versigtig wees met die toestemmings wat binne hierdie platform toegestaan word. Dit is 'n paar algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
+Platforms wat die bronkode van jou projek bevat huisves sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne hierdie platform toegestaan word. Dit is 'n paar algemene probleme oor VCS platforms wat 'n aanvaller kan misbruik:
 
-- **Leaks**: As jou kode lekkasies in die verbintenisse bevat en die aanvaller toegang tot die repo kan verkry (omdat dit publiek is of omdat hy toegang het), kan hy die lekkasies ontdek.
-- **Toegang**: As 'n aanvaller **toegang tot 'n rekening binne die VCS-platform** kan verkry, kan hy **meer sigbaarheid en toestemmings** verkry.
-- **Registrasie**: Sommige platforms sal net eksterne gebruikers toelaat om 'n rekening te skep.
-- **SSO**: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigeen toelaat om toegang te verkry met 'n geldige SSO (so 'n aanvaller kan sy github-rekening gebruik om in te gaan byvoorbeeld).
-- **Akrediteer**: Gebruikersnaam+Pwd, persoonlike tokens, ssh sleutels, Oauth tokens, koekies... daar is verskeie tipes tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te verkry.
-- **Webhooks**: VCS-platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigtbare geheime nie, kan 'n **aanvaller dit misbruik**.
-- As daar geen geheim is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
-- As die geheim in die URL is, gebeur dieselfde en die aanvaller het ook die geheim.
-- **Kode kompromie:** As 'n kwaadwillige akteur 'n soort **skryf** toegang oor die repos het, kan hy probeer om **kwaadwillige kode in te spuit**. Om suksesvol te wees, mag hy moet **tak beskermings omseil**. Hierdie aksies kan met verskillende doelwitte in gedagte uitgevoer word:
-- Kompromitteer die hooftak om **produksie te kompromitteer**.
-- Kompromitteer die hoof (of ander takke) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik toets, terraform of ander dinge binne die repo op hul masjiene uitvoer).
-- **Kompromitteer die pypeline** (kyk na die volgende afdeling).
+- **Leaks**: As jou kode leak(s) in die commits bevat en die aanvaller toegang tot die repo het (omdat dit public is of omdat hy toegang het), kan hy die leak(s) ontdek.
+- **Access**: As 'n aanvaller **toegang tot 'n rekening binne die VCS platform** kan kry, kan hy **meer sigbaarheid en permissies** verkry.
+- **Register**: Sommige platforms sal net toelaat dat eksterne gebruikers 'n rekening skep.
+- **SSO**: Sommige platforms sal gebruikers nie toelaat om te registreer nie, maar sal enigiemand met 'n geldige SSO toegang gee (sodat 'n aanvaller byvoorbeeld sy github-rekening kan gebruik om in te gaan).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... daar is verskeie soorte tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te kry.
+- **Webhooks**: VCS platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigbare secrets nie, **kan 'n aanvaller dit misbruik**.
+- As geen geheim (secret) in plek is nie, kan die aanvaller die webhook van die derdeparty platform misbruik.
+- As die secret in die URL is, gebeur dieselfde en die aanvaller het ook die secret.
+- **Code compromise:** As 'n kwaadwillige akteur sekere vorme van **write** toegang oor die repos het, kan hy probeer om **malscode in te inspuit**. Om suksesvol te wees kan hy nodig hê om **branch protections te omseil**. Hierdie aksies kan met verskillende doelwitte uitgevoer word:
+  - Kompromiseer die main branch om **production te kompromitteer**.
+  - Kompromiseer die main (of ander branches) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik tests, terraform of ander dinge vanuit die repo op hul masjiene uitvoer).
+- **Compromise the pipeline** (kyk volgende afdeling)
 
-## Pypelines Pentesting Metodologie
+## Pipelines Pentesting Methodology
 
-Die mees algemene manier om 'n pypeline te definieer, is deur 'n **CI-konfigurasie lêer wat in die repo gehos is** te gebruik. Hierdie lêer beskryf die volgorde van uitgevoerde take, toestande wat die vloei beïnvloed, en bouomgewinginstellings.\
-Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers wat onder .github/workflows geleë is. Wanneer geaktiveer, **trek die pypeline-taak die kode** van die geselekteerde bron (bv. verbintenis / tak), en **voert die opdragte wat in die CI-konfigurasie lêer gespesifiseer is** teen daardie kode uit.
+Die mees algemene manier om 'n pipeline te definieer, is deur 'n **CI configuration file gehost in die repository** te gebruik wat die pipeline bou. Hierdie lêer beskryf die volgorde van uitgevoerde jobs, voorwaardes wat die vloei beïnvloed, en build-omgewinginstellings.\
+Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers onder .github/workflows. Wanneer dit getrigger word, die pipeline job **pulls the code** van die gekose bron (bv. commit / branch), en **voer die opdragte wat in die CI configuration file gespesifiseer is uit** teen daardie kode.
 
-Daarom is die uiteindelike doel van die aanvaller om op een of ander manier **daardie konfigurasie lêers** of die **opdragte wat hulle uitvoer** te **kompromitteer**.
+Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie configuration files of die opdragte wat hulle uitvoer, te **kompromiseer**.
 
-### PPE - Gevulde Pypeline Uitvoering
+### PPE - Poisoned Pipeline Execution
 
-Die Gevulde Pypeline Uitvoering (PPE) pad misbruik toestemmings in 'n SCM-repo om 'n CI-pypeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige toestemmings kan CI-konfigurasie lêers of ander lêers wat deur die pypeline-taak gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vervuil" die CI-pypeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
+Die Poisoned Pipeline Execution (PPE) pad misbruik permissies in 'n SCM repository om 'n CI pipeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige permissies kan CI configuration files of ander lêers wat deur die pipeline job gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vergiftig" die CI pipeline, wat lei tot die uitvoering van daardie kwaadwillige opdragte.
 
 Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy in staat wees om:
 
-- **Skryf toegang tot die VCS-platform** te hê, aangesien pypelines gewoonlik geaktiveer word wanneer 'n stoot of 'n trek versoek uitgevoer word. (Kyk na die VCS pentesting metodologie vir 'n opsomming van maniere om toegang te verkry).
-- Let daarop dat soms 'n **eksterne PR as "skryf toegang" tel**.
-- Selfs as hy skryf toestemmings het, moet hy seker wees dat hy die **CI konfigurasie lêer of ander lêers waarop die konfigurasie staatmaak** kan **wysig**.
-- Hiervoor mag hy moet in staat wees om **tak beskermings om te seil**.
+- Skryf toegang tot die VCS platform te hê, aangesien pipelines gewoonlik getrigger word wanneer 'n push of 'n pull request uitgevoer word. (Kyk die VCS pentesting methodology vir 'n opsomming van maniere om toegang te kry).
+- Let daarop dat soms 'n **eksterne PR as "write access" beskou kan word**.
+- Selfs as hy write permissions het, moet hy seker maak dat hy die **CI config file of ander lêers waarvan die config afhanklik is, kan wysig**.
+- Hiervoor mag hy nodig hê om **branch protections te omseil**.
 
-Daar is 3 PPE geure:
+Daar is 3 PPE-variante:
 
-- **D-PPE**: 'n **Direkte PPE** aanval vind plaas wanneer die akteur die **CI konfigurasie** lêer wat gaan uitgevoer word, **wysig**.
-- **I-DDE**: 'n **Indirekte PPE** aanval vind plaas wanneer die akteur 'n **lêer** wat die CI konfigurasie lêer wat gaan uitgevoer word, **afhang** van, **wysig** (soos 'n make-lêer of 'n terraform konfigurasie).
-- **Publieke PPE of 3PE**: In sommige gevalle kan die pypelines **geaktiveer word deur gebruikers wat nie skryf toegang in die repo het nie** (en wat dalk nie eens deel van die org is nie) omdat hulle 'n PR kan stuur.
-- **3PE Opdrag Inspuiting**: Gewoonlik sal CI/CD pypelines **omgewing veranderlikes stel** met **inligting oor die PR**. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en **gebruik** word in 'n **gevaarlike plek** (soos die uitvoering van **sh opdragte**), kan 'n aanvaller **opdragte daar in spuit**.
+- **D-PPE**: 'n **Direct PPE**-aanval vind plaas wanneer die akteur die **CI config** lêer wysig wat uitgevoer gaan word.
+- **I-DDE**: 'n **Indirect PPE**-aanval vind plaas wanneer die akteur 'n **lêer** wysig waarop die CI config lêer staatmaak (soos 'n make file of 'n terraform config).
+- **Public PPE or 3PE**: In sommige gevalle kan die pipelines **getrigger word deur gebruikers wat nie write access in die repo het nie** (en wat dalk nie eens deel van die org is nie) omdat hulle 'n PR kan stuur.
+- **3PE Command Injection**: Gewoonlik stel CI/CD pipelines **environment variables** met **inligting oor die PR**. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en dit **gebruik** word op 'n **gevaarlike plek** (soos om **sh commands** uit te voer), kan 'n aanvaller **opdragte daarin injekteer**.
 
-### Exploitatie Voordele
+### Exploitation Benefits
 
-Om die 3 geure te ken om 'n pypeline te vervuil, laat ons kyk wat 'n aanvaller kan verkry na 'n suksesvolle uitbuiting:
+Met die kennis van die 3 variante om 'n pipeline te vergiftig, kom ons kyk wat 'n aanvaller na 'n suksesvolle exploit kan bekom:
 
-- **Geheime**: Soos voorheen genoem, vereis pypelines **bevoegdhede** vir hul take (om die kode te verkry, dit te bou, dit te ontplooi...) en hierdie bevoegdhede word gewoonlik **in geheime toegestaan**. Hierdie geheime is gewoonlik toeganklik via **omgewing veranderlikes of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel geheime as moontlik te eksfiltreer.
-- Afhangende van die pypeline platform mag die aanvaller **die geheime in die konfigurasie moet spesifiseer**. Dit beteken dat as die aanvaller nie die CI konfigurasie pypeline kan wysig nie (**I-PPE** byvoorbeeld), kan hy **slegs die geheime wat daardie pypeline het, eksfiltreer**.
-- **Berekening**: Die kode word iewers uitgevoer, afhangende van waar dit uitgevoer word, mag 'n aanvaller in staat wees om verder te pivot.
-- **On-premises**: As die pypelines op plek uitgevoer word, mag 'n aanvaller eindig in 'n **interne netwerk met toegang tot meer hulpbronne**.
-- **Wolk**: Die aanvaller kan toegang verkry tot **ander masjiene in die wolk** maar kan ook **geheime** IAM rolle/dienste rekeninge **tokens** van dit eksfiltreer om **verdere toegang binne die wolk** te verkry.
-- **Platforms masjien**: Soms sal die take binne die **pypelines platform masjiene** uitgevoer word, wat gewoonlik binne 'n wolk met **geen verdere toegang** is.
-- **Kies dit:** Soms sal die **pypelines platform verskeie masjiene geconfigureer hê** en as jy die **CI konfigurasie lêer kan wysig**, kan jy **aan dui waar jy die kwaadwillige kode wil uitvoer**. In hierdie situasie sal 'n aanvaller waarskynlik 'n omgekeerde skulp op elke moontlike masjien uitvoer om te probeer om dit verder te exploiteer.
-- **Kompromitteer produksie**: As jy binne die pypeline is en die finale weergawe daaruit gebou en ontplooi word, kan jy **die kode wat in produksie gaan loop, kompromitteer**.
+- **Secrets**: Soos voorheen genoem, benodig pipelines **privileges** vir hul jobs (kode retrieve, build, deploy …) en hierdie privileges word gewoonlik **geberg as secrets**. Hierdie secrets is tipies toeganklik via **env variables of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel secrets as moontlik te exfiltrate.
+- Afhangend van die pipeline platform mag die aanvaller **die secrets in die config moet spesifiseer**. Dit beteken dat as die aanvaller die CI configuration pipeline nie kan wysig nie (**I-PPE** byvoorbeeld), hy **slegs die secrets kan exfiltrate wat daardie pipeline het**.
+- **Computation**: Die kode word iewers uitgevoer; afhangend waar dit uitgevoer word, kan 'n aanvaller verder kan pivoteer.
+- **On-Premises**: As die pipelines on-premises uitgevoer word, kan 'n aanvaller in 'n **interne netwerk met toegang tot meer hulpbronne** eindig.
+- **Cloud**: Die aanvaller kan toegang tot **ander masjiene in die cloud** kry, maar kan ook IAM roles/service accounts **tokens** exfiltrate om **verdere toegang binne die cloud** te verkry.
+- **Platforms machine**: Soms sal die jobs binne die **pipelines platform masjiene** uitgevoer word, wat gewoonlik binne 'n cloud sit met **geen addisionele toegang nie**.
+- **Select it:** Soms het die **pipelines platform verskeie masjiene gekonfigureer** en as jy die **CI configuration file** kan wysig, kan jy **indikeer waar jy die kwaadwillige kode wil laat loop**. In daardie geval sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien probeer laat loop om verdere eksploitasie te probeer.
+- **Compromise production**: As jy in die pipeline is en die finale weergawe daar gebou en deployed word, kan jy die kode wat uiteindelik in production sal loop, **kompromiseer**.
 
-## Meer relevante inligting
+## More relevant info
 
-### Gereedskap & CIS Benchmark
+### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n oopbron gereedskap vir die oudit van jou sagteware voorsieningsketting stap vir sekuriteits nakoming gebaseer op 'n nuwe [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die oudit fokus op die hele SDLC-proses, waar dit risiko's van kode tyd in ontplooi tyd kan onthul.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source hulpmiddel om jou software supply chain stack te oudit vir sekuriteitskompliance gebaseer op die nuwe [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die oudit fokus op die hele SDLC-proses, waar dit risiko's van kode tyd tot deploy tyd kan openbaar.
 
-### Top 10 CI/CD Sekuriteitsrisiko's
+### Top 10 CI/CD Security Risk
 
-Kyk na hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Kyk hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
-### Laboratoriums
+### Labs
 
-- Op elke platform wat jy plaaslik kan uitvoer, sal jy vind hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets.
-- Gitea + Jenkins laboratorium: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- Op elke platform wat jy lokaal kan laat loop, sal jy vind hoe om dit lokaal te loods sodat jy dit kan konfigureer soos jy wil toets.
+- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Outomatiese Gereedskap
+### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is 'n statiese kode analise gereedskap vir infrastruktuur-as-kode.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is 'n static code analysis tool vir infrastructure-as-code.
 
-## Verwysings
+## 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}}