# AWS - Route53 Privesc

{{#include ../../../../banners/hacktricks-training.md}}

For more information about Route53 check:

{{#ref}}
../../aws-services/aws-route53-enum.md
{{#endref}}

### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`

> [!NOTE]
> この攻撃を実行するには、対象アカウントにすでに [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** がセットアップされており、VPC 内の EC2 インスタンスがそれを信頼するための証明書を既にインポートしている必要があります。このインフラが整っていれば、以下の攻撃で AWS API トラフィックを傍受できます。

Other permissions **recommend but not required for the enumeration** part: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`

Assuming there is an AWS VPC with multiple cloud-native applications talking to each other and to AWS API. Since the communication between the microservices is often TLS encrypted there must be a private CA to issue the valid certificates for those services. **If ACM-PCA is used** for that and the adversary manages to get **access to control both route53 and acm-pca private CA** with the minimum set of permissions described above, it can **hijack the application calls to AWS API** taking over their IAM permissions.

This is possible because:

- AWS SDKs は Certificate Pinning を実装していない
- Route53 は Private Hosted Zone と AWS API のドメイン名用の DNS レコードを作成できる
- ACM-PCA の Private CA は特定の Common Names のみに証明書の署名を制限できない

**Potential Impact:** トラフィックを傍受して機密情報を取得することで、間接的な privesc が発生する可能性があります。

#### 悪用 <a href="#discovery" id="discovery"></a>

Find the exploitation steps in the original research: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/)

{{#include ../../../../banners/hacktricks-training.md}}
