Re: [cobalt-users] [Raq4] Directory Listing Exploit found.

["Jonathan Michaelson" <michaelsonjd@xxxxxxxxxxx>]

Hello Jeff,

> Jonathan Michaelson wrote:
>
> > Indeed. It's also very trivial. I've written a perl CGI script in the
last
> > few minutes that any user could upload to their hosting account and run
that
> > trawls the whole server listing all files that you can read, write and
> > execute.
>
> ...<stuff snipped from middle>...
>
> > In this environment, if you're sticking with the Cobalt configuration,
> > client education is probably your most effective tool. Running CGI
scripts
> > such as this one helps you find those clients that need that education
to
> > help protect themselves _from_ themselves.
>
> So, are you going to release the script for our administration use
> <smile>?

Now, there's a dilemma :-)

Firstly, I'd like to apologise for rat-holing the PHP security discussion.

The short answer (for those that don't want to read my diatribe) with regard
to posting the script - "No" **

As I was writing the original reply I was thinking about a hullaballoo
caused maybe a year or so ago on the list when someone discovered that an
easily available CGI script could read pretty much all the files on their
server. Someone was getting righteous about this and wanted the publisher to
withdraw the script.

Now, that pissed me off. It showed a distinct ignorance of simple file
permissions that _anyone_ can teach themselves from a myriad of sources and,
because they hadn't bothered, their ire was aimed at someone who has simply
written a tool (yes, I'm a perl CGI programmer so sympathise with the
author) that allows people to manage their webspace. It's not their fault
that the system administrator of a server hasn't either properly secured
their directory structure or educated their client base such that the script
could be mis-used.

I haven't the energy or inclination to post a script that may attract this
kind of abuse from people ignorant of something as simple as file
permissions (which is funny since this is what the script is testing for).

The script is nothing special. Many people on this list could easily write
something similar, it's only 20 lines long and the bones can be obtained
from many a website or perl book.

Thinking about this, it's actually a little frightening. Why? Because one
server I ran it on revealed a customer whose online store was wide open to
anyone to read/modify/delete as they felt maliciously so inclined. It would
be simple to hide any such action within the noise of web traffic and you'd
probably never know what caused Joe Bloggs' website to become
deleted/corrupted/highjacked.

Unless you impose or educate your clients to _not_ use the Cobalt default
file permissions as they FTP upload files, then reading files in an Apache
"protected" directory (behind a .htaccess file) is simple. Reading data
files outside the web root directory is simple. Running CGI scripts that are
meant to be protected behind .htaccess files is simple. Your customer
sensitive data/details/passwords/credit cards _is_ all encrypted on-disk
with appropriate file permissions, isn't it?

I think one problem is that when clients see that FTP access is restricted
to their own site directory tree, they assume that that means no-one else
(on the server) can access their files in any way other than by browsing
their website. This is wrong, and is providing a completely false sense of
security.

If you consider that you only need to CHMOD a CGI script to 500 for it to
run on your RaQ, 755 suddenly looks very unprotected, especially if it has
embedded passwords, encryption routines, etc. Data files only need 400 to
read them or 600 to read/write to them, 444 or 666 starts leaving you site
open, never mind the comic 777. If you need group access (within that site)
to those files, change the second octal by all means, but there's no need to
have the last octal set to anything other than 0 - if you want it to be
secure.

** Having said all that, if you email me (and I can spot your emails from
the filtered cobalt list) then I'll probably send you the script to use at
your own risk, since it might save you the time of looking up how to do it,
and is an education to how simple it is to look into a server you host -
without the need for fancy exploits, admin passwords or shell access.

Regards,
Jonathan Michaelson

Commercial CGI Products
http://www.webumake.com