Author Archives: Dustin D. Trammell

The Truth in Caller ID Act

Well, it only took about five years and three sessions of Congress to finally pass this thing in both the House and the Senate.  The Senate passed their version of the bill (S. 30) on February 23rd and the House passed their version of the bill (H.R. 1258) on April 14th.  All that remains now is for any differences in the two bills to be reconciled and sent to the President for a signature.

Skype Trojan Records Your Calls

Apparently there’s a new piece of malware floating around that targets audio processors like Skype:

The Trojan has the ability to record audio from the computer — including any Skype calls in progress — and store the files locally in an encrypted MP3 file, where they can later be transmitted to the attacker.

The Trojan, which Symantec calls Trojan.Peskyspy, can be downloaded to a computer by tricking the user with an email scam or other social engineering tactic, Symantec says. Once a machine has been compromised, the threat can exploit an application that handles audio processing within a computer and save the call data as an MP3 file.

Tricking SIP Endpoints Into Divulging Authentication Credentials

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…

Truth in Caller ID Act Update

Welcome to the 111th United States Congress!  On January 7th, the bill that never made it through the Senate in the last Congress has been reintroduced as S. 30, the Truth in Caller ID Act of 2009.  It was apparently read twice and referred to the Committee on Commerce, Science, and Transportation.  It’s now got two more years to attempt to make it through the Senate and get signed into law…  Is anyone else as skeptical as I am that it’ll actually happen?  Remember, this bill started as the Truth in Caller ID Act of 2006.

Judge Rejects Feds’ Attempts to Eavesdrop On DTMF Without a Warrant

Score one for sanity.  Apparently the FBI believed that while eavesdropping on the audio of a conversation required a warrant, capturing any DTMF transmissions sent during the call did not.  From the CNet report:

Just about everyone knows that the FBI must obtain a formal wiretap order from a judge to listen in on your phone calls legally. But the U.S. Department of Justice believes that police don’t need one if they want to eavesdrop on what touch tones you press during the call.

Those touch tones can be innocuous (“press 0 for an operator”). Or they can include personal information including bank account numbers, passwords, prescription identification numbers, Social Security numbers, credit card numbers, and so on–all of which most of us would reasonably view as private and confidential.

That brings us to New York state, where federal prosecutors have been arguing that no wiretap order is necessary. They insist that touch tones cannot be “content,” a term of art that triggers legal protections under the Fourth Amendment.

China’s TOM-Skype Surveillance

According to a report published on October 1st by Citizen Lab, full chat text messages from TOM-Skype users were found on publicly-accessible web servers as well as the encryption key required to decrypt the data.  Additional data such as millions of IP address, user names, and land-line phone numbers, and records of international users who regularly communicated with Chinese users were found alongside the chat logs.

From an Ars Technica article about the report:

Clearly, there are a number of problems with this discovery, starting with security. Villeneuve notes that the information contained on the servers could be used to exploit the TOM-Skype server network, and an attacker can access detailed user profiles. “In fact, evidence suggests that the servers used to store captured data have been compromised in the past and used to host pirated movies and torrents (for peer-to-peer file sharing),” reads the report. Clearly, crafty hackers already know where these servers are and how to get into them.

While troubling from an overall Skype security standpoint, it’s not much of a surprise that the Chinese government had a way to monitor their Skype users, especially with Skype being partnered with TOM Online, a Chinese company.

Since around September 2005, Chinese users attempting to download the Skype client were blocked from doing so, instead being redirected to a modified Chinese version hosted by TOM.  Did anyone really think that this modified version wasn’t backdoored?  Who wants to bet that they have keys to decrypt the voice channels as well?

LinkedIn to VoIPSA

I would like to invite any VoIPSA LinkedIn users to join the new LinkedIn VoIPSA group.  While we already have documentation on the website regarding the Board of Directors and the Technical Board of Advisers, there wasn’t really much in the way of identifying and networking with other members of our organization who are not on either of these boards, other than of course the VoIPSec mailing list (which doesn’t have a public membership roster), so I’ve established this group to fill that void.

Variable Bitrate Compression Flawed

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.

FBI VoIP Surveillance Requirements Leaked

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…

Underpowered Hardware

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…