Zero Day Initiative

The number of vulnerabilities that we see through the program provides significant insight into the attack surfaces of each product that we purchase bugs in. These submissions sometimes reveal not only potential variants but also broader architectural flaws. Submitters frequently choose to provide a full exploit with their submission, which can further reveal interesting techniques. Some of these techniques are so versatile that they end up being useful in the exploitation of several products that all share common functionality. The technique discussed in this blog is one such example that we used to uncover and exploit several vulnerabilities.

Due to paywalls and other obstacles, several vendors and products on the market remain untested and may be vulnerable to the weaknesses we are about to share. We strongly recommend that defenders evaluate their products for these potential issues. Additionally, we encourage vendors who do not currently offer free trials to consider making them available, enabling researchers to conduct this type of research.

Using Alternate Data Streams to Bypass Assumptions

The technique we are about to share, introduced to us by researcher Abdelhamid Naceri, involves the use of NTFS streams. These streams allow a user to attach extra data to a file or directory by creating an alternate data stream (ADS). The interesting aspect of these alternate data streams is their relationship with directories. Typically, when a user wants to create an NTFS junction on a directory, the directory must be empty. However, what if a program needs to perform checks on a file before executing a specific operation that we might be interested in exploiting? In such a case it may not be feasible to maintain an empty directory.

That’s where alternate data streams come in. If we instead point the application to an alternate data stream attached to a directory, that directory can be made into a junction at any time! Since the alternate data stream isn’t technically a file inside the directory, the directory can be empty while the program performs any checks it needs to. Then, when the vulnerable file operation is about to occur, a junction can be created since the directory is technically empty. To further explain this technique, we will look at CVE-2024-0353, a privilege escalation vulnerability we discovered and exploited which affects several ESET Security products listed below.

CVE-2024-0353: ESET Smart Security Premium ekrn Link Following Local Privilege Escalation Vulnerability

For this case, we decided to dig into ESET’s real time protection feature. This feature is common to most antivirus solutions and is triggered by placing an infected file anywhere on the filesystem. For the purposes of testing, we can use an EICAR test file to trigger this behavior. (Be aware that some antiviruses we tested reacted differently to an EICAR file as opposed to a legitimately malicious file.) Once a test file has been placed onto the system, the real time protection feature should activate and delete the file. Doing this with ESET Smart Security, we see that the following actions occur:

ekrn.exe, a service run by ESET Smart Security, will initially scan and back up the detected EICAR file. Subsequently, it will open a handle to the EICAR file and modify its file attributes to FILE_ATTRIBUTE_NORMAL. Finally, it will open a new handle, this time with delete access requested, and call NtSetInformationFile to delete it. What immediately stands out is that when the handle is opened with delete permissions, there is nothing done to prevent it from following any links a standard user could create. Because of that, we can attempt to get the delete operation to follow a link and delete C:\Config.msi instead, so that we can escalate our privileges to NT AUTHORITY\SYSTEM.

The first challenge in attempting to do this is timing the creation of the link. If we create it too early, ekrn.exe won't detect the file as malicious. Conversely, if we create it too late, the link won't be followed, and our target directory won't be deleted. Lucky for us, ESET provides us with a good indicator for when the file will be deleted. As seen in the log from Procmon, shortly before the file is deleted, ekrn.exe will change the file attributes to FILE_ATTRIBUTE_NORMAL. By polling the file for attribute changes, we now have a good indicator of when the file will be deleted.

To start our exploit, we can create a new file and use the function SetFileInformationByHandle to set the new files attributes to something other than FILE_ATTRIBUTE_NORMAL. Then we can write an EICAR test string to this new file and close the handle so that it will be detected and deleted. While waiting for the file to be deleted we can repeatedly use GetFileInformationByHandleEx with a new handle to poll the file’s attributes. As soon as the files attributes have been changed to FILE_ATTRIBUTE_NORMAL, we know we can go ahead and create our link, as the file’s about to be deleted.

By default, standard Windows users don’t have the SeCreateSymbolicLinkPrivilege required to create symbolic links directly in the filesystem, so another approach must be used. One place a standard user does have the ability to create symbolic links is in Windows’ Object Manager. In writable object directories such as \RPC CONTROL\ or \BaseNamedObjects\Restricted\, a standard user can create an object manager symbolic link that can point to an arbitrary path. A standard user can then use NTFS junctions to set an empty directory as a mount point for either \RPC CONTROL\ or \BaseNamedObjects\Restricted\. By combining these two links, a standard user can create a path that will have the same behavior as a traditional symbolic link. You may recognize this approach from James Forshaw’s symboliclink-testing-tools.

There is still another issue. The directory we want to use to create the NTFS junction must be empty. This means that once we see our file attributes change, we need to delete the file before setting the directory as a junction. The issue is that once a file has been marked as malicious, ekrn.exe prevents any other process from accessing that file. This is where using the alternate data streams technique comes in. If the file we create is an alternate data stream attached to the directory, we can turn the directory into a junction at any time as it’s technically empty. This will finally allow us to create our link that will be used to delete any file or folder of our choosing.

In summary, our exploit will do the following:

1. Create an object manager symbolic link in \BaseNamedObjects\Restricted\ with the same name as the EICAR test file, pointing to C:\Config.Msi::$INDEX_ALLOCATION.
2. Create a directory, such as C:\LPE, and create an alternate data stream attached to it.
3. Set the file attributes of the alternate data stream to something other than FILE_ATTRIBUTE_NORMAL.
4. Write an EICAR test string to the alternate data stream.
5. Wait for ESET to change the file attributes to FILE_ATTRIBUTE_NORMAL.
6. Create an NTFS junction at C:\LPE pointing to \BaseNamedObjects\Restricted\
7. Watch as C:\Config.Msi is deleted by ekrn.exe.

By deleting the `::$INDEX_ALLOCATION` stream of `C:\Config.Msi` which stores the index data associated with the folder, we can effectively delete the folder using this arbitrary file delete primitive. More on that trick can be found here.

Following these steps, we can see in the above log that we are able to create our link and cause ekrn.exe to follow it, resulting in C:\Config.Msi being deleted instead of our EICAR test file! We can use this arbitrary delete to escalate our privileges to NT AUTHORITY\SYSTEM using the techniques described in the previous blog.

Something you will notice in the log shown is that ekrn.exe is impersonating the current user when it performs the delete. Since the standard user does not have permission to delete C:\Config.Msi, why does this succeed? The answer has to do with the function ESET uses when opening a handle to the file. By inspecting the call stack of the CreateFile operation in Procmon, we can get a better idea of what is happening:

We can see in the above log that ekrn.exe uses DeviceIoControl to send a control code to an ESET kernel-mode driver named eamonm.sys. This driver then calls FltCreateFileEx2 to open the handle for the requested file. FltCreateFileEx2 supports various arguments, of which the Flags argument is of particular interest. One of the supported flags is IO_FORCE_ACCESS_CHECK. This flag is of critical importance for security, because if that flag is not specified, the I/O manager will not enforce proper user level access checks. In that case, any impersonation would be ignored.

We can set up a kernel debugging session to determine if the absence of this flag is the root cause of the ignored impersonation. We set a breakpoint on FltCreateFileEx2 and once again place an EICAR file on the computer to trigger a file deletion. This will quickly cause our breakpoint to be hit, where we can inspect the value of the Flags argument:

We see in the shown screenshot that the Flags argument has the value 0x800. The value IO_FORCE_ACCESS_CHECK flag is 0x001, which means it is not set! This explains why impersonation does not stop us from deleting arbitrary files. Impersonation could have stopped ekrn.exe from being able to open C:\Config.Msi, but since it was not implemented properly it did not provide the protection it was supposed to.

We saw this as a common theme amongst the products we audited that used impersonation. There were often flaws with their implementation of impersonation. In some cases, if a file couldn’t be opened due to impersonation, the product would simply either stop impersonating or impersonate higher privileged users (including NT AUTHORITY\SYSTEM) until the file was able to be opened. This behavior defeats the entire purpose of using impersonation.

Let's now delve into another vulnerability that further demonstrates the use of alternate data streams. Unfortunately, this next case, among several others, is being disclosed without a patch.

CVE-2024-7238: (0day) VIPRE Advanced Security SBAMSvc Link Following Local Privilege Escalation Vulnerability

This vulnerability in VIPRE Advanced Security is similar to the one we found in ESET Smart Security, as it involves the same real time protection feature. VIPRE calls this feature Advanced Active Protection. When an infected file is placed on the computer, VIPRE will detect and delete it. We can test it with an EICAR test file as we did with ESET Smart Security:

In this case, VIPRE has a service, SBAMSvc.exe, that is responsible for deleting detected files. The service runs as NT AUTHORITY\SYSTEM. Much like ESET, VIPRE first inspects the file to determine if it’s malicious. If it is, VIPRE will make a backup of it and delete it. When the file is opened with delete access, we see that neither the FILE_FLAG_OPEN_REPARSE_POINT flag nor impersonation is used. Also, we do not see any checks after the file is opened to see if any reparse points have been followed. Altogether, this tells us that if we can create a link before SBAMSvc.exe opens the file for deletion, it should follow that link and delete an arbitrary file. This time, however, we don’t have a convenient gadget that will tell us when the file is going to be opened for deletion.

For us to be able to exploit this vulnerability, we need to be able to create a link before SBAMSvc.exe opens the file with delete access. Again, VIPRE prevents us from accessing the file after it has been detected, so we must use an alternate data stream to create our EICAR file.

If we look at what SBAMSvc.exe does before the file is deleted, we see the following in Procmon:

Highlighted in the shown log is every time SBAMSvc.exe reads from the file before it is deleted. Every time a file is read from or written to, the file’s last access timestamp is updated. We can access this value using the function GetFileInformationByHandleEx. By using this function to query a file’s basic info, we can count how many times the file is read by VIPRE. Once we count four reads from the file, we can create our link, ensuring it is created right before the file is deleted.

Counting the number of file reads in this manner did not result in accurate counts 100% of the time, but it did increase the reliability of our exploit. Using this idea, we were able to create our link at just the right time, as seen in the following logs:

Using this arbitrary file delete we are again able to escalate privileges to NT AUTHORITY\SYSTEM by deleting C:\Config.Msi.

Discoveries

The two cases we detailed illustrate the significant role the ADS technique played in uncovering and exploiting privileged file operations in common functionality across antivirus products. Absent this approach, such exploitation would likely have not been feasible. We also highlighted how impersonation seen in Procmon logs could just be a smokescreen if not implemented correctly.

Below is a list of vulnerabilities we discovered which leveraged alternate data streams:

CVE-2024-0353: ESET Smart Security Premium ekrn Link Following Local Privilege Escalation Vulnerability

CVE-2024-7227: Avast Free Antivirus AvastSvc Link Following Local Privilege Escalation Vulnerability

CVE-2024-7234: AVG AntiVirus Free AVGSvc Link Following Local Privilege Escalation Vulnerability

CVE-2024-7240: F-Secure Total Link Following Local Privilege Escalation Vulnerability

CVE-2024-7238: VIPRE Advanced Security SBAMSvc Link Following Local Privilege Escalation Vulnerability

CVE-2024-4454: WithSecure Elements Endpoint Protection Link Following Local Privilege Escalation Vulnerability

Looking Ahead

The next and final part of this series will discuss one more technique and provide a helpful tool you can use for debugging on Windows. We will also talk about issues we faced with several vendors and their understanding of this class of vulnerabilities. Until then, you can find us on Twitter at @Izobashi and @NZubrisky and the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

The number of link following vulnerabilities submitted to the Trend Micro ZDI program has been increasing rapidly over the past several years. These submissions have provided us with insight into how these vulnerabilities are being found and exploited.

In years prior we were seeing a lot of low-hanging fruit in this bug class where you simply just needed a privileged file operation in a directory with a permissive DACL. Now, as we will see with the vulnerabilities presented in this blog series, they often require programmatically exploiting a race condition. In a previous blog , we shared techniques that allow us to escalate our privileges using an arbitrary delete primitive, or to create a permanent DoS condition from an arbitrary file or folder creation primitive. In this blog series, we will discuss two additional techniques that take advantage of legacy functionality within Windows and provide various examples through the over 20 vulnerabilities that we found. We will also address some failures despite efforts and explanations from our side with various vendors. The techniques shared in this series were derived from submissions to the ZDI by Abdelhamid Naceri. 

What is a link following vulnerability?

A link following vulnerability, otherwise known as CWE-59, occurs when an application attempts to access a file by filename but doesn’t properly prevent that filename from resolving to an unintended resource. This means that if a malicious user has created an NTFS junction, hard link, or symlink, a vulnerable application will follow that link to a different location on the system. Since the default behavior in Windows is to transparently follow user-created links, most applications will follow them unless specifically instructed not to do so.

Scouting: The When, Where, and How

To look for this type of vulnerability, one must first find a target that is designed to run with elevated privileges and performs various file operations. After using Procmon to capture a log of file operations, the first thing we need to do is make sure the file operations are occurring in a location that a standard user has access to.

Next, we need to look for file operations that create, copy, move, rename, or delete files. Furthermore, any modifications to a file or folder’s Discretionary Access Control List (DACL) can be of interest. If any of these operations occur without checking for user-created links, we may have found a link following vulnerability that we can exploit! To successfully exploit a link following vulnerability, you must first be familiar with the file operations that can be used to create links. A good overview of the different types of useful file operations can be found here.

Eyes on the Defense

To prevent the CreateFile operation from following links, we observed several strategies employed by developers. As we will see, not all of these are sound practice.

1.         Using the FILE_FLAG_OPEN_REPARSE_POINT Flag: When opening a handle to a file, developers can use the FILE_FLAG_OPEN_REPARSE_POINT flag. NTFS uses reparse points, a collection of user-defined data attached to a file or directory, to implement linking behavior. This flag prevents the default behavior of following reparse points and instead opens the reparse point itself. Consequently, any subsequent operations performed using the returned handle will impact the reparse point rather than the file it points to.
2.         Checking for a Reparse Tag: Developers can check for a reparse tag after opening a handle to the file but before performing any operations using that handle. The NtQueryInformationFile function, used with the FileReparsePointInformation FileInformationClass value, can check a file or directory’s reparse tag. If the developer implements this, they must check for this every time they open a new handle.
3.         Using Protected and Hidden Files: Another method involves including a protected and sometimes hidden file in a directory with a restricted DACL. This will prevent an attacker from turning a directory into a mount point, as that attacker will already need elevated permissions to delete the protected file.
4.         Impersonation: We observed several instances of impersonation, which allows file operations to be executed within the security context of a specific user. An application impersonating a user can only access resources available to that user, even when following links.
5.         Redirection Guard: This more recently introduced mitigation was almost always disabled in the targets we looked at. In a future update to this blog, we will highlight the use of this and why we were able to get around it. For more details on Redirection Guard, you can check out this blog.

While this list is not a comprehensive guide to preventing link following vulnerabilities, our research identified these security measures that developers adopted to make exploitation more challenging for us.

New mitigations?

One technique that looked promising to us when we began our research was first discussed by James Forshaw in 2015. This technique results from an application improperly using impersonation. This allows a user to create a symlink in their device map that will be followed when the application impersonates that user and tries to open locations on a drive. As an example, if an application impersonates the current user and tries to open C:\Program Files, and the user creates a symlink at \??\C: pointing to C:\FakeRoot, the application will instead open C:\FakeRoot\Program Files.

We were introduced to this technique again by Abdelhamid Naceri. This researcher pointed out that when an application or driver running as NT AUTHORITY\SYSTEM wants to access a file on a network share, it must impersonate the user who mapped the share to do so. This gives us a convenient tool to force the products we are interested in to use impersonation. If the application fails to reverse this impersonation, file operations that usually occur in inaccessible locations can be redirected to occur elsewhere! However, once we started attempting to find some bugs using this technique, we quickly found out that the symlinks we created weren’t being followed.

It turns out that in September of 2023, Microsoft released a mitigation in response to ZDI-CAN-21597, among other reports within this bug class. This mitigation introduces the undocumented function ObpUseSystemDeviceMap, which will check if the file being looked up is on the system drive. If the file is on the system drive, and impersonation is being used, then the device map of the primary token will be used instead of the device map of the impersonated user. This explains why our symlinks are not followed as they only exist in the user’s device map.

However, there is a key word here that can potentially be taken advantage of. The mitigation only applies to file lookups that are on the system drive, which is usually “C:\”. This means that this technique can still be applied when the file operations occur on a non-system drive. These types of operations can be triggered when installing applications on non-system drives or by somehow triggering a file operation outside of the system drive. In our research, such operations were hard to come by and few products give you the option to change the install directory, however, this technique is still worth keeping in mind.

The following vulnerabilities from AVG and Avast demonstrate link following privilege escalation bugs with failed checks. The details of these cases are being released as zero-day vulnerabilities because the vendor has failed to coordinate with us and produce a patch. In a future update to this blog, we will provide another interesting case from an additional vendor. Please check back soon for that addendum.

ZDI-CAN-22803 and ZDI-CAN-22806: Avast Free Antivirus and AVG AntiVirus Free Link Following Denial-of-Service Vulnerability.

Most anti-virus solutions allow users to send files to and restore them from a quarantine. A quarantine is generally a location on the filesystem where the potentially malicious files can be stored so that they can’t impact the rest of the system. Files are usually sent to quarantine through a context menu and can be permanently deleted or restored through a UI. This is the case for both Avast Free Antivirus and AVG AntiVirus Free. Both products, despite being released by different vendors, are owned by the same parent company and share the majority of their code. The examples shown are from Avast Free Antivirus, but all the described behavior occurs in both programs.

The interesting behavior occurs when restoring a file from quarantine. First, we can create a file with the path “C:\1\2\TEST.exe” and using Avast’s UI we can send this file to the quarantine. Once the file is quarantined, we have the following options available to us:

By clicking Restore, Avast will perform some checks on the file’s parent directories before recreating it. This operation is interesting, but it’s not where we found this vulnerability. We started by asking ourselves the question, what if the file’s parent directories don’t exist? What happens when we delete “C:\1\2” before attempting to restore the file? If we do this and record a log of the file operations with Procmon, we can see the following happens:

The UI process, AvastUI.exe, will first check if the file already exists and then check if the file’s parent directory exists. Since they do not exist, indicated by the PATH NOT FOUND in Procmon, AvastSvc.exe will be triggered to recreate the non-existent directories. The directory creation operations are highlighted in blue, we can see that there is nothing done to prevent link following behavior. The FILE_FLAG_OPEN_REPARSE_POINT flag isn’t used, and there are no checks to see if there’s an existing reparse point before the directory is created. This AvastSvc.exe process also runs as NT AUTHORITY\SYSTEM, which means we can abuse this behavior to create an arbitrary directory!

An arbitrary directory creation isn’t going to let us do something as cool as escalating privileges, at least not without the created directory having a permissive DACL, but it is going to allow us to create a denial-of-service condition. If we create a directory or file at C:\Windows\System32\cng.sys, it will interrupt the machine’s boot process and prevent it from booting into Windows. We can get AvastSvc.exe to create an arbitrary directory by simply creating a junction at “C:\1” to the directory where we want our new directory to be created, in this case C:\Windows\System32. Instead of naming the child directory 2 as above, we will name it cng.sys. This is all that needs to be done to exploit this vulnerability! In this case we don’t need to worry about winning any races. We can just simply create a junction. For clarity, the exploit steps are as follows:

1. Quarantine a file with the path “C:\1\cng.sys\TEST.exe”.
2. Delete the path “C:\1\cng.sys”.
3. Create a junction at “C:\1” pointing to “C:\Windows\System32”.
4. Restore your quarantined file.

Following these steps, we can successfully exploit the vulnerability:

The first event highlighted in blue shows AvastSvc.exe successfully creating the directory C:\Windows\System32\cng.sys as intended. The second highlighted event shows a check for a reparse point, performed after the directory was created. While this check would have prevented our arbitrary directory creation, it was executed too late. However, this and similar checks do prevent our restored file from being placed in a location that would allow for privilege escalation.

ZDI-CAN-22960 and ZDI-CAN-22963: Avast Free Antivirus and AVG AntiVirus Free Link Following Local Privilege Escalation Vulnerability.

In the previous case we followed what happened when a file was restored from quarantine where the entire file path had to be reconstructed. Consider another edge case: What would happen if the process of recreating the path was interrupted? What if we were to create a directory in the path just before AvastSvc.exe was able to. What would happen then? Since the directories in the path are being created with the CREATE_NEW disposition, there might be some form of error handling if the directory creation fails. To test this behavior, we can once again quarantine a file, such as C:\1\2\3\TEST.exe, and delete the file path. Then we can restore this file while repeatedly trying to create the directory C:\1\2\3. If we manage to create C:\1\2\3 before AvastSvc.exe does, we see the following behavior recorded in Procmon:

The log shows that AvastSvc.exe successfully recreated C:\1 and C:\1\2. Our exploit then created C:\1\2\3 before AvastSvc.exe did, which caused AvastSvc.exe to run into a name collision when it also tries to create C:\1\2\3. This leads AvastSvc.exe to exhibit some interesting behavior. AvastSvc.exe will go back and attempt to delete every directory it had just created. If we can abuse this behavior to delete an arbitrary directory instead of the intended one, we can use this for privilege escalation. Once again, nothing is done to prevent following user created links when the directory is opened with delete access. The issue, however, is in the operations that occur beforehand:

In these operations, a check is performed on the directory before it is deleted. In this check, a handle to the directory is opened using the FILE_FLAG_OPEN_REPARSE_POINT, which is shown as Open Reparse Point in the disposition info in Procmon. Next, the service calls NtQueryInformationFile to retrieve the directory’s FileAttributeTagInformation, which can be used to determine if a directory or file is a reparse point. If this check fails, meaning that the check determines the directory is a reparse point, the service will not delete the directory and furthermore won’t attempt to delete any more directories.

However, this check is vulnerable to a Time-Of-Check-Time-Of-Use (TOCTOU) race condition. Since a different handle is used for the check and the delete, we can attempt to create our link after the check but before the delete. We must win this race in addition to winning the race to create C:\1\2\3 before AvastSvc.exe does. There’s no good way to do this other than brute force, but that is acceptable because there’s nothing stopping us from repeatedly quarantining and restoring a file until we win both races.

There is yet another challenge to address. To create our link at C:\1\2, this directory must be empty. This means that on top of creating a link at just the right time to pass the check, we also must delete C:\1\2\3 before we can create the link. That makes a lot of operations we need to perform in a short amount of time, so there are some things we should do to improve our chances of success.

The first few items are regarding how we create C:\1\2\3. When creating this directory using CreateFile, we can specify CREATE_NEW as the CreationDisposition value. This allows us to find out immediately if we have lost the race to create this directory before AvastSvc.exe does, since the last error value will be set to ERROR_ALREADY_EXISTS if AvastSvc.exe has created it first. This way we can immediately stop and retry the exploit. Another thing we can do when creating C:\1\2\3 is to set the flag FILE_FLAG_DELETE_ON_CLOSE. This flag lets us delete C:\1\2\3 more quickly, since all we need to do is close the handle we opened at creation time.

By changing which directory we use as a junction, we can give ourselves a further advantage. We will create our junction at C:\1 instead of C:\1\2. This gives our exploit more time to complete all its operations before AvastSvc.exe is ready to delete C:\1.

As a final optimization, we can use a separate thread to create the junction. The thread repeatedly attempts to create the junction in a tight loop running at high priority, and as soon as AvastSvc.exe deletes C:\1\2, the junction creation succeeds. The steps for this exploit can be summarized in the following flowchart:

Implementing these steps along with the above optimizations, we’re able to successfully cause AvastSvc.exe to follow our links and delete our target directory:

The Journey Continues

Link following is a great area for vulnerability research that offers plenty of opportunities for bug discovery. Tomorrow, we will release Part 2 of this series, where we will disclose more zero-days and detail a new technique that developers often do not sufficiently defend against. We found several vulnerabilities using this technique and were able to easily adapt our exploit to work on products from multiple AV vendors.

Until then, you can find us online at @Izobashi and @NZubrisky and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

Recently, Trend Micro’s ZDI has published multiple advisories concerning Deep Sea Electronics DSE855, a communications device that allows monitoring of a single DSE controller with USB connectivity over a wired network connection. This blog post looks at these reports in further detail. All the findings were made against DSE855 software version 1.1.0 (the latest available at the moment of writing) and hardware version 4.00. None of these bugs were patched within the standard ZDI 120-day timeframe and were published as 0-day advisories in June.

The DSE855

The DSE855 device presents itself as an unassuming black plastic box with several connection options on the front. The device is supposed to be mounted on a DIN rail, oriented vertically.

On the front, we have an RJ45 port, a small hole for an LED, a USB type A connector, and a 5-pin connector for powering the device.

Inside, there is a single two-sided PCB with components mounted on it.

The upper part is taken by the power section, while the lower part is dominated by a microcontroller p/n LPC4357JBD208 manufactured by NXP. Attached to it is a Micrel p/n KSZ8041, a 10/100 Ethernet PHY transceiver. The 8-pin SOIC part near the vertical USB connector was manufactured by TI, with the exact part number proving to be challenging to identify.

On the other side of the board, we have a variety of passives, an opto-isolator, and two memory chips: a W9812G6KH-6I 128M SDRAM manufactured by Winbond and IS29GL064-70SLET [PDF] 64M parallel Flash manufactured by ISSI.

While there are quite a few obvious test points on the board, probing them with an oscilloscope yielded no signals of interest like a serial console. However, on the top side of the board, there is a conspicuous-looking 2x5-pin 50mil pitched pin array close to the microcontroller. In this instance, however, software extraction via this route proved to be redundant as the manufacturer kindly provided downloadable software updates via their website. At the time of writing, however, downloads appear to be behind a login; allowing open access to firmware updates is always preferable as it promotes research and easy patching by end users

Software analysis

Those blessed with access would be able to download a certain 855.zip, containing a PDF file with instructions—just as described by the manufacturer—and several binaries:

·      A855-01.bin appears to contain an exception vector table
·      B855-01.bin contains the bulk of software—the whopping 439KB
·      C855-01.bin looks like default configuration data, and
·      M855-01.rfs proved to be a file system with a lot of XML files.

By trimming the first 8 bytes of B855-01.bin and loading it into Ghidra at address 0x1B000000, it is possible to explore the software in further detail. The address was hinted at by the contents of A855-01.bin, where many non-zero little-endian words started with 1B00.

The software was then explored both statically in Ghidra and dynamically by interacting with the exposed web server to confirm our hypotheses, but more on that in the text below.

Now, without any further ado, let’s get right to the issues that were discovered and look at them in more detail. Note: all symbol names listed below are based on the reverse engineering effort and the fact that the software, at least the web server part, was based on the embOS/IP middleware package from Segger as evidenced by the contents of the Server HTTP header.

ZDI-24-671: Configuration backup missing authentication

This was the initial report by Gjoko Krstic of Zero Science Lab, which prompted further investigation by the ZDI team.

The gist of the issue is dead simple: accessing a certain URL will result in obtaining a configuration backup, identical in format and size to what is supplied in the software update—like so:

The lucky person could then proceed to abuse the disclosed credentials to access everything else the device has to offer.

Searching the software blob for the URL revealed a table of handlers for dynamically generated content:

Finding the corresponding handler, let’s explore its code:

All that it does is supply some value, a pointer, and a size to another function. And the size looks suspiciously similar to the amount of data returned. Looking at the called function reveals:

For comparison, here is a different CGI handler:

So the expected authentication pattern would be to get the SID parameter, convert it to an integer, call session_find(), and check the result. Note how this is absent in the offending handler, leaving the critical backup function unprotected by any form of authentication.

ZDI-24-675 and ZDI-24-676: Two more missing authentication bugs

All the endpoint handlers were checked for this pattern, and two more handlers were found where authentication was missing. These handlers allow unauthenticated attackers to a) restart the device normally and b) cause a factory reset of the device.

Let’s have a look at the handler code.

All other endpoints made an apparent attempt at authenticating the user. This meant it was time to change the tune. A quick fuzzing session aimed at the HTTP protocol handling triggered several crashes of the device, all of which seemed to do with the handling of multipart requests.

ZDI-24-672: Stack-based buffer overflow when handling boundary values in multipart requests

The first issue turned out to be a classic stack-based buffer overflow, where code does not restrict the amount of attacker-controlled data being copied. Specifically, the overflow occurs in the following fragment of code, believed to be part of the ExecMethod() routine, which processes supplied HTTP request headers:

The code does not ensure the supplied value will fit within the fixed-length array before copying the boundary value into a buffer within the memory region pointed to by the ctx variable. This results in an overflow when values longer than 30 characters are supplied.

The overflown buffer is allocated on the stack and initialized as part of the ctx structure in the _Start() routine:

Note the contents of this structure also include function pointers (pfSend, pfReceive) that can be overwritten with controlled values and subsequently dereferenced, resulting in full control over execution. As is typical for embedded systems, no exploit mitigations like the NX bit or any kind of layout randomization are present.

ZDI-24-674: Stack-based buffer overflow when handling values in multipart requests

Here is another issue discovered through fuzzing. Specifically, the overflow occurs in the following fragment of code, which handles multipart form variables submitted with the request:

The code does not properly verify whether there is enough space left in the buffer before copying attacker-controlled data into it, leading to a buffer overflow. The copying loop terminates only when '\r' is encountered.

The affected buffer is allocated on the stack in the _Start() function, part of the very same object as in the previous issue.

Notably, the affected function does not appear to be part of the embOS/IP code base in what little code ZDI could find online to examine.

ZDI-24-673: DoS when handling multipart requests

This is a particularly curious issue. A logic error exists within the handling of boundary values supplied as part of multipart HTTP requests, resulting in an infinite loop.

Specifically, the following fragment of code is affected which is responsible for processing the multipart request body:

The intention behind this code is to locate the boundary line before processing the content that follows, skipping lines containing CR-LF only. However, when this code is presented with a boundary value different from the one provided in the request headers, the loop never terminates as the buffer data is only consumed on empty lines.

The following, rather minimalistic, request triggers this condition:

Timeline

 Here’s the timeline of our interactions with Deep Sea:

01/21/24 – ZDI requested a vendor PSIRT contact.
01/22/24 – The vendor provided contact information.
01/23/24 – ZDI reported the vulnerability to the vendor
02/05/24 – The vendor states the report was blocked by IT and asked ZDI to resend the report.
02/12/24 – ZDI resent the report using an alternative method.
02/13/24 – The vendor asked why we performed tests on their products.
02/13/24 – ZDI provided the vendor with additional details about the ZDI program.
02/14/24 – The vendor asked what initiated the ZDI to look at the DSE855.
02/14/24 – ZDI emphasized our intent to responsibly disclose this vulnerability to Deep Sea for remediation. The ZDI also offered additional resources about coordinated vulnerability disclosure, as well as feedback on implementing a proper incident response process. We also reiterated our 120-day disclosure policy to ensure the vendor was aware they needed to respond with a patch within the allotted time.
05/24/24 – ZDI informed the vendor that since we never received a response we have assumed this vulnerability remains unpatched, and that we’re publishing this case as a zero-day advisory on 06/13/24.

Summary

The embedded world continues to supply us with a lot of fun bugs, and we at ZDI are always interested in hearing about them from your reports just as much as finding them ourselves—especially in today’s world where a lot of bug classes are mitigated on major platforms like Linux, MacOS, and Windows, a good stack-based buffer overflow exploit writing session presents a welcome respite and a solid return to basics.

I hope you enjoyed this short write-up. Thanks to your continuous submissions, we will continue to post more of that. Until then, you can follow me on Mastodon and the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

If you just want to read the rules, you can find them here.

Over the last few years, our consumer-focused Pwn2Own event took place in the Trend Micro office in Toronto. However, that office closed, so we needed to find a new home. This isn’t unusual for this event, as it moved from Amsterdam to Tokyo to Austin to Toronto. We’re moving again. This year, we are heading to our offices in Cork, Ireland! We’re excited about our new location, and I personally have viewed several locations for after-hours and special events. Some of those will be secret until the competition, but I can tell you that our awards ceremony and end-of-contest party will be held at the historic Cork City Goal. It promises to be a fun and spooky event, and we’ll have more details about that in the future.

Beyond our new location, we’re excited to announce Meta has joined as a sponsor of this event and will participate in the new Messenger App category. That’s right – WhatsApp will be a target, with both 0-click and 1-click exploits being in scope. We’re offering $300,000 USD for a 0-click, so we hope to see some great research on an application used by millions. We’re also excited to announce the return of Synology as a co-sponsor of the event and QNAP joins them as a co-sponsor.

The Messenger App category isn’t the only exciting thing heading to Ireland. This will be our first competition to feature AI-enabled devices. Both the Samsung and Google phones include Galaxy AI and Google AI respectively. Multiple Synology devices use AI for tasks such as people and vehicle recognition on the cameras and AI-driven photo albums on their NAS devices. The Ubiquiti camera also uses AI for greater detection precision and range. There’s no special bonus for exploiting an AI feature, but it will be interesting to see if AI helps or hurts exploit attempts.

Last year’s favorite category was the “SOHO Smashup”, and it returns for another year. This category challenges contestants by having them start by exploiting the external interface of a router, compromise the router, and then pivot to another device connected to the network. In the Toronto event last year, several teams had winning entries in this category. It’s always amazing to watch the researchers as they pivot through multiple attack surfaces to hit their final goal. We’re also bringing wired and wireless cameras back into the contest under the surveillance category. Last year, we awarded $1,038,500 during the event for 58 unique 0-days. It will be interesting to see if the luck of the Irish will take that number up or down.

As for the contest itself, it will run from October 22-25, 2024. As always, we’ll have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there. Registration closes at 5:00 p.m. Irish Standard Time on Oct 17th, 2024. There are no exceptions for late entries, so if you have questions, please contact us at [email protected] (note the new address). We will be happy to address your issues or concerns directly.

Now on to the specific target categories. We’ll have seven different categories for this year’s event:

          - Mobile Phones
          - Messenger Apps
          - The SOHO Smashup
          - Surveilance Systems
          - Home Automation Hubs
          - Printers
          - Smart Speakers
          - NAS Devices

Let’s take a look at each category in more detail, starting with mobile phones.

The Target Phones

Back in Amsterdam where this contest originated, it was originally dubbed “Mobile Pwn2Own” and our focus was strictly on phones. Mobile handsets remain at the heart of this event, and some of the Samsung entries from last year were absolutely smashing. As always, these phones will be running the latest version of their respective operating systems with all available updates installed. You may notice there are no Xiaomi devices in this year’s event. That’s because, during the contest last year, they took measures to ensure attempts would fail. They didn’t seem to mind that those measures impacted all of their users globally. While we do encourage shenanigans, that’s a bit too far to be considered fair. Thus, they are not returning. If you want more details about what happened, be sure to check out Ken Gannon and Ilyes Beghdadi’s upcoming DEFCON talk about the subject.

In this category, contestants must compromise the device by browsing to content in the default browser for the target under test or by communicating with the following short-distance protocols: near field communication (NFC), Wi-Fi, or Bluetooth. The awards for this category are:

The Google and Apple devices in this category also include an add-on bonus. If your exploit payload executes with kernel-level privileges, you earn an additional $50,000 and 5 more Master of Pwn points. That means a full exploit chain that includes kernel-level access on the iPhone or Pixel will earn $300,000 and 30 Master of Pwn points.

Back to top

Messenger Apps

Almost everyone uses some messenger app in their daily lives, and these apps have been the target of sophisticated threats in the past. We’re excited that Meta has agreed to sponsor this event and are hopeful that one (or more) of our contestants will demonstrate a WhatsApp exploit. Both 0-click and 1-click exploits are in scope. All valid submissions must use vulnerabilities reachable via WhatsApp and must not depend on other applications. All WhatsApp entries will be run on a Google Pixel 8.

Back to top

The SOHO Smashup

The proliferation of WFH resulted in many enterprises finding their network perimeter relocated to the home office. Threat actors exploiting home routers and consumer devices can use these as a launch point for lateral movements into enterprise resources. We wanted to demonstrate this during the contest, which means the SOHO Smashup category continues to be relevant. Contestants will need to first compromise the WAN port on a selected router. Once they accomplish that not-so-insignificant feat, they will need to pivot to one of the other devices and compromise it as well. The contestant is free to select any combination of router and home automation hub, smart speaker, printer, or network-attached storage device during the registration process – although you won’t have some of the same easy targets as last year. If they get both devices within 30 minutes, they earn $100,000 and 10 Master of Pwn points.

Back to top

Surveillance Systems

Last year, we introduced this category not knowing what to expect. As usual, our contestants did not disappoint as they unleashed some fantastic exploits – including taking over a camera just by showing it a QR code. Cameras continue to be a part of daily life, and we can’t wait to see what research is put on display this year. An attempt in this category must be launched against the target’s exposed network services or the target’s exposed features from the contestant’s laptop within the contest network.

Back to top

Home Automation Hubs

Many of the cameras and other “smart” devices are connected to a centralized hub. From lights to locks to thermostats, cameras, and more, all can be accessed through a home automation hub. Of course, that means a threat actor could potentially access them as well. This year, we’re introducing the AeoTec Smart Home Hub in this category, so we’ll see if our contestants take a run at it. Here are the targets in the Home Automation category:

Back to top

Rage Against the Printers

Printers have long been the source of jokes and memes, but they are also an often overlooked attack surface in your office. The printer category always produces some interesting results, often by playing music it shouldn’t or the occasional Rick Roll. It will be interesting to see what exploits the contestants come up with this year.

Back to top

Smart Speakers

Smart speakers continue to play a large part in our daily interactions with music, news, and more. They also offer an attack surface for threat actors to target. For this event, Pwn2Own Ireland has three targets available in this category.

Back to top

Network Attached Storage (NAS) Devices

NAS devices make their return to Pwn2Own. This year, QNAP and TrueNAS enter as targets alongside the returning Synology devices. An attempt in this category must be launched against the target’s exposed network services from the contestant’s laptop within the contest network. For the Synology DiskStation target, we’ll have several packages enabled and in scope. These packages are as follows:

