AWS - Route53 Privesc
Aby uzyskać więcej informacji o Route53, sprawdź:
AWS - Route53 Enumroute53:CreateHostedZone
, route53:ChangeResourceRecordSets
, acm-pca:IssueCertificate
, acm-pca:GetCertificate
route53:CreateHostedZone
, route53:ChangeResourceRecordSets
, acm-pca:IssueCertificate
, acm-pca:GetCertificate
Aby przeprowadzić ten atak, konto docelowe musi już mieć skonfigurowane AWS Certificate Manager Private Certificate Authority (AWS-PCA), a instancje EC2 w VPC muszą już zaimportować certyfikaty, aby je zaufać. Przy tej infrastrukturze można przeprowadzić następujący atak, aby przechwycić ruch API AWS.
Inne uprawnienia zalecane, ale nie wymagane do części enumeracji: route53:GetHostedZone
, route53:ListHostedZones
, acm-pca:ListCertificateAuthorities
, ec2:DescribeVpcs
Zakładając, że istnieje VPC AWS z wieloma aplikacjami natywnymi w chmurze, które komunikują się ze sobą i z API AWS. Ponieważ komunikacja między mikroserwisami jest często szyfrowana TLS, musi istnieć prywatna CA, aby wydawać ważne certyfikaty dla tych usług. Jeśli używana jest ACM-PCA do tego, a przeciwnik zdoła uzyskać dostęp do kontroli zarówno route53, jak i prywatnej CA acm-pca z minimalnym zestawem opisanych powyżej uprawnień, może przejąć wywołania aplikacji do API AWS, przejmując ich uprawnienia IAM.
Jest to możliwe, ponieważ:
SDK AWS nie mają Certificate Pinning
Route53 pozwala na tworzenie prywatnych stref hostowanych i rekordów DNS dla nazw domen API AWS
Prywatna CA w ACM-PCA nie może być ograniczona do podpisywania tylko certyfikatów dla określonych nazw wspólnych
Potencjalny wpływ: Pośredni privesc poprzez przechwytywanie wrażliwych informacji w ruchu.
Wykorzystanie
Znajdź kroki wykorzystania w oryginalnych badaniach: https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated