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.
http://192.168.2.10/system/cfgload.htm
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.
-Chris