I have received the follow log message on my linode VPS.

Apr 13 15:16:37 vps suhosin[4699]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'controller' (attacker '75.126.235.115', file '/var/www/xxxxxxxxxxxxx.com

I get different opinions on this when i search google.

Does anyone believe that this something i need to be concerned about?

jk

I have also grabbed this stuff from my logs as well:

75.126.235.115 - - [13/Apr/2011:15:16:37 +0100] "GET /index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 8018 "-" "libwww-perl/6.01"
75.126.235.115 - - [13/Apr/2011:15:27:15 +0100] "GET /catalogue/report/index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 515 "-" "libwww-perl/6.01"
75.126.235.115 - - [13/Apr/2011:15:27:16 +0100] "GET /catalogue/report/index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 515 "-" "libwww-perl/6.01"
75.126.235.115 - - [13/Apr/2011:15:27:16 +0100] "GET /index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 8018 "-" "libwww-perl/6.01"
75.126.235.115 - - [13/Apr/2011:15:27:16 +0100] "GET /index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 8018 "-" "libwww-perl/6.01"
75.126.235.115 - - [13/Apr/2011:15:27:16 +0100] "GET /catalogue/index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 508 "-" "libwww-perl/6.01"
75.126.235.115 - - [13/Apr/2011:15:27:16 +0100] "GET /catalogue/index.php?option=com_product&controller=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 404 508 "-" "libwww-perl/6.01"

Does it looks like a php injection attack?

If so, how can i be sure this rat has not succeeded?

jk

Well, it's certainly someone fishing for information. You're always going to get crud like this on a public facing server though. As long as inappropriate requests are rejected that's pretty much the best you can do.

As to whether or not you're at risk, any of the 404 responses should be fine as they got rejected (unless your setup can do significant processing which can create side-effects even with a failure response).

The 200's however presumably hit your application code - or some default filesystem mapping - which in turn returned something as a successful response. It's impossible to tell what that was, or what code might have been involved to reach that point, from these logs. So you'll want to look at whatever more detailed logging you have from the application itself, or your knowledge of the application, to see how it satisfied those requests to judge if it may have created issues or exposed anything it ought not to. If, for example, your index.php just ignores query parameters and always returns your basic index page, then those successful responses are just fine.

If you don't have more detailed information, you could also manually fetch the same URLs yourself to see what you get back.

-- David

http://www.google.com/search?q=proc/self/environ%2500

http://www.google.com/search?q=suhosin% ... +ASCII-NUL
(2nd hit)

http://www.hardened-php.net/advisory_262005.111.html


My best guess is you're running some PHP based software on yours site that's had common, frequent and/or widely known vulnerabilities and script kiddies are poking at it.

Thanks for you replies.

The application is Prestashop 1.3.1.1, which is not the most recent version but as far as i can tell from the change log it has had the known security vulnerabilities patched.

I have also put the full url's into a browser and they just revert the the main index.php page.

Does this sound ok, or should i still be worried about the security of this webserver?

jk

It sounds fine, to be honest any scripts that allow arbitrary file paths to be opened shouldn't be used, I've not used prestashop in a while but I doubt they do allow arbitrary paths, they will have some form of sanitisation and just throw an "oops" invalid request page or 404 not found.

A way to protect against such attacks is to run something like apparmor, it can deny the php binary access to files in this case anything in /proc

However use it with care it can also break your apps.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Thanks for your reply obs.

The system does seem fine, but I wanted to get a few opinions on how concerned i should be about this stuff.

Unfortunately, i did my test setup on Centos with SELinux enabled, but when i got the Linode account i discovered that Linode's kernel does not have SELinux.

Centos 5.5 had also not received any updates for a few months due to the work going into Centos 5.6. I did not want to be without both SELinux and security updates - so i switched from Centos to Debian Squeeze and in a final twist Debian Squeeze seems to have dropped apparmor!

Therefore, neither Apparmor or SELinux seem to be an option. Maybe i should have went with Ubuntu to at least get Apparmor. However, the last time i tried the 10.04LTS version of Ubuntu server, grub2 seemed to get updated every other week, which rightly or wrongly gave me concerns about it's stability.

I think i will just have to keep the system updated and watch the logs. Thanks you all for your assistance - it has been much appreciated.

jk

Do the linode kernels come with apparmor? I know it went into the mainline kernel a few versions ago.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

cthulhu:~# uname -r
2.6.38-linode31
cthulhu:~# anycat /proc/config.gz | grep ARMOR
# CONFIG_SECURITY_APPARMOR is not set

no.

Darn it, well I run the ubuntu ec2 stock kernel and I've had no issues with it. So you could try that.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue