Prevent execution of perl scripts

Discussion in 'Parallels Plesk Panel for Linux - 8.x and Older' started by CiViX, Jul 13, 2006.

  1. CiViX

    CiViX New Member

    Messages:
    120
    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)?
  2. crobinson

    crobinson New Member

    Messages:
    38
    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
  3. CiViX

    CiViX New Member

    Messages:
    120
    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]hostmaster@mydomain.com[/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!
  4. atomicturtle

    atomicturtle Product Expert

    Messages:
    3,769
    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.
  5. crobinson

    crobinson New Member

    Messages:
    38
    Wicked Work Civix

    I'll try that stuff out.

    Thanks!

    -Carl
  6. Linulex

    Linulex Product Expert

    Messages:
    725
    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
  7. CiViX

    CiViX New Member

    Messages:
    120
    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...
  8. atomicturtle

    atomicturtle Product Expert

    Messages:
    3,769
    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!)

Share This Page