🔒
There are new articles available, click to refresh the page.
Before yesterdayZero Day Initiative - Blog

Looking at Patch Gap Vulnerabilities in the VMware ESXi TCP/IP Stack

27 July 2022 at 15:14

Over the last few years, multiple VMware ESXi remote, unauthenticated code execution vulnerabilities have been publicly disclosed. Some were also found to be exploited in the wild. Since these bugs were found in ESXi’s implementation of the SLP service, VMware provided workarounds to turn off the service. VMware also disabled the service by default starting with ESX 7.0 Update 2c. In this blog post, we explore another remotely reachable attack surface: ESXi’s TCP/IP stack implemented as a VMkernel module. The most interesting outcome of this analysis is that ESXi’s TCP/IP stack is based on FreeBSD 8.2 and does not include security patches for the vulnerabilities disclosed over the years since that release of FreeBSD.

This result also prompted us to analyze the nature of vulnerabilities disclosed in other open-source components used by VMware, such as OpenSLP and ISC-DHCP. Once again, we observed that most of the disclosed vulnerabilities had upstream patches before the disclosure.

The FreeBSD Code in the ESXi TCP/IP Stack

An initial analysis was done to locate the VMkernel module implementing the TCP/IP stack. In ESXi, the module details can be enumerated using esxcfg-info or esxcli system module commands as seen below:

Checking the function names and strings available in the module, it is understood that the code is coming from FreeBSD, as shown in the following:

While the exact version of FreeBSD was not initially known, comparing the binary against the patches mentioned in advisories revealed multiple missing fixes. I performed a manual diff of FreeBSD branches 8.x, 9.x, and 10.x against the VMkernel module to narrow down the version of code used. Consider a couple of MFC (Merge From CURRENT) commits for example: 213158 and 215207. The 213158 commit was merged to FreeBSD 8.2 and later, whereas 215207 was merged to FreeBSD 8.3 and later. While 213158 was found in the VMkernel module, the 215207 commit was missing. This gave an approximate timeline of when the code was forked, which is around FreeBSD 8.2.

Porting Type Information from FreeBSD to the ESXi VMkernel Module

Once the version of the FreeBSD source is known, we can port type information from FreeBSD 8.2 to the VMkernel module. The goal here was to make function prototype and structure information available in IDA. Since creating type libraries for multiple dependent headers can be complex, I decided to rely on the FreeBSD kernel binary compiled from source with DWARF information. My first choice was to use IDA Pro’s Dump typeinfo to IDC feature. However, there were still missing structures because only assembler-level types were exported to the IDC.

The workaround for the problem is to use the TILIB idea by @rolfrolles. Using the above-mentioned technique, it is possible to create a type library from the FreeBSD 8.2 kernel binary and then load it into the VMkernel module’s IDB. This imports all the C-level types required for further analysis with the decompiler. While the Structure and Local Types view does not list all imported type information, we can apply the function prototypes as detailed in a previous blog post.

As a recap, begin by extracting the function prototype from the FreeBSD kernel as a key value pair of function_name:function_type, then iterate through the extracted type information and apply it to the VMkernel module having symbols.

Once the prototypes are applied, the Structure and Local Types views are automatically populated. Any other types required for local variables can be further added manually using the workflow mentioned in Importing types into IDB.

Figure 1 - VMkernel module before (left) and after (right) adding FreeBSD type information

Analyzing VMkernel Debug Information from VMware Workbench

VMware Workbench is an Eclipse IDE plugin provided by VMware. Amongst many other features, it also provides debug symbols for VMkernel. Jan Harrie and Matthias Luft have documented the usage of the VMkernel debug information in their research entitled Attacking VMware NSX [Slides 34 – 37 in the PDF]. The UI of the Eclipse plugin is shown below:

Figure 2 - List of VMkernel debug symbols available in VMware Workbench

Kernel modules in ESXi communicate with VMkernel using VMK APIs. By using a VMkernel build that has debug information, it becomes easier to understand the VMK API calls made by any VMkernel module, which includes the TCP/IP stack. Moreover, the type information from VMkernel can be ported to any desired VMkernel module or even to the Virtual Machine Monitor. Here is an example of type information ported to the TCP/IP module found in ESXi 6.7 Update 3 using debug information from VMkernel version 14320388:

Figure 3 - TCP/IP module before (left) and after (right) adding VMkernel type information

As soon as the function prototypes are applied to the binary, IDA helpfully propagates the type information to many of the variables found in the code. When working with code forked from FreeBSD, it is useful to place the Hex-Rays decompilation side-by-side with known FreeBSD source code to rename variables and add type information to variables that IDA did not detect automatically . However, in this case, we do not have access to local variable names or types. While some variables are given meaningful names by IDA, the rest were manually added using context information from the detected enums, structure names, and so forth.

VMware seems to have stopped publishing VMkernel debug information for more than a year now. The last public release for which I could find the debug information goes back to ESXi 6.7 16773714.

Missing FreeBSD Patches

At this point, we had enough information to perform a diff of the TCP/IP VMkernel module against the FreeBSD security advisories. Patches provided in the advisories were compared against ESXi’s version of the module to identify the missing bug fixes. Based on static analysis, patches for 16 vulnerabilities fixed in FreeBSD were found to be missing in ESXi. We reported these missing patches to VMware for further evaluation.  Shown below is the set of missing patches that we reported to VMware and their corresponding applicability to ESXi as evaluated by VMware:

CVE Disclosure Date Bug Applicable
CVE-2013-3077 8/22/13 Integer overflow in IP_MSFILTER Yes
CVE-2013-5691 9/10/13 Insufficient credential checks in network IOCTL No
CVE-2004-0230 9/16/14 Denial of Service in TCP packet processing Yes
CVE-2015-1414 2/25/15 Integer overflow in IGMP protocol Yes
CVE-2015-2923 4/7/15 Denial of Service with IPv6 Router Advertisements Yes
CVE-2015-5358 7/21/15 Resource exhaustion due to sessions stuck in LAST_ACK state Yes
CVE-2015-1417 7/28/15 Resource exhaustion in TCP reassembly No
CVE-2018-6916 3/7/18 IPSec validation and use-after-free Yes
CVE-2018-6918 4/4/18 IPSec crash or denial of service Yes
CVE-2018-6922 8/6/18 Resource exhaustion in TCP reassembly No
CVE-2018-6923 8/14/18 Resource exhaustion in IP fragment reassembly No
CVE-2019-5608 8/6/19 ICMPv6 / MLDv2 out-of-bounds memory access Yes
CVE-2019-5611 8/20/19 IPv6 remote Denial-of-Service Yes
CVE-2020-7451 3/19/20 TCP IPv6 SYN cache kernel information disclosure Yes
CVE-2020-7457 7/8/20 IPv6 socket option race condition and use after free Yes
CVE-2020-7469 12/1/20 ICMPv6 use-after-free in error message handling Yes

These issues were addressed in ESXi 7.0 Update 3f as well as ESXi 6.5 and ESXi 6.7.

Analysis of OpenSLP in ESXi  

The next component considered for analysis is the SLPD service in ESXi. ESXi’s SLP service is a fork of OpenSLP version 1.0.0. The version information and build configuration details can be fetched as below:

Just like the VMkernel modules, the SLPD service executable has symbols but not type information. Using the available function names, we observed that VMware’s forked code is not entirely based on version 1.0.0. It also has some of the functions added later, including some from version 2.0.0. There are also differences in some of the structure definitions as well as function prototypes. These observations can be made as soon as you port type information from OpenSLP and certain functions won’t decompile cleanly.

To fetch the type information, build OpenSLP from source and then use IDA Pro’s Create C header + Parse C header feature to populate the local types. The C header parses without much error. This is a quick workaround compared to creating type libraries from multiple dependent headers. Note that ESXi versions 7.0 and above run the SLPD service as a 64-bit executable. Because of this, care must be taken while using the created C header interchangeably between ESXi 7.0 and other versions. This is especially true as the header may require some modifications on data sizes, such as size_t being unsigned int vs unsigned long long.

Timeline of Upstream Patches vs Disclosures:

In the case of OpenSLP, there is enough public information regarding the vulnerabilities affecting ESXi and their relevant upstream patches, most notable being the one published by Lucas Leong on CVE-2020-3992 and CVE-2021-21974. For the scope of this blog, we will consider the following set of remote code execution vulnerabilities:

CVE VMSA Bug
CVE-2015-5177 VMSA-2015-0007 Double Free
CVE-2019-5544 VMSA-2019-0022 Heap Overflow
CVE-2020-3992 VMSA-2020-0023 Use-After-Free
CVE-2021-21974 VMSA-2021-0002 Heap Overflow

CVE-2015-5177 is a double-free vulnerability that occurs when processing a message buffer across functions: SLPDProcessMessage, ProcessDAAdvert, and SLPDKnownDAAdd. An upstream patch to fix the issue in SLPDKnownDAAdd() was already available.

Similarly, CVE-2020-3992 is a use-after-free vulnerability, again found in the handling of message buffer across functions SLPDProcessMessage, ProcessDAAdvert, and SLPDKnownDAAdd. However, this vulnerability does not affect the upstream version of OpenSLP. This bug can be traced back to CVE-2015-5177 based on the information provided in VMSA.

VMware released updates in the form of the VIB (vSphere Installation Bundle). Installing the VIBs one by one on ESXi to perform patch diffing of SLPD binary can be a tedious process. Instead, binaries can be directly extracted from the VIB to speed up the process. The relevant VIBs can be downloaded from the ESXi Patch Tracker, which lists them based on the timeline of release. Consider a diff between ESXi 6.7 build 8169922 and 8941472:

Figure 4 - ESXi Patch Tracker with VIBs

To replicate this, download the esx-base VIB to extract the slpd binary using the vmtar utility. The vmtar utility can be copied from ESXi and executed in Ubuntu since it does not have any ESXi-specific dependencies:

Similarly, in the case of the ESXi 6.7 GA ISO image, extract the S.V00 file from VMware-VMvisor-Installer-6.7.0-8169922.x86_64.iso:

A patch diff between slpd binaries confirms that CVE-2020-3992 was introduced when patching CVE-2015-5177 in ESXi versions 6.0 and above. The fix for CVE-2015-5177, in this case, was different from that of the working upstream fix in SLPDKnownDAAdd():

Figure 5 - Bindiff between ESXi 6.7.0 8169922 and 8941472

CVE-2020-3992 was in fact fixed twice (VMSA-2020-0023.1) since the initial patch did not completely address the issue. Additionally, this bug was also reported to be exploited in the wild by the Cybersecurity and Infrastructure Security Agency (CISA).

CVE-2021-21974, a heap overflow in SLPParseSrvUrl() leading to RCE, also had an upstream patch. This fix was part of a large code change in OpenSLP.

CVE-2019-5544 was the only bug that affected both the upstream and the VMware fork of OpenSLP at the time of disclosure. Though the bug has already been disclosed and fixed by many distros, the patch for this bug is still missing in the OpenSLP GitHub repository. This was another bug exploited in the wild.

Putting it all together, here is the timeline of disclosure vs availability of patches:

CVE Disclosure Date Patch Availability Patches
CVE-2015-5177 10/1/15 6/8/11 53bbd77
CVE-2019-5544 12/5/19 N/A N/A
CVE-2020-3992 10/20/20 6/8/11 53bbd77
CVE-2021-21974 2/23/21 3/1/06 3c8e45d

Analysis of ISC-DHCP in Workstation

The next component considered for analysis is the DHCP service of VMware Workstation, which is based on ISC-DHCP version 2.0. You can refer to the blog post Wandering through the Shady Corners of VMware Workstation/Fusion for an earlier analysis of this attack surface. It is noted that, though the codebase is a couple of decades old, VMware has backported fixes for known vulnerabilities. Keeping this in mind, only the recently disclosed bugs, CVE-2019-5540 and CVE-2020-3947, were analyzed.

Unlike earlier analysis where the executables had symbols, the vmnet-dhcp is completely stripped. The first task is to identify as many function names as possible to carry out the analysis. Looking for binaries with symbols led us to the very first release – VMware 1.0 Build 160. The vmnet-dhcpd binary from the first release of VMware had symbols and type information in stabs format.

For matching the available symbols with recent releases of the Workstation DHCP server, I relied on the updated version of Rizzo published by Quarkslab. Since Rizzo can be very slow on large binaries, only the string reference signatures were used in detection. With this, Rizzo identified around 69 functions using 226 matching strings available in VMware 1.0 Build 160 vmnet-dhcpd binary. A somewhat similar result can be achieved using the strings in ISC-DHCP 2.0. For anyone interested, the historical releases of ISC-DHCP can be found here.

During the patch diffing process, bug fixes in vmnet-dhcpd are easy to spot since the binary undergoes very limited changes per release. The first bug, CVE-2019-5540, is an information disclosure vulnerability due to an uninitialized field in the ICMP packet structure. This issue can be narrowed down to an upstream patch in the function icmp_echorequest().

The next bug, CVE-2020-3947, is a use-after-free vulnerability when handling the DHCPRELEASE packet. During the handling of a DHCPDISCOVER packet from a client, ISC-DHCP allocates memory in the heap. If the client identifier is long, it stores the resultant pointer as part of the lease structure. Otherwise, uid_buf is used for storage. The relevant code can be found in the ack_lease function of the server/dhcp.c source file:

Later when a DHCPRELEASE packet is received, the lease structure is adjusted. First, a copy of lease is made in the function release_lease and then supersede_lease is called. This code can be found in common/memory.c:

Note that the uid pointer is now found in both the old and the newly copied lease structures when it is passed to supersede_lease. In supersede_lease, the comp->uid pointer is freed (provided that it points to memory other than uid_buf, that is, in the case of a long client identifier):

Later, lease->uid entry is reused. See the code below assigning comp -> uid = lease -> uid, which by this time points to freed memory:

Finally, the comp structure that has a pointer to the freed uid buffer is passed to write_lease where the use-after-free happens. The bug can be triggered by adding a long dhcp-client-identifier entry to the DHCP client configuration and then initiating a DHCP request followed by a DHCP release using dhclient:

This issue was fixed in the release_lease function as part of a bigger code change by introducing a lease_copy function. The copied lease structure no longer holds a reference to the uid buffer of the old lease. Instead, a new allocation is requested and assigned. The release_lease function received further changes during later updates for handling the failover protocol. VMware’s fix for this bug is different from that of the upstream, possibly due to the divergence of the codebase.

Here is the timeline of disclosure vs availability of patches:

CVE Disclosure Date Patch Availability Patches
CVE-2019-5540 11/12/19 6/25/98 34436cc
CVE-2020-3947 3/12/20 5/17/00 20916ca

The IDA Python scripts used for the analysis can be found here.

Conclusion

Over the last few months, we analyzed three different VMware components: the ESXi networking stack, the ESXi SLPD service, and the Workstation DHCP server. The three components share the fact that they are forks of open-source code. Unlike open-source packages that can be updated to a new version with relative ease, updating a fork takes significantly more effort. This is because various challenges arise when cherry-picking patch commits.

In the ESXi FreeBSD networking stack, even the vulnerabilities with known CVE identifiers remained unfixed – the forked code was never tracked for vulnerabilities. Better tracking of FreeBSD disclosures is a good place to start and can help resolve some of the issues. Also, considering the criticality of the component, it might be possible for VMware to work with FreeBSD Security Officers to get prior information on vulnerabilities as per their Information handling policies:

The FreeBSD Security Officer has close working relationships with a number of other organizations, including third-party vendors that share code with FreeBSD…..Frequently vulnerabilities may extend beyond the scope of the FreeBSD implementation, and (perhaps less frequently) may have broad implications for the global networking community. Under such circumstances, the Security Officer may wish to disclose vulnerability information to these other organizations.”

In most cases, vendor advisories only list the supported versions of the affected software. Even if a legacy version is not listed in the advisory, the patch might still be applicable for the forked code.

In the case of OpenSLP and ISC-DHCP forks, the patch gap vulnerabilities come from bugs that do not have CVE identifiers. Some of the bug fixes have clear commit messages about the issue, whereas other fixes are done as part of large code changes or refactoring. Either way, it is a challenging process and requires a trained set of eyes to pick up security patches when the vulnerabilities are not explicitly called out. This also shows the significance of requesting CVE identifiers for security fixes since companies largely rely on them for cherry-picking patches.

As we showed, a couple of ESXi SLP patches had further issues despite the availability of working upstream fixes. To avoid this, it is important to evaluate a bug report not just against the fork but also against the upstream project. If a fix is found, developers should evaluate the upstream fix. Upstream fixes in most cases are a safe bet compared to that of custom patches, which may be written without having a comprehensive understanding of the code. However, this process of adopting patches can be further complicated if the codebases have diverged considerably.

The most important concern with forked code is the lifetime of bugs. When open-source code is used and updated as a package to the latest version, all the bug fixes are applied (i.e., vulnerabilities with or without CVE identifiers). In a forked codebase, when a patch is missed during cherry-picking, it will remain unfixed until the code is updated as a whole or someone finds and reports the issue. For example, the ISC-DHCP bugs were fixed in VMware’s DHCP server a couple of decades after the upstream fixes were available. In fact, the ISC-DHCP uninitialized memory information disclosure was fixed upstream even before the launch of CVE. Overall, forked code requires more attention compared to that of packages.

Considering the challenges of adopting security fixes and gaps in the tracking process, exploitable bugs might be still lying around without a fix. There are different types of patch gaps as well, so expect to hear more about these in the future. Until then, you can find me on Twitter @RenoRobertr, and follow the team for the latest in exploit techniques and security patches.

Looking at Patch Gap Vulnerabilities in the VMware ESXi TCP/IP Stack

Riding the InfoRail to Exploit Ivanti Avalanche

19 July 2022 at 13:59

Back in 2021, I stumbled upon a proof of concept describing an arbitrary file read vulnerability in the Ivanti Avalanche mobile device management tool. As I was not aware of this product, I decided to take a quick look at the vendor’s website to learn more:

“Avalanche Enterprise Mobile Device Management manages some of the most demanding, high-profile supply chain mobility solutions in the world. So, we understand the pressure you're under to maximize worker (and device) uptime.”

“Manage all mobile devices in one place. Smartphones, barcode scanners, wearables and more—configure, deploy, update, and maintain them all in one system.”

“30,000 organizations. Over 10 million devices.”

As the product specification seemed to be both intriguing and encouraging, I decided to give it a shot and look for some vulnerabilities.

I was able to quickly identify a chain of three vulnerabilities in the Ivanti Avalanche Web Application:

- ZDI-21-1298 (CVE-2021-42124): Session takeover vulnerability, which requires user interaction.
- ZDI-21-1300 (CVE-2021-42126): privilege escalation vulnerability, which allows an attacker to gain administrative privileges.
- ZDI-21-1299 (CVE-2021-42125) – Remote code execution vulnerability, which can be exploited from the level of an administrator account.

Even though this chain is powerful, its first part heavily depends on factors that are not within the attacker’s control. We can do better, right?

The Inspiration

Later, I identified several interesting facts concerning Ivanti Avalanche:

- It contains multiple XStream 1.4.12 jar packages in its directories.
- It implements multiple ObjectGraph classes, which wrap the XStream serializer.
- Some of those classes define an allowlist of classes permitted for deserialization, while others lack such an allowlist.

This led me to suspect that there are multiple untrusted deserialization issues in the product. However, I was not yet able to determine how to reach those deserialization routines. Fortunately, I decided to pursue the matter further, and it turned out to be a long, exciting journey. It allowed me to not only exploit the XStream deserialization issues but to significantly increase the attack surface and find many more 0-days.

This blog post describes the first part of my Ivanti Avalanche research, where I identified the Ivanti Avalanche custom network protocol and abused it to perform several remote code executions. Moreover, it describes a cool race condition vulnerability that leads to an authentication bypass.

Identifying Ivanti Avalanche Services

To begin, let’s have a look at the Avalanche services:

Figure 1 - Ivanti Avalanche Services

We find we are dealing with the Tomcat Web Application plus other services. “Wavelink Information Router” seems to be the most interesting of them, due to the following description: “Coordinates communication between Wavelink processes…”.

At this stage, it all seemed complicated. Because of this, I used the following methods to gain some more insight:
• Network traffic analysis
• Static analysis
• Log file analysis

After a while, I was able to see a bigger picture. It seemed that the Avalanche Web Application is not able to perform tasks by itself, not even a login operation. However, it can freely use different services to perform tasks. The Information Router, also known as the InfoRail service, stands in between, and is responsible for the distribution of messages between the services. The InfoRail service listens on TCP port 0.0.0.0:7225 by default.

Figure 2 - Inter-Services communication

As can be seen in the above diagram, the communication flow is straightforward. The Web Backend creates a message and sends it to the InfoRail service, which forwards it to the appropriate destination service. The destination service handles the message and returns the response to the Web Backend, once more via the InfoRail service. In the default installation, all these services are running on the same host. However, it is possible to place some of these services on remote machines.

On the other hand, it is not easy to get more detailed information about the messages. Network traffic analysis was not of much use, as the messages seem to be obfuscated or encrypted. In order to learn something more about them, I had to conduct a detailed code analysis.

The following section presents an overview of the InfoRail protocol and all the basics needed to:
• Recreate the protocol and messages
• Understand its basics
• Understand the payload delivery mechanism

InfoRail Protocol Basics

A typical InfoRail message consists of three main parts:
• Preamble
• Header
• Optional XML payload

The following picture presents a message structure:

Figure 3 - Message Structure

The InfoRail Preamble

The preamble always has a length of 24 bytes. It consists of the following parts:
• Bytes 1-4: Length of the whole message
• Bytes 5-8: Length of the header
• Bytes 9-12: Length of the payload
• Bytes 13-16: Length of the uncompressed payload (payload can be optionally compressed)
• Bytes 17-20: Message ID (typically an incremented number, starting from 1)
• Byte 21: Protocol version (typically 0x10)
• Bytes 22-23: Reserved • Byte 24: Encryption flag (payload and header can be optionally encrypted) – 0 or 1

The InfoRail Header

The header of the typical message consists of multiple keys together with their corresponding values. Those keys and values are included in the header in the following way:
• 3 null bytes
• 0x02 byte
• 3 null bytes
• 1 byte which provides the length of a key (e.g. 0x08)
• 3 null bytes
• 1 byte which provides the length of a value (e.g. 0x06)
• Key + value

Here’s an example key and value:

         \x00\x00\x00\x02\x00\x00\x00\x08\x00\x00\x00\x06h.msgcat999999

As was mentioned before, a header can contain multiple keys. The most important ones that appear in most or all messages are:
h.msgcat - in typical requests, it is equal to 10 (request)
h.msgsubcat - information about the request type, thus it is crucial for the payload processing
h.msgtag - usually stores the JSESSIONID cookie, although no method that verifies this cookie was spotted, thus this value can be random.
h.distlist - specifies one or more services to which the message will be forwarded by InfoRail

The header must be padded with null bytes to a multiple of 16 bytes, due to the optional encryption that can be applied.

The Payload

As was mentioned before, the majority of messages contain an XML payload. An XStream serializer is used for the payload serialization and deserialization operations.

Different serialized objects can be transferred depending on the target service and the message subcategory. However, in most cases we are dealing with the RequestPayload object . The following snippet presents an example of the XML that is sent during an authentication operation. In this case, Avalanche Web Backend sends this XML to the Enterprise Server service, which then verifies user credentials.

RequestPayload.xml

As you can see, this message contains a serialized UserCredentials object, which consists of the loginName, encrypted password, domain, and clientIpAddress. You can also see that the RequestPayload contains the web cookie (sessionId). However, this cookie is never verified, so it can be set to any MD5 hash. As the payload can be optionally encrypted (and compressed), it must be padded to a multiple of 16 bytes.

Typically, every service implements its own ObjectGraph class, which defines the instance of the XStream serializer and configures it. Here’s a fragment of an example implementation:

ObjectGraphPart.java

When the service receives the XML payload, it deserializes it with the ObjectGraph.fromXML method.

Encryption

As was mentioned before, the header and the payload of the message can be encrypted. Furthermore, the payload can be compressed. InfoRail does not use the SSL/TLS protocol for encryption. Instead, it manually applies an encryption algorithm using a hardcoded encryption key.

As both the encryption algorithm and the encryption key can be extracted from the source code, the potential attacker can perform both the decryption and encryption operations without any obstacles.

Distribution to Services

The InfoRail service needs to know where to forward the received message. This information is stored in the h.distlist key of the message header. Values that can be used are stored in the IrConstants class. Variables that start with IR_TOPIC define the services where the message can be forwarded. The following code snippet presents several hardcoded variables:

DistributionVariables.java

If the sender wants the message to be forwarded to the license server, the h.distlist value must be set to 255.3.2.8.

Message Processing and Subcategories

This is probably the most important part of the protocol description. As was mentioned before, the message category is included in the message header under the h.msgsubcat key. As seen in the last line of the code snippet below, services protect themselves against the handling of an unknown message and, if the provided message subcategory is not implemented, the message is dropped.

Message processing may be implemented in slightly different ways depending on the service. Here, we are going to take a brief look at the Avalanche Notification Server. The following snippet represents the processMessage method found in the MessageDispatcher class:

processMessage.java

At [1], the message subcategory is retrieved from the header. Then, it is passed to the MessageProcessorVector.getProcessor method to obtain a reference to the appropriate message handler

At [2], the switch-case statement begins.

If the category is equal to 10 (request), the processInfoRailRequest method is invoked at [3]. Its arguments contain the handler that was retrieved at step [1]. We can have a quick look at this method here:

processInfoRailRequest.java

Basically, if the handler is not null, the code will invoke the handler.ProcessMessage method.

Finally, we must investigate how handlers are retrieved. The most important part is as follows:

MessageProcessorVector.java

At [1], a HashMap<Integer, IMessageProcessor> is defined.

At [2] and subsequent lines, the code invokes the setProcessor method. It accepts the message subcategory integer and the corresponding object that implements IMessageProcessor, such as AnsCredentialsHandler.

At [3], the setProcessor method is defined. It inserts the subcategory and appropriate object into the HashMap defined at [1].

At [4], getProcessor retrieves the handler based on the provided subcategory.

To summarize, there is a HashMap that stores the message subcategories and their corresponding handler objects. If we send a message to the Avalanche Notification Server with the subtype equal to 3706, the AnsTestHandler.processMessage method will be invoked.

Let’s have a look at one example of a message handler, AnsTestHandler:.

AnsTestHandler.java

At [1], the SUBCATEGORY variable is defined. It is common for the message processors to define such a variable.

At [2], the processMessage method is defined.

At [3], it retrieves the XML payload from the message.

At [4], it deserializes the payload with the ObjectGraph.fromXML method. It then casts it to AnsTestPayload, although the casting occurs after the deserialization. According to that, if the ObjectGraph does not implement any additional protections (such as an allowlist), we should be able to do harm here.

Success! We have identified the message processing routine. Moreover, we were able to quickly map the subcategory to the corresponding fragment of code that will handle our message. It seems that right now, we should be able to craft our own message.

Is There Any Authentication?

At this point, it seemed that I had everything necessary to send my own message. However, when I sent one, I saw no reaction from the targeted service. I looked at the InfoRail service log file and spotted these interesting lines:

Figure 4 InfoRail Log Files – Dropping the Unauthenticated Message

It seems that I had missed an important part: authentication. Having all the details regarding the protocol and encryption, I was able to quickly identify a registration message in the network traffic. It is one of the rare examples where the payload is not stored in the XML form. The following screenshot presents a fragment of a registration message:

Figure 5 - Fragment of an Exemplary Registration Message

Several important things can be spotted here:
         -- reg.appident – specifies the name of the service that tries to register.
         -- reg.uname / reg.puname – specifies something that looks like a username.
         -- reg.cred / reg.pcred – specifies something that looks like a hashed password.

After a good deal of code analysis, I determined the following:
         -- Uname and puname are partially random.
         -- Cred and pcred values are MD5 hashes, based on the following values:
                  -- Username (.anonymous.0.digits).
                  -- Appropriate fragment of the key, which is hardcoded in the source code.

Once more, the only secret that is needed is visible in the source code. The attacker can retrieve the key and construct his own, valid registration message.

Finally, we can properly register with the InfoRail service and send our own messages to any of the Avalanche services.

Just Give Me Those Pwns Please – Code Execution on Four Services

At this stage, one can verify the services that do not implement a allowlist in the ObjectGraph class. I identified 5 of them:

- Data Repository Service (ZDI-CAN-15169).
- StatServer Service (ZDI-CAN-15130).
- Notification Server Service (ZDI-CAN-15448).
- Certificate Management Server Service (ZDI-CAN-15449).
- Web File Server Service (ZDI-CAN-15330).

We have five XStream deserialization endpoints that will deserialize anything we provide. One can immediately begin to consider ways to exploit this deserialization. For starters, XStream is very transparent about its security. Their security page (available here) presents multiple gadgets based on classes available in the Java runtime. Sadly, no suitable gadget worked for the first four services that I tried to exploit, as the required classes were not loaded.

Going further, one can have a look at Moritz Bechler’s “Java Unmarshaller Security” paper:

XStream tries to permit as many object graphs as possible – the default converters are pretty much Java Serialization on steroids. Except for the call to the first non-serializable parent constructor, it seems that everything that can be achieved by Java Serialization can be with XStream – including proxy construction.

 Proxy construction does not seem to be a thing in the newer versions of XStream. However, we should still be able to exploit it with ysoserial gadgets. Ysoserial gadgets for XStream were not available back then, so I created several myself. They can be found in this GitHub repository.

 Using my ysoserial XStream gadgets, I was successful in getting remode code execution in four Avalanche services. Here is a summary of the services I was able to exploit, and the required gadgets:

- StatServer: Exploited using AspectJWeaver and CommonsBeanutils1
- Data Repository: Exploited using C3P0 and CommonsBeanutils1
- Certificate Management Server: Exploited using CommonsBeanutils1
- Avalanche Notification Server: Exploited using CommonsBeanutils1

For no particular reason, let’s focus on the StatServer. To begin, we must find the topic and subcategory of some message that will deserialize the included XML payload. According to that, the InfoRail protocol message headers should contain the following keys and values:
h.distlist = 255.3.2.12
h.msgsubcat = 3502 (GetMuCellTowerData message)

In this example, we will make use of the AspectJWeaver gadget, which allows us to upload files. Below is the AspectJWeaver gadget for the XStream:

AspectJWeaver.xml

Several things can be highlighted in this gadget:
• The iConstant tag contains the Base64 file content.
• The folder tag contains a path to the upload directory. I am targeting the Avalanche Web Application root directory here.
• The key tag specifies the name of the file.

Having all the data needed, we can start the exploitation process:

Figure 6 - StatServer Exploitation - Upload of Web shell

The following screenshot presents the uploaded web shell and the execution of the whoami command.

Figure 7 - StatServer Exploitation - Webshell and Command Execution

Success! To sum up this part, an attacker who can send messages to Avalanche services can abuse the XStream deserialization in 4 different services.

I also got remote code execution on a fifth serviceHowever, exploiting this one was way trickier.

Exploiting JNDI Lookups Before It Was Cool

Java Naming and Directory Interface (JNDI) Lookups have a long history, and a lot of researchers were familiar with this vector long before the Log4Shell vulnerability. One of the proofs for that is CVE-2021-39146 – an XStream deserialization gadget that triggers a lookup. It has occurred to be the only XStream gadget that worked against the Web File Server service, for which I was not able to craft a valid ysoserial gadget.

Still, we are dealing with a fresh Java version. Thus, we are not able to abuse remote class loading. Moreover, the attacker is not able to abuse the LDAP deserialization vector (described here [PDF]). Using the JNDI injection, we can deliver the serialized payload, which will be then deserialized by our target. However, we are not aware of any deserialization gadgets that could be abused in the Web File Server.  If there were any gadgets, we would not need the JNDI lookup in the first place. Luckily, there are several interesting JAR packages included in the Web File Server Classpath.

Figure 8 - Web File Server - Tomcat JARs

As you can see, the Web File Server loads several Tomcat JAR packages. You might perhaps also be familiar with the great technique discovered by Michael Stepankin, which abuses unsafe reflection in Tomcat BeanFactory to execute arbitrary commands through JNDI Lookup. The original description can be found here.

In summary, we can execute the following attack:

  1. Set up malicious LDAP server, which will serve the malicious BeanFactory. We will use the Rogue JNDI tool.
  2. Register with the InfoRail service.
  3. Send the message containing the CVE-2021-39146 gadget, targeting the Web File Server pointing to the server defined in step 1.
  4. The Web File Server makes an LDAP lookup and retrieves data from the malicious server.
  5. Remote code execution.

The following screenshot presents the setup of the LDAP server:

Figure 9 - Setup of Rogue Jndi

The next snippet presents the CVE-2021-39146 gadget, which was used for this Proof of Concept:

jndiGadget.xml

If everything goes well and the lookup was performed successfully, Rogue JNDI should show the following message and the code should be executed on the targeted system.

Figure 10 - Triggered JNDI Lookup

To summarize, we were able to abuse the custom Ivanti Avalanche protocol and XML message deserialization mechanisms to exploit five different services and get remote code execution with SYSTEM privileges. I have found more deserialization vulnerabilities in Ivanti Avalanche, but I am leaving them for the second part of the blog post. Right now, I would like to stay with the protocol and inter-services communication.

Abusing a Race Condition in the Communication and Authentication Messages

As detailed above, the various Avalanche services communicate with each other with the help of InfoRail. When a service provides a response, the response is again forwarded via the InfoRail service. The idea for this research was: is it possible for an attacker to spoof a response? If so, it may be possible to abuse Ivanti Avalanche behavior and perform potentially malicious actions.

I focused on the authentication operation, which is presented in the following scheme (read from top to bottom):

Figure 11 - Authentication Scheme

When a user authenticates through the Avalanche Web Application login panel, the backend transfers the authentication message to the Enterprise Server. This service verifies credentials and sends back an appropriate response. If the provided credentials were correct, the user gets authenticated.

During this research, I learned two important things:
• The attacker can register as any service.
• The authentication message is distributed amongst every instance of the registered Enterprise Server.

According to that, the attacker can register himself as the Enterprise Server and intercept the incoming authentication messages. However, this behavior does not have much of an immediate consequence, as the transferred password is hashed and encrypted.

The next question was whether it is possible to deliver the attacker’s own response to the Avalanche Web and whether it will be accepted or not. It turns out that yes, it is possible! If you would like to deliver your own response, you must properly set two values in the message header:
Origin – The topic (ID) of the Avalanche Web backend that sent the message.
MsgId – The message ID of the original authentication message.

Both values are relatively easy to get, and thus the attacker can provide his own response to the message. It will be accepted by the service, which is waiting for the response. An example attack scenario is presented in the following figure (read from top to bottom ).

Figure 12 - Race Condition Scheme

The attack scenario works as follows:
         -- The attacker tries to log into the Web Application with the wrong credentials.
         -- Web Application sends the authentication message.
         --The InfoRail service sends the message to both Enterprise Servers: the legitimate one and the malicious one.
         --Race time:
                  --The legitimate server responds with the “wrong credentials” message.
                  --The malicious server responds with the “credentials OK” message.          --If the attacker’s server was first to deliver the message, it is forwarded to the Avalanche Web Application.
         --The attacker gets authenticated.

Please note that the “Login message” targeting the attacker’s server is not present here on purpose (although it is in reality transmitted to the attacker). I wanted to highlight the fact, that this issue can be exploited without a possibility to read messages. In such a case, the attacker has to brute-force the already mentioned message ID value. It complicates the whole attack, but the exploitation is still possible.

To summarize this part, the attacker can set up his own malicious Enterprise Server and abuse a race condition to deliver his own authentication response to the Web Application. There are two more things to investigate: what does the response message look like and are we able to win the race?

Authentication Handling

The following snippet presents an example response to a login message. Please note that those messages are way bigger during legitimate usage. However, for the Proof of Concept, I have minimized them and stored only those parts that are needed for exploitation.

The response message consists of several important parts:
• It contains a responseObject tag, which is a serialized User object.
• It contains a responseCode tag, which will be important.

At some point during authentication, the Web Backend invokes the UserService.doLogin method:

doLogin.java

At [1], the UserCredentials object is instantiated. Then, its members are set.

At [2], the authenticate method is called, and the object initialized at [1] is passed as an argument:

authenticate.java

At [1], the UserLogin object is initialized.

At [2], the UserCredentials object is serialized.

At [3], the message is being sent to the Enterprise Server, and the Web Backend waits for the response.

At [4], the responseCode included in the response is verified. We want it to be equal to 0.

At [5], the userLogin.authenticated is set to True.

At [6], the userLogin.currentUser is set to the object that was included in the responseObject.

At [7], the method returns the userLogin object.

Basically, the response should have a responseCode equal to 0. It should also include a properly serialized User object in the responseObject tag.

Finally, we analyze the fragment of UserBean.loginInner method that was responsible for the invocation of the doLogin function.

loginInner.java

At [1], the doLogin method is invoked. It retrieves the object of UserLogin type (see the returns of previous code snippets).

At [2], it sets this.currentUser to the userLogin.currentUser (the one obtained from the response).

At [3], it sets various other settings. These will not be relevant for us.

One very important thing to note: the Web Backend does not compare the username provided in the login panel and the username retrieved by the Enterprise Server. Accordingly, the attacker can:
• Trigger the authentication with the username “poc”.
• Win the race and provide the user “amcadmin” in the response.
• The attacker will then be authenticated as the “amcadmin”.

To summarize, it seems that there are no obstacles for the attacker and his response should be handled by the Web Backend without any problems. Next, we turn our focus to winning the race.

Winning the Race

In a default installation, the Enterprise Server and InfoRail services are located on the same host as the Web Backend. This makes the exploitation of the race condition harder, as the legitimate communication is handled by the local interface, which is much faster than communication through an external network interface.

Still, the attacker has some advantages. For example, he does not have to generate dynamic responses, as the response payload can be hardcoded in the exploit. The following table presents a general overview of actions that must be performed by both the attacker and the legitimate Enterprise Server.

Attacker Enterprise Server
·       Get the message ID from the original Login message and place it in the header. ·       Get the message ID from the original Login message and place it in the header.
·      Send static response. ·       Decrypt and verify the user’s credentials.
  ·       Retrieve the user’s details and create the User object.
  ·       Dynamically create the response.

The remote attacker needs to perform far fewer operations and can prepare his response more rapidly. It makes the race winnable. One may ask – what if the attacker’s position in the network too disadvantageous and he still has no chance to win the race? Even then, there is an effective solution.

The unauthenticated attacker could modify the Avalanche System Settings. This is due to a separate vulnerability that allows to bypassing domain authentication (ZDI-CAN-15919). The remote attacker could enable the LDAP-based authentication and set any address for the LDAP server configuration. In such a scenario, the legitimate Enterprise Server will first try to access this “rogue” authentication server. This will give the attacker an additional second or two (or even more if played properly). In this way, an attacker can gain more time to win the race, should this be necessary

Exploitation

Having all the pieces, the race condition vulnerability can be exploited. The following video shows an example of the attacker providing wrong credentials via the panel but was still successfully authenticating as the “amcadmin” user.

Conclusion

When you don’t have ideas for further research, make sure that you have discovered the complete attack surface of your recent targets. When you find a spot that was not already studied by others, you might find a path to discovering a whole new set of exciting vulnerabilities.

Keep an eye out for the second part of this blog, where I will share some details about my favorite vulnerabilities in the Ivanti Avalanche services. It will cover one more deserialization vulnerability, cool chains leading to the remote code execution, and a pretty rare information disclosure vulnerability.

Until then, you can follow me @chudypb  and the team @thezdi on Twitter for the latest in exploit techniques and security patches.

Riding the InfoRail to Exploit Ivanti Avalanche

CVE-2022-30136: Microsoft Windows Network File System v4 Remote Code Execution Vulnerability

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Quintin Crist of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Windows operating system, originally discovered and reported by Yuki Chen. The bug is found in the implementation of Network File System (NFS)and is due to improper handling of NFSv4 requests. An unauthenticated attacker could exploit this bug to execute arbitrary code in the context of SYSTEM. The following is a portion of their write-up covering CVE-2022-30136, with a few minimal modifications.


A remote code execution vulnerability exists in Windows Network File System. The vulnerability is due to improper handling of NFSv4 requests.

A remote attacker can exploit this vulnerability by sending malicious RPC calls to a target server. Successful exploitation results in arbitrary code execution in the context of SYSTEM. Unsuccessful exploitation may result in a crash of the target system.

The Vulnerability

Microsoft Windows ships with several network features designed to communicate and interact with non-Windows file shares. One of these modules is called Network File System (NFS).

NFS is a network file system protocol originally developed by Sun Microsystems in 1984. Version 2 is documented in RFC 1094. Version 3 is documented in RFC 1813. Version 4 was developed by the IETF and is documented in RFC 3010 (released December 2000) and revised in RFC 3530 (released April 2003) and RFC 7530 (released March 2015). NFS allows users to access remote file shares in the same way that the local file system is accessed. Different access levels and permissions can be set on the share, such as read-write and read-only. Additionally, IP/UID/GID/Kerberos security can be used. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. ONC RPC was originally developed by Sun Microsystems and can also be referred to as Sun RPC.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the following table) that specifies the length of the message. This allows the receiver to distinguish multiple messages sent over a single TCP session. Other protocols such as UDP do not use this field. Note that all multi-byte values are encoded in big-endian byte order.

The structure of ONC RPC request messages, in general, is as follows:

The Credentials structure in a Sun-RPC message has the following structure:

The Flavor field in the above structure serves as a type identifier of the Contents data. Security flavors have been called authentication flavors for historical reasons. There are multiple security flavors defined in the RPC specification, such as AUTH_NONE(0), AUTH_SYS(1), AUTH_SHORT(2), AUTH_DH(3), and RPCSEC_GSS(6).

The Contents field for the flavor RPCSEC_GSS has the following structure:

There are four types such as RPCSEC_GSS_DATA(0), RPCSEC_GSS_INIT(1), RPCSEC_GSS_CONTINUE_INIT(2), and RPCSEC_GSS_DESTROY(3) defined in the GSS Procedure field. Also, in the GSS Service field, there are three types: rpc_gss_svc_none(1), rpc_gss_svc_integrity(2), and rpc_gss_svc_privacy(3). When using RPCSEC_GSS to authenticate the RPC clients, a security context must be created by using RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT RPC messages. First, the RPC client sends an RPCSEC_GSS_INIT message to start the creation of the context. Then, the RPC server decides whether it needs another token for the creation. If so, the server replies with a GSS_S_CONTINUE_NEEDED message, and the client needs to send an RPCSEC_GSS_CONTINUE_INIT message to continue.

If the GSS Service field is set to 2 (rpc_gss_svc_integrity), the Program-specific data field is prefixed with the following structure:

If the GSS Service field is set to 3 (rpc_gss_svc_privacy), the Program-specific data field is encrypted.

When the Program field is set to 100003 (NFS) and the Procedure field is set to 1 (Compound), the Program-specific data field has the following structure:

A buffer overflow vulnerability exists in the Windows implementation of NFS. The vulnerability is due to incorrect calculation of the size of response messages. The server calls the function Nfs4SvrXdrpGetEncodeOperationResultByteCount() to calculate the size of each opcode response, but it does not include the size of the opcode itself. This results in the size of the response buffer being too small by OP Count * 4 bytes. A corresponding buffer is allocated with OncRpcBufMgrpAllocate. When the response data is written to the buffer, the response data overflows. Due to the function only being used for NFS version 4, only NFS4 is vulnerable.

OncRpcBufMgrpAllocate() will actually allocate the data with either OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer(), when the request is under 0x800 bytes in size, or OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation(), which is used otherwise.

OncRpcBufMgrpAllocateDescriptorFromLLInlineBuffer() returns a buffer in a static 0x800 bytes inside the descriptor. The descriptor structure has 0x50 bytes of space that appears to be unused after the static buffer.

OncRpcBufMgrpAllocateDescriptorFromLLLargePoolAllocation() returns a buffer allocated with ExAllocatePoolWithTag(). The number of bytes allocated is equal to the following:

This means that for either buffer type, more than 0x48 bytes must be overflowed to get past the padding in either buffer type. Since the number of overflowed bytes is OP Count * 4, a minimum of 19 operations must be performed in a compound message for the overflow to have any impact.

An attacker can use this vulnerability to send a crafted request with many operations, producing a large size miscalculation, resulting in a buffer overflow. Successful exploitation results in arbitrary code execution in the context of SYSTEM. Unsuccessful exploitation may result in a crash of the target system.

Detecting Attacks

Much of this information is largely seen earlier in this post. It is reposted here for your convenience.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the following table) that specifies the length of the message. This allows the receiver to distinguish multiple messages sent over a single TCP session. Other protocols such as UDP do not use this field. Note that all multi-byte values are encoded in big-endian byte order.

The structure of ONC RPC request messages is shown above, as is the Credentials structure in a Sun-RPC message. As shown above, the Flavor field in the above structure serves as a type identifier of the Contents data. Security flavors have been called authentication flavors for historical reasons. There are multiple security flavors defined in the RPC specification, such as AUTH_NONE(0), AUTH_SYS(1), AUTH_SHORT(2), AUTH_DH(3), and RPCSEC_GSS(6).

As a reminder, the Contents field for the flavor RPCSEC_GSS has the following structure:

There are four types such as RPCSEC_GSS_DATA(0), RPCSEC_GSS_INIT(1), RPCSEC_GSS_CONTINUE_INIT(2), and RPCSEC_GSS_DESTROY(3) defined in the GSS Procedure field. Also, in the GSS Service field, there are three types: rpc_gss_svc_none(1), rpc_gss_svc_integrity(2), and rpc_gss_svc_privacy(3). When using RPCSEC_GSS to authenticate the RPC clients, a security context must be created by using RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT RPC messages. Firstly, the RPC client sends an RPCSEC_GSS_INIT message to start the creation of the context. Then, the RPC server will decide whether it needs another token for the creation. If so, the server will reply with a GSS_S_CONTINUE_NEEDED message, and the client needs to send an RPCSEC_GSS_CONTINUE_INIT message to continue.

If the GSS Service field is set to 2 (rpc_gss_svc_integrity), the Program-specific data field is prefixed with the following structure:

If the GSS Service field is set to 3 (rpc_gss_svc_privacy), the Program-specific data field is encrypted and must be decrypted before continuing.

The detection device needs to check if the Program field in an RPC request message has the value 100003 (NFS), the Procedure field has the value 1 (COMPOUND), and the Program Version field has the value 4 (NFS4). If found, the device must inspect the Program-specific data in the ONC RPC messages.

The data format of NFS COMPOUND has the following structure:

The buffer overflow is only triggered if at least 19 operations are present in the NFS reply. Since the NFS reply has the response for each operation in the NFS request, request messages should be monitored for an OP Count field greater than 18.

If a packet with greater than 18 operations is detected, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Note that all multi-byte values are expressed in network (big-endian) byte order. Also, this detection method may generate false positives if normal traffic contains similar NFS COMPOUND requests.

Conclusion

This bug was patched by Microsoft in June 2022 and assigned CVE-2022-30136. In their write-up, they also list disabling NFSv4.1 as a method to mitigate attacks. However, this could lead to a loss of functionality. Also, Microsoft notes the update to address this bug should not be applied unless the fix for CVE-2022-26937 is installed. Applying both updates in the appropriate order is the best method to fully address these vulnerabilities.

Special thanks to Guy Lederfein and Quintin Crist of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2022-30136: Microsoft Windows Network File System v4 Remote Code Execution Vulnerability

The July 2022 Security Update Review

12 July 2022 at 17:26

It’s once again Patch Tuesday, which means the latest security updates from Adobe and Microsoft have arrived. Take a break from your regularly scheduled activities and join us as we review the details of their latest security offerings.

Adobe Patches for July 2022

For July, Adobe addressed 27 CVEs in four patches for Acrobat and Reader, Photoshop, RoboHelp, and Adobe Character Animator. A total of 24 of these bugs were reported through the ZDI program. The update for Acrobat and Reader addresses a combination of 22 different Critical- and Important-rated bugs. The most severe of these could allow code execution if an attacker convinces a target to open a specially crafted PDF document. While there are no active attacks noted, Adobe does list this as a Priority 2 deployment rating. The update for Photoshop fixes one Critical- and one Important-rated bug. The Critical bug is a use-after-free (UAF) that could lead to code execution. The fix for Character Animator addresses two Critical-rated code execution bugs – one a heap overflow and the other an out-of-bounds (OOB) read. Finally, the patch for RoboHelp corrects a single Important-rated cross-site scripting (XSS) bug.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes most of these updates as a deployment priority rating of 3, with the Acrobat patch being the lone exception at 2.

Microsoft Patches for July 2022

For July, Microsoft released 84 new patches addressing CVEs in Microsoft Windows and Windows Components; Windows Azure components; Microsoft Defender for Endpoint; Microsoft Edge (Chromium-based); Office and Office Components; Windows BitLocker; Windows Hyper-V; Skype for Business and Microsoft Lync; Open-Source Software; and Xbox. This is in addition to the two CVEs patched in Microsoft Edge (Chromium-based). That brings the total number of CVEs to 87.

While this higher volume is expected for a July release, there are still no fixes available for the multiple bugs submitted during the last Pwn2Own competition. And after a brief respite last month, there are additional updates for the Print Spooler. Looks like this component will be back to a monthly release schedule.

Of the 84 new CVEs released today, four are rated Critical, and 80 are rated Important in severity. One of these bugs was submitted through the ZDI program. None of the new bugs patched this month are listed as publicly known, but one of the updates for CSRSS is listed as under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with the CSRSS bug under active attack:

-       CVE-2022-22047 – Windows CSRSS Elevation of Privilege
This bug is listed as being under active attack, but there’s no information from Microsoft on where the vulnerability is being exploited or how widely it is being exploited. The vulnerability allows an attacker to execute code as SYSTEM, provided they can execute other code on the target. Bugs of this type are typically paired with a code execution bug, usually a specially crafted Office or Adobe document, to take over a system. These attacks often rely on macros, which is why so many were disheartened to hear Microsoft’s delay in blocking all Office macros by default.

-       CVE-2022-30216 – Windows Server Service Tampering Vulnerability
This patch corrects a tampering vulnerability in the Windows Server Service that could allow an authenticated attacker to upload a malicious certificate to a target server. While this is listed as “Tampering”, an attacker who could install their own certificate on a target system could use this bug for various purposes, including code execution. While tampering bugs don’t often get much attention, Microsoft does give this its highest exploit index rating, meaning they expect active exploits within 30 days. Definitely test and deploy this patch quickly – especially to your critical servers.

-       CVE-2022-22029 – Windows Network File System Remote Code Execution Vulnerability
This is the third month in a row with a Critical-rated NFS bug, and while this one has a lower CVSS than the previous ones, it could still allow a remote, unauthenticated attacker to execute their code on an affected system with no user interaction. Microsoft notes multiple exploit attempts may be required to do this, but unless you are specifically auditing for this, you may not notice. If you’re running NFS, make sure you don’t ignore this patch.

