How is it possible ?

I found a Tr0rradeira.txt perl script running multiple times in my ps list
Tr0rradeira.txt was in /tmp
/tmp is (rw,noexec,nosuid,bind) partition

Tr0rradeira.txt or ".br" domain (typical in these cases) are not found in httpd logs

any clues of ...

1) how did it come ?
2) why /tmp can execute things ?

I've been told it's perl that has been run first, like when you do it on the command line:

perl someperlfile.pl

It simply uses the file in tmp to do it's stuff.

From what people are saying, it's from things like phpBB that haven't been updated, so check that first.

If you think about it, you could also do it with some other things just like they use perl:

sh nasty-script.sh
echo nasty-script > some-existing-script
cp nasty-program some-cron-job

All run by apache. The last two could overwrite any file that is normally executed, if you could call cp or echo from apache that is.

eth00 has mentioned a solution but it requires you to recompile the kernel. In a post he said:

"The other option is to limit apache from running perl programs. This can be done via POSIX ACLs after recompiling the kernel"

But I don't think a lot of people want to do that.

The other problem is that perl and shell "cgi" scripts are part of a lot of websites and so apache needs to call them.

I was thinking that you could take apache out of the group that is allowed to run shell, perl and all the others, but then I don't think you could use shell or perl scripts with your web pages.

I haven't done enough research on this, mostly because of lack of data on how these things are done from the outside exactly, but as you can see it's not a easy problem to solve.

eth00 has a good guide to set up mod_security that will help filter out some of the URLs they try to use. He also has some good info on securing PHP. See http://www.eth0.us/

mod_security is installed !

i do not find the way he inserted that there...
(besides, there's no phpbb or egallery installed)

The group deal will not work. Apache does not need a valid shell to still execute commands and besides, what about php and perl for legit uses like cgi. You could chmod 000 perl but then the entire system would start to break, you do NOT want to do that.

I have not published any of the kernel stuff yet because I am too busy working with it for servers I manage. IT requires POSIX ACL support then simply setting the permissions with a few lines of commands.


It does not have to be phpbb, it can be any php run application. There are a lot of them out there and many of them are exploitable. Mod_security does help block most of the problems but unless you use a gigantic ruleset stuff is still going to get through, even then something may still get through. The thing to keep in mind is a big ruleset consumes a lot of cpu for processing.

Did you have eth00's list of filters put in your mod_security?

I was just saying from what I have seen on the forums lately it's usually a php script like phpBB, but it could be other things, you may want to check the versions of things your users have installed.

Is anyone willing to write a script that would go through all users accounts and check the versions of the more popular programs? (and keep it updated)

And for eth00, thanks and yes you are right, I guess the group would be the same as blocking access completely.

I don't understand how they execute perl from a php input line. Is it only php stuff that's old allowing it? I mean, if it's as simple as "index.php?cmd=perl%20nasty-program.pl" then I can see how easy that would be.

With the above it would be simple to just upgrade to a fixed version of the php program. There's no reason to allow outside people to create a command like that, it's just bad programming.

As a server admin, it shouldn't be able to happen, no matter how bad the programmer is because you never know what your users are going to install next.

If you could get apache to only allow perl or shell to be called from the cgi-bin directory and/or have it only run programs that are in the cgi-bin, maybe that would work.

yeah, i know that stuff...
I have searched "cmd", "wget", "pl", "the name of the script", and "perl" in all httpd logs, and no results!

that's because i'm very confused

It's important to know this so I ask it again;

Did you have eth00's entire list of filters put in your mod_security?

I am talking about the specific instructions at
http://www.eth0.us/mod_security

The new injection attacks do not even use them in the command line, they call a text file hosted someplace else that has the commands. Some script kiddies have also started to use curl to download files. They are getting smarter and smarter and it is becoming harder to block them via mod_security.

Web1 - Well it is not that simple, they are getting very good at masking it. PHP allows execution via the exec function which people need for imagemagic among other things... It is not a flaw in php at all, it is a feature. As far as bad programing, well there are so many lines of code I would like to see you code it correctly.... If you want something that will be less suseptible code it yourself.

Web1 Just because you are the server admin means nothing. I can lock a php down so that none of this will happen but good luck hosting anything on it. The simple matter is the features in php that we all like are the same things are people are exploiting. So while you are up on your holy chair sit try to come back down to an earthly level and think about it. If you want secure hosting you have to disable the features people want. Now that you are down on the real earth you will see that leaves the server open to some exploitation.

Web1 as far as perl only being called from the cgi-bin, that does not make sense. It is the same problem as the /tmp running perl scripts, the perl binary is being called from /usr/bin/perl so every time you call it for all of the different purposes it will be the same place. You can either turn perl on or off, unless you want to go in and reprogram perl (obviously not a viable idea) and try to limit it.

It is still possible to upload stuff even using that ruleset, it just helps block most of the exploits. I could make a bigger ruleset but it would start to slow down slower servers.

OK, now what are you talking about? A text file doesn't execute on my server.OK, so we have another thing to set to 700. Any more? let's get a list going.

Yea, I think they read the EV1 forums

In that case you can control what programs they can call, just don't install imagemagic, let them use GD.

I do, all the time, and I always think about security and input exploits A lot of programmers are lazy and don't take the time to do things right.

I write all kinds of stuff so don't tell me it can't be secure enough to not let people drop a program into your server area and run it. It just takes a little more time and thought on the part of the programmers. They seem to be doing the fixing after the fact. It's the same amount of time spent.

I probably wasn't clear, I was talking about not allowing it to run anything that isn't in the cgi-bin when apache calls it. It's just a thought.

It's only called when someone does a POST command, isn't it?

yes, even my ruleset are more agressive...


anyway... it's the sysadmin life...

The thing to keep in mind is each incoming request has to be scanned by every rule. If you have a very busy server this can significantly slow it down. If you do end up having trouble with the server load I would suggest taking a look at the mod_sec rules and shortening the list to help.