File injection problem

[arctic_ged]

Hi,

I recently found that files were appearing inside one of domains im hosting. These files looked like some sort of shell hacks, they were somehow injected into my images folder which has file permissions set to 777. After my discovery this I uploaded an htaccess file to stop execution of any scripts.. this didn't really help as who ever was attacking was smart enough to overwrite the htaccess file. So as this continued i changed ownership of the htaccess file to root and this time they couldn't overwrite it.

This hasn't stopped the PHP script files appearing inside the folder, however it stopped the attacker from executing them. After I examined these scripts i noticed that a lot of them delete themselves after execution using PHP unlink() function. This makes me think that there was a lot more attacks that i didn't know about.

What id like to do is find a way of logging of file functions (create, move_uploaded, unlink, etc..) that are executed via apache or php - is there a way to do this? Just in case this is happening on other domains.

I have centOS 5 running Plesk 10.

[mikeshinn]

I recently found that files were appearing inside one of domains im hosting. These files looked like some sort of shell hacks, they were somehow injected into my images folder which has file permissions set to 777. After my discovery this I uploaded an htaccess file to stop execution of any scripts.. this didn't really help as who ever was attacking was smart enough to overwrite the htaccess file. So as this continued i changed ownership of the htaccess file to root and this time they couldn't overwrite it.

With file permissions of 777 the attacker could be another user on the system who is just copying the files into that directory. Equally, it could be a poorly protected account, stolen password (and FTP or SSH upload) or a poorly protected application that is allowing them to be uploaded (I once investigated an incident where the customer had a script that let *anyone* upload *anything* to the servers image directory, and the script was unimaginatively called upload.php, which the badguys found without even trying).

You may want to look at this article to help you identify the source of the uploads, we find that file uploads are usually the key source:

https://www.atomicorp.com/wiki/index.ph ... ystem:_FTP

You should also check your Apache logs to look for any events that might show unusual uploads, and if you arent using our mod_security rules then you should install those as well.

This hasn't stopped the PHP script files appearing inside the folder, however it stopped the attacker from executing them. After I examined these scripts i noticed that a lot of them delete themselves after execution using PHP unlink() function. This makes me think that there was a lot more attacks that i didn't know about.

Do you happen to have any of the files?

What id like to do is find a way of logging of file functions (create, move_uploaded, unlink, etc..) that are executed via apache or php - is there a way to do this? Just in case this is happening on other domains.

Off the top of my head, you may be able to do this with suhosin.

[arctic_ged]

I'm almost 100% certain that the attacks were through some sort of software vulnerability, as all files uploaded appear with the user apache as the owner and anything uploaded via FTP has the domain's username as the owner. So it must be uploaded via some script.

I have about 30 of these files I can email or upload them if you'd like to have a look.

As I downloaded one of them of the server onto my local machine the antivirus detected it as this:

Code: Select all

Detected item: backdoor:php/C99shell.F 
Alert level: Severe
Category: Backdoor
Description: This program provides remote access to the computer it is installed on.
Recommended action: Remove this software immediately.

I will look into suhosin in the mean time..

[JnascECSI]

Arctic,
I have seen this issue with some shopping carts on our server, by chance is this happening with OsCommerce, Cre-loaded or Zen Cart?

[arctic_ged]

This domain has osCommerce shopping cart, however I have been informed by the developer that all vulnerable parts such as file_manager.php have been taken out.

[JnascECSI]

Arctic,
Below is a prime example of someone trying to exploit the file_manager.php bug and it's getting blocked by mod_sec and not sure why mod_sec on your box is'nt catching it. I do know that even thou the OSCommerce file_manager.php bug is fixed on some of the builds there are mods that actually have roled back the fix which i found out with a module that used that file but the module replaced the file_manager.php with a version that was'nt fixed. That's the down fall of OSCommerce because you have to becareful with mod's reverting fixes that are in the core builds.

Code: Select all

OSSEC HIDS Notification.
2011 Mar 15 07:10:39

Received From: XXX-1->/var/log/httpd/audit_log
Rule: 60118 fired (level 7) -> "Access attempt blocked by Mod Security."
Portion of the log(s):

