Endpoint Protection

Following Dan Kaminsky’s research on DNS insecurities, we saw attackers racing with their DNS servers to hijack network connections. It was only a matter of time before the bad guys decided that racing against DNS was not enough.

DHCP is a widely used network protocol that has been around for a while—it’s used to automatically assign IP addresses on a local network. When you connect your laptop on the wireless router at your home or to your office network, it is most likely that a DHCP server assigns an IP address to your machine and will provide all of the important parameters such as a gateway IP and DNS servers. The DHCP protocol is simple, transparent, and efficient for end users, but it is also non-secure. There’s nothing new and sensational in that statement, because it’s something well known and is really just a lack of authentication. Wikipedia has a pretty good description of common DHCP attacks.

 

“Having been standardized before network security became a significant issue, the basic DHCP protocol includes no security features, and is potentially vulnerable to two types of attacks… (1) Unauthorized DHCP Servers… (2) Unauthorized DHCP Clients…”

The “Unauthorized DHCP Servers” attack is the main topic of this blog, and the real (bad) news is that today we found malicious code in the wild that actively uses this attack, with the aim of hijacking the DNS configurations of other machines on the same local network. The malicious code is named Trojan.Flush.M.

The idea is simple and evil at the same time: a Trojan installed on an infected machine runs a rogue DHCP server on the local network and serves bogus DHCP packets to other machines when they request a new IP configuration. If the Trojan is fast enough in sending out these DHCP packets, with some luck it can modify the network configuration of other computers. The basic principle of this attack is also described in this Wikipedia article.

 

The above network capture shows in detail what’s happening on a network with only a single machine (address 192.168.91.129) infected with Trojan.Flush.M. When a second, clean, machine (address 192.168.91.132) is renewing its IP address (e.g., ipconfig /release and ipconfig /renew on a Windows system) it sends a DHCP RELEASE packet and then tries to discover the DHCP server to get the new IP configuration. The configuration requested will have all the vital information that any device (PC, Mac, Smartphone, etc.) needs to access Internet, including the address of DNS servers.

On a clean network we should only see one DHCP OFFER packet sent from the legitimate DHCP Server (192.168.91.254) to the clean machine. This packet is showed in the above capture at entry number 7. However, as shown in the capture, there’s another DHCP OFFER packet (at number 3) that has been sent by the infected machine only a moment earlier. The following diagram provides a clearer picture of what’s happening on this network:



The packet sent by the infected machine arrives first; therefore, it wins the race against the real DHCP server and the clean machine ends up getting the following IP configuration:



Clearly, the IP configuration of the clean machine 192.168.91.132 (which is still clean and is not infected by any kind of threat) has been assigned remotely by the infected machine and now includes some well-known rogue DNS servers: 85.255.112.36 and 85.255.112.41.
 
Performing an Internet search for these DNS servers leads only to bad comments and results, mostly related to a known family of DNS “changer Trojans,” which include Zlob and the recent Mac OS X threat OSX.RSPlug.A. Once the DNS servers are modified, the attacker can redirect a machine to any malicious or phishing website (for example, you type “www.symantec.com” and your computer brings you to the “6.6.6.6” host).

Some interesting facts of this curious DNS pharming attack include:

•    A single infected machine with this Trojan can virtually compromise the DNS configuration of all other machines in the same network without infecting them.
•    It is difficult for the clean machine to identify if DNS servers in use are legitimate or not (the DHCP server shown in the example is still valid and the machine is not infected).
•    There’s no registry setting or configuration file that is modified on the machine—the attack relies on network protocols.
•    These malicious DHCP packets could affect any device connected to the compromised network, so even a smartphone or Mac could accept the bogus configuration and start using rogue DNS servers.

Since this is a race between the legit DHCP Server and an infected machine running a rogue DHCP Server, it all depends on luck and speed. We noticed that the attack is not always successful; sometimes the DHCP Server packet arrives first and so everything goes fine.

To detect this attack, administrators should scan their traffic for bogus DHCP offer packets coming from a machine that is not the DHCP server. As final note, the attack has been reported in the wild and as suggested by a friend at ISC SANS, network administrators should monitor and/or block traffic on: 85.255.112.0 – 85.255.127.255.

Thanks to my colleague Marian Borucki for help during the investigation of this threat.