DNS Exploit in the Wild - Test your ISP now!


#1

You can check if the dns server you use is vulnerable at both of the links below:

http://www.doxpara.com/

https://www.dns-oarc.net/oarc/services/dnsentropy

Report results from your ISP in the posts below. Use both links to test your DNS server before responding.

Source: http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html

[quote=", post:, topic:"]
Details of DNS Flaw Leaked; Exploit Expected by End of Today

Despite Dan Kaminsky's efforts to keep a lid on the details of the critical DNS vulnerability he found, someone at the security firm Matasano leaked the information on its blog yesterday, then quickly pulled the post down. But not before others had grabbed the information and reposted it elsewhere, leading Kaminsky to post an urgent 0-day message on his blog reading, "Patch. Today. Now. Yes, stay late."

Hackers are furiously working on an exploit to attack the vulnerability. HD Moore, creator of the Metasploit tool, says one should be available by the end of the day.

Earlier this month, Kaminsky, a penetration tester with IOActive, went public with information about a serious and fundamental security vulnerability in the Domain Name System that would allow attackers to easily impersonate any website -- banking sites, Google, Gmail and other web mail websites -- to attack unsuspecting users.

Kaminsky announced the vulnerability after working quietly for months with a number of vendors that make DNS software to create a fix for the flaw and patch their software. On July 8, Kaminsky held a press conference announcing a massive multivendor patch among those vendors, and urged everyone who owns a DNS server to update their software.

But Kaminsky broke one of the fundamental rules of disclosure in announcing the bug. He failed to provide details about the flaw so system administrators could understand what it was and determine if it was serious enough to warrant an upgrade to their systems.

Kaminsky promised to reveal those details next month in a presentation he plans to give at the Black Hat security conference in Las Vegas. But he said he wanted to give administrators a 30-day head start to get their systems patched before he provided details that could allow hackers to create an exploit to attack the systems.

Kaminsky asked researchers not to speculate about the bug details in the meantime and to trust that it was a serious issue. Some did as he asked. But many security researchers took his coyness as a challenge to uncover the details Kaminsky was holding back.

Halvar Flake, a German security researcher, was the first to publish details that correctly speculated on the bug (which have since been removed from his blog), though Kaminsky told Threat Level that others figured out the bug many days before Flake published his findings. Flake's post also didn't provide all of the correct details about the bug. But Matasano took care of that issue when it spilled the beans in a post that has garnered heavy criticism from other security researchers who accuse Matasano of irresponsible disclosure and of trying to get publicity by stealing attention from Kaminsky's Black Hat talk next month.

The disclosure was bound to happen, however, since Kaminsky had been forced to provide details of the bug privately to numerous people who balked at patching their systems without knowing the exact nature of the bug. In the absence of these details, some system administrators and security researchers had accused Kaminsky of rehashing an old, known vulnerability in DNS to gain notoriety.

Matasano's founder, Thomas Ptacek, had been one of the researchers who doubted Kaminsky's findings, but he recanted after Kaminsky disclosed details of the bug to him in private. Ptacek wasn't the employee whose name appeared at the bottom of the Matasano post disclosing the information, but the founder apologized today for disclosing the information. In the message he said the company had written the post in anticipation of publishing it as soon as Kaminsky or someone else spilled the details, implying that the early publication had been unintentional.

The DNS flaw that Kaminsky discovered allows a hacker to conduct a "cache poisoning attack" that could be accomplished in about ten seconds, allowing an attacker to fool a DNS server into redirecting web surfers to malicious web sites.

DNS servers do the job of translating a web site's name to its address on the internet -- for example, translating www.amazon.com to 207.171.160.0 -- so a browser can bring up the web site for a user. A cache poisoning attack allows a hacker to subvert a DNS server to surreptitiously translate a website's name to a different address instead of the real address, so that when a user types in "www.amazon.com," his browser is directed to a malicious site instead, where an attacker can download malware to the user's computer or steal user names and passwords that the user enters at the fake site (such as e-mail log-in information), similar to the way phishing attacks work.

"It's a really bad bug that really impacts every web site you use and your readers use," Kaminsky said. "It impacts whether or not readers are even going to see the article you're about to write."

