New trojan in mass DNS hijack

Researchers have identified a new trojan that can tamper with a wide array of devices on a local network, an exploit that sends them to impostor websites even if they are hardened machines that are fully patched or run non-Windows operating systems. The malware is a new variant of the DNSChanger, a trojan that has long been …

[Rob Dobs]

Great Article

A problem, and a simple fix what a novel concept! I love opendns, and reccommend that everyone start using them, they not only will protect you from this type of DNS poisioning, but they include other phishing and re-direct protections. Even better, set up a parental account, and they will block your kids PC from going to most "bad" sites on the net. Its not a perfect protection, one more good piece of armor in keeping your kids heads safe. Any Company that is still serving DNS over DHCP should have their IT dept fired or at least trained better.

[John A Thomson]

Nothing new here

James Eaton-Lee wrote about this back in 2005 and has presented on this type of attack.

His DHCP security paper:

http://www.jeremiad.org/download.shtml#DHCPSecurityPaper

I'm sure it was my laptop that was the victim in the demo done for the BCS in Dundee. My laptop hasn't been the same since :-P.

Tux... just for James...

[Michael Kean]

SSL is mostly immune :)

"Although the address bar on his browser may show he is accessing bankofamerica.com, he may in fact be at an impostor website."

Fortunately SSL will alert you to this trickery :) The certificate will be invalid if the IP address of the fake site is different to the real site, and will cause some warnings to appear on the browser. However if the fake site is linked to without https, then the user might not get a warning, so I guess it depends on where the user enters the banking site. If it's from an https bookmark, they're safe, but if it's from the bank's front page, well I'm not so sure :)

[matt]

Could you protect a network from this kind of attack...

Buy blocking outbound access to dns servers? (apart from your own dns server that is)

Of course that would also break anyone's machine who was using opendns etc.

[Destroy All Monsters]

What about....

...disallowing DNS requests outgoing from your LAN to the Internet except if they come from a trusted in-LAN DNS cache, which all workstations are supposed to use? That should be fine, too.

[James H]

Holy Shiite, that sucks!

All the more reason to check the certificates. Do as I say, not as I do!

[Geoff Thorpe]

Geoff Thorpe

Someone said "the network is the computer". They probably didn't realise at the time that this also means "the network can contract the virus for you"...

[Richard Boyce]

No protection against MITM?

Could the trojan also send its own address as a gateway at the same time? Extra traffic through the infected machine, but allowing redirection of DNS or anything else?

[John Navas]

OpenDNS is not a good idea

The problem with your advice to use OpenDNS is that those two DNS servers aren't geographically separated, so are likely to both be taken out by the same unfortunate event, wiping you out. (Shame on OpenDNS.)

For reliability it would be good to use or add at least one geographically separated DNS server, as per Internet Best Practice.

[Hugh McIntyre]

Static IP addresses

Steve's linux box in the example would presumably be immune if it's not using DHCP. Only DHCP-enabled boxes seem to be broken.

Of course this may not help much for the many people using DHCP. But DHCP on a potentially hostile network is always a problem (witness the previous MacOS boot-over-airport concern); the main unfortunate difference here is that infected LAN system A can infect DHCP system B.

[tony trolle]

I have the dns set on the router

and its Open dns.

[Kanhef]

@ matt

Most people don't run their own DNS server, so blocking external ones isn't much of a solution. Setting the server may be the best and only option, as this exploits the protocol for DNS lookups. It's a good idea in general, as auto-discovered servers may not be the most responsive. After a bit of searching, I found one of my ISP's servers just 5 hops away, with a 4ms ping.

[Simon Mackay]

What can be don about this?

This attack simply is about "DNS steering" and, from what this article says, cam even affect dedicated-function devices like IPTV set-top boxes that connect to the network. What needs to happen is the ability to provide security measures for DHCP and DNS handling so end-users can verify they are associating with the right network under the right conditions. It will become more important with public networks being used to exchange highly-valuable highly-confidential information and / or having access to online media that can be at risk of being compromised.

One way would be to provide "DHCP / DNS lockdown" as part of desktop firewalls and desktop / embedded operating systems. This would only permit the client device to use approved DNS servers when in a particular network. Another step that is currently being practised in every small network is that the Default Gateway and DHCP Server functionality are handled by one device being the router. Desktop firewalls and desktop / embedded-device operating systems can declare a network as being secure if the DHCP "meal ticket" is originating from the Default Gateway.

