openssh unix dev - Mar 2022 - Does a known security issue allow ssh login via system accounts?

On Mon, 28 Feb 2022, Whit Blauvelt wrote:
> Hi,
> 
> If this is not the right place to ask this, please redirect me. Hopefully
it
> is a known vulnerability, due to out of date software. We had a server
> running OpenSSH_8.6p1 compiled on Ubuntu 16.04.7 which was compromised last
> week. The intruder managed to achieve this:
> 
>   Feb 24 08:13:52 localhost sshd[32276]: Accepted password for backup from
5.161.47.185 port 37962 ssh2
> 
> This despite that /etc/passwd has:
> 
>   backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
> 
> And /etc/shadow has:
> 
>   backup:*:16359:0:99999:7:::
We're not aware of any security problems in OpenSSH 8.6 that could yield
access to a locked account like this.

On Ubuntu, OpenSSH delegates to PAM for password authentication and
verification of the user's shell against /etc/shells. You can check
whether this actually enabled using 'sudo sshd -T | grep ^usepam'

It sounds like you have already verified that your PAM configuration was
not tampered with, so that removes one possibility. Reviewing the Ubuntu
PAM configurations and the patches they apply to sshd seem to be prudent
next steps.

It's possible that the above log message was not from the initial
compromise, but rather the attacker running their own sshd to act as a
more reliable foothold.

Hopefully you're able to preseve and perform forensics on the host.
If there is evidence of a bug in sshd, then please send it to the
security bug reporting contact: openssh at openssh.com

Thanks,
Damien Miller

On Tue, 1 Mar 2022, Damien Miller wrote:
> We're not aware of any security problems in OpenSSH 8.6 that could
yield
> access to a locked account like this.
I'd just add that if an attacker did have a sshd 0-day, then burning it
only to send spam seems amazingly profligate...

-d

On Tue, 03/01/22, 2022 at 09:45:04AM +1100, Damien Miller wrote:
> It sounds like you have already verified that your PAM configuration was
> not tampered with, so that removes one possibility. Reviewing the Ubuntu
> PAM configurations and the patches they apply to sshd seem to be prudent
> next steps.
Found the culprit: me. I was stupid enough to install and configure for
libpam-google-auth, given a company mandate to 2FA all connections with
admin access, where it wasn't in scope to add 2FA to all client accounts. If
there's existing documentation anywhere on how dangerous this is, it's
not
in libpam-google-auth's own docs, nor in the recipes scattered across the
net.

I've found no way yet to tweak it to be safe that I can be sure of, short of
running a separate sshd on another port for it. Has there been consideration
of adding 2FA to OpenSSH that doesn't require enabling PAM? Public keys and
IP restrictions seem enough to me. Yet my corporate overlord is required by
their insurance firm to use 2FA. To satisfy that demand, I compromised
security with the badly documented libpam-google-auth -- as if a firm that
can't even secure their flagship browser should be trusted on security.

Stupid me,

Whit