RE: The Trivial Cisco IP Phones Compromise

["Ofir Arkin" <ofir () sys-security com>]

Dear all,

It seems that dispite repeated efforts to educate Cisco about the
dangers of unauthenticated adminstration mechanisms, they continue to
tout their knee-jerk "firewall" response. As I will clearly demonstrate
in my response, a firewall adds no security to a large scale deployment
of Cisco IP Phones.

I am dissapointed that my paper has not been understood by Cisco, but
hope that their customers will understand -- unauthenticated
administration mechanisms are inherently insecure.



> > 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.
>  

This is certainly a good step, however, the password is stored in plain
text in an easily accessible location (on the TFTP server in
SIPDefault.cnf). Any changed password can be readily retrieved,
highlighting the fundemental problems with the security of the Cisco
SIP-based IP Phone: unauthenticated administration mechanisms.


> > 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.
>  

Something that I acknowledge in my paper. This is simply another example
of how the administrative alterations to the IP Phone's settings can be
made by anyone. "**#" is the local unauthenticated administrative
mechanism, TFTP is the remote unauthenticated administrative mechanism.
Neither provide any level of security at all.


> > 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.
>  

This statement is incorrect. There is nothing that can be done to secure
and protect a service that is fundementally insecure. The below
knee-jerk suggestions, vis. a firewall, provide no security to the TFTP
server; authentication cannot be duct-taped onto TFTP.


> > 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.
>  

This is a clear demonstration of the faulty logic at work with Cisco:
applying band-aid solutions will fix a deeply flawed product. TFTP has
no means of determining legitimate from illegitimate requests (i.e. no
authentication). What Cisco has suggested as a remedy is a cobbling
together of two technologies (VLANs and firewalls) neither of which
address authentication. No amount of third party solutions will provide
a secure means of authenticating TFTP requests. 

There is no means of properly firewalling a TFTP server. Firewalls
prevent access to services or prevent access from certain IPs. TFTP is
being offered as a service, so the only protection that the firewall can
offer is based on IP addresses. Since TFTP uses the connectionless
protocol UDP as a transport layer, TFTP requests can be trivially
spoofed. A firewall can provide no security for TFTP. 


> > 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.
>  

Ingress/egress filtering might go some way towards resolving the
spoofing problem. I would point out however that no spoofing is required
to comprimise the integrity of a Cisco compliant deployment enterprise
VoIP network. There are deeper flaws with the Cisco solution.


> > 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
>  

Momentarily ignoring the fact that VLANs are networking solutions, not
security solutions, I will explore the problems with Cisco's VLAN
proposal.

Based on the discussion of firewalling TFTP, we can assume that an
attacker who can penetrate the voice data VLAN can impersonate any
device on that VLAN. Essentially Cisco is suggesting that a legitimate
TFTP request can be determined based on its presence on the voice data
VLAN. Penetrating the VLAN is not a difficult task. There are numerous
documents on this subject 
available on the Web.


Cisco recommends that the IP Phone and a PC (or workstation) share a
port on the switch. VLANs are then used to segment the traffic from
either device. With the VLAN keys an attacker can inject frames into the
voice data VLAN. The VLAN keys are supplied in the paper. 

The enterprise VoIP network (in the Cisco recommended deployment) shares
the same hardware as the enterprise IP network. The VLAN provides no
security to the VoIP network, only an additional address space. Because
an attacker can penetrate the VoIP VLAN he can bypass any ingress/egress
filtering in place. As such, filtering and IP addresses have nothing to
add to the security of the Cisco SIP-based IP Phone 7960.



> > 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.
>  

This crude IDS solution will also fail to provide any authentication to
the administration mechanisms of the IP Phone. While there are certainly
attack vectors which would be detected by arpwatch, there are also many
others which would not be detected, e.g. MAC spoofing. A simplistic IDS
solution is not going to secure the Cisco SIP-based IP Phone 7960.


> > 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.
>  

That is certainly one scenario, but I am more concerned about an
attacker using physical access to subvert the IP Phone and its VoIP
sessions (e.g. altering the SIP settings to perform man in the middle
attacks, etc). Physical access allows an attacker to trivially lay the
groundwork for more damaging attacks in the future. In the case of an
insider attack (lets not forget that some 80% of all cyber incidents are
caused by insiders) this could be particularly devestating. Do you want
Christine from Accounting monitoring all your calls, all your bosses
calls?


> > 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.
>  

What exactly are those mechanisms when the Cisco SIP-based IP Phone 7960
provides none of its own?


> > 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.
>  

I am happy to discuss my research with anyone, particularly the vendor
in the hopes of improving the security of their products.


> > 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.
>  

Exploiting the Cisco SIP-based IP Phone is trivial. No authentication
required. I hope that this notice doesn't mean Cisco has no plans to
resolve this issues, but is rather waiting until their customers are
effected before acting.


Yours,
Ofir Arkin [ofir () sys-security com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA