CVE-2015-5477の検証(&DNSに関する基礎知識)

本記事はCVE-2015-5477(BIND9.xの脆弱性)の検証に関するものです．

CVE-2015-5477の概要
攻撃者がサーバに不正なTKEYクエリを送信することでサーバのクラッシュ(正確にはnamedデーモンが落ちる)が発生する脆弱性です．調べたところ，世界中に存在する13のルートサーバの殆どがBINDを使用しているそうです．その点を考えるとこの脆弱性の危険性がおわかりいただけると思います．これは2015年7月に発見された脆弱性なので，2016年5月現在ではどのサーバも対策や修正がなされているでしょう．


DNSに関する基礎知識
DNSには「スタブリゾルバ・フルサービスリゾルバ(キャッシュサーバ)・コンテンツサーバ」という3種類の機能があります．

スタブリゾルバ
DNSの要求を始めに行うクライアントです．この要求を生成するコマンドとして「dig」等があります．

フルサービスリゾルバ
スタブリゾルバからの要求に対して自身のデータベース内に対応する答えがあればそれを返信し，なければ他のサーバに要求を行うサーバです．なおこの要求結果はスタブリゾルバに返信すると共に自身のデータベースにも格納するので「キャッシュサーバ」とも呼ばれます．この役割を行うサーバとしてISPのリゾルバ等があります．

コンテンツサーバ
自身の管理するゾーンにだけ応答し，自身のデータベースに要求の答えが存在しない場合，要求元に「存在しない」という返信を行うことです(つまり，他のサーバへ名前解決の要求を行いません)．この役割を行うサーバとして各ゾーンの権威サーバがあります．

CVE-2015-5477では，BINDのフルサービスリゾルバとコンテンツサーバ双方が被害を受けます．

検証する
検証方法については，次の記事を参考にさせていただきました．
BIND9の脆弱性 (CVE-2015-5477)のPoCを書いて検証してみた - Qiita
仮想環境にサーバ(攻撃を受ける)とクライアント(攻撃を行う)を用意し，検証を行いました．

• ホストOS Windows7 Professional x86_64
  
• ゲストOS サーバ CentOS(6.5) x86_64
  
• ゲストOS クライアント KaliLinux(2.0) x86_64
  
• VirtualBox(5.0.12.r104815)
  
• Vagrant(1.7.3)
  
• BIND(9.10.1-P1)
  

サーバ側でBINDを起動します．

起動されていることを確認します．今回はeth0(NAT)とeth1(Bridge)の2つが存在しているので，2つのアドレス(10.0.2.15,192.168.0.7)が対応しています．

では実際にサーバ(192.168.0.7)に向かって攻撃を行います．実際の攻撃コードについて深くは書きませんが，scapyを使えば非常に簡単に実現できます．クエリレコードタイプ249，クエリレコードと同じ名前を持つ追加レコード，これらを満たすDNSクエリをサーバへ送信します．
送信後，サーバ上でプロセスを確認すると，namedデーモンが落ちていることが確認できます．メッセージログ(/var/log/messages)からもrunning状態から異常終了していることがわかります．

おわりに
本記事では，ひとまず検証のみを目的としているので，対策方法や検知方法についてはまた別の機会に書きたいと思います(色々諸事情がありまして...)