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:
--
atom
philsmd
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:
--
atom
philsmd