インターネットの危機:ISC BINDパッチの分析(第2部)

2部構成の第2部であるこの記事では、ISC BINDで最近発見された2つの脆弱性、CVE-2016-1286とCVE-2016-2088について解説します。勧告によると、不正なDNAMEレコード(CVE-2016-1286)またはOPT COOKIEレコード(CVE-2016-2088)をトリガーとして使用することで、これらのバグが攻撃される可能性があります。

これら2つのバグの攻撃にはどちらも同じ方法が使用され、BINDサーバーが要求を作成して、その後に不正な応答を受け取った場合にのみトリガーされる可能性があります。このような状況でのみ攻撃が可能であることから、この攻撃に対するリスクが最も高いのは、再帰的な問い合わせを行うサーバーです。この攻撃では、認証のみを行なうサーバーに正当ではない方法でDNS要求が送信されることがその理由です。

CVE-2016-1286[1]

namedはサービスデーモンであり、BINDアプリケーションパッケージの一部です。namedは、ゾーンファイルの設定または転送元による指定に基づいて、ドメインからIPへ、あるいはその逆への変換を実行します [2]。データ交換の整合性と信頼性を保証するために、namedを構成して、DNSSEC拡張機能を使用するようにできます。RRSIG(リソースレコードシグネチャ)は、DNSSECに属する新しいRRタイプで、公開鍵基盤による別のRRの署名に使用されます [3]。

DNSのクエリと応答は、すべてCNAME、NS、およびDNAMEなどの異なるタイプのリソースレコード(RR)で構成されます。DNAMEもRRタイプの1つで、CNAMEとほぼ同様に処理できますが、ドメイン階層の上位に存在します。つまり、DNAMEはCNAMEのスーパーセットです。[4]

このバグを攻撃するために、フォーティネットは再帰機能を有効に設定したBINDサーバーと攻撃者のサーバーをセットアップし、レコードの存在しないドメインに対する再帰的クエリの解決に攻撃の被害者がそのサーバーを使用するようにしました。

最初に、パッチの内容を説明します。公開されたパッチの一部を以下に示します。

rdatasetは、タイプdns_rdataset(./lib/dns/include/dns/rdataset.h)の構造体です。

また、使用できるすべてのタイプは、./lib/dns/include/dns/enumtype.hで参照できます。

攻撃の被害者は再帰的応答を受け取りますが、この応答には、要求に対する答えであるDNAME以外のいずれかのタイプのRRがあり、さらにDNAMEを対象とするRRSIGタイプのRRが続きます。すなわちこれは、存在しないレコードをサーバーが署名していることを意味します。その後、攻撃の被害者が受け取った応答を後続の要求で使用するためにキャッシュしようとすると、REQUIREステートメントに遭遇してアサーションが失敗し、それによってデーモンがクラッシュします。以下に示す2つのキャプチャを参照してください。

クライアントとサーバーの通信、および意図的に作成された不正データを以下に示します。

DNSSECが有効/無効のどちらであるかは、サーバーの攻撃の可否に影響しません。

CVE-2016-2088[5]

今年の初めに、ISCはDNSサーバーが相互のメッセージの認証にCookieを使用できるようにする、まったく新しいメカニズムを提案しました [6]。ただし、現段階ではDNS Cookieはまだ実験段階の機能であり、RFCのステータスもまだドラフトの状態です。この脆弱性はまさに、この新しい機能を標的とするものです。

このバグは、パケット処理フローは異なるものの、攻撃方法は前述のCVE-2016-1286と極めてよく似ています。DNSサーバーが再帰的クエリを実行する場合に攻撃が可能になり、応答パケットに複数のCookieエントリがある不正OPTレコードの解析時に攻撃がトリガーされます。

このパッチは、最初のCookieだけを処理し、次のOPTエントリはスキップするという、とてもわかりやすいものです (lib/dns/resolver.c)。

次に、前バージョンで2つ目のCookieが処理されるとどうなるかを確認してみましょう。

応答メッセージ用のCookieの計算後に、そのメッセージが"good"でも"bad"でもないとnamedがINSIST(判断、assertと同じ)すると(行番号7585)、プログラムは、そのCookieが初期化されたばかりでまだ処理されていないと判断する可能性があり、それによって問題が発生することになります。

以下のif-elseブロックでは、最初のCookieの後に、Cookieを"bad"または"ok"のいずれかにセットします。そのため、いずれの場合も2回目のCookieの解析時にINSISTが失敗して、namedデーモンが異常終了することになります。

キャプチャした通信のイメージには、2つのCookieが次のように表示されます。

CVE-2016-2088の影響を受けるのは、DNS Cookieを有効にして作成されたBINDバージョンだけです。

フォーティネットのお客様の保護

フォーティネットのお客様はすべて、以下のIPSシグネチャによってこれらの脆弱性から保護されます。

  • CVE-2016-1286 - ISC.BIND.DNAME.Resource.Records.Parsing.DoS
  • CVE-2016-2088 - ISC.BIND.DNS.Cookie.Handling.DoS

Amir Zali、Tony Loi(FortiGuard Lion Team)

参考文献

[1] https://kb.isc.org/article/AA-01353
[2] https://www.ietf.org/rfc/rfc4034.txt
[3] https://tools.ietf.org/html/rfc1034.txt
[4] https://tools.ietf.org/html/rfc6672.txt
[5] https://kb.isc.org/article/AA-01351
[6] https://tools.ietf.org/html/draft-ietf-dnsop-cookies-09