Re: pgsql-brute and PostgreSQL match lines

[Patrik Karlsson <patrik () cqure net>]

Hi David,

Thank's for testing! Please find my comments inline.

On 25 feb 2010, at 04.32, David Fifield wrote:

> On Sun, Feb 21, 2010 at 02:59:18AM +0100, Patrik Karlsson wrote:
> > On 17 feb 2010, at 18.51, David Fifield wrote:
> > > Is this intentional? (The use of username as both user name and
> > > database name.)
> >
> > Yes, have a look at the following link for an explanation,
> > specifically "A convenient choice is to create a database with the
> > same name as your current user name. Many tools assume that database
> > name as the default, so it can save you some typing.". Based on how
> > the code currently works, the database does not need to exist in order
> > to correctly identify a successful login.
> > http://www.postgresql.org/docs/8.0/interactive/tutorial-createdb.html
>
> Okay, thanks.
No problem.

> > > status, response = v.sendStartup(socket, username, username)
> > >
> > > I'm getting log messages like this:
> > >
> > > FATAL:  unsupported frontend protocol 65363.19778: server supports 1.0 to 3.0
> > > FATAL:  no pg_hba.conf entry for host "192.168.0.21", user "versionprobe", database "versionprobe", SSL off
> > > FATAL:  no pg_hba.conf entry for host "192.168.0.21", user "root", database "root", SSL off
> > > FATAL:  no pg_hba.conf entry for host "192.168.0.21", user "root", database "root", SSL off
> > > FATAL:  no pg_hba.conf entry for host "192.168.0.21", user "admin", database "admin", SSL off
> > > FATAL:  no pg_hba.conf entry for host "192.168.0.21", user "admin", database "admin", SSL off
> > >
> > > Even if the above code is a bug, I don't know why each user name would
> > > be used only twice. It seems like it would be used as many times as
> > > there are passwords.
> >
> > This is correct behavior, or at least almost.  The script first
> > attempt to connect using SSL then without as SSL can be explicitly
> > denied in pg_hba.conf.
> > However, if the response contains "no pg_hba.conf entry for host"
> > there is no entry in the file so authentication won't succeed.
> > The script now correctly identifies this and moves on to the next
> > username.
>
> Ah, I see now. Checking for this and bailing out early is a good idea
> too.
>
> DEBUG:  forked new backend, pid=33800 socket=6
> LOG:  connection received: host=192.168.0.21 port=46373
> LOG:  could not receive data from client: Connection reset by peer
> LOG:  incomplete startup packet
> DEBUG:  server process (PID 33800) exited with exit code 0
> DEBUG:  forked new backend, pid=33801 socket=6
> LOG:  connection received: host=192.168.0.21 port=46374
> LOG:  connection authorized: user=versionprobe database=versionprobe
> FATAL:  database "versionprobe" does not exist
> DEBUG:  server process (PID 33801) exited with exit code 1
> DEBUG:  forked new backend, pid=33802 socket=6
> LOG:  connection received: host=192.168.0.21 port=46375
> LOG:  connection authorized: user=root database=root
> FATAL:  database "root" does not exist
> DEBUG:  server process (PID 33802) exited with exit code 1
>
> > > Can you tell me what lines to add to a configuration file to make a
> > > dummy account for testing the script?
> >
> > To create the user "test", as OS-user postgresql or equivalent do:
> > creatuser -P test
>
> All right, thanks. I did that, added the scanning machine to
> pg_hba.conf, and now I'm getting a different error:
>
> NSE: Starting pgsql-brute against 192.168.0.190:5432.
> NSE: Trying root/ ...
> NSE: pgsql-brute against 192.168.0.190:5432 threw an error!
> ./nselib/pgsql.lua:424: bad argument #2 to 'unpack' (string expected, got nil)
> stack traceback:
>        [C]: in function 'unpack'
>        ./nselib/pgsql.lua:424: in function 'decodeHeader'
>        ./nselib/pgsql.lua:440: in function 'processResponse'
>        ./nselib/pgsql.lua:488: in function 'loginRequest'
>        ./scripts/pgsql-brute.nse:136: in function <./scripts/pgsql-brute.nse:64>
>        (tail call): ?
>
> The server is closing the connection after the versionprobe request, so
> v3.readPacket is returning nil at line 400. Am I doing something wrong?
> I attached a packet capture in case that helps. This is against version
> 8.4.2.

Ok, so I'm guessing you set up the authentication method as "trust"? This means that the server won't ask for the 
credentials to access the DB.
I wasn't handeling this properly, but I've fixed it now. If the trusted method is in use the script will report the 
user with no password as the admin user below:

PORT     STATE SERVICE
5432/tcp open  postgresql
| pgsql-brute:  
|   admin => Trusted authentication
|_  test:test => Login Correct

Depending on the server setup, specifically if database and user are set to "all", all users may come back as "trusted 
authentication". 

> > > The library uses the openssl library without doing a require call; I'm
> > > not sure if that will be a problem. Try running the script after
> > > configuring Nmap --without-openssl and make sure it fails gracefully.
> >
> > I've added a require line for openssl.
>
> Okay. Running "nmap --script-updatedb" after configuring with
> "--without-openssl" fails in mysql.lua and pgsql.lua with an error like
> this:
>
> NSE: error while updating Script Database:
> [string "local nse = ......"]:17: ./nselib/pgsql.lua:22: module 'openssl' not found:
>        no field package.preload['openssl']
>        no file './openssl.lua'
>        no file '/usr/local/share/lua/5.1/openssl.lua'
>        no file '/usr/local/share/lua/5.1/openssl/init.lua'
>        no file '/usr/local/lib/lua/5.1/openssl.lua'
>        no file '/usr/local/lib/lua/5.1/openssl/init.lua'
>        no file './nselib/openssl.lua'
>        no file './openssl.so'
>        no file '/usr/local/lib/lua/5.1/openssl.so'
>        no file '/usr/local/lib/lua/5.1/loadall.so'
> stack traceback:
>        [C]: in function 'assert'
>        [string "local nse = ......"]:17: in main chunk
>
> Can you see if you can protect the module from being loaded when OpenSSL
> isn't available, perhaps like the ssh-hostkey script does?

Ok, I've fixed this. While doing so I also came across the same problem in my MySQL scripts.
I've fixed them as well and I'll post the diff in a separate thread to get any comments before commiting the change.

I'm attaching the new version of the library any pgsql-brute script:

Attachment: pgsql-brute.nse
Description:

Attachment: pgsql.lua
Description:

> David Fifield
> <pgsql-brute.pcap>_______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

//Patrik

--
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/