Re: pgsql-brute and PostgreSQL match lines

[David Fifield <david () bamsoftware com>]

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.

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

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

David Fifield

Attachment: pgsql-brute.pcap
Description:

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