nbase.txt

` The Telecom Security Group  
http://www.ttsg.com/TTSG/  
  
  
** TTSG VULNERABILITY ADVISORY **  
  
  
Summary:  
  
Date: July 20, 1998  
Subject: N-Base vulnerability  
Contact Address: [email protected]  
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.  
  
`