4 ms·
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 ca
by 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 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.