[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
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
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
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
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.