• Categories

  • Book Suggestions

  • Advertisements

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 TechScrawl.com


Enabling DNSSEC on BIND

My previous post was an overview of DNSSEC and how it secures DNS transactions. This one covers how to enable DNSSEC on zones running on the BIND DNS server. Specifically, this example will involve setting up DNSSEC on a parent and child zone, and confirming successful operation.

An important concept to grasp is that BIND sort of takes on two different roles pertaining to DNSSEC. One is that of providing signed data for a zone for which it is authoritative. The other is that of a validating resolver for external zones. If you only want to set up your BIND server as a DNSSEC validating resolver and not sign any of your own zones, you can skip down to the “Resolver Validation” section.
Continue reading


DNSSEC is something you’ve no doubt heard of, especially this past summer with the discovery of the Kaminsky DNS bug which led to a small panic and widespread patching from vendors. DNSSEC (sometimes called DNSSECbis) has existed as a proposal for about 10 years, but has undergone significant changes as recently as March 2008, and has only lately seen a major push to implementation. This post discusses both the need for DNSSEC and tackles the complex topic of how it works, as simply as possible. Though this really only scratches the surface, it should serve as a good intro for those who want to know more. A fundamental understanding of DNS is assumed.

Continue reading


DNS Scavenging

Scavenging of stale DNS records is key to a healthy DNS & Active Directory infrastructure, but is something that should be well understood before being enabled. Rather than rehashing a bunch of talking points on the subject, I’ve posted a link to a TechNet blog with one of the best descriptions I’ve found yet. Hopefully the second link is one you will not need, how to restore deleted DNS info.

Link: Don’t Be Afraid of DNS Scavenging

Link: Missing AD Integrated Zones


Random Tech-bits

COFEE Leaked? It looks like the COFEE utility (Computer Online Forensic Evidence Extractor) that I blogged about in April might have finally been leaked. Recall this tool is a Microsoft developed suite of pre-existing utilities designed for computer forensics and analyzation, meant for the law enforcement community. The files can be found here. I downloaded it and ran it against a Server 2008 virtual machine and it seems to be pretty comprehensive in the data it gathers. It’s worth noting that this might not actually be COFEE, when the program starts this text is displayed: “W.O.L.F. Incident Response Toolkit”. W.O.L.F apparently stands for Windows Online Forensics, which I found a small number of search results for, dating back to 2005. Looks like it could be a Microsoft pre-cursor to COFEE. Either way, seems like a decent toolset to work with until the real COFEE is leaked.

NTFS Alternate Data Streams. In my years in IT and working with Windows systems I had never heard of alternate data streams (ADS) until I saw this blog. ADS, or hidden streams, is a functionality of the NTFS file system that allows a file to be attached to another file, in essence hiding the existence of the attached file. The attached file can be executable, even if the original is not. Just imagine hiding Malware.exe in GroceryList.txt. From what I’ve read, certain virus scanners don’t always pick up these threats. The potentials for malicious use are numerous; thankfully Microsoft has helped decrease that potential in Vista & Server 2008 by making ADS files easier to find and not allowing those files to be executable. Click the link above for the entire blog post with all the details.

Full DNS Vuln Notes – Kaminsky Presentation. Now that the details of the DNS vulnerability found by Dan Kaminsky have been released, you can find a good summary of it in this blog post on his site; the Power Point slides from his presentation are a must read for a good understanding of the associated implications.


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 http://www.youronlinebank.com.

2) The attacker continuously queries your recursive DNS server for xxxxx.youronlinebank.com (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 xxxxx.youronlinebank.com can be found at (a rogue IP), but will also contain an Additional RR for http://www.youronlinebank.com, 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 (http://www.kb.cert.org/vuls/id/800113). 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: http://www.faqs.org/rfcs/rfc1035.html

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 http://www.youronlinebank.com. 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 youronlinebank.com. 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.