— MailPlus
— Drive
— Virtual Machine Manager
— Snapshot Replication
— Surveillance Station
— Photos

Here’s the full table of targets in the NAS category for 2024:

Back to top

Master of Pwn

No Pwn2Own contest would be complete without crowning a Master of Pwn, which signifies the overall winner of the competition. Earning the title results in a slick trophy, a different sort of wearable, and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2025).

For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it. If the contestant decides to remove an Add-on Bonus during their attempt, the Master of Pwn points for that Add-on Bonus will be deducted from the final point total for that attempt. For example, someone registers for the Apple iPhone 15 with the Kernel Bonus Add-on. During the attempt, the contestant drops the Kernel Bonus Add-on but completes the attempt. The final point total will be 20 Master of Pwn points.

The Complete Details

The full set of rules for Pwn2Own Ireland 2024 can be found here. They may be changed at any time without notice. We highly encourage potential entrants to read the rules thoroughly and completely should they choose to participate. We also encourage contestants to read this blog covering what to expect when participating in Pwn2Own.

Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at [email protected] to begin the registration process. (Email only, please; queries via social media, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing to determine the contest order. Registration closes at 5:00 p.m. Irish Standard Time on Oct 17th, 2024.

The Results

We’ll be blogging and tweeting results in real time throughout the competition. Be sure to keep an eye on the blog for the latest information. Follow us on Twitter at @thezdi and @trendmicro, and keep an eye on the #P2OIreland hashtag for continuing coverage.

We look forward to seeing everyone in Cork, and we look forward to seeing what new exploits and attack techniques they bring with them.

With special thanks to our Pwn2Own Ireland partner Meta and our co-sponsors, Synology and QNAP, for providing their assistance and technology.

©2024 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

On patch Tuesday last week, Microsoft released an update for CVE-2024-38112, which they said was being exploited in the wild. We at the Trend Micro Zero Day Initiative (ZDI) agree with them because that’s what we told them back in May when we detected this exploit in the wild and reported it to Microsoft. However, you may notice that no one from Trend or ZDI was acknowledged by Microsoft. This case has become a microcosm of the problems with coordinated vulnerability disclosure (CVD) as vendors push for coordinated disclosure from researchers but rarely practice any coordination regarding the fix. This lack of transparency from vendors often leaves researchers who practice CVD with more questions than answers.

If you’re just interested in the technical details of the bugs we discovered in the wild, my colleagues Peter and Ali have a fantastic write-up here, which includes IOCs and detection guidance.

What happened to transparency in communication?

We were surprised by the publication of CVE-2024-38112, and we weren’t the only ones. When an In-the-Wild (ITW) exploit goes unpatched for that long a time, it’s not unusual for someone else to independently discover it. In this instance, it was Haifei Li at Check Point who also detected this ITW and reported it to Microsoft. He too was surprised by the patch and noted it wasn’t the first occurrence: 

Figure 1 - Tweet from Haifei Li - https://x.com/HaifeiLi/status/1810743597127582135

That doesn’t seem to be the only communication problem from this release. Kẻ soi mói, a researcher from Dataflow Security, expressed his dismay about SharePoint bugs getting fixed that were similar to bugs he had submitted but were as yet unactioned:

Figure 2 - Tweets from Kẻ soi mói - https://x.com/testanull/status/1810837531770134709

His frustration with the disclosure process here is clear. Even when there are no obvious communication issues when reporting a bug, there can be issues when the fix is disclosed. That is what happened with Valentina Palmiotti, a researcher with IBM X-Force. She had a winning entry at Pwn2Own this year, but when the fix was released, despite literally handing Microsoft a working exploit, they made an odd choice in the CVSS rating:

Figure 3 - Tweet from Valentina Palmiotti - https://x.com/chompie1337/status/1800691497949614135

CVD doesn’t work if the only ones coordinating are the researchers. While these are Microsoft examples, there are multiple occasions from various vendors where “coordination” simply means “You tell us everything you know about this bug, and maybe something will happen.”

How can we trust you if you aren’t acting trustworthy?

In the Fall of 2023, Microsoft launched its Secure Future Initiative (SFI). Many in the security community – me included – hoped this would be like the TwC memo from Bill Gates that launched the MSRC and would result in a new age of security and transparency from the Redmond giant. Sadly, that has failed to materialize.

In May of this year, they updated their SFI site with additional information, including a whitepaper entitled, Setting a new standard for faster vulnerability response and security updates [PDF]. Interestingly, it included the following graphic defining the vulnerability lifecycle at Microsoft.

Figure 4 – Microsoft’s view of the vulnerability lifecycle

As a former Microsoft employee, I recognize this graphic as it was something similar to one I saw while there. At the bottom there is “Partner with Researcher”, which implies that open communications happen throughout the process, however, that clearly isn’t happening.

Vendors want researchers to trust them, but they aren’t taking the necessary steps to earn our trust. What’s sad is that we aren’t asking for a lot. Tell us you’ve received the report. Confirm or deny our findings. Tell us when a patch is coming. Acknowledge us appropriately (and spell our name right). And finally, once the patch is available, tell us where we can find the patch. Strangely, one of the biggest problems we have at the ZDI is just getting vendors to tell us when something is fixed.

Who arbitrates disagreements?

Here at the ZDI, one of the best things we offer researchers who sell bugs to us is that we handle the communications with the vendors. What happens when the vendor states the fix should be a defense-in-depth update rather than a full CVE? What happens when the vendor states the impact is spoofing but the bug results in remote code execution? If you’re a lone researcher, your voice might not be heard. The ZDI has existed since 2005, so we have a lot of experience in disclosing bugs and understand how to argue on behalf of the researcher.

There are times when even the ZDI is often not heard when these disagreements are had. However, we have the advantage of blogging platforms, social media, PR agencies, and legal teams backing us up. The average researcher typically doesn’t have access to such resources. The option to just 0-day the bug and release everything publicly becomes quite attractive. It’s not just about disagreements – it’s about network defenders and end users not having the right information to estimate the risk to their enterprises.

Let’s take CVSS ratings as an example. In the last patch Tuesday, Microsoft rated a RADIUS vulnerability as CVSS 7.5, but the researcher who discovered the bug rated it as a 9.0. Not only does that change the severity level from High to Critical, but it could also change how quickly a patch is deployed. Maybe your enterprise rolls out Critical-rated patches in 30 days but allows up to 90 for High severity bugs. A simple disagreement could result in a drastically different security posture for millions of people. In one sense, the CVE program was supposed to solve this problem. There exists a methodology for disputing CVEs [PDF], but this dispute process has not proved effective.

Other than bounties, why would researchers report bugs to vendors who don’t coordinate?

If you don’t offer a bounty payout and don’t coordinate with researchers or properly credit them, why in the world would anyone report bugs to you? Let’s say you’ve had a bad experience with a vendor. For most, they stop reporting bugs to that vendor. It’s not worth their time or effort. And I totally understand that feeling. However, that doesn’t mean that bugs in that vendor’s product simply disappear. Threat actors don’t care if a vendor is difficult to work with; they just keep exploiting the bugs until they can’t.

If researchers are actually worried about exploitation but don’t want to deal with the vendor, what’s stopping them from just dropping 0-day? That way, they know they will be credited, and the vendors typically move fast on publicly known bugs. Of course, vendors say that would be irresponsible of the researchers. And the researchers think it’s irresponsible for multi-billion dollar corporations to release shoddy code. That’s where the idea of “coordinated disclosure” came from. It took the good ideas of “responsible disclosure” and removed the moral judgments. CVD was also meant to acknowledge the vendor has a responsibility to the researcher. This is the part of the CVD process that needs the most improvement. Researchers have responded by doing their part; now it’s time to have the vendors step up and do theirs.

Quis custodiet ipsos custodes?

In April of 2024, the Cyber Safety Review Board (CSRB) released a report on Microsoft’s response to the Exchange Online intrusion from 2023. As a result of that report and the recommendations laid out in it, Microsoft president Brad Smith testified before Congress concerning the ongoing security improvements at Microsoft. Interestingly, on the same day, an article from ProPublica detailed how Microsoft ignored warnings from one of their engineers about a problem that led to the SolarWinds compromise.

While it’s good to see some official accountability somewhere, we as an industry must hold each other accountable for open and transparent communications as well. That’s one of the reasons the ZDI will be launching the Vanguard Awards at this year’s Black Hat. These awards are designed to highlight the best of both researchers and vendors. There won’t be a “failure” category because we’d rather reward outstanding work rather than highlight mistakes or miscalculations. We’ll be presenting vendor awards in five categories:

-              Best Security Advisories
-              Most Transparent Communication
-              Most Collaborative
-              Most Improved
-              Fastest to Patch

The winners of some of these will likely turn some heads, but it’s our way of monitoring and rewarding those in the industry who go above and beyond to make CVD work for everyone.

Conclusion 

Why is CVD not working? Have the number of bugs being disclosed increased to the level where vendors simply cannot cope with the level of coordination? Have budget cuts reduced the number of response personnel vendors employ? Has the rush to automation come at the expense of coordination? Are researchers just reporting to an API and no humans are reviewing the reports? As I said, we’re left with more questions than answers.

The lack of coordination doesn’t just hurt the vendor/researcher relationship. It hurts the end users. It lowers their ability to gauge risk, and it lowers their trust in security patches as well. Hopefully, increased government scrutiny and industry programs like the Vanguard Awards will serve as a stick-and-carrot approach that results in positive changes. It is said that security is a journey rather than a destination. Improvement works the same way. We can always get better, but we have to agree that we need to.

You can find me on Twitter at @dustin_childs and on Mastodon at @TheDustinChilds, and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

We’re just past the halfway point of 2024, and as expected, Microsoft and Adobe have released their regularly scheduled updates. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for July 2024

For July, Adobe released three patches addressing seven CVEs in Adobe Premiere Pro, InDesign, and Adobe Bridge. The patch for InDesign is the largest, fixing four Critical-rated CVEs. All four could lead to arbitrary code execution. The fix for Premiere Pro fixes a single CVE that could lead to arbitrary code execution. Finally, the fix for Bridge fixes one Critical rated and one Important rated bug. The Critical-rated bug could lead to code execution while the other bug is a memory leak. After such a huge Adobe release last month, it’s nice to see a smaller one this month.

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 a deployment priority rating of 3.

Microsoft Patches for July 2024

This month, Microsoft released a gargantuan 139 new CVEs in Windows and Windows Components; Office and Office Components; .NET and Visual Studio; Azure; Defender for IoT; SQL Server; Windows Hyper-V; Bitlocker and Secure(?) Boot; Remote Desktop; and Xbox (yes Xbox!). If you include the third-party CVEs being documented this month, the CVE count comes to 142. One of these cases came through the ZDI program.

Of the patches being today, five are rated Critical, 133 are rated Important, and three are rated Moderate in severity. This release is another huge bunch of fixes from Redmond, just shy of the record 147 CVEs from back in April this year.

Two of these CVEs are listed as publicly known, with one of those being a third-party update that’s now being integrated into Microsoft products. Two other bugs are listed as being under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

-       CVE-2024-38080 – Windows Hyper-V Elevation of Privilege Vulnerability
This vulnerability could allow an authenticated threat actor to execute code with SYSTEM privileges. While not specifically stated by Microsoft, let’s assume the worst-case scenario and say that an authorized user could be on a guest OS. Microsoft also does not state how widespread the exploitation is, but this exploit would prove quite useful for ransomware. If you’re running Hyper-V, test and deploy this update quickly.

-       CVE-2024-38112 – Windows MSHTML Platform Spoofing Vulnerability
This bug is listed as “Spoofing” for the impact, but it’s not clear exactly what is being spoofed. Microsoft has used this wording in the past for NTLM relay attacks, but that seems unlikely here. Given the researcher who reported this to Microsoft, we’ll likely see additional analysis from them soon. The good news is that a user would need to click a link to be affected. The bad news is that users click anything.

-       CVE-2024-38077 – Windows Remote Desktop Licensing Service Remote Code Execution Vulnerability
This is one of three Remote Desktop Licensing RCEs getting fixed this month, and all have a CVSS rating of 9.8. Exploitation of this should be straightforward, as any unauthenticated user could execute their code simply by sending a malicious message to an affected server. As a temporary workaround, you could disable the Licensing Service, but if you’re running it, you likely need it. I would also ensure these servers are not addressable to the Internet. If a bunch of these servers are Internet-connected, I would expect exploitation soon. Now is also a good time to audit your servers to ensure they aren’t running any unnecessary services.

-       CVE-2024-38060 – Microsoft Windows Codecs Library Remote Code Execution Vulnerability
This bug does require the attacker to be authenticated, but any authenticated user could abuse it. It simply requires an authenticated user to upload a specially crafted TIFF image to an affected system. This would be a nifty method for lateral movement once an initial foothold has been achieved. There are no workarounds either, so test and deploy the patch quickly.

-       CVE-2024-38023 – Microsoft SharePoint Server Remote Code Execution Vulnerability
This vulnerability also requires authentication, but any SharePoint user with Site Owner permissions can hit it. However, the default configuration of SharePoint allows authenticated users to create sites. That’s why I disagree with Microsoft’s CVSS rating here. By changing “Privileges Required” to low instead of high, it takes it from a 7.2 to (IMHO) more accurate 8.8. We blogged about this type of bug in the past. These types of bugs have been exploited in the past, so if you’re running SharePoint, don’t disregard or delay implementing this fix.

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

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

There are a total of 59 code execution bugs in this release, which is more CVEs than the entire June release. However, 38 of these are related to SQL Server and require a user to connect to a malicious SQL server database. That does seem unlikely, but it could be used as a post-exploitation technique for lateral movement. There’s an interesting bug in the Windows Multipoint Service, but it requires the service to be restarted for an attack to succeed. The one, new publicly known bug this month is in .NET Framework and Visual Studio. It’s an interesting race condition, but it seems unlikely to be exploited. There are the standard open-and-own Office bugs, including one that requires multiple security updates to fully address the vulnerability. Be sure to check for the “†” in the above table. There are some authenticated RCEs in the Performance Data Helper Library, but these require elevated permissions. There are additional SharePoint fixes, but it’s not clear why these are rated Important instead of Critical. There’s a scary-sounding bug in the DHCP server, but it also requires high privileges. That’s the same for the bug in Windows DTC. There’s a bug for adjacent attackers to use in the Layer-2 Bridge Network Driver. It’s not often you see exploits that low on the OSI model, but this one doesn’t require authentication. The final RCE fixes for this month happen in components you don’t expect to see patches for. The first is in the Azure Kinect SDK. Yes – that Kinect. It requires someone actually plug in a malicious USB drive to an affected system. The Kinect SDK is available for Windows and Linux, but it’s not clear if the fix covers both. Then there are fixes for the Xbox and Xbox Wireless Controller. For the Xbox, an unauthenticated attacker could get code execution by sending a malicious networking packet to an adjacent console that employs a Wi-Fi networking adapter. That’s the same scenario for the controller. Obviously, an attacker would need to be in close proximity to achieve this exploit.

There are a couple dozen fixes for Elevation of Privilege (EoP) bugs in this release, but most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bug in the Text Services Framework could be used as a sandbox or AppContainer escape. The bug in Defender for IoT could also be used as an AppContainer escape. Two of the PowerShell bugs allow a threat actor to go from a restrained user to an unrestrained WDAC user. PowerShell is often used for post-exploitation for lateral movement, so this technique would be handy for those living off the land. The bug is the Workstation Service could allow an attacker to overwrite critical structures of the service, leading to arbitrary memory writing or control flow hijacking. Not exactly a common technique, but it does lead to a privilege escalation. Finally, the bug in Azure CycleCloud could allow an authenticated user to escalate to the Administrator role on affected Azure CycleCloud instances. If you’re using this component, you need to update your CycleCloud VMs. If you aren’t familiar with that process, Microsoft provides some guidance here.

There are also two dozen fixes for security feature bypass (SFB) bugs, although I think we need to rename a component. Between 23 fixes in April and 20 more this month, I don’t think we can really call it Secure Boot anymore. Even worse, all but two of these could be exploited by an Adjacent attacker with LAN access to the target. Oof. I’m calling this feature “Protected Boot” rather than “Secure Boot”. The SFB bug in BitLocker requires physical access, but BitLocker is specifically designed to prevent this sort of attack, so…er…not good. The SFB in cryptographic services requires a SHA1 hash collision. The bug in the Windows Enroll Engine could allow a threat actor to avoid certificate validation during the enrollment process, but the exploitation would be complicated.

There are only nine information disclosure bugs receiving fixes this month and most only result in info leaks consisting of unspecified memory contents. There are only two exception. The bug in the on prem version of Dynamics 365 discloses data stored in the underlying datasets in Dataverse. This could include Personal Identifiable Information (PII). The bug in SharePoint could disclose data from the targeted website including IDs, tokens, cryptographic nonces, or other sensitive information.

There are quite a few Denial-of-Service (DoS) bugs in the July release, but Microsoft provides very little information about the details. It would be nice to know if these are blue screens or just a service-level DoS. We do know that the bugs in the iSCSI service and the Layer-2 Bridge Network driver require the attacker to be adjacent. The same goes for the bug in the Line Printer Daemon Service and the Network Driver Interface Specification. Lastly, one of the DoS bugs in the Remote Desktop Licensing Service requires some extra steps beyond the patch. According to Microsoft, “If your RD session hosts and RD licensing servers are joined to a workgroup, you need to ensure that your RD session hosts have the necessary credentials to access your RD licensing servers.” You can find additional information about that here.

The July release is rounded out by a few spoofing bugs. Probably the most important of these is the bug in Outlook that could result in NTLM relaying. Fortunately, the Preview Pane is not an attack vector. Although not specifically stated, one would assume the same for the NTLM spoofing bug. And while not as clear, one would assume the same for the spoofing bug in Themes as Microsoft lists disabling NTLM as a workaround. Finally, the bugs in Azure DevOps Server are listed as spoofing, but they could also be used for DoS or Information Disclosure.

There are no new advisories in this month’s release.

Looking Ahead

The next Patch Tuesday of 2024 will be on August 13, and I’ll return with details and patch analysis then. I’ll also be at Black Hat and DEFCON, so if you’re there, I’d love to chat about all things patches and bug bounties. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Earlier this year, the Trend Micro Zero Day Initiative (ZDI) acquired several vulnerabilities in the Logsign Unified SecOps Platform. These were all reported to the ZDI by Mehmet INCE (@mdisec) from PRODAFT.com. According to Logsign’s website:

Logsign provides comprehensive visibility and control of your data lake by allowing security analysts to collect and store unlimited data, investigate and detect threats, and respond automatically.

Logsign offers a single, unified whole security operation platform to alleviate the challenges associated with deploying multiple cybersecurity tools while reducing the costs and complexities that come with managing them individually.

Logsign runs as a Python-based web server. Users have the ability to interact with the web server through a variety of APIs. This blog looks at two separate vulnerabilities that can be combined to achieve remote, unauthenticated code execution on the web server via HTTP requests.

CVE-2024-5716 – Authentication Bypass

This vulnerability allows remote attackers to bypass authentication on affected installations of Logsign Unified SecOps Platform. The specific flaw exists within the password reset mechanism. The issue results from the lack of restrictions on excessive password reset attempts. An attacker can leverage this vulnerability to reset a user's password and bypass authentication on the system.

Anyone who can access TCP port 443 on the web server can request a password reset for a username. Once requested, the server sends a reset_code, which is a 6-digit number, to the email address associated with the username. Under normal operations, the user then uses the reset_code to reset their password.

The vulnerability is due to there being no rate limiting for requesting a reset_code. Since there is a default user named “admin”, an attacker can send multiple requests to reset the admin’s password until they brute force the correct reset_code. The attacker can then reset the admin’s password and log in as an administrator.

This vulnerability is located in /opt/logsign-api/api.py:

If we send a POST request to https://LOGSIGNIP/api/settings/forgotpassword, the server will use this function to handle it.

       -- On line [1], it gets the username parameter from the POST request.
       -- On line [2], it checks if this user is not from_ldap, which is the default configuration. It then sets reset_code to random_int(6).

reset_code is set to a randomly-selected string of 6 decimal digits. Finally, the server stores the username and reset_code pair, and sends reset_code to the user's email.

If we send a POST request to https://LOGSIGN_IP/api/settings/verify_reset_code, the server will use the above function to handle it. If the username and reset_code are correct, the server responds with verification_code. Once in possession of this verification_code, the attacker will be permitted to reset the password.

On the line marked [1] in the code snippet above, we find a 3-minute time check. However, this is merely a check against the expiry time of the reset_code and not a rate-limiter. An attacker can make numerous attempts at guessing the reset_code by calling verify_reset_code as many times as possible within the 3-minute window. If the attacker fails within these 3 minutes, they can send another request to https://LOGSIGNIP/api/settings/forgotpassword and repeat the brute-force attack until they succeed. Since there are only 1 million possible values for reset_code, it is feasible to enumerate within the allotted time a significant proportion of all possible codes.

Once the attacker has guessed the reset_code and successfully obtained the verification_code, the attacker can call the reset_user_password endpoint, passing the verification_code:

When the server receives the correct username and verification_code, it allows the attacker to reset the user’s password.

The Exploit

The exploit is designed to use as many threads as possible to guess the reset_code.

We tested this with Logsign installed on a VMware virtual machine with 8 CPUs and 16GB of memory. Our attacker machine was capable of running 20 threads, which equated to roughly 15,000 attempts within 3 minutes.

CVE-2024-5717 – Post-Auth Command Injection

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Logsign Unified SecOps Platform. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.

The specific flaw results from 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 execute code in the context of root.

This vulnerability resides in /opt/logsign-api/settings_api.py:

If a user sends a POST request to https://LOGSIGNIP/api/settings/demomode, the server will use this function to handle the request.

      -- On line [1], we see that the user needs to be authenticated to make this request. Hence this a post-authentication vulnerability.

The POST data for this request is as follows:

      -- On line [2], the server takes value of the list parameter from the POST data and passes it to escapeshellarg. It then takes the result of escapeshellarg, encloses it in single-quotes, and adds it as a parameter to a shell command using string concatenation.

To a PHP programmer, it seems that the escapeshellarg() function sanitizes the list string and makes this code secure. Unfortunately, this is Python, and escapeshellarg() is not a built-in function in Python. (Note that Python ships with its own mechanisms for sanitizing shell parameters.) Instead, what appears here as escapeshellarg()is a custom implementation that can be trivially bypassed.

The escapeshellarg() function is defined in /opt/logsign-commons/python/logsign/commons/helpers.pyc. Using python_uncompyle6 to decompile helpers.pyc, we obtain the following Python script:

escapeshellarg() only escapes single quote characters! Therefore, we can use any command injection technique as long as it doesn’t rely on single quotes.

This command injection works only once. If you want to subsequently execute another command, you need to first issue a request changing enable back to false. Then you can send the first request again to perform another command injection.

The Exploit

The exploit for this vulnerability is relatively simple. We will use backticks as a means of shell command injection, since this does not require single quotes. We can execute any shell command we wish, provided that our command does not itself contain any single quotes.

Combining CVE-2024-5716 and CVE-2024-5717

While the command injection vulnerability is post-auth, we can combine it with the authentication bypass to make it a pre-auth code execution. We use CVE-2024-5716 to reset the admin’s password, then log in with the admin’s credential and execute the command injection.

In this exploit, we use the command injection to get a reverse shell. We use a Python reverse shell, since Logsign installs Python by default.

Conclusion

Logsign patched these and other vulnerabilities with version 6.4.8. Combining these bugs shows why even post-authentication bugs are worth fixing. When paired with an authentication bypass, a post-auth bug becomes pre-auth relatively quickly. We have seen situations like this at Pwn2Own competitions, in which a vendor believed that the addition of authentication was sufficient for defense.

The authentication bypass vulnerability shown here is a textbook example of the problems that can arise when implementing your own authentication mechanism. (See Web Application Hacker’s Handbook, Chapter 6, Forgotten Password Functionality, Hack Step 5.)  The presence of this rudimentary vulnerability should prompt the vendor to perform a full audit of their software.

I hope you enjoyed this blog and remember not to be daunted by authentication. Until my next post, you can follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

Somehow, we’ve made it to the sixth patch Tuesday of 2024, and Microsoft and Adobe have released their regularly scheduled updates. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for June 2024

For June, Adobe released 10 patches addressing 165(!) CVEs in Adobe Cold Fusion, Photoshop,  Experience Manager, Audition, Media Encoder, FrameMaker Publishing Server, Adobe Commerce, Substance 3D Stager, Creative Cloud Desktop, and Acrobat Android. The fix for Experience Manager is by far the largest with a whopping 143 CVEs addressed. However, all but one of these bugs are simply cross-site scripting (XSS) vulnerabilities. The patch for Cold Fusion fixes two bugs, but neither are code execution bugs. That’s the same case for the patch addressing bugs in Audition. The fix for Media Encoder has a single OOB Read memory leak fixed. The update for Photoshop also has just one bug – a Critical-rated code execution issue. That’s also the story for the Substance 3D Stager patch.

The patch for FrameMaker Publishing Server has only two bugs, but one is a CVSS 10 and the other is a 9.8. If you’re using this product, this should be the first patch you test and deploy. The patch for Commerce should also be high on your test-and-deploy list as it corrects 10 bugs, including some Critical-rated code execution vulns. The patch for Creative Cloud Desktop fixes a single code execution bug. Finally, the patch for Acrobat Android corrects two security feature bypasses.

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 a deployment priority rating of 3.

Microsoft Patches for June 2024

This month, Microsoft released 49 CVEs in Windows and Windows Components; Office and Office Components; Azure; Dynamics Business Central; and Visual Studio. If you include the third-party CVEs being documented this month, the CVE count comes to 58. A total of eight of these bugs came through the ZDI program, and that does include some of the cases reported during the Pwn2Own Vancouver contest in March.

Of the new patches released today, only one is rated Critical, and 48 are rated Important in severity. This release is another small release when compared to the monster that was April.

Only one of the CVEs listed today is listed as publicly known, but that’s actually just a third-party update that’s now being integrated into Microsoft products. Nothing is listed as being under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with the lone Critical-rated patch for this month:

-       CVE-2024-30080 – Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability
This update receives a CVSS rating of 9.8 and would allow remote, unauthenticated attackers to execute arbitrary code with elevated privileges of systems where MSMQ is enabled. That makes this wormable between those servers, but not to systems where MSMQ is disabled. This is similar to the “QueueJumper” vulnerability from last year, but it’s not clear how many affected systems are exposed to the internet. While it is likely a low number, now would be a good time to audit your networks to ensure TCP port 1801 is not reachable.  

-       CVE-2024-30103 – Microsoft Outlook Remote Code Execution Vulnerability
This patch corrects a bug that allows attackers to bypass Outlook registry block lists and enable the creation of malicious DLL files. While not explicitly stated, attackers would likely then use the malicious DLL files to perform some form of DLL hijacking for further compromise. The good news here is that the attacker would need valid Exchange credentials to perform this attack. The bad news is that the exploit can occur in the Preview Pane. Considering how often credentials end up being sold in underground forums, I would not ignore this fix.  

-       CVE-2024-30078 – Windows Wi-Fi Driver Remote Code Execution Vulnerability
This vulnerability allows an unauthenticated attacker to execute code on an affected system by sending the target a specially crafted network packet. Obviously, the target would need to be in Wi-Fi range of the attacker and using a Wi-Fi adapter, but that’s the only restriction. Microsoft rates this as “exploitation less likely” but considering it hits every supported version of Windows, it will likely draw a lot of attention from attackers and red teams alike.

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

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the other fixes addressing code execution bugs, there are a couple that stand out. In addition to the Wi-Fi bug above, there are two similar bugs in the Link Layer Topology Discovery Protocol with similar exploit vectors. The difference is that for these two bugs, the target needs to be running the Network Map functionality for the attack to succeed. There are several “open-and-own” type vulnerabilities getting patched. The one to look out for would be the Office bug that states, “The Preview Pane is an attack vector, but additional user interaction is required.” It’s not clear how that would manifest. The exploit for DFS requires an adjacent attacker to already be executing code on a target, which reads more like an EoP to me. The OLE bug requires connecting to a malicious SQL server. The bug in the Speech Application Programming Interface (SAPI) requires a user to click a link to connect to the attacker’s server. Lastly, the code execution bug in Dynamics 365 requires authentication, which again sounds more like an EoP, but it also states no user interaction is required. It’s an odd write-up that implies it’s unlikely to be exploited in the wild.

More than half of this month’s release corrects privilege escalation bugs, but the majority of these lead to SYSTEM-level code execution if an authenticated user runs specially crafted code. Other privilege escalation bugs would allow the attacker to get to the level of the running application. The bugs in Winlogon are somewhat intriguing as they could allow an attacker to replace valid file content with specially crafted file content. One of the kernel bugs could be used for a container escape. The bug in the Perception Service could allow elevation to the “NT AUTHORITY\LOCAL SERVICE” account. The vulnerability in Visual Studio requires an attacker to create a malicious extension. An authenticated user would then need to create a Visual Studio project that uses that extension. If they manage all of that, it would lead to admin privileges.

The bug in Azure Identity Libraries and Microsoft Authentication Library allows attackers to read any file on the target with SYSTEM privileges. The privilege escalation in Azure Monitor Agent could let attackers delete files and folders. If you’ve disabled Automatic Extension Upgrades, you’ll need to perform a manual update to ensure the Monitor Agent is at the latest version. Speaking of extra actions, the bug in the Azure Science Virtual Machine (DSVM) requires you to upgrade your DSVM to Ubuntu 20.04. If you’re not familiar with this procedure, Microsoft provides this article for guidance. Attackers who exploit this bug could gain access to user credentials, which would allow them to impersonate authorized users.

There are only three information disclosure bugs receiving fixes this month and only one results in info leaks consisting of unspecified memory contents. The bug in the on prem version of Dynamics 365 could allow an attacker to exfiltrate all the data accessible to the logged-on user. The vulnerability in the Cryptographic Services could disclose sensitive information such as KeyGuard (KG) keys, which are intended to be per-boot and used to protect sensitive data. If an attacker could potentially use these to decrypt anything encrypted with those keys.

The final bugs for June address Denial-of-Service (DoS) vulnerabilities in Windows and Azure components. Unfortunately, Microsoft provides no additional information about these bugs and how they would manifest on affected systems. They do note the DoS in the DHCP Server does not affect those who have configured failover for their DHCP setup.

There are no new advisories in this month’s release.

Looking Ahead

The next Patch Tuesday of 2024 will be on July 9, and I’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Yes, the title is right. This blog covers an XML eXternal Entity (XXE) injection vulnerability that I found in SharePoint. The bug was recently patched by Microsoft. In general, XXE vulnerabilities are not very exciting in terms of discovery and related technical aspects. They may sometimes be fun to exploit and exfiltrate data (or do other nasty things) in real environments, but in the vulnerability research world, you typically find them, report them, and forget about them.

So why am I writing a blog post about an XXE? I have two reasons:

·       It affects SharePoint, both on-prem and cloud instances, which is a nice target. This vulnerability can be exploited by a low-privileged user.
·       This is one of the craziest XXEs that I have ever seen (and found), both in terms of vulnerability discovery and the method of triggering. When we talk about overall exploitation and impact, this Pwn2Own win by Chris Anastasio and Steven Seeley is still my favorite.

The vulnerability is known as CVE-2024-30043, and, as one would expect with an XXE, it allows you to:

·       Read files with SharePoint Farm Service account permission.
·       Perform Server-side request forgery (SSRF) attacks.
·       Perform NTLM Relaying.
·       Achieve any other side effects to which XXE may lead.

Let us go straight to the details.

BaseXmlDataSource DataSource

Microsoft.SharePoint.WebControls.BaseXmlDataSource is an abstract base class, inheriting from DataSource, for data source objects that can be added to a SharePoint Page. DataSource can be included in a SharePoint page, in order to retrieve data (in a way specific to a particular DataSource). When a BaseXmlDataSource is present on a page, its Execute method will be called at some point during page rendering:

At [1], you can see the Execute method, which accepts a string called request. We fully control this string, and it should be a URL (or a path) pointing to an XML file. Later, I will refer to this string as DataFile.

At this point, we can derive this method into two main parts: XML fetching and XML parsing.

       a) XML Fetching

