Administrators_authorized_keys security issue

[RalphSchuelke]

Hello,

referencing #1324 which has been closed because of discussions being deprecated in the Issues section.

If this is a duplicate, please close and reference. Or better yet, move there. Thanks.

in a nutshell

1. current service defaults allow any local administrator to impersonate anyone who is at least a local administrator. This includes domain and enterprise administrators.
2. using administrators authorized keys, as implemented, allow anyone who is a local administrator on at least one host to escalate their own privileges as described above.
3. It is very difficult to detect, or block, this.

Something - anything- must be done to address the problem. This tears down windows integrity and hurts ssh because it’s seen as being responsible.

For further information, see #1324 and linked issues.

the issue

SSH on windows implements a common authorized_keys file for all administrators on the host where the sshd service is running. This enables impersonation of all administrators.

Implications

In a managed environment, a lot of accounts get put into the local administrators, some by default, some by explicitly adding them.

Basically, anyone can use SSH on windows to steal my identity. They can act in my name without my knowledge and without me having to approve anything. I’ll be at fault and may even be unable to prove my innocence.
And not just me either. ALL my fellow administrators are at risk.

On a scale where 0 is secure and 10 is I don’t know how to adequately describe the impact, this is a solid 15.

details

SSH has no concept of distributed environments - all accounts, to SSH, are local accounts.

Therefore, administrators _authorized_keys enables any individual local administrator to trivially impersonate someone of higher rank. This local administrator can then act within the execution context of eg an enterprise administrator and is then able to affect the entire forest.

Referenced issue #1324 does not adequately address privilege escalation. Impersonation on windows is bad enough, but it pales before privilege escalation from the lowest level of permissions that are available in a distributed environment (“can modify system configuration on a single host”) straight up to “can manage the enterprise”.

exacerbating the problem is Windows’s permission set that enables an individual to set up access to the highest privilege levels: to achieve this, all they need to be is a local administrator.

The referenced thread goes so far as to suggest there is no escalation because all that happens is it enables administrators to do what they already can: manage a system.

But this ignores the hierarchical nature of a distributed environment. There are many administrators that can “do more” than local administrators- in fact, almost every administrator can do more than a local administrator. In an environment of eg. 10’000 endpoints, there is a difference between being authorized to manage one vs. being able to manage all of them—- without even having to do anything to get to that point.

In practical terms, the way administrators_authorized_keys is implemented, any intern in an IT department can gain control over their enterprise and everyone in it by;

• installing the openssh.server capability (which they are authorized to do as a local administrator)
• running it (same)
• Create a key pair and put the public part into administrators_authorized_keys (same)
• Log in as enterprise administrator using the key they just created

There doesn’t seem to be much that can block them from doing so:

• a network firewall with DPI will be unable to block intra-host traffic (when sshd runs on localhost)

• Anywhere else, as the service port is freely configurable by a local administrator, firewalls without dpi will not be able to reliably block ssh traffic; ones with dpi support will, but this would still require the ssh service to run on another node and there is no actual need for that.

• a software firewall such as applocker can block sshd from running, thereby mitigating the problem somewhat.

• But it can’t block any ssh clients, because it would mean to have to block the universe. There is always another ssh client you didn’t know and therefore didn’t block.

• this leaves open any situations where ssh services are required for any reasons.

I do not think the already-closed #1324 adequately addresses these concerns. Especially since points are raised there that suggests administrators_authorized _keys improves security.

In very simple terms: no it doesn’t. And as implemented, it can’t.

What can help

One of the key factors that enables the privilege escalation is that local administrators can expand their own security context. To get higher privileges, all they need is what they already have; local administrator permissions.

Therefore, I suggest introducing an additional security authority (rbac or whatever). A few related points:

1. Restricting service installation of sshd is infeasible.
   it would mean treating a particular service differently from all others.

2. running sshd as a particular account does not affect the issues. The problem is with configuration, not with the service’s execution context.

3. Being able to write to administrators_authorized_keys must (MUST) be restricted to EXCLUDE local administrators. That role being able to write here is what permits a local administrator to set up the relevant situation for themselves so they can elevate themselves (but it doesn’t affect an already set up context).

4. There is on windows a valid reason why an authorized keys file cannot go into a users profile: this profile might not exist yet and unlike on other operating environments, on windows, it is not sufficient to create a new folder to hold that profile along with the new key.

So it would be useful to deploy a designated folder to hold keys per user. Windows ACLs are sufficiently fine grained that each user can be set up to only see their own keys. (ETA: doesn’t help—— if I can sign in as X, I can access resources as X)

5. there already is an RBAC role for ssh users. There doesn’t seem to be any reason why there shouldn’t be another rbac role for ssh administrators- entirely disconnected from the local administrators group. This role can then be authorized to manage authorized_keys files (wherever they may be located).
   This includes administrators_authorized_keys - the problem isn’t so much that the concept exists, it’s that it is implemented by default; anyone setting it up deliberately is obviously going to be responsible for their own actions and decisions.

6. there is also the option to deploy, but not provision, the sshd service. If no default configuration is provided, then the service will not start without someone deliberately setting it up in a particular way.

Impersonation

Being a bsd based project, impersonation is something that’s par for the course. When in doubt, anyone can be authorized to impersonate everyone else eg by using the sudo tool (or any other implementation).

Not so on windows. Impersonation here is heavily frowned upon by design. To gain what amounts to impersonation on windows, it means setting up a security context using groups and then assigning users to this group. Impersonation will always match 100% of requirements (being that the context is shared); Windows will match just enough via ACLs that the results are identical.

As such, there are no guard rails against a concept that does not exist on windows, but that OpenSSH - not being a windows application- introduces; perhaps unintentionally; by allowing to customize the authorized_keys file path. Something that doesn’t quite matter on non-windows platforms; it’ll also permit impersonation and may also allow privilege escalation, but administrators are familiar with the concept. (Although granted, it does not appear there’s a valid use case that couldn’t be implemented another way.)

it might be advantageous to modify the codebase to ignore the authorizedkeysfile directive on windows. However that would be a breaking change with far reaching consequences. So in practical terms, it would probably be more efficient to just not provide a default and let ssh administrators come up with their own solutions, up to and including impersonation if they so choose.

ultimately, it is desirable to implement ssh on windows so that it is impossible to impersonate an account without the account holder to grant explicit permission.