Monthly Archives: July 2008

Asterisk “hack” to show blocked Caller-ID points to larger trust issues with SIP

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.


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:


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" <>
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" <>
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/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.


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:
, , , , , , , , ,

Two new Asterisk security advisories…

asterisklogo.jpgThe 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.


The first advisory, AST-2008-010, outlines a denial of service attack where an attacker can basically send a large number of IAX2 “POKE” requests and consume all available capacity to make or receive calls using IAX2. The only workaround seems to be to upgrade to the newest version. It does not say but one would imagine that if you do not use IAX2 connections you could presumably block that port and not allow any inbound IAX2 connections. (Although the safer course is, naturally, to upgrade.)


The second advisory, AST-2008-011, outlines a scenario in which an attacker could flood a site with bogus requests to download a firmware image which would result in the generation of a large amount of traffic on the network. Essentially, since there is apparently no “handshake” before the initiation of the firmware transfer, an attacker can spoof the source address. With a large number of such requests, the Asterisk system can wind up generating a large amount of network traffic destined for spoofed sources. As noted in the advisory, the workaround is simply to remove the firmware image. This firmware download service has been disabled by default in the new version.

As noted in both advisories, Asterisk users are strongly recommended to upgrade as soon as possible to the listed version.

Technorati Tags:
, , , , , ,

LinkedIn to VoIPSA

I would like to invite any VoIPSA LinkedIn users to join the new LinkedIn VoIPSA group.  While we already have documentation on the website regarding the Board of Directors and the Technical Board of Advisers, there wasn’t really much in the way of identifying and networking with other members of our organization who are not on either of these boards, other than of course the VoIPSec mailing list (which doesn’t have a public membership roster), so I’ve established this group to fill that void.

Ari Takanen starts blogging at ITworld…

aritakanen-itworld.jpgI was pleased to see today that Codenomicon CTO Ari Takanen has started blogging for ITworld with an entry “Greatest Challenge in VoIP Security” in what appears to be a new ITworld blog “VoIP Security: Secrets and Hype“. As that page says:

What is VoIP security all about? After close to ten years of hacking and bashing VoIP, Ari Takanen will finally reveal the secrets and discuss the hype around VoIP security. The discussions in this blog will draw from his book “Securing VoIP Networks: Threats, Vulnerabilities, and Countermeasures” co-authored by Peter Thermos, and published by Addison-Wesley. Ari will also answer any questions and comments you might have regarding penetration testing and fuzzing of VoIP and other telephony networks.

Ari’s a great guy who is a member of the VOIPSA Technical Board of Advisor, who I’ve met at a number of shows and who has often shared his insight on the VOIPSEC mailing list. He was also a member of a panel last year that we ran as a Blue Box Special Edition. (There’s also another interview with Ari and his co-author Peter Thermos that’s in the Blue Box post-production queue… soon…)

Anyway, it’s great to see Ari joining the blogging space. In his first post he writes:

Building VoIP security is a team effort. Each of us look at it from a slightly different angle. All opinions are correct. During the future weeks I will share mine in this blog.

I look forward to reading those opinions!

Technorati Tags:
, , , , ,

Highlights From IPTCOMM Heidelberg July 2008

IPTCOMM 2008, held in Heidelberg, was a great event and directly relevant to the VOIPA community.  What made it notable was the success of the organizing committee and venue host in showcasing outstanding new research results for security, performance, and new features in IMS/NGN based technologies.

Much of the work was developed by graduate students and postdocs under sponsorship of senior technical members of our community.   In addition to the technical work the spirit, energy, and enthusiasm of the attendees was a notable pleasure.

The conference program will be published by Springer Lecture Notes in Computer Science; other details available directly at the IPTCOMM site.

An industry talk for VOIPSA identified four new projects necessary to advance research in the market.  I’ll mention details by separate post.

A quick summary of what happened at IPTCOMM follows:

Welcome Note
Saverio Niccolini (NEC Laboratories Europe, DE) and Pamela Zave (AT&T Laboratories, US)

Dr. Ralf Steinmetz Professor, Multimedia Communications Lab (TU Darmstadt, DE).
“Real-time Communications and Services in 2018 and Beyond.”

SIP and new service environments
A SIP-based Programming Framework for Advanced Telephony Applications
Wilfried Jouve (INRIA / LaBRI, FR); Nicolas Palix (LaBRI/INRIA, FR); Charles Consel (LaBRI/INRIA, FR); Patrice Kadionik (IMS, University of Bordeaux, FR)

An IMS Based Mobile Podcasting Architecture Supporting Multicast Delivery
Heiko Perkuhn (Ericsson Research, DE)

Generalized Third-Party Call Control in SIP Networks
Eric Cheung (AT&T, US); Pamela Zave (AT&T Laboratories, US)

Attack detection and mitigation in SIP networks
Automatic Adaptation and Analysis of SIP Headers using Decision Trees
Karin Hummel; Michael Nussbaumer; Andrea Hess Helmut Hlavacs (Univ. of Vienna, AT); Karin Hummel (University of Vienna, AT); Michael Nussbaumer (University of Vienna, AT); Andrea Hess (University of Vienna, AT)

A Self-Learning System for Detection of Anomalous SIP Messages
Konrad Rieck (Fraunhofer FIRST, DE); Stefan Wahl (Alcatel-Lucent, DE); Pavel Laskov (Fraunhofer FIRST, DE); Peter Domschitz (Alcatel-Lucent, DE); Klaus-Robert Müller (Technical University of Berlin, DE)

Secure SIP: A scalable prevention mechanism for DoS attacks on SIP based VoIP systems
Gaston Ormazabal (Verizon, US); Henning Schulzrinne (Columbia University, US); Eilon Yardeni (Columbia University, US); Sarvesh Nagpal (Columbia University, US)

Performance management in SIP networks
One Server Per City: Using TCP for Very Large SIP Servers
Kumiko Ono (Columbia University, US); Henning Schulzrinne (Columbia University, US); Erich Nahum (IBM T.J. Watson Research Center)

SIP Server Overload Control: Design and Evaluation
Charles Shen (Columbia University, US); Henning Schulzrinne (Columbia University, US)

Improving the scalability of an IMS-compliant conferencing framework. Part II: involving mixing and floor control Simon Pietro Romano (University of Napoli Federico II, IT); Alessandro Amirante (University of Napoli Federico II, IT); Tobia Castaldi (University of Napoli Federico II, IT); Lorenzo Miniero (University of Napoli Federico II, IT)

On Mechanisms for Deadlock Avoidance in SIP Servlet Containers
Laura Dillon; Kurt Stirewalt; Yi Huang (Michigan State University, US)

Security, legal and modeling issues of SIP based communications
Lawful Interception in P2P-based VoIP Systems
Jan Seedorf (NEC Europe Ltd., DE)

Security Analysis of an IP Phone: Cisco 7960G
Italo Dacosta (Georgia Institute of Technology, US)

Understanding SIP Through Model-Checking
Pamela Zave (AT&T Laboratories, US)

Next generation services for VoIP
Detecting VoIP Traffic Based on Human Conversation Patterns
Chen-Chi Wu (National Taiwan University, TW); Kuan-Ta Chen (Academia Sinica, TW); Yu-Chun Chang (National Taiwan University, TW); Chin-Laung Lei (National Taiwan University, TW)

Template-based Signaling Compression for Push-To-Talk over Cellular (PoC)
Andrea Forte (Columbia University, US); Henning Schulzrinne (Columbia University, US)

Providing Content Aware Enterprise Communication Services
Xiaotao Wu (Avaya Labs Research, US); K. Kishore Dhara (Avaya Labs Research, US); Venkatesh Krishnaswamy (Avaya Labs Research, US)

Industry talk session
An overview of ETSI standardisation activities in the Information Security arena with a focus on NGNs
Carmine Rizzo, Technical Officer, ETSI Standardisation Projects

Simulating Realistic Metro-area Network Behavior
Darius, Product Manager, Empirix

