Voice of VOIPSA

Wikileaks recently published a leaked 88 page document entitled FBI Electronic Surveillance Needs for Carrier-Grade Voice over Packet (CGVoP) Service (PDF), which is part of the CALEA Implementation Plan published in January 2003. The document describes detailed FBI requirements for surveillance of phone calls made utilizing packet networks as their transport. The document broadly defines CGVoP Service as:

“The set of subscription-based voice services and features provided over carrier-managed packet networks, and includes wireline and wireless services.”

The document covers such surveillance events as:

• Registration and Authorization events including address registration and de-registration, mobility authorization and de-authorization
• Call Management events including call origination, termination, answer, call release, address resolution, admission control, and media modification
• Signaling events including subject signaling, network signaling, and post-cut-through dialing and signaling
• Feature Use events including call redirection, party hold, party retrieve, party join, party drop, call merge, and call split
• Communication Content events including content delivery start, change, and stop, as well as content unavailable
• Feature Management events including feature activation and deactivation
• Surveillance Status events including surveillance activation, continuation, change, and deactivation.

The document also discusses authorized access to identifying information and communication content, and more generalized surveillance requirements. It looks like they’ve fairly well covered the bases…

One of the issues with VoIP endpoints that I regularly encounter as a security researcher is the problem with underpowered hardware. Many VoIP hardware devices are initially designed with just enough horsepower to do their job in order to keep costs low and stay competitive in the market. Due to VoIP technologies evolving so rapidly and devices being updated to include many additional new features shortly after being brought to market, the software running on these devices generally outgrow the hardware and will consume the few remaining unused resources available on the device. Vendors then have to play a balancing game of what software features can be crammed onto a particular device and it still work properly.

Not only does this condition of the technology promote attacks like Denial of Service via resource exhaustion, floods, and so forth, but it also gives rise to other vulnerabilities such as this one which was detailed yesterday by Larry Dignan & George Ou. Due to the resource limitations of the hardware device, corners were cut when adding support for the device’s 802.1x PEAP authentication feature which resulted in the server certificate not being checked during authentication, which then devolves into a number of other security issues. Not only does this affect the device being discussed in the article, but it apparently also affects a number of other devices as well who’s designers cut the same corner, likely for the same reason.

Because VoIP technology evolves so rapidly, and generally grows in resource requirements by leaps and bounds while doing so, VoIP hardware vendors really should be providing much more processing power than the initial software needs when the devices are brought to market. Unfortunately the cost of including this extra horsepower initially is borne by the vendor, whereas the cost of having to upgrade (i.e., replace) masses of deployed hardware devices when their resource limitations become insurmountable is borne by the consumer.  Device replacement results in additional sales and profits for the vendor, so don’t expect properly resilient hardware devices anytime soon…

Yesterday, Cisco released an advisory detailing a number of vulnerabilities which covered most recent versions of their IP phones, essentially the “Unified IP Phone” set of products, running both firmwares for SCCP and SIP. The covered vulnerabilities include a DNS Response Parsing Overflow, a Large ICMP Echo Request DoS, an HTTP Server DoS, an SSH Server DoS, a SIP MIME Boundary Overflow, a Telnet Server Overflow, and a SIP Proxy Response Overflow. Essentially, a wide range of vulnerabilities covering a number of the devices’ services and functionality.

While it’s good that Cisco is actively taking steps to improve their products and are actually informing customers and the security community about the device’s security issues via security advisories, the scope and number of vulnerabilities involved in this one advisory seems to still be fairly indicative of the state of security for new VoIP products hitting the market, especially user agents and client devices. It would seem that as the rush continues for VoIP innovation and a quick to market product, much of these products’ security assessment due-diligence, not to mention many of their security features, are still being left in the dust…  Or at best, left for a firmware or software update post-launch.

Building upon a previously reported (and still un-patched!) vulnerability in the BT Home Hub which allows HTTP authentication to be bypassed, the folks over at GNUCitizen recently announced a way to leverage that vulnerability to cause the Hub to steal or hijack VoIP calls if the BT customer is also using the BT Broadband Talk service:

If the victim visits our evil proof-of-concept webpage, his/her browser sends a HTTP request to the BT Home Hub’s web interface. After this, the Home Hub starts a VoIP/telephone connection to the recipient’s phone number specified in the exploit page. This is what the attack looks like: the victim’s VoIP telephone starts ringing and shows an external call message on the LCD screen along with the recipient’s phone number. However, what’s interesting is that from the point of view of the victim, it looks like he/she is receiving a phone call from the number shown on the screen, but in fact he/she is calling that number!

At the heart of the vulnerability is the fact that to the victim it appears that they are receiving a call when in fact they are actually the party placing the call. Essentially, this vulnerability can be leveraged to perform a number of attacks utilizing the BT Home Hub, such as annoyance or prank calls like the scenario described above where two unwitting people believe that each has called the other when they are connected, advanced phishing attacks such as causing the user to believe their Bank has called them, or even toll fraud in some cases where the user could be made to call pay services.

For users of the BT Home Hub and Talk Service, you can demo the exploit for yourself by visiting GNUCitizen’s Proof-of-Concept web page.

McAfee recently published their top ten threat predictions for 2008. Among the other threats, attacks against VoIP systems were predicted to rise by 50% in 2008:

VoIP attacks should increase by 50 percent in 2008. More than twice the number of VoIP-related vulnerabilities were reported in 2007 versus the previous year - several high-profile “vishing” attacks, and a criminal phreaking (or fraud) conviction - so it’s clear that VoIP threats have arrived and there’s no sign of a slowdown.

I’ve long been a staunch opponent of the “isolate your VoIP network from your data network” strategy. I personally believe that by putting up such restrictive barriers as would be required to provide any sense of actual security, the owners and administrators of a VoIP deployment are severely limiting the potential value they are able to receive from using Internet telephony. One of the Great Promises of VoIP is the ability to integrate communications with other productivity technologies such as work-group software and CRM applications. A lot of VoIP security practitioners tout the isolation strategy as a solution for the insecurity of the VoIP core devices and endpoints when in reality it is little more than a stop-gap, and not a very good one at that. By providing a false sense of security by way of network isolation, many VoIP deployment administrators may become complacent and pay less attention to the security posture of the actual VoIP devices and endpoints themselves. If you plan to integrate your communications system into the data-flow of your business in even the most minimal way, you’ll find quickly that most types of isolation that are available either provide a barrier to the desired functionality or open up so many holes in the barrier that it may as well not be there.

(more…)

There were a number of new tools released at the recent BlackHat and DEFCON conferences that I’ve just finished adding to the VoIPSA Security Tools List.

First, during the BlackHat Voice Services Security track, Himanshu Dwivedi & Zane Lackey spoke about attacks against H.323 and IAX. They released a number of tools including H225regreject, IAXHangup, IAXAuthJack, and IAX.Brute. Now you can easily launch many of the same attacks (as well as a few new ones) that you’ve known and loved from attacking SIP against both H.323 and IAX.

Next, Zane Lackey & Alex Garbutt debuted their RTPInject tool during the BlackHat turbo-talk track. It’s essentially a nice, pretty, easy to use GUI version of the RTP audio injection attack that I demoed last year at EUSecWest using the rtpinsertsound and rtpmixsound tools.

At DEFCON, Ian G. Harris released a tool called INTERSTATE which is a stateful protocol fuzzer for SIP.

Finally, I released my new RTP steganography tool, SteganRTP, at DEFCON. It uses steganographic data embedding techniques to create a covert channel in an RTP session’s audio payloads which it uses to transport it’s own custom communications protocol. The protocol provides user chat, file transfer, and remote shell access (if enabled).

All of the tools mentioned above can be found via the VoIPSA Security Tools List.

The Truth in Caller ID Act of 2007 (HR 251) passed in the U.S. House of Representatives on June 12th. It’ll be interesting to see if it makes it through the Senate this time, as last Congress the Senate basically sat on it until it was dropped at the end of the 109th Congress as not having passed.

If you’re interested in tracking this (or any other) bill as it makes it’s way through the U.S. Legislation process, I’ve found GovTrack.us to be invaluable.

According to the New York Times, it appears as if consumers in Italy are rapidly moving toward encryption for voice technologies due to rampant publication of private conversations, both due to leaked conversations that were a result of government wiretaps as well as conversations recorded through private means. From the article:

What has spurred encryption sales is not so much the legal wiretapping authorized by Italian magistrates–though information about those calls is also frequently leaked to the press–but the widespread availability of wiretapping technology over the Internet, which has created a growing pool of amateur eavesdroppers. Those snoops have a ready market in the Italian media for filched celebrity conversations.

It would seem that in Italy, it’s fairly common to take someone’s private conversations straight to the press… Even the national telco’s head of Security was in on the game:

This year, Bonini’s name was among thousands that surfaced in an illegal-wiretapping scandal involving employees of Telecom Italia, the Italian phone company.

Twenty people were arrested, including the former chief of Telecom Italia security, in what investigators say was an attempt to use the intercepted phone conversations to blackmail Italian public figures.

Many of the cell-phone encryption products mentioned in the article that are being marketed to Italian consumers sound a lot like Zfone, essentially providing end-to-end encryption for the audio between two devices that run the encryption software in advance of the call.

In case anyone missed it, the Truth in Caller ID Act (now of 2007!) was re-introduced in the House as HR 251 on January 5th. The Senate’s version of the previous bill never passed during the 109th Congress, so here we go again… While re-reading through the bill however, I noticed something interesting that I hadn’t noticed before:

`(1) IN GENERAL- It shall be unlawful for any person within the United States, in connection with any telecommunications service or VOIP service, to cause any caller identification service to transmit misleading or inaccurate caller identification information, with the intent to defraud or cause harm.

By specifically naming VoIP service separately from other telecommunications services, and then subsequently defining what a VoIP “service” is:

`(C) VOIP SERVICE- The term `VOIP service’ means a service that–

`(i) provides real-time voice communications transmitted through end user equipment using TCP/IP protocol, or a successor protocol, for a fee or without a fee;

This ammendment seems to very specifically preclude any communications that take place on the Internet or any other “non-telecomunications” network that isn’t transmitted via both IP and TCP, or any successor protocols of IP and TCP used in conjuction that may follow them.

Now, I’m no lawyer by any stretch of the imagination, but that seems fairly clear to me. If true, that precludes Caller-ID information transmitted via any other transport protocol running within IP, or otherwise, from being affected by this law. Does that mean that if my signaling traffic happens to be UDP, as many of the protocols either are or allow, that it is then not subject to this law? I wonder if the tech-savvy, or lack thereof, of the U.S. Legislature may be introducing a nice convienient loophole for an attacker’s attorney to exploit when going to trial… birds of a feather after all.

Series of tubes, indeed.