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 /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 forgot 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.