-       CVE-2022-22038 - Remote Procedure Call Runtime Remote Code Execution Vulnerability
This bug could allow a remote, unauthenticated attacker to exploit code on an affected system. While not specified in the bulletin, the presumption is that the code execution would occur at elevated privileges. Combine these attributes and you end up with a potentially wormable bug. Microsoft states the attack complexity is high since an attacker would need to make “repeated exploitation attempts” to take advantage of this bug, but again, unless you are actively blocking RPC activity, you may not see these attempts. If the exploit complexity were low, which some would argue since the attempts could likely be scripted, the CVSS would be 9.8. Test and deploy this one quickly.

Here’s the full list of CVEs released by Microsoft for July 2022:

CVE Title Severity CVSS Public Exploited Type
CVE-2022-22047 Windows CSRSS Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2022-22038 Remote Procedure Call Runtime Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-30221 Windows Graphics Component Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-22029 Windows Network File System Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-22039 Windows Network File System Remote Code Execution Vulnerability Critical 7.5 No No RCE
CVE-2022-30215 Active Directory Federation Services Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2022-23816 * AMD: CVE-2022-23816 AMD CPU Branch Type Confusion Important N/A No No Info
CVE-2022-23825 * AMD: CVE-2022-23825 AMD CPU Branch Type Confusion Important N/A No No Info
CVE-2022-30181 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33641 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33642 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33643 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33650 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33651 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33652 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.4 No No EoP
CVE-2022-33653 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33654 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33655 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33656 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33657 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33658 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.4 No No EoP
CVE-2022-33659 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33660 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33661 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33662 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33663 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33664 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33665 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33666 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33667 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33668 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33669 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33671 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-33672 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33673 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-33674 Azure Site Recovery Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-33675 Azure Site Recovery Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-33677 Azure Site Recovery Elevation of Privilege Vulnerability Important 7.2 No No EoP
CVE-2022-33676 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-33678 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-30187 Azure Storage Library Information Disclosure Vulnerability Important 4.7 No No Info
CVE-2022-22048 BitLocker Security Feature Bypass Vulnerability Important 6.1 No No SFB
CVE-2022-27776 * HackerOne: CVE-2022-27776 Insufficiently protected credentials vulnerability might leak authentication or cookie header data Important N/A No No Info
CVE-2022-22040 Internet Information Services Dynamic Compression Module Denial of Service Vulnerability Important 7.3 No No DoS
CVE-2022-33637 Microsoft Defender for Endpoint Tampering Vulnerability Important 6.5 No No Tampering
CVE-2022-33632 Microsoft Office Security Feature Bypass Vulnerability Important 4.7 No No SFB
CVE-2022-22036 Performance Counters for Windows Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-33633 Skype for Business and Lync Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-22037 Windows Advanced Local Procedure Call Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2022-30202 Windows Advanced Local Procedure Call Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-30224 Windows Advanced Local Procedure Call Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-22711 Windows BitLocker Information Disclosure Vulnerability Important 6.7 No No Info
CVE-2022-30203 Windows Boot Manager Security Feature Bypass Vulnerability Important 7.4 No No SFB
CVE-2022-30220 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30212 Windows Connected Devices Platform Service Information Disclosure Vulnerability Important 4.7 No No Info
CVE-2022-22031 Windows Credential Guard Domain-joined Public Key Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-22026 Windows CSRSS Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2022-22049 Windows CSRSS Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30214 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2022-22043 Windows Fast FAT File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-22050 Windows Fax Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-22024 Windows Fax Service Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-22027 Windows Fax Service Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30213 Windows GDI+ Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-22034 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30205 Windows Group Policy Elevation of Privilege Vulnerability Important 6.6 No No EoP
CVE-2022-22042 Windows Hyper-V Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-30223 Windows Hyper-V Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2022-30209 Windows IIS Server Elevation of Privilege Vulnerability Important 7.4 No No EoP
CVE-2022-22025 Windows Internet Information Services Cachuri Module Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-21845 Windows Kernel Information Disclosure Vulnerability Important 4.7 No No Info
CVE-2022-30211 Windows Layer 2 Tunneling Protocol (L2TP) Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-30225 Windows Media Player Network Sharing Service Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2022-22028 Windows Network File System Information Disclosure Vulnerability Important 5.9 No No Info
CVE-2022-22023 Windows Portable Device Enumerator Service Security Feature Bypass Vulnerability Important 6.6 No No SFB
CVE-2022-22022 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2022-22041 Windows Print Spooler Elevation of Privilege Vulnerability Important 6.8 No No EoP
CVE-2022-30206 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30226 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2022-30208 Windows Security Account Manager (SAM) Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-30216 Windows Server Service Tampering Vulnerability Important 8.8 No No Tampering
CVE-2022-30222 Windows Shell Remote Code Execution Vulnerability Important 8.4 No No RCE
CVE-2022-22045 Windows.Devices.Picker.dll Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-33644 Xbox Live Save Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-2294 * Chromium: CVE-2022-2294 Heap buffer overflow in WebRTC High N/A No Yes RCE
CVE-2022-2295 * Chromium: CVE-2022-2295 Type Confusion in V8 High N/A No No RCE

* Indicates this CVE had previously been assigned by a 3rd-party and is now being incorporated into Microsoft products.

Please note that Google is aware that an exploit for one of the Chromium bugs (CVE-2022-2294) exists in the wild. If you’re using Microsoft Edge (Chromium-based), make sure it gets updated as soon as possible.

Looking at the rest of the release, the first thing that stands out is the 32(!) patches for the Azure Site Recovery service. Two are remote code execution (RCE) bugs while the rest are elevation of privilege (EoP) issues. This is primarily a cloud-based service, but there are some on-prem components. Don’t expect an automatic update for these bugs. In all cases, you will need to upgrade to version 9.49 to remediate these vulnerabilities. Instructions for this can be found here. It’s incredibly unusual to see so many CVEs addressed in a single month for a single component, and it’s not clear why Microsoft chose to address these bugs in this manner. Regardless of why, if you rely on Azure Site Recovery, make sure you update all the necessary components.

There are two other Critical-rated bugs still to cover. There’s a second Critical-rated NFS vulnerability in addition to the one previously discussed. This is very similar to the other one but rates a slightly lower CVSS. It’s still Critical and the CVSS is questionable, so don’t think it’s any less dangerous. The highest CVSS patch this month belongs to a bug in Windows Graphic Component. These types of bugs usually manifest by either opening a file or viewing an image.

The remaining Critical-rated bugs impact some critical business functions. The first is a patch for the DNS server component. While certainly worth paying attention to, it does require the attacker to have elevated privileges. There’s an RCE bug in Windows Shell, but it requires a local attacker to interact with the logon screen. As always, don’t ignore physical security. There’s a code execution bug in Skype for Business and Lync (remember those?), but there are several prerequisites that make exploitation less likely. There’s a patch for the Layer 2 Tunneling Protocol (L2TP). It’s not clear how many people are using L2TP these days, but if you’re one of them, make sure you get this patch installed. Speaking of outdated methods of communication, there are two RCE bugs in the Windows Fax service receiving patches.

There are 52 fixes for EoP bugs, which includes the 30 Azure Site Recovery bugs we’ve already mentioned. In addition to the one under active attack, there are two other EoP bugs in CSRSS. For the most part, the rest of these bugs require an attacker to already have the ability to execute code on the target. They can then use one of these bugs to escalate to SYSTEM or some other elevated level. An exception to this is the bug in the Media Player Network Sharing service, which could be leveraged to delete registry keys. There’s also a patch for IIS to address a bug that could allow attackers to bypass authentication on an affected IIS server. The Group Policy bug requires the attacker to have privileges to create Group Policy Templates. Microsoft reminds us to regularly audit these groups, and that’s good advice for many reasons. There’s a patch for the Xbox Live Save Service, but it’s not clear what privileges an attacker would gain if they exploited this bug. Microsoft does list the attack vector as local, so perhaps multiple user profiles on the same Xbox would be impacted? And finally, after getting a month off, there are four new patches for the Print Spooler. We will likely continue to see additional print spooler fixes for the foreseeable future.

There are three fixes for denial-of-service (DoS) bugs in this month’s release, and all are impactful. The first impacts the Security Account Manager (SAM). While Microsoft doesn’t state the impact of this bug, a DoS on the SAM would likely lead to problems logging on to a domain. The other DoS patches fix bugs in IIS. The first covers the Cachuri module, which provides user-mode caching of URL information. The other is in the dynamic compression module, which (as its name implies) allows IIS to compress responses coming from various handlers. It doesn’t seem like either of these would lead to a complete website shutdown, but they would certainly degrade services.

In addition to the tampering bug mentioned above, there’s another tampering issue in Microsoft Defender for Endpoint. However, this bug requires the attacker to authenticate to the management console appliance and to have an integration token.

Physical access is a common factor in three of the four security feature bypass bugs getting fixed this month. The first is a BitLocker bypass that allows an attacker with physical access to a powered-off system to gain access to encrypted data. Similarly, the bug in Boot Manager allows an attacker with physical access to bypass Secure Boot and access the pre-boot environment. The bypass in the Windows Portable Device Enumerator service allows an attacker to attach a USB storage device to a system where Group Policy failed to apply. The final SFB occurs when opening a specially crafted Office file.

The July release contains new fixes for seven information disclosure bugs. Most of these only result in leaks consisting of unspecified memory contents, but there are a couple of notable exceptions. The bug in BitLocker could allow a local attacker to view raw, unencrypted disk sector data. Considering BitLocker’s purpose, you could almost consider this a security feature bypass. One of the Hyper-V bugs could let an attacker on a guest OS gain data from the Hyper-V host. The bug in the Azure Storage Library allows an attacker to decrypt data on the client side and disclose the content of the file or blob. There’s also a CVE assigned by HackerOne that could leak authentication or cookie header data via curl. This was originally patched in April 2022 and is now being incorporated into Microsoft products that use curl.

Finally, there are two information disclosure bugs covering AMD CPU Branch Type Confusion issues. These are related to the “Hertzbleed” vulnerabilities first documented in Intel processors last month. While interesting from an academic perspective, exploits using speculative execution side channels haven’t had much of an impact in the real world. 

No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV990001.

Looking Ahead

The next Patch Tuesday falls on August 9, and I’ll be at Black Hat in Las Vegas to present on determining risk in an era of low patch quality. I’ll still be able to publish details and patch analysis of the August release, but please come by for the presentation if you’re at the conference. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The July 2022 Security Update Review

CVE-2022-23088: Exploiting a Heap Overflow in the FreeBSD Wi-Fi Stack

16 June 2022 at 16:38

In April of this year, FreeBSD patched a 13-year-old heap overflow in the Wi-Fi stack that could allow network-adjacent attackers to execute arbitrary code on affected installations of FreeBSD Kernel. This bug was originally reported to the ZDI program by a researcher known as m00nbsd and patched in April 2022 as FreeBSD-SA-22:07.wifi_meshid. The researcher has graciously provided this detailed write-up of the vulnerability and a proof-of-concept exploit demonstrating the bug.


Our goal is to achieve kernel remote code execution on a target FreeBSD system using a heap overflow vulnerability in the Wi-Fi stack of the FreeBSD kernel. This vulnerability has been assigned CVE-2022-23088 and affects all FreeBSD versions since 2009, along with many FreeBSD derivatives such as pfSense and OPNsense. It was patched by the FreeBSD project in April 2022.

The Vulnerability

When a system is scanning for available Wi-Fi networks, it listens for management frames that are emitted by Wi-Fi access points in its vicinity. There are several types of management frames, but we are interested in only one: the beacon management subtype. A beacon frame has the following format:

In FreeBSD, beacon frames are parsed in ieee80211_parse_beacon(). This function iterates over the sequence of options in the frame and keeps pointers to the options it will use later.

One option, IEEE80211_ELEMID_MESHID, is particularly interesting:

There is no sanity check performed on the option length (frm[1]). Later, in function sta_add(), there is a memcpy that takes this option length as size argument and a fixed-size buffer as destination:

Due to the lack of a sanity check on the option length, there is an ideal buffer overflow condition here: the attacker can control both the size of the overflow (sp->meshid[1]) as well as the contents that will be written (sp->meshid).

Therefore, when a FreeBSD system is scanning for available networks, an attacker can trigger a kernel heap overflow by sending a beacon frame that has an oversized IEEE80211_ELEMID_MESHID option.

Building a “Write-What-Where” Primitive

Let’s look at ise->se_meshid, the buffer that is overflown during the memcpy. It is defined in the ieee80211_scan_entry structure:

Here, the overflow of se_meshid allows us to overwrite the se_ies field that follows. The se_ies field is of type struct ieee80211_ies, defined as follows:

We will be interested in overwriting the last two fields: data and len.

Back in sta_add(), not long after the memcpy, there is a function call that uses the se_ies field:

This ieee80211_ies_init() function is defined as:

The data parameter here points to the beginning of the beacon options in the frame, and len is the full length of all the beacon options. In other words, the (data,len) couple describes the options buffer that is part of the frame that the attacker sent:

Figure 1 - The Options Buffer

As noted in the code snippet, the ies structure is fully attacker-controlled thanks to the buffer overflow.

Therefore, at $1:

       -- We can control len, given that this is the full size of the options buffer, and we can decide that size by just adding or removing options to our frame.
       -- We can control the contents of data, given that this is the contents of the options buffer.
       -- We can control the ies->data pointer, by overflowing into it.

We thus have a near-perfect write-what-where primitive that allows us to write almost whatever data we want at whatever kernel memory address we want just by sending one beacon frame that has an oversized MeshId option.

Constraints on the Primitive

A few constraints apply to the primitive:

  1. The FreeBSD kernel expects there to be SSID and Rates options in the frame. That means that there are 2x2=4 bytes of the options buffer that we cannot control. In addition, our oversized MeshId option has a 2-byte header, so that makes 6 bytes we cannot control. For convenience and simplicity, we will place these bytes at the beginning of the options buffer.

  2. Our oversized MeshId option must be large enough to overwrite up to the ies->data and ies->len fields, but not more. This equates to a length of 182 bytes for the MeshId option, plus its 2-byte header. To accommodate the MeshId option plus the two options mentioned above, we will use an options buffer of size 188 bytes.

  3. The ies->data and ies->len fields we overwrite are respectively the last 8 and 4 bytes within the options buffer, so they too are constrained.

  4. The ies->len field must be equal to len for the branch at $0 not to be taken.

The big picture of what the frame looks like given the aforementioned constraints:

Figure 2 - The Big Picture

Maintaining stability of the target

Let’s say we send a beacon frame that uses the primitive to overwrite an area of kernel memory. There is going to be a problem at some point when the kernel subsequently tries to free ies->data. This is because ies->data is supposed to point to a malloc-allocated buffer, which may no longer be true after our overwrite.

To maintain stability and avoid crashing the target, we can send a second, corrective beacon frame that overflows ies->data to be NULL and ies->len to be 0. After that, when the kernel attempts to free ies->data, it will see that the pointer is NULL, and won’t do anything as a result. This allows us to maintain the stability of the target and ensure our primitive doesn’t crash it.

Choosing what to write, and where to write it

Now we have a nice write-what-where primitive that we can invoke with just one beacon frame plus one corrective frame. What exactly can we do with it now?

A first thought might be to use the primitive to overwrite the instructions that the kernel executes in memory. (Un)fortunately, in FreeBSD, the kernel text segment is not writable, so we cannot use our primitive to directly overwrite kernel instructions. Furthermore, the kernel implements W^X, so no writable pages are executable.

However, the page tables that map executable pages are writable.

Injecting an implant

Here we are going to inject an implant into the target's kernel that will process "commands" that we send to it later on via subsequent Wi-Fi frames — a full kernel backdoor, if you will.

The process of injecting this implant will take four beacon frames.

This is a bit of a bumpy technical ride, so fasten your seatbelt.

Frame 1: Injecting the payload

Background: the direct map is a special kernel memory region that contiguously maps the entire physical memory of the system as writable pages, except for the physical pages of read-only text segments.

We use the primitive to write data at the physical address 0x1000 using the direct map:

Figure 3 - Frame 1

0x1000 was chosen as a convenient physical address because it is unused. The data we write is as follows:

Figure 4 - Frame 1

The implant shellcode area contains the instructions of our implant. The rest of the fields are explained below.

Frame 2: Overwriting an L3 PTE

Quick Background: x64 CPUs use page tables to map virtual addresses to physical RAM pages, in a 4-level hierarchy that goes from L4 (root) to L0 (leaf). Refer to the official AMD and Intel specifications for more details.

In this step, we use the primitive to overwrite an L3 page table entry (PTE) and make it point to the L2 PTE that we wrote at physical address 0x1000 as part of Frame 1. We crafted that L2 PTE precisely to point to our three L1 PTEs, which themselves point to two different areas: (1) two physical pages of the kernel text segment, and (2) our implant shellcode.

In other words, by overwriting an L3 PTE, we create a branch in the page tables that maps two pages of kernel text as writable and our shellcode as executable:

Figure 5 - Frame 2

At this point, our shellcode is mapped into the target’s virtual memory space and is ready to be executed. We will see below why we're mapping the two pages of the kernel text segment.

The attentive reader may be concerned about the constraints of the primitive here. Nothing to worry about: the L3 PTE space is mostly unpopulated. We just have to choose an unpopulated range where overwriting 188 bytes will not matter.

Frame 3: Patching the text segment

In order to jump into our newly mapped shellcode, we will patch the beginning of the sta_input() function in the text segment. This function is part of the Wi-Fi stack and gets called each time the kernel receives a Wi-Fi frame, so it seems like the perfect place to invoke our implant.

How can we patch it, given that the kernel text segment is not writable? By mapping as writable the text pages that contain the function. This is what we did in frames 1 and 2, with the first two L1 PTEs, that now give us a writable view of the instruction bytes of sta_input():

Figure 6 - Our writable view of sta_input()

Back on topic, we use the primitive to patch the first bytes of sta_input() via the writable view we created in frames 1 and 2, and replace these bytes with:

This simply calls our shellcode. However, the constraints of our primitive come into play:

  1. The first constraint of the primitive is that the first 6 bytes that we overwrite cannot be controlled. Overwriting memory at sta_input would not be great, as it would put 6 bytes of garbage at the beginning of the function, causing the target to crash.

However, if we look at the instruction dump of sta_input, we can see that it actually has a convenient layout:

What we can do here is overwrite memory at sta_input-6. The 6 bytes of garbage will just overwrite the unreachable NOPs of the previous sta_newstate() function, with no effect on execution.

With this trick, we don’t have to worry about these first 6 bytes, as they are effectively discarded.

  1. The second constraint of the primitive is that we are forced to overwrite exactly 182 bytes, so we cannot overwrite the first few bytes only. This is not really a problem. We can just fill the rest of the bytes with the same instruction bytes that are there in memory already.

  2. The third constraint of the primitive is that the last 12 bytes that we write are the ies->data and ies->len fields, and these don’t disassemble to valid instructions. That’s a problem because these bytes are within sta_input(). If the kernel tries to execute these bytes, it won’t be long before it crashes. To work around this, we must have corrective code in our implant. When called for the first time, our implant must correct the last 12 bytes of garbage that we wrote into sta_input(). Although slightly annoying, this is not complicated to implement.

With all that established, we’re all set. Our implant will now execute each time sta_input() is called, meaning, each time a Wi-Fi frame is received by the target!

Frame 4: Corrective frame

Finally, to maintain the stability of the target, we send a final beacon frame where we overflow ies->data to be NULL and ies->len to be 0.

This ensures that the target won’t crash.

Subsequent communication channel

With the aforementioned four frames, we have a recipe to reliably inject an implant into the target’s kernel. The implant gets called in the same context as sta_input():

Notably, the second argument, m, is the memory region containing the buffer of the frame that the kernel is currently processing. The implant can therefore inspect that buffer (via %rsi) and act depending on its contents.

In other words, we have a communication channel with the implant. We can therefore code our implant as a server backdoor and send commands to it via this channel.

Full steps

Let’s recap:

  1. A heap buffer overflow vulnerability exists in the FreeBSD kernel. An attacker can trigger this bug by sending a beacon frame with an oversized MeshId option.
  2. Using that vulnerability, we can implement a write-what-where primitive that allows us to perform one kernel memory overwrite per beacon frame we send.
  3. We can use that primitive three times to inject an implant into the target’s kernel.
  4. A fourth beacon frame is used to clean up ies->data and ies->len, to prevent a crash.
  5. Finally, our implant runs in the kernel of the target and acts as a full backdoor that can process subsequent Wi-Fi frames we send to it.

The Exploit

A full exploit can be found here. It injects a simple implant that calls printf() with the strings that the attacker subsequently sends. To use this exploit from a Linux machine that has a Wi-Fi card called wifi0, switch the card to monitor mode with:

Then, build and run the exploit for the desired target. For example, if you wish to target a pfSense 2.5.2 system:

Please exercise caution - this will exploit all vulnerable systems in your vicinity.

Once you have done this, look at the target’s tty0 console. You should see: “Hello there, I’m in the kernel”.


Thanks again to m00nbsd for providing this thorough write-up. They have contributed multiple bugs to the ZDI program over the last few years, and we certainly hope to see more submissions from them in the future. Until then, follow the team for the latest in exploit techniques and security patches.

CVE-2022-23088: Exploiting a Heap Overflow in the FreeBSD Wi-Fi Stack

The June 2022 Security Update Review

14 June 2022 at 17:25

It’s once again Patch Tuesday, which means the latest security updates from Adobe and Microsoft have arrived. Take a break from your regularly scheduled activities and join us as we review the details of their latest security offerings.

Adobe Patches for June 2022

This month, Adobe released six patches addressing 46 CVEs in Adobe Illustrator, InDesign, InCopy, Bridge, Robohelp, and Animate. A total of 40 of these CVEs were reported by ZDI vulnerability researcher Mat Powell. The largest update belongs to Illustrator, which addresses 17 total CVEs. The most severe of these bugs could allow code execution if an affected system opens a specially crafted file. Many of these bugs fall into the Out-Of-Bounds (OOB) Write category. The update for Adobe Bridge fixes 12 bugs, 11 of which are rated Critical. The patch for InCopy fixes eight Critical-rated bugs, all of which could lead to arbitrary code execution. Similarly, the InDesign patch fixes seven Critical-rated arbitrary code execution bugs. For both InDesign and InCopy, the bugs are a mix of OOB Read, OOB Write, heap overflow, and Use-After-Free (UAF) vulnerabilities. The lone bug fixed by the Animate patch is also a Critical-rated OOB Write that could lead to arbitrary code execution. Finally, the Robohelp patch fixes a Moderate-rated privilege escalation bug caused by improper authorization.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes these updates as priority 3.

Microsoft Patches for June 2022

For June, Microsoft released 55 new patches addressing CVEs in Microsoft Windows and Windows Components; .NET and Visual Studio; Microsoft Office and Office Components; Microsoft Edge (Chromium-based); Windows Hyper-V Server; Windows App Store; Azure OMI, Real Time Operating System, and Service Fabric Container; SharePoint Server; Windows Defender; Windows Lightweight Directory Access Protocol (LDAP); and Windows Powershell. This is in addition to the 4 CVEs patched in Microsoft Edge (Chromium-based), and the new update for MSDT. That brings the total number of CVEs to 60.

Of the 55 new CVEs released today, three are rated Critical, 51 are rated Important, and one is rated Moderate in severity. None of the new bugs patched this month are listed as publicly known or under active attack at the time of release, however, we do have an update for MSDT, which is public and reported to be under active attack.

It's also interesting to note is what is not included in today’s release. This is the first month in recent memory without an update for the Print Spooler. We’ll see if that trend continues or if this reprieve is only temporary. Finally, there are no fixes listed for any of the bugs disclosed during Pwn2Own Vancouver.

Before we take a deeper dive into this month’s release, let’s take just a minute to remember Internet Explorer, which will go out of support tomorrow. The ubiquitous browser has served up websites to users since 1995, and while it’s doubtful anyone will miss it, it certainly had a good run. If you’re worried about your legacy apps still functioning, IE Mode in Microsoft Edge will be supported through at least 2029. With nostalgia out of the way, let’s take a closer look at some of the more interesting updates for this month, starting with the much anticipated fix for MSDT:

-       CVE-2022-30190 - Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability
Although it’s difficult to see from the Security Update Guide, Microsoft did release an update to address the much discuss “Follina” vulnerability in MSDT. This bug has been reported to be under active attack, so priority should be given to the testing and deployment of this update.

-       CVE-2022-30136 - Windows Network File System Remote Code Execution Vulnerability
This CVSS 9.8 bug looks eerily similar to CVE-2022-26937 – an NFS bug patched last month and one we blogged about last week. This vulnerability could allow a remote attacker to execute privileged code on affected systems running NFS. On the surface, the only difference between the patches is that this month’s update fixes a bug in NFSV4.1, whereas last month’s bug only affected versions NSFV2.0 and NSFV3.0. It’s not clear if this is a variant or a failed patch or a completely new issue. Regardless, enterprises running NFS should prioritize testing and deploying this fix.

 -       CVE-2022-30163 - Windows Hyper-V Remote Code Execution Vulnerability
This bug could allow a user on a Hyper-V guest to run their code on the underlying Hyper-V host OS. The update doesn’t list the privileges the attacker’s code would run at, but any guest-to-host escape should be taken seriously. Microsoft notes that attack complexity is high since an attacker would need to win a race condition. However, we have seen many reliable exploits demonstrated that involve race conditions, so take the appropriate step to test and deploy this update.

