Hack turns the Cisco phone on your desk into a remote bugging device

No fix yet for attack that allows eavesdropping on private conversations.

Internet phones sold by Cisco Systems are vulnerable to stealthy hacks that turn them into remote bugging devices that eavesdrop on private calls and nearby conversations.

The networking giant warned of the vulnerability on Wednesday, almost two weeks after a security expert demonstrated how people with physical access to the phones could cause them to execute malicious code. Cisco plans to release a stop-gap software patch later this month for the weakness, which affects several models in the CiscoUnified IP Phone 7900 series. The vulnerability can also be exploited remotely over corporate networks, although Cisco has issued workarounds to make those hacks more difficult.

"Cisco recognizes that while a number of network, device, and configuration based mitigations exist, there is no way to mitigate the physical attack vector on the affected devices," the company's advisory stated. "To this end, Cisco will conduct a phased remediation approach and will be releasing an intermediate Engineering Special software release for affected devices to mitigate known attack vectors for the vulnerability documented in this advisory."

The vulnerability is the latest reminder of privacy threat posed by today's phones, computers, smartphones, and other network-connected devices. Because the devices run on software that is susceptible to hacking, they can often surreptitiously be turned into listening—and sometimes spying—vehicles that capture our business secrets or most intimate moments.

Among other things, the hack allows attackers to monitor phone calls and to turn on the phone's microphone in order to eavesdrop on conversations within earshot and stream them over the network.

Cui demonstrated the vulnerability earlier in December. Cisco issued a patch around the same time, but in his later demonstration, Cui said it was ineffective. Cisco responded with Wednesday's advisory, pledging to rewrite the underlying firmware to "fully mitigate the underlying root cause" of the vulnerability. The advisory said that would happen in the next few months but wasn't more specific.

Cui's hack works by overwriting portions of the user or kernel space in the phone's memory. That allows him to gain root access to the phone's Unix-like firmware system and take control of the digital signal processor and other key functions.

While the hack requires physical access to the phone, it would still be possible for janitors, colleagues, or other trusted insiders to carry out the attack. Once done, a phone exhibits few indications that it has been compromised. It's not uncommon for security-conscious people to place masking tape over the video camera of their computers to prevent drive-by attacks that turn them on. Thwarting attacks that turn phones into bugging devices will be harder, since the phones can't be unplugged during calls. Welcome to the world of network-connected devices.

If physical access is available, POTS analog phones are subject to an attack in which a copper wire is wrapped around the cable. As I recall, it's called an inductive pickup and is harder to locate than VOIP packets leaving a network to an odd IP address.

I would be vastly more impressed if the hackers had found a way to compromise a UC5xx or ISR to mass upload such firmware to all the phones in the office over Ethernet. From the sounds of it, the update mechanisms built both into the VOIP distribution hardware (firewall / services routers) and the phones themselves is preventing improper, unsigned firmware from being uploaded conventionally. If physical access to the phone itself is required, the whole issue becomes academic FUD. A microphone is just as easy to put in an office and a Trojan placed on computers with microphones already built in is vastly easier.

Edit:Read the full articles linked. You need console level access to the device. The following is quite relevant and sounds a good bit like the last time I ran across an article that required some degree of administrative or root access first to accomplish an attack (emphasis mine):

Quote:

A local, authenticated attacker with the ability to place a malicious binary on the phone could leverage this issue to elevate their privileges or take complete control of the device....Workaround: Restrict SSH and CLI access to trusted users only. Administrators may consider leveraging 802.1x device authentication to prevent unauthorized devices or systems from accessing the voice network.

Yep, non issue if your VOIP subnet has remotely decent ACLs and policies in place. I hate starting the day with such FUD. The janitor should not have the root password for your Cisco hardware.

Yeah we use entirely Cisco 7900's throughout our government office. This is good news. I mean some points were good that were brought up that in the end we need to remember these things are effectively software phones and as such vulnerabilities can be found.

If physical access is available, POTS analog phones are subject to an attack in which a copper wire is wrapped around the cable. As I recall, it's called an inductive pickup and is harder to locate than VOIP packets leaving a network to an odd IP address.

I would be vastly more impressed if the hackers had found a way to compromise a UC5xx or ISR to mass upload such firmware to all the phones in the office over Ethernet. From the sounds of it, the update mechanisms built both into the VOIP distribution hardware (firewall / services routers) and the phones themselves is preventing improper, unsigned firmware from being uploaded conventionally. If physical access to the phone itself is required, the whole issue becomes academic FUD. A microphone is just as easy to put in an office and a Trojan placed on computers with microphones already built in is vastly easier.

Edit:Read the full articles linked. You need console level access to the device. The following is quite relevant and sounds a good bit like the last time I ran across an article that required some degree of administrative or root access first to accomplish an attack (emphasis mine):

Quote:

A local, authenticated attacker with the ability to place a malicious binary on the phone could leverage this issue to elevate their privileges or take complete control of the device....Workaround: Restrict SSH and CLI access to trusted users only. Administrators may consider leveraging 802.1x device authentication to prevent unauthorized devices or systems from accessing the voice network.

