Contesto
Quando si crea un peering attachment su AWS Transit Gateway, qualsiasi Transit Gateway sorgente può richiedere la connessione verso un Transit Gateway di destinazione. Per stabilire la connessione servono tre informazioni:
- AWS Account ID dell'account di destinazione
- Transit Gateway ID della rete Transit Gateway di destinazione
- Region del Transit Gateway di destinazione
Al momento del provisioning, l'attachment passa nello stato pending-acceptance, in attesa dell'approvazione dell'account di destinazione. Una falla di sicurezza, però, consentiva all'account sorgente di aggirare questo passaggio in determinate condizioni.
Transit Gateway attachment nello stato Pending Acceptance
Nella AWS Console, l'account sorgente (richiedente) può tentare di accettare la richiesta, ma riceve il seguente errore:
La AWS Console rifiuta l'accettazione da parte dell'account sorgente
È il comportamento atteso: solo l'account di destinazione dovrebbe poter accettare la richiesta.
Tuttavia, invocando l'API AWS direttamente tramite la AWS CLI, la richiesta di peering poteva essere accettata dall'account sorgente (richiedente) senza una reale autorizzazione, a condizione che i Transit Gateway si trovassero in region differenti (ad esempio Ireland e London).
Risposta della AWS CLI all'accettazione dell'attachment dall'account sorgente
L'attachment passa così allo stato "Available", concedendo all'account sorgente (potenzialmente un soggetto non autorizzato) l'accesso alla sua rete. In pratica, l'account sorgente — chiunque esso sia — ottiene l'accesso alla sua rete.
Transit Gateway Attachment Available
Come rilevare l'exploit
L'exploit è tracciabile e osservabile tramite CloudTrail, che registra l'attività dell'account esterno al momento dell'approvazione della richiesta di attachment:
Log CloudTrail nell'account di destinazione
Come mitigare l'exploit
Per fortuna, le SCP permettono di bloccare la chiamata API AcceptTransitGatewayPeeringAttachment.
Nell'esempio di policy seguente, qualsiasi account diverso da quello fidato specificato viene bloccato dall'accettare peering attachment:
{
"Version": "2012-10-17",
"Statement": [\
{\
"Sid": "Statement1",\
"Effect": "Deny",\
"Action": [\
"ec2:AcceptTransitGatewayPeeringAttachment"\
],\
"Resource": "*",\
"Condition": {\
"StringNotEquals": {\
"aws:PrincipalAccount": "339712835926"\
}\
}\
}\
]
}
Per proteggere l'intera organizzazione, può estendere la policy includendo l'ID della sua organizzazione:
"Version": "2012-10-17",
"Statement": [\
{\
"Sid": "Statement1",\
"Effect": "Deny",\
"Action": [\
"ec2:AcceptTransitGatewayPeeringAttachment"\
],\
"Resource": "*",\
"Condition": {\
"StringNotEquals": {\
"aws:PrincipalOrgID": "o-xxxxxxxxxxx"\
}\
}\
}\
]
}
Applicando queste policy, gli account non autorizzati ricevono un errore quando provano ad accettare peering attachment di Transit Gateway.
Richiesta negata nell'account sorgente
Abbiamo segnalato la vulnerabilità ad AWS il 25 luglio 2024, alla scoperta dell'exploit, ed è stata corretta il 7 agosto 2024.
DoiT aiuta le organizzazioni cloud-driven a comprendere e sfruttare il cloud per alimentare la crescita del business. Lo facciamo unendo tecnologia intelligente, consulenza senza pari, supporto 24/7 e formazione, per aiutare queste organizzazioni a superare le sfide del cloud, far crescere le competenze interne e accelerare l'innovazione. Ci contatti per scoprire come possiamo affiancarla nel suo percorso cloud.