AWS - STS Enum

Reading time: 4 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

STS

AWS Security Token Service (STS) ist hauptsächlich dafür konzipiert, temporäre, privilegierte Anmeldeinformationen auszustellen. Diese Anmeldeinformationen können für AWS Identity and Access Management (IAM)-Benutzer oder für authentifizierte Benutzer (federierte Benutzer) angefordert werden.

Da der Zweck von STS darin besteht, Anmeldeinformationen für Identitätsübernahme auszustellen, ist der Dienst äußerst wertvoll für Privilegieneskalation und Aufrechterhaltung der Persistenz, auch wenn er möglicherweise nicht über eine breite Palette von Optionen verfügt.

Assume Role Impersonation

Die Aktion AssumeRole, die von AWS STS bereitgestellt wird, ist entscheidend, da sie einem Principal erlaubt, Anmeldeinformationen für einen anderen Principal zu erwerben und ihn im Wesentlichen zu impersonieren. Bei der Ausführung antwortet sie mit einer Zugangs-ID, einem geheimen Schlüssel und einem Sitzungstoken, die dem angegebenen ARN entsprechen.

Für Penetration Tester oder Red Team-Mitglieder ist diese Technik entscheidend für die Privilegieneskalation (wie hier erläutert). Es ist jedoch erwähnenswert, dass diese Technik recht auffällig ist und einen Angreifer möglicherweise nicht unvorbereitet trifft.

Assume Role Logic

Um eine Rolle im selben Konto zu übernehmen, wenn die zu übernehmende Rolle speziell eine Rollen-ARN zulässt, wie in:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:role/priv-role"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}

Die Rolle priv-role muss in diesem Fall nicht speziell erlaubt sein, um diese Rolle zu übernehmen (mit dieser Erlaubnis ist es ausreichend).

Wenn jedoch eine Rolle einem Konto erlaubt, sie zu übernehmen, wie in:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}

Die Rolle, die versucht, übernommen zu werden, benötigt eine spezifische sts:AssumeRole-Berechtigung für diese Rolle, um sie zu übernehmen.

Wenn Sie versuchen, eine Rolle aus einem anderen Konto zu übernehmen, muss die übernommene Rolle dies erlauben (indem die Rolle ARN oder das externe Konto angegeben wird), und die Rolle, die versucht, die andere zu übernehmen, MUSS die Berechtigungen haben, um dies zu tun (in diesem Fall ist dies nicht optional, selbst wenn die übernommene Rolle eine ARN angibt).

Enumeration

bash
# Get basic info of the creds
aws sts get-caller-identity
aws sts get-access-key-info --access-key-id <AccessKeyID>

# Get CLI a session token with current creds
## Using CLI creds
## You cannot get session creds using session creds
aws sts get-session-token
## MFA
aws sts get-session-token --serial-number <arn_device> --token-code <otp_code>

Privesc

Auf der folgenden Seite können Sie überprüfen, wie man STS-Berechtigungen missbraucht, um Privilegien zu eskalieren:

AWS - STS Privesc

Post Exploitation

AWS - STS Post Exploitation

Persistence

AWS - STS Persistence

References

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks