[Mailman-Users] message about probes

[Donna Dierker]

See inline comments below.

On 04/29/2009 11:34 AM, Steff Watkins wrote:
>> -----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). 
>   
It could be used to spoof addresses of valid list members in spam to lists.
>   
>> 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.
>   
This is exactly what do, and I find the URLs, when pasted in browsers, 
give not found responses.

But it's worth pointing out that we've had mailman installed for over 
seven years without these probes.  It was only after we switched our 
main web site to a wiki a few months ago that we started seeing these 
probes.  The attempts on our server are using the wiki index.php, e.g.:

    /wiki/index.php?doc=../../../../../../../../../../../../../etc/passwd%00? HTTP Response 200 
    /wiki/index.php/index.php?doc=../../../../../../../../../../../../../etc/passwd%00? HTTP Response 200 


> Steff (currently going slightly mad sorting out samba access problems!)
> ------------------------------------------------------
> Mailman-Users mailing list
> Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-users/donna%40brainvis.wustl.edu
>
> Security Policy: http://wiki.list.org/x/QIA9
>