Process-Based Security Testing in a Carrier Environment
Sven Weizenegger, Lead of Security Testing and Senior Consultant, T-Systems; Heikki Kortti, Senior Security Specialist, Codenomicon

VoIP Security: Do Claims of Threats Justify Continued Research Efforts?
Jonathan Zar, Pingalo, Inc; Eric Y. Chen, NTT Information Sharing Platform Laboratories

Advanced Structural Fingerprinting in SIP
Humberto J. Abdelnur Radu State, Olivier Festor (INRIA)

Robustness Testing Of SIP, IMS and Of the Underlying IP Infrastructure
Lauri Piikivi (Codenomicon)

Protocol interactions among User Agents, Application Servers andMedia Servers
A. Amirante, T. Castaldi, L. Miniero and S. P. Romano (University of Napoli Federico II)

SOA-Type Service Composition With Reusable Telecommunications Components
Ioannis Fikouras (Ericsson Research), Gregory W. Bond (AT&T Laboratories)

VoIP SEAL 2.0 Security Suite for SIP enabled networks
Thilo Ewald, Nico d’Heureuse, Saverio Niccolini (NEC Laboratories Europe, DE)

On the deployment of Network Processors in Operational and Testing Network Devices
Fabio Mustacchio, Federico Rossi, Francesco Lamonica (NetResults Srl); Andrea Di Pietro, Fabio Vitucci, Domenico Ficara (University of Pisa – Department of Information Engineering)

Vishing Prevention by Authenticated Display-name
Stanley Chow Christophe Gustave Dmitri Vinokurov (Alcatel-Lucent, Bell Laboratories)

Note: This posting is for informative purposes only.  Conference notes are available from Springer LNCS and copyrighted IPTCOMM 2008.

Want to learn about voice biometrics? VoiceVerified to be interviewed tomorrow (July 10, 2008)

voiceverifiedlogo.jpgAre you interested in using voice for authentication, also known as voice biometrics? Would you like to know how far voice biometrics has come from that 1992 film “Sneakers” with “My voice is my password”?

If you are free tomorrow, July 10, 2008, at 11am US Eastern time you can join in a conference call/podcast where I’ll be interviewing David Standig with about voice biometrics in general and VoiceVerified’s specific offering. If you can’t join us at 11am, the interview will be available as a “Squawk Box” podcast later in the day.

The deal is that Alec Saunders, the regular host/producer of the daily Squawk Box podcast is away on vacation and I’ve been guest-hosting this week in his absence. The daily shows have been about a range of topics (today was a great one about P2PSIP) and tomorrow’s show actually gets into VoIP security in terms of voice verification/biometrics.

If you would like to join into the show, there are two ways you can do so:

In either case, you’ll get access to the telephone number you need to call and, during the call, will also have access to the live chat session that is used.

If you aren’t able to attend (or don’t want to use the app), you can listen to the show after I post it on Alec’s sometime later tomorrow, probably in the evening.

Also, if you are interested in being on Alec’s Squawk Box show, my guest hosting is done tomorrow but drop me a note and I’ll be glad to suggest your name to Alec after he returns. I frequently participate and they’ve been enjoyable shows to be a part of.

P.S. In the interest of full transparency and disclosure, I should note that VoiceVerified is actually a business partner of my employer, Voxeo, as I outlined in a blog post. That fact, however, did not influence my decision to bring them on the show – I was just looking for interesting companies to interview and they were one that caught my eye.

Technorati Tags:
, , , , , ,

Sipera looking to hire a few good VoIP security researchers…

siperalogo.jpgWant a job in VoIP security? Jason Ostrom, who recently joined Sipera Systems as director of their VIPER Lab, passed along word to us that they are looking to hire two new positions related to VoIP security:

  • VIPER Security Consultant
  • VIPER Vulnerability Research Engineer

Job descriptions and information about applying can be found over on Sipera’s “Careers in VoIP Security” page. (i.e. please do not leave comments here about these jobs or contact us as we have nothing to do with the jobs).

Technorati Tags:
, , , ,