Does a known security issue allow ssh login via system accounts?

Whit Blauvelt whit at transpect.com
Wed Mar 2 04:16:37 AEDT 2022


On Mon, 02/28/22, 2022 at 11:17:12PM +0100, Alexander Wuerstlein wrote:

> To check, I'd look at: PAM-Config (/etc/pam.d/*). That that config is
> the same as another machine doesn't mean that there isn't a problem in
> there. 

Right. Just saying if the problem's there, it's endemic to Ubuntu 16, as
those files don't differ from the same on other Ubuntu 16 systems

> It just might mean that an attacker didn't introduce the problem
> (or the problem was introduced in all machines). Then I'd look at
> /etc/nsswitch.conf to check for other passwd/group/shadow mechanisms
> than 'file'. 

The nsswitch.conf is consistent even with Ubuntu 20 systems, except that the
latter have added systemd on the passwd and group lines. 

> Then I'd look at the relevant configs for those mechanisms.

All I've found are standard. 

> Then I'd compare "getent passwd" to /etc/passwd, same for group and
> shadow. 

They each produce dumps identical to the files. However the VM has been
rebooted since the compromise, so this doesn't rule out prior subverion
there.

> There might be sssd in use, check config and cache.  

I'm not familiar with sssd. Certainly never configured it. There's no "sssd"
process running.

> And check etc/shells, this should only contain proper shells, not anything
> /like usr/bin/nologin, /bin/false, ...

Just the standard list there. 

> ... In the sshd_config, there might also be Match-blocks or other
> configuration that makes certain users be treated specially.

The match-blocks in sshd_config are only of the restrictive kind for certain
groups, not such as to add any extra permissions.

> It is hard to say what your exact problem is withouth having seen all of
> the above. There are just too many things that can go wrong and a lot of
> "traditional nuances" in the configs one has to watch out for.

> > 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.
> 
> I don't see any common use cases for system users to be accessible via
> SSH directly. Usually one uses /bin/false as a shell to disable login
> for those users. /usr/bin/nologin does the same, but with a message.
> This is what most distros do.  I've seen problems with a homegrown
> version of /usr/bin/nologin that displayed a multipage message with
> 'press any key to continue' and timeouts, which caused the exact
> portforwarding problem you might have.

It's the standard Ubuntu 16 version of that file.

> Another approach would be AllowGroups in the sshd_config, or appropriate
> PAM configuration (there are tons of possibilities here).

What _is_ different here -- the only thing distinguishing this system from
stock Ubuntu 16.04.7 -- is the custom compile of a later (but now far from
latest) version of OpenSSH. The vulnerabilty looks to be either in Ubuntu
16.04.7, now beyond EOL, or OpenSSH_8.6p1 using OpenSSL 1.0.2g, also now
antiquated -- or their combination. Adding a DenyUsers line in sshd_config
listing all the system user accounts works to block this intrusion, and will
be my standard practice now. I found some discussion from about 8 years ago
claiming older versions of OpenSSH checked for the "nologin" shell (at least
in some configurations) and themselves blocked accordingly, which if true
would be equivalent to what adding that DenyUsers now can do.

Much appreciate all your help. Most generous! I only wish I'd have found
some additional clue by now.

Best,
Whit


More information about the openssh-unix-dev mailing list