DNS/毒盛/Kaminsky手法/unixwiz.net

DNS/キャッシュサーバ毒盛/Kaminskyの攻撃手法/unixwiz.netについて、ここに記述してください。

1. www.unixwiz.netの説明

http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

2. Shenanigans, Version 1

In this illustration, we'll attempt to poison a particular nameserver with a fraudulent IP for a legitimate banking website, www.BankOfSteve.com. The bad guy's intention is to get all of the ISP's customers to visit his own malicious site instead of the real one operated by the Bank.

2.1. Simple Poisoning (うまくいきそうもない）

Step 1 — Bad guy sends a DNS query to the victim nameserver for the hostname it wishes to hijack.

This example assumes that the victim nameserver allows recursive queries from the outside world.

Step 2a — Knowing that the victim will shortly be asking ns1.bankofsteve.com

(as directed from the root/GTLD servers) for an IP address, the bad guy starts flooding the victim with forged DNS reply packets. All purport to be from ns1.bankofsteve.com, but include the answer with the IP of badguy's fraudulent webserver.

Steps 2b & 3 — Root/GTLD servers provide referral to ns1.bankofsteve.com.

This may be multiple queries, but we're showing just one for simplicity.

Step 4 — victim nameserver asks ns1.bankofsteve.com for the IP address of www.bankofsteve.com,

and it uses query ID 1001 (one higher than the previous query).

Step 5 — the real nameserver provides a legitimate response to this query, with QID=1001.

But if the bad guy has successfully matched the query ID in the step 2a flood, this legal reply arrives too late and is ignored. Oops.

Step 6 — With the bogus IP address (of the bad guy's webserver) in cache

it provides this poisoned answer to the requesting DNS client. Boom.

Step 7 (not illustrated) —

future DNS clients asking for www.bankofsteve.com will receive the same fraudulent answer.

3. Dan's Shenanigans

Step 1 — bad guy client requests a random name within the target domain (www12345678.bankofsteve.com),

something unlikely to be in cache even if other lookups for this domain have been done recently.

Step 2a — As before, the bad guy sends a stream of forged packets to the victim,

but instead of A records as part of an Answer, it instead delegates to another nameserver via Authority records.
- "I don't know the answer, but you can ask over there".

The authority data may well contain the "real" bankofsteve.com nameserver hostnames,
but the glue points those nameservers at badguy IPs.
This is the crucial poisoning,
because a Query ID match means that the victim believes that
badguy's nameservers are authoritative for bankofsteve.com.

The bad guy now owns the entire zone.

Curiously, the rest of the steps don't matter: the point of this process was to fake out the victim into thinking that badguy runs the domain in question, and that would have been successful in this step.

Once one of the victim's queries has been poisoned — it could be any in the chain — all the rest are directed to badguy's servers.

4. コメント

こんなに簡単に入るのを確認できたのなら、その時のbindには不良があったはずだ。 -- ToshinoriMaeno 2011-08-20 10:32:04