3 ms·

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. Ev

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 14y ago
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 14y ago
  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.

Swannie 14y ago

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 14y ago
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.