AWS - STS Privesc

Reading time: 5 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

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.

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.

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

Sie können eine Rolle übernehmen, die ausgeführt wird:

bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname

Potenzielle Auswirkungen: 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.

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.

Ein Beispiel für eine Vertrauensrichtlinie mit dieser Berechtigung ist:

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Um Anmeldeinformationen zu generieren, um die Rolle zu impersonieren, könnten Sie etwas wie Folgendes 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:

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.

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.

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:

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

Federation Abuse

AWS - Federation Abuse

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.

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.

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

Um Privilegien zu eskalieren, 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.

bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin

Referenzen

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