COMMAND
Bay Networks
SYSTEMS AFFECTED
Systems with Bay Networks routers
PROBLEM
Marty Rigaletto found following. The problem with the Bay boxes
is that by default the two system accounts on the machine are not
passworded. Now, usually the "Manager" account on the machine is
passworded by the administrator, however, the "User" account is
often left untouched. While the "User" account has restricted
access, it can be a huge security hole, especially when these
machines are used for the purposes of IP filtering (a firewall).
Because the Bay machines have snmp configuration capabilities,
anyone knowing the snmp string for the machine or snmp community
could edit IP filtering rules with any SNMP management software or
the bay networks software they put out for solaris and just
recently NT.
All a proposed attacker would have to do is telnet to the router,
login as "User", and issue a single command, "sho snmp community".
Then adjust his or her snmp software to use that string and IP
address, and b00m, sucks to be you.
Jason Ackley added following. Even if the box is not doing
filtering and such, the 'User' Account can be used to ftp into the
Bay router (they run ftp daemons), download the configuration file
and then read it into their Managment program, in which you will
have the snmp read/write strings to do whatever you want with!
Basically if the 'User' account is open, the router can be taken
over with very little effort.. Once you load up the config file
into the managment console, you could toggle T1s, down interfaces,
reset BGP tables, capture packets.. You name it. Here is a
sample random-bay-router-on-the-net(IP addr changed of course):
llama:/usr/home/jason/doc# ftp 1.3.3.3
Connected to 1.3.3.3.
220 WfFTP server(x12.00) ready.
Name (1.3.3.3:jason): User
230 User User logged in.
ftp> bin
200 Type set to I.
ftp> get config
local: config remote: config
200 PORT command successful.
150 Image data connection for 2:config (1.3.3.3,20) (50140 bytes).
226 Binary Transfer Complete.
50140 bytes received in 2.01 seconds (24909 bytes/s)
ftp> ls
200 PORT command successful.
150 ASCII data connection for 2: (1.3.3.3,0) (0 bytes).
Volume - drive 2:
Directory of 2:
File Name Size Date Day Time
------------------------------------------------------
config.isp 45016 08/22/97 Fri. 17:05:51
startup.cfg 7472 08/24/97 Sun. 23:31:31
asnboot.exe 237212 08/24/97 Sun. 23:31:41
asndiag.exe 259268 08/24/97 Sun. 23:32:28
debug.al 12372 08/24/97 Sun. 23:33:17
ti_asn.cfg 504 08/24/97 Sun. 23:33:31
install.bat 189114 08/24/97 Sun. 23:33:41
config 50140 04/20/98 Mon. 22:08:01
4194304 bytes - Total size
3375190 bytes - Available free space
3239088 bytes - Contiguous free space
226 ASCII Transfer Complete.
ftp> quit
221 Goodbye.
SOLUTION
Set password on "User". It would be wise to make it where the
'User' account cannot ftp in, or cannot read the contents of the
flash card. Removing the 'User' account would be a good idea too,
as not too many people use it and even more people are not even
aware of it. Few good recommendations:
* FTP Daemon on the router is not enabled by default - it's
good to leave that untouched.
* If the User level has to be made publically available, don't
install snmp.bat on the flash image, or at least don't make
it available to the User account. This would disallow
command "show snmp" at all.
* Restrict TELNET access and especially TFTP access to the
router to certain sites on the network only, by applying
appropriate filters!
To address security concerns, Bay has documented in the 'Quick
Starting Routers' manual, that users initially configure the
router using the Bay Command Console (BCC). Using the BCC
requires the authorized user to consciously configure all access
related services. The BCC also provides the ability to define
access policies for IP related protocols such as Telnet, FTP,
TFTP, NTP, and SNMP. The BCC has been available for the Bay
Networks Access Node router since BayRS 11.02.
Bay recommends that both accounts (User and Manager) have
passwords assigned. Both have default/null passwords as they ship
from the factory. The administrator should immediately take
measures to secure the system, at initial system install, so that
an unauthenticated user/manager doesn't have access to device
management information, such as the community names and addresses
via telnet/console.