-       CVE-2022-30148 - Windows Desired State Configuration (DSC) Information Disclosure Vulnerability
Most info disclosure bugs simply leak unspecified memory contents, but this bug is different. An attacker could use this to recover plaintext passwords and usernames from log files. Since DSC is often used by SysAdmins to maintain machine configurations in an enterprise, there are likely some sought-after username/password combos that could be recovered. This would also be a great bug for an attacker to move laterally within a network. If you’re using DSC, make sure you don’t miss this update.

Here’s the full list of CVEs released by Microsoft for June 2022:

CVE Title Severity CVSS Public Exploited Type
CVE-2022-30163 Windows Hyper-V Remote Code Execution Vulnerability Critical 8.5 No No RCE
CVE-2022-30139 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Critical 7.5 No No RCE
CVE-2022-30136 Windows Network File System Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-30184 .NET and Visual Studio Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30167 AV1 Video Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30193 AV1 Video Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-29149 Azure Open Management Infrastructure (OMI) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30180 Azure RTOS GUIX Studio Information Disclosure Vulnerability Important 7.8 No No Info
CVE-2022-30177 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30178 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30179 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30137 Azure Service Fabric Container Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2022-22018 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-29111 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-29119 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30188 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-21123 * Intel: CVE-2022-21123 Shared Buffer Data Read (SBDR) Important N/A No No Info
CVE-2022-21125 * Intel: CVE-2022-21125 Shared Buffers Data Sampling (SBDS) Important N/A No No Info
CVE-2022-21127 * Intel: CVE-2022-21127 Special Register Buffer Data Sampling Update (SRBDS Update) Important N/A No No Info
CVE-2022-21166 * Intel: CVE-2022-21166 Device Register Partial Write (DRPW) Important N/A No No Info
CVE-2022-30164 Kerberos AppContainer Security Feature Bypass Vulnerability Important 8.4 No No SFB
CVE-2022-30166 Local Security Authority Subsystem Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30173 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30154 Microsoft File Server Shadow Copy Agent Service (RVSS) Elevation of Privilege Vulnerability Important 5.3 No No EoP
CVE-2022-30159 Microsoft Office Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30171 Microsoft Office Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30172 Microsoft Office Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30174 Microsoft Office Remote Code Execution Vulnerability Important 7.4 No No RCE
CVE-2022-30168 Microsoft Photos App Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30157 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-30158 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29143 Microsoft SQL Server Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-30160 Windows Advanced Local Procedure Call Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30151 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-30189 Windows Autopilot Device Management and Enrollment Client Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2022-30131 Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30132 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30150 Windows Defender Remote Credential Guard Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2022-30148 Windows Desired State Configuration (DSC) Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30145 Windows Encrypting File System (EFS) Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-30142 Windows File History Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2022-30147 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30140 Windows iSCSI Discovery Service Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2022-30165 Windows Kerberos Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2022-30155 Windows Kernel Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2022-30162 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30141 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2022-30143 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-30146 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-30149 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-30153 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-30161 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-30135 Windows Media Center Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30152 Windows Network Address Translation (NAT) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-32230 * Windows SMB Denial of Service Vulnerability Important N/A No No DoS
CVE-2022-22021 Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Moderate 8.3 No No RCE
CVE-2022-2007 * Chromium: Use after free in WebGPU High N/A No No RCE
CVE-2022-2008 * Chromium: Out of bounds memory access in WebGL High N/A No No RCE
CVE-2022-2010 * Chromium: Out of bounds read in compositing High N/A No No RCE
CVE-2022-2011 * Chromium: Use after free in ANGLE High N/A No No RC

* Indicates this CVE had previously been assigned by a 3rd-party and is now being incorporated into Microsoft products.

Looking at the rest of the release we that more than half of the patches this month deal with remote code execution. Seven of these deal with LDAP vulnerabilities, which is at least a decrease from the 10 LDAP patches last month. The most severe of these clocks in with a CVSS of 9.8 but would require the MaxReceiveBuffer LDAP policy to be set to a value higher than the default value. This doesn’t seem to be a common scenario. Still, the volume of bugs in LDAP over the last couple of months could indicate a broad attack surface in the component. Speaking of fertile attack surfaces, there are another six fixes for code execution bugs in the AV1 and HEVC media codecs. If you are connected to the Internet, you should automatically get updates from the Windows Store. However, if you are using these optional components in a disconnected environment, you’ll need to get these through either the Microsoft Store for Business or the Microsoft Store for Education. The same holds true for the patch addressing the RCE in the Photos App.

There are three RCE bugs receiving fixes in the Azure RTOS GUIX Studio, which provides developers a design for developing GUIs for IoT applications. What’s not clear is whether these apps will also need updates after installing these patches. There are a few RCE bugs in Office components, including a couple of interesting SharePoint bugs. Most of these require a user to open a specially crafted file. The SQL Server bug sounds pretty nasty but requires authentication. That should lessen the impact. Still, admins will need to carefully review the listed chart to determine which GDR and CU updates they require. This release includes patches impacting the iSCSI Discovery Service, Encrypting File System (EFS), and the File History component. All require some form of authentication, and the iSCSI and File History bugs require user interaction.

Moving on, there are 12 patches to address elevation of privilege (EoP) vulnerabilities. Most of these require an attacker to log on to a system and run specially crated code. There are, however, a couple of patches that stand out. The update for Azure Open Management Infrastructure (OMI) impacts multiple different Azure and SCOM components. Admins will need to touch most of these to ensure the bug is fully addressed, which will add to their workload. The patch for Azure Service Fabric doesn’t fix any bugs. Instead, it enforces the path to least privilege on Linux clusters. The bug in Kerberos affects servers with both Credential Security Service Provider (CredSSP) and Remote Credential Guard (RCG) installed. An attacker could elevate privileges and then spoof the Kerberos logon process when an RCG connection is made via CredSSP. Finally, the patch for the File Server Shadow Copy Agent Service (RVSS) only affects systems where the File Server VSS Agent Service is installed. However, on those systems, the patch alone isn’t enough. Admins must install the updates on Application and File Servers. Failure to do so could negatively impact backups and cause them to fail. See this KB article for more details.

The June release contains fixes for three Denial-of-Service (DoS) bugs. The DoS in the kernel could crash the OS, but it’s not clear how severe the bug in NAT could be. If it shut down NAT completely, it could devastate impacted enterprises. If you use NAT, treat this as a Critical update. Rapid7 also contributed a CVE in a Windows SMB that Microsoft had initially classified as a stability bug. This was silently fixed in the May 2022 updates and is being documented publicly here.

There’s a single security feature bypass being fixed this month in Kerberos AppContainer. If exploited, an attacker could bypass the Kerberos service ticketing feature that performs user access control checks. There’s also a single spoofing bug in this release for the Windows Autopilot Device Management component. There are a mountain of caveats to this bug, so if you’re using this management tool, read the bulletin carefully to determine if your systems are affected.

The release is rounded out by 11 information disclosure bugs. As previously mentioned, most of these only result in leaks consisting of unspecified memory contents. There are a couple of exceptions. The Office bug could expose device information such as resource IDs, SAS tokens, and user properties. The bug in .NET and Visual Studio could be used to intercept the API key intended for NuGet.org.

Finally, there are four info disclosure bugs addressing Intel Processor MMIO stale data vulnerabilities. An attacker could use these bugs to read privileged data across trust boundaries. Microsoft has also released Advisory ADV220002 detailing these bugs, and Intel has also released further details about this class of vulnerabilities.

Looking Ahead

The next Patch Tuesday falls on July 12, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The June 2022 Security Update Review

CVE-2022-26937: Microsoft Windows Network File System NLM Portmap Stack Buffer Overflow

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Jason McFadyen of the Trend Micro Research Team detail a recently patched code execution vulnerability in the Microsoft Windows operating system. The bug was originally discovered and reported to Microsoft by Yuki Chen. A stack buffer overflow vulnerability exists in Windows Network File System. A remote attacker can exploit this vulnerability by sending specially crafted RPC packets to a server, resulting in code execution in the context of SYSTEM. The following is a portion of their write-up covering CVE-2022-26937, with a few minimal modifications.


A stack buffer overflow vulnerability exists in Windows Network File System. The vulnerability is due to improper handling of crafted RPC responses to Portmap requests made by the Network Lock Manager (NLM) RPC program.

A remote attacker can exploit this vulnerability by sending malicious RPC calls to a target server. Successful exploitation may result in arbitrary code execution under the context of SYSTEM. Unsuccessful exploitation results in a crash of the target system.

The Vulnerability

Microsoft Windows ships with several network features designed to communicate and interact with non-Windows files shares. One of these modules is called Network File System (NFS).

NFS is a network file system protocol originally developed by Sun Microsystems in 1984. Version 2 is documented in RFC 1094. Version 3 is documented in RFC 1813. Version 4 was developed by the IETF and is documented in RFC 3010 (released December 2000) and revised in RFC 3530 (released April 2003) and RFC 7530 (released March 2015). NFS allows users to access remote file shares in the same way that the local file system is accessed. Different access levels and permissions can be set on the share, such as read-write and read-only. Additionally, IP/UID/GID/Kerberos security can be used. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. ONC RPC was originally developed by Sun Microsystems and can also be referred to as Sun RPC.

The Network Lock Manager (NLM) protocol is an extension of NFS versions 2 and 3, which provides a System V style of advisory file and record locking over the network. Since NFS versions 2 and 3 are stateless protocols, the NLM protocol was developed to manage the state of locks on files stored on NFS shares. The NLM protocol supports both synchronous and asynchronous procedures to implement locking and file-sharing functionality. Similar to NFS, NLM also uses ONC RPC to exchange control messages.

ONC RPC uses XDR packets, which can be transmitted over UDP or TCP. Over UDP, the XDR packet is contained within the UDP payload. Over TCP, XDR packets are preceded by a Fragment header (as illustrated in the following table). The most significant bit of the Fragment header indicates whether the packet is the last fragment, and the remaining 31 bits are the length of the Fragment that follows. The Fragment itself contains the XDR packet.

The structure of an ONC RPC call is as follows:

The Program field of the RPC message specifies what RPC service the message is sent to. Windows NFS server implements the NLM protocol via RPC with Program type set to 100021. It supports multiple RPC procedures, which can be specified in the Procedure field in the RPC message. A list of synchronous and asynchronous procedures supported by the NLM protocol version 3 follows:

Microsoft Windows runs the RPCBIND RPC program, which implements the Port Mapper protocol, documented in RFC 1833. The RPCBIND program converts RPC program numbers into universal addresses, which can then be used by programs to communicate over UDP or TCP. Briefly, the way it works is that when a program wishes to use RPC, it registers its ports with the host's Port Mapper. A client that wishes to issue RPC calls connects to the Port Mapper, uses various RPC calls such as GETPORT, GETADDR etc. to obtain a port on which the RPC service is available, and connects to the desired RPC service. Standard RPC program numbers have been defined and maintained by IANA and they include portmapper (100000), nfs (100003), mount daemon (100005) and hundreds of other less commonly used programs. Only the portmapper service and NFS service have standard ports of 111 and 2049 respectively.

Windows implements the RPCBIND protocol via RPC with Program type set to 100000. It supports multiple RPC procedures, which can be specified in the Procedure field in the RPC message. One of the procedures supported by the RPCBIND program when Program Version is set to 3 or 4, is GETADDR, which is procedure number 3. The reply to this RPC call contains the Universal Address associated with the callee. The format for the returned Universal Address is XDR_String, which has the following format:

A stack buffer overflow vulnerability exists in Windows Network File System. More specifically, the vulnerability is due to incorrect handling of the Universal Address field returned in GETADDR RPC replies. When Windows NFS responds to an NLM call in an asynchronous manner, the NlmGetClientAddressAndConnection() function is called. This flow is triggered either as a response to an asynchronous NLM call, such as NLM_TEST_MSG, NLM_LOCK_MSG, NLM_UNLOCK_MSG, or when the server sends an `NLM_GRANTED` call to the client, after a previous (synchronous or asynchronous) call by the client to create a lock returned the status `LCK_BLOCKED`. If the IPv6 protocol is used for communication over the ONC RPC protocol, the server will issue a GETADDR RPC call to the client to retrieve its IP address. When the Universal Address field returned by the client in the GETADDR reply is processed by the NFS server, the field is copied using memmove() into a buffer of size 96 bytes. In addition, this buffer is later referenced at an index equal to the Universal Address field’s string size and set to 0. However, the NlmGetClientAddressAndConnection() function does not verify the size of the returned Universal Address string. Therefore, if the string provided by the client is 96 bytes or longer, the buffer will be written past its boundary, resulting in the stack buffer overflow condition.

A remote attacker can exploit this vulnerability by sending an NLM request triggering an asynchronous response by the NFS server. When the server sends a GETADDR RPC request, the attacker can respond with a crafted GETADDR reply. Successful exploitation may result in arbitrary code execution under the context of SYSTEM. Unsuccessful exploitation results in a crash of the target system.

Source Code Walkthrough

The following code snippet was taken from nfssvr.sys version 10.0.17763.1999. Comments added by Trend Micro have been highlighted.

 In function NlmGetClientAddressAndConnection():

Detecting Attacks

ONC RPC uses XDR packets, which can be transmitted over UDP or TCP. Over UDP, the XDR packet is contained within the UDP payload. Over TCP, XDR packets are preceded by a Fragment header (as illustrated in the following table). The most significant bit of the Fragment header indicates whether the packet is the last fragment, and the remaining 31 bits are the length of the Fragment that follows. The Fragment itself contains the XDR packet.

The detection device must inspect all outgoing ONC RPC calls, which have the following structure:

The detection device must check if the Message Type field is 0 (Call), the Program field is 100000 (portmap), the Program Version field is larger than 2, and the Procedure field is equal to 3 (GETADDR). If found, the device must inspect the Program-specific data object. This object uses the rpcb structure, which has the following format:

If the Program Number field is set to 100021 (NLM), the detection device must inspect all incoming ONC RPC replies, which have the following structure:

The detection device must check if the XID field is equal to the XID field of the GETADDR RPC call detected, and the Message Type field is 1 (Reply). If found, the device must inspect the Program-specific data object. This object uses the XDR_String structure, which has the following format:

If the String Length field is larger than 95, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Conclusion

This bug was patched by Microsoft in May 2022 and assigned CVE-2022-26937. In their write-up, they also list disabling NFSV2 and NFSV3 as a method to mitigate attacks. However, this could lead to a loss of functionality. Applying the security update is the best method to fully address this vulnerability.

Special thanks to Guy Lederfein and Jason McFadyen of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2022-26937: Microsoft Windows Network File System NLM Portmap Stack Buffer Overflow

Is exploiting a null pointer deref for LPE just a pipe dream?

A lot of blog posts I have read go over interesting vulnerabilities and exploits but do not typically share the process behind discovery. I want to show how sometimes just manually poking around can quickly uncover vulnerabilities you might miss with other approaches to vulnerability discovery.

In my previous blog, I highlighted a tool named IO Ninja and shared why it is helpful when working with Inter-Process Communications (IPC). In this blog, I would like to show you how this tool helped me find two vulnerabilities: CVE-2021-4198 and CVE-2021-4199 in Bitdefender’s antivirus software on Windows. The exploit I wrote targets a named pipe used by the Vulnerability.scan.exe process. The first vulnerability results in a denial-of-service on almost any process within the AV. The second results in local privilege escalation by exploiting a link following issue.

Now you might be thinking, wait a minute... how does a tool that lets you communicate with named pipes allow you to find a link following vulnerability? That is what we are going to dive into next.

The pipelist tool from Sysinternals reveals that Bitdefender uses several pipes for IPC.

Figure 1 – Output of the pipelist utility from the Sysinternals tool suite.

bdservicehost.exe is one of the executables that runs as SYSTEM after installing Bitdefender. It uses these pipes to communicate with other processes on the system and might be an interesting target.

Figure 2 – List of named pipes used by bdservicehost.exe

Using IO Ninja, we can spawn a pipe server as our standard user to see if we can trigger a connection from the client. Without reading any code, we can poke around the agent GUI to see what IPC connections are being created and what the traffic looks like.

Figure 3 - Bitdefender Total Security GUI

The screenshot below shows that we receive a connection from the client of the pipe that sends data to our named pipe server every time we open the agent GUI. This can be done by double clicking the Bitdefender icon in the system tray or opening it from the start menu.

Figure 4 - Connection from client to our named pipe server

What is interesting here is that the connection remains open. This allows us to send data back to the client. I took the first 16 bytes of data that was being sent to the server and echoed it back to the client multiple times to see if anything interesting would happen. I was also looking to see if the pipe connection would remain open after sending the data.

Figure 5 - Pipe client disconnects after sending data to it

After sending several messages, the client disconnects, and we get a popup box from Bitdefender informing the user that something went wrong within the AV. Take note of the “x” at the top right for dismissing the dialog box. This will become relevant later.

Figure 6 - Bitdefender telling us that we broke something.

After seeing this message, I knew that debugging information in some shape or form must be getting saved or logged.  I fired up Process Monitor from Sysinternals to see if a crash dump file, which I can further analyze in a debugger, was created.

As it turns out, an executable named “BDReinit.exe”, which is Bitdefender’s own crash handler, produces a crash dump file for us on the system.

Figure 7 – Process Monitor showing crash dump files being created by BDReinit.exe.

Another interesting discovery here was finding out that the folder to which the .dmp file is being written to is readable and writeable by standard users.

Figure 8 - Permissions of the directory storing the dump files.

Unfortunately, after looking at the dump file, I concluded the crash alone was not very interesting, and the process being crashed runs as our current user. At this point, I knew I had a potential local DoS on the AV but there had to be more to chew on here.

Figure 9 - NULL pointer dereference: CVE-2021-4198

After crashing this first process “seccenter.exe,” which is Bitdefender’s main GUI interface, I realized that I was still getting connections to my named pipe server. I was able to crash almost any process related to the AV by simply spamming the incoming pipe connections with those 16 bytes as soon as a client connected. I sat in front of my computer, watching the AV processes fall like dominos one after the other in process explorer.

I knew that kicking off a “Vulnerability Scan” in the GUI would spawn vulnerability.scan.exe, which ran as SYSTEM. I quickly tried to see if I could also crash this privileged process.

Figure 10 - Process Monitor showing crash dump files being created by BDReinit.exe, this time running as SYSTEM.

Ahh, the same “BDReinit.exe” process runs again, but this time it runs as SYSTEM. Based on the file name of the dump, we know we can also crash “Vulnerability.scan.exe,” and it writes the dump to disk as SYSTEM.

When looking for link following vulnerabilities, there are a few directories that are of immediate interest.

         C:\ProgramData
         C:\windows\temp
         C:\Users\[standard user]\AppData

I often look for privileged file writes and delete operations in these directories.

In this case, a .dmp file is being written to this directory as SYSTEM when a highly privileged process that is part of the AV crashes. This alone is not very interesting as we do not control the contents of the dump being written, and it’s the same exact crash from before.

I further analyzed the Process Monitor log and discovered that “BDReinit.exe” was doing two very dangerous things. First, it was writing a very permissive DACL to a file with a predictable name in a different directory. This directory also allowed a standard user read and write access, and the DACL write happened every time a crash occurred.

Figure 11 - Read and write access for everyone

The permissive DACL would get written to this file as SYSTEM if you crashed a process running as SYSTEM within Bitdefender. In this case, I just chose to again crash “Vulnerability.scan.exe” because of how easy it was to trigger. All I had to do was kick off a vulnerability scan in the GUI, and I would get a connection to my named pipe server from this process.

Figure 12 - Kicking off a vulnerability scan

Figure 13 - BDReinit.exe ACL write after crashing Vulnerability.scan.exe

One of my favorite parts about logic bugs like this is that exploiting them is typically very quick and easy. All we need to do to escalate to SYSTEM is redirect the permissive DACL write to a DLL used by the system, modify the contents of that DLL, and then have it get loaded. To do this redirection we just need one symbolic link and a target DLL.

One great candidate for the job is:

         C:\Windows\System32\spool\Drivers\x64\3\PrintConfig.dll

This is because a standard user can easily trigger a print job which will force svchost.exe to load our modified DLL as SYSTEM.

Figure 14 - Creating Symbolic link

Figure 15 - Redirecting BDReinit.exe DACL write

Figure 16 - Svchost.exe Loading modified DLL

Putting this all together, the following screenshot demonstrates executing code at SYSTEM using the techniques described.

Figure 17 - Putting it all together

The second major issue I found was related to the crash dump itself. If you clicked the “x” at the top right of the popup box I showed earlier, “BDReinit.exe” or “BdSubWiz.exe” which is the submission wizard, would delete the crash dump as your current user. If the user waited or ignored it for a while, the dialog box would timeout and delete the dump file as SYSTEM if the process that crashed was running as SYSTEM!

Figure 18- Log of BDReinit.exe arbitrary file deletion PoC

In the above screenshot, you can see how we can redirect this highly privileged file deletion to any file on the system. You can also use the techniques described in this blog to achieve privilege escalation and execute code at SYSTEM. Again, this is because the crash dump was being written and deleted from a location that our standard user had read and write access to regardless of the user that was running the crashed process. Furthermore, the files in that folder were not protected at all, so deleting them and replacing one with our link before the timeout was not an issue.

Figure 19 - Unrestricted file permissions

Conclusion

Sometimes vulnerability discovery isn’t super methodical and that’s okay! I did not spend any time reversing the functions responsible for IPC in this application to figure out what data to send over the pipe. However, I identified an attack surface and started poking around. This led me to an entirely different attack surface where there were some critical vulnerabilities.

I hope this blog inspires and enables you to do the same with your targets. Furthermore, I hope it reminds you to look at custom crash handlers and their dialog boxes – both for bugs and to make sure you aren’t unintentionally giving away your research. 😀

Below is a Procmon filter I use that you can download and import to search for link-following vulnerabilities. Just be sure to either change your username to “lowpriv,” or edit the filter before you use it. You can download it here.

Keep an eye out for future blogs where I will share details on other vulnerabilities I have found. Until then, you can follow me @izobashi and the team @thezdi on Twitter for the latest in exploit techniques and security patches.

Happy hunting!

 

Tools used:

-       IO Ninja
-       SysInternals
-       Symboliclink Testing Tools

Advisories:

https://www.bitdefender.com/support/security-advisories/incorrect-permission-assignment-for-critical-resource-vulnerability-in-bdreinit-exe-va-10017/

https://www.bitdefender.com/support/security-advisories/messaging_ipc-dll-null-pointer-dereference-in-multiple-bitdefender-products-va-10016/

Other Resources:       

https://www.zerodayinitiative.com/blog/2021/11/17/mindshare-using-io-ninja-to-analyze-npfs

https://decoder.cloud/2019/11/13/from-arbitrary-file-overwrite-to-system/

https://www.zerodayinitiative.com/blog/2022/3/16/abusing-arbitrary-file-deletes-to-escalate-privilege-and-other-great-tricks

Is exploiting a null pointer deref for LPE just a pipe dream?

Pwn2Own Vancouver 2022 - The Results

18 May 2022 at 19:08

Pwn2Own Vancouver for 2022 is underway, and the 15th anniversary of the contest has already seen some amazing research demonstrated. Stay tuned to this blog for updated results, picture, and videos from the event. We’ll be posting it all here - including the most recent Master of Pwn leaderboard.

Jump to Day One results; Jump to Day Two results; Jump to Day Three results

Here are the current standings for the Master of Pwn:

Current as of May 20, 12:00 Pacific

Day One - May 18, 2022

SUCCESS - Hector “p3rr0” Peralta was able to demonstrate an improper configuration against Microsoft Teams. He earns $150,000 and 15 Master of Pwn points.

Hector “p3rr0” Peralta demonstrates a improper configuration bug on Microsoft Teams by launching calc.

SUCCESS - Billy Jheng Bing-Jhong (@st424204), Muhammad Alifa Ramdhan (@n0psledbyte), and Nguyễn Hoàng Thạch (@hi_im_d4rkn3ss) of STAR Labs successfully used an OOB Read and OOB Write to achieve escalation on Oracle Virtualbox. They earn $40,000 and 4 Master of Pwn points.

SUCCESS - Masato Kinugawa was able to execute a 3-bug chain of injection, misconfiguraton and sandbox escape against Microsoft Teams, earning $150,000 and 15 Master of Pwn points.

SUCCESS - Manfred Paul (@_manfp) successfully demonstrated 2 bugs - prototype pollution and improper input validation - on Mozilla Firefox, earning him $100,000 and 10 Master of Pwn points.

Manfred Paul (left) demonstrates his 2 bug vulnerability submission on Mozilla Firefox to ZDI Analysts Hossein Lotfi and Michael DePlante.

SUCCESS - Marcin Wiązowski was able to execute an out-of-bounds write escalation of privilege on Microsoft Windows 11, earning $40,000 and 4 Master of Pwn points, and high praise on the accompanying whitepaper from the Microsoft team.

SUCCESS - Team Orca of Sea Security (security.sea.com) was able to execute 2 bugs on Ubuntu Desktop - an Out-of-Bounds Write (OOBW) and Use-After-Free (UAF) - earning $40,000 and 4 Master of Pwn points.

Team Orca of Sea Security successfully demonstrates their OOBW and UAF on Ubuntu Desktop.

SUCCESS - Daniel Lim Wee Soong (@daniellimws), Poh Jia Hao (@Chocologicall), Li Jiantao (@CurseRed) & Ngo Wei Lin (@Creastery) of STAR Labs successfully demonstrated their zero-click exploit of 2 bugs (injection and arbitrary file write) on Microsoft Teams. They earn $150,000 and 15 Master of Pwn points.

