full-disclosure - CAT6500 accessible via 127.0.0.x loopback addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <OFF62C0958.E6911E46-ON85257362.0063937E-85257362.00647650@census.gov>
Date: Wed, 26 Sep 2007 14:17:18 -0400
From: lee.e.rian@...sus.gov
To: full-disclosure@...ts.grok.org.uk
Cc: psirt@...co.com
Subject: CAT6500 accessible via 127.0.0.x loopback
	addresses

Lee E Rian/TCO/HQ/BOC wrote on 08/29/2006 01:49:40 PM:
>
> I found something interesting w/ the cat6000s - telnet 127.0.0.11
> gets you into the switch & telnet 127.0.0.12 gets you into the router
>
> % snmpget 127.0.0.11 sysDescr.0
> RFC1213-MIB::sysDescr.0 = STRING: "Cisco Systems WS-C6509.Cisco
> Catalyst Operating System Software, Version 5.5(18).Copyright (c)
> 1995-2002 by Cisco Systems."

    <.. snip ..>

> I'm trying to figure out if that opens us up to something or not.

Yes, the date is correct - it was a bit over a year ago when I wrote a
co-worker about the problem.  And it did open us up to an attacker gaining
access to the router or switch; I sent a msg to Cisco PSIRT the same day.

Cisco has documented the fix in the release notes
  (eg.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/ol_4164.htm#wp3511819)
but it's buried in the release notes and how many people will a) read the
release notes and b) realize the implications?  So while I agree with Cisco
about this being a low to moderate vulnerability, that's only if one
realizes that the various line cards in a catalyst 6500 are accessible via
127.0.0.xx addresses from the network.  At least in my mind, this is on the
same level as routers accepting snmp sets to 255.255.255.255, {network, 0}
and {network, -1} ... a minor issue as long as you realize that it is
possible to access the router/switch that way.

Mitigating factors:
- an attacker would still need to know/guess the snmp community string or
userid/password
- only the first cat6000 with an MSFC in the path can be accessed this way

As an example of 'only the first MSFC in the path', the path from one of
our remote offices to a data center is
 cat6500 with a supervisor 2 card (no MSFC)
 cisco 2800 router
 cisco 7200 router
 cat6500 with a SUP720 in slot 5
Anyone in that remote office would have been able to access the data center
cat6500 by sending traffic to 127.0.0.51.

I would like to thank Ilker Temir of Cisco for his professionalism and many
courtesies extended to me while working on this issue.

Lee Rian

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/