| /CNAME例 /MX+CNAME /twimg /unbound |
1. DNS/毒盛/CNAME
Contents
警告：CNAME返答を利用した毒盛攻撃に弱いリゾルバーがある。
http://insecure.org/sploits/dns.cache-poison.cname.html
https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf
以下の三種類を分けて考慮する必要がある。
正当なゾーンサーバが返事に偽の情報を返すもの
偽の返答としてCNAMEを受け取らせようとするもの
偽返答でCNAMEの指す先に毒を盛るもの
こんな毒も可能なのか。-- ToshinoriMaeno 2019-03-21 01:29:49
Wrong DNS answer with CNAME and A Record at the same time
2. CNAME返答中のAuthority Section (NS) でも毒盛
「ひと粒で二度美味しい」ならぬ、二度危ない返答。;-<
3. 対策案
DNS/CNAMEレコードの非存在推定 を用い、キャッシュを上書きしないという原則が重要だ。
対策1： Answer Sectionにあるレコードの検査; ownerがqnameに一致しないものは捨てる。
- in-bailiwick検査では攻撃を排除できない。(キャッシュにあるNS/Aレコードを上書きされるかも）
- 例えば、random名の先が返答サーバ守備範囲のゾーン内の名前を指していて、
そのNSやAレコードが毒である場合。-- ToshinoriMaeno 2019-03-16 03:04:38
- 例えば、random名の先が返答サーバ守備範囲のゾーン内の名前を指していて、
- ではin-bailiwick検査しか考慮していない。
BIND 9.4.1 は毒盛されるとのこと（Hitchhiker's Guide)
対策2: キャッシュされているレコードのownerと一致するCNAME返答は捨てるのがよい。
CNAMEレコードは他のタイプのレコードとは共存させてはならない。DNS/CNAMEレコードの非存在推定
- キャッシュにあるレコードを上書きすると毒盛される。(CNAMEに限らない)
- CNAMEでは任意のレコードタイプを乗っ取れるので、危険性が大きい。
対策3: ネガティブキャッシングされているレコードのownerと一致するCNAME返答は捨てるのがよい。
DNS/返答/NoData返答がキャッシュにどう保存されているのか、どう使われるのか。DNS/RFC/2308
これらが攻撃手法のヒントになる危険性もあるが、警告しないのもまずいので、書いておく。 -- ToshinoriMaeno 2016-07-14 15:10:05
3.1. Kaminsky 以前
http://insecure.org/sploits/dns.cache-poison.cname.html (1997)
Description: You can poison DNS cache by returning a bogus IP as a CNAME for a real server. Author: Johannes Erdfelt outlined this type of attack originally. Compromise: Subvert DNS Vulnerable Systems: Almost all current DNS servers, including bind 8.1 and M$ DNS Date: 14 June 1997 (It was actually discovered in April, apparently)
RFC 2181 でCNAME毒について書いてあるという解釈もある。
3.2. Kaminsky
CNAME Records provide the “Canonical Name” for a server, and additionally the IP of that server
- CNAME may be returned for any type
- Additional IP may show up in Answer section, unclear if treated as an Answer though
These Imply A Series Of Attacks
- MX records don’t get the ANSWER defense, so they’re easy to hit
- CDN’s cause major sites to be hosted via CNAMEs, so they’re easy to hit
- – www.google.com, www.whitehouse.gov, www.navy.mil
4. 別の例
%dnsq a dns2.psn.jp 49.212.13.62
1 dns2.psn.jp: 110 bytes, 1+2+2+1 records, response, authoritative, noerror query: 1 dns2.psn.jp answer: dns2.psn.jp 7200 CNAME ns2.psn.jp answer: ns2.psn.jp 7200 A 59.106.185.138 authority: psn.jp 7200 NS ns2.psn.jp authority: psn.jp 7200 NS ns.psn.jp additional: ns.psn.jp 7200 A 49.212.13.62
answer: ns2.psn.jp 7200 A 59.106.185.138 を信用するかどうか。
5. これまで
こういう返事をもらったら、キャッシュはどう扱うべきなのか。
- 「本来のanswerであるCNAMEレコードだけを受け入れる。他は捨てる。」のがよさそう。
- in-bailiwick 検査は毒盛攻撃には対抗できない。
5.1. dnscache/djbdns
DJBは危険性に気づいていたようだが、dnscacheでは実装されていなかったようだ。
簡単なパッチを入れたが、十分か。（CNAME返答をみたら、他は捨てるというもの） -- ToshinoriMaeno 2015-10-04 22:06:34
5.2. unboundの扱い
answer sectionのAは捨て、CNAMEの先を問い合せしなおす。
手元のunbound 1.5.5 はCNAME chain は8,9段で打ちきっている。
Unbound 1.0.2 Patch Announcement：
CNAME chains are cut off, only the first CNAME is kept as answer. The remaining CNAMEs or answer records are not kept, but looked up instead.
5.3. Knot resolver
CNAME毒盛攻撃が成立する。修正案を提案しておいた。 -- ToshinoriMaeno 2015-10-20 22:27:17
5.4. BIND
https://lists.isc.org/pipermail/bind-users/2012-June/088009.html
Named first parses the response to extract the records into RRsets. Responses with multiple CNAMES are detected at this point and get rejected. Named then tries to interpet the parsed message and once it has seen the CNAME and associated RRSIGs it stops processing the result and issues a new query for the target of the CNAME. This is done to stop the cache being poisoned.
RRSIGがないとどうなるのかは不明。
CNAME毒盛可能と思われる。
6. pdns-recursor
BINDに同じらしい。
7. NS 攻撃？
Metasploit’s Bailiwicked_domain is thus, in the long term, much more effective than Bailiwicked_host
https://www.rapid7.com/db/modules/auxiliary/spoof/dns/bailiwicked_domain