Contexto
Ao criar um peering attachment no AWS Transit Gateway, qualquer Transit Gateway de origem pode solicitar conexão com um Transit Gateway de destino. Para que essa conexão seja estabelecida, três informações são essenciais:
- AWS Account ID da conta de destino
- Transit Gateway ID da rede do Transit Gateway de destino
- Região do Transit Gateway de destino
Após o provisionamento, o attachment fica no estado pending-acceptance, aguardando aprovação da conta de destino. No entanto, uma falha de segurança permite que a conta de origem contorne essa etapa de aprovação em determinadas condições.
Transit Gateway attachment no estado Pending Acceptance
No Console da AWS, a conta de origem (solicitante) tem a opção de aceitar a solicitação, mas recebe o seguinte erro:
Console da AWS rejeitando a aceitação feita pela conta de origem
Esse é o comportamento esperado, já que apenas a conta de destino deveria poder aceitar a solicitação.
Porém, se a API da AWS for chamada diretamente pela AWS CLI, a solicitação de peering pode ser aceita pela conta de origem (solicitante) sem a devida autorização, desde que os Transit Gateways estejam em regiões diferentes (por exemplo, Irlanda e Londres).
Resposta da AWS CLI ao aceitar o attachment na conta de origem
Com isso, o estado do attachment passa para "Available" e a conta de origem (potencialmente um agente não autorizado) ganha acesso à sua rede. Na prática, a conta de origem (ou seja, qualquer um) passa a ter acesso à sua rede.
Transit Gateway Attachment Available
Como detectar o exploit
Esse exploit pode ser rastreado e observado pelo CloudTrail, que registra a atividade da conta externa ao aprovar a solicitação de attachment:
Log do CloudTrail na conta de destino
Como mitigar o exploit
A boa notícia é que dá para usar SCPs para bloquear a chamada de API AcceptTransitGatewayPeeringAttachment.
No exemplo de política abaixo, qualquer conta diferente da conta confiável especificada fica impedida de aceitar peering attachments:
{
"Version": "2012-10-17",
"Statement": [\
{\
"Sid": "Statement1",\
"Effect": "Deny",\
"Action": [\
"ec2:AcceptTransitGatewayPeeringAttachment"\
],\
"Resource": "*",\
"Condition": {\
"StringNotEquals": {\
"aws:PrincipalAccount": "339712835926"\
}\
}\
}\
]
}
Para proteger toda a sua organização, basta ampliar a política incluindo o ID da organização:
"Version": "2012-10-17",
"Statement": [\
{\
"Sid": "Statement1",\
"Effect": "Deny",\
"Action": [\
"ec2:AcceptTransitGatewayPeeringAttachment"\
],\
"Resource": "*",\
"Condition": {\
"StringNotEquals": {\
"aws:PrincipalOrgID": "o-xxxxxxxxxxx"\
}\
}\
}\
]
}
Com essas políticas em vigor, contas não autorizadas vão receber um erro ao tentar aceitar peering attachments no Transit Gateway.
Negado na conta de origem
Reportamos o problema à AWS em 25/07/2024, quando descobrimos o exploit, e a falha foi corrigida em 07/08/2024.
A DoiT ajuda organizações nativas da nuvem a entender e tirar o máximo proveito da nuvem para impulsionar o crescimento do negócio. Para isso, combinamos tecnologia inteligente com consultoria sem igual, suporte 24/7 e treinamento, ajudando essas empresas a superar desafios na nuvem, ampliar o conhecimento e acelerar a inovação. Fale com a gente para conversarmos sobre como podemos apoiar sua jornada na nuvem.