In one of my previous 'Turn That S#!T Off' posts, I discussed an HTTP authentication bypass pertaining to the JBoss JMX console (CVE-2010-0738). This vulnerability hinges on a recommended/default policy that applies security constraints only to the specific HTTP methods GET and POST. This has the unintended consequence that other methods (such as HEAD) will be passed off to the GET handler even without authentication.
This vulnerability was disclosed two years ago, but I recently learned that a very similar flaw exists in a common Apache configuration.
While attending Black Hat, I had the opportunity to converse with Matias Katz, an Argentinian penetration tester and co-author of the HTExploit tool demonstrated in the Black Hat Arsenal. HTExploit demonstrates how it is possible to use an unexpected HTTP method to access PHP scripts that were intended to be password protected. The tool preys on poorly configured htaccess files like the one below, which explicitly states the specific HTTP methods to limit:
As in the case of the JBoss JMX console authentication bypass, an attacker can bypass the htaccess authentication requirement by using a method other than GET. Even if the htaccess file has been configured to restrict access for all HTTP methods specified in the RFC, it should be noted that an attacker can also use gibberish in place of a valid method and Apache will allow PHP to process the request as if it were authenticated. The quick fix for this is to remove the ‘Limit’ tag so that Apache will enforce restrictions on all requests.
Apache admins should beware – if you use a ‘limit’ section in your config, TURN THAT S#!T OFF!
I received some good feedback from a reader (thanks 'laserlight') which is important to note here. This post should not give the impression that limit tags implemented in the main Apache configuration are any better than in an .htaccess file. The problem exists in how the directive is processed regardless of which config file it is specified in.
