Explaining the PostgreSQL pass-the-hash vulnerability

[atom]

While we were working on the hashcat trac ticket #490 Support for postgres challenge-response authentication we instantly realized that this scheme is vulnerable to a pass-the-hash attack (PTH).

As all infosec people know finding an unknown exploitable vulnerability is something that hooks us pretty hard. So we started to investigate that vulnerability instead of continuing to code the oclHashcat kernel. First, we tried to use the search engines to see if this problem is already publicly known. To our surprise, there were no interesting results (at the time we tried) for PostgreSQL in combination to pass-the-hash.

After that we tried to write a proof of concept (POC) to make sure our finding is real, using the latest available PostgreSQL database version from their GIT repository. That indeed worked so we decided to write a comprehensive write-up of our finding and sent it to the PostgreSQL security team and hence we handled this problem using a responsible disclosure.

The PostgreSQL security team response was fast. The response was (in short) that the vulnerability is known and they linked us to a public mailing list. It took us a little bit to go through all the different posts and we finally did find an interesting post that seems to be the only post that somehow referes to the PTH protocol design weakness. To our surprise, no one commented on this, in our opinion, very important note about this critical protocol design weakness. The response to our private email to the security team also said that there is no reason to keep this disclosure private and that we can go ahead and publicly discuss/announce it.

Attached to this forum post is a link to our comprehensive write-up, a link to our proof of concept patch and including in our write-up a proposal for a fix in pseudocode form. As we are no professionals when it comes to handling such weaknesses we hoped that the postgres security team would took the lead over handling the issue and for example open up a CVE or starting on implementing a fix, but this did not happen.

We know that many hashcat users work professionally as pentesters or do have very good pentesting skills, hence we are pretty sure that you will "like" this pass-the-hash weakness and have some opinions to share how critical such things are.

For those of you who do not deal with PTH in a daily basis, PTH is simply a technique that allows an attacker to gain access to a system that is protected with a password but without knowing the password. So instead of cracking the hash you can use the hash itself for authentication. Simply put, (using this protocol) you do not need to know the password to login to a PostgreSQL server even if it is "password-protected".

Finally, please note that this vulnerability is still present in all known PostgreSQL database versions.

Here are the links:

• Write-up including proposal for FIX
  
• POC 1
  
• POC 2
  

--
atom
philsmd

[giveen]

Really good read, you would have to capture the hash first right as it transitioned across the network?

[atom]

Really good read, you would have to capture the hash first right as it transitioned across the network?

It's a bit different but for your case we have added a new hash-type -m 11100 which let's you crack such a sniffed authentication

[coolbry95]

Really good read, you would have to capture the hash first right as it transitioned across the network?

Based on the write up you need to just dump the credentials. Then use the md5 hash from the credentials database. There is no need to sniff the hash over the network. Although in theory you could also sniff the hash over the network and still do pth. I believe this is possible I may be wrong. From the write up it also seems they use ssl so you would have that to deal with also.

[mr.schyte]

Based on the write up you need to just dump the credentials. Then use the md5 hash from the credentials database. There is no need to sniff the hash over the network. Although in theory you could also sniff the hash over the network and still do pth. I believe this is possible I may be wrong. From the write up it also seems they use ssl so you would have that to deal with also.

You cannot do pth with the captured hashes, because H(P) is never transmitted over the wire, only H(P . R) is. Here P is the password and R is the random nonce as used in the article. Since H is a one way function you cannot recover H(P) from H(P . R) efficiently.

Edit: It seems that R is 4 bytes only, so you have 1/2^32 chance of success; the case when the nonce is the same.