Voice of VOIPSA

So today VoIPshield Laboratories announced the discovery of over 100 security vulnerabilities in systems from Avaya, Cisco and Nortel and, somewhat predictably, this has already resulted in coverage from the Wall Street Journal BizTech blog and InfoWorld’s Security Watch blog. I will expect to see more coverage in the days ahead as it works its way out into the mainstream media. The news release is a good one and includes great quotes from Gartner’s Lawrence Orans and our (VOIPSA) own Jonathan Zar.

VoIPshield has disclosed all the vulnerabilities to the vendors and has made 44 of the vulnerabilities available at www.voipshield.com/research (That is the number I currently see on the page.)

I should note that VoIPshield Systems, under whom VoIPshield Laboratories falls, is a member of the VOIPSA Technical Board of Advisors. I also have met the VoIPshield folks several times and Jonathan and I interviewed CTO Bogdan Materna eons ago back on Blue Box podcast #12. We’ve been on panels together and I have a high degree of respect for what they are doing and how they are doing it.

This familiarity, though, does not prevent me from feeling a bit uneasy about two aspects of this announcement today. First, if you look down the list of vulnerabilities in almost all cases (41 of 44) the vendor response state is “Attempting to address the issue“.

In other words, these are current, open vulnerabilities. No patches. No fixes. (Outside of the stated recommendation to follow network security best practices and potentially to purchase a VoIP security product such as the one VoIPshield makes.)

Now in many cases the vulnerability announcements are sufficiently vague that an attacker is not going to be able to do a whole lot with them. However, in other cases, there’s enough information there to point the way for an attacker. For instance, this one for Cisco for “UCM Multiple Hardcoded Passwords” indicates:

Description

By knowing and using the hardcoded account names and passwords (a total of three have been identified) on the UCM platform, an attacker can connect to the system and issue database commands which can result in code execution, denial of service, license exhaustion or theft, etc.

So now we know there are three account names (at least) with default passwords that can be used to administer a Cisco UCM system. How long will it be now before someone sitting there with a brute-force password script will figure out those names and post them to one of the various default password lists out there?

Now, this particular vulnerability announcement does state:

Cisco acknowledges the presence of these hardcoded passwords and is working to have the values set to an administrator definined setting during installation.

This will undoubtedly involve a new release of the software (since it refers to the installation process). That will take some time, obviously, and in the meantime any Cisco Unified Communications Manager installations out there are potentially vulnerable to abuse through these hardcoded usernames and passwords.

I understand that VoIPshield did contact these vendors and at least per the WSJ article gave them at least 30 days notice. I also realize that vendors may not always be able to create quick solutions and also may not assign the same priority to issues (or may in fact dispute/dismiss the issue). Having been on the vendor side, I well understand the dynamics of working with security research firms. I know there can be challenges on both sides. Still, I personally would have been a lot more comfortable with seeing this information out there if they had waited a bit until more than just 3 of the 44 listed vulnerabilities have vendor patches available.

Which brings me to my second concern. The vulnerability notices posted do not include any “mitigating circumstances”. They state the description of the problem and offer the recommendation to use network security best practices and VoIP security products such as those sold by VoIPshield, but they do not provide a sense of how to evaluate the risk involved. For instance, with the hardcoded passwords, I am assuming the attacker needs to be on the internal network, but is that correct to assume? With the DFR Cancel Backup Command Injection vulnerability, does the attacker need to be on the internal network? Or could they be on the public Internet? (if systems traversed the Internet)

Now perhaps VoIPshield is waiting to provide this type of information until there is a fix out there. This is also their first time issuing public vulnerability notices in this form. Perhaps with feedback such as this they will provide that added information. But without that kind of information, it’s not clear to me that I have enough information to understand the potential risk to my systems. (And perhaps we’ll have to have them on a podcast to talk about all of this.)

Regardless of these two concerns, the fact remains that VoIPshield Laboratories has entered the space as a new research entity and has already brought out a wealth of research. Per their news release, this is just the first step and more information will be coming soon. That all is good to hear as having such research groups focusing on the VoIP security space is a definite good thing. We need more research in the field and so it’s great to see VoIPshield entering the space publicly. (They’ve obviously been doing this research privately for their products for some time.)

And, if you are the administrator of a system from Avaya, Cisco or Nortel, I would strongly encourage you to review the vulnerabilities and try to understand which of them may or may not affect your installations.

Technorati Tags:
voip, voip security, security, cisco, avaya, nortel, voipshield

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:

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.

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…

Want to learn more about the voip security aspects of peer-to-peer SIP? As I mentioned in the VOIPSEC mailing list last week, researchers from Huawei and the University of California recently released an Internet-Draft called “P2PSIP Security Analysis and Evaluation” which dives into an analysis of security issues in P2PSIP. It’s a good overview and one I’d strongly recommend to folks. (Note - you may want to read “P2PSIP Concepts” first to understand the language being used.)

Beyond the Internet-Draft, though, the researchers announced yesterday that their slides are now available (PPT) that go into the issues. These are being prepared from presentation at the upcoming IETF 71 meeting March 10-14 in Philadelphia, so if you are attending the event you’ll be able to hear the presentation yourself.

Peer-to-peer SIP is a fascinating area of current research and it’s good to see work like this being put into exploring the security aspects. Note - the researchers are looking for feedback so if you have comments on what you read, their contact information is in the Internet-Draft.

Technorati Tags:
SIP, IETF, security, voip security, SIP security, p2p, p2psip, peer-to-peer

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.

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.

We were contacted today by Takehiro Takahashi, a graduate research student at the Georgia Institute of Technology, who has an intriguing new research project they called “Voice over VoIP”.  From their main web page:

Vo²IP is a proof of concept attack which demonstrates a new type of VoIP threats, the VoIP covert channel. With Vo²IP, you can establish a hidden conversation by embedding further compressed voice data into regular PCM-based voice traffic (i.e. G.711 codec). Therefore anyone who is wire-tapping your conversation will decode something completely different from the actual conversation - granted that he is not aware of the use of Vo²IP.

As I understand it, they basically take a G.729 audio stream and tuck that into a spare 8Kbps that can be found in a G.711 audio stream.  An eavesdropping attacker would hear only the overall G.711 audio while the Vo2IP clients on either end encoded/decoded the covert stream (more details here and here). In any event, Takehiro and his fellow researchers would be very interested in any feedback folks have on the project.  Source and binary code for Windows is available. Please email Takehiro with any feedback.

One of the highlights of 3GSM Barcelona for me was visiting NEC at their stand, and to see their demonstrations in action. There was some discussion in the VoIP and security space over the last weeks about a server technology called VoIP SEAL that NEC were to demonstrate at the show, and I was keen to see this in action. VoIP SEAL is a system that attempts to defend a VoIP system against VoIP SPAM or SPIT (SPAM over Internet Telephony).

Luckily, at the time I visited the stand, Saverio Niccolini of NEC was there. Saverio is a prominent researcher for NEC, and was a speaker at the 3rd Annual VoIP Security Workshop last year, which I attended and wrote about here. It was great to meet up with Saverio, and he showed me the VoIP SEAL demo himself.

To briefly summarize the system, VoIP SEAL combines a number of different techniques to detect a suspicious VoIP call. Each module does a test and produces a score or index, and at the end the indices are weighted and combined to give an overall score that measures how ‘dangerous’ a call might be. For example, there are modules that can apply blacklist or whitelist logic; measure SIP INVITE rates; test reputation or check that different SIP URIs are not coming from the same IP address. So, each module is dedicated to measuring for a particular exploit or security aspect, and they can be combined in different ways, with different weights.

An interesting part of VoIP SEAL is that it can apply tests in two phases: firstly before answering the call and then after picking up. In the first phase, the ‘suspiciousness level’ of a call can be assessed, and if the level is low, the second phase can be skipped, simply connecting the call to the recipient. However, if the level passes a configured threshold, the call is diverted to a specialized answer machine that can apply further tests. Having this two-phase approach helps to minimize false positives, where genuine human callers get trapped in the system and can’t get through.

In phase 2, VoIP SEAL can measure the speech energy when a greeting or outgoing message is being played. For a genuine human caller, this energy should be low, as humans tend to listen rather than talk over greetings. A bot or SPAM application will behave differently, perhaps starting to stream audio continuously as soon as the media channel is available. There are more sophisticated audio CAPTCHA tests (Turing Tests) that can also be applied to attempt to tell the difference between a human and a bot. If the call is considered suspicious, it can just be allowed to play its message into a voicemail SPAM queue, and perhaps this queue would be periodically reviewed by an administrator to make sure that the VoIP SEAL was working effectively and not trapping too many real human callers.

If you want to hear more about VoIP SEAL, I recorded an interview with Saverio where he explains it in more detail. This interview will be coming up in a future edition of the Bluebox Podcast, run by two of our VOIPSA Chairs, Dan York and Jonathan Zar.

On the Infoworld Zero Day Security page, Garza talks a little about the VoIP Phreaking session at the Black Hat conference, which is on right now in Las Vegas.  I’m looking forward to the promised podcast with The Grugg, who led that class.

On the Black Hat website is an archive of presentations from previous conferences, and the ones from the current conference should pop-up there in the coming weeks. 

News broke last week about Session Border Controller manufacturer Newport Networks, which has run into cash-flow problems waiting for deals to close.  Newport Networks was started by serial entrepreneur Sir Terry Matthews, reportedly Wales’s first billionaire, who also founded Newbridge (now part of Alcatel) and Mitel.

Last year Newport were lined up to supply their 1460 Session Border Controller to troubled equipment supplier Marconi.  Marconi themselves failed to become prime NGN suppliers to British Telecom, which ultimately resulted in the failure of the company.  The rump of Marconi has now been absorbed into Ericsson.

Newport have announced layoffs, as reported at ZDNet and in the UK Guardian Newspaper, in an attempt to reduce cash burn while waiting for the business to arrive.  It’s ironic with CALEA in the headlines and telcos rolling out NGNs that a provider of the enabling technology should have run onto the rocks.  Let’s hope the Newport investors can keep their nerve.