At [2], this.FetchData is called and our URL is passed as an input argument. BaseXmlDataSource does not implement this method (it’s an abstract class).

FetchData is implemented in three classes that extend our abstract class:
• SoapDataSource - performs HTTP SOAP request and retrieves a response (XML).
• XmlUrlDataSource - performs a customizable HTTP request and retrieves a response (XML).
• SPXmlDataSource - retrieves an existing specified file on the SharePoint site.

We will revisit those classes later.

       b) XML Parsing

At [3], the xmlReaderSettings.DtdProcessing member is set to DtdProcessing.Prohibit, which should disable the processing of DTDs.

At [4] and [5], the xmlTextReader.XmlResolver is set to a freshly created XmlSecureResolver. The request string, which we fully control, is passed as the securityUrl parameter when creating the XmlSecureResolver

At [6], the code creates a new instance of XmlReader.

Finally, it reads the contents of the XML using a while-do loop at [7].

At first glance, this parsing routine seems correct. The document type definition (DTD) processing of our XmlReaderSettings instance is set to Prohibit, which should block all DTD processing. On the other hand, we have the XmlResolver set to XmlSecureResolver.

From my experience, it is very rare to see .NET code, where:
• DTDs are blocked through XmlReaderSettings.
• Some XmlResolver is still defined.

I decided to play around and sent in a general entity-based payload at some test code I wrote similar to the code shown above (I only replaced XmlSecureResolver with XmlUrlResolver for testing purposes):

As expected, no HTTP request was performed, and a DTD processing exception was thrown. What about this payload?

It was a massive surprise to me, but the HTTP request was performed! According to that, it seems that when you have .NET code where:
• XmlReader is used with XmlTextReader and XmlReaderSettings.
• XmlReaderSettings.DtdProcessing is set to Prohibit.
• An XmlTextReader.XmlResolver is set.

The resolver will first try to handle the parameter entities, and only afterwards will perform the DTD prohibition check! An exception will be thrown in the end, but it still allows you to exploit the Out-of-Band XXE and potentially exfiltrate data (using, for example, an HTTP channel).

The XXE is there, but we have to solve two mysteries:

• How can we properly fetch the XML payload in SharePoint?
• What’s the deal with this XmlSecureResolver?

XML Fetching and XmlSecureResolver

As I have already mentioned, there are 3 classes that extend our vulnerable BaseXmlDataSource. Their FetchData method is used to retrieve the XML content based on our URL. Then, this XML will be parsed with the vulnerable XML parsing code.

Let’s summarize those 3 classes:

       a) XmlUrlDataSource

       • Accepts URLs with a protocol set to either http or https.
       • Performs an HTTP request to fetch the XML content. This request is customizable. For example, we can select which HTTP method we want to use.
       • Some SSRF protections are implemented. This class won’t allow you to make HTTP requests to local addresses such as 127.0.0.1 or 192.168.1.10. Still, you can use it freely to reach external IP address space.

       b) SoapDataSource

       • Almost identical to the first one, although it allows you to perform SOAP requests only (body must contain valid XML, plus additional restrictions).
       • The same SSRF protections exist as in XmlUrlDataSource.

       c) SPXmlDataSource

       • Allows retrieval of the contents of SharePoint pages or documents. If you have a file test.xml uploaded to the sample site, you can provide a URL as follows: /sites/sample/test.xml.

At this point, those HTTP-based classes look like a great match. We can:
• Create an HTTP server.
• Fetch malicious XML from our server.
• Trigger XXE and potentially read files from SharePoint server.

Let’s test this. I’m creating an XmlUrlDataSource, and I want it to fetch the XML from this URL:

       http://attacker.com/poc.xml

poc.xml contains the following payload:

The plan is simple. I want to test the XXE by executing an HTTP request to the localhost (SSRF).

We must also remember that whatever URL that we specify as our source also becomes the securityUrl of the XmlSecureResolver. Accordingly, this is what will be executed:

Figure 1 XmlSecureResolver initialization

Who cares anyway? YOLO and let’s move along with the exploitation. Unfortunately, this is the exception that appears when we try to execute this attack:

Figure 2 Exception thrown during XXE->SSRF

It seems that “Secure” in XmlSecureResolver stands for something. In general, it is a wrapper around various resolvers, which allows you to apply some resource fetching restrictions. Here is a fragment of the Microsoft documentation:

“Helps to secure another implementation of XmlResolver by wrapping the XmlResolver object and restricting the resources that the underlying XmlResolver has access to.”

In general, it is based on Microsoft Code Access Security. Depending on the provided URL, it creates some resource access rules. Let’s see a simplified example for the http://attacker.com/test.xml:

Figure 3 Simplified sample restrictions applied by XmlSecureResolver

In short, it creates restrictions based on protocol, hostname, and a couple of different things (like an optional port, which is not applicable to all protocols). If we fetch our XML from http://attacker.com, we won’t be able to make a request to http://localhost because the host does not match.

The same goes for the protocol. If we fetch XML from the attacker’s HTTP server, we won’t be able to access local files with XXE, because neither the protocol (http:// versus file://) nor the host match as required.

To summarize, this XXE is useless so far. Even though we can technically trigger the XXE, it only allows us to reach our own server, which we can also achieve with the intended functionalities of our SharePoint sources (such as XmlDataSource). We need to figure out something else.

SPXmlDataSource and URL Parsing Issues

At this point, I was not able to abuse the HTTP-based sources. I tried to use SPXmlDataSource with the following request:

       /sites/mysite/test.xml

The idea is simple. We are a SharePoint user, and we can upload files to some sites. We upload our malicious XML to the http://sharepoint/sites/mysite/test.xml document and then we:
       • Create SPXmlDataSource
       • Set DataFile to /sites/mysite/test.xml.

SPXmlDataSource will successfully retrieve our XML. What about XmlSecureResolver? Unfortunately, such a path (without a protocol) will lead to a very restrictive policy, which does not allow us to leverage this XXE.

It made me wonder about the URL parsing. I knew that I could not abuse HTTP-based XmlDataSource and SoapDataSource. The code was written in C# and it was pretty straightforward to read – URL parsing looked good there. On the other hand, the URL parsing of SPXmlDataSource is performed by some unmanaged code, which cannot be easily decompiled and read.

I started thinking about a following potential exploitation scenario:
       • Delivering a “malformed” URL.
       • SPXmlDataSource somehow manages to handle this URL, and retrieves my uploaded XML successfully.
       • The URL gives me an unrestricted XmlSecureResolver policy and I’m able to fully exploit XXE.

This idea seemed good, and I decided to investigate the possibilities. First, we have to figure out when XmlSecureResolver gives us a nice policy, which allows us to:
       • Access a local file system (to read file contents).
       • Perform HTTP communication to any server (to exfiltrate data).

Let’s deliver the following URL to XmlSecureResolver:

       file://localhost/c$/whatever

Bingo! XmlSecureResolver creates a policy with no restrictions! It thinks that we are loading the XML from the local file system, which means that we probably already have full access, and we can do anything we want.

Such a URL is not something that we should be able to deliver to SPXmlDataSource or any other data source that we have available. None of them is based on the local file system, and even if they were, we are not able to upload files there.

Still, we don’t know how SPXmlDataSource is handling URLs. Maybe my dream attack scenario with a malformed URL is possible? Before even trying to reverse the appropriate function, I started playing around with this SharePoint data source, and surprisingly, I found a solution quickly:

       file://localhost\c$/sites/mysite/test.xml

Let’s see how SPXmlDataSource handles it (based on my observations):

Figure 4 SPXmlDataSource - handling of malformed URL

This is awesome. Such a URL allows us to retrieve the XML that we can freely upload to SharePoint. On the other hand, it gives us an unrestricted access policy in XmlSecureResolver! This URL parsing confusion between those two components gives us the possibility to fully exploit the XXE and perform a file read.

The entire attack scenario looks like this:

Figure 5 SharePoint XXE - entire exploitation scenario

Demo

Let’s have a look at the demo, to visualize things better. It presents the full exploitation process, together with the debugger attached. You can see that:
       • SPXmlDataSource fetches the malicious XML file, even though the URL is malformed.
       • XmlSecureResolver creates an unrestricted access policy.
       • XXE is exploited and we retrieve the win.ini file.
       • “DTD prohibited” exception is eventually thrown, but we were still able to abuse the OOB XXE.

The Patch

The patch from Microsoft implemented two main changes:
       • More URL parsing controls for SPXmlDataSource.
       • XmlTextReader object also prohibits DTD usage (previously, only XmlReaderSettings did that).

In general, I find .NET XXE-protection settings way trickier than the ones that you can define in various Java parsers. This is because you can apply them to objects of different types (here: XmlReaderSettings versus XmlTextReader). When XmlTextReader prohibits the DTD usage, parameter entities seem to never be resolved, even with the resolver specified (that’s how this patch works). On the other hand, when XmlReaderSettings prohibits DTDs, parameter entities are resolved when the XmlUrlResolver is used. You can easily get confused here.

Summary

A lot of us thought that XXE vulnerabilities were almost dead in .NET. Still, it seems that you may sometimes spot some tricky implementations and corner cases that may turn out to be vulnerable. A careful review of .NET XXE-related settings is not an easy task (they are tricky) but may eventually be worth a shot.

I hope you liked this writeup. I have a huge line of upcoming blog posts, but vulnerabilities are waiting for the patches (including one more SharePoint vulnerability). Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

Recently, the automotive VR team has undertaken an effort to reproduce the software extraction attack against one of the target devices used during the Automotive Pwn2Own 2024 held in Tokyo, Japan. The electromagnetic fault injection (EMFI) approach was chosen to attempt an attack against the existing readout protection mechanisms. This blog post details preparatory steps to speed up the attack, hopefully considerably.

Electromagnetic fault injection

In general, fault injection attacks against hardware attempt to produce some sort of gain for an attacker by injecting faults into a device under attack by manipulating clock pulses, supply voltages, temperature, electromagnetic fields around the device, and aiming short light pulses at certain locations on the device. Of these vectors, EMFI stands out as probably the only attack approach that requires close to no modifications of the device under attack, with all action being conducted at a quite short distance. The attack then proceeds by moving an EM probe above the device in very small increments and triggering an EM pulse. With any luck, this would disturb the normal operation of the device under attack in just the right way to cause the desired effect.

Practically speaking, some sort of an EM pulse tool is required to conduct the attack. In this case, the PicoEMP was chosen for that purpose, which has been mounted on a modified 3D printer carriage.

Figure 1 - The ChipSHOUTER-PicoEMP

However, the device in question (a GD32F407Z by GigaDevice) is physically rather large, with the package measuring 20mm by either side. Considering how long each individual attempt runs, the fact that the attempt needs to be retried multiple times to collect meaningful outcome statistics, and rather small increments used to move the probe, it would make sense to narrow down the search area as much as possible. Injecting EM faults into the epoxy encapsulation would not bring much of an effect.

Decapping

Unfortunately, the encapsulation is not transparent and does not allow for easy visual identification of the die in the package. This means that some way of getting the die out is required to measure it, or better yet, leave the die in the package so it will be possible to measure both the die dimensions and the position of the die within the package.

There are multiple approaches to decapsulation, or decapping for short:

·      Mechanical: sanding or milling the package, cracking the encapsulation when heated
·      Chemical: applying acid to dissolve encapsulation
·      Thermal: placing the package in a furnace to burn encapsulation away
·      Optical: using a laser to burn encapsulation away in a precise manner

Of these, many require specialized equipment (mill, laser, furnace, fume hood for nitric acid), are time-consuming (sanding), or do not preserve important information (cracking the package). The choice was thus limited to what was available: hot sulfuric acid.

DANGER: Hot sulfuric acid is extremely corrosive; avoid spilling and wear proper PPE at all times.

DANGER: Sulfuric acid vapors are extremely corrosive; avoid inhaling and work in a well-ventilated area (fume hood or outside).

NOTE: Study relevant safety information including but not limited to materials handling, spill containment, and clean-up procedures before working with any hazardous chemicals.

NOTE: This blog post was written purely for educational purposes; any attempts to replicate the work are at your own risk.

Decapping process

As my home lab is, sadly, not equipped with a fume hood, all work was conducted outside.

Figure 2 - Example of tools used

The following tools were used:

·      Sulfuric acid, 96%
·      A heat source in the form of a hot air station
·      A crocodile clip “helping hands”
·      A squirt bottle with acetone
·      A PE pipette
·      A waste container.

To begin, the device under attack is fixed in the clip, and a small drop of acid was applied with the pipette in the package center.

Figure 3 - Applying sulfuric acid

The device was then heated using the hot air station set to 200°C  and a moderate air flow of around 40%. The aim of this process is to slowly dissolve the packaging epoxy. The device was heated until some fuming was observed from the drop and stopped before any bubbling would occur. If the acid gets hot enough to produce bubbles, the material will form a hard carbonized “cake” which will be problematic to remove. Unfortunately, this has been a problem before.

After the acid visibly darkened, which should take around 1 minute +- 50%, the heating was stopped, and the device was allowed to cool down somewhat. Then, the acid was washed off with acetone into the waste container. The device then was dried off with hot air to remove moisture.

The process was then repeated multiple times, with each iteration removing a bit of the packaging material. This was captured in the following series of images (more steps were taken than is presented here):

Figure 4 - Time lapse of decapping process

A stack of dice slowly emerged from the package: the larger one is the microcontroller itself, and the smaller one is the serial Flash memory holding all the programmed code and data. Unfortunately, the current process does not preserve the bond wires, rendering the device inoperable. Its operation was not required in our case. This could possibly be mitigated by using a 98% acid and anhydrous acetone – something to attempt in the future.

Measurements

The end result of the decapping process is pictured below.

Figure 5 - End result of decapping

Using a graphics editor, it is possible to take measurements in pixels of the package, the die, and the die positioning. This came out to be the following:

·      Package size 1835x1835 pixels (measured) = 20x20 mm (known from the datasheet)
·      Pixels per mm: 91.75
·      Die size 366x366 pixels (measured) = 4x4mm (computed)
·      Die offset from bottom left: 745x745 pixels (measured) = 8.12x8.12mm (computed)

The obtained numbers are immediately useful to program the EM probe motion restricted to the die area only. To find out how much experiment time this could save, let’s compute the areas: 4x4 = 16 mm2 for the die itself, and 20x20 = 400 mm2 for the whole package. This is 25 times decrease in the area and thus the experiment time.

Another approach that could avoid the decapping process is moving the probe in a spiral fashion, starting from the package center and moving outwards. This is of course possible to implement. However, the challenge here is the possibility of the two dice getting packaged side-to-side instead of being stacked like in this example – this would severely decrease the gain from this approach. Given the decapping only takes no more than 1-2 hours including cleanup, this was deemed well worth the information gained – and the die pictures obtained.

Conclusion

I hope you enjoyed this brief demonstration. Again, please take caution when using sulfuric acid or any other corrosive agents. Please dispose of waste materials responsibly. The world of hardware hacking offers many opportunities for discovery. We’ll continue to post guides and methodologies in future posts. Until then, you can follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

Welcome to the second Tuesday of May. As expected, Adobe and Microsoft have released their standard bunch of security patches. Take a break from your regular activities and join us as we review the details of their latest advisories. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Apple Patches for May 2024

Apple kicked off the May release cycle with a group of updates for their macOS and iOS platforms. Most notable is a fix for CVE-2024-23296 for iOS 16.7.8 and iPadOS 16.7.8. This vulnerability is a memory corruption issue in RTKit that could allow attackers to bypass kernel memory protections. The initial patch was released back in March, but Apple noted additional fixes would be coming, and here they are. This bug is reported as being under active attack, so if you’re using a device with an affected OS, make sure you get the update.

Apple also patched the Safari bug demonstrated at Pwn2Own Vancouver by Master of Pwn Winner Manfred Paul.

Adobe Patches for May 2024

For May, Adobe released eight patches addressing 37 CVEs in Adobe Acrobat and Reader, Illustrator, Substance3D Painter, Adobe Aero, Substance3D Designer, Adobe Animate, FrameMaker, and Dreamweaver. Eight of these vulnerabilities were reported through the ZDI program. The update for Reader should be the priority. It includes multiple Critical-rated bugs that are often used by malware and ransomware gangs. While none of these bugs are under active attack, it is likely some will eventually be exploited. The patch for Illustrator also addresses a couple of Critical-rated bugs that could result in arbitrary code execution. The patch for Aero (an augmented reality authoring and publishing tool) fixes a single code execution bug. Unless I’m mistaken, this is the first Adobe patch for this product.

The fix for Adobe Animate fixes eight bugs, seven of which result in Critical-rated code execution. The patch for FrameMaker also fixes several code execution bugs. These are classic open-and-own bugs that require user interaction. That’s the same for the single bug fixed in Dreamweaver. The patch for Substance 3D Painter addresses four bugs, two of which are rated Critical, while the patch for Substance 3D Designer 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. Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for May 2024

This month, Microsoft released 59 CVEs in Windows and Windows Components; Office and Office Components; .NET Framework and Visual Studio; Microsoft Dynamics 365; Power BI; DHCP Server; Microsoft Edge (Chromium-based); and Windows Mobile Broadband. If you include the third-party CVEs being documented this month, the CVE count comes to 63. A total of two of these bugs came through the ZDI program. As with last month, none of the bugs disclosed at Pwn2Own Vancouver are fixed with this release. With Apple and VMware fixing the vulnerabilities reported during the event, Microsoft stands alone as the only vendor not to produce patches from the contest.

Of the new patches released today, only one is rated Critical, 57 are rated Important, and one is rated Moderate in severity. This release is roughly a third of the size of last month’s, so hopefully that’s a sign that a huge number of fixes in a single month isn’t going to be a regular occurrence.

Two of the CVEs released today are listed as under active attack, and one other is listed as publicly known at the time of the release. Microsoft doesn’t provide any indication of the volume of attacks, but the DWM Core bug appears to me to be more than a targeted attack. Let’s take a closer look at some of the more interesting updates for this month, starting with the DWM bug currently exploited in the wild:

-       CVE-2024-30051 – Windows DWM Core Library Elevation of Privilege Vulnerability
This bug allows attackers to escalate the SYSTEM on affected systems. These types of bugs are usually combined with a code execution bug to take over a target and are often used by ransomware. Microsoft credits four different groups for reporting the bug, which indicates the attacks are widespread. They also indicate the vulnerability is publicly known. Don’t wait to test and deploy this update as exploits are likely to increase now that a patch is available to reverse engineer.

-       CVE-2024-30043 – Microsoft SharePoint Server Information Disclosure Vulnerability
This vulnerability was reported to Microsoft by ZDI researcher Piotr Bazydło and represents an XML external entity injection (XXE) vulnerability in Microsoft SharePoint Server 2019. An authenticated attacker could use this bug to read local files with SharePoint Farm service account user privileges. They could also perform an HTTP-based server-side request forgery (SSRF), and – most importantly – perform NLTM relaying as the SharePoint Farm service account. Bugs like this show why info disclosure vulnerabilities shouldn’t be ignored or deprioritized.

-       CVE-2024-30033 – Windows Search Service Elevation of Privilege Vulnerability
This is another bug reported through the ZDI program and has a similar impact to the bug currently being exploited, although it manifests through a different mechanism. This is a link following bug in the Windows Search service. By creating a pseudo-symlink, an attacker could redirect a delete call to delete a different file or folder as SYSTEM. We discussed how this could be used to elevate privileges here. The delete happens when restarting the service. A low-privileged user can't restart the service directly. However, this could easily be combined with a bug that allows a low-privileged user to terminate any process by PID. After failure, the service will restart automatically, successfully triggering this vulnerability.

-       CVE-2024-30050 – Windows Mark of the Web Security Feature Bypass Vulnerability
We don’t normally detail Moderate-rated bugs, but this type of security feature bypass is quite in vogue with ransomware gangs right now. They zip their payload to bypass network and host-based defenses, they use a Mark of the Web (MotW) bypass to evade SmartScreen or Protected View in Microsoft Office. While we have no indication this bug is being actively used, we see the technique used often enough to call it out. Bugs like this one show why Moderate-rated bugs shouldn’t be ignored or deprioritized.

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

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

There’s just one Critical-rated bug this month, and it deals with a remote code execution (RCE) vulnerability in SharePoint server. An authenticated attacker could use this bug to execute arbitrary code in the context of the SharePoint Server. While permissions are needed for this to occur, any authorized user on the server has the needed level of permissions.

Looking at the other RCE bugs, we see a lot of vulnerabilities in rarely used protocols. The Windows Mobile Broadband driver and the Routing and Remote Access Service (RRAS) make up the bulk of this category. More notable are the two bugs in Hyper-V. One of these would allow an authenticated attacker to execute code on the host system. This would result in a guest-to-host escape, but Microsoft doesn’t indicate what level the code execution occurs on the host OS. After a couple of months with many SQL-related fixes, there’s just one this month. As with the previous bugs, you would need to connect to a malicious SQL server. The bug in Cryptographic Services requires a machine-in-the-middle (MITM) but could lead to a malicious certificate being imported onto the target system. The RCE bugs are rounded out with open-and-own style bugs in Excel and .NET and Visual Studio.

Moving on to the elevation of privilege (EoP) patches in this month’s release, almost all lead to SYSTEM-level code execution if an authenticated user runs specially crafted code. While there isn’t a lot else to say about these bugs, they are often used by attackers to take over a system when combined with a code execution bug – like the Excel bug mentioned above. They convince a user to open a specially crafted Excel document that executes the EoP and takes over the system. The lone exception to this is the bug in the Brokering File System component. The vulnerability allows attackers to gain the ability to authenticate against a remote host using the current user’s credentials. The attack could be launched from a low-privileged AppContainer, which would allow the attacker to execute code or access resources at a higher integrity level than that of the AppContainer execution environment.

We’ve already discussed the MotW security feature bypass (SFB), and the only other SFB vulnerability receiving a fix this month is the MSHTML engine. Just when you thought you were safe from Internet Explorer, the Trident engine rears its ugly head. This bug allows an unauthenticated attacker to get code execution if they can convince a user to open a malicious document. The code execution occurs in the context of the user, so this is another reminder not to log on with Admin privileges unless you absolutely need to.

There are only seven information disclosure bugs receiving fixes this month, and we’ve already covered the one in SharePoint. As usual, most of these vulnerabilities only result in info leaks consisting of unspecified memory contents. The bug in Power BI could result in the disclosing of “sensitive information,” but Microsoft doesn’t narrow down what type of “sensitive information” could be leaked. Similarly, the bug in Deployment Services could leak “file contents.” Microsoft provides no information on whether that’s any arbitrary file contents or only specific files, so your guess is as good as mine.

The May release includes four spoofing bugs. The first is a stored cross-site scripting (XSS) bug in Azure Migrate. There’s not a straightforward patch for this one. You need the latest Azure Migrate Agent and ConfigManager updates. More info on how to do that can be found here. There are two spoofing bugs in Dynamics 365, but they read more like XSS bugs. The final spoofing bug addressed this month is in the Bing search engine. An attacker could modify the content of the vulnerable link to redirect the victim to a malicious site.

There’s a single Tampering bug addressed in this release fixing a bug in Microsoft Intune Mobile Application Management. An attacker could gain sensitive information on a target device that has been rooted.

The final bugs for May are Denial-of-Service (DoS) vulnerabilities in ASP.NET, DHCP server, and Hyper-V. Unfortunately, Microsoft provides no additional information about these bugs and how they would manifest on affected systems.

There are no new advisories in this month’s release.

Looking Ahead

The next Patch Tuesday of 2024 will be on June 11, and I’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

In this guest blog from Pwn2Own winner Cody Gallagher, he details CVE-2024-21115 – an Out-of-Bounds (OOB) Write that occurs in Oracle VirtualBox that can be leveraged for privilege escalation. This bug was recently patched by Oracle in April. Cody has graciously provided this detailed write-up of the vulnerability and how he exploited it at the contest.

The core bug used for this escape is a relative bit clear on the heap from the VGA device. The bug is in function vgaR3DrawBlank, which is called from vgaR3UpdateDisplay. The bug can be triggered with a single core and 32MB of VRAM, and possibly less. All testing was done using the default graphics controller for Linux (VMSVGA). It should work on others as well.

As for the exploit, I could not get it to work with those constraints. For my exploit, I require at least 65 MB of VRAM but am using 128 MB to be safe. It requires 4 cores because of the race condition I use.

The Vulnerability

Inside the VGAState struct there is a bitmap used for tracking dirty pages in the vram buffer so that it knows whether it needs to redraw that part of the frame buffer.

This bitmap is large enough to hold the total number of pages even when using the max vram allowable by vbox, which is 256MB. However, inside vgaR3DrawBlank, when it attempts to clear the dirty page bits it incorrectly multiplies start_addr by 4 before doing so:

We can see here that if we are able to set start_addr to a value greater than 64MB, it will clear bits outside the bounds of the bitmap. Alternatively, even if start_addr is below 64MB, so that it starts clearing within the bitmap, the bit clear operation can continue past the bitmap's end.

Examining how start_addr is set, we can see that it allows any value up to vram_size:

Later in the code, vbe_start_addr is stored into start_addrand and vbe_line_offset is stored into line_offset. This happens when vgaR3UpdateBasicParams calls vgaR3GetOffsets. This update occurs whenever a new graphic or text is being drawn.

As long as our vram_size is greater than 64MB we will able to clear bits in heap memory following the bitmap.

The following are the values I set up to trigger the bug. All of these are settable via ioport communication.

These values are chosen to zero out a specific bit, but if the VBE_DISPI_INDEX_VIRT_WIDTH is increased it will most likely overwrite enough data to cause a segfault. For the exact ioport comms used, please reference the exploit code.

The Exploit

I explored several paths to find something we can zero out that would be usable to gain reliable code execution. I ended up looking at CritSect inside of VGAState. This critical section is used so that only 1 thread at a time can process in and out instructions for each device, as well as any loads or stores to the mmio region. There are several things we are concerned with in the critical section. The relevant structures are as follows:

When a thread locks the critical section, it adds 1 to cLockers, updates NativeThreadOwner to the current thread, and adds 1 to cNestings.

If a different thread then attempts to lock this same section it will see that cLockers is set and will attempt to wait its turn to lock. There is first an optimized wait, in which it will attempt to spin for some microseconds to see if it can quickly acquire the lock.

If that fails it will the block on the EventSem semaphore.

This hEvent value is just an int. Each time a critical section is created, a new hEvent value will be allocated in sequential fashion. When we look at the critical section of VGAState we can see the value of hEvent is 0x23.

The first 4 bytes are u32Magic, and the hEvent value can be seen at offset 0x18. With this information in hand, I realized that if we can find another critical section with an hEvent, we can modify the hEvent of VGState to match that of the other critical section. Then we can use that confusion to produce a race condition in any VGA ioport or mmio read/write. After looking around I found that VMMDev was using the hEvent value of 0x21.

After some testing, I found that the hEvent values are consistent between runs because they are assigned sequentially on startup. The critical sections for VMMDev and VGA are created directly after the processor-related critical sections. So long as the processor chipset doesn't change, these should remain constant.

I will note here that there are other critical sections that could potentially be used, but I chose to write my exploit using the VMMDev critical section.

First, we use our bit clearing bug to turn 0x23 into 0x21. Subsequently, whenever there are two threads, one holding the critical section for VMMDev and one holding the critical section for VGA, when either thread releases its critical section it can wake up a thread waiting for either device. Our plan is to use this race condition to wake a thread waiting for VGA prematurely, which is to say, while some other thread is still using VGA.

This is not good enough yet, though. Even if we hit the race, VirtualBox throws a SigTrap shortly thereafter. This is because when the racing thread locks the critical section, it changes NativeThreadOwner. When the first thread tries to unlock the critical section, the NativeThreadOwner does not match, causing the error.

Upon discovering this we also see that there is a way to completely turn off an individual critical section. There is a bit in fFlags called RTCRITSECT_FLAGS_NOP. If this bit is set then it will ignore all locking and unlocking operations for that particular critical section.

This poses a challenge for us, though. The only bug we have is a bit clear, so we have no way to set this flag. Instead, we must find a way to set the flag from our racing VGA thread before the first VGA thread exits and crashes the process.

When looking for a way to accomplish this, I found an ioport for writing data to vbe_regs in VGAState:

       uint16_t vbe_regs[VBE_DISPI_INDEX_NB];

This ioport allows us to specify vbe_index as an arbitrary short, and then it will write an arbitrary short to vbe_regs[vbe_index] in vbe_ioport_write_data. The write is protected by a bounds check on the index, but we can circumvent the check by using the race condition we manufactured.

To exploit, we start a VGA request on one thread (the “worker”) specifying a valid vbe_index, and a second VGA request on a second thread (the “racer”) specifying a bad vbe_index. Normally the racer request would need to wait for the worker to finish, but by racing two VMMDev requests (on two other threads) we can wake the racerVGA thread prematurely, modifying the vbe_index after the workerthread has finished validating it but before using it.

Note that, for this to succeed, the racer thread must be woken at a critical moment during execution of the worker. To make this race easier to win, we can take advantage of a memset in vbe_ioport_write_data where we control the length. For the worker request, we make this a large number so we have a longer window in which to win the race. In testing, I found we can easily get this to over 1 millisecond which is a massive amount of time during which we can win the race.

After winning the race, we can see the desired effect.

By means of the vgaR3DrawBlank bug we have changed hEvent from 0x23 to 0x21, and by means of the vbe_ioport_write race we have changed the fFlags member at offset 0x14 to 0xf, disabling the critical section. Now that the critical section is fully disabled, we can easily race VGA threads against each other. The next step is to find a read and a better write with our new and improved race condition.

Both the write and the read can be achieved by corrupting the same value. In VGAState there is a field of struct type VMSVGASTATE, and that struct contains a field named cScratchRegion.

cScratchRegion is used to track the size of the buffer au32ScratchRegion, which stores data during VMSVGA IO port communication. In functions vmsvgaIORead and vmsvgaIOWrite we can read and write this buffer based on the value of cScratchRegion.

Using the vbe_ioport_write race one more time, we can corrupt cScratchRegion. This gives us a fully controlled buffer overread and buffer overflow of a buffer within VGAState.

From here we need to find a way to get arbitrary execution. Conveniently, each device in VirtualBox has a PDMPCIDEV allocated directly after it in memory. Since it is part of the initial allocation for the device, we can be assured it will always be there.

At the beginning of the structure there is a pointer to the static string vga located in VBoxDD.dll. We can use our buffer overread to read this pointer and infer the base address of VBoxDD.dll. The structure also has a nested PDMPCIDEVINT structure, which contains several easily accessible function pointers:

The function pointers pfnConfigRead and pfnConfigWrite can be overwritten by our buffer overflow. Afterwards, we can trigger calls to these function pointers using PCI ioports.

To prepare for calling these function pointers, we first call pciIOPortAddressWrite to set uConfigRegto to specify the PCI device we want to read from or write to. In our case, that value can be found in the uDevFn value at the beginning of the PDMPCIDEV struct.

After we set uConfigReg, we can then call pciIOPortDataWrite, which will call pci_data_write. This function will call our function pointer with some controlled arguments.

When the function pointer is called, arg1 ends up being the value of pDevInsR3 which is fully user-controlled by means of our buffer overflow. arg2 points to the PDMPCIDEV struct after our VGAState, which means we can control data at that location. With a fully controlled arg1 and arg2, we can start to write our final execution chain.

These libraries use Windows Control Flow Guard so we are not able to make indirect calls to arbitrary code. Fortunately for us, CFG allows calls to arbitrary functions in other libraries, so it doesn’t prevent us from calling WinExec("calc").

First, we need to use our buffer read/write primitives to construct an arbitrary read so we can get the address of kernel32.dll. We currently have the base address for VBoxDD.dll only, so we will have to find something to use in that library. When looking through functions in VBoxDD.dll I found one that will work perfectly for what we want to do.

Our arg1 is fully controlled, so this read routine will allow us to take memory from arg1+0x2d8 and store it into the memory pointed to by arg2. arg2 points directly after VGAState in memory, so we can read it afterwards with our buffer overread. This effectively gives us an arbitrary read primitive. With this, we can leak pointers to functions in other libraries through VBoxDD.dlls IAT.

VBoxDD.dll imports several functions from kernel32.dll, so we can read any one of those import table entries to get a pointer into kernel32.dll. From there we can scan backward using our read until we encounter the PE magic at the beginning of kernel32.dll, which gives us the base.

Next, we scan for the export table of kernel32.dll. We start by reading out all the table addresses.

We then scan through the names table until we find the name WinExec. Having obtained the index, we can use the ordinal and address tables to get the function address. Finally we write calc into heap memory we control and call WinExec("calc").

Impact

This bug can be triggered on a large percentage of virtual machines because it is an easily accessible path in VGA. I believe this can probably be turned into at least a DOS on any VM with at least 32MB of VRAM.

The way I exploited it has significantly more constraints, which restricts the number of machines affected by the full escape. It still may be possible to turn this bug into a full escape under a wider range of conditions, but that was not part of my research.

Thanks again to Cody for providing this thorough write-up. This was his first Pwn2Own event, and we certainly hope to see more submissions from him in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

In this guest blog from Master of Pwn winner Manfred Paul, he details CVE-2024-2887 – a type confusion bug that occurs in both Google Chrome and Microsoft Edge (Chromium). He used this bug as a part of his winning exploit that led to code execution in the renderer of both browsers. This bug was quickly patched by both Google and Microsoft. Manfred has graciously provided this detailed write-up of the vulnerability and how he exploited it at the contest.

In this blog, I describe a means of exploiting the V8 JavaScript and WebAssembly engine to gain execution of arbitrary shellcode inside the renderer process. This includes a bypass of the V8 memory sandbox (Ubercage), though code execution is still constrained by the process isolation-based browser sandbox. For demonstration purposes, this limitation can be removed by running the browser with the --no- sandbox flag.

Root Cause of the WebAssembly Universal Type Confusion

A WebAssembly module may contain a type section that defines a list of custom “heap types”. In the base specification, this is used only to declare function types, but with the adoption of the garbage collection (GC) proposal [PDF], this section can additionally define struct types, allowing for the use of composite, heap-allocated types in WebAssembly.

Normally, a struct declared in this section may only reference structs that precede it (structs with a lower type index). To support mutually recursive data structures, a feature called recursive type groups is available. Instead of declaring the (potentially) mutually recursive types as individual entries in the type section, a recursive group is declared as a single type section entry. Within this group, individual types are declared, which are thereby allowed to reference each other.

With this in mind, consider the function responsible for parsing the type section from the binary WebAssembly format in v8/src/wasm/module-decoder-impl.h:

At (1), the limit kV8MaxWasmTypes (currently equal to 1,000,000) is passed as a maximum to consume_count(), ensuring that at most this many entries are read from the type section. When recursive type groups were added, this check became insufficient. While this code will permit only kV8MaxWasmTypes entries of the type section to be read, each of those can potentially be a recursive type group containing more than one individual type definition.

This insufficiency was clearly noticed at the time of this change, as together with recursive type groups a second check was added at (2). Here, for each recursive type group, it is checked that the addition of the constituent types would not exceed the kV8MaxWasmTypes limit.

However, this second check is still not enough. While it protects the indices of each type allocated inside a recursive group, the presence of those groups also has implications for types declared outside this group, as each recursive group adds to the total count of declared types.

To make this clearer, imagine a type section consisting of two entries: one recursive group containingkV8MaxWasmTypes entries, and following that group, one non-recursive type. The check at (1) is passed, as the section only has two entries. While processing the recursive group, the check at (2) is also passed, as the section has exactly kV8MaxWasmTypes entries. For the following single type, there is no further check: at (3) the type is simply allocated at the next free index. In this case, the index will be kV8MaxWasmTypes, exceeding the usual maximum of kV8MaxWasmTypes-1. If there were more than one non-recursive type at the end of the type section, they would similarly get assigned kV8MaxWasmTypes+1, kV8MaxWasmTypes+2, and so forth, as type indices.

Impact of the Root Cause

Exceeding the maximal number of declared heap types might seem like a very harmless resource exhaustion bug at first. However, due to some internal details of how V8 handles WebAssembly heap types, it directly allows constructing some very powerful exploit primitives.

In v8/src/wasm/value-type.h, the encoding of heap types is defined:

Here, V8 assumes that all user-defined heap types will be assigned indices smaller than kV8MaxWasmTypes. Larger indices are reserved for fixed, internal heap types (beginning with kFunc). This results in our own type declarations aliasing one of these internal types, leading to many opportunities for type confusion.

Universal WebAssembly Type Confusion

To leverage this encoding ambiguity into a full type confusion, let’s first consider the struct.new opcode, which produces a reference to a new struct created from fields given on the stack. The caller specifies the desired struct type by passing its type index. The relevant check on the type index can be found in v8/src/wasm/function-body-decoder-impl.h:

Following the validation logic into the has_struct() method from v8/src/wasm/wasm-module.h:

Since we can make types.size() exceed the usual limit of kV8MaxWasmTypes, we can make the check pass even if when passing an index larger than this value. This allows us to create a reference of an arbitrary internal type that points to the struct we can freely define.

On the other hand, consider now the handling of the ref.cast instruction:

Here, a type check elimination is performed. If TypeCheckAlwaysSucceeds returns true, then no actual type check is emitted and the value is simply reinterpreted as the target type.

The function TypeCheckAlwaysSucceeds ultimately calls IsHeapSubtypeOfImpl defined in v8/src/wasm/wasm-subtyping.cc:

This means that if our declared type index aliases the constant HeapType::kNone, the type check will always be elided if we cast to any non-function, non-external reference. In combination, we can use this to turn any reference type into any other by the following steps:

1. In the type section, define a structure type with a single field of type anyref, and make this struct have a type index equal to HeapType::kNone using the bug described above.

2. Place a non-null reference value of any type on the top of the stack and call struct.new with the type index set to HeapType::kNone. This will succeed, as has_struct() validates the index against the index established via the previous step.

3. Also, declare a struct with a normal type index lower than kV8MaxWasmTypes with a single field of the target reference type. Call ref.cast with this this struct’s type index. The engine will not perform any type check, as the input value is at this point understood to be reference type HeapType::kNone.

4. Finally, read back the reference stored in the struct by executing struct.get.

This arbitrary casting of reference types allows transmuting any value type into any other by referencing it, changing the reference type, and then dereferencing it – a universal type confusion.

In particular, this directly contains nearly all usual JavaScript engine exploitation primitives as special cases:

• Transmuting int to int* and then dereferencing results in an arbitrary read.

• Transmuting int to int* and then writing to that reference results in an arbitrary write.

• Transmuting externrefto int is the addrOf() primitive, obtaining the address of a JavaScript object.

• Transmuting int to externref is the fakeObj() primitive, forcing the engine to treat an arbitrary value as a pointer to a JavaScript object.

While casting from HeapType::kNone to an externref is not allowed, remember that we are actually operating on one more level of indirection - transmuting to externref involves casting to a reference to a struct containing one externref member.

Note however that these “arbitrary” reads and writes are still contained in the V8 memory sandbox, as all involved pointers to heap-allocated structures are tagged, compressed pointers inside the heap cage, not full 64-bit raw pointers.

Integer Underflow Leading to V8 Sandbox Escape

The primitives described above allow for freely manipulating and faking most JavaScript objects. However, all of this happens inside the limited memory space of the V8 sandbox. “Trusted” objects such as WebAssembly instance data cannot yet be manipulated. We will now turn our attention to a bug that can be used to escape the memory sandbox.

An often-used object for JavaScript engine exploits is ArrayBuffer and its corresponding views, (i.e. typed arrays), as it allows for direct, untagged access to some region of memory.

To prevent access to pointers outside the V8 sandbox, sandboxed pointers are used to designate a typed array’s corresponding backing store. Similarly, an ArrayBuffer’s length field is always loaded as a “bounded size access”, inherently limiting its value to a maximum of 235 − 1.

However, in modern JavaScript, the handling of typed arrays has become quite complex due to the introduction of resizable ArrayBuffers (RABs) and their sharable variant, growable SharedArrayBuffers (GSABs). Both variants feature the ability to change their length after the object has been created with the shared variant being restricted to never shrink. In particular, for typed arrays with these kinds of buffers, the array length can never be cached and must be recomputed on each access.

Additionally, ArrayBuffers also feature an offset field, describing the start of the data in the actual underlying backing store. This offset must be taken into account when computing the length.

Let’s now look at the code responsible for building a TypedArray’s length access in the optimizing Turbofan compiler. It can be found in v8/src/compiler/graph-assembler.cc. Note that most non-RAB/GSAB cases and the code responsible for dispatching are omitted for simplicity:

For arrays backed by a resizable ArrayBuffer, we can see at (1) that the length is computed as floor((byte_length - byte_offset) / element_size). Crucially, there is an underflow check. If byte_offset exceeds byte_length, then 0 is returned instead.

Curiously though, in the case of a GSAB-backed array, the corresponding underflow check is missing. Thus, if byte_offset is larger than byte_length, an underflow occurs and the subtraction wraps around to something close to the maximum unsigned 64-bit integer 264. As both of these fields are found in the (by now) attacker-controlled array object, we can easily trigger this using the sandboxed arbitrary read/write primitives discussed previously. This results in access to the whole 64-bit address space, as the length computed by this function is used to bound any typed array accesses (in JIT-compiled code).

Exploitation for Arbitrary Shellcode Execution

Using the two bugs described above, exploitation becomes fairly straightforward. The primitives described in the Universal WebAssembly Type Confusion section directly give arbitrary reads and writes within the V8 memory sandbox. This can then be used to manipulate a growable SharedArrayBuffer to have an offset greater than its length. A previously JIT-compiled read/write function can then be used to access and overwrite data anywhere in the process’s address space. An appropriate target for overwrite is the compiled code of a WebAssembly module, since that resides in an RWX (read-write-execute) page and can be overwritten with shellcode.

Thanks again to Manfred for providing this thorough write-up. He has contributed multiple bugs to the ZDI program over the last few years, and we certainly hope to see more submissions from him in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

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 remote code execution vulnerability in Microsoft Windows. This bug was originally discovered by the Microsoft Offensive Research & Security Engineering team. Successful exploitation could result in arbitrary code execution in the context of the application using the vulnerable library. The following is a portion of their write-up covering CVE-2024-20697, with a few minimal modifications.

An integer overflow vulnerability exists in the Libarchive library included in Microsoft Windows. The vulnerability is due to insufficient bounds checks on the block length of a RARVM filter used for Intel E8 preprocessing, included in the compressed data of a RAR archive.

A remote attacker could exploit this vulnerability by enticing a target user into extracting a crafted RAR archive. Successful exploitation could result in arbitrary code execution in the context of the application using the vulnerable library.

The Vulnerability

The RAR file format supports data compression, error recovery, and multiple volume spanning. Several versions of the RAR format exist: RAR1.3, RAR1.5, RAR2, RAR3, and the most recent version, RAR5. Different compression and decompression algorithms are used for different versions of RAR.

The following describes the RAR format used by versions 1.5, 2.x, and 3.x. A RAR archive consists of a series of variable-length blocks.

Each block begins with a header. The following table is the common structure of a RAR block header:

The RarBlock Marker is the first block of a RAR archive and serves as the signature of a RAR formatted file:

This block always contains the following byte sequence at the beginning of every RAR file:

           0x52 0x61 0x72 0x21 0x1A 0x07 0x00 (ASCII: "Rar!\x1A\x07\x00")

The ArcHeader is the second block in a RAR file and has the following structure:

The ArcHeader block is followed by one or more FileHeader blocks. These blocks have the following structure:

Note that the above offsets are relative to the existence of the optional fields.

The EndBlock block will signify the end of the RAR archive. This block has the following structure:

For each FileHeader block in the RAR archive, if the Method field is not set to "Store" (0x30), then the Data field will contain the compressed file data. The method of decompression depends on the RAR version used to compress the data. The RAR version needed to extract the compressed data is recorded in the UnpVer field of the FileHeader block.

Of relevance to this report is the RAR extraction method used by RAR format version 2.9 (a.k.a. RAR4), which is used when the UnpVer field is set to 29. The compressed data may be compressed either using the Lempel-Ziv (LZ) algorithm or using Prediction by Partial Matching (PPM) compression. This report will not describe in full detail the extraction algorithm, but only summarize the relevant parts for understanding the vulnerability. For a reference implementation of the extraction algorithm, see the Unpack::Unpack29() function in the UnRAR source code.

When the libarchive library attempts to extract the contents of a file from a RAR archive, if the file data is compressed (i.e. the Method field is not set to "Store"), the function read_data_compressed() will be called to extract the compressed data. The compressed data is composed of multiple blocks, each of which can be compressed using the LZ algorithm (denoted by the first bit of the block set to 0) or using PPM compression (denoted by the first bit of the block set to 1). Initially, the function parse_codes() will be called to decode the tables necessary to extract the file data. If a block of data compressed using the LZ algorithm is encountered, the expand() function will be called to decompress the data. In the expand() function, symbols are read from the compressed data by calling read_next_symbol() in a loop. In the function read_next_symbol(), the symbol will be decoded according to the Huffman table decoded in function parse_codes().

If the decoded symbol is 257, the function read_filter() will be called to read a RARVM filter, which has the following structure:

Note that the above offsets are relative to the existence of the optional fields.

The calculation of the size of the Code field is as follows: If the lowest 3 bits of the Flags field (will be referred to as LENGTH) are less than 6, the code size is (LENGTH + 1). If LENGTH is set to 6, the code size is (LengthExt1 + 7). If LENGTH is set to 7, the code size is (LengthExt1 << 8) | LengthExt2. After the code length is calculated and the code itself is copied into a buffer, the code, its length, and the filter flags are sent to the parse_filter() function to parse the code section.

Within the code section, numbers are parsed by calling the function membr_next_rarvm_number(). This function reads 2 bits, and according to their value, determines how many bits to read to parse the value. If the first 2 bits are 0, 4 value bits will be read; if they are 1, 8 value bits will be read; if they are 2, 16 value bits will be read; and if they are 3, 32 value bits will be read.

Function parse_filter() will parse the code section, which has the following structure:

Note that if the READ_REGISTERS flag is not set, the registers will be initialized, such that the 5th register is set to the block length, which is either read from the code section (if the READ_BLOCK_LENGTH flag is set), or carried over from the block length of the previous filter.

After these fields are parsed in parse_filter(), the ByteCode field and its length are sent to the function compile_program(). In this function, the first byte of the bytecode is verified to be equal to the XOR of all other bytes in the bytecode. If true, it will set the fingerprint field of the rar_program_code struct to the value of the CRC-32 algorithm run on the full bytecode, combined with the bytecode length shifted left 32 bits.

Back in the function parse_filter(), after all fields are calculated for the filter, therar_filter struct will be initialized by calling create_filter() with the rar_program_code struct containing the fingerprint field and the register values calculated. These values will be set to the prog field and the initialregisters fields of the rar_filter struct, respectively.

Once processing of the filter is done, function run_filters() is called to run the parsed filter. This function initializes the vm field of the rar_filters struct with a structure of type rar_virtual_machine. This structure contains a registers field, which is an array of 8 integers, and a memory field of size 0x40004. Then, each filter is executed by calling execute_filter(). If the fingerprint field of the rar_program_code struct associated with the executed filter is equal to either 0x35AD576887 or 0x393CD7E57E, the execute_filter_e8() function is called. This function reads the block length from the 5th field of the initialregisters array. Then, a loop is run for replacing instances of 0xE8 and/or 0xE9 within the VM memory, with the block length used as the loop exit condition.

An integer overflow vulnerability exists in the Libarchive library included in Microsoft Windows. The vulnerability is due to insufficient bounds checks on the block length of a RARVM filter used for Intel E8 preprocessing, included in the compressed data of a RAR archive. Specifically, if the archive contains a RARVM filter whose fingerprint field is calculated as either 0x35AD576887 or 0x393CD7E57E, it will be executed by calling execute_filter_e8(). If the 5th register of the filter is set to a block length of 4, the loop condition in this function, which is set to the block length minus 5, will overflow to 0xFFFFFFFF. Since the VM memory has a size of 0x40004, this will result in memory accesses that are out of the bounds of the heap-based buffer representing the VM memory.

A remote attacker could exploit this vulnerability by enticing a target user into extracting a crafted RAR archive, containing a RARVM filter that has its 5th register set to 4. Successful exploitation could result in arbitrary code execution in the context of the application using the vulnerable library.

Notes:

• All multi-byte integers are in little-endian byte order.
• All offsets and sizes are in bytes unless otherwise specified.
• Since there is no official documentation of the RAR4 format, the description is based on the UnRAR and libarchive source code. Field names are either copied from source code or given based on functionality.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the common ports where a RAR archive might be sent, such as FTP, HTTP, SMTP, IMAP, SMB, and POP3.

The detection device must look for the transfer of RAR files and be able to parse the RAR file format. Currently, there is no official documentation of the RAR file format. This detection guidance is based on the source code for extracting RAR archives provided by the UnRAR program and the libarchive library.

The common structure of a RAR block header is detailed above. The detection device must first look for a RarBlock Marker, which is the first block of a RAR archive and serves as the signature of a RAR formatted file:

The detection device can identify this block by looking for the following byte sequence:

          0x52 0x61 0x72 0x21 0x1A 0x07 0x00 ("Rar!\x1A\x07\x00")

If found, the device must then identify the ArcHeader, which is the second block in a RAR file and is detailed above. The ArcHeader block is followed by one or more FileHeader blocks, whose structure is also detailed above. Note that the above offsets are relative to the existence of the optional fields.

The detection device must parse each FileHeader block and inspect its Method field. If the value of the Method field is greater than 0x30, the detection device must inspect the Data field of the FileHeader block, containing the compressed file data. The compressed data may be compressed either using the Lempel-Ziv (LZ) algorithm or using Prediction by Partial Matching (PPM) compression. This detection guidance will not describe in full detail the extraction algorithm. For a reference implementation of the extraction algorithm, see the Unpack::Unpack29() function in the UnRAR source code.

The compressed data is composed of multiple blocks, each of which can be compressed using the LZ algorithm (denoted by the first bit of the block set to 0) or using PPM compression (denoted by the first bit of the block set to 1). The detection device must extract each block according to the algorithm used to compress it. If a block compressed using the LZ algorithm is encountered, the detection device must decode the Huffman tables from the beginning of the compressed data. The detection device must then iterate over the remaining compressed data and decode each symbol based on the generated Huffman tables. If the symbol 257 is encountered, the following data must be parsed as a RARVM filter, which has the following structure:

Note that the above offsets are relative to the existence of the optional fields.

The detection device must then calculate the size of the Code field. The calculation of the size of the Code field is as follows: If the lowest 3 bits of the Flags field (will be referred to as LENGTH) are less than 6, the code size is (LENGTH + 1). If LENGTH is set to 6, the code size is (LengthExt1 + 7). If LENGTH is set to 7, the code size is (LengthExt1 << 8) | LengthExt2. After the size of the Code field is calculated, the Code field must be parsed according to the following structure:

All numerical fields within this structure (FilterNum, BlockStart, BlockLength, register values, and ByteCodeLen) must be read according to the algorithm implemented in the RarVM::ReadData() function of the UnRAR source code. The algorithm reads 2 bits of data, signifying the number of bits of data containing the numerical value. Note that some of the fields in this structure are optional and depend on flags set in the Flags field of the RARVM filter structure.

After extracting all necessary fields, the detection device must check for the following conditions:

• The CRC-32 checksum of the ByteCode field is 0xAD576887 and the ByteCodeLen field is 0x35 OR the CRC-32 checksum of the ByteCode field is 0x3CD7E57E and the ByteCodeLen field is 0x39.
• The READ_REGISTERS flag is set and the value of the 5th register of the Registers field is set to 4 OR the READ_BLOCK_LENGTH flag is set and the value of the BlockLength field is set to 4. If both these conditions are met, the traffic should be considered suspicious. An attack exploiting this vulnerability is likely underway.

Notes:

• All multi-byte integers are in little-endian byte order.
• All offsets and sizes are in bytes unless otherwise specified.

Conclusion

Microsoft patched this vulnerability in January 2024 and assigned it CVE-2024-20697. While they did not recommend any mitigating factors, there are some additional measures you can take to help protect from this bug being exploited. This includes not extracting RAR archive files from untrusted sources and filtering traffic using the guidance provided in the section “Detection Guidance” section of this blog. Still, it is recommended to apply the vendor patch to completely address this issue.

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 team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

It’s the second Tuesday of the month, and Adobe and Microsoft have released a fresh crop of security updates. Take a break from your other activities and join us as we review the details of their latest advisories. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for April 2024

For April, Adobe released nine patches addressing 24 CVEs in Adobe After Effects, Photoshop, Commerce, InDesign, Experience Manager, Media Encoder, Bridge, Illustrator, and Adobe Animate. The largest of these updates is for Experience Manager, however, all of the bugs being patched are simple Cross-site Scripting (XSS) bugs. Still, if exploited, these Important-severity bugs could lead to code execution if exploited. The only other patches that address multiple CVEs are the fixes for Animate and Commerce. The patch for Animate addresses four bugs. Two of these are rated Critical and could lead to arbitrary code execution. The patch for Commerce also fixes two Critical-rated bugs, one XSS and one improper input validation bug. Both could lead to code execution.

Then we have several patches that are all info leaks due to an Out-Of-Bounds (OOB) read. These were all reported by the same person, and it makes me wonder if there is shared code between these products that makes them all vulnerable. In any case, After Effects, Photoshop, InDesign, Bridge, and Illustrator all fall into this category. That just leaves the update for Media Encoder. This patch fixes a single buffer overflow that could lead to code execution.

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 a deployment priority rating of 3.

Microsoft Patches for April 2024

This month, Microsoft released a whopping 147 new CVEs in Microsoft Windows and Windows Components; Office and Office Components; Azure; .NET Framework and Visual Studio; SQL Server; DNS Server; Windows Defender; Bitlocker; and Windows Secure Boot. If you include the third-party CVEs being documented this month, the CVE count comes to 155. A total of three of these bugs came through the ZDI program. None of the bugs disclosed at Pwn2Own Vancouver are fixed with this release.

Of the new patches released today, only three are rated Critical, 142 are rated Important, and two are rated Moderate in severity. This is the largest release from Microsoft this year and the largest since at least 2017. As far as I can tell, it’s the largest Patch Tuesday release from Microsoft of all time. It’s not clear if this is due to a backlog from the slower months or a surge in vulnerability reporting. It will be interesting to see which trend continues.

None of the CVEs released today are listed as currently under active attack and none are listed as publicly known at the time of release. However, the bug reported by ZDI threat hunter Peter Girnus was found in the wild. We have evidence this is being exploited in the wild, and I’m listing it as such.

Let’s take a closer look at some of the more interesting updates for this month, starting with a bug we consider to be currently exploited in the wild:

-       CVE-2024-29988 – SmartScreen Prompt Security Feature Bypass Vulnerability
This is an odd one, as a ZDI threat researcher found this vulnerability being in the wild, although Microsoft currently doesn’t list this as exploited. I would treat this as in the wild until Microsoft clarifies. The bug itself acts much like CVE-2024-21412 – it bypasses the Mark of the Web (MotW) feature and allows malware to execute on a target system. Threat actors are sending exploits in a zipped file to evade EDR/NDR detection and then using this bug (and others) to bypass MotW.

-       CVE-2024-20678 – Remote Procedure Call Runtime Remote Code Execution Vulnerability
There is a long history of RPC exploits being seen in the wild, so any RPC bug that could lead to code execution turns heads. This bug does require authentication, but it doesn’t require any elevated permission. Any authenticated user could hit it. It’s not clear if you could hit this if you authenticated as Guest or an anonymous user. A quick search shows about 1.3 million systems with TCP port 135 exposed to the internet. I expect a lot of people will be looking to exploit this in short order.

-       CVE-2024-20670 – Outlook for Windows Spoofing Vulnerability
This bug is listed as a spoofing bug, but based on the end result of exploitation, I would consider this information disclosure. In this case, the information disclosed would be NTLM hashes, which could then be used for Spoofing targeted users. Either way, a user would need to click something in an email to trigger this vulnerability. The Preview Pane is NOT an attack vector. However, we have seen a rash of NTLM relaying bugs over the last few months. With the wide user base of Outlook, this will likely be targeted by threat actors in the coming months.

-       CVE-2024-26221 – Windows DNS Server Remote Code Execution Vulnerability
This is one of seven DNS RCE bugs being patched this month and all are documented identically. These bugs allow RCE on an affected DNS server if the attacker has the privileges to query the DNS server. There is a timing factor here as well, but if the DNS queries are timed correctly, the attacker can execute arbitrary code on the target server. Although not specifically stated, it seems logical that the code execution would occur at the level of the DNS service, which is elevated. I really don’t need to tell you that your DNS servers are critical targets, so please take these bugs seriously and test and deploy the patches quickly.

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

*Note that post-release, Microsoft confirmed CVE-2024-26234 is also under active attack. The table has been updated to reflect this new information

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Moving on to the Critical-rated bugs, all impact Microsoft Defender for IoT. An authenticated attacker with file upload privileges could get arbitrary code execution through a path traversal vulnerability. They would need to upload specially crafted files to sensitive locations on the target. It’s not clear how likely this would be, but anything that targets your defensive tools should be taken seriously.

All told, there are almost 70 fixes for bugs that could lead to code execution in this release. The (somewhat) good news is that nearly half of these impact SQL server components. In these cases, an attacker would need to have an affected system connect to a specially crafted SQL database and perform a query. If you can socially engineer that, then you will get code execution. However, that does seem unlikely. More practically, I would concern myself with the DNS and DHCP code execution bugs in this release. I’ve already mentioned the DNS bugs. For the DHCP bugs, the attacker would need elevated privileges. This would be a good time to audit your DHCP server to see who has privileges and who should be removed. The fix for Azure Migrate is only network adjacent, but you’ll need to take extra steps to be fully protected. You need to the latest Azure Migrate Appliance's AutoUpdater, which ensures MSI installers downloaded from the Download Center have been authentically signed by Microsoft prior to installation. Check here for more details. There is an update for Excel to address an open-an-own bug, but you’re out of luck if you’re on macOS. Updates for Apple users are not available yet.

There’s a mountain of elevation of privilege (EoP) patches in this month’s release, and in most cases, exploitation requires an attacker to log on the an affected system then run their code. Again, this usually results in getting code to elevate to SYSTEM. The Azure EoPs are a little bit different and require some extra steps. The bug in Azure Arc-enabled Kubernetes could allow an attacker to gain access to sensitive information, such as Azure IoT Operations secrets and potentially other credentials or access tokens stored within the Kubernetes cluster. You’ll also need to update any affected Extensions that are used in your environment and ensure you update your Azure Arc Agent. The bug in Azure Content Gallery also needs extra actions to be protected. This bug has been mitigated by the latest change to the Azure Compute Gallery (ACG) image creation permission requirements, which means you’ll need to check the permissions and possibly update them. For information on how to update permissions, see here for details. For the Azure Monitor Agent EoP, you need to make sure you have Automatic Extension Upgrades enabled. If you don’t you can manually get the updates following these instructions. Finally, the bug in the Azure Kubernetes Service also needs some extra work. To be fully protected, you need to ensure you are running the latest version of “az confcom” and Kata Image. If you don’t have “az conform” installed, you can get the latest version by running the command “az extension add -n conform”. See the bulletin for full details.

Moving on to the security feature bypass (SFB) bugs, how in the world are there 23 different SFB patches for Secure Boot? As if that isn’t enough, you’ll need to take additional steps to be protected. The patch fixes the bugs, but the protections aren’t enabled by default. You’ll need to check out this KB article and follow the instructions listed there. With 23 bugs and manual actions needed to address them, I don’t think we should call it “secure” boot anymore. Other SFB bugs include one that could bypass RSA signature verification and a bug in BitLocker that could also bypass secure boot. At least that one just requires a patch and no extra steps.

There are more than a dozen information disclosure bugs. Fortunately, most only result in info leaks consisting of unspecified memory contents. The bug in Azure AI Search could allow an attacker to obtain sensitive API Keys. While this bug has been mitigated by a recent update to Azure AI Search's backend infrastructure, you’ll need to manually rotate specific credentials that have been notified through Azure Service Health alerts. The bug in Azure Identity Library for .NET could divulge data inside the targeted website like IDs, tokens, nonces, and other sensitive information. At least there are no additional steps beyond the patch for this one. Finally, the bug in Windows DFS could disclose the ever-descriptive “sensitive information”.

The April release is rounded out by a handful of spoofing and denial-of-service (DoS) bugs. Microsoft doesn’t provide a lot of useful information here, but if you need to focus on something, the DoS bugs in the DHCP service are where I’d start. Shutting down DHCP for any time in an enterprise will likely lead to a “no fun at all” day.

Finally, Microsoft has updated ADV99001 with the latest servicing stack updates. Be sure to check them out.

Looking Ahead

The next Patch Tuesday of 2024 will be on May 14, and I’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Welcome to the second and final day of Pwn2Own Vancouver 2024! We saw some amazing research yesterday, including a Tesla exploit and a single exploit hitting both Chrome and Edge. So far, we have paid out $723,500 for the event, and we’re poised to hit $1,000,000 again. Today looks to be just as exciting with more attempts in virtualization, browser sandbox escapes, and the Pwn2Own’s first ever Docker escape, so stay tuned for all of the results!

And that’s a wrap! Pwn2Own Vancouver 2024 has come to a close. In total, we awarded $1,132,500 for 29 unique 0-days. We’re also happy to award Manfred Paul with the title of Master of Pwn. He won $202,500 and 25 points total. Combining the last three events (Toronto, Automotive, and Vancouver), we’ve awarded $3,494,750 for this year’s Pwn2Own events. Here’s how the Top 10 of this event added up:

Congratulations to all the winners. We couldn’t hold this event without the hard work of the contestants. And thanks to the vendors as well. They now have 90 days to fix these vulnerabilities. Special thanks to Tesla for their sponsorship and support. For details of each of today’s exploits, see the entries below.

SUCCESS - Marcin Wiązowski used an improper input validation bug to escalate privileges on Windows 11. He earns $15,000 and 3 Master of Pwn points.

SUCCESS - STAR Labs SG's exploit of VMware Workstation used two bugs. One is an uninitialized variable, but the other was previously known. They still win $30,000 and 6 Master of Pwn points.

SUCCESS - ColdEye used two bugs, including a UAF, to exploit Oracle VirtualBox. He even managed to leave the guest OS intact. His guest-to-host escape earns him $20,000 and 4 Master of Pwn points.

SUCCESS - Manfred Paul (@_manfp) used an OOB Write for the RCE and an exposed dangerous function bug to achieve his sandbox escape of Mozilla Firefox. He earns another $100,000 and 10 Master of Pwn points, which puts him in the lead with 25.

SUCCESS - First time Pwn2Own contestant Gabriel Kirkpatrick (gabe_k of exploits.forsale) used an always tricky race condition to escalate privileges on #Windows 11. He earns $15,000 and 3 Master of Pwn points.

SUCCESS - Edouard Bochin (@le_douds) and Tao Yan (@Ga1ois) from Palo Alto Networks used an OOB Read plus a novel technique for defeating V8 hardening to get arbitrary code execution in the renderer. They were able to exploit Chrome and Edge with the same bugs, earning $42,500 and 9 Master of Pwn points.

BUG COLLISION - STAR Labs SG successfully demonstrated their privilege escalation on Ubuntu desktop. However, they used a bug that was previously reported. They still earn $5,000 and 1 Master of Pwn point.

BUG COLLISION - Although the Hackinside Team was able to escalate privileges on Windows 11 through an integer underflow, the bug was known by the vendor. They still earn $7,500 and 1.5 Master of Pwn points.

SUCCESS -Seunghyun Lee (@0x10n) of KAIST Hacking Lab used a UAF to RCE in the renderer on both Microsoft Edge and Google Chrome. He earns $85,000 and 9 Master of Pwn points. That brings his contest total to $145,000 and 15 Master of Pwn points.

SUCCESS - The first Docker desktop escape at Pwn2Own involved two bugs, including a UAF. The team from STAR Labs SG did great work in the demonstration and earned $60,000 and 6 Master of Pwn points.

SUCCESS - Valentina Palmiotti (@chompie1337) with IBM X-Force used an Improper Update of Reference Count bug to escalate privileges on Windows 11. She nailed her first #Pwn2Own event and walks away with $15,000 and 3 Master of Pwn points.

BUG COLLISION - The final entry of Pwn2Own Vancouver 2024 ends as a collision as Theori used a bug that was previously know to escalate privileges on Ubuntu desktop. He still wins $5,000 and 1 Master of Pwn point.

Welcome to the first day of Pwn2Own Vancouver 2024! We have two amazing days of research planned, including every browser, SharePoint, and Tesla. We’ll be updating this blog in real time as results become available. We have a full schedule of attempts today, so stay tuned! All times are Pacific Daylight Time (GMT -7:00).

And we’re done with Day One of Pwn2Own Vancouver 2024. We awarded $732,500 USD for 19 unique 0-days. See below for the details of each event. Here are the Master of Pwn standings after the first day:

SUCCESS - AbdulAziz Hariri of Haboob SA was able to execute their code execution attack against Adobe Reader. He combined an an API Restriction Bypass and a Command Injection bug. He earns himself $50,000 and 5 Master of Pwn points.

SUCCESS - The DEVCORE Research Team was able to execute their LPE attack against Windows 11. They combined a couple of bugs, including a somewhat risky TOCTOU race condition. They earn $30,000 and 3 Master of Pwn points.

FAILURE - The Starlabs SG team was unable to get their exploit of Microsoft SharePoint working within the time allotted.

SUCCESS - Seunghyun Lee (@0x10n) of KAIST Hacking Lab was able to execute their exploit of the Google Chrome web browser using a single UAF bug. They earn $60,000 and 6 Master of Pwn points.

SUCCESS - Gwangun Jung (@pr0ln) and Junoh Lee (@bbbig12) from Theori (@theori_io) combined an uninitiallized variable bug, a UAF, and a heap-based buffer overflow to escape VMware Workstation and then execute code as SYSTEM on the host Windows OS. This impressive feat earns them $130,000 and 13 Master of Pwn points.

BUG COLLISION - The DEVCORE Team was able to execute their LPE attack against Ubuntu Linux. However, the bug they used was previously known. They still earn $10,000 and 1 Master of Pwn points.

SUCCESS - Bruno PUJOS and Corentin BAYET from REverse Tactics (@Reverse_Tactics) combined two Oracle VirtualBox bugs - including a buffer overflow - along with a Windows UAF to escape the guest OS and execute code as SYSTEM on the host OS. This fantastic research earns them $90,000 and 9 Master of Pwn points.

SUCCESS - The Synacktiv (@synacktiv) team used a single integer overflow to exploit the Tesla ECU with Vehicle (VEH) CAN BUS Control. The win $200,000, 20 Master of Pwn points, and a new Tesla Model 3 (their second!).

SUCCESS - Kyle Zeng from ASU SEFCOM used an ever tricky race condition to escalate privileges on Ubuntu Linux desktop. This earns him him $20,000 and 20 Master of Pwn points.

SUCCESS - Cody Gallagher used a single OOB Write bug to exploit Oracle VirtualBox. His first ever Pwn2Own attempt results in him winning $20,000 (second round win) and 4 Master of Pwn points.

SUCCESS - Manfred Paul (@_manfp) gets RCE on the Apple Safari browser with an integer underflow bug plus a PAC bypass using a weakness in Apple Safari. He wins himself $60,000 and 6 Master of Pwn points.

FAILURE - STAR Labs SG could not get their exploit of VMware ESXi working within the time allotted.

SUCCESS - Dungdm (@_piers2) of Viettel Cyber Security used two bugs, including the ever-risky race condition, to exploit Oracle VirtualBox. As a round 3 winner, they receive $20,000 and 4 Master of Pwn points.

SUCCESS - Manfred Paul (@_manfp) executed a double-tap exploit on both Chrome and Edge browsers with the rare CWE-1284 Improper Validation of Specified Quantity in Input. His Round 2 win earns him $42,500 and 15 Master of Pwn points.

That’s a wrap on Day One of Pwn2Own Vancouver 2024. We awarded $732,500 for 19 unique bugs. Tune in tomorrow to see if Synacktive can hold on to their Master of Pwn lead or if Manfred Paul is able to overtake them.

Welcome to Pwn2Own Vancouver 2024! This year’s event promises to be the largest-ever Vancouver event - both in terms of entries and potential prizes. If everything hits, we will end up paying out over $1,300,000 in cash and prizes - including a Tesla Model 3. We’ve got two full days of exciting competition ahead. 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 Daylight Time [UTC - 7:00]).

Note: All times subject to change

Day One

Wednesday, March 20 – 0930              

AbdulAziz Hariri of Haboob SA targeting Adobe Reader in the Enterprise Applications category.

Wednesday, March 20 – 1000              

DEVCORE Research Team targeting Microsoft Windows 11 in the Local Privilege Escalation category.

Wednesday, March 20 – 1030              

STAR Labs SG targeting Microsoft SharePoint in the Server category.

Wednesday, March 20 – 1100              

Seunghyun Lee (@0x10n) of KAIST Hacking Lab targeting Google Chrome in the Web Browser category.

Wednesday, March 20 – 1200              

Theori targeting VMware Workstation with an additional Windows Kernel LPE vulnerability in the Virtualization category.

Wednesday, March 20 – 1230              

DEVCORE Research Team targeting Ubuntu Desktop in the Local Privilege Escalation category.

Wednesday, March 20 – 1300              

Bruno PUJOS and Corentin BAYET from REverse Tactics (@Reverse_Tactics) targeting Oracle VirtualBox with an additional Windows Kernel LPE vulnerability in the Virtualization category.

Wednesday, March 20 – 1430              

Synacktiv targeting Tesla ECU with Vehicle (VEH) CAN BUS Control in the Automotive category.

Wednesday, March 20 – 1500              

Kyle Zeng from ASU SEFCOM targeting Ubuntu Desktop in the Local Privilege Escalation category.

Wednesday, March 20 – 1530              

Cody Gallagher targeting Oracle VirtualBox in the Virtualization category.

Wednesday, March 20 – 1600              

Manfred Paul (@_manfp) targeting Apple Safari in the Web Browser category.

Wednesday, March 20 – 1700              

STAR Labs SG targeting VMware ESXi in the Virtualization category.

Wednesday, March 20 – 1800              

Team Viettel targeting Oracle VirtualBox in the Virtualization category.

Wednesday, March 20 – 1830              

Manfred Paul (@_manfp) targeting Google Chrome with Double Tap addon in the Web Browser category.

Day Two 

Thursday, March 21 – 0930   

Marcin Wiązowski targeting Microsoft Windows 11 in the Local Privilege Escalation category.

Thursday, March 21 – 1000   

STAR Labs SG targeting VMware Workstation in the Virtualization category.

Thursday, March 21 – 1030   

ColdEye targeting Oracle VirtualBox in the Virtualization category.

Thursday, March 21 – 1100   

Manfred Paul (@_manfp) targeting Mozilla Firefox with Sandbox Escape in the Web Browser category.

Thursday, March 21 – 1200   

Gabriel Kirkpatrick (gabe_k of exploits.forsale) targeting Microsoft Windows 11 in the Local Privilege Escalation category.

Thursday, March 21 – 1230   

STAR Labs SG targeting Ubuntu Desktop in the Local Privilege Escalation category.

Thursday, March 21 – 1300   

Edouard Bochin (@le_douds) and Tao Yan (@Ga1ois) from Palo Alto Networks targeting Google Chrome with Double Tap addon in the Web Browser category.

Thursday, March 21 – 1430   

HackInside targeting Microsoft Windows 11 in the Local Privilege Escalation category.

Thursday, March 21 – 1500   

STAR Labs SG targeting Docker Desktop in the Cloud Native / Container category.

Thursday, March 21 – 1530   

Seunghyun Lee (@0x10n) of KAIST Hacking Lab targeting Microsoft Edge (Chromium) with Double Tap Addon in the Web Browser category.

Thursday, March 21 – 1630   

Valentina Palmiotti with IBM X-Force targeting Microsoft Windows 11 in the Local Privilege Escalation category.

Thursday, March 21 – 1700   

Theori targeting Ubuntu Desktop in the Local Privilege Escalation category. 

We’ll be publishing results live on the blog as the contest unfolds. We’ll also be posting brief video highlights to Twitter, YouTube, Mastodon, LinkedIn, and Instagram, so follow us on your favorite flavor of social media for the latest news from the event.

It’s the second Tuesday of the month, and Adobe and Microsoft have released a fresh crop of security updates. Take a break from your other activities and join us as we review the details of their latest advisories. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for March 2024

For March, Adobe released six patches addressing 56 vulnerabilities in Adobe Experience Manager, Premiere Pro, ColdFusion, Adobe Bridge, Lightroom, and Adobe Animate. Two of these bugs were submitted through the ZDI Program. The largest is the update for Experience Manager, which addresses 44 CVEs. However, all but two of these are simple cross-site scripting (XSS) bugs. The fix for Adobe Animate corrects four CVEs. Only one of these CVEs is rated Critical and could lead to arbitrary code execution if a user opens a specially crafted file on an affected system. The other three bugs are all memory leaks resulting from Out-of-Bounds (OOB) Read bugs. The patch for Premiere Pro fixes two Critical-rated bugs that also require user interaction to gain code execution.

For those still running ColdFusion, there’s a single Critical-rated arbitrary file system read bug getting fixed. Adobe also recommends updating your ColdFusion JDK/JRE LTS version to the latest update release. The fix for Adobe Bridge addresses three Critical rated and one Important severity bug. The worst could lead to code execution when opening a specially crafted file. The final patch fixes a single code execution bug in Lightroom. Adobe also made the odd decision to stop tweeting when its patches become available and limiting communication to just email subscriptions. Let’s hope they reverse that decision as many people (myself included) rely on the twitter feed for notifications.

And with this release, anyone targeting Adobe Reader at next week’s Pwn2Own Vancouver event can breathe a sigh of relief. It seems your exploits won’t be patched before the event.  

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 a deployment priority rating of 3.

Microsoft Patches for March 2024

This month, Microsoft released 59 new patches addressing CVEs in Microsoft Windows and Windows Components; Office and Office Components; Azure; .NET Framework and Visual Studio; SQL Server; Windows Hyper-V; Skype; Microsoft Components for Android; and Microsoft Dynamics. In addition to the new CVEs, multiple Chromium bugs are being incorporated into the release, bringing the total number of CVEs to 64. One of these bugs was reported through the ZDI program.

Of the new patches released today, two are rated Critical, and 57 are rated Important in severity. This is a relatively low volume for March, especially considering this is the last patch cycle before the Pwn2Own contest next week. Vendors usually try to patch as much as possible knowing we update all targets to the latest release. Considering Microsoft has several targets in the contest, it’s interesting to see such a small release.

None of the CVEs released today are listed as publicly known or under active attack, but that could change. After the February release, Microsoft revised multiple updates to indicate they were being actively exploited. For now, nothing is listed as in the wild. I’ll update this blog should that change.

Let’s take a closer look at some of the more interesting updates for this month, starting with a Critical-rated Hyper-V bug:

-       CVE-2024-21407 – Windows Hyper-V Remote Code Execution Vulnerability
This is one of the two Critical-rated bugs for this month, and this is the only one that could result in code execution. This vulnerability would allow a user on a guest OS to execute arbitrary code on the host OS. This is often referred to as a guest-to-host escape and could be used to impact other guest OSes on the server. It’s a shame we won’t see this bug get exploited at Pwn2Own next week, where it could have won $250,000. Maybe next year.

-       CVE-2024-26198 – Microsoft Exchange Server Remote Code Execution Vulnerability
It seems there are Exchange patches almost every month now, and March is no different. This bug is a classic DLL loading vulnerability. An attacker places a specially crafted file in a location they control. They then entice a user to open the file, which loads the crafted DLL and leads to code execution. Last month, Microsoft stated the Exchange bug was being actively exploited only after the release. This bug is currently NOT listed as exploited in the wild, but I’ll update this blog should Microsoft change its mind (again).

-       CVE-2024-21334 – Open Management Infrastructure (OMI) Remote Code Execution Vulnerability
This bug rates the highest CVSS rating for this release with a 9.8. It would allow a remote, unauthenticated attacker to execute code on OMI instances on the Internet. It’s not clear how many of these systems are reachable through the Internet, but it’s likely a significant number. Microsoft gives this an “Exploitation less likely” rating, but considering this is a simple Use After Free (UAF) bug on a juicy target, I would expect to see scanning for TCP port 5986 on the uptick soon.

-       CVE-2024-21400 – Microsoft Azure Kubernetes Service Confidential Container Elevation of Privilege Vulnerability
This bug allows an unauthenticated attacker to access the untrusted AKS Kubernetes node and AKS Confidential Container to take over confidential guests and containers. Successful exploitation would allow the attacker to steal credentials and affect other resources. While that’s bad enough, patching won’t be straightforward. Customers must ensure they are running the latest version of “az confcom” and Kata Image. The bulletin contains additional information on the commands needed. Be sure to check it out.

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

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

The only other Critical-rated bug is a Denial-of-Service (DoS) vulnerability in Hyper-V Server. Microsoft does not indicate how extensive the DoS is or if the system automatically recovers, but considering its rating, the bug likely shuts down the entire system.

Moving on to the other remote code execution bugs, as we saw last month, there are many impacting SQL clients that would require connecting to a malicious SQL server. Practical exploitation is unlikely without significant social engineering. That’s not the case for the bug in Django Backend for SQL Server. This vulnerability is a classic SQL injection via unsanitized parameters. There’s also a DLL loading bug for Windows OLE. The RCE bug in SharePoint requires user interaction in that the threat actor needs to convince the user to open a specially crafted file. Social engineering will also be required for the Skype for Consumer vulnerability. You’ll also need to manually download the latest version of Skype here as there doesn’t seem to be an automated upgrade option. The final two RCE bugs are a bit rare in that they require physical access to the target system. Both vulnerabilities rely on the attacker plugging a device into an open USB port. It’s uncommon to see patches for bugs with this physical attack vector, but it’s good to see Microsoft is willing to make updates for these types of issues.

Speaking of rarities, there is a single patch for a Tampering bug in the Windows compressed folder component. Microsoft doesn’t give any indication of how the vulnerability would manifest other than to say it requires a user to open a specially crafted file. After that, it’s not clear what is actually being tampered with, although the inclination is to believe an attacker could change file contents with this bug.

There are more than 20 elevation of privilege (EoP) patches in this month’s release. In most cases, a local attacker would need to run specially crafted code to elevate to SYSTEM. The bug in the telephony component would lead to the similar (but distinctly different) “NT AUTHORITY\Network Service” privilege. The bug in the Azure Data Studio would only elevate to the permission level of the user running the application. Another reminder to not do daily tasks with administrative privileged accounts. The bug in the Microsoft Intune Linux Agent bypasses compliance checks when using custom compliance scripts, thus altering the results. The bug in the Authenticator app sounds quite bad as it could bypass 2FA, but it requires a fair bit of user interaction to succeed. An attacker needs to be already executing code on the target and have the user close and re-open the Authenticator application. The vulnerability in the Windows Installer would allow an attacker to delete files. We recently blogged about a similar bug in the .NET framework. The bug in OMI is interesting in that an attacker could exploit it to communicate as Root with an OMI server. The final EoP patch for March affects the Software for Open Networking in the Cloud (SONiC) component. Successful exploitation would allow an attacker to escalate to Root in the Border Gateway Protocol (BGP) container and perform specific actions that enable them to escape the container.

There are three separate Security Feature Bypass (SFB) patches in this month’s release with the most impactful affecting Windows Defender. The good news is that you’ll likely need to take no action as the Defender engine automatically updates itself. The bad news is that if you’re in an isolated environment or have Defender disabled, you’ll likely need to manually verify the Defender version. Given that this bug allows attackers to prevent Defender from starting, it’s best to make sure you have that patch applied. The bug in the hypervisor-protected code integrity (HVCI) could allow an attacker to bypass code integrity protections, but it requires administrator-level permissions. Another rarity, as exploits that begin with admin permissions rarely get fixed. The final SFB update fixes a bug in Kerberos that could lead to impersonating other users.  

The March release includes five information disclosure bugs, but unusually, only one leaks unspecified memory contents. The two bugs in the kernel could allow an attacker to view registry keys they would otherwise not be able to access. The bug in Teams for Android would allow the reading of files from the private directory of the app. You’ll also need to manually get this update from the Google Play Store. That’s also the case for Outlook for Android. That bug allows attackers to view the ineffable “file contents”. In addition to the one already documented, the March release includes fixes for five different denial-of-service (DoS) bugs in various. However, Microsoft provides no real information or details for them.

There are two spoofing bugs receiving patches this month, and the Microsoft Edge for Android is a strange one. It was actually published earlier this month but without an actual fix. Instead, it notes, “The security update for Edge for Android is not immediately available.” It seems odd that Microsoft would choose to publish information about the bug without also pushing a fix for the bug. Perhaps it will be updated soon. The other spoofing bug is in the Azure SDK, and you may or may not need to take extra steps to be fully protected. If you are running a deployment created before October 19, 2023, you will need to manually upgrade Azure-core to Azure Core Build 1.29.5 or higher. If you have a deployment from after October 19, you should receive the patch automatically.

There is one new advisory for this month as Microsoft announces the deprecation of Oracle’s libraries within Exchange. This is a long time coming and a welcome change, as Exchange was essentially 0-day’ed every time Oracle updated their libraries.

Finally, there is a single cross-site scripting (XSS) bug in Microsoft Dynamics fixed this month.

Looking Ahead

Be sure to look out for updates from Pwn2Own Vancouver, and if you’re at the CanSecWest conference, please stop by to say hello. I like it when people say hello. The next Patch Tuesday of 2024 will be on April 9, and I’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!