Research

The fourth horseman: CVE-2019-0797 vulnerability

In February 2019, our Automatic Exploit Prevention (AEP) systems detected an attempt to exploit a vulnerability in the Microsoft Windows operating system. Further analysis of this event led to us discovering a zero-day vulnerability in win32k.sys. We reported it to Microsoft on February 22, 2019. The company confirmed the vulnerability and assigned it CVE-2019-0797. Microsoft have just released a patch, crediting Kaspersky Lab researchers Vasiliy Berdnikov and Boris Larin with the discovery:

This is the fourth consecutive exploited Local Privilege Escalation vulnerability in Windows we have discovered recently using our technologies. Just like with CVE-2018-8589, we believe this exploit is used by several threat actors including, but possibly not limited to, FruityArmor and SandCat. While FruityArmor is known to have used zero-days before, SandCat is a new APT we discovered only recently. In addition to CVE-2019-0797 and CHAINSHOT, SandCat also uses the FinFisher/FinSpy framework.

Kaspersky Lab products detected this exploit proactively through the following technologies:

  1. Behavioral detection engine and Automatic Exploit Prevention for endpoint products;
  2. Advanced Sandboxing and Anti Malware engine for Kaspersky Anti Targeted Attack Platform (KATA).

Kaspersky Lab verdicts for the artifacts used in this and related attacks are:

  • HEUR:Exploit.Win32.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

Brief technical details – CVE-2019-0797

CVE-2019-0797 is a race condition that is present in the win32k driver due to a lack of proper synchronization between undocumented syscalls NtDCompositionDiscardFrame and NtDCompositionDestroyConnection. The vulnerable code can be observed below on screenshots made on an up-to-date system during initial analysis:

Snippet of NtDCompositionDiscardFrame syscall (Windows 8.1)

On this screenshot with the simplified logic of the NtDCompositionDiscardFrame syscall you can see that this code acquires a lock that is related to frame operations in the structure DirectComposition::CConnection and tries to find a frame that corresponds to a given id and will eventually call a free on it. The problem with this can be observed on the second screenshot:

Snippet of NtDCompositionDestroyConnection syscall inner function (Windows 8.1)

On this screenshot with the simplified logic of the function DiscardAllCompositionFrames that is called from within the NtDCompositionDestroyConnection syscall you can see that it does not acquire the necessary lock and calls the function DiscardAllCompositionFrames that will release all allocated frames. The problem lies in the fact that when the syscalls NtDCompositionDiscardFrame and NtDCompositionDestroyConnection are executed simultaneously, the function DiscardAllCompositionFrames may be executed at a time when the NtDCompositionDiscardFrame syscall is already looking for a frame to release or has already found it. This condition leads to a use-after-free scenario.

Interestingly, this is the third race condition zero-day exploit used by the same group in addition to CVE-2018-8589 and CVE-2018-8611.

Stop execution if module file name contains substring “chrome.exe”

The exploit that was found in the wild was targeting 64-bit operating systems in the range from Windows 8 to Windows 10 build 15063. The exploitation process for all those operating systems does not differ greatly and is performed using heap spraying palettes and accelerator tables with the use of GdiSharedHandleTable and gSharedInfo to leak their kernel addresses. In exploitation of Windows 10 build 14393 and higher windows are used instead of palettes. Besides that, that exploit performs a check on whether it’s running from Google Chrome and stops execution if it is because vulnerability CVE-2019-0797 can’t be exploited within a sandbox.

The fourth horseman: CVE-2019-0797 vulnerability

Your email address will not be published. Required fields are marked *

 

Reports

Lazarus targets defense industry with ThreatNeedle

In mid-2020, we realized that Lazarus was launching attacks on the defense industry using the ThreatNeedle cluster, an advanced malware cluster of Manuscrypt (a.k.a. NukeSped). While investigating this activity, we were able to observe the complete life cycle of an attack, uncovering more technical details and links to the group’s other campaigns.

Sunburst backdoor – code overlaps with Kazuar

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Our observations shows that Kazuar was used together with Turla tools during multiple breaches in past years.

Lazarus covets COVID-19-related intelligence

As the COVID-19 crisis grinds on, some threat actors are trying to speed up vaccine development by any means available. We have found evidence that the Lazarus group is going after intelligence that could help these efforts by attacking entities related to COVID-19 research.

Sunburst: connecting the dots in the DNS requests

We matched private and public DNS data for the SUNBURST-malware root C2 domain with the CNAME records, to identify who was targeted for further exploitation. In total, we analyzed 1722 DNS records, leading to 1026 unique target name parts and 964 unique UIDs.

Subscribe to our weekly e-mails

The hottest research right in your inbox