COMMAND

	Cisco voice over Ip phones multiple vulnerabilities

SYSTEMS AFFECTED

	Cisco 7900 line of VoIP phones, including CP-7960, CP-7940, and  CP-7910
	phones.
	

	 

PROBLEM

	In Johnathan Nightingale [http://johnath.com/] advisory :
	

	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.
	

	

	 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 

	

SOLUTION

	For a patch see:
	

	http://www.cisco.com/warp/public/707/multiple-ip-phone-vulnerabilities-pub.shtml

	

	

	 Short term Recommendations - For VoIP admins

	 ============================================

	

	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.