UM Labs Ltd. Founder and CEO Peter Cox’s post is based on a presentation given at a recent ITSPA workshop on the risks of auto provisioning.
Everyone understands the need for security on the Internet. We all know the importance of using strong passwords and — painful as it may be — regularly changing those passwords. As such, would it surprise you to learn that there is one widely used Internet service that routinely provides sensitive information to anyone that asks without asking for a password or employing any other form of authentication?
The service I refer to is phone auto provisioning. If your company has an IP phone system (as most mid-to-large companies do) or if you outsource your phone system to an IP service provider, the chances are that your phones are using auto provisioning and possibly without using authentication. ITSPA has recognised the problem and is working on producing guidelines to address it.
One of the benefits of VoIP is that you can take a phone out of the box, plug it in just about anywhere, and it works. Of course, there is a lot going on behind the scenes. For instance, for an IP phone to work it must first be configured with such details as a phone number, the network address of the system it should connect to, and a password the phone uses to authenticate itself to the service provider or internal phone system. Calls cost money, so phones must be identified and authenticated when they connect to the service and when they are used to make calls. The problem is that the complete configuration for a phone is long and complex. It could include 100 or more parameters, for example:
sips persistent tls: 1 download protocol: HTTPS sip line1 proxy ip: xxx.xxx.xx.xx sip line1 registrar ip: xxx.xxx.xx.xx sip line1 proxy port: 5060 sip line1 registrar port:506 sip line1 password: xxxxxxxxxxxxxxxxx
Of course, nobody wants to have to type such information in, so this is where provisioning steps in. When a handset is connected it contacts a pre-defined provisioning server (just a specialised web server), identifies itself via its unique MAC address, and downloads its configuration. Simple! The problem, though, is that most provisioning servers identify the phone (particularly when hardware IP phones are connected) solely via its MAC address — a 12-digit value unique to each phone that is normally printed on the phone alongside the serial number.* As such, if a provisioning server gets a request for a MAC address it recognises the server replies with the complete configuration needed to configure the phone….and most provisioning servers DO NOT ask for a password or use any other authentication mechanism. Thus, anyone who knows or is able to guess your phone’s MAC address can download its configuration, including the password needed by the phone to make calls.
Distributing passwords to anyone who asks without some form of authentication is clearly a bad idea. And guessing MAC addresses is not as difficult as it sounds. All an attacker has to do is to connect to a provisioning server and try each of the 16.7 million possible addresses for a specific vendor, which may sound like a big challenge but which in truth is not. To support this point I recently wrote a very simple script to do exactly this in just 5 minutes. I then pointed my script at a service provider’s provisioning server and ran it using a restricted set of 1,000 address. Running on a £25 Raspberry Pi, my script took roughly 7 minutes to complete and returned the complete configuration of two phones including passwords. And as I had no way of knowing if any of the 1,000 MAC addresses belonged to phones connecting to the service provider, 1,000 is a good hit rate.
At a rate of 7 minutes to scan 1,000 MAC addresses it would take 86 days to scan the entire range of 16.7 Million addresses used by a particular phone manufacturer. Then, having done that, I could get the configuration — including the password — for every phone from a single vendor used by the targeted service provider. And what if I was not willing to wait 86 days? I could invest in faster hardware or spend a bit more time writing a more efficient script (or both) and easily complete the scan in a week.
The information that my script returns would be invaluable to an attacker, offering an easy route for call fraud that could leave the victim with a bill of tens or thousands of pounds. Thus, ITSPA’s initiative to address the problem could not be more timely.
*All systems connecting to a network, whether a wired Ethernet connection or a WiFi connection, must have a globally unique MAC address hard-wired in when the device is built. These MAC addressees are managed by the IEEE, with each manufacturer assigned a six digit prefix (A list of vendor prefixes is published at
http://standards.ieee.org/develop/regauth/oui/oui.txt). MAC addresses are base 16 numbers, so the remaining 6 digits can be used to create 16.7 million unique addresses.