Quote:

In November 2019, Kaspersky technologies successfully detected a Google Chrome 0-day exploit that was used in Operation WizardOpium attacks. During our investigation, we discovered that yet another 0-day exploit was used in those attacks. The exploit for Google Chrome embeds a 0-day EoP exploit (CVE-2019-1458) that is used to gain higher privileges on the infected machine as well as escaping the Chrome process sandbox. The exploit is very similar to those developed by the prolific 0-day developer known as ‘Volodya’.

The EoP exploit consists of two stages: a tiny PE loader and the actual exploit. After achieving a read/write primitive in the renderer process of the browser through vulnerable JS code, the PE exploit corrupts some pointers in memory to redirect code execution to the PE loader. This is done to bypass sandbox restrictions because the PE exploit cannot simply start a new process using native WinAPI functions.

The PE loader locates an embedded DLL file with the actual exploit and repeats the same process as the native Windows PE loader – parsing PE headers, handling imports/exports, etc. After that, a code execution is redirected to the entry point of the DLL – the DllEntryPoint function. The PE code then creates a new thread, which is an entry point for the exploit itself, and the main thread simply waits until it stops.

The compilation timestamp of Wed Jul 10 00:50:48 2019 is different from the other binaries, indicating it has been in use for some time.

Our detailed analysis of the EoP exploit revealed that the vulnerability it used belongs to the win32k.sys driver and that the EoP exploit was the 0-day exploit because it works on the latest (patched) versions of Windows 7 and even on a few builds of Windows 10 (new Windows 10 builds are not affected because they implement measures that prevent the normal usage of the exploitable code).

The vulnerability itself is related to windows switching functionality (for example, the one triggered using the Alt-Tab key combination). That’s why the exploit’s code uses a few WinAPI calls (GetKeyState/SetKeyState) to emulate a key press operation.

At the beginning, the exploit tries to find the operating system version using ntdll.dll’s RtlGetVersion call that’s used to find a dozen offsets needed to set up fake kernel GDI objects in the memory. At the same time, it tries to leak a few kernel pointers using well-known techniques to leak kernel memory addresses (gSharedInfo, PEB’s GdiSharedHandleTable). After that, it tries to create a special memory layout with holes in the heap using many calls to CreateAcceleratorTable/DestroyAcceleratorTable. Then a bunch of calls to CreateBitmap are performed, the addresses to which are leaked using a handle table array.

After that, a few pop-up windows are created and an undocumented syscall NtUserMessageCall is called using their window handles. In addition, it creates a special window with the class of a task switch window (#32771) and it’s important to trigger an exploitable code path in the driver. At this step the exploit tries to emulate the Alt key and then using a call to SetBitmapBits it crafts a GDI object which contains a controllable pointer value that is used later in the kernel driver’s code (win32k!DrawSwitchWndHilite) after the exploit issues a second undocumented call to the syscall (NtUserMessageCall). That’s how it gets an arbitrary kernel read/write primitive.

This primitive is then used to perform privilege escalation on the target system. It’s done by overwriting a token in the EPROCESS structure of the current process using the token value for an existing system driver process.

Kaspersky products detect this exploit with the verdict PDM:Exploit.Win32.Generic.
These kinds of threats can also be detected with our Sandbox technology. This detection component is a part of our KATA and Kaspersky Sandbox products. In this particular attack sandbox solution can analyze URL/malicious payload in isolated environment and detect the EPROCESS token manipulation.
...