Is administrators_authorized_keys a security problem?

[gpduck]

Can someone please explain the reasoning behind PowerShell/openssh-portable/pull/369?

Unless I just don't know what I'm doing, it seems like this lets anyone with a key in administrators_authorized_keys log in as any other user in the administrators group? I feel like this should not be a default configuration (or anyone's configuration really)...

[manojampalam]

Reason behind this change: You could otherwise do the following in a non-elevated session, when sshd is running:

cd %userprofile%
ssh-keygen
copy .\.ssh\id_rsa.pub .\.ssh\authorized_keys
ssh localhost "i can do a privileged task"

This would bypass Windows UAC and lead to privilege escalation.

How can we solve this?
By making sure that the default location of authorized_keys for administrators is itself in a privileged location that only Administrators have access to.

Where could it be?
Why not %programdata%\ssh since it hosts the rest of ssh/sshd config too

Should we separate out authorized_keys for different users in Administrators group?
Lets see. If I'm an admin, there nothing stopping me to play around with sshd config and do something like this

Implant this in sshd_config
AuthorizedKeysFile c:\mystaticauthorized_keys

and effectively login as any user I wish. So, there is no real security benefit in separating authorized_keys for users in Administrators group. With an intent to keep things simple, we decided to go with a single file. If you wish, you could override it with something like this:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/%u/authorized_keys

[jborean93]

So does this mean for a user in the Administrators group, it's authorized_keys file needs to be in C:\Program Data\ssh\<username>\authorized_keys and C:\Users\<username>\.ssh\authorized_keys is no longer valid?

Isn't the whole point of the LocalAccountTokenFilterPolicy the usual way to control this? Why would SSH be different when you could also say the same thing about a loopback WinRM command, or anything else that does a network logon.

This is a bit concerning as you now have different behaviour from what users may expect which is to have this file in the user's .ssh folder in their profile directory. This coupled with the fact that the MS stance seems to be that UAC is not considered a security boundary* means you are treating it like it is when there are other ways to get around this. I could be misinterpreting the situation so please let me know if that's the case.

* See the below for references

• https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac/

One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all

• https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria?rtc=1

This is saying UAC is a defence in depth and not a security boundary

[gpduck]

It's my understanding that UAC is not a security boundary (so technically no privilege escalation is occuring). However I believe separate accounts are supposed to be a security boundary and out of the box, this configuration would allow any administrator to log in as any other administrator with no logging or auditing that it occurred. This seems to violate that security boundary.

The new default configuration is the equivalent of just having everyone in an organization log in using a shared admin account. Shipping with the extra %u in the file by default would preserve the expected security boundary of using separate accounts (and allow filesystem auditing of administrators changing other user's authorized_keys files) while still mitigating the UAC problem.

[jborean93]

this configuration would allow any administrator to log in as any other administrator with no logging or auditing that it occurred

An admin can do this anyway if they have enough privileges set (the default set is enough). If you have the SeTakeOwnershipPrivilege and SeRestorePrivilege you can adjust the other admin user's profile to put your own key in there with the correct privileges which is the same thing here. If you have the SeDebugPrivilege, you have enough to impersonate the SYSTEM account and call LsaLogonUser and log on any user without a password. There's bound to be other scenarios that could achieve the same result but this is just how Windows works. Once you have admin privileges you can pretty much do anything locally.

The key part here is that you don't have delegation capabilities so you cannot interact with network resources as that user unless you have the password. What I'm concerned about is the behaviour change for admin accounts that doesn't really achieve anything. This leads to fragmentation , confusion for end users, and adds complexity.

[gpduck]

I realize that as an administrator you can eventually accomplish anything, but calling a bunch of APIs to take over someone's account and typing "ssh otheruser@server" are on totally different levels. If you had two people with similar names you could accidentally end up logged in as someone else because of a typo, and that seems like we've set the bar a bit too low.

[jborean93]

You would still need to set up the key for that user under that directory. It's not one shared key just the location of the key is different. E.g there would be a key for Administrator under C:\ProgramData\ssh\Administrator\authorized_keys and then a key for otheradmin under C:\ProgramData\ssh\otheradmin\authorized_keys.

[gpduck]

The configuration that is shipping now is a single administrators_authorized_keys for everyone in the Administrators group. I would be fine with the version that includes %u.

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

[jborean93]

Oh I did not realise that I thought the default was with %u. This is more troubling then I thought.

[manojampalam]

Feedback taken. We'll consider a change in the next release. For the time being, please override. Also bear in mind the implications with domain accounts (%u would resolve to domain\user).

[jborean93]

@manojampalam did you end up making a decision on this, I see the next release is out and still contains this entry.

[manojampalam]

Not yet. Contemplating on making yet another breaking change. The only drawback of the current setting is a potential "accidental log in as someone else because of a typo". In its defence, the current setting sets a clear expectation that all admins on a machine are equal. One can easily impersonate other, irrespetive of how the this path pans out. Its also easy to use and manage since there is no user specific variability in its path.
Otherwise, I believe this would not be a practical problem as "admin" in most cases is a single principal. If it were ever a problem, one could easily customize this path to suit their needs.

[jborean93]

Thanks for the update.

My main objections to it is that it's a breaking change in the first place and a change in the expected behaviour for SSH in POSIX. We all know that by default an SSH key should be located in ~/.ssh/authorized_keys and even for root that would be relevant. From a security perspective I agree with what you are saying I just think it's too different a change in behaviour and if the ultimate goal was to merge this back into the upstream repo as 1 package then this might be a barrier that has to be changed again. I'm not a maintainer there so it's just my thoughts.