kaminsky's DNS bug + Rogue CA Certificates = Trust No One

If there has been any missing part in most of the previous clever and sophisticated phishing attacks, it would be a valid SSL certificate signed by a valid CA.

Recently, a smart group of cryptography researchers have successfully exploited a bug in the MD5 hashing algorithm that allows them to hack VeriSign's RapidSSL.com certificate authority and create fake digital certificates for any Web site on the Internet.

I won't talk about their findings here; you can check it out here: http://www.win.tue.nl/hashclash/rogue-ca/

Today I'll draw the attention to a couple of possible attack scenarios that Phishers and malware authors can use by combining techniques that would be very difficult to stop unless a number of defenses is being used against.
The techniques of this attack are:

1) DNS Cache Poisoning Attack (For directing victims to fake sites like banks)

2) SQL injection Attack (For injecting IFrame redirectors into high traffic website, to redirect visitor to the fake website)

3) Double Flex Network (botnet) that would host malicious name servers (malicious/phishing websites resolution) and webservers (host the malicious/phished site)

4) Rouge CA SSL Certificates (For fooling victims who are visiting a website that is secured by using a valid SSL certificate, and the browser is showing a padlock indicating that it's a safe and legitimate website)

So, hackers have multiple targets to meet to launch a perfect attack. Well, the first three techniques are being used nowadays, but were lacking a very important member in the crew, Trust.

Before, nobody was able to break the trust rule and build a complete, flawless phishing attack. Now they can generate any valid certificate and make their phishing bank websites appear legitimate and secure. End user who is dealing with secure online transactions will be comfortable when he sees the padlock and there are no warning signs about website identity.

Countermeasures for (Website Admins):

1) Replace MD5-based SSL certificates, with SHA-1 certificates because they are more secure.

2) Use Extended Validation certificates (EV).

Countermeasures for (CA):

1) Stop issuing MD5-based SSL certificates, and replace them with SHA-1 certificates

2) Encourage customers to replace their MD5-certificates with SHA-1 certificates

3) Encourage customers to upgrade their certificates to Extended Validation (EV) for more security. See http://www.verisign.com/ssl/ssl-information-center/extended-validation-ssl-certificates/

4) Monitor "Certificate Signing Requests" by the same user in quick succession

5) Add randomness to the certificate fields, like the serial number field.

Countermeasures for (Users):

The basics:

1) Padlock appearance is not enough, you should move on with other ways to make sure your visiting the legitimate and secure website.

2) Upgrade your browser to the latest version (IE 8 / FF 3 / Opera 10) to use their built-in anti-phishing capabilities.

3) Install good endpoint security software to stop malwares, and make sure it's updating definitions daily. The latest versions includes online security features like (Norton Internet Security 2009 and Kaspersky Internet Security 2009)

4) Install Windows patches and service packs to stop malwares and online attacks from exploiting any vulnerability in your system.

5) Install and updates all ActiveX components in your browser by upgrading the original software (ex. PDF reader ActiveX, you should upgrade Adobe Reader. Real player embedded ActiveX; you should upgrade RealPlayer…and so on). You can use Secunia Personal Software Inspector (PSI) to scan your system for insecure softwares and utilities.

The Advanced:

If you want to do any online transactions, use Authentium’s SafeCentral to create a secure session between a locked-down browser and your online bank. It has capabilities to defend against the following attacks: Keyloggers, Spywares, DNS poisoning, Malwares, Sniffing, Man-in-the-middle

Visit their website: http://www.safecentral.com/

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:

Use default passwords, get hijacked !