Some researchers over at Johns Hopkins University have discovered that due to the way Variable Bitrate Compression does it’s thing, even if the audio stream is encrypted it is still possible to determine entire words and phrases based on the lengths of the packets with a high degree of accuracy.
According to the article referenced above it appears that the proof of concept tool is fairly limited, but given a little time and additional effort it’s capabilities could be greatly expanded, potentially to the point of transcribing entire conversations.
The researchers’ paper was presented at the 2008 IEEE Symposium on Security and Privacy a few weeks ago.
While most VoIP-related vulnerabilities are posted to the VOIPSA mailing list or blog, I thought it might be useful to have a informal quarterly summary of sorts among VoIP devices per searches from NIST. I hope folks find it helpful, and of course post comments if I’ve overlooked anything from 1 January 2008 through 31 March 2008.
- CVE-2008-0531 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
- CVE-2008-0530 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
- CVE-2008-0529 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
- CVE-2008-0528 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
- CVE-2008-0527 Cisco Unified IP Phone 7935 and 7936 2/14/2008
- CVE-2008-0526 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
- CVE-2008-1113 Cisco Unified Wireless IP Phone 7921 3/3/2008
Routers & Gateways
Cisco Call Manager
- CVE-2008-0026 Cisco Unified CallManager/Communications Manager 2/14/2008
- CVE-2008-0027 Cisco Unified Communications Manager 1/16/2008
Milw0rm 5113 Philips VOIP841 PC-Free DECT 6.0 Wireless IP Phone 2-14-2008
An interesting paper recently published by Adrian Pastor of ProCheckup discusses vulnerabilities and attacks against ZyXEL gateways, including (yikes) Remote wardriving/attacking internal networks over the Internet, among others:
Privilege escalation from “userâ€Ÿ to “adminâ€Ÿ account
SNMP read and SNMP write access enabled by default
Persistent XSS via SNMP
Poor session management allows hijacking of admin sessions
Authentication vulnerable to replay and password cracking attacks
Disclosure of credentials
Considering the code reuse among various products made by most vendors of these residential gateways, not to mention the widespread deployment by service providers, I think it would be quite interesting for VOIPSA folks to expand on Adrian Pastor’s work and pursue this type of testing on some of the VoIP gateway products that ZyXEL offers, specifically the Analog Telephone Adapter, Station Gateway and Integrated Access Device to start. Also, the web interface of embedded devices like these are especially problemmatic from a security perspective, and it’s well worth a look at another one of Adrian Pastor’s papers over at OWASP.
“So what” you might say about the security of these types of devices? Well, SANS diary notes some strange things afoot at the Circle K with Dlink, and there is the recent BT Home Hub CVE-2008-1334 vulnerability. More routers and details at GNU Citizen’s router hacking challenge.
Earlier this week, the team at Digium released four new security vulnerabilities:
The solution is, predictably, to upgrade to the latest version of whichever stream of Asterisk you are using.
asterisk, asterisk security, security, voip, sip, sip security, voip security
Over on Bugtraq, another Asterisk vulnerability has been announced. Several buffer overflows affect the below version:
Package / Vulnerable / Unaffected
1 net-misc/asterisk = 1.2.17-r1
This one comes with an admonishment to upgrade to the latest patch:
All Asterisk users should upgrade to the latest version:
# emerge –sync
# emerge –ask –oneshot –verbose “>=net-misc/asterisk-1.2.17-r1”
This is the link to the announcement at Gentoo Linux. I was hoping to find the link to the actual patch over at Asterisk, but I don’t see the right reference yet. The CVE #’s are all from 2007, but the announcement seems to be from 2008. If anyone finds the link, drop me a line or leave it in the comments.
On a minor note, the Nortel Networks UNIStim IP Phone with firmware version 0604DAS is vulnerable to a ping of death. No patch yet, but keep your eye on Nortel’s Security Advisory site for a response from the company.
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.
Many of you probably have seen Sipera’s Top 5 VoIP Security threats for 2008.
VoIP-News has an article about that list, but they have added quite of few links that provide further information.
[If anyone saw the previous post before it got deleted, I apologize. I didn’t recognize the list until after I published the post]
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.
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.