Against DeviceGuard: in-depth analysis of the CVE-2017-0007-vulnerability warning-the black bar safety net

Over the past few months, I’m happy and Matt Graeber and Casey Smith together with the study Device Guard user-mode integrity UMCI around it. If you are not familiar with Device Guard, you can read: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/device-guard-deployment-guide the. In short, the Device Guard UMCI prevents unauthorized binary execution, limiting the Windows Scripting Host, and PowerShell placed in restricted language mode, unless the script by a trusted signer’s signature. In the spend some time researching Device Guard to start the system how to process the script, I eventually determined a method to perform any unauthorized script. Problem reported to MSRC, this bug is labeled CVE-2017-0007, and patch repair. This particular bug only affects PowerShell and Windows Scripting Host, will not affect the compiled code.
0x01 analysis
When performing a signed script, wintrust. dll processing file signature verification. Ideally, if you will be a Microsoft signature script modifications, the integrity of the file will be broken ring, and the signature is no longer reliable. This is the authentication for the Device Guard is important, its sole purpose is to block unsigned or untrusted code to run. CVE-2017-0007 circumvent this protection, allows you to by simply modifying the previously obtained trusted signed scripts to run whatever you want unsigned code. In this case, you can select a Microsoft signature script, because Microsoft signed code need to run on the Device Guard. For example, if we try to run unsigned PowerShell scripts to perform the restricted acts, such as most of the COM instantiation, since the PowerShell restricted language mode will fail. Any signature and trusted PowerShell code through the deployment of a code integrity policy approved in FullLanguage mode operation, the implementation without any restrictions. In this case, our code is not signed or trusted, therefore in restricted language mode, the execution failed.
! [](/Article/UploadPic/2017-4/20174119750178. png? www. myhack58. com)
Fortunately, Microsoft’s scripts with their code signing certificate signature. You can use sigcheck or PowerShell cmdlet “Get-AuthenticodeSignature“verify that the script actually consists of Microsoft signature. In this case, I grab from the Windows SDK in a signed PowerShell script, rename it to”MicrosoftSigned. ps1“:
! [](/Article/UploadPic/2017-4/20174119750537. png? www. myhack58. com)
When these scripts are signed, they are often in the script body contains an embedded authentication code signature. If you modify a file of any content, file integrity will be broken ring, and the signature is no longer reliable. You can also be simple from a signature file, copy the authentication code for the certificate, and paste to an unsigned script:
! [](/Article/UploadPic/2017-4/20174119751640. png? www. myhack58. com)
As you can see, the script of the original content with our own code to replace, and verify the signature, the result is“the object of the digital signature cannot be verified“, means that the file integrity has been broken ring, the code will be blocked from running, right?
! [](/Article/UploadPic/2017-4/20174119751559. png? www. myhack58. com)
As you can see, our code is still executed, although the digital signature is not trusted. Microsoft will be this bug fixed CVE-2017-0007, classified as MS17-012’s. Here potential problem is to ensure that the integrity of the file function returns the error code has not been verified, resulting in the successful execution of the unsigned code.
So, what is this bug the reason, and how to be fixed? Device Guard relies on wintrust. the dll processing of the signature file the signature and integrity check. Use bindiff to compare the patch before 10.0.14393.0 and patch after 10.0.14393.953）的 wintrust.dll reveal the added code block. Wintrust. dll with a change, which is to verify the signature of the script only change. Due to this, the patch is as follows:
! [](/Article/UploadPic/2017-4/20174119751265. png? www. myhack58. com)
Look carefully, you can see sub_18002D0F8 some of the code is removed:
! [](/Article/UploadPic/2017-4/20174119751681. png? www. myhack58. com)
Look under the newly added sub_18002D104 of the code block, you will see it contains some from the sub_18002D0F8 code. These special functions no symbol, so we must refer to the defined name. Alternatively, you can also in IDA to rename these functions.
! [](/Article/UploadPic/2017-4/20174119751638. png? www. myhack58. com)
The above text is a bit small, but I will be in-depth analysis of specifically what has been done. I will not detail the use of bindiff, but if you want to learn more, you can refer to the manual. With the bug fixes of the position that I see is determining when our unsigned code execution what is happening. Learned in sub_18002D0F8 delete some code, and added a new block sub_18002D104, these two places are a good analytical starting point. First, 我在IDA中打开补丁前版本的wintrust.dll（10.0.14393.0, navigate to the modified sub_18002D0F8 it. This function consists of several variables to start, and then call the“SoftpubAuthenticode” in.
! [](/Article/UploadPic/2017-4/20174119751930. png? www. myhack58. com)
Look under“SoftpubAuthenticode”discloses that it calls another function”CheckValidSignature“: the
! [](/Article/UploadPic/2017-4/20174119751785. png? www. myhack58. com)
Obviously, the“CheckValidSignature”process to verify a file signature/integrity verification. Look at this function, we can get the return before the last execution of the position.

[1] [2] next