世の中でもセキュリティ攻撃の話題が賑わってますが、なんと自分の環境も攻撃を受けちゃいました。
分析調査や対応について、そんなに情報見つからない気がするので、今後、同じようなことにあった方が迅速に対応できるよう、ブログで残しておきたいと思います。

※ 逆手に取った悪用は絶対にしないでください

今回、攻撃を受けた構成はこんな感じでした。

赤字の箇所が、通常の構成と異なるところ。公式ドキュメントを守っていないところです。

サブドメインに対して CNAME レコードを使うことは問題はないですが、バケット名と異なるものは NG になります。

重要
バケットは、ドメインまたはサブドメインと同じ名前にする必要があります。例えば、サブドメイン acme.example.com を使用している場合、バケットの名前は acme.example.com にする必要があります。

論理的には動きそうだなぁと思って試しに設定した（実際、その当時は問題なく動作した）ままだったのが、今回の問題点の一つでした。

では、検知からその後の対応についても述べていきたいと思います。

検知 〜 初動対応編

検知

仕事も終わり、最後にメールチェックをしていたところ、見慣れないメールが…
「New owner for http://www.example.com/」（ example.com は実際は自分のドメイン ）という件名で届きました。

このドメインは、Gemini for Google Workspace など新しめの機能を勉強するために、個人で契約している Google Workspace で使っています。
そこにオーナーとして、全然知らないアドレスが追加されたと。
このアドレスはフリーメールアドレスなのでますます怪しい…怪しすぎる！

自分のドメインではあるものの、www のサイトは作った記憶はあるが、Google Serch Console に登録した記憶はない。
サイトにアクセスすると、何やら海外のゲーム広告っぽいものに。
完全にヤられている。

ここで、なんとなく状況は理解できたので、初動対応にかかりました。

初動対応

DNS レコードを削除

まずは、www のレコードを削除しました。
Route 53 で管理しているホストゾーンだったので、該当レコードを選んで削除。
これで、サイトアクセスはできなくなり、何が仕込まれているかわからないコンテンツの配信を止めて、世の中に迷惑をかけないようにします。
まずは、レコードを削除を頭の片隅に置いておきしましょう！

Google Serch Console での該当ユーザー削除

こっちに少し苦戦。
送られてきたメールに従い、コンソールを確認してみても、該当のユーザーが見つからない。
インターネット上を検索しても、同じような質問は見つかったが、どれも解決はしていなさそう…

プロパティが怪しそう。

メールで届いた URL で、URL Prefix を追加。

追加した URL Prefix を選択し、ユーザー一覧を確認することで、不正に作られたユーザーを発見。
無事、不正ユーザーを削除できました。

調査・分析 〜 対応編

調査・分析

現状どうなっているのか？

検証のみの環境のため、サイトは不要なものの、何が起こっているのかを調査。

S3 バケットを「www.example.com」で作ろうとしたところ、そのバケット名はすでに利用されているとのこと。
乗っ取られている…

偽サイトのソースコードを見ると、verification token のメタタグが付けられていた。
これを使って、Google Serch Console 上のユーザーを作った模様。
実際に試してみたところ、ユーザー削除と同様の手順で、別の Google Workspace アカウントからも対象の FQDN のメタタグを発行できました。

この FQDN が狙われた理由（漏洩元）としては、外部からクラウドのサブドメインテイクオーバーを補助するツールはいろいろ出回っているので、そこからだろうとは思いましたが、一応、CloudTrail などを確認し、IAM 情報の漏洩はなさそうであることを確認しました。

万が一、IAM 漏洩していると危険なので、確認は必須です。

名前解決の挙動

名前解決のメカニズムは、ドキュメント上ではそこまで詳細に明記されていなかったので、実際に色々試してみました。

  • 別の S3 バケットで、Web ホスティングしたものに CNAME を向ける
    論理的には行けそうな気もしますが、冒頭で挙げた重要項目の違反です。
    ドメインと一致するバケット名のものが存在しない場合は、これでも動作はしました。（※ ドキュメントに書かれている NG パターンなので動作の保証はない）
    一方、バケットが存在する場合は、CNAME に設定した値ではなく、ドメインと一致するバケット名の方が優先されてしまいます。冒頭で書いた構成図のものがこちらです。
    蛇足ではありますが、S3 のバケット名は AWS アカウント横断的にリージョン内でユニークである必要があるので、自分の AWS アカウントを確認するだけではダメです。
  • ALB 配下で Web サイトを構築
    この場合だと、CNAME でも A レコードでも、どちらででも自身のサイトの方へ名前解決されました。
  • AWS 外部のサイトに CNAME を向ける
    この場合も、自身のサイトの方へ名前解決されました。

対応

Abuse レポートを挙げることで、AWS 側で対処してくれる可能性はありますが、おそらくレコード削除などで無効化することで、攻撃者側があきらめてバケット削除するとは思います。
いずれにせよ、それまでは直接の S3 Web ホスティングでの提供は諦めねばです。

サイトの復旧手段を考察

先に書いた名前解決の挙動も、明確に定義されているものではないので、バケットが削除されるまではレコードを作らないほうが無難そうです。
ただ、もし商用環境であった場合には、Abuse の対応を待っているだけでは辛いと思います。そこで、どのような復旧手段があるのかを考察してみました。

結論、以下のような手段が考えられます。

  • CloudFront を前段に置く
    今のところ、これがベストの気がします。
    先ほど述べた Route 53 での S3 Web ホスティングドメインの名前解決は、あくまで CNAME で S3 Web ホスティングドメインの名前解決時の優先順位です。
    それ以外のドメインでは、設定内容が優先される挙動です。
    CloudFront を前段に置く構成では、CloudFront のドメインを CNAME として登録するようになります。
    そうすることで、乗っ取られたバケットへの名前解決が行われなくなります。
    ※ くどいですが、S3 Web ホスティングのマニュアルには、FQDN とバケット名を揃えるよう記されています。何かあっても動作保証外となるリスクはある暫定対応です。
  • EC2 や ECS で Web サーバーを立ち上げる
    コンテナなどを使うことで、環境構築のコストは下がって入るものの、構成変更が必要になるのでできれば避けたいところです。
  • 別のクラウドの静的ホスティングサービスを利用
    S3 以外の CNAME であれば、そちらが優先されるので、こちらでも対応可能。ただし、同じ静的ホスティングサービスでも、使い勝手はかなり違うので、よほど精通していないと辛そう。

再発防止編

一つのアカウント内で、Route 53 も管理しているのであれば、Config Rule とか書けばいい気がしますが、
ドメインは別アカウントで管理することも多いと思うので、単純に Web Hosting のバケットを削除する際には、合わせてレコードも削除することを徹底するとか。

また、ドメイン取得時に、www は一般的なもので、「www.example.com」 バケットを作っておくことも有効かもと思いました。

まとめ

早々に気づけてよかったです。通知に感謝！

自分の個人用の環境だったことが不幸中の幸いで、企業サイトだったらと思うと、いい学習の機会となりました。
フィッシングサイトを作成されて、ユーザーに損害を与えるような大きな問題にもなりかねません。

ちょっとしたミスで発生してしまうものなので、気をつけましょう！
また、ここに記した手順で、一次対応から暫定復旧まではできると思いますので、もし陥ってしまった際は落ち着いて速やかに対応しましょう！