Why does NMAP's Http-Method-Tampering Mark a Server's 405 Code as Vulnerable?

Question

I recently tested a custom server with the http method tamper script from NMAP. It reported the server as being vulnerable with the following output:

nmap -p 8000 -sV --script http-method-tamper 192.168.68.63

| http-method-tamper:
|   VULNERABLE:
|   Authentication bypass by HTTP verb tampering
|     State: VULNERABLE (Exploitable)
|       This web server contains password protected resources vulnerable to authentication bypass
|       vulnerabilities via HTTP verb tampering. This is often found in web servers that only limit access to the
|        common HTTP methods and in misconfigured .htaccess files.
|              
|     Extra information:
|      
|   URIs suspected to be vulnerable to HTTP verb tampering:
|     / [POST]
|  

The server only allows GET, HEAD, OPTIONS, PUT methods. It checks for these allowed HTTP verbs before doing any authentication/authorization check (i.e. 405 will show up before 401s or 403s). It's unclear to me why a 405 would be flagged as vulnerable as 405 doesn't seem like the wrong choice if someone issues a POST.

Answer 1

If the server indeed responds with a 405 code (and doesn't do anything else), then the finding is a false positive caused by limitations of the script.

When you inspect the script, you'll see that it first looks for all paths where a GET request leads to a 401 response. It then tries HEAD, POST and random methods. If a HEAD or POST request leads to anything other than a 401 response, this is considered a vulnerability.

In your case, the rule is too strict. It's perfectly fine to respond with a 405 code, and the test for random methods indeed allows the somewhat similar code 501 (Not Implemented). One possible explanation for the strict check is that the script authors may want to detect cases where unauthenticated requests are in fact accepted but then lead to a client-side or server error while the request is further processed. For example, imagine the server responds with a 400 code for an unauthenticated request. This can be fine if the request is immediately rejected. But it can also indicate an actual vulnerability where the server accepts the unauthenticated request and merely has an issue with, for example, a particular parameter.

Answer 2

The goal of that test is to detect the very common Apache httpd misconfiguration (as people copied and pasted blindly a bad example), where the config was something along the lines of:

<Limit GET POST>
    (... statements requiring authentication ...)
</Limit>

So only requests with GET or POST would require authentication, but other verbs (like PUT or PATCH or HEAD or OPTIONS) would not.

So the test detects that with some verbs you send back a 401, but with others (everything else being equal) you do not, and thinks this matches the above misconfiguration.

It may seem innocuous (a 405 instead of a 401 means it's blocked anyway), but the fact you return a 405 may imply that there is a resource there (as the choice of methods should depend on the resource), accessible via other methods. It can be argued it would be better to check for authentication first, and only then for the method, path, and other parts of the request.