deleted perl hacks in /tmp

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

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


--
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

Hi,

>> I have some web servers which occasionally have hacks that are uploa=
ded that
>> change their name to look like apache and somehow get apache to send=
requests
>> to them. =A0The result is that people somewhat randomly get pages ad=
vertising
>> self enhancing drugs etc. =A0The hacks are perl scripts, but they ar=
e 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/Secu=
rity_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

.... 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 ...

--
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

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

Re: deleted perl hacks in /tmp

On 16 April 2010 17:45, Chris 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!
>>
>> =A0 =A0 from my reading, this is a security nightmare. =A0and , i , =
am hard
>> pressed to find a time when "what's" been uploaded, more important t=
han
>> the fact, "that is was".
>>
>> =A0 =A0 without a meaningful translation of "web server hacks" is a =
real
>> limiting factory in problem resolution. =A0however, your logs are yo=
ur
>> friend; access, error, and referrer.
>>
>> =A0 =A0 securityfocus recently disclosed a problem with apache and w=
ordpress.
>>
>> =A0 =A0 a specific description of the environment would be a big hel=
p ...
>
> These are large shared servers serving a lot of stuff. =A0I could onl=
y 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 import=
ant since
> I don't have the luxery of having control over everything. =A0I don't=
have a
> problem with nuking the processes once started, but I would really li=
ke to
> prevent them from ever making it do disk and run to begin with. =A0In=
order to do
> that, I need a pretty good idea of what the hack looks like. =A0Not o=
nly that,
> pure curiousity plays a large role too.
>
> My question was not so much about web security (I would pick a differ=
ent
> mailing list for that), as much as it was about whether anyone had ex=
perience
> or trickery to recover/trap file contents that someone is working rea=
lly hard
> to hide. =A0Perl 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 ca=
n read
> /tmp all it wants). =A0Like 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 lo=
g 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 =A0http://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


--=20
"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

> 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
--
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

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 wrote:
>> Is changing the filesystem type an option? =A0You could temporarily
>> create a new non-extn filesystem on a free partition and mount it on
>> /tmp.
>> In that case, you could =A0set the undeletable attribute on /tmp
>> ("chattr +U /tmp"). =A0It will be inherited by any file created ther=
e.
>> 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