1. DNS/1/UDP/fragmentation
https://en.wikipedia.org/wiki/IP_fragmentation
長いUDP packetが分割されて、組み立て直されるときに、後半をすり替えるのは比較的簡単です。
IPヘッダのidentification(16ビット）を一致させられればよい。DNS/1/UDP
- そして、id が予測可能だったりしたケースすらあったと。
Amir Herzberg, Haya Shulman: Fragmentation Considered Poisonous
あとはDNS返答としての整合性が問題になるだけです。
https://www.iajapan.org/ipv6/summit/SAPPORO2014/pdf/JPRS_SAPPORO2014.pdf
- 攻撃にチェックサムの調整が必要で、「不可能ではない」とあるので、困難だと考えているようだが、
- 簡単なので、誤解しているのだろう。
UDP checksum 0 返答をするサーバ： https://twitter.com/beyondDNS/status/693456707909865474
2. 脅威
二つ目以降の偽フラグメントを先に送り込む攻撃が可能
キャッシュDNSサーバーの応答ログには攻撃の痕跡が残らない
- IP-IDが一致しなかった場合
IP fragmentation attack on DNS
dns-operationでのやりとり https://lists.dns-oarc.net/pipermail/dns-operations/2013-September/010625.html
nxdomain 返答が返るものは使えない。 だが、ワイルドカード設定があると、...
the Kaminsky-attack on top of Shulman-attack is just limited to heavily populated zones (TLDs) or wildcard domains, since you need a positive response (since you cannot rewrite RCODE in the packet).
TTLが短いと、攻撃の機会が増える。-- ToshinoriMaeno 2016-02-06 01:19:53
http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/
3. リゾルバーでの対策
unbound option
- max-udp-sizeを512に制限できる。do-udpをnoにすることも可能。
ただし、手元で試してみたが、512に制限しているようには見えない。確かめる。 -- ToshinoriMaeno 2016-02-07 00:46:49
4. サーバ側での緩和策
返答パケットでの工夫
[draft] DNS message fragments draft-muks-dns-message-fragments-00
5. 仙豆 blog
http://senz.hatenablog.com/entry/2014/03/24/000442
難関はただひとつ、IPヘッダのIdentificationフィールドです。
http://senz.hatenablog.com/entry/2014/05/06/200528
そのエントリではUDPチェックサムをうまくあわせることができず最終的に毒入れを成功させることができませんでした。
6. checksum 0 は危険
きっかけはこのあたり https://twitter.com/muranet/status/688946338965262336?lang=ja