GCP - IAM Privesc

Reading time: 9 minutes

IAM

Finden Sie weitere Informationen zu IAM in:

GCP - IAM, Principals & Org Policies Enum

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

Ein Angreifer mit den genannten Berechtigungen kann eine Ihnen zugewiesene Rolle aktualisieren und Ihnen zusätzliche Berechtigungen für andere Ressourcen 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 siehe 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 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 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 Berechtigung iam.serviceAccounts.getAccessToken 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"]
}'

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 lesen Sie die ursprüngliche Forschung.

iam.serviceAccounts.signBlob

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, beliebige Payloads in GCP zu signieren. Es wird also möglich sein, 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. Für weitere Informationen lesen Sie dies.

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 und hier finden. Für weitere Informationen lesen Sie die ursprüngliche Forschung.

iam.serviceAccounts.signJwt

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, wohlgeformte JSON-Web-Token (JWTs) zu signieren. Der Unterschied zur vorherigen Methode besteht darin, dass wir anstelle von Google ein Blob, das ein JWT enthält, signieren zu lassen, die signJWT-Methode verwenden, die bereits ein JWT erwartet. Dies macht die Verwendung einfacher, aber Sie können nur JWTs anstelle von beliebigen Bytes signieren.

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 lesen Sie die ursprüngliche Forschung.

iam.serviceAccounts.setIamPolicy

Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, IAM-Richtlinien zu Dienstkonten hinzuzufügen. Sie können dies ausnutzen, um sich selbst die Berechtigungen zu gewähren, die Sie benötigen, um das Dienstkonto zu impersonieren. Im folgenden Beispiel gewähren wir uns die Rolle roles/iam.serviceAccountTokenCreator über das interessante 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"

Sie finden ein Skript zur Automatisierung der 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 Identität zu bestätigen und tragen nicht unbedingt eine implizite Autorisierung gegen eine Ressource.

Laut diesem interessanten Beitrag ist es notwendig, das Publikum (den 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:

• Google Cloud Run
• Google Cloud Functions
• Google Identity Aware Proxy
• Google Cloud Endpoints (wenn Google OIDC verwendet wird)

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

Referenzen

• https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/