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:
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:
So how do we secure this obviously vulnerable switch or is it hopeless? We can start by ignoring the manual:
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.