Monday, March 30, 2009

Scalable Infrastructure vs Large Problems, or OpenDNS vs Conficker

After seeing Dan Kaminsky's talk at Black Hat DC last month, I blogged about the benefits of DNS' ability to scale to address big problems like asset management records. I've avoid talking about Conficker (except for yesterday) since it's all over the media.

Why mention DNS and Conficker in the same post? All of the commotion about Conficker involves one variant's activation of a new domain generation algorithm on 1 April. Until today no one had publicly announced the reverse engineering of the algorithm, but right now you can download a list of 50,014 domains that one Conficker variant will select from when trying to phone home starting 1 April. Some of the domains appear to be pre-empted:

$ whois aadqnggvc.com.ua
% This is the Ukrainian Whois query server #B.
% Rights restricted by copyright.
%

% % .UA whois
% Domain Record:
% =============
domain: aadqnggvc.com.ua
admin-c: CCTLD-UANIC
tech-c: CCTLD-UANIC
status: FROZEN-OK-UNTIL 20090701000000
dom-public: NO
mnt-by: UARR109-UANIC (ua.admin)
remark: blocked according to administrator decision
changed: CCTLD-UANIC 20090320144409
source: UANIC

Others appear ready for registration:

~$ whois aafkegx.co.uk

No match for "aafkegx.co.uk".

This domain name has not been registered.

WHOIS lookup made at 00:56:31 31-Mar-2009

Keep in mind that another 50,000 domains will be generated on 2 April, and so on. With such a big problem, what could we do to contain this malware?

OpenDNS is a possible answer:

OpenDNS has kept our users safe from Conficker for the past several months by blocking the domains it uses to phone home...

The latest variant of Conficker is now churning through 50,000 domains per day in an attempt to thwart blocking attempts. Consider this: at any given time we have filters that hold well over 1,000,000 domains (when you combine our phishing and domain tagging filters). 50,000 domains a day isn’t going to rock the boat.

So here’s our update: OpenDNS will continue to identify the domains, all 50,000, and block them from resolving for all OpenDNS users. This means even if the virus has penetrated machines on your network, its rendered useless because it cannot connect back to the botnet.


That's one advantage of outsourcing your Internet DNS to a third party. They have the resources to integrate the latest threat intelligence and the position to do something to protect users.

This is a great example of scalable infrastructure (DNS) vs large problems (Conficker).

Finally, you've probably heard about the Conficker Know Your Enemy paper and associated upgraded scanning tools, like Nmap 4.85BETA5 and the newest Nessus check. I can't wait to see the results of tools like this. It could mark one of the first times we could fairly easily generate a statistic for the percentage of total assets compromised, similar to steps 8 and 9 from my 2007 post Controls Are Not the Solution to Our Problem. In other words, you can scan for Conficker and determine one score of the game -- the percentage of hosts compromised by one or more Conficker variants. The question is, how long until those controlling Conficker update the code to resist these remote, unauthenticated scans?


Richard Bejtlich is teaching new classes in Europe and Las Vegas in 2009. Online Europe registration ends by 1 Apr, and seats are filling. Early Las Vegas registration ends 1 May.

11 comments:

zonky said...

So now you can create malware which encourages DoS attacks by OpenDNS against potentially legitimately registered domains?

Aren't we giving OpenDNS a bit too much power?

Richard Bejtlich said...

Hi Zonky,

There are no perfect answers here, but this one looks best given the alternatives. And, if you don't like it, you don't have to use it. That works well I think!

zonky said...

Agreed, there are never absolutes. But if opendns are seriously proposing to be blocking 50,000 domains from DNS a day, does that not become a new form of a Denial of Service attack?

I just feel sorry for the American-Armenian foundation of Kingston, Edgware, Guilford (based) Xenophobes, and their inability to aquire a domain that may work for a certain percentage of the internet.

nr said...

zonky, outsourcing site categorization and blocking is nothing new. Most companies using a web proxy or other similar tools are already blocking traffic based largely on lists of malicious domains generated outside one's own organization. How is using OpenDNS any worse? You always have the potential to block non-malicious sites, and how aggressive you want to be with blocking will depend largely on risk.

zonky said...

That's a fair point. Presumably OpenDNS are going to spell out when a blocked name is accessed via your web browser, much like they do for other services?

I guess i was initially thinking in such a situation there would be little or no info on why a particular dns name was not working.

I know OpenDNS do 'report errors' via web rewriting- do they also offer any sort of mail bouncebank if you encoutered a problem with a domain via smtp or other common protocol?

Anonymous said...

The nmap scan at least uses a port 445 control...can't the worm just omit that port when it disables local firewall protection, or does it even need to have that open? If nmap sees it as filtered, I'm guessing it can't fingerprint it. I ran the new nmap and it seemed to do the check AFTER determining that 445 was open.

jof said...

What's to stop a future version or worm from just doing it's own DNS lookups?

I suppose one could firewall all outgoing to DNS except to OpenDNS.

Anonymous said...

I would like to point out that OpenDNS is directing traffic destined for www.google.com through proxy servers they operate.

You can check this for yourself, but FYI :

normal results (might be depending on your geographical location) :

C:\Tools\isc-dig>dig www.google.com +short
www.l.google.com.
74.125.79.104
74.125.79.99
74.125.79.103
74.125.79.147
C:\Tools\isc-dig>

when using OpenDNS servers :

C:\Tools\isc-dig>dig www.google.com @208.67.222.222 +short
google.navigation.opendns.com.
208.69.34.230
208.69.34.231

C:\Tools\isc-dig>dig www.google.ca @208.67.222.222 +short
www.google.com.
google.navigation.opendns.com.
208.69.34.231
208.69.34.230

C:\Tools\isc-dig>dig www.google.co.uk @208.67.222.222 +short
www.google.com.
google.navigation.opendns.com.
208.69.34.231
208.69.34.230

C:\Tools\isc-dig>


Credits to find this out (AFAIK) go to HD Moore - see here

David Ulevitch from OpenDNS states in a comment on above blogpost

"With regards to the Google redirect, it is done to solve some issues caused by newer versions of the Google toolbar. We do it in as clear a way as possible (hence the CNAME instead of just returning an IP).
We also make it easy to turn off just by going to "Settings -> Advanced Settings" and unchecking the box for the proxy. 99.999% of people don't care, and for the few who do, that's why we make it as crystal clear as we do. And finally, we do not keep logs of ANY of the traffic that passes through it."


You could discuss whether or not they are open about this, and to what degree (see http://www.opendns.com/support/article/244 ) and whether or not this infringes their privacy statements but - most importantly :

(1) be aware of this

(2) do your own evaluation of benefits and tradeoffs


Regards
Tomas Vanhoof

P.S.: Richard, please keep up the excellent work you do by running this blog! You have a positive impact on the professional lives of thousands of people and this blog contributes to make systems and networks all over the world being operated more securely! Thank you very much for that!

Anonymous said...

It's probably good to keep in mind that the CONFICKER botnet has a built in p2p network which means it doesn't really need any of the 250 or 50,000 domains to work in order for it to get upgraded.

So saying OpenDNS is going to protect you because it will block the 50,000 domains doesn't exactly give the whole picture.

bazizoo said...
This comment has been removed by the author.
bazizoo said...
This comment has been removed by the author.