クロスアカウントのプライベートホストゾーンを使ったチョット怖い話

先日のアップデート記事にてクロスアカウントのプライベートホストゾーンが悪用されるケースについてさらっと触れましたが、本記事にてもう少し詳細に説明したいと思います。

想定している環境

今回の想定は外からの攻撃ではなく、内部の悪意のある従業員による攻撃を想定しています。

悪意のある従業員は攻撃用の AWS アカウントにプライベートホストゾーンを作成し、攻撃対象の VPC に対して関連付け出来るように承認を行います。

$ aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z0726249140AAR8TX1YWT \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-010be4739e500d319
HostedZoneId: Z0726249140AAR8TX1YWT
VPC:
  VPCId: vpc-010be4739e500d319
  VPCRegion: ap-northeast-1

次に攻撃対象として狙われたあなたの VPC から、事前に作成しておいたプライベートホストゾーンに対して、クロスアカウントでの関連付けを行います。

$ aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z0726249140AAR8TX1YWT \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-010be4739e500d319
ChangeInfo:
  Comment: ''
  Id: /change/C10075012WJ67JNEX16U6
  Status: PENDING
  SubmittedAt: '2020-06-20T10:31:20.701000+00:00'

用意周到な悪意のある従業員は、この時点では常に本来のレコードと同じ内容が返るように偽のプライベートホストゾーンを管理しているため、誰もこの事実には気づいていません。

$ dig dev.classmethod.jp +short
54.178.152.146
3.113.86.157
18.180.87.239

偽のプライベートホストゾーンはご覧のとおりです。

ある日、攻撃がはじまった

悪意のある従業員は、ひっそりと A レコードを書き換え、あなたの VPC から次々に悪質な Web サイトへとトラフィックが流れはじめ、マルウェアはあなたの VPC 内に蔓延しはじめます。

$ dig dev.classmethod.jp +short
52.xxx.xxx.xxx

これまではクロスアカウントでプライベートホストゾーンを参照している側から、当該 VPC が dev.classmethod.jp をプライベートホストゾーンで参照していることが確認できるのは associate-vpc-with-hosted-zone 時に出力される CloudTrail ログのみでした。また、関連付けの解除に必要となるホストゾーン ID が確認できるのも CloudTrail ログのみでした。

悪意のある従業員は発見を遅らせるために忍耐強く待ち、長期にわたり攻撃をしかけなかった場合、あなたは数万行、数十万行のログのなかから見落とした associate-vpc-with-hosted-zone ログに辿りつくことが出来るでしょうか。

というのが以前までの状態でしたが、これは先日のアップデートで追加された list-hosted-zones-by-vpc によって、簡単に調査が可能となっていますのでご安心ください。

関連付けの解除ができない！

どうにかして異常に気づきプライベートホストゾーンの事実に辿り着いたとしましょう。あなたは、判明したホストゾーン ID を使って disassociate-vpc-from-hosted-zone コマンドで関連付けを解除し、いち早く復旧させようと試みるでしょう。

しかし、事はそんなに簡単ではありません。

悪意のある従業員は管理者がこの事態に気づくことも想定し、次の手を打っています。悪意のあるプライベートホストゾーンに関連付く VPC から自身の VPC は削除し、あなたの VPC のみが関連付けられている状態にしているでしょう。

プライベートホストゾーンには制約があり、最後の 1 つとして関連付けられている状態では disassociate-vpc-from-hosted-zone は受け付けられません。

最後の VPC とプライベートホストゾーンの関連付けを解除することはできません。その VPC の関連付けを解除するには、まず別の VPC をホストゾーンに関連付ける必要があります。

（引用：プライベートホストゾーンから VPC の関連付けを解除する）

$ aws route53 disassociate-vpc-from-hosted-zone \
  --hosted-zone-id Z0726249140AAR8TX1YWT 
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-010be4739e500d319

An error occurred (LastVPCAssociation) when calling the DisassociateVPCFromHostedZone operation: Cannot remove last VPC association for private zone

こうなってしまってはプライベートホストゾーンの解除をユーザー側で行うことは出来ません。AWS サポートに介入していただくように相談しましょう。しかし、復旧するまでにしばらくの時間は掛かってしまうでしょう。。

ユーザー側で出来ること

ではユーザー側で何もできないのでしょうか？

このような状態に陥った場合に想定される、いくつかの暫定対策案を検討しました。環境に依存するところが多いので、参考程度にとらえてください。

自アカウントで同名のプライベートホストゾーンを作成できるか？

いいえ、出来ません。すでに classmethod.jp が当該 VPC のプライベートホストゾーンとして関連づけられているため、以下のようなエラーになります。

