Reading view

There are new articles available, click to refresh the page.

CVE-2021-28632 & CVE-2021-39840: Bypassing Locks in Adobe Reader

Over the past few months, Adobe has patched several remote code execution bugs in Adobe Acrobat and Reader that were reported by researcher Mark Vincent Yason (@MarkYason) through our program. Two of these bugs, in particular, CVE-2021-28632 and CVE-2021-39840, are related Use-After-Free bugs even though they were patched months apart. Mark has graciously provided this detailed write-up of these vulnerabilities and their root cause.


This blog post describes two Adobe Reader use-after-free vulnerabilities that I submitted to ZDI: One from the June 2021 patch (CVE-2021-28632) and one from the September 2021 patch (CVE-2021-39840). An interesting aspect about these two bugs is that they are related – the first bug was discovered via fuzzing and the second bug was discovered by reverse engineering and then bypassing the patch for the first bug.

CVE-2021-28632: Understanding Field Locks

One early morning while doing my routine crash analysis, one Adobe Reader crash caught my attention:

After a couple of hours minimizing and cleaning up the fuzzer-generated PDF file, the resulting simplified proof-of-concept (PoC) was as follows:

PDF portion (important parts only):

JavaScript portion:

The crash involved a use-after-free of CPDField objects. CPDField objects are internal AcroForm.api C++ objects that represent text fields, button fields, etc. in interactive forms.

In the PDF portion above, two CPDField objects are created to represent the two text fields named fieldParent and fieldChild. Note that the created objects have the type CTextField, a subclass of CPDField, which is used for text fields. To simplify the discussion, they will be referred to as CPDField objects.

An important component for triggering the bug is that fieldChild should be a descendant of fieldParent by specifying it in the /Kids key of the fieldParent PDF object dictionary (see [A] above) as documented in the PDF file format specification:

img01.jpg

Another important concept relating to the bug is that to prevent a CPDField object from being freed while it is in use, an internal property named LockFieldProp is used. Internal properties of CPDField objects are stored via a C++ map member variable.

If LockFieldProp is not zero, it means that the CPDField object is locked and can't be freed; if it is zero or is not set, it means that the CPDField object is unlocked and can be freed. Below is the visual representation of the two CPDField objects in the PoC before the field locking code (discussed later) is called: fieldParent is unlocked (LockFieldProp is 0) and is in green, and fieldChild is also unlocked (LockFieldProp is not set) and is also in green:

img02.jpg

On the JavaScript portion of the PoC, the code sets up a JavaScript callback so that when the “Format” event is triggered for fieldParent, a custom JavaScript function callback() will be executed [2]. The JavaScript code then triggers a “Format” event by setting the textSize property of fieldParent [3]. Internally, this executes the textSize property setter of JavaScript Field objects in AcroForm.api.

One of the first actions of the textSize property setter in AcroForm.api is to call the following field locking code against fieldParent:

The above code locks the CPDField object passed to it by setting its LockFieldProp property to 1 [AA].

After executing the field locking code, the lock state of fieldParent (locked: in red) and fieldChild (unlocked: in green) are as follows:

img03.jpg

Note that in the later versions of Adobe Reader, the value of LockFieldProp is a pointer to a counter instead of being set with the value 1 or 0.

Next, the textSize property setter in AcroForm.api calls the following recursive CPDField method where the use-after-free occurs:

On the first call to the above method, the this pointer points to the locked fieldParent CPDField object. Because it has no associated widget [aa], the method performs a recursive call [cc] with the this pointer pointing to each of fieldParent's children [bb].

Therefore, on the second call to the above method, the this pointer points to the fieldChild CPDField object, and since it has an associated widget (see [B] in the PDF portion of the PoC), a notification will be triggered [dd] that results in the custom JavaScript callback() function to be executed. As shown in the previous illustration, the locking code only locked fieldParent while fieldChild is left unlocked. Because fieldChild is unlocked, the removeField("fieldChild") call in the custom JavaScript callback() function (see [1] in the JavaScript portion of the PoC) succeeds in freeing the fieldChild CPDField object. This leads to the this pointer in the recursive method to become a dangling pointer after the call in [dd]. The dangling this pointer is later dereferenced resulting in the crash.

This first vulnerability was patched in June 2021 by Adobe and assigned CVE-2021-28632.

CVE-2021-39840: Reversing Patch and Bypassing Locks

I was curious to see how Adobe patched CVE-2021-28632, so after the patch was released, I decided to look at the updated AcroForm.api.

Upon reversing the updated field locking code, I noticed an addition of a call to a method that locks the passed field’s immediate descendants:

With the added code, both fieldParent and fieldChild will be locked and the PoC for the first bug will fail in freeing fieldChild:

img04.jpg

While assessing the updated code and thinking, I arrived at a thought: since the locking code only additionally locks the immediate descendants of the field, what if the field has a non-immediate descendant?... a grandchild field! I quickly modified the PoC for CVE-2021-28632 to the following:

PDF portion (important parts only):

JavaScript portion:

And then loaded the updated PoC in Adobe Reader under a debugger, hit go... and crash!

The patch was bypassed, and Adobe Reader crashed at the same location in the previously discussed recursive method where the use-after-free originally occurred.

Upon further analysis, I confirmed that the illustration below was the state of the field locks when the recursive method was called. Notice that fieldGrandChild is unlocked, and therefore, can be freed:

img05.jpg

The recursive CPDField method started with the this pointer pointing to fieldParent, and then called itself with the this pointer pointing to fieldChild, and then called itself again with the this pointer pointing to fieldGrandChild. Since fieldGrandChild has an attached widget, the JavaScript callback() function that frees fieldGrandChild was executed, effectively making the this pointer a dangling pointer.

This second vulnerability was patched in September 2021 by Adobe and assigned CVE-2021-39840.

Controlling Field Objects

Control of the freed CPDField object is straightforward via JavaScript: after the CPDField object is freed via the removeField() call, the JavaScript code can spray the heap with similarly sized data or an object to replace the contents of the freed CPDField object.

When I submitted my reports to ZDI, I included a second PoC that demonstrates full control of the CPDField object and then dereferences a controlled, virtual function table pointer:

Conclusion

Implementation of object trees, particularly those in applications where the objects can be controlled and destroyed arbitrarily, is prone to use-after-free vulnerabilities. For developers, special attention must be made to the implementation of object reference tracking and object locking. For vulnerability researchers, they represent opportunities for uncovering interesting vulnerabilities.


Thanks again to Mark for providing this thorough write-up. He has contributed many 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 for the latest in exploit techniques and security patches.

CVE-2021-28632 & CVE-2021-39840: Bypassing Locks in Adobe Reader

MindShaRE: Using IO Ninja to Analyze NPFS

In this installment of our MindShaRE series, ZDI vulnerability researcher Michael DePlante describes how he uses the IO Ninja tool for reverse engineering and software analysis. According to its website, IO Ninja provides an “all-in-one terminal emulator, sniffer, and protocol analyzer.” The tool provides many options for researchers but can leave new users confused about where to begin. This blog provides a starting point for some of the most commonly used features. 


Looking at a new target can almost feel like meeting up with someone who’s selling their old car. I’m the type of person who would want to inspect the car for rust, rot, modifications, and other red flags before I waste the owner’s or my own time with a test drive. If the car isn’t super old, having an OBD reader (on-board diagnostics) may save you some time and money. After the initial inspection, a test drive can be critical to your decision. 

Much like checking out a used car, taking software for test drives as a researcher with the right tools is a wonderful way to find issues. In this blog post, I would like to highlight a tool that I have found incredibly handy to have in my lab – IO Ninja.

Lately, I have been interested in antivirus products, mainly looking for local privilege escalation vulnerabilities. After looking at several vendors including Avira, Bitdefender, ESET, Panda Security, Trend Micro, McAfee, and more, I started to notice that almost all of them utilize the Named Pipe Filesystem (NPFS). Furthermore, NPFS is used in many other product categories including virtualization, SCADA, license managers/updaters, etc.

I began doing some research and realized there were not many tools that let you locally sniff and connect to these named pipes easily in Windows. The Sysinternals suite has a tool called Pipelist and it works exactly as advertised. Pipelist can enumerate open pipes at runtime but can leave you in the dark about pipe connections that are opening and closing frequently. Another tool also in the Sysinternals suite called Process Explorer allows you to view open pipes but only shows them when you are actively monitoring a given process. IO Ninja fills the void with two great plugins it offers.

An Introduction to IO Ninja  

When you fire up IO Ninja and start a new session, you’re presented with an expansive list of plugins as shown below. I will be focusing on two of the plugins under the “File Systems” section in this blog: Pipe Monitor and Pipe Server.  

Before starting a new session, you may need to check the “Run as Administrator” box if the pipes you want to interact with require elevated privileges to read or write. You can inspect the permissions on a given pipe with the accesschk tool from the Sysinternals Suite:

The powerful Pipe Monitor plugin in IO Ninja allows you to record communication, as well as apply filters to the log. The Pipe Server plugin allows you to connect to the client side of a pipe. 

IO Ninja: Pipe Monitor

The following screenshot provides a look at the Pipe Monitor plugin that comes by default with IO Ninja.

In the above screenshot, I added a process filter (*chrome*) and started recording before I opened the application. You can also filter on a filename ( name of the pipe), PID, or file ID. After starting Chrome, data started flowing between several pipe instances. This is a terrific way to dynamically gather an understanding of what data is going through each pipe and when those pipes are opened and closed. I found this helpful when interacting with antivirus agents and wanted to know what pipes were being opened or closed based on certain actions from the user, such as performing a system scan or update. It can also be interesting to see the content going across the pipe, especially if it contains sensitive data and the pipe has a weak ACL.

It can also help a developer debug an application and find issues in real-time like unanswered pipe connections or permission issues as shown below. 

Using IO Ninja’s find text/bin feature to search for “cannot find”, I was able to identify several connections in the log below where the client side of a connection could not find the server side. In my experience, many applications make these unanswered connections out of the box.

What made this interesting was that the process updatesrv.exe, running as NT AUTHORITY\SYSTEM, tried to open the client side of a named pipe but failed with ERROR_FILE_NOT_FOUND. We can fill the void by creating our own server with the name it is looking for and then triggering the client connection by initiating an update within the user interface.

As a low privileged user, I am now able to send arbitrary data to a highly privileged process using the Pipe Server plugin. This could potentially result in a privilege escalation vulnerability, depending on how the privileged process handles the data I am sending it.

IO Ninja: Pipe Server

The Pipe Server plugin is powerful as it allows you to send data to specific client connections from the server side of a pipe. The GUI in IO Ninja allows you to select which conversation you’d like to interact with by selecting from a drop-down list of Client IDs. Just like with the Pipe Monitor plugin, you can apply filters to clean up the log. Below you’ll find a visual from the Pipe Server plugin after starting the server end of a pipe and getting a few client connections.  

In the bottom right of the previous image, you can see the handy packet library. Other related IO Ninja features include a built-in hex editor, file- and script-based transmission, and packet templating via the packet template editor.

The packet template editor allows you to create packet fields and script custom actions using the Jancy scripting language. Fields are visualized in the property grid as shown above on the bottom left-hand side of the image, where they can be edited. This feature makes it significantly easier to create and modify packets when compared to just using a hex editor.

Conclusion

This post only scratches the surface of what IO Ninja can do by highlighting just two of the plugins offered. The tool is scriptable and provides an IDE that encourages users to build, extend or modify existing plugins.  The plugins are open source and available in a link listed at the end of the blog. I hope that this post inspires you to take a closer look at NPFS as well as the IO Ninja tool and the other plugins it offers.

Keep an eye out for future blogs where I will go into more detail on vulnerabilities I have found in this area. Until then, you can follow me @izobashi and the team @thezdi on Twitter for the latest in exploit techniques and security patches.

Additional information about IO Ninja can be found on their website. All of IO Ninja’s plugins are open source and available here.

Additional References

If you are interested in learning more you can also check out the following resources which I found helpful.

Microsoft - Documentation: Named Pipes

Gil Cohen - Call the plumber: You have a leak in your named pipe

0xcsandker - Offensive Windows IPC Internals 1: Named Pipes

MindShaRE: Using IO Ninja to Analyze NPFS

Abusing Arbitrary File Deletes to Escalate Privilege and Other Great Tricks

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

The Trouble with Arbitrary File Deletes

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

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

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

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

The Solution is Found Elsewhere: Windows Installer

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

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

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

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

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

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

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

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

From Arbitrary Folder Delete/Move/Rename to SYSTEM EoP

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

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

The full mechanism of the EoP exploit is as follows:

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

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

From Arbitrary File Delete to SYSTEM EoP

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

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

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

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

From Folder Contents Delete to SYSTEM EoP

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

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

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

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

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

From Arbitrary Folder Create to Permanent DoS

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

      C:\Windows\System32\cng.sys

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

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

Conclusion

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

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

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

Abusing Arbitrary File Deletes to Escalate Privilege and Other Great Tricks

What to Expect when Exploiting: A Guide to Pwn2Own Participation

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

1.     You need to register before the contest.

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

2.     You need to answer the vetting email.

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

3.     What should we call you?

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

4.     Will you be participating locally or remotely?

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

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

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

6.     Ask questions before the competition.

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

7.     Be prepared for things to go wrong.

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

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

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

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

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

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

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

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

What to Expect when Exploiting: A Guide to Pwn2Own Participation

Pwn2Own Vancouver 2023 - Day One Results

Welcome to Pwn2Own Vancouver 2023! We’ll be updating this blog in real time as results become available. We have eight attempts for today, including a SharePoint RCE and a Tesla exploit. We’re excited to say that all unique winning entries will receive the full payout during this year’s contest. We’ll update this blog throughout the day with results as they come in.

SUCCESS - AbdulAziz Hariri (@abdhariri) of Haboob SA (@HaboobSa) completed his attack against Adobe Reader using a 6-bug logic chain exploiting multiple failed patches which escaped the sandbox and bypassed a banned API list. He earns $50,000 and 5 Master of Pwn points.

FAILURE - last_minute_pwnie was unable to get their Ubuntu exploit working within the time allotted.

SUCCESS - STAR Labs (@starlabs_sg) was able to execute a 2-bug chain against Microsoft SharePoint. They earn $100,000 and 10 Master of Pwn points.

SUCCESS - Bien Pham (@bienpnn) from Qrious Security (@qriousec) used an OOB Read and a stacked-based buffer overflow to exploit Oracle VirtualBox. He earns $40,000 and 4 Master of Pwn points.

SUCCESS - Synacktiv (@Synacktiv) was able to execute their TOCTOU attack against Tesla – Gateway. They earn $100,000 as well as 10 Master of Pwn points and a Tesla Model 3.

COLLISION - STAR Labs (@starlabs_sg) successfully executed their attack against Ubuntu Desktop, but the exploit was previously known. They still earn $15,000 and 1.5 Master of Pwn points.

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

SUCCESS - Synacktiv (@Synacktiv) used a TOCTOU bug to escalate privileges on Apple macOS. They earn $40,000 and 4 Master of Pwn points.

That wraps up the first day of Pwn2Own Vancouver 2023! We awarded $375,000 (and a Tesla Model 3!) for 12 zero-days during the first day of the contest. We’ll continue posting results and videos to Twitter, YouTube, Mastodon, LinkedIn, and Instagram, so follow us on your favorite flavor of social media for the latest news from the event.

Pwn2Own Vancouver 2023 - Day Two Results

Welcome to Day 2 of Pwn2Own Vancouver 2023! We’ll be updating this blog in real time as results become available. We’re excited to say that all unique winning entries will receive the full payout during this year’s contest. We’ll update this blog throughout the day with results as they come in.

SUCCESS / COLLISION - Thomas Imbert (@masthoon) and Thomas Bouzerar (@MajorTomSec) from Synacktiv (@Synacktiv) demonstrated a 3-bug chain against Oracle VirtualBox with a Host EoP. One bug was previously known. They still earn $80,000 and 8 Master of Pwn points.

SUCCESS - @hoangnx99, @rskvp93, and @_q5ca from Team Viettel (@vcslab) used a 2-bug chain in their attempt against Microsoft Teams. They earn $75,000 and 8 Master of Pwn points.

SUCCESS - David Berard (@_p0ly_) and Vincent Dehors (@vdehors) from Synacktiv (@Synacktiv) used a heap overflow and an OOB write to exploit Tesla - Infotainment Unconfined Root. They qualify for a Tier 2 award, earning $250,000 and 25 Master of Pwn points.

SUCCESS - dungdm (@_piers2) of Team Viettel (@vcslab) used an uninitialized variable and a UAF bug to exploit Oracle VirtualBox. They earn $40,000 and 4 Master of Pwn points.

SUCCESS - Tanguy Dubroca (@SidewayRE) from Synacktiv (@Synacktiv) used an incorrect pointer scaling leading to privilege escalation on Ubuntu Desktop. They earn $30,000 and 3 Master of Pwn points.

That wraps up Day 2 of Pwn2Own Vancouver 2023! We awarded $475,000 for 10 unique zero-days during the second day of the contest. We’ll continue posting results and videos to Twitter, YouTube, Mastodon, LinkedIn, and Instagram, so follow us on your favorite flavor of social media for the latest news from the event.

Pwn2Own Vancouver 2023 - Day Three Results

That’s a wrap for Pwn2Own Vancouver! Contestants disclosed 27 unique zero-days and won a combined $1,035,000 (and a car)! Congratulations to the Masters of Pwn, Synacktiv (@Synacktiv), for their huge success and hard work! They earned 53 points, $530,000, and a Tesla Model 3.

Team Synacktiv: Eloi Benoist-Vanderbeken, David Berard, Vincent Dehors, Tanguy Dubroca, Thomas Bouzerar, and Thomas Imbert. They also receive a $25,000 bonus and Platinum status in 2024.

Follow us here and on Twitter, YouTube, Mastodon, LinkedIn, and Instagram to keep up with the latest news – and stay tuned for Pwn2Own Toronto in October!


Welcome to Day 3 of Pwn2Own Vancouver 2023. We’ll be updating this blog in real time as results become available. For this year’s event, each round will receive the full payout for unique entries.

SUCCESS - Kyle Zeng from ASU SEFCOM used a double free bug to exploit Ubuntu Desktop. He earns $30,000 and 3 Master of Pwn points.

FAILURE - STAR Labs was unable to get their exploit of Microsoft Teams working within the time allotted.

SUCCESS - Thomas Imbert (@masthoon) from Synacktiv (@Synacktiv) used a UAF against Microsoft Windows 11. They earn $30,000 and 3 Master of Pwn points.

SUCCESS - Mingi Cho of Theori used a UAF against Ubuntu Desktop. They earn $30,000 and 3 Master of Pwn points.

SUCCESS - STAR Labs (@starlabs_sg) used an uninitialized variable and UAF against VMWare Workstation. They earn $80,000 and 8 Master of Pwn points.

COLLISION - Bien Pham (@bienpnn) of Qrious Security successfully targeted Ubuntu Desktop, but the exploit was previously known. They still earn $15,000 and 1.5 Master of Pwn points.

Bash Privileged-Mode Vulnerabilities in Parallels Desktop and CDPATH Handling in MacOS

In the last few years, we have seen multiple vulnerabilities in Parallels Desktop leading to virtual machine escapes. Interested readers can check our previous blog posts about vulnerabilities across interfaces such as RDPMC hypercalls, the Parallels ToolGate, and the VGA virtual device. This post explores another set of issues we received last year - local privilege escalations through setuid root binaries.

Parallels Desktop has a couple of setuid binaries: prl_update_helper and Parallels Service. Both binaries run with root privileges and both invoke bash scripts to run commands with the privileges of root. For such use cases, bash specifically provides a privileged mode using the “-p” flag. Parallels Desktop prior to version 18.1.0 does not take advantage of bash privileged mode, nor does it filter untrusted environment variables. This leads to local privilege escalation.

In the case of Parallels Desktop, the setuid binaries use the setuid() system call to set the real user identifier to that of the effective user identifier. The problem with this implementation is that sensitive environment variables such as BASH_ENV, ENV, SHELLOPTS, BASHOPTS, CDPATH, GLOBIGNORE, and other shell functions are processed by bash. This is because bash is not aware of the setuid or setgid execution and trusts its environment. A local unprivileged user with control over environment variables can exploit this bug to execute code with the privileges of root.

The Bash Privileged Mode

Bash shell drops privileges when started with the effective user identifier not equal to that of the real user identifier. The effective user identifier is reset by setting it to the value of the real user identifier. The same is also applicable for group identifiers. In privileged mode, bash does not drop the effective privileges and ignores sensitive variables and shell functions from the environment. Here’s the relevant source code in bash that can be found in shell.c file:

The functions of interest here are uidget and disable_priv_mode. The uidget function sets running_setuid if bash is launched from a setuid/setgid process. Later in the code, if privileged mode is not specified, the setuid and setgid calls are used to drop privileges to that of the real identifiers:

Note that, since the Bourne shell sh is linked to bash in macOS, the Apple bash code for invoking disable_priv_mode is slightly different from that of the upstream version. Interested readers can search for the __APPLE__ macro to narrow down changes made to the upstream version of bash by Apple.

The other functions of interest in the bash startup code are run_startup_files and shell_initialize, as they handle information passed through the untrusted environment variables. When privileged mode is not specified, these functions provide at least a couple of generic ways to exploit the vulnerability. To begin, the BASH_ENV is an environment variable specifying a path to a shell script that will be executed by bash during a non-interactive start-up. One can set up an arbitrary startup script to be executed by bash running without privileged mode. Shown below is the code snippet of run_startup_files in shell.c:

A second approach is by using bash shell functions. When commands are executed in bash without an absolute path, it is possible to hijack those commands by exporting shell functions having the same name as that of the command being executed. This is possible even when the PATH environment variable is set to trusted paths. The corresponding source code can be found across shell.c and variables.c files:

Knowing this, let’s take a look at some of the privileged mode bugs in Parallels Desktop and their exploitation.

CVE-2023-27322 - Local Privilege Escalation Through Parallels Service

This bug was submitted by Grisha Levit and is also identified as ZDI-23-216. Parallels Service forks a child process and executes an embedded script using a non-interactive bash shell invoked as /bin/bash -s. The parent process writes the embedded script through a pipe to the child process running the bash shell. Before invoking the bash shell, Parallels Service calls setuid(0) to set the real user identifier to the effective user identifier (root). Here is the relevant code snippet from the executable in Parallels Desktop version 17.1.4:

The execv function is a wrapper around execve, which fetches the environment using _NSGetEnviron() and passes it to execve. Therefore, the bash shell spawned as a child process has access to all the environment variables set by the user who launched Parallels Service, who may be an unprivileged user. Interestingly, the execution of an embedded shell script turned out to be not immediately vulnerable. This is because Parallels Service also has the setgid bit set and there is no corresponding call setgid(getegid()) as there was for the uid. Because of this, the real group identifier is not equal to that of the effective group identifier when bash is invoked. In such cases, bash identifies this as setgid execution, drops group privileges, and does not trust the environment. However, any further subshell launched from this bash shell will also have all the environment variables as well as the privileges of the parent shell, which is running as root and has the group privileges set after the call to disable_priv_mode. Considering this, the next interesting target is the watchdog script invoked from the embedded script as seen below:

The watchdog script uses /bin/bash as shebang and does not use privileged mode:

In this instance, bash trusts the environment. Because of this, the watchdog script can be exploited to gain root either by using the BASH_ENV environment variable or by exporting shell functions. Here is an example of exploitation using BASH_ENV:

To exploit using shell functions, we must identify a command to hijack. The watchdog script uses the echo command for printing some debug messages:

A shell function with the same name can be exported such that the malicious function is executed instead of the expected echo command. Note that exporting functions is a feature of bash. We must therefore use the bash shell to export the target function instead of using the default zsh shell in macOS.

This issue was fixed in Parallels Desktop 18.1.0 by adding the “-p” flag, indicating privileged mode, to the shebang interpreter directive:

CVE-2023-27324 and CVE-2023-27325 - Local Privilege Escalation Through Parallels Updater

The next two bugs were found in the Parallels Updater prl_update_helper binary. These bugs were submitted by the researcher known as kn32 and are also identified as ZDI-23-218 and ZDI-23-219. In the case of CVE-2023-27324, the prl_update_helper binary invokes a bash script named inittool without setting privileged mode:

Before invoking the inittool script, the real user identifier is set to that of the effective user identifier, which is root. This means bash will run as root and will trust its execution environment, which can lead to local privilege escalation.

This vulnerability can be exploited by using the BASH_ENV environment variable or by exporting the shell function for the dirname command.

The next bug (CVE-2023-27325) in the Parallels Updater affects the inittool2 executable invoked from the inittool script. Like the Parallels Service, inittool2 forks a child process and executes an embedded script using a non-interactive bash shell invoked as /bin/bash -s. Exploitation is similar to that of CVE-2023-27324. In this case, the rm command can be hijacked to execute arbitrary code as root. Below is the embedded script from Parallels Desktop version 17.1.4:

Both CVE-2023-27324 and CVE-2023-27325 were fixed in Parallels Desktop 18.1.0 by clearing the environment during the call to posix_spawn. Instead of passing the environ array to the child process, the envp argument is now provided with a pointer to a NULL array during the call to posix_spawn. Below is the patch diff between 17.1.4 and 18.1.0:

Figure 1 - Patch diff of prl_update_helper executable

Additionally, the privileged mode flag “-p” is also added to the shebang interpreter directive of the inittool script as well as the embedded script within inittool2. Note that the shebang of the embedded script is ignored since it is explicitly run using the bash interpreter.

CDPATH Handling in MacOS

During the analysis of these submissions, we also observed some differences in the way Apple bash handles “privileged mode” as compared to the upstream bash. Apple’s bash in macOS 13.0.1 is based on GNU Bash 3.2:

The upstream bash in privileged mode ignores many variables such as SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE as mentioned below:

Based on the CHANGES, here is a timeline of various changes related to privileged mode. Parsing of SHELLOPTS was ignored starting from bash-2.02-alpha1 and therefore ignored in version 3.2 too.

BASHOPTS was introduced at a later stage in bash-4.1-alpha and therefore not applicable to version 3.2.

The CDPATH and GLOBIGNORE variables were ignored only since bash-4.0-beta and therefore still get processed in Apple’s bash, which is based on version 3.2.

The CDPATH environment variable can be set to a colon-separated list of directories, which can then be used as a directory root by the built-in “cd” command instead of the current working directory (CWD). In the case of Apple’s bash, if a bash script executed through a setuid wrapper uses “cd [Absolute Path to Trusted Directory]” to change the CWD and further uses “cd subdirectory” to change the CWD, the later cd command with the relative path can be hijacked to a location controlled by an attacker by setting the CDPATH variable. Consider the sample code below:

Here is the outcome as tested in Ubuntu:

It is seen that the CDPATH environment variable is ignored in bash privileged mode (-p). While repeating the same in macOS, it is honored.

This can become problematic when a script is written assuming bash privileged mode behavior in macOS to be the same as that of the upstream version. You may note the duplicated /tmp/secure line. This is not a typo. It comes from the POSIX standard. If CDPATH is used for a directory change, the new directory path is echoed to stdout, which is the first line /tmp/secure. The second line comes from the pwd command.

Here is the comparison of builtins/cd.def which handles CDPATH in Apple bash versus the upstream version:

Figure 2 - Missing privileged mode check when handling CDPATH

