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

So, it’s been a few business days since I posted “Asking the Cisco Systems’ IPICS Expert: Questions 1-5″ and while I haven’t heard anything back from the IPICS Expert either via email or comment on the blog post, it is somewhat amusing, and perhaps a bit disturbing, that a Google search for “IPICS Expert” leads back to VOIPSA…go figure.

Anyway, as with the previous post, this post continues focusing on Cisco Systems’ IPICS (IP Interoperability and Collaboration System) Server, the “heart” of the IPICS solution, with five more questions for the Cisco IPICS Expert:

Question 6: Early versions of the IPICS Server documentation refer to the operating system as Red Hat Linux, while a later version of documentation refer to the operating system as “Cisco Linux” and the latest version of documentation states “Linux” — Is the IPICS Server still based on Red Hat? If so, what version of Red Hat (enterprise, etc.)?

Cisco Answer

Question 7: Does the IPICS Server have any kind of file-integrity assurance program like, for example, Open Source Tripwire?

Cisco Answer

Question 8: Is the “Cisco Security Agent” provided at no cost for the IPICS Server, or is there an extra cost for this piece of software “protection?”

Cisco Answer

Question 9: The IPICS Server uses the IBM Informix database. According to documentation, IPICS Server 2.1(1) uses IBM Informix Dynamic Server Version 10.00.UC1. In 2008 several vulnerabilities were released concerning Informix, such as CVE-2008-0949, CVE-2008-0727, CVE-2008-0768 , CVE-2008-0369 , and CVE-2008-0368. If applicable to the IPICS Server 2.1(1) and earlier versions, have these vulnerabilities been addressed and patched in the IPICS Server? There seems to be nothing at the Cisco PSIRT site addressing these vulnerabilities. Am I missing something here?

Cisco Answer

Question 10: For IPICS Server 2.1(1), please provide a listing of all installed RPM packages, their version, and indication of known vulnerabilities in each RPM package.

Cisco Answer

As with my previous five (as yet unanswered) questions, I thank you and look forward to your answers.

Shawn Merdinger
Security Researcher

AST-2008-010 - IAX2 ‘POKE’ RESOURCE EXHAUSTION

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

AST-2008-011 - IAX2 FIRMWARE PROVISIONING SYSTEM

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:
asterisk, security, asterisk security, iax, voip, voip security, digium

Please note - We are contemplating some new projects:

1. Global Test Bed Project

2. End-Point Security Project

3. Secure IMS Billing Project

4. Privacy Commerce Project

If your organization might be interested in participating

please send a note of interest directly to secretary@voipsa.org

As I’ve been working for some time on a whitepaper and presentation entitled “Emergency Communications Infrastructure: Asking The Difficult And Dangerous Questions” — I figured that the time has come to directly ask vendors some of the many questions I have as I’ve read through product literature, release notes, independent evaluations, journal coverage, and the like….even a little IPICS YouTube action.

So, I was very surprised when the email I sent to ipicsasktheexpert@cisco.com bounced (screenshot here!) Rather than go through the various emails and personnel to actually get a response or email address that worked for contacting the Cisco IPICS Expert, I figured I would provide the IPICS Expert the opportunity and privilege to answer my questions in a public forum such as VOIPSA’s Blog, as well as let the community know when they fixed their email address. As the IPICS is a solution, I have focused first on the “heart” — the IPICS Server, described by Cisco Systems as:

A security-enhanced, Linux-based platform that provides an administration console and resource management and hosts the optional Cisco IPICS Policy Engine and Operational Views applications.

Below are the questions. Cisco Systems’ IPICS Expert may either answer the questions in this post’s comments sections or email me the answers. If people in the community have IPICS solution questions, please add them to the comments or email them to me and we’ll get the questions posted on the VOIPSA Blog in the next batch, or the one after, or the one after….you get the idea.

Question 1: The IPICS Server is described by Cisco Systems as “Security Enhanced” — please provide a formal, technical definition for this term.

Cisco Answer

Question 2: On each network interface, by default what TCP ports are open across the 1-65535 range?

Cisco Answer

Question 3: On each network interface, by default what UDP ports are open across the 1-65535 range?

Cisco Answer

Question 4: On IPICS Server 2.1(1), what type and version Web server is running?

Cisco Answer

Question 5: Has this IPICS Server 2.1(1) Web Server version or type changed from previous versions of IPICS Server software?

Cisco Answer

Thank you and I, as well as others I’m sure, look forward to your answers.

Shawn Merdinger

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:
ari takanen, voip, security, voip security, itworld, codenomicon

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)

Keynote
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

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

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 VoiceVerified.com 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:

• If you are a Facebook user, go to: http://apps.facebook.com/calliflower/conf/show/34614 You’ll be prompted to install the “Calliflower” Facebook app.

• If you don’t use Facebook - or don’t want to install the app, you can go to Calliflower.com at: http://apps.calliflower.com/conf/show/34614 You’ll need to register for a free account.

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 Saunderslog.com 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:
voiceverified, voice, voip, voip security, security, authentication, squawk box