Intro
There has been a lot of excitement around the new htaccess authentication bypass tool called HTExploit (HiperText Access Exploit [1]) that was recently presented at the Arsenal station at Blackhat USA 2012. This tool abuses a very old attack made possible due to a common htaccess configuration issue. Being an industry that loves to name old things anew, we now call this attack HTTP Verb Tampering.
HTTP Verb Tampering
HTTP Verb Tampering is an idea that was talked about in attack scenarios as far back as 2004. The attacks stems from restricting resources based on a white or blacklist of http methods. The methods outside of those defined in this restricted list may have unintended consequences like allowing an attacker to bypass the authentication requirement. Let’s take a look at a sample htaccess file that uses the problematic LIMIT directive:
AuthName “restrict posting”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
< Limit POST >
require group staff
< /Limit >
*http://www.apacheweek.com/features/userauth
The intended idea of the author was to only allow those in the staff group to post content to the restricted resource(s). Unfortunately for the developer, this is exactly how it works. This only limits the POST http method to require staff group authentication, any other http methods such as GET and PUT will bypass this authentication requirement.
HEAD Bypass
So the developer decided to deny methods like PUT, DELETE, and OPTIONS at the webserver and then only allow GET and POST methods from authenticated users. They modified their htaccess file to look like:
AuthName “restrict access”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
< Limit GET POST >
require group staff
< /Limit >
In 2008 another paper was released that named the attack and pointed out that the RFC for http/1.1 [2] says to treat head requests like get requests in the data returned.
“The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request.”
This allows us to send a HEAD request to bypass this limit restriction and retrieve the content without authenticating.
Custom Method
Finally, let’s say the developer went through the HTTP RFC’s and limited all known methods, even those denied at the webserver. One may think this would protect the resource(s) from all known methods. Take a look at the new example:
AuthName “restrict all methods”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
< Limit > POST GET PUT DELETE SPACEJUMP DEBUG OPTIONS TRACE CONNECT PROPFIND LOCK UNLOCK PROPPATCH MKCOL COPY MOVE>
require group staff
< /Limit >
In reality, anything that is called by Apache is displayed back as if it were retrieved by GET. This was created to take advantage of modules that may use custom methods such as WebDav. In this case we can create our own HTTP Method and use that to retrieve content, bypassing any limit restriction. The HTExploit tool uses ‘POTATO’ while the paper from 2004 uses ”BILBOA’.
Protection
The first style of protection is to use the directive instead of . LimitExcept causes a limit to be placed on any method except the ones specified. This allows you to require authentication for POST and GET and deny every other http method from accessing the resource. This would look like:
AuthName “restrict all methods except”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
< LimitExcept GET POST >
require group staff
< /LimitExcept >
The second style of protection is to completely remove any form of http method limit and only require authenticated users to access the resource(s). This would simply remove any limit directives:
AuthName “restrict all methods except”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
require group staff
Blog Contribution By Tyler Borland, Security Researcher
References
[1] http://www.mkit.com.ar/labs/htexploit/ – HTExploit Tool
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html – RFC HTTP/1.1 HTTP Methods
