1. DNS/毒盛/脆弱性の歴史
Contents
DNSについて、ひととおりの知識があることを前提に毒盛攻撃を説明します。
ゾーンサーバのふりをして、リゾルバーに偽のDNS/返答を受け取らせることで、 偽情報をリゾルバーのキャッシュに入れ、リゾルバーに嘘の返答をさせます。
毒盛で中心的役割を果たすのはNSレコードです。(/NS毒盛) ../索引 ../歴史 ../対策
1.1. 毒盛手法の進化
実験的に作られた実装にはいろいろな脆弱性がある。
リゾルバーになんらかの「不正な返答を受け取らせる」ことが第一段階です。
- ゾーンサーバがおかしな返事をすることは想定されていなかった時代もありました。
リゾルバーになんらかの「偽造返答を受け取らせる」ことが第二段階です。
- キャッシュサーバはキャッシュにある情報は通常は問い合わせを送出しません。
Kaminskyはリゾルバーに「次々と」問い合わせを送り出させる攻撃手法を示しました。(2008年）
これが第三段階です。 Kaminsky流攻撃手法
どういう返答であれば、有効な毒となりやすいかを考えるのが第四段階です。
あとは誰かがキャッシュにある偽の情報を参照するのを待ちます。
DNS/毒盛では主に第四段階の毒盛を検討しています。
Kaminsky-Mueller流攻撃を利用した/NS毒盛を扱っています。
- 中間者攻撃は扱いません。暗号化されていないUDPパケットは盗聴/偽造し放題ですから。
DNSSECは使いません。手間がかかりすぎです。（間違いやすい）/誤解
http://nominum.com/ghosts-in-the-dns-machine/
Domain Name System (DNS) Cookies M. Andrews May 2016
これが実装されて、普及すれば毒盛はほぼ無理になる。だが、いつになるだろう。
- 実現までに簡単にやれる対策もある。
リゾルバー側で/NS毒盛を簡単に十分に防御できる方法を/2016で説明しています。
- (まだ実装がない）簡単な対策があるのに放置されている。
いまや実装の不良と呼んでもいいでしょう。
- DNSSEC推進の立場のひとはMITM攻撃以外に関心はないのでしょうか。
/NS毒盛以外の攻略は現在では困難だと考えています。
例：Kashupureff型攻撃、CNAME攻撃、/移転インジェクション /AncillaryDataAttacks
1.2. 簡単な歴史
初期： ゾーンサーバから送られてくる間違い情報、悪意ある情報の排除 DNS/用語/in-bailiwick
偽パケット送付： transaction 情報が予測可能などの理由で、偽返答パケットを送りつけることが可能だと指摘される。
DJBDNS： port randomization による偽パケットの排除
虚しきインターネットの宴 http://www.suzuki.sist.chukyo-u.ac.jp/utage.html
1.2.1. 2008
2008年のKaminskyの指摘: キャッシュにある情報を問い合わせるのではTTLに制約されて、
- 外部へ問い合わせさせられない。 キャッシュにない名前を問い合わせることで、問い合わせを送り出させて、毒盛の機会を増やす。
- 以降は偽パケットでどういう情報なら送りつけられるかが課題となるはずだったが。 Muellerの指摘などを含め、ほとんど理解されることはなかった。
N. Weaver: Comprehensive DNS Resolver Defenses Against Cache Poisoning
DNS/毒盛/AncillaryDataAttacks が重要だが、Internet-Draftは賞味期限ぎれだ。なぜだ。
1.2.2. 2012
DNS/脆弱性/GhostDomainNames リゾルバー実装の欠陥
1.2.3. 2014
2014年 co.jp などの中間ドメイン名には比較的簡単に毒入れすることができると判明した。
- これは単にMueller手法の適用先を見つけたということに過ぎなかったが、影響は大きい。
NS毒盛はこれだけではなかった。鈴木はキャッシュにあるNSが上書きされる脆弱性を指摘した。
こちらの方がずっと危険だ。/移転インジェクション 簡単な対策があるのに、なぜBINDでは対策されていないのか。Unboundはoptionがある。
/2015 /2014 /2012 /2008 DNS/脆弱性 /NXDOMAIN返答活用
https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-resolver-00.html
一番信用ならないのは/AuthoritySection /CNAME も危ない。 /MX返答 はどうか。/SOAはどうか。
「キャッシュにあるレコードは書き換えない」という原則を守るのが重要だが、 RFC2181というおかしなRFCが障害になる。
/キャッシュサーバがどのように振る舞うかは実装依存です。 /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.2.4. 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.2.5. 攻撃手法
/成立の要件 /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.2.6. 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.2.7. Mueller の委譲返答攻撃
Mueller は偽委譲返答（NSなど）を送りこむ攻撃が考えられると言っています。 DNS/毒盛/Mueller手法
Mueller paper の指摘では
キャッシュにないレコードを毒として注入します。ここでもTTLは関係しません。（ランキングも）
ここまでが2008年に明らかになったことです。（それに世界が気づいていなかったとしたら不思議です。）
問い合わせポートのランダム化である程度の防御ができるからでしょう。
1.2.8. Ghost Domain Names
そして、2012年にはDNS/GhostDomainNames脆弱性が指摘されています。(これもキャッシュへの毒盛です）
- （上位サーバで）登録を削除されたはずのドメイン（幽霊）をキャッシュサーバに残す（活かし続ける）というもの。
関連して「DNS/共用サービスの危険性」を指摘しました。（サブドメイン登録など一部の問題は改善されました。）
unbound などのキャッシュサーバ（実装）での対策も追加されていますが、十分利用されているとは言えません。 -- ToshinoriMaeno 2014-03-22 23:56:19