Bugtraq mailing list archives

Re: Standard & Poors security nightmare


From: dick () SEAMAN ORG (Richard Seaman, Jr.)
Date: Sat, 20 May 2000 18:09:00 -0500


On Wed, May 17, 2000 at 12:44:01PM -0700, Stephen Friedl wrote:

Standard & Poor's ComStock division sells a MultiCSP system...
[snip]

I have done a similar but more limited review of an MCSP system with
a "burn date" of Feb. 17, 2000.  The results differ somewhat from yours.

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 /etc/issue file is blank on the machine I looked at.  The help accounts
don't exist.  The other login accounts exist, however, and all shared a
common password that I gather is univeral for all MCSP machines.  It also
isn't very clever, though after 12 hours crack still couldn't recover it, but
since everyone with an MCSP has it, its obviously not secure.

The other "config"
accounts provide similarly easy interfaces via simple menus, though I 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 gave me 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 password file is shadowed on the machine I looked at.  The same root
password existed on this machine as yours.

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.

Many of these problems still exist.  However, they have disabled at least
some unneeded services, including named, apache and sendmail.  samba is
still on, but unneeded.  Likewise for nfsd.  I have disabled both without
adverse effect.  World writeable directories and files are still a problem
(eg. /etc/rc.d/rc.local was world writeable).

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.

The machine I looked at is connected to a satellite feed.  I gather most
S&P customers are linked via satellite rather than via the Concentric
private network.  The "inside" (or "second") interface in this case
should be pretty safe if connected as S&P instructs.  The satfeed goes
into a decoder box with an ethernet output.  They supply a crossover
cable for direct connection of the decoder output to the "inside"
ethernet interface.  Its a one-way broadcast feed, so I don't really
see any risk on the inside interface in this case.

Of course, if you hook the decoder box to a network, and let the MCSP
box read the feed accross the network, you will have the vulnerabilities
on the network that you so ably discuss.  However, there doesn't seem to
be any reason to do this.  And, if you use the Concentric PN, you have
the vulnerabilites you site, at least those that haven't been fixed.

[snip]

This means that no matter how good your firewall and security is on the
"outside" of the network, I am able to show up as root on a Linux box
with compiler tools. On the *inside* of your network.

Only for the Concentric PN.  There are two reasons I know of to use
Concentric. First, your location doesn't get sat coverage (only true
for some non-US locations, I think).  Second, the sat feed isn't "fast
enough" (the issues involved here are worthy of discussion, but they're
not directly security related so I'll skip them for this forum).  S&P seems
to be pushing most or all customers to upgrade to the MCSP unit as a
prerequiste for a double or triple to the bandwidth of the sat
feed planned for August.  As a result the sat feed should be "fast enough"
for a lot more customers.

[snip]

Recommendations
---------------
[snip]

All good where they still apply.  For sat feed customers, I'd say that
changing the passwords, disabling samba and nfsd, and keeping the MCSP
"outside" interface behind a firewall on a "trusted network" will
reduce the vulnerabilities dramatically as compared to the MCSP setup
you analyzed.  Thats not to say they're eliminated.  Concentric PN
customers still have a bigger problem, I'd say.

Standard & Poors is simply out of their minds for producing a product
like this *and* not responding when the issue was raised.

I'd guess that the machine you looked at has a "burn date" prior to the
one I looked at.  If so, I'd say they responded somewhat half-heartedly
to the issues that were previously raised, but perhaps have not tried
to fix machines already in the field.   If your machine is more recent,
then I'd say they are very crazy, since they have regressed.

-------------------------------------------------
Richard Seaman, Jr.        email: dick () seaman org
5182 N. Maple Lane         phone:    262-367-5450
Nashotah WI 53058            fax:    262-367-5852


Current thread: