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.