3 ms·
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 firmwa
by Swannie 14y ago
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 14y agoThat'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 14y agoSorry 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 14y agoSo 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.
- revelation 14y agoEh, permission escalation? It was basically a memcpy into kernel space. And thats just the first suitable syscall they found. They fuzz tested a bunch of them and dozens produced crashes worth pursuing. Of 173 syscalls tested, 60 produced kernel panics.