Network-Based Attacks Against PostgreSQL

Before the database can be attacked , a connection must be established via a startup message containing a username. This must cause at least a partial match in the pg_hba.conf, or else the postmaster will respond with an ErrorResponse and the connection will be dropped. If a database name is not specified, it defaults to the username. Attackers may have to resort to guesswork if they have little knowledge of the environment. The error message returned to the attacker when no match has been made in the pg_hba.conf file does not reveal whether the username was correct but the database was not (and vice versa), nor whether there is a specific host from which the username-database name pair is accepted.

The techniques described in the following sections can be performed only if the attacker is on the same network segment as either the client or the server ”this implies the attacker has physical access to the network, or has already compromised a system on the same segment. This is not an unreasonable assumption, because it is rare that an administrator will allow remote access to their database from an untrusted network such as the Internet, thus the attacker will first look to compromise other systems that have Internet- facing services such as a web server or FTP server.

Network Sniffing

If SSL is not enabled, PostgreSQL transactions will appear in clear text. The packet sniffer Ethereal contains a basic PostgreSQL protocol dissector that displays strings contained in messages. If the attacker is able to sniff the initial exchanges of a connection, the username and database will become apparent, as will the authentication type. If the authentication type is set to AuthenticationCleartextPassword, the attacker will also be able to obtain the password; otherwise it will be encrypted or hashed ( assuming a password is required).

ARP Spoofing and TCP Hijacking

If the pg_hba.conf file consists of rules matching access from specific hosts , the attacker must compromise a particular host or launch a network-based attack such as ARP spoofing or TCP hijacking in order to appear to be that host. ARP spoofing (also referred to as ARP poisoning ) updates the target computer's ARP cache with forged ARP reply packets in an effort to change the IP “ MAC address mapping of another system on the network. The attacker will typically choose to target the ARP cache of the database server in order to make use of a particular pg_hba.conf rule (for example, a trust rule) or the ARP cache of a client (to tell it the new MAC address of the database server) in order to fake replies from the database and steal credentials.

TCP Hijacking is a technique that results in desynchronization of the client and server sides of a TCP connection. This is made possible by sniffing the wire to monitor TCP sequence numbers and then inserting spoofed packets to leave either side in an inconsistent state. TCP Hijacking is easier to perform on slow (that is, long round-trip time per packet) connections that exist for a long time. It is not without difficulties, one of which is the resulting "ACK storm " caused by repeated ACK packets sent by both sides in response to "missing" packets. With a limited window of opportunity once a successful hijack has been performed, the attacker is likely to attempt to execute a query that adds or upgrades an account via the pg_shadow table (or CREATE USER/ALTER USER ).

A number of tools are available that can perform TCP Hijacking and ARP spoofing. One such tool, Hunt, attempts to resynchronize the connection after the attacker has inserted the required data. Hunt is available at http://www. securiteam .com/tools/3X5QFQUNFG.html .

Ident Spoofing

When a rule is matched in the pg_hba.conf file that specifies an authentication type of "ident," the postmaster will connect to the client system on port 113 TCP. The listening identd daemon accepts requests of the form

 port_on_server,  port_on_client 

where port_on_server is the port on the system running identd (that is, the local port that the frontend has used to connect to the PostgreSQL database) and port_on_client is the port on the system connecting to identd (that is, the postmaster). As an example, the postmaster might connect to the identd daemon and issue the request:

 1025, 5432 

The identd daemon responds with:

 port_on_server,  port_on_client :  resp_type :  add_info 

where port_on_server and port_on_client are as above, resp_type is either ERROR or USERID, and add_info is the error type or username depending on the success of the query. Thus an affirmative response might be:

 1025,5432 : USERID : UNIX : admin1 

whereas a negative response might be:

 1025,5432 : ERROR : NO-USER 

As discussed in the previous chapter, the security of the identd daemon depends on the security of the client system. If the postmaster queries the attacker's machine, either through a loose entry in the pg_hba.conf file or a network attack such as ARP spoofing, the attacker can simply respond with the username of his choice. This effectively allows the attacker to brute force a successful login attempt. If the SAMEUSER directive is used in the pg_hba.conf entry, the username supplied by the attacker is matched against database usernames, otherwise an ident mapping file is interrogated.

Many Unix distributions ship with an identd daemon, which is often under control of inetd, the daemon responsible for starting server processes. Several freeware identd daemons are available for Windows, such as the Windows Ident Server ( http://identd.dyndns.org/identd/ ). Alternatively the protocol is simple enough that individual responses could be crafted via a listening Netcat.