SetIamPolicy-Missbrauch: Owner-Rechte für Externe aufspüren

Kurz gesagt. Jede Änderung an einer IAM-Richtlinie ist ein Admin-Activity-Eintrag, und nützlich ist nicht die vollständige Richtlinie in der Anfrage, sondern die Differenz: serviceData.policyDelta.bindingDeltas (oder metadata.policyDelta, metadata.datasetChange bei BigQuery), mit action, role und member je Änderung. Suchen Sie nach ADD von roles/owner, roles/editor oder IAM-Admin-Rollen, von privaten Konten (@gmail.com), von Domains, die nie unter Ihren Aufrufern vorkommen, von allUsers sowie der Rollen Token Creator / Service Account User.

Sobald ein Angreifer Anmeldedaten mit der Berechtigung setIamPolicy hat, verschafft er sich in der Regel als Erstes eine dauerhafte Identität unter seiner Kontrolle. In MITRE-ATT&CK-Begriffen ist das T1098.003, Additional Cloud Roles. Es ist zugleich der am leichtesten zu erkennende Schritt, denn Admin-Activity-Logs sind immer aktiv und werden 400 Tage aufbewahrt.

Was ein SetIamPolicy-Eintrag enthält

gcloud projects add-iam-policy-binding sieht nach einer kleinen Änderung aus, doch die API arbeitet nach dem Prinzip Lesen-Ändern-Schreiben: Der Client ruft GetIamPolicy auf, bearbeitet die Richtlinie lokal und schickt sie mit SetIamPolicy vollständig zurück. Die Anfrage enthält also die gesamte neue Richtlinie. Sie zu lesen verrät Ihnen das Ergebnis, nicht die Änderung.

Die Änderung steht im Policy-Delta:

"serviceData": {
  "@type": "type.googleapis.com/google.iam.v1.logging.AuditData",
  "policyDelta": {
    "bindingDeltas": [
      { "action": "ADD", "role": "roles/owner", "member": "user:someone@gmail.com" }
    ]
  }
}

Je nach Dienst und API-Version erscheint dieselbe Struktur unter protoPayload.metadata.policyDelta oder, bei BigQuery-Datasets und -Tabellen, unter metadata.datasetChange.bindingDeltas / metadata.tableChange.bindingDeltas (BigQuery-Audit-Logs).

Auch der Methodenname hängt von der Ressource ab:

Suchen Sie deshalb nach dem Delta, nicht nur nach einem einzigen Methodennamen.

Die fünf Rollenvergaben, auf die es ankommt

1. Owner, Editor und Rollen zur IAM-Verwaltung

roles/owner und roles/editor sind die Basisrollen mit (nahezu) voller Kontrolle (Rollenübersicht). roles/resourcemanager.projectIamAdmin, roles/resourcemanager.organizationAdmin und roles/iam.securityAdmin sind genauso gefährlich, weil sie erlauben, alles andere zu vergeben. Jedes ADD einer dieser Rollen im Zeitfenster eines Vorfalls ist eine Spur.

2. Private Konten

Ein Mitglied, das auf @gmail.com oder @googlemail.com endet, ist ein privates Google-Konto. Angreifer mögen sie: kostenlos, anonym, und sie überstehen die Rotation sämtlicher Anmeldedaten Ihrer Organisation. ADD roles/owner user:x@gmail.com ist, sofern es sich nicht um ein dokumentiertes Notfallkonto handelt, eine Übernahme.

3. Unbekannte Domains

Weniger offensichtlich: ein Mitglied user: oder group: aus einer Domain, die in Ihren Logs nie als Aufrufer auftaucht. Das kann ein externer Dienstleister sein, aber auch der eigene Workspace-Tenant des Angreifers. Die Einschränkung für die Domain-beschränkte Freigabe (iam.allowedPolicyMemberDomains) verhindert beides.

4. allUsers und allAuthenticatedUsers

Diese speziellen Identitäten machen eine Ressource öffentlich. Bei einem Bucket bedeutet das, dass jeder im Internet die Objekte lesen kann. Siehe allUsers und den Artikel zur Exfiltration.

5. Rollen für Impersonation

roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser, roles/iam.serviceAccountKeyAdmin und roles/iam.workloadIdentityUser erlauben dem Mitglied, als Dienstkonto zu handeln. Sie sind unauffälliger als Owner und bleiben oft unbemerkt. Siehe Impersonation von Dienstkonten.

Änderungen rund um die Richtlinie

