|
Vulnerability 3com switches Affected Systems running 3com switches (CoreBuilder LAN and SuperStack II) Description Eric Monti found following. There appears to be a backdoor or undocumented "access level" in current (and possibly previous) versions of 3Com's "intelligent" and "extended" switching software for LanPlex/Corebuilder switches. In addition to the "admin", "read", and "write" accounts, there is a "debug" account with a password of "synnet" on shipped images (including those available for download from infodeli.3com.com). The versions of firmware this was tested under include 7.0.1 and 8.1.1. The debug account appears to have all the privileges of the admin account plus some "debug" commands not available to any other ID. If you allow "remote administration" (telnet access), well you can change all the other access passwords from the "debug" account without having to know the old passwords. So, someone can lock you out of your switch completely. In addition, they can get to the "underlying OS shell", which looks like a very fun place to completely screw things up. Mike Richichi verified this works with the Lanplex/Corebuilder 2500s (all SW versions 7.x and 8.x) and the CoreBuilder 3500 (ver 1.0.0.) and Jean-Francois Malouin on 3Com LANplex 2500 (rev 7.15) with Version 7.0.1-19 - Built 01/17/97 02:41:17 PM. Durval Menezes found similar story, actually there is another "tech" user. It works om LinkSwitch 2700 and CELLplex 7000 (so far tested). The username is tech, as is the password. Acording to 3COM advisory, situation looks like: CoreBuilder 6000/2500 - username: debug password: synnet CoreBuilder 7000 - username: tech password: tech SuperStack II Switch 2200 - username: debug password: synnet SuperStack II Switch 2700 - username: tech password: tech The CoreBuilder 3500, SuperStack II Switch 3900 and 9300 also have these mechanisms, but the special login password is changed to match the admin level password when the admin level password is changed. As we are sticking with these stuff, let's mention another thing. You can for instance find on SuperStack II Switch 1000 (and 3000) that username "monitor", with password "monitor" work for you. This on the other hand is very well documented. Users "monitor", "manager" and "security" are factory pre-existent, with default passwords equal to the account name. It's user's obligation to change all 3 passwords if he wants security. This is valid for every SuperStack management module/equipment. Netbuilder seems to be safe, but there is another way to gain access to a Netbuilder. All 3Com Netbuilders support a remote command. The remote command comes with RBCS (Remote Boot and Configuration Services) and Transcend Management Suite. If you are root on a Netbuilder and know the address of someone elses Netbuilder you can remote to their Netbuiler from yours and gain root privelages. It might also be worth mentioning (Michael Mittelstadt as source) that the enterprise MIB (at least for the Corebuilder 3500) contains the passwords and the snmp keys for the box. If some poor sap sets their SNMP key to something guessable (like 'public'), you can get the admin password and SNMP key with these: enterprises.synernetics.lanplex.lanplexSystemsMib.1.19.0 = "password" enterprises.synernetics.lanplex.lanplexSystemsMib.6.7.0 = "public" This is true with both software release 1.0 and 1.1 on the Corebuilder 3500. And since it's the synernetics enterprise MIB, this info might be on other corebuilder and lanplex boxen. With release 1.0 on the corebuilder, you may be able to reboot the box by sending a lot of UDP traffic to it's administrative port. Running netcat against it it will cause some 10 seconds later to reboot. rel 1.1 seems more robust. Solution Customers should also immediately change the SNMP Community string from the default to a proprietary and confidential identifier known only to authorized network management staff. This is due to the fact that the admin password is available through a specific proprietary MIB variable when accessed through the read/write SNMP community string. This issue applies only to the CoreBuilder 2500/6000/3500 and SuperStack II Switch 2200/3900/9300. Fixed versions of software will be available from 3Com for all of these products by 20th May 1998. Fix for remote Netbuilder vulnerabily is under System Options, Limit remote access connections to a single station or single subnet. SHow -SYS RemoteManager =============================================== Remote-In allowed from the following addresses: your.ip.subnet.here your.ip.addr.here =============================================== There are no backdoor passwords on the NETBuilder s/w. The remote "back-door" mentioned here has been fixed. Access to other NETBuilders using the Remote command has to be explicitly enabled (at least from Rel 9.3 onwards).