AWS - STS Privesc

Reading time: 6 minutes

STS

sts:AssumeRole

Jede Rolle wird mit einer role trust policy erstellt; diese Policy gibt an, wer die erstellte Rolle übernehmen kann. Wenn eine Rolle aus dem gleichen Account angibt, dass ein Account sie übernehmen kann, bedeutet das, dass der Account auf die Rolle zugreifen kann (und möglicherweise privesc).

Zum Beispiel zeigt die folgende role trust policy, dass jeder sie übernehmen kann; daher wird jeder Benutzer in der Lage sein, privesc zu den mit dieser Rolle verbundenen Berechtigungen durchzuführen.

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

Du kannst eine Rolle übernehmen, die ausgeführt wird:

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

Potentielle Auswirkungen: Privesc auf die Rolle.

sts:AssumeRoleWithSAML

Eine Trust-Policy für diese Rolle gewährt SAML-authentifizierten Benutzern Zugriff, die Rolle zu übernehmen.

Ein Beispiel für eine Trust-Policy mit dieser Berechtigung ist:

{
"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, mit denen Sie die Rolle übernehmen können, könnten Sie allgemein Folgendes verwenden:

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:

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.

sts:AssumeRoleWithWebIdentity

Diese Berechtigung erlaubt es, ein Set temporärer Sicherheitsanmeldeinformationen für Benutzer, die in einer mobilen, Webanwendung, EKS... authentifiziert wurden von einem Web-Identity-Provider zu erhalten. Learn more here.

Zum Beispiel: Wenn ein EKS service account sich als IAM-Rolle ausgeben können soll, hat er ein Token in /var/run/secrets/eks.amazonaws.com/serviceaccount/token und kann die Rolle übernehmen und Anmeldeinformationen erhalten, indem er so etwas ausführt:

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 Roles Anywhere ermöglicht Workloads außerhalb von AWS, IAM roles mithilfe von X.509-Zertifikaten zu übernehmen. Wenn trust policies jedoch nicht richtig eingeschränkt sind, können sie für privilege escalation missbraucht werden.

Um diesen Angriff zu verstehen, muss erklärt werden, was ein trust anchor ist. Ein trust anchor in AWS IAM Roles Anywhere 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 vorgelegten X.509-Zertifikate validieren kann. Auf diese Weise erkennt AWS ein client certificate als gültig an, wenn es von dieser CA ausgestellt wurde und der trust anchor aktiv ist.

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 später mit den Bedingungen der trust policy verglichen werden.

Diese Policy enthält keine Beschränkungen, welche trust anchors oder Zertifikatattribute zugelassen sind. Folglich kann jedes Zertifikat, das an einen beliebigen trust anchor im Account gebunden ist, verwendet werden, um diese Rolle zu assume.

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

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 eine Rolle mit höheren Rechten pivot.

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

Der Vertrauensanker verifiziert, dass das Client-readonly.pem-Zertifikat von seiner autorisierten CA stammt, und innerhalb dieses readonly.pem-Zertifikats befindet sich der öffentliche Schlüssel, den AWS verwendet, um zu prüfen, dass die Signatur mit dem entsprechenden privaten Schlüssel readonly.key erstellt wurde.

Das Zertifikat liefert außerdem Attribute (wie CN oder OU), die das default-Profil in Tags umwandelt, welche die Trust-Policy der Rolle verwenden kann, um zu entscheiden, ob Zugriff autorisiert wird. Wenn in der Trust-Policy keine Bedingungen definiert sind, 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 Vertrauensanker als auch das default-Profil aktiv sein.

References

• https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation