AWS - Route53 Privesc
Aby uzyskać więcej informacji na temat Route53, sprawdź:
pageAWS - 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ć AWS Certificate Manager Private Certificate Authority (AWS-PCA) skonfigurowane w koncie, a instancje EC2 w VPC muszą już zaimportować certyfikaty, aby ufać mu. Mając taką infrastrukturę, można przeprowadzić następujący atak w celu przechwycenia ruchu AWS API.
Inne uprawnienia zalecane, ale nie wymagane dla części wyliczania: route53:GetHostedZone
, route53:ListHostedZones
, acm-pca:ListCertificateAuthorities
, ec2:DescribeVpcs
Zakładając, że istnieje AWS VPC z wieloma aplikacjami natywnymi dla chmury, które komunikują się ze sobą i z AWS API. Ponieważ komunikacja między mikroserwisami jest często szyfrowana protokołem TLS, musi istnieć prywatne centrum certyfikacji (CA), które wydaje ważne certyfikaty dla tych usług. Jeśli do tego celu używany jest ACM-PCA i atakujący jest w stanie uzyskać dostęp do kontroli zarówno nad route53, jak i prywatnym CA acm-pca z minimalnym zestawem uprawnień opisanym powyżej, może przejąć wywołania aplikacji do AWS API i uzyskać ich uprawnienia IAM.
Jest to możliwe, ponieważ:
AWS SDK nie ma Pinningu Certyfikatów
Route53 umożliwia tworzenie prywatnych stref hostowanych i rekordów DNS dla domen AWS API
Prywatne centrum certyfikacji w ACM-PCA nie może być ograniczone do podpisywania tylko certyfikatów dla określonych nazw wspólnych
Potencjalne skutki: Pośrednia eskalacja uprawnień poprzez przechwytywanie wrażliwych informacji w ruchu.
Wykorzystanie
Znajdź kroki wykorzystania w oryginalnym badaniu: https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated