VoIP Provider Toll Fraud Attempts

I received an automated email this morning from a VoIP service provider, informing me that:

We received a request to reset the password for the account <account_name> from the IP address 41.76.XXX.XXX but the security question entered was invalid.
As a security precaution we have set your accounts password to: <new_password>
Once you have logged in you will be prompted to change your password immediately.

My first reaction was that this was an attempt to conduct toll fraud using hosted accounts with weak passwords. Toll fraud is one of the largest threats to VoIP systems, and all-too-easy to perpetrate in many instances.

I immediately accessed my account from the web portal to change the new password. This account can be used to incur charges against my balance, or potentially using stored payment information; it should not be protected only with a password that has been sent via email. (not to mention that the newly-set password was weaker (shorter and less complex) than I would like)

Upon login, the provider offered this small bit of additional information:

A large scale scan attack was attempted last night around 1am on our portal logins, therefore you may have received an email with a new password. We apologize if this has inconvenienced you.

The sequence as described seems incongruous:

• large-scale (automated) attempts to reset the password for numerous accounts;
• security question serving its purpose by preventing the attack; yet
• the provider resets all affected (targeted) account passwords.

I certainly appreciate that they take this activity seriously, but their handling of the situation strikes me as the knee-jerk reaction of an incident response team that does not know the full extent or details of the attack, and does not have a formal incident response plan in place. The incident response team should be able to identify which accounts were identified / targeted, for which accounts the security question successfully guessed, which accounts (if any) had their password reset, and which accounts were maliciously accessed. Based upon this information, they can respond accordingly. A simple attempt to reset the password, prevented by the security question, is the type of attack that occurs every single day, and should not require resetting the passwords (in an insecure fashion) of all targeted users.

As for the attack itself, several factors make this provider's web portal susceptible to (and an attractive target for) such attacks:

• no CAPTCHA requirement for login or password reset attempts (initially or for repeated attempts);
• server responses allow attackers to harvest valid account names by differentiating between valid and invalid username submissions. For example:

The account 'nosuchaccount4563' was not found or has been disabled.  

I haven't seen any additional communications from the provider via email, Twitter, etc. No mention of two-factor authentication options on their website. I'm tempted to take my business to different provider with better security practices, but I've had great success with this provider in (authorized) "war-dialing" modem security assessments. As detailed here, I've been able to use up to 30 concurrent outbound lines to dial a massive number of DID lines in a short period of time. So for my part, I've re-set a strong password, ensured that auto-replenishment is disabled for my account, and configured the account to deactive upon balance depletion, limiting the financial impact of a successful attack. From the provider side, here are some useful tips from a company thinking proactively about defense.

IPv6 Scanning via Mobile Network Hotspots

On several occasions, I've had a need to run quick, small-scale network scans of externally-accessible IPv6 systems. While it's never been easier to set up a tunnel on a hosted system, or, better yet, rent a system from a provider offering native IPv6 connectivity, I was interested in running these scans with minimal setup, and from a local laptop, without the need to connect to an external system.

I recently enabled the mobile hotspot feature on my Android phone, and noticed that when connecting through this hotspot the wireless interface on my laptop receives a global IPv6 address, in addition to a link-local scope address and IPv4 address. For example:
$ ifconfig wlan0
Link encap:Ethernet  HWaddr 00:27:10:12:4d:10
inet addr:192.168.34.42  Bcast:192.168.34.255  Mask:255.255.255.0
inet6 addr: fe80::227:10ff:fe12:4d10/64 Scope:Link
inet6 addr: 2600:100c:b034:39ae:227:10ff:fe12:4d10/64 Scope:Global

I decided to check out the capabilities of this connection, in terms of outbound connectivity, speed, reliability, and filtering or otherwise prohibited traffic, to determine its suitability for such tasks. (As always, check the terms of use with your ISP before conducting significant scanning activity.)

First, I browsed to http://ipv6.whatismyv6.com/ (URL only accessible via IPv6), and checked that the global address displayed locally is the address seen by remote systems that I connect to. This confirms that no intrusive NAT or proxy activity is performed on outbound connections.

I performed several basic connectivity tests to confirm the IPv6 connection. I first resolved the IPv6 address for the web server, and browsed to the site using the address:
$ host -t AAAA ipv6.whatismyipv6.com
ipv6.whatismyipv6.com has IPv6 address 2001:4870:a24f:2::90

I also confirmed connectivity to Google's IPv6 server, using ping6:
$ host -t AAAA www.google.com
www.google.com has IPv6 address 2607:f8b0:4000:803::1012

$ ping6 2607:f8b0:4000:803::1012
PING 2607:f8b0:4000:803::1012(2607:f8b0:4000:803::1012) 56 data bytes
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=1 ttl=54 time=329 ms
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=2 ttl=54 time=69.0 ms
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=3 ttl=54 time=67.6 ms
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=4 ttl=54 time=65.8 ms
^C
--- 2607:f8b0:4000:803::1012 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 65.899/133.045/329.631/113.504 ms

I used Nmap's built-in IPv6 scanning capability to port scan this host:

root@laptop$ nmap -v -6 -oA /tmp/www.google.com-6-tcp -p 0-65535 2607:f8b0:4000:803::1012
<...>
Nmap done: 1 IP address (1 host up) scanned in 284.60 seconds

This scan took slightly under five minutes, and identified two open ports, five closed ports, and the remainder filtered:
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"open\"" | wc -l
2
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"closed\"" | wc -l
5
$ cat /tmp/www.google.com-6-tcp.xml | grep "extraports state"
<ports><extraports state="filtered" count="65529">

For purposes of comparing performance and identifying any ISP-level filtering, I ran the same scan from a native IPv6 hosted server:
root@linode$ nmap -v -6 -oA /tmp/www.google.com-6-tcp -p 0-65535 2607:f8b0:4000:803::1012
<...>
Nmap done: 1 IP address (1 host up) scanned in 104.69 seconds

This scan took less than half the time -- under two minutes, but produced the same results: two open ports, five closed, and the remainder filtered.
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"open\"" | wc -l
2
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"closed\"" | wc -l
5
$ cat /tmp/www.google.com-6-tcp.xml | grep "extraports state"
\<ports><extraports state="filtered" count="65529">
This confirms that no outbound TCP traffic filtering affects the mobile hotspot IPv6 connection.

Interestingly, the results for these scans differ slightly from those for the corresponding IPv4 hosts:
root@laptop$ nmap -v -p 0-65535 www.google.com
Starting Nmap 6.02 ( http://nmap.org ) ( http://nmap.org ) at 2013-02-26 00:46 CST
Scanning www.google.com (74.125.225.180) [65536 ports]
Not shown: 65533 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
1720/tcp open  H.323/Q.931
As has been pointed out by others, this serves as a reminder to scan both addresses, if accessible. Comparing results can identify differences in the configuration (or absence) of firewall protections, as well as different service listening profiles.

To verify and expand upon these initial results, I decided to scan a larger number of IPv6 hosts. NIST's Advanced Network Technologies Division (ANDT) tracks the U.S. federal government's external deployment of IPv6 (and DNSSEC) technologies. (Their methodology is documented.)

I pulled down data from the 'Detailed IPv6 & DNSSEC Service Interface Statistics' chart on March 7, 2013, and worked it into suitable Nmap scan input format:

$ cat /tmp/fed-ipv6 | cut -d "," -f1,2,5 | grep -v "0/0/0" > /tmp/gov-ipv6-web-partial.csv

After sorting, the script randomly chose 10 unique IPv6 addresses. (Note that the script above limits the output to the first 25 domains with an IPv6-accessible website; as of this date, there are 1384 total domains tracked, 384 of which host an IPv6-accessible website.)

Port scans from the native IPv6 hosted system:
root@linode$ nmap -v -6 -oA outputs/nmap/web-ipv6s -iL /tmp/web-ipv6s-10
<...>
Nmap done: 10 IP addresses (10 hosts up) scanned in 25.40 seconds

root@linode$ cat outputs/nmap/web-ipv6s.xml | grep "state=\"open\"" | wc -l
15
root@linode$ cat outputs/nmap/web-ipv6s.xml | grep "state=\"closed\"" | wc -l
3
root@linode$ cat outputs/nmap/web-ipv6s.xml | grep "extraports state=\"filtered\"" | wc -l 
10

Identical scan from the mobile hotspot-connected laptop:
root@laptop$ nmap -v -6 -oA /tmp/nmap-web-ipv6s -iL /tmp/web-ipv6s-10
<...>
Nmap done: 10 IP addresses (10 hosts up) scanned in 85.34 seconds

root@laptop$ cat /tmp/nmap-web-ipv6s.xml | grep "state=\"open\"" | wc -l
16
root@laptop$ cat /tmp/nmap-web-ipv6s.xml | grep "state=\"closed\"" | wc -l
3
root@laptop$ cat /tmp/nmap-web-ipv6s.xml | grep "extraports state=\"filtered\"" | wc -l
10

Interestingly, one more service is reported up from the laptop-based scan, which was confirmed using Ncat. This appears to be due to a difference in how the hotspot connection handles "IPv4-mapped" IPv6 addresses presented by a hybrid dual stack implementation, opting to use IPv4 connectivity in spite of software instructions (from Nmap, Ncat) to the contrary.

The native stack on a Linode hosted system does not exhibit this behavior, and thus does not identify this service, which is appropriate since it is not actually listening on an IPv6 interface.

Aside from this slight discrepancy, these tests confirm that scanning results are consistent between a mobile hotspot client and a native IPv6 system, albeit at less than 1/3 of the speed. The performance disparity increased significantly during additional tests targeting a larger number of systems, and all 65536 TCP ports, indicating that this technique should not be relied upon for large-scale scanning.

One additional, related point to note: while outbound TCP traffic from the IPv6 mobile hotspot appears not to be restricted, inbound traffic most certainly is. This was determined by running Ncat listeners on several ports from the laptop, with the local firewall disabled. None of these services were accessible from a remote server. Likewise, ICMP activity was filtered. Therefore, this technique should not be relied upon for connect-back shells from target systems, inbound file transfers, or similar connections requiring remotely-initiated connections.

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.