1. DNS/毒盛
Contents
DNSの基礎的知識があることを前提にします。 DNS/返答
公開リゾルバーはOff Path Attackを受けます。どう防ぐかが重要です。
毒盛攻撃の概要と防衛(検査)方法/対策を解説します。 そのあと、DNSキャッシュへの毒盛を目的にした/攻撃手法を説明します。
UDPでは容易に成立する中間者攻撃は考慮しません。
中間者攻撃による偽情報(毒)の混入はDNSだけの問題ではないので、ここでは扱いません。 現状のDNSSECはDNS情報だけを保護するものとしては手間がかかりすぎです。
防御には管理の複雑なDNSSECは必要ありません。
UDP をやめるのが第一歩です。TCPを使うならDNSSECもいらない。
- TCP でも危険だと、TCP利用を止めようとするひとたちもいます。
1.1. はじめに
キャッシュ毒盛攻撃は リゾルバーに対する攻撃です。
- リゾルバーにDNS問い合わせを送り出させ、それに対する(偽の)返答を受け取らせるものです。。
- UDPではパケット(送信元)の詐称が比較的簡単なことを利用します。
毒盛攻撃はゾーンサーバのふりをして、DNS/リゾルバーに偽のDNS/返答を受け取らせ偽情報をリゾルバーのキャッシュに入れ させることを狙います。成功したら、リゾルバーは嘘の返答をすることになります。
毒盛されると/影響が大きいのはNSレコードです。(/NS毒盛) そして、/CNAME, /NXDOMAINを使った毒盛についても考察します。
1.1.1. リゾルバーの現状
現存のリゾルバーはすでに得ている情報(キャッシュにある)とは矛盾する返答であるにも拘らず受け入れてしまう、 という欠陥を持っています。つまり、毒の検査が不十分ということです。/毒見 /危険なサーバー
RFC 2181を持ち出して、毒盛される言い訳にするのは筋違いです。予め断っておきます。
木構造のドメイン構造と上位に問い合わせ負荷が集中する実装に問題があります。
- それを避けるためとは言え、毒盛耐性を弱めるようなことをしていいとは思えません。
キャッシュ優先を実施しても負荷増大は問題にならないことを示すつもりです。-- ToshinoriMaeno <<DateTime(2017-1
1.2. 基本的対策
/対策 にまとめました。
- 現状のキャッシュサーバ（リゾルバー）はNS毒の毒見をしていないので、以下の対策がいります。
1. アクセス制限（できれば、他人には使わせないw） 2. 問い合せのエントロピー増加策 （ポートランダム化など） あるいはTCP利用 ルータがNATで使うポートにも注意が必要です。 3. 不審な問い合せをしていないかの24時間監視
これらは手間がかかるので、すべてが実施されているとは限らない。
ポートランダム化検査：http://snoopy.e-ontap.com/
1.2.1. 対策はあります
キャッシュサーバへの毒盛は/防衛できると考えています。DNSSECは必要ないと思います。
- JPRSが勧める常時監視をしないで済ませたいものです。
https://jprs.jp/tech/security/2014-04-15-portrandomization.html
キャッシュサーバへの/実装が普及していないのが大きな問題です。
- 実装者を説得するのは私には無理かもしれない。
現時点で知られている毒盛手法に対してはいくつかの簡単な対策があります。対策は 毒を紛れ込ませ難くする方法と紛れ込んだ毒を判別する方法に分けて考察します。
リゾルバーは非公開に(アクセス制限）するのが簡単な対策ですが、 利用者が多ければ、内部からの攻撃にも配慮しなければなりません。
Knot resolverであれば、私が知るかぎりの攻撃は実用上十分な対策が出来ています。 (対NS毒盛、対CNAME毒盛には私的パッチを適用して、確認中です。） -- ToshinoriMaeno 2017-05-06 00:12:08
2008年のKaminskyの警告を受けてのdraftと思われるが、これを実装しないのはなぜか。
Comprehensive DNS Resolver Defenses Against Cache Poisoning
- draft-weaver-dnsext-comprehensive-resolver-00
https://tools.ietf.org/html/draft-weaver-dnsext-comprehensive-resolver-00
1.2.2. 運用妨害
正規のサーバが通常動作をしているという前提での防衛策は 正規サーバが(DoSなどにより）返答しなくなっている場合には有効に機能しません。
- 十分準備した攻撃者には対抗できないのかも。
1.3. キャッシュ優先の原則
/キャッシュにあるレコードは上書きしないことで、多くの毒盛は撃退できます。/脆弱性の歴史 そうすると、残る問題は新たにキャッシュに登録するときということになります。（登録は慎重に）
このページでは主に どういう返答であれば、有効な毒となるかを考えます。
Kaminsky-Mueller流攻撃を利用した/NS毒盛を扱っています。
- 中間者攻撃は扱いません。暗号化されていないUDPパケットは盗聴/偽造し放題ですから。
DNSSECは使いません。手間がかかりすぎです。（間違いやすい）/誤解
http://nominum.com/ghosts-in-the-dns-machine/
1.4. 偽返答を送られにくくする
1.4.1. DNS Cookies
Domain Name System (DNS) Cookies M. Andrews May 2016 https://tools.ietf.org/html/rfc7873 これが実装されて、普及すれば毒盛はほぼ無理になる。だが、いつになるだろう。
- 実現までに簡単にやれる対策もある。
1.4.2. DNS返答の嘘を見破る
リゾルバー側で/NS毒盛を簡単に十分に防御できる方法を/2016で説明しています。
- (まだ実装がない）簡単な対策があるのに放置されている。
いまや実装の不良と呼んでもいいでしょう。
- DNSSEC推進の立場のひとはMITM攻撃以外に関心はないのでしょうか。
/NS毒盛以外の攻略は現在では困難だと考えています。
例：Kashupureff型攻撃、CNAME攻撃、/移転インジェクション /AncillaryDataAttacks
https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html
一番信用ならないのは/AuthoritySection /CNAME も危ない。 /MX返答 はどうか。/SOAはどうか。
「キャッシュにあるレコードは書き換えない」という原則を守るのが重要だが、 RFC2181というおかしなRFCが障害になる。
DNS/毒盛/対策/NXDOMAIN返答活用 はいかが。（実装されているリゾルバーはまだないｗ）
1.5. 毒盛とは
DNS/リゾルバーに偽の情報(DNSレコード)を送り込むことです。
危険性の大きさに配慮して、NS毒以外のものは当面の考察の対象外とします。
CNAME返答を利用する毒: /CNAME
glue を目標とした毒盛： /毒glue
/キャッシュサーバがどのように振る舞うかは実装依存です。 /NS毒盛 では検討します。
/部品紹介 /キャッシュサーバ /成立の要件 /ゾーンサーバの監視
http://cloud.watch.impress.co.jp/epw/cda/security/2008/08/28/13724.html 「ポートランダム化もすでに破られている」
nicの説明だが、間違いも： https://www.nic.ad.jp/ja/newsletter/No40/0800.html
1.5.1. 2014 年にあらたな展開
- Mueller の「委譲毒盛」を使った攻撃の再評価（前野）で、 co.jp などに簡単に毒が入ることがわかった。
- 鈴木は NS が上書きできる実装が多いことを確認した。 (キャッシュされているほぼすべてのNSかも）
http://www.e-ontap.com/blog/20140415.html 長年放置されてきた DNS の恐るべき欠陥が明らかに
/委任インジェクション はNS毒盛に属する攻撃（の一部）にJPRSがつけた呼び名です。
JPRSは注意喚起を出すはずだったが、Kaminsky流攻撃が増えているとの注意喚起だけでお茶を濁した。
このページも続きが出なかった。http://www.geekpage.jp/blog/?id=2014/4/25/1
1.5.2. 攻撃手法
/成立の要件 /taxonomy /poison https://moin.qmail.jp/DNS/RFC2181/s5
https://www.nic.ad.jp/ja/newsletter/No40/0800.html /nicの説明
https://tools.ietf.org/html/rfc5452
DNS/攻撃/fragmentation UDP 返答パケットで分割を引き起こすとすり替えやすい。
1.6. 経緯
1.6.1. Kaminsky 攻撃
Kaminsky流の攻撃手法により、毒盛の防御にはTTLは役にたたないことが示されました。 /Kaminsky手法
Kaminsky 手法は「キャッシュされていない名前を問い合わせる」ことにより、「毒を送りつける機会を増やす」ものである。
- どういうレコードをキャッシュさせるか（毒盛するか）は、次の段階の話です。
- Kaminsky が示した例では当時のBINDにすら毒盛できませんでした。
BIND各バージョンへの毒入れ実験 (Kaminsky Bug の検証) http://www.e-ontap.com/dns/bindmatrix.html
https://www.nic.ad.jp/ja/materials/iw/2008/proceedings/H3/IW2008-H3-07.pdf 民田スライドを参照
glue に毒らしい。
The authority data may well contain the "real" bankofsteve.com nameserver hostnames, but the glue points those nameservers at badguy IPs.
2008年に見た資料では一番よかったもの： DNSにおけるキャッシュ汚染攻撃 http://www.sec-pro.net/spnseminar081025_shio.pdf
しかし、 DNS/node_re-delegationの報告にあるように「委譲返答」を使った攻撃が有効であると分かっています。
/Mueller手法 による「委譲返答攻撃」 と呼びます。
1.6.2. Mueller の委譲返答攻撃
Mueller は偽委譲返答（NSなど）を送りこむ攻撃が考えられると言っています。 DNS/毒盛/Mueller手法
Mueller paper の指摘では
キャッシュにないレコードを毒として注入します。ここでもTTLは関係しません。（ランキングも）
ここまでが2008年に明らかになったことです。（それに世界が気づいていなかったとしたら不思議です。）
問い合わせポートのランダム化である程度の防御ができるからでしょう。
1.6.3. Ghost Domain Names
そして、2012年にはDNS/GhostDomainNames脆弱性が指摘されています。(これもキャッシュへの毒盛です）
- （上位サーバで）登録を削除されたはずのドメイン（幽霊）をキャッシュサーバに残す（活かし続ける）というもの。
関連して「DNS/共用サービスの危険性」を指摘しました。（サブドメイン登録など一部の問題は改善されました。）
unbound などのキャッシュサーバ（実装）での対策も追加されていますが、十分利用されているとは言えません。 -- ToshinoriMaeno 2014-03-22 23:56:19
1.7. いまも残る脅威
A レコード(web サーバやDNSゾーンサーバ) はキャッシュされていることが多いので、対象としません。
リゾルバー側で簡単に実装できる対策が存在するにもかかわらず、なぜか実装されないために、 残っている脆弱性があります。
1.7.1. NSレコード
Mueller 手法にある NSレコードを狙うのが有効そうです。
RFC2181 では参照返答に含まれるNSレコードでキャッシュを上書きしてよいか、あいまいです。
- Mueller 手法で簡単にNSに毒を入れられるキャッシュ実装もありそうです。
正規の返答がNXDOMAINであるような問い合せを送るので、 毒盛したいNSレコードがキャッシュさせられることがない。 これにより効果的な攻撃になります。
--> Kaminsky 流の「存在しない下位の名前」を問い合せて、一段上位のNSを返答します。
1.7.2. NSレコードをもたないノード
現実のDNSゾーン構成を観察すると、簡単に毒盛できそうなケースが多数見つかります。
2月に通報済みです。-- ToshinoriMaeno 2014-03-23 00:01:19
NSレコードを持たないノードです。たとえば、co.jp などの属性型JPドメイン名のおおもとです。
JPRSはいまもこのことを説明していません。 -- ToshinoriMaeno 2015-07-12 01:04:34
1.7.3. キャッシュの上書き
- !!! リゾルバーの実装にこんな欠陥が。 これは不良と呼ぶべきものです。
Internet Week 2014 ランチセミナー 未熟なDNSと今後どう付き合うべきか
- スライド１２
移転通知インジェクション攻撃 – 移転通知(子のNS)は委任応答(親のNS)よりも信頼度(trustworthiness)が上 • RFC 2181 5.4.1. Ranking data – 上記仕様に準拠しない実装では攻撃は成立し}ない
- この説明は間違い。キャッシュを上書きする実装をよく調べましょう。
1.8. いますぐ確認して欲しいこと
ゾーンサーバとキャッシュサーバは分けていますか。
キャッシュサーバのポートランダム化はお済みでしょうか。
http://snoopy.e-ontap.com/ http://snoopy.e-ontap.com/announce.html
- 危険なDNSサーバの利用者へ警告を行う活動を行っています
1.9. 毒盛に使う毒
- キャッシュサーバにキャッシュされていなくて、
- 正当な権威サーバからの返事には含まれていなさそうで、
- 偽返答なら受け入れられそうなレコードとは：
Answer Section ではなさそうですね。
Mueller にあるように Authoriyt Section 内の NS レコードが一番狙われ易い。
なかでも、DNS/委譲毒盛 はターゲットを発見できれば、すぐにも毒盛できてしまう危険な手口です。
1.10. キャッシュにあっても危ないかも
キャッシュが優先されて、置き換えが起きないのなら、 余計なお節介のNSレコードも毒盛防御には役にたっているのかもしれない。
でも、置き換えられるのではないか。 DNS/RFC2181/s5 /root-servers.net
「毒入れの原理」という言葉を使うひとはどういう意味で使っているのだろう。
- 「原理」というような概念があるなら、はっきりした説明があると思ったが、見つからない。
毒が入れられるような「DNS（実装）の欠陥」、あるいは「DNS設計の欠陥」という方がふさわしい呼び方だと考える。 -- ToshinoriMaeno 2015-11-10 06:23:59
1.11. 参考情報
Comprehensive DNS Resolver Defenses Against Cache Poisoning
- draft-weaver-dnsext-comprehensive-resolver-00
https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html
Cache Policy, Scoping, and Ancillary Data Attacks /AncillaryDataAttacks
https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture17.pdf Lecture 17: DNS and the DNS Cache Poisoning Attack by Avi Kak ( kak@purdue.edu )
http://www.e-ontap.com/dns/bindmatrix.html (Kaminsky Bug の検証)
http://maradns.samiam.org/deadwood/doc/Recursive-algorithm.html
http://dnsops.jp/event/20130719/20130719-undocumented-DNS-orange-6.pdf 教科書には載っていないDNS （JPRS 森下）