Similarly, differences in GLOBIGNORE handling can be seen by diffing variables.c source file:

Figure 3 - Missing privileged mode check when handling GLOBIGNORE

Since macOS Catalina, zsh is used as the default shell. The official announcement for the same can be found here. Bash is deprecated on macOS and likely exists only for backward compatibility. For any bash scripts executed through a setuid wrapper, one must ensure privileged mode “-p” is enabled. In addition to that, beware of the differences in privileged mode between Apple bash and the upstream version. This is specifically noticed in the handling of the CDPATH and GLOBIGNORE environment variables.

Conclusion

Parallels Desktop is a popular target for researchers. We’ve already published seven advisories in the product in 2023 to go along with the 10 we published in 2022. With Parallels Desktop being one of the major virtualization solutions used in macOS, it’s understandable why it can be an enticing target for threat actors. My research into Parallels continues, and I’ll blog about any significant findings in the future. Of course, if you find similar vulnerabilities, we’d be interested in seeing those as well.

Until then, you can follow me @renorobertr and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

The April 2023 Security Update Review

It’s the second Tuesday of the month, which means Adobe and Microsoft (and others) have released their latest security patches. Take a break from your regularly scheduled activities and join us as we review the details of the latest offerings from Microsoft and Adobe. If you’d rather watch the video recap, check out the Patch Report webcast on our YouTube channel. It should be posted within a couple of hours after the release.

Adobe Patches for April 2023

For April, Adobe released six bulletins addressing 56 CVEs in Acrobat and Reader, Adobe Digital Editions, InCopy, Substance 3D Designer, Substance 3D Stager, and Adobe Dimension. A total of 47 of these CVEs were reported by ZDI vulnerability researchers Mat Powell and Michael DePlante. The update for Reader is likely the most important. It corrects 16 different CVEs, and 14 of these could lead to arbitrary code execution if a threat actor can get a user to open a specially crafted PDF with an affected version of Reader. This update also includes four CVEs from Abdul-Aziz Hariri of Haboob SA that were a part of his successful demonstration at the recent Pwn2Own Vancouver.

The patch for Adobe Digital Edition corrects a single Critical-rated code execution bug. The fix for InCopy also addresses a lone Critical-rated code execution issue. The other updates are noticeably larger. The update for Substance 3D Designer addresses nine bugs, all of which are rated Critical. The fix for Substance 3D Stager corrects 14 vulnerabilities, 10 of which are rated Critical and could lead to arbitrary code execution. The final patch from Adobe covers Adobe Dimension and corrects 15 unique bugs. A total of 14 of these bugs could lead to arbitrary code execution with the other being a 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.

Apple Patches for April 2023

Apple had a couple of CVEs patched last week and yesterday covering two bugs under active attack. CVE-2023-28205 is a UAF in WebKit and can be found in Safari, macOS, and iOS. It can lead to code execution at the level of the logged-on user. It would need to be paired with a privilege escalation to take over a system. The second bug patched by Apple does just that. CVE-2023-28206 is a privilege escalation in the IOSurfaceAccelerator component in macOS and iOS. Apple doesn’t expressly state these were used in conjunction, but they were reported by the same researchers at the same time, so their combined use makes sense.

Microsoft Patches for April 2023

This month, Microsoft released 97 new patches addressing CVEs in Microsoft Windows and Windows Components; Office and Office Components; Windows Defender; SharePoint Server; Windows Hyper-V; PostScript Printer; and Microsoft Dynamics. This is in addition to three Edge (Chromium-based) CVEs previously released and being documented today. That brings today’s total CVE count to an even 100. Six of these bugs came were submitted through the ZDI program.

Of the patches released today, seven are rated Critical and 90 are rated Important in severity. While this volume does seem to be in line with past years, the number of remote code execution (RCE) bugs makes up nearly half the release. It’s unusual to see that many RCE fixes in a single month. Also, note that none of the bugs disclosed over Teams during Pwn2Own Vancouver are being addressed by Microsoft this month.

One of the new CVEs is listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug under active attack:

 -       CVE-2023-28252 – Windows Common Log File System Driver Elevation of Privilege Vulnerability
This is the one bug under active attack this month, and if it seems familiar, that’s because there was a similar 0-day patched in the same component just two months ago. To me, that implies the original fix was insufficient and attackers have found a method to bypass that fix. As in February, there is no information about how widespread these attacks may be. This type of exploit is typically paired with a code execution bug to spread malware or ransomware. Definitely test and deploy this patch quickly.

-       CVE-2023-21554 – Microsoft Message Queuing Remote Code Execution Vulnerability
This is a CVSS 9.8 bug and receives Microsoft’s highest exploitability rating. It allows a remote, unauthenticated attacker to run their code with elevated privileges on affected servers with the Message Queuing service enabled. This service is disabled by default but is commonly used by many contact center applications. It listens to TCP port 1801 by default, so blocking this at the perimeter would prevent external attacks. However, it’s not clear what impact this may have on operations. Your best option is to test and deploy the update.

-       CVE-2023-23384 – Microsoft SQL Server Remote Code Execution Vulnerability
This is a silent patch released by Microsoft in February and is just now being documented. The problem of silent patching has already been well documented, so I won’t rehash it here. The patch fixes an OOB Write bug in the SQLcmd tool that could allow a remote, unauthenticated attacker to exploit code with elevated privileges. While not listed in the CVSS, the attack complexity seems high since the attacker can only control a few bytes at a time. A server crash is much more likely. If you’re running SQL server, read the Cumulative Update table to ensure you have both the February and April updates installed.

-       CVE-2013-3900 – WinVerifyTrust Signature Validation Vulnerability
That’s no mistake on the CVE number – this is a 10-year-old patch being reissued. And if this bug sounds familiar, it’s because it was used by a threat actor in the recent 3CX attacks. This was an “opt-in” fix in the past, meaning admins had to opt-in to get this fix. With this revision, add fixes for additional platforms and adds further recommendations for enterprises. Definitely take the time to review all of the recommendations, including the information on the Microsoft Trusted Root Program, and take the actions needed to protect your environment.

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

CVE Title Severity CVSS Public Exploited Type
CVE-2023-28252 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2023-28231 DHCP Server Service Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-28219 Layer 2 Tunneling Protocol Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2023-28220 Layer 2 Tunneling Protocol Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2023-21554 Microsoft Message Queuing Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-28291 Raw Image Extension Remote Code Execution Vulnerability Critical 8.4 No No RCE
CVE-2023-28232 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability Critical 7.5 No No RCE
CVE-2023-28250 Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-28260 .NET DLL Hijacking Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28312 Azure Machine Learning Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-28300 Azure Service Connector Security Feature Bypass Vulnerability Important 7.5 No No SFB
CVE-2023-24860 Microsoft Defender Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28309 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 7.6 No No XSS
CVE-2023-28314 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 6.1 No No XSS
CVE-2023-28313 Microsoft Dynamics 365 Customer Voice Cross-Site Scripting Vulnerability Important 6.1 No No XSS
CVE-2023-21769 Microsoft Message Queuing Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28302 Microsoft Message Queuing Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28285 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-24883 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-24884 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24885 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24886 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24887 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24924 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24925 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24926 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24927 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24928 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24929 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-28243 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-28287 Microsoft Publisher Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28295 Microsoft Publisher Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28288 Microsoft SharePoint Server Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2023-23375 Microsoft SQL Server Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-23384 Microsoft SQL Server Remote Code Execution Vulnerability Important 7.3 No No RCE
CVE-2023-28304 Microsoft SQL Server Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28275 Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-28311 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28268 Netlogon RPC Elevation of Privilege Vulnerability Important 8.1 No No EoP
CVE-2023-28292 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28267 Remote Desktop Protocol Client Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-21729 Remote Procedure Call Runtime Information Disclosure Vulnerability Important 4.3 No No Info
CVE-2023-21727 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-24893 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28262 Visual Studio Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28263 Visual Studio Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-28296 Visual Studio Remote Code Execution Vulnerability Important 8.4 No No RCE
CVE-2023-28299 Visual Studio Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2023-24914 Win32k Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-28223 Windows Domain Name Service Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28216 Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-28218 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-28227 Windows Bluetooth Driver Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2023-28249 Windows Boot Manager Security Feature Bypass Vulnerability Important 6.6 No No SFB
CVE-2023-28269 Windows Boot Manager Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2023-28273 Windows Clip Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-28229 Windows CNG Key Isolation Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-28266 Windows Common Log File System Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-28277 Windows DNS Server Information Disclosure Vulnerability Important 4.9 No No Info
CVE-2023-28254 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2023-28255 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28256 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28278 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28305 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28306 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28307 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28308 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-28226 Windows Enroll Engine Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2023-28221 Windows Error Reporting Service Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-24912 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28276 Windows Group Policy Security Feature Bypass Vulnerability Important 4.4 No No SFB
CVE-2023-28238 Windows Internet Key Exchange (IKE) Protocol Extensions Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2023-28244 Windows Kerberos Elevation of Privilege Vulnerability Important 8.1 No No EoP
CVE-2023-28298 Windows Kernel Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2023-28222 Windows Kernel Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2023-28236 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28248 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28272 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28293 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28253 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-28271 Windows Kernel Memory Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-28237 Windows Kernel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28235 Windows Lock Screen Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2023-28270 Windows Lock Screen Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2023-28217 Windows Network Address Translation (NAT) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28247 Windows Network File System Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2023-28240 Windows Network Load Balancing Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-28225 Windows NTLM Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28224 Windows Point-to-Point Protocol over Ethernet (PPPoE) Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2023-28246 Windows Registry Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28297 Windows Remote Procedure Call Service (RPCSS) Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2023-24931 Windows Secure Channel Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28233 Windows Secure Channel Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28234 Windows Secure Channel Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28241 Windows Secure Socket Tunneling Protocol (SSTP) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-28228 Windows Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2023-28274 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-28284 * Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability Moderate 4.3 No No SFB
CVE-2023-24935 * Microsoft Edge (Chromium-based) Spoofing Vulnerability Low N/A No No Spoofing
CVE-2023-28301 * Microsoft Edge (Chromium-based) Tampering Vulnerability Low 4.2 No No Tampering

* Indicates this CVE had been released prior to today.

 

Looking at the remaining Critical-rated patches, there’s another CVSS 9.8 bug in Pragmatic General Multicast (PGM) that’s similar to the MSMQ bug already discussed. However, this bug is listed as not exploitable as the Messaging Queue vulnerability. There’s a bug in the DHCP server, but it may not be as severe as it initially seems. It requires a network adjacent attacker to send an affected DHCP server a specially crafted RPC call. DHCP is not a routable protocol (or a secure one), so external threat actors can’t take advantage of this vulnerability. There are a couple of Critical-rated bugs in the Layer 2 Tunneling Protocol and the Point-to-Point Tunneling Protocol. We’ve seen plenty of similar bugs receive fixes over the last few months, but none have ever been reported as being exploited in the wild. The final Critical-rated bug impacts the Raw Image Extension. Viewing a specially-crafted file could allow code execution.

Moving on to the other code execution bugs, the first thing that jumps out are the 11 different patches for the PostScript and PCL6 Class Printer driver. It seems printers will continue to be a security issue for Microsoft for some time to come. There are also eight patches for DNS server to go along with the one already mentioned. These are less severe as they require the attacker to have elevated privileges. There’s a fix for RPC Runtime, but the description is confusing. While the CVSS state low permissions are needed, the description states an unauthenticated attacker could exploit this bug. There’s a patch for the Internet Key Exchange (IKE) protocol, but it requires the IKE and AuthIP IPsec Keying Modules to be running. Note that disabling either of these will adversely impact IPSec functionality, so if you are running these, patch rather than disable services. There’s an RCE bug in the Network Load Balancer that leave it open to network adjacent attackers. In this case, it’s recommended to upgrade to the newer Software Load Balancing service, which is listed as not affected. The Bluetooth component receives a patch that would require an attacker to be in close physical proximity to a target. Most of the remaining patches fix open-and-own bugs, including a rare Windows kernel RCE. Most kernel bugs are privilege escalations, so it’s interesting to see a RCE bug in the component.

There are roughly half as many elevation of privilege (EoP) patches as there are RCE patches, and the vast majority of these require an authenticated user to run specially crafted code to elevate to SYSTEM. There are a couple of exceptions worth noting. Both the Kerberos and the Netlogon RPC bugs require a man-in-the-middle (MiTM) attacker. The Kerberos bug could lead to a downgrade of a client's encryption to the RC4-md4 cypher. An attacker could use this to compromise the user's Kerberos session key to elevate privileges. Similarly, an MiTM attacker could intercept Netlogon RPC messages to modify Netlogon protocol traffic to elevate their privileges.  

Seven different security feature bypass (SFB) bugs receive patches this month, and this continues the trend of increasing SFB bugs in each release. The first in the Azure Service Connector could allow attackers to bypass internal firewall restrictions. There are two different bugs in the Lock Screen that could allow it to by bypassed, but both of these would require physical access. That’s the same for the two bugs in the Windows Boot Manager. The bug in Group Policy is interesting as it would prevent an admin from updating group policies under certain circumstances. The patch for the Windows Enroll Engine fixes a bug that could bypass certificate validation during the account enrollment process. The final SFB bug is in the Driver Revocation List. As the name would imply, the bypass allows an attacker to modify the revocation list, thus allowing drivers to load that are otherwise banned. 

Moving on to the information disclosure bugs receiving fixes this month, and almost all of them simply result in info leaks consisting of unspecified memory contents. While this may be useful when chaining bugs for an exploit, they aren’t very interesting on their own. The lone exception this month is the info disclosure bug in the Azure Machine Learning component. An attacker could use this bug to read (but not modify) system logs. Instead of a patch, you will need to upgrade your instance of Azure Machine Learning Compute to address the vulnerability.

There are three spoofing-related fixes in the April release. The first is in SharePoint and was reported by ZDI vulnerability researcher Piotr Bazydło. The bug allows a low-privileged attacker with site creation permissions to perform an NTLM relay exploit on affected SharePoint servers. There’s no real information on what the spoofing bugs in Visual Studio and Windows could lead to, but Microsoft does note the Windows spoofing bug require a target user to open a specially-crafted HTML application (HTA) file designed to appear as a signed Windows Imaging Format (WIM) file.

Looking at the denial-of-service (DoS) fixes for April, most of these have no additional information or documentation from Microsoft. The bugs in the Windows Secure Channel only impact devices running TLS version 1.3. The bug in the Network Address Translation (NAT) service is limited to attacker traffic inside the NAT firewall. Finally, the DoS bug in Microsoft Defender may already be remediated on your systems as the Malware Protection Engine is updated frequently. However, if you are in an isolated environment, you will need to manually apply the fix. Also note that Microsoft says the patch also includes “defense-in-depth updates to help improve security-related features,” but doesn’t document what those changes may be.

Finally, there are three cross-site scripting (XSS) bugs in Dynamics 365, which breaks the streak of five XSS bugs in Dynamics seen in the last two months. That’s we call a combo breaker.

No new advisories were released this month.

Looking Ahead

The next Patch Tuesday will be on May 9, and we’ll return with details and patch analysis then. Be sure to catch the Patch Report webcast on our YouTube channel. It should be posted in just a few hours. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

CVE-2022-29844: A Classic Buffer Overflow on the Western Digital My Cloud Pro Series PR4100

This post covers an exploit chain demonstrated by Luca Moro (@johncool__) during Pwn2Own Toronto 2022. At the contest, he used a classic buffer overflow to gain code execution on the My Cloud Pro Series PR4100 Network Attached Storage (NAS) device. He also displayed a nifty message on the device. Luca’s successful entry earned him $40,000 and 4 points towards Master of Pwn. All Pwn2Own entries are accompanied by a full whitepaper describing the vulnerabilities being used and how they were exploited. The following blog is an excerpt from that whitepaper detailing CVE-2022-29844 with minimal modifications.


Prior to being patched by Western Digital, a memory corruption vulnerability existed in the FTP service of the My Cloud Pro Series PR4100. It allowed unauthenticated attackers to read arbitrary files and, in certain cases, write them. This vulnerability could allow the full compromise of the NAS and gives remote command execution capabilities.

The exploitation requires the FTP service to be activated. While the ability to read arbitrary files is always possible, writing needs at least one share to be “Public” and accessible via FTP. Such setting is the default configuration when a share is made available on FTP, so it should be a common case.

Here is Network Services panel showing FTP Access enabled:

Figure 1 - Network Services Panel

Here is the control panel for configuring FTP shares. Note that the needed settings are enabled by default when sharing a folder via FTP.

Figure 2 - Control panel dialog for setting up FTP shares

Technical Analysis

The issue was discovered by reverse engineering the firmware and source code auditing. The firmware used during this event can be downloaded here. The archive can be carved to extract a SquashFS filesystem. The GPL source code and the modifications made by Western Digital can be downloaded here.

The FTP service used by the NAS is based on the Pure-FTPd open source implementation with a few custom patches made by Western Digital. After extracting the GPL tar archive, one can find the custom modification in the WDMyCloud_PR4100_GPL_v5.24.108_20220826/open-source-packages/pure-ftpd/pure-ftpd-1.0.47/patch/ path within the archive listed above.

To apply the WD patches, run the following commands:

One of the modifications concerns the function douser(), which is called when a user issues the ftp command “user ” in order to log in. In the next code example, the content pointed by the argument const char \*username is user controlled.

We can spot a buffer overflow vulnerability in the first strncpy. When username is larger than 2048 bytes an overwrite occurs after auth_name which is located in the .bss section. The overwritten data is fully controlled by the user. The only requirement is that the data should not contain any NULL bytes beside the finishing one.

Here are some of the relevant global variables located after auth_name:

The global variable loggedin is especially useful as it represents whether a user was authenticated. The string wd is also valuable as it represents the path of the working directory. By overwriting and abusing both of these variables, it is possible to achieve an arbitrary file read and write by using the FTP commands cwd, retr, and stor.

Exploitation

Given the previous analysis, the overall strategy for getting command execution would be to read or write an arbitrary file in order to install a backdoor served by the NAS webserver.

The first step would be to find a way to authenticate without valid credentials. This section explains how to do so given the vulnerability.

Then, to read or write a file, it seems reasonable to try to use the FTP features and commands. This would require changing the current working directory of the FTP session by using the command “cwd ”. This step needs some attention because of various access control checks detailed in this section. After a better understanding on how “cwd” is implemented, we will see how the exploit manage to achieve a file read and write.

Step One: The Authentication Bypass

As expected, the attacker does not have any credential on the NAS. Moreover, we must assume the FTP service is not accessible to anonymous user. Therefore, it is necessary to find a way to bypass the authentication.

Usually, authentication is achieved in two ftp commands:

         -- 'user ': This specifies the username we want to use to log on. It is implemented in douser().
         -- 'pass ': This gives the password for the previous username. This is implemented in dopass().

It is worth mentioning that without first authenticating, it is impossible to use other FTP commands to fetch or store files.

A simplified description of the dopass() implementation is to check the user password and set the global variable loggedin to 1 and eventually to use setuid() to change the user ID of the running process.

As previously seen, the vulnerability allows the attacker to overflow the variable loggedin. It is possible to make the server think that the user has already logged in by issuing only a malicious user command with a name long enough so that loggedin becomes something other than 0, which is sufficient.

One side effect is that the process will not use setuid() so the user root will remain the user of the running process. This will have some consequences later.

Step Two: Access control

An Overview of the implementation

Before retrieving or storing files, we need to change the current working directory of the FTP session by using the cwd path command. This command handling is implemented by the function docwd(), which was patched by Western Digital to include access control checks. Here are some of the relevant parts:

The main access control check revolves around the call to check_allowed(wd_tmp, allowed), where wd_tmp is the concatenation of the global string wd and the user-controlled argument dir. The general idea is that check_allowed() returns something greater than 0 if the user is allowed to enter the directory.

In a similar fashion, the function check_allowed() is called when the user tries to read (retr) or write a file (stor). To provide some additional detail, check_allowed() is specific to Western Digital and is implemented in the closed source /wd/usr/lib/libftp_allow.so as seen in the example below:

This function checks whether the current user (using getuid() and getpwuid()) has access to the required path. The function relies on the Get_Share_Permission() function to determine the permissions over a path representing a share.

We can sum up the check_allowed() method as follows:

         -- If the path is /, then check_allowed() returns 1, which means the path is readable.
         -- If path looks like /<some_path>, then check_allowed() returns the value of Get_Share_Permission(some_path, pw_name).
         -- Otherwise, check_allowed() returns its second argument perm, which is the global variable allowed that was passed along in the call docwd().

The last case is interesting because it means that for paths that do not start with /, no check is really enforced. Indeed, in that case, the access control check only relies on the global variable allowed. This in peculiar will be used later.

The Get_Share_Permission() function is also closed source and specific to Western Digital. Because of this, we won’t dig deeper here. The gist of that function is that it opens the file /etc/NAS_CFG/ftp.xml, which specifies the authorizations on the share.

The Get_Share_Permission() function returns 1 for readable shares for a given username and 2 for readable and writable files and 0 for other states. The file /etc/NAS_CFG/ftp.xml maps the user’s permissions and is an image of what is configured in the “Shares” tab of the administration web page. Here is an example of this file:

In that example, Get_Share_Permission() would:

         -- return 2 for the path “share1” for any account.
         -- return 2 for the path “share2” for the account user2.
         -- return 1 for the path “share2” for the account admin.
         -- return 0 for the path “share2” for all other accounts.

In our context with the previous authentication bypass, the user that is being passed to the Get_Share_Permission() function is root. This may seem ideal, but it is not in the context of the access control. That is because root is different than the default administrator account, which is admin. Additionally, the user root does not makes sense in the ACL context. Consequently, it is likely that Get_Share_Permission() does not give permission to our user root.

That being said, in the previous example, “share1” would still return 2 (making it writable) for the user root. That is because of the parameter #@allaccount# appearing in its write_list. This is because share1 represents a share configured as “Public” (see Figure 1 above). This means that everyone with valid credentials can access this share via FTP. In fact, this is the default configuration for FTP shares.

Please note that Public in this context is a different concept than anonymous access since you would still require a username and password to write or read anything on share1. In that sense, it is fair to expect some kind of security for Public shares.

Step Three: Reaching Arbitrary Directories to Read or Write

At this point, we already bypassed the FTP authentication, but we cannot yet use the cwd command on an arbitrary directory as the check_allowed() function is preventing that command for most folders that are not a Share. For example, we cannot reach the /etc/ directory.

As seen earlier, check_allowed() is called with the variable wd_tmp (path) and allowed (int). Additionally, when the user given path dir does not start with '/', the content of wd_tmp is the concatenation of the global path wd and dir. This is interesting because using the vulnerability, we can rewrite wd_tmp. To summarize, the path argument of check_allowed() can be fully chosen by the attacker.

Using the peculiarities of the check_allowed() function with the control of the first argument, the following strategy allows reaching arbitrary folders with write access:

  1. Use the user vulnerability to rewrite loggedin and bypass authentication.
  2. Use cwd share1, which is writable by root. Therefore, this sets allowed to 2.
  3. Use the user vulnerability to rewrite and erase wd so that wd_tmp[0] == 0. As explained previously, this will prevent check_allowed() from checking anything and forces it to return its second argument (allowed).
  4. Use cwd to any path without starting slash (e.g., etc/). Because of the previous step, this will be allowed, and the server will think that the user has write permissions to the folder.

After that, it is possible to use the stor command to achieve an arbitrary file write. In accordance with the FTP protocol, this command is to be preceded by a port command so that the server will connect to the client on the given port (FTP active mode).

However, there is one limitation with the previous strategy. The attacker must know a valid and writable (i.e., Public) share name. One way to get around this is to first obtain an arbitrary file read capability in order to read the /etc/NAS_CFG/ftp.xml file. With the contents of that file, the attacker can find valid share names to use in the write strategy.

By noticing that the check_allowed() function always returns 1 when called with / as path, we can construct a similar strategy to achieve arbitrary file read:

  1. Use the user vulnerability to rewrite loggedin and bypass the authentication.
  2. Use the cwd / command, which is always “readable”, therefore setting allowed to 1.
  3. Use the user vulnerability to rewrite and erase wd_tmp so that wd_tmp[0] == 0. As explained previously, this will prevent check_allowed() from checking anything. It will return its second argument (allowed).
  4. Use the cwd command to any path without starting slash (for example etc/NAS_CFG/). Because of the previous step, this will be allowed, and the server will think that the user has read permissions on the folder.

After that, it is possible to use the retr command to achieve an arbitrary file read. Here again, one must use the port command per FTP standards.

To summarize, the vulnerability is used to rewrite a global stored path in order to control an argument of check_allowed(). This allows the attacker to circumvent the check and force check_allowed() to return the value of its previous invocation, stored in the value allowed. By using the cwd command in a valid directory then using this attack, it is possible to reach any folder with the permissions of the valid directory. Since the root directory (/) is readable, we can reach /etc/NAS_CFG/ with read permissions to get a read access to the ftp.xml file and learn a writable directory name. From there, we apply the same strategy to access any location with writable permissions.

Getting Remote Code Execution

At that point, we have both arbitrary file read and write access on the NAS. It is the time to investigate getting remote code execution (RCE).

It is worth mentioning that an arbitrary file read might be sufficient to achieve command execution of a sort. For instance, one might find ways to steal user passwords, session cookies, or other secrets stored on the filesystem. However, getting RCE with the file write is easier and only adds a small requirement since FTP shares are Public by default. Therefore, the exploit uses the file write technique, though we know that RCE might be possible without it.

The command execution is achieved in a couple of steps. To begin, a PHP web shell is uploaded to /var/www/cmd.php. This makes the web server serve the url /cmd.php and executes the GET argument cmd. While this might be sufficient, a proper reverse Python shell is uploaded in /tmp/python_shell.py and is executed thanks to the web shell. The Python shell connects back to the attacker device and provides a root shell.

Conclusion

This vulnerability was patched by Western Digital in firmware version 5.26.119 and assigned CVE-2022-29844. Based on the writeup from the vendor, the vulnerability was addressed by correcting the memory corruption condition that could allow an attacker to read and write arbitrary files. During the Pwn2Own contest, Luca was able to demonstrate success both with a reverse shell and a special light show on the device:


Thanks again to Luca Moro for providing this write-up and for his participation in Pwn2Own Toronto. He has participated in multiple events, 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.

TP-Link WAN-side Vulnerability CVE-2023-1389 Added to the Mirai Botnet Arsenal

Last week, the Zero Day Initiative (ZDI) threat-hunting team observed new exploit attempts coming from our telemetry system in Eastern Europe indicating that the Mirai botnet has updated its arsenal to include CVE-2023-1389, also known as ZDI-CAN-19557/ZDI-23-451. This bug in the TP-Link Archer AX21 Wi-Fi router was originally disclosed to ZDI during the Pwn2Own Toronto event, where it was used by Team Viettel in their LAN-side entry against the TP-Link device and by Qrious Security in their WAN-side entry. 

Both teams’ entries were successful at the contest, and the vulnerabilities were disclosed to the vendor. Interestingly, the bug was also used by the Tenable team in their unsuccessful Pwn2Own attempt against the device. They, too, disclosed the bug to TP-Link, but their public report did not show that the bug could be exploited on the WAN interface. TP-Link released a firmware update in March that “Fixed some security issues” – including this and other CVEs. It was after this fix was made public that exploit attempts using this CVE were detected in the wild.

Vulnerability Details 

