Re: The Trivial Cisco IP Phones Compromise

From: Jim Duncan (jnduncanat_private)
Date: Thu Sep 19 2002 - 13:32:43 PDT

  • Next message: secureat_private: "[CLA-2002:525] Conectiva Linux Security Announcement - kdelibs"

    -----BEGIN PGP SIGNED MESSAGE-----
    
    Ofir Arkin writes:
    > The referred paper lists several severe vulnerabilities with Cisco
    > systems' SIP-based IP Phone 7960 and its supporting environment. These
    > vulnerabilities lead to: 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.
    > 
    > A PDF version of the paper is available from:
    > http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf 
    
    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, psirtat_private,  as soon as possible.
    
    ==
    Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
    http://www.cisco.com/warp/public/707/sec_incident_response.shtml
    E-mail: jnduncanat_private  Phone(Direct/FAX): +1 919 392 6209
    
    
    -----BEGIN PGP SIGNATURE-----
    Version: PGP 6.5.2
    
    iQB1AwUBPYoyi95wH2yjJs+JAQFDxAL8DkZSBdl1BRXgUfqqqw0E2E1eIyM/guy5
    rdNeEZEBiq7lSbqRwW4c+whG+3TKRKo8aV9rX2JkTWkwJ6JHxWeOKY5xHh1eGeiK
    kuyGHbGy1Sp+5Jr9Vol0nqBk3igYFxhi
    =/Mz6
    -----END PGP SIGNATURE-----
    
    
    ==
    Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
    http://www.cisco.com/warp/public/707/sec_incident_response.shtml
    E-mail: jnduncanat_private  Phone(Direct/FAX): +1 919 392 6209
    



    This archive was generated by hypermail 2b30 : Fri Sep 20 2002 - 07:43:48 PDT