COMMAND
ComStock
SYSTEMS AFFECTED
S&P ComStock multiCSP (Linux)
PROBLEM
Kevin Kadow found following. Standard & Poor's ComStock provides
stock quotes and news as a real-time data feed on dedicated
circuits. ComStock offers a 'Client Site Processor' as a means of
receiving their data feed, the MultiCSP Kevin tested against is
shipped as a PC running Red Hat Linux 5.1, with version 4.2.x.x of
'mcsp', the MultiCSP application software.
The MultiCSP system Kevin examined was a textbook example of how
NOT to ship a Linux-based 'appliance', with numerous extraneous
services enabled, several UN-passworded accounts (including a
root-equivalent account), world-writable files, and multiple root
holes. It does not appear that there is any effort to update the
OS after the machine is deployed at a client site, or to train
clients (Most of whom are only familiar with MS-Windows) to
update the system. The network connection for the stock quote
service is a leased line or other dedicated data feed. The Linux
client at customer sites use reserved (private) address space,
however clients are connected to Bay routers on the Concentric
network which are Internet accessible.
There's no evidence of IP filters anywhere within the network,
there is nothing on the Concentric network to prevent leaking of
172.23.*.* traffic to the public Internet, or to prevent clients
from within the ComStock network forging source IPs on outbound
packets.
The most obvious root hole on the MultiCSP host is the 'netconfig'
account, an unpassworded UID 0 login that runs a menu program.
This account displays a menu allowing for changing the IP
addresses, and the ability to edit the MCSP startup script, using
the 'vi' editor. The implications are obvious. The system ships
with very weak default passwords for the root account as well as
'support' and 'isdnconfig'. Root can be logged into via telnet.
Stephen Friedl added following. Review above is fairly scathing,
but it substantially UNDERstates the risk of running one of these
machines. These machines are an unmitigated *disaster* for
security, and it's not often we can use "unmitigated" so
literally.
For starters, on the "outside" interface they provide an
/etc/issue file that kindly tells you nearly everything you need
to know. Just telnet to the box, and it greets you with:
Red Hat Linux release 5.1 (Manhattan)
Kernel 2.0.35 on an i686
MCSP - Standard & Poor's ComStock - The McGraw-Hill Companies
Multiuser CSP Login:
<alt><F1> login: screen
<alt><F#> login: showusers
<alt><F#> login: showlog
<alt><F#> login: netconfig
<alt><F#> login: isdnconfig
<alt><F#> login: helpmcsp
<alt><F#> login: helpicl
login:
The only thing missing is "Please Hack Me -- I'm easy". The last
two "help" accounts have no passwords, and they bring up "more" on
some text files. When paused at the first prompt, it's easy to
type "v" to bring up vi on the file, then type
:set shell=/bin/bash <RETURN>
:shell <RETURN>
and get a non-root shell. This takes about 12 seconds. The other
"config" accounts provide similarly easy interfaces via simple
menus, though Stephen didn't spend any time on them. They
helpfully keep passwords in the "old" format in /etc/password: no
/etc/shadow, no MD5, so Crack will give you the root password of
"c0mst0ck" (zero instead of oh -- aren't they clever). Now you
are root on a Linux box with a C compiler.
The machine has LOTS of security issues: programs with known holes,
/many/ unneeded services, world-writable directories, and the list
goes on. But in one respect this shouldn't matter much: if you
have a proper firewall in place, this machine won't allow the
outside world to get anywhere near it. Or so you thought.
These machines have a dedicated circuit on the second network
interface (T1, ISDN, etc.) that supports the feed from S&P, and
it seems to be on a 172.23.*.* private network run by Concentric.
By downloading and compiling a few tools (the compiler was
thoughtfully left behind), you'll be able to "scan" various
172.23.x.x address blocks to discover numerous MultiCSP machines
owned by entirely unrelated customers. Since these machines are
all configured to run Samba by default, their "signature" is very
easy to detect with a NETBIOS nameservice scanner.
Once the machines are identified, it is a trivial matter to login
to these remote machines and get root via the same default
password or "vi" exploit. These machines are apparently located
all over the world and every single one has a "private" 10.x.x.x
or 192.168.x.x address on the "customer" side of the machine.
This means that no matter how good your firewall and security is
on the "outside" of the network, someone will be able to show up
as root on a Linux box with compiler tools. On the *inside* of
your network.
SOLUTION
If you have the misfortune of having a MultiCSP on your network,
you have my sympathy. If you can't live without their stock
information, It is possible to use the root holes to lock down
the box as best you can, then put it behind a firewall with just
the CSP TCP port open _inbound_ to the MCSP system from your
hosts, or at least a router with equivalent traffic filters. Then
pray for the best.
Stephen added:
1) Scream *bloody murder* at your S&P representative. They have
more or less completely ignored reports of this serious matter
as far as one can tell. The previous reporter of this (Kevin
Kadow) tried every way he knows how to get them interested, and
nothing happened, and even an indirect communiation to S&P's
CTO got no response. Talk to your legal counsel if you are so
inclined. S&P is just grossly negligent on this front.
2) Remove the /etc/issue file that reveals just how much stuff is
here. Though there are way too many services running on this
machine, and it would probably take no time to break into via
other means, the big /etc/issue file provided is just an open
invitation to abuse by even a casual passer-by. It surely
caught *someones* attention.
Unless S&P's changed something (unlikely from your description
of what's been left enabled) Red Hat systems regenerate
/etc/issue from scratch on boot. You need to modify
/etc/rc.d/rc.local instead, which contains the code that
generates /etc/issue.
3) Put good passwords on ALL the accounts, including the "helpful"
ones. If you really don't need the help accounts, disable them
entirely. These help files are very easy to find without
special logins. It is believed that S&P might login to these
machines remotely, so you may need to coordinate this with
them.
4) Find out from S&P just which services that they really need and
drop the ones not needed. They are running Samba, portmapper,
and SNMP, and it's not clear that any are really needed. Apache
is running, and for sure it's /not/ needed. Shut down
EVERYTHING you don't need. telnet is probably the only thing
really needed.
5) Use TCP wrappers to limit who can login to your system from
random IP addresses, and certainly disable all logins from the
Concentric side of the world. If possible, disable the telnet
daemon entirely and just do all your administration from the
console. Use Secure Shell instead of telnet.
6) Install and use ipchains on *both* interfaces to drastically
reduce what this machine can do. The Concentric side of the
world seems to talk to just two machines that are mentioned in
/etc/hosts:
#Name of machine on far side (e.g big1 and big2)
172.23.94.10 BIG1
172.23.95.10 BIG2
If you determine that this is the limit of your "outside"
traffic, firewall everything else.
As another poster mentioned, this is a 2.0.x kernel, so you
need to use ipfwadm, not ipchains.
You must also firewall the "outside" interface as well on the
assumption that the machine is compromised from the "inside".
Also use ipchains to limit virtually everything on this interface,
allowing only that which you know to be required.