Another technique that can be used especially for public-access networks could be to use SSL authentication on the data supplied as part of the DHCP "meal ticket". This may involve the re-engineering of the DHCP protocol to support this authentication measure but may be used for showing the trustworthiness of a network environment.

With regards,

Simon Mackay

http://homenetworking01.wordpress.com/

[bill]

Am I right in assuming...

...that this exploit is only possible if the LAN includes a Windows machine capable of being infected with the trojan? In other words, Mac/Linux-only LANs are immune to this threat?

[lucmars]

have I missed something ?

The trojan need to be installed or executed, how can it do that without exploiting a vuln ?

[Kansas City]

The heart of this attack is a rogue DHCP server

As Mr Mackay notes above, this exploit is an exploit of DHCP, not of anything else. We implicitly trust the DHCP server on any foreign network to which we connect, yet that DHCP server can give us a compromised gateway, cracked DNS server, evil DHCP offer options, and scads more dangerous things.

To my mind, there's no reason in the world to give an unvetted server (of any service) such trust. And this is the point of James Eaton-Lee's talk and paper, http://www.jeremiad.org/downloads/Why%20DHCP%20Deserves%20More%20Love%20(release).pdf, which John Thompson made reference to above.

A DHCPSEC protocol mod (like the DNSSEC protocol mod--though one hopes much more rapidly adopted than DNSSEC) is essential to preventing these types of attacks. But I don't see much work happening on this. This appears to be all of IETF's work to-date: http://tools.ietf.org/html/draft-ietf-dhc-securing-dhc-00

Yes, Rob Dobs comment to force your laptop/desktop to use OpenDNS will generally suffice to prevent a DNS hijack thru DHCP, but it's cumbersome for folks who switch around between corporate and non-corporate networks to have to swap DNS settings for each (though there are command-line and GUI tools to make this easier.)

[Chris C]

re: SSL is mostly immune

"Fortunately SSL will alert you to this trickery :) The certificate will be invalid if the IP address of the fake site is different to the real site, and will cause some warnings to appear on the browser."

Umm, no, that's not correct. SSL does literally nothing to say "this site really is this organization". As you mention, SSL simply says "this site matches this IP address". You're assuming that the rogue site would use the real site's SSL certificate instead of getting (or creating) their own.

Let's say the rogue DNS server returns 10.1.2.3* as the address for www.bankofamerica.com. If the server at 10.1.2.3 has an SSL certificate for www.bankofamerica.com, and that SSL certificate is assigned to 10.1.2.3, then your browser will accept it as valid and will not throw up any flags. So the question then becomes "Can a rogue individual get an SSL certificate for a well-known domain?" I'd venture a guess and say it's not outside the realm of possibilities.

* Yes, I know 10.1.2.3 is a private address. I only use it here as an example.

[James Troutman]

SSL certs don't work that way

SSL certs care only about domain names, not IP addresses.

If have a spoofed DNS server that points you to a different webserver IP than the real one, if your browser DNS matches the SSL cert name given by the webserver , it will be fine -- no warning by you browser, unless your browser is doing additional checks to compare to a registry of known SSL web server IPs.

The whole point of the web of trust around getting an SSL cert is supposed to prevent fraud in obtaining SSL certs for a site. But now there are many cheap SSL cert providers that don't really do much of anything for verification before issuing a cert. So fraud is quite possible, even with a seemingly valid SSL cert, if your DNS server cannot be trusted.

This white paper explains the issue: http://www.us.kpmg.com/RutUS_prod/Documents/12/DC80502.pdf

[Mike Banahan]

@chrisc

If the rogue 'secure' site serves up a certificate for www.bankofamerica.com that certificate still isn't going to be signed by a trusted Certificate Authority so the punter will get a warning pop-up. Some will probably click through so the goal will have been partially achieved.

To overcome savvy users you would need to get a rogue certificate signed by the CA. That's not going to be easy for an obvious name like bankofamerica.

However, given that you can get a server certificate for peanuts nowadays just by waving a credit card and if you go for a domain name like bnakofamerica.com (i.e. a typo) or, as Alliance and Leicester seem to do, direct to an unrelated domain name (mybusinessbank.co.uk) then it will be a lot easier to have a domain with matching and signed certificate. It takes an alert user to spot that one.

