Discovering Remote VPN Credentials via Public IP Phones

A recent on-site penetration test provides an interesting anecdote around the importance of physical security as it relates to network assets, as well as the importance of network segregation. More specifically, this experience demonstrates the ease with which an outsider may gain authenticated remote access to the internal network, based on nothing more than IP-based courtesy phones provided for visitor use.

The customer in this situation occupies two buildings within an office park complex. All contractors, visitors, guests, etc. are required to enter these buildings through reception areas. During business hours, these reception areas are unrestricted, but the interior connecting doors, and all other exterior doors are locked, requiring badge card access.

On Monday morning, I introduced myself to the receptionist, obtained a visitor badge, and placed a call to my point of contact, who seemed rather busy. It sounded as though I had a bit of waiting time. I noticed two voice-over-IP (VoIP) phones placed next to chairs and couches in the waiting area -- clearly intended for visitors' use. These piqued my interest, knowing that there are well-documented techniques and tools to bypass VoIP-based VLAN security restrictions. However, I didn't anticipate what I would find by simply observing traffic and browsing accessible servers.

I decided to get started with the passive assessment portion of this (authorized) penetration test. I subtly plugged a power-over-ethernet, port-mirroring switch into the exposed wall port, and connected an Asus EEE netbook running BackTrack 5 downstream of the 'mirror' port. Once I had a tcpdump sniffer session running, I quickly switched the phone's upstream ethernet cable from the wall into the switch's 'mirrored' port, allowing me to see all of the phone's network traffic. The phone rebooted upon losing and re-gaining power (via ethernet), so I was able to examine all network traffic related to the boot sequence, including the connection to a TFTP server, and firmware and configuration file retrievals. One can either reconstruct the device configuration file from the packet capture file using Wireshark, or download the file separately, based on knowledge of the TFTP server address and observed filename. Additional files may be retrieved from the TFTP server by guessing common filenames:

Enumeration of files accessible on TFTP server using Metasploit TFTPBrute module.

Manually reviewing or searching the retrieved file for sensitive or useful information, lead, in this case, to the HTTP server URL. This server was accessible from the netbook connection (an unauthenticated, public area network jack). The root page shows that the server allows directory listings -- revealing all of the configuration, firmware, and instruction files accessible from the server:

HTTP server root directory listing.

Two of the filenames in particular caught my interest: '46vpnsetting.txt', and '46vpnsetting.txt.CISCO.txt'. The first file reveals an internal VPN server address, the device username (MAC address), and other internal infrastructure servers:

Internal VPN server settings accessible on web server.

Even more damaging, the second file reveals an external (publicly-accessible) VPN server address, and the pre-shared key (PSK) used to authenticate connections:

External VPN server settings accessible on web server.

At this point it should be noted that, on many hardware IP phones, much of the information that was discovered in this case by capturing network traffic, reconstructing and viewing infrastructure communications and configuration files, can be gleaned from the phone interface itself. By simply browsing the phone's menu system, the device's IP address, gateway, DNS and DHCP servers, TFTP server, HTTP server URL, etc. are often revealed. VPN client settings may be included, but are typically protected by an 'access code'.


Unfortunately, the VPN servers revealed in this exercise were considered out of scope for the engagement, so I wasn't able to confirm these authentication credentials, nor determine to what level of access these VPN connections provide. I provided an informal briefing of this finding for the customer to investigate and remediate.

Specific recommendations include implementing a policy to the effect that visitor PCs should utilize the guest wireless network, rather than connecting to network ports (or VoIP pass-through ports), to help prevent casual observation of phone network traffic. As an additional layer of defense, network filters should restrict systems connected to the internal network without the proper VLAN ID from accessing sensitive systems, such as the voice infrastructure web server in this instance (bearing in mind, again, that this countermeasure can be bypassed). Alternatively, switch ports for compatible IP phones can be configured to require 802.1x authentication. Another solution for publicly-accessible IP phones is the implementation of a separate DMZ network, whereby these relatively untrusted network clients are permitted access only to the required data signalling, media streaming, and infrastructure ports of specified servers. For high-security environments, consider utilizing physical tamper-prevention products such as Panduit Lockin and Blockout devices, to restrict removal and insertion of network cables, respectively. Also consider disabling network ports upon detection of a disconnected network cable, and generating and alerting on logs related to these events.

