Last updated at Fri, 21 Jul 2017 13:33:38 GMT

Pass the Hash, Database Style

One of the tried and true techniques for extending access in any Windows environment is the Pass the Hash (PTH) attack. As you can see from the linked Wikipedia article, this attack is described in the context of Microsoft authentication protocols NTLM and its older sibling, LanMan. If you have the hashed password for something that relies on NTLM-based authentication, you needn't bother cracking it; for reasons escaping easy explanation, the hash itself is just as functional as the underlying password.

Well, it looks like someone needs to update the Wikipedia article. It was revealed recently on the Hashcat Forum that PostgreSQL instances are also vulnerable to Pass The Hash. Again, the reasons for allowing PTH as a protocol element aren't well-articulated, and it's difficult to understand how such a thing could be implemented by accident. To allow this, you need code that says, "Oh, here's the password, and I'm going to encode it -- oh wait, no, it's already encoded, so I'll just pass it along." It's a very strange protocol design decision, and not one that comes up often.

While I don't know the reasons Microsoft and the PostgreSQL folks had for this, what may be going on here is a misunderstanding between "encoding" and "encrypting." So, let me back up a little bit.

MD5 is part and parcel of many encryption standards and has its own set of weaknesses which I won't get into here. However, it's a hashing algorithm, not an encryption algorithm. There is no secret key, and the md5sum of "trustno1" is always and forever 5fcfd41e547a12215b173ff47fdd3739. So, while this may look random and unguessable, it's already been added to any number of rainbow tables, given its status as an extremely common password.

Rainbow tables, though, aren't the problem here. Let's say I know your password hash is ac76486d35cb6ab4cbe52fd4a034e9ce, which is an uncommon password hash and not currently on any public rainbow table. But, I don't care, because if I can just take that hash and treat it like a password, I don't have to do any of that tiring cryptanalysis or cracking work. For all practical purposes, the password hash and the original, cleartext password itself are equivalent. In this configuration, every PostgreSQL user actually has two passwords, and either will work.

So, if I'm a penetration tester, and your PostgreSQL database is set up to store MD5 hashes of passwords, and your database also accepts MD5 hashes as passwords, storing the hash is exactly the same as storing the plaintext password for that database. This breaks one of the cardinal rules of authentication database design: Thou Shalt Not Store Cleartext Passwords.

Sure, I'd love to know what the plaintext behind ac76486d35cb6ab4cbe52fd4a034e9ce is, and given enough effort I can find that out. If I have that, I can start reusing the true plaintext password over other protocols. But, if I get in a position to sniff or dump PostgreSQL password hashes, I can extend my access to both that particular database server, and any other PostgreSQL database where the same passwords have been stored. This is great news for the penetration tester, since these people love extending access laterally. After popping shells, it's pretty much their favorite thing to do. Thanks to Dave TheLightCosine Maloney for updating the Metasploit Credential schema and LoginScanner mixin to allow for this new PTH vector.

New Modules

Since the last blog post, we've added six new exploits and three new auxiliary modules. In addition to the unpatched PostgreSQL design flaw, we have a new exploit for unpatched Seagate Business NAS devices. You really should read OJ's account of how an otherwise normal vulnerability disclosure exercise went sideways. The bummer here is not that Seagate is particularly incompetent or anything like that -- the bummer is that this sort of fruitless back and forth is pretty much industry standard, even for tech heavyweights. When you run into the fact that some major hardware and software vendors have no reasonable mechanism for dealing with reported vulnerabilities, it can be pretty demoralizing. Give OJ TheColonial Reeves a hug next time you see him, okay? Let him know that you at least still believe in the Exploit Fairy.

Exploit modules

Auxiliary and post modules

You should also check out what's included in this week's packaged release by reading Thao's most excellent release notes.