世の中でもセキュリティ攻撃の話題が賑わってますが、なんと自分の環境も攻撃を受けちゃいました。
分析調査や対応について、そんなに情報見つからない気がするので、今後、同じようなことにあった方が迅速に対応できるよう、ブログで残しておきたいと思います。
※ 逆手に取った悪用は絶対にしないでください
今回、攻撃を受けた構成はこんな感じでした。
赤字の箇所が、通常の構成と異なるところ。公式ドキュメントを守っていないところです。
サブドメインに対して 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」 バケットを作っておくことも有効かもと思いました。
まとめ
早々に気づけてよかったです。通知に感謝！
自分の個人用の環境だったことが不幸中の幸いで、企業サイトだったらと思うと、いい学習の機会となりました。
フィッシングサイトを作成されて、ユーザーに損害を与えるような大きな問題にもなりかねません。
ちょっとしたミスで発生してしまうものなので、気をつけましょう！
また、ここに記した手順で、一次対応から暫定復旧まではできると思いますので、もし陥ってしまった際は落ち着いて速やかに対応しましょう！
