German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - IAM Privesc

Unterstütze HackTricks

IAM

Finde mehr Informationen über IAM in:

GCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, eine dir zugewiesene Rolle zu aktualisieren und dir zusätzliche Berechtigungen für andere Ressourcen zu geben, wie:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

Sie können ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier finden und ein Python-Skript, um dieses Privileg hier auszunutzen. Für weitere Informationen siehe die ursprüngliche Forschung.

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, ein Zugriffstoken anzufordern, das zu einem Dienstkonto gehört, sodass es möglich ist, ein Zugriffstoken eines Dienstkontos mit mehr Berechtigungen als unserem anzufordern.

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

Sie finden ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript, um dieses Privileg auszunutzen hier. Für weitere Informationen überprüfen Sie die ursprüngliche Forschung.

iam.serviceAccountKeys.create

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, einen benutzerverwalteten Schlüssel für ein Dienstkonto zu erstellen, was uns den Zugriff auf GCP als dieses Dienstkonto ermöglicht.

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

Sie können ein Skript zur Automatisierung der Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier und ein Python-Skript zur Ausnutzung dieses Privilegs hier finden. Für weitere Informationen siehe die ursprüngliche Forschung.

Beachten Sie, dass iam.serviceAccountKeys.update nicht funktioniert, um den Schlüssel eines SA zu ändern, da dafür auch die Berechtigung iam.serviceAccountKeys.create erforderlich ist.

iam.serviceAccounts.implicitDelegation

Wenn Sie die iam.serviceAccounts.implicitDelegation Berechtigung für ein Service-Konto haben, das die iam.serviceAccounts.getAccessToken Berechtigung für ein drittes Service-Konto hat, können Sie implicitDelegation verwenden, um ein Token für dieses dritte Service-Konto zu erstellen. Hier ist ein Diagramm zur Erklärung.

Beachten Sie, dass laut der Dokumentation die Delegation von gcloud nur funktioniert, um ein Token mit der generateAccessToken() Methode zu generieren. Hier ist, wie Sie ein Token direkt über die API erhalten:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

You can find a script to automate the Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier and a python script to abuse this privilege hier. For more information check the ursprüngliche Forschung.

iam.serviceAccounts.signBlob

An attacker with the mentioned permissions will be able to beliebige Payloads in GCP zu signieren. So it'll be possible to ein unsigniertes JWT des SA zu erstellen und es dann als Blob zu senden, um das JWT vom SA, das wir anvisieren, signieren zu lassen. For more information lesen Sie dies.

You can find a script to automate the Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier and a python script to abuse this privilege hier and hier. For more information check the ursprüngliche Forschung.

iam.serviceAccounts.signJwt

An attacker with the mentioned permissions will be able to wohlgeformte JSON-Web-Token (JWTs) zu signieren. The difference with the previous method is that anstatt Google einen Blob, der ein JWT enthält, signieren zu lassen, verwenden wir die signJWT-Methode, die bereits ein JWT erwartet. This makes it easier to use but you can only sign JWT instead of any bytes.

You can find a script to automate the Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier and a python script to abuse this privilege hier. For more information check the ursprüngliche Forschung.

iam.serviceAccounts.setIamPolicy

An attacker with the mentioned permissions will be able to IAM-Richtlinien zu Dienstkonten hinzuzufügen. You can abuse it to sich selbst die Berechtigungen zu gewähren, die Sie benötigen, um das Dienstkonto zu impersonieren. In the following example we are granting ourselves the roles/iam.serviceAccountTokenCreator role over the interesting SA:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

You can find a script to automate the Erstellung, Ausnutzung und Bereinigung einer verwundbaren Umgebung hier.

iam.serviceAccounts.actAs

Die iam.serviceAccounts.actAs Berechtigung ist wie die iam:PassRole Berechtigung von AWS. Sie ist entscheidend für die Ausführung von Aufgaben, wie das Starten einer Compute Engine-Instanz, da sie die Fähigkeit gewährt, "als" ein Dienstkonto zu agieren, was eine sichere Berechtigungsverwaltung gewährleistet. Ohne dies könnten Benutzer unrechtmäßigen Zugriff erhalten. Darüber hinaus umfasst die Ausnutzung der iam.serviceAccounts.actAs verschiedene Methoden, von denen jede eine Reihe von Berechtigungen erfordert, im Gegensatz zu anderen Methoden, die nur eine benötigen.

Dienstkonto-Impersonation

Die Impersonation eines Dienstkontos kann sehr nützlich sein, um neue und bessere Berechtigungen zu erhalten. Es gibt drei Möglichkeiten, wie Sie ein anderes Dienstkonto impersonieren können:

  • Authentifizierung mit RSA-Privatschlüsseln (oben behandelt)

  • Autorisierung mit Cloud IAM-Richtlinien (hier behandelt)

  • Bereitstellung von Jobs auf GCP-Diensten (mehr anwendbar auf den Kompromiss eines Benutzerkontos)

iam.serviceAccounts.getOpenIdToken

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, ein OpenID JWT zu generieren. Diese werden verwendet, um die Identität zu bestätigen und tragen nicht unbedingt eine implizite Autorisierung gegenüber einer Ressource.

Laut diesem interessanten Beitrag ist es notwendig, das Publikum (Dienst, bei dem Sie das Token zur Authentifizierung verwenden möchten) anzugeben, und Sie erhalten ein von Google signiertes JWT, das das Dienstkonto und das Publikum des JWT angibt.

Sie können ein OpenIDToken generieren (wenn Sie den Zugriff haben) mit:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

Dann können Sie es einfach verwenden, um auf den Dienst zuzugreifen mit:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Einige Dienste, die die Authentifizierung über diese Art von Tokens unterstützen, sind:

Sie finden ein Beispiel, wie man ein OpenID-Token im Namen eines Dienstkontos erstellt hier.

Referenzen

Unterstützen Sie HackTricks
PreviousGCP - Deploymentmaneger PrivescNextGCP - KMS Privesc

Last updated