Correct way to do privilege elevation like sudo?

[RaymiiOrg]

I'm looking for a way to do sudo-like privilege elevation. Administrators are not allowed to login, so as a regular user I need a way to become Administrator to do privileged actions, in the same ssh session. I've written down a way with Powershell here:

https://raymii.org/s/tutorials/SSH_on_Windows_Server_2019.html#sudo

$Username = 'Administrator'
$Password = 'P@ssw0rd'
$Pass = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$Pass

Enter-PSSession -ComputerName localhost -Credential $Cred

Example output:

[localhost]: PS C:\Users\Administrator\Documents> whoami
win-doipgfhik47\administrator

But that is not as easy as just "sudo". What is the correct way to do privilege elevation?

[jborean93]

I could be wrong with this but I don't believe it is possible to have a sudo like setup of Windows when the connecting user is does not already have admin credentials. AFAIK there are 3 public APIs you can use to create a new process under a different account;

• CreateProcessWithLogon
  • There is nothing in the docs that indicate you need specific privileges to run so a standard user should be able to call this
  • You can't control the logon type, it will only logon with an interactive type and not batch
• CreateProcessWithToken
  • You can create a process from an existing process token that has been duplicated or from calling LogonUser
  • Because it uses an existing token, you can call LogonUser and create a token with a different logon type, like batch
  • It requires the SeImpersonatePrivilege which isn't assigned to a standard user so this is out
• CreateProcessAsUser
  • Like CreateProcessWithToken, it requires privileges that are not held by a standard user; SeAssignPrimaryTokenPrivilege and SeIncreaseQuotaPrivilege

So because CreateProcessWithToken and CreateProcessAsUser requires privileges that are not assigned to standard users you are left with CreateProcessWithLogon but this probably won't get what you are looking for. This is because on a typial Windows host, an admin user logon would have 2 tokens assigned;

• A limited token with the Admin group and certain privileges stripped out
• A full token with all the groups and privileges that are assigned to that account

There are cases where an admin account would only have the full token which "should" work for you but this isn't universal. These scenarios would be;

• UAC is disabled
• You are creating a process with the BUILTIN\Administrator account and Admin Approval Mode is not enabled for that account (this is the default on Windows)

If UAC is enabled, you aren't running as the builtin admin account, or it is the builtin admin account and admin approval mode is enabled for that account, then the created process will run under the limited token. This is because when you call CreateProcessWithLogon, the spawned process will use the limited token so you can run commands as that user it just won't be elevated, defeating the point of using an admin account. Technically you can use GetTokenInformation with TOKEN_LINKED_TOKEN to get the full token but you would require the SeTcbPrivilege privilege which not even admin users are assigned by default.

This means that unless an existing service (with higher privileges) acts as a broker, you aren't able to logon as limited user and "sudo" to an admin account with all it's privileges intact. I'll be happy if someone could prove me wrong with this as I've been looking for a way to achieve this outside of SSH.

[manojampalam]

@RaymiiOrg your best bet is to do a nested ssh from within the remote session

ssh -t adminuser@localhost

[mgkuhn]

PowerShell has a feature called Just Enough Administration that sounds like the closest thing I've seen so far on Windows to /etc/sudoers on Linux, i.e. a config file where you can specify who is allowed to do what with elevated privileges. However, elsewhere it says "SSH-based remoting doesn't currently support remote endpoint configuration and JEA (Just Enough Administration)".

What is still required to make JEA work over SSH?

[jborean93]

@mgkuhn JEA is something that's implemented directly in PowerShell and WinRM/SSH is just the underlying transport for the PSRP fragments sent over the wire. This means it's probably a question for the PowerShell team to talk about how to implement JEA support over SSH as this project stays focused on the SSH aspects. I'm in no way affiliated with either teams so I'm not sure what communication goes on between the 2 or whether there are already plans to do this currently.

Currently JEA works over WinRM by having a JEA configuration tied to a specific resource URI registered against the WinRM listener. When a user goes to connect to a particular configuration endpoing, using -ConfigurationName in the PS cmdlets, the WinRM listener will call the dll registered to that configuration which then starts up a Runspace with a restricted set of actions that are allowed.

SSH is a bit different as it uses a subsystem that is set to call pwsh.exe -sshs -NoLogo -NoProfile to pipe the PSRP fragments through the standard sdin and stdout pipes. This is why you need to add the following line to the sshd_config file for PSRP over SSH to work Subsystem powershell c:/program files/powershell/6/pwsh.exe -sshs -NoLogo -NoProfile. Potentially this could be extended to allow different JEA endpoints to be registered and used over custom SSH subsystems but this would still require plumbing to be done in PowerShell for it to work.

It looks like the -ConfigurationName also controls what subsystem PowerShell connects to when using SSH and it defaults to powershell. This may mean that they are planning on implementing JEA through custom subsystems but I could be completely wrong here. In the end this is more a question for PowerShell/PowerShell as this is just used as a transport mechanism for PSRP.