Tools and Techniques for Assessing Authenticated Web Services

A web application security assessment that I recently performed included a web services component. These web services existed to provide equivalent functionality to non-browser-based client applications, as well as administrative functions for authorized users. To thoroughly test this portion of the application would require tools tailored to web services, with two qualifications beyond what I'd required from software tools used in previous web service assessments:

• the web service was hosted only over an SSL-encrypted, HTTPS connection; and
• traditional, cookie-based authentication tokens were required to interact with most of the web service methods.

Several tools that I've previously utilized were outdated and not capable of meeting either or both of these requirements - namely, WSFuzzer (version 1.9.5 released September, 2010); and WebScarab (version 20070504 from May, 2007). Several alternative options exist, fortunately.

WSDigger, from Foundstone, includes discovery and audit functionality via built-in attack plug-ins, but has not been updated in several years, and is not natively capable of HTTPS connections. However, by configuring an SSL tunneling proxy such as stunnel to listen on the local loopback interface, and redirect connections to the web service, WSDigger can be used to interact with the target web service. The 'WSDL' and 'Service URL' fields should be populated with the stunnel listener's local address and port, via HTTP; this connection is then forwarded to the web service over an HTTPS connection, and requests the path specified in the 'Service URL' field.

The 'Get Methods' button successfully retrieved the web service methods, such as 'SaveUserToAddressBook', 'InsertNewUser', 'SendDICOM', etc.

WSDigger can connect through a local web proxy application, such as Burp Proxy, using the local system proxy settings.

A call to the 'GetWeatherReport' method, specifying a 'ZipCode' string, is captured in a local proxy as an XML SOAP request.

WSScanner is a similar tool with discovery, vulnerability scan, and fuzzing components, in addition to acting as a SOAP proxy. Although WSScanner claims to support HTTPS URLs, my experience indicates otherwise. The tool does not provide built-in support for passing authentication credentials, using system proxy settings, or otherwise configuring connections through a local proxy.

The stratsec Web Method Search tool, used to enumerate unpublished web service methods, is able to interact with SSL-encrypted web services, and can also be configured to use a proxy.

A default list of verbs and nouns used in requests to guess method names.

The Metasploit Framework includes a similar SOAP verb/noun brute-force scanner, which is capable of SSL connections.

SoapUI, one of the most full-featured tools to interact with and test web services, can interact with HTTPS-based services.

The 'Authenticate Preemptively' option instructs the application to send specified HTTP Basic credentials with each request, providing a way to authenticate with web services that support this mechanism.

The 'Proxy Settings' option allows the user to pass requests and receive responses through a local web proxy application as well.

However, when attempting to access HTTPS-based services using a local proxy, soapUI returns a generic error message, due to the untrusted SSL certificate presented by the local proxy. Unlike with a web browser, there is no apparent way to ignore or override this error.

By starting stunnel once again as an SSL redirector, configuring soapUI to connect to the stunnel listener via HTTP, and passing these connections through the local web proxy, we can view and modify requests and responses to and from the target HTTPS-based service.

Finally, we can utilize the soapUI TestCase option 'Maintain HTTP Session', if the service supports authentication via HTTP Basic credentials.

Alternatively, in the case that the target service requires cookie-based token authentication, we can manually authenticate using a web browser (e.g., submit credentials to a login form), and examine the cookie value(s) set by the service to maintain an authenticated session state, using the local proxy. Then, configure Burp Proxy to automatically modify future requests to the stunnel listener, adding the required Cookie header and values.

Subsequent requests from the soapUI application will be modified by the intercepting proxy to include currently-authenticated sesion token values, forwarded to the local stunnel listener, and redirected to the target HTTPS service. Responses, conversely, will be received by the stunnel listener, converted to plaintext HTTP, forwarded to the intercepting proxy for viewing and/or modification, and ultimately received and displayed by soapUI.

Though slightly convoluted, this method of chaining an intercepting web proxy and SSL tunneling proxy allows us to interact with and test HTTPS-based, authentication-required web services, using a robust testing tool.

An alternative, ultimately-customizable solution is to script a simple web service client -- using, for example, Ruby's SOAP::WSDLDriver class. This script can be written to connect through a local proxy, thereby providing request modification, fuzzing, and authentication capabilities, and can log requests and responses to a local file for further analysis.

WiFi Protected Setup PIN Brute-force Vulnerability Stats

Late last year, Stefan Viehböck published a blog post and paper detailing a significant design flaw in the WiFi Protected Setup (WPS) standard, specifically affecting the external registrar PIN authentication method. This flaw can be abused to brute-force the PIN value, and thereby extract the WPA(2) pre-shared key (PSK) used by an affected wireless router. (The vulnerability was independently discovered by Craig Heffner also). I was interested in learning more about the extent of this issue -- getting a grasp on how many wireless devices may be vulnerable to this type of attack.

Many have speculated about the ubiquity of vulnerable devices, with some outlets simply stating that "most" routers are vulnerable. In the interest of more specific and accurate figures, I took a scientific approach, based on gathering the information broadcast by nearby wireless devices. Focusing on SOHO wireless routers, which are most likely to implement the WPS standard, I scanned my neighborhood surroundings in Austin, Texas -- a fairly dense, urban area composed mainly of residences, with scattered small businesses and office buildings.

Dan Kaminsky undertook a similar survey a few weeks ago, using data gathered in Berlin and compared against Wigle's online database to extrapolate that "26.3% of APs with crypto enabled exposed methods that imply vulnerability to the WPS design flaw... suggests at least 4.1M vulnerable hosts".

Using the Wigle WiFi active 802.11 scanner for Android (discussed in a previous post) to identify and enumerate basic information broadcast by wireless networks in an approximately 3 mile radius, I arrived at slightly higher numbers. The numbers below suggest 27.1% of the APs support WPS:

$ cat WigleWifi_20120102134243.csv | grep WIFI | wc -l

71046

$ cat WigleWifi_20120102134243.csv | grep WIFI | grep -v -i wps | wc -l

51789

$ cat WigleWifi_20120102134243.csv | grep WIFI | grep -i wps | wc -l

19257

A more interesting and meaningful number is the percentage of WPA(2)-enabled devices supporting WPS (since unencrypted and WEP-enabled devices can be easily compromised through other attacks):

$ cat WigleWifi_20120102134243.csv | grep WIFI | grep -i wpa | wc -l

37985

This figure indicates that 50.7% of the wireless devices otherwise (likely) well-protected by WPA-based security advertise support for WPS.¹

Now the question becomes -- of these 50% of WPA-enabled devices that support WPS, what portion are vulnerable to a brute-force PIN guessing attack? Because support for the PIN method is mandated for WPS-certified products, nearly all devices advertising WPS capabilities should allow PIN authentication.

In search of empirical data (albeit a very limited data set), I initially tested a variety of devices myself. In doing so, I was able to learn greater details about the attack, how software to exploit the issue works, and how to defend against it.

I tested a spare router that supports WPS, and four others belonging to friends and neighbors (with their permission, of course). It goes without saying that my sample set of five devices is insufficient to draw meaningful conclusions from. Having said this, I was surprised by the varied results. I used several software tools to test for this vulnerability -- Viehböck's 'wpscrack', and the previously-commercial, now open-sourced 'reaver' were used to brute-force guess PIN values; the 'wps_tools' wpscan and wpspy were useful for enumerating WPS-capable routers, and monitoring changes in a target network's state (such as locking). Results were as follows:

• D-Link DIR-615, hardware version B2 -> not vulnerable due to WPS lock implementation that activates after approximately 60 failed PIN attempts, and requires a system reboot to unlock²;
• Cisco Linksys WRT320N -> seemingly not vulnerable due to repeated "WPS transaction failed (code: 0x2)" messages (Reaver), indicating an "Unexpected timeout or EAP failure";
• D-Link DIR-625, hardware version C2 -> vulnerable; PIN successfully cracked in approximately five hours;
• Netgear N150 WNR1000, version 3 -> vulnerable to a DoS condition, but not PIN discovery -- repeated PIN attempts resulted in the router ceasing to provide connectivity; a hard reboot was required to restore service;
• Cisco Linksys E4200 -> vulnerable; PIN successfully cracked in approximately four hours.

Demonstrating use of the 'Reaver' tool to brute-force guess the PIN value, and extract the network's pre-shared key.

Two out of five devices tested vulnerable to PIN discovery; one of five vulnerable to DoS.

Of course, significantly more results were desirable, and while the crowd-sourced test data submitted to the 'WPS Vulnerability Testing' Google document created by jagermo on January 2nd initially seemed inconsistent and confusing, the results are becoming more clear. Testing results and direct submissions from some vendors (Cisco, D-Link) have been incorporated into the document, lending additional credibility and accuracy to the results.

Aggregated entries submitted to this point, viewable at the response summary page show that 79% of submissions identify the WPS PIN method enabled by default, and 64% indicate a device vulnerable to the WPS attack. An additional 16% indicate a device 'maybe' vulnerable. (Whether devices that experience a DoS condition as a result of the attack, but do not disclose the PIN value should be considered 'vulnerable', 'maybe', or 'not' in this taxonomy is unclear.)

Whether we use the very conservative 20% figure arrived at in my small-scale testing (50% of discovered routers supporting WPS * 40% vulnerability rate in five tested routers) or the 64% figure from crowd-sourced data (keeping in mind a possible reporting bias), extrapolation based on Wigle's mapping project data suggests that millions of devices have been recently identified as vulnerable.

Disclosure of this weakness has changed the SOHO wireless security world for some time to come -- until device vendors issue firmware updates, customers update their devices, old and vulnerable routers are replaced, and/or a new Wi-Fi Simple Configuration Specification (WSC) is released addressing this design weakness.



1 – Results from a larger dataset -- Wigle scanning results over the past 18 months, covering much wider and more diverse areas, including business districts and office environments -- produce similar statistics: 28.0% of all 71,046 APs, and 49.2% of WPA-enabled devices support WPS (back to post)
2 – Router logs recording failed authentication attempts and activation of lock state as follows:

...

[INFO] Sat Jan 13 13:02:09 2012 Wireless system with MAC address 00401B0323D0 associated

[INFO] Sat Jan 13 13:02:11 2012 Peer configuration error 0

[WARN] Sat Jan 13 13:02:11 2012 AP failed to registere to Registrar () through EAP reason (input fail) err code (3)

[INFO] Sat Jan 13 13:02:12 2012 Wireless system with MAC address 00401B0323D0 associated

[INFO] Sat Jan 13 13:02:12 2012 Wireless system with MAC address 00401B0323D0 disconnected for reason: Received Deauthentication.

[INFO] Sat Jan 13 13:02:13 2012 Wireless system with MAC address 00401B0323D0 associated

[INFO] Sat Jan 13 13:02:13 2012 Wireless system with MAC address 00401B0323D0 disconnected for reason: Received Deauthentication.

[WARN] Sat Jan 13 13:02:14 2012 Lock AP setup

[INFO] Sat Jan 13 13:02:14 2012 Peer configuration error 0

[WARN] Sat Jan 13 13:02:14 2012 AP failed to registere to Registrar () through EAP reason (input fail) err code (3)

[INFO] Sat Jan 13 13:02:15 2012 Wireless system with MAC address 00401B0323D0 associated

[INFO] Sat Jan 13 13:02:15 2012 Wireless system with MAC address 00401B0323D0 disconnected for reason: Received Deauthentication.

[INFO] Sat Jan 13 13:07:47 2012 Wireless system with MAC address 00401B0323D0 disconnected for reason: Received Deauthentication.

...

(back to post)