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
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.
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!
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?
@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.
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.
I think that if they are so worried about identity but what about someone who just doesn’t want to be kept in the dark when receiving a call or if you are getting harassed or threaten by someone who’s hiding their ID I personally experienced that and when that happen the police could not do anything just sit and wait till your stocker or prank caller calls again to find who it is i think if you want to be trusted you must show trust as well and not block your number because you simply think that’s your God given right if you don’t want to let someone know who you are before talking to them then the person who must show trust is you, in other words would you open your door if someone were nocking while wearing a mask?
I think the issue is with the caller not the end point recipient who is totally unaware of the caller identity after all why get a caller ID service if everyone decides they should blocking their phone I think if they don’t want to be know then don’t call at all but if they gonna block their call why can’t I unblock it?
Yeah it is too easy to mask caller id with voip, this can cause some security problems. I actually found that att cell phone service authenticates the voicemail box based on the caller id number so you can hack into peoples voicemail boxes. I haven’t tested this in a while so they may have corrected it.
Bit of a thread necro going on here, but I don’t see the problem. If YOUR system is going to connect to MY system, I have the right to know who you are and the number that’s associated with your call.
I already send them to another IVR that basically tells them they can hang up, unrestrict their number, and call back or we don’t want their business.