Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

2025-12-28 21:53:15 -08:00 · 2025-09-29 22:45:25 +00:00
parent ed8324f118
commit edf09c1980
2 changed files with 42 additions and 46 deletions
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
@@ -10,14 +10,13 @@ Für weitere Informationen:
 ../aws-services/aws-iam-enum.md
 {{#endref}}

-### Von IAM-Credentials zur Konsole
+### From IAM Creds to Console

-Wenn es Ihnen gelungen ist, einige IAM-Credentials zu erhalten, könnten Sie daran interessiert sein, **auf die Webkonsole zuzugreifen** mit den folgenden Tools.\
-Beachten Sie, dass der Benutzer/die Rolle die Berechtigung **`sts:GetFederationToken`** haben muss.
+Wenn Sie einige IAM-Anmeldedaten erlangt haben, möchten Sie möglicherweise die Webkonsole mit den folgenden Tools aufrufen. Hinweis: Der Benutzer/die Rolle muss die Berechtigung **`sts:GetFederationToken`** besitzen.

 #### Benutzerdefiniertes Skript

-Das folgende Skript verwendet das Standardprofil und einen Standard-AWS-Standort (nicht gov und nicht cn), um Ihnen eine signierte URL zu geben, die Sie verwenden können, um sich in der Webkonsole anzumelden:
+Das folgende Skript verwendet das Standard-Profil und einen Standard-AWS-Standort (nicht gov und nicht cn), um Ihnen eine signierte URL zu geben, die Sie zur Anmeldung in der Webkonsole verwenden können:
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -55,7 +54,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler

-Sie können **einen Webkonsole-Link generieren** mit [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
+Du kannst mit [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) einen **Link zur Web-Konsole generieren**.
 ```bash
 cd /tmp
 python3 -m venv env
@@ -64,22 +63,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> Stellen Sie sicher, dass der IAM-Benutzer die Berechtigung `sts:GetFederationToken` hat oder eine Rolle zum Übernehmen bereitstellt.
+> Stellen Sie sicher, dass der IAM-Benutzer die Berechtigung `sts:GetFederationToken` hat, oder stellen Sie eine Rolle zum Übernehmen bereit.

 #### aws-vault

-[**aws-vault**](https://github.com/99designs/aws-vault) ist ein Tool, um AWS-Anmeldeinformationen sicher zu speichern und in einer Entwicklungsumgebung darauf zuzugreifen.
+[**aws-vault**](https://github.com/99designs/aws-vault) ist ein Tool, um AWS-Zugangsdaten in einer Entwicklungsumgebung sicher zu speichern und darauf zuzugreifen.
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> Sie können auch **aws-vault** verwenden, um eine **Browser-Konsole-Sitzung** zu erhalten.
+> Sie können auch **aws-vault** verwenden, um eine **Browser-Konsolensitzung** zu erhalten

-### **Umgehung von User-Agent-Beschränkungen aus Python**
+### **Bypass User-Agent restrictions from Python**

-Wenn es eine **Einschränkung gibt, bestimmte Aktionen basierend auf dem verwendeten User-Agent** durchzuführen (wie die Einschränkung der Verwendung der Python boto3-Bibliothek basierend auf dem User-Agent), ist es möglich, die vorherige Technik zu verwenden, um **über einen Browser eine Verbindung zur Webkonsole herzustellen**, oder Sie könnten direkt den **boto3 User-Agent** ändern, indem Sie:
+Wenn eine **Einschränkung besteht, bestimmte Aktionen basierend auf dem verwendeten User-Agent auszuführen** (z. B. die Nutzung der python boto3 library basierend auf dem User-Agent zu beschränken), ist es möglich, die vorherige Technik zu verwenden, um **über einen Browser eine Verbindung zur Webkonsole herzustellen**, oder Sie können direkt den **boto3 User-Agent** wie folgt ändern:
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -92,4 +91,14 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
 # Perform the action
 response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
 ```
+### **`sts:GetFederationToken`**
+
+Mit dieser Berechtigung ist es möglich, eine föderierte Identität für den ausführenden Benutzer zu erstellen, beschränkt auf die Berechtigungen, die dieser Benutzer hat.
+```bash
+aws sts get-federation-token --name <username>
+```
+Das von sts:GetFederationToken zurückgegebene Token gehört zur föderierten Identität des aufrufenden Benutzers, hat jedoch eingeschränkte Berechtigungen. Selbst wenn der Benutzer Administratorrechte besitzt, können bestimmte Aktionen wie das Auflisten von IAM-Benutzern oder das Anhängen von Policies nicht über das föderierte Token ausgeführt werden.
+
+Außerdem ist diese Methode etwas unauffälliger, da der föderierte Benutzer nicht im AWS Portal erscheint; er kann nur über CloudTrail-Logs oder Überwachungstools beobachtet werden.
+
 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
@@ -6,9 +6,9 @@

 ### `sts:AssumeRole`

-Jede Rolle wird mit einer **Rollenvertrauensrichtlinie** erstellt, diese Richtlinie gibt an, **wer die erstellte Rolle übernehmen kann**. Wenn eine Rolle aus dem **gleichen Konto** angibt, dass ein Konto sie übernehmen kann, bedeutet das, dass das Konto Zugriff auf die Rolle (und potenziell **privesc**) haben wird.
+Jede Rolle wird mit einer **Rollen-Trust-Policy** erstellt; diese Richtlinie gibt an, **wer die erstellte Rolle übernehmen kann**. Wenn eine Rolle aus demselben **Account** angibt, dass ein Account sie übernehmen kann, bedeutet das, dass dieser Account auf die Rolle zugreifen kann (und potenziell **privesc**).

-Zum Beispiel zeigt die folgende Rollenvertrauensrichtlinie an, dass jeder sie übernehmen kann, daher wird **jeder Benutzer in der Lage sein, privesc** zu den mit dieser Rolle verbundenen Berechtigungen zu gelangen.
+Zum Beispiel zeigt die folgende Rollen-Trust-Policy, dass jeder sie übernehmen kann; daher **kann jeder Benutzer privesc** auf die mit dieser Rolle verbundenen Berechtigungen.
 ```json
 {
 "Version": "2012-10-17",
@@ -23,41 +23,22 @@ Zum Beispiel zeigt die folgende Rollenvertrauensrichtlinie an, dass jeder sie ü
 ]
 }
 ```
-Sie können eine Rolle übernehmen, die ausgeführt wird:
+Sie können eine Rolle übernehmen, indem Sie Folgendes ausführen:
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**Potenzielle Auswirkungen:** Privesc auf die Rolle.
+**Mögliche Auswirkung:** Privesc auf die Rolle.

 > [!CAUTION]
-> Beachten Sie, dass in diesem Fall die Berechtigung `sts:AssumeRole` **in der Rolle angegeben werden muss, die ausgenutzt werden soll** und nicht in einer Richtlinie, die dem Angreifer gehört.\
-> Mit einer Ausnahme, um **eine Rolle aus einem anderen Konto zu übernehmen**, muss das Angreiferkonto **auch** die **`sts:AssumeRole`** über die Rolle haben.
+> Beachte, dass in diesem Fall die Berechtigung `sts:AssumeRole` **in der Rolle, die missbraucht werden soll, angegeben sein muss** und nicht in einer Policy, die dem Angreifer gehört.\
+> Mit einer Ausnahme: um **eine Rolle aus einem anderen Account anzunehmen** benötigt das Angreiferkonto **ebenfalls** die **`sts:AssumeRole`** für diese Rolle.

-### **`sts:GetFederationToken`**

-Mit dieser Berechtigung ist es möglich, Anmeldeinformationen zu generieren, um jeden Benutzer zu impersonifizieren:
-```bash
-aws sts get-federation-token --name <username>
-```
-So kann diese Berechtigung sicher erteilt werden, ohne den Zugriff auf die Identität anderer Benutzer zu gewähren:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "VisualEditor0",
-"Effect": "Allow",
-"Action": "sts:GetFederationToken",
-"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
-}
-]
-}
-```
 ### `sts:AssumeRoleWithSAML`

-Eine Vertrauensrichtlinie mit dieser Rolle gewährt **Benutzern, die über SAML authentifiziert sind, Zugriff auf die Rolle zu impersonieren.**
+Eine Trust-Policy mit dieser Rolle gewährt **Benutzern, die via SAML authentifiziert sind, Zugriff, sich als diese Rolle auszugeben.**

-Ein Beispiel für eine Vertrauensrichtlinie mit dieser Berechtigung ist:
+Ein Beispiel für eine Trust-Policy mit dieser Berechtigung ist:
 ```json
 {
 "Version": "2012-10-17",
@@ -78,7 +59,7 @@ Ein Beispiel für eine Vertrauensrichtlinie mit dieser Berechtigung ist:
 ]
 }
 ```
-Um Anmeldeinformationen zu generieren, um die Rolle zu impersonieren, könnten Sie etwas wie Folgendes verwenden:
+Um credentials zu generieren, um eine role zu impersonate, könntest du im Allgemeinen so etwas verwenden:
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
@@ -86,13 +67,13 @@ Aber **Anbieter** könnten ihre **eigenen Tools** haben, um dies zu erleichtern,
 ```bash
 onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
 ```
-**Potenzielle Auswirkungen:** Privesc auf die Rolle.
+**Mögliche Auswirkung:** Privesc auf die Rolle.

 ### `sts:AssumeRoleWithWebIdentity`

-Diese Berechtigung gewährt die Erlaubnis, ein Set von temporären Sicherheitsanmeldeinformationen für **Benutzer, die in einer mobilen, Webanwendung, EKS...** mit einem Web-Identitätsanbieter authentifiziert wurden, zu erhalten. [Hier mehr erfahren.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+Diese Berechtigung erlaubt es, ein Set temporärer Sicherheitsanmeldeinformationen für **Benutzer, die in einer mobilen App, einer Webanwendung, EKS ... authentifiziert wurden** mit einem Web-Identity-Provider zu erhalten. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)

-Zum Beispiel, wenn ein **EKS-Dienstkonto** in der Lage sein sollte, **eine IAM-Rolle zu impersonifizieren**, wird es ein Token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** haben und kann **die Rolle annehmen und Anmeldeinformationen erhalten**, indem es etwas wie Folgendes tut:
+Zum Beispiel, wenn ein **EKS service account** in der Lage sein sollte, sich als **IAM role** auszugeben, hat er ein Token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** und kann die **Rolle übernehmen und Anmeldeinformationen erhalten**, indem er etwa Folgendes ausführt:
 ```bash
 aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
 # The role name can be found in the metadata of the configuration of the pod
