Stopping Conficker with OpenDNS

Conficker is quickly becoming a mainstream news story as April 1 approaches, the date that the worm is programmed to “phone home” for further instructions. It has been discussed in various news outlets, even garnering a primetime spot on 60 Minutes this past weekend. The worm has been a great source of concern for IT execs the past couple of months, though the actual severity is yet to be determined. There are several mitigating factors that are supposed to minimize the chance for compromise, and a number of ways to detect and remove the virus. Another potential weapon against Conficker that should be considered is the use of OpenDNS to block the worm from communicating with command and control servers for further instructions.

In analyzing the virus, engineers have found that Conficker uses an algorithm to determine a number of different domains to contact for further instructions beginning on April 1. The algorithm was used to determine the exact list of domains that would be used. OpenDNS recently added a feature which would block access to these domains: We’ve teamed with Kaspersky Lab to identify those domains, and stop resolving them. This means if you’re using OpenDNS, Conficker will do your network no damage. From a management perspective, this is a much less intensive solution than attempting to block the domains on your local DNS servers and dealing with the overhead involved.

While using OpenDNS might not be feasible for larger enterprises, this is a great solution for SMB’s and home users. I’ve used it personally for some time now; the amount of centralized control available and ease of use makes it extremely attractive. A wealth of reporting features are also available, including one to specifically identify requests to known malware sites (like Conficker). Steps still need to be taken to ensure that Conficker is identified and removed from your network, but this is a good way to ensure that if any instances go undiscovered, they won’t be able to cause further harm.

Related Links:

In depth analysis of Conficker
Subscribe to

Random Tech-Bits: Friday Link Roundup – Nov 14

Interesting IT & InfoSec related links this week:

30 Skills Every IT Person Should Have – InfoWorld Article. This is one of the better lists like this I’ve come across.

Security Vulnerabilities in SOHO Routers – Very interesting paper discussing a number of the weaknesses found in SOHO routers.

Breaking WEP & WPA – Paper covering the recent WPA TKIP attack.

Roughly 25% of DNS Servers Still Vulnerable – Article covers a recent study showing many DNS servers still vulnerable to cache poisoning attacks.

Links: Major TCP/IP Vulnerability & New “Windows Cloud” OS

Just a few quick links of interest today. First up are a few related to a serious vulnerability in TCP/IP that enables denial of service attacks against any platform running TCP/IP (so basically everything). Hopefully we’ll see patches from vendors before more details are made available on Oct. 17th.

New DoS Attack is a Killer

New attacks reveal fundamental problems with TCP

Researchers caution against TCP/IP weakness

Update (Oct 2): This post from Fyodor, creator of Nmap, does a good job at explaining what this vulnerability might be, and putting it into perspective. Sounds like this may not be anything new.

Update (Oct 3): Robert Lee, one of the researchers behind the vuln discovery, responds to Fyodor’s post.

Last up, Microsoft CEO Steve Ballmer announced today that within a month MS will release a new operating system, currently being called “Windows Cloud”. Sounds interesting, I’m sure it will build upon their “Live” services platform, some of which I’ve covered in the past.

Microsoft will soon release ‘Windows Cloud’ OS

BGP Exploit

The usual security blogs are abuzz today with the news of the Border Gateway Protocol (BGP) vulnerability described at DEFCON 16. I won’t bother reposting all the details, but I’ve aggregated a few of the more informative links to information on the subject below. The potential to exploit BGP in this way has been talked about for at least the better part of a decade, but apparently never demonstrated until the DEFCON conference. The links have some decent technical info; it appears frighteningly simple for a person with the proper resources to hijack & intercept a remote network’s transmissions while mostly remaining undetected. Article

Original DEFCON Presentation

DHS Routing Security Initiative

And of course…. Wikipedia

DNS Vulnerability Notes, part 2

Looks like the details of the Kaminsky DNS vulnerability (intended to be released in mid August) have been discovered early. This was inadvertently confirmed on the Matasano blog yesterday but pulled a few hours later. Fortunately Google Reader cached it for me. I won’t repost it here, though a quick search online should find it. There are also additional details here.

If this is correct, it confirms that it was an issue based on being able to identify a DNS resolver’s source port, combined with the transaction ID, as well as being able to craft a packet to add an Additional Resource Record (this additional RR is where the malicious data is). In the testing I did on Microsoft DNS implementations, prior to the patch, a server’s resolver for recursive data used the same source port for queries. This is one of the fixes in the latest patches; resolvers are now using a random source port for each query.

