キャッシュポイズニングの開いたパンドラの箱
Opened Pandora's box of Cache Poisoning

背景

1. Kaminsky
   2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。
   しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。
   http://www.e-ontap.com/dns/bindmatrix.html
2. Müller
   Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14
   https://www.sec-consult.com/fxdata/seccons/prod/downloads/whitepaper-dns-node-redelegation.pdf
   彼は偽応答を毒として機能させる方法 "node re-delegation" を示した。
   
3. Sooel Son and Vitaly Shmatikov
   The Hitchhiker's Guide to DNS Cache Poisoning
   https://www.cs.utexas.edu/~shmat/shmat_securecomm10.pdf
   どのような条件で毒を入れられるのかについてかなり網羅的に書かれている。
   
4. Shulman
   Amir Herzberg and Haya Shulman の Fragmentation Considered Poisonous,2013.3
   http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf
   Fragment化したパケットの(チェックが甘い)第2フラグメントで毒を入れられることを示した。偽応答を受け入れさせる方法として確実性が高いが、どういう偽応答が毒として機能するかは明確に述べられていない。
   

今回の発見: 委任インジェクション攻撃

前野、鈴木らの考察、検証により、どのようなターゲットに対して偽応答が毒として有効に機能するかが色々明らかになった。

ポイントは以下である。

「事前に NS のキャッシュがないか容易に上書きでき、本物の応答に邪魔されないノードが危険である」

以下のケースで node re-delegation の応用によって重要なドメイン名(ゾーン)が危険に晒されることがわかった。

1. ゾーンがないサブドメインへの毒入れ (Müllerの手法の応用)

NSが存在せず事前にキャッシュがない例のようなケースにおいて、偽の sld.tld の 偽 NS を容易に毒入れすることができ、偽 sld.tld ゾーンを自由にできる。

なお、事前に example.sld.tld 内の A レコードがキャッシュされていても、偽 sld.tld ゾーンの NS は毒入れ可能である。再度引かれたレコードから毒に侵されていく。

2. 親子ゾーン同居 (世代間同居)への毒入れ ...(我々との情報交換からJPRSが発見)

tld から sld.tld が委譲されているが sld.tld ゾーンが tld ゾーンと同じサーバにある場合、

a) キャッシュは子の応答を親の応答として受け取る可能性がある
b) NSが高い優先度でキャッシュされる機会が少ない (aによる)
c) 内部名検査をパスする

という理由により偽の sld.tld の 偽 NS を容易に毒入れすることができ、偽 sld.tld ゾーンを自由にできる。

3. 子のゾーン内の名前を親のNSに用いているゾーンへの毒入れ

子ゾーン内の名前に毒入れして親ゾーンを自由にできる。

結論

以上の手法を用いて、以下の重大な毒入れが可能となる。

i) co.jp などに毒が入る
ii) jp などに毒が入る / com などに毒が入る
iii) . (root) に毒が入る

仕様(RFC2181など)、実装、運用をすべて見直す必要がある。

* 今回さらに危険な問題 (移転インジェクション攻撃)が見つかっている。

緩和策

キャッシュサーバでの対策

• アクセス制限を行う (オープンリゾルバは危険)
• query source port randomization (ポート固定は非常に危険)
• 0x20 などによるエントロピー増加
• NS キャッシュ条件の見直し (再検査など)
• 攻撃の検知とキャッシュクリア
• EDNS0 をやめて TCP を用いる (フラグメント攻撃対策)
• その他 (Google Public DNS が多々とっている緩和策を参考)

ゾーンサーバでの対策

• NSなしノードの解消
• 親子同居構成の解消
• NS名の見直し

注:実験はすべて仮想インターネット環境上で行った (BIND 9.9.2-P2 /Unbound 1.4.20)
今回の脆弱性の公開について様々なご助言を頂いた名古屋大学高倉弘喜教授に感謝致します。
連絡先: 中京大学工学部教授 鈴木常彦 / endofdns at e-ontap.com