AWS - Route53 Privesc
Per ulteriori informazioni su Route53, controlla:
pageAWS - 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 di AWS Certificate Manager (AWS-PCA) configurato nell'account e le istanze EC2 nella VPC devono aver già importato i certificati per fidarsi di esso. Con questa infrastruttura in atto, è possibile eseguire l'attacco seguente per intercettare il traffico dell'API di AWS.
Altri permessi raccomandati ma non richiesti per la parte di enumerazione: route53:GetHostedZone
, route53:ListHostedZones
, acm-pca:ListCertificateAuthorities
, ec2:DescribeVpcs
Assumendo che ci sia una VPC AWS con più applicazioni native per il cloud che comunicano tra loro e con l'API di AWS. Poiché la comunicazione tra i microservizi è spesso crittografata con TLS, deve essere presente un CA privato per emettere i certificati validi per tali servizi. Se viene utilizzato ACM-PCA per questo scopo e l'attaccante riesce ad ottenere accesso al controllo sia di route53 che di acm-pca private CA con il set minimo di permessi descritti sopra, può intercettare le chiamate dell'applicazione all'API di AWS assumendo i loro permessi IAM.
Ciò è possibile perché:
Le SDK di AWS non hanno Certificate Pinning
Route53 consente di creare una zona ospitata privata e record DNS per i nomi di dominio delle API di AWS
La CA privata in ACM-PCA non può essere limitata a firmare solo certificati per nomi comuni specifici
Impatto potenziale: Privesc indiretto 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