LinkedInでDNSハイジャックの可能性

昨日LinkedInでアクセス障害があり、DNSハイジャックの可能性を指摘されています。

app.netの共同創設者、Bryan Berg氏はその原因を「DNSハイジャック」によるものではないかと指摘している。Berg氏は、「その間LinkedInにアクセスしたユーザーのトラフィックは、Confluence-Networksがホスティングしていたネットワークに送信されていた」と述べ、しかもサイトではSSLを利用していなかったことから、長い有効期限が設定されていたCookieが平文のまま送信された可能性があるとしている。
LinkedInでアクセス障害、原因はDNSハイジャックとの指摘 - ＠IT より引用

DNSハイジャックとは

DNSハイジャックとは、ドメイン名を管理するネームサーバーを乗っ取られることですが、具体的には以下のような状況が考えられます。以下の例では、モデルとしてドメイン名example.jpを使います。

• example.jpの権威DNSサーバー(レンタルDNSサーバー含む)が不正アクセスされた（脆弱性の例）
• example.jpのレジストラのコントロールパネルが不正アクセスされた（他国の例）
• JPドメイン名のレジストリ(JPRS)が不正アクセスされた（他国ではまれにあります; 参考）
• example.jpの管理者がドメイン情報の設定を間違えた（たまにあります）

このうち、レジストラに対する不正アクセスは時々見かけますので、以下、このケースについて説明します。下図は、www.example.jpがDNSハイジャックされる様子を説明するために、まず正常時の状況を図示したものです。

この状況で、example.jpの架空のレジストラ「おネーム.com」（仮に類似の名前のレジストラがあったとしても偶然に過ぎません）のコントロールパネルに侵入され、example.jpの権威DNSサーバーを書きかえられると、下記の状況になります。

evil.example.comは、攻撃者が管理するDNSサーバーです。この状況では、攻撃者はexample.jpのDNS設定を自由に変更できるので、www.example.jpのAレコードを192.0.2.5(攻撃者が管理するWebサーバーのIPアドレス)に変更します。これがDNSハイジャックです。

2010年11月には、著名なデンマークのセキュリティ企業Secuniaが、レジストラDirectNICが攻撃を受けた影響で、ウェブサイトの表示を改ざんされた事件が起こっています（参考、参考）。

DNSハイジャックの影響

DNSハイジャックされると以下の影響があり得ます。

• 秘密情報の漏洩
• コンテンツの書き換え
• サービス停止（今回のLinkedInでも起こった）
• なりすまし

すなわち、セキュリティ上の悪いことは全てあり得るという状況です。
上記の例で説明すると、www.example.jpへのリクエストには、このサイトのCookieが付与されるため、利用者がアクセスした瞬間に、Cookieが漏洩することになります。これは、冒頭に紹介した記事でも言及されています。
さらに積極的に、フィッシングのテクニックによりログイン情報を収集することもできます。正規のドメイン名を悪用されるので、見分けるにはSSL証明書のエラーの他にはないわけですが…LinkedInのトップ画面を確認してみましょう。

なんということでしょう! 平文のトップページにログインフォームが設置してあります。これでは、DNSハイジャックによる偽画面を見分ける術がありません。『SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも』は高木浩光氏の2005年11月の記事ですが、それから約7年半以上たつのに、著名サイトでこのような状況は困ったものです。

情報漏洩やコンテンツ書き換えのシナリオとして、偽のWebサーバーが本物サイトのリバースPROXYとして動く仕組みも考えられます（下図）。

この状況ですと、利用者の通信（リクエストおよびレスポンス）はすべて傍受されます。中間者攻撃(MITM)という奴ですね。攻撃者は盗聴に徹することもできますし、iframe要素やscript要素を埋め込んで、利用者の端末にマルウェア感染させることもできます（利用者の端末に脆弱性がある場合）。

対策

DNSハイジャックの根本対策は、DNS運用を見直すこと、信頼の置けるレジストラ（どこ?）と契約するくらいでしょうが、私はDNSの専門家ではないので、具体的には専門家の解説にゆだねたいと思います。
Webサイト側でとれる緩和策としては、SSLの運用があります。

• 少なくとも入力フォームからSSLとする
• サイト全体をSSLとする（いわゆる常時SSL）を検討する
• 機密性の要求されるCookieにセキュア属性を付与する

GoogleやTwitterは常時SSLに移行していますし、今後この流れが進むのではないでしょうか。
徳丸は今年の6月13日以降下記を実施しています。

• 会社ホームページは常時SSLとする
• DNS情報の監視スクリプトの稼働

後者のDNS情報の監視ですが、TLDから当該ドメイン名などのツリーから監視項目を定め、別サーバーから定期的に監視するようにしています。このままですと、監視システムが動いているか不安になるので、テスト用のドメイン名についても監視して、たまに人為的にDNS設定を変更して、検知されることを確認しています。

まとめ

LinkedInのアクセス障害がDNSハイジャックである可能性を受けて、DNSハイジャックの脅威について説明しました。
DNSに対する攻撃は意外に頻繁に発生しており、Webサイト管理者が想定しておかなければならない脅威と言えます。すぐにとれる対策としては、SSLの使用状況を見直すことが挙げられます。