静的ウェブサイトをホスティングしている S3 と Subdomain Takeover の関係について

この記事は公開されてから半年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

静的ウェブサイトをホスティングしている S3 を削除した際に発生する Subdomain Takeover のリスクについて、意外と認知度が低いのではないかと思い、まとめました。

Subdomain Takeover とは

企業が所有しているサブドメインを乗っ取り、悪質な詐欺サイト等へ誘導する攻撃手段です。例えば、企業が自社サービスをクローズしたりすると、そこで使用されていたサブドメインが削除されず、放置されることがあります。この放置されたサブドメインを攻撃者が取得し、管理下に置くことで、フィッシング攻撃、悪意あるコンテンツのホスト等、破壊的な活動を行うことができます。

S3 と Subdomain Takeover の相性

個人的な意見ですが、S3 と Subdomain Takeover はとても相性が良いです。他の CDN サービスに比べ、少しの知識で容易く攻撃を行うことができます。次項からは、どういった状況でどのような手口で攻撃が行われるのか、サブドメインを保持する企業側と攻撃者側のそれぞれの視点から説明していきたいと思います。

企業視点

自社サービスを開発している企業があります。企業は最近、サービスの一部をクローズすることになりました。サービスは S3 に静的コンテンツとしてホストされており、Route53 のホストゾーン内にあるサブドメインレコードへ、その値が登録されています。開発者は事業部からの依頼を受け、不要となった S3 の削除を行いました。しかし、その際に Route53 の存在を失念し、レコードを削除せずに作業を終えてしまいました。現状は、コンテンツがホストされた S3 は存在しないが、Route53 にレコードだけは残っている、という状態です。

上記の結果、使用されずに放置されたサブドメインが誕生します。

攻撃者視点

攻撃者はまず、放置サブドメインを発見します。それが S3 でホストされていた場合、サブドメインへアクセスした攻撃者側には、以下のような画面が表示されます。

これにより、攻撃者は以下の情報を得ることができます。

このドメインは S3 でホストされている。
バケット名は「×××」である。
現在、バケットは存在していない。

更に、ドメインに対して dig や nslookup などのコマンドを用いれば、バケットのリージョンも調べることができます。

各種情報を手に入れた攻撃者は、自身の AWS アカウント上に攻撃対象と同じ名前のバケットを作成します。その後、作成したバケットの静的ウェブサイトホスティングを有効にすることで、企業が保持していたサブドメインレコードの向き先が自動的に攻撃者所有のバケットとなり、サブドメインを乗っ取ることができます。加えて、作成したバケットへ悪意のあるコンテンツを配置すると、それ以降サブドメインへアクセスしたユーザーに対して、攻撃を試みることが可能です。

防止策

対象が S3 の場合に限ったことではありませんが、Subdomain Takeover を未然に防ぐためには、リソース及びドメインの管理を徹底することが大切です。

現状では IAM や SCP 等といったサービスを用いても、AWS を使って作業をするユーザーに「Route53 から参照されている場合は S3 の削除を許可しない」といった動作を強制することはできません。また「Route53 のレコードに値として登録された S3 が今も環境に存在しているか」という監視の実装も、コードの記述等が必要になり、簡単にはできないかと思われます。

今回例に挙げた事例で、開発者ができることを挙げます。