False positive or hack attempt?
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
9 Replies
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
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
(2nd hit)
> The TinyMCE compressor script allows the selection of things like
language, plugins, themes from within URL variables and does not
properly validate them. Because there is no check enforced on the
content of these variables it is possible to specify not only
illegal but also filenames outside of the dedicated directories.
It is only required to truncate the end of the filename with for
example an ASCII NUL. Which is for example not possible when the
server is running the latest version of the Hardening-Patch for PHP.
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.
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
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.
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
@obs:
Do the linode kernels come with apparmor? I know it went into the mainline kernel a few versions ago.
cthulhu:~# uname -r
2.6.38-linode31
cthulhu:~# anycat /proc/config.gz | grep ARMOR
# CONFIG_SECURITY_APPARMOR is not set
no.