Vulnerabilidade de curinga na conta da execution role do AWS MWAA

Reading time: 4 minutes

A Vulnerabilidade

A execution role do MWAA (o IAM role que os workers do Airflow usam para acessar recursos da AWS) requer esta política obrigatória para funcionar:

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

O curinga (*) na posição do account ID permite que a role interaja com qualquer SQS queue em qualquer AWS account que comece com airflow-celery-. Isso é necessário porque a AWS provisiona as filas internas do MWAA em uma conta separada gerenciada pela AWS. Não há restrição para criar filas com o prefixo airflow-celery-.

Não pode ser corrigido: Remover o curinga antes da pré-implantação quebra completamente o MWAA — o scheduler não consegue enfileirar tarefas para os workers.

Documentação verificando a vulnerabilidade e reconhecendo o vetor: AWS Documentation

Exploração

Todos os Airflow DAGs rodam com as permissões da execution role. DAGs são scripts Python que podem executar código arbitrário - eles podem usar yum ou curl para instalar ferramentas, baixar scripts maliciosos ou importar qualquer biblioteca Python. Os DAGs são obtidos de uma pasta S3 atribuída e executados automaticamente segundo o agendamento; tudo que um atacante precisa é da capacidade de fazer um PUT naquele caminho do bucket.

Qualquer pessoa que possa escrever DAGs (tipicamente a maioria dos usuários em ambientes MWAA) pode abusar dessa permissão:

1. Data Exfiltration: Criar uma queue chamada airflow-celery-exfil em uma conta externa, escrever um DAG que envie dados sensíveis para ela via boto3

2. Command & Control: Consultar comandos de uma queue externa, executá-los, retornar resultados — criando um backdoor persistente através das SQS APIs

3. Cross-Account Attacks: Injetar mensagens maliciosas nas queues de outras organizações se elas seguirem o padrão de nomes

Todos os ataques contornam controles de rede, pois usam APIs da AWS, não conexões diretas com a internet.

Impacto

Isto é uma falha arquitetural no MWAA sem mitigação baseada em IAM. Toda implantação de MWAA que siga a documentação da AWS tem essa vulnerabilidade.

Evasão de Controles de Rede: Esses ataques funcionam mesmo em VPCs privadas sem acesso à internet. As chamadas da API SQS usam a rede interna da AWS e os VPC endpoints, contornando completamente os controles tradicionais de segurança de rede, firewalls e o monitoramento de egress. As organizações não conseguem detectar ou bloquear esse caminho de exfiltração de dados por meio de controles em nível de rede.