$ whoami

@wa6sn

• CCoE っぽいこと、データ基盤、セキュリティ、データベースなど

• 今年の目標

  • 人と話す
  • https://speakerdeck.com/wa6sn を 4 つぐらいに増やす

今日

• サービス運用の過程で、様々な資産の棚卸しを行うと思いますが、
  それが甘かった （ゆるかった？） ことで発生したことを話します

  • さまざまな配慮により、一部ぼかしています

• 不要なリソースレコードはセキュリティリスクにつながるので消そう

  • DNS のそれに限らず、不要なリソースはマメに消そう

• 懇親会は、せっかくオフラインなので、こういう話を聞きたいです

発端

コーポレートチーム「こんなメールが届いたんですが……」

本当？

• 本当でした
• ドメインの乗っ取りって本当にあるんだなあ
  • ※ 今回は善意の報告であり、実害を被ったわけではありません

DNS takeover

• DNS リソースレコードについて、紐づけ先が利用終了したあともレコードを残したまま になってしまっていることを利用し、第三者がそのドメインの乗っ取りを図る攻撃手法

  • 特に目新しいものではなく、古くからある攻撃

• Subdomain takeover や NS takeover は、そのより細かい分類にあたる

• https://jprs.jp/tech/material/iw2020-lunch-L3-01.pdf が詳しいです

  • "jprs iw2020 lunch" で検索すると出ます

例

1. 「イベント用ページを作りました！
   　Netlify でホスティングして CNAME で event2023. に向けますね。」

# wa6sn.com は wa6sn 社が所有するドメイン
event2023.wa6sn.com.    300	IN	CNAME	temp-event.netlify.com.

2. 「イベントが終わったので、Netlify のサイトは消しておきます！」

   • 一方、リソースレコードを消し忘れる

3. 忘れたころに誰かが Netlify で temp-event.netlify.com を取得する。
   event2023.wa6sn.com. にアクセスした人が、意図しないページに飛ぶ

例の解説

「建物を取り壊すなら、案内板（レコード）も外さないといけない」

• 任意のサブドメインを指定して取得できる Netlify や Vercel のような
  サービスでは、temp-event.netlify.com. は誰でも取得できるので、
  DNS リソースレコードも同時に消さないと、第三者が takeover できてしまう

  • その他、S3 バケットの Web hosting 機能が悪用された例も
    • https://blog.flatt.tech/entry/s3_security

• CNAME レコードの例だけでなく、AWS の Elastic IP のような
  「共有プールから払い出されるような IP」を A レコードで指定している場合も、
  第三者による takeover が起こりうる

補足: NS takeover

• ネームサーバにおいても同様の仕組みでドメイン名を takeover できる

  • 「委任先」が無くなっているのを確認して、なりかわるイメージ

• サービス提供者側が takeover を防ぐような仕組みを用意していることがある

  • https://github.com/indianajson/can-i-take-over-dns のような、
    Vulnerable な DNS Provider かどうかをリストするようなリポジトリもある
  • AWS の Route53 はネームサーバとしては Not Vulnerable（安全）
    • https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/protection-from-dangling-dns.html

対応

• DNS takeover という攻撃の概念を社内で共有した

• 会社にある全 AWS アカウントの Route53 に設定されているリソースレコードを
  列挙・共有しつつ、レコードタイプ別にリスク判断と棚卸し

  • 「CNAME で向き先が Vercel や Netlifiy のように任意のサブドメインを取得できるもの」はリスク高、「向き先が CloudFront」ならドメインの左端部分はランダム化されているのでリスク低、みたいな

• それはそうと、使っていないものは消してほしいな、といった呼びかけ

わりとポロポロ

潜在的なリスクが

見つかるのであった

感想

• クラウドサービスが前提になった昨今、様々なリソースを「作る」ハードルは
  下がったけど、「捨てる」ことまで気が回っていないことも多い（気がする）

• 思った以上に「不要なもの」は堆積する

  • 意識しないと不要なものは掃除されないがち
  • 掃除するリスクが高いと判断されて残ったまま、背景が分からなくなりがち
    • 発覚したものは 5〜10 年物のリソースばかり

• 今回は善意の報告がきっかけで運が良かったけど、
  いつもそうとは限らないので気を引き締めていきたい