Results 1 to 22 of 22
  1. #1
    Join Date
    Sep 2004
    Posts
    242

    how to stop this attack ? [Bypass safe_mode & openbase dir]

    Hello

    Recently , some of our Linux/cPanel servers got hacked (not rooted) by using the following code (method)

    #!/usr/bin/perl
    symlink ("/home/USER/config.php","/home/USER2/test.txt");

    The hacker just execute the perl file , and then he called the "test.txt" file through internet explorer , and its done , he can read the file easily !

    We tried to :

    1- run php as CGI module .
    2- run SUPHP module .
    3- run php as apache module.
    4- enable open_basedir and safe_mode .

    But the hacker still can bypass the system !

    the only solution is to disable /usr/bin/perl , chmoded it to 700 . but thats caused a broken cpanel !

    as it requires it to be at 755 for proper operation, since it is used by customers as well when it suexec into the user when they log into cPanel. and so we cannot change it to that setting (700) , since it breaks the entire system.

    So is there any way to stop the "symlink" perl function ?

    any way to stop this attack method ?

    Thank you !
    Last edited by learnerman; 02-06-2008 at 11:43 AM.

  2. #2
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    How is the script being run/called?
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!

  3. #3
    Join Date
    Sep 2004
    Posts
    242

    Unhappy

    Quote Originally Posted by bitserve View Post
    How is the script being run/called?
    Thank you for stopping by my post .

    it doesnot a matter how they called the file , they can call it via cron job(cPanel Feature) , via httpd (direct url http://site.com/perl.pl) or even via a phpshell !


    Any suggestion ?

    Thank you !

  4. #4
    Join Date
    Nov 2007
    Posts
    181
    To me, all the methods you used to stop it were for PHP/CGI and not Perl. Try some Perl security measures.

  5. #5
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    I might be confused, but it looks to me that the attacker is just making it so they can access or view another user's file. If so, you should ensure that CGI is using the suexec wrapper and have the other users set their permissions lower so they can't be accessed/viewed. They shouldn't then be able to run another users script from their own CGI process or that of a cron ran process. If they are using PHP to somehow call the Perl script and it's running as a global user (nobody), then phpsuexec or suphp would solve that problem as well. Then, provided permissions aren't open to the world, no user should be able to access (or view) or run another user's file/script.

  6. #6
    Join Date
    May 2006
    Posts
    1,398
    UPDATE: the grsecurity function wont prevent links to world writable files with that perl function. If the files arent word writable though linking fails. the grsecurity function does a totally different thing. It prevents following links owned by other users
    Last edited by jon-f; 02-06-2008 at 05:47 PM.

  7. #7
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    You'll pretty much have three different sets of likely problems and answers depending on if they call it via cron, perl CGI or from a PHP script. Also, if it works from all three, that would indicate quite a bit. Are you saying that it works from all three?
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!

  8. #8
    Join Date
    Sep 2004
    Posts
    242
    Quote Originally Posted by Karbon View Post
    To me, all the methods you used to stop it were for PHP/CGI and not Perl. Try some Perl security measures.
    Hello
    Can you plz mention some of these measures ? some links , more details ,Keywords will be appriciated too .

    Thank you !

  9. #9
    Join Date
    Sep 2004
    Posts
    242
    Quote Originally Posted by bitserve View Post
    You'll pretty much have three different sets of likely problems and answers depending on if they call it via cron, perl CGI or from a PHP script. Also, if it works from all three, that would indicate quite a bit. Are you saying that it works from all three?
    Yes all of them working , calling the perl file via cron working as a charm , also via some phpshells !

    I also tried to "chmod 000 /bin/ln" , but the perl file still have the ability to create the links !

    Thank you for your time

  10. #10
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,842
    Any reason you can't just set permissions on the config files individually?
    Code:
    chmod 600 /home/USER/config.php
    You'd need to be running php as suexec / suphp, of course.
    Chris

    "Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." - Laurence J. Peter

  11. #11
    Join Date
    Sep 2004
    Posts
    242
    Quote Originally Posted by foobic View Post
    Any reason you can't just set permissions on the config files individually?
    Code:
    chmod 600 /home/USER/config.php
    You'd need to be running php as suexec / suphp, of course.
    Hello

    Okay They are hosting servers , contains 100s of sites !

    we can not set all files perm. manually !

    Is there any command/bash script will do the job ? (find all bad perm. and reset them to 600 for example)

    Thank you !

  12. #12
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    You can compile for phpsuexec or suphp and then either run a command or two or create a script to check for permission and ownerships and set them accordingly.

  13. #13
    Join Date
    Jan 2008
    Location
    Internet
    Posts
    20
    Chmod-ing the /home/user directories to 750 won't help?

    You will still need to be running phpsuexec on the server for the above to work.

  14. #14
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    If it's a Cpanel server using phpsuexec, you can only set the web root directory to 750 (or 710), as mail related files need to have access to the user's parent home directory itself, but I believe that's what all of the web root's are on Cpanel servers by default anymore -- though it's true (and a good point) that it doesn't offer any protection (for PHP) unless you're running phpsuexec or a similar wrapper (CGI is still better protected regardless, since suexec is default for normal CGI (for C, Perl, Python and CGI PHP scripts), so you can still at least offer protection in that regard, if you have qualms about phpsuexec or suphp).

    Which, speaking of, the phpsuexec hack that Cpanel used is really out of date and you risk security issues the way they modified that patch. I'd suggest using the original phpsuexec patch and maybe mod it yourself, if at all, as Cpanel's version is seriously and stupidly hacked up due to their "global script" redirects and requirements (maybe they changed it by now, I've not looked, but it was like that for many, many years). Thus, suphp is a better option (and that's what the original patch author said himself when he stopped his patch many years ago, suggesting to just use suphp instead). Anyway, food for thought.

  15. #15
    Join Date
    Feb 2005
    Location
    Australia
    Posts
    5,842
    Tim, I believe recent CPanel versions use suPHP by default.

    StoAdm, it's not just the user's root directory - most of these config files end up under public_html (and it's the apache user that's reading them!)

    Quote Originally Posted by learnerman View Post
    Is there any command/bash script will do the job ? (find all bad perm. and reset them to 600 for example)
    Something like this should remove world access from any file called *.php:
    Code:
    find /home -type f -name \*.php |xargs chmod o-rwx
    (untested - try it on a small directory first!)
    Chris

    "Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them." - Laurence J. Peter

  16. #16
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    I think Cpanel defaults to suphp now as well. The reason is they offer Apache 2.x now and the phpsuexec patch they used over the years doesn't work with Apache 2.x.

  17. #17
    Quote Originally Posted by learnerman View Post
    #!/usr/bin/perl
    symlink ("/home/USER/config.php","/home/USER2/test.txt");

    <snip>

    1- run php as CGI module .
    2- run SUPHP module .
    3- run php as apache module.
    4- enable open_basedir and safe_mode .
    The issue here as someone mentioned is that all your measures are to block PHP scripts. Naturally it will be useless for Perl. You have just highlighted one of the biggest fallancy in server management that using safe_mode and openbase_dir, you are secure. Many forget that Perl can be a bigger issue and there's no similar inbuilt protections. On top of that an adapt programmer can do a lot more damage in Perl compare to PHP.

    If you do not offer CGI-BIN for clients, disable CGI / Perl functionality totally from Apache. That will stop this particular attack. We have done similar for some clients who didn't offer cgi-bin. This will not break Cpanel the way chmodding it 700 will. If you do offer, then the only way currently is proper system permissions. That of course is a subject on its own.
    Like us on Facebook to qualify for discounts!
    http://www.sprintserve.net
    Offering: | Internap FCP Bandwidth! | Rebootless Kernel Updates! | Magento Optimized Hosting | Wordpress Hosting |
    Services: | Managed Multiple Cores 64bit Servers | Server Management |

  18. #18
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    First, this issue is NOT about Perl (that has nothing to do with it). The cgi-bin directory is just a common script aliased directory name, so I assume you mean to say to also disable the cgi-script handler list of file extensions and disable CGIExec? Regardless, PHP can run as CGI, as can C, C++, ruby, shell scripts, Python, etc., so if you only want to allow PHP itself, that is up to you. I don't recommend this and there are perfectly reasonable ways to allow CGI scripts (CGI really has nothing to do with Perl anymore than any other language), but if absolutely no client uses CGI, you can use the PHP Apache API. Problem is, now all of the user's scripts need the same permissions and globally run as the same user.

    It's actually much easier to control CGI scripts than something ran in the Apache API, and Perl (and other languages) can be just as secure as PHP (and in fact, Perl is much more secure than PHP as a language itself). It's all about how you configure the server. Also, everything from permissions and ownerships in addition to a CGI wrapper (suexec), to things such as specifically setting what's allowed in a user's .htaccess control file (such as setting SymLinksIfOwnerMatch (or allow none at all) and so on, and only allowing options you specifically trust and allow, and disallow everything else). If you have user's creating problems by doing hardlinks and symbolic links from one account to another, then allowing Perl, or Python, or Ruby, or PHP, or anything else as CGI, is the last of your concerns.

  19. #19
    Join Date
    Nov 2001
    Location
    Ann Arbor, MI
    Posts
    2,978
    Quote Originally Posted by learnerman View Post
    Yes all of them working , calling the perl file via cron working as a charm , also via some phpshells !

    I also tried to "chmod 000 /bin/ln" , but the perl file still have the ability to create the links !

    Thank you for your time
    If all three of the methods you mentioned work, then it's probably just a file/directory permissions problem. Once you get that sorted out though, you may still want to make sure that the user's CGI and cron jobs are running as the appropriate user or jailed somehow.
    -Mark Adams
    www.bitserve.com - Secure Michigan web hosting for your business.
    Only host still offering a full money back uptime guarantee and prorated refunds.
    Offering advanced server management and security incident response!

  20. #20
    Join Date
    Jan 2006
    Location
    Morocco
    Posts
    73
    yes this is a known atack to vbulletin config file .

    i think in the first step is disable perl extention in mod_security . and then search how to prevent this perl function .

    i was the same case , i have disabled the perl extention and it work perfectly .

    note : all other perl script will be not working more .
    From The

  21. #21
    Join Date
    Jun 2007
    Location
    Jordan
    Posts
    322
    please Activa can u let us know how you disable perl extention and please guys what function you prever to Disable for the php.ini File ?

    regards .
    Learn whatever you read ...
    Some day you well tech ...
    E-Learning .

  22. #22
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    As mentioned previously, Perl itself isn't the issue. You can disable it in various ways, though setting lower permissions is best. While you're at it, you may as well disable Python, PHP, shells (bash, ksh, etc.), ruby, C and C++ compilers, etc. Don't forget to disable SSI. You may as well just only allow HTML and graphics files, css, etc. I don't think you'll get many clients this way without any features.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •