gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-31 15:05:44 -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-30 19:17:31 +00:00
parent 810e92b227
commit 78801b8061
1 changed files with 24 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
View File

@@ -6,9 +6,9 @@
### `sts:AssumeRole`
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**).
Jede Rolle wird mit einer **role trust policy** erstellt; diese Policy 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 Zugriff auf die Rolle (und potenziell **privesc**) erhalten wird.
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.
Zum Beispiel zeigt die folgende role trust policy an, dass jeder sie übernehmen kann; daher kann **jeder Benutzer privesc** auf die mit dieser Rolle verknüpften Berechtigungen durchführen.
```json
{
"Version": "2012-10-17",
@@ -23,22 +23,22 @@ Zum Beispiel zeigt die folgende Rollen-Trust-Policy, dass jeder sie übernehmen
]
}
```
Sie können eine Rolle übernehmen, indem Sie Folgendes ausführen:
Du kannst die Identität einer laufenden Rolle annehmen:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Mögliche Auswirkung:** Privesc auf die Rolle.
**Potential Impact:** Privesc auf die Rolle.
> [!CAUTION]
> 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.
> Beachte, dass in diesem Fall die Berechtigung `sts:AssumeRole` in der **zu missbrauchenden Rolle** angegeben sein muss und nicht in einer Policy, die dem attacker gehört.\
> Mit einer Ausnahme: Um **eine Rolle aus einem anderen Account zu übernehmen** muss das attacker account **ebenfalls** die **`sts:AssumeRole`** für die Rolle besitzen.
### `sts:AssumeRoleWithSAML`
Eine Trust-Policy mit dieser Rolle gewährt **Benutzern, die via SAML authentifiziert sind, Zugriff, sich als diese Rolle auszugeben.**
Eine trust policy mit dieser Rolle gewährt **Benutzern, die via SAML authentifiziert sind, Zugriff, die Rolle zu impersonate.**
Ein Beispiel für eine Trust-Policy mit dieser Berechtigung ist:
Ein Beispiel für eine trust policy mit dieser Berechtigung ist:
```json
{
"Version": "2012-10-17",
@@ -59,21 +59,21 @@ Ein Beispiel für eine Trust-Policy mit dieser Berechtigung ist:
]
}
```
Um credentials zu generieren, um eine role zu impersonate, könntest du im Allgemeinen so etwas verwenden:
Um Anmeldeinformationen zu generieren, um die Rolle zu übernehmen, könntest du im Allgemeinen so etwas verwenden:
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
Aber **Anbieter** könnten ihre **eigenen Tools** haben, um dies zu erleichtern, wie [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
Aber **Provider** könnten ihre **eigenen Tools** haben, um das zu erleichtern, wie [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
**Mögliche Auswirkung:** Privesc auf die Rolle.
**Mögliche Auswirkungen:** Privesc to the role.
### `sts:AssumeRoleWithWebIdentity`
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)
Diese Berechtigung erlaubt es, ein Set temporärer Sicherheitsanmeldeinformationen für **Benutzer, die in einer mobilen oder 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 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:
Zum Beispiel: Wenn ein **EKS service account** in der Lage sein soll, **impersonate an IAM role**, hat es ein Token unter **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** und kann **assume the role and get credentials**, indem es 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
@@ -86,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
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.
AWS IAM RolesAnywhere erlaubt Workloads außerhalb von AWS, IAM roles mittels X.509-Zertifikaten zu übernehmen. Werden trust policies jedoch nicht richtig eingeschränkt, können sie für privilege escalation missbraucht werden.
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.
Um diesen Angriff zu verstehen, muss erklärt werden, was ein trust anchor ist. Ein trust anchor in AWS IAM RolesAnywhere ist die root-of-trust-Entität; er enthält das öffentliche Zertifikat einer Certificate Authority (CA), die im Account registriert ist, sodass AWS die präsentierten X.509-Zertifikate validieren kann. Wenn das Client-Zertifikat von dieser CA ausgestellt wurde und der trust anchor aktiv ist, erkennt AWS es als gültig.
Außerdem ist ein profile die Konfiguration, die definiert, welche Attribute des X.509-Zertifikats (wie CN, OU oder SAN) in session tags umgewandelt werden, und diese Tags werden später mit den Bedingungen der trust policy verglichen.
Diese policy enthält keine Einschränkungen darüber, welche trust anchor oder Zertifikatattribute erlaubt sind. Infolgedessen kann jedes Zertifikat, das an irgendeinen trust anchor im Account gebunden ist, verwendet werden, um diese role zu assume.
```json
{
"Version": "2012-10-17",
@@ -108,9 +112,9 @@ Diese Policy enthält keine Beschränkungen, welche trust anchor oder certificat
}
```
Um privesc zu erreichen, wird der `aws_signing_helper` von https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html benötigt.
Für privesc 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 höher privilegierte Rolle pivot.
Anschließend kann der attacker mit einem gültigen Zertifikat in die höher privilegierte Rolle pivoten.
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -119,11 +123,11 @@ aws_signing_helper credential-process \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
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.
Der Vertrauensanker validiert, dass das Client-`readonly.pem`-Zertifikat von seiner autorisierten CA stammt, und in diesem `readonly.pem`-Zertifikat befindet sich der öffentliche Schlüssel, den AWS verwendet, um zu verifizieren, dass die Signatur mit dem entsprechenden privaten Schlüssel `readonly.key` erstellt 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.
Das Zertifikat liefert außerdem Attribute (wie CN oder OU), die das `default`-Profil in Tags umwandelt, welche die Vertrauensrichtlinie der Rolle nutzen kann, um zu entscheiden, ob Zugriff gewährt werden soll. Fehlen Bedingungen in der Vertrauensrichtlinie, sind diese Tags nutzlos und Zugriff wird jedem mit einem gültigen Zertifikat gewährt.
Damit dieser Angriff möglich ist, müssen sowohl der trust anchor als auch das `default`-Profil aktiv sein.
Damit dieser Angriff möglich ist, müssen sowohl der Vertrauensanker als auch das `default`-Profil aktiv sein.
### References