[modsecurity] [client 72.249.118.183] [domain www.XXXXXXXXXXX.com] [403] [/20110315/20110315-0710/20110315-071037-UO@By38AAAEAAAzzlFsAAAAG]  [file "/etc/httpd/modsecurity.d/99_asl_jitp.conf"] [line "4562"] [id "390756"] [rev "1"] [msg "Atomicorp.com WAF Rules - Just In Time Patch: Oscommerce Exploit"] [data "/admin/file_manager.php/login.php"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Pattern match "/admin/.*\.php/(?:login|application_top)\.php" at REQUEST_URI.



 --END OF NOTIFICATION

[mikeshinn]

This domain has osCommerce shopping cart, however I have been informed by the developer that all vulnerable parts such as file_manager.php have been taken out.

What version of ASL are you running?

Can you send us your access_log files?

[arctic_ged]

I do not have ASL or mod_security is this something that can intercept the attacks?

[Highland]

If they had files running on your server I'll bet they got your kernel (meaning root access). Had something similar happen a few months back. Hacker uploaded a PHP script through an insecure file and tried to gain root access but the ASL kernel caught it and stopped him cold. While they could have done other bad things, it looked like that was all they were after and they gave up after that failed. I'm willing to bet that's what they've done to your box.

ASL would have stopped some of the attack. Unfortunately it can only go so far if the underlying code has holes you can drive a truck through. I dropped Zen Cart (an oscommerce offshoot) after a similar attack attempt was thwarted by ASL on another box several years ago.

[mikeshinn]

I do not have ASL or mod_security is this something that can intercept the attacks?

In a word, yes. Thats what ASL is designed for.

[arctic_ged]

Right I've installed mod_security and i'm slowly getting through configuring the base rules as at the moment if I turn on the default settings it stops the websites from operating properly.

One thing that I have noticed in the logs (vat/log/secure) there are hundreds of these entries - is this normal, for a centOS 5 server running Plesk 10?

Code: Select all

....
Mar 22 08:18:47 www su: pam_unix(su-l:session): session closed for user popuser
Mar 22 08:18:47 www su: pam_unix(su-l:session): session opened for user popuser by (uid=0)
Mar 22 08:18:48 www su: pam_unix(su-l:session): session closed for user popuser
Mar 22 08:18:48 www su: pam_unix(su-l:session): session opened for user popuser by (uid=0)
Mar 22 08:18:49 www su: pam_unix(su-l:session): session closed for user popuser
Mar 22 08:18:49 www su: pam_unix(su-l:session): session opened for user popuser by (uid=0)
Mar 22 08:18:51 www su: pam_unix(su-l:session): session closed for user popuser
.....

[mikeshinn]

Right I've installed mod_security and i'm slowly getting through configuring the base rules as at the moment if I turn on the default settings it stops the websites from operating properly.

Which rules did you install? Our rules, or someone elses?

[mikeshinn]

Mar 22 08:18:47 www su: pam_unix(su-l:session): session closed for user popuser

Thats not normal on our Plesk 9 systems, can't say for sure with Plesk 10 we dont use those in production yet.

[arctic_ged]

I installed the latest mod security crs rules, however they stop normal websites from working properly, so its a bit of a nightmare.

If i was to purchase ASL yearly subscription would it be better configured for a regular day-to-day webserver? The standard CRS rules are a bit of a nightmare to get your head around.

[mikeshinn]

I installed the latest mod security crs rules, however they stop normal websites from working properly, so its a bit of a nightmare.

If i was to purchase ASL yearly subscription would it be better configured for a regular day-to-day webserver? The standard CRS rules are a bit of a nightmare to get your head around.

Absolutely. We've been writing modsecurity rules longer than anyone else, long before the CRS rules even existed. We pioneered modsecurity rules, so we don't use the CRS rules - we don't have to, we had this all covered years ago. Its a fact we've been doing this longer than anyone else, and because of all that experience and attention to detail, our rules work - period. You don't have to mess around with the rules and tear your hair our trying to get them to work. Our motto is "Security for everyone". We focus our energy on not just protecting you, but also on making sure we dont have false positives. So unlike other security projects that expect you to figure it, we have figured it out. So you get a solution that works.

And if by some chance one of our rules did stop something it shouldnt, we will fix that issue the same day, no questions asked. Its all part of the service. Think of us as your Tier 4 security help desk. Just ask us and we'll get it right for you.

So don't waste your time with other rules, no one has been writing modsecurity rules longer than us, not even the current people writing the CRS rules, not Breach, no one. Our rules not only protect you from attacks, but they also protect you from upset customers! No False Positives no grief!

Plus with ASL, you are also protected from lots of other attack methods that a WAF alone can't protect you from, such as upload attacks, kernel attacks, vulnerabilities in other software and so on. ASL is a full spectrum security suite, run it and sleep well at night. Let us worry about the bad guys. So don't waste your time with the CRS rules, use ASL and your system will be secure and reliable.