Help support this project...
Raising awareness about secure phone provisioning
[This story was delayed from 10/24 to give a vendor time to respond. As it turned out, that vendor decided to take no action.]
Cal Leeming (foxx on IRC) was kind enough to join our weekly conference call to raise awareness about the importance of secure provisioning.
Many providers put configuration files for IP phones on publicly-accessible servers. Often these files are neither encrypted nor protected by any form of authentication. All you need to access these files is the URL scheme used by the provider and the MAC address of the phone. As we'll see in a moment, this is in fact essentially required for zero-touch provisioning to work as it does today.
Let's say you want the contents of one of these files. How might you find the URL scheme used by a provider? Previously if you couldn't find it by guessing, you would probably need to get a phone from that provider and then either extract the firmware or watch the traffic with Wireshark. Having to do that for many providers, while not infeasible at all, does present something of a barrier.
Fortunately (for the bad guys), phone manufacturers have decided to adopt a technique (I hesitate to say 'technology') called zero-touch provisioning or RPS (Redirection and Provisioning Service). The idea behind RPS is that providers can remotely provision new phones they've never physically handled at all.
After a phone is sold to a service provider (perhaps via a wholesaler), the service provider makes an API call that tells the manufacturer they now own a particular phone, identified by MAC address, and to where requests for the phone's configuration should be redirected.
Now when a request is made to the manufacturer's publicly accessible server for the phone's configuration, their server redirects the request to a file on the provider's configuration server. If an attacker simply knows the MAC address of a phone, she can make a request to the manufacturer's RPS server, which will redirect to the provider's server, which -- more likely than not -- will hand over the plaintext file containing the phone's configuration.
With this configuration file, the bad guys can impersonate the user. That would be bad enough, as it would likely give them access to the user's voicemail or other privileged services.
More likely, however, the bad guys will be interested in committing toll fraud. They'll use the stolen account to pump a large volume of calls to high cost foreign rate centers where -- through complicated business mechanisms -- they'll be able to collect a portion of the toll charges paid by the victim and the other intermediating carriers. The dollar amounts involved in this kind of fraud can be shockingly high.
But we're getting ahead of ourselves. How will the bad guys find a valid MAC address for a phone?
As it turns out, this isn't difficult, and RPS makes this much easier. MAC addresses are 48 bits long, so there are 2\^48 of them. The first 3 bytes (24 bits) of the address compose the Organizationally Unique Identifier (OUI). One or more of these are assigned to organizations like Yealink or Snom. This leaves 24-bits for the manufacturer to assign unique addresses to their equipment. In practice, for a particular model of phone, a manufacturer might assign addresses out of a space as small as 16 bits, and they are likely to assign these nearly sequentially. Therefore, if you know the MAC address of just one phone, and search the surrounding 2\^16 addresses, you're likely to find many valid phone MAC addresses.
In Cal's testing, he found he could make at least 1000 requests per second against manufacturers' RPS servers. It's likely that determined bad guys with a cluster of systems could do better.
1000 requests per second is about 2\^10. So we can search a 2\^16 space in only 2\^(16-10) = 2\^6 = 64 seconds. And because of RPS, we don't have to repeat this search against N different service providers. We simply target our search against the manufacturer's RPS server and they'll tell us who the service provider is and where we can find the provisioning file.
This really is as bad as it sounds. What's perhaps worse, however, is how little surprise there was on our call. This is not a disclosure in the common sense of the word. Everyone familiar with these systems already knows about this problem -- though there was some debate on our call about whether there really may exist people dull enough to both understand the system design and miss this problem (I doubt it). The mission instead is to remind people that this flaw, though widely accepted, is a recipe for failure that should not be tolerated. As soon as attackers organize around exploiting this weakness, the damage to the industry could be massive.
Problematically, there is no way for service providers -- without assistance from phone manufacturers -- to completely address this weakness without forfeiting the benefits of zero-touch provisioning. Providers can configure their provisioning servers to require a valid username and password, and then assign unique credentials to each phone. When the phone supports HTTPS provisioning, this would be reasonably secure as long as you could securely deliver the credentials.
(Some phone firmwares allow the service provider to encrypt the configuration file using a key the server shares with each phone. This is isomorphic, for the purposes of our discussion.)
But delivering the credentials securely is exactly the problem with zero-touch provisioning in its current form. The first time the phone connects to your servers (via an RPS redirect), it won't have any credentials. You'll have to decide whether to issue the phone the credentials it will use in the future. If you do so, you'll also need to never issue this phone credentials in plaintext again (otherwise you won't have improved security at all). But you have no way of knowing whether what's connecting to your servers is the phone you sold, or an attacker impersonating it. How can you decide whether to give it the credentials? If you make the wrong choice, you'll open yourself up to toll fraud, and you'll lock out the actual phone.
The obvious solution to this issue is for the manufacturer to include a unique private key with each phone (ideally via a TPM) such that the phone could securely authenticate itself to servers. Doing only this, however, would complicate the sale of phones through distribution as the public components of the keys would need to be distributed and managed.
A more sane solution would be to sign each phone's public certificate (which should contain the phone's MAC address) with the manufacture's private key. The phone could then provide its signed public component when authenticating to the service provider, and the provider could check the MAC address in the certificate and check the signature against the manufacturer's public key component. As long as the manufacturer securely created and managed their certificate authority, this would work fine.
There are other solutions that are somewhat less elegant, such as dispensing with "zero-touch" and forcing the entry of a PIN-like code on each phone.
It will be interesting to see how manufacturers respond to the increased attention being focused on this issue. Will they take down their RPS servers? Will they move to more secure provisioning models? Or will attackers need to inflict large financial damage to their customers before the manufacturers respond? Time will tell.