Here's The Solution For Using Edge With An Eset Product

[itman 1,659]

Morphisec Uncovers New Attack Vector Named CIGslip That Bypasses Microsoft Code Integrity Guard

Quote

Morphisec researchers Michael Gorelik and Andrey Diment have discovered CIGslip, a new method which can be exploited by attackers to bypass Microsoft’s Code Integrity Guard (CIG) and load malicious libraries into protected processes such as Microsoft Edge.

The new attack vector manipulates the way CIG works to circumvent its controls without any in-memory unsigned image codepage injection, a technique with serious destructive potential if becomes popular.

Morphisec disclosed the vulnerability details and proof of concept code to Microsoft as part of its Responsible Disclosure policy and has been available to assist with fixing the weakness. Microsoft responded that the new found technique that is to be outside the scope of CIG, as “CIG is designed to prevent a process with CIG enabled from being able to directly load an improperly signed image.”

Novel Method of Binary Injection – CIGslip

This proposed novel method for binary injection does not involve any injection of unsigned image code pages, and bypasses CIG while mimicking natural Windows dll loading from disk.

The basic assumption is that we have the ability to execute a non-protected CIG process on disk. This assumption holds since there is no feasible way to protect all processes with CIG (e.g. Outlook would not load). Moreover, a CIG protected process may execute a non-CIG protected process, which will do the backward injection back into the CIG protected process.

If the assumption holds, and we do have a control on a non-CIG protected process, we are only left with bypassing the CIG verification during the section create in the target process (this is the only time in which the OS verifies the dll signature). In order to detour the code integrity verification, we would need to hijack the control when the section is created within the targeted process.

Since section handles are global objects managed by Kernel, handles could be duplicated between processes. Therefore, a section that correlated to a non-signed dll could be created within the context of the malicious process and then duplicated into the target process.

In-order to inject malicious dll (“non-signed”) into a target process, all we need to do is to hook the createsection method within the target process, so that it will not go down to Kernel and will return the duplicated section handle. Following that, the targeted process will map the dll code page into its memory as part of a regular dll loading process, assuming that the section went through the appropriate verification process. Which it did, since createsection now returns an already existing verified section handle!

http://blog.morphisec.com/new-method-to-bypass-microsoft-cig