[Mailman-Users] message about probes

[Steff Watkins]

> -----Original Message-----
> From: mailman-users-bounces+s.watkins=nhm.ac.uk at python.org 
> [mailto:mailman-users-bounces+s.watkins=nhm.ac.uk at python.org] 
> On Behalf Of Stephen J. Turnbull
> Sent: 29 April 2009 16:29
> To: Mark Sapiro
> Cc: Gruver, Sandi; 'mailman-users at python.org'
> Subject: Re: [Mailman-Users] message about probes
> 
> Mark Sapiro writes:
>  > Gruver, Sandi wrote:
> 
>  > >!!!! 2 possible successful probes
>  > > 
> /mailman/private/sqlhelp///includes/session.php?baseDir=../../
../../../../../../etc/passwd HTTP Response 200
>  > 
>  > I saw the same thing in my Logwatch the other day. These 
>  > messages are reported in the httpd report.

These are, IMNSHO, attempts by persons (or scripts or bots) to attempt
to "exploit" a potential hole that may be in your setup.

Of course, if the hole isn't in your setup then they get no success and
so no exploit. Ho hum, they'll say, and move on to one of the X hundred
millions of other websites on the internet and try again. It's "shotgun
principle"; take a shotgun into a field with 100 crows, fire the shotgun
and you're bound to hit at least one crow.

> Aha, I see where I went wrong ... /mailman is an Apache ScriptAlias
(or equivalent), isn't it.  (I prefer a cgi-bin ScriptAlias so
> it's immediately obvious what the URL is supposed to resolve to.)

I think you may be mixing up concepts here, or rather splitting a
concept. A ScriptAlias under Apache points to a cgi-bin location and so
it IS a "cgi-bin alias". They're both "obvious" where they point to if
you look through the webserver config file. As Apache is one of the
major players in the webserver market, it is likely that your install of
Mailman runs under Apache and so technically it'd be an Apache
ScriptAlias to Mailman! :)  

> Good to know that this probably isn't a problem after all.  But do
> check the logs to make sure that it is mailman's CGIs that are being
> accessed!

I did a quick scan through the code of my local Mailman setup and could
not find a session.php file. If anything this looks like an attempt by
someone or something to try and exploit one of the many CMS systems that
are out there that have session handlers written into their code.... Or
possibly a bulletin board system or two!

The attempt works by calling a php script called session.php which is
passed the variable 'baseDir=../../../../../../../../etc/passwd'.
Whatever script this is targetted at has probably been found to have a
duff sanitising routine and so will probably evaluate it directly. If
the script is NOT buried more than 8 levels of sub-directory down the
target website it will eventually evaluate to "/etc/passwd". The script
is labelled as "includes" so I'm guessing it is meant to just reurn the
contents of the requested file. In this case, it'd be /etc/passwd.

This in itself is of questionable use. They could potentially get some
usernames out of it if it worked but most likely would not get many (or
any) of the encrypted password hashes as they are stored in the
/etc/shadow file (usually, depending on O/S). 

> Mark, do you understand what the attacker is trying to exploit here?
It's not at all obvious to me.

They're attempting to force a script to return to contents of the
password file.

> Since /mailman/ is a scriptalias, and those are both actual scripts,
it's mailman/private and mailman/admin
> that are going to be interpreting everything after the script name.

Hhmm... Except the /mailman/ scriptalias itself points to a directory...
which is marked up as "active content" by virtue of being a script
alias. Now, unless you have had a really bad run of luck and the person
who setup Mailman felt they really needed a 'backdoor' in to be able to
see what was in there and so setup a htaccess file/index.php, what
SHOULD happen is a call to http://blahblah/Mailman/ will return a big
fat juicy failure message telling the user/bot that they are not allowed
to look there.

> The next segment of the path is the listname, and anything after that
> is either garbage or a query about the list, so I can't see an attempt
> to exploit mailman here, despite the fact that they're specifically
> invoking mailman CGIs.  Am I missing something?

I'd guess that it was not a Mailman specific 'attack', mainly because of
the call to includes/session.php. A poorly setup webserver could, maybe,
possibly, ever so slightly try and satisfy the request but if you have a
setup like that then it's not really hackers/crackers/phreakers you have
to worry about more than your sysadmin/webadmin who has let that setup
run on the public internet in the first place.

I think that this has raised a good point though. If you spot
'questionable activity' to your webserver systems then it's probably
wise to spend a few minutes looking at it, cut'n'pasting the same URIs
inta web-browser and seeing what it shows and looking at the webserver's
logfiles. Make sure that your webserver behaves properly, or fails to
behave in a way that would be useless to any potential attacker... and
then move on.

Steff (currently going slightly mad sorting out samba access problems!)