Knowing the source port makes it moderately easy to spoof a DNS response. Using a slightly different variation of the example in my previous post on this subject, an attacker could use this exploit on an un-patched DNS server as follows:

1) An attacker wants to spoof a DNS response for

2) The attacker continuously queries your recursive DNS server for (where xxxxx is a variable, resulting in a Non-Existent domain response).

3) During this time, the attacker submits a large number of DNS response queries to your DNS server, knowing the source port, all he needs to eventually get correct is the transaction ID. The majority of these packets will be dropped by your DNS server. However, when the attacker finally gets the correct query ID, as long as the malicious packet beats the actual recursive response, it will be accepted.

4) This packet will tell your DNS server that can be found at (a rogue IP), but will also contain an Additional RR for, directing it to a rogue IP. A patch to DNS some time ago, called bailiwick checking, specifies that Additional RR’s must match the domain in the DNS query, and in this case, it does.

5) Setting a high TTL on the RR means that your clients are vulnerable to this attack for as long as the record is cached.

So the patch for this at the very least addresses source port randomization, making this current exploit nearly impossible. I don’t know what other fixes are included, but I could see some sort of record name checking on the response being good, though I don’t know what affect that may have on DNS wild-carding (probably none). This is a difficult vulnerability to take advantage of, but still very possible, especially with the details now being out there. Now is a good time to patch this if you haven’t already.

Update (23-Jul): Check here or here for details on how to check your resolvers for this vulnerability. Confirmed that MS patch fixes this by “using strongly random DNS transaction IDs, using random sockets for UDP queries, and updating the logic used to manage the DNS cache“.

DNS Vulnerability Notes

I’ve been experimenting with various DNS implementations this week since the release of the latest cache poisoning vulnerability discovered by Dan Kaminsky ( The Nemesis utility, included on the BackTrack 3 distribution, is great for crafting & injecting DNS packets onto the wire (and just about any other packet type) to do this type of testing.

The exact technical details won’t be released until early August, but it appears this DNS vulnerability is possible because a response to a DNS client request is typically considered valid if a minimum of 3 requirements are met: 1) the response must be sent to the port that the request originated from, 2) the DNS message transaction ID must match, and 3) the response should contain the correct resource record (RR) asked for in the request. Depending on the resolver, other conditions may need to be met, such as the source IP of the response matching the destination IP of the original request. Also I’ve found that #3, the response containing the correct RR, isn’t always required, depending on the client. RFC 1035 has all the technical details:

This weakness in DNS and the ability to exploit it have been known for several years, and somewhat addressed by various software updates. In the past, resolvers would start the source port and the DNS message transaction ID’s at a certain point, and then increment these in subsequent requests by one. This made it very easy to guess what these values would be in future DNS requests. Later versions of Microsoft OS’s randomized the transaction ID, but often used the same source port for requests, and the randomnization of the transaction ID’s was suspect. This vulnerability is such a big issue because it allows an attacker to spoof a response to a client’s name resolution request; when a request is made to a recursive DNS server that doesn’t hold the required zone info, that server then becomes a client itself. So not only is there potential to poison the cache of a single client, there is potential to poison a DNS server’s cache, potentially impacting all the clients of that server.

Consider the following: through several possible methods, an attacker is able to determine what the expected possible transaction ID and source port of the next DNS request will be on your DNS server. He then makes a query to your recursive DNS server for Having previously configured Nemesis to respond to this request, he injects this packet into the network to respond to your DNS server’s request (or quickly injects multiple packets to increase chances of success). As long as the attacker’s response beats the valid response to the DNS server (and meets the RFC 1035 requirements), it will be accepted. The DNS answer will direct traffic to a rogue IP address, on which the attacker will have set up a website identical to From there, passwords can be stolen from unexpecting users. This is a high level overview and there are several factors I won’t get into here that may decrease or increase the attacker’s chances of success, but this is just an example of one possible exploitation.

The bottom line is to make sure your DNS servers and clients are patched to address this (the CERT link above lists vulnerable systems). It is fairly easy with a little know-how (and patience to convert text to hex to binary) to exploit DNS with tools such as Nemesis. Those interested in trying this to see exactly how it works can still do so even on patched Microsoft systems, as long as the nslookup utility is used as the client. I’ve found this tool still increments source port and transaction ID by one, even on patched XP, 2003, and 2008 systems (I haven’t yet tested Vista or other OS’s). Hopefully this recent exploit and others like it will raise awareness of the need to secure DNS with something along the lines of DNSSEC.