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:GetCertificate
Um 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 in place kann der folgende Angriff durchgeführt werden, um den AWS-API-Verkehr abzufangen.
Andere Berechtigungen empfohlen, aber nicht erforderlich für den Enumerationsteil: route53:GetHostedZone
, route53:ListHostedZones
, acm-pca:ListCertificateAuthorities
, ec2:DescribeVpcs
Angenommen, es gibt eine AWS-VPC mit mehreren Cloud-native Anwendungen, die miteinander und mit der AWS-API kommunizieren. Da die Kommunikation zwischen den Microservices oft TLS-verschlüsselt ist, muss es eine private CA geben, um gültige 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 Satz von Berechtigungen zu erhalten, kann er die Anwendungsaufforderungen an die AWS-API kapern, um deren IAM-Berechtigungen zu übernehmen.
Dies ist möglich, weil:
AWS-SDKs haben kein Zertifikats-Pinning
Route53 ermöglicht das Erstellen von privaten gehosteten Zonen und DNS-Einträgen für AWS-API-Domänennamen
Private CA in ACM-PCA kann nicht darauf beschränkt werden, nur Zertifikate für bestimmte Common Names zu signieren
Potenzielle Auswirkungen: Indirekter Privilege Escalation durch Abfangen sensibler Informationen im Datenverkehr.
Ausnutzung
Finden Sie die Ausnutzungsschritte in der Originalforschung: https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated