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.
2 replies on “Wot? No Password?”
The “problem” with VoIP is that it is so easy, any clown can set up a commercial VoIP service without knowing a thing about security (the same could probably be said about web hosting, or any number of other Internet businesses of course.)
Auto provisioning works great inside a controlled environment, like a private network, but clearly there are issues if you change the assumptions (for example “private network” -> “Internet”) without understanding the consequences.
One thing I’m confused about – these phones need to have a provisioning server address configured before being sent out, or else they’d never find their service provider in the first place. The fact they have this would indicate they have been “touched” by the service provider in some way. Perhaps they should have put some more configuration in at that time, like a temporary password?
Alternatively, and significantly more securely, the obvious fix for this is not to rely solely on SIP password for authentication. A newly-provisioned phone should be placed in a “walled garden” where it can not make or receive calls, and any attempt to do so leads the user to an automated second level of authentication (“welcome to the VoIP service, please enter your activation code”) which has to be completed before the phone is fully activate.
This is the same as banks do when they send out new payment cards – they aren’t active until you call the bank and confirm the card is in your rightful possession.
The problem is deeper than “any clown setting up VoIP Services”, there is a lack of good advice and guidance. The good news is that ITSPA have recognised the problem and are working on a best practice guide.
Service providers do not need to touch phones, most manufactures run a master provisioning server, the identity of this server is built-in to each phone. When a phone is shipped to or on behalf of a service provider, the phone’s identity is added to the master server with the location of the service provider’s own server. When the phone is connected, it queries the manufacturer’s master server and is redirected to the service provider’s provisioning server.
The idea of requiring a second level of authentication before a phone is activated is a good one, but there is still a need to to improve provisioning security.
Lastly, I don’t agree that auto provisioning works great inside a controlled environment. The risks are certainly reduced when compared with Internet based services, but what is to stop an employee or even a visitor in the conference room scanning an internal provisioning server and then setting up a device to receive or record calls for senior managers? This is a genuine problem which I have found on many VoIP security audits.