In this installment of our MindShaRE series, ZDI vulnerability researcher Michael DePlante describes how he uses the IO Ninja tool for reverse engineering and software analysis. According to its website, IO Ninja provides an “all-in-one terminal emulator, sniffer, and protocol analyzer.” The tool provides many options for researchers but can leave new users confused about where to begin. This blog provides a starting point for some of the most commonly used features.
Looking at a new target can almost feel like meeting up with someone who’s selling their old car. I’m the type of person who would want to inspect the car for rust, rot, modifications, and other red flags before I waste the owner’s or my own time with a test drive. If the car isn’t super old, having an OBD reader (on-board diagnostics) may save you some time and money. After the initial inspection, a test drive can be critical to your decision.
Much like checking out a used car, taking software for test drives as a researcher with the right tools is a wonderful way to find issues. In this blog post, I would like to highlight a tool that I have found incredibly handy to have in my lab – IO Ninja.
Lately, I have been interested in antivirus products, mainly looking for local privilege escalation vulnerabilities. After looking at several vendors including Avira, Bitdefender, ESET, Panda Security, Trend Micro, McAfee, and more, I started to notice that almost all of them utilize the Named Pipe Filesystem (NPFS). Furthermore, NPFS is used in many other product categories including virtualization, SCADA, license managers/updaters, etc.
I began doing some research and realized there were not many tools that let you locally sniff and connect to these named pipes easily in Windows. The Sysinternals suite has a tool called Pipelist and it works exactly as advertised. Pipelist can enumerate open pipes at runtime but can leave you in the dark about pipe connections that are opening and closing frequently. Another tool also in the Sysinternals suite called Process Explorer allows you to view open pipes but only shows them when you are actively monitoring a given process. IO Ninja fills the void with two great plugins it offers.
An Introduction to IO Ninja
When you fire up IO Ninja and start a new session, you’re presented with an expansive list of plugins as shown below. I will be focusing on two of the plugins under the “File Systems” section in this blog: Pipe Monitor and Pipe Server.
Before starting a new session, you may need to check the “Run as Administrator” box if the pipes you want to interact with require elevated privileges to read or write. You can inspect the permissions on a given pipe with the accesschk tool from the Sysinternals Suite:
The powerful Pipe Monitor plugin in IO Ninja allows you to record communication, as well as apply filters to the log. The Pipe Server plugin allows you to connect to the client side of a pipe.
IO Ninja: Pipe Monitor
The following screenshot provides a look at the Pipe Monitor plugin that comes by default with IO Ninja.
In the above screenshot, I added a process filter (*chrome*) and started recording before I opened the application. You can also filter on a filename ( name of the pipe), PID, or file ID. After starting Chrome, data started flowing between several pipe instances. This is a terrific way to dynamically gather an understanding of what data is going through each pipe and when those pipes are opened and closed. I found this helpful when interacting with antivirus agents and wanted to know what pipes were being opened or closed based on certain actions from the user, such as performing a system scan or update. It can also be interesting to see the content going across the pipe, especially if it contains sensitive data and the pipe has a weak ACL.
It can also help a developer debug an application and find issues in real-time like unanswered pipe connections or permission issues as shown below.
Using IO Ninja’s find text/bin feature to search for “cannot find”, I was able to identify several connections in the log below where the client side of a connection could not find the server side. In my experience, many applications make these unanswered connections out of the box.
What made this interesting was that the process updatesrv.exe, running as NT AUTHORITY\SYSTEM, tried to open the client side of a named pipe but failed with ERROR_FILE_NOT_FOUND. We can fill the void by creating our own server with the name it is looking for and then triggering the client connection by initiating an update within the user interface.
As a low privileged user, I am now able to send arbitrary data to a highly privileged process using the Pipe Server plugin. This could potentially result in a privilege escalation vulnerability, depending on how the privileged process handles the data I am sending it.
IO Ninja: Pipe Server
The Pipe Server plugin is powerful as it allows you to send data to specific client connections from the server side of a pipe. The GUI in IO Ninja allows you to select which conversation you’d like to interact with by selecting from a drop-down list of Client IDs. Just like with the Pipe Monitor plugin, you can apply filters to clean up the log. Below you’ll find a visual from the Pipe Server plugin after starting the server end of a pipe and getting a few client connections.
In the bottom right of the previous image, you can see the handy packet library. Other related IO Ninja features include a built-in hex editor, file- and script-based transmission, and packet templating via the packet template editor.
The packet template editor allows you to create packet fields and script custom actions using the Jancy scripting language. Fields are visualized in the property grid as shown above on the bottom left-hand side of the image, where they can be edited. This feature makes it significantly easier to create and modify packets when compared to just using a hex editor.
This post only scratches the surface of what IO Ninja can do by highlighting just two of the plugins offered. The tool is scriptable and provides an IDE that encourages users to build, extend or modify existing plugins. The plugins are open source and available in a link listed at the end of the blog. I hope that this post inspires you to take a closer look at NPFS as well as the IO Ninja tool and the other plugins it offers.
Keep an eye out for future blogs where I will go into more detail on vulnerabilities I have found in this area. Until then, you can follow me @izobashi and the team @thezdi on Twitter for the latest in exploit techniques and security patches.
Additional information about IO Ninja can be found on their website. All of IO Ninja’s plugins are open source and available here.
If you are interested in learning more you can also check out the following resources which I found helpful.
The second Tuesday of the month is upon us, and with it comes the latest security patches from Adobe and Microsoft. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.
Adobe Patches for November 2021
For November, Adobe released only three patches correcting four CVEs in Creative Cloud Desktop, InCopy, and RoboHelp. The patch for Creative Cloud fixes a single Important-rated denial-of-service (DoS) bug. The InCopy patch fixes two bugs, including a Critical-rated code execution. The release for RoboHelp Server is listed as a security hotfix rather than a security patch, but it’s not clear why there’s a difference in the nomenclature. Either way, a Critical-rated arbitrary code execution bug is being fixed, so if you still use RoboHelp, apply this hotfix.
If this seems especially light, Adobe did release fixes for more than 80 CVEs in late October for critical code execution flaws, privilege escalation, denial-of-service, and memory leaks across multiple products. None of these fixes were listed as under active attack, so it’s unclear why Adobe released so many patches out of band.
None of the patches released today by Adobe are listed as being publicly known or under active attack at the time of release.
Microsoft Patches for November 2021
For November, Microsoft released patches today for 55 new CVEs in Microsoft Windows and Windows Components, Azure, Azure RTOS, Azure Sphere, Microsoft Dynamics, Microsoft Edge (Chromium-based), Exchange Server, Microsoft Office and Office Components, Windows Hyper-V, Windows Defender, and Visual Studio.
Historically speaking, 55 patches in November is a relatively low number. Last year, there were more than double this number of CVEs fixed. Even going back to 2018 when there were only 691 CVEs fixed all year, there were more November CVEs fixed than in this month. Given that December is typically a slower month patch-wise, it causes one to wonder if there is a backlog of patches awaiting deployment due to various factors. It seems odd that Microsoft would be releasing fewer patches after seeing nothing but increases across the industry for years.
Of the CVEs patched today, six are rated Critical and 49 are rated as Important in severity. Four of these bugs came through the ZDI program. Four of these bugs are listed as publicly known two are listed as under active exploit at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the two bugs listed as under active attack:
- CVE-2021-42321 – Microsoft Exchange Server Remote Code Execution Vulnerability This Exchange bug is listed by Microsoft as currently under active attack; however, authentication is listed as a requirement. As with all Exchange bugs in the wild, we urge Exchange admins to test and deploy the patches as soon as possible. Microsoft has also published this blog to aid Exchange administrators with their patch deployment.
- CVE-2021-42292 – Microsoft Excel Security Feature Bypass Vulnerability This patch fixes a bug that could allow code execution when opening a specially crafted file with an affected version of Excel. This is likely due to loading code that should be behind a prompt, but for whatever reason, that prompt does not appear, thus bypassing that security feature. It’s unclear if it’s a malicious macro or some other form of code loading within a spreadsheet, but I would be reluctant to open any unexpected attachments for a while. This is especially true for users of Office for Mac because there currently is no patch available for Mac users. They must wait for a future update to be protected. It’s also interesting to note Microsoft lists this as under active attack, but the CVSS rating lists the exploit code maturity as “proof of concept”.
- CVE-2021-26443 – Microsoft Virtual Machine Bus (VMBus) Remote Code Execution Vulnerability This patch addresses a guest-to-host escape through the virtual machine bus (VMBus). A user on a guest VM can send a specially crafted communication on the VMBus channel to the host OS that could result in arbitrary code execution on the underlying host. With a CVSS of 9.0, this is one of the more severe vulnerabilities fixed this month. Based on the CVE number, this has been known to Microsoft for a few months.
- CVE-2021-38666 – Remote Desktop Client Remote Code Execution Vulnerability While not as severe as a bug in the RDP Server, this bug in the RDP client is still worth prioritizing. If an attacker can lure a user to connect to a malicious RCP server, they could execute code on the connecting RDP client system. Again, this doesn’t reach the level of the Bluekeep bugs, but definitely something to watch.
Here’s the full list of CVEs released by Microsoft for November 2021:
Looking at the remaining Critical-rated patches for November, the entries for Chakra and Dynamics (On-Prem) stand out. The Chakra patch fixes a bug that could allow an attacker to execute their own code on affected systems, usually in a browse-and-own or open-and open-and-own scenario. Microsoft doesn’t make it clear how the code execution on Dynamics would occur but considering the types of infrastructure and supply chains managed by Dynamics, this Critical-rated bug should be taken seriously. The patch for Defender should be of concern for those disconnected from the Internet, but for others will likely not need to take any action. Microsoft regularly updates the Malware Protection Engine, so if your system is connected to the Internet, it should have already received an update. You should still verify the version and manually apply the update if needed. Finally, Microsoft is releasing its update of an OpenSSL patch from August. This is a good reminder that if you ship open-source code, you should always check to ensure you’re shipping the latest, most secure version.
Moving on to the other code execution bugs, two can be found in the 3D Viewer. These were reported by ZDI’s Mat Powell, but Microsoft failed to meet our disclosure timeline. That’s why these are listed as publicly known as we published some details about these bugs back in June and July. The other code execution bugs mostly reside in one of the Office components. In these cases, opening a specially crafted file could lead to code execution. The final code exec bug resides in NTFS, but it’s not clear from Microsoft how this could work. They list no user interaction required, while also listing the vector as local. This removes the open-and-own scenario as well as the browse-to-a-remote-folder vector. This bug came through the THEORI team, who had quite the showing at the recent Pwn2Own Austin. Hopefully, they will release additional details in the near future.
There are 20 elevation of privilege (EoP) bugs patches in this release, with the most severe impacting NTFS, Active Directory Domain Service, and Azure RTOS. The NTFS bugs are confusing as they list no user interaction needed while still being a local vector with low privileges required. Those are the same ratings for the NTFS RCE bug, so it’s not clear how these are different. The patches for ADDS also should not be ignored as bugs here could make lateral movement within an enterprise easier. It’s also not clear how many people are using Azure RTOS, but they have a tough road ahead of them. They can’t just apply a patch. Instead, they will need to recompile their project with updated USBX source code then redeploy the new code. Failure to do so could result in an EoP if an attacker plugged in a malicious USB device. The remaining EoP patches fix more traditional issues where an attacker is required to log on to a system and run their own code to take advantage of an affected component.
There are some heavy-hitting information disclosure bugs being patched this month. First up are three patches for Azure RTOS that could lead to info disclosure, although Microsoft does not state what type of information could be disclosed. Again, a recompile and redeploy is required to stop a malicious USB attack. More disturbingly, there are two publicly known info disclosure bugs in RDP that could allow read access to Windows RDP client passwords by RDP administrators. That could be a game-changer to inside threats since we all know users would NEVER reuse a password – at least that’s what they swear to me (and this time, they mean it).
There’s also an info disclosure bug being fixed in FSLogix. This bug could allow an attacker to disclose user data redirected to the profile or Office container via FSLogix Cloud cache, which includes user profile settings and files. Surprisingly, only one of the 10 info disclosure bugs results in a leak consisting of unspecified memory contents.
Three info disclosure impact Azure Sphere devices, but these devices should receive updates automatically if they are connected to the internet. There’s also a tampering bug being fixed in Azure Sphere, but again, provided you are connected to the internet, there’s no action to take.
Looking at patches for denial-of-service (DoS) bugs, the most important is the one impacting Windows – not a subcomponent – Windows. A remote attacker with no permissions could create a DoS on all supported Windows versions (including Windows 11). It’s not clear if this would result in a system hang or a reboot, but either way, do not bypass this impactful DoS. The other two DoS bugs impact Hyper-V, and one of those requires GRE to be enabled.
Besides the Excel bug already mentioned, there’s only one other Security Feature Bypass (SFB) being fixed in November. This impacts Windows Hello on Windows 10 and Server 2019 systems. No details are provided, but just by the component and impact, it seems there’s a way to access affected systems without using a PIN, facial recognition, or fingerprint. If you use this feature for authentication, you may want to disable it until you are sure all affected systems are patched.
Finally, the November release contains fixes for four spoofing bugs, including one for Exchange that must be obvious when you look for it as eight different researchers are all acknowledged by Microsoft for reporting it. Of course, they provide no info on what sort of spoofing is being fixed by this patch, the other Exchange spoofing bug, or by the Edge (Chrome-based) spoofing bug while on IE Mode. Microsoft does state the fix for the Power BI Report Server addresses a Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) vulnerability with the template file.
No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV90001.
The next Patch Tuesday falls on December 14, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!
Welcome to Pwn2Own Austin 2021! This year’s consumer-focused event is our largest ever with 58 total entries from 22 different contestants. As with all of our contests now, you can follow along live on YouTube and Twitch. With attempts going every 30 minutes, is should be an exciting few days.
As always, we started the contest with a random drawing to determine the order of attempts. You can view the results here. Our schedule is so packed, we’ve extended to contest to a fourth day. The complete schedule for the contest is below (all times Eastern [GMT -4:00]). We will update this schedule with results as they become available.
Note: All times subject to change - You can watch the event live here.
For a quick review of Day One, check out our recap video here.
1000 - Sam Thomas (@_s_n_t) from team Pentest Limited (@pentestltd) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
SUCCESS - Sam used a three-bug chain that included an unsafe redirect and a command injection to get code execution on the Western Digital My Cloud Pro Series PR4100. This successful demonstration earns him $40,000 and 4 Master of Pwn points.
1030 - Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the WAN interface of the Cisco RV340 in the router category
SUCCESS - Bien Pham leveraged a logic error to compromise the WAN interface of the Cisco RV340 router. He earns $30,000 and 3 Master of Pwn points.
1100 - The Synacktiv (@Synacktiv) team targeting the Canon ImageCLASS MF644Cdw in the printer category
SUCCESS - The Synacktiv team used a heap overflow to take over the Canon ImageCLASS printer and bring home the first Printer Category win in Pwn2Own history. They earn $20,000 and 2 points towards Master of Pwn.
1130 - trichimtrich and nyancat0131 targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi in the router category
SUCCESS - trichimtrich used an Out-Of-Bounds (OOB) Read to get a root shell via the LAN interface of the TP-Link AC1750 router. This earns him $5,000 and 1 point towards Master of Pwn.
1200 - The THEORI Team (@theori_io) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
SUCCESS - The THEORI team combined an OOB Read and a stack-based buffer overflow to take over the Western Digital My Cloud Pro Series PR4100 NAS device. They used a unique bug chain, so they earn the full $40,000 and 4 points towards Master of Pwn.
1230 - Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the LAN interface of the Cisco RV340 in the router category
SUCCESS - Bien Phamfrom Team Orca of Sea Security used a three-bug chain, including an auth bypass and a command injection, to take over the LAN interface of the Cisco RV340. This effor earns him $15,000 and 2 more Master of Pwn points.
1300 - Ken Gannon (@yogehi) of F-Secure Labs (@fsecurelabs) targeting the Samsung Galaxy S21 in the Mobile Phone category
FAILURE - Unfortunately, Ken could not get his exploit to work within the time allotted.
1400 - Bugscale targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
COLLISION - The exploit chain used by Bugscale included known bugs. They still earn $20,000 and 2 Master of Pwn points.
1430 - Benjamin Grap (@blightzero), Hanno Heinrichs (@HeinrichsH), and Lukas Kupczyk (@___luks___) of CrowdStrike Intelligence targeting the LAN interface of the Cisco RV340 in the router category
COLLISION - The exploit chain used by the CrowdStrike team included some known bugs. They still earn $10,000 and 1.5 Master of Pwn points.
SUCCESS - The DEVCORE team used an integer underflow to gain code execution on the Sonos One Speaker. They earn $60,000 and 6 points towards Master of Pwn.
1700 - Gaurav Baruah (@_gauravb_) targeting the WAN interface of the Cisco RV340 in the router category
COLLISION - A partial collision. One of the bugs used by Gaurav was previously known. He still $22,500 and 2.5 Master of Pwn points.
1730 - The THEORI Team (@theori_io) targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category
SUCCESS - The THEORI Team used a stack-based buffer overflow to get code execution on the 3TB My Cloud Home Personal Cloud from WD. This earns them $40,000 and 4 Master of Pwn points, giving them a 1 day total of $80,000 and 8 points.
1800 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the HP Color LaserJet Pro MFP M283fdw in the printer category
SUCCESS - The DEVCORE team used a stack-based buffer overflow to gain code execution on the HP Color LaserJet Pro. They earn another $20,000 and 2 Master of Pwn points, bringing their day 1 total to $100,000 and 10 Master of Pwn points.
Due to time limitations and resource constraints, the following attempts will occur off the live stream during the evening. Results of these attempts will still be reported here and on Twitter.
— trichimtrich and nyancat0131 targeting the LAN interface of the NETGEAR R6700v3 in the router category
SUCCESS - trichimtrich leveraged an integer overflow to gain code execution via the LAN interface of the NETGEAR R6700v3 router. They win another $5,000 and 1 more point towards Master of Pwn.
— Flashback Team of Pedro Ribeiro (@pedrib1337) && Radek Domanski (@RabbitPro) targeting the WAN interface of the NETGEAR R6700v3 in the router category
FAILURE - Unfortunately, Team Flashback could not get their exploit to work within the time allotted.
— Bugscale targeting the LAN interface of the NETGEAR R6700v3 in the router category
SUCCESS - The Bugscale team combined an authorization bypass with a command injection bug to get code execution on the LAN interface of the NETGEAR router. They earn $5,000 and 1 Master of Pwn point.
— crixer (@pwning_me), Axel Souchet (@0vercl0k), @chillbro4201, and friends from Mofoffensive Research Team targeting the LAN interface of the NETGEAR R6700v3 in the router category
SUCCESS - The Mofoffensive Research Team combining a heap overflow and a stack-based buffer overflow to gain code execution on the LAN interface of the NETGEAR R6700 router. Their efforts earn $5,000 and 1 Master of Pwn point.
Wednesday, November 3
For a video overview of the Day Two results, see here.
1000 - NCC Group EDG (Alex Plaskett, Cedric Halbronn, Aaron Adams) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
SUCCESS - The NCC Group leveraged a memory corruption bug three different ways (and overcame a timing issue) to get code execution on the Western Digital My Cloud Pro Series PR4100. They earn themselves $40,000 and 4 Master of Pwn points.
1030 - Flashback Team of Pedro Ribeiro (@pedrib1337) && Radek Domanski (@RabbitPro) targeting the WAN interface of the Cisco RV340 in the router category
SUCCESS - The Flashback team of Pedro and Redek used an impressive stack-based buffer overflow to get code execution on the WAN interface of the Cisco RV340 router. They earn $30,000 and 3 Master of Pwn points.
1100 - Nicolas Devillers (@nikaiw), Jean-Romain Garnier, and Raphael Rigo (@_trou_) targeting the Canon ImageCLASS MF644Cdw in the printer category
SUCCESS - The team of Nicolas Devillers, Jean-Romain Garnier, and Raphael Rigo obtained code execution on the Canon ImageCLASS printer through a stack-based buffer overflow. This unique bug chain earns them $20,000 and 2 Master of Pwn points.
1130 - crixer (@pwning_me), Axel Souchet (@0vercl0k), @chillbro4201, and friends from Mofoffensive Research Team targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi Router in the router category
FAILURE - Unfortunately, the Mofoffensive Team could not get his exploit to work within the time allotted.
1200 - The Synacktiv (@Synacktiv) team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
SUCCESS - The Synacktiv team leveraged a configuration error bug to get code execution on the PR411. They earn $40,000 and 4 Master of Pwn points.
1230 - Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab targeting the LAN interface of the Cisco RV340 in the router category
SUCCESS - Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab used 3 unique bugs, incuding an authorization bypass and a commange injection, to get code execution on the Cisco RV340 via the LAN interface. They earn $15,000 and 2 Master of Pwn points.
1300 - The STARLabs Team targeting the Samsung Galaxy S21 in the mobile phone category
COLLISION - The exploit chain used by the STARLabs team included a bug known by the vendor. They still earn $25,000 and 2.5 Master of Pwn points.
1400 - The Synacktiv (@Synacktiv) team targeting the Sonos One Speaker in the home automation category
SUCCESS - The Synacktiv team used a stack-based buffer over to compromise the Sonos One speaker and play us a tune. They earn $60,000 and 6 Master of Pwn points.
1430 - trichimtrich and nyancat0131 targeting the WAN interface of the Cisco RV340 in the router category
SUCCESS - trichmitrich used nearly all the time on the clock, but his command injection bug is unique. His takeover of the Cisco RV340 via the WAN interface earns him $30,000 and 3 Master of Pwn points.
1500 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
COLLISION - The DEVCORE team successfully exploited the WD PR411, but the bugs they leveraged had been previously used in the competition. Their work still earns them $20,000 and 2 Master of Pwn points.
1530 - The STARLabs Team targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi Router in the router category
COLLISION - The STARLabs team exploited the LAN interface of the TP-Link AC1750 router, but they used a known bug. This still nets them $2,500 and .5 Master of Pwn points.
1600 - The Synacktiv (@Synacktiv) team targeting the Lexmark MC3224i in the printer category
SUCCESS - The Synacktiv team combined three unique bugs, including an unprivileged access bug and a command injection bug, to get code execution on the Lexmark MC3224i printer. They earn $20,000 and 2 more Master of Pwn points.
1700 - The STARLabs Team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
COLLISION - The exploit chain used by Nguyễn Hoàng Thạch (hi_im_d4rkn3ss) of STARLabs team included bugs previously used in the contest. They still earn $20,000 and 2 Master of Pwn points.
1745 - The Synacktiv (@Synacktiv) team targeting the HP Color LaserJet Pro MFP M283fdw in the printer category
COLLISION - The exploit chain used by the Synacktiv team included a bug used earlier in the competition. They still earn $10,000 and 1 Master of Pwn point.
Due to time limitations and resource constraints, the following attempts will occur off the live stream during the evening. Results of these attempts will still be reported here and on Twitter.
— Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
FAILURE - Unfortunately, the IoT Inspector Research team could not get their exploit to work within the time allotted.
— The STARLabs Team targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category
COLLISION - The exploit chain used by Nguyễn Hoàng Thạch (hi_im_d4rkn3ss) and Phan Thanh Duy (PTDuy) of STARLabs took over the 3TB My Cloud Home Personal Cloud from WD using a bug previously seen in the competition. They still earn $20,000 and 2 Master of Pwn points.
— Diffense Team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category
COLLISION - In their Pwn2Own debut, the Diffense Team runs into a collision. They were able to exploit the Western Digital My Cloud Pro Series PR4100, but the bug they leveraged was also used on Day 1. They still earn $20,000 and two Master of Pwn points in their debut effort.
SUCCESS - The team from F-Secure Labs used a single stack-based buffer overflow to take over the printer and turn it into a jukebox. They earn $20,000 and 2 Master of Pwn points.
1200 - The STARLabs Team targeting the beta version of the 3TB My Cloud Home Personal Cloud from WD in the NAS category
SUCCESS - The STARLabs team of Nguyễn Hoàng Thạch (@hi_im_d4rkn3ss) and Billy Jheng Bing-Jhong
(@st424204) combined an OOB Read and a heap-based buffer overflow to exploit the beta version of the 3TB My Cloud Home Personal Cloud from WD. They earn $45,000 and 5 Master of Pwn points.
1230 - Stephen Fewer (@stephenfewer) of Relyze Software Limited (www.relyze.com) targeting the LAN interface of the Cisco RV340 in the router category
COLLISION - The four-bug exploit chain used by the Stephen included some known bugs. His successful demonstration still earns him $10,000 and 1.5 Master of Pwn points.
1300 - Sam Thomas (@_s_n_t) from team Pentest Limited (@pentestltd) targeting the Samsung Galaxy S21 in the mobile phone category
SUCCESS - Sam used a three-bug chain to get code execution on the Sumsung Galaxt S21. This successful demonstration earns him $50,000 and 5 Master of Pwn points.
1400 - The Synacktiv (@Synacktiv) team targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category
COLLISION - The Synacktiv team used a two-bug chain to compromise the 3TB My Cloud Home Personal Cloud, but one of the bugs had been used prior in the contest. Their demonstration still earns them $20,000 and 2 Master of Pwn points.
1500 - Chris Anastasio (@mufinnnnnnn) targeting the Lexmark MC3224i in the printer category
COLLISION - Chris used a four-bug chain to compromise the Lexmark printer, but one of the bugs had been used prior in the contest. His efforts still earns him $17,500 and 1.75 Master of Pwn points.
1600 - The STARLabs Team targeting the LAN interface of the NETGEAR R6700v3 in the router category
FAILURE - Unfortunately, the STARLabs Team could not get their exploit to work within the time allotted.
1700 - Stephen Fewer (@stephenfewer) of Relyze Software Limited (www.relyze.com) targeting the LAN interface of the NETGEAR R6700v3 in the router category
SUCCESS - Stephen used an uninitialized variable to get a root shell via the LAN interface of the NETGEAR R6700v3 router. He earns $5,000 and 1 Master of Pwn point.
Due to time limitations and resource constraints, the following attempts will occur off the live stream during the evening. Results of these attempts will still be reported here and on Twitter.
— The Synacktiv (@Synacktiv) team targeting the WAN interface of the NETGEAR R6700v3 in the router category
SUCCESS - The Synactiv team used an improper certificate validation and a stack-based buffer overflow to compromise the NETGEAR router via the WAN interface. They earn $20,000 and 2 critical Master of Pwn points.
— Flashback Team of Pedro Ribeiro (@pedrib1337) && Radek Domanski (@RabbitPro) targeting the LAN interface of the NETGEAR R6700v3 in the router category
COLLISION - Pedro and Radek leveraged 2 bugs to exploit the NETGEAR R6700 router via the LAN interface, but the path traversal they chose was an N-day. This still earns them $3,750 and .75 Master of Pwn points.
Friday, November 5
For a quick overview of Day Four results, see the recap video here.
1000 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category
SUCCESS - The DEVCORE team combined an OOB Read and an OOB Write to sucessfully exploit the 3TB My Cloud Home Personal Cloud from WD. This unique bug chain earned them $40,000 and 4 Master of Pwn points.
1030 - Diffense Team targeting the LAN interface of the Cisco RV340 in the router category
COLLISION - The Diffense Team leveraged 4 bugs to exploit the Cisco RV340 router via the LAN interface, but some of the bugs had been seen earlier in the conference. This still earns them $10,000 and 1.5 Master of Pwn points.
1100 - Benjamin Grap (@blightzero), Hanno Heinrichs (@HeinrichsH), and Lukas Kupczyk (@___luks___) of CrowdStrike Intelligence targeting the Lexmark MC3224i in the printer category
COLLISION - The team from CrowdStrike had no problem taking over the Lexmark printer using a three-bug chain, however all of the bused used had been seen earlier in the contest. Their effort wins them $10,000 and 1 Masrer of Pwn point.
1200 - The NullRiver team of Xin’an Zhou, Xiaochen Zou, Zhiyun Qian targeting the LAN interface of the NETGEAR R6700v3 in the router category
SUCCESS - The team used a pair of bugs to execute code via the LAN interface. They earn $5,000 and 1 Master of Pwn point.
1230 - Final wrap-up and the crowning of the Master of Pwn
Congratulations to the Synacktiv team for being crowned Master of Pwn! It was a tight race, but tehir combined efforts held off all challengers.
Thanks again to our partners Western Digital as well as our sponsor Synology. Thanks also to the researchers who participate and to the vendors for providing fixes for what’s discovered during the contest. As a reminder, vendors have 90 days to produce a fix for all vulnerabilities reported.
Our inaugural Pwn2Own Miami was held back in January 2020 at the S4 Conference, and we had a fantastic time as we awarded over $280,000 USD in cash and prizes for 24 unique 0-day vulnerabilities. At the time, we couldn’t wait to get back to South Beach for the next contest. Of course, the rest of 2020 happened, so those plans were put on hold. Today, we are excited to announce Pwn2Own Miami returns in person to S4 on January 25-27, 2022. As of now, we are planning on running the contest in Miami and hope to have contestants in the room with us. However, we know not everyone is ready to hit the road again, so we will also still allow remote participation.
This will be our first “hybrid” event with contestants participating locally (hopefully) and remotely. Even though we will be at the Fillmore, we realize not everyone can be there with us. If you have either travel restrictions or travel safety concerns, you can opt to compete remotely. You will still need to register before the contest registration deadline (January 21, 2022) and submit a detailed whitepaper completely explaining your exploit chain and instructions on how to run the entry. A member of the ZDI staff in Miami will run your exploit for you. All attempts will be filmed and available for viewing by the contestant and the vendor. As in the past, we will work with remote contestants to monitor the attempt in real-time via a phone call or video chat. Please note that since you are not in person, changes to exploits/scripts/etc. will not be possible, which could lower your chance of winning should something unexpected occur. Otherwise, the contest will run as we have in the past. We will have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there.
This contest is not possible without the participation and help from our partners within the ICS community, and we would like to especially thank Schneider Electric, OPC Foundation, Inductive Automation, and Triangle Microworks for their expertise and guidance. Their cooperation is essential in ensuring we have the right categories and targets to create a meaningful test of the security of these products and protocols. Pwn2Own Miami seeks to harden these platforms by revealing vulnerabilities and providing that research to the vendors. The goal is always to get these bugs fixed before they’re actively exploited by attackers. These vendors have been instrumental in making that goal a reality.
The 2022 edition of Pwn2Own Miami has four categories:
- Control Server - OPC Unified Architecture (OPC UA) Server - Data Gateway - Human Machine Interface (HMI)
Control Server Category
The Control Server category covers server solutions that provide connectivity, monitoring, and control across disparate Programmable Logic Controller (PLC) and other field systems. An attacker who took over a control server could alter the process in any way they wanted and would only be limited by their engineering and automation skills. The targets in this category include the control servers from Iconics and Inductive Automation.
An attempt in this category must be launched against the target’s exposed network services from the contestant’s laptop within the contest network or by opening a file within the target on the contest laptop. The files that are eligible to be opened must be file types that are handled by default by the target application. A successful entry in the category must result in arbitrary code execution.
OPC UA Server Category
The OPC Unified Architecture (UA) is a platform-independent, service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. OPC UA serves as the universal translator protocol in the ICS world. It is used by almost all ICS products to send data between disparate vendor systems. OPC UA was designed to be more secure than the previously used DCOM and is gaining in popularity. This category has four products: the Unified Automation C++ Demo Server, the OPC Foundation OPC UA .NET Standard, the Prosys OPC US SDK for Java, and the Softing Secure Integration Server.
A successful entry in the category must result either in a denial-of-service condition, arbitrary code execution or in a bypass of the trusted application check that occurs after the creation of a secure channel. These types of devices usually restrict who can connect, so bypassing the application check becomes a prime target for attackers.
Data Gateway Category
This category focuses on devices that connect other devices of varying protocols. There are two products in this category. The first is the Triangle Microworks SCADA Data Gateway product. Triangle Microworks makes the most widely used DNP3 protocol stack. The other is the Kepware KEPServerEx server. KEPServerEX is an industry-leading connectivity platform that provides a single source of industrial automation data to multiple applications.
A successful entry in the category must result in arbitrary code execution.
Human Machine Interface (HMI)
If you’re familiar with ICS at all, you’ve likely heard of the Human Machine Interface (HMI) system. The HMI connects the operator of an ICS to the various hardware components of the ICS. Attackers that take over the HMI can also prevent the operator from seeing process issues in the ICS until it is too late. Our HMI category consists of the AVEVA Edge and the Schneider Electric EcoStruxure Operator Terminal Expert.
A successful entry in this category must result in arbitrary code execution.
Master of Pwn
No Pwn2Own contest would be complete without crowning a Master of Pwn, and Pwn2Own Miami is no exception. Earning the title results in a slick trophy and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2023, which includes a one-time bonus estimated at $25,000).
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 a contestant decides to withdraw from the registered attempt before the actual attempt, the Master of Pwn points for that attempt will be divided by 2 and deducted from the contestant's point total for the contest. Since Pwn2Own is now often a team competition, along with the initial deduction of points, the same number of Master of Pwn points will also be deducted from all contestant teams from the same company.
The Complete Details
The full set of rules for Pwn2Own Miami 2022 are available here. They may be changed at any time without notice. We encourage entrants to read the rules thoroughly and completely should they choose to participate.
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 Twitter, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing to determine the contestant order. Again, this random drawing will not impact awards. Contest registration closes at 5:00 p.m. Eastern Standard Time on January 21st, 2022.
We’ll be live blogging and tweeting results throughout the competition. Be sure to keep an eye on the blog for the latest results. Follow us on Twitter at @thezdi and @trendmicro, and keep an eye on the #P2OMiami hashtag for continuing coverage.
We look forward to seeing everyone again in Miami, and we look forward to seeing what new exploits and attack techniques they bring with them.
Our ICS-Themed Pwn2Own Contest Returns to Miami in 2022
Over the past few months, Adobe has patched several remote code execution bugs in Adobe Acrobat and Reader that were reported by researcher Mark Vincent Yason (@MarkYason) through our program. Two of these bugs, in particular, CVE-2021-28632 and CVE-2021-39840, are related Use-After-Free bugs even though they were patched months apart. Mark has graciously provided this detailed write-up of these vulnerabilities and their root cause.
This blog post describes two Adobe Reader use-after-free vulnerabilities that I submitted to ZDI: One from the June 2021 patch (CVE-2021-28632) and one from the September 2021 patch (CVE-2021-39840). An interesting aspect about these two bugs is that they are related – the first bug was discovered via fuzzing and the second bug was discovered by reverse engineering and then bypassing the patch for the first bug.
CVE-2021-28632: Understanding Field Locks
One early morning while doing my routine crash analysis, one Adobe Reader crash caught my attention:
After a couple of hours minimizing and cleaning up the fuzzer-generated PDF file, the resulting simplified proof-of-concept (PoC) was as follows:
PDF portion (important parts only):
The crash involved a use-after-free of CPDField objects. CPDField objects are internal AcroForm.api C++ objects that represent text fields, button fields, etc. in interactive forms.
In the PDF portion above, two CPDField objects are created to represent the two text fields named fieldParent and fieldChild. Note that the created objects have the type CTextField, a subclass of CPDField, which is used for text fields. To simplify the discussion, they will be referred to as CPDField objects.
An important component for triggering the bug is that fieldChild should be a descendant of fieldParent by specifying it in the /Kids key of the fieldParent PDF object dictionary (see [A] above) as documented in the PDF file format specification:
Another important concept relating to the bug is that to prevent a CPDField object from being freed while it is in use, an internal property named LockFieldProp is used. Internal properties of CPDField objects are stored via a C++ map member variable.
If LockFieldProp is not zero, it means that the CPDField object is locked and can't be freed; if it is zero or is not set, it means that the CPDField object is unlocked and can be freed. Below is the visual representation of the two CPDField objects in the PoC before the field locking code (discussed later) is called: fieldParent is unlocked (LockFieldProp is 0) and is in green, and fieldChild is also unlocked (LockFieldProp is not set) and is also in green:
One of the first actions of the textSize property setter in AcroForm.api is to call the following field locking code against fieldParent:
The above code locks the CPDField object passed to it by setting its LockFieldProp property to 1[AA].
After executing the field locking code, the lock state of fieldParent (locked: in red) and fieldChild (unlocked: in green) are as follows:
Note that in the later versions of Adobe Reader, the value of LockFieldProp is a pointer to a counter instead of being set with the value 1 or 0.
Next, the textSize property setter in AcroForm.api calls the following recursive CPDField method where the use-after-free occurs:
On the first call to the above method, the this pointer points to the locked fieldParentCPDField object. Because it has no associated widget [aa], the method performs a recursive call [cc] with the this pointer pointing to each of fieldParent's children [bb].
This first vulnerability was patched in June 2021 by Adobe and assigned CVE-2021-28632.
CVE-2021-39840: Reversing Patch and Bypassing Locks
I was curious to see how Adobe patched CVE-2021-28632, so after the patch was released, I decided to look at the updated AcroForm.api.
Upon reversing the updated field locking code, I noticed an addition of a call to a method that locks the passed field’s immediate descendants:
With the added code, both fieldParent and fieldChild will be locked and the PoC for the first bug will fail in freeing fieldChild:
While assessing the updated code and thinking, I arrived at a thought: since the locking code only additionally locks the immediate descendants of the field, what if the field has a non-immediate descendant?... a grandchild field! I quickly modified the PoC for CVE-2021-28632 to the following:
PDF portion (important parts only):
And then loaded the updated PoC in Adobe Reader under a debugger, hit go... and crash!
The patch was bypassed, and Adobe Reader crashed at the same location in the previously discussed recursive method where the use-after-free originally occurred.
Upon further analysis, I confirmed that the illustration below was the state of the field locks when the recursive method was called. Notice that fieldGrandChild is unlocked, and therefore, can be freed:
This second vulnerability was patched in September 2021 by Adobe and assigned CVE-2021-39840.
Controlling Field Objects
When I submitted my reports to ZDI, I included a second PoC that demonstrates full control of the CPDField object and then dereferences a controlled, virtual function table pointer:
Implementation of object trees, particularly those in applications where the objects can be controlled and destroyed arbitrarily, is prone to use-after-free vulnerabilities. For developers, special attention must be made to the implementation of object reference tracking and object locking. For vulnerability researchers, they represent opportunities for uncovering interesting vulnerabilities.
Thanks again to Mark for providing this thorough write-up. He has contributed many bugs to the ZDI program over the last few years, and we certainly hope to see more submissions from him in the future. Until then, follow the team for the latest in exploit techniques and security patches.
CVE-2021-28632 & CVE-2021-39840: Bypassing Locks in Adobe Reader
Today, we are announcing the inclusion of the beta version of the Western Digital 3TB My Cloud Home Personal Cloud in our upcoming Pwn2Own Austin competition. Normally, devices under test are updated to the most recent publicly available patch level. This is still the case. However, our partners over at Western Digital wanted to include their upcoming beta software release in this year’s event. Consequently, we are adding the beta version as an available target in addition to the existing current version of the NAS device.
If a contestant can get code execution on the beta release of the Western Digital 3TB My Cloud Home Personal Cloud, they will earn $45,000 (USD) and 5 Master of Pwn points. There are some significant differences between the released software version and the beta version, so we suggest contestants upgrade their systems to test their exploits prior to the contest. To get the beta version installed on your NAS, you will need to enter your email address and the MAC address of your device in this form. Within a few hours, an automated process to update the NAS will begin. The updates will take you from 7.15.1-101 (current) to 7.16.0-216 and then the beta 8.0.0-301. Please note that not all features and applications included in the current version of the software release are available in the beta version.
Again, registration for the contest closes at 5:00 p.m. Eastern Daylight Time on October 29, 2021. A full copy of the rules – including this new change – is available 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. If you have any questions, please forward them to [email protected].
We believe exploiting the beta version of this software will not be trivial, but we certainly hope some tries. We look forward to seeing all the attempts to learn about the latest exploits and attack techniques on these devices.
The second Tuesday of the month is here, and that means the latest security updates from Adobe and Microsoft have arrived. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.
Adobe Patches for October 2021
For October, Adobe released six patches covering 10 CVEs in Adobe Reader, Acrobat Reader for Android, Adobe Campaign Standard, Commerce, Ops-CLI, and Adobe Connect. The update for Adobe Acrobat fixes four bugs in total – two rated Critical and two rated Moderate in severity. Two of these bugs were submitted through the ZDI program. The Critical-rated bugs could allow remote code execution while the Moderate-rated bugs could allow a privilege escalation. The update for Reader for Android fixes a single path traversal bug that could lead to code execution. All require some form of user interaction, such as browsing to a web page or opening a PDF.
Several cross-site scripting (XSS) bugs receive patches this month. The patch for Campaign Standard fixes a DOM-based XSS. The fix for Adobe Commerce addresses a stored XSS. The patch for Adobe Connect fixes two bugs, one of which is a reflective XSS. The other bug is more a more severe Critical-rated deserialization vulnerability that could allow remote code execution. The final Adobe patch for October fixes a Critical-rated deserialization bug in Ops-CLI, which is a python wrapper for Terraform, Ansible, and SSH for cloud automation.
None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.
Microsoft Patches for October 2021
For October, Microsoft released patches today for 71 new CVEs in Microsoft Windows and Windows Components, Microsoft Edge (Chromium-based), Exchange Server, .NET Core and Visual Studio, Microsoft Office Services and Web Apps, SharePoint Server, Microsoft Dynamics, InTune, and System Center Operations Manager. This is in addition to the eight CVEs patched by Microsoft Edge (Chromium-based) earlier this month and three previously released OpenSSL patches, which brings the October total to 82 CVEs – slightly down from last month. A total of 11 of these bugs were submitted through the ZDI program.
Of the 71 CVEs patched today, two are rated Critical, 68 are rated Important, and one is rated Low in severity. Three of today’s patches are listed as publicly known, while one is listed as being under active attack at the time of release. This is in addition to two of the Chromium bugs that were listed as under active attack when Chrome patched on September 30. For those wondering, this month does include patches for the recently released Windows 11 operating system.
Let’s take a closer look at some of the more interesting updates for this month, starting with the kernel bug that’s listed as under active attack:
- CVE-2021-40449 - Win32k Elevation of Privilege Vulnerability This patch corrected a kernel bug that could be used to escalate privileges on an affected system. Attackers typically use these types of bugs in conjunction with code execution bugs to take over a system. Considering the source of this report, this bug is likely being used in a targeted malware attack. We will also likely see more information about this bug and the associated attack within the next few days.
- CVE-2021-26427 - Microsoft Exchange Server Remote Code Execution Vulnerability The bug will certainly receive its fair share of attention, if nothing else, due to it being reported by the National Security Agency (NSA). Due to the similar CVE numbers, this bug was likely reported when they reported the more severe Exchange issues back in April. This bug is not as severe since this exploit is limited at the protocol level to a logically adjacent topology and not reachable from the Internet. This flaw, combined with the other Exchange bugs patched this month, should keep Exchange admins busy for a while.
- CVE-2021-40486 - Microsoft Word Remote Code Execution Vulnerability This patch corrects a bug that would allow code execution when a specially crafted Word document is viewed on an affected system. Although Microsoft lists user interaction required, the Preview Pane is also listed as an attack vector. This creates a much larger attack surface. When combined with a privilege escalation – like the one currently under active attack – this could be used to take over a target system. This bug came through the ZDI program and results from the lack of validating the existence of an object before performing operations on the object.
- CVE-2021-40454 - Rich Text Edit Control Information Disclosure Vulnerability We don’t often highlight information disclosure bugs, but this vulnerability goes beyond just dumping random memory locations. This bug could allow an attacker to recover cleartext passwords from memory, even on Windows 11. It’s not clear how an attacker would abuse this bug, but if you are using the rich text edit control in Power Apps, definitely test and deploy this bug quickly.
Here’s the full list of CVEs released by Microsoft for October 2021:
OpenSSL: CVE-2021-3450 CA certificate check
bypass with X509_V_FLAG_X509_STRICT
* Indicates this CVE had previously been released by a 3rd-party and is now being incorporated into Microsoft products.
The remaining Critical-rated bugs fix remote code execution vulnerabilities in Hyper-V server. One of these bugs could allow a guest OS to execute code on the host OS if the guest can cause a memory allocation error within the guest VM. Microsoft provides no details on the other bug, but it could also be used for a guest-to-host escape.
Looking at the remaining 18 code execution bugs, most are within the Office family and require a user to open a specially crafted file. One notable exception is a remote code execution bug in the DNS server. No user interaction is required to exploit this bug, but it does require high privileges, knocking this from Critical rated to Important. Microsoft lists this as publicly known but doesn’t state where which is frustrating. Knowing how widespread the knowledge of this vulnerability could benefit network defenders in creating a true risk assessment for their enterprise. There are also a couple of SharePoint code execution bugs receiving patches, but both require local privileges to exploit. These bugs came through the ZDI program, and we’ll have more details about them in the future. Another interesting RCE bug impacts the MSHTML platform. Although Internet Explorer is now “retired”, it lives on as the underlying MSHTML, EdgeHTML, and scripting platforms are still supported. There are even patches here for Windows 11. The legacy of IE hasn’t quite left us after all.
Moving on to the privilege escalation bugs, most require an attacker to log on to a system and run their own code to take advantage of an affected component. There’s another kernel bug here, and it is listed as publicly known – again with no additional information or details on the public disclosure. There’s also a privilege escalation in Exchange that also requires the attacker to be on an adjacent network. No user interaction is listed, so the likely scenario would be an insider threat.
There are five security feature bypass (SFB) bugs patched in this month’s release. The first is a vulnerability in RPC Runtime that could allow an attacker to bypass Extended Protection for Authentication provided by Service Principal Name (SPN) target name validation. A different bug in the Windows active directory could allow an attacker to bypass the Active Directory Federation Services (AD FS) BannedIPList entries for WS-Trust workflows. A different Active Directory bug could allow an attacker to bypass Active Directory domain permissions for Key Admins groups. The bypass in Intune requires the Intune Management Extension to be installed, but Microsoft provides no further details on what is being bypassed. Microsoft provides no details on what security feature is being bypassed on either the console Windows host or the Windows AppContainer Firewall. The lack of details around the container firewall vulnerability is especially frustrating since Microsoft lists this bug as publicly known.
The October release contains fixes for three new Denial-of-Service (DoS) bugs, each of which is significant. The first patch fixes a DoS vulnerability in TCP/IP that impacts all supported versions of Windows – including Windows 11. It’s not clear if this would allow an attacker to completely shut down a system, but without further details from Microsoft, network defenders should assume this worst-case scenario is likely. There’s a DoS bug in Exchange Server, and again, details are scarce. Since the CVSS score lists Availability=High, assume an attacker can abuse this bug to shut down an Exchange server. The final DoS bug getting fixed this month impacts Windows Network Address Translation (NAT) and was discovered by the same researchers that found the TCP/IP bug. Again, the CVSS score indicates this vulnerability could be used to take down a system, so test and deploy these patches quickly.
In addition to the one previously mentioned, there are 13 information disclosure bugs receiving fixes in this month’s release. Most of these simply result in leaks consisting of unspecified memory contents. However, if you’re running the web console of the System Center Operations Manager (SCOM), you definitely want to pay attention to the bug that could disclose file content on an affected system.
The October release is rounded out by fixes for six spoofing bugs and two cross-site scripting (XSS) bugs. Microsoft provides no details on what may be spoofed for any of these vulnerabilities, but the ones for Print Spooler and Exchange stand out. There are only a couple of print spooler bugs in this month’s release, so perhaps the days of PrintNightmare are finally behind us. The only clue we have for the impact of the Exchange spoofing bug is the CVSS rating of Confidentiality=High. This implies a total loss of confidentiality, which is not something you want to be associated with your Exchange server. The remaining spoofing bugs read very close to XSS bugs, including the rare Low severity fix for SharePoint Server.
No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV90001.
The next Patch Tuesday falls on November 9, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!
In June of 2021, Microsoft released a patch to correct CVE-2021-26420 – a remote code execution bug in the supported versions of Microsoft SharePoint Server. This bug was reported to the ZDI program by an anonymous researcher and is also known as ZDI-21-755. This blog takes a deeper look at the root cause of this vulnerability.
Before this patch being made available, this vulnerability could be used by an authenticated user to execute arbitrary .NET code on the server in the context and permissions of service account of SharePoint web application. For successful attack, the attacker should have “Manage Lists” permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permissions.
SharePoint workflows are pre-programmed mini-applications that streamline and automate a wide variety of business processes. An organization can use workflows to attach business logic to documents or items in a SharePoint list or library.
For security purposes, Workflow Foundation (WF) on SharePoint runs workflows only when all dependent types and assemblies are authorized in the authorizedTypes list in the web.config file. Along with allowed types, this list also contains items that block specific types from allowed namespaces that are considered dangerous. One example is System.Workflow.ComponentModel.Compiler. The Compile() method offered by WorkflowCompiler compiles a workflow based on parameters. Workflows in SharePoint are normally compiled in very restricted context (no code, types restricted by the authorizedTypes list, etc.), but invoking WorkflowCompiler would allow attackers to create a new context without these restrictions by specifying appropriate parameters. Because of this, WorkflowCompiler is blocked by the authorizedTypes list in web.config:
Therefore, we cannot mount an attack using WorkflowCompiler type.However, examining the .NET code of WorkflowCompiler.Compile reveals something interesting:
From here we see that the bulk of the implementation of WorkflowCompiler.Compile resides a different class named WorkflowCompilerInternal. This class is not blocked by authorizedTypes list. Furthermore, since it is found within the `System.Workflow` namespace, it is allowed by the line:
Therefore, we can compile an arbitrary workflow by invoking the WorkflowCompilerInternal type directly.
For arbitrary code execution, we can use the following XOML file (Attck.xoml). When compiled, it will execute the desired .NET commands, provided that the noCode flag is not specified:
Here is the .rules file (WF02.rules) of a SharePoint workflow that invokes the WorkflowCompilerInternal.Compile to compile an arbitrary XOML workflow definition, provided that the XOML file can be retrieved from an SMB share:
This rule will be triggered by the following lines from the XOML file of our SharePoint workflow (WF02.xoml):
An attacker could store Attck.xoml in a shared SMB folder controlled by the attacker and upload the WF02.xoml and WF02.rules files to a location on the SharePoint site, for example, to the Documents folder. Also, the attacker would need a workflow configuration file (WF02config.xml) that points to the uploaded XOML and rules files, and associates them with the ListID of a list in the site where the attacker can add new items:
An attacker would need to associate this new workflow with the SharePoint list. This can be done by using the AssociateWorkflowMarkup method from the WebPartPages WebService (/_vti_bin/WebPartPages.asmx) and providing the relative path to the uploaded config file.
To trigger workflow execution, the attacker adds a new item to the target SharePoint list.
Proof of Concept
For this demonstration, we use Microsoft SharePoint Server 2019 installed with all default options on Windows Server 2019 Datacenter. The server’s computer name is sp2019.contoso.lab and it is a member of the contoso.lab domain. The domain controller is a separate virtual machine. It has been updated to the February 2021 patch level (version 16.0.10371.20043) and a couple of users have been added, including “user2” as a regular, unprivileged user.
On the attacker side, we need: -- an SMB server hosting the Attck.xoml file containing the .NET code we want to execute. It must be hosted on a share that can be accessed by the SharePoint server -- our PoC application for sending SOAP requests to the server (SP_soap_RCE_PoC.exe) that calls the AssociateWorkflowMarkup method of the WebPartPages web service -- the workflow config file, WF02config.xml -- The XOML and .rules files referenced by the workflow config file -- any supported web browser. For this demonstration, we are using Firefox.
Achieving Remote Code Execution
Let’s visit our SharePoint Server and authenticate as a regular user. In my case it is user2:
Before our attack, we need to prepare a few things. We could try to do this with current user sites, but if possible, we recommend creating a new site so that we will be the owner and have all permissions.
Click on “SharePoint” on the top panel:
Now click the “+ Create site” link:
Choose Team Site.
Pick a name for the new site. Here we use testsiteofuser2.
Click “Finish” and the new site will be created:
Now we need to create a new list. Click on the “Site contents” link:
Then click “+ New” -> “List”:
Enter any available name. For example, “NewList”:
And click “Create”:
We will need the ListID of this new list. Let’s go back to the “Site contents” page and click on “Settings” in the dropdown menu for our new list:
We will be redirected to the listedit.aspx page:
We need value of the List URL parameter. In my case it is:
We need to place this value into the ListId attribute in the workflow config file, WF02config.txt:
Now we need to upload the Attck.xoml file, containing the .NET code we want to run, into an SMB folder that is accessible from the SharePoint server.
We should place the remote path to the Attck.xoml file into WF02.rules:
Save changes in both files (WF02config.txt and WF02.rules) and upload them together with the WF02.xoml file to the Documents folder of our SharePoint site:
We are almost ready for the final step. But first, let’s check the C:\windows\temp folder on our target SharePoint server:
There is no PoC_SPRCE02.txt file yet.
For our attack, we will use the SP_soap_RCE_PoC.exe application. We need to provide the following information:
— BaseUrl of the target SharePoint Site (in this case http://sp2019/sites/testsiteofuser2/) — UserName (in this case user2) — Password — Domain — Relative path to the workflow config file on our site - "Shared Documents/WF02config.txt"
We received a “Success” result. Now to trigger the RCE, we just need to add a new item to NewList:
Click on the “Save” button there.
Let’s check C:\windows\temp folder on our target SharePoint server:
The file PoC_SPRCE02.txt has been created, demonstrating the success of our code execution. In this manner, our attacker can execute arbitrary OS commands in the context of the SharePoint web application account.
To run additional OS commands, we would need to place them into Attck.xoml file in the shared folder and create another new item in NewList.
Microsoft patched this in June and assigned identifier CVE-2021-26420, with a CVSS score of 7.1. While the inclusion of an attacker-controlled SMB server adds a level of complexity, this bug can still be used for code execution in many scenarios. Since SharePoint is generally considered an attractive target for attackers, it would not be surprising if this bug were to be found in the wild. SharePoint continues to be an attractive target for security researchers, and many SharePoint-related disclosures are currently in our Upcoming queue. Stay tuned to this blog for details about those bugs once they are disclosed.
Until then, follow the team for the latest in exploit techniques and security patches.
CVE-2021-26420: Remote Code Execution in SharePoint via Workflow Compilation
In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Yazhi Wang of the Trend Micro Research Team detail a recent code injection bug in the Atlassian Confluence server. Since the publication of the vendor advisory, U.S. Cybercom has reported that mass exploitation of this bug for crypto mining is ongoing and expected to accelerate. The following is a portion of their write-up covering the root cause CVE-2021-26084, with a few minimal modifications.
An Object-Graph Navigation Language (OGNL) injection has been reported in the Webwork module of Atlassian Confluence Server and Data Center. The vulnerability is due to insufficient input validation leading to OGNL evaluation of user-supplied input.
A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation can result in arbitrary code execution in the security context of the affected server.
Atlassian Confluence is a collaboration platform written in Java. Users can create content using spaces, pages, and blogs that other users can comment on and edit. It is written primarily in Java and runs on a bundled Apache Tomcat application server. By default, Confluence is accessible via HTTP on port 8090/TCP.
HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:
where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF). SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like:
A corresponding HTTP request using the POST method might look as follows:
Confluence uses the Webwork web application framework to map URLs to Java classes, creating what is known as an “action”. Action URLs end with the “.action” suffix and are defined in the xwork.xml file in confluence- <version>.jar (where <version> is the Confluence version number) and in the atlassian-plugin.xml file in JAR files of included plugins. Each action entry contains at least a name attribute, defining the action name, a class attribute, defining the Java class implementing the action, and at least one result element which decides the Velocity template to render after the action is invoked based on the result of the action. Common return values from actions are “error”, “input”, and “success”, but any value may be used if there is a matching result element in the associated XWork XML. Action entries can contain a method attribute, which allows invocation of a specific method of the specified Java class. When no command is specified, the doDefault() method of the action class is called. The following is a sample action entry for the doenterpagevariables action:
In the above example, the doEnter() method of the com.atlassian.confluence.pages.actions.PageVariablesAction class handles requests to “doenterpagevariables.action” and will return values such as “success”, “input”, or “error”. This results in the appropriate Velocity template being rendered.
Confluence supports the use of Object Graph Navigational Language (OGNL) expressions to dynamically generate web page content from Velocity templates using the Webwork library. OGNL is a dynamic Expression Language (EL) with terse syntax for getting and setting properties of Java objects, list projections, lambda expressions, etc. OGNL expressions contain strings combined to form a navigation chain. The strings can be property names, method calls, array indices, and so on. OGNL expressions are evaluated against the initial, or root context object supplied to the evaluator in the form of OGNL Context.
Confluence uses a container object of class com.opensymphony.webwork.views.jsp.ui.template.TemplateRenderingContext to store objects needed to execute an Action. These objects include session identifiers, request parameters, spaceKey, etc. TemplateRenderingContext also contains a com.opensymphony.xwork.util.OgnlValueStack object to push and store objects against which dynamic Expression Languages (EL) are evaluated. When the EL compiler needs to resolve an expression, it searches down the stack starting with the latest object pushed into it. OGNL is the EL used by the Webwork library to render Velocity templates defined in Confluence, allowing access to Confluence objects exposed via the current context. For example, the $action variable returns the current Webwork action object.
OGNL expressions in Velocity templates are parsed using the ognl.OgnlParser.expression() method. The expression is parsed into a series of tokens based on the input string. The ognl.JavaCharStream.readChar() method, called by the OGNL parser, evaluates Unicode escape characters in the form of “\uXXXX” where “XXXX” is the hexadecimal code of the Unicode character represented. Therefore, if an expression includes the character “\u0027”, the character is evaluated as a closing quote character ('), escaping the context of evaluation as a string literal, allowing to append an arbitrary OGNL expression. If an OGNL expression is parsed in a Velocity template within single quotes and the expression’s value is obtained from user input without any sanitization, an arbitrary OGNL expression can be injected.
An OGNL injection vulnerability exists in Atlassian Confluence. The vulnerability is due to insufficient validation of user input used to set variables evaluated in Velocity templates within single quotes. By including the “\u0027” character in user input, an attacker can escape the string literal and append an arbitrary OGNL expression.
Before OGNL expressions are evaluated by Webwork, they are compared against a list of unsafe node types, property names, method names, and variables names in the com.opensymphony.webwork.util.SafeExpressionUtil.containsUnsafeExpression() method. However, this list is not exhaustive, and arbitrary Java objects can be instantiated without using any of the unsafe elements listed. For example, the following expression, executing an OS command, would be accepted as a safe expression by this method:
A remote attacker can exploit this vulnerability by sending a crafted HTTP request containing a malicious parameter to a vulnerable server. Successful exploitation can result in the execution of arbitrary code with the privileges of the server.
Remote Detection of Generic Attacks
To detect this attack, you should monitor all HTTP traffic requests where the path component of the request-URI contains one of the strings in the “URI path” column of the following table:
If such a request is found, you should inspect the HTTP request method. If the request method is POST, look for the respective vulnerable parameters from the table above in the body of the HTTP request, and if the request method is GET, you should look for the parameters in the request-URI of the HTTP request. Check to see if the value of any of the vulnerable parameters contains the string "\u0027" or its URL-encoded form. If so, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway.
Atlassian patched this vulnerability on August 25, 2021. Since the initial publication of their advisory, they have updated it multiple times to note the active attacks and to add clarification on how customers can identify if they are using Confluence Cloud. They do list some mitigations, but considering how widespread this bug is currently being exploited, the best course of action is to apply the patch and enhance system monitoring.
Special thanks to Guy Lederfein and Yazhi Wang of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.
The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.
CVE-2021-26084: Details on the Recently Exploited Atlassian Confluence OGNL Injection Bug
It’s the second Tuesday of the month, and that means the latest security updates from Adobe and Microsoft have been released. Apple and Google Chrome also released updates yesterday to fix bugs under active attack. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.
Adobe Patches for September 2021
For September, Adobe released 15 patches covering 59 CVEs in Adobe Acrobat Reader, XMP Toolkit SDK, Photoshop, Experience Manager, Genuine Service, Digital Editions, Premiere Elements, Photoshop Elements, Creative Cloud Desktop, ColdFusion, Framemaker, InDesign, SVG-Native-Viewer, InCopy, and Premiere Pro. A total of 17 of these bugs came through the ZDI program.
The update for Adobe Acrobat fixes 26 bugs in total. Of these 26 bugs, 13 are rated Critical, 9 are rated Important, and four are rated Moderate in severity. The most severe of these bugs could allow remote code execution through either a type confusion, heap-based buffer overflow, or a use after free vulnerability. The single bug fixed by the Photoshop patch could also lead to code execution when opening a specially crafted file. The update for Framemaker includes five bugs found by ZDI researcher Mat Powell. The most severe of these issues result from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. If you’re still using ColdFusion, you’ll definitely want to patch the two Critical rated security feature bypass bugs being fixed today.
You can check out all of Adobe’s patches on their PSIRT page. None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.
Apple Patches for September 2021
Although Apple does not follow the second Tuesday patch release cycle, they did release patches yesterday fixing a couple of significant bugs. CVE-2021-30860 fixes an input validation bug in CoreGraphics that could allow remote code execution. Apple notes they are aware of a report this bug is being actively exploited. This was reported by the Citizen Lab, and public accounts indicate this bug was used to target a Saudi activist’s iPhone. While the likelihood of widespread attack using this bug is low, it should still be taken seriously. Apple also notes CVE-2021-30858 – a Use-After-Free (UAF) bug in Webkit – has also been detected in the wild. These bugs impact several different Apple products, including iOS, iPad OS, watchOS, Safari, Catalina, and Big Sur. Definitely take some time to review all of the patches and apply the applicable updates once tested.
Google Chrome Patches for September 2021
Not to be outdone by Apple, Google also released a new version of Chrome yesterday to address a total of nine CVEs – two of which are listed as under active attack. CVE-2021-30632 fixes an Out-of-Bounds (OOB) Write, while CVE-2021-30633 fixes a UAF bug. Both were reported by an anonymous researcher, and both could lead to code execution at the level of the logged-on user. All of the bugs fixed in this release receive a “High” severity rating from Google. If you are running Chrome, definitely update to ensure you are on the latest stable version.
Side note: As of today, not all these fixes have not been absorbed by Microsoft Edge (Chromium) and are unrelated to the Edge (Chromium) fixes discussed below. Microsoft did list CVE-2021-30632 on September 11 but appears to have jumped the gun a bit on this release as it currently shows a September 14 release date.
Microsoft Patches for September 2021
For September, Microsoft released patches today for 66 CVEs in Microsoft Windows and Windows components, Microsoft Edge (Chromium, iOS, and Android), Azure, Office and Office Components, SharePoint Server, Microsoft Windows DNS, and the Windows Subsystem for Linux. This is in addition to the 20 CVEs patched by Microsoft Edge (Chromium-based) earlier this month, which brings the September total to 86 CVEs. A total of 11 of these bugs were submitted through the ZDI program.
Of the 66 new CVEs patched today, three are rated Critical, 62 are rated Important, and one is rated Moderate in severity. This volume is slightly higher than the average for 2021, which is below the 2020 volume while still above what was seen in 2019. As with last month, Microsoft spent significant resources responding to bugs under active attack, most notably CVE-2021-40444. One other bug is listed as publicly known but not being exploited (for now).
Let’s take a closer look at some of the more interesting updates for this month, starting with the MSHTML bug that’s listed as under active attack:
- CVE-2021-40444 - Microsoft MSHTML Remote Code Execution Vulnerability This patch fixes a bug currently being exploited via Office documents. A specially crafted ActiveX control is embedded in an Office doc then sent to a target. If opened on an affected system, code executes at the level of the logged-on user. Microsoft lists disabling ActiveX as a workaround, but other reports state this may be ineffective. As of now, the most effective defense is to apply the patch and avoid Office docs you aren’t expecting to receive. There are multiple updates for specific platforms, so be sure to carefully review and install all needed patches to ensure you are covered.
- CVE-2021-36965 - Windows WLAN AutoConfig Service Remote Code Execution Vulnerability This patch fixes a vulnerability that could allow network adjacent attackers to run their code on affected systems at SYSTEM level. This means an attacker could completely take over the target – provided they are on an adjacent network. This would be highly useful in a coffee shop scenario where multiple people are using an unsecured WiFi network. Still, this requires no privileges or user interaction, so don’t let the adjacent aspect of this bug diminish the severity. Definitely test and deploy this patch quickly.
- CVE-2021-38647 - Open Management Infrastructure Remote Code Execution Vulnerability This patch rates the highest CVSS (9.8) for this month and fixes an RCE bug in the Open Management Infrastructure (OMI). If you aren’t familiar with OMI, it’s an open-source project to further the development of a production-quality implementation of the DMTF CIM/WBEM standards. You can read all about it here. This vulnerability requires no user interaction or privileges, so an attacker can run their code on an affected system just by sending a specially crafted message to an affected system. OMI users should test and deploy this one quickly.
Here’s the full list of CVEs released by Microsoft for September 2021:
Chromium: CVE-2021-30622 Use after free in
As we did last month, this month’s table also lists the Chromium updates for Edge. These vulnerabilities are listed with the severity as assigned by Google, which is different from the standard Microsoft nomenclature. Google does not assign CVSS scores, so none are listed in the table. Again, these bugs are different than the ones fixed by Google Chrome in yesterday’s release. Those bugs should be incorporated into a future version of Edge (Chromium).
The remaining Critical-rated bug fixes a code execution vulnerability in the Scripting Engine. An attacker would need to convince a user to browse to a specially crafted website or open a file to get code execution. Looking at the other RCE bugs addressed in this release, many impact Office or an Office component. Visio receives some rare updates to go along with the more common fixes for Word, Access, and Excel.
This month’s release brings a total of 27 Elevation of Privilege (EoP) patches with it. The most notable is one listed as publicly known impacting DNS. Microsoft provides no details about the nature of the bug other than to say local privileges are required to successfully exploit it. This is not to be confused with the patch for an EoP in the Bind Filter Driver, which is completely different from the ISC BIND DNS system. Other notable EoP bugs include updates for Edge (Chromium) that seem unique to Edge – meaning the bugs weren’t from the port of Chromium and patched by Google. Visual Studio receives a patch to fix an EoP reported by ZDI researcher Michael DePlante. The issue results from incorrect permissions set on a resource used by the installer. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. There are some patches for the Print Spooler, but these don’t appear to have the impact or urgency as the PrintNightmare series of bugs. The other EoP fixes address various Windows components. In almost all cases, an attacker would need to log on to an affected system and run specially crafted code.
There are only two patches for security feature bypasses (SFBs) in this month’s release, but one seems awfully familiar. CVE-2021-38632 fixes a bug that could allow an attacker with physical access to a powered-off system to gain access to encrypted data. This sounds vaguely like the “cold boot” attacks widely discussed back in 2008. The other SFB bug being fixed this month could allow an attacker to bypass the Windows Key Storage Provider that issues key certificates for trust in attestation scenarios. This one’s a bit more vague, but surprisingly, Microsoft lists the attack complexity as Low for this bug. Definitely something to look out for.
Looking at the 12 information disclosure bugs in this month’s release, more simply result in leaks consisting of unspecified memory contents. A notable exception is a bug in the Windows Installer that could allow an attacker to read from the file system. The Windows Storage component has a bug with a similar impact. It’s not clear if any file can be read by an attacker or just specifical files and locations. The info disclosure being fixed in the Microsoft Accessibility Insights for Android is even more vague. According to Microsoft, the type of info disclosed is “sensitive information.” Well then. Plan accordingly.
The September release includes fixes for seven spoofing bugs and one for a cross-site scripting (XSS) bug. Microsoft provides no details on what may be spoofed for any of these vulnerabilities, but some have intriguing titles. There are fixes for Microsoft Edge for iOS and Android, so for those of you who use Edge on your phone, hit up the appropriate store to update your apps. There is a fix for a spoofing bug in Windows Authenticode, but the attacker vector is listed as local with privileges required. It’s possible this could allow an attacker access to something otherwise prohibited, but without further details, we can only speculate.
This month’s release is rounded out by a fix for a Denial-of-Service (DoS) bug in the Windows Installer and by a fix for Microsoft Edge (Chromium) in the mercurial Tampering category. Again, no information on what sort of tampering this vulnerability would allow. However, tampering bugs in the browser usually means an attacker could view and/or alter data within the browser. Interestingly, Microsoft appears to have released this update on September 9, but it does not appear to map to any bug fix released by the Chrome team.
No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV990001.
The next Patch Tuesday falls on October 12, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!
Parallels Desktop uses a paravirtual PCI device called the “Parallels ToolGate” for communication between guest and host OS. This device is identified by Vendor ID 0x1AB8 and Device ID 0x4000 in a Parallels guest.
The guest driver provided as part of Parallels Tools and the host virtual device communicate using a ToolGate messaging protocol. To provide a summary, the guest driver prepares a message and writes the physical address of the message to TG_PORT_SUBMIT [PORT IO ADDRESS+0x8]. The host then maps the guest provided physical address, parses the message, and transfers control to the respective request handlers for further processing. Many of the bugs received by the ZDI program in Parallels are in these request handlers.
ToolGate Interface and Protocol Format
The ToolGate request format is a variable size structure that could span across multiple pages. The guest sends data to the host as inline bytes or pointers to paged buffers by writing the physical address of TG_PAGED_REQUEST structure to the IO port of the virtual device.
The host then maps the page pointed to by the physical address, prepares a host buffer based on the information provided by the guest and then invokes the request handler. Request handlers may use inline bytes or paged buffers or both, for reading and writing data. These data buffers are accessed using a set of functions as roughly defined below:
The STARLabs submission (ZDI-21-937) for Pwn2Own 2021 is an uncontrolled memory allocation vulnerability where a guest provided size value is allocated in the stack. If the size provided by the guest is more than the total size of the stack, it is possible to shift the Stack Pointer (RSP) into other regions of process memory (e.g., stack region of another thread).
When handling TG_REQUEST_INVSHARING (0x8420), Parallels Desktop does not validate the ByteCount value provided by the guest as part of TG_PAGED_BUFFER. When allocated in stack, this untrusted size value can be used for shifting the stack top of thread processing the ToolGate request into another victim thread to overwrite its contents. There is a guard page that is 4KB in size, however it is possible to jump over this small allocation without accessing it. Qualys published a detailed paper titled The Stack Clash on this bug class back in 2017, which also leads to various compiler mitigations to prevent such guard page jumps.
Below is the vulnerable section of code from Parallels Desktop 16.1.3. During the call to TG_ReadBuffer(), the stack memory of another thread can be overwritten with guest-controlled values.
Backward Compatibility and Compiler Mitigations
The most interesting question here is what happened to the stack clash compiler mitigation in Apple Clang? When a variable size allocation is made in stack like alloca(value) or char buffer[value], the Apple Clang compiler instruments the allocation with ___chkstk_darwin() to validate the size of allocation request. ___chkstk_darwin() essentially allocates a PAGE_SIZE of memory in stack, and then, for each page allocated, probes the new stack top if it is accessible. If the case guard page is reached, the probing step will fail leading to a safe crash. It is no longer possible to shift the stack pointer into an arbitrary location.
It is clear that Parallels Desktop did not have this mitigation enabled because there is no call to ___chkstk_darwin() during the variable size stack allocation. At this point there are couple of open questions:
-- Did Parallels disable the mitigation using -fno-stack-check compiler flag? -- Did they use an old build configuration which disabled the mitigation?
Mac OS otool can be used to get a fair amount of information regarding the build environment. Specifically, LC_VERSION_MIN_MACOSX can provide information regarding the macOS versions supported. Here is the output of otool -l prl_vm_app:
The SDK used is 10.15 (Catalina), which is quite new. Moreover, Parallels has also set the minimal macOS version supported to 10.13, which makes it compatible with High Sierra. This aligns with the compatibility information provided in their KB article. Still, does backward compatibility for 10.13 disable the compiler mitigation? Here is a comparison of sample code compiled with and without -mmacosx-version-min=10.13:
It is unclear if Parallels had ___chkstk_darwin() explicitly disabled using -fno-stack-check, but setting -mmacosx-version-min=10.13 has the same effect and silently drops the mitigation. The same behavior is also observed with -mmacosx-version-min=10.14 (Mojave). Interestingly, GCC has inlined the stack probe check instead of depending on an external library function. This is possibly due to an external dependency, as compiling in Apple Clang with the backward compatibility flags (macosx-version-min, target etc.) ended up removing the mitigation.
Saying that, Mojave (10.14.6) did not give any symbol errors when running executables with calls to ___chkstk_darwin(). One can find many such issues in High Sierra (10.13.6). It is noticed that, in older compilers (e.g. Apple LLVM version 10.0.1 on Mojave), the stack clash mitigation is not enabled by default unless the -fstack-check flag is explicitly provided. Therefore, the recent compilers seem to drop the mitigation entirely when compiled with macosx-version-min for any version less than 10.15. This can be worked around by providing both the -fstack-check and -mmacosx-version-min flags together. However, High Sierra compatibility is questionable. The highlight is that using macosx-version-min alone can make the bug exploitable even on latest versions of Mac OS.
Variant hunting using Binary Ninja
The next question is, are there other similar bugs in Parallels Desktop? How can we automate this process? The size of a stack frame is generally known during compile time. Moreover, any operations that shift the stack pointer can also be tracked. Binary Ninja has static data flow capability which keeps track of the stack frame offset at any point in a function. However, when there is a variable size allocation in stack, the stack offsets cannot be determined statically. This exact property can be used to look for variants of the bug.
Consider the index 88 in the above Low-Level IL, where RSP register is loaded.
Here, the new stack top is calculated using a guest-provided size and loaded into RSP. Binary Ninja provides get_possible_reg_values() and get_possible_reg_values_after() python APIs to fetch statically determined values for registers. The register values are also associated with type information (RegisterValueType). Here is the stack frame offset value in RSP before and after the load operation:
The RSP is always associated with StackFrameOffset RegisterValueType. However, when the RSP value is not known, it is marked as UndeterminedValue. With this value type information, search for all references to TG_ReadBuffer() where RSP value is undetermined. If RSP is undetermined before the call to TG_ReadBuffer(), its deduced that a variable size allocation was made in stack prior to the call.
The above query yielded 3 results; one was the Pwn2Own submission and 2 other previously unknown vulnerabilities.
Our research has shown that, in some cases, compiling for backward compatibility might silently drop mitigations, thus making an entire bug class exploitable. Perhaps the vendors should consider releasing separate binaries in such cases?
We also took a look at how Binary Ninja’s static data flow capability and python API’s can be useful in automating bug finding tasks. If you find any such vulnerabilities, consider submitting it to our program. Until then, you can find me on Twitter @RenoRobertr, and follow the team for the latest in exploit techniques and security patches.
Analysis of a Parallels Desktop Stack Clash Vulnerability and Variant Hunting using Binary Ninja
In April 2021, the ZDI received a submission of a vulnerability in the MySQL database. It turned out to be a heap-based buffer overflow bug in the InnoDB memcached plugin. It was submitted to the program by an anonymous researcher.
The vulnerability affects MySQL versions 8.0.25 and prior. It can be triggered remotely and without authentication. Attackers can leverage this vulnerability to execute arbitrary code on the MySQL database server. Oracle patched it in July and assigned it CVE-2021-2429, while ZDI’s identifier is ZDI-2021-889.
The following analysis is based on the source code of MySQL Community Server version 8.0.25. The bug is in the memcached GET command, which is used for retrieving data from a table. For performance, the GET command supports fetching multiple key-value pairs in a single memcached query. Here is an example:
If a key in the GET command has the form @@containers.name, then the variable report_table_switch will have been set to true, satisfying the branch at (1). The memcpy at (3) copies table_name to the row_buf buffer. Before performing the memcpy, the code at (2) validates that there is still enough space in row_buf. However, this validation is performed with an assert() only. Since assert is a macro that produces code only in debug builds but not in release builds, this leads to a buffer overflow that can be reached when running a release build.
The InnoDB memcached plugin is not enabled by default. One must build MySQL from source with -DWITH_INNODB_MEMCACHED=ON. Here is the build detail. By default, the memcached daemon listens on TCP and UDP port 11211. The payload is a single GET command as seen in the example below.
get @@aaa @@aaa @@aaa ...
@@aaa is one of the default rows in the innodb_memcache database.
Each @@aaa is replaced with the table name test/demo_test at (5) within the innodb_get() function shown above. The resulting overflow content has the form test/demo_testtest/demo_testtest/demo_test.... The length of the overflow is controllable by the attacker. After sending the payload, the heap overflow is triggered in the mysqld process. The call stack is shown below.
The vulnerability was fixed in version 8.0.26. The patch is straightforward. It explicitly checks the length before copying.
Although the InnoDB memcached plugin is not enabled by default, it is nonetheless wise to apply the patch as soon as possible. It would not surprise me to see a reliable full exploit in the near future.
You can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.
CVE-2021-2429: A Heap-based Buffer Overflow Bug in the MySQL InnoDB memcached Plugin
Continuing with the theme of serious vulnerabilities that have recently come to light in Microsoft Exchange Server, in this article we present a new vulnerability we call ProxyToken. It was reported to the Zero Day Initiative in March 2021 by researcher Le Xuan Tuyen of VNPT ISC, and it was patched by Microsoft in the July 2021 Exchange cumulative updates. Identifiers for this vulnerability are CVE-2021-33766 and ZDI-CAN-13477.
With this vulnerability, an unauthenticated attacker can perform configuration actions on mailboxes belonging to arbitrary users. As an illustration of the impact, this can be used to copy all emails addressed to a target and account and forward them to an account controlled by the attacker.
The essential HTTP traffic needed to trigger the vulnerability is as follows:
“SecurityToken=x”? What might this be, some secret backdoor access code?
Understanding the Root Cause
To understand what has happened here, it is necessary to discuss a bit about the architecture of Exchange Server. Recently, security researcher Orange Tsai has done excellent work in this area, and readers are encouraged to read his full findings here as well as the recent guest blog he wrote on this site. However, for the purposes of this particular vulnerability, the salient points will be summarized below.
Microsoft Exchange creates two sites in IIS. One is the default website, listening on ports 80 for HTTP and 443 for HTTPS. This is the site that all clients connect to for web access (OWA, ECP) and for externally facing web services. It is known as the “front end”. The other site is named “Exchange Back End” and listens on ports 81 for HTTP and 444 for HTTPS.
The front-end website is mostly just a proxy to the back end. To allow access that requires forms authentication, the front end serves pages such as /owa/auth/logon.aspx. For all post-authentication requests, the front end’s main role is to repackage the requests and proxy them to corresponding endpoints on the Exchange Back End site. It then collects the responses from the back end and forwards them to the client.
Exchange is a highly complex product, though, and this can lead to some wrinkles in the usual flow. In particular, Exchange supports a feature called “Delegated Authentication” supporting cross-forest topologies. In such deployments, the front end is not able to perform authentication decisions on its own. Instead, the front end passes requests directly to the back end, relying on the back end to determine whether the request is properly authenticated. These requests that are to be authenticated using back-end logic are identified by the presence of a SecurityToken cookie:
Thus, for requests within /ecp, if the front end finds a non-empty cookie named SecurityToken, it delegates authentication to the back end.
Code on the back end that examines and validates the SecurityToken cookie is found in the class Microsoft.Exchange.Configuration.DelegatedAuthentication.DelegatedAuthenticationModule. What goes wrong on the validation side? To see the answer, have a look at /ecp/web.config on the back end:
As you can see, in a default configuration of the product, a <remove> element appears, so that the module DelegatedAuthModule will not be loaded at all for the back-end ECP site.
In summary, when the front end sees the SecurityToken cookie, it knows that the back end alone is responsible for authenticating this request. Meanwhile, the back end is completely unaware that it needs to authenticate some incoming requests based upon the SecurityToken cookie, since the DelegatedAuthModule is not loaded in installations that have not been configured to use the special delegated authentication feature. The net result is that requests can sail through, without being subjected to authentication on either the front or back end.
Bagging a Canary
There is one additional hurdle to clear before we can successfully issue an unauthenticated request, but it turns out to be a minor one. Each request to an /ecp page is required to have a ticket known as the “ECP canary”. Without a canary, the request will come back with an HTTP 500. However, the attacker is still in luck, because the 500 error response is accompanied by a valid canary:
An example of the final request would then be as follows:
This particular exploit assumes that the attacker has an account on the same Exchange server as the victim. It installs a forwarding rule that allows the attacker to read all the victim’s incoming mail. On some Exchange installations, an administrator may have set a global configuration value that permits forwarding rules having arbitrary Internet destinations, and in that case, the attacker does not need any Exchange credentials at all. Furthermore, since the entire /ecp site is potentially affected, various other means of exploitation may be available as well.
Exchange Server continues to be an amazingly fertile area for vulnerability research. This can be attributed to the product’s enormous complexity, both in terms of feature set and architecture. We look forward to receiving additional vulnerability reports in the future from our talented researchers who are working in this space. Until then, follow the team for the latest in exploit techniques and security patches.
ProxyToken: An Authentication Bypass in Microsoft Exchange Server
In April 2021, Orange Tsai from DEVCORE Research Team demonstrated a remote code execution vulnerability in Microsoft Exchange during the Pwn2Own Vancouver 2021 contest. In doing so, he earned himself $200,000. Since then, he has disclosed several other bugs in Exchange and presented some of his findings at the recent Black Hat conference. Now that the bugs have been addressed by Microsoft, Orange has graciously provided this detailed write-up of the vulnerabilities he calls “ProxyShell”.
Hi, I am Orange Tsai from DEVCORE Research Team. In this article, I will introduce the exploit chain we demonstrated at the Pwn2Own 2021. It’s a pre-auth RCE on Microsoft Exchange Server and we named it ProxyShell! This article will provide additional details of the vulnerabilities. Regarding the architecture, and the new attack surface we uncovered, you can follow my talk on Black Hat USA and DEFCON or read the technical analysis in our blog.
With ProxyShell, an unauthenticated attacker can execute arbitrary commands on Microsoft Exchange Server through an exposed 443 port!
CVE-2021-34473 - Pre-auth Path Confusion
The first vulnerability of ProxyShell is similar to the SSRF in ProxyLogon. It too appears when the frontend (known as Client Access Services, or CAS) is calculating the backend URL. When a client HTTP request is categorized as an Explicit Logon Request, Exchange will normalize the request URL and remove the mailbox address part before routing the request to the backend.
Explicit Login is a special feature in Exchange to make a browser embed or display a specific user’s mailbox or calendar with a single URL. To accomplish this feature, this URL must be simple and include the mailbox address to be displayed. For example:
Through our research, we found that in certain handlers such as EwsAutodiscoverProxyRequestHandler, we can specify the mailbox address via the query string. Because Exchange doesn’t conduct sufficient checks on the mailbox address, we can erase a part of the URL via the query string during the URL normalization to access an arbitrary backend URL.
From the above code snippet, if the URL passes the check of IsAutodiscoverV2PreviewRequest, we can specify the Explicit Logon address via the Email parameter of the query string. It’s easy because this method just performs a simple validation of the URL suffix.
The Explicit Logon address will then be passed as an argument to method RemoveExplicitLogonFromUrlAbsoluteUri, and the method just uses Substring to erase the pattern we specified.
Here we designed the following URL to abuse the normalization process of Explicit Logon URL:
This faulty URL normalization lets us access an arbitrary backend URL while running as the Exchange Server machine account. Although this bug is not as powerful as the SSRF in ProxyLogon, and we could manipulate only the path part of the URL, it’s still powerful enough for us to conduct further attacks with arbitrary backend access.
So far, we can access arbitrary backend URLs. The remaining part is post-exploitation. Due to the in-depth RBAC defense of Exchange (the ProtocolType in /Autodiscover is different from /Ecp), the unprivileged operation used in ProxyLogon which generates an ECP session is forbidden. So, we have to discover a new approach to exploit it. Here we focus on the feature called Exchange PowerShell Remoting!
Exchange PowerShell Remoting is a feature that lets users send mail, read mail, and even update the configuration from the command line. Exchange PowerShell Remoting is built upon WS-Management and implements numerous Cmdlets for automation. However, the authentication and authorization parts are still based on the original CAS architecture.
It should be noted that although we can access the backend of Exchange PowerShell, we still can’t interact with it correctly because there is no valid mailbox for the User NT AUTHORITY\SYSTEM. We also can’t inject the X-CommonAccessToken header to forge our identity to impersonate a different user.
So what can we do? We thoroughly examined the implementation of the Exchange PowerShell backend and found an interesting piece of code that can be used to specify the user identity via the URL.
From the code snippet, when the PowerShell backend can’t find the X-CommonAccessToken header in the current request, it will try to deserialize and restore the user identity from the parameter X-Rps-CAT of the query string. It looks like the code snippet is designed for internal Exchange PowerShell intercommunication. However, because we can access the backend directly and specify an arbitrary value in X-Rps-CAT, we have the ability to impersonate any user. We leverage this to “downgrade” ourselves from the SYSTEM account, which has no mailbox, to Exchange Admin.
And now we can execute arbitrary Exchange PowerShell commands as Exchange Admin!
CVE-2021-31207 - Post-auth Arbitrary-File-Write
The last part of the exploit chain is to find a post-auth RCE technique using Exchange PowerShell commands. It’s not difficult because we are the admin and there are hundreds of commands that could be leveraged. Here we found the command New-MailboxExportRequest, which exports a user’s mailbox to a specified path.
This command is useful to us, since it lets us create a file at an arbitrary path. To make things better, the exported file is a mailbox that stores the user’s mails, so we can deliver our malicious payload through SMTP. But the only problem is - it seems like the mail content is not stored in plaintext format because we can’t find our payload in the exported file :(
We found the output is in Outlook Personal Folders (PST) format. By reading the official documentation from Microsoft, we learned that the PST just uses a simple Permutative Encoding (NDB_CRYPT_PERMUTE) to encode our payload. So we can encode the payload before sending it out, and when the server tries to save and encode our payload, it turns it into the original malicious code.
Let’s chain everything together!
Step 1 - Malicious payload delivery
We first deliver our encoded web shell to the targeted mailbox through SMTP. If the target mail server doesn’t support sending mail from an unauthorized user, Gmail can be also used as an alternative way to deliver the malicious payload externally.
Step 2 - PowerShell session establishment
Because PowerShell is based on the WinRM protocol, and it’s not easy to implement a universal WinRM client, we use a proxy server to hijack the PowerShell connection and modify the traffic. We first rewrite the URL to the path of EwsAutodiscoverProxyRequestHandler, which will trigger the path confusion bug and let us access the PowerShell backend. Then we insert the parameter X-Rps-CAT into the query string to impersonate any user. Here we specify the SID of Exchange Admin to become the admin!
Step 3 - Malicious PowerShell command execution
In the established PowerShell session, we execute the following PowerShell commands:
New-ManagementRoleAssignment to grant ourselves the Mailbox Import Export role
New-MailboxExportRequest to export the mailbox containing our malicious payload to webroot, to act as our web shell
After ProxyLogon, Windows Defender started blocking dangerous behaviors under the webroot of Exchange Server. To spawn a shell at Pwn2Own successfully, we spent a little time bypassing Defender. We found that Defender blocks us if we call cmd.exe directly. However, if we first copy cmd.exe to a <random>.exe under webroot via Scripting.FileSystemObject and then execute it, it works and Defender is silent :P
The other side note is that if the organization is using the Exchange Server cluster, sometimes an InvalidShellID exception occurs. The reason for this problem is that you are dealing with a load balancer, so a bit of luck is needed. Try to catch the exception and send the request again to solve that ;)
The last step is to enjoy your shell! Here is a demonstration video:
Microsoft fixed all 3 of the ProxyShell vulnerabilities via patches released in April and May, but it announced the patches and assigned the CVEs three months after. The reason Microsoft gave is that:
Regarding the patch of CVE-2021-31207, Microsoft didn’t fix the arbitrary file write but used a allowlist to limit the file extension to .pst, .eml, or .ost.
As for the vulnerabilities which were patched in April but assigned CVEs in July, Exchange now checks the value of IsAuthenticated to ensure all frontend requests are authenticated before generating the Kerberos ticket to access the backend.
Although the April patch mitigated the authentication part of this new attack surface, the CAS is still a good place for security researchers to hunt for bugs. In fact, we have uncovered a few additional bugs after the April patch. In conclusion, Exchange Server is a treasure waiting for you to find bugs. As we mentioned in our previous article, even in 2020, a hard-coded cryptography key could still be found in Exchange Server. I can assure you that Microsoft will fix more Exchange vulnerabilities in the future.
For the system administrators, since it’s an architecture problem, it’s hard to mitigate the attack surface with one single action. All you can do is keep your Exchange Server up-to-date and limit its external Internet exposure. At the very least, please apply the April Cumulative Update to prevent most of these pre-auth bugs!
Thanks again to Orange for providing this detailed analysis of his research. He has contributed many bugs to the ZDI program over the last couple of years, and we certainly hope to see more submissions from him in the future. Until then, follow the team for the latest in exploit techniques and security patches.
From Pwn2Own 2021: A New Attack Surface on Microsoft Exchange - ProxyShell!
If you just want to read the rules, you can find them here.
Since its inception, our Fall Pwn2Own contest has focused on consumer devices – even as the contest itself has wandered around the world. It started in Amsterdam in 2012 with just mobile phones. The next year, the contest moved to Tokyo to be held concurrently with the PacSec Applied Security conference and, over the years, grew to include TVs, wearable, and smart speakers. Last year, the contest moved to Toronto and expanded again to include Network Attached Storage (NAS) devices. For 2021, we’re on the move again. This year, we’ll be hosting Pwn2Own for our headquarters in Austin, Texas on November 2-4, 2021. For this year’s event, we’re growing again to reflect the home-office environment many currently find themselves in by expanding the router category and implementing the printer category. In all, we’ll have 22 devices available as targets and be offering more than $500,000 USD in prize money.
Similar to how we’ve conducted our last few Pwn2Own events, we will allow remote participation in this inaugural Pwn2Own Austin. As of now, we are planning on having contestants in person if possible. However, if you have either travel restrictions or travel safety concerns, you can opt to compete remotely. You will still need to register before the contest deadline (October 29, 2021) and submit a detailed whitepaper completely explaining your exploit chain and instructions on how to run the entry by November 1, 2021. A member of the ZDI staff in Austin will run your exploit for you. All attempts will be filmed and available for viewing by the contestant and the vendor. As in the past, we will work with remote contestants to monitor the attempt in real-time via a phone call or video chat. Please note that since you are not in person, changes to exploits/scripts/etc. will not be possible, which could lower your chance of winning should something unexpected occur.
Otherwise, the contest will run as we have in the past. We will have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there. Our intention with allowing remote participation is to provide as many people as possible with the benefits of participating in Pwn2Own while still treating all contestants as equally as possible. As always, if you have questions, please contact us at [email protected]. We will be happy to address your issues or concerns directly.
As for the contest itself, we’re pleased to announce Western Digital has joined us as an Event Partner this year, offering three of its devices as targets. We’ve also signed on Synology to co-sponsor the competition. Western Digital and Synology devices will be prime targets for researchers. Both vendors had NAS devices featured in last year’s event, and we’re thrilled they decided to expand their participation in this year’s contest. Vendor participation remains a key component to the success of these contests. As with our other Pwn2Own competitions, Pwn2Own Austin seeks to harden these consumer-focused devices and their operating systems by revealing vulnerabilities and providing that knowledge to the vendors. As always, the goal is to get these bugs identified and fixed before they’re exploited by threat actors.
The Target Handsets
At its heart, Pwn2Own Austin (once known as Pwn2Own Mobile) looks at mobile phones, and our move to Texas doesn’t change this fact. Here are the target handsets for Pwn2Own Austin 2021:
As always, these phones will be running the latest version of their respective operating systems with all available updates installed. We’ve increased the rewards on these targets to add further incentives on these handsets.
Printers, Network Attached Storage, Smart Speakers, Televisions, and More
Over the past few years, we’ve been expanding the targets to include more than just mobile phones. Last year, we introduced Network Attached Storage (NAS) devices. This year, we’re including printers as a target. Print spooler bugs have garnered much attention this summer, but what about the devices themselves? We’ll find out, as printers from HP, Lexmark, and Canon will be put to the test.
Here’s the full list of all devices included in this year’s event:
As with the phones, these devices will be updated to the most recent patch level or system update, and all will be in their default configuration.
Pwn2Own Austin Challenges for 2021
Now that you know the devices available, let’s look at the different categories of challenges, starting with the mobile handsets.
Mobile Phone Category
In this category, contestants must compromise the device by browsing to web content in the default browser for the target under test or by communicating with the following short distance protocols: near field communication (NFC), Wi-Fi, or Bluetooth. The awards for this category are:
This category also includes an add-on bonus. If your exploit payload executes with kernel-level privileges, you earn an additional $50,000 and 5 more Master of Pwn points. That means a full iPhone or Pixel browser exploit with kernel-level access will earn $200,000.
Challenges Involving Other Devices
This is our fourth year including other types of consumer and home automation devices, and each year brings new research that exceeds our expectations. Last year we saw NAS devices compromised as a part of the contest. They return along with an expanded routers list and the aforementioned printers. It should be a great contest.
An attempt in this category must be launched against the target’s exposed network services from the contestant’s device. Three of the most popular LaserJet printers are included in this year’s event.
This is the second year for NAS devices at Pwn2Own, and both Synology and Western Digital have returned with their latest offerings. An attempt in this category must be launched against the target’s exposed network services from the contestant’s laptop within the contest network.
For details about the 3TB My Cloud Home Personal Cloud from WD - firmware version 8.xx.xx-xxx (Beta), see the supplemental blog here.
External Storage Category
While not as complex as a NAS server, external storage devices offer a tempting target for attackers. This year’s contest adds a single device in this category. An attempt in this category must be launched against the target’s exposed interfaces and result in arbitrary code execution.
Home Automation Category
Smart speakers continue to play a large part in our daily interactions with music, news, and more. Pwn2Own Austin has five targets available in this category.
Past successful entries in this category have demonstrated some flair by having the LED lights flash in different patterns. This year, we add some more sophisticated routers to the list. An attempt in this category must be launched against the target’s exposed network services from the contestant’s device within the contest network.
Contestants can register for attempts against the WAN interface, the LAN interface, or both interfaces on the same device.
These days, it’s difficult to find a television set that doesn’t include a web browser and network applications. Pwn2Own Austin 2021 has two devices under test this year.
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 2022).
For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it. If the contestant decides to remove an Add-on Bonus during their attempt, the Master of Pwn points for that Add-on Bonus will be deducted from the final point total for that attempt. For example, someone registers for the Apple iPhone 12 in the Browser category with the Kernel Bonus Add-on. During the attempt, the contestant drops the Kernel Bonus Add-on but completes the attempt. The final point total will be 10 Master of Pwn points.
The Complete Details
The full set of rules for Pwn2Own Austin 2021 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.
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 Twitter, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing to determine the contest order. Registration closes at 5:00 p.m. Eastern Daylight Time on October 29, 2021.
We’ll be blogging and tweeting results in real-time throughout the competition. We’ll also be broadcasting the event live on Twitch and YouTube. Be sure to keep an eye on the blog for the latest information. Follow us on Twitter at @thezdi and @trendmicro, and keep an eye on the #P2OAustin hashtag for continuing coverage.
We look forward to seeing everyone in Austin and online, and we look forward to seeing what new exploits and attack techniques they bring with them.
With special thanks to our Pwn2Own Austin 2021 partner Western Digital for providing their hardware and support. Thanks also go to our Pwn2Own Austin 2021 sponsor, Synology, for providing their assistance and technology.
It’s the second Tuesday of the month, and that means the latest security updates from Adobe and Microsoft have been released. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.
Adobe Patches for August 2021
For August, Adobe released two patches addressing 29 CVEs in Adobe Connect and Magento. The update for Connect is rated Important and fixes a single security feature bypass and two cross-site scripting bugs. The Critical-rated patch for Magento fixes a wide range of bugs, the worst of which could allow remote code execution.
None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.
Microsoft Patches for August 2021
For August, Microsoft released patches today for 44 CVEs in Microsoft Windows and Windows components, Office, .NET Core and Visual Studio, Windows Defender, Windows Update and Update Assistant, Azure, and Microsoft Dynamics. This is in addition to seven CVEs patched in Microsoft Edge (Chromium-based) earlier this month. A total of eight of these bugs were submitted through the ZDI program. Of the 44 CVEs patched today, seven are rated Critical and 37 are rated Important in severity. This is the smallest release for Microsoft in 2021 and could be due to resource constraints since Microsoft spent so much time in July responding to events like PrintNightmare and PetitPotam. In fact, this is the smallest release since December 2019. It will be interesting to see if the September patch volume rebounds to triple digits or remains on the smaller side.
According to Microsoft, two of these bugs are publicly known and one is listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with a bug that’s listed as under active attack:
- CVE-2021-36948 - Windows Update Medic Service Elevation of Privilege Vulnerability This bug could allow a local privilege escalation through the Windows Update Medic Service – a new feature introduced in Windows 10 designed to repair Windows Update components from damage so that the computer can continue to receive updates. An attacker would need to log on to an affected system and run a specially crafted program to escalate privileges. Microsoft does not say how widespread the attacks are, but they are most likely targeted at this point.
- CVE-2021-36942 - Windows LSA Spoofing Vulnerability Speaking of PetitPotam, Microsoft released this patch to further protect against NTLM relay attacks by issuing this update to block the LSARPC interface. This will impact some systems, notably Windows Server 2008 SP2, that use the EFS API OpenEncryptedFileRawA function. You should apply this to your Domain Controllers first and follow the additional guidance in ADV210003 and KB5005413. This has been an ongoing issue since 2009, and, likely, this isn’t the last we’ll hear of this persistent issue.
- CVE-2021-36936 - Windows Print Spooler Remote Code Execution Vulnerability Another month, another remote code execution bug in the print spooler. This bug is listed as publicly known, but it’s not clear if this bug is a variant of PrintNightmare or a unique vulnerability all on its own. There are quite a few print spooler bugs to keep track of. Either way, attackers can use this to execute code on affected systems. Microsoft does state low privileges are required, so that should put this in the non-wormable category, but you should still prioritize testing and deployment of this Critical-rated bug.
UPDATE: Microsoft has released KB5005652 to provide guidance on managing new Point and Print default driver installation behavior. This is an update for CVE-2021-34481, which was originally released in July, 2021. Sysadmins should review this KB along with applying the Print Spooler related updates in this release.
- CVE-2021-34535 - Remote Desktop Client Remote Code Execution Vulnerability Before you start having flashbacks to BlueKeep, this bug affects the RDP client and not the RDP server. However, the CVSS 9.9 bug is nothing to ignore. An attacker can take over a system if they can convince an affected RDP client to connect to an RDP server they control. On Hyper-V servers, a malicious program running in a guest VM could trigger guest-to-host RCE by exploiting this vulnerability in the Hyper-V Viewer. This is the more likely scenario and the reason you should test and deploy this patch quickly.
Here’s the full list of CVEs released by Microsoft for August 2021:
Chromium: CVE-2021-30597 Use after free in
You’ll notice this month’s table includes the Chromium updates for Edge. These vulnerabilities are listed with the severity as assigned by Google, which is different from the standard Microsoft nomenclature. Google does not assign a CVSS score, so none is listed in the table.
Looking at the remaining Critical-rated updates, most are of the browse-and-own variety, meaning an attacker would need to convince a user to browse to a specially crafted website with an affected system. One exception would be CVE-2021-26432, which is a patch for the Windows Services for NFS ONCRPC XDR Driver. Microsoft provides no information on how the CVSS 9.8 rated vulnerability could be exploited, but it does note it needs neither privileges or user interaction to be exploited. This may fall into the “wormable” category, at least between servers with NFS installed, especially since the open network computing remote procedure call (ONCRPC) consists of an External Data Representation (XDR) runtime built on the Winsock Kernel (WSK) interface. That certainly sounds like elevated code on a listening network service. Don’t ignore this patch.
Another interesting Critical-rated bug affects the TCP/IP stack. Despite its CVSS rating of 9.9, this may prove to be a trivial bug, but it’s still fascinating. An attacker on a guest Hyper-V OS could execute code on the host Hyper-V server by sending a specially crafted IPv6 ping. This keeps it out of the wormable category. Still, a successful attack would allow the guest OS to completely take over the Hyper-V host. While not wormable, it’s still cool to see new bugs in new scenarios being found in protocols that have been around for years.
The remaining patches for RCE bugs primarily address open-and-own types of bugs in Microsoft Dynamics (on-prem), Office, Word, and Windows media components. For example, the vulnerability in Word would require someone to open a specially crafted Word doc with an affected version, resulting in code execution at the logged-on user lever. There’s also an Important-rated RCE bug in the print spooler, however, it’s not clear why this one is rated Important while the other is rated Critical. Both have the exact same CVSS rating. One is publicly known, but that shouldn’t affect severity. Best to treat both print spooler bugs as Critical, just to be on the safe side.
There are a total of 16 Elevation of Privilege (EoP) patches in this month’s release. Most of these exist in Windows components and require an attacker to log on to an affected system and execute their specially crafted program. Six of these bugs were reported through the ZDI program by Abdelhamid Naceri (halov) and deal with improper link resolution before file access (Link Following) vulnerabilities. For example, by creating a directory junction, an attacker can abuse the Windows Update Assistant to delete a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the Administrator. Altogether, there are EoP fixes for Windows Defender, Azure Sphere and CycleCloud, Storage Spaces, the Update Assistant, the Bluetooth service, Windows Event Tracing, and the aforementioned Print Spooler.
Looking at the eight information disclosure bugs in this month’s release, more simply result in leaks consisting of unspecified memory contents. A notable exception is the patch for .NET Core and Visual Studio that could disclose data inside the targeted website like IDs, tokens, nonces, and other sensitive information. Microsoft does not specify what information is disclosed by the bug in the Windows Cryptographic Primitives Library, but judging by the title alone, it’s possible (though unlikely) that an attacker could recover plaintext data from encrypted content. Let’s hope we receive more information on this bug in the future.
Only two patches this month result in Denial-of-Service (DoS) conditions, but you likely only need to act on one. The update for Azure Sphere should have been automatically delivered to your device provided it is connected to the Internet. The other patch fixes a DoS bug in .NET Core and Visual Studio and needs to be installed as per usual.
There are also just two security feature bypasses getting fixes this month. The first is for Azure Active Directory Connect, but you’ll need to do more than just patch to prevent a Man-in-The-Middle (MiTM) attack between your Azure AD Connect server and a domain controller. You will also need to disable NTLM as laid out in this document. The other spoofing bug occurs in SharePoint Server and likely manifests as a cross-site scripting (XSS) issue. Speaking of XSS bugs, this month’s release is rounded out by two patches for XSS vulnerabilities in Microsoft Dynamics.
As expected, the servicing stack advisory (ADV990001) was revised for multiple versions of Windows this month. No new advisories were released this month.
The next Patch Tuesday falls on September 14, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!
In March 2021, Microsoft released a patch to correct a vulnerability in the Windows GDI subsystem. The bug could allow an attacker to execute code with escalated privileges. This vulnerability was reported to the ZDI program by security researcher Marcin Wiązowski. The patch for CVE-2021-27077 addresses several of his bug submissions. He has graciously provided this detailed write-up of the vulnerabilities and an analysis of the patch from Microsoft.
To handle devices on which drawing can be performed (pixel-based devices), Windows provides so-called device contexts (DCs). A device context object encapsulates a device object where a device object represents either a screen or a printer. Device contexts are an abstraction layer between user-mode code and low-level device drivers. They also act as containers, referencing various graphic objects used during drawing operations, such as pens, brushes, bitmaps, palettes, regions, and paths. To establish a connection between a device context and some other graphic object, the user-mode code calls SelectObject. For example:
In this example, we create a screen-related device context and three other GDI objects: a region, a font, and a bitmap. By selecting them into the device context, we cause them to be used during the ExtTextOut call below. This call will draw text on our TestBitmap by using our TestFont, and the drawing area will be clipped by our TestRegion.
For us, the important facts about device contexts are:
1 - They can be either screen-related or printer-related. 2 - To reference the screen or printer, each device context internally keeps a handle, referred to as hdev. Internally, a device context object resides in kernel memory, and its hdev field is a pointer to another object residing in kernel memory, this one being a device object.
Bitmaps selected into device contexts
Bitmaps are represented in kernel memory as surface objects. The partial structure definition shown here includes some fields documented by Microsoft, as well as some undocumented fields that have been reconstructed:
As we can see, bitmaps can contain a hdev value. This value is initially set to NULL, but selecting the bitmap into a device context copies the hdev value from the device context to the bitmap’s hdev field.
Now let’s do an experiment:
In this example:
1) We create one printer-related device context (DCPrn) and one screen-related device context (DCScr). For the printer DC, we used the printer named “Microsoft XPS Document Writer” which is available by default, but any installed printer could be used instead. If necessary, the EnumPrinters API could be used to get the names of all installed printers. 2) We create a bitmap (Bitmap). Note that it’s a monochrome (1 bit deep) bitmap, so it’s compatible with any device context. This includes 1-bit or 8-bit printer-related DCs and 32-bit screen-related DCs. 3) We select the bitmap into the printer-related DC. This sets the bitmap’s hdev field so that it points to the printer device object in kernel memory. The variable PrevBitmap is set to the default bitmap that was created together with the printer DC. 4) We deselect our bitmap (by selecting PrevBitmap instead), so we’ll be able to select Bitmap into some other device context again. Bitmaps are specific in that sense. They can be selected into only one device context at a time, so deselecting is required. 5) Finally, we select Bitmap into a screen-related DC. This updates bitmap’s hdev field so that it no longer points to the printer device object, but rather to the screen device object.
This code isn’t malicious, but we’ll make it malicious in the next step. But first, let’s look at some changes that were introduced in Windows 2000.
User-Mode Printer Drivers (UMPD)
Historically, both screens and printers used to be handled by kernel-mode drivers. While there are only a small number of vendors that manufacture graphic cards and write corresponding driver code, the world of printers is quite a different story. Undoubtedly there were plenty of printer manufacturers who introduced numerous security risks and instabilities in their drivers. To make things safer and more stable, Windows 2000 introduced an architecture that allowed printer drivers to work in user mode instead. Both kernel-mode and user-mode printer drivers coexisted until Windows Vista. Since then, Windows has supported only user-mode drivers for printing.
Consequently, only some stubs remained in kernel code for printer handling. These stubs mainly just make callbacks to user mode. In user mode, these calls are first passed to some internal code in user32.dll, then to some more code in gdi32.dll, then to yet more internal code in gdi32full.dll, which finally passes them to user-mode printer drivers for handling:
To provide user-mode drivers with the needed functionalities, some kernel-mode APIs now also have their user-mode API counterparts. One such API is EngAssociateSurface. Display drivers use calls to the kernel-mode function win32kbase.sys!EngAssociateSurface, whereas printer drivers use the user-mode function gdi32.dll!EngAssociateSurface:
For our purposes, we can consider the user-mode EngAssociateSurface function to be an extended version of the SelectObject API. When passing a bitmap as the first parameter, we can set not only the bitmap’s hdev field but also its dhpdev and flags fields. Here are a few things to consider:
1) The hdev parameter will be a valid value obtained from an existing printer-related device context. User-mode code can obtain this value since it’s forwarded by the kernel to the user-mode printer driver. This will be explained below in greater detail. After validation, the passed hdev parameter will be copied to the bitmap’s hdev field. 2) The flHooks parameter may contain any combination of HOOK_XXX flags, documented here. These flags will be set in the bitmap’s flags field. 3) The dhpdev value is not passed as a parameter. However, the kernel maintains its internal list of hdev-dhpdev pairs, so setting the bitmap’s hdev field will also set its dhpdev field.
During device initialization, the device driver can pass a dhpdev value of the driver’s choice to the operating system, thus creating a hdev-dhpdev pair. In practice, the dhpdev value points to a block of driver-allocated memory, which will be either kernel-mode memory for display drivers or user-mode memory for printer drivers. This observation is very important for us.
Whenever executing a GDI graphics primitive (for example, ExtTextOut, which renders text to a DC), there are two code paths that could be chosen. One code path implements the primitive via a call to a corresponding driver function (supposing one exists) that knows how to perform that graphics primitive natively. The other code path uses a generic implementation of the primitive as supplied by win32k. The bitmap’s flags field, containing a combination of values from the HOOK_XXX enumeration, tells the operating system which GDI operations should be handled by the win32k subsystem and which should be directed to a corresponding device driver function. When so requested, the driver is identified by the device context’s hdev field.
Since we used ExtTextOut in our example above, let’s consider the HOOK_TEXTOUT flag. The ExtTextOut GDI function takes a device context as a parameter and passes it to the kernel-mode implementation of GDI. The kernel obtains the bitmap that is selected into this device context and checks if the bitmap’s flags field has the HOOK_TEXTOUT bit set. If this bit is not set, the kernel will pass our request to the generic win32kfull.sys!EngTextOut function to render the text. If HOOK_TEXTOUT is set, though, the kernel will forward our request to the device driver as specified by the bitmap’s hdev field. In this case, execution will be passed in kernel mode to one of three possible places (a few more are used in some specific cases, but they are not interesting for us):
• Cdd.dll!DrvTextOut, which is a part of a top-level display driver, used for screen devices when only one monitor is active. • win32kfull.sys!MulTextOut, which is a part of a top-level display driver, used for multi-monitor configurations. This driver is embedded directly in the win32k subsystem. • win32kfull.sys!UMPDDrvTextOut, which is one of the printer stubs in the kernel. It uses a callback to pass the request through to user mode. This allows the request to be handled by the appropriate user-mode printer driver.
We are now ready to make our piece of code malicious. To achieve this, we’ll replace one of the SelectObject calls with a call to EngAssociateSurface call, passing HOOK_TEXTOUT as the flags parameter:
Other modifications are as follows:
1) We no longer need to call CreateCompatibleDC when creating DCPrn. This is because we no longer call SelectObject on DCPrn but rather EngAssociateSurface on DCPrn’s hdev value. 2) Because of internal EngAssociateSurface requirements, we can’t use the CreateBitmap call anymore. We must instead call CreateCompatibleBitmap on DCPrn. 3) We no longer need to deselect our bitmap from DCPrn. This is because there is no SelectObject call on DCPrn but rather EngAssociateSurface on DCPrn’s hdev value. 4) Note that we explicitly call a Unicode (wide) version of the ExtTextOut API. We also provide an ETO_IGNORELANGUAGE flag to this call, along with a very long string. This way, our ExtTextOut request will be passed directly to the kernel mode without any further user-mode handling.
Let’s look at the comments in the code snippet above. The EngAssociateSurface call sets the bitmap’s hdev field so it points to a printer device in kernel mode. As explained above, this will also affect the bitmap’s dhpdev field. As we remember, this value, in practice, points to a block of driver-allocated memory. Since printer drivers are handled in user mode, this will be some block of user-mode memory. Finally, the HOOK_TEXTOUT bit is set in the bitmap’s flags field.
The SelectObject call is then made, which ties the bitmap to DCScr and modifies the bitmap’s hdev field so it no longer points to the printer device but rather to a screen device. Other bitmap fields are not modified. In particular, SelectObject will not alter the dhpdev field.
Finally, we have the ExtTextOutW call on the screen-related DCScr. When handling this call, the kernel will see the HOOK_TEXTOUT flag set in the bitmap’s flags field, so drawing will not be handled by the win32k subsystem. Instead, our request will be passed to the device driver specified by the DCScr’s hdev value, which in our case is the display driver. This way, thanks to our manipulations, the display driver will get the bitmap containing a pointer to some user-mode memory in the bitmap’s dhpdev field while it expects to see a pointer to its own, kernel-mode memory there. We definitely found a security problem.
By preparing a block of user-mode memory appropriately, we can trick the display driver into overwriting kernel memory of our choice. This means privilege escalation is possible. But first, we must perform some interactions with a user-mode printer driver to help us fulfull the following four requirements:
Requirement 1: We must obtain the printer’s hdev value so we will be able to make the EngAssociateSurface call. This is a kernel-mode pointer. Requirement 2: We must obtain the printer’s dhpdev pointer (note that this is a user-mode pointer), so we can prepare the memory that the display driver will access there. Even better, we can also modify this pointer at will, as explained below. Requirement 3: Calling CreateCompatibleBitmap on DCPrn must return a bitmap that can be then selected into DCScr, so it must be either a 1-bit or a 32-bit bitmap. For this reason, we must force the user-mode printer driver to create either a 1-bit or a 32-bit device context, which will become our DCPrn. Requirement 4: We must force the user-mode printer driver to report that it has a native text rendering function. Otherwise, calling EngAssociateSurface with HOOK_TEXTOUT will fail.
Hooking the UMPD implementation
Printer drivers are user-mode DLLs registered in the Registry. Printer drivers may implement functions that are defined in the winddi.h header file and are identified by integer constants:
To implement INDEX_DrvEnablePDEV functionality, device drivers provide a function with the following definition:
As we can see, this function gets the hdev value as a parameter and returns the dhpdev value. This means that we need to install some wrapper around this function in the printer driver to be able to obtain and modify these values.
To reach our goal, we could hook the user-mode printer driver itself, as described in detail here. However, this is quite a complex approach. Instead, we’ll try another solution that is both simpler and more universal. Instead of placing hooks in the driver itself, we will hook the user-mode code that is executed above the driver:
By injecting our own layer between user32.dll!ClientPrinterThunk and gdi32.dll!GdiPrinterThunk, we can obtain a central point at which all data passed to or returned from printer drivers can be read and modified. This can be achieved easily, since gdi32.dll!GdiPrinterThunk is a public export from the gdi32.dll module. Because user32.dll is a PE image mapped into memory, it’s enough to enumerate its import table and replace all pointers to gdi32.dll!GdiPrinterThunk with pointers to our own code. This gives us the ability to modify the incoming data, call the original gdi32.dll!GdiPrinterThunk function, and modify the returned data as needed.
The gdi32.dll!GdiPrinterThunk function, although exported by gdi32.dll, is not publicly defined. As of today, it has four parameters and can be reconstructed as:
In this call, the input buffer contains the identifier of the driver function to be called (i.e., one of the INDEX_XXX values) along with data needed for the call. The output buffer receives the results returned by the printer driver. The needed parts of the input and output buffer can be reconstructed as:
For our exploit, we need custom handling of the following INDEX_XXX requests in our GdiPrinterThunk wrapper:
1) INDEX_DrvEnablePDEV 2) INDEX_UMPDDrvDriverFn (undocumented, called from win32kfull.sys!UMPDDrvDriverFn) 3) INDEX_DrvDisablePDEV
Aside from the INDEX_XXX values defined in winddi.h, GdiPrinterThunk also receives a few undocumented commands. These have INDEX_XXX values greater than the highest documented value. Undocumented commands are never forwarded down to the lowest level (the user-mode printer driver DLL). They are designed for internal gdi32full.dll use only. The first command passed to the GdiPrinterThunk call is always a particular undocumented command, which, after increasing by 3, gives us the needed INDEX_UMPDDrvDriverFn value.
After using CreateDC to create a printer-related device context, we’ll catch many requests in our installed GdiPrinterThunk wrapper. Most of them should be just passed directly to the original gdi32.dll!GdiPrinterThunk implementation, with the three exceptions as mentioned above:
• When handling INDEX_DrvEnablePDEV, we can find the hdev value needed for the EngAssociateSurface call in the input buffer, which satisfies Requirement #1. Then, after calling the original gdi32.dll!GdiPrinterThunk function, we can find the dhpdev value in the output buffer, which points to some block of user-mode memory. Disassembling gdi32full.dll shows that this block of memory contains only two handles/pointers. At this moment, we can allocate some large (64 kB) block of user-mode memory, copy these two handles/pointers to our block, and overwrite the original dhpdev value with a pointer to our own block. By disclosing dhpdev as well as overwriting it with a new value to our liking, we have satisfied Requirement #2. Additionally, the output buffer contains a pointer to a pdi record. We should set pdi->iDitherFormat to BMF_1BPP and also ensure that pdi->flGraphicsCaps has the GCAPS_PALMANAGED flag cleared. This way, Requirement #3 will be met as well.
• When handling INDEX_UMPDDrvDriverFn, we get the DriverFn array in the output buffer. After calling the original gdi32.dll!GdiPrinterThunk function, we should set DriverFn[INDEX_DrvTextOut] to TRUE so the kernel will think that text drawing functionality is handled natively by the printer driver. Thanks to this, passing HOOK_TEXTOUT flag to our EngAssociateSurface call will succeed. This will satisfy Requirement #4.
• When handling INDEX_DrvDisablePDEV, we’ll find our own dhpdev value in the input buffer. It’s good to replace it with the original value before calling the original gdi32.dll!GdiPrinterThunk function to avoid problems with heap memory. gdi32full.dll treats this value as a pointer to its own block of heap memory and tries to release it.
Kernel Exploitation with a Fake dhpdev Block
We are now ready to pass our block of user-mode memory to the display driver. Our choice will be the multi-monitor display driver. More precisely, we will target its win32kfull.sys!MulTextOut function. This will limit our exploitation to multi-monitor machines only, but exploitation will be a bit tricky. The multi-monitor driver expects to see its own data structures in the dhpdev block, so we must craft this block of memory properly to obtain a controllable memory write. A detailed description of the needed memory contents would be quite boring and not really cutting-edge, so let’s immediately focus on the tricky part. There are some flags stored in the dhpdev block where we can set the RC_PALETTE bit. This informs the multi-monitor driver that our displays need a palette for drawing. A palette is used for dealing with 8-bit color modes. Enabling such modes for displays has not been possible since Windows 8. However, the code for handling them is still present. This allows us to use the RC_PALETTE flag and thus force the driver to create a palette object while, by preparing contents of the fake dhpdev block carefully, we can control the memory address where the palette object will be stored. In other words, we can overwrite kernel memory of our choice with a palette handle value.
Our target for overwriting will be our process token’s privileges – see here for details on how to obtain the address of our privileges in kernel memory. In short, we can treat privileges as two 64-bit bitfields located in kernel memory. One of these bitfields tells which privileges are present and another one tells which are enabled. For our purposes, it’s enough to gain the following four privileges:
To obtain these privileges, we need to set their corresponding bits in the present bitfield. Generally speaking, once a privilege is present in the token, it can be enabled by calling the AdjustTokenPrivileges API. However, not all privileges can be enabled so easily. Each process token contains not only its privileges but also a so-called integrity level. Normal processes don’t have an integrity level high enough to enable the most critical privileges just by making an API call. For this reason, we must perform our exploitation twice: once to overwrite the bitfield indicating which privileges are present and a second time to overwrite the bitfield indicating which privileges are enabled. This means we must:
1) Prepare our fake dhpdev block in such a way that the handle to the palette object will be stored in the present bitfield. 2) Call ExtTextOutW. 3) Prepare our fake dhpdev block once again so the handle to the palette object will be stored in the enabled bitfield. 4) Call ExtTextOutW again.
For successful exploitation, we need to hold only the four privileges listed above. All other privileges may be either set or cleared. Having these four privileges is enough to make a successful call to an undocumented NtCreateToken native API. This allows us to create a token with all privileges present and enabled and with the highest possible integrity level. Passing such a token to a CreateProcessAsUser call allows us to create a maximally powerful user-mode process.
Our last task is to force the kernel to create palettes with the proper handle values so that writing so those values to the privileges bitfields will set the required bits.
Controlling GDI handle values
The lowest 16 bits of each GDI handle act as an index to a so-called global GDI table. For example, a handle value may be:
where: 1) 0x59b2 is an index to a slot in the global GDI table. 2) 0x08 is an object type. 0x08 stands for a palette object. 3) 0x6c is a counter that is incremented each time a slot is assigned for a new object.
Slots in the global GDI table are used in a LIFO (Last In, First Out) manner. We can experiment and create 3 GDI objects: Object1, Object2, and Object3. Obtained handle values may be, for example:
0x74xx25c8 0x21xx1287 0x15xx4f34
Now we can delete these objects in reverse order (Object3, Object2, and Object1) and recreate them in the original order again. The handle values will most probably still reference the same slots, and their values will now be:
0x75xx25c8 0x22xx1287 0x16xx4f34
To achieve our goal, we should: 1) Create many GDI objects of any type. Since there is a per-process limit of 10,000 GDI handles, we can create 9,500 objects. Assuming a linear distribution, 1/16 of the obtained handle values (nearly 600 of them) will have the needed bit combination. 2) Delete the objects that don’t have the needed bit combination in their lowest 16 bits. 3) Delete the objects that do have the needed bit combination in their lowest 16 bits.
The slots of the most recently deleted objects will be first to be reused again when the multi-monitor driver allocates its palette objects during exploitation. Since the most recently deleted objects have the required bit combination in their handle values, the kernel-generated palette objects will also have this same bit combination.
Due to multitasking, other processes may interfere with our manipulations and release additional slots or reuse our just-released slots before they are used by the multi-monitor driver when creating its internal palette objects. This is not a big problem. We can call PrivilegeCheck to see if our process token’s privileges have been overwritten as expected. In case of failure, we can just attempt our exploitation once again.
As a result of our exploitation: 1) The needed privileges in our process token will always be set. 2) There are some other privileges that will always be in a predictable state (set or cleared) due to their being overwritten by the 0x08 part of the handle value. 3) The remaining privileges will be overwritten randomly.
When the vulnerability was found, it was first thought that the problem was that the multi-monitor driver doesn’t validate that the dhpdev pointer in the received bitmaps falls within the kernel-mode memory range. We should note that some other HOOK_XXX flags could also be used for exploitation, for example, HOOK_LINETO along with a LineTo call. Therefore, the validation would need to be implemented in multiple places in the multi-monitor driver.
However, under the hood, things are probably more complicated than they appear, so another solution has been implemented. Now, when a bitmap’s dhpdev field is non-NULL (which would be a consequence of making an EngAssociateSurface call), and the bitmap is also printer-compatible (one of the bitmap’s undocumented flags indicates this), selecting the bitmap into a screen-related device context is no longer possible. A newly-added win32kbase.sys!bIsSurfaceAllowedInDC function checks these conditions and causes the SelectObject call to fail. The introduced change shouldn’t cause any problems in real-life scenarios, since the algorithm used for the exploitation is highly artificial. However, this change still breaks compatibility to some extent. For this reason, the patch can be disabled by adding an undocumented registry key from an elevated command prompt and rebooting:
Another newly-added function named win32kbase.sys!UMPDAllowPrinterSurfaceInDisplayDC is now called during system initialization. It reads the registry key (if it exists) and stores the result in a global variable called win32kbase.sys!gAllowPrinterSurfaceInDisplayDC. This variable is then read by the aforementioned win32kbase.sys!bIsSurfaceAllowedInDC function, which is internally called during each SelectObject call.
Thanks again to Marcin for providing this thorough write-up. He has contributed many bugs to the ZDI program over the last couple of years, and we certainly hope to see more submissions from him in the future. Until then, follow the team for the latest in exploit techniques and security patches.
CVE-2021-27077: Selecting Bitmaps into Mismatched Device Contexts
With the popularity of cloud storage, various operating systems have added services and functionalities to support such storage. You can now have your storage in the cloud while exploring it locally on your system. On Windows, this is done via the Cloud Sync Engine. This component exposes a native API known as the Cloud Filter API. The implementation is found in the Cloud Files Mini Filter Driver, or cldflt.sys. The purpose of this blog is to provide some details about an integer underflow vulnerability within this driver tracked as CVE-2021-31969/ZDI-21-797, which was originally reported to the ZDI by an anonymous researcher. It can be exploited to overflow a kernel buffer and gain code execution with escalated privileges.
A quick look at Cloud Sync Engines
The Cloud Files API in Windows has been available since Windows 10 version 1709. It offers support for cloud sync engines and handles tasks such as creating and managing placeholder files and directories. A sync engine is a service that syncs files between a remote host and a local client in a way that allows cloud-hosted files and directories to be available to local users through the Windows file system and File Explorer. In this scenario, the file itself resides in the cloud, while on your local filesystem, there is a representation of that file known as a “placeholder.” Your file in the cloud might be huge, but a placeholder file might consume only the few bytes needed to store headers. When you access a placeholder file, Windows makes the associated cloud file available via syncing. The vulnerability can be triggered during the processing of placeholder files.
Method of triggering the vulnerability
Here is a description of the key steps in the proof of concept:
1: It starts by performing a sync root registration. It then initiates the communication between a sync provider and the sync filter API:
2: It gets a handle to the target directory and retrieves the reparse point data via an FSCTL_GET_REPARSE_POINT control code:
3: It modifies the retrieved reparse point data, setting the length to zero. It then sets it back via an FSCTL_SET_REPARSE_POINT_EX control code (with the tag set to 0x9000301A which is IO_REPARSE_TAG_CLOUD_3). Finally, it sets parameters to ask for a placeholder update (code= 0xC0000003) via the cloud filter FSCTL (0x903BC):
The Kernel Bug
As we mentioned, a kernel driver called cldflt.sys is responsible for processing cloud filter FSCTLs. As usual, this is accomplished using a function with a large switch statement. This function is named HsmFltProcessHSMControl:
For an operation with code 0xC0000003, it will eventually call HsmFltProcessUpdatePlaceholder:
After some processing, the execution flow will reach HsmpRpReadBuffer. It first allocates a buffer then retrieves reparse point data by issuing an FSCTL_GET_REPARSE_POINT control code. Note that the retrieved data may have been modified by the attacker. Afterward, it calls HsmpRpiDecompressBuffer:
Inside HsmpRpiDecompressBuffer, the provided length (which the attacker has set to zero) is retrieved and increased by 8. It is saved in a local variable (length) and then is used to allocate a kernel buffer. Shortly afterward, the code proceeds to decompress data via a call to RtlDecompressBuffer using the allocated buffer as the destination buffer for the uncompressed data. However, the pointer it passes to RtlDecompressBuffer is not the start of the allocated buffer. Instead, it is advanced by 12 bytes to make room for some metadata. Correspondingly, the buffer size it passes to RtlDecompressBuffer is length minus 12. In the disassembly shown below, the subtraction is seen optimized as an ADD. In our case, this subtraction produces an integer underflow, so that a huge buffer length value of 0xFFFFFFF4 is passed to RtlDecompressBuffer. This enables a kernel buffer overflow.
Microsoft fixed this vulnerability by adding a check to make sure the retrieved length is not less than 4. This makes it impossible to trigger an integer underflow.
New technologies are always on the way and operating systems must add new features to support such technologies and bring them to the end users. Researchers can always expect vulnerabilities in such a fresh piece of code no matter how good programmers are or how thorough a vendor checks and performs fuzzing to catch errors and vulnerabilities.
You can find me on Twitter at @hosselot and follow the team for the latest in exploit techniques and security patches.
The second Tuesday of the month is here, and it brings with it the latest security patches from Adobe and Microsoft. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.
Adobe Patches for July 2021
For July, Adobe released five patches addressing 29 CVEs in Adobe Dimension, Illustrator, Framemaker, Acrobat and Reader, and Adobe Bridge. A total of 15 of these bugs were reported through the ZDI program with several being discovered by ZDI researchers Mat Powell and Joshua Smith. The update for update Acrobat and Reader fixes 19 different bugs – several of which could lead to code execution if an attacker can convince a user to open a malicious PDF with an affected version. The update for Dimension also could allow code execution. For Illustrator, three bugs are being fixed. The two that allow for code execution occur in during the processing of PDF and JPEG2000 files. These issues result from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. Similar Out-Of-Bounds (OOB) Write bugs exist in the five fixes for Bridge. Again, code execution would occur at the level of the logged-on user. The single CVE fixed by the Framemaker patch corrects an OOB Write that exists within the parsing of TrueType fonts embedded in PDF files.
None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.
Microsoft Patches for July 2021
For July, Microsoft released patches for 117 CVEs in Microsoft Windows, Dynamics, Exchange Server, Microsoft Office, Windows Storage Spaces Controller, Bing, SharePoint Server, Internet Explorer (IE), Visual Studio, and OpenEnclave. A total of 17 of these bugs were reported through the ZDI program. Of these 117 bugs, 13 are rated Critical, 103 are rated Important, and one is rated as Moderate in severity. This volume of fixes is more than the last two months combined and on par with the monthly totals from 2020. Perhaps the lowered rate seen in the prior months was an aberration. According to Microsoft, six of these bugs are publicly known and four 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 a bug that’s already received a lot of (warranted) attention:
- CVE-2021-34527 - Windows Print Spooler Remote Code Execution Vulnerability Much has already been written about this currently exploited bug also known as PrintNightmare. Microsoft released an Out-of-Band (OOB) patch for this bug on July 1, and they have updated it multiple times since then. There have been reports the patch is ineffective, but Microsoft insists it works – provided certain registry keys have the correct values. Enterprises should verify these registry keys are configured as intended and get this patch rolled out. It’s also a fine time to disable the Print Spooler service wherever it isn’t needed and restrict the installation of printer drivers to just administrators.
- CVE-2021-34448 - Scripting Engine Memory Corruption Vulnerability This bug is also listed as under active exploit, but there’s no indication of how widespread the attack is. The vulnerability allows an attacker to execute their code on an affected system if a user browses to a specially crafted website. The code execution would occur at the logged-on user level. This is also a case where CVSS doesn’t quite offer a true glimpse of the threat. Microsoft lists the attack complexity as high, which knocks this from a high severity (>8) to a medium severity (6.8). However, if there are already active attacks, does complexity matter? Regardless, treat this as critical since it could allow code execution on every supported version of Windows.
- CVE-2021-34494 - Windows DNS Server Remote Code Execution Vulnerability This bug is currently not under active attack, but considering the severity, there are those who will work to change that status. This bug could allow remote code execution at a privileged service level on a listening network port without user interaction. Microsoft does mention low privileges are needed, but depending on the server configuration, these could be easily gained. This bug is restricted to DNS Servers only, but if there’s one system you don’t want wormed, it’s probably your DNS server. Definitely test and deploy this one quickly.
- CVE-2021-34458 - Windows Kernel Remote Code Execution Vulnerability It’s rare to see remote code execution in a kernel bug, but this is that rare exception. This bug impacts systems hosting virtual machines with single root input/output virtualization (SR-IOV) devices. It’s not clear how widespread this configuration is, but considering this bug rates as a CVSS 9.9, it’s not one to ignore. If you have virtual machines in your environment, test and patch quickly.
Here’s the full list of CVEs released by Microsoft for July 2021:
Microsoft SharePoint Server Information
Looking at the remaining patches, you’ll note seven patches for Exchange Server, but only some of these are actually new. One of the new ones is CVE-2021-31206, which was disclosed during the last Pwn2Own contest. There are also new patches for elevation of privilege bugs that could be exploited in a man-in-the-middle attack or be network adjacent. The real surprise in this month’s Exchange patches are the three bugs patched in April but not documented until today. Silent patches have caused many problems in the past and represent significant risks to enterprises. While the goal should be for administrators to install every patch, this is simply not feasible for most networks. Network defenders need as much information as possible to prioritize their resources. If they are not provided guidance on installing the patch, or information from the vendor on the severity of the patch, their uninformed decision could have negative consequences.
Taking a look at the remaining Critical-rated bugs, there are two updates for Defender code execution bugs, although you likely won’t need to take any action. Microsoft regularly updates the Malware Protection Engine, so if your system is connected to the Internet, it should have already received an update. There are also RCE bugs in Dynamics 365 Business Central, Windows Media Foundation, MSHTML, and Hyper-V.
Moving to the Important-rated RCE bugs, there are quite a few impacting the Windows DNS Server. Most of these would require an administrator to view a malicious record in the DNS Snap-in to be exploited. There are also a few that have no user interaction and require only low-level privileges. Two of the patches fix denial-of-service (DoS) bugs in the server. Shutting DNS down is nearly as severe as taking it over. In all cases, the DNS Server must be enabled for a system to be impacted by these bugs. The Important RCEs category is rounded out by fixes for Office components, SharePoint Server, and HEVC Video Extensions.
There are a total of 32 Elevation of Privilege (EoP) patches in this month’s release. In addition to the ones previously mentioned, six of these fix EoP bugs in the Windows Storage Spaces Controller. There are also fixes for EoP vulnerabilities in the kernel, Remote Access Connection Manager, Installer service, partition management, and projected file system.
We’ve already mentioned quite a few DoS bugs in this release, and there are a few more to look out for. The first is a bug in the Local Security Authority (LSA). Microsoft doesn’t detail the impact of the bug, but a DoS on LSA implies users can’t authenticate. There are three DoS vulnerabilities in the TCP/IP stack. Again, no details from Microsoft, but it appears an attacker could shut down all networking on a device. Finally, there are fixes for DoS bugs in bowser.sys and the Windows AF_UNIX Socket Provider.
There are 14 patches fixing information disclosure bugs this month, including the single Moderate-rated fix for a bug in SharePoint Server. This bug could disclose PII and, in some cases, requires multiple packages to be completely addressed. Most of the other bugs only lead to leaks consisting of unspecified memory contents. Two notable exceptions impact KDC and SMB. The KDC has a weak encryption algorithm that could be used to decrypted and expose information related to a user or service's active session. The SMB bug could allow an attacker unauthorized file system access, meaning they could read files on the affected system.
Eight security feature bypasses are fixed in this month’s release. The patch for ADFS fixes a bug in the Primary Refresh Tokens, which are normally stored in the TPM. The tokens aren’t encrypted properly. Attackers could extract and potentially decrypt the token for reuse until the token expires or is renewed. There’s a bug in LSA that could allow a read-only domain controller (RODC) to delegate rights by granting itself a ticket. This ticket isn’t validated by a domain controller, which could lead to a read-only DC getting Read/Write privileges. A patch for the Security Account Manager adds Advanced Encryption Standard (AES) encryption as the preferred method when using the MS-SAMR protocol. Microsoft will be releasing KB5004605 with additional configuration details in the future. At the time of release, it’s mentioned, but not live yet. Frustratingly, no details are available about the other bypasses, which includes the patches for two publicly known bugs and Windows Hello.
This month’s release is rounded out by seven patches to address spoofing bugs in SharePoint Server, Bing Search, Visual Studio, Office, Authenticode, Installer, and bug that could allow certificate spoofing. In late June, Microsoft reported they were investigating reports regarding a malicious actor trying to leverage the Windows Hardware Compatibility Program (WHCP) process. While they indicated there was no evidence of certificate exposure, it’s possible this patch resulted from that investigation. They do mark the bug as publicly known, but there’s no documentation confirming the link. No details are available about any of the other spoofing patches.
As usual, the servicing stack advisory (ADV990001) was revised for multiple versions of Windows this month. No new advisories were released this month.
The next Patch Tuesday falls on August 10, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!