AWS - Route53 Privesc
Для отримання додаткової інформації про Route53 перегляньте:
route53:CreateHostedZone, route53:ChangeResourceRecordSets, acm-pca:IssueCertificate, acm-pca:GetCertificate
route53:CreateHostedZone, route53:ChangeResourceRecordSets, acm-pca:IssueCertificate, acm-pca:GetCertificateЩоб виконати цю атаку, цільовий обліковий запис повинен вже мати налаштований AWS Certificate Manager Private Certificate Authority (AWS-PCA), а EC2 екземпляри у VPC(ах) повинні вже імпортувати сертифікати для довіри до нього. З цією інфраструктурою можна виконати наступну атаку для перехоплення трафіку AWS API.
Інші дозволи рекомендуються, але не є обов'язковими для частини перерахування: route53:GetHostedZone, route53:ListHostedZones, acm-pca:ListCertificateAuthorities, ec2:DescribeVpcs
Припустимо, що є AWS VPC з кількома хмарними додатками, які спілкуються один з одним і з AWS API. Оскільки зв'язок між мікросервісами часто шифрується за допомогою TLS, має бути приватний CA для видачі дійсних сертифікатів для цих служб. Якщо використовується ACM-PCA для цього, і противник отримує доступ до контролю як route53, так і acm-pca приватного CA з мінімальним набором дозволів, описаних вище, він може перехопити виклики додатків до AWS API, взявши на себе їх IAM дозволи.
Це можливо, оскільки:
AWS SDK не має Certificate Pinning
Route53 дозволяє створювати приватні хостингові зони та DNS записи для доменних імен AWS API
Приватний CA в ACM-PCA не може бути обмежений лише підписанням сертифікатів для конкретних загальних імен
Потенційний вплив: Непряме підвищення привілеїв шляхом перехоплення чутливої інформації в трафіку.
Використання
Знайдіть кроки експлуатації в оригінальному дослідженні: https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/
Last updated
