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.
Back on August 22nd, Radu State from the Madynes research group in France posted a security advisory to the VOIPSEC mailing list, “Remote eavesdropping with SIP Phone GXV-3000“. He also posted it to full-disclosure and several other lists. As he writes:
While playing with the SIP Madynes stateful fuzzer, we have realized that some SIP stack engines have serious bugs allowing to an attacker to automatically make a remote phone accept the call without ringing and without asking the user to take the phone from the hook, such that the attacker might be able to listen to all conversations that take place in the remote room without being noticed.
The Madynes team also included the perl exploit script in the advisory as well, enabling someone wishing to test this to easily execute the attack. They indicate that they have found this vulnerability in several SIP stacks and that they can disclose the vulnerability with the Grandstream phone as Grandstream was apparently notified of this issue back in May. They indicate that “fixed software will be available from the vendor” – however as of today, Grandstream’s firmware page is still showing the same load as that found to be vulnerable by the researchers. Unless I missed it, I can’t seem to find any page on Grandstream’s site dealing with security issues.
The reason I mention this here, partly, is because the issue was slashdotted, based on the SÃ»nnet Beskerming article “Listen to SIP Phones Even When They are on the Hook“.
If you use Grandstream phones, I would suggest you should be contacting Grandstream to find out when a fix may be available. If you a producer of SIP phones, you might want to have a look at the exploit, which seems to be fairly straightforward, and see if your phones are vulnerable.