The VPC vpc-010be4739e500d319 in region ap-northeast-1 has already been associated with the hosted zone Z06768722B376SR3RUCJ9 with the same domain name.

（余談ですが、先ほど従来は CloudTrail ログのみと伝えましたが、同じドメイン名のプライベートホストゾーンを関連付けようとすると、すでに関連付けられているホストゾーン ID は確認できるんですね。エラーメッセージとして、ですが。。）

enableDnsHostnames および enableDnsSupport を false にする？

たしかにプライベートホストゾーンを利用するためには enableDnsHostnames および enableDnsSupport が true であることが条件となっていますので、いずれかを false にすることでプライベートホストゾーンの使用を止めることはできます。

しかし、VPC エンドポイントなど enableDnsHostnames および enableDnsSupport が true であることを条件としたサービスはいくつかありますが、それらも同時に利用できなくなりますのでシステムとして維持できるかについては環境に依存するでしょう。

/etc/hosts に直接書く？

影響を受けている対象が少なく、且つ、/etc/hosts を編集可能でれあば緊急対応としてはてっとり早いでしょう。ただし、対象が多かったり、宛先となるリソースの IP が動的に変わる場合は難易度が高くなりそうです。

Route 53 Resolver ルールを使う？

先述のとおりプライベートホストゾーンでの重複はできませんが、Route 53 Resolver ルールを使って別の DNS に向けることで、プライベートホストゾーンよりも優先させることが可能です。

プライベートホストゾーンと Route 53 Resolver ルール
プライベートホストゾーン (example.com) があり、ドメイン名が同じである場合にネットワークにトラフィックをルーティングする リゾルバー ルールがある場合は、リゾルバー ルールが優先されます。

（引用：プライベートホストゾーンと Route 53 Resolver ルール）

何をすれば良かったか

このように悪意のある従業員によって仕込まれたクロスアカウントのプライベートホストゾーンはとても厄介です。

list-hosted-zones-by-vpc が追加されて調査しやすくなったとはいえ、クロスアカウントのプライベートホストゾーンは AWS コンソールに表示されませんし、AWS Config も Route 53 に対応していませんので、まだまだ気づきにくいことに変わりありません。

悪意のある従業員からするとセキュリティグループなどに比べて気づかれにくいクロスアカウントのプライベートホストゾーンは、DNS スプーフィング（なりすまし）のバックドアを作るためのツールとして都合がよいことがお解りいただけたでしょうか。

では、管理者は何をすれば良かったのか？について、考えていきましょう。

権限管理

クロスアカウントのプライベートホストゾーンの関連付けは、当該ドメイン名の主導権をプライベートホストゾーンの管理アカウント側に渡す、ということです。

そのため、route53:AssociateVPCWithHostedZone 権限については、Permissions Boundary などを使って制限するのが良いでしょう。（もちろん、その他の Route 53 権限についても広く許可するべきではないでしょう）

ただし、route53:AssociateVPCWithHostedZone を制限してしまうと、自アカウントのプライベートホストゾーンも関連付けできなくなってしまう点は悩ましいですが。。

変更検知

Amazon EventBridge 使って、AssociateVPCWithHostedZone イベントを通知することで意図しないプライベートホストゾーンの関連付けに気づくことができます。

CloudTrail はバージニア北部リージョンに出力されますので、EventBridge および SNS はバージニア北部リージョンで作成する点はご注意ください。

{
  "source": [
    "aws.route53"
  ],
  "detail-type": [
    "AWS API Call via CloudTrail"
  ],
  "detail": {
    "eventSource": [
      "route53.amazonaws.com"
    ],
    "eventName": [
      "AssociateVPCWithHostedZone"
    ]
  }
}

発見的統制

プライベートホストゾーンの書き換えを防ぐものではありませんが、最悪のケースも想定し、IDS/IPS のサードパーティ製品を使って不正なトラフィックを検出、遮断するような対策も効果的です。

てっとり早く脅威検出するだけであれば Amazon GuardDuty はオススメです。DNS の書き換えによって EC2 から**異なるパターンのアウトバウンドが発生するでしょうから、かなりの確率で検出が期待できるでしょう。

さいごに

アップデートをきっかけにクロスアカウントでのプライベートホストゾーン利用について調べる機会があり、そのなかで悪用されたときに気づきにくいという課題があることを知りました。

あくまで管理されていない状態において危険性があるという啓蒙であり、クロスアカウントのプライベートホストゾーンそのものの利用に対して警鐘を鳴らす記事ではない、という点だけ誤解のないようにお願いいたします。

最近、暑くなってきましたので、稲川淳二よろしくチョットこわい話として取りげてみました。

以上！大阪オフィスの丸毛（@marumo1981）でした！

参考

• Backdooring Route 53 With Cross Account DNS