@@ -105,9 +86,9 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/

 ### IAM Roles Anywhere Privesc

-AWS IAM RolesAnywhere ermöglicht es Workloads außerhalb von AWS, IAM-Rollen mithilfe von X.509-Zertifikaten zu übernehmen. Wenn die Vertrauensrichtlinien jedoch nicht ordnungsgemäß festgelegt sind, können sie für die Eskalation von Rechten missbraucht werden.
+AWS IAM RolesAnywhere ermöglicht Workloads außerhalb von AWS, IAM roles mit X.509 certificates zu übernehmen. Wenn trust policies jedoch nicht richtig eingeschränkt sind, können sie für privilege escalation missbraucht werden.

-Diese Richtlinie weist keine Einschränkungen auf, welche Vertrauensanker oder Zertifikatsattribute erlaubt sind. Infolgedessen kann jedes Zertifikat, das mit einem beliebigen Vertrauensanker im Konto verknüpft ist, verwendet werden, um diese Rolle zu übernehmen.
+Diese Policy enthält keine Beschränkungen, welche trust anchor oder certificate attributes erlaubt sind. Infolgedessen kann jedes Zertifikat, das an einen beliebigen trust anchor im Account gebunden ist, verwendet werden, um diese Rolle zu assume.
 ```json
 {
 "Version": "2012-10-17",
@@ -127,9 +108,9 @@ Diese Richtlinie weist keine Einschränkungen auf, welche Vertrauensanker oder Z
 }

 ```
