Vulnerabilità wildcard dell'account del ruolo di esecuzione di AWS MWAA

Reading time: 4 minutes

La vulnerabilità

Il ruolo di esecuzione di MWAA (il ruolo IAM che i worker di Airflow usano per accedere alle risorse AWS) richiede questa policy obbligatoria per funzionare:

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

Il wildcard (*) nella posizione dell'account ID permette al ruolo di interagire con any SQS queue in any AWS account che inizi con airflow-celery-. Questo è necessario perché AWS provvede le queue interne di MWAA in un account gestito separatamente da AWS. Non ci sono restrizioni nel creare queue con il prefisso airflow-celery-.

Cannot be fixed: Rimuovere il wildcard pre-deployment rompe completamente MWAA - lo scheduler non può mettere in coda i task per i worker.

Documentazione che verifica la vulnerabilità e riconosce il vettore: AWS Documentation

Sfruttamento

Tutti gli Airflow DAGs vengono eseguiti con i permessi del ruolo di esecuzione. I DAGs sono script Python che possono eseguire codice arbitrario - possono usare yum o curl per installare tool, scaricare script dannosi, o importare qualsiasi libreria Python. I DAGs vengono prelevati da una cartella S3 assegnata ed eseguiti automaticamente secondo schedule; tutto ciò di cui un attaccante ha bisogno è la capacità di fare PUT in quel path del bucket.

Chiunque possa scrivere DAGs (tipicamente la maggior parte degli utenti negli ambienti MWAA) può abusare di questo permesso:

1. Data Exfiltration: Creare una queue chiamata airflow-celery-exfil in un account esterno, scrivere un DAG che invii dati sensibili ad essa via boto3

2. Command & Control: Pollare comandi da una queue esterna, eseguirli, restituire i risultati - creando una backdoor persistente tramite le SQS APIs

3. Cross-Account Attacks: Iniettare messaggi dannosi nelle queue di altre organizzazioni se seguono il naming pattern

Tutti gli attacchi aggirano i controlli di rete poiché usano le AWS APIs, non connessioni Internet dirette.

Impatto

Questa è una falla architetturale in MWAA senza mitigazione basata su IAM. Ogni deployment MWAA che segue la documentazione AWS ha questa vulnerabilità.

Network Control Bypass: Questi attacchi funzionano anche in VPC private senza accesso a internet. Le chiamate SQS API usano la rete interna di AWS e gli endpoint VPC, aggirando completamente i tradizionali controlli di sicurezza di rete, firewall e il monitoraggio dell'egress. Le organizzazioni non possono rilevare o bloccare questo percorso di data exfiltration tramite controlli a livello di rete.