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.