Kaminsky told Threat Level he's not interested right now in slinging mud with Matasano and others over how the information has been disclosed. He just wants people to patch their systems.

He also says he's happy that administrators have had some time, though not as much as he'd hoped, to get their systems patched before the information went public.

"We got thirteen days of a patch being out without the bug being public," he said. "That's unprecedented. I'm pretty proud of at least thirteen days. I would have liked thirty, but I got thirteen."

[/quote]

Source: http://blog.wired.com/27bstroke6/2008/07/dns-exploit-in.html

[quote=", post:, topic:"]
DNS Exploit in the Wild -- Update: 2nd More Serious Exploit Released

Well it took a little longer than expected so it's not quite a zero-day exploit, but the anticipated attack code to exploit the critical Kaminsky DNS cache-poisoning flaw is now in the wild (assuming there wasn't one already out there).

Let's call it a .5-day exploit.

HD Moore, creator of the Metasploit Framework research and hacking tool, pinged me that he's just released the code. System administrators who dragged their feet over updating their DNS servers have lost the race . . . so to speak. But that doesn't mean it's too late to patch your system.

Moore says the code currently has a limitation:

This exploit can't be used to overwrite an existing cache entry, so attackers will have a hard time spoofing common host names on busy DNS servers. The module added to Metasploit will display the expiration date for any pre-cached entries and automatically wait for that amount of time for completing the attack.

No one should take comfort in this, however.

For readers who aren't familiar with it, Metasploit is a penetration testing tool that system administrators use to test their networks with real exploits in order to uncover vulnerabilities and fix them. But in the double-edged world of computer security, any tool used legitimately to test the security of a network can also be used by hackers to attack a network.

The exploit was co-developed with |)ruid from Computer Academic Underground. The two have posted an advisory about the exploit.

UPDATE: Moore has added a second exploit to Metasploit; this one is more serious. Here's his description:

We just added a second exploit which replaces the nameservers of the target domain. This is the bug people should actually care about, since it doesn't matter if anything is already cached.

Regarding the cache situation (of the first exploit) -- it's not possible to do cache overwrites, but it is possibe to look up the cache timeout, wait for it, and then replace it. With the new exploit module, we just change the DNS server for the entire domain (regardless of what is cached), so it's much more effective for wide-scale hijacking.

[/quote]

#2

In this post, I will maintain a list of test results for various ISPs. Color codes represent if the listed ISP has patched its systems and is safe or not.

Key:

Red: Unsafe/Unpatched

Green: Safe/patched

Cyberlink: Report

Maxcom: Report

Micronet: Report

Multinet: Report

Wateen: Report

To view report, replace 'hxxp' with 'http'.


#3

Your name server, at 202.70.150.11, appears vulnerable to DNS Cache Poisoning.

All requests came from the following source port: 33994

Due to events outside our control, details of the vulnerability have been leaked. Please consider using a safe DNS server, such as OpenDNS. Note: Comcast users should not worry.Requests seen for 48063d230606.doxdns5.com:

202.70.150.11:33994 TXID=12135

202.70.150.11:33994 TXID=41619

202.70.150.11:33994 TXID=59546

202.70.150.11:33994 TXID=26851

202.70.150.11:33994 TXID=34027

Maxcom seems to be vulnerable


#4

Saad, please use the second testing link to verify the results. After that, link the test result page here.

If your ISP is vulnerable, immediately contact your ISP to inform them of this problem and urge them to take steps post-haste to ensure security.


#5

Here it is:

http://6a509eace6c28f69feebbd94.et.dns-oarc.net/

its a mix bag of results!

btw last time I didn't see the second link


#6

here is mine:

Your name server, at 221.132.112.8, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).

from 2nd link,

http://c200d30dbe23beccf5fc9716.et.dns-oarc.net/


#7

[quote=", post:, topic:"]

1. 202.125.152.195 (UFONE.rwp44.pie.net.pk) appears to have POOR source port randomness and GREAT transaction ID randomness.

2. 202.125.152.252 (UFONE.rwp44.pie.net.pk) appears to have POOR source port randomness and GREAT transaction ID randomness.

[/quote]

mine here


#8

Warid EDGE, Lahore

First Test: "Appears to be Safe"

Second Test: Results for 4 different Nameservers: "appears to have POOR source port randomness and GREAT transaction ID randomness."

I am going to call the Helpline and ask them to get the servers patched, hoping they would pass the message and someone will be active enough to make the patch.

EDIT: The CR guy said that I am very thankful for informing this, but I advise you to mail all the details so it can be fixed. I have just mailed them but just reading that specific mail might take days, so I am going to call them again and ask them to inform the responsible department.


#9

[quote=", post:, topic:"]

Here it is:

http://6a509eace6c28f69feebbd94.et.dns-oarc.net/

its a mix bag of results!

btw last time I didn’t see the second link

[/quote]

Yeah, I found that latter to be far more detailed so I edited my post to include it too.


#10

[quote=", post:, topic:"]

mine here

[/quote]

Please post the results from second link.


#11

[quote=", post:, topic:"]

Warid EDGE, Lahore

First Test: "Appears to be Safe"

Second Test: Results for 4 different Nameservers: "appears to have POOR source port randomness and GREAT transaction ID randomness."

I am going to call the Helpline and ask them to get the servers patched, hoping they would pass the message and someone will be active enough to make the patch.

EDIT: The CR guy said that I am very thankful for informing this, but I advise you to mail all the details so it can be fixed. I have just mailed them but just reading that specific mail might take days, so I am going to call them again and ask them to inform the responsible department.

[/quote]

Post the results page link from second testing site please.


#12

Wateen "appears to have POOR source port randomness and GREAT transaction ID randomness." ... I don't care since I am using the OpenDNS anyways.


#13

I have mailed both Cybernet and Wateen regarding the patch, so lets hope they do something about it.

Though I was wondering, isn't posting the link to your ISPs nameserver's a bad idea at the moment, as that would be indexed and made public for any attacker? I realize that they might be able to search for nameservers via other methods, but still.


#14

[quote=", post:, topic:"]

@ Asad:

Here you go man.

[/quote]

Thanks.

[quote=", post:, topic:"]
Though I was wondering, isn’t posting the link to your ISPs nameserver’s a bad idea at the moment, as that would be indexed and made public for any attacker? I realize that they might be able to search for nameservers via other methods, but still.
[/quote]

I have taken a security precaution now. Using hxxp in the link instead of http.


#15

[quote=", post:, topic:"]

I have taken a security precaution now. Using hxxp in the link instead of http.
[/quote]

Yeah that’s a good idea. I think the rest of the posts in the topic should also be edited, you know just to be on the safe side.


#16

I use opendns. Seems they are cool

first one

[quote=", post:, topic:"]
Your name server, at 208.69.34.6, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).
[/quote]

second one

[quote=", post:, topic:"]
1. 208.69.34.6 (bld2.lon.opendns.com) appears to have GREAT source port randomness and GREAT transaction ID randomness.

2. 208.69.34.10 (bld4.lon.opendns.com) appears to have GREAT source port randomness and GREAT transaction ID randomness.

[/quote]

So seems better to ditch your isp's dns servers and use opendns :)


#17

Reports for Zong Internet //Zong uses cybernet at backend

The 1st one

Your name server, at 203.82.55.28, appears vulnerable to DNS Cache Poisoning.

All requests came from the following source port: 1057

Due to events outside our control, details of the vulnerability have been leaked. Please consider using a safe DNS server, such as OpenDNS. Note: Comcast users should not worry.

Requests seen for 71d8f4fcfdc7.doxdns5.com:

203.82.55.28:1057 TXID=27879

203.82.55.28:1057 TXID=43287

203.82.55.28:1057 TXID=17342

203.82.55.28:1057 TXID=37109

203.82.55.28:1057 TXID=24026

The 2nd one

203.82.55.xx (nsx.paktel.com) appears to have POOR source port randomness and GREAT transaction ID randomness.


#18

every dns server here seems to be using single port instead of random ports


#19

[quote=", post:, topic:"]

mine here

[/quote]

Since i am on ptcl so i got same results… poor and great.

I wonder if ptcl officials will even understand if there is such kind of threat exist in nature?


#20

I hope these ISPs stop sitting around and resolve this right away!