AWS - Route53 Privesc
Pour plus d'informations sur Route53, consultez :
route53:CreateHostedZone, route53:ChangeResourceRecordSets, acm-pca:IssueCertificate, acm-pca:GetCertificate
route53:CreateHostedZone, route53:ChangeResourceRecordSets, acm-pca:IssueCertificate, acm-pca:GetCertificatePour effectuer cette attaque, le compte cible doit déjà avoir une AWS Certificate Manager Private Certificate Authority (AWS-PCA) configurée dans le compte, et les instances EC2 dans le(s) VPC doivent déjà avoir importé les certificats pour lui faire confiance. Avec cette infrastructure en place, l'attaque suivante peut être effectuée pour intercepter le trafic API AWS.
Autorisations recommandées mais non requises pour la partie d'énumération : route53:GetHostedZone, route53:ListHostedZones, acm-pca:ListCertificateAuthorities, ec2:DescribeVpcs
En supposant qu'il y ait un VPC AWS avec plusieurs applications cloud-native communiquant entre elles et avec l'API AWS. Étant donné que la communication entre les microservices est souvent chiffrée en TLS, il doit y avoir une CA privée pour émettre les certificats valides pour ces services. Si ACM-PCA est utilisé pour cela et que l'adversaire parvient à accéder au contrôle à la fois de route53 et de l'acm-pca CA privée avec le minimum de permissions décrites ci-dessus, il peut détourner les appels d'application vers l'API AWS en prenant le contrôle de leurs permissions IAM.
Cela est possible parce que :
Les SDK AWS n'ont pas de Certificate Pinning
Route53 permet de créer des zones hébergées privées et des enregistrements DNS pour les noms de domaine des API AWS
La CA privée dans ACM-PCA ne peut pas être restreinte à la signature uniquement des certificats pour des noms communs spécifiques
Impact potentiel : Privesc indirect en interceptant des informations sensibles dans le trafic.
Exploitation
Trouvez les étapes d'exploitation dans la recherche originale : https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated
