If your organization's website runs on Apache, and many do, you might wonder if the webserver's .htaccess controls are securely configured. If you believe the demo we saw yesterday at Blackhat by Matias Katz and Maximiliano Soler, the answer is a resounding 'NO!' What Katz and Soler described in their session is not some rare "corner case" hack that could only possibly occur in a lab with billions of automated attempts, this is easily testable in the real world, and the tools to exploit it are freely available.
It turns out that Apache, the most common web server in the world, has an arrangement where it hands off PHP-based requests within .htaccess to PHP itself, which has been working fine on millions and millions of websites for years. But with .htaccess, you can specify WHAT requests get sent to PHP to try to interpret. The usual methods are GET and POST, but if you feed the .htaccess process some non-standard input, PHP automatically (unless otherwise instructed) treats it as a GET request, and allows the utility to start saving the PHP files on a webserver to your local filesystem.
Then it gets worse. Once the process has identified links buried in the files it just saved, it goes hunting down those links, requesting to save them all. It also checks to see if it already saved the file that the link points to, and in this way, won't download duplicates, keeping the fileset fresh.
But wait, there's more. After it saves all THOSE linked files, it scours them as well, searching for files located wherever THEY link to, and so the process goes. With so many pages linking to other resources, it's easy to see how a bad actor can pull down all the PHP files that run the site. These may well contain references to login credentials for databases, passwords, personally identifiable information, and a host of other goodies that be sold on the black market or used to enable further exploits.
Want to protect yourself? Turns out you can get very specific in your .htaccess file about why types of requests get handed to PHP by using the "LimitExcept" directive instead of the more commonly used "Limit". You can also fix the issue within your PHP code as well.
So, now might be a good time to check your website configuration to make sure you're protected, before the bad guys go scouring around trying to use this type of exploit. And if you're not the person in charge of your website, you might want to point out this problem to the person who is, they may thank you, a lot.