-Um Privilegien zu eskalieren, wird der `aws_signing_helper` von https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html benötigt.
+Um privesc zu erreichen, wird der `aws_signing_helper` von https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html benötigt.

-Anschließend kann der Angreifer mit einem gültigen Zertifikat in die Rolle mit höheren Rechten wechseln.
+Anschließend kann der Angreifer mit einem gültigen Zertifikat in die höher privilegierte Rolle pivot.
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -138,7 +119,13 @@ aws_signing_helper credential-process \
 --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
 --role-arn arn:aws:iam::123456789012:role/Admin
 ```
-### Referenzen
+Der trust anchor validiert, dass das Client-Zertifikat `readonly.pem` von seiner autorisierten CA stammt. Als der trust anchor erstellt wurde, wurde das öffentliche Zertifikat der CA eingeschlossen (und wird jetzt zur Validierung von `readonly.pem` verwendet). Im Inneren von `readonly.pem` befindet sich der öffentliche Schlüssel, den AWS verwendet, um zu überprüfen, dass die Signatur mit dem korrespondierenden privaten Schlüssel `readonly.key` erzeugt wurde.
+
+Das Zertifikat beweist außerdem die Identität und liefert Attribute (wie CN oder OU), die das `default`-Profil in Tags umwandelt. Die Trust-Policy der Rolle kann diese Tags verwenden, um zu entscheiden, ob Zugriff autorisiert wird. Gibt es keine Bedingungen in der Trust-Policy, werden diese Tags ignoriert und jeder mit einem gültigen Zertifikat erhält Zugang.
+
+Damit dieser Angriff möglich ist, müssen sowohl der trust anchor als auch das `default`-Profil aktiv sein.
+
+### References

 - [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)