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 target deve già avere un AWS Certificate Manager Private Certificate Authority (AWS-PCA) configurato nell'account, e le istanze EC2 nelle VPC devono già aver importato i certificati per fidarsi di esso. Con questa infrastruttura in atto, è possibile eseguire il seguente attacco per intercettare il traffico 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 cloud-native che comunicano tra loro e con l'API AWS. Poiché la comunicazione tra i microservizi è spesso crittografata TLS, deve esserci una CA privata per emettere i certificati validi per quei servizi. Se viene utilizzato ACM-PCA per questo e l'avversario riesce a ottenere accesso per controllare sia route53 che acm-pca CA privata con il set minimo di permessi descritti sopra, può dirottare le chiamate dell'applicazione all'API AWS prendendo il controllo dei loro permessi IAM.
Questo è possibile perché:
Gli SDK AWS non hanno Certificate Pinning
Route53 consente di creare Zone Ospitate Private e record DNS per i nomi di dominio delle API 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