Friday, December 19, 2008

DNS Chanager 2.0


DNS Changer 2.0 (Trojan.Flush.M) is the next –in the wild- variant of this famous malware. Now the strategy has been changed, no need to modify the DNS settings on ADSL routers. Instead it will install a network driver (NDISProt.sys) which allows the malware to send/receive raw Ethernet packets. Such approach will help it bypass Windows TCP/IP, FW and HIPS.

It installs a rogue DHCP server on the infected machine and listens for DHCP requests and responds with its own crafted DHCP offer packets. The reply contains malicious DNS servers, which will redirect hosts to infected websites that include everything from phishing to exploit-and-infect pages.

The question is how to protect and prevent such attacks. Here is my compiled checklist:

1) As always, keep your systems up-to-date and make sure you are using/deployed the latest browser (IE 7/8, FF 3, Google Chrome, and Opera 10) in your network. Because it's always start from exploiting your old browser and process with the rest of the attack.

2) Make sure your antivirus is prepared to detect and block this malware. If you detect any suspicious process which listens on port 67, you can upload it your vendor or use virustotal.com.

3) If you are a Cisco shop, you are lucky enough because they have implemented a built-in security mechanism called "DHCP Snooping", is a DHCP security feature that provides security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding table. Read more about it.
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/12ew/configuration/guide/dhcp.pdf

This is an example of enabling DHCP Snooping on a Cisco Switch:

switch(config)# ip dhcp snooping
!Enables DHCP Snooping globally!
switch(config)# ip dhcp snooping vlan {,}
!Enables DHCP Snooping for Specific VLANs!
switch(config-if)# ip dhcp snooping trust
!Sets the interface to trusted state; can then pass DHCP replies!
switch(config-if)# ip dhcp snooping limit rate
!Sets rate limit for DHCP Snooping!


4) Use " DHCPLOC Utility" to detect rogue DHCP servers on your network, Get it from here (http://technet2.microsoft.com/windowsserver/en/library/8fa42e83-ec08-4a9b-9057-8909f7ed433e1033.mspx?mfr=true)

With this tool, you can determine which DHCP servers are available to a DHCP client and to detect unauthorized DHCP servers on a subnet.


5) Use " DhcpExplorer" , it’s a tool that allows you to discover DHCP servers on your local subnet or LAN. This is useful for locating servers that are not supposed to be on your network (rogue DHCP servers) as well as checking the expected output of known servers. The tool is designed with a user-friendly interface and is easy to use. Download it from here:
http://www.filesland.com/companies/Nsasoft-LLC/download/DhcpExplorer.exe

6) Use " DHCPing", it is a simple utility, like ping, except it tests for running DHCP servers. The results of a dhcping scan can be matched against a list of known DHCP servers on your network. Anything showing up in the scan, and not on your server inventory, should be suspect. Get it from here: http://www.securiteam.com/tools/5TP0G0KDFG.html


7) If you are a Microsoft shop, make sure that you have configured authorized DHCP server correctly, read here for more details:
http://technet.microsoft.com/en-us/library/cc781697.aspx


8) If you use Nmap, and you should by the way. You can scan your network for hosts that listen to port 67. See this example:

nmap -sU -P0 -p 67-68 -oN dhcp-scan-results > 192.168.0-3.*

Replace 192.168.0-3.* with your network's IP range.


9) Snort, is your watch dog while you are busy. Modify your snort.conf file to add a new servers list, like this:

var Authorized_DHCP [1.1.1.1,2.2.2.2]

replace 1.1.1.1, 2.2.2.2 with your production servers

And use this rule to detect rogue dhcp servers:

alert udp !$AUTHORIZED_DHCP 67 -> 255.255.255.255 any (msg: "Rogue DHCP Server OnNetwork"; sid:1000001;)


10)If you have tcpdump around, you can run and use this Bpf filter to detect rogue dhcp servers:

tcpdump -i eth0 -nn 'udp port 67 and !(host x.x.xx or host x.x.xx)'

11)And last, double check with your host-based firewall vendor that their product dose support NDIS-level firewalling. This means the FW will protect against unauthorized NDIS protocol registration by hooking NdisRegisterProtocol()/NdisOpenAdapter(). So, the FW will be notified when a NDIS protocol is trying to be registered or when it’s binding to some adapter.


Related Posts: