Voice of VOIPSA

In the 80s movie “The Color of Money” there’s a great scene where a player challenges Tom Cruise’s character to a game. He strolls up to Vincent and says “So what you got in there?” — to which Vincent replies. “Doom.”

This is akin to how I felt a few weeks ago after I finally got ahold of a Nokia N900 smartphone. Calling it a phone is a bit of a stretch, as it is primarily a Debian Linux tablet with impressive hardware specs and a huge number of .deb packages available for installation…oh, and you can make cellular phone calls with it. Many people use this phone, and despite some glitches it is rapidly developing into a formidable platform for security tools and penetration testing.

Broadly speaking, the objective of this series of blog posts is to introduce folks to the tools available and the potential for this phone as a security testing platform. Given the fact I’m a bit late in obtaining this phone, some smart people out there have already started to address the n900′s capabilities and available tools, and I would be remiss not to mention, and build upon, their insightful work. The key phrase here is “build upon” and get the word out, not to steal or simply re-hash their fine work and efforts!

I’ve one caveat to this series of blog posts. As my n900 is for now a “production phone” for me in that I need to use it and can’t brick it just yet, the path of this blog series on “Weaponizing the Nokia N900″ will progress from known, tested and functioning security tools on this phone — and therefore lower risk of bricking — to more advanced, edgy tools that require more tweaks and modifications, such as replacing the stock kernel. If someone out there finds this series useful, and has interest in furthering research on running security tools on the n900, I’d welcome the donation of a n900 for development and testing, and would credit them for their support. Please ping me offline if you’re interested

NeoPwn and the Nokia N900

One project to watch in particular is the upcoming release of NeoPwn, which is based on BackTrack and bills itself as the “First Ever Network Auditing Distribution for a Mobile Phone Platform” and is due for release sometime this month, hopefully before DefCon. I am fortunate to be in the BETA and will write up a blog post for this series on NeoPwn once I get full access to the NeoPwn toolset.

Worthy Resources on Nokia n900 Security Tools

1. Metasploit on the Nokia n900. ‘Nuff said.

2. knownokia.ca Blog SimonLR wrote an excellent post on “Using the N900 for Fun and Profit” that covers several awesome tools, such as Metasploit, Dsniff, SSLstrip, Aircrack-NG, etc. He’s clearly savvy and his future blogging on tools for the n900 will be great to see.

3. Asterisk on the n900

When I added the extra package repositories to my n900, I was more than a bit surprised to see a full version of Asterisk available as a .deb package. Wow. Think about this for a moment. One can run a full Asterisk server on a phone in their pocket. The capability of Asterisk on the n900 could enable attackers to do all sorts of mischief, such as running the SPITTER tool from their pocket as a simple example. From a surveillance aspect, think of “bad people” with n900s in their pockets running Asterisk servers on their phones and connecting to each other point-to-point over encrypted tunnels — now that’s a challenge.

Stay tuned for more posts on “Weaponizing the Nokia N900″

This is a guest post from Andy Zmolek, Senior Manager, Security Planning and Strategy at Avaya, and past participant in VOIPSEC mailing list discussions and other VOIPSA activities. Andy asked if I could publicize this because he believes it is a discussion which we in the security community need to have.

Text by Andy Zmolek of Avaya:

Is it appropriate for a security research firm to require payment from a product vendor prior to detailed vulnerability disclosure? I received the following notification this morning from the CEO of a VoIP security startup:

“I wanted to inform you that VoIPshield is making significant changes to its Vulnerabilities Disclosure Policy to VoIP products vendors. Effective immediately, we will no longer make voluntary disclosures of vulnerabilities to Avaya or any other vendor. Instead, the results of the vulnerability research performed by VoIPshield Labs, including technical descriptions, exploit code and other elements necessary to recreate and test the vulnerabilities in your lab, is available to be licensed from VoIPshield for use by Avaya on an annual subscription basis.

“It is VoIPshield’s intention to continue to disclose all vulnerabilities to the public at a summary level, in a manner similar to what we’ve done in the past. We will also make more detailed vulnerability information available to enterprise security professionals, and even more detailed information available to security products companies, both for an annual subscription fee.”

I would like to solicit opinions about what appears to me to be a new challenge to infosec industry best practices. For those of you who work for software or equipment vendors, have you ever received similar notices from legitimate security researchers? Does anyone here believe the practice of equipment vendors making payments to security researchers in order to receive details about potential exploits is an acceptable business practice?

For infosec professionals, would you be comfortable purchasing services from a security research firm that follows such a policy?

NOTE from Dan York: In an effort to get VoIPshield’s perspective, I attempted to reach CEO Rick Dalmazzi but could only get his voicemail. (Perhaps because it is Canada Day and they are in Ottawa.) Andy Zmolek informed me on a call today that he had emailed Rick this morning asking when VoIPShield would be updating their Vendor Disclosure Policy (dated Nov 2007) that is on their Vulnerability Advisories page, as this email from Rick represents a significant departure from that stated policy. I also called the number of the PR contact listed on VoIPShield’s website but that extension went to a “general delivery” mailbox.

This post will be updated with information from VoIPShield Systems when such information can be obtained.

Technorati Tags:
voip, security, voipsecurity, voipshield, avaya

This is a neat trick. By doing a little up-front scanning and/or guesswork, an attacker can send an INVITE directly to a SIP user agent, causing the device to ring.  Then, when the user agent issues the BYE message to hang-up, the attacker can respond with a 407 Proxy authorization required message, causing the endpoint to then respond with it’s authentication credentials, essentially handing them directly to the attacker.

The page linked above indicates that this attack is currently implemented in the VoIP Pack for CANVAS, so it’s essentially packaged and ready to use for you CANVAS users.  You can see a video of this being used in CANVAS here.  I would expect to see this credential-harvesting attack in other exploitation frameworks or stand-alone tools shortly…

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.

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.