Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

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,103 +6,99 @@
 
 ## VCS
 
-VCS stands for **Version Control System**, this systems allows developers to **manage their source code**. The most common one is **git** and you will usually find companies using it in one of the following **platforms**:
+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**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- Cloud providers (they offer their own VCS platforms)
+- Cloud verskaffers (hulle bied hul eie VCS-platforms aan)
 
-## CI/CD Pipelines
+## CI/CD Pypelines
 
-CI/CD pipelines enable developers to **automate the execution of code** for various purposes, including building, testing, and deploying applications. These automated workflows are **triggered by specific actions**, such as code pushes, pull requests, or scheduled tasks. They are useful for streamlining the process from development to production.
+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.
 
-However, these systems need to be **executed somewhere** and usually with **privileged credentials to deploy code or access sensitive information**.
+Egter, hierdie stelsels moet **ergens uitgevoer word** en gewoonlik met **bevoorregte akrediteer om kode te ontplooi of toegang tot sensitiewe inligting te verkry**.
 
-## VCS Pentesting Methodology
+## VCS Pentesting Metodologie
 
 > [!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.
+> 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.
 
-Platforms that contains the source code of your project contains sensitive information and people need to be very careful with the permissions granted inside this platform. These are some common problems across VCS platforms that attacker could abuse:
+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 aanvallers kan misbruik:
 
-- **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**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**.
-  - **Register**: Some platforms will just allow external users to create an account.
-  - **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example).
-  - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo.
-- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**.
-  - 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:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid:
-  - Compromise the main branch to **compromise production**.
-  - Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines).
-  - **Compromise the pipeline** (check next section)
+- **Lekke**: As jou kode lekke 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 lekke 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)
 
-## Pipelines Pentesting Methodology
+## Pypelines Pentesting Metodologie
 
-The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\
-These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code.
+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 werksgeleenthede, toestande 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 wat onder .github/workflows geleë is. Wanneer geaktiveer, **trek die pypeline werk** die kode van die geselekteerde bron (bv. verbintenis / tak), en **voert die opdragte uit wat in die CI-konfigurasie lêer gespesifiseer is** teen daardie kode.
 
-Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**.
+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**.
 
-### PPE - Poisoned Pipeline Execution
+### PPE - Gevulde Pypeline Uitvoering
 
-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.
+Die Gevulde Pypeline Uitvoering (PPE) pad benut 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 werk gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vervuil" die CI-pypeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
 
-For a malicious actor to be successful performing a PPE attack he needs to be able to:
+Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy in staat wees om:
 
-- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
-  - Note that sometimes an **external PR count as "write access"**.
-- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
-  - For this, he might need to be able to **bypass branch protections**.
+- **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**.
 
-There are 3 PPE flavours:
+Daar is 3 PPE variasies:
 
-- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
-- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
-- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
-  - **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
+- **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** (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** met **inligting oor die PR** stel. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en is **gebruik** in 'n **gevaarlike plek** (soos die uitvoering van **sh opdragte**), kan 'n aanvaller **opdragte daar in spuit**.
 
-### Exploitation Benefits
+### Exploitatie Voordele
 
-Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
+Om die 3 variasies om 'n pypeline te vervuil te ken, laat ons kyk wat 'n aanvaller kan verkry na 'n suksesvolle eksploitatie:
 
-- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible.
-  - Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**.
-- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further.
-  - **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**.
-  - **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**.
-  - **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**.
-  - **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further.
-- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**.
+- **Geheime**: Soos voorheen genoem, vereis pypelines **bevoegdhede** vir hul werksgeleenthede (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 êrens 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**.
+- **Cloud**: Die aanvaller kan toegang verkry tot **ander masjiene in die cloud** maar kan ook **eksfiltreer** IAM rolle/dienste rekeninge **tokens** daarvan om **verdere toegang binne die cloud** te verkry.
+- **Platforms masjien**: Soms sal die werksgeleenthede binne die **pypelines platform masjiene** uitgevoer word, wat gewoonlik binne 'n cloud 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 **aangee 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**.
 
-## More relevant info
+## Meer relevante inligting
 
-### Tools & CIS Benchmark
+### Gereedskap & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
+- [**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.
 
-### Top 10 CI/CD Security Risk
+### Top 10 CI/CD Sekuriteitsrisiko's
 
-Check this interesting article about the top 10 CI/CD risks according to 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
+### Laboratoriums
 
-- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
-- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- 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)
 
-### Automatic Tools
+### Outomatiese Gereedskap
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is 'n statiese kode analise gereedskap vir infrastruktuur-as-kode.
 
-## References
+## Verwysings
 
 - [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}}
-
-
-
-