Asterisk “hack” to show blocked Caller-ID points to larger trust issues with SIP
July 23rd, 2008 by Dan YorkCan 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
July 23rd, 2008 at 1:18 am
I agree that “trust boundary” is the operative concept here. Back when telco was a small club the Caller ID was set by the originating CO and the display of same was handled by the terminating CO and everyone played by the same rules. Now that those boundaries have become more porous, not everyone respects the old rules, but the customers haven’t figured it out. I’m waiting from some high profile case where someone relied on caller ID for identity or relied on the carrier for anonymity but didn’t get the intended result. Do you think we’ll get “strong identity” in time? I doubt it.
July 23rd, 2008 at 3:30 am
Dan:
Thanks for this post. I will be the first to admit that I am not a nuts and bolts telephony guy, so I was looking at this from the, “is there anything that people are not doing with Asterisk,” but after reading this, wow, what a problem this could be.
Again thanks for increase my acumen here on this subject - you rock!
July 23rd, 2008 at 4:52 am
The trust boundary was made porous in part by VoIP proponents who lobbied for unregulated access to VoIP providers. So I do not agree that “there are no easy answers”. By the way this form of passing restricted Caller ID could have been done in PRI as well. Why can’t VoIPers leave PSTN alone or live with the rules of PSTN? If VoIP is wild west, why should a gentrified PSTN be forced to interact with it?
July 23rd, 2008 at 5:22 am
@Christopher - Yes, I, too, expect that sadly there will need to be a “significant effect” before customers realize how much things have changed from what they expect. Can we get strong identity soon enough? I don’t know.
@Garrett - Thanks for your kind words and I’m glad it helped.
@aswath - I don’t know that the unregulated access is the issue… people have woken up to the fact that telephony is no longer this arcane and complicated thing when you bring it onto a PC. They are figuring out new ways to do things via VoIP. Regulated or unregulated, I think it still would have happened.
You’re right that SS7 passes the same basic signaling with a “privacy bit” called “CNID”. The issue is that as @Christopher commented, there were far fewer players in the SS7 club than there are now.
As to your question about “why can’t VoIPers leave the PSTN alone…”, I’ve been working on a draft that answers that precise question (in the way that you posed it to Twitter). I’ll probably work on that on my plane ride home from Portland and post it next week.
September 9th, 2008 at 7:13 pm
Well, here is little question if someone know. How can i know that a call is bridged and what dtmf-relay is being used? someone told me it can be identified from the network trace i.e. TCPDUMP etc .. but not sure how.