• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Prevent execution of perl scripts

C

CiViX

Guest
We're reallly plagued by script-kiddies uploading scripts to /tmp and executing them via perl. Yes, /tmp IS mounted nosuid,noexec,nodev,noatime so they can't run programs from this directory, but they can run perl from another location using the script (textfile) uploaded in /tmp.

We're running the full rulesets from http://www.gotroot.com/mod_security+rules but still they manage to upload and run the scripts.

I usually find scrips (text-files) in /tmp, but sometimes also in directories with 777-permissions, which customers create to allow webapps to upload files since php runs as apache and not as the user :-(

What happens if I disable perl by chmodding /usr/bin/perl to 000 (as I have done with /usr/bin/*cc*)? Will this break things? Is there a way to stop perl-scripts from being executed like this?

Do anyone have scripts that I can run as a cronjob which kill unknown processes run as user apache for more than 5 minutes (or something)?
 
Same Problem....

I am having the same problem and it really makes me want to shoot those script kiddies. Any luck on hunting down a solution?

-Carl
 
I think I found the reason why mod_security wasn't blocking those attacks where files were being downloaded to /tmp and 777-dirs by exploiting security-holes in php-applications. I was running mod_security using:
Code:
SecFilterEngine DynamicOnly

However, it seems that if php is "activated" using:
Code:
AddType application/x-httpd-php .php .php4 .php3 .phtml
in /etc/httpd/conf.d/php.conf (or directly in httpd.conf), then php-generated pages aren't identified as "dynamic" and therefore ignored by mod_security.

As soon as I set mod_security to:
Code:
SecFilterEngine On
it started catching all those attacks where files were being downloaded by using "wget", "cd%20/tmp", "perl" and so forth in the URLs.

Using "SecFilterEngine On" scans all pages, even static (like html, gif, jpg, css) so it heightens the server-load. There seems to be a solution though. Replace AddType with AddHandler and mod_security should correctly identify php-pages as dynamic:
Code:
AddHandler application/x-httpd-php .php .php4 .php3 .phtml

Then you can use DynamicOnly again.

I have also created a script for killing those unwanted processes as soon as they show up. This isn't a fix for the problem, but it can help you at least temporarely. The script is called kill_processes.sh and I place it in /usr/local/sbin/ and run it as a cronjob every minute.

Code:
#!/bin/bash

# Find process-IDs (PID) for unwanted processes and kill them

# List unwanted processnames or some text that can uniquely identify the unwanted process. Separate the strings with a single space.

UNWANTED="httpssql DSSL httpdse"

for PROGRAM in $UNWANTED
do
        for PID in `ps aux | awk '/^apache.+'"$PROGRAM"'/ {print $2}'`
        do
                #lsof -p $PID | mail -s "Files used by unwanted process" [email][email protected][/email]
                kill -9 $PID
                #echo $PID
        done
done

(Note the difference between ` and ' and " in the shellscript.)

Uncomment the "lsof..."-line if you want the script to email you a list of files used by the unwanted process. This can help you find the script so that you can delete it.

For testing purposes you can comment out the "kill"-line and uncomment the "echo"-line so that it only lists the process-IDs.

I hope this helps!
 
We stop this from happening in ASL by setting the process ACL on interpreters like perl, sh, ksh, bash, python, etc that they can't run from any publically writable directory.
 
We had the same problem and came up with a very simple but extremly effective solution: delete wget from all servers

If a client on a dedicated server really needs wget we install it for him but rename it.

regards
Jan
 
I now see that DynamicOnly has been deprecated in mod_security 1.9.4, so the whole AddType/AddHandler thing isn't really relevant anymore as you have to use
Code:
SecFilterEngine On
with the latest version...
 
Theres definitely more than one way to do it. I can't recommend enough to folks to learn about security by trying to exploit your own systems. This is one of those times it helps to go down all the different ways to attack and defend something since its one of the top methods the badguys use to exploit your system. For example:

Beating noexec, you just use an external app to run your commands (perl, python, sh, ksh, bash, etc)

Getting the exploit on the system:
1) wget (external app)
2) curl (external app)
3) lynx (external app)
4) curl (internal to php)
5) php remote include (internal to php)
6) echo/upload via an exploitable app (echo <some perl code> > foo.pl)

There are a lot of others, just use your imagination, and you'll quickly see how to counter those threats. Removing tools like wget is one way, another to create the same effect is make those tools executible only by a specific group, or create process ACL's on the way that tool can be used. GRSEC for example allows you to control the IP address an application can connect to, apply that to apache, or wget for example, and you could restrict their outbound connections on those apps to localhost. (Just came up with that right now.. guess whats going into the next release of ASL!)
 
Back
Top