Re: Built-in authentication for http.lua

[Patrik Karlsson <patrik () cqure net>]

Hi David,

I implemented a quick brute script to test the new authentication feature and found two problems.
One is related to caching and the other to calling the http lua with multiple worker threads.

As my brute framework uses multiple worker threads to perform brute-forcing I noticed the following
error popping up at times:

./nselib/http.lua:874: do not have a lock on this mutex
stack traceback:
        [C]: in function 'mutex'
        ./nselib/http.lua:874: in function 'insert_cache'
        ./nselib/http.lua:1040: in function 'get'
        ./scripts/http-brute.nse:62: in function 'login'
        ./nselib/brute.lua:405: in function 'doAuthenticate'
        ./nselib/brute.lua:442: in function 'main'
        ./nse_main.lua:584: in function <./nse_main.lua:584>

The error may be in how I'm calling the http lib from my code, I don't know. 
Anyway, when running with a single thread it works great. In order to test this change the line         
engine:setMaxThreads(1) in http-brute to 10.

The cache problem occurs when a page is protected by authentication.
As the cached result is not tied to the authenticated user any subsequent calls, regardless if they were authenticated 
or not will return the result.
I don't know if this is a big problem for anything else, but when testing authentication it sure is, as all login 
attempts after the first successful will appear as correct.
I worked around this in my script by issuing the no_cache option when calling the http.get method.

I'm attaching an updated version of the brute.lua library and my http-brute.nse script.

Regards,
Patrik

Attachment: brute.lua
Description:

Attachment: http-brute.nse
Description:

On 26 jul 2010, at 01.28, David Fifield wrote:

> On Wed, Jul 21, 2010 at 11:11:31PM -0600, David Fifield wrote:
> > The http library doesn't have support for HTTP authentication. The one
> > script that needs it, http-auth, implements it itself, parsing the
> > WWW-Authenticate header and creating a credentials string with the
> > base64 library.
> >
> > Here is a patch to make this automatic through the http library. You use
> > it like this:
> >
> >      http.get(host, port, path, { auth = { username = "username", password = "password" } })
> >
> > In other words, it just adds a new key to the "options" table.
> >
> > Although it's not necessary for Basic authentication, I added code to
> > parse the WWW-Authenticate header, the logic of which is copied from
> > Ncat. This replaces the pcre-using code in http-auth, and will also be
> > necessary to support Digest authentication.
> >
> > Speaking of Digest, the current implementation wouldn't work well for
> > that. With Basic you can fire and forget--just send username:password in
> > the clear with every request. With Digest, you have to make an initial
> > unauthenticated request to get the nonce, then retry the request. A
> > server can offer both Basic and Digest, and if you blindly send Basic
> > credentials in your first request, you've just disclosed your password
> > unnecessarily.
> >
> > I struggled for a while trying to make the http library try the request
> > unauthenticated first, then retry if authentication is required. I found
> > it hard to fit in with the http functions we have already. So I decided
> > on this implementation, the interface of which can remain the same even
> > if we move to a retrying model.
>
> I committed this today in r19231.
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/