Cenzic 232 Patent
Paid Advertising
web application security lab

HTTP Verb Brute Forcing

I read a few interesting posts here and here regarding brute forcing HTTP verbs. The F5 post suggested that it is possible to thwart people who are looking for what options you support by giving a fake response. That’s certainly one way to do it, but it’s not as robust as it might appear.

By actually testing each verb by hand, it’s pretty easy to skip using options, if that’s not available to you. Or, if you are on the defensive side, if you are turning off one verb, turn off everything that you don’t use, so you don’t have to worry about it. Iterating verbs can be super useful for finding open/unprotected Webdav servers, finding open directories that allow PUT, or open proxies. In general automated worms just try to perform the exploit rather than iterate options anyway, so in general it’s probably a good idea to shut down all HTTP verbs and open them up as you need them, rather than close them down one at a time as you figure out why they could be used for nefarious purposes.

8 Responses to “HTTP Verb Brute Forcing”

  1. Marcin Says:

    Hey Rsnake, I was going to just add in the ability to perform a PUT $random_file and then do a DELETE $random_file… and perhaps do a directory listing while I was at it. Only thing I gotta sort out is the performance of doing one request at a time.

    Even if it’s a simple script, it has proven very useful for me in the past.

  2. DoctorDan Says:

    Out of curiosity, how does this affect Rails servers, where many verbs are necessary?

  3. Jabra Says:

    Backtrack includes a script from HD Moore that can do a put request:

    http://www.metasploit.com/users/hdm/tools/put.pl

    I could writeup a http verb brute forcer in Perl, if your interested.

  4. patrick Says:

    handy little tool that automate the process:

    http://www.computec.ch/projekte/httprecon/

    can also be scripted in about 5min in perl/python/ruby

  5. Ory Says:

    Hi,

    Like DoctrorDan, I think that discussing the trivial scenario is futile. I mean, it’s common (security) sense to shut down functionality that you don’t need and enable the ones you do. The tough problem to solve is how do you secure your environment, when you actually need those verbs.

    A great example would be securing REST web services, which implement CRUD using PUT and DELETE….

    just some food for thought.

  6. blah Says:

    “open/unprotected Webdav servers, finding open directories that allow PUT,”

    Uh huh. What’s that, like one in a million boxes?

  7. Robert Says:

    This functionality has been in scanners for 5+ years now. Qualys/appscan/webinspect/ has it and I’m pretty sure nesus does as well.

  8. Aditya K Sood Says:

    Specifically the verb based brute forcing is required to check access control and parameters for number of web pages. The response returned plays a critical role in determining whether specific HTTP verb is allowed to access. The point is to look at the additional methods allowed and the way they can be brute forced to check the access on all the linked and other pages in website.

    Even HTTP Verb Jacking we do to check whether the required request is 200 OK or not. If a manipulative verb performs the trick then the request will be executed in the context of that application page.

    So its easy to design verb check tool. Another Firefox plug in by security compass i.e. Access Me check for the access enabled on web pages by sending different HTTP verb request.

    But it is really good to play with HTTP Verbs.:)