Abus de SetIamPolicy : repérer les Owner et les intrus

En bref. Chaque modification d'une stratégie IAM est une entrée Admin Activity, et la partie utile n'est pas la stratégie complète contenue dans la requête mais le diff : serviceData.policyDelta.bindingDeltas (ou metadata.policyDelta, metadata.datasetChange pour BigQuery), avec action, role et member pour chaque changement. Cherchez les ADD de roles/owner, roles/editor ou de rôles d'administration IAM, de comptes grand public (@gmail.com), de domaines qui n'apparaissent jamais parmi vos appelants, de allUsers, et des rôles Token Creator / Service Account User.

Dès qu'un attaquant dispose d'un identifiant doté de la permission setIamPolicy, sa première action est généralement de se donner une identité durable qu'il contrôle. En termes MITRE ATT&CK, c'est T1098.003, Additional Cloud Roles. C'est aussi l'étape la plus facile à repérer, car les journaux Admin Activity sont toujours actifs et conservés 400 jours.

Ce que contient une entrée SetIamPolicy

gcloud projects add-iam-policy-binding ressemble à une petite modification, mais l'API fonctionne en lecture-modification-écriture : le client appelle GetIamPolicy, modifie la stratégie localement et renvoie l'ensemble avec SetIamPolicy. La requête contient donc la totalité de la nouvelle stratégie. La lire vous donne le résultat, pas ce qui a changé.

Le changement se trouve dans le delta de stratégie :

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

Selon le service et la version d'API, la même structure apparaît sous protoPayload.metadata.policyDelta, ou, pour les jeux de données et tables BigQuery, sous metadata.datasetChange.bindingDeltas / metadata.tableChange.bindingDeltas (journaux d'audit BigQuery).

Le nom de méthode varie aussi selon la ressource :

Cherchez donc sur le delta, pas sur un seul nom de méthode.

Les cinq octrois qui comptent

1. Owner, Editor et rôles d'administration IAM

roles/owner et roles/editor sont les rôles de base qui donnent un contrôle (quasi) total (présentation des rôles). roles/resourcemanager.projectIamAdmin, roles/resourcemanager.organizationAdmin et roles/iam.securityAdmin sont tout aussi dangereux, puisqu'ils permettent d'accorder n'importe quoi d'autre. Tout ADD de ces rôles pendant la fenêtre d'incident est une piste.

2. Comptes grand public

Un membre se terminant par @gmail.com ou @googlemail.com est un compte Google personnel. Les attaquants les apprécient : gratuits, anonymes, et ils survivent au renouvellement de tous les identifiants de votre organisation. ADD roles/owner user:x@gmail.com est, sauf compte « bris de glace » documenté, une prise de contrôle.

3. Domaines inconnus

Moins évident : un membre user: ou group: d'un domaine qui n'apparaît jamais comme appelant dans vos journaux. Ce peut être un prestataire ; ce peut être le propre tenant Workspace de l'attaquant. La contrainte de partage restreint au domaine (iam.allowedPolicyMemberDomains) empêche les deux.

4. allUsers et allAuthenticatedUsers

Ces principaux spéciaux rendent une ressource publique. Sur un bucket, n'importe qui sur Internet peut lire les objets. Voir allUsers et l'article sur l'exfiltration.

5. Rôles d'emprunt d'identité

roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser, roles/iam.serviceAccountKeyAdmin et roles/iam.workloadIdentityUser permettent au membre d'agir en tant que comptes de service. Ils sont plus discrets qu'Owner et passent souvent inaperçus. Voir l'emprunt d'identité de comptes de service.

Les changements autour de la stratégie

Deux autres événements Admin Activity relèvent de la même revue :

• Modifications des règles d'administration (google.cloud.orgpolicy.v2.OrgPolicy.CreatePolicy, UpdatePolicy, DeletePolicy, ou les anciens SetOrgPolicy / ClearOrgPolicy). Un attaquant qui assouplit iam.allowedPolicyMemberDomains avant d'ajouter un compte Gmail, ou iam.disableServiceAccountKeyCreation avant de créer des clés, prépare l'étape suivante (T1484).
• Rôles personnalisés (google.iam.admin.v1.CreateRole, UpdateRole, UndeleteRole). Un rôle nommé « Viewer (legacy) » peut contenir iam.serviceAccountKeys.create. Les travaux de Rhino Security Labs sur l'élévation de privilèges dans GCP comptent iam.roles.update parmi les chemins d'élévation.

Les modifications de configuration d'audit (auditConfigDeltas) passent aussi par SetIamPolicy ; elles sont traitées dans l'évasion des défenses.

Enquêter sur un octroi suspect

Pour chaque delta suspect, répondez à ces questions :

1. Qui a fait l'appel ? authenticationInfo.principalEmail, et serviceAccountKeyName ou serviceAccountDelegationInfo s'ils sont présents. Un octroi fait par un compte de service de CI avec une clé, depuis un VPS, n'est pas une erreur humaine.
2. D'où ? requestMetadata.callerIp et le user agent. Comparez avec les IP habituelles du principal.
3. Que s'est-il passé ensuite ? Cherchez le nouveau membre en tant que principalEmail. Un compte qui reçoit Owner et agit quelques minutes plus tard depuis la même IP boucle l'histoire.
4. Est-ce toujours en place ? Les dernières réponses de SetIamPolicy, ou un gcloud projects get-iam-policy actuel, indiquent si la liaison a été retirée.
5. Qu'est-ce qui a changé d'autre ? Cherchez aussi les deltas REMOVE : les attaquants retirent parfois les propriétaires légitimes.

Une requête Logs Explorer qui attrape la plupart des changements au niveau du projet :

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

Ce que l'analyseur signale

Les règles de l'analyseur évaluent chaque delta séparément, quelle que soit la ressource :

Les cibles s'affichent sous forme de deltas lisibles (ADD roles/owner user:…), et l'onglet Entités marque les comptes grand public comme « Gmail personnel ».

Remédiation

Retirez les liaisons, puis vérifiez toute la hiérarchie (projet, dossiers, organisation) à la recherche d'autres ajouts ; imposez le partage restreint au domaine ; passez en revue les rôles personnalisés ; et restaurez toute règle d'administration assouplie. Le guide de Google sur les identifiants compromis couvre le volet identité.

Questions fréquentes

Comment savoir qui a accordé le rôle Owner sur un projet Google Cloud ?

Interrogez les journaux Admin Activity sur protoPayload.methodName="SetIamPolicy" et lisez protoPayload.serviceData.policyDelta.bindingDeltas : chaque delta comporte une action (ADD ou REMOVE), un rôle et un membre. L'appelant est protoPayload.authenticationInfo.principalEmail.

Un compte gmail.com dans une stratégie IAM est-il toujours malveillant ?

Non : certaines petites structures utilisent des comptes personnels, et les comptes « bris de glace » existent. Mais un compte grand public qui reçoit roles/owner pendant un incident est le geste classique de prise de contrôle, et la règle iam.allowedPolicyMemberDomains existe pour l'empêcher.

Pour aller plus loin

• Présentation des rôles IAM — documentation Google Cloud.
• Restreindre les identités par domaine — documentation Google Cloud.
• Privilege Escalation in Google Cloud Platform – Part 1 (IAM) — Rhino Security Labs.
• Clé de compte de service GCP divulguée : enquêter.