Yep, non issue if your VOIP subnet has remotely decent ACLs and policies in place. I hate starting the day with such FUD. The janitor should not have the root password for your Cisco hardware.

Now that I think about it, people with physical access have been able to do far worse for a very long time. We should be more concerned about tiny cameras, and lasers that read sound waves from the vibration of a window miles away.

Edit:Read the full articles linked. You need console level access to the device. The following is quite relevant and sounds a good bit like the last time I ran across an article that required some degree of administrative or root access first to accomplish an attack (emphasis mine):

Yep, non issue if your VOIP subnet has remotely decent ACLs and policies in place. I hate starting the day with such FUD. The janitor should not have the root password for your Cisco hardware.

You seem to have missed the part where console-level access is available at the RS232 port on the back of the phone. I work with these phones every day, it's not hard to plug in cables or tiny devices blind just by reaching around the back of the phone. In the demo the exploit ran fairly rapidly, at which point from my understanding the local access is no longer required. You could easily have a device the size of a USB stick with the right connector and plug it in for a few seconds while no one's looking.

I agree entirely that analog lines are easier to tap, but an analog tap is a physical thing which can be found if someone's looking. This is a software-only attack which turns an otherwise trusted device in to a tap. It's not as likely of an attack, but for those who find it worth worrying about it should be terrifying.

whquaint wrote:

Yay. I can't wait for the all IP phone system. Should be awesome. -_-

IP phone technology itself is inherently far more secure than analog ever could be. As aaronb1138 notes a POTS line is trivial to passively tap without interruption, where ethernet connections require either interrupting the signal to insert a passive tap (which doesn't work with gigabit anyways) or having administrative-level access to a network device in the path which can sniff the signal. The only downside is that the software-based nature of the things processing the signal makes it easier for them to have bugs such as the one being discussed here, particularly when dealing with vendors who should know better but prioritize the almighty dollar over doing it right (anyone who's tried to use Cisco IP phones in a non-Cisco PBX environment knows what I'm talking about here).

Full disclosure I'm in hosted VoIP and have a shitload of 7940/7960s in the field. They're not vulnerable to this particular exploit, but I'm sure given the hackish nature of their SIP stack (they were designed to be SCCP phones, which are basically more of dumb terminals) that something is there too.

Analog phones are considerably more vulnerable. The KGB basically had the ability to turn any USSR citizen's home phone into a remote listening device because they could activate a phone call without the ringer which would activate the microphone in the handset.

If physical access is available, POTS analog phones are subject to an attack in which a copper wire is wrapped around the cable. As I recall, it's called an inductive pickup and is harder to locate than VOIP packets leaving a network to an odd IP address.

I would be vastly more impressed if the hackers had found a way to compromise a UC5xx or ISR to mass upload such firmware to all the phones in the office over Ethernet. From the sounds of it, the update mechanisms built both into the VOIP distribution hardware (firewall / services routers) and the phones themselves is preventing improper, unsigned firmware from being uploaded conventionally. If physical access to the phone itself is required, the whole issue becomes academic FUD. A microphone is just as easy to put in an office and a Trojan placed on computers with microphones already built in is vastly easier.

Edit:Read the full articles linked. You need console level access to the device. The following is quite relevant and sounds a good bit like the last time I ran across an article that required some degree of administrative or root access first to accomplish an attack (emphasis mine):

Quote:

A local, authenticated attacker with the ability to place a malicious binary on the phone could leverage this issue to elevate their privileges or take complete control of the device....Workaround: Restrict SSH and CLI access to trusted users only. Administrators may consider leveraging 802.1x device authentication to prevent unauthorized devices or systems from accessing the voice network.

Yep, non issue if your VOIP subnet has remotely decent ACLs and policies in place. I hate starting the day with such FUD. The janitor should not have the root password for your Cisco hardware.

A locking ferrite wrapped with a copper coil clamped over either one of the two leads for the phone line, but not both. So you do have to splice the wire to hook on the bug.

Most analog phones use Red and Green for line one and Black and Yellow/Orange for Line two (AKA Christmas and Hallowe'en pairs)

If they're being used to record they can be darn near impossible to locate requiring a base-line of the phase and resistance on the lines from when they were installed, followed by regular testing to ensure that shift in phase and change in resistance due to line degradation is accounted for and checked against as the baseline becomes a moving target.

It is far easier to detect these bugs when they are hooked up to a transmitter of some kind as you can use an RF Spectrum analyzer to find unexpected RF signals, again in this case it helps to already have a base-line and regular updates of what RF saturation is like in the area, and what has changed over time. And of course accounting for those changes.

Less savvy taps that clamp onto the wire directly or create an inline circuit are much more difficult to disguise as they will almost always create a noticeable resistance point even if you do not have a baseline against which to test. (Oh a resistance spike exists 10m down the copper, lets trace it out and have a look. Aha!)

But as has always been said in the computer security sector, physical access, is total access.