How to secure servers from a cgi-bin/php POST request attack

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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 or configuring web servers. These attacks count on the fact that there is a chance are that you, your vendor, web application developers or your IT team made a small error or have forgotten to keep your software or configurations up to date for newly discovered security issues, so they are just trying to exploit a lot of known issues against every server on the internet. If you do not keep your systems up to date and stay informed of latest security issues in the platform or software stack you are using, eventually your security (or that of your visitors) will be compromised.

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), or there are free options like https://modsecurity.org (at this moment it seems like the package managers for distro's need to pick up on the nginx plugin/module for this, but there is an apache module out there)
• 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
• next to a WAF you can install software that blocks users that make to many invalid requests. e.g. brute force (ssh, basic auth, ftp, mysql...) logins, generate to much internal server errors, or even to much page not founds. my favorite software for this is to install fail2ban (https://www.fail2ban.org/) which will scan your log files and block offending ip's for a few minutes using firewall rules.

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

For an exhaustive list of all security/hardening measures you can take on your centos7 system, you can follow this guide by RedHat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/index/index

Answer 4

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/