Lots of scope for tricking the punter here! This looks like a pretty nasty vulnerability.

[Anonymous Coward]

SSL cert checking

Check out the Petname tool addon for Firefox. When you visit an SSL site which you know is valid, you simply enter a name for it in the Petname field on the toolbar. This displays the name and colours the background green. If the fingerprint of the cert changes for the same domain name, you are alerted. Thus any DNS hijacking will be exposed for SSL sites (you can also check manually but this makes it trivially easy).

https://addons.mozilla.org/en-US/firefox/addon/957

[Big Al]

Now this is what I like

Clear article, problem explained, solution offered that even my 13-yr old can apply by herself.

(I agree with John Navas, but that doesn't really affect my gut reaction to the article!)

[Tim Blair]

ERRR?

opendns.org seem way on top of this kind of crap and can filter out loads of other sh*t for free (pron, nasties adware sites etc..). NO i don't work for them, just a very impressed user....

[Anonymous Coward]

I'm not clicking....

...until the Intertubes are safe!!

[Rasczak]

OpenDNS Account

If you have set up an account with OpenDNS then you can customise the error screen you get if you enter an invalid domain.

If you then set your router to use the OpenDNS DNS servers, its DHCP server to serve the Router as DNS, and log your internet IP Address against the OpenDNS account, then wouldn't that allow you to tell if the DNS was being hijacked, on your own network at least, by putting in a known invalid URL and seeing the error page that comes up. If it is not your custom page then it may well be hijacked.

Add this to setting up an OpenVPN server, for when you are on an untrusted network, which you set to act as an internet gateway to VPN clients, set the TAP/TUN network adapter to always use the OpenDNS DNS servers and you will either be safe or know you are compromised and act appropriately.

Of course this is possibly beyond your basic home user, so a real solution is still needed.

[Anonymous Coward]

Thank god we lock down our network settings...

..otherwise there will dozens of people calling tomorrow..

"I can't get in email / home folder / network resource...all I did was change my DNS to OpenDNS"

[mdubh]

@John Navas & Big Al

According to Wikipedia:

"As of August 2008, OpenDNS provides geographically distributed servers in Seattle, Palo Alto, New York, Washington, D.C., London, and Chicago."

[Robert Brockway]

@What about....

Unfortunately forcing use of trusted DNS servers will only fix a symptom of the problem. Imagine if the "dhcp trojan" started advertising itself as the default gateway via dhcp. It could do any funny business it wanted including changing data or redirecting to the wrong sites again.

[Robert Brockway]

VPN anyone?

The implication of a serious 'sploit in DHCP is broad. Essentially everyone would need to use IPSec to trust their own router - either that or always use a VPN.

Remember: "If it's not on, it's not on!"[1]

[1] This was a catchy anti-STD ad run in Australia (and perhaps elsewhere) in the early 90s.

[Matt Vernon]

Possibly a problem between keyboard and chair on my end...

... but after changing my dns addresses to those given in the article it took my PC ~20mins to boot up (stuck on applying computer settings) changed it back to our servers and back to ~30 seconds...

No Stop or flame icon because as it says in the title problem could be me!

[Gautier]

DHCP in the switch

One of the easiest solution that will not require modifications of DHCP protocol, server and client, will be to proxy the DHCP server inside the LAN switch. As the switch will be the first in the chain to receive the DHCP request, it will most probably be the first to reply. Compromising the switch seems more difficult than compromising a PC. The switch may not (or may) act as a DHCP server but will forward the request to a know DHCP server, with the Mac address of the requesting device. I realize that, as there is no authentication mechanism between the requester and the DHCP proxy, there is a theoretical possibility of DHCP high jacking if a rogue DHCP server answer faster than the Switch: But it is a very unlikely possibility and a switch level 3 may even block the DHCP request at its level. Most of the home router/switch already integrate a DHCP servers and many switches already integrate End Point Compliance protocol (NAC, NAP or EAD) linked to a Policy server: Adding a DHCP Policy server in these protocols should not be a big deal. As a quick fix, using such DHCP secured switch seems a easiest solution than DHCPSEC (even if DHCPSEC is where we should go, ultimately). SLL and OpenDNS are clearly not the solutions. It can be a non-obtrusive, optional and transparent implementation by the switch manufacturers.