While preparing my talk for this year’s PSConfEU, I made a discovery that, while not being a major security disaster or anything like that, still surprised me a bit.

Started as a skunkworks type side project at Microsoft, SSH wormed its way into being an integrated Windows feature both on server and client. The PowerShell team has been evangelizing SSH remoting across all platforms for quite a while now, now more or less openly declaring WinRM remoting „legacy“. But is it all bright and shiny?

„Deny Logon“ policies do not affect SSH

You’re reading correctly. Here we have a machine named PSCONF-MS01 for which a GPO named „Keep Bob Out“ denies a domain user named Bob any sort of interactive, remote-interactive, service or batch logon:

Yet, since PSCONF-MS01 has OpenSSH Server activated and Password Authentication enabled, we can SSH in from another machine:

immediately leading to

Unsurprisingly, this also works with PowerShell 7 and SSH Remoting:

But is it an actual session?

With credentials exposure and so on? Oh yes, it most certainly is:

The logon type 8 gives us a hint to what is going on here. 8 stands for „Network logon with cleartext credentials“, which is why none of the prepackaged logon types in the group policy applies here. We basically use SSH encryption layer to send cleartext creds to the SSH daemon in a more or less secure manner, and the daemon attempts using them for establishing a logon session. Here’s the accompanying 4648 to the above 4624:

What about WinRM Remoting?

It depends on what you’re really asking 🙂 Since WinRM is an integral part of Windows and not a bolted-on port of a UNIX daemon, it handles impersonation more gracefully and creates a logon session of Type 3 (Network logon) without exposing credentials – but at the price, as you probably know, of the next hop not being authenticated unless you configure Kerberos delegation and ensure that Kerberos actually ends up being used (e.g. by not using IP addresses to connect but rather FQDNs).

The logon restrictions set by the above Group Policy will still be bypassed, but since WinRM-based remoting has JEA built in, a user needs to be a local administrator or at least a member of the local Remote Management Users group to access the WinRM endpoint in the first place so can’t be just a random connection attempt.

But what about key-based SSH auth?

This may come as a surprise, it certainly did to me. Using a private key file with SSH creates a Type 3 logon session which, while also bypassing „Deny Logon“, will not disclose cleartext creds – again, at the price of not being capable of a second hop.

Sounds dramatic. Why is it bad, again?

In my work, I usually concentrate on protecting privileged credentials from hijacked computers so my typical threat model for this would be a domain admin inadvertently connecting to a compromised system by using SSH remoting with password authentication and leaving their cleartext credentials exposed there. This being bad enough already, my esteemed colleague and security researcher Andrea Pierini pointed out that, if an unprivileged user were to connect to a Domain Controller using SSH, they could be able to initiate a „Remote Potato“ type attack which would lead to compromising credentials of legitimate Tier 0 admins logging on to that box.

Restricting logon properly

In all above mentioned scenarios, denying network access would prevent the user from remoting into the Windows box. However, denying network access may not be practical – domain users need network access to DCs (LDAP and SYSVOL), authorized users need access to file servers, SQL servers etc. So, instead of denying network access on top of denying all the possible logon types on the target machine, you should use Kerberos Authentication Policies, at least for network cleartext logon scenarios. If you do require some kind of network access to the target machine but not the kind resulting in an actual interactive session, this will be much trickier. Lastly, should you belong to the unlucky ones still stuck in the pre-Server2012R2 world, your best bet would probably be using the old logonWorkstation attribute from the Windows NT era.

And if you are going to use SSH to remote into Windows machines, do not allow password authentication in the SSHD configuration and stick with key-based – remember, even unprivileged credentials can be of use for an attacker!

Happy and safe remoting!

Image by Convegni_Ancisa from Pixabay