PHP Exploit query

LordOfLA

Godlike!
Joined
2 Feb 2004
Messages
7,026
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?
 

Attachments

  • decrypted_hack.txt
    1.9 KB · Views: 244
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
 
Do you still have the perl script? Would you mind sending it to me? I collect such items!
 
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 :)
 
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.
 
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.
 
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.

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.
 
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.
 
Thanks for reminding me ;)

is that output buffering for the purpose of response compression? could apache not be configured to handle that?
 
Nope its for incremental progress updates on our installer script.
 
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.
 

Members online

No members online now.

Latest profile posts

Also Hi EP and people. I found this place again while looking through a oooollllllldddd backup. I have filled over 10TB and was looking at my collection of antiques. Any bids on the 500Mhz Win 95 fix?
Any of the SP crew still out there?
Xie wrote on Electronic Punk's profile.
Impressed you have kept this alive this long EP! So many sites have come and gone. :(

Just did some crude math and I apparently joined almost 18yrs ago, how is that possible???
hello peeps... is been some time since i last came here.
Electronic Punk wrote on Sazar's profile.
Rest in peace my friend, been trying to find you and finally did in the worst way imaginable.

Forum statistics

Threads
62,015
Messages
673,494
Members
5,621
Latest member
naeemsafi
Back