[27142] in bugtraq
Re: The Trivial Cisco IP Phones Compromise
daemon@ATHENA.MIT.EDU (Peter Peters)
Fri Sep 20 15:00:55 2002
From: Peter Peters <P.G.M.Peters@civ.utwente.nl>
To: bugtraq@securityfocus.com
Date: Fri, 20 Sep 2002 16:53:00 +0200
Reply-To: peter.peters@civ.utwente.nl
Message-ID: <k9dmouslir2ratnsp62ve0n0dek60tht96@4ax.com>
In-Reply-To: <200209192032.g8JKWhd11198@rooster.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
On Thu, 19 Sep 2002 16:32:43 -0400, you wrote:
>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.
There have been discussion going on (and off) about the danger of
default passwords. How long does it take before so-called secure aware
companies become really aware of security issues?
> 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.
Then just don't accept is as a password. It's that simple, isn't it?
>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.
Not in all situations the IP phones are within one network. Sometimes
the phones are used by home workers. And not all ADSL- and
cable-companies allow IPsec over their network. At least not when you
have a consumer version of the connection. If you want IPsec you have to
buy the expensive business version for all the home workers.
