DNS/FCP/Subdomain_Injection
以下の節を吟味する。 -- ToshinoriMaeno 2018-11-20 04:01:44
- よく考えられている。基本線として、delegation返答を理解していること。
DNSSEC返答の内容をきちんと理解しているということも条件になりそうで、厳しい。:-<
NoData返答とreferral返答とはSOAが含まれているかどうかで区別されると理解しているのです。 ただ、SOA+NS返答をreferralだと解釈する実装が存在するかも知れない。(これは不良だというのが私の立場です。) 16:26 - 2018年11月20日
SOAが第二フラグメント以降に含まれていて、NSに置き換えることができれば、毒になります。(こういう返事をするサーバーが存在することを示す必要はあります。)
4.2 Subdomain Injection
The delegation records, NS (name server) and A (IP address), located in authority and additional sections, are not signed, [3].
This allows the attacker to change the IP address (in the additional section) of the name server of some victim domain, to its own address, or to add a new name server (in authority section) for the victim domain.
Such NS and A records are usually cached and used, for queries to the specified domain; see [33]. At this point, the attacker managed to cause queries for the victim subdomain to be sent to a machine controlled by the attacker.
This vulnerability, of redirecting DNSSEC enabled DNS requests to malicious server by a man-in-the-middle, was pointed out by Bernstein [6], yet without a specific application for such an exploit.
Bau and Mitchell, [5], refute Bernstein’s claim of this being a vulnerability, by proving that it does not enable a man-in-the-middle attacker any additional capabilities, and conclude that it does not pose a significant threat.
Indeed, not signing the delegation records does not break the design requirements defined for DNSSEC, [3].
However, it exposes to NS Hijacking (leading to a range of other attacks), Section 4.3, and to subdomain injection (as we discuss next).
Resource records in the answer section of DNSSEC-enabled domains are signed, hence, if the resolver performs strict validation of DNSSEC, it should not accept unsigned records in the answer section.
However since the delegation records in the authority and additional sections are not signed, the attacker can create a new subdomain, e.g., secure.bank.com under bank.com, by creating an NS record (in the authority section) for the new subdomain secure.bank.com mapping it to the name server which the attacker controls.
This attack is only applicable to DNSSEC protected domains that use NSEC3 opt-out:
the attacker may be able to use legitimate NSEC3 responses, e.g., for non-existing sub-domain, or other type responses, e.g., DNSKEY,
and turn them into what appears to be a legitimate referral to an unprotected subdomain;
this can be used for phishing attacks. [この部分は正しくなさそう -- ToshinoriMaeno 2018-11-20 07:14:10]
Furthermore, as [5] show, domains which deploy NSEC3 opt-out records are vulnerable to browser cookie theft by a man-in-the-middle attacker, as they allow the attacker to insert insecure delegations into DNS responses.
[5] J. Bau and J. C. Mitchell. A security evaluation of DNSSEC with NSEC3.
- In Network and Distributed Systems Security (NDSS) Symposium. The Internet Society, 2010.
[6] D. J. Bernstein. Breaking DNSSEC. 3rd USENIX Workshop on Offensive Technologies, 2009
This is in contrast to the recommendations in [26] which suggest that NSEC3 opt-out does not pose a significant threat. Bau and Mitchell performed the attack with a man-in-the-middle attacker, using our techniques an off-path spoofing attacker can perpetrate such attacks, see Figure 7.
The attack is similar to the attack in Section 4.1.1, thus to save space, we performed the addition of a new subdo- main as part of the name server hijacking attack, see Figure 7.
The record: www.sec.cs.biu.ac.il is a new (nonexisting) subdomain under sec.cs.biu.ac.il and it points at the name server ams.sec.cs.biu.ac.il controlled by the attacker.