DNSキャッシュポイズニングのリスク - ケーススタディ
攻撃ではない、バッドプラクティスが引き起こすDNSポイズニング
2023年10月24日
翻訳: 竹洞 陽一郎
この記事は米Catchpoint Systems社のブログ記事「DNS Cache Poisoning Risks - Case Study
」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。
サードパーティのプロバイダは、Webサイトに多くの利点をもたらします。
これには、運用コストの削減（CDN）、収益生成（広告）、より良い洞察（分析）などがあります。
それらはシステムの任意のコンポーネントと同じく、リスクも持っており、プロバイダとサイトはそのリスクを様々な手段で管理しようとします。
最も話題にされるリスクは、ページ上のJavaScriptタグ、貧弱なコード、または遅いAPIコールを通じてWebサイトやアプリケーションに与えるパフォーマンスへの影響です。
二番目に広く取り上げられるリスクはエンドユーザのプライバシーです。
つまり、プロバイダがサイトやユーザの知識なしに（故意かどうかを問わず）ユーザ情報をサイト間で収集することです。
最近、私たちはスポットライトを浴びていないが、サイト運用に大きな影響を与える第三のリスクに出くわしました。
大手のeコマース企業と作業している際に、彼らのモバイルサイトを監視していると、時折DNSエラーが発生していることに気付きました。
何時間ものトラブルシューティングと実験の後、モバイルサイトのプロバイダであるUsablenetが誤ってDNSキャッシュを汚染していることが判明しました。
DNSキャッシュポイズニングとは?
DNSキャッシュポイズニングとは、新しいDNSレコードがリゾルバやコンピューターのDNSキャッシュに導入され、トラフィックが別のIPアドレスに誘導されるデータ侵害を指します。
キャッシュポイズニングは、ハッカーがトラフィックをフィッシングサイトやマルウェアサイトに誘導しようとする場合や、設定ミスが原因で起こる場合があります。
いずれの場合も、エンドユーザにとっては良くない結果となります。
間違ったサイトにアクセスしてしまうか、あるいはあなたのサイトにまったくアクセスできなくなる可能性があります。
DNSキャッシュポイズニングはどのように起こるか？
Usablenetはモバイル変革のリーダーであり、そのプラットフォームはExpedia、Dell、Fedexなどの主要ブランドのモバイルWebサイトを支えています。
このプラットフォームによって、企業は既存のWebサイトをエンドユーザのデバイスの機能に合ったモバイルWebサイトに迅速に変換することができます。
このモバイルプラットフォームの一つの重要な要件は、モバイルサイトのDNSレコードがUsablenetによって処理されることです。
例えば、Expediaのウェブアドレスはwww.expedia.comであり、Expediaのサーバにポイントしています。
しかし、モバイルサイトについては新たなDNSレコード「m.expedia.com」を作成し、それをUsablenetの権威あるDNSサーバに委任しました。
Dig（DNS問い合わせツール）を使用して、OpenDNSサーバの1つを使用してm.expedia.comがどこにあるのかを問い合わせしました。
(訳注: 2012年の時点の結果です)
$ dig +norec +trace @208.67.222.222 m.expedia.com ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 <<>> +norec +trace @208.67.222.222 m.expedia.com ; (1 server found) ;; global options: +cmd . 71766 IN NS a.root-servers.net. . 71766 IN NS b.root-servers.net. . 71766 IN NS c.root-servers.net. . 71766 IN NS d.root-servers.net. . 71766 IN NS e.root-servers.net. . 71766 IN NS f.root-servers.net. . 71766 IN NS g.root-servers.net. . 71766 IN NS h.root-servers.net. . 71766 IN NS i.root-servers.net. . 71766 IN NS j.root-servers.net. . 71766 IN NS k.root-servers.net. . 71766 IN NS l.root-servers.net. . 71766 IN NS m.root-servers.net. ;; Received 228 bytes from 208.67.222.222#53(208.67.222.222) in 13 ms com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. ;; Received 491 bytes from 192.36.148.17#53(m.root-servers.net) in 141 ms expedia.com. 172800 IN NS pdns3.ultradns.org. expedia.com. 172800 IN NS pdns4.ultradns.org. expedia.com. 172800 IN NS pdns1.ultradns.net. expedia.com. 172800 IN NS pdns2.ultradns.net. expedia.com. 172800 IN NS pdns5.ultradns.info. expedia.com. 172800 IN NS pdns6.ultradns.co.uk. ;; Received 234 bytes from 192.12.94.30#53(k.gtld-servers.net) in 173 ms m.expedia.com. 900 IN NS glb.ky.4usable.net. m.expedia.com. 900 IN NS glb.tx.4usable.net. ;; Received 84 bytes from 204.74.108.1#53(pdns1.ultradns.net) in 80 ms m.expedia.com. 120 IN A 174.123.66.58 m.expedia.com. 120 IN A 174.123.66.58 expedia.com. 38400 IN NS b01h.4usable.net. ;; Received 93 bytes from 174.123.66.38#53(glb.tx.4usable.net) in 56 ms
問題は、モバイルのDNSエントリが解決されたときに発生します。
Usablenetの権威サーバに問い合わせると、彼らは「m.expedia.com」のAレコードを（二度）提供するだけでなく、新しいNSレコードも「expedia.com」に対して提供します。
基本的に、彼らは自分たちのDNS「system balancer.ky.4usable.net」を「.EXPEDIA.COM」ゾーン全体に対する権威あるサーバとして昇格させ、TTL（Time To Live）を38,400秒、すなわち10時間に設定しています。
m.expedia.com. 120 IN A 174.123.66.58 m.expedia.com. 120 IN A 174.123.66.58 expedia.com. ☜ 38400 IN NS ☜ b01h.4usable.net. ☜ ;; Received 93 bytes from 174.123.66.38#53(glb.tx.4usable.net) in 56 ms
これはキャッシュポイズニングを引き起こす一つの方法であり、それは悪い実践です。
以下のドメインでも同じ問題が発生しているので、試してみることができます。
(訳注：これは2012年の時点で警告として挙げられている例で、現在は異なります。)
- m.chanel.com
- m.asos.com
- mobile2.macys.com
なぜこれは悪い実践なのか？
エンドユーザが「m.expedia.com」にアクセスしてから、「www.expedia.com」や「mail.expedia.com」などのExpediaのドメインにアクセスしようとすると、そのISP（インターネットサービスプロバイダ）のDNSリゾルバは、Usablenetのサーバが権威あるレコードの1つであるため、UsablenetからDNSレコードを問い合わせる可能性があります。
最終的な結果としてDNSの失敗が発生し、ユーザはサイトにアクセスできなくなります。
この問題は、DNSサーバによってデータがキャッシュされ、それが他のエンドユーザに利用されると、問題が拡大します。
幸いなことに、大多数のエンドユーザはこれらのドメインにモバイルデバイスでアクセスし、これらのデバイスが依存しているDNSサーバはデスクトップで設定されたものとは異なります。
それでもリスクは存在し、その影響は容易には測定できません。
リアルユーザモニタリングとWeb分析ソリューションは、このような失敗を追跡することはできません。
（DNSが失敗すると、WebサーバはHTTPリクエストを受け取らず、ログに記録されず、分析／RUMのタグもエンドユーザには配信されません）
モバイル体験、広告の配信、バニティドメイン(※)などを提供するために、クライアントがDNSエントリを自分たちのシステムに委任するような他の第三者プロバイダもあります。
もし、あなたの企業がこのようなDNSの委任を行う必要がある場合は、プロバイダが誤ってDNSを汚染していないか確認とフォローアップが必要です。
DNSはユーザがあなたのブランドと最初に接触する部分です、それを守り、パートナーにも同じことを要求してください。
※訳注: バニティドメインとは、企業や個人がブランド名や特定のキーワードを反映した、独自かつ覚えやすいドメイン名のことを指します。
注: このブログ記事で指摘した問題は、ベンダーによって、2012年3月15日に修正されました。