The 7900 line of VoIP phones from Cisco contain remote-accessible code which can be exploited to cause a denial of service, and possibly leak information; the phones are also weak in ways that facilitate man-in-the-middle attacks directed at intercepting telephone traffic. Vulnerable products include CP-7960, CP-7940, and CP-7910 phones.
This advisory is being released simultaneously with one from Cisco which, once released, can be found at: http://www.cisco.com/warp/public/707/multiple-ip-phone-vulnerabilities - -pub.shtml
1. The Cisco 7900 series of phones include a built-in web server on port 80. The server provides several pages of debug and status information about the phone and is presumably intended for diagnostic purposes. However the pages require no authentication, and some are CGI scripts with exploitable errors. The most glaring of these is the StreamingStatistics page. Opening http://<phone-ip>/StreamingStatistics?1 will present a page of debug statistics as intended. Requesting statistics on a non-existent stream, e.g. http://<phone-ip>/StreamingStatistics?7 will return a page indicating the error. However, requesting statistics for a stream with sufficiently high ID will cause a hard-reset of the phone. Testing has produced varying results, but hard reset tends to occur with IDs > 32768, and using an (arbitrarily selected) ID of 120000 consistently produces the reset. This results in a reboot process of approximately 15-30 seconds during which the phone is not in service. The result is a very simple and not at all packet intensive DoS possibility. The attack is further facilitated the phone's willingness to provide its IP and phone number through the web page, allowing an attacker to walk a subnet looking for the correct IP, when targeting a specific extension.
2. Related to #1, another script on the phone's website, PortInformation has similar, though less catastrophic input validation problems. It uses the same format as above, http://<phone-ip>/PortInformation?1 will give you information on the first Ethernet port of the phone (which has its own port, as well as a second 10/100 switched port for connecting a computer to the network without requiring multiple Ethernet drops). Like StreamingStatistics, PortInformation will indicate an invalid port number up to a point (again, results vary, but IDs over 32768 seem to cause the problem consistently). Above that limit, rather than crashing, the page is generated with what looks like the contents of arbitrary memory locations. It is conceivable that a dedicated attacker could put this data to some use. If a tool were developed which could extract from this, for instance, the phone's recent calls lists, then it would be possible for an intruder to monitor and map telephone usage within the system. This is certainly not as dangerous as #1, but it should clearly be fixed nonetheless.
3. The telephones store all of their network information locally and most of it is accessible through the "Settings" button on the phone. By default, these settings are locked (as indicated by a padlock icon when viewing them) however the key to unlock the settings is the constant string '**#' (entered from the phone's keypad) . This is not admin-configurable. Once unlocked, several fields can be specified, including the TFTP server from which the phone receives its configuration file. Among other things, this file provides the phone with the list of CallManager IPs who will provide the telephony services. With one-time physical access to the phone, an attacker could enter an alternate, malicious TFTP server which would provide the phone with attacker-controlled CallManager IPs. In this fashion, the attacker could route all telephone traffic through his or her systems, presumably recording it or altering it before passing it to the legitimate CallManager systems for transport. This modification of the phone's configuration is very unlikely to be noticed, since a user never has to interact with the network settings menu where these changes were made.
Cisco first contacted March 27, 2002 and responded promptly. They are releasing an announcement in parallel with this one, and have been cooperative in confirming these problems and coordinating our announcements.
Once released, the Cisco advisory can be obtained from
http://www.cisco.com/warp/public/707/multiple-ip-phone-vulnerabilities - -pub.shtml
Short term Recommendations - For VoIP admins
(See also Cisco's advisory)
X. Do not separate phone network from other networks as an attempt at solution; any sense of security gained by separating the phone from the computer network is illusory. Not only is it relatively straightforward to obtain a phone's MAC address and then take the phone's place with a PC/Laptop network card with re-assignable MAC, but the phones themselves offer a built-in switch for connecting computers to the phone's network -- clearly the networks cannot be cleanly separated.
1. Use internal firewalls to kill all port 80 traffic on phone subnets/VLANs. This will at least block *some* attacks in the short term, however it may not totally eliminate the problem since, as described above, it is relatively simple to get onto the same wire as the phones -- depending on internal network architecture, it may be the case that significant numbers of phones are connected with hardware which does not support internal firewalling in this way.
2. Internal firewalls could also be set up to prevent TFTP based attacks as described above, but this may affect other services which rely on TFTP, and is subject to the same restrictions mentioned in #1.
3. It may be possible, depending on the level of activity on the phone network, to monitor for unusual TFTP traffic and phone resets. It should never be the case that one IP requests the configuration file for a phone with a different IP, unless something fishy is going on. Likewise, clumsy attackers experimenting with these techniques will likely be causing a higher-than-normal level of phone resets, since a reset is the easiest way to cause the phone to re-download its configuration over TFTP.
Concerns (a.k.a. the Mini-Rant)
The idea of putting a web server into something so mission critical as the phones should have set off alarm bells. I can't imagine an analysis under which the debug information provided by this web server (much of which is available from the physical unit as well) outweighs the potentially catastrophic results of having one's phone system trivially DoS'd. With a list of known phone IPs, I suspect a single malicious user could use the hard reset vulnerability above to effectively disable the entire phone system within a building - or possibly within multiple sites on the same intranet. Even without total saturation, an attack that made phones inoperable for 30 seconds every 5 minutes would effectively incapacitate the system, making even emergency calls almost impossible.
Cisco CallManager 3.0 Manual
Cisco 7960 Administration Guide