Re: [OT] Microsoft: Kubernetes clusters hacked in malware campaign via PostgreSQL - Mailing list pgsql-bugs

On Tue, 10 Jan 2023 at 18:58, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Tue, Jan 10, 2023 at 10:48 AM Magnus Hagander <magnus@hagander.net> wrote:
> >
> > On Tue, Jan 10, 2023 at 4:38 PM Jeffrey Walton <noloader@gmail.com> wrote:
> >>
> >> On Tue, Jan 10, 2023 at 10:20 AM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> >> > On Tue, 10 Jan 2023 at 18:07, Magnus Hagander <magnus@hagander.net> wrote:
> >> > > [ ...]
> >> > >> I wonder what was the vulnerability in Postgres that enabled "hackers"
> >> > >> to run malware? I've read the article and the linked ones and found no
> >> > >> causative link between Postgres and malware inside. Sorry, it seems
> >> > >> like baseless warnings, not a description of vulnerability. Maybe I
> >> > >> haven't got something?
> >>
> >> From the article Pavel linked to (below), it looks like PostgreSQL may
> >> suffer from CWE-521, Weak Password Requirements.
> >>
> >> Well designed systems today reject weak and wounded passwords out of
> >> the box. Users don't need to do something special to enjoy the
> >> benefit.
> >
> > The default PostgreSQL installation on most platforms doesn't even allow password based logins. And it doesn't
allowconnections across the network at all. And it most definitely doesn't assign any weak default passwords. 
>
> CWE-521 does not require the system to generate a weak password. It is
> triggered when a weak password is used for authentication.
>
> >> Now if a user pulls out the foot gun and disables strong password
> >> requirements, then the user created the misconfiguration and the user
> >> is at fault. If the user did nothing out of the ordinary, then I would
> >> look for a design flaw, like letting users use weak passwords in the
> >> first place.
> >
> > The reference in the first article is to "trust" authentication, which is even worse than that -- it is explicitly
askingpostgres to "turn off all authentication". 
> >
> > The second article doesn't actually contain anything more than a guess that maybe the password was weak. But the
coreproblem there more seems to be to expose the postgres port to the public with no restrictions at all - one should
*never*do that with the database port, regardless of database. It is correct that postgres does not itself have any
defenceagainst a brute force attack if you use the built-in password auth (if you use an integrated authentication
method,that of course depends on the method it's being integrated with, but for simple passwords it doesn't). 
>
> Agreed.
>
> But stepping back a bit, where is the PostgreSQL security guide or
> hardening guide? I would expect the document to cover these topics
> (and more). Earlier it was said, "The page simply doesn't exist,
> because the information is spread out across multiple places". Sending
> users on a scavenger hunt is not a good approach to the problem. Maybe
> all of this points to a gap in documentation?

I don't think there is a gap in a documentation. The page
https://www.postgresql.org/docs/current/client-authentication.html
addresses auth options in a very detailed way. The only problem is
that 10+ years old page doesn't link to it.

Regarding the fact that using weak passwords isn't limited, I think
anyone can write an extension that limits (or advises against) weak
passwords based on the author's definition of weakness, like checking
by dictionary or so. That's the power of Postgres extensibility. I
don't like an idea that Postgres core should enforce some arbitrary
things like "weakness".

Regards,
Pavel Borisov.