Faille AWS Transit Gateway Peering

Lors de la création d'un peering attachment AWS Transit Gateway, n'importe quel Transit Gateway source peut demander à se connecter à un Transit Gateway de destination. Trois informations clés sont nécessaires pour établir cette connexion :

• L'AWS Account ID du compte de destination
• Le Transit Gateway ID du réseau Transit Gateway de destination
• La région du Transit Gateway de destination

Une fois provisionné, l'attachment passe à l'état pending-acceptance, en attente d'approbation du compte de destination. Or, une faille de sécurité permet au compte source de contourner cette étape d'approbation sous certaines conditions.

Transit Gateway attachment à l'état Pending Acceptance

Dans la console AWS, le compte source (le demandeur) a la possibilité d'accepter la requête, mais l'opération échoue avec l'erreur suivante :

La console AWS rejette une acceptation depuis le compte source

C'est le comportement attendu, puisque seul le compte de destination devrait être autorisé à accepter la requête.

En revanche, si l'API AWS est appelée directement via l'AWS CLI, la requête de peering peut être acceptée par le compte source (le demandeur) sans autorisation appropriée, dès lors que les Transit Gateways se trouvent dans des régions distinctes (par exemple, Irlande et Londres).

Réponse de l'AWS CLI après acceptation de l'attachment depuis le compte source

L'attachment passe alors à l'état Available, octroyant au compte source (potentiellement un acteur non autorisé) un accès à votre réseau. Autrement dit, le compte source — c'est-à-dire n'importe qui — dispose désormais d'un accès à votre réseau.

Transit Gateway Attachment Available

Cette faille se trace et s'observe via CloudTrail, qui révèle l'activité du compte externe lors de l'approbation de la requête d'attachment :

Log CloudTrail dans le compte de destination

Heureusement, les SCP permettent de bloquer l'appel API AcceptTransitGatewayPeeringAttachment.

Dans l'exemple de policy ci-dessous, tout compte autre que le compte de confiance spécifié se voit refuser l'acceptation des peering attachments :

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

Pour sécuriser toute votre organisation, vous pouvez étendre cette policy en y intégrant l'ID de votre organisation :

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

Avec ces policies en place, les comptes non autorisés rencontrent une erreur dès qu'ils tentent d'accepter des Transit Gateway peering attachments.

Refus dans le compte source

Nous avons signalé ce problème à AWS le 25 juillet 2024, dès la découverte de la faille, et celle-ci a été corrigée le 7 août 2024.

DoiT aide les organisations cloud-native à comprendre et exploiter le cloud pour stimuler la croissance de leur activité. Pour cela, nous associons une technologie intelligente à un conseil sans équivalent, un support 24/7 et des formations qui permettent aux organisations cloud-native de relever leurs défis cloud, d'approfondir leurs connaissances et d'accélérer l'innovation. Contactez-nous pour échanger sur la façon dont nous pouvons vous accompagner dans votre parcours cloud.