攻撃時のパケットから見るDNSキャッシュポイズニング

目次

はじめに

こんにちは。株式会社エヌ・エフ・ラボラトリーズ 学生インターンの林です。弊社ではセキュリティトレーニングプラットフォームの開発を行っています。私はプラットフォームのフロントエンド、バックエンドの開発や教育コンテンツの開発に携わっています。

私は大学でネットワークセキュリティに関する授業のティーチングアシスタントをしており、その授業でも触れられているDNSキャッシュポイズニングに関する問題を作問しました。今回は攻撃時に発生するパケットを参照しながらDNSキャッシュポイズニングとはどのような攻撃なのかを解説していきたいと思います。

インターンについて

本題に入る前にインターンでの働き方についてご紹介します。現在、私は大学院修士1年です。弊社のインターンには2022年の11月頃から参加しています。授業のない日や授業コマ数が少ない日に週2回、地方からフルリモートで勤務をしています。授業や個人的な用事などが入っていても臨機応変に時間や勤務日の変更ができるため、かなり働きやすいです。また、分からないことがあってもメンターの方にサポートしていただけるため、大変心強いですし、様々なことにチャレンジできる環境のため、自分にとってとてもよい刺激となっています。

DNSキャッシュポイズニングの概要

DNSキャッシュポイズニングとはDNSキャッシュサーバにキャッシュされるドメイン名とIPアドレスの組を偽装する攻撃です。この攻撃を受けた脆弱なDNSキャッシュサーバの利用者は正規ドメインでアクセスしているにも関わらず、偽サイトなど悪意のあるサイトに誘導されます。

今回はDNSキャッシュポイズニングの中でも特にカミンスキー型(CVE-2008-1447、Kaminsky bug)について解説します。

カミンスキー型のDNSキャッシュポイズニングは下記の手順でDNSキャッシュサーバに誤った情報を登録させる攻撃手法です。

1. 攻撃者端末からDNSキャッシュサーバに対してキャッシュが存在する可能性の低いドメイン名を問い合わせるリクエストを送出する (例：6zd8ttqzld3xgwyw4.example.com )
2. DNSキャッシュサーバがレスポンスを受信する前に攻撃者端末から応答を偽装したレスポンスを送出する
3. DNSキャッシュサーバが偽装されたレスポンスを正規の応答とみなす
4. 以降、名前解決を行うと、キャッシュされた偽のIPアドレスが返答される

検証に使用した環境、手順

ターゲットとなるドメイン

sushi.example.com

マシン一覧(カッコ内はIPアドレス)

• クライアントマシン (10.236.179.182)
  • curlコマンドがインストール済み
• DNSキャッシュサーバ (10.236.179.159)
  • BIND9.3.2が53/udpで動作中
  • named.confでquery-sourceのport(DNS権威サーバに名前解決リクエストを送信する際の送信元port)ã‚’53/udpで固定している
• DNS権威サーバ å…¼ 正規Webサーバ (10.236.179.58)
  • BINDが53/udpで動作中
  • Apache HTTP Serverが80/tcpで動作中
• 攻撃者マシン (10.236.179.131)
  • Metasploit Frameworkがインストール済み
• 偽Webサーバ (10.236.179.237)
  • Apache HTTP Serverが80/tcpで動作中

手順

1. クライアントマシンからcurlコマンドを使ってsushi.example.comにアクセス(正規のWebページが表示されることを確認)
2. 攻撃者マシンのMetasploit Framework(bailiwicked_hostモジュール)を使ってDNSキャッシュポイズニングを行う
3. クライアントマシンからcurlコマンドを使ってsushi.example.comにアクセス(偽のWebページが表示されることを確認)

Let's パケット解析

どのようにDNSキャッシュが汚染されたか、実際のパケットをWiresharkで確認しながら追っていきます。

解析するパケットは「クライアントマシン」「DNSキャッシュサーバ」「DNS権威サーバ 兼 正規Webサーバ」と接続されているネットワーク機器で取得したものとします。

まず、Wiresharkのディスプレイフィルタで http と入力し絞り込むと、正規のWebページ(通常のHTML)と偽のWebページ(「Hacked by Anonymous!!」と書かれたデータ)の両方のパケットが表示されます。

上記パケットより偽WebサーバのIPアドレスが 10.236.179.237 だと分かったため、次にどのようなDNS通信が発生したかを見ていきます。

Wiresharkのディスプレイフィルタで dns.a eq 10.236.179.237 と絞り込みます。

すると、(ランダム文字列).example.comのクエリが大量に表示されます。

そのうちの一つ(上記画像では 6ZD8Ttqzld3XgwYW4.example.com のクエリ)を調べると、Additional recordsに sushi.example.com のアドレスが 10.236.179.237(偽Webサーバ) であると書かれています。

(ランダム文字列).example.comのクエリをもう少し詳細に確認するためWiresharkのディスプレイフィルタに dns.qry.name == (ランダム文字列).example.com と入力し、絞り込んでみます。

今回は 6ZD8Ttqzld3XgwYW4.example.com を対象として dns.qry.name == 6ZD8Ttqzld3XgwYW4.example.com としています。

上記画像より、最初に 10.236.179.159(DNSキャッシュサーバ) に向けて 6ZD8Ttqzld3XgwYW4.example.com のAレコードが引かれていることが分かります。その後、10.236.179.159(DNSキャッシュサーバ)が 10.236.179.58(DNS権威サーバ)に対して名前解決リクエストを送信しています。さらに続けて10.236.179.58(DNS権威サーバ)からTransaction IDフィールドの値が異なるレスポンスパケットが大量に発生しています。

これらのパケットのSource Addressは 10.236.179.58(DNS権威サーバ) となっていますが、これは攻撃者が詐称したものです。
正規のDNS権威サーバが返すTransaction IDと一致するパケットが先にDNSキャッシュサーバに届くことで、Additional recordsがキャッシュされ攻撃が成立します。

おわりに

今回はカミンスキー型のDNSキャッシュポイズニング(CVE-2008-1447、Kaminsky bug)について、実際のパケットをWiresharkで確認しながら解説していきました。

攻撃時に実際何が起こっているかを理解できたかと思います。教育コンテンツとして作問した問題では、さらに最新事情や対策についても触れています。

本記事の内容がDNSキャッシュポイズニングについて知る、学ぶきっかけとなっていれば幸いです。

更新履歴

• 2023-05-10: DNSキャッシュサーバのバージョン番号、Kaminsky bugという文言を追記