Zwei weitere Admin-Activity-Ereignisse gehören in dieselbe Prüfung:

• Änderungen an Organisationsrichtlinien (google.cloud.orgpolicy.v2.OrgPolicy.CreatePolicy, UpdatePolicy, DeletePolicy oder die älteren SetOrgPolicy / ClearOrgPolicy). Ein Angreifer, der iam.allowedPolicyMemberDomains lockert, bevor er ein Gmail-Konto hinzufügt, oder iam.disableServiceAccountKeyCreation, bevor er Schlüssel erstellt, bereitet den nächsten Schritt vor (T1484).
• Benutzerdefinierte Rollen (google.iam.admin.v1.CreateRole, UpdateRole, UndeleteRole). Eine Rolle namens „Viewer (legacy)“ kann iam.serviceAccountKeys.create enthalten. Die Forschung von Rhino Security Labs zur Rechteausweitung in GCP führt iam.roles.update unter den Eskalationswegen auf.

Änderungen an der Audit-Konfiguration (auditConfigDeltas) laufen ebenfalls über SetIamPolicy; sie werden im Artikel zur Umgehung von Abwehrmaßnahmen behandelt.

Eine verdächtige Rollenvergabe untersuchen

Beantworten Sie für jedes verdächtige Delta:

1. Wer hat den Aufruf getätigt? authenticationInfo.principalEmail, dazu serviceAccountKeyName oder serviceAccountDelegationInfo, falls vorhanden. Eine Rollenvergabe durch ein CI-Dienstkonto mit Schlüssel, von einem VPS aus, ist kein menschlicher Fehler.
2. Von wo? requestMetadata.callerIp und User-Agent. Vergleichen Sie mit den üblichen IPs der Identität.
3. Was geschah danach? Suchen Sie nach dem neuen Mitglied als principalEmail. Ein Konto, das Owner-Rechte erhält und binnen Minuten von derselben IP aus handelt, schließt den Kreis.
4. Besteht die Bindung noch? Die letzten Antworten auf SetIamPolicy oder ein aktuelles gcloud projects get-iam-policy zeigen, ob die Bindung entfernt wurde.
5. Was hat sich sonst noch geändert? Achten Sie auch auf REMOVE-Deltas: Angreifer entfernen manchmal legitime Owner.

Eine Abfrage im Logs Explorer, die die meisten Änderungen auf Projektebene erfasst:

logName:"cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"

Was der Analyzer markiert

Die Regeln im Analyzer bewerten jedes Delta einzeln, unabhängig von der Ressource:

Die Ziele werden als lesbare Deltas angezeigt (ADD roles/owner user:…), und der Reiter „Entitäten“ kennzeichnet private Konten als „privates Gmail“.

Behebung

Entfernen Sie die Bindungen und prüfen Sie dann die gesamte Hierarchie (Projekt, Ordner, Organisation) auf weitere Ergänzungen; erzwingen Sie die Domain-beschränkte Freigabe; prüfen Sie benutzerdefinierte Rollen; und stellen Sie jede gelockerte Organisationsrichtlinie wieder her. Googles Leitfaden für kompromittierte Anmeldedaten deckt die Identitätsseite ab.

Häufige Fragen

Wie sehe ich, wer in einem Google-Cloud-Projekt Owner-Rechte vergeben hat?

Fragen Sie die Admin-Activity-Audit-Logs nach protoPayload.methodName="SetIamPolicy" ab und lesen Sie protoPayload.serviceData.policyDelta.bindingDeltas: Jedes Delta hat eine Aktion (ADD oder REMOVE), eine Rolle und ein Mitglied. Der Aufrufer steht in protoPayload.authenticationInfo.principalEmail.

Ist ein gmail.com-Konto in einer IAM-Richtlinie immer bösartig?

Nein, manche kleinen Organisationen nutzen private Konten, und es gibt Notfallkonten (Break-Glass). Ein privates Konto, das während eines Vorfalls roles/owner erhält, ist aber der klassische Übernahmezug, und genau dagegen gibt es die Richtlinie iam.allowedPolicyMemberDomains.

Weiterführende Links

• IAM roles overview – Dokumentation von Google Cloud.
• Restricting identities by domain – Dokumentation von Google Cloud.
• Privilege Escalation in Google Cloud Platform – Part 1 (IAM) – Rhino Security Labs.
• Geleakter GCP-Dienstkontoschlüssel: so untersuchen Sie ihn.