Attack via php session id
In the past month or so, I noticed a new attack on our servers. Many accounts of ours generate this error multiple times:
Apparently, this method of attack uses the PHPSESSID cookie value in the HTTP GET/POST headers, with a crazy value of invalid characters. So far, I can't see if they are trying to exploit an old bug, or if they found some new 0-day vulnerability with session handling. At the very least, if the server reports PHP errors to the client, then they have managed to get the following information: - PHP file name - full path to the file - full user home directory - unix user account name What do you guys think? information leak or remove exploit vulnerability?
PHP Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /home/user/public_html/somefile.php on line XXXX
Apparently, this method of attack uses the PHPSESSID cookie value in the HTTP GET/POST headers, with a crazy value of invalid characters. So far, I can't see if they are trying to exploit an old bug, or if they found some new 0-day vulnerability with session handling. At the very least, if the server reports PHP errors to the client, then they have managed to get the following information: - PHP file name - full path to the file - full user home directory - unix user account name What do you guys think? information leak or remove exploit vulnerability?
-
Hello :) Is Mod_Security installed with any particular ruleset on this system? Thank you. 0 -
Yes, it is installed and enabled. I'm using the default configuration file with a few extra updates of my own. 0 -
I recall some old bugs where you could eval code inside of referrers, session ids, etc. I can't remember the exact bugs but IIRC it was for joomla plugins that do some logs/stats; when the referers etc got logged they'd become executable code. If you want the full payload you could use a custom modsec rule to see exactly what data they're sending. If you need help with that, let me know. Also a good time to disable display_errors for PHP so that the data you mentioned (account name, script path, etc) isn't displayed to visitors/attackers. 0 -
I would be interested to know the full payload. Can you please help me? I've never used the most advanced features of modsec, just simple rules to match keywords really. 0 -
Sure. Say the request is coming to somefile.php, you can capture any requests (including post payloads) to somefile.php with a custom rule like this: SecRule REQUEST_URI "somefile.php" "pass,log,id:2857467" When any requests are made for that file name, all the parts should be in your modsec audit log. You may want to disable cPanel's modsecparse.pl cron while inspecting this, as it empties your audit log hourly. Just temporarily move /etc/cron.hourly/modsecparse.pl out of the way to /backup/ or somewhere. Your data will be in /usr/local/apache/logs/modsec_audit.log and this can help you understand the parts of the request as they are logged (cookies, post data, headers, etc): 0 -
Great work, thanks for the explanation! 0
Please sign in to leave a comment.
Comments
6 comments