AWS MWAA Execution Role Account Wildcard Vulnerability

Reading time: 4 minutes

La vulnérabilité

Le rôle d'exécution de MWAA (le rôle IAM que les workers Airflow utilisent pour accéder aux ressources AWS) requiert la politique obligatoire suivante pour fonctionner :

{
"Effect": "Allow",
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:us-east-1:*:airflow-celery-*"
}

Le caractère générique (*) dans la position de l'ID de compte permet au rôle d'interagir avec n'importe quelle queue SQS dans n'importe quel compte AWS qui commence par airflow-celery-. Cela est nécessaire car AWS provisionne les queues internes de MWAA dans un compte géré séparément par AWS. Il n'y a aucune restriction pour créer des queues avec le préfixe airflow-celery-.

Ne peut pas être corrigé : Supprimer le caractère générique avant le déploiement casse complètement MWAA — le scheduler ne peut plus mettre les tâches en queue pour les workers.

Documentation vérifiant la vuln et reconnaissant le vecteur : AWS Documentation

Exploitation

Tous les Airflow DAGs s'exécutent avec les permissions du rôle d'exécution. Les DAGs sont des scripts Python capables d'exécuter du code arbitraire — ils peuvent utiliser yum ou curl pour installer des outils, télécharger des scripts malveillants, ou importer n'importe quelle librairie Python. Les DAGs sont récupérés depuis un dossier S3 assigné et exécutés automatiquement selon la planification ; tout ce dont un attaquant a besoin est la capacité de PUT sur ce chemin de bucket.

Quiconque peut écrire des DAGs (typiquement la plupart des utilisateurs dans des environnements MWAA) peut abuser de cette permission :

1. Exfiltration de données : Créer une queue nommée airflow-celery-exfil dans un compte externe, écrire un DAG qui envoie des données sensibles vers celle-ci via boto3

2. Command & Control : Récupérer des commandes depuis une queue externe, les exécuter, renvoyer les résultats — créant une porte dérobée persistante via les SQS APIs

3. Attaques cross-account : Injecter des messages malveillants dans les queues d'autres organisations si elles suivent le schéma de nommage

Toutes les attaques contournent les contrôles réseau puisqu'elles utilisent les APIs AWS, et non des connexions Internet directes.

Impact

C'est une faille architecturale dans MWAA sans atténuation basée sur IAM. Chaque déploiement MWAA suivant la documentation AWS présente cette vulnérabilité.

Bypass des contrôles réseau : Ces attaques fonctionnent même dans des VPC privés sans accès Internet. Les appels SQS utilisent le réseau interne d'AWS et les VPC endpoints, contournant complètement les contrôles de sécurité réseau traditionnels, les firewalls et la surveillance de l'egress. Les organisations ne peuvent pas détecter ni bloquer cette voie d'exfiltration de données via des contrôles au niveau réseau.