New Attacks to Disable and Bypass Windows Management Instrumentation [LABSCon Edition]

In a previous blog covering one of Binarly’s presentations at the Black Hat 2022 conference, we discussed in detail our research on attacks that disable Windows Management Instrumentation (WMI) and blind an entire class of endpoint security solutions. We introduced a template for attacks, dubbed ‘one-bit change attack’, on objects residing inside the WMI service address space. We also demonstrated another way to disable WMI by isolating the WMI service from the rest of the operating system through a sandboxing attack.

As a follow-up to that research, Binarly co-founders Alex Matrosov and Claudiu Teodorescu took the stage at the inaugural LABScon 2022 to call industry attention to a new batch of high-impact security vulnerabilities affecting tens of millions of computer devices.

During the first presentation, titled “Breaking through the Pre-EFI”, Matrosov presented the details of seven (7) new serious vulnerabilities affecting Insyde reference code, a direct implication of the complexity of the firmware development ecosystem resulting in repeatable failures.

Binarly’s second LABScon talk, titled “Blasting Event-Driven Cornucopia: WMI Edition,” presented by Teodorescu, introduced new ways to disable the WMI mechanism used by existing security technologies to monitor endpoints for signs of malicious attacks. Another topic covered in the talk was how OEM Manufacturers leverage WMI for firmware policy orchestration thus extending the attack surface to allow threat actors to influence the BIOS settings from userland.

Firmware Policy Orchestration via WMI

In the aforementioned blog, we detailed how to forensically parse the WMI database (CIM repository) to extract the class definitions and the corresponding persistent objects. We showed an example how to forensically parse the class definitions from a WMI namespace (root\wmi) on a Lenovo device to identify several interesting classes related to the system BIOS configuration. The hierarchy of Lenovo WMI classes is presented below:

As can be seen, there are four base classes and a number of setter and getter derived classes related to the system BIOS such as Lenovo_SetBiosSetting and its corresponding Lenovo_BiosSetting, Lenovo_SetBiosPassword and its corresponding Lenovo_BiosPasswordSettings.

Instances of these classes are not represented as persistent WMI objects in the CIM repository. They are created, on the fly, by a WMI provider implemented by the OEM vendor. Leveraging PowerShell, we can read the non-empty instance of the Lenovo_BiosSetting class property CurrentSetting that provides insight into the settings related to trusted execution(TXT), Trusted Platform Module (TPM), BIOS update:

Lenovo provides an interface, below the OS, to allow the custom WMI Provider to interact with the firmware layer to read and alter those settings from userland.

At OffensiveCon 2019, in his presentation “Attacking Hardware Root Of Trust from UEFI Firmware”, Matrosov provided a simple VBScript to demonstrate how to change the BIOS password leveraging the aforementioned Lenovo_SetBiosPassword WMI Class and the vendor implemented WMI Provider.

Digging deeper into the details presented at OffensiveCon 2019, there are two firmware modules -- LenovoSetupUnderOSDxe and LenovoSetupUnderOSSmm -- that implement the interface the Lenovo WMI provider is leveraging to perform the firmware policy orchestration from userland:

This is a great feature for enterprise management and BIOS policy orchestration, but exposing such functionality to alter these settings from userland is very dangerous.

In the last firmware update from Lenovo (September 2022),  fixes for two important CVEs with industry-wide impact are included.

Those two CVEs identify two vulnerabilities in the SMI Handler implementation of the interface that the Lenovo WMI provider is leveraging. The CVE-2022-40137 is a classical buffer overflow while CVE-2022-40134 is an information leak vulnerability in the SMI Handler that the aforementioned WMI provider is calling to populate the Lenovo_SetBIOSPassword WMI class instances.

Attacks on WMI to blind Security Solutions - Advanced Local Procedure Call (ALPC) communication channels

WMI Service process communicates with providers, consumer clients and the services.exe via Advanced Local Procedure Calls (ALPC) communication channels. In the WMI Threat model presented by Binarly, attacking the ALPC communication channels is one of the ways to disable WMI without triggering any security alert.

The following WMI user-mode components are targeted in this attack:

• WMI service “Winmgmt” which is running as a SVCHost process,
• WMI clients that consume WMI events,
• services.exe that communicates directly with the WMI service.

These processes communicate with each other using the ALPC mechanism:

• services.exe creates the server connection port named  “\netsvcs” and receives a connection request from the WMI service.
• After the request for connection was accepted by services.exe, the WMI service receives a handle to the client communication port while services.exe receives a handle to the server communication port thus the ALPC communication channel is established
• WMI service creates the named server connection port with the prefix “\RPC Control\OLE*” and receives a connection request from a WMI client.
• After the request for connection was accepted by the WMI service, the WMI client receives a handle to the client communication port while WMI service receives a handle to the server communication port thus the ALPC communication channel is established

As a result of the previous steps, WMI events from WMI providers are transferred to the connected WMI clients using these established ALPC communication channels.

Based on the previous diagram, two ways to attack the WMI ALPC communication channels are identified:

• Attack on the handle to the ALPC client communication port (WMI Consumer side)
• Attack on the handle to the ALPC server communication port (WinMgmt service side)

Attack on the ALPC client communication port

An attacker’s application can blind the targeted WMI client consumer by closing the handle to the ALPC client communication port as depicted below:

As a result of such an attack, the targeted WMI client stops receiving new events. The same WMI client can reestablish the ALPC connection or relaunch itself, but the attacker application can act as a watchdog and close the handle to the ALPC client communication port again.

A demo that showcases this attack can be found on the Binarly YouTube channel.

Attack on the ALPC server communication port

An attacker application closes the handle to the ALPC server communication port inside the WMI service (WinMgmt).

As a result of such an attack, all attempts from clients to connect to the WMI service fail with the error code 0x800706BF. WMI service can be relaunched, but an attacker can close the server side handle again.

A demo that showcases this attack can be found on the Binarly YouTube channel.

Conclusion

The new attacks presented at LABScon prove once again that the WMI service doesn’t have any protection mechanisms, thus the WMI event delivery can easily be disabled by attackers without triggering any security warnings. In this case, simply closing a handle will disable WMI event distribution for a targeted WMI consumer or for all of them.

These latest attack vectors as well as the other ones introduced previously can originate in the firmware -- a big blind spot for endpoint security solutions -- to achieve persistence across different versions of Windows and survive OS reinstallations. Publicly known firmware threats have persisted for a very long time without being detected by the endpoint security solutions which gave attackers plenty of time to influence the device telemetry coming from multiple data points, including WMI.

At EkoParty 2022, we will advance our research on disabling WMI and introduce several new attacks on objects inside WMI service, ALPC communication channels and sandboxing the winmgmt service using DKOM attack.