Date: Wed, 22 May 2002 11:50:50 -0400
From: Johnathan Nightingale <johnath@johnath.com.>
To: [email protected]Subject: Multiple Vulnerabilities in CISCO VoIP Phones
Cc: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Abstract
- --------
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
Vulnerabilities
- ---------------
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.
Vendor Status
- -------------
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.
References
- ----------
Cisco CallManager 3.0 Manual
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/adm
in_gd/3_0_9/ccm3_bk.pdf
Cisco 7960 Administration Guide
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/ip_7960
/admguide/7900adm2.pdf
- ---
Johnathan Nightingale
[email protected]
http://johnath.com/
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>;
iQA/AwUBPOu4npTq1bXoStsJEQKBKQCg9LBATuzcL8op5Q4y8J8HIH6qOWUAoNyG
QSA914SCj6wyX+lT/x18q+ar
=yl/p
-----END PGP SIGNATURE-----
