Tag: kaminsky

Digital Armageddon

April 1, 2009. The major media outlets are all over this one. Digital Armageddon. The end of computing as we know it. Again. But is it? Should we all just “Chill Out?”

So what happens April 1, 2009? Well, Conficker activates. Well, sort of. It activates the latest revision of its auto-update algorithm, switching the number of domains it can find updates on from 250 per day to 50,000 per day. Conficker, in its current form, isn’t really malicious beyond techniques to prevent detection. In order to become malicious, it will need to download an update to the base code.

There are two methods by which Conficker will update its base code. The first method is to download the code via a connection to one of the 50,000 domains it generates. However, it does not scan all 50,000 domains at once. Instead, it creates a random list of 500 of the 50,000 generated domains and scans them for an update. If no update is found, Conficker sleeps for 24 hours and starts over by generating a new list of 50,000 domains, randomly picking 500, and contacting them for an update. The overall result of this is that it becomes nearly impossible to block all of the generated domains, increasing the likelyhood that an update will get through. On the flip side, this process appears that it would result in a very slow spread of updates. It can easily take days, weeks, or months for a single machine to finally stumble upon a live domain.

The second method is to download the code via a peer-to-peer connection between infected hosts. As I understand it, the peer-to-peer mechanism has been active since revision C of Conficker has been in the wild. This mechanism allows an update to spread from system to system in a very rapid manner. Additionally, based on how the peer-to-peer mechanism works, it appears that blocking it is difficult, at best.

So what is the risk here? Seriously, is my computer destined to become a molten heap of slag, a spam factory, or possibly a zombie soldier in a botnet attack against foreign governments? Is all hope lost? Oh my , are we all going to die!

For the love of all things digital, pull it together! It’s not as bad as it looks! First off all, if you consistently update your machines and keep your anti-virus up to date, chances of you being infected are very low. If you don’t keep up to date, then perhaps you should start. At any rate, fire up a web browser and search for a Conficker scanner. Most of the major anti-virus vendors have one. Make sure you’re familiar with the company you’re downloading the scanner from, though, a large number of scam sites have popped up since Conficker hit the mainstream media.

If you’re a network admin, you have a bigger job. First, I’d recommend any windows machines you are responsible for are patched. Yes, that includes those machines on that private network that is oh-so impossible to get to. Conficker can spread via samba shares and USB keys as well. Next, try scanning your network for infections. There are a number of Conficker scanners out there now thanks to the Honeynet Project and Dan Kaminsky. I have personally used both the proof-of-concept python scanner, as well as the latest version of nmap.

If you’re using nmap, the following command line works quite well and is incredibly fast :

nmap -sC –script=smb-check-vulns –script-args=safe=1 -p139,445 \
-d -PN -n -T4 –min-hostgroup 256 –min-parallelism 64 \
-oA conficker_scan

Finally, as a network admin, you should probably have some sort of Intrusion Detection System (IDS) in place. Snort is an open source IDS that works quite well and has a large community following. IDS signatures exist to detect all known variants of Conficker.

So calm down, take a deep breath, and don’t worry. I find it extremely unlikely that April 1 will result in anything more than a blip in network activity. Instead, concentrate on detection and patching. Conficker isn’t Skynet…. Yet.

 

Detecting DNS cache poisoning

I spoke with a good friend of mine last week about his recent trip to NANOG. While he was there, he listened to a talk about detecting DNS cache poisoning. However, this was detection at the authoritative server, not at the cache itself. This is a bit different than detection at a cache because most cache poisoning will happen outside of your domain.

I initially wrote about the Kaminsky DNS bug a while back, and this builds somewhat on that discussion. When a cache poisoning attack is underway, the attacker must spoof the source IP of the DNS response. From what I can tell, this is because the resolver is told by the root servers who the authoritative server is for the domain. Thus, if a response comes back from a non-authoritative IP, it won’t be accepted.

So let’s look at the attack briefly. The attacker starts requesting a large number of addresses, something to the tune of a.example.com, b.example.com, etc. While those packets are being sent, the attacker sends out the responses with the spoofed headers. Since we are now guessing both the QID *and* the port, we miss a lot because the port is incorrect.

When the server receives a packet on a port that is not expecting data, it responds with an ICMP message, “Destination Port Unreachable.” That ICMP message is sent to the source IP of the packet, which is the spoofed authoritative IP. This is known as ICMP backscatter.

Administrators of authoritative name servers can monitor for ICMP backscatter and identify possible cache poisoning attacks. In most cases, there is nothing that can be done directly to mitigate these attacks, but it is possible to identify the cache being attacked and notify the admin. Cooperation between administrators can lead to a complete mitigation of the attack and protection of clients who may be harmed.

This is an excellent example of the type of data you can identify simple through passive monitoring on your local network.