deleted perl hacks in /tmp

deleted perl hacks in /tmp

[Chris]

I have some web servers which occasionally have hacks that are uploaded that
change their name to look like apache and somehow get apache to send requests
to them.  The result is that people somewhat randomly get pages advertising
self enhancing drugs etc.  The hacks are perl scripts, but they are run from
/tmp and then deleted.  Trying to get anything out of /proc/pid/fd/whatever
just yields an empty file.  Anyone have any ideas on how to recover the
original script?  Right now I just have a process checking for them and
whacking them when I see them, but I'd like to know more about them to actually
prevent them from happening.

Any thoughts would be appreciated!

Chris

Re: deleted perl hacks in /tmp

[Dwight Hubbard]

Have you tried mounting /tmp with the noexec flag? 

On Thu, 2010-04-15 at 17:36 -0400, Chris wrote:
> I have some web servers which occasionally have hacks that are uploaded that
> change their name to look like apache and somehow get apache to send requests
> to them.  The result is that people somewhat randomly get pages advertising
> self enhancing drugs etc.  The hacks are perl scripts, but they are run from
> /tmp and then deleted.  Trying to get anything out of /proc/pid/fd/whatever
> just yields an empty file.  Anyone have any ideas on how to recover the
> original script?  Right now I just have a process checking for them and
> whacking them when I see them, but I'd like to know more about them to actually
> prevent them from happening.
> 
> Any thoughts would be appreciated!
> 
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: deleted perl hacks in /tmp

[Alex]

Hi,

>> I have some web servers which occasionally have hacks that are uploaded that
>> change their name to look like apache and somehow get apache to send requests
>> to them.  The result is that people somewhat randomly get pages advertising
>> self enhancing drugs etc.  The hacks are perl scripts, but they are run from

Have you thought about the applications that you have running under
apache that may be causing this, such as an outdated wordpress,
joomla, phpmyadmin, etc?

It's very likely that it's a vulnerable application causing it, and
the only real fix is to disable the application or update it so it's
no longer vulnerable.

Maybe run one of the security scanners that are out there, such as
websecurify, nessus, or one of the multitudes of Windows scanners. Try
this list:

http://www.dmoz.org/Computers/Security/Internet/Products_and_Tools/Security_Scanners/

Most are easy to set up, pretty comprehensive, and may give you a
direction to head.

Best,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: deleted perl hacks in /tmp

[terry white]

... ciao:

: on "4-15-2010" "Chris" writ:
: web servers which occasionally have hacks that are uploaded 
: know more about them to actually prevent them from happening.
: Any thoughts would be appreciated!
 
    from my reading, this is a security nightmare.  and , i , am hard 
pressed to find a time when "what's" been uploaded, more important than 
the fact, "that is was".
 
    without a meaningful translation of "web server hacks" is a real 
limiting factory in problem resolution.  however, your logs are your 
friend; access, error, and referrer.
 
    securityfocus recently disclosed a problem with apache and wordpress.
 
    a specific description of the environment would be a big help ...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: deleted perl hacks in /tmp

[Chris]

On Fri, Apr 16, 2010 at 02:28:09AM -0700, terry white wrote:
> ... ciao:
> 
> : on "4-15-2010" "Chris" writ:
> : web servers which occasionally have hacks that are uploaded 
> : know more about them to actually prevent them from happening.
> : Any thoughts would be appreciated!
>  
>     from my reading, this is a security nightmare.  and , i , am hard 
> pressed to find a time when "what's" been uploaded, more important than 
> the fact, "that is was".
>  
>     without a meaningful translation of "web server hacks" is a real 
> limiting factory in problem resolution.  however, your logs are your 
> friend; access, error, and referrer.
>  
>     securityfocus recently disclosed a problem with apache and wordpress.
>  
>     a specific description of the environment would be a big help ...

These are large shared servers serving a lot of stuff.  I could only wish that
I had control over how up to date all the web apps were!

Anyway, in this case, finding what is being uploaded is fairly important since
I don't have the luxery of having control over everything.  I don't have a
problem with nuking the processes once started, but I would really like to
prevent them from ever making it do disk and run to begin with.  In order to do
that, I need a pretty good idea of what the hack looks like.  Not only that,
pure curiousity plays a large role too.

My question was not so much about web security (I would pick a different
mailing list for that), as much as it was about whether anyone had experience
or trickery to recover/trap file contents that someone is working really hard
to hide.  Perl obviously read the file to run the sript (anyone can run perl,
so any flags on the /tmp mount are pointless in this case, as perl can read
/tmp all it wants).  Like I said before, reading the open file from proc yields
nothing.  

I guess I might have to bite the bullet and set up a huge space to log a
gazzillion POSTs until I can find what is.

Re: deleted perl hacks in /tmp

[Herta Van den Eynde]

On 16 April 2010 17:45, Chris <chris@deksai.com> wrote:
> On Fri, Apr 16, 2010 at 02:28:09AM -0700, terry white wrote:
>> ... ciao:
>>
>> : on "4-15-2010" "Chris" writ:
>> : web servers which occasionally have hacks that are uploaded
>> : know more about them to actually prevent them from happening.
>> : Any thoughts would be appreciated!
>>
>>     from my reading, this is a security nightmare.  and , i , am hard
>> pressed to find a time when "what's" been uploaded, more important than
>> the fact, "that is was".
>>
>>     without a meaningful translation of "web server hacks" is a real
>> limiting factory in problem resolution.  however, your logs are your
>> friend; access, error, and referrer.
>>
>>     securityfocus recently disclosed a problem with apache and wordpress.
>>
>>     a specific description of the environment would be a big help ...
>
> These are large shared servers serving a lot of stuff.  I could only wish that
> I had control over how up to date all the web apps were!
>
> Anyway, in this case, finding what is being uploaded is fairly important since
> I don't have the luxery of having control over everything.  I don't have a
> problem with nuking the processes once started, but I would really like to
> prevent them from ever making it do disk and run to begin with.  In order to do
> that, I need a pretty good idea of what the hack looks like.  Not only that,
> pure curiousity plays a large role too.
>
> My question was not so much about web security (I would pick a different
> mailing list for that), as much as it was about whether anyone had experience
> or trickery to recover/trap file contents that someone is working really hard
> to hide.  Perl obviously read the file to run the sript (anyone can run perl,
> so any flags on the /tmp mount are pointless in this case, as perl can read
> /tmp all it wants).  Like I said before, reading the open file from proc yields
> nothing.
>
> I guess I might have to bite the bullet and set up a huge space to log a
> gazzillion POSTs until I can find what is.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Is changing the filesystem type an option?  You could temporarily
create a new non-extn filesystem on a free partition and mount it on
/tmp.
In that case, you could  set the undeletable attribute on /tmp
("chattr +U /tmp").  It will be inherited by any file created there.
Problem is that extn doesn't honour the attribute, though you could
patch it if you prefer (cf. http://lwn.net/Articles/211193/).

Kind regards,

Herta


-- 
"Life on Earth may be expensive,
 but it comes with a free ride around the Sun."
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: deleted perl hacks in /tmp

[Chris]

> Is changing the filesystem type an option?  You could temporarily
> create a new non-extn filesystem on a free partition and mount it on
> /tmp.
> In that case, you could  set the undeletable attribute on /tmp
> ("chattr +U /tmp").  It will be inherited by any file created there.
> Problem is that extn doesn't honour the attribute, though you could
> patch it if you prefer (cf. http://lwn.net/Articles/211193/).
> 
> Kind regards,
> 
> Herta

Thank you!  Yes, I will try that out.

Chris

Re: deleted perl hacks in /tmp

[Alex]

Hi,

Some time ago Chris was trying to track down some cracker using perl
to breach his system:

On Fri, Apr 16, 2010 at 5:27 PM, Chris <chris@deksai.com> wrote:
>> Is changing the filesystem type an option?  You could temporarily
>> create a new non-extn filesystem on a free partition and mount it on
>> /tmp.
>> In that case, you could  set the undeletable attribute on /tmp
>> ("chattr +U /tmp").  It will be inherited by any file created there.
>> Problem is that extn doesn't honour the attribute, though you could
>> patch it if you prefer (cf. http://lwn.net/Articles/211193/).

How did it work out? Were you able to mount undeletable? Did you find
out which files they were? Do you now have plans to rebuild the
system?

Best,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html