
Hack turns the Cisco phone on your desk into a remote bugging device - SanderMak
http://arstechnica.com/security/2013/01/hack-turns-the-cisco-phone-on-your-desk-into-a-remote-bugging-device/
======
Swannie
Yes. Physical access to devices is usually considered "game over" anyway. This
is just proving that devices other than PCs are vulnerable to having their
firmware overwritten if you have physical access.

However, there are a number of items here:

1) You need command line (SSH) access to the phone. This can be done via the
Aux port, or remotely.

2) With the latest version of Call Manager, once a phone is provisioned: SSH
is disabled, the Firmware is Signed, and only signed firmware can be loaded.
Therefore this exploit only works on a) older networks with SSH still enabled,
no Firmware signing, and you know the SSH password for the phone or b) newer
networks with SSH actively enabled, actively disabled Firmware signing and you
know the SSH password for the phone or c) non-provisioned phones.

3) You must then spoof the TFTP server, containing your malware, and request
an update.

4) The 79x1 series lets the exploit listen to the handset microphone with no
indication. The speaker phone microphone cannot be activated without the
"Speaker" LED turning on.

5) The 79x2 and 79x5 series don't allow the handset microphone, so only the
speaker phone mic is available, with the LED turning on.

6) You need to get "out" to your recording destination. This should be
impossible on the IP Phone VLAN.

So all in all, a lot of FUD spreading. Sure, there is a user-space to kernel-
space permission escalation vulnerability, and that's not good, but the rest?
Hmm.

Disclosure: Cisco employee.

~~~
josh2600
That's all well and good but your #3 here belies what really happened.

If you watch the presentation, the TFTP server attack is a very simple ARP
poisoning. Everyone who watched that video did a double take on the two TFTP
attacks because they're frankly a little ridiculous.

The IP Phone VLAN might not be an issue if you pwn the phone...

So look, is Cisco FUBARR'd? Not any worse than Avaya, Shoretel or any other
phone manufacturer. Ang just happened to pick on Cisco because they're the
most popular; __every phone vendor has these issues __.

In short, yes this exploit is bad, yes you probably need physical access to
the device to pull this off, but YES it is quite serious.

Disclosure: I work at a company (2600hz) which does a lot of work on many
phones including Cisco devices.

~~~
Swannie
Sorry for the naivety, but what should be done against the TFTP arp poisoning?
This is a non-provisioned phone, it doesn't know who it's owner is. OK, in the
case this is registered, and you know the SSH password, then yes, I agree the
phone could do more to verify the TFTP. But if you're running an up-to-date
call manager, then more has been done.

If you pwn the phone, true, you'd probably be able to register it to another
VLAN, pretend to be a PC plugged into the PC port, and bingo.

Not disagreeing, it is quite serious. But the coverage it's getting is rather
overblown - compared to the coverage that most remote execution exploits get
(almost none).

~~~
josh2600
So the hack being demonstrated is against a provisioned phone, which requests
a secure auth list from the TFTP to authenticate SSH access.

The SSH access file is checksummed and the processor on the phone would be too
slow processing this file, so it asks the TFTP server for this. A simple way
to lock this down would be MAC filtering, another alternative would be
building a secondary auth mechanism into the firmware. Either way, this
shouldn't happen.

So in answer to your question: there are a lot of things Cisco could do to
mitigate this, but they haven't done them for whatever reason.

I don't think Cisco is the only guilty party here (these exploits would likely
work on many other manufacturers with a little modification), but pretending
this isn't a serious exploit is ridiculous.

------
ddunkin
Yawn. Physical access is a joke compared to what you can sniff out of an
unencrypted call (all audio, SIP registrations, etc) if you can get in the
middle of the network, regardless of manufacturer.

------
signa11
PSIRT advisory on this: [http://www.cisco.com/en/US/products/csa/cisco-
sa-20130109-ui...](http://www.cisco.com/en/US/products/csa/cisco-
sa-20130109-uipphone.html#@ID)

