Can Asterisk really be used to “unmask”blocked Caller-ID and show the private number?
Well, yes… but it really has less to do with Asterisk then it does with not respecting the signaling sent to you by a SIP trunking provider. It’s conceivable that any IP-PBX could be configured to allow you to do this… and points to a larger issue with trust boundaries between SIP Service Providers (a.k.a. Internet Telephony Service Providers or ITSPs) and their customers.
THE “HACK”
Let’s take a step back first and explain… over the weekend FierceVoIP ran a piece about VoIP security talks at the “Last Hope” conference that referenced a demonstration by Kevin Mitnick of how you could use Asterisk to show Caller ID information for someone calling even if the caller’s ID is set to “private”. Someone (“phant0msignal”) recorded a video of the demonstration (and yes, if you listen, the audio cuts in and out) and posted the video to YouTube and the code to his blog. This might have gone somewhat unnoticed except that it got picked up by Engadget, which naturally garnered a good bit of attention. Here’s the video:
THE EXPLANATION
So was this really a big “hack” that exposed private information?
Not really… although it may be a clever use of scripting within Asterisk.
Here’s the thing:
Asterisk received this information as a natural part of SIP communication because the SIP Service Provider TRUSTED Asterisk to “do the right thing” and NOT display the information.
Which, normally, would be the case. Asterisk would respect the SIP privacy headers and not display the Caller ID. However, in this case Asterisk was modified to NOT respect the privacy headers and display the information that was requested to be private.
To understand this, we need to look at one of the ways that “Caller ID” is usually handled within the world of SIP communication. RFC 3325 defines a SIP header called “P-Asserted-Identity” that is inserted typically by the first SIP proxy that is interacting with the SIP endpoint. The result, within a trusted administrative domain, is the inclusion of one or more headers that look like:
P-Asserted-Identity: "Dan York" <sip:dyork@example.com> P-Asserted-Identity: tel:+14155551212
The P-Asserted-Identity header, often referred to as P-A-I for short, includes this identity information that can be used by the proxy for the recipient of the call to display “Caller ID” on the recipient’s SIP endpoint (phone, softphone, etc.).
Now, when a call is to be private, there is an additional SIP header included. RFC 3323 defines the “Privacy” SIP header and section 9.3 of RFC 3325 adds an “id” value to the Privacy header. So the resulting SIP headers look like:
P-Asserted-Identity: "Dan York" <sip:dyork@example.com> P-Asserted-Identity: tel:+14155551212 Privacy: id
Per RFC 3325 Section 7, this Privacy header indicates to the SIP proxy that the P-A-I information MUST be stripped off before the SIP headers are sent to an “untrusted” entity. From the RFC:
Parties who wish to request the removal of P-Asserted-Identity header
fields before they are transmitted to an element that is not trusted
may add the “id” privacy token defined in this document to the
Privacy header field. The Privacy header field is defined in [6].
If this token is present, proxies MUST remove all the P-Asserted-
Identity header fields before forwarding messages to elements that
are not trusted.
So the “hack” in this case was that Asterisk’s SIP handling was modified to NOT respect the Privacy header and instead pass along the P-A-I information to, in this case, the endpoint.
THE LARGER PROBLEM
The larger problem/issue is really this:
Why did the SIP Service Provider send the P-A-I information down to Asterisk box in the first place?
The answer, of course, is simply this:
The SIP Service Provider assumed that it could trust the SIP server with which it was communicating.
The Service Provider extended its “trust boundary” out to encompass the SIP network of its customers. As far as the Service Provider was concerned, the customer was just another SIP network and should be trusted. The Service Provider did not apparently care whether the customer was another carrier – or just someone running Asterisk on a home system. They were simply glad to provide connectivity to the customer.
The problem is:
The trust boundary of the PSTN was then extended out to the customer system.
and there was an implicit assumption that PSTN privacy requests would be respected.
NO EASY ANSWERS
One obvious reaction is “So the Service Provider shouldn’t send that information to the customer’s SIP server!” Perhaps. Perhaps the Service Provider should not trust any of its customers with that information. (And I Am Not A Lawyer so I don’t know if in this case there are actual legal issues here.)
But I’m not sure it’s that simple.
You see, there’s a bit of a “Wild West” going on right now in the world of SIP trunking. Basically, anyone and their brother, mother, father, sister (and…) can get into the world of providing SIP trunks simply by setting up a SIP server (which could be done with Asterisk) and buying some upstream SIP connectivity from a larger SIP Service Provider… ta da… “ZZZZZ VoIP Services” is born. Simple. Easy.
If you are a larger SIP Service Provider, you will sell to smaller Service Providers and naturally extend your “trust boundary” to them. They will sell to others… and so on… and so on… until some final system is connected to some endpoints.
SIP clouds connected to SIP clouds connected to more SIP clouds.
Where do you appropriately define the “trust boundary”? Is it perhaps the “top tier” SIP Service Providers? Is it “the carriers who run the PSTN”? Should it have been stripped off at a gateway coming in from the PSTN?
We’re building this massive “interconnect” of SIP clouds… and this is just one of the many issues that it is not entirely clear that we have a consensus on. Sure, RFC 3325 defines what should happen on a technical level… but what about on a policy level? Who gets to be part of the “trusted” community? (FYI, I would strongly recommend reading RFC 3325 for a better understanding of the issue.)
In the meantime, it’s fairly safe to assume that if you are “blocking” your Caller ID, there is no actual guarantee that it won’t be seen by the recipient. In the vast majority of cases, sure, that privacy will be respected. But there’s no guarantee.
Welcome to new world of VoIP…
P.S. And yes, if you were reading this and thinking “Gee, so can’t the ‘Caller-ID’ be easily spoofed just by modifying the SIP headers?” you are absolutely right. That’s why there’s a good amount of work going on right now in the IETF around the whole area of “strong identity”… but that’s a topic for another blog post some time…
Technorati Tags:
voip, security, voip security, caller id, callerid, telephony, telecommunications, kevin mitnick, SIP, SIP security
The security team over at Digium today released two new security advisories. In both cases, the fixes are in the latest version of Asterisk and all Asterisk users should upgrade to those new versions.
