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:
- Standard & Poors security nightmare Stephen Friedl (May 17)
- Re: Standard & Poors security nightmare Jim Knoble (May 18)
- Re: Standard & Poors security nightmare Richard Seaman, Jr. (May 20)
- Re: Standard & Poors security nightmare Richard Seaman, Jr. (May 21)
- Re: Standard & Poors security nightmare Crispin Cowan (May 20)
- "gdm" remote hole Chris Evans (May 21)
- Re: "gdm" remote hole Katherine M. Moussouris (May 22)
- fdmount buffer overflow Arend-Jan Wijtzes (May 22)
- Re: fdmount buffer overflow Greg Olszewski (May 22)
- About VNC Patrick Oonk (May 24)
- Re: fdmount buffer overflow Tomasz Grabowski (May 24)
- Re: fdmount buffer overflow Matt Wilson (May 24)
- Re: fdmount buffer overflow Greg Olszewski (May 22)
- Gauntlet Firewall Vulnerability Elias Levy (May 22)
(Thread continues...)