SUCCESS - Manfred Paul (@_manfp) successfully scored his second win of the day with an out-of-band write on Apple Safari, earning him another $50,000 and 5 additional Master of Pwn points.

SUCCESS - Phan Thanh Duy (@PTDuy and Lê Hữu Quang Linh (@linhlhq of STAR Labs earned $40K and 4 Master of Pwn points for a Use-After-Free elevation of privilege on Microsoft Windows 11.

SUCCESS - Keith Yeo (@kyeojy) earned $40K and 4 Master of Pwn points for a Use-After-Free exploit on Ubuntu Desktop.

Day Two - May 19, 2022

SUCCESS and BUG COLLISION - On the first attempt of the day, David BERARD and Vincent DEHORS from @Synacktiv were able to demonstrate 2 unique bugs (Double-Free & OOBW) with collision on a known sandbox escape on a Tesla Model 3 Infotainment System. They earn $75,000 and 7.5 Master of Pwn points, and although they don't win the car outright, they have made enough to go pick one up themselves!

First attempt of the day at Tesla. From left to right: 2 representatives from Tesla (standing and seated), ZDI Analyst Michael DePlante, Sr. Director of Vulnerability Research (ZDI) Brian Gorenc, David BERARD and Vincent DEHORS of Synacktiv.

FAILURE - On the second attempt of day 2, namnp was unable to get their exploit of Microsoft Windows 11 working within the time allotted.

SUCCESS - Bien Pham (@bienpnn) was able to execute a Use After Free bug leading to elevation of privilege on Unbuntu Desktop, earning $40,000 and 4 Master of Pwn points.

Local elevation of privilege on Ubuntu Desktop courtesy of Bien Pham.

FAILURE - @Jedar_LZ was unable to get today's second Tesla attempt working within the time allotted. On a positive note, @thedzi decided to acquire the details of the exploit and disclose them to Tesla.

SUCCESS - T0 was able to successfully show an improper access control bug leading to elevation of privilege on Microsoft Windows 11 - earning $40,000 and 4 Master of Pwn points.

SUCCESS - On the final attempt of Day 2, Zhenpeng Lin (@Markak_), Yueqi Chen (@Lewis_Chen_), and Xinyu Xing (@xingxinyu) of Team TUTELARY from Northwestern University successfully demonstrated a Use After Free bug leading to elevation of privilege on Ubuntu Desktop. This earns him $40,000 and 4 Master of Pwn points.

From left: Yueqi Chen of Team TUTELARY of Northwestern University with ZDI Analysts Tony Fuller and Bobby Gould.

Day Three - May 20, 2022

FAILURE - On the first attempt of day 3, Team DoubleDragon: Yonghwi Jin (@jinmo123) of Theori, and Yongjin Kim (@adm1nkyj1) of Enki was unable to get their exploit of Microsoft Teams working within the time allotted. All is not lost though, in that Team Double Dragon was able to get their research into the regular ZDI process.

SUCCESS - nghiadt12 from Viettel Cyber Security was able to successfully show an escalation of privilege via Integer Overflow on Microsoft Windows 11 - earning $40,000 and 4 Master of Pwn points.

EOP via Integer Overflow on Windows 11 courtesy of nghiadt12 from Viettel Cyber Security

SUCCESS - Billy Jheng Bing-Jhong (@st424204) STAR Labs was able to successfully demonstrate a Use-After-Free exploit on Ubuntu Desktop - earning another $40,000 and 4 Master of Pwn points.

SUCCESS - vinhthp1712 successfully achieved Elevation of Privilege via Improper Access Control on Microsoft Windows 11. vinhthp1712 earns $40,000 and 4 Master of Pwn points.

SUCCESS - On the final attempt of the competition, Bruno PUJOS (@brunopujos) from REverse Tactics successfully achieved Elevation of Privilege via Use-After-Free on Microsoft Windows 11. Bruno earns $40,000 and 4 Master of Pwn points.

Bruno PUJOS from REverse Tactics drops an EOP via UAF on Microsoft Windows 11.

That concludes the regular scheduled programming for our event! This year, we had a total of 21 attempts from 17 contestants with Trend Micro and ZDI awarding $1,155,000! We can’t wait to share more details in the near future about our fall event, so stay tuned!

As always, follow us on Twitter for the latest results, update, and breaking news.

Thanks again to our partners Tesla, Zoom, and Microsoft as well as our sponsor VMware. Thanks also to the researchers who participate and to the vendors for providing fixes for what was discovered and reported during the contest. As a reminder, vendors have 90 days to produce a fix for all vulnerabilities disclosed.

Pwn2Own Vancouver 2022 - The Results

Pwn2Own Vancouver 2022 - The Schedule

17 May 2022 at 23:47

Welcome to Pwn2Own Vancouver 2022! This year marks the 15th anniversary of the contest, and we plan on celebrating by putting some amazing research on display. For this year’s event, we have 17 contestants attempting to exploit 21 targets across multiple categories. As always, we began our contest with a random drawing to determine the order of attempts. If you missed it, you can watch the replay here.

The complete schedule for the contest is below (all times Pacific [GMT -7:00]).

Note: All times subject to change - You can see the results and live updates here once they become available. Entries marked with a 📷 icon will be live-streamed on YouTube, Twitch, and Twitter.

Wednesday, May 18, 2022

0930: Hector “p3rr0” Peralta targeting Microsoft Teams in the Enterprise Communications category

📷  1030: Billy Jheng Bing-Jhong (@st424204), Muhammad Alifa Ramdhan (@n0psledbyte), and Nguyễn Hoàng Thạch (@hi_im_d4rkn3ss) of STAR Labs targeting Oracle VirtualBox with a guest-to-host escape in the Virtualization category

📷  1200: Masato Kinugawa targeting Microsoft Teams in the Enterprise Communications category

📷  1300: Manfred Paul (@_manfp) targeting Mozilla Firefox (including sandbox escape) in the Web Browser category

1330: Marcin Wiązowski targeting Microsoft Windows 11 in the Local Elevation of Privilege category

1400: Team Orca of Sea Security (security.sea.com) targeting Ubuntu Desktop in the Local Elevation of Privilege category

1450: Daniel Lim Wee Soong (@daniellimws), Poh Jia Hao (@Chocologicall), Li Jiantao (@CurseRed) & Ngo Wei Lin (@Creastery) of STAR Labs targeting Microsoft Teams in the Enterprise Communications category

📷  1550: Manfred Paul (@_manfp) targeting Apple Safari in the Web Browser category

📷  1650: Keith Yeo (@kyeojy) targeting Ubuntu Desktop in the Local Elevation of Privilege category

1720: Phan Thanh Duy (@PTDuy) and Lê Hữu Quang Linh (@linhlhq) of STAR Labs targeting Microsoft Windows 11 in the Local Elevation of Privilege category

Thursday, May 19, 2022

 📷  1000: David BERARD and Vincent DEHORS from @Synacktiv target the Tesla Model 3 Infotainment System (with Sandbox Escape) in the Automotive category

 1100: namnp targeting Microsoft Windows 11 in the Local Elevation of Privilege category

 📷  1130: Bien Pham (@bienpnn) targeting Ubuntu Desktop in the Local Elevation of Privilege category

 📷 1300: @Jedar_LZ targeting the Tesla Model 3 Diagnostic Ethernet (with Root Persistence) in the Automotive category

 1400: T0 targeting Microsoft Windows 11 in the Local Elevation of Privilege category

 📷  1430: TUTELARY from Northwestern University targeting Ubuntu Desktop in the Local Elevation of Privilege category

 Friday, May 20, 2022

 📷  1000: Team DoubleDragon: Yonghwi Jin (@jinmo123) of Theori, and Yongjin Kim (@adm1nkyj1) of Enki targeting Microsoft Teams in the Enterprise Communications category

 1030: nghiadt12 from Viettel Cyber Security targeting Microsoft Windows 11 in the Local Elevation of Privilege category

📷  1100: Billy Jheng Bing-Jhong (@st424204) of STAR Labs targeting Ubuntu Desktop in the Local Elevation of Privilege category

1300: vinhthp1712 targeting Microsoft Windows 11 in the Local Elevation of Privilege category

📷  1330: Bruno PUJOS (@brunopujos) from REverse Tactics targeting Microsoft Windows 11 in the Local Elevation of Privilege category

 📷  1520: Award Ceremony

Pwn2Own Vancouver 2022 - The Schedule

The May 2022 Security Update Review

10 May 2022 at 17:29

It’s the fifth second Tuesday of 2022, which also means it’s the also the fifth Patch Tuesday of the year, and it brings with it the latest security updates from Adobe and Microsoft. This is also the last release before Pwn2Own Vancouver, which means multiple participants will be holding their breath to see if their exploits still work or were patched out. Take a break from your regularly scheduled activities and join us as we review the details of their latest security offerings.

Adobe Patches for May 2022

For May, Adobe released five bulletins addressing 18 CVEs in Adobe CloudFusion, InCopy, Framemaker, InDesign, and Adobe Character Animator. A total of 17 of these CVEs were reported by ZDI vulnerability researcher Mat Powell. The largest of these patches is the fix for Framemaker with 10 CVEs in total. Nine of these are Critical-rated bugs that could lead to code execution, mostly due to Out-of-Bounds (OOB) Write vulnerabilities. The patch for InDesign addresses three Critical-rated bugs that could lead to code execution. Two of these are due to OOB Writes while one is an OOB Read. The patch for InCopy also fixes three Critical-rated code execution bugs. In this case, it’s two OOB Writes plus a Use-After-Free (UAF). The patch for Character Animator fixes a single, Critical-rated OOB Write code execution bug. Finally, the ColdFusion patch corrects an Important-rated reflected cross-site scripting (XSS) bug.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes all of these updates as priority 3.

Microsoft Patches for May 2022

For May, Microsoft released 74 new patches addressing CVEs in Microsoft Windows and Windows Components, .NET and Visual Studio, Microsoft Edge (Chromium-based), Microsoft Exchange Server, Office and Office Components, Windows Hyper-V, Windows Authentication Methods, BitLocker, Windows Cluster Shared Volume (CSV), Remote Desktop Client, Windows Network File System, NTFS, and Windows Point-to-Point Tunneling Protocol. This is in addition to the 36 CVEs patched by Microsoft Edge (Chromium-based) in late April.

Of the 74 CVEs released today, seven are rated Critical, 66 are rated Important, and one is rated Low in severity. A total of seven of these bugs came through the ZDI program. Historically speaking, this volume is in line with May releases in the past, with 19 more than May 2021, but 5 less than May 2019. The entire 2020 release volume was somewhat of an anomaly, so comparisons there aren’t as useful.

One of the bugs released today is listed as publicly known and under active attack, while two others are listed as publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerability currently being exploited:

-       CVE-2022-26925 – Windows LSA Spoofing Vulnerability
This complex-sounding vulnerability could allow an unauthenticated attacker to force a domain controller to authenticate against another server using NTLM. The threat actor would need to be in the logical network path between the target and the resource requested (e.g., Man-in-the-Middle), but since this is listed as under active attack, someone must have figured out how to make that happen. Microsoft notes this would be a CVSS 9.8 if combined with NTLM relay attacks, making this even more severe. In addition to this patch, sysadmins should review KB5005413 and Advisory ADV210003 to see what additional measures can be taken to prevent NTLM relay attacks. Also note this patch affects some backup functionality on Server 2008 SP2. If you’re running that OS, read this one carefully to ensure your backups can still be used to restore.

 -       CVE-2022-26923 – Active Directory Domain Services Elevation of Privilege Vulnerability
This bug was submitted through the ZDI program by Oliver Lyak (@ly4k_) of the Institut for Cyber Risk. The specific flaw exists within the issuance of certificates. By including crafted data in a certificate request, an attacker can obtain a certificate that allows the attacker to authenticate to a domain controller with a high level of privilege. In essence, any domain authenticated user can become a domain admin if Active Directory Certificate Services are running on the domain. This is a very common deployment. Considering the severity of this bug and the relative ease of exploit, it would not surprise me to see active attacks using this technique sooner rather than later.

 -       CVE-2022-26937 – Windows Network File System Remote Code Execution Vulnerability
This CVSS 9.8-rated bug could allow remote, unauthenticated attackers to execute code in the context of the Network File System (NFS) service on affected systems. NFS isn’t on by default, but it’s prevalent in environments where Windows systems are mixed with other OSes such as Linux or Unix. If this describes your environment, you should definitely test and deploy this patch quickly. Microsoft notes NFSv4.1 is not exploitable, so upgrade from NFSv2 or NFSv3 if possible.

 -       CVE-2022-29972 – Insight Software: Magnitude Simba Amazon Redshift ODBC Driver
This update was actually released yesterday and is complicated enough for Microsoft to blog about the bug and how it affects multiple Microsoft services. Microsoft also released its first advisory of the year, ADV220001, with additional information about the vulnerability. The flaw exists in the third-party ODBC data connector used to connect to Amazon Redshift, in Integration Runtime (IR) in Azure Synapse Pipelines, and Azure Data Factory, and could allow an attacker to execute remote commands across Integration Runtimes. If you use these services, review the blog and advisory to ensure you understand the risks to your services.

Here’s the full list of CVEs released by Microsoft for May 2022:

CVE Title Severity CVSS Public Exploited Type
CVE-2022-26925 Windows LSA Spoofing Vulnerability Important 8.1 Yes Yes Spoofing
CVE-2022-29972 Insight Software: CVE-2022-29972 Magnitude Simba Amazon Redshift ODBC Driver Critical N/A Yes No RCE
CVE-2022-22713 Windows Hyper-V Denial of Service Vulnerability Important 5.6 Yes No DoS
CVE-2022-26923 Active Directory Domain Services Elevation of Privilege Vulnerability Critical 8.8 No No EoP
CVE-2022-21972 Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-23270 Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-22017 Remote Desktop Client Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-26931 Windows Kerberos Elevation of Privilege Vulnerability Critical 7.5 No No EoP
CVE-2022-26937 Windows Network File System Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-23267 .NET and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-29117 .NET and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-29145 .NET and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-29127 BitLocker Security Feature Bypass Vulnerability Important 4.2 No No SFB
CVE-2022-29109 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-29110 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-21978 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 8.2 No No EoP
CVE-2022-29107 Microsoft Office Security Feature Bypass Vulnerability Important 5.5 No No SFB
CVE-2022-29108 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29105 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26940 Remote Desktop Protocol Client Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-22019 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-26932 Storage Spaces Direct Elevation of Privilege Vulnerability Important 8.2 No No EoP
CVE-2022-26938 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-26939 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29126 Tablet Windows User Interface Application Core Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-30129 Visual Studio Code Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29148 Visual Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26926 Windows Address Book Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23279 Windows ALPC Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-26913 Windows Authentication Security Feature Bypass Vulnerability Important 7.4 No No SFB
CVE-2022-29135 Windows Cluster Shared Volume (CSV) Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29150 Windows Cluster Shared Volume (CSV) Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29151 Windows Cluster Shared Volume (CSV) Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29138 Windows Clustered Shared Volume Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29120 Windows Clustered Shared Volume Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-29122 Windows Clustered Shared Volume Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-29123 Windows Clustered Shared Volume Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-29134 Windows Clustered Shared Volume Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-29113 Windows Digital Media Receiver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-29102 Windows Failover Cluster Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-29115 Windows Fax Service Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-22011 Windows Graphics Component Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-26934 Windows Graphics Component Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-29112 Windows Graphics Component Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-26927 Windows Graphics Component Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-24466 Windows Hyper-V Security Feature Bypass Vulnerability Important 4.1 No No SFB
CVE-2022-29106 Windows Hyper-V Shared Virtual Disk Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29133 Windows Kernel Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2022-29142 Windows Kernel Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29116 Windows Kernel Information Disclosure Vulnerability Important 4.7 No No Info
CVE-2022-22012 Windows LDAP Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2022-22013 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-22014 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29128 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29129 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29130 Windows LDAP Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2022-29131 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29137 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29139 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-29141 Windows LDAP Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-26933 Windows NTFS Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-22016 Windows PlayToManager Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29104 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-29132 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-29114 Windows Print Spooler Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-29140 Windows Print Spooler Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-29125 Windows Push Notifications Apps Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-29103 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26930 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-22015 Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-26936 Windows Server Service Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-29121 Windows WLAN AutoConfig Service Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-26935 Windows WLAN AutoConfig Service Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-30130 .NET Framework Denial of Service Vulnerability Low 3.3 No No DoS

Looking at the remaining Critical-rated patches, there are two that affect the Windows implementation of Point-to-Point Tunneling Protocol (PPTP) that could allow an RCE. Microsoft notes an attacker would need to win a race condition to successfully exploit these bugs, but not every race condition is identical. In other words, an attacker may pull a Rich Strike and win that race. There’s a Critical-rated Elevation of Privilege (EoP) bug in Microsoft Kerberos, but no further information is provided. It’s unusual for an EoP to be rated Critical, so the privilege escalation must result in something beyond just a domain account. Finally, there’s another patch for the RDP Client, which seem to be coming at least once a month these days. An attacker would need to convince an affected system to connect to a specially crafted RDP server to gain code execution.

There are 20 other patches for RCE bugs in this month’s release, and half of those deal with LDAP vulnerabilities. The most severe of these clocks in with a CVSS of 9.8 but would require the MaxReceiveBuffer LDAP policy to be set to a value higher than the default value. It’s not clear if that is a common or rare configuration. The others would require some form of authentication. Three of the remaining RCEs came through the ZDI program. ZDI vulnerability researcher Hossein Lotfi discovered a bug in Windows Media Foundation that exists within the parsing of AVI files. The research known as ZhangYang found a heap overflow bug in Visual Studio, and Uncodable reported a use-after-free (UAF) bug in the Windows Graphic component. The remaining RCE bugs require some form of user interaction – mostly clicking on a link or opening a file. The only exception to this is the bugs in SharePoint, which requires an authenticated user with page creation permissions. By default, any authenticated user can create their own site where they have the necessary permissions.   

Moving on to EoP-related patches, there are 21 total privilege escalation bugs in the release, including the two previously mentioned. Most of these require an attacker to log on a run their specially crafted code or somehow convince (or trick) an authorized user to do so. However, there are a couple of patches that stand out. The most obvious is the patch for Exchange Server, which requires an admin to specifically prepare Active Directory before installing the patch. This entails running specific commands from the command prompt once the patch has been downloaded. Microsoft doesn’t indicate what could happen if these steps are not followed, but the bug allows an Exchange admin to become a Domain Admin, so ensure you take the appropriate steps to fully remediate this vulnerability. There’s a privilege escalation in the Remote Access Connection Manager, but without further details from Microsoft, it’s not clear how this vulnerability manifests. Finally, there are two EoP fixes for the Print Spooler, with one coming from Oliver Lyak through ZDI. The bug he reported could allow an attacker to create a symbolic link, which could then cause the service to load an arbitrary DLL.

Speaking of the Print Spooler, two of the 17 info disclosure bugs patched by this month’s release impact this component, and both were reported by Oliver through ZDI. These bugs result from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage these vulnerabilities to disclose information in the context of SYSTEM. Most of the other Info Disclosure bugs in this release only result in leaks consisting of unspecified memory contents. The other exception to this would be the bug in the Windows Server Service (aka LanManServer). Microsoft states that an attacker could confirm the presence of specific file names and users over an internal network, but they don’t state how this would occur.

There are four fixes for Security Feature Bypass (SFB) bugs in this release, and each one deserves a mention. The first relates to a Virtual Machine Switch with virtual networking in Hyper-V Network Virtualization (HNV). An attacker could bypass extended ACLs and other checks, which implies one guest OS could impact a different guest OS on the same server. Up next is a bug in Office that could allow an attacker to gain personally identifiable information (PII) by bypassing the “ThisDocument.RemovePersonalInformation” functionality. If you’re sharing files online but want your personal information removed, be sure to apply this update. The update for Windows Authentication addresses a vulnerability that could allow Man-in-the-Middle (MITM) attackers to decrypt and read or modify TLS traffic between the client and server. Finally, there is a bypass of BitLocker Device Encryption that requires physical access but could allow an attacker to gain access to encrypted data in certain scenarios. These final two bugs may be a bit unlikely to be seen in the wild, but if they are, the impact would be quite severe. Bugs like these are the ones sought by advanced threat actors for use on high-profile targets.

The May release is rounded out by six updates to address Denial-of-Service bugs in Hyper-V, the WLAN Autoconfig Service, and .NET and Visual Studio. The WLAN vulnerability is limited to a logically adjacent topology and can’t be reached from the internet. The bug in Hyper-V is listed as public, but Microsoft provides no information on where it was posted or how much detail was exposed. There are multiple DoS bugs listed for .NET and Visual Studio, but no further details are provided. One of these .NET bugs is the lone Low-severity bug in this release.

There is one new advisory for May covering improvements to Azure Data Factory and Azure Synapse Pipeline. This was previously mentioned (above) and is in response to CVE-2022-29972. While certainly not new, the latest servicing stack updates can be found in the revised ADV990001.

Looking Ahead

The next Patch Tuesday falls on June 14, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean! (And hope to see you in Vancouver!)

The May 2022 Security Update Review

What to Expect when Exploiting: A Guide to Pwn2Own Participation

So you’ve heard of Pwn2Own and think you are up to the challenge of competing in the world’s most prestigious hacking competition. Great! We would love to have you! However, there are a few things you should know before we get started. With Pwn2Own Vancouver just around the corner, here are 10 things you need to know before participating in Pwn2Own.

1.     You need to register before the contest.

We try to make this as apparent as possible in the rules, but we still have people walk into the room on the first day of the contest hoping to participate. There are a lot of logistics around Pwn2Own, so we need everyone to complete their registration before the contest starts. We can’t support anyone who wants to join on the first day of the competition.

2.     You need to answer the vetting email.

Again, the logistics of running the Pwn2Own competition can be daunting. One way we prepare is by vetting all entries before registration closes. We need to understand the nature of your exploit to ensure it fits within the rules and to ensure we have everything we need on hand to run the attempt. For example, we need to know how you plan on demonstrating if the exploit is successful. If you answer, “Our exploit will provide a root shell when it has succeeded” – we know you have a solid plan and that it is within the rules. If you tell us you need to start as an admin user and require four reboots, your entry is unlikely to qualify. We’ll also ask for things like other user interactions or the need for a Man-in-the-Middle (MitM). These could disqualify the entry – or it could be fine. It depends on the target and details, which is why we want to know before the competition. It’s not fair to any of the contestants to have them think their exploit is a winner just to be disqualified during the contest.

3.     What should we call you?

We know people enter Pwn2Own to win cash and prizes, but they want recognition, too. We’re more than happy to include your Twitter handle, your company name, or just about anything else. Just let us know. We try to pre-stage a lot of our communications, so an omission or misspelling could take a bit to get fixed, and we want to give contestants the attention they deserve. You’d be surprised how many people wait until during or after the event to clarify how they wish to be mentioned.

4.     Will you be participating locally or remotely?

This is a newer question but opening up the contest to remote participation has allowed many to participate that otherwise would not. However, remote contestants have a few extra hurdles the on-site participants do not. For remote participants, all artifacts must be submitted to the ZDI prior to registration closing. This includes things like the white paper, the exploit, and any further details needed for the entry. Contestants competing in person have until the contest begins to have these deliverables ready.

5.     Are you aware a white paper is required for each entry?

This is one aspect that many don’t realize. Each entry in Pwn2Own needs an accompanying white paper describing the vulnerabilities used during the attempt. These white papers are critical in the judging of the competition, especially if exploits from different contestants seem similar. For example, if two groups both use a use-after-free bug against a target, is it the same bug? Maybe. Maybe not. A clearly written white paper will help us understand your research and identify whether it is unique or a bug collision. It also helps the vendor pinpoint the exact place to look at when they start working on the fix.

6.     Ask questions before the competition.

There can be a lot of nuances in exploiting targets at Pwn2Own. How will we judge certain scenarios? How will the targets be configured? Does this type of exploit qualify for this bonus? Is the target in this configuration or that configuration? Is this software completely in the default configuration, or is this commonly applied setting used? There are a lot of very reasonable questions to ask before the contest, and we try to answer every one of them the best we can. If you are thinking about participating but have a specific configuration or rule-related questions, please e-mail us. Questions asked over Twitter or other means may not be answered in a timely manner. It might seem archaic to some, but e-mail makes it easier to track inquiries and ensure they get responses.

7.     Be prepared for things to go wrong.

Five minutes seems like plenty of time – until you’re on stage at Pwn2Own and there’s a clock counting down. If your first attempt fails, do you have a plan? What are you going to check? Can you adjust your exploit in a meaningful way within the allotted time? Certain types of exploits work better at Pwn2Own than others. For example, timing attacks and race conditions might not be the best choice to use at Pwn2Own. Yes, your exploit may work 100% of the time before you arrive at the contest, but what if it doesn’t when you’re on stage? Make a plan B, and probably a plan C and D as well.

8.     Are you participating as an individual, a part of a team, or representing a company?

While we do want maximum participation in each contest, we also need to place some restrictions on how that participation occurs. For example, if you are representing a company, you can’t also participate as an individual. If you are a part of a small team, you can’t also represent a company. This restriction helps keep the contest fair to everyone involved and prevents bug sharing meant to skew the overall results.

9.     When you arrive at the contest, take a minute to confirm the target versions.

Before the contest begins – even before we do the drawing for order – we allow contestants to verify configurations and software versions of the targets. We always use the latest and greatest versions of available software as Pwn2Own targets, and vendors are known to release patches right before the competition in a last-ditch attempt to thwart contestants. It’s a good idea to take a minute and double-check the versions in the contest are the same versions you were testing back home. We will communicate the versions before the contest, so you will know what to target.

10.  Rub a rabbit’s foot, grab a four-leafed clover, or do whatever else brings you luck.

Thanks to the drawing for order at the beginning of each contest, there is a degree of randomness to the competition. You could end up with a great spot in the schedule, or you could end up late in the contest when the chances for bug collisions are higher. But you can’t rely on luck, either. Some teams will just move on to a new target as soon as they find a bug to try to get as many entries in as possible and hope for a good draw - even if their bugs are low-hanging fruit. However, the teams that really want to compete for Master of Pwn spend a lot of time going deep and finding bugs other teams may miss. Pwn2Own is certainly a competition of skill but having a little luck (at least good luck) never hurts either.

Of course, there’s a lot more to participating in Pwn2Own than just these 10 things, but these will definitely help you prepare for the competition and, hopefully, increase your chances of winning. We really do root for all of the contestants, and we want to do all we can to increase your chances of success. Still, we need to adjudicate the contest fairly for all competitors. If you are on the fence about participating in Pwn2Own, I hope this guidance helps you find the right path to joining us. We celebrate the 15th anniversary of the contest this year in Vancouver, and we’d love to see you there.

What to Expect when Exploiting: A Guide to Pwn2Own Participation

Pwn2Own Miami 2022 Results

19 April 2022 at 16:55

Pwn2Own Miami for 2022 has wrapped up, and it was an amazing three days of competition. In total, we awarded $400,000 for 26 unique 0-days (plus a few bug collisions). With 90 points accumulated over three days, the team of Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) have won Master of Pwn! You can see all of the points and full results from all entries below.

Daan Keuper (center left) and Thijs Alkemade receive their Master of Pwn jackets and trophy from ZDI’s Dustin Childs (far left) and ZDI Director Brian Gorenc

Thanks again to all of the competitors who participated. We couldn’t have a contest without them. Thanks also to the participating vendors for their cooperation and for providing fixes for the bugs disclosed throughout the contest. As a reminder, vendors have 120 days to produce a fix for all vulnerabilities reported.

Jump to Day One results; Jump to Day Two results; Jump to Day Three results

Final Master of Pwn standings

Day One - April 19, 2022

SUCCESS - 20urdjk was able to execute their DoS attack against Unified Automation C++ Demo Server. They earn $5,000 and 5 Master of Pwn points.

SUCCESS - Sam Thomas (@_s_n_t) from @pentestltd combined an auth bypass and a deserialization bug to get code execution. They win $20,000 and 20 points towards Master of Pwn.

SUCCESS - Or Peles, Omer Kaspi and Uriya Yavnieli from JFrog Security Research leveraged a Use-After-Free (UAF) bug to create a DoS on the Unified Automation C++ Demo Server. They win $5,000 and 5 Master of Pwn points.

SUCCESS - After a slight logistical delay, Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) used a deserialization bug to get their code executing on #Iconics Genesis64. They earn $20,000 and 20 Master of Pwn points.

SUCCESS - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) used a missing authentication for critical function vuln to execute code on Inductive Automation Ignition. They win $20,000 and 20 Master of Pwn points.

SUCCESS - Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) used an Uncontrolled Search Path bug in AVEVA Edge to execute their code. In doing so, they win $20,000 and 20 points towards Master of Pwn.

SUCCESS - The Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov used a resource exhaustion bug to execute their DoS on the Prosys OPC UA SDK for Java. This wins them $5,000 and 5 Master of Pwn points.

SUCCESS - Axel '0vercl0k' Souchet of https://doar-e.github.io used a double free bug to execute his code on Iconics Genesis64. He wins $20,000 and 20 Master of Pwn points. You can watch a replay of this attempt here.

SUCCESS - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) used an uncontrolled search path vulnerability to get RCE in AVEVA Edge. They win $20,000 and 20 Master of Pwn points.

SUCCESS - 20urdjk used a file upload vulnerability on Inductive Automation Ignition to get RCE. He wins $20,000 and 20 more points towards Master of Pwn. His contest total is now $25,000 and 25 points.

SUCCESS - The Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) used a pair of bugs, including a directory traversal, to get code execution on Triangle Microworks SCADA Data Gateway. The win another $20,000 and 20 more Master of Pwn points.

BUG COLLISION - While the Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov successfully demonstrated RCE against Iconics Genesis64, the bug used was one we already knew about. They still win $5,000 and 5 Master of Pwn points.

BUG COLLISION - The Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) were able to get code execution on Inductive Automation Ignition, but the bug they used was previously known. They still win $5,000 and 5 Master of Pwn points.

BUG COLLISION - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) successfully popped calc, but the bug they used had been disclosed earlier in the competition. They still win $5,000 and 5 Master of Pwn points.

SUCCESS - The Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov used a resource exhaustion bug to perform a DoS on the OPC Foundation OPC UA .NET Standard. They earn $5,000 and 5 Master of Pwn points.

SUCCESS - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) end Day One of Pwn2Own Miami 2022 by using a deserialization bug to execute code on AVEVA Edge. They win another $20,000 and 20 more Master of Pwn points. Their Day One total is $60,000 and 60 points.

Day Two - April 20, 2022

SUCCESS - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) used an infinite loop condition to create a DoS against the Unified Automation C++ Demo Server. They earn $5,000 and 5 points towards Master of Pwn.

Thijs Alkemade (left) and Daan Keuper from Computest Sector 7 watch their exploit run

SUCCESS - Piotr Bazydło (@chudyPB) used a deserialization bug to exploit Inductive Automation Ignition and execute his code on the system. He earns $20,000 and 20 Master of Pwn points.

SUCCESS - Ben McBride (@bdmcbri) used an exposed dangerous function bug to get RCE on Iconics Genesis64. He earns himself $20,000 and 20 Master of Pwn points.

SUCCESS - Or Peles, Omer Kaspi and Uriya Yavnieli from JFrog Security Research used a stack exhaustion bug to perform a DoS on the OPC Foundation OPC UA .NET Standard. They earn another $5,000 and 5 more Master of Pwn points.

BUG COLLISION - The Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov did achieve RCE against AVEVA Edge, however the bug they used had been seen previously in the contest. They still earn $5,000 and 5 more Master of Pwn points.

ZDI analyst Peter Girnus (left) confers with Sharon Brizinov of the Claroty Research team

FAILURE - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) were unable to get their exploit of Inductive Automation Ignition working within the time allotted.

The Incite Team of Chris Anastasio (far left) and Steve Seeley watch their attempt as ZDI analysts Michel DePlante and Joshua Smith observe.

BUG COLLISION - Piotr Bazydło (@chudyPB) was able to get RCE on Iconics Genesis64, however the bug he used had been previously seen. He still earns $5,000 and 5 Master of Pwn points.

Piotr Bazydło participates remotely as he discusses his exploit with ZDI analyst Tony Fuller

SUCCESS - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) used one of the more interesting bugs we've ever seen at a Pwn2Own to bypass the trusted application check on the OPC Foundation OPC UA .NET Standard. The earn $40,000 and 40 Master of Pwn points. Their contest total is now at $90,000 with a commanding lead in Master of Pwn.

Thijs Alkemade (left) and Daan Keuper of Computest Sector 7 review their exploit as ZDI analyst Mat Powell watches the results.

BUG COLLISION - While Christopher Hernandez (@piffd0s) was able to show his RCE on AVEVA Edge, the bug he used was previous disclosed. He still earns $5,000 and 5 Master of Pwn points.

FAILURE - The Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov were unable to get their DoS exploit of the Unified Automation C++ Demo Server working within the time allotted.

BUG COLLISION - The Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) did demonstrate their RCE on Iconics Genesis64, the bug used had been previously disclosed. They still win $5,000 and 5 Master of Pwn points.

Radek Domanski (left) and Pedro Ribeiro watch their exploit as ZDI members Tony Fuller, Brian Gorenc, and Bobby Gould observe

SUCCESS - Piotr Bazydło (@chudyPB) used an untrusted search path bug to get code execution on AVEVA Edge. He wins another $20,000 and 20 Master of Pwn points. That brings his contest total to $45,000.

SUCCESS - The Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov needed a little time, but they did get their amazing buffer overrun chain to achieve code execution against Kepware KEPServerEx. They earned $20,000 and 20 Master of Pwn points.

Uri Katz (left) and Sharon Brizinov of Claroty Research work with ZDI analysts Michel DePlante and Tony Fuller to prepare their exploit

Day Three - April 21, 2022

SUCCESS - The Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) used a pair of bugs, including a directory traversal, to exploit the Softing Secure Integration server and run their code. They earn $20K and 20 Master of Pwn points. That brings their conference total to $80,000.

SUCCESS/BUG COLLISION - The Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) combined 3 bugs to get RCE on the Softing Secure Integration Server, but two were previously known. Their exploit chain earned them $10,000 and 10 Master of Pwn points. They end the contest with $40,000 total.

SUCCESS - The Claroty Research (@claroty) team of Noam Moshe, Vera Mens, Amir Preminger, Uri Katz, and Sharon Brizinov used a null pointer deref to perform their DoS on the Softing Secure Integration Server. They earn $5,000 and 5 Master of Pwn points, which brings their contest total to $45,000.

Pwn2Own Miami 2022 Results

Pwn2Own Miami 2022 Schedule

18 April 2022 at 23:14

¡Bienvenidos de nuevo a Miami!

Welcome to Pwn2Own Miami 2022! This year’s ICS-focused event promises to be three days of great research and exploits, as we have 32 total entries from 11 contestants. As always, we began our contest with a random drawing to determine the order of attempts. If you missed it, you can watch the replay here.

The complete schedule for the contest is below (all times Eastern [GMT -4:00]).

Note: All times subject to change - You can see the results and live updates here once they become available. Entries marked with a 📷 icon will be live streamed on YouTube, Twitch, and Twitter.

Tuesday, April 19

09:30 - 20urdjk targeting Unified Automation C++ Demo Server with a DoS in the OPC UA Server category

10:30 - @_s_n_t from @pentestltd targeting Inductive Automation Ignition with an RCE in the Control Server category

📷 11:30 - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) targeting Iconics Genesis64 with an RCE in the Control Server category

11:30: Or Peles, Omer Kaspi and Uriya Yavnieli from JFrog Security Research targeting the Unified Automation C++ Demo Server with a DoS in the OPC UA Server category

13:00 - Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) targeting AVEVA Edge with an RCE in the Human Machine Interface category

13:00 - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) targeting Inductive Automation Ignition with an RCE in the Control Server category

📷 14:00 - Axel '0vercl0k' Souchet of https://doar-e.github.io targeting Iconics Genesis64 with an RCE in the Control Server category

14:00 - Claroty Research targeting the Prosys OPC UA SDK for Java with a DoS in the OPC UA Server category

15:00 - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) targeting AVEVA Edge with an RCE in the Human Machine Interface category

15:00 - 20urdjk targeting Inductive Automation Ignition with an RCE in the Control Server category

16:00 - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) targeting Triangle Microworks SCADA Data Gateway with an RCE in the Data Gateway category

16:00 - Claroty Research (@claroty) targeting Iconics Genesis64 with an RCE in the Control Server category

📷 17:00 - Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) targeting Inductive Automation Ignition with an RCE in the Control Server category

18:00 - Claroty Research (@claroty) targeting the OPC Foundation OPC UA .NET Standard with a DoS in the OPC UA Server category

18:00 - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) targeting Iconics Genesis64 with an RCE in the Control Server category

19:00 - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) targeting AVEVA Edge with an RCE in the Human Machine Interface category

Wednesday, April 20

09:30 - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) targeting the Unified Automation C++ Demo Server with a DoS in the OPC UA Server category

10:30 - Piotr Bazydło (@chudyPB) targeting Inductive Automation Ignition with an RCE in the Control Server category

11:30 - Or Peles, Omer Kaspi and Uriya Yavnieli from JFrog Security Research targeting the OPC Foundation OPC UA .NET Standard with an DoS in the OPC UA Server category

11:30 - Ben McBride (@bdmcbri) targeting Iconics Genesis64 with an RCE in the Control Server category

12:30 - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) targeting Inductive Automation Ignition with an RCE in the Control Server category

12:30 - Claroty Research (@claroty) targeting AVEVA Edge with an RCE in the Human Machine Interface category

📷 13:30 - Daan Keuper (@daankeuper) and Thijs Alkemade (@xnyhps) from Computest Sector 7 (@sector7_nl) targeting the OPC Foundation OPC UA .NET Standard with a Bypass of the Trusted Application Check in the OPC UA Server category

13:30 - Piotr Bazydło (@chudypb) targeting Iconics Genesis64 with an RCE in the Control Server category

14:30 - Christopher Hernandez targeting AVEVA Edge with an RCE in the Human Machine Interface category

15:30 - Claroty Research (@claroty) targeting Unified Automation C++ Demo Server with a DoS in the OPC UA Server category

15:30 - Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) targeting Iconics Genesis64 with an RCE in the Control Server category

16:30 - Piotr Bazydło (@chudypb) targeting AVEVA Edge with an RCE in the Human Machine Interface category

📷 17:20 - Claroty Research (@claroty) targeting Kepware KEPServerEx with an RCE in the Data Gateway category

Thursday, April 21

09:30 - Incite Team of Steven Seeley (@steventseeley) and Chris Anastasio (@mufinnnnnnn) targeting Softing Secure Integration Server with an RCE in the OPC UA Server category

10:30 - Flashback Team of Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro) targeting Softing Secure Integration Server with an RCE in the OPC UA Server category

11:30 - Claroty Research (@claroty) targeting the Softing Secure Integration Server with a DoS in the OPC UA Server category

We’ll be posting updates on our Twitter page, and look for live video updates on Twitter as well. We wish all contestants good luck, and may all your exploits be unique and effective.

Pwn2Own Miami 2022 Schedule

The April 2022 Security Update Review

12 April 2022 at 18:08

Another Patch Tuesday is upon, and Adobe and Microsoft have released a bevy of new security updates. Take a break from your regularly scheduled activities and join us as we review the details of their latest security offerings.

Adobe Patches for April 2022

For April, Adobe released four updates addressing 70 CVEs in Acrobat and Reader, Photoshop, After Effects, and Adobe Commerce. The update for Acrobat and Reader is by far the largest, with 62 CVEs being addressed. A total of 54 of these CVEs were reported through the ZDI program, with ZDI vulnerability analyst Mat Powell responsible for 27 of these. The more severe vulnerabilities being fixed are the Critical-Rated Use-After-Free (UAF) and Out-of-Bounds (OOB) Write bugs. These could allow an attacker to execute code on a target system if they can convince a user to open a specially crafted PDF document. There are 13 CVEs fixed in the patch for Photoshop, and all of these were reported through the ZDI program. All the vulnerabilities addressed by this patch address Critical-rated code execution bugs. Again, an attacker would need to convince a user to open a specially crafted file to gain code execution.

The update for After Effects addresses two Critical-rated CVEs that could allow for code execution. Both bugs are listed as stack-based buffer overflows. Finally, the patch for Adobe Commerce fixes a single, Critical-rated vulnerability. Adobe rates this as a CVSS 9.1, but they also point out authentication would be required to exploit this bug. They also note admin privileges are required, so the high CVSS is somewhat puzzling. Still, if you’re using Commerce, test and deploy this patch as soon as you are able.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release.

Microsoft Patches for April 2022

This month, Microsoft released 128 new patches addressing CVEs in Microsoft Windows and Windows Components, Microsoft Defender and Defender for Endpoint, Microsoft Dynamics, Microsoft Edge (Chromium-based), Exchange Server, Office and Office Components, SharePoint Server, Windows Hyper-V, DNS Server, Skype for Business, .NET and Visual Studio, Windows App Store, and Windows Print Spooler Components. This is in addition to the 17 CVEs consumed from the Chromium Open-Source Software (OSS) by Microsoft Edge (Chromium-based), which brings the April total to 145 CVEs.

Of the 128 new CVEs released today, 10 are rated Critical, 115 are rated Important, and three are rated Moderate in severity. A total of six of these bugs came through the ZDI program. This large volume of patches hasn’t been seen since the fall of 2020. However, this level is similar to what we saw in the first quarter of last year.

One of the bugs patched is listed as under active exploit this month, and one other is listed as publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with a Critical-rated bug that could prove wormable:

-       CVE-2022-26809 - RPC Runtime Library Remote Code Execution Vulnerability
This bug is rated as a CVSS 9.8, and the exploit index notes exploitation is more likely. The vulnerability could allow a remote attacker to executed code at high privileges on an affected system. Since no user interaction is required, these factors combine to make this wormable, at least between machine where RPC can be reached. However, the static port used here (TCP port 135) is typically blocked at the network perimeter. Still, this bug could be used for lateral movement by an attacker. Definitely test and deploy this one quickly.

-       CVE-2022-24491/24497 – Windows Network File System Remote Code Execution Vulnerability
Speaking of nearly wormable bugs, these two NFS vulnerabilities also rate a 9.8 CVSS and are listed as exploitation more likely. On systems where the NFS role is enabled, a remote attacker could execute their code on an affected system with high privileges and without user interaction. Again, that adds up to a wormable bug – at least between NFS servers. Similar to RPC, this is often blocked at the network perimeter. However, Microsoft does provide guidance on how the RPC port multiplexer (port 2049) “is firewall-friendly and simplifies deployment of NFS.” Check your installations and roll out these patches rapidly.

-       CVE-2022-26815 - Windows DNS Server Remote Code Execution Vulnerability
This vulnerability is the most severe of the 18(!) DNS Server bugs receiving patches this month. This bug is also very similar to one patched back in February, which makes one wonder if this bug is the result of a failed patch. There are a couple of important mitigations to point out here. The first is that dynamic updates must be enabled for a server to be affected by this bug. The CVSS also lists some level of privileges to exploit. Still, any chance of an attacker getting RCE on a DNS server is one too many, so get your DNS servers patched.

-       CVE-2022-26904 - Windows User Profile Service Elevation of Privilege Vulnerability
This is one of the publicly known bugs patched this month, and not only is PoC out there for it, there’s a Metasploit module as well. This privilege escalation vulnerability allows an attacker to gain code execution at SYSTEM level on affected systems. They would, of course, need some level privileges before they could escalate. That’s why these types of bugs are often paired with code execution bugs like the ones in Adobe Reader (mentioned above) to completely take over a system.

Here’s the full list of CVEs released by Microsoft for April 2022:

CVE Title Severity CVSS Public Exploited Type
CVE-2022-24521 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2022-26904 Windows User Profile Service Elevation of Privilege Vulnerability Important 7 Yes No EoP
CVE-2022-23259 Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-26809 RPC Runtime Library Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-22008 Windows Hyper-V Remote Code Execution Vulnerability Critical 7.7 No No RCE
CVE-2022-23257 Windows Hyper-V Remote Code Execution Vulnerability Critical 8.6 No No RCE
CVE-2022-24537 Windows Hyper-V Remote Code Execution Vulnerability Critical 7.7 No No RCE
CVE-2022-26919 Windows LDAP Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-24491 Windows Network File System Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-24497 Windows Network File System Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-24541 Windows Server Service Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-24500 Windows SMB Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-26832 .NET Framework Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-26907 Azure SDK for .NET Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2022-26896 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-26897 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-26898 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24489 Cluster Client Failover (CCF) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24479 Connected User Experiences and Telemetry Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26830 DiskUsage.exe Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-24767 GitHub: Git for Windows' uninstaller vulnerable to DLL hijacking when run under the SYSTEM user account Important Unknown No No EoP
CVE-2022-24765 GitHub: Uncontrolled search for the Git directory in Git for Windows Important Unknown No No EoP
CVE-2022-24532 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24496 Local Security Authority (LSA) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24548 Microsoft Defender Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2022-24475 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-26891 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-26894 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-26895 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-26900 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-26908 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.3 No No EoP
CVE-2022-24473 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26901 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26924 YARP Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-24493 Microsoft Local Security Authority (LSA) Server Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-23292 Microsoft Power BI Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2022-24472 Microsoft SharePoint Server Spoofing Vulnerability Important 8 No No Spoofing
CVE-2022-26788 PowerShell Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24533 Remote Desktop Protocol Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2022-24492 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-24528 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-26910 Skype for Business and Lync Spoofing Vulnerability Important 5.3 No No Spoofing
CVE-2022-26911 Skype for Business Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-26921 Visual Studio Code Elevation of Privilege Vulnerability Important Unknown No No EoP
CVE-2022-24513 Visual Studio Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24485 Win32 File Enumeration Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-21983 Win32 Stream Enumeration Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-24534 Win32 Stream Enumeration Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-26914 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24482 Windows ALPC Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24540 Windows ALPC Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24494 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24549 Windows AppX Package Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26828 Windows Bluetooth Driver Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24484 Windows Cluster Shared Volume (CSV) Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2022-24538 Windows Cluster Shared Volume (CSV) Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-26784 Windows Cluster Shared Volume (CSV) Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-24481 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24488 Windows Desktop Bridge Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24547 Windows Digital Media Receiver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24495 Windows Direct Show - Remote Code Execution Vulnerability Important 7 No No RCE
CVE-2022-26816 Windows DNS Server Information Disclosure Vulnerability Important 4.9 No No Info
CVE-2022-24536 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26811 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26812 Windows DNS Server Remote Code Execution Vulnerability Important 6.7 No No RCE
CVE-2022-26813 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26814 Windows DNS Server Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-26815 Windows DNS Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-26817 Windows DNS Server Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-26818 Windows DNS Server Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-26819 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2022-26820 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2022-26821 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2022-26822 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2022-26823 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26824 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26825 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26826 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-26829 Windows DNS Server Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-24546 Windows DWM Core Library Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24527 Windows Endpoint Configuration Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26916 Windows Fax Compose Form Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26917 Windows Fax Compose Form Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26918 Windows Fax Compose Form Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-26808 Windows File Explorer Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-26810 Windows File Server Resource Management Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26827 Windows File Server Resource Management Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-26920 Windows Graphics Component Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-26903 Windows Graphics Component Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23268 Windows Hyper-V Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-22009 Windows Hyper-V Remote Code Execution Vulnerability Important 7.7 No No RCE
CVE-2022-24490 Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability Important 8.1 No No Info
CVE-2022-24539 Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability Important 8.1 No No Info
CVE-2022-26783 Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-26785 Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-24499 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24530 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24498 Windows iSCSI Target Service Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2022-24486 Windows Kerberos Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24544 Windows Kerberos Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24545 Windows Kerberos Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2022-24483 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-26831 Windows LDAP Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-24487 Windows Local Security Authority (LSA) Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-26786 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26787 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26789 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26790 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26791 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26792 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26793 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26794 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26795 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26796 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26797 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26798 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26801 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26802 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26803 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26915 Windows Secure Channel Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-24550 Windows Telephony Server Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24543 Windows Upgrade Assistant Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24474 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24542 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-26807 Windows Work Folder Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-26909 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Moderate 8.3 No No EoP
CVE-2022-26912 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Moderate 8.3 No No EoP
CVE-2022-24523 Microsoft Edge (Chromium-based) Spoofing Vulnerability Moderate 4.3 No No EoP
CVE-2022-1129 * Chromium: Inappropriate implementation in Full Screen Mode High N/A No No RCE
CVE-2022-1128 * Chromium: Inappropriate implementation in Web Share API High N/A No No RCE
CVE-2022-1130 * Chromium: Insufficient validation of untrusted input in WebOTP High N/A No No RCE
CVE-2022-1134 * Chromium: Type Confusion in V8 High N/A No No RCE
CVE-2022-1232 * Chromium: Type Confusion in V8 High N/A No No RCE
CVE-2022-1131 * Chromium: Use after free in Cast UI High N/A No No RCE
CVE-2022-1125 * Chromium: Use after free in Portals High N/A No No RCE
CVE-2022-1127 * Chromium: Use after free in QR Code Generator High N/A No No RCE
CVE-2022-1133 * Chromium: Use after free in WebRTC High N/A No No RCE
CVE-2022-1143 * Chromium: Heap buffer overflow in WebUI Medium N/A No No RCE
CVE-2022-1139 * Chromium: Inappropriate implementation in Background Fetch API Medium N/A No No N/A
CVE-2022-1137 * Chromium: Inappropriate implementation in Extensions Medium N/A No No N/A
CVE-2022-1138 * Chromium: Inappropriate implementation in Web Cursor Medium N/A No No N/A
CVE-2022-1145 * Chromium: Use after free in Extensions Medium N/A No No RCE
CVE-2022-1135 * Chromium: Use after free in Shopping Cart Medium N/A No No RCE
CVE-2022-1136 * Chromium: Use after free in Tab Strip Medium N/A No No RCE
CVE-2022-1146 * Chromium: Inappropriate implementation in Resource Timing Low N/A No No EoP

* Indicates this CVE had previously been released by a 3rd-party and is now being incorporated into Microsoft products.

We should also call attention CVE-2022-24521, which is a bug in the Windows Common Log File System Driver and listed as under active attack. Since this vulnerability only allows a privilege escalation, it is likely paired with a separate code execution bug. We should also point out that this was reported by the National Security Agency. It’s not stated how widely the exploit is being used in the wild, but it’s likely still targeted at this point and not broadly available. Go patch your systems before that situation changes.

Looking at the remaining Critical-rated bugs patched this month, there are three RCE vulnerabilities impacted the Hyper-V server. In these cases, someone on a guest OS could gain code execution on the underlying host OS. There’s a bug in the LDAP service that’s remote and does not require user interaction. However, to be affected, the default setting for MaxReceiveBuffer LDAP setting must be changed. This isn’t something that’s commonly tweaked, but if your environment has this setting, pay attention to this one. There are Critical patches for SMB and the Server service. In both cases, a user must connect to a malicious share, which would typically require some form of social engineering – like a link in an email or instant message. This is yet another port (TCP 445) that should be blocked at the perimeter. Finally, there’s an update for Microsoft Dynamics 365 (on prem). This vulnerability requires a user to run a specially crafted trusted solution package to execute arbitrary SQL commands. This would allow an attacker to escalate and execute commands with the privileges of the db_owner.

Moving on to the Important-rated patches, the first that stand out are the bunches of fixes for some all too familiar components. We’ve already mentioned the 18 fixes for the DNS Server component. Most of these have multiple mitigations, but many could allow remote code execution. There’s one info disclosure bug thrown in there for good measure. Despite this component being around for years, it seems there are still bugs to find. There are also 15 patches for the Print Spooler this month. Ever since PrintNightmare last year, print spooler bugs seem to just keep coming. It makes sense as the printing system is complex and offers attackers a broad attack surface. Let’s hope these patches don’t cause the types of problems introduced by some the other printer-related patches. And when it comes to large groups of patches, there are a mountain of CVEs affecting the Edge (Chromium-based) browser as well. Most of these bugs were patched by Google and consumed by Edge earlier this month. However, this demonstrates the risk of everyone relying on the same browser platform. A bug in one is now shared by many.  

In total, there are 47 patches to correct RCE bugs in this month’s patch. Beyond those already mentioned, there’s yet another RDP client bug that would allow code execution if a user connected to a malicious RDP server. If that sounds familiar, there was a similar bug last month (and more going back months prior). There are a few open-and-own bug in Office components, most notably Excel. The chances of people applying patches to Excel before April 15 seem low, so let’s hope these bugs don’t get exploited. There are a couple of intriguing bugs affecting Win32 file enumeration, although these also require a user to connect to a malicious server or share. There hasn’t been much research on this component, so it will be interesting to see if further bugs are found. Finally, there’s an RCE in Kerberos, but to be affected, the system needs Restricted Admin or Windows Defender Remote Credential Guard enabled on a box with Remote Desktop Connections configured. It’s not clear how common this configuration is, but you should check your systems and apply the update as needed.

The April release includes 59 patches to address Elevation of Privilege (EoP) bugs this month. For the most part, these are in Windows components and would need to be paired with an RCE to allow an attacker to take over a system. A few do stand out. The first is a vulnerability in the Windows Telephony Server that was reported by ZDI vulnerability researcher Simon Zuckerbraun. This flaw exists within the CreateObjectHandler COM object. Crafted method invocations on this object can trigger the deserialization of untrusted data. There are also a pair of bugs in Azure Site Recovery that should be called out as well. Don’t let the admin credential requirement fool you. This bug applies to the VMWare-to-Azure scenario, and administrators will need to upgrade to the latest version to mitigate these vulns.

There are 10 fixes address that address information disclosure bugs. For the most part, these only result in leaks consisting of unspecified memory contents. The lone exception is the bug impacting the Skype for Business. This vulnerability could inadvertently disclose file content to an attacker, but Microsoft doesn’t specific if any file content can be exposed or if just files in specific locations.

April brings eight updates to address DoS bugs, and a few stand out over the others. There’s a DoS in Microsoft Defender, but Microsoft provides no details. Another is a DoS bug in Hyper-V, which is always inconvenient if you happen to be one of the other guest OSes on that Hyper-V server. There are a trio of DoS vulnerabilities in the Windows Cluster Shared Volume (CSV) component, but again, Microsoft provides not details on how the DoS manifests. There are also no details provided about the DoS in Windows Secure Channel, but considering how much relies on schannel these days, definitely don’t take this update lightly.

This month’s update is rounded out by three updates addressing spoofing bugs. The spoofing bug in SharePoint could allow an authenticated user to send malicious content in SIP Address field. This would allow the user to have access to content that is otherwise not authorized. The spoofing vulnerability in Skype for Business and Lync could expose IP addresses or port numbers to an attacker. Finally, the patch for Power BI requires multiple uses hitting the gateway at the same time. While this can likely be scripted, it does increase the attack complexity.

No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV990001.

Looking Ahead

The next Patch Tuesday falls on May 10, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The April 2022 Security Update Review

CVE-2022-26381: Gone by others! Triggering a UAF in Firefox

7 April 2022 at 15:51

Memory corruption vulnerabilities have been well known for a long time and programmers have developed various methods to prevent them. One type of memory corruption that is very hard to prevent is the use-after-free and the reason is that it has too many faces! Since it cannot be associated with any specific pattern in source code, it is not trivial to eliminate this vulnerability class. In this blog, a use-after-free vulnerability in Mozilla Firefox will be explained which has been assigned CVE-2022-26381. The Mozilla bug entry 1756793 is still closed to the public as of this writing, but the Zero Day Initiative advisory page ZDI-22-502 can provide a bit more information.

What Is a Use-After-Free Vulnerability?

A use-after-free (UAF) vulnerability happens when a pointer to a freed object is accessed. It does not make sense! Why would a programmer free an object and afterward access it again?

It happens due to the complexity of today’s software. A browser, for example, has many components and each of them may allocate different objects. They may even pass these objects to each other for processing. A component may free an object when it is done using it, while other components still have a pointer to that object. Any dereference of that pointer can lead to a use-after-free vulnerability.

Proof-of-Concept

Let’s start quickly by having a look at the minimized proof-of-concept:

When running this on the latest vulnerable release version of Mozilla Firefox, which is 97.0.1, it gives a very promising crash:

This is what the crash point looks like in IDA. It happens inside a loop:

It dereferences a value from memory and then makes an indirect call (a virtual function call) using the fetched value. Thus, this is rated as a remote code execution vulnerability. The value of the “rax” register which is used during dereferencing is particularly interesting: 0xE5E5E5E5E5E5E5E5. This is a magic value that Firefox uses to “poison” the memory of a freed object so that a dereference of a value fetched from that freed object will cause a crash, as this value is never a valid memory address. This helps greatly to catch use-after-free conditions.

To analyze a use-after-free vulnerability, it is always desired to have more information about the freed object: its type, size, where it is allocated, where it is freed, and where it is subsequently used. On Windows, this is usually done by enabling advanced debugging features using the GFlags tool to enable various global flags. Specifically, it can be used to enable pageheap and create a﷟ user-mode stack trace to capture the stack trace at the time a particular object is allocated. Unfortunately, this will not help us on Mozilla Firefox, because Firefox has its own memory management mechanism called jemalloc. The way we can get more information about the object is to run the PoC on an ASAN version of Firefox. You can see the result below:

We got lots of information. Let’s break it down a bit by checking where the object is allocated:

Let’s further check this by looking at the source code (line 1164 of /builds/worker/checkouts/gecko/layout/svg/SVGObserverUtils.cpp). You can download the source code of Firefox 97.0.1 or use the online version (note that line numbers of the online version may not match, as it gets updated constantly):

And this is how it looks in the compiled release version:

So the object size is 0x70 (112) bytes and it is used to store and track properties of frames during reflow triggered by scrolling.

Then we want to know where it is freed and reused. ASAN provides a long stack trace. A closer look gives a good hint. Let’s first check the stack trace when the object is freed:

And now the stack trace when the object is subsequently used:

We can see the “mozilla::SVGRenderingObserverSet::InvalidateAll” function in the stack trace when the crash happens and when the object free is initiated. This also matches the crash point of the release version which is inside the OnNonDOMMutationRenderingChange function (it says it is inlined in xul!mozilla::SVGRenderingObserverSet::InvalidateAll). We can now make an initial educated guess: while an object was being processed in a loop in the “mozilla::SVGRenderingObserverSet::InvalidateAll” function, a code path was reached that freed the object being processed, leading to a use-after-free vulnerability.

Now that we have all the details, we can validate this hypothesis step-by-step by running the PoC on the released version of Firefox.

First, we want to know the address of an allocated object so we can monitor it. This can easily be achieved by setting a breakpoint that prints the address of the object upon allocation:

Then, let’s see how the objects are processed in the loop we saw in IDA inside the “mozilla::SVGRenderingObserverSet::InvalidateAll” function. We will print the address of the object that is going to be processed. We also set a breakpoint on the subsequent virtual function call:

We run the PoC, and the debugger stops before calling the virtual function. As you can see, two objects are allocated and these two are going to be processed in the loop. First, one object is processed and a call to the “SVGTextPathObserver::OnRenderingChange” function is made, which eventually frees various allocated objects including the second object which is awaiting processing!

We can see this clearly in the picture below, which is taken immediately after the return from the call. As you can see, the second object has been freed (and poisoned with 0xe5) during the processing of the first object:

In the second iteration, the freed object is loaded for processing, leading to a load of the poison value and resulting in a crash:

Release Versus ASAN Behavior

When running the PoC against the release version, we got a crash during a dereference of 0xE5E5E5E5E5E5E5E5. However, in the ASAN version, it crashed when writing to memory. Why is there a difference? The reason is as follows:

In a release (non-ASAN) build, when freeing an object, its memory remains accessible (not unmapped), and thus any read and write to that memory will still succeed without triggering an immediate crash. That is why the instruction “mov byte ptr [rcx+8], 0” in the above picture executed without error. A crash is likely to occur further along, though. As in our case, if a value is fetched value from a freed object and then dereferenced, the dereference may cause a crash. This is especially true if the freed object content is overwritten by “poison” values as seen above. Note that there is a chance that there will be no crash at all, for example, if there are only reads and writes to the freed object without any dereference operations on fetched values, or if the poison value becomes overwritten with unrelated data. This means that if we fuzz a release version, there is a chance we could miss a vulnerability.

ASAN, on the other hand, monitors all read, write, and dereferences on memory and can catch such vulnerabilities as soon as possible. That is why it is recommended to use an ASAN version for fuzzing.

The Patch

Use-after-free vulnerabilities are often fixed by converting raw pointers to smart pointers or by correcting the management of the object reference count. Here, it was fixed by changing how continuations frame reflows are handled in the engine:

Final Notes

Developers have expended a great deal of effort to eliminate vulnerabilities associated with known patterns in source code, and they have mostly succeeded in decreasing their prevalence. However, there are some classes of vulnerabilities that are harder to prevent, and use-after-free is one of them. Assuring perfect management of object lifecycles in software with a million lines of code is extremely difficult. This is one of the main motivations behind languages like Rust that enforce proper object ownership and lifetime management.

You can find me on Twitter at @hosselot and follow the team for the latest in exploit techniques and security patches.

CVE-2022-26381: Gone by others! Triggering a UAF in Firefox

Abusing Arbitrary File Deletes to Escalate Privilege and Other Great Tricks

What do you do when you’ve found an arbitrary file delete as NT AUTHORITY\SYSTEM? Probably just sigh and call it a DoS. Well, no more. In this article, we’ll show you some great techniques for getting much more out of your arbitrary file deletes, arbitrary folder deletes, and other seemingly low-impact filesystem-based exploit primitives.

The Trouble with Arbitrary File Deletes

When you consider how to leverage an arbitrary file delete on Windows, two great obstacles present themselves:

  1. Most critical Windows OS files are locked down with DACLs that prevent modification even by SYSTEM. Instead, most OS files are owned by TrustedInstaller, and only that account has permission to modify them. (Exercise for the reader: Find the critical Windows OS files that can still be deleted or overwritten by SYSTEM!)
  2. Even if you find a file that you can delete as SYSTEM, it needs to be something that causes a “fail-open” (degradation of security) if deleted.

A third problem that can arise is that some critical system files are inaccessible at all times due to sharing violations.

Experience shows that finding a file to delete that meets all the above criteria is very hard. When looking in the usual places, which would be within C:\Windows, C:\Program Files or C:\Program Data, we’re not aware of anything that fits the bill. There is some prior work that involves exploiting antivirus and other products, but this is dependent on vulnerable behavior in those products.

The Solution is Found Elsewhere: Windows Installer

In March of 2021, we received a vulnerability report from researcher Abdelhamid Naceri (halov). The vulnerability he reported was an arbitrary file delete in the User Profile service, running as SYSTEM. Remarkably, his submission also included a technique to parlay this file delete into an escalation of privilege (EoP), resulting in a command prompt running as SYSTEM. The EoP works by deleting a file, but not in any of the locations you would usually think of.

To understand the route to privilege escalation, we need to explain a bit about the operation of the Windows Installer service. The following explanation is simplified somewhat.

The Windows Installer service is responsible for performing installations of applications. An application author supplies an .msi file, which is a database defining the changes that must be made to install the application: folders to be created, files to be copied, registry keys to be modified, custom actions to be executed, and so forth.

To ensure that system integrity is maintained when an installation cannot be completed, and to make it possible to revert an installation cleanly, the Windows Installer service enforces transactionality. Each time it makes a change to the system, Windows Installer makes a record of the change, and each time it overwrites an existing file on the system with a newer version from the package being installed, it retains a copy of the older version. In case the install needs to be rolled back, these records allow the Windows Installer service to restore the system to its original state. In the simplest scenario, the location for these records is a folder named C:\Config.Msi.

During an installation, the Windows Installer service creates a folder named C:\Config.Msi and populates it with rollback information. Whenever the install process makes a change to the system, Windows Installer records the change in a file of type .rbs (rollback script) within C:\Config.Msi. Additionally, whenever the install overwrites an older version of some file with a newer version, Windows Installer will place a copy of the original file within C:\Config.Msi. This type of a file will be given the .rbf (rollback file) extension. In case an incomplete install needs to be rolled back, the service will read the .rbs and .rbf files and use them to revert the system to the state that existed before the install.

This mechanism must be protected against tampering. If a malicious user were able to alter the .rbs and/or .rbf files before they are read, arbitrary changes to the state of the system could occur during rollback. Therefore, Windows Installer sets a strong DACL on C:\Config.Msi and the enclosed files.

Here is where an opening arises, though: What if an attacker has an arbitrary folder delete vulnerability? They can use it to completely remove C:\Config.Msi immediately after Windows Installer creates it. The attacker can then recreate C:\Config.Msi with a weak DACL (note that ordinary users are allowed to create folders at the root of C:\). Once Windows Installer creates its rollback files within C:\Config.Msi, the attacker will be able to replace C:\Config.Msi with a fraudulent version that contains attacker-specified .rbs and .rbf files. Then, upon rollback, Windows Installer will make arbitrary changes to the system, as specified in the malicious rollback scripts.

Note that the only required exploit primitive here is the ability to delete an empty folder. Moving or renaming the folder works equally well.

From Arbitrary Folder Delete/Move/Rename to SYSTEM EoP

In conjunction with this article, we are releasing source code for Abdelhamid Naceri’s privilege escalation technique. This exploit has wide applicability in cases where you have a primitive for deleting, moving, or renaming an arbitrary empty folder in the context of SYSTEM or an administrator. The exploit should be built in the Release configuration for either x64 or x86 to match the architecture of the target system. Upon running the exploit, it will prompt you to initiate a delete of C:\Config.Msi. You can do this by triggering an arbitrary folder delete vulnerability, or, for testing purposes, you can simply run rmdir C:\Config.Msi from an elevated command prompt. Upon a successful run, the exploit will drop a file to C:\Program Files\Common Files\microsoft shared\ink\HID.DLL. You can then get a SYSTEM command prompt by starting the On-Screen Keyboard osk.exe and then switching to the Secure Desktop, for example by pressing Ctrl-Alt-Delete.

The exploit contains an .msi file. The main thing that’s special about this .msi is that it contains two custom actions: one that produces a short delay, and a second that throws an error. When the Windows Installer service tries to install this .msi, the installation will halt midway and rollback. By the time the rollback begins, the exploit will have replaced the contents of C:\Config.Msi with a malicious .rbs and .rbf. The .rbf contains the bits of the malicious HID.DLL, and the .rbs instructs Windows Installer to “restore” it to our desired location (C:\Program Files\Common Files\microsoft shared\ink\).

The full mechanism of the EoP exploit is as follows:

  1. The EoP creates a dummy C:\Config.Msi and sets an oplock.
  2. The attacker triggers the folder delete vulnerability to delete C:\Config.Msi (or move C:\Config.Msi elsewhere) in the context of SYSTEM (or admin). Due to the oplock, the SYSTEM process is forced to wait.
  3. Within the EoP, the oplock callback is invoked. The following several steps take place within the callback.
  4. The EoP moves the dummy C:\Config.Msi elsewhere. This is done so that the oplock remains in place and the vulnerable process is forced to continue waiting, while the filesystem location C:\Config.Msi becomes available for other purposes (see further).
  5. The EoP spawns a new thread that invokes the Windows Installer service to install the .msi, with UI disabled.
  6. The callback thread of the EoP continues and begins polling for the existence of C:\Config.Msi. For reasons that are not clear to me, Windows Installer will create C:\Config.Msi, use it briefly for a temp file, delete it, and then create it a second time to use for rollback scripts. The callback thread polls C:\Config.Msi to wait for each of these actions to take place.
  7. As soon as the EoP detects that Windows Installer has created C:\Config.Msi for the second time, the callback thread exits, releasing the oplock. This allows the vulnerable process to proceed and delete (or move, or rename) the C:\Config.Msi created by Windows Installer.
  8. The EoP main thread resumes. It repeatedly attempts to create C:\Config.Msi with a weak DACL. As soon as the vulnerable process deletes (or moves, or renames) C:\Config.Msi, the EoP’s create operation succeeds.
  9. The EoP watches the contents of C:\Config.Msi and waits for Windows Installer to create an .rbs file there.
  10. The EoP repeatedly attempts to move C:\Config.Msi elsewhere. As soon as Windows Installer closes its handle to the .rbs, the move succeeds, and the EoP proceeds.
  11. The EoP creates C:\Config.Msi one final time. Within it, it places a malicious .rbs file having the same name as the original .rbs. Together with the .rbs, it writes a malicious .rbf.
  12. After the delay and the error action specified in the .msi, Windows Installer performs a rollback. It consumes the malicious .rbs and .rbf, dropping the DLL.

Note that at step 7, there is a race condition that sometimes causes problems. If the vulnerable process does not immediately awaken and delete C:\Config.Msi, the window of opportunity may be lost because Windows Installer will soon open a handle to C:\Config.Msi and begin writing an .rbs there. At that point, deleting C:\Config.Msi will no longer work, because it is not an empty folder. To avoid this, it is recommended to run the EoP on a system with a minimum of 4 processor cores. A quiet system, where not much other activity is taking place, is probably ideal. If you do experience a failure, it will be necessary to retry the EoP and trigger the vulnerability a second time.

From Arbitrary File Delete to SYSTEM EoP

The technique described above assumes a primitive that deletes an arbitrary empty folder. Often, though, one has a file delete primitive as opposed to a folder delete primitive. That was the case with Abdelhamid Naceri’s User Profile bug. To achieve SYSTEM EoP in this case, his exploit used one additional trick, which we will now explain.

In NTFS, the metadata (index data) associated with a folder is stored in an alternate data stream on that folder. If the folder is named C:\MyFolder, then the index data is found in a stream referred to as C:\MyFolder::$INDEX_ALLOCATION. Some implementation details can be found here. For our purposes, though, what we need to know is this: deleting the ::$INDEX_ALLOCATION stream of a folder effectively deletes the folder from the filesystem, and a stream name, such as C:\MyFolder::$INDEX_ALLOCATION, can be passed to APIs that expect the name of a file, including DeleteFileW.

So, if you are able to get a process running as SYSTEM or admin to pass an arbitrary string to DeleteFileW, then you can use it not only as a file delete primitive but also as a folder delete primitive. From there, you can get a SYSTEM EoP using the exploit technique discussed above. In our case, the string you want to pass is C:\Config.Msi::$INDEX_ALLOCATION.

Be advised that success depends on the particular code present in the vulnerable process. If the vulnerable process simply calls DeleteFileA/DeleteFileW, you should be fine. In other cases, though, the privileged process performs other associated actions, such as checking the attributes of the specified file. This is why you cannot test this scenario from the command prompt by running del C:\Config.Msi::$INDEX_ALLOCATION.

From Folder Contents Delete to SYSTEM EoP

Leveling up once more, let us suppose that the vulnerable SYSTEM process does not allow us to specify an arbitrary folder or file to be deleted, but we can get it to delete the contents of an arbitrary folder, or alternatively, to recursively delete files from an attacker-writable folder. Can this also be used for EoP? Researcher Abdelhamid Naceri demonstrated this as well, in a subsequent submission in July 2021. In this submission he detailed a vulnerability in the SilentCleanup scheduled task, running as SYSTEM. This task iterates over the contents of a temp folder and deletes each file it finds there. His technique was as follows:

  1. Create a subfolder, temp\folder1.
  2. Create a file, temp\folder1\file1.txt.
  3. Set an oplock on temp\folder1\file1.txt.
  4. Wait for the vulnerable process to enumerate the contents of temp\folder1 and try to delete the file file1.txt it finds there. This will trigger the oplock.
  5. When the oplock triggers, perform the following in the callback:
    a. Move file1.txt elsewhere, so that temp\folder1 is empty and can be deleted. We move file1.txt as opposed to just deleting it because deleting it would require us to first release the oplock. This way, we maintain the oplock so that the vulnerable process continues to wait, while we perform the next step.
    b. Recreate temp\folder1 as a junction to the ‘\RPC Controlfolder of the object namespace. c. Create a symlink at\RPC Control\file1.txtpointing toC:\Config.Msi::$INDEX_ALLOCATION`.
  6. When the callback completes, the oplock is released and the vulnerable process continues execution. The delete of file1.txt becomes a delete of C:\Config.Msi.

Readers may recognize the symlink technique involving \RPC Control from James Forshaw’s symboliclink-testing-tools. Note, though, that it’s not sufficient to set up the junction from temp\folder1 to \RPC Control and then let the arbitrary file delete vulnerability do its thing. That’s because \RPC Control is not an enumerable file system location, so the vulnerable process would not be able to find \RPC Control\file1.txt via enumeration. Instead, we must start off by creating temp\folder1\file1.txt as a bona fide file, allowing the vulnerable process to find it through enumeration. Only afterward, just as the vulnerable process attempts to open the file for deletion, we turn temp\folder1 into a junction pointing into the object namespace.

For working exploit code, see project FolderContentsDeleteToFolderDelete. Note that the built-in malware detection in Windows will flag this process and shut it down. I recommend adding a “Process” exclusion for FolderContentsDeleteToFolderDelete.exe.

You can chain these two exploits together. To begin, run FolderOrFileDeleteToSystem and wait for it to prompt you to trigger privileged deletion of Config.Msi. Then, run FolderContentsDeleteToFolderDelete /target C:\Config.Msi. It will prompt you to trigger privileged deletion of the contents of C:\test1. If necessary for your exploit primitive, you can customize this location using the /initial command-line switch. For testing purposes, you can simulate the privileged folder contents deletion primitive by running del /q C:\test1\* from an elevated command prompt. FolderContentsDeleteToFolderDelete will turn this into a delete of C:\Config.Msi, and this will enable FolderOrFileDeleteToSystem to drop the HID.DLL. Finally, open the On-Screen Keyboard and hit Ctrl-Alt-Delete for your SYSTEM shell.

From Arbitrary Folder Create to Permanent DoS

Before closing, we’d like to share one more technique we learned from this same researcher. Suppose you have an exploit primitive for creating an arbitrary folder as SYSTEM or admin. Unless the folder is created with a weak DACL, it doesn’t sound like this would be something that could have any security impact at all. Surprisingly, though, it does: it can be used for a powerful denial of service. The trick is to create a folder such as this one:

      C:\Windows\System32\cng.sys

Normally there is no file or folder by that name. If an attacker name squats on that filesystem location with an extraneous file or even an empty folder, the Windows boot process is disrupted. The exact mechanism is a bit of a mystery. It would appear that Windows attempts to load the cng.sys kernel module from the improper location and fails, and there is no retry logic that allows it to continue and locate the proper driver. The result is a complete inability to boot the system. Other drivers can be used as well for the same effect.

Depending on the vulnerability at hand, this DoS exploit could even be a remote DoS, as nothing is required besides the ability to drop a single folder or file.

Conclusion

The techniques we’ve presented here show how some rather weak exploit primitives can be used for great effect. We have learned that:

• An arbitrary folder delete/move/rename (even of an empty folder), as SYSTEM or admin, can be used to escalate to SYSTEM.
• An arbitrary file delete, as SYSTEM or admin, can usually be used to escalate to SYSTEM.
• A delete of contents of an arbitrary folder, as SYSTEM or admin, can be used to escalate to SYSTEM.
• A recursive delete, as SYSTEM or admin, of contents of a fixed but attacker-writable folder (such as a temp folder), can be used to escalate to SYSTEM.
• An arbitrary folder create, as SYSTEM or admin, can be used for a permanent system denial-of-service.
• An arbitrary file delete or overwrite, as SYSTEM or admin, even if there is no control of contents, can be used for a permanent system denial-of-service.

We would like to thank researcher Abdelhamid Naceri for his great work in developing these exploit techniques, as well as for the vulnerabilities he has been reporting to our program. We look forward to seeing more from him in the future. Until then, you can find me on Twitter at @HexKitchen, and follow the team for the latest in exploit techniques and security patches.

Abusing Arbitrary File Deletes to Escalate Privilege and Other Great Tricks

The March 2022 Security Update Review

8 March 2022 at 18:30

It’s once again Patch Tuesday, which means the latest security updates from Adobe and Microsoft have arrived. Take a break from your regularly scheduled activities and join us as we review the details of their latest security offerings.

Adobe Patches for March 2022

The Adobe release for March is quite small. This month, Adobe released only three patches addressing six CVEs in Adobe Photoshop, Illustrator, and After Effects. The patch for After Effects is the largest of the three. It fixes four Critical-rated, stacked-based buffer overflows that could result in arbitrary code execution. The fix for Illustrator is also rated Critical. It addresses a single buffer overflow that could lead to arbitrary code execution. Finally, the update for Photoshop fixes a single Important-rated memory leak.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release.

Microsoft Patches for March 2022

For March, Microsoft released 71 new patches addressing CVEs in Microsoft Windows and Windows Components, Azure Site Recovery, Microsoft Defender for Endpoint and IoT, Intune, Edge (Chromium-based), Windows HTML Platforms, Office and Office Components, Skype for Chrome, .NET and Visual Studio, Windows RDP, SMB Server, and Xbox. This is in addition to the 21 CVEs patched by Microsoft Edge (Chromium-based) earlier this month, which brings the March total to 92 CVEs.

Of the 71 CVEs released today, three are rated Critical and 68 are rated Important in severity. A total of seven of these bugs came through the ZDI program. Historically speaking, this is volume is in line with previous March releases. However, the number of Critical-rated patches is again strangely low for this number of bugs. It’s unclear if this low percentage of bugs is just a coincidence or if Microsoft might be evaluating the severity using different calculus than in the past.

None of the bugs are listed as under active exploit this month, while three are listed as publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with one of the bugs listed as publicly known:

-       CVE-2022-21990 – Remote Desktop Client Remote Code Execution Vulnerability
This client-side bug doesn’t have the same punch as server-side related RDP vulnerabilities, but since it’s listed as publicly known, it makes sense to go ahead and treat this as a Critical-rated bug. If an attacker can lure an affected RDP client to connect to their RDP server, the attacker could trigger code execution on the targeted client. Again, this isn’t as severe as BlueKeep or some of the other RDP server bugs, but it definitely shouldn’t be overlooked.

-       CVE-2022-23277 – Microsoft Exchange Server Remote Code Execution Vulnerability
This Critical-rated bug in Exchange Server was reported by long-time ZDI contributor Markus Wulftange. The vulnerability would allow an authenticated attacker to execute their code with elevated privileges through a network call. This is also listed as low complexity with exploitation more likely, so it would not surprise me to see this bug exploited in the wild soon - despite the authentication requirement. Test and deploy this to your Exchange servers quickly.

-       CVE-2022-24508 – Windows SMBv3 Client/Server Remote Code Execution Vulnerability
This bug could allow an attacker to execute code on Windows 10 version 2004 and newer systems. It’s also reminiscent of CVE-2020-0796 from a couple of years ago. Both also list disabling SMBv3 compression as a workaround for SMB servers, but this doesn’t help clients. In 2020, Microsoft noted SMBv3 compression “is not yet used by Windows or Windows Server and disabling SMB Compression has no negative performance impact.” That’s not in the current advisory, so it’s unclear what disabling this feature will have now. Authentication is required here, but since this affected both clients and servers, an attacker could use this for lateral movement within a network. This is another one I would treat as Critical and mitigate quickly.

-       CVE-2022-21967 – Xbox Live Auth Manager for Windows Elevation of Privilege Vulnerability
This appears to be the first security patch impacting Xbox specifically. There was an advisory for an inadvertently disclosed Xbox Live certificate back in 2015, but this seems to be the first security-specific update for the device itself. Microsoft even notes other Windows OSes are not affected by this bug. It’s not clear how an attacker could escalate privileges using this vulnerability, but the Auth Manager component is listed as affected. This service handles interacting with the Xbox Live service. I doubt many enterprises are reliant on Xbox or Xbox Live, but if you are, make sure this patch doesn’t go unnoticed.

Here’s the full list of CVEs released by Microsoft for March 2022:

CVE Title Severity CVSS Public Exploited Type
CVE-2022-24512 .NET and Visual Studio Remote Code Execution Vulnerability Important 6.3 Yes No RCE
CVE-2022-21990 Remote Desktop Client Remote Code Execution Vulnerability Important 8.8 Yes No RCE
CVE-2022-24459 Windows Fax and Scan Service Elevation of Privilege Vulnerability Important 7.8 Yes No EoP
CVE-2022-22006 HEVC Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2022-23277 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-24501 VP9 Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2022-24508 Windows SMBv3 Client/Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-21967 Xbox Live Auth Manager for Windows Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24464 .NET and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-24469 Azure Site Recovery Elevation of Privilege Vulnerability Important 8.1 No No EoP
CVE-2022-24506 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-24515 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-24518 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-24519 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-24467 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24468 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24470 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24471 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24517 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24520 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2020-8927 * Brotli Library Buffer Overflow Vulnerability Important 6.5 No No N/A
CVE-2022-24457 HEIF Image Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-22007 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23301 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24452 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24453 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24456 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-21977 Media Foundation Information Disclosure Vulnerability Important 3.3 No No Info
CVE-2022-22010 Media Foundation Information Disclosure Vulnerability Important 4.4 No No Info
CVE-2022-23278 Microsoft Defender for Endpoint Spoofing Vulnerability Important 5.9 No No Spoofing
CVE-2022-23266 Microsoft Defender for IoT Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-23265 Microsoft Defender for IoT Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-24463 Microsoft Exchange Server Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2022-24465 Microsoft Intune Portal for iOS Security Feature Bypass Vulnerability Important 3.3 No No SFB
CVE-2022-24461 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24509 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24510 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-24511 Microsoft Office Word Tampering Vulnerability Important 5.5 No No Tampering
CVE-2022-24462 Microsoft Word Security Feature Bypass Vulnerability Important 5.5 No No SFB
CVE-2022-23282 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23253 Point-to-Point Tunneling Protocol Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-23295 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23300 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23285 Remote Desktop Client Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-24503 Remote Desktop Protocol Client Information Disclosure Vulnerability Important 5.4 No No Info
CVE-2022-24522 Skype Extension for Chrome Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2022-24460 Tablet Windows User Interface Application Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24526 Visual Studio Code Spoofing Vulnerability Important 6.1 No No Spoofing
CVE-2022-24451 VP9 Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-23283 Windows ALPC Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-23287 Windows ALPC Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24505 Windows ALPC Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-24507 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24455 Windows CD-ROM Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-23286 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-23281 Windows Common Log File System Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-23288 Windows DWM Core Library Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-23291 Windows DWM Core Library Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-23294 Windows Event Tracing Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-23293 Windows Fast FAT File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24502 Windows HTML Platforms Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2022-21975 Windows Hyper-V Denial of Service Vulnerability Important 4.7 No No DoS
CVE-2022-23290 Windows Inking COM Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-23296 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-21973 Windows Media Center Update Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2022-23297 Windows NT Lan Manager Datagram Receiver Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-23298 Windows NT OS Kernel Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-23299 Windows PDEV Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-23284 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.2 No No EoP
CVE-2022-24454 Windows Security Support Provider Interface Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-24525 Windows Update Stack Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2022-0789 * Chromium: Heap buffer overflow in ANGLE High N/A No No RCE
CVE-2022-0797 * Chromium: Out of bounds memory access in Mojo High N/A No No RCE
CVE-2022-0792 * Chromium: Out of bounds read in ANGLE High N/A No No RCE
CVE-2022-0795 * Chromium: Type Confusion in Blink Layout High N/A No No RCE
CVE-2022-0790 * Chromium: Use after free in Cast UI High N/A No No RCE
CVE-2022-0796 * Chromium: Use after free in Media High N/A No No RCE
CVE-2022-0791 * Chromium: Use after free in Omnibox High N/A No No RCE
CVE-2022-0793 * Chromium: Use after free in Views High N/A No No RCE
CVE-2022-0794 * Chromium: Use after free in WebShare High N/A No No RCE
CVE-2022-0800 * Chromium: Heap buffer overflow in Cast UI Medium N/A No No RCE
CVE-2022-0807 * Chromium: Inappropriate implementation in Autofill Medium N/A No No Info
CVE-2022-0802 * Chromium: Inappropriate implementation in Full screen mode Medium N/A No No Info
CVE-2022-0804 * Chromium: Inappropriate implementation in Full screen mode Medium N/A No No Info
CVE-2022-0801 * Chromium: Inappropriate implementation in HTML parser Medium N/A No No Tampering
CVE-2022-0803 * Chromium: Inappropriate implementation in Permissions Medium N/A No No SFB
CVE-2022-0799 * Chromium: Insufficient policy enforcement in Installer Medium N/A No No SFB
CVE-2022-0809 * Chromium: Out of bounds memory access in WebXR Medium N/A No No RCE
CVE-2022-0805 * Chromium: Use after free in Browser Switcher Medium N/A No No RCE
CVE-2022-0808 * Chromium: Use after free in Chrome OS Shell Medium N/A No No RCE
CVE-2022-0798 * Chromium: Use after free in MediaStream Medium N/A No No RCE

* Indicates this CVE had previously been released by a 3rd-party and is now being incorporated into Microsoft products.

Looking at the rest of the March release, the 11 CVEs impacting Azure Site Recovery stand out. For those not familiar with it, Site Recovery is a native disaster recovery as a service (DRaaS). This month’s release includes fixes for five elevation of privilege (EoP) and six remote code execution (RCE) bugs in the platform. Considering everything going on in the world, now is a bad time to have issues with your disaster recovery plans. If you’re using this platform, make sure these patches get installed. If you’re not using this platform, take time to review your disaster recovery plans anyway. It couldn’t hurt.

Besides the Exchange bug already mentioned, the Critical-rated fixes in this release both address bugs in HEVC and VP9 video extensions. These updates can be found in the Microsoft Store. If you aren’t connected to the internet or are in an otherwise disconnected environment, you’ll need to manually apply the patch.

Including those already mentioned, there are a total of 28 RCE fixes released today. There are additional updates for the HEVC video extension component. Again, these fixes are obtained through the Microsoft Store. The raw image extension bugs fall into this class as well. There are three fixes for Visio that were reported by kdot through this ZDI program. These bugs include a type confusion, an untrusted pointer deref, and an Out-Of-Bounds (OOB) Write. In each case, a user must open a specially crafted Visio file to be impacted. One of the other publicly known bugs is an RCE in .NET and Visual Studio. There’s scant information about this bug, but if you are developing apps in .NET or Visual Studio, review it carefully. Since RPC bugs are never out of fashion, there’s a fix for event tracing that could result in code execution through a specially crafted RPC connection. There are several caveats to this one that lower the severity, but don’t remove the risk completely.

Rounding out the RCE bugs is one submitted by an anonymous researcher through the ZDI program impacts Microsoft Defender for IoT. The vulnerability exists within the password change mechanism. It results from the lack of proper validation of a user-supplied string before using it to execute a system call. Defender for IoT also receives a patch for an EoP bug found by ZDI Vulnerability Researcher Simon Zuckerbraun. This bug also occurs within the password change mechanism, but here, the bug is caused by the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of root.

Moving on to the other EoP cases, most would require an attacker to log on to a system and run a specially crafted program. Several of these fixes note that the vulnerability is the result of a race condition, making exploitation somewhat unreliable. There are some interesting components receiving fixes for privilege escalations this month, including the FAT file system, the Fax and Scan Service, and the CD-ROM driver. It’s almost retro. Another interesting component is the Windows PDEV, which is a logical representation of a physical device characterized by the type of hardware, logical address, and surfaces that can be supported. ZDI Vulnerability Researcher Lucas Leong reported a Use-After-Free (UAF) bug in the handling of PDEV objects. An attacker could use this to escalate privileges and execute arbitrary code in the context of SYSTEM.

Six of this month’s fixes address information disclosure bugs. For the most part, these only result in leaks consisting of unspecified memory contents. The lone exception is the bug impacting the Skype for Chrome extension. This vulnerability could inadvertently disclose the Skype ID of a target. An attacker could gain access to that ID they could match it within Skype to a name and Avatar of the target user. If you’re using Skype for Chrome, you’ll need to get the update through the Chrome Web Store.

There are four updates to address DoS bugs in this release, and two stand out over the others. The first is a DoS in Hyper-V, which is always inconvenient if you happen to be one of the other guest OSes on that Hyper-V server. The other is a vulnerability in the Point-to-Point Tunneling (PPTP) protocol, which is used in the implementation of virtual private networks (VPN) that allow people to extend their private networks over the Internet via “tunnels”. There are no details about this bug given, but anything that could take down a VPN is unwelcome – especially since so many of us rely on VPNs to work from home (or wherever).

Three different components receive fixes for security feature bypasses (SFB) in this month’s release. The first continues the retro theme by fixing bugs in the Windows HTML platforms, including Internet Explorer and Edge (HTML-Based). Microsoft does not indicate which security feature is bypassed, but considering how pervasive MSHTML continues to be, patching is certainly recommended. Word receives a fix for an SFB bug that could allow specific protections to be bypassed in Protected View. This could potentially result in a user opening a malicious document but not receiving the intended warning dialogs. The final SFB fix applies to the Intune Portal for iOS. An attacker could use this vulnerability to bypass the Intune policy file save location and presumably load their own policy instead.

This month’s release includes three updates for spoofing bugs. The Exchange spoofing bug could allow an authenticated attacker to view file content on the affected server. Microsoft provides little information about the spoofing bugs in Defender Endpoint and Visual Studio other than to say the Defender bug requires knowledge of the target environment and the Visual Studio bug requires a user to open a file.

We wrap up this month’s release with an odd tampering bug in Microsoft Word. Microsoft gives no information on how the vulnerability can be exploited, but they do indicate information from the victim can be sent to the attacker, and that the Preview Pane is an attack vector. It sounds like a specially crafted Word doc can send potentially sensitive information to an attacker when the document is opened or viewed in the Preview Pane. Office for Mac users are out of luck as well, as the patches for Microsoft Office 2019 for Mac and Microsoft Office LTSC for Mac 2021 are not available yet. It will be interesting to see if additional information is released about this bug in the future.

No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV990001.

Looking Ahead

The next Patch Tuesday falls on April 12, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The March 2022 Security Update Review

Clang Checkers and CodeQL Queries for Detecting Untrusted Pointer Derefs and Tainted Loop Conditions

23 February 2022 at 17:49

In the first blog of the series, we saw how CodeQL and Clang checkers can be used to find bugs in MySQL Cluster involving untrusted size arguments leading to buffer overflow or out-of-bound array accesses. Though the majority of bugs were out-of-bounds array accesses, there were also bugs involving untrusted data being used in loop conditions or casted to pointers. In this final blog of the series, we experiment with CodeQL’s IR and Clang checkers for detecting such bug classes.

Defining taint sources - CSA vs CodeQL

The first part of the problem is defining the taint sources. Clang Static Analyzer (CSA) provides an experimental checker alpha.security.taint.TaintPropagation for performing static taint analysis. Implemented as GenericTaintChecker, it has a set of built-in taint sources. Since the Signal data used by message handlers does not come directly from these built-in taint sources, it is necessary to find an alternative approach to define taint sources. Lucas Leong had a quick approach to work around the problem - rewrite all access to signal->theData with getenv(). Since the return value of getenv() is considered tainted by GenericTaintChecker, taint propagation works after rewrite. Refer to his blog post “MindShaRE: When MySQL Cluster Encounters Taint Analysis” for details on using existing taint checkers and CodeQL to find memory corruption bugs.

One has to be careful with this approach to avoid missing potential taint sources. Though MySQL Cluster has defined APIs like Signal::getDataPtr() to fetch the Signal data pointer, various handlers don’t follow the standard. Instead, signal->theData is accessed in numerous other ways from offset 0 or from various other offsets. I rewrote some common patterns using find and sed. This may not be exhaustive but provides sufficient taint sources to experiment with the checkers.

The situation is much different when working with CodeQL, where defining taint sources is far more flexible. All we have to do is override the isSource() predicate to something like this:

CWE-822: Untrusted Pointer Dereference

In an untrusted pointer deference vulnerability, data from an untrusted source is casted to a pointer for further use. The impact of the bug depends on the usage of the casted pointer. This section provides details about detecting such pointer load operation using CSA and CodeQL.

Detecting untrusted pointer dereference using CSA

To detect this vulnerability using CSA, I relied on path-sensitive checker callback check::Location which fires every time a program accesses memory for read or write. The information below is from the checker documentation:

The SVal symbolic value Loc points to the memory region being accessed. IsLoad indicates whether the access is a read or a write. To check if a memory load is happening from a tainted memory region, we can check if Loc is tainted. If so, we can use the statement S to get the type of the expression:

Whenever the expression type is a pointer, it is logged as a bug. Scanning MySQL Cluster with this checker gave about 86 results, which is significantly high and also has false positives. Here is what the scan results look like:

The large number of results is due to the fact that any pointer derived from a tainted value (via pointer arithmetic, array indexing, etc.) is also considered tainted, irrespective of whether the tainted value is constrained by validation. In some cases, OOB reads which load pointers are also reported. Understanding the nature of false-positive results significantly improves the triage experience.

Considering the high number of results, we can sort the results by “File” which is likely to organize the result by feature, or for a less familiar code base, sorting by “Path Length” can help identify code paths reachable with minimum complexity.

scan-view results sorted by File

scan-view results sorted by Path Length

CSA reported a number of bugs in the code handling DBDIH block with a path length of 1. Here is an example bug report:

Using a known bug pattern, it is possible to apply filters to reduce the results in addition to the taint check. For example, we can check the AST statements for pointer loads which are only assignment statements like above. The checker can be tweaked as per the nature of bugs in the codebase.

Analyzing memory loads using CodeQL IR

To perform a similar analysis in CodeQL, one can possibly rely on expression classes such as PointerDereferenceExpr, VariableAccess, FieldAccess and its subtypes. But in this case, I was curious to explore CodeQL’s Intermediate Representation (IR) to track memory loads. Since the documentation around CodeQL’s IR is limited, I used the Instruction class to dump the IR for further analysis. Here is a partial dump of IR for the line EmulatedJamBuffer * jambuf = (EmulatedJamBuffer*)req->jamBufferPtr in function execDIH_SCAN_TAB_REQ():

The CodeQL query used to dump the IR along with source code information:

Consider the below set of instructions in the IR:

Here the LoadInstruction relies on 2 operands - a source address operand (r17303_4) and a source value operand (m17300_12). The source value operand is a MemoryOperand. The MemoryOperand describes the memory address accessed by the instruction, whose value gets copied to the result register (r17303_5). Moreover, the result is also associated with type information. The idea was to filter all tainted memory load operations whose return type is a pointer. However, such a query resulted in an unusably large number of results.

Adding constraints using overlap relationship and virtual variables

Consulting CodeQL’s IR SSA Construction documentation, I found a couple of features that could be useful for refining the query: the overlap relationship and VirtualVariables.

Overlap defines the relationship between the definition of a memory location and its usage. The most interesting relationship for this analysis is MustExactlyOverlap - the set of bits written by the definition is identical to the set of bits read by the use, and the data type of both the definition and the use are the same. For more clarity on the overlap relationship, refer to the SSA test case found in the repository. In the case of untrusted pointer load bugs, it is very likely that there will be a mismatch of data type between definition and usage (type casting) or that the number of bits read will be a subset of the definition. Therefore, we can skip Load operations where the source value operand has an exactly overlapping relationship with its definition. The getOperandMemoryLocation() predicate provides information regarding the MemoryLocation read by a memory operand. Consider the output of the following query:

The memory operands that are marked with tilde “~” are the ones that do not have an exactly overlapping relationship. This can also be checked using isDefinitionInexact() predicate. Putting all this together, we can override the isSink() predicate to get a meaningful number of results to work with.

Many of the false-positive results were due to multiple load operations performed using some misidentified pointer. These results can be either skipped or removed by adding further constraints to the query, such as ignoring certain variable names in the sink or checking for AST patterns.

In the case of MySQL Cluster, one such constraint explored for filtering memory access to the Signal structure is VirtualVariable. As per the documentation, “Each MemoryLocation is associated with exactly one VirtualVariable. A VirtualVariable represents a set of MemoryLocations such that any two MemoryLocations that overlap have the same VirtualVariable.” VirtualVariable information can be fetched from a MemoryLocation using the getVirtualVariable() predicate.

When the variable names are consistent, we can add a constraint to consider only Load operations where the memory operand points to the signal variable. A more generic option is to fetch the type information of the virtual variable to check if it is a Signalstructure. Such a query is still restrictive (not as much variable name) but significantly reduces false positives and returns results involving jamBufferPtr:

CWE-606: Unchecked Input for Loop Condition

In CWE-606: Unchecked Input for Loop Condition, values from an untrusted source are used for loop termination conditions. This may lead to a DoS or other issues depending on the operations done in the loop body. This section provides details about detecting such tainted loop conditions using CSA and CodeQL.

Detecting tainted loop condition using CSA

Unlike tainted memory loads, I couldn’t find any path-sensitive callback to trigger on loop conditions. Moreover, AST-based matchers without path-sensitivity are not useful in this case. Therefore, I relied on the check::BranchCondition callback which fires every time a control flow branching occurs during analysis. The following information is from the checker documentation:

The idea here is, whenever the callback triggers due to a conditional statement, walk up the AST using ParentMap and check for a loop statement. Here is what an example AST looks like for while loop:

For loop operations we are only interested in 3 AST statement classes – WhileStmtClass, DoStmtClass and ForStmtClass. Below is the loop detection code used in the checker:

Once we know that the condition statement triggering the callback is part of a loop statement, we can check if it is tainted. Specifically, I wanted to look for some common code patterns involving induction variables compared against untrusted values, or untrusted values used as induction variables to decide on loop termination. Consider a couple of common code patterns below that involve explicit binary comparison operations:

•      The induction variable is compared against a potentially untrusted value. For example, RHS could be tainted and LHS is not.
•      The induction variable could be potentially untrusted. Here LHS value is compared against constant 0 on RHS.

 The checker specifically looks for these cases to make decisions on bugs. When RHS is constant 0, check if LHS is tainted. Otherwise, check if RHS is tainted:

Another common code pattern is unary operations in loop statements, especially while and do while loops:

No special breakdown is necessary in case of unary operations in the way we handled binary operations. However, in certain cases, implicit Boolean conversions result in implicit conditional statements received by the check::BranchCondition callback. Here is what the AST looks like:

To handle these, if any non-binary conditional operations have a Boolean outcome, it is possibly due to implicit casting and hence we get the sub-expression associated with the expression.

Evaluating constraints on tainted variables

While it is possible to know if an input is tainted or not, there is no way to know if the tainted input value is constrained by some validation. Without this information, the checker is going to generate a lot of false-positive results. To solve this problem, I used the solution provided by Andrew Ruef in the blog post Trail of Bits - Using Static Analysis and Clang to Find Heartbleed. Since Signal data is treated as an unsigned 32-bit integer in most cases, I queried if the variable can take a value greater than 0x10000. If yes, consider the variable as unconstrained and log the bug.

Configuring analyzer-max-loop in CSA

Clang analyzer has a configuration parameter to choose the number of times a basic block in a loop gets executed. By default, this value is 4.

So how does it matter in our analysis? Consider the below code:

Here is buffer->index is validated and the loop operation is considered safe. But the checker still reports a false positive bug.

What seems to be happening here is, the symbolic expression gets evaluated analyzer-max-loop number of times i.e., for each visit to the basic block.

The analyzer seems to evaluate that the decrement operation can underflow resulting in a value greater than 0x10000, therefore reporting it as a bug. I’m not entirely sure of the right way to solve this issue, but a quick workaround is to set analyzer-max-loop to 1. This can also be done in scan-build using the maxloop parameter. In this case, the expression is evaluated only once and it does not report the bug.

        (reg_$3<unsigned int Element{SymRegion{conj_$2{char *, LC2, S26616, #1}},0 S64b,struct index_buf}.index>) > 65536U

The scan reported around 46 bugs, with some valid ones including previously found issues like ZDI-CAN-14488, ZDI-CAN-15120, ZDI-CAN-15121.

Here is the example bug report for vulnerability in Dbdict::execLIST_TABLES_CONF():

Detecting tainted loop condition using CodeQL

Using the analysis done earlier for CSA, an equivalent query in CodeQL can be implemented using the Loop class. The isSink() predicate essentially looks as follows:

Building and Performing the Scan

In order to build clang with custom checkers, copy the source files to the clang/lib/StaticAnalyzer/Checkers directory in the LLVM toolchain. Then add the filenames to the CMakeLists:

Also update the clang/include/clang/StaticAnalyzer/Checkers/Checkers.td file to add the package information:

Once you make clang, the new checkers will be listed alongside other alpha checkers.

Now we can use scan-build to perform the analysis. Use the maxloop and use-analyzer configurations if necessary.

Building with checkers can be slow. To speed up the scan, limit the target path by either modifying the Makefile as necessary or use the custom Makefile by Lucas. All this analysis was performed on clang 12.0 and MySQL Cluster 8.0.25

Scanning with CodeQL requires creating a database, followed by running any queries we are interested in against the created database.

The source code for the Clang checkers and CodeQL queries can be found here.

Acknowledgments and References

•      MindShaRE: When MySQL Cluster Encounters Taint Analysis
•      Clang Static Analyzer - A Checker Developer's Guide
•      A Memory Model for Static Analysis of C Programs
•      Using Static Analysis and Clang to Find Heartbleed
•      Source code of existing clang checkers
•      Vulnerability hunting with Semmle QL
•      CodeQL IR SSA Construction

Conclusion

We hope you’ve enjoyed this look at finding bugs using Clang Static Analyzer, CodeQL, and Binary Ninja. As ZDI Vulnerability Analysts, these have proved helpful in finding new bugs. If you use these (or other) tools to find bugs of your own, consider submitting them to our program. Until then, you can find me on Twitter @RenoRobertr, and follow the team for the latest in exploit techniques and security patches.

Clang Checkers and CodeQL Queries for Detecting Untrusted Pointer Derefs and Tainted Loop Conditions

❌