Impenetrable

Securing Remote Maintenance

Starting in PowerShell version 3, remote maintenance is supported by the Windows Remote Management (WinRM) service and the Web Services Management (WSMAN) protocol. WSMAN was designed as a secure and reliable method for managing computers based on Simple Object Access Protocol (SOAP) and HTTP. Both session-controlled 1:1 management by get-Command -noun PsSession and 1:N administration with the Invoke command are possible. Remote admins can start, view, terminate, and delete terminal sessions.

Additionally, alternative methods such as the Distributed Component Object Model (DCOM) relying on WMI calls or remote procedure calls (RPCs) also exist in PowerShell. PowerShell remoting by WinRM does not rely on an API call; rather, it communicates with a remote peer. The executed commands are sent to the remote shell and executed there, and the results are returned. An administrator uses PowerShell remoting to connect to server A. The existing session should then connect to server B, passing in the existing credentials. However, this approach fails, and access to the resource on server C is denied, because the credentials that were used to create the remote PowerShell session are not passed from server B to server C.

As a workaround, PowerShell offers Credential Security Support Provider (CredSSP) as an authentication method. However, when using CredSSP, PowerShell performs a network logon in plain text instead of an encrypted connection. Therefore, when using CredSSP, the password is first sent as a text message to server A, and the user can then authenticate against server B.

PowerShell Limitations

Windows PowerShell is a .NET application that belongs to the System.Management.Automation class type in the .NET framework. Interoperability with the .NET framework puts WPS on par with the most powerful scripting languages, ranking up there with high-level languages like C#. Windows PowerShell has automatic and self-defined variables, as well as host environment variables, that can be used to control PowerShell's behavior. The $ExecutionContext variable is particularly relevant for security; it contains a list of sub-objects with configuration options. Settings regarding class access can be implemented by the SessionState.LanguageMode object, where:

• FullLanguage = no limitation.
• RestrictedLanguage = no property reference, no method call, no object initialization, no change of host settings possible.
• NoLanguage = static methods of a class are not executed, only referencing of core types.
• ConstrainedLanguage = (see NoLanguage).

Conclusions

Deeply anchored in the system and with access to system APIs, PowerShell can play the devil's advocate, assuming the role of the bad guys and scanning for IT vulnerabilities. The knowledge of offensive possibilities can lead to a more considered use of Windows PowerShell. Here, Just Enough Administration especially seeks to replace rigid group-based management with the roles that admins actually need.