PHP Exploit query

Discussion in 'Web Design & Coding' started by LordOfLA, Dec 4, 2008.

  1. LordOfLA

    LordOfLA Godlike!

    Messages:
    7,027
    Location:
    Maidenhead, Berkshire, UK
    I'm trying to track down a way to protect a bunch of servers from XSS exploits.

    I'm not understanding how an attacker can inject php code in to a variable with the querystring and then have that variable execute code arbitrarily.

    I have attached 2 files that were recently linked to in a perl script that was successfully dropped in to a /tmp folder. This script could not execute as I have set the perl binary chown root:root and chmod 700. one is the encrypted file as I found it, the other is the decrypted code.

    How do people make a variable execute code that downloads, saves and executes the perl script that then finishes the job?

    Notice the decrypted code contains ?> which is the php close tag.

    Notice the encrypted code starts off <?php.

    How does a variable say $product_id containing the value 8 followed by the contents of the encrypted code actually manage to do anything?
     

    Attached Files:

  2. X-Istence

    X-Istence * Political User

    Messages:
    6,498
    Location:
    USA
    That is not a cross site scripting vulnerability. Cross site scripting vulnerability is when people can do things with users that are logged in to your website, for instance a simplified example:

    I log into my bank
    I browse to bad website 1
    bad website 1 knows that my bank uses just one form to submit transfer requests for money
    They use javascript to send the valid data to my bank it looks like the request came from me
    The money is transferred.

    What you have here is a standard PHP inclusion vulnerability. That code you have attached would be included in random pages that are vulnerable to that. For example, if you have the following code:

    Code:
    include ($_GET['page']);
    to include different pages based on the variables in the URL, that would allow the attacker to instead include /tmp/badfile.php and have it executed within that script. Also they could include arbitrary files that are located on the system, for example /etc/passwd, and stuff like that.

    Now, to drop files on a server requires that there is an exploit available for any of the services running, or any of the PHP scripts that are there. So somewhere there is an PHP script that allows remote file inclusion/remote uploads at which point they have full control over what can and can't be done. Generally the culprit is outdated phpBB versions, along with various bits and pieces of other PHP scripts. The servers I have had this happen on all happened to be running phpBB, and that was found to be the culprit.

    Ways to protect against it?

    phpSuHoSin. It is protection software and makes sure that no external variables are set, it also drops requests that don't make sense or variable names that are too long. It is just another piece of software to stop bad stuff happening. http://www.hardened-php.net/suhosin/. Runs on all of my servers. See the feature list as to what it all adds: http://www.hardened-php.net/suhosin/a_feature_list.html

    Code:
    Dec  3 11:34:31 defiant suhosin[63413]: ALERT - tried to register forbidden variable 'GLOBALS[WE_MAIN_DOC]' through GET variables (attacker '64.251.7.205', file '/usr/home/personal/public_html//index.php') 
    Dec  3 11:34:31 defiant suhosin[14766]: ALERT - tried to register forbidden variable 'GLOBALS[WE_MAIN_DOC]' through GET variables (attacker '64.251.7.205', file '/usr/home/personal/public_html/index.php') 
    Dec  3 11:34:32 defiant suhosin[63412]: ALERT - tried to register forbidden variable 'GLOBALS[WE_MAIN_DOC]' through GET variables (attacker '64.251.7.205', file '/usr/home/personal/public_html//index.php') 
    Dec  3 11:35:10 defiant suhosin[63413]: ALERT - tried to register forbidden variable 'GLOBALS[WE_MAIN_DOC]' through GET variables (attacker '64.251.7.205', file '/usr/home/personal/public_html//index.php') 
    Dec  3 11:35:10 defiant suhosin[14766]: ALERT - tried to register forbidden variable 'GLOBALS[WE_MAIN_DOC]' through GET variables (attacker '64.251.7.205', file '/usr/home/personal/public_html/index.php') 
    
    
    Dec  3 15:21:44 defiant suhosin[77220]: ALERT - configured request variable name length limit exceeded - dropped variable 'ouml;ffnen//modules/xoopsgallery/upgrade_album_php?GALLERY_BASEDIR' (attacker '216.117.175.247', file '/usr/home/main/public_html/forum/archive/index.php') 
    Dec  3 15:26:59 defiant suhosin[76955]: ALERT - configured request variable name length limit exceeded - dropped variable 'ouml;ffnen//modules/xoopsgallery/upgrade_album_php?GALLERY_BASEDIR' (attacker '208.109.248.68', file '/usr/home/main/public_html/forum/archive/index.php') 
    Dec  3 15:35:02 defiant suhosin[76959]: ALERT - configured request variable name length limit exceeded - dropped variable 't-713_html//modules/xoopsgallery/upgrade_album_php?GALLERY_BASEDIR' (attacker '202.64.130.106', file '/usr/home/main/public_html/forum/archive/index.php') 
    Dec  3 15:37:08 defiant suhosin[76953]: ALERT - configured request variable name length limit exceeded - dropped variable 't-713_html//modules/xoopsgallery/upgrade_album_php?GALLERY_BASEDIR' (attacker '202.64.130.106', file '/usr/home/main/public_html/forum/archive/index.php')
    
    
    Dec  1 00:38:58 defiant suhosin[11723]: ALERT - tried to register forbidden variable '_REQUEST' through GET variables (attacker '218.239.45.154', file '/usr/home/spammers/public_html/forums/index.php') 
    Dec  1 00:38:58 defiant suhosin[11723]: ALERT - tried to register forbidden variable '_REQUEST[option]' through GET variables (attacker '218.239.45.154', file '/usr/home/spammers/public_html/forums/index.php') 
    Dec  1 00:38:58 defiant suhosin[11723]: ALERT - tried to register forbidden variable '_REQUEST[Itemid]' through GET variables (attacker '218.239.45.154', file '/usr/home/spammers/public_html/forums/index.php') 
    Dec  1 00:38:58 defiant suhosin[11723]: ALERT - tried to register forbidden variable 'GLOBALS' through GET variables (attacker '218.239.45.154', file '/usr/home/spammers/public_html/forums/index.php')
    The other thing you can do is turn off remote includes. By default this is valid PHP code:

    Code:
    include(http://example.net/remoteurl.php);
    There is a php.ini setting that you can use to turn that off.

    Turn off globals. Anything that is set in a $_GET or $_POST should not instantly become a global (and turning this off will also give you a whole list of PHP scripts that are insecurely programmed).

    Other things to consider:

    Attackers for some reason assume that all of the hosts they are attacking are going to have the following things installed and ready for use:

    1. Perl (which you already got)
    2. wget (This is never installed on any of my FreeBSD machines, about 90% of all attacks I have seen would have not worked if wget had not been installed)
    3. GCC to compile code (they use wget to drop this code on the machine ...)
    4. the Apache web server and its user (mine is www) having a valid PATH and other environment variables.
    (Dropping /bin, /sbin, /usr/bin, and /usr/sbin from PATH means only /usr/local/bin is left for Apache to execute from. Which is all it requires anyway (ImageMagick). So scripts that assume PATH is valid now don't work!)

    I hope this helps, I have not had a server compromised within the last 2 years. The one before that was because of a known php script vulnerability. At the time however they were only able to drop files on the server, but were unable to use them. I still have their code :p
     
  3. X-Istence

    X-Istence * Political User

    Messages:
    6,498
    Location:
    USA
    Do you still have the perl script? Would you mind sending it to me? I collect such items!
     
  4. Dark Atheist

    Dark Atheist Moderator Political User Folding Team

    Messages:
    6,376
    Location:
    In The Void
    for the purpose of good or evil ;)
     
  5. Geffy

    Geffy Moderator Folding Team

    Messages:
    7,805
    Location:
    United Kingdom
    archiving :p
     
  6. LordOfLA

    LordOfLA Godlike!

    Messages:
    7,027
    Location:
    Maidenhead, Berkshire, UK
    The software in question is rather heavily customised OSCommerce. The problem is only happening on older servers (apache 1.3, php4), with older or very heavily tweaked sites for customers that would be cost prohibitive to fix.

    The requirements for these servers is that register globals be on. We are looking at writing code that will intercept and sanitise the globals before the rest of the code gets hold of them. I'm also chmodding wget, perl, etc to 700 with root:root ownership (apache/mod_php as nobody then can't execute them). I will also be killing off the process execution functions and turning on PHP open_base_dir protection.

    URL fopen needs to be on as well unless you know of a better way to include remote files or to validate licensing.

    We will be moving the servers to FreeBSD based machines next year providing Geffy's sales guys don't forget the offer they accepted :)

    Unfortunately I don't have the perl script around anymore. If it lands on a server again I'll send it you way if I remember :)
     
  7. X-Istence

    X-Istence * Political User

    Messages:
    6,498
    Location:
    USA
    I always archive all of the exploits to look at how far people are coming, how much more intriguing the scripts are getting. Also most of the time I can figure out exactly what script has code stolen from what other authors that came before it. So if you see it dropped on your box again, shoot me an email.

    There are some PHP scripts available that will sanitise the variables and place them in the GLOBALS, but not all of them do the greatest of jobs.

    PHP's open_base_dir protection is a joke. All it will do is causes major headaches, I personally am currently doing work for 3 different web-hosting companies and none of them have it turned on because of the issues. Your best bet is to get phpSuHoSin installed and up and running. It will do much of the work for you that you are planning to do by hand.

    URL fopen, well since it is required, how about blocking outgoing for the user nobody? Don't allow it to connect to any remote sites that are not listed as explicitly allowed. What scripts require remote connections to validate licensing? Could you possibly contact those companies that require it and ask for alternate means of validating the licenses for security reasons?

    OH is a great place to host. My client is extremely happy with them, and the speeds the have been getting from their server located there.
     
  8. LordOfLA

    LordOfLA Godlike!

    Messages:
    7,027
    Location:
    Maidenhead, Berkshire, UK
    The code is largely ours that we have altered from base oscommerce. The license code includes a file hosted on our corporate server so we don't have to have its database connection details on every customers account.

    open_base_dir blocks access to folders outside the users home folder. If you know of a better way to do this let me know.
     
  9. X-Istence

    X-Istence * Political User

    Messages:
    6,498
    Location:
    USA
    Ehm, if you are doing remote includes from a corporate server, adding in firewall rules for that should be pretty simple. Also, if you are doing remote include, the customer is still able to get it either way. Just change it to local only for security reasons.
     
  10. X-Istence

    X-Istence * Political User

    Messages:
    6,498
    Location:
    USA
    As for your open_base_dir stuff, we run an fastCGI PHP process as the user, thereby not allowing them access to other peoples home folders to include random files.
     
  11. LordOfLA

    LordOfLA Godlike!

    Messages:
    7,027
    Location:
    Maidenhead, Berkshire, UK
    FastCGI/CGI breaks output buffering :(
     
  12. Geffy

    Geffy Moderator Folding Team

    Messages:
    7,805
    Location:
    United Kingdom
    Thanks for reminding me ;)

    is that output buffering for the purpose of response compression? could apache not be configured to handle that?
     
  13. LordOfLA

    LordOfLA Godlike!

    Messages:
    7,027
    Location:
    Maidenhead, Berkshire, UK
    Nope its for incremental progress updates on our installer script.
     
  14. X-Istence

    X-Istence * Political User

    Messages:
    6,498
    Location:
    USA
    Stop running unsupported and outdated versions of software. That alone should help with being less viable of a target for exploits. This output buffering bug was fixed in PHP 5.0 and 5.1:

    http://bugs.php.net/bug.php?id=34429

    Funny how other FastCGI implementations were not affected, just Apache's.
     
  15. LordOfLA

    LordOfLA Godlike!

    Messages:
    7,027
    Location:
    Maidenhead, Berkshire, UK
    Would love to stop, but this software is making thousands per month. Unfortunately it would cost our customer more than they can afford for us to update their site(s) to the newer PHP5 based application.

    We're going to need to keep an apache 1.3/php4 server around for this reason alone, so I need to lock it down as tight as I can while still allowing the software to work.

    The output buffering issue was occuring on a brand new apache 2.2/PHP 5.2.6 machine however.