The bug itself is an unauthenticated command injection vulnerability in the locale API available via the web management interface. This endpoint allows a user to specify the form we want to call by specifying the query string form along with an operation, which is usually read or write. In this instance, we are interested in the write operation on the country form, which is handled by the set_country function. This function will call merge_config_by_country that concatenates the specified country field into a command string. This command string will be executed using the popen function. There is no sanitization of the country field, so an attacker can achieve command injection at this point.

This functionality is exposed on the LAN side of the router, as evidenced by both Team Viettel and Tenable targeting this functionality at the contest. However, the team from Qrious Security was able to exploit this vulnerability on the WAN interface of the router. They discovered a race condition issue related to iptable handling on the TP-Link’s WAN-side processing that would briefly expose this functionality on the WAN-side. This allowed them to chain the race condition weakness with the locale API command injection to gain code execution at the contest. According to TP-Link, both issues were resolved in the patch released on March 17.

Active Exploitation Details

Starting on April 11th, we began seeing notifications from our telemetry system that a threat actor had started to publicly exploit this vulnerability. You can see an example of the attack here:

Most of the initial activity was seen attacking devices in Eastern Europe, but we are now observing detections in other locations around the globe.

Mirai Payloads

In this version of Mirai, the attackers utilize CVE-2023-1389 to make an HTTP request to the Mirai command and control (C2) servers to download and execute a series of binary payloads. These binary payloads are intended for various system architectures. This is one such request:

The binary payloads are downloaded and then executed using brute-force methodology to find the appropriate payload for the target system architecture.

Once the appropriate binary is found and the payload is installed, the host becomes fully infected and establishes a connection with the Mirai C2. Here’s a network trace showing this connection:

While analyzing some of the payloads, we determined that the threat actors are encrypting strings using 0x00 and 0x22 as XOR keys. Unencrypting these strings revealed some of the capabilities and configuration details that correspond with known Mirai indicators.

Part of the plaintext configuration reveals the Mirai bot attack functions, which can be found in Mirai’s source code. For example:

Among the interesting functions is a TSource Engine Query attack functionality. This can be used to launch a Valve Source Engine (VSE) distributed denial-of-service (DDoS) attack against game servers.

The unencrypted strings reveal further configuration details about this Mirai bot. These include specific User-Agent strings and server headers, such as cloudflare-nginx and dosarrest. These allow the bot to imitate legitimate traffic, making it more difficult to separate DDoS traffic from legitimate network traffic.

Indicators of compromise

The following hashes and other data were detected as being used by this exploit:
Initial Downloader
888f4a852642ce70197f77e213456ea2b3cfca4a592b94647827ca45adf2a5b8

Payloads
b43a8a56c10ba17ddd6fa9a8ce10ab264c6495b82a38620e9d54d66ec8677b0c
b45142a2d59d16991a38ea0a112078a6ce42c9e2ee28a74fb2ce7e1edf15dce3
366ddbaa36791cdb99cf7104b0914a258f0c373a94f6cf869f946c7799d5e2c6
413e977ae7d359e2ea7fe32db73fa007ee97ee1e9e3c3f0b4163b100b3ec87c2
2d0c8ab6c71743af8667c7318a6d8e16c144ace8df59a681a0a7d48affc05599
4cb8c90d1e1b2d725c2c1366700f11584f5697c9ef50d79e00f7dd2008e989a0
461f59a84ccb4805c4bbd37093df6e8791cdf1151b2746c46678dfe9f89ac79d
aed078d3e65b5ff4dd4067ae30da5f3a96c87ec23ec5be44fc85b543c179b777
0d404a27c2f511ea7f4adb8aa150f787b2b1ff36c1b67923d6d1c90179033915
eca42235a41dbd60615d91d564c91933b9903af2ef3f8356ec4cfff2880a2f19
3f427eda4d4e18fb192d585fca1490389a1b5f796f88e7ebf3eceec51018ef4d
aaf446e4e7bfc05a33c8d9e5acf56b1c7e95f2d919b98151ff2db327c333f089
4f53eb7fbfa5b68cad3a0850b570cbbcb2d4864e62b5bf0492b54bde2bdbe44b

URLs
http[://]185[.]225[.]74[.]251/armv4l
http[://]185[.]225[.]74[.]251/armv5l
http[://]185[.]225[.]74[.]251/armv6l
http[://]185[.]225[.]74[.]251/armv7l
http[://]185[.]225[.]74[.]251/mips
http[://]185[.]225[.]74[.]251/mipsel
http[://]185[.]225[.]74[.]251/sh4
http[://]185[.]225[.]74[.]251/x86_64
http[://]185[.]225[.]74[.]251/i686
http[://]185[.]225[.]74[.]251/i586
http[://]185[.]225[.]74[.]251/arc
http[://]185[.]225[.]74[.]251/m68k
http[://]185[.]225[.]74[.]251/sparc

Domain
zvub[.]us

IP Address
185[.]225[.]74[.]251

Conclusion

Seeing this CVE being exploited so quickly after the patch being released is a clear demonstration of the decreasing “time-to-exploit" speed that we continue to see across the industry. That said, this is nothing new for the maintainers of the Mirai botnet, who are known for quickly exploiting IoT devices to maintain their foothold in an enterprise. Looking back at this CVE, it was also interesting to see it being discovered independently by multiple teams in preparation for the Pwn2Own Toronto contest. Each team used different techniques to discover this vulnerability along with distinctive approaches to how they went about exploiting it. We would like to thank all the teams at the Pwn2Own contest for finding and disclosing these critical-class issues. It truly demonstrates the value of the contest, especially in the realm of home and small office devices. Finally, we would like to acknowledge the efforts TP-Link exhibited in developing and deploying a patch. Applying this patch is the only recommended action to address this vulnerability, and we recommend all users of the TP-Link Archer AX21 Wi-Fi router apply it as soon as possible.

Our threat hunting team continues to seek and find exploits being used in the wild, and we’ll publish details on some of these discoveries in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

CVE-2023-28231: RCE in the Microsoft Windows DHCPv6 Service

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Windows DHCPv6 Service. This bug was originally discovered by YanZiShuang@BigCJTeam of cyberkl. The vulnerability results from the improper processing of DHCPv6 Relay-forward messages. A network-adjacent attacker can leverage this vulnerability to execute code in the context of the DHCP service. The following is a portion of their write-up covering CVE-2023-28231, with a few minimal modifications.


A heap-based buffer overflow has been reported in Microsoft DHCPv6 Server. The vulnerability is due to improper processing of DHCPv6 Relay-forward messages. A remote attacker can exploit this vulnerability by sending crafted DHCPv6 Relay-forward messages to the target server. Successful exploitation could result in the execution of arbitrary code with administrative privileges.

The DHCPv6 Protocol

The Dynamic Host Configuration Protocol (DHCP) protocol is used to centrally manage and automate the assignment of IP addresses on a network. DHCPv6 is the Dynamic Host Configuration Protocol for IPv6. Although IPv6's stateless address auto-configuration can also be used to acquire an IPv6 address, DHCPv6 may be a more suitable solution to assign addresses, name servers and other configuration information that are configured with DHCP for IPv4.

DHCPv6 uses UDP on ports 547 and 546 for communication. The DHCPv6 protocol is described in RFC 8415. A typical DHCPv6 transaction consists of several DHCPv6 messages exchanged between the client and the server:

Briefly, the way DHCPv6 work is as follows: before a client obtains an IPv6 address, it sends a Solicit message to the link-scoped multicast address to find a DHCPv6 server. For the DHCPv6 protocol, the value of the link- scoped multicast address is "FF02::1:2". Any DHCPv6 server on the local network may respond with an Advertise message. If the client selects the DHCPv6 server, it sends a Request message to get an IPv6 address and other configuration information. The server responds with a Reply message containing the IPv6 address and other configuration.

The general structure of DHCPv6 messages between clients and servers is shown below:

The msg-type field is DHCPv6 message identifier. The value of the msg-type field for Solicit, Advertise, Request, Renew, and Reply messages are 1, 2, 3, 5, and 7, respectively. The options field of a DHCPv6 message contains a sequence of option fields.

The general structure of an option field is as follows:

To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client's link will relay messages between the client and server. This relay agent acts as an intermediary to deliver DHCP messages between clients and servers. In certain configurations, there may be more than one relay agent between clients and servers, so a relay agent may send DHCP messages to another relay agent.

The general structure of messages between a relay agent and other relay agents and servers is shown below:

This format is shared by the two relay agent messages: Relay-forward and Relay-reply. Specifically, for Relay-forward messages, the msg-type field is set to RELAY-FORW (12) and the options field must include a Relay Message option. The Relay Message option has its option-code field set to OPTION_RELAY_MSG (9), and its option-data contains the received message.

The Vulnerability

A heap-based buffer overflow has been reported in Microsoft DHCPv6 Server. The vulnerability is due to improper processing of DHCPv6 Relay-forward messages. The DHCPv6 server runs as a svchost.exe service and follows the DHCPv6 protocol to supply IPv6 addresses for the network devices on the system. When the server receives a Relay-forward message, it is processed by the function ProcessRelayForwardMessage() within dhcpssvc.dll. This function initializes a 1664-byte heap buffer, which is an array of 32 structures of size 52 bytes for each nested Relay- forward message encountered. The function also initializes a counter used to count the number of nested Relay- forward messages encountered. While processing the outer Relay-forward message, each time a nested Relay- forward message is encountered within a Relay Message option, the array of structures is filled at the appropriate offset and the counter is incremented. However, no validation is done to ensure that the counter does not exceed the maximum expected number of hops, 32. Therefore, if more than 32 nested Relay-forward messages are included in a Relay-forward message, the function will write to an offset exceeding the size of the allocated buffer, resulting in a buffer overflow.

A remote attacker can exploit this vulnerability by sending crafted DHCPv6 Relay-forward messages containing more than 32 nested Relay-forward messages to the target server. Successful exploitation could result in the execution of arbitrary code. Since the service runs as NETWORK SERVICE, after a compromise, an attacker could escalate to SYSTEM.

Source Code Walkthrough

The following code snippet was taken from dhcpssvc.dll version 10.0.17763.3469. Comments added by Trend Micro have been highlighted.

From function ProcessRelayForwardMessage():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on UDP ports 546 and 547 and be capable of inspecting DHCPv6 packets on UDP port 547.

The general structure of DHCPv6 messages between clients and servers and the general structure of an option field is shown above. The general structure of messages between a relay agent and other relay agents and servers is also shown above.

If a DHCPv6 Relay-forward message is found, meaning the value of its msg-type field is 12, the detection device must iterate through each option present in the options field. For each option, if the option is of type Relay Message, meaning the value of its option-code field is 9, the detection device must parse its option-data field as a new message. If the total number of Relay-forward messages encountered is greater than 32, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Note that all multi-byte values are in network byte order.

Conclusion

Microsoft addressed this vulnerability in April 2023 and assigned the vulnerability CVE-2023-28231. While they state that exploitation is unlikely, we do have working Proof-of-Concept (PoC) code available. Microsoft provides no other workaround apart from applying the available fix. This is the only suggested action to address the vulnerability. While DHCP is not a routable protocol, it is still recommended to apply the update once tested.

Special thanks to Guy Lederfein and Lucas Miller 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.

The May 2023 Security Update Review

It’s patch Tuesday once again, and Adobe and Microsoft have released their monthly batch of security updates. Take a break from your regularly scheduled activities and join us as we review the details of the latest offerings from Microsoft and Adobe. If you’d rather watch the video recap, you can check out the Patch Report webcast on our YouTube channel.

Adobe Patches for May 2023

For May, Adobe released a single bulletin for Substance 3D Painter addressing 11 Critical-rated and 3 Important-rated vulnerabilities. All of these bugs were found and reported by ZDI vulnerability researcher Mat Powell. The most severe of these issues would allow an attacker to execute arbitrary code on an affected system if they can convince a user to open a specially-crafted file.

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 2023

This month, Microsoft released 38 new patches addressing CVEs in Microsoft Windows and Windows Components; Office and Office Components; Microsoft Edge (Chromium-based); SharePoint Server; Visual Studio; SysInternals; and Microsoft Teams. This is in addition to 11 CVEs in Chromium that were previously released for Edge and are now being documented in the Security Updates Guide.

A total of four of these bugs were submitted through the ZDI program. This includes three SharePoint fixes that were reported during the most recent Pwn2Own Vancouver competition. However, none of the other bugs reported at that event have yet to be addressed by Microsoft.

Of the new patches released today, seven are rated Critical and 31 are rated Important in severity. May tends to be a smaller month for fixes historically, but this month’s volume is the lowest since August 2021. However, considering just the number of ZDI cases waiting to be patched, this number is expected to rise in the coming months.

One of the new CVEs is listed as under active attack and two are listed as publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the one bug under active attack:

-       CVE-2023-29336 – Win32k Elevation of Privilege Vulnerability
This is the one bug listed as being under active attack at the time of release, and you must go all the way back to May of last year before you find a month where there wasn’t at least one Microsoft bug under active attack. This type of privilege escalation is usually combined with a code execution bug to spread malware. Considering this was reported by an AV company, that seems the likely scenario here. As always, Microsoft offers no information about how widespread these attacks may be.

-       CVE-2023-29325 – Windows OLE Remote Code Execution Vulnerability
While the title says OLE, when it comes to this bug, the real component to worry about is Outlook. This vulnerability allows an attacker to execute their code on an affected system by sending a specially crafted RTF e-mail. The Preview Pane is an attack vector, so a target doesn’t even need to read the crafted message. And while Outlook is the more likely exploit vector, other Office applications are also impacted. This is one of the publicly known bugs patched this month and has been widely discussed on Twitter. Although Microsoft offers some workarounds, it’s a better idea to test and deploy this update quickly.

-       CVE-2023-24941 – Windows Network File System Remote Code Execution Vulnerability
This bug has been given a CVSS of 9.8 and allows a remote, unauthenticated attacker to run arbitrary code on an affected system with elevated privileges. No user interaction is required. Another interesting thing about this vulnerability is that exists in NFS version 4.1 but not versions NFSv2.0 or NFSv3.0. You can mitigate this bug by downgrading to a previous version, but Microsoft warns that you should not use this mitigation unless you have the CVE-2022-26937 patch from May 2022 installed. The better idea is to test and deploy this month’s fix instead.

-       CVE-2023-24955 – Microsoft SharePoint Server Remote Code Execution Vulnerability
This bug was demonstrated by the STAR Labs team during Pwn2Own Vancouver and was part of a chain used to obtain code execution on the target server. While this specific bug requires authentication, during the contest, it was combined with an authentication bypass. This is what would happen in real-world scenarios as well. Although there are other SharePoint fixes being released this month, additional patches will be required to fully address what was disclosed. Hopefully, we’ll see the remaining Pwn2Own fixes in the coming months.

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

CVE Title Severity CVSS Public Exploited Type
CVE-2023-29336 Win32k Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2023-29325 Windows OLE Remote Code Execution Vulnerability Critical 8.1 Yes No RCE
CVE-2023-24932 Secure Boot Security Feature Bypass Vulnerability Important 6.7 Yes No SFB
CVE-2023-24955 Microsoft SharePoint Server Remote Code Execution Vulnerability Critical 7.2 No No RCE
CVE-2023-28283 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2023-29324 Windows MSHTML Platform Elevation of Privilege Vulnerability Critical 7.5 No No EoP
CVE-2023-24941 Windows Network File System Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-24943 Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-24903 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2023-29340 AV1 Video Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-29341 AV1 Video Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-29333 Microsoft Access Denial of Service Vulnerability Important 3.3 No No DoS
CVE-2023-29350 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2023-24953 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-29344 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-24954 Microsoft SharePoint Server Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-24950 Microsoft SharePoint Server Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2023-24881 Microsoft Teams Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-29335 Microsoft Word Security Feature Bypass Vulnerability Important 7.5 No No SFB
CVE-2023-24905 Remote Desktop Client Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28290 Remote Desktop Protocol Client Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-24942 Remote Procedure Call Runtime Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-24939 Server for NFS Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-29343 SysInternals Sysmon for Windows Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-29338 Visual Studio Code Information Disclosure Vulnerability Important 5 No No Info
CVE-2023-24902 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-24946 Windows Backup Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-24948 Windows Bluetooth Driver Elevation of Privilege Vulnerability Important 7.4 No No EoP
CVE-2023-24944 Windows Bluetooth Driver Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-24947 Windows Bluetooth Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-28251 Windows Driver Revocation List Security Feature Bypass Vulnerability Important 5.5 No No SFB
CVE-2023-24899 Windows Graphics Component Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-24904 Windows Installer Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2023-24945 Windows iSCSI Target Service Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-24949 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-24901 Windows NFS Portmapper Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2023-24900 Windows NTLM Security Support Provider Information Disclosure Vulnerability Important 5.9 No No Info
CVE-2023-24940 Windows Pragmatic General Multicast (PGM) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-24898 Windows SMB Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-29354 Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability Moderate 4.7 No No SFB
CVE-2023-2459 * Chromium: CVE-2023-2459 Inappropriate implementation in Prompts Medium N/A No No RCE
CVE-2023-2460 * Chromium: CVE-2023-2460 Insufficient validation of untrusted input in Extensions Medium N/A No No RCE
CVE-2023-2462 * Chromium: CVE-2023-2462 Inappropriate implementation in Prompts Medium N/A No No RCE
CVE-2023-2463 * Chromium: CVE-2023-2463 Inappropriate implementation in Full Screen Mode Medium N/A No No RCE
CVE-2023-2464 * Chromium: CVE-2023-2464 Inappropriate implementation in PictureInPicture Medium N/A No No RCE
CVE-2023-2465 * Chromium: CVE-2023-2465 Inappropriate implementation in CORS Medium N/A No No RCE
CVE-2023-2466 * Chromium: CVE-2023-2466 Inappropriate implementation in Prompts Low N/A No No RCE
CVE-2023-2467 * Chromium: CVE-2023-2467 Inappropriate implementation in Prompts Low N/A No No RCE
CVE-2023-2468 * Chromium: CVE-2023-2468 Inappropriate implementation in PictureInPicture Low N/A No No RCE

* Indicates this CVE had been released prior to today.

 

Looking at the remaining Critical-rated patches, there’s another CVSS 9.8 bug in Pragmatic General Multicast (PGM) that looks identical to PGM bug patched last month. This could indicate a failed patch or, more likely, a wide attack surface in PGM that is just starting to be explored. There are patches for Critical-rated bugs in the LDAP and SSTP protocols. Finally, there’s an intriguing bug in MSHTML that could allow a remote attacker to escalate to administrator privileges. Microsoft doesn’t provide details here, but they do note some level of privileges are required. As written, it reads as though an authenticated user could browse to a site and gain administrative rights. 

Moving on to the other code execution bugs fixed this month, there are the standard open-and-own bugs in Office products. There are a couple of fixes for the AV1 Video Extensions, which are not installed by default. These updates are available from the Windows Store, so if you’re in a disconnected environment, you’ll need to manually apply these fixes. The code execution bug in RDP is somewhat troubling, but it’s client not server, so that lessens the severity a bit. The bug in Bluetooth requires the attacker to be in close physical proximity. The final RCE patch for May fixes a bug in the NuGet package manager client. Microsoft provides no details on the attack scenario, but it’s likely a client would need to connect to a specially crafted .NET project to be exploited.

In addition to the two already mentioned, there are eight other elevation of privilege (EoP) bugs being fixed this month. Most of these require an authenticated user to run specially crafted code, resulting in code execution at the level of SYSTEM. Like the Bluetooth RCE, the EoP in Bluetooth requires close proximity. The bug in Windows Installer only allows an attacker to delete targeted files rather than escalate to SYSTEM.

There are four security feature bypass (SFB) vulnerabilities being patched this month, including a publicly known bypass of the Secure Boot feature. As is typical, Microsoft does not provide information on where this vulnerability is public, however, they do provide some additional information about some additional configuration guidance resulting from this change. The bypass in Word would allow attackers to evade Office Protected View. The fix for Edge addresses a bug that could allow an iFrame sandbox escape, but not a full browser sandbox escape. The bug in the Driver Revocation List would allow an attacker to bypass the revocation list feature by modifying it and thus impact the integrity of that list.

The May release contains eight fixes for information disclosure bugs, including a SharePoint bug that was disclosed as a part of Pwn2Own. It was another piece of the SharePoint exploit chain mentioned above. For the most part, the remaining info disclosure bugs merely result in info leaks consisting of unspecified memory contents. There are some notable exceptions. The info disclosure in RDP Client could allow the recovery of plaintext information from TLS-protected data. The vulnerability in Teams could allow an attacker to disclose various “sensitive data,” including a user's full trust token. Although not specified, it’s possible this token could be replayed to impersonate a user. The last info disclosure fix is for Visual Studio. This bug allows attackers to disclose NTLM hashes. Again, it’s possible these hashes could be passed to impersonate other users.

There are five fixes for denial-of-service (DoS) bugs in the release, and four of these are mostly unremarkable. The fifth, however, impacts only the hotpatch version of Windows Server 2022. It also impacts SMB over QUIC, which is a rather interesting VPN-like functionality for SMB. Apart from the DoS in Access, it’s unclear if any of these bugs blue screen the system or merely interrupt service operations. The bug in Access impacts the database connectivity but doesn’t fully deny service.

Finally, there is a spoofing bug in SharePoint receiving a patch this month. It was reported through the ZDI program by an anonymous researcher and could allow an authenticated attacker to cause the server to leak its NTLM hash. Any user on the SharePoint site has the needed permissions.

No new advisories were released this month, but there was a patch re-release of note. CVE-2022-26928 was re-released to add security updates for all affected versions of Microsoft Windows. Microsoft indicates these new updates are needed to “fully address” the bug, which sounds like the original fix from last year was incomplete. Regardless, ensure you don’t miss applying this update to your systems – again.

Looking Ahead

The next Patch Tuesday will be on June 13, and we’ll return with details and patch analysis then. Be sure to catch the Patch Report webcast on our YouTube channel. It should be posted in just a few hours. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

CVE-2023-20869/20870: Exploiting VMware Workstation at Pwn2Own Vancouver

This post covers an exploit chain demonstrated by Nguyễn Hoàng Thạch (@hi_im_d4rkn3ss) of STAR Labs SG Pte. Ltd. during the Pwn2Own Vancouver event in 2023. During the contest, he used an uninitialized variable bug and a stack-based buffer overflow in VMware to escalate from a guest OS to execute code on the underlying hypervisor. His successful demonstration earned him $80,000 and 8 points towards Master of Pwn. All Pwn2Own entries are accompanied by a full whitepaper describing the vulnerabilities being used and how they were exploited. The following blog is an excerpt from that whitepaper detailing CVE-2023-20869 and CVE-2023-20870 with minimal modifications.


Prior to being patched by VMware, a pair of vulnerabilities existed within the implementation of the virtual Bluetooth USB device inside VMware Workstation. During the event, the VMware version used was 17.0.1 build-21139696. An attacker could leverage these two bugs together to execute arbitrary code in the context of the hypervisor. To exploit this vulnerability, the attacker must have the ability to execute high-privileged code on the guest OS. Bluetooth functionality is also required, but this is enabled by default. These bugs were patched in late April with VMSA-2023-0008.

CVE-2023-20870 – The Uninitialized Variable Info Leak

In VMware Workstation, in the USB Controller setting, there is the “Share Bluetooth devices with the virtual machine” option. This is enabled by default. It allows guest OSes to use Bluetooth devices. This functionality is handled by the Vbluetooth component, which is implemented in the vmware-vmx.exe binary. The VBluetooth device information can be read by lsusb command (in Linux) as follows:

Each time a guest OS sends a USB Request Block (URB) request to the VBluetooth device, the function VUsbBluetooth_OpNewUrb() is invoked to allocate memory to read or write data. The following code snippet is the sub_140740EB0 function in vmware-vmx.exe:

This function returns a VUsbURB object. Data is stored in this object in the urb_data buffer. This buffer is allocated by the RBuf_New() function and assigned to urb_data at [1]. Note that the RBuf_New() function calls the malloc function to allocate memory, so the memory is uninitialized. Then, the URB data is handled by VUsbBluetooth_OpSubmitUrb() function. This code snippet is from the sub_140740F50 function in vmware-vmx.exe:

total_urb_len is the length of data the guest OS wants to read from or write to the URB. This value is controllable by the attacker. At [2], total_urb_len is assigned to urb->urb_actualsize without a check. Then, based on the endpoint type and URB packet, the corresponding function is invoked. Afterwards, urb->urb_actualsize is set again in the handler function, but only if the packet is valid. We can see in the VUsbBluetooth_OpSubmitUrb() function that if the urb_data->bRequest is an invalid opcode (checked at [3]), urb->urb_actualsize will not be set, and it will remain set to an attacker-controllable value.

Finally, the UHCI_UrbResponse() function is invoked to send data back to the guest. The following snippet is in the sub_1401F7C50 function in vmware-vmx.exe, corresponding to assembly code from address 0x1401F7CBF:

A maximum of urb->urb_actualsize bytes of data from the urb->urb_data buffer will be returned to the guest. Since an attacker could control the value of urb->urb_actualsize and the urb->urb_data buffer is uninitialized, the guest OS could read uninitialized data from the heap.

CVE-2023-20869 – The Stack-based Overflow

The VBluetooth device also implements an Service Discovery Protocol (SDP) feature. When a guest OS wants to send an SDP packet to a specific Bluetooth peer, it must initialize a L2CAP connection to this peer. This is done by sending an L2CAP_CMD_CONN_REQ packet to the L2CAP_SIGNALLING_CID channel with the Protocol/Service Multiplexer (PSM) field set to 0x1. The result is a newly created SDP socket. This socket is used when processing subsequent SDP operations.

The SDP protocol data unit (PDU) format is well explained here. When the host OS processes an SDP PDU from the guest, it invokes SDPData_ReadElement() to parse the PDU. Here’s a look at the SDPData_ReadElement() function from the sub_14083C1D0 function in vmware-vmx.exe:

The switch-case [1] is used to parse the data element size descriptor to determine the size of the raw data. Then this size is passed to SDPData_ReadRawInt() to parse the unsigned int at [2].

Here’s another code snippet. This one is from the sub_14083C570 function in vmware-vmx.exe. Since the PDU is submitted by the guest OS, an attacker can control the size argument, which leads to a possible stack buffer overflow at [3]/[4].

These bugs were combined at Pwn2Own Vancouver to pop calc on the target system. The exploit itself started in the guest OS while the calculator spawned on the host OS.


Thanks again to Nguyễn Hoàng Thạch for providing this write-up and for his participation in Pwn2Own Vancouver. He has participated in multiple Pwn2Own contests, 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.

Exploiting the Sonos One Speaker Three Different Ways: A Pwn2Own Toronto Highlight

During Pwn2Own Toronto 2022, three different teams successfully exploited the Sonos One Speaker. In total, $105,000 was awarded to the three teams, with the team of Toan Pham and Tri Dang from Qrious Secure winning $60,000 since their entry was first on the schedule. Part of Pwn2Own competitions involves a random drawing for order. Not only does the team selected first get the full award if they are successful, but the subsequent entries are also more likely to have bug collisions. That means if three teams show up with the same exploit, only the first one randomly selected will get full credit. That’s not exactly what happened during the event, but some bug collisions did occur. In fact, there were four unique bugs used by the three different teams. Let’s take a look at the vulnerabilities used during the contest and see which team used which bug.

CVE-2023-27354 – The Unique libsmb2 Info Leak

With three different teams targeting the Sonos speaker, it’s obviously a huge advantage to go first. The team from Qrious Secure was randomly selected to go first, and they successfully exploited the speaker using a two-bug chain. This first bug used was this info leak, and they ended up being the only team to use this particular bug during the contest.

On the speaker, there exists a daemon named anacapad that handles all Sonos-specific functions, including accessing music services, LED control, and audio playback. The vulnerability exists in the way anacapad handles SMBv2 replies from a server, specifically in the smb2_process_query_directory_fixed() function that processes query directory reply data. It does this by allocating an smb2_query_directory_reply struct and storing the result in the Protocol Data Unit (PDU) pdu->payload field. The function then extracts the output buffer offset and length from the query directory reply from the server:

The speaker then checks that the output buffer does not overlap with the query directory reply header. The offset here will later be used to calculate the IOV_OFFSET:

This will also be used at:

The output_buffer here will later be used to decode file information from that directory PDU response from the server in the smb2_decode_fileidfulldirectoryinformation field. However, it never checks if the offset is within the len of a PDU packet. This can be leveraged to perform an information leak by acting as a SMB server and sending a malformed PDU query directory response with a large offset. The client will decode the file information from an out-of-bounds (OOB) memory region and send that information back to the malicious SMB server as part of a filename. By manipulating the offset, the SMB server can determine libc and heap addresses on the client, which are useful for the next step of the exploit chain.

CVE-2023-27353 – The Other Infoleak

The libsmb2 bug wasn’t the only infoleak we saw during the contest. Two of the teams used CVE-2023-27533/ZDI-23-448 to kick off their exploit. This vulnerability resides in the /msprox endpoint, which serves as a proxy for Sonos Speaker array communication. It forwards the user-supplied SOAP request to other registered speakers. When a user sends a request to this endpoint, the request is handled by function sub_15DFA0(), which in turn calls sub_1C86C0(). The following code snippet is from sub_1C86C0 in the anacapad binary, corresponding to assembly code from address 0x1C876C:

The code fails to check the return value of snprintf() at [1], and later uses this value as the size of an outgoing HTTP header buffer at [2]. The team from STAR Labs used this bug by sending a crafted request that provides overly long parameters to the snprintf() function at [1]. In this way, the return value from snprintf() (request_len) exceeds the size of the request buffer, which is 0x1000 bytes. At [2], it calls ana_server_send_request() to send the contents of the request buffer, using request_len as the length. STAR Labs used this out-of-bounds read (OOBR) vulnerability to leak the address of the .text segment.

The DEVCORE Team took a slightly different route to achieve the same effect. Their exploit relied on acting like a rogue Sonos Speaker adjacent on the network to the target. This allowed them to reach the following code, which contains an out-of-bounds read vulnerability analogous to the one discussed above. The result is leakage of stack data right after the request_body buffer.

From address location 0x1C889C:

While they took different approaches, both teams arrived at the same vulnerable code and leaked the data needed to continue their exploit.

CVE-2023-27352 – Remote Code Execution Through libsmb2

Now that we have our info leaks established, let’s take a look at how two teams leveraged that information for code execution. Both the Qrious Secure and STAR Labs teams leveraged a use-after-free (UAF) bug in the libsmb2 library. Again, since Qrious Securewas randomly chosen to go first, they won the full $60,000 while the bug collision resulted in STAR Labs earning $22,500.

Sonos provides SMB functionality by incorporating the open-source libsmb2 library with a few modifications. It runs within the anacapad daemon and can be reached by unauthenticated users to play music via the smb2 shared directory.

smb2_closedir is implemented as below in libsmb2:

And smb2_lazy_readdir is implemented as follows:

The main function handling data returned from an SMB server is as follows:

The control flow proceeds as follows:

(1) smb2_lazy_readdir -> smb2_fetchfiles_async -> smb2_cmd_query_directory_async -> create pdu (PDU) with internal message_id (MID) -> add to wait_queue (3)

When the client receives data from a server (4), it will decode the header (5) and find the PDU via its message_id (6). The interesting thing is that smb2_fetchfiles_async() function adds the PDU to wait_queue, which then holds a callback to fetchfiles_cb() at (7). This callback keeps the dir structure within its private data (8). Before it finishes, it invokes dir->cb callback at (9).

Back to (6), in a normal scenario, the SMB server will return the data with the valid message_id as MID, and the callback will be triggered before dir is freed in close_dir at (2). However, if the server sends an invalid message_id (different from MID), the PDU will not be found and will still be alive in wait_queue. Should this occur, the PDU will keep holding on to the dir struct pointer. When (2) finishes, the dir pointer will be freed, and the PDU will be left holding a dangling pointer.

The next time the client tries to read data from the server, if we reply with a previously valid message_id of MID, the client will decode the data and find the corresponding PDU via that MID. This time the PDU’s callback fetchfiles_cb will be called, and at (4) it will access the dangling pointer. By reallocating the freed dir structure before fetchfiles_cb is called, we can control the value cb and thereby gain control of $PC by pointing cb to maliciously crafted data.

Combined with the memory address leak from CVE-2023-27354, this vulnerability can be used to achieve remote code execution.

The STAR Labs team took a different approach to hit the same vulnerability. As stated above, the speaker allows us to play media files remotely using SMB using libsmb2. One of the added functions to this library is smb2_lazy_readdir(). Here is how they triggered the bug.

        -- smb2_opendir() is called, which will return an smbdir (smb2dir structure).         -- smbdir is later passed into smb2_lazy_readdir() together with a custom callback function.

smb2_cmd_query_directory_async() receives a callback function with the following prototype and any user-defined structure (in this case smb2dir):

This function will then insert a pdu (smb2_pdu) into a request queue waiting to be handled. After a reply is received, the callback will be invoked with the received data. The Sonos device passes the smbdir structure as cb_data, then populates it inside the callback. This code snippet is in sub_109C0() function of the libsmb2.so.1 binary, corresponding to assembly code from address 0x10A04:

If wait_for_reply fails, meaning smb2_cmd_query_directory_async did not receive any valid response for its pdu, smb2_closedir is invoked to free thesmbdir object. Then smb2_disconnect_share function is called. However, during this process, a dangling pointer to smbdir is left in the request queue.

In smb2_disconnect_share, it calls wait_for_reply->smb2_service->smb2_service_fd->smb2_read_from_socket->smb2_read_data. In smb2_read_data, it uses smb2_find_pdu to retrieve the pdu based on the message_id of the response packet, which is controllable by the attacker. If our response specifies the message_id of the Query Directory pdu, smb2_find_pdu will return the smb2_cmd_query_directory_async’s pdu. Finally, when pdu->cb is invoked from z_query_directory_cb_109C0, the dangling pointer leads to $PC control.

Reclaiming the freed smb2dir object is accomplished by appending extra data onto the response packet from server. The client will allocate a buffer to store this extra padding data.

The exploit uses a modified impacket to implement a malicious smb server.

The exploit proceeds as follows.

  1. Send a command to the target device to add a new SMB share.
  2. Using a modified smb2QueryDirectory() function in the exploit’s impacket SMB server, return a malformed response to the client’s smb2_cmd_query_directory request, producing a dangling pointer.
  3. When the client calls smb2_disconnect_share function, it sends a disconnect tree request to server. Using a modified smb2TreeDisconnect function in the impacket SMB server, the exploit returns a Query Directory response with the message_id from step 2. Additionally, the exploit appends data to this response to reclaim the smb2dir object in the client.
  4. The exploit gains control of $PC via the overwritten smb2dir->cb pointer and uses ROP to get shell.

CVE-2023-27355 – Remote Code Execution via the MPEG-TS Parser

This remote code execution bug was used only by the DEVCORE team. Due to the random draw, this was the third attempt on the Sonos, which left them at a disadvantage as they were more likely to run into a bug collision. They did collide regarding their info leak, which we have already discussed above. However, the remote code execution portion of their exploit chain was unique and earned its own CVE.

While parsing a .ts audio file, the Sonos speaker does not check the length of the Adaptation field, which leads to a stack buffer overflow. The bug results from the ability to specify an arbitrary value to the afelen field. The speaker will then read the specified number of bytes into the payload buffer, smashing the stack.

From address: 0x406604

Since Sonos enables exploit mitigations, the attacker needs to leak some information first. During the contest, the DEVCORE entry first leaked the stack canary, stack address and program base address using the previously described CVE-2023-27353. Once they obtained those values, exploitation is straightforward. They used the MPEG-TS parser vulnerability to overwrite the return address and jump to the exec() wrapper.

As the #x19 and #x22 registers are also controllable by the exploit, the attacker can set these registers to a controllable stack buffer and execute arbitrary commands.

The end result was a successful demonstration during the contest, but due to the collision of CVE-2023-27353, the DEVCORE team didn’t win the full amount. Still, they earned $22,500 for being the third team to exploit the Sonos speaker during the event.

Wrapping Things Up 

It’s always interesting to see different teams reach similar conclusions when targeting a piece of software. It’s equally as interesting when they take completely different paths but still end up with the same result. In this example, we had three different teams use a various combination of three different bugs to get code execution on a Sonos speaker. In the end, we awarded these teams a total of $105,000 for their efforts. Situations like this also highlight how bug collisions can encourage more thorough and innovative research to avoid duplicate entries in the future. All three of these teams had participated in Pwn2Own before, and we certainly hope they return for future events.

Now that many of the bugs disclosed during Pwn2Own Toronto are patched, we’ll continue to disclose some of those details on this blog. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

CVE-2023-24941: Microsoft Network File System Remote Code Execution

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Quinton Crist, Guy Lederfein, and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the Microsoft Network File Service (NFS). This bug was originally discovered by Wei in Kunlun Lab with Cyber KunLun. The vulnerability is triggered when handling incoming NFSv4.1 calls containing utf8strings when the server is low on memory. A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted call to an affected server. The following is a portion of their write-up covering CVE-2023-24941, with a few minimal modifications.


A remote code execution vulnerability has been reported in Microsoft Network File System (NFS). The vulnerability is triggered when handling incoming NFSv4.1 calls.

The Vulnerability

Microsoft Windows ships with several network features, some of which can be used to communicate with non-Windows file shares. One of these modules is NFS.

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

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

In the NFS4 protocol, a utf8string is transferred in the following format:

A remote codes execution vulnerability has been reported in Microsoft Network File System. The vulnerability is triggered when handling incoming NFSv4.1 calls containing utf8strings when the server is low on memory. When a server is parsing a received string, a buffer is allocated to store the string data. The code does not properly handle the allocation failing, resulting in the null termination byte still being written to the end of an invalid buffer.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted call to the victim Network File System service. Successful exploitation of this vulnerability can result in remote code execution.

Source Code Walkthrough

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

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on ports 2049/TCP and 2049/UDP.

When ONC RPC messages are transferred over TCP, they are prepended with a Fragment header structure (as illustrated in the table above) that specifies the length of the message. This allows the receiver to distinguish multiple messages sent over a single TCP session. Other protocols such as UDP do not use this field. The vulnerable method XdrDecodeString can only trigger this vulnerability when called from Nfs4SvrXdrpDecode_STRING.

The following fields are parsed using Nfs4SvrXdrpDecode_STRING and are defined in RFC 3530:

The detection device should monitor the above fields in all NFS4 messages. Any valid field value could trigger this vulnerability, but an attacker would request a large buffer to increase the probability of the failed allocation happening during the string processing. String lengths greater than 0x1000 should be considered suspicious. If found, an attack exploiting this vulnerability is likely underway.

Note that the detection of strings larger than 0x1000 is based on the typical allowed limit of file path strings and can be adjusted higher or lower to account for various server configurations.

Conclusion

Microsoft patched this bug in May as CVE-2023-24941. In their write-up, they note that disabling NFSv4.1 and downgrading to NFSv2 or NFSv3 can be used as a temporary mitigation for this vulnerability. However, they also note that you should not employ this mitigation unless you have already installed CVE-2022-26937 from the May 2022 Windows security updates. The better option is to test and deploy the latest patch for NFSv1 to completely address this vulnerability.

Special thanks to Quinton Crist, Guy Lederfein, and Lucas Miller 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.

Adventures in Disclosure: When Reporting Bugs Goes Wrong

The Zero Day Initiative (ZDI) is the world’s largest vendor-agnostic bug bounty program. That means we purchase bug reports from independent security researchers around the world in Microsoft applications, Adobe, Cisco, Apple, IBM, Dell, Trend Micro, SCADA systems, etc. We don’t buy every bug report submitted, but we buy a lot of bugs. Of course, this means we disclose a lot of bugs. And not every disclosure goes according to plan.

Why Disclose at All?

This is a fine place to start. Why would anyone disclose a bug to a vendor – or anywhere for that matter? In our opinion – disclosure drives action. We hope that the action will be a vendor producing a patch. We hold vendors accountable for producing patches and will release public details if they fail to take action within a reasonable timeline. Wait – what action does this drive? To start, it provides defenders with information they can use to protect their unpatched systems. It also produces additional pressure on the vendor to produce a patch. Just look at this example. And behind the scenes, there are numerous examples of us telling a vendor we’ll 0day the case on Friday only for a patch to “appear” on Wednesday. Of course, not every patch released – scheduled or other otherwise – is of perfect quality. That’s one reason we announced special disclosure timelines for bugs resulting from faulty or incomplete patches. We want to drive the action of vendors producing real, effective defenses for the bug reports we send them.

Who Pays for All of This?

This is another area where there’s a lot of public confusion. Many people think the vendors pay us for the bug reports. I wish that were true. The simple fact is that the Trend Micro Zero Day Initiative pays 100% of the cost of the vulnerabilities we acquire. And we pay before we disclose a bug to the vendor, too. Some programs only pay out when a patch is made available. When people realize the ZDI pays for the bugs we purchase, their first question usually is, “Then how do you make money?” That’s the neat part – we don’t! We take the threat intelligence we gain through bug acquisition and add it to our internal research to develop virtual patches and better filters for Trend Micro products. We take no money from other vendors through our standard program. We do have some co-sponsors for Pwn2Own events. For example, Tesla has worked with us for several years, and they are the ones providing the actual Model 3 under test. However, most of other vendors have products under test that provide no funding at all. In fact, some even refuse to participate in receiving the bug reports even though we don’t ask for any funding or compensation. That was the case in Pwn2Own Toronto for one router vendor, and this is not a unique occurrence. We’ve had other vendors decline participation. We’ve even had a few that acted surprised when we e-mailed them bugs after the contest – even though they had participated in previous events. By the way, you don’t have to be in person to participate. We disclose over Teams/Zoom all the time, even if you’re less than a two hour drive from being in the room where it happens. It’s free real estate bug reports, so it’s always confusing to us as to why vendors don’t want free bugs, but here we are.

What’s the Problem with Disclosure?

Sometimes, there isn’t a problem. We reach out to a vendor’s PSIRT and report the bug. They acknowledge receipt and produce a patch within 120 days. They publish their advisory and let us know we can publish ours. Easy peasy lemon squeezy. Unfortunately, that’s not always the case. Sometimes it’s hardy tardy lemon party. Not every vendor has a “[email protected]” or “[email protected]” e-mail address. It can take some time to find the right place to notify. Not everyone is familiar with ZDI or what we do, so we get some interesting responses. We had one vendor CC their local FBI field office when replying to a bug report. I still don’t know what they expected the FBI to do. We’ve received threats responses from lawyers threatening all sorts of legal actions. We’ve been at this since 2005, so we’re aware of all the relevant laws (and have had some input on more than one of them). One odd problem we run in to is vendors not telling us when a patch is available. We buy lots of bugs and can’t track every step of every report. This means vendors will release a patch we don’t know about, or the advisories are paywalled, or they just choose to not involve us in the public disclosure at all. It isn’t until we inform them that we’re releasing a report as 0day that they tell us the bug was patched last month. The sad fact is that plenty of vendors do not have a robust and efficient sustained engineering program to handle bug reports, patch releases, and customer notification. In fact, it’s becoming increasingly rare to find a well-run PSIRT, and it’s something as an industry we should all be worried about.

Why Does It Have to Be So Hard?

Sustained engineering and running a PSIRT are not trivial. We know this. Many people on the ZDI team come from that world, so we intimately know the problems that can arise. But we have seen a disturbing trend over the last few years of companies disinvesting in these areas. We’ve already seen companies outsource support to third parties. Now, they are outsourcing PSIRT responsibilities as well. Even though many in our industry have seen this decline in quality occur, there have been no negative consequences to vendors who do not patch well. No one is losing market share due to bad patches. The insurance companies that are paying out ransomware fees aren’t chasing vendors for higher-quality fixes. There’s no legislation enacted to hold vendors accountable for poor disclosure practices. Quite frankly, this decline will likely continue until there are negative consequences.

If I Report a Bug, Do I Have to Do All of This?

If you report a bug to the ZDI, we handle the disclosure process entirely. We’ll keep you informed of course, but we handle all the interactions with the vendor. That’s one of the primary benefits of working with the ZDI (aside from us paying you cash). We find the e-mail address. We handle the questions from the vendor. We respond to requests for more info, or stack traces, or proof of concept, or (in rare cases) demonstration videos. Yes – we really had a vendor ask for a video. When necessary, we assign a CVE. We monitor releases as much as we can, and when the vendor informs us it’s fixed, we publish our advisory. You say want to publish a blog about the bug after the patch is available? No problem – just let us know ahead of time. We may even offer to host it for you. In other words, you’ve already done the hard part of finding the bug. Let us do the next hard part of disclosing the bug to the vendor.

Today I Learned…

Hopefully, this blog has educated you on something about our program. Maybe it reinforced something you already knew. Maybe you learned something new today. Hopefully, I was able to answer some questions you may have had about our program or disclosing bugs in general. Finding, disclosing, and fixing bugs are three different processes, and none of those processes are inconsequential. Here at the ZDI, we try to improve all three areas wherever we can. ZDI researchers find a multitude of bugs on their own – pretty much whenever they aren’t working on bugs submitted to the program. We disclose bugs at a wholesale rate. We might not get every one of these reports 100% right, but we get plenty of chances to get better. Finally, we work with any willing vendor to help them improve their response process. When they are willing to learn, we walk vendors through the PSIRT process and provide them guidance on what to expect since they may not understand how it works.

While these problems may not be something that affects you personally, they do have a negative impact on the industry at large. Exploits resulting from failed patches and variant vulnerabilities are being used in the wild. This isn’t an opinion – it’s based on data seen by our sensors and our competitors. And a lot of that starts with improving the disclosure process. We certainly will keep buying and disclosing bugs at a high rate. Hopefully, we can see some improvement in this process in the years to come.

Until then, be sure to follow us on TwitterMastodonLinkedIn, or Instagram for the latest updates from the ZDI. 

The June 2023 Security Update Review

It’s the second Tuesday of the month, which means Adobe and Microsoft have released their latest security patches. Take a break from your regularly scheduled activities and join us as we review the details of their latest advisories. If you’d rather watch the video recap, check out the Patch Report webcast on our YouTube channel.

Adobe Patches for June 2023

For June, Adobe released four patches addressing 18 CVEs in Adobe Commerce, Substance 3D Designer, Adobe Animate, and Experience Manager. The bug in Substance 3D Designer was found by ZDI researcher Mat Powell and could lead to arbitrary code execution when opening a specially crafted file. The patch for Commerce is the largest this month with a dozen total fixes. Most of these are Important or Moderate rated Security Feature Bypasses (SFB), but there is a lone Critical-rate code execution bug in there as well. The fix for Adobe Animate also addresses a lone code execution bug. The patch for Experience Manager fixes four bugs, but none are Critical. There are three Important-rated cross-site scripting (XSS) bugs getting fixes plus one more SFB.

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 2023

This month, Microsoft released 69 new patches addressing CVES in Microsoft Windows and Windows Components; Office and Office Components; Exchange Server; Microsoft Edge (Chromium-based); SharePoint Server; .NET and Visual Studio; Microsoft Teams; Azure DevOps; Microsoft Dynamics; and the Remote Desktop Client. This is in addition to 25 CVEs that were previously released by third parties and are now being documented in the Security Updates Guide.

A total of five of these bugs were submitted through the ZDI program. This includes fixes for some of the bugs submitted at the Pwn2Own Vancouver contest. The SharePoint and local privilege escalations should be addressed with these fixes. However, we’re still awaiting the fixes for the Teams bugs demonstrated during the competition.

Of the new patches released today, six are rated Critical, 62 are rated Important, and one is rated Moderate in severity. This volume of fixes is slighter larger than the typical number of fixes for June, but not extraordinarily so. July tends to be a larger month as it is the last patch Tuesday before the Black Hat USA conference. It will be interesting to see if this trend continues.

None of the CVEs released today are listed as being publicly known or under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with a familiar-looking bug in the Exchange Server:

-       CVE-2023-32031 – Microsoft Exchange Server Remote Code Execution Vulnerability
This vulnerability was discovered by ZDI researcher Piotr Bazydło and is a bypass of both CVE-2022-41082 and CVE-2023-21529. The former was listed as being under active exploit. The specific flaw exists within the Command class. The issue results from the lack of proper validation of user-supplied data, which can result in the deserialization of untrusted data. While this does require the attacker to have an account on the Exchange server, successful exploitation could lead to executing code with SYSTEM privileges.

-       CVE-2023-29357 – Microsoft SharePoint Server Elevation of Privilege Vulnerability
This bug was one of the bugs chained together during the Pwn2Own Vancouver contest held back in March. This particular bug was used to bypass authentication due to a flaw within the ValidateTokenIssuer method. Microsoft recommends enabling the AMSI feature to mitigate this vulnerability, but we have not tested the efficacy of this action. The best bet is to test and deploy the update as soon as possible.

-       CVE-2023-29363/32014/32015 – Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability
These three bugs look identical on paper, and all are listed as a CVSS 9.8. They allow a remote, unauthenticated attacker to execute code on an affected system where the message queuing service is running in a Pragmatic General Multicast (PGM) Server environment. This is the third month in a row for PGM to have a CVSS 9.8 bug addressed, and it’s beginning to be a bit of a theme. While not enabled by default, PGM isn’t an uncommon configuration. Let’s hope these bugs get fixed before any active exploitation starts.

-       CVE-2023-3079 – Chromium: CVE-2023-3079 Type Confusion in V8
This CVE shouldn’t be news to anyone as it was released by the Chrome team back on June 1. However, since it’s listed as being under active attack, I wanted to highlight it for anyone who may have missed it due to graduations, vacations, or other distractions. This is a type confusion bug in Chrome that could lead to code execution at the level of the logged-on user. It’s also the second type of confusion bug in Chrome actively exploited this year. Definitely make sure your Chromium-based browsers (including Edge) are up to date.

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

CVE Title Severity CVSS Public Exploited Type
CVE-2023-24897 .NET, .NET Framework, and Visual Studio Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2023-29357 Microsoft SharePoint Server Elevation of Privilege Vulnerability Critical 9.8 No No EoP
CVE-2023-32013 Windows Hyper-V Denial of Service Vulnerability Critical 6.5 No No DoS
CVE-2023-29363 Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-32014 Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-32015 Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-32030 .NET and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-32032 .NET and Visual Studio Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2023-33135 .NET and Visual Studio Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2023-33126 .NET and Visual Studio Remote Code Execution Vulnerability Important 7.3 No No RCE
CVE-2023-33128 .NET and Visual Studio Remote Code Execution Vulnerability Important 7.3 No No RCE
CVE-2023-29331 .NET Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-29326 .NET Framework Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-24895 .NET, .NET Framework, and Visual Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-27909 * AutoDesk: CVE-2023-27909 Out-Of-Bounds Write Vulnerability in Autodesk® FBX® SDK 2020 or prior Important 7.8 No No RCE
CVE-2023-27910 * AutoDesk: CVE-2023-27910 stack buffer overflow vulnerability in Autodesk® FBX® SDK 2020 or prior Important 7.8 No No RCE
CVE-2023-27911 * AutoDesk: CVE-2023-27911 Heap buffer overflow vulnerability in Autodesk® FBX® SDK 2020 or prior Important 7.8 No No RCE
CVE-2023-21565 Azure DevOps Server Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2023-21569 Azure DevOps Server Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2023-29355 DHCP Server Service Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2023-25652 * GitHub: CVE-2023-25652 "git apply --reject" partially-controlled arbitrary file write Important 7.5 No No N/A
CVE-2023-25815 * GitHub: CVE-2023-25815 Git looks for localized messages in an unprivileged place Important 3.3 No No N/A
CVE-2023-29007 * GitHub: CVE-2023-29007 Arbitrary configuration injection via `git submodule deinit` Important 7.8 No No N/A
CVE-2023-29011 * GitHub: CVE-2023-29011 The config file of `connect.exe` is susceptible to malicious placing Important 7.5 No No N/A
CVE-2023-29012 * GitHub: CVE-2023-29012 Git CMD erroneously executes `doskey.exe` in current directory, if it exists Important 7.2 No No N/A
CVE-2023-29367 iSCSI Target WMI Provider Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-24896 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 5.4 No No XSS
CVE-2023-33145 Microsoft Edge (Chromium-based) Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-32029 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-33133 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-33137 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-28310 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2023-32031 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-29373 Microsoft ODBC Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-33146 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-33140 Microsoft OneNote Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2023-33131 Microsoft Outlook Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2023-32017 Microsoft PostScript Printer Driver Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32024 Microsoft Power Apps Spoofing Vulnerability Important 3 No No Spoofing
CVE-2023-33129 Microsoft SharePoint Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33142 Microsoft SharePoint Server Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2023-33130 Microsoft SharePoint Server Spoofing Vulnerability Important 7.3 No No Spoofing
CVE-2023-33132 Microsoft SharePoint Server Spoofing Vulnerability Important 6.3 No No Spoofing
CVE-2023-29372 Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-29346 NTFS Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-29337 NuGet Client Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2023-29362 Remote Desktop Client Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-29369 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-29353 Sysinternals Process Monitor for Windows Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2023-33144 Visual Studio Code Spoofing Vulnerability Important 5 No No Spoofing
CVE-2023-33139 Visual Studio Information Disclosure Vulnerability Important 7.8 No No Info
CVE-2023-29359 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-29364 Windows Authentication Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-32010 Windows Bus Filter Driver Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-29361 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-32009 Windows Collaborative Translation Framework Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2023-32012 Windows Container Manager Service Elevation of Privilege Vulnerability Important 6.3 No No EoP
CVE-2023-24937 Windows CryptoAPI Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2023-24938 Windows CryptoAPI Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2023-32020 Windows DNS Spoofing Vulnerability Important 3.7 No No Spoofing
CVE-2023-29358 Windows GDI Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-29366 Windows Geolocation Service Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-29351 Windows Group Policy Elevation of Privilege Vulnerability Important 8.1 No No EoP
CVE-2023-32018 Windows Hello Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32016 Windows Installer Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-32011 Windows iSCSI Discovery Service Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-32019 Windows Kernel Information Disclosure Vulnerability Important 4.7 No No Info
CVE-2023-29365 Windows Media Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-29370 Windows Media Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-29352 Windows Remote Desktop Security Feature Bypass Vulnerability Important 6.5 No No SFB
CVE-2023-32008 Windows Resilient File System (ReFS) Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32022 Windows Server Service Security Feature Bypass Vulnerability Important 7.6 No No SFB
CVE-2023-32021 Windows SMB Witness Service Security Feature Bypass Vulnerability Important 7.1 No No SFB
CVE-2023-29368 Windows TCP/IP Driver Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-29360 Windows TPM Device Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-29371 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-33141 Yet Another Reverse Proxy (YARP) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-24936 .NET, .NET Framework, and Visual Studio Remote Code Execution Vulnerability Moderate 8.1 No No RCE
CVE-2023-33143 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Moderate 7.5 No No EoP
CVE-2023-29345 Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability Low 6.1 No No SFB
CVE-2023-3079 * Chromium: CVE-2023-3079 Type Confusion in V8 High N/A No Yes RCE
CVE-2023-2929 * Chromium: CVE-2023-2929 Out of bounds write in Swiftshader High N/A No No RCE
CVE-2023-2930 * Chromium: CVE-2023-2930 Use after free in Extensions High N/A No No RCE
CVE-2023-2931 * Chromium: CVE-2023-2931 Use after free in PDF High N/A No No RCE
CVE-2023-2932 * Chromium: CVE-2023-2932 Use after free in PDF High N/A No No RCE
CVE-2023-2933 * Chromium: CVE-2023-2933 Use after free in PDF High N/A No No RCE
CVE-2023-2934 * Chromium: CVE-2023-2934 Out of bounds memory access in Mojo High N/A No No RCE
CVE-2023-2935 * Chromium: CVE-2023-2935 Type Confusion in V8 High N/A No No RCE
CVE-2023-2936 * Chromium: CVE-2023-2936 Type Confusion in V8 High N/A No No RCE
CVE-2023-2937 * Chromium: CVE-2023-2937 Inappropriate implementation in Picture In Picture Medium N/A No No N/A
CVE-2023-2938 * Chromium: CVE-2023-2938 Inappropriate implementation in Picture In Picture Medium N/A No No N/A
CVE-2023-2939 * Chromium: CVE-2023-2939 Insufficient data validation in Installer Medium N/A No No N/A
CVE-2023-2940 * Chromium: CVE-2023-2940 Inappropriate implementation in Downloads Medium N/A No No N/A
CVE-2023-2941 * Chromium: CVE-2023-2941 Inappropriate implementation in Extensions API Low N/A No No N/A

* Indicates this CVE had been released prior to today.

There are only two other Critical-rated bugs in this month’s release. The first is in what appears to be all supported versions of .NET, .NET Framework, and Visual Studio. It’s an open-and-own sort of exploit, but guessing by the Critical rating, it appears there are no warning dialogs when opening the dodgy file. The final Critical-rated fix for June addresses a Denial-of-Service (DoS) bug in the Hyper-V server. The Critical rating here implies a guest OS could potentially shut down the host OS, or at least cause some form of a DoS condition.

Moving on to the other code execution bugs fixed this month, there are the standard complement of open-and-own bugs in Office components and services. There are also a few more RCE bugs in .NET, .NET Framework, and Visual Studio. This includes the lone Moderate-rated bug, which surprisingly still comes in at a CVSS of 8.1. It’s implied (but not stated) that there would be some warning dialog when opening a crafted XML, thus lowering the severity. There’s another bug in Exchange that allows network adjacent authenticated attackers to achieve RCE via a PowerShell remoting session. You rarely see RCE bugs with a physical component, but that’s the case for the vulnerability in the Windows Resilient File System (ReFS). An attacker could gain code execution either through mounting a specially crafted VHD or by inserting a malicious USB drive. There’s a fix for the RDP client, but since it requires connecting to a malicious RDP server, it’s not as concerning. That’s similar to the two bugs that require connecting to an attacker’s SQL server. The final code execution bug is in our old frenemy the PostScript Printer Driver. Again, a user would need to open a specially crafted file on an affected system to trigger the RCE.

Looking at the Elevation of Privilege (EoP) bugs receiving fixes this month, the vast majority require an attacker to run a specially crafted program on an affected system. In most cases, this leads to attackers running code at SYSTEM level. The EoP bugs in .NET and Visual Studio lead some different scenarios, such as gaining some understanding of the filesystem layout or gaining the rights of the user running an affected application. This Moderate-rated EoP in Edge could allow a browser sandbox escape.

The June release includes fixes for four security feature bypass (SFB) bugs, and two of these involve bypassing the check RPC procedure. They could allow the execution of RCE procedures that should otherwise be restricted when making calls to an SMB server. The bug in the RDP requires someone open a specially crafted file, but if they can convince the use to take that action, the attacker could bypass certificate or private key authentication when establishing a remote desktop protocol session. The final SFB patch is the Low-severity bug in Edge that could allow attackers to bypass the permissions dialog feature when clicking on a URL.

There’s an unusually large number of spoofing bugs receiving patches this month. There are two bugs in the Azure DevOps Server that could be exploited to gain data available to the current user. An attacker is able to manipulate DOM model of website adding/removing elements, with crafted script is able to do actions on ADO in current user context without user consent or awareness. There’s little detail provided about the SharePoint bugs, but spoofing in SharePoint generally equates to cross-site scripting (XSS). The bug in the Power Apps component almost acts like an information disclosure, as successful exploitation would allow the attacker to read information in the target’s browser associated with a vulnerable URL. Little detail is provided about the other spoofing bugs other than to say user interaction is required to trigger them.

There are only five patches addressing information disclosure bugs this month, and as usual, the majority result in info leaks consisting of unspecified memory contents. The two exceptions are for Edge and the DHCP service. The bug in the DHCP server could allow an attacker to learn the IP addresses pool information of affected systems. The Edge bug could disclose IDs, tokens, nonces, and other sensitive information when following malicious URLs. Considering how much is down in the browser these days, that information could prove quite useful to threat actors.

Looking at the remaining DoS fixes for June, the vast majority have no details. It’s not clear an attack would only impact the component or the entire system. The bugs in the CryptoAPI service may impact authentication actions, but that’s just speculation based on the component. Microsoft does specify the SharePoint bug only crashes the application. The bug in the Sysinternals Process Monitor likely only crashed the application. For that fix, you’ll need to access the Microsoft Store. If you have updates enabled, you should get it automatically. However, if you’re in a disconnected or otherwise isolated environment, you’ll need to get the Sysinternals MSIX package.

The June release is rounded out with a fix for a single XSS bug in Microsoft Dynamics 365.

No new advisories were released this month.

Looking Ahead

The next Patch Tuesday will be on July 11, and we’ll return with details and patch analysis then. Be sure to catch the Patch Report webcast on our YouTube channel. It should be posted in just a few hours. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

CVE-2022-31696: An Analysis of a VMware ESXi TCP Socket Keepalive Type Confusion LPE

Last year we published our patch gap analysis of ESXi’s TCP/IP stack, which is forked from FreeBSD 8.2. While our focus was mainly on missing FreeBSD patches in ESXi, we also came across a type confusion bug in code introduced by VMware. This blog post details a vulnerability I discovered in ESXi’s implementation of the setsockopt system call that could lead to a sandbox escape. The vulnerability was assigned CVE-2022-31696 and disclosed as part of the advisory VMSA-2022-003. Additionally, I also explore ESXi’s kernel heap allocator and weaknesses in existing kernel mitigations.

For information regarding the initial analysis of the TCP/IP kernel module, VMkernel debug symbols, and porting type information from FreeBSD to ESXi, it is recommend to read our earlier analysis.

Comparing setsockopt in FreeBSD vs ESXi

First, let’s take a look at how ESXi 6.7 build 19195723’s setsockopt implementation differs from that of FreeBSD. Of particular note are differences in the handling of the SO_KEEPALIVE socket option. This option enables keep-alive messages on connection-oriented sockets.

Figure 1 - FreeBSD 8.2 code (left) vs ESXi 6.7 19195723 IDA Pro decompiled code (right)

In BSD systems, the TCP timer functions are registered and executed through the callout facility. ESXi added code here to check if there is an active callout for the keep-alive, by calling tcp_timer_active. If so, it resets the TCP keepidle to a newer value using tcp_timer_activate. The keepidle value determines how long TCP should wait before sending out the first keep-alive probe.

Type confusion vulnerability in SO_KEEPALIVE handling

What’s the issue with this newly added code? To understand this better, let’s take another look at the decompiled code with type information added.

Figure 2 - Protocol PCB type casted without validation

The Internet PCB structure inpcb has a pointer inp_ppcb that can point to either a TCP PCB (tcpcb) or a UDP PCB (udpcb) structure depending on the protocol. The vulnerable code shown here always type casts the pointer to tcpcb irrespective of the socket type. If the SO_KEEPALIVE option is set for a UDP socket, inp_ppcb is a pointer to a udpcb structure, but here it is casted to tcpcb structure due to the lack of validation. When the code further accesses the tcp_timer structure variable t_timers at offset 0x20, the access is out of bounds because the udpcb structure is only 0x10 bytes in size.

Figure 3 - The Kernel Data Structures for TCP and UDP Protocol Control Blocks as seen in FreeBSD

Triggering the Vulnerable Code and PSOD

In order to trigger the vulnerable code path, we need to create a UDP socket and then manipulate the socket using the setsockopt system call. Specifically, it is necessary to set the SO_KEEPALIVE option. Since ESXi does not package any build tools, we must compile the PoC statically in a Linux machine and then transfer the binary to ESXi for execution. Running the PoC will immediately trigger the Purple Screen of Death (PSOD). To trigger the bug from a sandboxed process, an attacker must be able to invoke the setsockopt system call on an existing UDP socket descriptor or create a new one for that purpose. Below is the PoC to trigger the bug:

The resulting PSOD:

Figure 4 - ESXi PSOD on TCP Timers code when running the PoC

Kernel Debug Setup for ESXi

While ESXi supports a local VMkernel debugger, VMKDBG, which can be used to inspect the PSOD, it is not as flexible as GDB. The GDB setup detailed in Attacking VMware NSX (Slides 34 – 37 in the PDF) is an excellent reference for getting started with ESXi kernel debugging. In summary, we used the GDB stubs feature provided by VMware to debug ESXi running as a guest VM on Fusion. We also disabled kASLR for ease of debugging. Since the ESXi kernel modules have symbols, it is possible to use GDB’s add-symbol-file command to load symbol information given an executable file and its base address in memory. The module base address and the path information required for add-symbol-file can be fetched using the esxcfg-info command as seen below:

While the file path to the tcpip module can be seen in the output, there is no file path entry for the VMkernel module. The VMkernel module with symbol information is found as a gzip-compressed file k.b00 within the bootbank directory of ESXi. Alternatively, to obtain the VMkernel executable with not only symbols but also type information, one can download it from the VMware WorkBench. However, in this case, the VMware WorkBench does not have debug information for the version of ESXi currently under analysis.

Once the kernel modules are available and their base addresses are known, connect the debugger and run the PoC to trigger the crash. The exception triggered may not be caught by GDB. In that case, ESXi will continue running, executing the handler for Interrupt 13 - General Protection Fault (GP), which is responsible for collecting fault information and core dumps. Should this occur, wait for the PSOD and then hit “Control + C” (SIGINT) to break into GDB. In the debug session shown below, you can see the symbolized stack trace obtained using GDB’s add-symbol-file command. tcp_timer_active was the last function to be executed before calling the interrupt handler. Therefore, choose the relevant frame (12 in this case) and inspect the program state. The register RAX was found to be loaded with some garbage value, leading to an invalid memory access during the execution of the mov eax,DWORD PTR [rax+0x38] instruction.

Analyzing the Exploitability of the Type Confusion Bug

Since the debug setup with symbols is now ready, let’s take another look at the crash by setting breakpoints and stepping through the code. The tcpcb structure can be inspected during the call to tcp_timer_active function, which takes it as the first argument. However, the type information is still missing within GDB. As a workaround, it is possible to use the type information from the FreeBSD kernel for debugging ESXi’s tcpip kernel module. Though some of the structure definitions vary somewhat between the FreeBSD and ESXi TCP/IP stacks, they have substantial similarities. Once again, GDB’s add-symbol-file command comes in handy. To import all structure definitions, use the add-symbol-file command but with address set to 0. Similarly, type information for VMkernel can be imported from an older version of ESXi vmkernel-visor (6.7-14320388) available through the VMware WorkBench.

Unlike the previous debug session, where the crash happened when accessing a garbage pointer, this time the t_timers variable is pointing to NULL and will result in a NULL pointer dereference. To better understand this behavior, it is necessary to examine the heap allocator used by ESXi. After some analysis on the vmkernel-visor executable, it was noticed that ESXi’s kernel heap allocator is based on Doug Lea's Malloc:

In dlmalloc, the malloc chunk headers are 32 bytes in size. The structure definition is as follows:

Figure 5 - Chunk header of Doug Lea's Malloc

The prev_foot field holds the size of previous chunk if free, whereas the head field holds the size of the current chunk. In addition to the size, the head field also holds two flag bits: PINUSE_BIT and CINUSE_BIT. The PINUSE_BIT (lowest order bit) marks if the previous chunk is in use. The CINUSE_BIT (second lowest bit) marks if the current chunk is in use. The forward fd and backward bk pointer fields are used only when the chunk is free. Otherwise the chunk data starts immediately after the head field. Now, looking back at the memory pointed to by RDI, it can be inferred that it is the data region of a dlmalloc chunk of size 32 bytes, which can hold 16 bytes of data (the udpcb structure).

As explained above, when fetching the t_timers pointer from offset +0x20, it accesses data from the adjacent chunk. This is because the allocated udpcb structure is smaller than the offset of t_timers in the tcpcb structure. Since the adjacent chunk may hold unrelated data, its contents are unpredictable (unless greater care is taken to first groom the heap). That is why the PoC crash will sometimes manifest as a NULL pointer deference and sometimes as a different kind of invalid access. Here is what the access of t_timers looks like:

Figure 6 - State of heap memory during type confusion

Assuming control of the t_timers pointer, it is possible to corrupt arbitrary memory during the write operations within the callout_stop or callout_reset functions. Alternatively, if there is control over the memory pointed to by the t_timers pointer, it is possible to control the subsequent access of the tcp_timer structure. Specifically, tcp_timer contains a callout substructure scheduled for execution by tcp_timer_activate. By targeting the c_func function pointer we can gain control of the instruction pointer. Since ESXi does not support Supervisor Mode Access Prevention (SMAP), t_timers could in fact point to user space memory instead of controlled memory in kernel space.

Figure 7 - TCP timers and Callout data structures

Note that structures such as tcpcb, tcp_timer and callout in ESXi are slightly different from the corresponding structures in FreeBSD. By comparing the decompiled ESXi code against FreeBSD 8.2, I identified new structure elements and adjusted the offsets of existing fields. For example, some global variables in FreeBSD such as tcp_keepidle, tcp_keepintvl and tcp_keepcnt were turned into fields of the tcp_timer structure in ESXi. This can be recognized by analyzing the tcp_timer_keep callout function.

In addition to lack of support for SMAP, the kASLR of kernel modules was also found to be weak. While the text base address showed significant randomization, the data segment base address did not, with as little as 1 bit of entropy in some cases. Here are the load addresses of the tcpip kernel module across multiple reboots:

Patch Analysis

To understand the fix for the type confusion bug, a patch diff was performed against ESXi 6.7 Build 20497097 (now at end-of-life). Instead of setting up the newer version of ESXi, you can just download the relevant VIB (vSphere Installation Bundle) from the ESXi Patch Tracker. In the case of tcpip, the kernel module is found within the ESXi base system esx-base VIB. This information can be queried using the esxcli command:

The diff between tcpip kernel modules from build 19195723 and 20497097 revealed an additional check added to sosetopt function. The code now checks whether the socket protocol is IPPROTO_TCP before proceeding with TCP timers. There is no explicit check to prevent a raw socket from entering the code path, but inp_ppcb is initialized only for socket types SOCK_STREAM and SOCK_DGRAM but not for type SOCK_RAW. Therefore, the timer code is reachable only when the socket type is SOCK_STREAM and the protocol is IPPROTO_TCP.

Figure 8 - Vulnerable code (left) vs Fixed code (right)

Interestingly, in 2012, the Linux kernel fixed a very similar issue in the handling of RAW sockets - CVE-2012-6657 Kernel: net: guard tcp_set_keepalive against crash:

Figure 9 - Linux patch for CVE-2012-6657

Conclusion

Historically, kernel privilege escalation vulnerabilities in ESXi have not been frequently seen. ESXi has no login shell for low-privileged users, so that entry point is eliminated. On the other hand, user-mode daemons such as SLPD run with the highest privileges (i.e., superDom), so in the case of compromise of a daemon, there is no need for further escalation. For these reasons, ESXi kernel bugs have not been a popular topic of discussion, at least not publicly. However, the situation is changing. SLP is no longer enabled by default, and ESXi is now sandboxing more and more user-mode processes. This makes us believe ESXi kernel bugs will become important in the coming years. For anyone interested, I hope this blog post will give some ideas to get started on the topic, and I’ll continue blogging about any significant findings in the future. Until then, you can follow me @renorobertr and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

CVE-2023-20864: Remote Code Execution in VMware Aria Operations for Logs

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Jonathan Lein and Dusan Stevanovic of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in VMware Aria Operations for Logs (formerly vRealize). This bug was originally submitted to the ZDI program by an anonymous researcher. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of root. Similar bugs are reported as being exploited in the wild. The following is a portion of their write-up covering CVE-2023-20864, with a few minimal modifications.


An insecure deserialization vulnerability has been reported in VMware Aria Operations for Logs. The vulnerability is due to improper validation of user data in the InternalClusterController class. A remote unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation could result in arbitrary code execution under the security context of the root user.

The Vulnerability

VMware Aria Operations for Logs is a log management solution, formerly developed under the name vRealize Log Insight. It can be used to collect log files from remote machines to a central server for storage and processing. Administrators can then access a web-based user interface to create dashboards to visualize the data, create reports, and manage the log data. In addition to the web user interface, the application contains an API to manage the server. The API is accessible on port 9000/TCP through HTTP, or port 9543/TCP via HTTPS.

Aria Operations for Logs can be run as a stand-alone appliance running on a single node, or multiple instances can be configured together to run in a cluster. The APIs impacted by this vulnerability are designed to be used between two instances of Aria Operations for Logs during setup to add the application to the cluster. The API “applyMembership” is used by a server to send a request to join a cluster. If the primary server accepts the request to join the cluster, it will use the API “approveMembership” to send configuration data to the server needed to join the cluster, and the API “setToken” to send a token to apply to the server. The HTTP POST request body for each API call will contain a serialized Java object containing data to pass to the API. Each serialized object will have a different class, depending on which API it was sent to. Java allows the serialization of objects, enabling them to be represented as a compact and portable byte stream. This byte stream can then be transferred via the network and deserialized for use by the corresponding servlet or applet. The following example illustrates how a class is serialized and then later extracted:

All Java Objects that are serializable implement the Serializable interface. This interface enforces the writeObject() and readObject() methods, which are called when serializing and deserializing objects respectively. These methods can be modified to implement custom behavior during the serialization and deserialization of Java Objects. A serialized Java object begins with the following structure:

An insecure deserialization vulnerability has been reported in VMware Aria Operations for Logs. The vulnerability is due to improper validation of user data in multiple methods in the InternalClusterController class. Aria Operation for Logs defines three API functions in the file “routes” to assist in the management of clusters: “applyMembership”, “setToken”, and “approveMembership”. When the server receives a call to any of these APIs, a method corresponding to the API name will be called in the class InternalClusterController. Regardless of the API used, the method will first pass the body of the HTTP request to the method SerializationUtils.deserialize() as a byte array. The deserialize() method will then convert the byte array to a ByteArrayInputStream object and then pass it to deserialize() again. The method will then convert the user data to an ObjectInputStream object and call readObject() on it to deserialize it. After the user data has been deserialized, it will be passed to another method to finish handling the user’s request to the API. However, the serialized objects in the body of requests to the APIs are not validated before they are deserialized. A remote, unauthenticated attacker could exploit this vulnerability by sending an API request containing a crafted serialized object. Such a crafted object can be created with the ysoserial tool using the “CommonsBeanutils1” gadget chain. Successful exploitation could result in arbitrary code execution under the security context of the root user.

Source Code Walkthrough

The following code snippet was taken from VMware Aria Operation for Logs version 8.10.2. Comments have been added by Trend Micro researchers.

From /usr/lib/loginsight/application/lib/api-play-service_2.13-1.0.jar!routes:

From decompiled Java class /usr/lib/loginsight/application/lib/api-play-service_2.13-1.0.jar!controllers/InternalClusterController.class:

From decompiled Java class /usr/lib/loginsight/application/lib/lib/commons-lang3.jar!org/apache/commons/lang3/SerializationUtils.class:

From decompiled Java class /usr/lib/loginsight/application/lib/lib/commons-lang3-3.1.jar!org/apache/commons/lang3/SerializationUtils.class:

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on TCP ports 9000 and 9543. Note that traffic may be encrypted and will need to be decrypted prior to applying this detection guidance. The detection device must parse Java serialized objects in HTTP requests. Java allows the serialization of objects, enabling them to be represented as a compact and portable byte stream. This byte stream can then be transferred via the network and deserialized for use by the corresponding servlet or applet. A serialized Java object begins with the structure shown above.

The detection device must inspect incoming HTTP POST requests to the following URIs:

If found, the detection device must inspect the request body for a Java serialized object. The detection device can inspect the request for the magic bytes “\xac\xed” followed by a 2-byte stream version “\x00\x05” to find a serialized object. The detection device must then inspect the serialized object beginning at offset 0x04 and look for the following bytes, corresponding to TC_OBJECT, TC_CLASSDESC, and then the length of the Class Name, immediately followed by a Class Name depending on which API endpoint the request to going to:

If the Class Name in the serialized object in the request does not match the expected Class Name, the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway. Note that it is possible the expected class name for each API could change in future versions of the software.

Conclusion

VMware patched this bug in April with VMSA-2023-0007. To date, we have not seen any evidence this bug is being used in active attacks. However, similar bugs have reportedly been detected in the wild. It is recommended that Aria users test and deploy this update quickly.

Special thanks to Jonathan Lein and Dusan Stevanovic 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.

The July 2023 Security Update Review

It’s the second Tuesday of the month, which means Adobe and Microsoft have released their latest security patches. Take a break from your regularly scheduled activities and join us as we review the details of their latest advisories. If you’d rather watch the video recap, you can check it out here.

Apple Patches for July 2023

Apple doesn’t conform to “Patch Tuesday,” but they started things off yesterday with an emergency patch for macOS, iOS, and iPadOS. The bug in Webkit is labeled as CVE-2023-34750. Apple notes the vulnerability has been reported to be under active attack. Apple terms these emergency patches as “Rapid Security Response (RSR)” and reserves them for the most critical components where exploitation has been detected in the wild. Apple also notes this update is causing problems rendering certain websites. You should expect an update in the near future. I would anticipate this CVE to be patched on other supported macOS versions soon as well.

Adobe Patches for July 2023

For July, Adobe released two patches addressing 15 CVEs in Adobe InDesign and ColdFusion. The patch for ColdFusion is arguably more critical as it contains a CVSS 9.8-rated remote code execution bug. The bulletin also recommends reading (and implementing) the ColdFusion Lockdown guide and updating your ColdFusion JDK/JRE to the latest version of the LTS releases for JDK 17 where applicable. The fix for InDesign corrects one Critical and 11 Important rated bugs. The most sever of these could lead to code execution when opening a specially crafted file.

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 2023

This month, Microsoft released 130 new patches addressing CVES in Microsoft Windows and Windows Components; Office and Office Components; .NET and Visual Studio; Azure Active Directory and DevOps; Microsoft Dynamics; Printer Drivers; DNS Server; and Remote Desktop. One of these CVEs was reported through the ZDI program, but if you check out our upcoming page, you’ll find quite a few more awaiting resolution.

Of the new patches released today, nine are rated Critical and 121 are rated Important in severity. This volume of fixes is the highest we’ve seen in the last few years, although it’s not unusual to see Microsoft ship a large number of patches right before the Black Hat USA conference. It will be interesting to see if the August release, which comes the day before the Black Hat briefings, will also be a large release.

One of the CVEs released today is listed as being publicly known, but five(!) are listed as being under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the multiple bugs currently being exploited in the wild:

-       CVE-2023-36884 – Office and Windows HTML Remote Code Execution Vulnerability
Of the five active attacks receiving patches today, this is arguably the most severe. Microsoft states they are aware of targeted exploits using this bug in specially crafted Office documents to get code execution on targeted systems. For now, the keyword there is “targeted”. However, Microsoft has taken the odd action of releasing this CVE without a patch. That’s still to come. Their Threat Intelligence team has released this blog with some guidance. Oh, and Microsoft lists this as “Important”. I recommend treating it as Critical.

-       CVE-2023-35311 - Microsoft Outlook Security Feature Bypass Vulnerability
This bug is listed as being under active exploit, but as always, Microsoft provides no information on how broadly these attacks are spread. The bug allows attackers to bypass an Outlook Security Notice prompt after clicking a link. This is likely being paired with some other exploit designed to execute code when opening a file. Outlook should pop a warning dialog, but this vulnerability evades that user prompt. Considering how broadly Outlook is used, this should be your first priority for test and deployment.

-       CVE-2023-36874 - Windows Error Reporting Service Elevation of Privilege Vulnerability
This is the second bug listed as under active attack for July, but it doesn’t affect every user on a system. To elevate to administrative privileges, an attacker would need to have access to a user account with the ability to create folders and performance traces on the target system. Standard user accounts don’t have these permissions by default. Privilege escalations are often combined with code execution exploits to spread malware, and that’s likely the case here as well.

-       CVE-2023-32046 - Windows MSHTML Platform Elevation of Privilege Vulnerability
This is the final bug listed as being under active attack this month, but it’s not a straightforward privilege escalation. Instead of granting the attacker SYSTEM privileges, it only elevates to the level of the user running the affected application. Of course, many applications run with elevated privileges, so this point may be moot. It still requires a user to click a link or open a file, so remain wary of suspicious-looking attachments or messages.

-       CVE-2023-32049 - Windows SmartScreen Security Feature Bypass Vulnerability
The final exploited bug this month is in the SmartScreen filter. Similar to the Outlook SFB, the bug in SmartScreen allows attackers to evade warning dialog prompts. Again, a user would need to click a link or otherwise take an action to open a file for an attacker to use this. This is likely being paired with another exploit in the wild to take over a system or at least install some form of malware on a target.

-       CVE-2023-32057 - Microsoft Message Queuing Remote Code Execution Vulnerability
Not only is this tied for the highest-rated CVSS (9.8) bug this month, but it’s also nearly identical to a CVE patched back in April. It was even reported by the same researcher. That has all the hallmarks of a failed patch. Either way, this bug could allow unauthenticated remote attackers to execute code with elevated privileges on affected systems where the message queuing service is enabled. You can block TCP port 1801 as a mitigation, but the better choice is to test and deploy the update quickly. Let’s also hope the quality of this patch is higher than the last one.

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

CVE Title Severity CVSS Public Exploited Type
CVE-2023-36884 Office and Windows HTML Remote Code Execution Vulnerability Important 8.3 Yes Yes RCE
CVE-2023-35311 Microsoft Outlook Security Feature Bypass Vulnerability Important 8.8 No Yes SFB
CVE-2023-36874 Windows Error Reporting Service Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2023-32046 Windows MSHTML Platform Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2023-32049 Windows SmartScreen Security Feature Bypass Vulnerability Important 8.8 No Yes SFB
CVE-2023-32057 Microsoft Message Queuing Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-33157 Microsoft SharePoint Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-33160 Microsoft SharePoint Server Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-35315 Windows Layer-2 Bridge Network Driver Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-35297 Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability Critical 7.5 No No RCE
CVE-2023-35352 Windows Remote Desktop Security Feature Bypass Vulnerability Critical 7.5 No No SFB
CVE-2023-35365 Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-35366 Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-35367 Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-36871 Azure Active Directory Security Feature Bypass Vulnerability Important 6.5 No No SFB
CVE-2023-33127 .NET and Visual Studio Elevation of Privilege Vulnerability Important 8.1 No No EoP
CVE-2023-35348 Active Directory Federation Service Security Feature Bypass Vulnerability Important 7.5 No No SFB
CVE-2023-32055 Active Template Library Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2023-33170 ASP.NET Core Security Feature Bypass Vulnerability Important 8.1 No No SFB
CVE-2023-36869 Azure DevOps Server Spoofing Vulnerability Important 6.3 No No Spoofing
CVE-2023-35320 Connected User Experiences and Telemetry Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35353 Connected User Experiences and Telemetry Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-32084 HTTP.sys Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-35298 HTTP.sys Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-33152 Microsoft Access Remote Code Execution Vulnerability Important 7 No No RCE
CVE-2023-33156 Microsoft Defender Elevation of Privilege Vulnerability Important 6.3 No No EoP
CVE-2023-33171 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 6.1 No No XSS
CVE-2023-35335 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 8.2 No No XSS
CVE-2023-33162 Microsoft Excel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-33158 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-33161 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32083 Microsoft Failover Cluster Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-32033 Microsoft Failover Cluster Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-35333 Microsoft Media-Wiki Extensions Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2023-32044 Microsoft Message Queuing Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-32045 Microsoft Message Queuing Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-35309 Microsoft Message Queuing Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2023-32038 Microsoft ODBC Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-33148 Microsoft Office Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-33149 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-33150 Microsoft Office Security Feature Bypass Vulnerability Important 9.6 No No SFB
CVE-2023-33153 Microsoft Outlook Remote Code Execution Vulnerability Important 6.8 No No RCE
CVE-2023-33151 Microsoft Outlook Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2023-32039 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-32040 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-32085 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35296 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-35306 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35324 Microsoft PostScript and PCL6 Class Printer Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35302 Microsoft PostScript and PCL6 Class Printer Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-32052 Microsoft Power Apps Spoofing Vulnerability Important 6.3 No No Spoofing
CVE-2023-33134 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-33165 Microsoft SharePoint Server Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2023-33159 Microsoft SharePoint Server Spoofing Vulnerability Important 8.8 No No Spoofing
CVE-2023-35347 Microsoft Store Install Service Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2023-35312 Microsoft VOLSNAP.SYS Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2023-35373 Mono Authenticode Validation Spoofing Vulnerability Important 5.3 No No Spoofing
CVE-2023-32042 OLE Automation Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-32047 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35374 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32051 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32034 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-32035 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33164 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33166 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33167 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33168 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33169 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33172 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-33173 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35314 Remote Procedure Call Runtime Denial of Service Vulnerability Important 5.3 No No DoS
CVE-2023-35318 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35319 Remote Procedure Call Runtime Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35316 Remote Procedure Call Runtime Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-35300 Remote Procedure Call Runtime Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-35303 USB Audio Class System Driver Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-36867 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-32054 Volume Shadow Copy Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2023-36872 VP9 Video Extensions Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35337 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35350 Windows Active Directory Certificate Services (AD CS) Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2023-35351 Windows Active Directory Certificate Services (AD CS) Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-29347 Windows Admin Center Spoofing Vulnerability Important 8.7 No No Spoofing
CVE-2023-35329 Windows Authentication Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35326 Windows CDP User Components Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35362 Windows Clip Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-33155 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35340 Windows CNG Key Isolation Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35299 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35339 Windows CryptoAPI Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-33174 Windows Cryptographic Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35321 Windows Deployment Services Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35322 Windows Deployment Services Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-35310 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-35344 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-35345 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-35346 Windows DNS Server Remote Code Execution Vulnerability Important 6.6 No No RCE
CVE-2023-35330 Windows Extended Negotiation Denial of Service Vulnerability Important 6.2 No No DoS
CVE-2023-35343 Windows Geolocation Service Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35342 Windows Image Acquisition Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-32050 Windows Installer Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-32053 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35304 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35305 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35356 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35357 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35358 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35360 Windows Kernel Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-35361 Windows Kernel Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-35363 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35364 Windows Kernel Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2023-32037 Windows Layer-2 Bridge Network Driver Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-35331 Windows Local Security Authority (LSA) Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35341 Windows Media Information Disclosure Vulnerability Important 6.2 No No Info
CVE-2023-35308 Windows MSHTML Platform Security Feature Bypass Vulnerability Important 4.4 No No SFB
CVE-2023-35336 Windows MSHTML Platform Security Feature Bypass Vulnerability Important 6.5 No No SFB
CVE-2023-21526 Windows Netlogon Information Disclosure Vulnerability Important 7.4 No No Info
CVE-2023-33163 Windows Network Load Balancing Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2023-35323 Windows OLE Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35313 Windows Online Certificate Status Protocol (OCSP) SnapIn Remote Code Execution Vulnerability Important 6.7 No No RCE
CVE-2023-33154 Windows Partition Management Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35338 Windows Peer Name Resolution Protocol Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-35325 Windows Print Spooler Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2023-35332 Windows Remote Desktop Protocol Security Feature Bypass Important 6.8 No No SFB
CVE-2023-32043 Windows Remote Desktop Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2023-32056 Windows Server Update Service (WSUS) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35317 Windows Server Update Service (WSUS) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35328 Windows Transaction Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-32041 Windows Update Orchestrator Service Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-21756 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP

Looking at the other Critical-rated patches, the three bugs in the Routing and Remote Access Service (RRAS) stand out. All have a CVSS of 9.8 and allow a remote, unauthenticated attacker to execute code at the level of the service by merely sending a specially-crafted packet. That makes these bugs wormable – albeit only between systems with RRAS enabled. It’s not on by default. There are two patches for SharePoint server. Both require authentication, but the level required is the default for any regular SharePoint user. The bug in the Layer-2 Bridge Network Driver is really a guest-to-host code execution bug. Someone on a guest VM could execute code on the underlying host OS. The bug in PGM also has a network adjacent requirement and could be seen on VMs. The Security Feature Bypass (SFB) in Remote Desktop would allow an attacker to bypass certificate or private key authentication when establishing a remote desktop protocol session. Considering how much RDP is targeted by ransomware gangs, I would expect to see this incorporated into their toolkits.  

Looking at the remaining 24 remote code execution patches, many are the open-and-own variety in Office and Windows components. Of the others, everything old is new again. There’s a fix for the printer driver to remind us of PrintNightmare. There are more SharePoint RCEs, and like the ones previously mentioned, they do require authentication. There’s an RPC bug that’s reminiscent of RPC bugs from the early 2000s. There’s another Message Queueing patch, although this one doesn’t have the failed patch hallmarks of the one previously mentioned. There’s a fix for an Outlook RCE, but the Preview Pane is not an attack vector. There are four bugs in the DNS Server, but all require elevated privileges for exploitation. That’s the same for the two Active Directory Certificate Services (AD CS) vulnerabilities. An attacker would need Certificate Authority (CA) read access permissions, which are restricted to domain admins by default. Speaking of admin credentials, the bug in the Online Certificate Status Protocol (OCSP) SnapIn requires an attacker to compromise admin credentials. I’m a little surprised Microsoft chose to fix this as a security patch. The patch for Windows Deployment Services is interesting in that it requires no user interaction but it does require authentication. Finally, the bug in Network Load Balancing would allow RCE to unauthenticated attackers, but only if they are network adjacent.

Moving on to the Elevation of Privilege (EoP) bugs receiving patches this month, the vast majority require an attacker to run a specially crafted program on an affected system. In most cases, this leads to attackers running code at SYSTEM level. This includes 11 fixes for the kernel and Win32k. There’s a fix for Active Template Libraries (ATL) that personally makes me twitch, but I ran the case behind MS09-035 and the myriad of applications it affected. The EoP in .NET and Visual Studio would allow an attacker to elevate to the rights of the user running the application. That’s also true for the bug in Volume Shadow Copy. The bug in volsnap.sys could allow an attacker to elevate to administrator, which is different than SYSTEM, but just barely. The final EoP patch for July is in Office. It would allow an attacker to make RPC calls that are restricted to local clients only.

There are nine more SFB patches to go along with the two already mentioned. The bug in the Active Directory Federation Service is a bit of an odd one. An attacker could bypass the TPM by crafting an assertion and using the assertion to request a Primary Refresh Token from another device. That’s the same impact as the bug in Azure Active Directory. The Office bypass would allow attackers to escape Office Protected View, but not if you have Application Guard for Office enabled. The SFB bug in SharePoint would allow an attacker to bypass the logging of downloaded files. There are two SFB bugs in Remote Desktop. The first could allow a machine-in-the-middle (MitM) attacker to bypass the certificate validation performed when a targeted user connects to a trusted server. The other also requires a MitM attacker and could compromise the confidentiality and integrity of data when the targeted user connects to a trusted server. There are also two bugs in MSHTML. The first allows a bypass of the Mark of the Web (MotW) designator. The other allows attackers to access a URL in a less restricted Internet Security Zone than intended. No additional information is given regarding the SFB in ASP.NET.

The July release contains 18 total information disclosure fixes. Fortunately, the majority of these merely result in info leaks consisting of unspecified memory contents. The lone exception is a frightening one. The bug in NetLogin could allow an attacker to intercept and potentially modify traffic between client and server systems. The attacker would need to be able to monitor traffic (i.e., MiTM) to exploit this vulnerability.

This month’s release contains 22 fixes for Denial-of-Service (DoS) bugs. A dozen of these vulnerabilities are in the RPC runtime library. Microsoft provides no details about these bugs other than to note authentication is required. That’s also true for the flaws in Windows Authentication and Deployment Services. The remaining DoS bugs do not require authentication, but again, no additional details from Microsoft are available. The lone exception is one of the vulnerabilities in HTTP.sys. In this case, Microsoft notes an unauthenticated attacker could send crafted messages utilizing the Server Name Indication (SNI) to an affected system.

There are a half dozen spoofing bugs in this month’s release, and the one in Outlook stands out the most. An exploit would require the target to click a link, but that’s all it takes to allow the disclosure of NetNTLMv2 hashes. Another interesting one is in Mono Authenticode Validation as it requires low privileges and no user interaction. However, Microsoft provides no real details on what an attack would look like. The other spoofing bugs all do require user interaction. Spoofing on SharePoint looks very much like cross-site scripting (XSS). The bug in Power Apps could be used either to retrieve cookies or present a fake dialog box to a user. The bug in Windows Admin Center requires extensive user interaction but could result in code execution. You’ll also need to manually install the latest build of the Windows Admin Center from here.

The July release is rounded out by two XSS bugs in Microsoft Dynamics 365.

There are two new advisories in this month’s release – the first advisories of 2023. The first provides guidance for Microsoft-signed drivers being used maliciously. This has been known since at least last December, so it’s nice something is coming out of Redmond to deal with it. The update in the advisory revokes the certificate for known impacted files. The other advisory provides guidance for an SFB in Trend Micro EFI modules. This is something we disclosed back in May.

Looking Ahead

The next Patch Tuesday will be on August 8, and we’ll return with details and patch analysis then. I’ll be blogging from Las Vegas while attending the Black Hat conference, so say hello if you see me. I like it when people say hello. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The SOHO Smashup Returns for Pwn2Own Toronto 2023

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

Our consumer-focus Pwn2Own event return to Toronto for 2023. The contest will be held at the Trend Micro office in Toronto on October 24-27. We had a great event last year, and we’re looking forward to another exciting contest. One of the things that made it so great was having so many of the competitors hanging out all day. We had so many fantastic discussions with talented researchers, and in-person attendance was key to that experience. While we are still allowing remote participation, we’ll be reimbursing up to $3,000 for travel expenses for former Pwn2Own winners that choose to come to Toronto to participate. We also will be able to host a limited audience for those who wish to attend and observe the contest, so look out for more information about that in the future.

If you can’t be in Toronto due to travel restrictions or travel safety concerns, you can opt to compete remotely. You will still need to register before the contest deadline (October 19, 2023) and submit your entry, a detailed whitepaper completely explaining your exploit chain, and instructions on how to run the entry by the end of the registration period. A member of the ZDI staff will run your exploit for you. All attempts will be filmed and available for viewing by the contestant and the vendor. As in the past, we will work with remote contestants to monitor the attempt in real-time via a phone call or video chat. Please note that since you are not in person, changes to exploits/scripts/etc. will not be possible, which could lower your chance of winning should something unexpected occur.

As for the contest itself, we’re pleased to announce the return of Synology as a co-sponsor of the event. We’re also excited to announce the return of the “SOHO Smashup” category, where the contestants must start on the external interface of a router, compromise the router, then pivot to another device connected to the network. Last year, the DEVCORE team was the first to succeed in this category by using two different stack-based buffer overflow attacks against a Mikrotik router and a Canon printer – winning $100,000 in the process. We’re also bringing cameras back into the contest under the surveillance category. You may notice we’ve eliminated the router category. We still want to find bugs in these devices, but we’re focusing on the WAN interface in the SOHO Smashup rather than just the LAN interface. Beyond that, the contest remains similar to the event we had last year. We awarded $989,750 during the 2022 event. We’ll see if we can eclipse $1,000,000 this year.

UPDATE: As of September 18, we’re happy to announce Google has also signed on to be a partner for this year’s event. We’ve worked with Google in the past on other Pwn2Own competitions, and we’re happy to include some of their products in a special “Google Devices” category.

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. Our intention with allowing remote participation is to provide as many people as possible with the benefits of participating in Pwn2Own while still treating all contestants as equally as possible. As always, 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
- The SOHO Smashup
- Surveilance Systems
- Home Automation Hubs
- Printers
- Smart Speakers
- NAS Devices
- Google Devices

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

The Target Phones

The original name for this event was “Mobile Pwn2Own” and our focus was strictly on phones. Mobile handsets remain at the heart of this event. As always, these phones will be running the latest version of their respective operating systems with all available updates installed. We’ve increased the rewards on these targets to add further incentives to these handsets.

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 will earn $300,000 for the iPhone and $250,000 for the Pixel.

Back to top

The SOHO Smashup

With many working from home, enterprises have found their network perimeter relocate 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, so we’re bringing back the SOHO Smashup category to show how this could happen. Contestants will need to first compromise the WAN port on a selected router. Once they accomplish that, 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, surveillance systems, 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. We’re hopeful multiple teams will use this category to choose their own (mis)adventure.

Back to top

Surveillance Systems

Cameras have become an everyday part of our world, with wireless cameras operating in homes, offices, and stores. Notwithstanding privacy questions, the security of these devices could prove a tempting treat for attackers. An attempt in this category must be launched against the target’s exposed network services or 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. Some of the most popular smart hubs are included in this year’s event.

Back to top

The Return of Printers

Exploits involving printers have made quite a bit of news over the last few years, with ransomware gangs incorporating PrintNightmare bugs in their exploit kits. During last year’s event, one printer ended up playing the theme to Mario. 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 Toronto has four targets available in this category.

Back to top

Network Attached Storage (NAS) Devices

NAS devices make their return to Pwn2Own, and both Synology and Western Digital have returned as targets. We’re also adding the TS-464 from QNAP to this group. An attempt in this category must be launched against the target’s exposed network services from the contestant’s laptop within the contest network.

Back to top

Google Devices

In addition to the added Google devices in the Surveillance and SOHO Smashup categories, we have a couple of extra targets specifically requested to be added by Google. 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

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 2024).

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 14 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 Toronto 2023 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. Eastern Daylight Time on October 19, 2023.

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 #P2OToronto hashtag for continuing coverage.

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

With special thanks to our Pwn2Own Toronto 2023 sponsors, Synology and Google, for providing their assistance and technology.

©2023 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.

CVE-2023-36934: Progress Software MOVEit Transfer SQL Injection Remote Code Execution Vulnerability

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in Progress MOVEit Transfer. This bug was originally discovered by Trend Micro Vulnerability Researcher Guy Lederfein and is the same type of vulnerability being used by the Cl0p ransomware gang to exfiltrate data. A crafted request can trigger the execution of SQL queries composed from a user-supplied string. An attacker can leverage this vulnerability to execute code in the context of the “moveitsvc” user. The following is a portion of their write-up covering CVE-2023-36934, with a few minimal modifications.


An SQL injection vulnerability has been reported for Progress MOVEit Transfer. This vulnerability is due to insufficient validation of encrypted query parameters sent to the server. A remote, unauthenticated attacker could exploit this vulnerability by sending crafted requests to the target server.

A successful attack would result in arbitrary SQL command execution against the database on the target server, which can lead to arbitrary code execution under the security context of the running service.

The Vulnerability

MOVEit provides collaboration and automated file transfers of sensitive data and advanced workflow automation capabilities without the need for scripting. Encryption and activity tracking enable compliance with regulations such as PCI, HIPAA, and GDPR. MOVEit can be accessed via an API or a web interface accessed over HTTPS.

MOVEit supports the encryption of sensitive HTTP query parameters when generating redirection URLs. For example, if a request is made to the “/human.aspx” endpoint over plaintext HTTP, the user is redirected to the HTTPS endpoint. To generate the redirected URL, method MakeEncryptedURLIfNec() of class MOVEit.DMZ.ClassLib.SILGlobals will encrypt all HTTP query parameters in the original request and set the encrypted value in the ep HTTP query parameter of the new redirected URL. When this redirected request is read by the server, method GetEncryptedQueryParameters() of class MOVEit.DMZ.ClassLib.SILGlobals decrypts the ep HTTP query parameter, and the decrypted parameters are set to the server's global variables.

In addition, some redirects call method SaveArgumentsToSessionForRedirect() of class MOVEit.DMZ.ClassLib.SILGlobals to save the global variables to the current session. These variables are stored in the sessionvars SQL table. When another request is made to the server with the HTTP cookie ASP.NET_SessionId set to the same session ID, the global variables will be loaded in method LoadArgumentsFromSessionIfNeeded() by reading them from the sessionvars table.

An SQL injection vulnerability exists within MOVEit Transfer. This vulnerability is due to insufficient validation of encrypted query parameters sent to the server.

As mentioned above, if a request is made to the “/human.aspx” endpoint over plaintext HTTP, the server will redirect to the HTTPS endpoint with all HTTP query strings in the original request encrypted in the ep HTTP query parameter. This allows generating arbitrary encrypted query strings. When another request is made to the “/human.aspx” endpoint with the ep HTTP query parameter set to the encrypted query string returned by the server from the initial request, the value will be decrypted and read in method GetEncryptedQueryParameters(). If the decrypted string contains the query string username, its value will be sanitized using the method SILUtility.XHTMLClean(), and then URL-decoded using the method HttpUtility.UrlDecode(). Note that due to the order of these operations, if the value contains a URL-encoded quote character (%27), it will not be sanitized by SILUtility.XHTMLClean() and will be successfully decoded to a quote character ('). This improperly sanitized variable is written to the SILGlobals.LoginName variable. If this request also contains an InitialPage HTTP cookie with a value matching the regular expression “[a-z0-9]+\.aspx”, the SILGlobals.LoginName variable will be saved to the sessionvars table with a session ID generated by the server and returned in the response.

If a subsequent call is made to the “/machine.aspx” endpoint with the same session ID, the SILGlobals.LoginName variable will be loaded by method LoadArgumentsFromSessionIfNeeded(). Later, the method ProcessPreAuthXMLRequest() of class MOVEit.DMZ.WebApp.SILMachine will be called. In case the SILGlobals.Transaction variable is set to “passchangerequest”, the method UserProcessPassChangeRequest() of class MOVEit.DMZ.ClassLib.UserEngine will be called with the value of the SILGlobals.LoginName variable set as the MyLoginName argument. In this method, the MyLoginName argument is used when building an SQL Select query using the MOVEit.DMZ.ClassLib.SQLBasicBuilder class. Specifically, the argument is concatenated to the query using the AddAndToWhere() method, which does not perform any sanitization on the argument, leading to SQL injection.

A remote, unauthenticated attacker could exploit this vulnerability by sending crafted requests to the target server. Specifically, an initial request can be made to the “/human.aspx” endpoint with a crafted URL-encoded value in the username HTTP query string. Another request can be made to the “/human.aspx” endpoint with the encrypted query strings returned in the first response set in the ep HTTP query parameter, and a “.aspx” page set in the InitialPage HTTP cookie, leading to the crafted username value being decrypted, URL-decoded, saved to the SILGlobals.LoginName variable, and saved to the sessionvars table. Finally, a request can be made to the “/machine.aspx” endpoint with the same session ID returned by the second response. This will lead to the crafted value being loaded from the sessionvars table and used in the vulnerable SQL query.

A successful attack would result in arbitrary SQL command execution against the database on the target server. This would allow an attacker to inject a session into the activesessions SQL table, allowing the attacker to authenticate as an arbitrary user. In addition, an arbitrary value may be set in the state field of the fileuploadinfo SQL table, which is decrypted and deserialized using BinaryFormatter. Setting this field to a crafted encrypted value would lead to insecure deserialization, which can lead to arbitrary code execution under the security context of the running service.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the ports used by MOVEit Transfer.

Note that traffic may be SSL/TLS encrypted and must be decrypted before applying the following guidance.

The detection device must monitor for HTTP requests to the MOVEit Transfer endpoint “/human.aspx”. If found, the detection device must parse the HTTP query parameters from the following URIs:

       -- Request-URI of the HTTP request
       -- An InitialPage HTTP cookie value (only applicable if the value matches the regular expression “[a-z0-9]+\.aspx”)

After parsing the query parameters from both sources, the detection device must search for the “username” query parameter name. If found, and the value of the query parameter contains a URL-encoded single quote character (%27), the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway.

Please also note the string matching of the “username” query parameter name, the “human.aspx” endpoint, and the “InitialPage” cookie name should be done in a case-insensitive manner.

Conclusion

Progress patched this vulnerability along with two others in early July 2023. As of now, we have not seen any evidence this bug is being used in active attacks. However, similar bugs have been used by ransomware gangs to exfiltrate data from targets. Progress offers no other mitigations other than applying the update. It is recommended that all MOVEit users test and deploy the patch as soon as possible.

Special thanks to Guy Lederfein and Lucas Miller 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.

Exploiting a Flaw in Bitmap Handling in Windows User-Mode Printer Drivers

In this guest blog from researcher Marcin Wiązowski, he details CVE-2023-21822 – a Use-After-Free (UAF) in win32kfull that could lead to a privilege escalation. The bug was reported through the ZDI program and later patched by Microsoft. Marcin has graciously provided this detailed write-up of the vulnerability, examines how it could be exploited, and a look at the patch Microsoft released to address the bug.


In the Windows kernel, there are three APIs intended for general use by device drivers for the purpose of creating bitmaps: EngCreateBitmap, EngCreateDeviceBitmap and EngCreateDeviceSurface. Each of these APIs return a bitmap handle. If the caller wants to perform some drawing operations on the bitmap, the caller must first lock the bitmap by passing its handle to EngLockSurface. EngLockSurface increases the bitmap’s reference counter and returns a pointer to a corresponding SURFOBJ record. SURFOBJ is a structure located in kernel memory containing all the information regarding the bitmap, such as the bitmap’s dimensions, pixel format, a pointer to the pixel buffer, and so forth. We’ll take a closer look at the SURFOBJ structure later. After calling EngLockSurface, the obtained SURFOBJ pointer can be passed to various drawing APIs such as EngLineTo and EngBitBlt. See winddi.h for the complete list of these drawing APIs. After the caller is finished with drawing operations, they should call EngUnlockSurface. At this point, the bitmap’s reference counter decreases to zero again, and the caller is no longer allowed to use the SURFOBJ pointer. Finally, the caller can delete the bitmap by calling EngDeleteSurface on its handle. Typical usage of these APIs is shown below:

All APIs discussed above are exported from win32k.sys kernel-mode module. Note, though, that the functions in win32k.sys are only wrappers, and the implementations are in win32kbase.sys and win32kfull.sys.

Many years ago, both display drivers and printer drivers worked in kernel mode, but since Windows Vista, printer drivers work only in user mode (hence User-Mode Printer Drivers, or UMPD). Two important facts emerge from this change:
       -- During printing operations, the kernel must now perform some callbacks to user mode to call the appropriate user-mode printer driver.
       -- To allow printer driver code to run in user mode, some kernel APIs have now been made available from user mode.

As a result, all the kernel APIs described above now have user-mode counterparts, exported from the gdi32.dll user-mode module. Let’s try to execute the same code shown above, but, this time, from user mode:

Note the reference counter values shown in the comments. The value is still zero after locking the bitmap. Why is this?

Kernel-mode code is always trusted, while user-mode code is always untrusted. So, now that printer drivers execute in user mode, they are considered untrusted and potentially malicious.

Suppose that the user-mode EngLockSurface call would increase the bitmap’s reference counter in the same way that the kernel-mode version does. An attacker, acting as a user-mode printer driver, could call EngLockSurface many times in a loop on a bitmap in order to overflow the bitmap’s reference counter, causing it to wrap around to zero. Then the bitmap could be deleted, leading to a use-after-free on the bitmap.

For this reason, the Windows kernel has implemented a different approach. The EngLockSurface API is expected to return a pointer to the bitmap’s SURFOBJ record – and it does, but, in user mode, this is a user-mode copy of the “true”, kernel-mode SURFOBJ record. We can reconstruct this user-mode data structure as follows:

The user-mode EngLockSurface implementation returns a pointer to the UMSO.so field, which is a copy of the true, kernel-mode SURFOBJ record, so that everything will work as expected. Internally, the user-mode EngLockSurface call jumps to its kernel-mode implementation win32kfull.sys!NtGdiEngLockSurface, where the user-mode UMSO record is allocated and filled in. In kernel mode, the “true”, kernel-mode EngLockSurface call is made on the bitmap, which is needed to access the bitmap’s SURFOBJ record so its data can be copied into the UMSO.so field. Afterwards, though, NtGdiEngLockSurface calls the kernel-mode EngUnlockSurface, which decreases the bitmap’s reference counter to zero again. This explains the observed reference counter values.

Once we call the user-mode EngLockSurface, we are allowed to pass its result (which is a pointer to the copied SURFOBJ data) to various drawing functions, such as EngLineTo or EngBitBlt. When corresponding calls are made from kernel mode, it works in a straightforward manner, but when calling from user mode, an additional layer is needed to translate the user-mode SURFOBJ pointers into true, kernel-mode pointers. So, for example, if the user-mode code calls gdi32.dll!EngLineTo, this will jump to the kernel-mode win32kfull.sys!NtGdiEngLineTo wrapper. The wrapper will obtain the bitmap’s true kernel-mode SURFOBJ record, so the kernel-mode win32kfull.sys!EngLineTo drawing handler ultimately can be executed.

How does the kernel obtain the needed kernel-mode SURFOBJ record? A SURFOBJ record contains sensitive data such as the bitmap’s pixel buffer pointer, so the kernel never relies on the contents of SURFOBJ records coming from user mode. Otherwise, there would be a security risk from malicious user-mode code that tampers with the contents of UMSO.so structures. Instead, inside the wrapper function (such as win32kfull.sys!NtGdiEngLineTo in the example above), the kernel verifies the UMSO.magic value, and then uses the UMSO.hsurf bitmap handle value to lock the bitmap by calling EngLockSurface. In this way, the kernel safely obtains the requested bitmap’s kernel-mode SURFOBJ record, which it can then pass to the appropriate kernel-mode win32kfull.sys!EngXXX drawing function.

The Vulnerability

The user-mode EngLockSurface function performs some validation on the supplied bitmap handle, meaning that not every kind of bitmap can be passed successfully to this call (we will discuss this in more detail later). But malicious user-mode code can now bypass this in any of these ways:

1) After making the EngLockSurface call, we can delete the already-validated bitmap and create some other bitmap with the same handle value. We could choose to create a bitmap of a kind that couldn’t be successfully passed to EngLockSurface.

2) After making the EngLockSurface call, we receive a pointer to a user-mode SURFOBJ record, which, as we already know, is a part of a UMSO record. So, we can overwrite the UMSO.hsurf field, setting it to the handle of any bitmap that we want. We can choose to set it to the handle of a bitmap that couldn’t be successfully passed to EngLockSurface.

3) Simplest of all, we could prepare a UMSO record from scratch, without making any EngLockSurface call first. All we need to do is allocate some user-mode memory, set UMSO.magic to 0x554D534F, and set UMSO.hsurf to the handle of a bitmap of our choice. The remaining part of this record (the UMSO.so field, containing the SURFOBJ record under normal circumstances) can be zeroed, as it will be disregarded by the kernel in any event.

Each of the three possibilities above will allow us to bypass the bitmap validation performed by the user-mode version of the EngLockSurface API.

Now that we have seen that the validation can be bypassed, we must ask what is the purpose of that validation, and what ramifications does it have for security? To answer this question, we must look at the SURFOBJ record definition. Some fields are publicly documented, while others have been reconstructed, as shown below:

The bitmap’s flags field is undocumented, but it is known to contain some documented HOOK_XXX flags found in the winddi.h header file. These flags tell the win32k subsystem which drawing operations should be handled by win32k itself, and which should instead be directed to a specialized device driver. The device driver is indicated by the bitmap’s hdev field.

For example, suppose we want to draw a line on some bitmap. We’ll call EngLineTo, passing a pointer to the bitmap’s SURFOBJ record. Internally, the kernel will convert the requested line into a more general drawing construct known as a “path” (which can be a sequence of lines and curves). It will then check if the bitmap’s SURFOBJ.flags field has the HOOK_STROKEPATH flag set. If this flag is not present, it will use the generic code for drawing (“stroking”) paths provided by win32kfull. If HOOK_STROKEPATH is present, though, the kernel will direct the drawing request to the device driver specified by the SURFOBJ.hdev field. The latter case, where possible, offers improved performance, as it allows individual device drivers to take advantage of accelerations offered by the specific hardware. For example, a graphics adapter may offer hardware-accelerated path stroking. Similarly, printer devices have specialized acceleration for outputting text.

So, if we prepare a bitmap that has a screen-related SURFOBJ.hdev value, and also has the appropriate HOOK_XXX flag set, and we pass it to one of the EngXXX drawing APIs, there is the possibility of reaching an entry point of a specialized display driver, working in kernel mode. This could be cdd.dll!DrvXXX in the single-monitor case or win32kfull.sys!MulXXX in the multi-monitor case (though, there is not always a simple relationship between the requested functionality and the driver entry point ultimately called, as noted in the example above). The pointer to the bitmap’s SURFOBJ record will be passed as a parameter to the driver’s entry point.

Further note that some EngXXX APIs take not only one bitmap as a parameter, but rather two: a source bitmap and a destination bitmap. (Some optionally also take a mask bitmap, but that is not interesting for us). An example of such an API is EngBitBlt, which copies a rectangle of pixels from a source bitmap to a destination bitmap. APIs that work on two bitmaps use the SURFOBJ.flags and SURFOBJ.hdev values of the destination bitmap when determining the ultimate device driver to receive the call. Nonetheless, when the final driver’s entry point is called, both the source and destination bitmaps are passed to it.

Hence, a properly prepared, screen-related bitmap, when passed to some EngXXX API as the destination bitmap, allows us to reach a kernel-mode display driver, while also allowing an arbitrary bitmap of our choice to be passed as the source bitmap.

There is still no obvious security problem here, but let’s look at the SURFOBJ record definition once again. It contains a dhsurf field (not to be confused with the hsurf field discussed above). The win32k subsystem treats SURFOBJ.dhsurf as an opaque value. It is reserved for individual device drivers to use for their internal purposes. Setting this field on a new bitmap is easy: the EngCreateDeviceBitmap and EngCreateDeviceSurface bitmap creation APIs just take the dhsurf value as a parameter. Both the Canonical Display Driver (cdd.dll, used for single-monitor graphics output) and the multi-display driver (win32kfull.sys!MulXXX) expect to work only with their own bitmaps – bitmaps with SURFOBJ.dhsurf values set by that specific driver – rather than on arbitrary bitmaps created from user mode (or by other drivers). Internally, each of these drivers use the SURFOBJ.dhsurf value as a pointer to a block of kernel-mode memory, containing private data owned by that driver.

But we can reach a kernel-mode display driver by passing a properly prepared, destination bitmap to the EngXXX call, and we can also pass some arbitrary bitmap of our choice as the source bitmap to the same EngXXX call. This source bitmap can be an arbitrary bitmap we created, and its SURFOBJ.dhsurf value may point to arbitrary controllable memory. The kernel-mode display driver, such as the Canonical Display Driver, will work on this block of memory as if it were its own block of kernel-mode memory. This means “game over”.

For these reasons, the user-mode EngLockSurface implementation has validation to reject screen-related bitmaps that could be used to reach a kernel-mode display driver. But, thanks to the vulnerability described above, we can bypass this EngLockSurface validation easily. In fact, we can get away with not calling EngLockSurface at all, and just preparing the needed UMSO record from scratch instead, as we have explained.

Exploitation

We must first notice that user-mode EngXXX calls are intended to be used by user-mode printer drivers only, so most of these APIs will fail unless they are called during a callback from kernel to user-mode for a printing operation. But this doesn’t complicate things too much: the user-mode part of the callback is implemented as a gdi32.dll!GdiPrinterThunk function, which is a public export from gdi32.dll. It’s enough to hook or patch this function and perform our main exploitation there. This function receives four parameters (the input buffer, the input buffer size, the output buffer, and the output buffer size), but we don’t need the parameters during our exploitation at all. (However, if you are interested in more details, see Selecting Bitmaps into Mismatched Device Contexts. In particular, see sections titled “User-Mode Printer Drivers (UMPD)” and “Hooking the UMPD implementation”.)

We first need to get a callback from the kernel to our hooked gdi32.dll!GdiPrinterThunk function. To achieve this, we need to initiate some printing operation. First we must locate an installed printer. There is at least one virtual printer installed by default on every Windows machine. We can locate installed printers using a call to the user-mode winspool.drv!EnumPrintersA/W API. Then we must create a printer-related device context:

This call will go down to kernel mode, which will then perform several callbacks to user mode again – so our hooked gdi32.dll!GdiPrinterThunk function will be invoked, exactly as we need. Our main exploitation phase starts here.

First, we need to obtain a bitmap with a screen-related SURFOBJ.hdev value and a useful HOOK_XXX flag set in its SURFOBJ.flags field. To obtain such a bitmap, we can create a window with proper parameters, obtain the window’s device context, and grab the underlying bitmap. The obtained bitmap will act as our destination bitmap:

We also need a source bitmap, with its SURFOBJ.dhsurf field pointing to controlled user-mode memory (our FakeDhsurfBlock):

Now we can prepare two UMSO records, one for the destination bitmap and one for the source bitmap:

At this point, we have everything that we need to make a malicious EngXXX call with our bitmaps. Our screen-related, destination bitmap will have all the defined HOOK_XXX flags set, so we are free to choose any of the EngXXX APIs that accept two bitmaps:

Through reverse engineering the Canonical Display Driver or multi-display driver internals, we can learn how to prepare the user-mode FakeDhsurfBlock so that the call to the display driver yields exploitable memory primitives.

The Patch

As discussed earlier, each of the user-mode EngXXX drawing APIs (such as EngLineTo and EngBitBlt) calls its corresponding kernel-mode win32kfull.sys!NtGdiEngXXX wrapper, where, amongst other things, user-mode SURFOBJ pointers are converted to kernel-mode SURFOBJ pointers. Afterwards, a kernel-mode win32kfull.sys!EngXXX driver endpoint is called to perform the requested drawing operation.

Although it’s not related to our vulnerability, it’s worth mentioning that, for the duration of the gdi32.dll!GdiPrinterThunk user-mode callback, the kernel maintains a mapping of known user-mode SURFOBJ records to kernel-mode SURFOBJ records. When a user-mode printer driver passes a user-mode SURFOBJ pointer to some user-mode EngXXX call, the kernel will try to use the mapping to find the corresponding kernel-mode SURFOBJ pointer so it can be passed to the corresponding kernel-mode EngXXX call.

The mapping is prepared before the user-mode GdiPrinterThunk callback begins. This is because some bitmaps may be passed to the callback as parameters (though, during our exploitation, we made no use of the GdiPrinterThunk input data). However, this means that bitmaps “locked” later, that is, by calls to EngLockSurface made from inside the callback, are not present in the mapping.

Whenever some win32kfull.sys!NtGdiEngXXX receives a user-mode SURFOBJ pointer as a parameter and is not able to find it in the mapping, it assumes that the received SURFOBJ record is contained in an UMSO record (as its UMSO.so field).

Before the patch, such cases were directed to the internal win32kfull.sys!UMPDSURFOBJ::GetLockedSURFOBJ function, where the UMSO.magic value would be verified against the 0x554D534F value, and then the kernel-mode EngLockSurface call would be made on the UMSO.hsurf handle value, yielding the needed pointer to the “true”, kernel-mode SURFOBJ record, as discussed earlier.

As you may have noticed, the name GetLockedSURFOBJ is misleading, as it suggests that the bitmap is already locked. In reality, when coming from user mode, a bitmap’s reference counter is still zero. And as we saw above, a malicious user-mode printer driver may not have called EngLockSurface at all, but instead just prepared the needed UMSO record from scratch.

After the patch, the function name was changed to GetLockableSURFOBJ. A user-mode printer driver can still perform all the manipulations described above, but now GetLockableSURFOBJ considers the received bitmap handle (UMSO.hsurf) as untrusted. After using the UMSO.hsurf value to lock the bitmap in kernel mode, GetLockableSURFOBJ now once again performs the same bitmap validation that is performed when calling the user-mode EngLockSurface API. This validation is performed by calling win32kfull.sys!IsSurfaceLockable. In this way, screen-related bitmaps that could be used to reach the kernel-mode display driver from within the user-mode printer driver are now rejected by GetLockableSURFOBJ.


Thanks again to Marcin 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 them in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

The August 2023 Security Update Review

Greetings from hacker summer camp! Black Hat and DEFCON start this week, but let’s kick everything off with Patch Tuesday and the latest security offerings from Adobe and Microsoft. Take a break from your regularly scheduled activities and join us as we review the details of their latest advisories. If you’d rather watch the video recap, you can check it out here.

Adobe Patches for August 2023

For August, Adobe released four patches addressing 37 CVEs in Adobe Acrobat and Reader, Commerce, Dimension, and the Adobe XMP Toolkit SDK. A total of 28 of these CVEs came through the ZDI program. The update for Reader is the largest, clocking in with 30 CVEs. The most severe of these are rated Critical and would allow code execution when opening a specially crafted PDF. The update for Commerce fixes three CVEs, including an OS command injection bug rated at a CVSS 9.1. The update for Dimension also fixes three CVEs. Similar to reader, and attacker could gain code execution if an affected system opened a specially crafted file. The final patch for the Adobe XMP Toolkit SDK corrects a single Denial-of-Service (DoS) bug.

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

Microsoft Patches for August 2023

This month, Microsoft released 74 new patches and two new advisories addressing CVES in Microsoft Windows and Windows Components; Edge (Chromium-Based); Exchange Server; Office and Office Components; .NET and Visual Studio; ASP.NET; Azure DevOps and HDInsights; Teams; and Windows Defender. Three of these CVEs were reported through the ZDI program and based on our upcoming page, many others are coming in the near future. Once you include the 11 fixes from the Chromium group for Edge (Chromium-Based) and the fix for AMD, it brings the total number of CVEs to 86.

Of the new patches released today, six are rated Critical and 67 are rated Important in severity. This is on the lower side for an August release, but perhaps Microsoft was distracted by other security problems.

None of the CVEs released today are listed as being publicly known or under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the fix that’s not a fix:

-       ADV230003 - Microsoft Office Defense in Depth Update
This advisory does not provide a fix for CVE-2023-36884, but it does (allegedly) break the exploit chain currently being used in active attacks. Microsoft released an advisory last month providing some details about this bug, but not a patch to fix it. Surprisingly, there still isn’t a patch – just this mitigation. Hopefully, a full patch to thoroughly address this bug under exploit will be released soon.

[UPDATE] Microsoft has now revised CVE-2023-36844 to include patches for all 33 affected products. You should apply the patch and consider this advisory as a temporary fix only.

-       CVE-2023-38181 - Microsoft Exchange Server Spoofing Vulnerability
This is a patch bypass of CVE-2023-32031, which itself was a bypass of CVE-2023-21529, which was a bypass of CVE-2022-41082, which was under active attack. This exploit does require authentication, but if exploited, an attacker could use this to perform an NTLM relay attack to authenticate as another user. It could also allow an attacker to get a PowerShell remoting session to the server. This is one of six CVEs fixed in Exchange this month, and each seems more severe than the next. Definitely take the time to test and deploy the cumulative update quickly.

-       CVE-2023-35385/36910/36911 - Microsoft Message Queuing Remote Code Execution Vulnerability
All three of these are rated at a CVSS of 9.8 and could allow a remote anonymous attacker to execute their code on an affected server at the level of the Message Queuing service. There are 11 total bugs impacting Message Queuing getting fixed this month, and it’s clear that the research community is paying close attention to this service. While we haven’t detected active exploits targeting Message Queuing yet, it’s like just a matter of time as example PoCs exist. You can block TCP port 1801 as a mitigation, but the better choice is to test and deploy the update quickly.

-       CVE-2023-29328/29330 - Microsoft Teams Remote Code Execution Vulnerability
These bugs allow an attacker to gain code execution on a target system by convincing someone to a malicious Teams meeting set up by the attacker. Microsoft doesn’t specifically state what level the code execution occurs, but they do note the attacker could provide “access to the victim's information and the ability to alter information,” so that implies at the logged-on user level. We’ve seen similar exploits demonstrated at Pwn2Own, so don’t skip this update.

-       CVE-2023-21709 - Microsoft Exchange Server Elevation of Privilege Vulnerability
I know I already brought up Exchange, but I couldn’t let this CVE pass without a mention. This vulnerability allows a remote, unauthenticated attacker to log in as another user. In this case, you’re elevating from no permissions to being able to authenticate to the server, which makes all of those post-authentication exploits (see above) viable. Although rated Important, I would consider this bug rated Critical and act accordingly.

Here’s the full list of CVEs released by Microsoft for August 2023:

CVE Title Severity CVSS Public Exploited Type
CVE-2023-35385 Microsoft Message Queuing Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-36910 Microsoft Message Queuing Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-36911 Microsoft Message Queuing Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2023-29328 Microsoft Teams Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-29330 Microsoft Teams Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-36895 Microsoft Outlook Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2023-20569 * AMD: CVE-2023-20569 Return Address Predictor Important N/A No No Info
CVE-2023-35390 .NET Core Remote Code Execution Vulnerability Important 8.4 No No RCE
CVE-2023-36899 .NET Framework Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2023-36873 .NET Framework Spoofing Vulnerability Important 5.9 No No Spoofing
CVE-2023-35391 ASP.NET Core and Visual Studio Information Disclosure Vulnerability Important 7.1 No No Info
CVE-2023-38178 ASP.NET Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-38180 ASP.NET Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-36881 Azure Apache Ambari Spoofing Vulnerability Important 4.5 No No Spoofing
CVE-2023-38188 Azure Apache Hadoop Spoofing Vulnerability Important 4.5 No No Spoofing
CVE-2023-35393 Azure Apache Hive Spoofing Vulnerability Important 4.5 No No Spoofing
CVE-2023-36877 Azure Apache Oozie Spoofing Vulnerability Important 4.5 No No Spoofing
CVE-2023-38176 Azure Arc-Enabled Servers Elevation of Privilege Vulnerability Important 8.5 No No EoP
CVE-2023-36869 Azure DevOps Server Spoofing Vulnerability Important 6.3 No No Spoofing
CVE-2023-35394 Azure HDInsight Jupyter Notebook Spoofing Vulnerability Important 4.5 No No Spoofing
CVE-2023-38170 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35389 Microsoft Dynamics 365 On-Premises Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2023-38157 Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability Important 3.9 No No SFB
CVE-2023-36896 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35368 Microsoft Exchange Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-21709 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 9.8 No No EoP
CVE-2023-35388 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2023-38182 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2023-38185 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-38181 Microsoft Exchange Server Spoofing Vulnerability Important 8.8 No No Spoofing
CVE-2023-35376 Microsoft Message Queuing Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35377 Microsoft Message Queuing Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-36909 Microsoft Message Queuing Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-36912 Microsoft Message Queuing Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-38172 Microsoft Message Queuing Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-38254 Microsoft Message Queuing Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-35383 Microsoft Message Queuing Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2023-36913 Microsoft Message Queuing Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-35371 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35372 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36865 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36866 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-38169 Microsoft OLE DB Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-36893 Microsoft Outlook Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2023-36890 Microsoft SharePoint Server Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-36894 Microsoft SharePoint Server Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2023-36891 Microsoft SharePoint Server Spoofing Vulnerability Important 8 No No Spoofing
CVE-2023-36892 Microsoft SharePoint Server Spoofing Vulnerability Important 8 No No Spoofing
CVE-2023-36882 Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-38175 Microsoft Windows Defender Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35379 Reliability Analysis Metrics Calculation Engine (RACEng) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36898 Tablet Windows User Interface Application Core Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36897 Visual Studio Tools for Office Runtime Spoofing Vulnerability Important 5.9 No No Spoofing
CVE-2023-35387 Windows Bluetooth A2DP driver Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2023-36904 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36900 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36906 Windows Cryptographic Services Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-36907 Windows Cryptographic Services Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-35381 Windows Fax Service Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-36889 Windows Group Policy Security Feature Bypass Vulnerability Important 5.5 No No SFB
CVE-2023-35384 Windows HTML Platforms Security Feature Bypass Vulnerability Important 5.4 No No SFB
CVE-2023-36908 Windows Hyper-V Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2023-35359 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35380 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38154 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35382 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35386 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38184 Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2023-38186 Windows Mobile Device Management Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-35378 Windows Projected File System Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-36914 Windows Smart Card Resource Management Server Security Feature Bypass Vulnerability Important 5.5 No No SFB
CVE-2023-36903 Windows System Assessment Tool Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36876 Windows Task Scheduler Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2023-36905 Windows Wireless Wide Area Network Service (WwanSvc) Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-38167 Microsoft Dynamics Business Central Elevation Of Privilege Vulnerability Important 7.2 No No EoP
CVE-2023-4068 * Type Confusion in V8 High N/A No No RCE
CVE-2023-4069 * Type Confusion in V8 High N/A No No RCE
CVE-2023-4070 * Type Confusion in V8 High N/A No No RCE
CVE-2023-4071 * Heap buffer overflow in Visuals High N/A No No RCE
CVE-2023-4072 * Out of bounds read and write in WebGL High N/A No No RCE
CVE-2023-4073 * Out of bounds memory access in ANGLE High N/A No No RCE
CVE-2023-4074 * Use after free in Blink Task Scheduling High N/A No No RCE
CVE-2023-4075 * Use after free in Cas High N/A No No RCE
CVE-2023-4076 * Use after free in WebRTC High N/A No No RCE
CVE-2023-4077 * Insufficient data validation in Extensions Medium N/A No No SFB
CVE-2023-4078 * Inappropriate implementation in Extensions Medium N/A No No SFB

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

 

There are only other Critical-rated patches being released today deals with Outlook. This is a bit odd since these types of open-and-own bugs are typically rated Important due to the needed user interaction. The exception is when the Preview Pane is an attack vector, but that’s not documented here. There’s clearly something that makes this bug stand out, but Microsoft offers no clues as to what that may be. Also note that if you use Outlook for Mac, you’ll have to wait for your update as Microsoft didn’t release it today.

Looking at the other remote code execution patches, many are the expected Important-rated Office bugs. There are additional Exchange RCEs as well, although they require the attacker to be network adjacent – meaning on the same LAN as the target. The concerning one is CVE-2023-38185, which does require authentication, but could allow an attacker to run elevated code through a network call. There are two separate bugs that require connecting to a malicious database. Also note that if you have installed Microsoft SQL Server 2022 for x64-based Systems (GDR) or Microsoft SQL Server 2019 for x64-based Systems (GDR), you are still vulnerable and need to apply this update. There’s a patch for LDAP that would allow an attacker to run code with the service’s permissions through a specially crafted LDAP call. The final RCE this month is a fix for Dynamics 365 that could be exploited by clicking a link in e-mail.

Moving on to the Elevation of Privilege (EoP) bugs receiving patches this month, the vast majority require an attacker to run a specially crafted program on an affected system. In most cases, this leads to attackers running code at SYSTEM level. The bug in Azure Arc-Enabled servers is somewhat interesting in that it affects both Linux and Windows servers. An attacker could elevate to root or administrator respectively. The bug in Windows Defender would allow an attacker to delete arbitrary files on a system. The Task Scheduler vulnerability also allows for the creation and deletion of files, but you wouldn’t be able to overwrite existing files – just delete them. The bug in .NET Framework would only yield the privileges on the application targeted. Lastly, the bug in Bluetooth would yield SYSTEM access, but only after you pair a Bluetooth device.

There are only four security feature bypass (SFB) fixes in this month’s release, and the most severe is likely the bug in the Windows Smart Card Resource Management Server. This flaw could allow an attacker to bypass the Fast Identity Online (FIDO) secure authentication feature, which effectively removes two-factor authentication. The SFB in HTML Platforms is similar to other bugs that have been exploited in the wild. An attacker could use this bug to have URLs map to the incorrect Security Zone. The SFB for Edge-Chromium is confusing as Microsoft states physical access and user interaction are required, but they don’t elaborate on either point. The bug in Group Policy would allow an attacker to read specific Group Policy configurations but not alter them.

In addition to the Exchange spoofing bug previously mentioned, there are 11 other spoofing fixes in the August release. The bugs in SharePoint act like cross-site scripting (XSS) bugs and require multiple patches to address. Be sure you install all applicable updates. The bug in Outlook could allow the disclosure of NetNTLMv2 hashes, which would allow an attacker to potentially authenticate as another user. Little information is available about the other fixes, although Microsoft notes user interaction is required for all of the other bugs. The Azure Apache cases (yes – that sounds odd to me too) require an administrator to open a malicious file.

The August release contains 10 total information disclosure fixes. Fortunately, the majority of these merely result in info leaks consisting of unspecified memory contents. One of the bugs in SharePoint could disclose the cryptically-named “sensitive information”. Thanks for narrowing that down. The other SharePoint bug could leak private property values. The bug in ASP.NET is interesting as it could be used to listen to any group or user with a specially crafted group/username. By exploiting this vulnerability, the attacker can now receive messages for group(s) that they are unauthorized to view. The Hyper-V bug could allow a guest to disclose info from the Hyper-V host, but no details on what information is available. Finally, the AMD return address predictor fix is also included in this release.

Wrapping things up, there are eight fixes for Denial-of-Service (DoS) bugs, with six of these being for the Message Queuing service. Microsoft notes user interaction is required for some of these bugs in that the bug is triggered “when a user on the target machine accesses message queuing.” However, users may not be aware which application use message queuing and unintentionally create a DoS condition on the system. No further information is available regarding the two ASP.NET DoS bugs.

The other new advisory (ADV230004) is a defense-in-depth update for the Memory Integrity System Readiness scan tool. Also known as the hypervisor-protected code integrity (HVCI), this tool for ARM64 and AMD64 processors checks for compatibility issues with memory integrity. The release update takes care of a publicly known bug. The latest servicing stack updates can be found in the revised ADV990001.

Looking Ahead

The next Patch Tuesday will be on September 12, 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!

CVE-2023-35150: Arbitrary Code Injection in XWiki.org XWiki

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Simon Humbert and Lucas Miller of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in the XWiki free wiki software platform. This bug was originally discovered by Michael Hamann with public Proof-of-Concept (PoC) code provided by Manuel Leduc. Successful exploitation of this vulnerability would allow an authenticated attacker to perform an arbitrary code injection on affected systems. The following is a portion of their write-up covering CVE-2023-35150, with a few minimal modifications.


A code injection vulnerability has been reported in the XWiki.Org XWiki. The vulnerability is due to improper input validation when rendering a link in the Invitation Application.

A remote, authenticated attacker can exploit this vulnerability by sending crafted requests to the target server. Successful exploitation could result in arbitrary code injection.

The Vulnerability

XWiki is a second-generation wiki, which provides wiki functionality as well as an application development platform. XWiki offers the features expected from a wiki (such as powerful access rights and user management) and the possibility to create new applications on top of the platform. The XWiki interface can be accessed over HTTP on port 8080 by default.

XWiki includes a robust scripting feature set. Scripting allows users to create basic to complex web applications at the XWiki page (or view) layer without the need for compiling code or deploying software components. In other words, users can use scripting syntax in addition to wiki markup inside the content of an XWiki page. XWiki supports a variety of scripting languages including Velocity, Groovy, and Python enabled by default. XWiki implements the JSR-223 scripting platform to support the evaluation of script code. XWiki implements a script macro that evaluates script code and has the following form:

Script code for the default enabled languages can be declared directly with the language name as follows:

XWiki includes an “Invitation Application”. The “Invitation Application” is used to configure a wiki to send email notifications to users to request registration with the server. The user can then access a provided link to register with the server.

A code injection vulnerability has been reported in XWiki. The vulnerability is due to insufficient validation of user data rendered by the “Invitation Application”. Requests to the “Invitation Application” typically consist of many request parameters, with the action parameter used to determine what actions to take for the request. If the action parameter is not present the server will display a link to the “Invitation Application” based on the contents of the request-URI. However, the request-URI is not sanitized before rendering the link. An attacker could include script code in the request-URI that will then be evaluated when the link is rendered. An example of a malicious requestURI is shown below:

Source Code Walkthrough

The following code snippet was taken from XWiki version 14.10.3. Comments added by Trend Micro have been highlighted.

From xwiki-platform-core/xwiki-platform-invitation/xwiki-platform-invitation-ui/src/main/resources/Invitation/InvitationGuestActions.xml:

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following ports:
         -- HTTP, over port 8080/TCP
         -- HTTPS, over port 8443/TCP

Note that traffic may be SSL encrypted and should be decrypted before applying the following guidance. The detection device must monitor for HTTP requests to XWiki endpoints with a request-URI that contains the string:

         /xwiki/bin/view

If found, the detection device must look for a request parameter with the name sheet with a value of “Invitation.InvitationGuestActions” and a request parameter with the name xpage with a value of view. If found, the request-URI should be inspected for the characters {{ (or the URL encoded equivalent %7B%7B, case insensitive). If found, the traffic should be considered suspicious and an attack exploiting this vulnerability is likely underway.

Note that the string matching of the request-URI and parameter names should be performed in a case-insensitive manner.

Conclusion

This vulnerability has been addressed in XWiki versions 14.4.814.10.4, and 15.0. In their announcement of the fix, the XWiki team also showed the steps to reproduce this bug, which essentially serves as a public PoC. No other mitigations are listed beyond upgrading to a fixed version, so it is recommended all XWiki users upgrade to a non-impacted version as soon as possible.

Special thanks to Simon Humbert and Lucas Miller 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.

Revealing the Targets and Rules for the First Pwn2Own Automotive

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

 

Earlier this year, I announced the ZDI, along with our cohorts at VicOne, will host a new Pwn2Own contest focused on automotive systems – Pwn2Own Automotive – at the upcoming Automotive World conference in Tokyo, Japan, held on January 24th – 26th, 2024. Today, we are releasing the targets and payouts for this inaugural event. As a reminder, we have three primary goals in hosting this event:

1.     Provide an avenue to encourage automotive research. We want to offer a place where researchers can submit and be financially rewarded for reports targeting various products and platforms.
2.     Incentivize vendors to participate in the security research community. We want to connect our global community of security researchers with automotive manufacturers to help improve their security and resiliency.
3.     Bring a focus to the sub-components of a vehicle. Rather than looking at the vehicle as a monolithic unit, we want to bring attention to the multiple complex systems that comprise a modern automobile ecosystem.

We’re also excited to announce Tesla will partner with us on this event. They have worked with us extensively for our Pwn2Own Vancouver event, and we rely on their guidance and understanding of the complexities of electric vehicles (EV). We’re also grateful that ChargePoint decided to provide their EV chargers to use during the contest. The researchers from VicOne have also been essential in helping to determine targets and providing technical guidance on EV attack surfaces. We have more than $1,000,000 USD in cash and prizes available, and we can’t wait to see what researchers bring to demonstrate in Tokyo. However, we know not everyone can make it to Automotive World, so we will allow remote participation similar to other events. You will still need to register before the contest deadline (January 18, 2024) and submit your entry, a detailed whitepaper completely explaining your exploit chain and instructions on how to run the entry by the end of the registration period. If you plan on participating remotely, you will need to contact us even earlier the ensure we put you in the best position for success. We recommend two weeks prior to the deadline at the very latest.

As with other Pwn2Own events, we’ll have a random drawing to determine the schedule of attempts prior to the contest, and we will proceed from there. As always, if you have questions, don't hesitate to get in touch with us at [email protected]. We will be happy to address your issues or concerns directly.

Now on to the four categories we’ll have for the first Pwn2Own Automotive contest:

            - Tesla
            - In-Vehicle Infotainment (IVI)
            - Electric Vehicle Chargers
            - Operating Systems

Tesla Category 

We introduced the Automotive Category at Pwn2Own Vancouver in 2019, and Pwn2Own Automotive wouldn’t be complete without something similar. Earlier this year, the team from Synacktiv combined multiple exploits to target a combination of systems. It will be interesting to see what researchers bring to Tokyo. Contestants can register an entry against either a Tesla Model 3/Y (Ryzen-based) or Tesla Model S/X (Ryzen-based) equivalent bench top unit.  Also note that while a Tesla is available as a prize, not every successful attempt will win the vehicle itself. Some of the targets have add-ons available, but to drive away with a Tier 3 prize, a contestant would need to target one of the entries marked “Vehicle Included” in the table below:

Here’s some additional info on the optional add-ons that are included in targets:

Previous exploits in this category have provided highlights of past events, and we’re hopeful we’ll see something similar in Tokyo. If you are going to participate in this category, please notify us at least two weeks before the event so we can source the hardware in time for the contest.  

Back to top

In-Vehicle Infotainment (IVI)

When we started looking at targets within an automotive system, one of the first things we thought of was the first thing we looked at – the In-Vehicle Infotainment (IVI) system. These serve as radios and connect with our phones, but they do so much more as well. Navigation, in-car internet, and Wi-Fi are provided through these devices, but they also server a connection to other vehicle systems through the CAN bus – making them a ripe target for attackers. These devices are also retrofitted to existing vehicles to modern capabilities – and perhaps modern vulnerabilities as well. For our first Pwn2Own Automotive contest, we’ll have three IVI devices to target. An attempt in this category must be launched against the target's exposed services or against the target’s communication protocols/physical interfaces that are accessible to a typical user.

Back to top

Electric Vehicle Chargers Category

There’s been a fair amount of research into the security of EVs, but there hasn’t been as much scrutiny around what we plug into an EV. Attack surfaces such as mobile apps, Bluetooth Low Energy (BLE) connections, and the OCPP protocol could all allow threat actor to cause harm to an EV. For this event, we’ll have six different EV Chargers available as targets. An attempt in this category must be launched against the target's exposed services or against the target’s communication protocols/physical interfaces that are accessible to a typical user.

Back to top

Operating Systems

Most don’t think of operating systems within their car, but if you drive a recent Mercedes, Subaru, Mazda, or Toyota, there’s a good chance you’re also driving something with Automotive Grade Linux installed. How do these onboard OSes compare to their desktop counterparts? That’s what we aim to discover. An attempt in this category must be launched against the target's exposed services/features or launched against the target’s communication protocols that are accessible to a typical user.

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.

The Complete Details

The full set of rules for Pwn2Own Automotive 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. Japanese Standard Time on January 18, 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 #P2OAuto hashtag for continuing coverage.

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

With special thanks to our Pwn2Own Automotive 2024 partners, Tesla, for providing their assistance and technology and to ChargePoint for providing hardware to use during the event. Thanks also to the researchers from VicOne for their guidance and recommendations.

©2023 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.

Looking at the ChargePoint Home Flex Threat Landscape

We recently announced the rules and targets for the upcoming Pwn2Own Automotive competition. As we look forward to the event, we thought we would review the attack surface on some of the targets. We begin with the ChargePoint Home Flex – a 240-volt Level 2 home charger that delivers up to 50 amps of power.


The ChargePoint Home Flex is a level 2 electric vehicle charge station designed for use by end-users in their homes. The device has a minimal user interface in its hardware. The device employs mobile applications for both the installation and the regular operation of the equipment by the consumer.

ChargePoint Home Flex Attack Surface Summary

Broadly speaking, the attack surface of the device can be broken down into three categories.

1.     ChargePoint Mobile Applications
The ServicePro application used by electricians during the installation of the ChargePoint Home Flex unit offers one avenue of attack.
The ChargePoint application used by end-users when configuring and using the ChargePoint Home Flex also provides an attack surface.

2.     ChargePoint Home Flex hardware
The device includes an embedded Linux host that communicates over Wi-Fi to hosts on the internet. The unit also contains a PCB based around the Texas Instruments MSP430 micro-controller. The wireless communication PCB is based on an Atmel CPU. Finally, the JTAG interface is accessible via the wireless communication PCB.

3.     Network Attack Surfaces
Software patches to the device are provided via Internet-based over-the-air (OTA) updates. The Bluetooth Low Energy (BLE) endpoint used by mobile applications for local communication could provide an opportunity for attack. Any Wi-Fi communication with a local access point opens the opportunity for interception and manipulation. Finally, the device implements the Open Charge Point Protocol (OCPP). Any deficiencies in this protocol would be inherited by the charger.

Prior Security Research

The ChargePoint Home Flex was the subject of a security assessment performed by Dmitry Skylar, a researcher from Kaspersky Labs. This review was performed in 2018, and the results were published in a paper, as well as a presentation at a number of security conferences. The slides can be found here.

ChargePoint Home Flex Mobile Applications

ChargePoint distributes two applications for use with the Home Flex charger. Both applications interact with the ChargePoint Home Flex over Bluetooth Low Energy (BLE).

The ChargePoint ServicePro application is intended for use by an electrician when installing the device for an end-user. This application is written using the React Native application development framework. This is a JavaScript-based development framework intended for cross-platform mobile application development.

The consumer-focused ChargePoint mobile app is intended for use by end-users to manage their charging preferences.

While we did not thoroughly investigate these applications for vulnerabilities or other bugs, problems in mobile applications have been used by threat actors in the past and represent a significant attack surface. Even though the mobile applications themselves are out of scope for the Pwn2Own Automotive contest, they should still be thoroughly reviewed by the research community.

ChargePoint Home Flex Bluetooth Low Energy

The ChargePoint Home Flex uses Bluetooth Low Energy to communicate with mobile applications. Trend Micro researchers used a custom BLE scanning tool to enumerate the endpoints made available by the charger.

The following service is defined in the BLE spec:

— BLE Service Device Information
System ID
Model Number String: CPH50
Serial Number String
Software Revision String: 5.5.2.5

The researchers observed the following BLE services and characteristics when scanning the device under test (DUT): 

— Device Details Service 274BC3A3-1A52-4D30-99C0-4DE08FFF2358
Get/Set PowerSourceType: Characteristic 8D4D6AF5-E562-4DC7-85AD-842FBF321C87
Get/Set PowerSourceAmps: Characteristic F24F7C35-A5FD-4B98-BCA5-50BB5DC8E7CD
Get/Set Apply Settings Status : Characteristic 5597DD46-7EDD-40CC-9904-B6934DC05E19
Get/Set UserId : Characteristic E79C86D4-8106-4908-B602-5B61266B2116
Get/Set Latitude : Characteristic 85F296FC-3152-4EF0-84CB-FAB8D05432E4
Get/Set Longitude : Characteristic 9253A155-701A-4582-A0CF-5E517E553586
Get/Set NOSStatus : Characteristic C31D51E5-BD61-4D09-95E2-C0E34ED1224C
Get/Set Power Source: Characteristic C1972E92-0D07-4464-B312-E60BA5F284FC

— WIFI Service DFAF46E7-04F9-471C-8438-A72612619BE9
Get/Set NextWIFIAccessPoint: Characteristic E5DEBB4B-4DAC-4609-A533-B628E5797E91
Get/Set CurrentSSID: Characteristic EB61F605-DED9-4975-9235-0A5FF4941F32
Get/Set WIFISecurityType: Characteristic 733ED10A-CD1B-43CA-A0C2-6864C8DCF7C1
Get/Set WiFi Configuration: Characteristic 25A03F00-1AF2-44F0-80F2-D6F771458BB9
Get/Set ApplyStatusCode: Characteristic 3BE83845-93E4-461E-8A49-7370F790EBC4
Get/Set Always Empty Response Characteristic: Characteristic CED647D7-E261-41E2-8F0D-35C360AAE269

— Unknown Service B67CB923-50E4-41E8-BECC-9ACD24776887 B67CB923-50E4-41E8-BECC-9ACD24776887
Get/Set Always NULL Byte Characteristic: Characteristic 7AC61302-58AB-47BA-B8AA-30094DB0B9A1

Trend Micro researchers performed limited probing of these BLE endpoints using a bespoke BLE scanner. In addition, Trend researchers performed reverse engineering of the end-user ChargePoint application. The names identified in the above listing have been inferred from the understanding of the Android application code.

ChargePoint Home Flex Hardware Details

The ChargePoint Home Flex comprises two circuit boards within the device housing. Those boards are the metrology board and the CPU board.

The metrology board hosts an MSP430 microcontroller. It terminates the power connection from the power supply, and it also terminates the charging cable that end-users connect to the electric vehicle. The metrology board also provides power to the CPU board via a stacked PCB connector on the upper right of the metrology board. The metrology board is labeled with the identifier Panda AC 50 on the PCB silkscreen markings. It hosts an MSP430 microcontroller.

The CPU board hosts an ATMEL Arm CPU, Wi-Fi radio, and Bluetooth LE radio. The CPU board is labeled CPH-50 CPU on the PCB silkscreen markings.

Here are some images detailing the ChargePoint Home Flex Metrology board and CPU board:

Figure 1 - Front side of the CPH-50 CPU Board

Figure 2 - Back side of the CPH-50 CPU Board

Figure 3 - Front side of the ChargePoint Home Flex metrology Board

Figure 4 - Back side of the ChargePoint Home Flex metrology Board

ChargePoint Home Flex Embedded Linux

Prior research performed by Kaspersky Labs indicates the charger uses the Linux operating system. The charger hardware has a board identified as the “Panda CPU” board, which implements all the accessible attack surface on the charger. The hardware comprises an ARM CPU, and the device provides a JTAG debug header. Prior research showed this JTAG header could be leveraged to obtain shell access to the charger.

During a preliminary assessment of the charger, Trend Micro researchers used a captive test network to interrogate the ChargePoint Home Flex. The test network had a Wi-Fi access point running connected to a network running a set of services configured to simulate the services the charger required. This network has a DNS server configured to respond to all DNS A-record queries with an IP address from within the test network.

During testing, the researchers observed the DNS queries made by the DUT and configured the DNS server with all the observed host names it attempted to connect to. Additionally, the test network includes a web server configured to respond to the web requests made by the DUT. The DUT has made DNS requests to the following domains:

        ba79k2rx5jru.chargepoint.com
        homecharger.chargepoint.com
        publish.chargepoint.com

The researchers noted that TLS connections initiated to web servers failed to establish due to the TLS certificate authority mismatches. The enforcement of TLS certificate authority matching is a security benefit.

The ChargePoint Home Flex connected over SSH to the server ba79k2rx5jru.chargepoint.com on TCP port 343. The research network included a permissive SSH server that would allow authentication for any user. When the charger initiated a connection to the permissive SSH server in the test network, the researchers noted the SSH client from the DUT initiated a TCP port forward from the SSH server back to TCP port 23 on the charger. This matches the results noted by the Kaspersky research report.

Summary

While these may not be the only attack surfaces available on the ChargePoint Home Flex unit, they represent the most likely avenues a threat actor may use to exploit the device. ChargePoint has committed to providing the hardware for us to use during the Pwn2Own Automotive competition, and we appreciate their support. We’re excited to see what research is displayed in Tokyo during the event. Stay tuned to the blog for attack surface reviews for other devices, and if you’re curious, you can see all the devices included in the contest. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

The September 2023 Security Update Review

Hello and welcome to another patch Tuesday in what continues to be a hot 0-day summer, with new exploits being identified by Apple, Cisco, and Microsoft. Take a break from your regularly scheduled activities and join us as we review the details of the latest advisories from Adobe, Microsoft, and more. If you’d rather watch the video recap, you can check it out here.

Apple Patches for September 2023

Apple kicked off the September patch release by patching two bugs in macOS Ventura, iPad and iOS, and watchOS to address active exploits. The first vulnerability is tracked as CVE-2023-41064 and represents a buffer overflow in Image I/O. The other bug, CVE-2023-41061, represents a validation issue that can be exploited used malicious attachments. According to Citizen Lab researchers, these bugs were combined to deploy the infamous Pegasus spyware from the NSO Group. Regardless, make sure you take the time to update your Apple devices. Apple backported this fix to older phones today, so even if you aren’t on the latest iOS, you can still get the fix.

Cisco Advisories for September 2023

You may notice I said “advisories” instead of “patches” here, and that’s not just another case of me pedantic. On September 6, Cisco published an advisory notifying their customers of active exploits in the Cisco Adaptive Security Appliance (ASA) software and Firepower Threat Defense (FTD) software remote access VPN. This CVE, tracked as CVE-2023-20269, is reportedly being used by ransomware groups to gain access to target networks. There’s no patch for this yet, but Cisco does offer some temporary mitigations. If you’re using these products, it’s recommended that you apply the mitigations until a patch is available. Also, please remember these mitigations are temporary. Once the patch is available, don’t delay the testing and deployment just because these mitigations are in place.   

Adobe Patches for September 2023

For September, Adobe released three updates addressing five CVEs in Adobe Acrobat and Reader, Experience Manager, and Adobe Connect. Not to be left out of the 0-day…er…excitement, the lone bug in the Acrobat and Reader patch has been detected in the wild. Opening a specially crafted PDF could lead to code execution on an affected system. Clearly, this patch should be your priority. Interestingly, the patches for Experience Manager and Connect both address two cross-site scripting (XSS) bugs. Just an interesting coincidence.

Adobe lists the Reader patch as a deployment rating of 1 since it is under active attack. The other two patches are not 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 September 2023

This month, Microsoft released 59 new patches addressing CVEs in Microsoft Windows and Windows Components; Exchange Server; Office and Office Components; .NET and Visual Studio; Azure; Microsoft Dynamics; and Windows Defender. A total of 15 of these CVEs (25.4%) were reported through the ZDI program, and more are waiting in the wings. In addition to the new CVEs, two external bugs and four Chromium bugs are being incorporated into the release, bringing the total number of CVEs to 65.

Of the new patches released today, five are rated Critical, 55 are rated Important, and one is rated Moderate in severity. This is slightly lower than most September releases, but looking at the year-to-date totals, Microsoft is very close to the volume of fixes released in 2022.

Two of the CVEs released today are listed as being under active attack at the time of release while only one is listed as publicly known. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug being exploited:

-       CVE-2023-36761 - Microsoft Word Information Disclosure Vulnerability
This is the bug currently under active attack, but I wouldn’t classify it as “information disclosure”. An attacker could use this vulnerability to allow the disclosure of NTLM hashes, which would then presumably be used in an NTLM-relay style attack. Those are usually defined as Spoofing bugs (see Exchange blew). Regardless of the classification, the preview pane is a vector here as well, which means no user interaction is required. Definitely put this one on the top of your test-and-deploy list.

-       CVE-2023-29332 - Microsoft Azure Kubernetes Service Elevation of Privilege Vulnerability
This Critical-rated bug in the Azure Kubernetes service could allow a remote, unauthenticated attacker to gain Cluster Administration privileges. We’ve seen bugs like this before, but this one stands out as it can be reached from the Internet, requires no user interaction, and is listed as low complexity. Microsoft gives this an “Exploitation Less Likely” rating, but based on the remote, unauthenticated aspect of this bug, this could prove quite tempting for attackers.

-       CVE-2023-38148 - Internet Connection Sharing (ICS) Remote Code Execution Vulnerability
This Critical-rated bug is the highest-rated CVSS this month (8.8), but it’s not all bad news. First, this is limited to network-adjacent attackers. A successful exploit also relies on ICS being enabled. Most places these days don’t require ICS, and it’s not turned on by default. However, if you’re in one of those places where ICS is used, this could allow an unauthenticated attacker to run their code on affected systems.

-       CVE-2023-38146 - Windows Themes Remote Code Execution Vulnerability
This probably isn’t one of the most severe bugs patched this month, but it kicked off such a wave of nostalgia, that I had to call it out. This bug could allow code execution if an attacker can convince a user to open a specially crafted theme file. If this sounds like screensaver exploits from 20+ years, it’s because it’s just like screensaver bugs from 20+ years ago. Congrats to Pwn2Own winners Thijs Alkemade and Daan Keuper of Computest Sector 7 for helping bring this oldie but goodie to light.

Here’s the full list of CVEs released by Microsoft for September 2023:

CVE Title Severity CVSS Public Exploited Type
CVE-2023-36761 Microsoft Word Information Disclosure Vulnerability Important 6.2 Yes Yes Info
CVE-2023-36802 Microsoft Streaming Service Proxy Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2023-38148 Internet Connection Sharing (ICS) Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2023-29332 Microsoft Azure Kubernetes Service Elevation of Privilege Vulnerability Critical 7.5 No No EoP
CVE-2023-36792 Visual Studio Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2023-36793 Visual Studio Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2023-36796 Visual Studio Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2023-36799 .NET Core and Visual Studio Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2023-36788 .NET Framework Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36770 3D Builder Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36771 3D Builder Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36772 3D Builder Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36773 3D Builder Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36739 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No EoP
CVE-2023-36740 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36760 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-41303 * AutoDesk: CVE-2022-41303 use-after-free vulnerability in Autodesk® FBX® SDK 2020 or prior Important 7.8 No No RCE
CVE-2023-38155 Azure DevOps Server and Team Foundation Server Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2023-33136 Azure DevOps Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-38156 Azure HDInsight Apache Ambari Elevation of Privilege Vulnerability Important 7.2 No No EoP
CVE-2023-38162 DHCP Server Service Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-36801 DHCP Server Service Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2023-38152 DHCP Server Service Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2023-36800 Dynamics Finance and Operations Cross-site Scripting Vulnerability Important 7.6 No No XSS
CVE-2023-39956 * Electron: CVE-2023-39956 -Visual Studio Code Remote Code Execution Vulnerability Important 6.1 No No RCE
CVE-2023-36886 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 7.6 No No XSS
CVE-2023-38164 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 7.6 No No XSS
CVE-2023-36766 Microsoft Excel Information Disclosure Vulnerability Important 7.8 No No Info
CVE-2023-36777 Microsoft Exchange Server Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2023-36744 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2023-36745 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2023-36756 Microsoft Exchange Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2023-36757 Microsoft Exchange Server Spoofing Vulnerability Important 8 No No Spoofing
CVE-2023-36736 Microsoft Identity Linux Broker Information Disclosure Vulnerability Important 4.4 No No Info
CVE-2023-36765 Microsoft Office Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36767 Microsoft Office Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2023-36763 Microsoft Outlook Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2023-36764 Microsoft SharePoint Server Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2023-36802 Microsoft Streaming Service Proxy Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2023-36805 Windows MSHTML Platform Security Feature Bypass Vulnerability Important 7 No No RCE
CVE-2023-36742 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-36758 Visual Studio Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36759 Visual Studio Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2023-36794 Visual Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2023-35355 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38143 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38144 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38163 Windows Defender Attack Surface Reduction Security Feature Bypass Important 7.8 No No SFB
CVE-2023-36804 Windows GDI Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38161 Windows GDI Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38139 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38141 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38142 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-38150 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2023-36803 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-38140 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-38147 Windows Miracast Wireless Display Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-38149 Windows TCP/IP Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2023-38160 Windows TCP/IP Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2023-38146 Windows Themes Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2023-41764 Microsoft Office Spoofing Vulnerability Moderate 5.5 No No Spoofing
CVE-2023-4761 * Chromium: CVE-2023-4761 Out of bounds memory access in FedCM High N/A No No RCE
CVE-2023-4762 * Chromium: CVE-2023-4762 Type Confusion in V8 High N/A No No RCE
CVE-2023-4763 * Chromium: CVE-2023-4763 Use after free in Networks High N/A No No RCE
CVE-2023-4764 * Chromium: CVE-2023-4764 Incorrect security UI in BFCache High N/A No No SFB

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

 

Before we get to the other Critical-rated patches for September, let’s talk about the Exchange fixes released this month. Yes – even though Exchange just received a big update last month, there’s another one* today. There are five different Exchange CVEs today, and all were reported by ZDI researcher Piotr Bazydło. He’s been on quite the Exchange kick recently, including finding bypasses for both patches and silent fixes. The one that concerns me the most is the NTLM relay, which is marked as a Spoofing bug (see my pedantic note above). What’s most concerning about this is that this vulnerability seems to have been patched last month but wasn’t documented. This bug, along with the three RCE bugs, require authentication, but recall that last month’s Exchange patches included an auth bypass. Nifty. The final Exchange patch corrects an info disclosure bug that could disclose “file content.” It’s not clear if that’s a random file or if an attacker can name an arbitrary file. All of these patches require the August update to be installed, so don’t skip that and think you’re protected. And to all those admins rebooting Exchange over the weekend, I wish you Godspeed and good luck.

*UPDATE: Microsoft reached out to let us know these CVEs are not new updates but were released in the August update and are now being documented. They did not state why they were patched silently in August and gave no indication if their omission was intentional or accidental.

The remaining Critical-rated patches are all for Visual Studio. These are all open-and-own bugs that could lead to arbitrary code execution when opening a malicious package file with an affected version of Visual Studio.

Looking at the 15 other RCE getting patches this month, most share that open-and-own exploit scenario as the Critical-rated Visual Studio bugs. Interestingly, there are two Important-rated Visual Studio RCEs that look identical to the Critical-rated ones. There’s no indication why one is more severe than the others. There are six fixes for RCE in 3D Viewer Remote, and four of these were reported by ZDI researcher Mat Powell. The bugs are simple open-and-own vulns, but the product must be updated through the app store. If automatic updates from the store are disabled or if you’re otherwise disconnected, you’ll need to manually update. One of the RCEs in Word has a Preview Pane vector, but a user needs to click the attachment preview to trigger the exploit. There’s a scripting engine (Trident/EdgeHTML) bug that was reported through the ZDI. Under limited circumstances, crafted data in an image can lead to execution of untrusted script. An attacker can leverage this vulnerability to execute code in the context of the current process. There’s a patch for Miracast that could allow an attacker to project to an affected system in limited circumstances. Microsoft lists that as Adjacent, but I would consider it more of a Physical attack. Finally, there’s a fix for Azure DevOps that’s listed as RCE, but I would classify it as a privilege escalation instead. An attacker needs Queue Build permissions on an Azure DevOps pipeline that has an overridable variable. They could then use this to get a code injection by overriding the variable. You decide if it’s RCE or EoP as you patch your affected servers.

Before looking at the privilege escalation bugs, there are some impactful Denial-of-Service (DoS) vulnerability we should address. The first involves TCP/IP. A remote, unauthenticated attacker could take down an affected system by sending specially crafted IPv6 packets. As you might imagine, systems with IPv6 disabled aren’t impacted, but considering IPv6 is enabled by default, this could create some havoc on unpatched systems. Microsoft lists disabling router discovery on the IPv6 as a temporary workaround. As above, patches are permanent while workarounds are temporary. The other DoS bug of note impacts the DHCP server, although Microsoft provides no other details about the bug. The final DoS impact .NET and Visual Studio, but this bug requires someone to open a specially crafted file.

Moving on to the other EoP bugs receiving patches this month, the vast majority require an attacker to run a specially crafted program on an affected system. That’s true for CVE-2023-36802, which is the other bug listed as being under active attack. In most cases, this leads to either administrator privileges or running code at SYSTEM level. In fact, this is true of all of the EoP bugs patched this month outside of the previously mentioned Azure Kubernetes escalation.

Two fixes in this month’s release address security feature bypass (SFB) bugs. The first is in the Windows Defender Attack Surface Reduction blocking feature. The vulnerability could allow attackers to bypass the Windows Defender Attack Surface Reduction blocking feature, which definitely falls into the you-had-one-job category. The other patch impacts Office and corrects a bypass that could allow a potentially dangerous extension from being uploaded and downloaded. Like one of the Office bugs mentioned above, the Preview Pane is an attack vector, but a user would need to click to preview an attachment.

The September release contains eight additional information disclosure fixes. Fortunately, the majority of these merely result in info leaks consisting of unspecified memory contents. There are two significant exceptions. The first is in Outlook. A successful exploit could allow the disclosure of credentials. Yikes. At least the Preview Pane is not an attack vector here. The other interesting bug resides in the Microsoft Identity Linux Broker. Exploiting this vulnerability could disclose application data on the target. However, encrypted data at rest remains encrypted.

The lone Moderate-rated bug in this month’s release impacts Office components. Successful exploitation would allow an unauthenticated attacker to insert malicious content into a document. This document may then pass an authentication check when a partial signature is present.

Wrapping things up, there are three cross-site scripting (XSS) bugs fixed in this release. One fix is for Dynamics Finance and Operations while the remaining are for the on-prem Microsoft Dynamics 365.

No new advisories were released this month.

Looking Ahead

The next Patch Tuesday will be on October 10, 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!

❌