AWS Transit Gateway Peering Exploit

Beim Anlegen eines AWS Transit Gateway Peering Attachments kann jedes Source Transit Gateway eine Verbindung zu einem Ziel-Transit-Gateway anfragen. Damit die Verbindung zustande kommt, sind drei Angaben erforderlich:

• AWS Account ID des Zielaccounts
• Transit Gateway ID des Ziel-Transit-Gateway-Netzwerks
• Region des Ziel-Transit-Gateways

Nach dem Provisionieren steht das Attachment zunächst im Status "pending-acceptance" und wartet auf die Bestätigung durch den Zielaccount. Eine Sicherheitslücke erlaubte es dem Source-Account jedoch, diesen Schritt unter bestimmten Bedingungen zu umgehen.

Transit Gateway Attachment im Status Pending Acceptance

In der AWS Console hat der Source-Account (Anforderer) zwar die Option, die Anfrage anzunehmen — der Versuch endet jedoch mit folgendem Fehler:

Die AWS Console lehnt eine Annahme durch den Source-Account ab

Das ist das erwartete Verhalten, denn nur der Zielaccount sollte die Anfrage annehmen dürfen.

Wird die AWS API hingegen direkt über die AWS CLI aufgerufen, lässt sich die Peering-Anfrage vom Source-Account (Anforderer) ohne korrekte Autorisierung bestätigen — sofern sich die Transit Gateways in unterschiedlichen Regionen befinden (z. B. Irland und London).

Antwort der AWS CLI nach Annahme des Attachments im Source-Account

In der Folge wechselt das Attachment in den Status "Available" und der Source-Account (möglicherweise eine unbefugte Partei) erhält Zugriff auf Ihr Netzwerk. Damit hat der Source-Account — also potenziell jeder — Zugang zu Ihrem Netzwerk.

Transit Gateway Attachment Available

Der Exploit lässt sich in CloudTrail nachvollziehen — dort wird die Aktivität des externen Accounts beim Bestätigen der Attachment-Anfrage sichtbar:

CloudTrail-Log im Zielaccount

Der API-Aufruf AcceptTransitGatewayPeeringAttachment lässt sich glücklicherweise per SCP blockieren.

Im folgenden Policy-Beispiel wird jedem Account außer dem angegebenen vertrauenswürdigen Account untersagt, Peering Attachments anzunehmen:

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

Um Ihre gesamte Organisation abzusichern, lässt sich die Policy um Ihre Organisations-ID erweitern:

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

Mit diesen Policies laufen unbefugte Accounts beim Versuch, Transit Gateway Peering Attachments anzunehmen, zuverlässig in eine Fehlermeldung.

Abgelehnt im Source-Account

Wir haben das Problem am 25. Juli 2024 unmittelbar nach der Entdeckung an AWS gemeldet; seit dem 7. August 2024 ist es behoben.

DoiT unterstützt cloud-native Unternehmen dabei, die Cloud zu verstehen und gezielt für ihr Wachstum zu nutzen. Wir verbinden dafür intelligente Technologie mit erstklassigem Consulting, 24/7-Support und Trainings — damit Sie Cloud-Herausforderungen lösen, Cloud-Know-how aufbauen und Innovation beschleunigen. Sprechen Sie uns an, wenn wir Sie auf Ihrem Weg in die Cloud begleiten dürfen.