In this article, we will review how to bypass the UMCI enforcement. In what we have seen in Part 1, Bypass logics is similar to changing the mode from a Constrained to a Full Language state to execute all elements of the PowerShell Language. Other ways would be to bypass the restrictions enforced by the Constrained Language Mode.
PowerShell Downgrade Attack
The PowerShell Downgrade attack is a straightforward code execution to modify the configs like changing the Language Mode from a Constrained to a Full Language Mode. For this technique to work, the PowerShell v2 needs to be enabled as illustrated in the screenshot below:
Once this has been accomplished, the initial PowerShell language is in Full mode, and then we change it back to a Constrained state. After that, a shell is then opened using v2, and then the Language mode is again set to Full. This means that if a Cyber attacker can turn on the feature of v2, the full language mode can be easily obtained using the method as illustrated below:
Revisiting: CVE-2017-8715 & CVE-2017-0218
In Part 1, we reviewed the Constrained Language Mode Restriction. One of them was a restricted cmdlet Add-Type. It was also discussed how such functions could be used which have been explicitly exported by the modules. Now, imagine a scenario where a Cyber attacker can use the exported functions of a signed MS PowerShell script to execute and launch an arbitrary code. Before the official fix known as “CVE-2017-0218”, it was possible to execute the arbitrary code from a signed MS PowerShell script. After the fix, Microsoft imposed further restrictions, such as when a Constrained Language Mode (CLM) was no longer able to import scripts. To counter the renaming of scripts from .ps1 to .psm1, another restriction was imposed. This allowed for the ability to import those modules that were exported by using the Export-ModuleMember technique. The restriction mentioned above was bypassed using the PowerShell Module Manifest(.PSD1). This contains the information about the Powershell script such as author, load type, file type, etc. The interesting feature of these manifest files is that the functions which need to be exported can be explicitly defined using the element “FunctionsToExport.” It specifies the function that can be exported and even those wildcards that are supported. PSD1 files are not required to be signed as .ps1 and. psm1 and thus can be dropped to the top-level directory which contains the module to expose those functions. Microsoft later imposed restrictions on .PSD1 files as well to be signed for the allowed. psm1 files. More details about this technique can be found here.
Revisiting CVE-2017-0007
When the PowerShell session is in the Constrained Language Mode (CLM), a lot of restrictions are imposed. For example, if the Device Guard policy is enforced, then only the signed MS binaries can run. However, it is the code (wintrust.dll) that checks whether the binary is signed or not. This is what CVE-2017-0007 is all about. It was discovered that the wintrust.dll file never performs validation checks on the error code returned if the file integrity is compromised. How is this possible? Authenticode signatures can be extracted from the signed files and then copied over to the custom .ps1 files. The content of a signed binary is replaced with custom content, keeping the Signature block intact. It is important to note that the digital signature cannot be verified, but the error that is returned is never handled by the wintrust.dll. This allows for custom scripts to be run which can execute any arbitrary code on the machine. This is even though the Device Guard and Constrained Language Mode are in full enforcement mode. More details about CVE-2017-0007 can be found here. So far, three separate techniques have been examined, but this is by no means an exhaustive list. There are many more techniques which have been discovered in the past to bypass enforced Device Guard policies and Constrained Language Mode. The good news is that Microsoft is very active in fixing these kinds of bugs and is not shy about introducing new features which really make PowerShell a great tool to use Pen Testing applications.
