[ http://www.rootshell.com/ ]

Please see the bottom of this advisory for new workaround published by
N-Base.

-Rootshell

From ttsg@ttsg.com Mon Jul 20 14:33:17 1998
Date: Mon, 20 Jul 1998 17:00:00 -0400 (EDT)
From: TTSG <ttsg@ttsg.com>
To: www-request@rootshell.com
Subject: N-Base Vulnerability Advisory

                    The Telecom Security Group
                     http://www.ttsg.com/TTSG/


		** TTSG VULNERABILITY ADVISORY **


Summary:

Date:			July 20, 1998
Subject:		N-Base vulnerability
Contact Address:	nbase@ttsg.com
Result:			Comprimise security of switch, or render
				inoperable
--------------------------------------------------------------------------
Introduction :

  I have been trying to get N Base to acknowledge that there's a problem since
April. The original advisory was sent on May 19th, and a followup advisory was
sent on July 4th.  They didn't even bother responding. People should feel
free to contact me for more information or verification.

  N Base products are also OEM'd to DEC, Allied Telesyn, Lantronix, Intel,
and Black Box (and presumably others). Some of these companies no longer use
N Base gear, but may have sold products in the past that are affected. The
only way to find out if a given OEM box is really an affected N Base unit is
to try one of the exploits. The <any username>/forgot is probably the best
test.

  All I's are the author.
===========================================================================
  Advisory of May 19th, 1998:

  A number of security problems exist in various N Base products. It is quite
likely that these problems are also present in OEM versions of N Base products
sold by others. Because of this, this advisory is CC'd to companies that I be-
live are currently distributing N Base products (or have distributed N Base
products in the past), as well as to various computer security response teams.

  I spent a substantial amount of time over the past months trying to get N
Base to resolve these (and other) problems, as I would have preferred to have
fixes available before making these announcements. However, I am told that
N Base has discussed these problems "at the highest levels" and has made a
conscious decision to not correct them. I also stated I would send this notice
on Monday, May 18th, and gave N Base several weeks notice.

  Problem 1: 

  Many (all?) N Base managed products have "back door" passwords which cannot
be disabled. These apply to both the serial console port and the telnet con-
sole port (if enabled). The username/password combinations are:

  Username	Password
  <any>		forgot
  <any>		debug

  Both of these combinations grant full access to the switch - in particular,
any of the switch parameters can be changed, including the password. Further,
the "debug" password allows reading of various internal registers. Issuing
some debug commands can cause the switch to lock up, requiring a complete
power cycle to reset. Lastly, with these passwords it is possible to overwrite
the switch operational software, leaving the switch in an unbootable mode. 
Depending on the switch model, a return to the factory may be necessary, though
I have not investigated that.

  This problem has been verified on the NH208, NH215, and NH2016 switches and
I believe it is present on all managed N Base switches (though I have only
tested the 3 models listed).

  There is no workaround that does not greatly impact functionality. The most
secure workaround is to not define an IP address (disabling IP-based manage-
ment) and to not connect the console serial port. Depending on the environment,
this may not be adequate (for example, a switch located in an insecure area
can still have its console port tampered with). Other workarounds would be to
firewall the network the switch is on to prevent telnet access to the switch.
Of course, this assumes that a security boundary can be established, which is
not always the case.

  To disable the IP functionality, use the set-ip command to set the IP address
to a random net 10 address, like this: "set-ip 10.2.3.4" (do not use 2.3.4, 
pick your own random value). Since net 10 is not routed on the Internet and
is unlikely to be routed on your LAN, this should be safe (the default gate-
way will remain as originally configured, so any attacks would have to orig-
inate on an Ethernet segment directly attached to the switch, and picking a
random net 10 address gives a 24-bit "random" value that would need to be
found in order to attack the switch). We set the switch to a net 10 address
as it does not seem possible to delete the IP configuration without complete-
ly initializing the switch configuration and losing all other setup values.
IMPORTANT NOTES: Changing the IP address does not take effect until the switch
is initialized with the "warm-reset" command. I suggest being physically pres-
ent at the switch(es) when you reset them, as 2 of 5 test NH208's hung when I
tried to reset them.

Problem 2:

  N Base switches that implement a default TFTP server can have the server
operational software or (possibly) parameters overwritten by anyone who knows
the IP address of the switch and has an IP path to the switch.

  N Base switches with a default TFTP server have standard filenames for their
operational software and parameters. For example, a NH208 uses a software file
named FLASH08.HEX and a parameter file named PARAM08.PAR. The switch will ac-
cept a TFTP load of any data as long as the file name matches. In the case of
the operating software, the currently running software will be erased, the new
software flashed, and the switch restarted. If the software is not a valid
operating software for the switch, the switch will appear dead, usually with
the FAULT LED illuminated. An unsuspecting user might return the switch to N
Base for repair, but in any event this will cause substantial inconvenience.
The proper operational software can be uploaded to the switch via the serial
port, assuming that the user has the loader utility and switch software (which
may be available from ftp://ftp.nbase.com).

  It may be possible to make similar attacks against the parameter file, which
could then be used to compromise VLANs (by removing VLAN partitioning in the
switch) or for denial-of-service attacks (by changing ports to incompatible
operating modes). This has not been verified.

  This problem has been verified on the NH208 and NH215 switches. It is not
present on the NH2016 switch unless the switch has been changed to a TFTP
server with the "set-tftp-mode" command. If your switch has the "get-tftp-mode"
command and it reports "Tftp client will be operate on next software download"
then your switch should not be vulnerable to this problem.

  Workaround: use the "set-sw-file" and "set-par-file" commands to set the
filenames to strings which cannot be easily guessed. IMPORTANT NOTE: It may
be possible to read the filenames via the switch MIB. If this is the case,
then there is no defense against these attacks other than by disabling IP as
shown in the statement of Problem 1.

===========================================================================
Advisory of July 4th, 1998:

  To date, N Base has not made any substantial effort to integrate a fix for
this security hole into the N Base switch product line. Some switch firmware
has been released with a useless "fix", but other switches have not had a
new release, and no discernable effort has been made to inform N Base custom-
ers of this critical security flaw.

  The "fix" that N Base has implemented is to simply change the former debug
password of "debug" to the new debug password of "debug0" and the former
lost password recovery password of "forgot" to the new recovery password of
"forgotten".

  N Base should retain a security consultant to explain to them that *any*
fixed passwords are an *extremely* bad idea, even if "hidden" or "encrypted"
in the firmware. This has been true for many years, even before the days of
DEC's VMS "FIELD/SERVICE" account. It was true 2 months ago, when 3Com fixed
a similar problem (with a true fix, not just changing the passwords).

  It *might* be acceptable for these passwords to only work on the serial
console. It depends on the user and the application, and it's not a decision
I think N Base can make for its customers (at least not without informing
them).

  Other products that I am familiar with require either a jumper to be added/
moved/removed inside the product, or require the user to contact the vendor
with the serial number of the unit in question. The manufacturer then uses an
algorithm to compute the maintenance password from the unit serial number.

  Personally, I am in favor of the jumper method. However, I understand that
it may not be possible to retrofit existing units. It is possible to develop
a solution that does not involve hardware changes - for example, the debug
and password recovery code could be removed completely from the standard image
and only include in a special debug-and-recover image. As long as customers
are informed that the debug-and-recover image is for these purposes only and
represents a security exposure if not replaced with the standard image once
debugging and/or password recovery is complete. The debug-and-recover image
doesn't need to track other bug fixes, and so could be "frozen". This means
that there is no additional development overhead - just rename the current
images to the debug-and-recover, and omit that capability from future re-
leases. This assumes that the serial upload functionality is present on all
current products, of course.

  Lastly, I would add that aside from one contact from N Base saying "I do
not think we have a vulnerability of this nature", I have received *no* com-
munication from N Base regarding my original report.

  If I do not hear from N Base via email by July 20th with a plan for success-
fully securing these products and notifying affected customers, I will release
my original advisory and this update to unrestricted security incident report-
ing lists.
===========================================================================
The Telcom Security Group
PO Box 69
Newburgh, NY 12551
1.800.596.6882
http://www.ttsg.com/TTSG/
===========================================================================
Copyright July 1998  The Telcom Security Group

The information in this document is provided as a service from The Telecom
Security Group (TTSG).  Neither TTSG, nor any of it's employees, makes
any warranty, express or implied, or assumes any legal liability or
responsibility for the accuracy, completeness, or usefulness of any
information, apparatus, product, or process contained herein, or
represents that its use would not infringe any privately owned rights.
Reference herein to any specific commercial products, process, or
services by trade name, trademark, manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation or
favoring by TTSG.  The views and opinions of authors express herein do no 
necessarily state or reflect those of TTSG, and may not be used for 
advertising or product endorsement purposes.

The material in this vulnerability advisory may be reproduced and distributed,
without permission, in whole or in part, by other security incident
response teams (both commercial and non-commercial), provided the above
copyright is kept intact and due credit is given to TTSG.

This vulnerability advisory may be reproduced and distributed, without
permission, in its entirety only, by any person provided such
reproduction and/or distribution is performed for non-commercial
purposes and with the intent of increasing the awareness of the Internet
community.

===========================================================================

Trademarks are property of their respective holders.

-----------------------------------------------------------------------------

Date:         Mon, 20 Jul 1998 22:48:02 -0700
From:         Geoff Cummins <geoff@NBASE.COM>
Subject:      Re: N-Base Vulnerability Advisory

Currently, supported switches with the following ROM updates do have real
fixes for password/tftp problems.

For MegaSwitch II:    Model           ROM
                      NH2012          2.54
                      NH2012R         2.54
                      NH2015          2.51
                      NH2048          1.33

With these configurations you can do the following to fix these problems.

set-full-sec enable  (this disables the backdoor passwords)

set-sw-file  XXX     (where XXX is the name you want to call your SNMP
                      software update file)

set-par-file XXX     (where XXX is the name you want to call your
                      parameters file)

set-passwd <return>  (this will display a prompt to enter a new password)

set-comm read XXX    (where XXX is the new read community)

set-comm write XXX   (where XXX is the new write community)

These steps should secure the mentioned MegaSwitch II configurations.

For GigaFrame Switch    NH3012          2.1

set-full-sec enabled

set-sw-file XXX

set-par-file XXX

set-comm read XXX

set-comm write XXX

set-passwd <return>

del-user user       (By default there are two users "super", and "user".
                     "super" has supervisor priveldges, "user" is just a
                     default.  To secure the system, you should delete
                     the "user" account.)


Geoff Cummins
geoff@nbase.com