OpenSSH login to a system account

Question

While doing a routine pen test for a client I came across a box that had OpenSSH 7.2p1 running.

Through a Google search I figured out this vulnerability with the above OpenSSH version

I went in to investigate it further. I was able to understand some of the details of the vulnerability and the exploit itself. However, I need help understanding some more things.

I have a basic understanding of how exactly does SSH work. This is a resource that is very much in sync with the understanding that I have.

Now investigating the issue further, from what I understand is that on the server X11Forwarding yes is required in the sshd config file. Because I have SSH access to the box, I verified that this condition was met.

Next my understanding about it is that an account with the shell set to /bin/false or a user account with forced-commands is needed to be able to demo the exploitation itself.

Also, additionally, the above user must already be authenticated. (Is this understanding correct?)

So I went in the box and tried to see if there is any such user that meets the above conditions.

I did a cat /etc/passwd | grep /bin/false and it pulled up a list of users that had their shell set to /bin/false. One of these users was the user named mongodb, that had it's home directory set to /home/mongodb and also was protected by a password as indicated by the x in the passwd file.

I read about mongodb installation and came to know that it gets installed with its own user.

Now somethings that I need help with understanding :

1. What is the use of this mongodb user? I looked thorough /home and could not find a home directory for this user despite that it was mentioned in the passwd file.
2. How and when does this user get authenticated?
3. Is there any way that when this user authenticates with the system, it can be leveraged to exploit the OpenSSH authenticated xauth command injection bug?

Please pardon my less understanding of Linux users or SSH and let me know if there are any resources that would help me understand these basics better.

Answer 1

Unix systems typically have many user accounts for system purposes, used for a particular system service, e.g. to run a particular daemon. The processes that provide that service run as that user, the data files manipulated by the service are owned by that user, and the configuration files are readable by that user (but normally not writable: root, i.e. the system administrator, owns the configuration files). This mongodb account is a bog-typical case: it would own the MongoDB database files.

Home directories are not really useful for most system users. For human users they determine where applications look for configuration files, but that's not a concern for system users that only run a specific program that doesn't read per-user configuration files. The home directory is also where the SSH server looks for the user's authorized keys, i.e. additional credentials that grant access to the account, but most system users shouldn't be logged into and so won't have SSH keys. Sometimes the home directory is a system directory (e.g. under /var), sometimes it's /, sometimes it's a nonexistent directory, it doesn't matter.

System users may or may not have a valid shell as their login shell. Having a valid shell such as /bin/sh allows things like su mongodb but in many cases this isn't necessary and the login shell is set to a program that does nothing, such as /bin/false, /bin/true or /usr/sbin/nologin. This serves as an extra layer of defense if some other part of the configuration is botched and allows the user to log in.

Most ways to access a user account run the user's login shell, including SSH (but also su, cron, etc.). Normally, with the shell set to /bin/false, even if you managed to log in over SSH, you wouldn't be able to run anything. The bug you found, CVE-2016-3115, is due to OpenSSH running the X11 cookie injection (calling xauth) before it runs the user's login shell.

But to exploit this bug, you'll first need to pass the first layer of defense and log in to the mongodb account. This should not be possible: the account has no authorized public keys since its home directory doesn't exist, and it should not have a password. Having x in the password column of /etc/passwd does not indicate that the account has a password; it's probably the case for all the accounts. It means that the password hash, if there is one, is in /etc/shadow.