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

On 2022-02-28T18:55, Whit Blauvelt <whit at transpect.com>
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:::
> 
> Either the /usr/bin/nologin or the "*" in the second field of
/etc/shadow
> should have been enough to prevent "Accepted password for
backup." The
> /usr/sbin/nologin is the standard version for that Ubuntu generation, byte
> identical.
There are a few more mechanisms that may allow password logins despite
the measures you named: When using PAM authentication (which I would
assume, since you are talking about Ubuntu) all the configuration in
/etc/pam.d regarding ssh logins, so /etc/pam.d/ssh and
/etc/pam.d/common* will be in effect. If e.g. some module there
specifies a different password and shell for backup, e.g. from LDAP,
NIS, ActiveDirectory or different passwd/shadow files, those might
apply. You said below that pam.d is "standard", but installed packages
might modify configuration there, so I'd suggest having another look
there.

Also, depending on your configuration, /usr/sbin/nologin may not be
sufficient to prevent port-forwarding without an open shell, thus
enabling a spammer to forward some SMTP port for sending spam without
authentication by "looking like" coming from an internal server.  This
is also hard to see and distinguish from an attacker having a shell in
the logs.
> Adding this to sshd_config was effective:
> 
>   DenyUsers backup
> 
> If that's still not the default for system-level users like
"backup", would
> adding it be a reasonble feature request? Or is that on the distros to
> define their default sshd_config settings?
I'd consider it good practice to selectively 'AllowGroup ssh-login'
or
something to that effect for any internet-exposed system. But common
distros are far more open than that.  I don't think OpenSSH is the right
place for a policy change, since as mentioned before, there is a lot
going on in PAM that will affect what OpenSSH does here, without being
part of OpenSSH.


Ciao,

Alexander W?rstlein.

Hi Alexander,

Much appreciate the quick response and advice. May I ask for just a bit
more? It would be useful to find out more precisely how the intrusion worked
to know where its method should be appropriately reported.
> There are a few more mechanisms that may allow password logins despite
> the measures you named: When using PAM authentication (which I would
> assume, since you are talking about Ubuntu) all the configuration in
> /etc/pam.d regarding ssh logins, so /etc/pam.d/ssh and
> /etc/pam.d/common* will be in effect. If e.g. some module there
> specifies a different password and shell for backup, e.g. from LDAP,
> NIS, ActiveDirectory or different passwd/shadow files, those might
> apply. You said below that pam.d is "standard", but installed
packages
> might modify configuration there, so I'd suggest having another look
> there.
Checking the files in /etc/pam.d/ and /lib/x86_64-linux-gnu/security/, they
exactly match the same sets of files on another Ubuntu system of the same
vintage with no public exposure, both in files there and each file's
particulars. There is no LDAP, NIS or AD use by the system. The string
"backup" is not in any file in /etc/pam.d/; the two places it
obviously
shows up in /lib/x86_64-linux-gnu/security/*.so files are in message
strings, not references to the userid.
> Also, depending on your configuration, /usr/sbin/nologin may not be
> sufficient to prevent port-forwarding without an open shell, thus
> enabling a spammer to forward some SMTP port for sending spam without
> authentication by "looking like" coming from an internal server. 
This
> is also hard to see and distinguish from an attacker having a shell in
> the logs.
Likely right about port forwarding. When I caught the intrusion in
action "backup" did have an open ssh connection; unsure if
"backup" had a
shell. Postfix was seeing the email origin as local.
> > Adding this to sshd_config was effective:
> > 
> >   DenyUsers backup
> > 
> > If that's still not the default for system-level users like
"backup", would
> > adding it be a reasonble feature request? Or is that on the distros to
> > define their default sshd_config settings?
> 
> I'd consider it good practice to selectively 'AllowGroup
ssh-login' or
> something to that effect for any internet-exposed system. But common
> distros are far more open than that.  I don't think OpenSSH is the
right
> place for a policy change, since as mentioned before, there is a lot
> going on in PAM that will affect what OpenSSH does here, without being
> part of OpenSSH.
Is there a valid use case where standard systems users (sync, backup, etc.)
should have ssh access? If not, blocking by default should be prudent. On
the other hand, if there are valid, standard uses for ssh for such users,
what are normal ways to enable them? I should see if any of them were used
here. 

Highjacking a server for spam is a pedestrian goal; this evidences something
the hands of the script kiddies which requires better defense. Neither OSSEC
(Wazuh) on the system, nor regular scans with Nessus and OpenVAS, gave
warning. It would be good to find a signature for it; a start would be
adding a watch in OSSEC for system-level userids showing up in auth.log, but
there's some additional trick enabling those to bypass standard security.

Thanks again,

Whit