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

Downadup / Conficker and Disabling Autorun

Just a quick heads up related to disabling Autorun to protect against Downadup / Conficker. While the worm continues to spread and receive more media coverage, IT personnel are working to make sure their systems are protected. One of several ways this worm spreads is by taking advantage of the Autorun feature in Windows systems. Disabling this feature via Group Policy is a logical decision, but it turns out it may not actually work like it should.

Disabling Autorun via GPO currently only disables Autoplay on media insert. However, if there is an Autorun.inf file present on a CD, USB, or network drive, the program will still run when double clicking that drive in Windows Explorer. This vulnerability was announced by the U.S. CERT team on January 20, and later updated to provide patch details from Microsoft. Follow the links below for full details on the problem and where to get the patch.

Microsoft KB953252
UPDATE: Microsoft released KB967715 on March 10 to address this autorun problem in all versions of Windows.

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

Security Assessment with Nessus

As an IT Professional, one of your most important responsibilities is to ensure that your environment is a secure one in terms of protection from known vulnerabilities. To many Sys Admins, this often means just making sure patches are applied. That is necessary, but patching alone isn’t the complete answer, many problems are not resolved by patching. Critical security issues can be the result of accidental or negligent misconfigurations of some system component, poorly coded applications (especially web apps), the result of some past malicious activity, or any number of other factors.

There are a large number of security assessment tools available, ranging widely in capabilities and price. The Microsoft Baseline Security Analyzer (MBSA) tool is one familiar to many, but that only shows a small subset of potential problems on Windows based machines. An MBSA scan result of Pass can lure one into a false sense of security. One of the best, if not the best, security assessment tools is Nessus, a cross platform scanner from the Tenable Network Security group. Nessus has consistently been voted #1 security tool in Top 100 survey. The Nessus scanner can identify problems on Windows and *nix based hosts, as well as other networked systems such as routers and NAS devices. The Nessus scanner will use various methods to attempt OS fingerprinting and service detection, then utilizing a system of “plugins”, Nessus identifies system misconfigurations, known vulnerabilities, or systems otherwise not complying with a local security policy. Having this information allows you to resolve problems that could lead to privilege escalations, denial of service (DoS) attacks, data theft, etc. It can be quite eye opening to see how many potential problems exist on your network.

Here are some problems of various severity levels identified by a recent Nessus scan on my network:

  • IIS Web server: found cross site scripting vulnerabilities because of unnecessarily enabled debugging functions; various misconfigurations allowing path enumeration & site maps, plain text authentication forms, and some minor CGI issues
  • Apache Web server: identified old version allowing cross site scripting vulnerabilities in several in-use modules; potential DoS issue
  • Domain Controllers: allow certain anonymous LDAP enumeration queries (actually the default in Server 2003)
  • Discovered several systems with “Etherleak” vulnerabilities in NIC drivers, including a router – where contents from memory or previous packets are leaked in response to malformed packets.
  • Found vulnerability in McAfee ePO agent allowing remote code execution.
  • Found old version of print daemon on a Linux print server allowing remote command execution
  • NAS Device: Found Samba buffer overflow vulnerability allowing remote code execution; identified enabled guest account allowing NULL session share & file enumeration.
  • Identified a few MS Terminal Servers vulnerable to MITM attacks
  • Database Servers: found a brute force and several buffer overflow vulnerabilities on 2 different platforms

As you can see, Nessus is great for giving you an idea of where your environment stands from a security & vulnerability perspective. Obviously it’s also a must for anyone with an interest in penetration testing. Nessus binaries are available for Windows, Linux, Mac, & Unix. The Windows version uses an agentless client-server model (both can be on the same machine), is easily configured, and simple to install. Scan results can be exported into various formats. There is also a “Safe Checks” option that, when disabled, will actually attempt to exploit some vulnerabilities or crash certain services or OS’s (obviously not recommended in production). Nessus is free to download and use for personal use, with licensing options available for support and advanced enterprise usage.

A successful security policy design often uses a layered approach. Many problems identified by a security assessment can be mitigated by other best practices such as patching, proper segmentation, firewall design, least user privilege, and secure coding. Nessus is one of several tools available to IT personnel to ensure their infrastructure is secure as possible at all layers.

Nessus Vulnerability Scanner

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

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

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“.