News

Windows PowerShell 5.0 Expected To Add Improved Security

• By Kurt Mackie
• 02/24/2016

Microsoft is planning to deliver its Windows Management Framework (WMF) 5.0 release-to-manufacturing (RTM) version by the end of this month, which also will bring PowerShell 5.0 with it.

PowerShell 5.0 is the newest version of Microsoft's scripting language for managing enterprise software products. It will be most notable, perhaps, for adding security perks for IT pros. PowerShell 5.0's distribution vehicle, WMF 5.0, actually was released in late December, but Microsoft pulled it after discovering a flaw that resets PowerShell module environmental variables. This flaw was fixed last month, but Microsoft is still testing the updated WMF 5.0 product prior to another RTM release, per a February update to this PowerShell team blog post.

Update 2/24: Microsoft rereleased WMF 5.0, according to a PowerShell team blog update today. It's available at the Microsoft Download Center here, but it bears a release date of Jan. 12, which is kind of confusing. Install details are described in this blog post.

Microsoft's "RTM" milestone signifies that the company deems the software OK for commercial use in production environments. However, Microsoft fudged that distinction with WMF 5.0 early on by describing a September release as a "production preview." Clearly, fortune favored the cautious in that case, given that Microsoft later pulled the WMF 5.0 RTM.

PowerShell Security Hole
PowerShell 5.0 will be a key upgrade because of promised security benefits. It turns out that older PowerShell versions can serve as a nasty security hole for organizations. And the problems could go unnoticed.

PowerShell is a potential security liability for organizations because it's possible to execute scripts in memory. An attacker doesn't need to use hard disk space to carry out exploits, which means that it's harder to detect attacks. Earlier PowerShell versions don't have the same logging capabilities for detecting attacks as the emerging PowerShell 5.0 solution. These security concepts are well explained in a February blog post, "Detecting Offensive PowerShell Attack Tools," by Sean Metcalf, a Microsoft Certified Master for Directory Services (Active Directory).

"PowerShell Version 5 (v5) greatly improves the defensive posture of PowerShell and when run on a Windows 10 system, PowerShell attack capability is greatly reduced," Metcalf wrote.

Metcalf offers tips to lock down PowerShell somewhat. While it's possible to constrain PowerShell's access to Windows APIs and COM functions, PowerShell 5.0 also will make such lockdowns difficult to bypass. He suggested combining PowerShell 5.0 with Microsoft's AppLocker application white-listing solution to prevent attackers from executing binaries.

"PowerShell v5 detects when AppLocker Allow mode is in effect and sets the PowerShell language to Constrained Mode, severely limiting the attack surface on the system," Metcalf wrote. "With AppLocker in Allow mode and PowerShell running in Constrained Mode, it is not possible for an attacker to change the PowerShell language mode to full in order to run attack tools."

All PowerShell activity should be logged to detect attacks, although it can take up a lot of disk space (around 1 GB). Microsoft started enabling PowerShell logging capabilities with version 3.0. It added additional log support with PowerShell 4.0.

The newer PowerShell versions support three types of logging. First there's module logging, which "records pipeline execution details." The module logging capability has been available since PowerShell 3.0, a February FireEye blog post explained. Next there's script block logging, which shows "blocks of code as they are executed by the PowerShell engine." Script block logging isn't available in PowerShell 4.0, according to FireEye. Lastly, transcription logging shows "all input and output" in a session, but it only shows what was typed in the terminal. It doesn't show "executed scripts or output written to other destinations such as the file system," FireEye explained.

PowerShell 5.0 adds a script block logging capability by default. Script block logging will show "de-obfuscated PowerShell code to the event log," Metcalf wrote. It will allow IT pros to see the attack code that was run, he explained.

PowerShell 5.0 also supports system-wide transcripts. They show "every PowerShell command and code block executed on a system by every user on that system," Metcalf said, and the information can be fed into security analysis tools, he added.

While logging improvements are coming in PowerShell 5.0, some of them have been brought back to PowerShell 4.0, according to the FireEye blog post.

"The current General Availability release of PowerShell for pre-Windows 10 systems is version 4.0, due to a recall of version 5.0," the FireEye blog stated. "However, Microsoft back-ported several useful security features from version 5.0 to 4.0 in a series of optional updates."

It's not exactly clear what was backported, though, from the blog post.

PowerShell's enhanced reporting capabilities are supported on Windows 10 without additional software updates. Older Windows client and server versions can get enhanced logging capabilities if a computing environment meets certain requirements, which includes having WMF 4.0 and .NET Framework 4.5 installed, among others, according to FireEye.

PowerShell Script Analyzer
In other Windows PowerShell news this month, Microsoft announced that it has released PSScriptAnalyzer 1.4.0. It's not a security tool, though. It's a static code analysis tool designed to help scripters with common issues. It compares code with PowerShell rules as well as Microsoft's best practices, for instance.

This PSScriptAnalyzer 1.4.0 release is notable by adding script analysis support for Windows PowerShell 3.0 and later versions. Microsoft's announcement also indicated that "Windows Management Framework (WMF) 5.0 is no longer a dependency to use ScriptAnalyzer."

And that's a good thing, since WMF 5.0 was still unavailable at print time.