AWS - Route53 Privesc
Per ulteriori informazioni su Route53, controlla:
AWS - Route53 Enumroute53:CreateHostedZone
, route53:ChangeResourceRecordSets
, acm-pca:IssueCertificate
, acm-pca:GetCertificate
route53:CreateHostedZone
, route53:ChangeResourceRecordSets
, acm-pca:IssueCertificate
, acm-pca:GetCertificate
Per eseguire questo attacco, l'account di destinazione deve già avere un Certificato di Autorità Privata del Gestore di Certificati AWS (AWS-PCA) configurato nell'account, e le istanze EC2 nelle VPC devono aver già importato i certificati per fidarsi di esso. Con questa infrastruttura in atto, l'attacco seguente può essere eseguito per intercettare il traffico API AWS.
Altre autorizzazioni raccomandate ma non necessarie per la parte di enumerazione: route53:GetHostedZone
, route53:ListHostedZones
, acm-pca:ListCertificateAuthorities
, ec2:DescribeVpcs
Supponendo che ci sia una VPC AWS con diverse applicazioni native per il cloud che comunicano tra loro e con l'API AWS. Poiché la comunicazione tra i microservizi è spesso crittografata con TLS, deve esserci un CA privato per emettere i certificati validi per quei servizi. Se ACM-PCA viene utilizzato per questo e il malintenzionato riesce ad avere accesso al controllo sia di route53 che di acm-pca private CA con il minimo set di autorizzazioni descritte sopra, può intercettare le chiamate dell'applicazione all'API AWS assumendo il controllo delle loro autorizzazioni IAM.
Questo è possibile perché:
Gli SDK AWS non hanno il Pinning del Certificato
Route53 consente di creare una Zona Ospitata Privata e record DNS per i nomi di dominio delle API AWS
Il CA privato in ACM-PCA non può essere limitato a firmare solo certificati per nomi comuni specifici
Impatto Potenziale: Escalazione dei privilegi indiretta intercettando informazioni sensibili nel traffico.
Sfruttamento
Trova i passaggi di sfruttamento nella ricerca originale: https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated