The Community Forums

Interact with an entire community of cPanel & WHM users.
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

/tmp/back script even with APF+modsecurity+securetmp

Discussion in 'Security' started by pcsousa, Oct 8, 2008.

  1. pcsousa

    pcsousa Well-Known Member

    Joined:
    May 28, 2004
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    Hello.

    Today I found a /tmp script (/tmp/back).
    I have APF firewall and anti-DoS, secured tmp's and modsecurity2 on apache2 running gotroot rules.

    How can it is possible to write a perl file on /tmp? File has not run permitions, but is a Perl file, so I think they ran it. I found this script after someone to send mail bomb through the server (about 9000 each time).

    Server simptoms:
    several connections from my server to ftp.hosteurope.de
    several phishing emails being sent over my server

    Script code:
    Email Bazilian content:
    How can server possible be compromised?

    Any help will be appreciated.

    Regards.
     
    #1 pcsousa, Oct 8, 2008
    Last edited: Oct 8, 2008
  2. oshs

    oshs Well-Known Member
    PartnerNOC

    Joined:
    Sep 5, 2004
    Messages:
    146
    Likes Received:
    0
    Trophy Points:
    16
    Hi,

    Firstly I don't think you should paste what you think is malicious code on these Cpanel forums. A moderator will probably snip it soon.

    Secondly, looking at the Perl file we see that it is sniffing for information using

    Code:
    $cmd= "lynx";
    So make sure you

    Code:
    chmod 750 /usr/bin/lynx
    Are you sure you have secured /tmp properly? If so these files may be sitting there, but should not be able to run.

    The script you have pasted is not the mailbomb script. The mailbomb script is probably being run as a PHP script in a user's home directory. You need to locate it and shut it down.

    You also should disable some PHP functions.

    Install CSF instead of APF as that will give you many pointers for server security.

    And definitely install SuPHP.

    Finally hire a server admin if you want your server locked up properly.
     
  3. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    No matter what security measures you have in place, nothing comes close to the security of a well programmed and up-to-date script.

    You can install all the firewalls that you want, all the mod_security rules that you want, run PHP with suPHP and disable all of the PHP functions, if your users are running outdated scripts or improperly coded scripts, then there is always the potential for exploits through those scripts.

    Running a firewall and a good mod_security set is good, in fact its probably vital in a shared hosting environment. But don't think just because you have these in place that your server is safe and secure. In fact with a firewall in place, it is doubtful that this script did anything on your server, but it does mean that you have an insecure script somewhere on your server.
     
  4. jpetersen

    jpetersen Well-Known Member

    Joined:
    Dec 31, 2006
    Messages:
    113
    Likes Received:
    4
    Trophy Points:
    18
    Just to clarify:

    The script isn't using lynx. It's setting $0 to lynx:

    Code:
    $cmd= "lynx";
    $0=$cmd;
    
    Basically what this means is that when the script ( /tmp/back ) is run, instead of showing "back" as the name of the process in the process list, it will show as "lynx".

    perl scripts (and others such as php, python, and ruby scripts) can still be run from a partition that is mounted noexec.

    From the manpage for mount:

    Code:
    [b]noexec[/b] Do  not  allow direct execution of any binaries on the mounted file system.
    and from the execve manpage:

    Code:
    EACCES The file system is mounted noexec.
    
    Since the perl script is not a binary, it does not rely on using the execve() system call. As such, it is not restricted by the noexec setting.
     
  5. oshs

    oshs Well-Known Member
    PartnerNOC

    Joined:
    Sep 5, 2004
    Messages:
    146
    Likes Received:
    0
    Trophy Points:
    16
    Thanks for this info jpetersen.

    I'm not a Perl coder and didn't look hard enough at this code to understand it.

    That's interesting that such a script could still be run under a partition mounted with noexec attribute.

    What do you advise in detecting/preventing such scripts from being run on the server?

    Regards,
    Suhail.
     
  6. jpetersen

    jpetersen Well-Known Member

    Joined:
    Dec 31, 2006
    Messages:
    113
    Likes Received:
    4
    Trophy Points:
    18
    Hi Suhail,

    Sure thing, glad to help out! If you're interested in learning a bit more, check this page out:

    http://perldoc.perl.org/perlvar.html

    Look for the part that says:

    $PROGRAM_NAME
    $0


    as it will explain $0 a bit more in depth.


    As far as detecting such scripts, I know that CSF has some logic to do just that. Check out line 2952 from lfd.pl (the lfd.pl that is included in CSF 4.10):

    $ vi lfd.pl +2952

    If the first line of a file in /tmp starts with this: #!
    then CSF will send an email alert to the sysadmin.

    As far as preventing the execution of such scripts, that's something very different and much more complex. I'm not aware of any simple solutions for this.
     
  7. oshs

    oshs Well-Known Member
    PartnerNOC

    Joined:
    Sep 5, 2004
    Messages:
    146
    Likes Received:
    0
    Trophy Points:
    16
    Many thanks for tips/pointers :)
     
  8. pcsousa

    pcsousa Well-Known Member

    Joined:
    May 28, 2004
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    Many thanks for tips.

    wget and lynx are 700 for long time ago on my system.

    At this point I'm concerned how this script get /tmp and why. They don't need to put a perl script on /tmp to run it.

    Yes, /tmp is noexec, but as said, this is intrepreted by other program (perl):
    root@ [/tmp]# echo "echo 'test'" > script |chmod 700 script
    root@ [/tmp]# ./script
    -bash: ./script: Permission denied
    root@ [/tmp]#

    Also:
    -bash: ./back: /usr/bin/perl^M: bad interpreter: No such file or directory
    unless they know the real perl script, they didn't ran it. But this scrip works. I've tried it with netcat on another server.

    I know this is not a mailsender. I just think it's same guy.

    By the away, server has now suphp and php_mail_headers.

    I'l give a shot on CSF one these days.

    Regards.
     
  9. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    You can still run the script, you just can't run it directly.

    In your example instead of:

    ./script

    run:

    /bin/bash script

    This will work.

    You have to understand that noexec on /tmp isn't going to stop everything.

    Someone on your server is running an outdated script. It could be an old phpBB script, it could be an old Wordpress script, it could be anything. But someone has or had an old script installed (probably more than one.. a lot more ... but don't get too alarmed by this, this is common on almost any web server). Hackers or some type of malicious user found this old script. Old scripts are usually old because they had a security hole in them. The hackers or malicious user used this security hole to exploit the script and gain access to your server.

    They didn't get a whole lot when they gained access. All they got was the same access level that the user nobody has on the server (which isn't a whole lot, so don't think of this as a severe root compromise). That allowed them to place this file in /tmp and possibly execute it.

    A properly configured firewall will prevent the script from making any connections. That may have been what happened here.

    A good mod_security ruleset would likely also help prevent the old and outdated script from being exploited.

    However, nothing compares to the security of a well up-to-date and maintained script. This is why it is so important that your hosting account users understand that when they install a script on their account, they are not done, they are just getting started. Installing a script on an account is step 1. Step 2 and so on is continuing to keep the script up-to-date whenever a new version is released.

    To put this in perspective. If you have a server and it has one account on it. And that one account only runs Wordpress. If the owner of that account upgrades that Wordpress script the second that a new version is released. You basically have no need for mod_security. If all of the scripts on all of your accounts on your server are being kept up-to-date, then this is really the best security model that can happen.

    (A gentle note, I wouldn't run a server without mod_security regardless if the above scenario is true. I'm just pointing out that mod_security is less needed in the above scenario. mod_security would still help to protect against 0-day exploits and exploits that reach the wild before the Wordpress developers can patch against it)

    If you are not running suPHP when this was exploited, the only way to track the exploit is through comparing timestamps. You take the timestamp of when the exploit was created on the server. Then run through all of your domlogs to find hits that occurred on or around that timestamp. This will get you closer to finding the exploited account. You then just have to filter those results, look for PHP scripts, look for possible warning signs and find your culprit. It gets real fun, when the web script that was responsible for writing this exploit script is also an exploit script and then you have to do this all over again for that script.

    Running suPHP allows you to narrow this down to a specific account. Then you can compare timestamps for all of the domlogs under that account, which should be a much smaller sample size and easier to find.

    Comparing timestamps doesn't always provide an answer, which again is another good reason to run suphp. If timestamps come up empty, you at least know the account that was responsible for the exploit.
     
  10. pcsousa

    pcsousa Well-Known Member

    Joined:
    May 28, 2004
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    sparek-3

    Many thanks for your time replying to this thread.

    Well catched on /bin/bash script detail! :eek:

    You right on many things. For instance "I wouldn't run a server without mod_security regardless if the above scenario is true"... That's why I have mod_security. It's impossible to control that variable (every script up2date).
    The problem is the false positive match. I think gotrules rules are good, but after install them, I need to remove some locks, otherwise nice scripts (like myPhpAdmin, one I can remember now because I use extensively) will not run well. That's also why I didn't update rules automatically.

    Now I'm running on suphp but probably I'll never discover the exploited account because as far as I can understand, nobody files and files with write permissions will now be blocked.

    Timestamp suggestion is nice, but too late now :\

    Regards.
     
Loading...

Share This Page