AWS - Route53 Privesc
Für weitere Informationen zu Route53 siehe:
AWS - Route53 Enumroute53:CreateHostedZone, route53:ChangeResourceRecordSets, acm-pca:IssueCertificate, acm-pca:GetCertificate
route53:CreateHostedZone, route53:ChangeResourceRecordSets, acm-pca:IssueCertificate, acm-pca:GetCertificateUm diesen Angriff durchzuführen, muss das Zielkonto bereits eine AWS Certificate Manager Private Certificate Authority (AWS-PCA) im Konto eingerichtet haben, und EC2-Instanzen in den VPC(s) müssen die Zertifikate bereits importiert haben, um ihnen zu vertrauen. Mit dieser Infrastruktur kann der folgende Angriff durchgeführt werden, um den AWS API-Verkehr abzufangen.
Andere Berechtigungen werden empfohlen, sind aber nicht erforderlich für den Enumerations-Teil: route53:GetHostedZone, route53:ListHostedZones, acm-pca:ListCertificateAuthorities, ec2:DescribeVpcs
Angenommen, es gibt eine AWS VPC mit mehreren cloud-nativen Anwendungen, die miteinander und mit der AWS API kommunizieren. Da die Kommunikation zwischen den Mikrodiensten oft TLS-verschlüsselt ist, muss es eine private CA geben, um die gültigen Zertifikate für diese Dienste auszustellen. Wenn ACM-PCA dafür verwendet wird und der Angreifer es schafft, Zugriff auf die Kontrolle sowohl von route53 als auch von acm-pca private CA mit dem oben beschriebenen minimalen Berechtigungsset zu erhalten, kann er die Anwendungsaufrufe an die AWS API hijacken und deren IAM-Berechtigungen übernehmen.
Dies ist möglich, weil:
AWS SDKs kein Certificate Pinning haben
Route53 das Erstellen von Private Hosted Zone und DNS-Einträgen für AWS API-Domainnamen ermöglicht
Private CA in ACM-PCA nicht darauf beschränkt werden kann, nur Zertifikate für spezifische Common Names zu signieren
Potenzielle Auswirkungen: Indirekter Privesc durch Abfangen sensibler Informationen im Verkehr.
Ausnutzung
Finde die Schritte zur Ausnutzung in der ursprünglichen Forschung: https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated
