Saturday, June 23, 2012

Vetting Devices with PowerShell & CVE-2012-1838

A few months ago, I set out to replace an old Cisco switch with a managed gigabit switch. I settled on a 24-port LG-Nortel managed switch because it supported port mirroring, VLANs and costs under $200. Before I introduced the switch to my lab network, I decided to practice what I preach and vet the device.

The first step was to read the manual and find out how the manufacturer recommends to configure the switch and more importantly secure it.  The manual is available here, but I will be referencing relevant sections with screenshots. According to the documentation, the only way to manage the switch is through the web interface:

It is extremely disconcerting that an enterprise networking appliance would allow management over an unencrypted port, but for it to be the only way to remotely manage the switch is shocking. Also, we will definitely want to change the default password, but for now lets focus on that note. That statement leads me to believe that the authentication and session management is fixed (probably by IP address) which could be a vulnerability. If proxies are used or admins share IPs or workstations with normal users, this condition could possibly be exploitable. Sometimes an attacker can find a way in just by reading the manual.

Another interesting thing that I noticed in the manual was a reference to SNMP which was not listed as a feature of the switch in any other documentation:

The next step was to scan the switch to see if there were any other listening ports besides TCP 80.  There appeared to be no surprises except for the aforementioned SNMP on UDP 161 was not listening.

Since security was apparently not a part of the development life-cycle, I kept digging. The next step was to ensure that the switches firmware was updated. I verified that it was and downloaded the latest version for analysis. I whipped up a PowerShell function for extracting strings from binary files, (it pales in comparison to the Sysinternals Strings utility) and extracted all lines containing "htm":

After a bit of cleaning up, we now have a solid list of directories and files that we can check for without authenticating. I have used this simple process successfully many times and it will yield better results than a web scanner with a generic dictionary would.

Next, we need a way to check to see which are valid files and paths.  Get-HttpStatus is a PowerShell function to do just that:

Get-HttpStatus Function

Armed with our dictionary and Get-HttpStatus, lets see what status codes are returned from the switch without authenticating to it:

We have lots of results, so the authentication mechanism used by the switch is obviously broken. The following URLs disclose nearly the entire configuration of the switch and are classified as information disclosure:

Information Disclosure URLs

From an attacker's perspective, there are several more interesting URLs that are accessible without authentication:

Potentially Exploitable URLs

The first in the list seemed really promising:
Unfortunately, the switch returns an error when you hit the apply button. Lets look at another of the files and see if there is an easier way to compromise the switch without authenticating.

This page contains an area for uploading and downloading the switch configuration.  Downloading the current configuration could be very handy and in this case its aided by the fact that the single admin password is stored in a plain-text string:

Now we can change the password with a hex editor and upload the altered configuration without ever authenticating!
The attacker could then log into the switch with the password that they placed in the config file.

So how do we secure this obviously vulnerable switch or is it hopeless? We can start by ignoring the manual:
Since you have to leave one port as a member of VLAN 1, designate one as the "admin" port and put every other port in a different VLAN. Use the "admin" port to configure the switch (VLANs, port mirroring for your IDS, etc...) and then remove the cable or plug it into a completely out-of-band admin network. You won't be able to remotely manage the switch, but hopefully neither will anyone else.  It is possible to secure vulnerable systems if you know what the vulnerabilities are and mitigate risk effectively.

I also verified that the switch maps an IP address to an authenticated session for exactly 5 minutes.  Even if you log out, the switch will allow anyone using the previously authenticated IP to connect as the administrative user for the remainder of the 5 minutes. The results above were discovered using an IP that had not been used to log in to the switch.

These vulnerabilities (lame as they are) were disclosed through the US-CERT (since LG gave me the run-around for several weeks and Nortel didn't respond either) and were assigned CVE-2012-1838.  The advisory was released early because LG has decided that they are no longer supporting this or similar models of switches.


Monday, June 11, 2012

SHA-1 Password Cracking

In the last week, there have been several major compromises resulting in the leak of password hashes to the internet.  Some of the major sites that were hit are Linkedin, Eharmony and Although there are many others that have cracked more than I have or will, armed with an older video card and an extra laptop I was able to crack around 3 million of the exposed SHA1 hashes utilizing Hashcat,  John and dictionaries that I have collected over the years.  The professionals at KoreLogic tweeted this within a day of the hashes being released:

If you would like to safely check to see if your password was included in the Linkedin compromise, you can download the file "combo_not.txt".  I believe it is probably still being hosted in a few places but you'll probably have to do a bit of searching to find it.

I threw together a PowerShell function for others to check to see if their passwords were included.  It is horribly slow and could definitely be improved, but I don't think it will be useful for long.  I really don't like the idea of utilizing any online look-up services (despite the obvious speed benefit from storing the data in a true database) because of the obvious social-engineering implications.

A special version of Hashcat was released to handle the zeroed hashes which paired with a large dictionary is very effective:

The Hashcat syntax can be tricky, but there is a lot of great documentation out there.

Next, I reran the same dictionary with a mangle rule in John which got quite a few of the longer passwords due to the 15 character limitation imposed by CudaHashcat.  There are lots of usage guides and cheat-sheets out there for John.

The final result was over 3 million hashes cracked in less than 24 hours. KoreLogic has been able to crack 4.92 million in just a few days so it seems that very few of the original passwords are safe: 

I recommend using the publicity around these major breaches to remind your managers, users, friends and family about passwords.  The following is what I try to stress, but there are certainly lots of other great ideas on how to improve password security:

1. Never reuse passwords between web sites or systems.
2. Change your passwords as often as its reasonable.
3. Choose longer passwords such as  (complex) passphrases to increase the difficulty of cracking.
4. Have a plan to quickly and securely change your passwords if they become compromised.
5. Consider a common password manager for web sites.
Finally, since there aren't public details as to how Linkedin was compromised, its safe to assume that they are still compromised or could be again.  Take that into consideration when you are planning on how to change your passwords.  Even if Linkedin takes steps to properly salt the hashes, its not unreasonable to think that they could be quickly cracked again.

***Update 16 June 2012***
Changed the name of the function to be inline with the PowerShell way.  Changed the way to the password is read in to be more secure as requested by the first comment below.