AWS Transit Gateway Peering Exploit

When creating an AWS Transit Gateway peering attachment, any source Transit Gateway can request to connect to a destination Transit Gateway. For this connection to be established, three key pieces of information are required:

• AWS Account ID of the destination account
• Transit Gateway ID of the destination Transit Gateway network
• Region of the destination Transit Gateway

Upon provision, the attachment will be in a pending-acceptance state, awaiting approval from the destination account. However, a security flaw allows the source account to circumvent this approval step under certain conditions.

Transit Gateway attachment in Pending Acceptance State

In the AWS Console, the source account (requestor) has the option to accept the request but will error with the following:

AWS Console rejecting an acceptance from the source account

This is expected behavior as the destination account should only be allowed to accept the request.

However, if the AWS API is called directly via the AWS CLI, the peering request can be accepted by the source account (requestor) without proper authorization, provided the Transit Gateways are in separate regions (e.g., Ireland and London).

AWS CLI response from accepting the attachment in the source account

Consequently, the attachment state becomes “Available”, granting the source account (potentially an unauthorized party) access to your network. As a result, the source account (i.e. anyone) now has access to your network.

Transit Gateway Attachment Available

This exploit can be traced and observed via CloudTrail, showing the external account’s activity when approving the attachment request:

CloudTrail log in the destination account

Fortunately, SCPs can be used to block the AcceptTransitGatewayPeeringAttachment API call.

In the policy example below, any account other than the specified trusted account is blocked from accepting peering attachments:

{
 "Version": "2012-10-17",
 "Statement": [\
   {\
     "Sid": "Statement1",\
     "Effect": "Deny",\
     "Action": [\
       "ec2:AcceptTransitGatewayPeeringAttachment"\
     ],\
     "Resource": "*",\
     "Condition": {\
       "StringNotEquals": {\
         "aws:PrincipalAccount": "339712835926"\
       }\
     }\
   }\
 ]
}

To secure your entire organization, you can expand this policy by including your organization’s ID:

"Version": "2012-10-17",
 "Statement": [\
   {\
     "Sid": "Statement1",\
     "Effect": "Deny",\
     "Action": [\
       "ec2:AcceptTransitGatewayPeeringAttachment"\
     ],\
     "Resource": "*",\
     "Condition": {\
       "StringNotEquals": {\
         "aws:PrincipalOrgID": "o-xxxxxxxxxxx"\
       }\
     }\
   }\
 ]
}

Implementing these policies ensures that unauthorized accounts will encounter an error when attempting to accept Transit Gateway peering attachments.

Denied in the source account

We raised this issue with AWS on July 25th, 2024 when the exploit was discovered and has now been patched as of the 7th of August 2024.

DoiT helps cloud-driven organizations understand and harness the cloud to drive business growth. We do this by pairing intelligent technology with unrivaled consulting, 24/7 support, and training to help cloud-driven organizations solve cloud challenges, advance cloud knowledge, and accelerate innovation. Get in touch with us to chat about how we can help you with your cloud journey.