{"id":1078,"date":"2010-12-10T18:37:37","date_gmt":"2010-12-10T22:37:37","guid":{"rendered":"http:\/\/cd34.com\/blog\/?p=1078"},"modified":"2010-12-10T18:37:37","modified_gmt":"2010-12-10T22:37:37","slug":"hackers-bypass-htaccess-security-by-using-gets-rather-than-get","status":"publish","type":"post","link":"https:\/\/cd34.com\/blog\/web-security\/hackers-bypass-htaccess-security-by-using-gets-rather-than-get\/","title":{"rendered":"Hackers bypass .htaccess security by using GETS rather than GET"},"content":{"rendered":"
Last night I received an urgent message from a client. My machine has been hacked, someone got into the admin area, I need all of the details from this IP.<\/p>\n
So, I grepped the logs, grabbed the appropriate entries and saw something odd.<\/p>\n
\r\nAuthUserFile .htpasswd\r\nAuthName \"Protected Area\"\r\nAuthType Basic\r\n\r\n<Limit GET POST>\r\nrequire valid-user\r\n<\/Limit>\r\n<\/pre>\n
Of course, we know GETS isn’t valid, but, why is Apache handing out status 200s and content lengths that appear to be valid? We know the area was password protected behind .htaccess and with some quick keyboard work we’ve got a system that properly prompts for Basic Authentication with a properly formed HTTP\/1.0 request. Removing the <Limit> restriction from the .htaccess protects the site, but, why are these other methods able to pass through? Replacing GETS with anything other than POST, PUT, DELETE, TRACK, TRACE, OPTIONS, HEAD results in Apache treating those requests as if GET had been typed.<\/p>\n
Let’s set up a duplicate environment on another machine to figure out what Apache is doing.<\/p>\n
\r\ntsavo:~ mcd$ telnet devel.mia 80\r\nTrying x.x.x.x...\r\nConnected to xxxxxxx.xxx.\r\nEscape character is '^]'.\r\nGET \/htpasstest\/ HTTP\/1.0 \r\n\r\nHTTP\/1.1 401 Authorization Required\r\nDate: Fri, 10 Dec 2010 21:29:58 GMT\r\nServer: Apache\r\nWWW-Authenticate: Basic realm=\"Protected Area\"\r\nVary: Accept-Encoding\r\nContent-Length: 401\r\nConnection: close\r\nContent-Type: text\/html; charset=iso-8859-1\r\n<\/pre>\n
Let’s try what they did:<\/p>\n
\r\ntsavo:~ mcd$ telnet devel.mia 80\r\nTrying x.x.x.x...\r\nConnected to xxxxxxx.xxx.\r\nEscape character is '^]'.\r\nGETS \/htpasstest\/ HTTP\/1.0\r\n\r\nHTTP\/1.1 501 Method Not Implemented\r\nDate: Fri, 10 Dec 2010 21:53:58 GMT\r\nServer: Apache\r\nAllow: GET,HEAD,POST,OPTIONS,TRACE\r\nVary: Accept-Encoding\r\nContent-Length: 227\r\nConnection: close\r\nContent-Type: text\/html; charset=iso-8859-1\r\n<\/pre>\n
Odd, this is the behavior we expected, but, not what we are experiencing on the client’s machine. Digging a little further we look at the differences and begin to suspect the machine may have been compromised. The first thing that struck was mod_negotiation – probably not. mod_actions, maybe, but, no. DAV wasn’t loaded, but, Zend Optimizer was on the machine that appeared to have been exploited. Testing the above script on the client’s machine resulted in…. exactly the same behavior — method not supported. Testing the directory that was exploited results in the GETS request served as if it was a GET request.<\/p>\n
So, now we’ve got a particular domain on the machine that is not behaving as the config files would suggest. A quick test on the original domain, and as expected, GETS responds with the data and bypasses the authorization clause in the .htaccess. Lets try one more test:<\/p>\n
\r\n\r\n# telnet xxxxxx.mia 80\r\nTrying x.x.x.x...\r\nConnected to xxxxxx.xxx.\r\nEscape character is '^]'.\r\nGETS \/zend.php HTTP\/1.1\r\nHost: xxxxxx.xxx\r\n\r\nHTTP\/1.1 200 OK\r\nDate: Fri, 10 Dec 2010 22:02:33 GMT\r\nServer: Apache\r\nVary: Accept-Encoding\r\nContent-Length: 602\r\nConnection: close\r\nContent-Type: text\/html\r\n<\/pre>\n
Bingo. A Zend encoded file handed us an error 200 even though it contained an invalid request method.<\/p>\n
The solution in this case was simple, remove the <Limit> clause from the .htaccess.<\/p>\n
The question is, is Zend Optimizer actually doing the proper thing here. Watching Apache with gdb, Zend Optimizer does appear to hook the Apache request handler a bit higher, but why is it attempting to correct an invalid request?<\/p>\n
One of the first rules in input validation is validate and reject on error. Never try to correct the data and accept it. If you try to correct it and make a mistake, you’re just as vulnerable and hackers will try to figure out those patterns and add extra escaping into their url request. In this case, only a few pages were able to be displayed as there were checks to make sure forms were POSTed. But, the Limit in .htaccess that should have protected the application, didn’t work as expected because the invalid methods weren’t specified.<\/p>\n
As so many applications on the web generate .htpasswd files with the Limit clause, it makes me wonder how many Zend Encoded applications are vulnerable. Take a minute to check your systems.<\/p>\n
Last night I received an urgent message from a client. My machine has been hacked, someone got into the admin area, I need all of the details from this IP. So, I grepped the logs, grabbed the appropriate entries and saw something odd. 1.2.3.4 – – [09\/Dec\/2010:22:15:41 -0500] “GETS \/admin\/index.php HTTP\/1.1” 200 3505 “-” “Mozilla\/5.0 […]<\/p>\n