COMMAND
3com switches
SYSTEMS AFFECTED
Systems running 3com switches (CoreBuilder LAN and SuperStack II)
PROBLEM
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).