> -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of Stephen J. Turnbull > Sent: 29 April 2009 16:29 > To: Mark Sapiro > Cc: Gruver, Sandi; '[email protected]' > 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!) ------------------------------------------------------ Mailman-Users mailing list [email protected] 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
