Harkening back to an earlier article, a recent discovery by the author of this very article only even more so drives home the point that anybody who owns a network-capable device and an Internet connection should be more than wary of what they may be broadcasting to the world.
Last week, I spent some time crafting a custom Google search based upon my knowledge of the 79XX series of Cisco IP Phones. Utilizing the Google search operator “inurl:” and the content “adapter=device.statistics.device” pulled from the phone’s web UI URL, I was able to return 273 search results. After examining a number of the returned results, I was able to confirm that there are a significant number of Cisco IP Phones open to the Internet, and thus easily accessible by anybody with an Internet connection.
Of course, any news of this nature brings to mind one question—at least for those individuals interested, for good or for ill, in computer and network security: what can be done to exploit these phones? The most obvious advantage an infiltrator can obtain with such a vulnerability is access to the phone’s web UI. Immediately available to the attacker are the device’s MAC address and serial number, which could be used for spoofing and social engineering attacks, respectively. By visiting the second page of the phone’s web UI, the attacker can gain access to device's network configuration page, which contains the usual information (DHCP server, DNS server, subnet mask, gateway address, etc) as well as the machine’s TFTP server. This TFTP server is used by the phone to grab configuration files that exert a high level of control over the device’s settings (settings such as whether or not Telnet console sessions into the device are enabled or disabled.) Though proof-of-concept has yet to be established, it is extremely reasonable to conceive than an attacker could craft a malicious configuration file and either spoof, alter, or bypass the device’s TFTP server to upload said file. If such an attack could be successfully be carried out, an entirely new plethora of doors would be opened for the attacker to exploit.
Moving further down the phone’s web UI, the attacker can also download log files and core/kernel dumps, in many cases without any form of authentication. The attacker can also view the device’s status messages and debug display, potentially allowing them to watch for update/maintenance patterns that they can exploit. Outside of the web UI, the user can send binary data to the device via certain ports, or even initiate SSH sessions with the device, though both of those exploits require that the machine either be placed outside of the NAT or that the requisite ports be forwarded through said NAT. Either way, the possibility is there for the exploits to be plausible.
While this report is still in its early stages and the author, admittedly, has not had the opportunity to perform proof-of-concept testung on the listed device model series, the notion that there are network administrators in existence that have, be it knowingly or unknowingly, placed powerful, vulnerable devices such as these on the Web where they can easily be exploited is simultaneously baffling and frightening. In computer and network security, the phrase is often uttered that the number one threat to any system is its users. While that is most certainly true, there are without a doubt administrators in the world that are just as much of a threat to their systems as the users that utilize those same systems every single day.
Remember, keep all of your devices inside the NAT, do not forward any ports other than those that are absolutely necessary, and always enable as many authentication methods as possible on your network-capable devices. To do otherwise is, essentially, to invite disaster into your network, and the denizens of the Internet hardly ever decline an invitation to disaster.
Comments