この記事は、Ciscoの脅威インテリジェンスアナリストBen Nahorneyによるブログ「DNS under attack」（2019/7/25）の抄訳です。
ご存じかもしれませんが、最近、インターネットの根幹を成す DNS が頻繁に攻撃を受けています。
英国の国家サイバー セキュリティ センター (NCSC : National Cyber Security Centre) は今月初めに、複数の地域や業界で DNS ハイジャック攻撃が起きているとして、注意勧告を出しました。これは過去 6 ヵ月で 2 回目の勧告となります。先月に IDC から出された『2019 Global DNS Threat Report（DNS への脅威に関する 2019 年のグローバルレポート）』は、DNS 攻撃の増加と関連コストの大きさに警鐘を鳴らしています。また今年初めには、「（DNS インフラという）基幹部に対して継続的かつ重大なリスクが存在する」として ICANN が警告を出し、より堅牢なセキュリティ実装の導入を呼びかけています。
シスコの脅威インテリジェンスグループである Cisco Talos は、これまで DNS を入念に監視してきました。DNS の改ざんを主な手口とする複数の攻撃を検出してきたほか、警告を促す調査も数多く発表しています。
DNS に対する攻撃は重大な懸念事項です。しかし DNS とは何でしょうか？また、攻撃方法はどのようなもので、どう対策すればよいのでしょうか？
DNS の基本
まず DNS について簡単にご説明します。DNS は「ドメインネームシステム」の略で、さまざまな Web サイトなどにユーザを誘導するためのインターネットの中核技術です。DNS の仕組みは、図書館員に蔵書について尋ねるのに例えられます。図書館員は蔵書の案内係ですが、DNS の場合はそれが本ではなく特定の Web サイトになります。DNS の役目はレコードを確認し、Web サイトの場所をコンピュータに通知することです。
この観点から DNS は一種の通訳だとも言えます。人間が判読可能なドメイン（www.example.com など）を取得し、それをサイトの IP アドレス（ドメインを参照するためにコンピュータが使用する番号）と照合するからです。つまり、「このドメインの IP アドレスは何か？」という質問に答えるのが DNS です。
図 1：DNS の仕組み
DNS ルックアップの標準的なプロセスは複数の DNS サーバが関係するため、上記の説明よりも少し複雑です。最初に接続されるサーバは DNS リゾルバです。先ほどの例では図書館員が該当します。そこからのプロセスは、一般に次のようになります。
- リゾルバは Web サイトの場所を DNS ルートサーバに問い合わせます。これは蔵書の場所について図書館員が図書目録を調べるのと同じです。
- ルートサーバは、リゾルバをトップレベルドメインサーバ（TLD : Top Level Domain サーバ）に送信します。TLD はドメイン（.com、.net、.org など）ごとに存在する DNS サーバです。図書館の例で言えば、デューイ十進分類法（図書分類法の一種）に相当します。
- TLD サーバは、到達しようとしているドメインの公式 DNS サーバの場所を特定し、その IP アドレスをリゾルバに伝えます。DNS ネームサーバは、例えるならば図書の所在確認票です。
- リゾルバは目的ドメインの IP アドレスをコンピュータに通知し、コンピュータはサイトにアクセスできます。目的ドメインの IP アドレスは、所在確認票に印刷された本の場所だと言えます。
図 2：詳しい DNS の仕組み
攻撃の仕組み
DNS 攻撃で特異なのは、標的を直接攻撃せず、図書館員を攻撃する点です。
この攻撃は一般に「DNS ハイジャック」または「DNS リダイレクト」と呼ばれます。図書館員が持つ蔵書の情報を改ざんするのと同じです。蔵書の情報が改ざんされていると、図書館員に場所を尋ねても完全に誤った場所に誘導されることになります。誘導された先の棚には、一見すると目的の本があります。しかし実際の中身は完全なる別物で、子ども向けの本を装った『アナーキストクックブック』（爆発物、薬物の作成法などについて書かれた本）が置かれていたりします。
DNS 攻撃の目的は、Web サイトへの正当なルートを改ざんして不正サイトに誘導し、最終的に標的へ侵入することです。被害者は目的ドメインの IP アドレスを要求しますが、DNS レコードが改ざんされているため、実際には不正サイトの IP アドレスが返されます。
図 3：DNS リダイレクト
DNS レコードが改ざんされるシナリオは無数考えられます。いくつか例を挙げてみましょう。
- フィッシング攻撃により DNS 管理者のログイン情報が流出。それを基に攻撃者が DNS 管理画面にログインし、サイトの IP アドレスを改ざん。
- DNS レコードが維持管理される DNS ホスティング インターフェイスに攻撃者が侵入し、ドメインレコードを改ざん。
- DNS リクエストチェーンに沿った DNS サーバまたは DNS インフラの一角を攻撃者が改ざんし、不正なリダイレクトを形成。
過去 10 年間のリダイレクト攻撃
DNS システムの欠陥や弱点は長らく知られていましたが、最初の大規模な DNS 攻撃は 2009 年に始まりました。2009 年の攻撃では twitter.com の DNS レコードが一時的に改ざんされ、イランサイバー軍のハクティビストの Web サイトに向けられました。
続く数年間で多くの DNS 攻撃が発生しました。
- 2011 年にトルコのハッカーが起こした DNS 攻撃では約 186 のドメインが影響を受け、「ハッキング済み」という趣旨のメッセージを表示した Web サイトにリダイレクトされました。
- 2013 年と 2014 年には、シリア電子軍による攻撃でニューヨークタイムズ、Twitter、ハフィントンポストへのトラフィックがハッカーの Web サイトにリダイレクトされたほか、Facebook も同様の攻撃を受けました（Facebook への攻撃が失敗した要因のひとつは多要素認証です）。
- 暗号通貨会社である Blockchain 社は、2016 年に DNS レコードを改ざんされる被害を受けています（ただし幸いにも、DNS レコードの改ざんが OpenDNS によってすぐに検出され、復元されました）。
DNS 攻撃はこの 10 年間で多数発生していますが、成功した攻撃もあれば、失敗した攻撃もあります。しかし Talos では、2018 年後半に DNS 攻撃が飛躍的に進化したことを突き止めています。
DNSpionage
事の起こりは 1 通の LinkedIn メッセージでした。メッセージを受け取った DNS 管理者は、自身に興味がある採用担当者からのものだと考え、エントリードキュメントへのリンクをクリックしてしまったのです。
図 4：DNSpionage で使用された悪意のあるドキュメント
エントリードキュメントは悪意のあるマクロに感染していました。これにより攻撃者が管理者のマシンに侵入し、DNS ログイン情報を盗み出したのです。
ドメインを管理できるようなった攻撃者は、Webメール サーバを悪意のある IP アドレスにリダイレクトしました。しかも有効な証明書を登録することで、リダイレクト先のドメインを正当なアドレスに見せかけたのです。問題のサイトへの訪問者は異常に一切気付きませんでした。
図 5：DNSpionage 攻撃プロセス
DNSpionage 攻撃の戦術、手法、手順を調査する中で、TLD DNS サーバに対する別の（より懸念すべき）攻撃を発見しました。
Sea Turtle
それが「Sea Turtle」攻撃です。その目的は DNSpionage と同じく情報の盗取にあります。「Sea Turtle」攻撃では、TLD サーバがホストされているネットワークインフラやサーバを狙い、既知の脆弱性をエクスプロイトすることで侵入に成功したのです。TLD サーバに侵入した攻撃者は、特定ドメインのネームサーバについて IP アドレスを変更しました。
この手口ではリダイレクトをより細かく制御できます。悪意のあるネームサーバを設けておけば、特定ドメインに対する要求を正当なサイトと不正なサイトに振り分けるタイミングが選択できるからです。
図 6：Sea Turtle の攻撃プロセス
DNSpionage と同様に、Sea Turtle も Web メールサーバのレコードを改ざんしました。これにより情報を傍受して盗み出し、その後は被害者を正当な Web サイトにリダイレクトできるからです。
関連する他の攻撃手法
今回の記事ではいくつかの DNS リダイレクト攻撃と手口を取りあげていますが、実際の手口は非常に多様です。Talos では多数のブログ記事を公開し、ペイロードの詳細や攻撃手口などについて解説してきました。記事へのリンクについては、以下の「その他の参考資料」のセクションをご覧ください。
攻撃で DNS が利用されるシナリオは他にも考えられます。たとえば DNSpionage や DNSMessenger などの脅威は、DNS を使用してコマンドアンドコントロール（C2）サーバと通信します。DNSMessenger などは、盗んだデータを外部に送信するために DNSトンネリングを使います。
最近の別の懸念事項は、DNS over HTTPS（DoH）プロトコルを使用した脅威です。DoH プロトコルの目的は、DNS クエリのセキュリティを強化し、傍受や MitM 攻撃を防ぐことです。ただし今月初めには、DoH プロトコルを不正な通信目的で使用するマルウェアファミリ「Godlua」が発見されました。DoH はトラフィックを暗号化できるため、それを逆手に取った脅威がさらに出現する可能性も考えられます。
DNS 攻撃から保護する方法
DNS 攻撃の最終目標である個々のユーザにとって、残念ながら打てる対策は限られています。ユーザの観点からは、Web サイトに到達するための DNS 通信が正当なものに見えるからです。攻撃者が DNS レコードを改ざんし、有効な証明書を不正サイトに登録した場合は、特に検知が困難になります。
この場合の防御の責任は、DNS サービスを維持管理する側にあります。幸いなことに、管理者側にできる対策はいくつか存在します。
- DNS レコードを監視する。Umbrella Investigate などのツールにより、DNS レコードの改ざんをすばやく検知できます。
- DNS レコードの変更に多要素認証（MFA）を必須化する。Cisco Duo などの MFA ソリューションにより、DNS レコードの改ざんを防げます。
- DNS ハイジャックの試行、TLD レコードの改ざん、トラフィックのリダイレクトや傍受が起きていないか、BGPmon や Crosswork Network Insights などのツールを使用して監視する。
- システムを最新状態に保つ。Sea Turtle の攻撃で侵入経路となった脆弱性の一部は 10 年前のものでした。
- 環境に DNSSEC を実装する。DNSSEC は DNS 通信にデジタル署名を追加して発信元の認証を可能にし、要求の改ざんを防ぎます。
最後に、Web サイトまたはドメインをホストする場合、DNS プロバイダーで上記の対策が取られていることを確認してください。
________________________________________
その他の参考資料
• 中東を狙った DNSpionage キャンペーン
• DNSpionage が Karkoff をリリース
• インターネットの中核技術への信頼性を悪用する DNS ハイジャック
• DNS ハイジャックにより感染を広げる「Sea Turtle」
• 隠されたチャネルと不適切な決断：DNSMessenger の物語
• SEC を装った電子メールにより、進化した DNSMessenger が拡散
• DNS を利用したデータ盗難の検出
その他の脅威について、「今月の脅威」ブログ シリーズをご覧ください。
Authors