A few weeks ago a new physical attack against Cisco phones was announced [YouTube clip]. A few days ago, this was detailed further in a 29C3 presentation by Ang Cui and Michael Costello [YouTube clip]. And even just today, this news has hit the mainstream news waves because of how cool it is to watch a phone be pwned and be turned into a silent eavesdropper, recording conversations without any indication the mic is engaged. And this, of course, means questions from non-technical people who sometimes are important enough to need some pragmatic answers quickly!

The 29C3 preso is excellent, but very technical. The shorter vid up above is nice, but doesn’t quite give enough information for a proper risk assessment. (There are a scattering of other articles on this topic, but nothing that brings anything new beyond talking about the mic issues, and really not anything worth mentioning from any incident response/vuln announcement outlets… Cisco has an advisory or two, but I don’t have the time at the moment to look that up.)

To me, there is one major issue, which then can be leveraged in 2 attack scenarios. There are actually more issues, but for anyone who is not a pen-tester or Cisco, there is really just one main one to look at. If the others are important to you, then you’re going to be technical enough to digest them from the preso.

• The big issue: privilege escalation/kernel exploit where someone with access to the phone can become root and run whatever they want on the phone.
• Physical attack by plugging a device into the rear ethernet jack on the phone and then executing arbitrary code to own the phone, leveraging item #1.
• Local network (“remote”) SSH authentication bypass by impersonating the TFTP server the phone interrogates for authorized SSH user keys, and then leveraging item #1. (skip to 38:00 in the preso.)

This distills down to a few talking points.

• The physical attack is neat, but has a few components to it. First, the attack hasn’t (to my knowledge) been yet made public, so many people know this is possible, but don’t have the tools (yet) to do anything about it. Second, Cisco will certainly be working to patch the issue. Third, leveraging item #1 above requires some sort of access, either physical or local network, to a target phone.
• Even if the “eavesdropping mic” attack is successful and the attacker turns on the mic, the recorded data still needs to be sent somewhere for the attacker to listen to or retrieve. This is possible in many ways, but keep in mind the above presentations pretty much avoid that hurdle.
• These phones are basically little computers. If an attacker can take control of it, they can do the same things from it that they could by using a rogue or compromised system on a network. The “eavesdropping mic” is just one of many ways the compromised phone could be used.
• Physical security is still paramount, even for phones placed in semi-public locations.
• Keep unauthorized devices off your network so they aren’t able to do things like impersonate TFTP servers or make SSH attempts to your phones. In addition, make sure your network monitoring is set up to let you know when even someone authorized tries to do suspicious things. This isn’t new.
• It’s up to Cisco to fix the privilege escalation and other various issues in their firmware.
• Always be vigilant and report any strange devices, electronics, dongles, or other things hanging off phones, systems, or plugged into jacked that aren’t normally used or have not been sanctioned/installed by your local IT. And even then, question what things are in case an insider is planting devices.

The tough part of assuring security for phones like this is their closed nature. Do we have logs shuttled somewhere to watch for events like firmware replacements, for instance? How do we know firmware has been replaced? Or when the Flash/ROM has been tampered with? Or when audio data is going to a weird place on the network? Basically, similar questions we have of any device we can’t properly manage quite as deeply as a server, or have our management abstracted out to someone else’s centralized management that probably has not accounted for these sorts of questions.

And to throw what many non-technical people will claim is FUD (and is mentioned in the preso, kudos!), this issue has been present for 6 years. Go ahead and think about that one for a bit! 🙂