1. DNS/毒盛/CNAME

警告:CNAME返答を利用した毒盛攻撃に弱いリゾルバーがある。

http://insecure.org/sploits/dns.cache-poison.cname.html

https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf

以下の三種類を分けて考慮する必要がある。

  1. 正当なゾーンサーバが返事に偽の情報を返すもの

  2. 偽の返答としてCNAMEを受け取らせようとするもの

  3. 偽返答で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に一致しないものは捨てる。

BIND 9.4.1 は毒盛されるとのこと(Hitchhiker's Guide)

参考: ../AncillaryDataAttacks

対策2: キャッシュされているレコードのownerと一致するCNAME返答は捨てるのがよい。

対策3: ネガティブキャッシングされているレコードのownerと一致するCNAME返答は捨てるのがよい。

これらが攻撃手法のヒントになる危険性もあるが、警告しないのもまずいので、書いておく。 -- ToshinoriMaeno 2016-07-14 15:10:05

/防御 /KnotResolver

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

https://www.blackhat.com/presentations/bh-dc-09/Kaminsky/BlackHat-DC-09-Kaminsky-DNS-Critical-Infrastructure.pdf

CNAME Records provide the “Canonical Name” for a server, and additionally the IP of that server

These Imply A Series Of Attacks

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. これまで

こういう返事をもらったら、キャッシュはどう扱うべきなのか。

5.1. dnscache/djbdns

DJBは危険性に気づいていたようだが、dnscacheでは実装されていなかったようだ。

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

8. 未読

http://www.icir.org/vern/papers/hold-on.satin12.pdf

/unbound