Brute forcing HTTP authentication

Many home routers, IP webcams, and even web applications still rely on HTTP authentication these days, and penetration testers need to try a word list of weak passwords to make sure the system or user accounts are safe. Now, thanks to the NSE script http-brute, we can perform robust dictionary attacks against HTTPAuth protected resources.

This recipe shows how to perform brute force password auditing against web servers that are using HTTP authentication.

How to do it...

Use the following Nmap command to perform brute force password auditing against a resource protected by HTTP's basic authentication:

$ nmap -p80 --script http-brute –script-args http-brute.path=/admin/ <target>

The results contain all of the valid accounts that were found:

PORT     STATE SERVICE REASON
80/tcp   open  http    syn-ack
| http-brute:  
|   Accounts
|     admin:secret => Valid credentials
|   Statistics
|_    Perfomed 603 guesses in 7 seconds, average tps: 86

How it works...

The argument -p80 --script http-brute tells Nmap to launch the http-brute script against the web server running on port 80. This script was originally committed by Patrik Karlsson, and it was created to launch dictionary attacks against URIs protected by HTTP's basic authentication.

The script http-brute uses, by default, the files usernames.lst and passwords.lst located at /nselib/data/ to try each password, for every user, to hopefully find a valid account.

There's more...

The script http-brute depends on the NSE libraries unpwdb and brute. These libraries have several script arguments that can be used to tune the auditing for your brute force password.

To use different username and password lists, set the arguments userdb and passdb:

$ nmap -p80 --script http-brute --script-args userdb=/var/usernames.txt,passdb=/var/passwords.txt <target>

To quit after finding one valid account, use the argument brute.firstOnly:

$ nmap -p80 --script http-brute --script-args brute.firstOnly <target>

By default, http-brute uses Nmap's timing template to set the following timeout limits:

  • -T3,T2,T1: 10 minutes
  • -T4: 5 minutes
  • -T5: 3 minutes

For setting a different timeout limit, use the argument unpwd.timelimit. To run it indefinetly, set it to 0:

$ nmap -p80 --script http-brute --script-args unpwdb.timelimit=0 <target>
$ nmap -p80 --script http-brute --script-args unpwdb.timelimit=60m <target>

HTTP User Agent

There are some packet filtering products that block requests made using Nmap's default HTTP User Agent. You can use a different User Agent value by setting the argument http.useragent:

$ nmap -p80 --script http-brute --script-args http.useragent="Mozilla 42" <target>

HTTP pipelining

Some web servers allow the encapsulation of more than one HTTP request in a single packet. This may speed up the execution of an NSE HTTP script, and it is recommended that it is used if the web server supports it. The HTTP library, by default, tries to pipeline 40 requests and auto adjusts that number according to the traffic conditions, based on the Keep-Alive header.

$ nmap -p80 --script http-methods --script-args http.pipeline=25 <target>

Additionally, you can use the argument http.max-pipeline to set the maximum number of HTTP requests to be added to the pipeline. If the script parameter http.pipeline is set, this argument will be ignored:

$.nmap -p80 --script http-methods --script-args http.max-pipeline=10 <target>

Brute modes

The brute library supports different modes that alter the combinations used in the attack. The available modes are:

  • user: In this mode, for each user listed in userdb, every password in passdb will be tried.
    $ nmap --script http-brute --script-args brute.mode=user <target>
    
  • pass: In this mode, for each password listed in passdb, every user in usedb will be tried.
    $ nmap --script http-brute --script-args brute.mode=pass <target>
    
  • creds: This mode requires the additional argument brute.credfile.
    $ nmap --script http-brute --script-args brute.mode=creds,brute.credfile=./creds.txt <target>
    

See also

  • The Detecting possible XST vulnerabilities recipe
  • The Discovering interesting files and directories on various web servers recipe
  • The Detecting web application firewalls recipe
  • The Abusing mod_userdir to enumerate user accounts recipe
  • The Testing default credentials in web applications recipe
  • The Brute-force password auditing WordPress installations recipe
  • The Brute-force password auditing Joomla! installations recipe
  • The Detecting web servers vulnerable to slowloris denial of service attacks recipe
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.143.255.36