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 Functionfunction Get-HttpStatus { <# .NAME Get-HttpStatus .SYNOPSIS Returns the numeric HTTP Status Code and full URL for specified paths. Author: Chris Campbell (@obscuresec) www.obscuresec.com License: GNU GPL v2 .LINK http://obscuresecurity.blogspot.com .SYNTAX Get-HttpStatus -Target <string> -Path <string> [<CommonParameters>] .DESCRIPTION A script to check for the existence of a path or file on a webserver. .PARAMETERS -Target <string> Specifies the remote web host either by IP or hostname. Required? true Position? 1 Default value 127.0.0.1 Accept pipeline input? false Accept wildcard characters? false -Path <string> Specifies the remost host. Required? true Position? 2 Default value $pwd\dictionary.txt Accept pipeline input? false Accept wildcard characters? false <CommonParameters> This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type, "get-help about_commonparameters". -------------------------- EXAMPLE 1 -------------------------- C:\PS>Get-HttpStatus -Target www.example.com -Path c:\users\obscuresec\desktop\dictionary.txt | Select-Object {where StatusCode -eq 20*} .Description ----------- This is a PowerShell script to return the HTTP status codes for paths or files in a dictionary. It does not properly return errors. Status Codes: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html HTTP Codes: 100 - Informational * 200 - Success * 300 - Redirection * 400 - Client Error * 500 - Server Error #> param( [string] $Target = '127.0.0.1', [string] $Path = "$pwd\dictionary.txt" ) #function to test connectivity to root of target site function HttpCheck { $TcpConnection = New-Object System.Net.Sockets.TcpClient try { $ConnectionResult = $false $TcpConnection.Connect($Target, 80) $ConnectionResult = $TcpConnection.Connected } catch { $ConnectionResult = $false Write-Error "Connection Test Failed - Check Target" } finally { $Tcpconnection.Close() } } #function to return the HTTP status code of the expanded URL function HttpStatus { param( [string] $TargetUrl ) try { $WebTarget = "$TargetUrl" $WebRequest = [System.Net.WebRequest]::Create($WebTarget) $WebResponse = $WebRequest.GetResponse() $WebStatus = [int]$WebResponse.StatusCode Write-Output "$WebStatus `t $WebTarget" $WebResponse.Close() } catch { Write-Output "400 or 500 `t $WebTarget" } } #Function using Foreach to Pipe contents of dictionary into HTTPStatus function function ExpandDictionary { try { foreach ($Item in Get-Content $Path){ $TargetURL = "$WebRoot/$Item" HttpStatus $TargetURL } } catch { Write-Output "Dictionary Expansion Failed" } } #assign variable $WebRoot = "http://$Target" #run check function HttpCheck #run path function and sort $ScanResults = ExpandDictionary $SortedResults = $ScanResults | sort Write-Output $SortedResults }

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 URLshttp://192.168.2.10/dot1x/dot1x.html http://192.168.2.10/dot1x/dot1xstat.html http://192.168.2.10/igmps/igmpconf.html http://192.168.2.10/igmps/igmpstat.html http://192.168.2.10/ports/ports_bsc.html http://192.168.2.10/ports/ports_config.html http://192.168.2.10/ports/ports_mir.html http://192.168.2.10/ports/ports_rl.html http://192.168.2.10/ports/veriphystat.html http://192.168.2.10/qos/qos_conf.html http://192.168.2.10/rstp/rstp.html http://192.168.2.10/rstp/rstpstatus.html http://192.168.2.10/security/security.html http://192.168.2.10/security/security_acl.html http://192.168.2.10/security/security_port.html http://192.168.2.10/status/status_ov.html http://192.168.2.10/status/status_stats.html http://192.168.2.10/system/system_cntconfig.html http://192.168.2.10/system/system_ls.html http://192.168.2.10/system/system_name.html http://192.168.2.10/system/system_smac.html http://192.168.2.10/system/system_smac_setup.html http://192.168.2.10/system/system_upok.html http://192.168.2.10/trunks/lacp.html http://192.168.2.10/trunks/lacpstatus.html http://192.168.2.10/trunks/trunks_config.html http://192.168.2.10/trunks/trunks_mem.html http://192.168.2.10/trunks/trunks_rl.html http://192.168.2.10/vlans/vlan_mconf.html http://192.168.2.10/vlans/vlan_pconf.html http://192.168.2.10/vlans/vlan_setup.html

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

Potentially Exploitable URLshttp://192.168.2.10/snmp/snmp.html http://192.168.2.10/sysreboot.html http://192.168.2.10/system/cfgload.htm http://192.168.2.10/system/system_config.html http://192.168.2.10/system/system_configfrm.html http://192.168.2.10/system/system_pswd.html

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

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.

-Chris