We got a POST request to our server with the following in it:

%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%F%69%6E%70%75%74+%2D%6E

Using url decode this translates to:

cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env file=php://input -n

It seems to be similar to Strange URL requests via Nginx on Ubuntu 14.04, what is the malicious user trying to do?. In what scenario would the request work? I see from the logs we sent a 404 but I want to make sure we don't have any other box that may be vulnerable to it.

  • I've always found that servers are least vulnerable to attack when turned off, removed from all networked systems, or otherwise isolated from the world. – MSC Aug 9 at 23:04
  • The question there offer some advise; serverfault.com/questions/453732/… – yagmoth555 Aug 10 at 12:21

Many years ago people used to run PHP as a CGI script (not even FastCGI, it didn't exist yet!) in part so that they could switch Apache from its low-performance prefork MPM to the new and somewhat higher performing worker MPM. (And nginx was unknown yet, it was that long ago.) If a server was set up to run PHP as a CGI script, then you could call the PHP interpreter directly at /cgi-bin/php.

PHP technically still could be installed as CGI, but it turned out not to be as performant as people were hoping, thus FastCGI was invented. All current high performance PHP sites use FastCGI/FPM, generally with nginx or sometimes with Apache's event MPM. FastCGI/FPM are not vulnerable to this as they do not permit PHP to be called directly through /cgi-bin.

If your server isn't an ancient rotting pile of PHP run as CGI, then you need not worry about this request.

  • For some reason when you wrote 'Many years ago people ...' I had the thought of the old exploit in Apache 2.x. It's at the tip of my fingers but it was often used to cat /etc/passwd though of course it wouldn't work on all servers just like everything else. This was in the 1990s though maybe it went to the early 2000s? I don't remember. Right. I know why I thought of it - phf instead of php... – Pryftan Aug 9 at 21:15
  • @Pryftan There have been so many exploits over the years...but phf does sound vaguely familiar. I'm pretty sure that was long gone by the time this millennium rolled around though. – Michael Hampton Aug 9 at 21:17
  • All I know for certain is it was around in the mid 1990s. Even so assuming that a new tree of Apache was released it tends to take a long time for all the servers out there to update (then again it does for standard computers - a good example being Windows XP although I suppose it's not as bad as it was). – Pryftan Aug 9 at 21:33

The general problem is command injection. Made easier by old insecure CGI configurations allowing php execution direction, although a modern web server that sent a 404 isn't vulnerable to this specifically.

You prevent it by removing CGI where it is not needed, locking down the web server with file permissions and maybe SELinux, and securing your web apps. Open Web Application Security Project Testing Project has some general advice.

Mallicious attackers, or pentesters who want to get a part of your bug bounty will test your website for common errors made when writing web applications.

There are a few ways to harden your webapps against a successfull attack:

  • train your web developers in using good security practices, as always OWASP is a good starting point: https://www.owasp.org/index.php/OWASP_Guide_Project
  • put your applications behind a Web Application Firewall. (WAF) a WAF will scan all incomming requests and simply drop the ones that look like they're up to no good. An easy to use cloud solution is https://www.cloudflare.com/lp/waf-a/ but there are lots of others out there, be it cloud, appliances you can install at your datacenter of software you can run on your servers (think palo alto, fortigate, checkpoint, watchguard)
  • Let a pen tester investigate your infrastructure (regularly), if you give them documentation and information about your systems they will be able to perform these tests less blind than a random attacker on the internet, chances are they will find the issues faster then a random attacker and you can fix them. If you want to do this yourself, again, OWASP is a great resource: https://www.owasp.org/index.php/OWASP_Testing_Project

Neither of these options have a 100% guarantee, and I would recommend doing all of them.

Remediation

Sanitization

The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters or command list should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.

Genereal blacklist to be included for commannd injection can be | ; & $ > < ' \ ! >> #

Escape or filter special characters for windows, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + ,

Escape or filter special characters for Linux, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + ,

Permissions

The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view.

https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-013)

Also install modsecurity in Nginx with the comodo rules.

https://waf.comodo.com/

  • 4
    Blanket blacklisting is never the correct answer to a security question. All the characters you mention could legitimately occur in an URL, never mind form data! How would you feel about not being able to use + or / or ' or () in SE posts? – marcelm Aug 9 at 14:52
  • Several of us have linked to OWASP, but I don't think narrowly focusing on sanitation is the right priority. Remove PHP if not in use, if in use use a modern web server. Prevent web server from executing arbitrary programs. Add a WAF to filter malicious stuff. Don't execute OS commands in web apps at all if possible. And so on. – John Mahowald Aug 10 at 11:49

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.