Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD Metodologie
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-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:
+VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars toe om **hul bronkode te bestuur**. Die algemeenste is **git** en gewoonlik sal maatskappye dit op een van die volgende **platforms** gebruik:
 
 - Github
 - Gitlab
@@ -18,81 +18,81 @@ VCS staan vir weergawebeheerstelsel (Version Control System); hierdie stelsels l
 
 ## CI/CD Pipelines
 
-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.
+CI/CD pipelines stel ontwikkelaars in staat om die uitvoering van kode te **outomatiseer** vir verskeie doeleindes, insluitend bou, toetsing en uitrol van toepassings. Hierdie outomatiese workflows word **geaktiveer deur spesifieke aksies**, soos code pushes, pull requests of geskeduleerde take. Hulle help om die proses van ontwikkeling na produksie te stroomlyn.
 
-Hierdie stelsels moet egter **eers ergens uitgevoer word** en gewoonlik met **bevoorregte credentials om kode te deploy of sensitiewe inligting te bereik**.
+Hierdie stelsels moet egter **êrens uitgevoer word** en gewoonlik met **geprivilegieerde inlogbewyse om kode te deploy of toegang tot sensitiewe inligting te kry**.
 
-## VCS Pentesting Methodology
+## VCS Pentesting Metodologie
 
 > [!NOTE]
-> 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.
+> Selfs al laat sommige VCS-platforms toe om pipelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode ontleed.
 
-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:
+Platforme wat die bronkode van jou projek huisves, bevat sensitiewe inligting en mense moet baie versigtig wees met die permissies wat binne hierdie platform toegeken word. Dit is 'n paar algemene probleme oor VCS-platforms wat 'n aanvaller kan misbruik:
 
-- **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)
+- **Leaks**: As jou kode leaks in die commits bevat en die aanvaller toegang tot die repo het (omdat dit publiek is of omdat hy toegang het), kan hy die leaks ontdek.
+- **Access**: As 'n aanvaller toegang tot 'n rekening binne die VCS-platform kry, kan hy **meer sigbaarheid en permissies** bekom.
+- **Register**: Sommige platforme sal bloot eksterne gebruikers toelaat om 'n rekening te skep.
+- **SSO**: Sommige platforme laat nie gebruikers toe om te registreer nie, maar laat enigiemand toe om aan te meld met 'n geldige SSO (so 'n aanvaller kan byvoorbeeld sy GitHub-rekening gebruik om toegang te kry).
+- **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 by 'n repo in te teken.
+- **Webhooks**: VCS-platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigbare secrets nie, **kan 'n aanvaller dit misbruik**.
+- 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:** As 'n kwaadwillige akteur enige soort **write** toegang oor die repos het, kan hy probeer om **skadelike kode te inject**. Om sukses te hê, mag hy die **branch protections** moet omseil. Hierdie aksies kan met verskillende doelwitte uitgevoer word:
+  - Kompromiseer die main branch om **produksie te compromise**.
+  - Kompromiseer die main (of ander branches) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik toetse, terraform of ander take binne die repo op hul masjiene uitvoer).
+- **Compromise the pipeline** (check next section)
 
-## Pipelines Pentesting Methodology
+## Pipelines Pentesting Metodologie
 
-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.
+Die mees algemene manier om 'n pipeline te definieer, is deur 'n **CI configuration file hosted in the repository** wat die pipeline bou. Hierdie lêer beskryf die volgorde van uitgevoerde jobs, kondisies wat die vloei beïnvloed, en bou-omgewing instellings.\
+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 geaktiveer word, die pipeline job **pulls the code** vanaf die gekose bron (bv. commit / branch), en **runs the commands specified in the CI configuration file** teen daardie kode.
 
-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**.
+Dus is die uiteindelike doel van die aanvaller om op een of ander manier daardie configuration files of die commands wat hulle uitvoer, te **kompromiseer**.
 
 ### PPE - Poisoned Pipeline Execution
 
-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.
+Die Poisoned Pipeline Execution (PPE) pad misbruik permissies in 'n SCM repository om 'n CI pipeline te manipuleer en skadelike commands 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 commands in te sluit. Dit “vergiftig” die CI pipeline, wat lei tot die uitvoering van daardie kwaadwillige commands.
 
 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 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**.
+- Wees in besit van **write access to the VCS platform**, aangesien pipelines gewoonlik geaktiveer word wanneer 'n push of 'n pull request uitgevoer word. (Kyk die VCS pentesting metodologie vir 'n opsomming van maniere om toegang te kry).
+- Let daarop dat soms 'n **external PR** as "write access" tel.
+- Selfs as hy write permissions het, moet hy seker maak dat hy die **CI config file of ander lêers waarop die config staatmaak** kan wysig.
+- Hiervoor mag hy die **branch protections** moet kan omseil.
 
-Daar is 3 PPE-variante:
+Daar is 3 PPE flavours:
 
-- **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**.
+- **D-PPE**: 'n **Direct PPE** aanval gebeur wanneer die akteur die **CI config** lêer wysig wat uitgevoer gaan word.
+- **I-DDE**: 'n **Indirect PPE** aanval gebeur wanneer die akteur 'n **lêer wysig** waarop die CI config lêer vertrou (soos 'n make file of 'n terraform config).
+- **Public PPE or 3PE**: In sommige gevalle kan pipelines **geaktiveer word deur gebruikers wat geen write access tot die repo het nie** (en wat moontlik 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 in 'n **gevaarlike plek** gebruik word (bv. by die uitvoering van **sh commands**), kan 'n aanvaller **commands daarin inject**.
 
 ### Exploitation Benefits
 
-Met die kennis van die 3 variante om 'n pipeline te vergiftig, kom ons kyk wat 'n aanvaller na 'n suksesvolle exploit kan bekom:
+As ons die 3 flavours ken om 'n pipeline te vergiftig, kom ons kyk watter voordele 'n aanvaller uit 'n suksesvolle uitbuiting kan trek:
 
-- **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**.
+- **Secrets**: Soos voorheen genoem, vereis pipelines **privileges** vir hul jobs (kode ophaal, bou, deploy, ens.) en hierdie privileges word gewoonlik in **secrets** gehou. 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 eksfiltreer.
+- Afhangend van die pipeline platform mag die aanvaller **moet spesifiseer watter secrets in die config is**. Dit beteken dat as die aanvaller nie die CI configuration pipeline kan wysig nie (**I-PPE** byvoorbeeld), hy slegs die secrets wat daardie pipeline het, kan eksfiltreer.
+- **Computation**: Die kode word êrens uitgevoer; afhangend van waar dit uitgevoer word, kan 'n aanvaller verder kan pivot.
+- **On-Premises**: As die pipelines on-premises uitgevoer word, kan 'n aanvaller binnekant 'n **interne netwerk met toegang tot meer hulpbronne** beland.
+- **Cloud**: Die aanvaller kan toegang kry tot **ander masjiene in die cloud**, maar ook IAM roles/service accounts **tokens** eksfiltreer om verdere toegang in die cloud te kry.
+- **Platforms machine**: Soms word jobs in die **pipelines platform machines** uitgevoer, wat gewoonlik in 'n cloud is met **geen verdere toegang**.
+- **Select it:** Soms het die **pipelines platform verskeie masjiene gekonfigureer** en as jy die **CI configuration file kan wysig**, kan jy aandui waar jy die skadelike kode wil laat loop. In daardie situasie sal 'n aanvaller waarskynlik 'n reverse shell op elke moontlike masjien hardloop om verdere eksploitasie te probeer.
+- **Compromise production**: As jy binne die pipeline is en die finale weergawe vanaf dit gebou en uitgerol word, kan jy die kode wat uiteindelik in produksie gaan hardloop, **kompromiseer**.
 
-## More relevant info
+## Meer relevante inligting
 
 ### Tools & CIS Benchmark
 
-- [**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.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n open-source hulpmiddel om jou software supply chain stack te oudit vir sekuriteit-nakomingsdoeleindes 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 code-tyd tot deploy-tyd kan blootlê.
 
 ### Top 10 CI/CD Security Risk
 
-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/)
+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/)
 
 ### Labs
 
-- 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.
+- Op elke platform wat jy lokaal kan laat loop, sal jy vind hoe om dit lokaal te begin sodat jy dit kan konfigureer soos jy wil om te toets
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools