COMMAND

	Trivial Cisco IP Phones Compromise

SYSTEMS AFFECTED

	SIP-based IP Phone 7960 and its supporting environment

PROBLEM

	Ofir Arkin [ofir@sys-security.com] Founder  of  The  Sys-Security  Group
	[http://www.sys-security.com] details :
	

	... complete control of a user's  credentials;  total  subversion  of  a
	user's settings for  the  IP  Telephony  network,  and  the  ability  to
	subvert the entire IP  Telephony  environment.  Malicious  access  to  a
	user's  credentials  could  enable   "Call   Hijacking",   "Registration
	Hijacking", "Call  Tracking",  and  other  voice  related  attacks.  The
	vulnerabilities exist with  any  deployment  scenario,  but  this  paper
	deals specifically  with  large  scale  deployments  as  recommended  by
	Cisco.
	

	-In-
	

	http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_C

	ompromise.pdf 

	

	http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_C

	ompromise.zip

	

SOLUTION

	Jim Duncan  [jnduncan@cisco.com],  Product  Security  Incident  Manager,
	Cisco Systems, Inc., forwards :
	

	http://www.cisco.com/warp/public/707/sec_incident_response.shtml

	

	

	This message contains Cisco responses to the  issues  described  in  the
	white paper referenced above.
	

	1.  Access to the Cisco 7960 IP phone:
	

	    A Cisco model 7960 IP phone running a SIP-compatible image has a

	    password that can be set by the IP phone administrator.  The default

	    password is "cisco" if the password has not been set to some other

	    value.  Cisco strongly recommends setting the password to something

	    other than the default.

	

	    The key sequence of "**#" is not intended as a password.  It is

	    clearly and publicly documented in many places within Cisco's

	    product literature.  The key sequence is solely intended to protect

	    against casual or accidental changes to the phone's configuration.

	

	2.  Abuse of the TFTP service:
	

	    Although the author is correct that various attacks against the TFTP

	    service can be mounted, there are several measures that can be

	    employed by the IP phone administrator and the organization to

	    mitigate the risk. 

	

	    If the network is firewalled properly so that the different network

	    segments are compartmentalized as the Cisco SAFE white papers

	    recommend, then the TFTP server will only respond to legitimate

	    requests.  The TFTP server does not need to reside on the same

	    network segment as the IP phone.  If RFC 1918 addressing is employed

	    for the IP phones and proper ingress/egress filtering is in place as

	    recommended, then any such attack is highly unlikely to succeed from

	    outside the enterprise VoIP network, even with the use of UDP.

	    Access to the physical networks from within the enterprise may make

	    it easier to succeed with the attack, but if the VLANs are properly

	    protected and MAC addresses monitored per the SAFE documents -- for

	    example, by using arpwatch or arpsnmp -- then an attack may be

	    detected by the IP phone administrators. 

	

	3.  Manual modification of the IP phone configuration:
	

	    At some level, successful attacks would require such physical access

	    to the local network segment or the IP phone that the attacker could

	    simply use the IP phone itself to commit toll fraud and some of the

	    other improper acts listed in the paper.  Physical access to network

	    hardware is a long-standing, well-known problem in the industry.

	    This is an especially important consideration for IP phones located

	    in public or semi-public areas such as building lobbies.  The IP

	    phone admistrator should use all available mechanisms to secure any

	    IP phones that are exposed to unauthorized manipulation.

	

	As always, Cisco is interested in  protecting  our  customers'  networks
	and is continually striving to improve the security of our products.  We
	appreciate the seventeen days of advance notice  we  received  from  the
	author and his willingness to discuss the issue with us. We are  unaware
	of any confirmed incidents of malicious exploitation of  the  issues  in
	the author's paper and ask that any such  exploitation  be  reported  to
	the Cisco PSIRT, psirt@cisco.com,  as soon as possible.