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

Our ICS-Themed Pwn2Own Contest Returns to Miami in 2022

25 October 2021 at 13:14

¡Bienvenidos de nuevo a Miami!

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.

ControlServer.png

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.

OPC UA.png

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.

Data Gateway-b.png

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.

HMI.png

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.

The Results

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

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

21 October 2021 at 16:12

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


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

CVE-2021-28632: Understanding Field Locks

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

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

PDF portion (important parts only):

JavaScript portion:

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

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

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

img01.jpg

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

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

img02.jpg

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

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

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

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

img03.jpg

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

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

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

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

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

CVE-2021-39840: Reversing Patch and Bypassing Locks

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

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

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

img04.jpg

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

PDF portion (important parts only):

JavaScript portion:

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

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

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

img05.jpg

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

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

Controlling Field Objects

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

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

Conclusion

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


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

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

Adding a Beta NAS Device to Pwn2Own Austin

14 October 2021 at 20:26

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.

Good luck, and we’ll see you in Austin.

Adding a Beta NAS Device to Pwn2Own Austin

The October 2021 Security Update Review

12 October 2021 at 17:28

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:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-40449 Win32k Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-41338 Windows AppContainer Firewall Rules Security Feature Bypass Vulnerability Important 5.5 Yes No SFB
CVE-2021-40469 Windows DNS Server Remote Code Execution Vulnerability Important 7.2 Yes No RCE
CVE-2021-41335 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 Yes No EoP
CVE-2021-40486 Microsoft Word Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-38672 Windows Hyper-V Remote Code Execution Vulnerability Critical 8 No No RCE
CVE-2021-40461 Windows Hyper-V Remote Code Execution Vulnerability Critical 8 No No RCE
CVE-2021-41355 .NET Core and Visual Studio Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2021-41361 Active Directory Federation Server Spoofing Vulnerability Important 5.4 No No Spoofing
CVE-2021-41337 Active Directory Security Feature Bypass Vulnerability Important 4.9 No No SFB
CVE-2021-41346 Console Window Host Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2021-40470 DirectX Graphics Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-41363 Intune Management Extension Security Feature Bypass Vulnerability Important 4.2 No No SFB
CVE-2021-41339 Microsoft DWM Core Library Elevation of Privilege Vulnerability Important 4.7 No No EoP
CVE-2021-41354 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 4.1 No No XSS
CVE-2021-40457 Microsoft Dynamics 365 Customer Engagement Cross-Site Scripting Vulnerability Important 7.4 No No XSS
CVE-2021-41353 Microsoft Dynamics 365 Sales Spoofing Vulnerability Important 5.4 No No Spoofing
CVE-2021-40472 Microsoft Excel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-40471 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40473 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40474 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40479 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40485 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34453 Microsoft Exchange Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-41348 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-26427 Microsoft Exchange Server Remote Code Execution Vulnerability Important 9 No No RCE
CVE-2021-41350 Microsoft Exchange Server Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2021-40480 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40481 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-40482 Microsoft SharePoint Server Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2021-41344 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-40487 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-40484 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-41330 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40454 Rich Text Edit Control Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-41352 SCOM Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-40478 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40488 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40489 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26441 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-41345 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40450 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-41357 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40456 Windows AD FS Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2021-40476 Windows AppContainer Elevation Of Privilege Vulnerability Important 7.5 No No EoP
CVE-2021-41347 Windows AppX Deployment Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40468 Windows Bind Filter Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-40475 Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-40443 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40466 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40467 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-41334 Windows Desktop Bridge Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-40477 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38663 Windows exFAT File System Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-38662 Windows Fast FAT File System Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-41343 Windows Fast FAT File System Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-41340 Windows Graphics Component Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-26442 Windows HTTP.sys Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-40455 Windows Installer Spoofing Vulnerability Important 5.5 No No Info
CVE-2021-41336 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-41331 Windows Media Audio Decoder Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40462 Windows Media Foundation Dolby Digital Atmos Decoders Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-41342 Windows MSHTML Platform Remote Code Execution Vulnerability Important 6.8 No No RCE
CVE-2021-40463 Windows NAT Denial of Service Vulnerability Important 7.7 No No DoS
CVE-2021-40464 Windows Nearby Sharing Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-41332 Windows Print Spooler Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-36970 Windows Print Spooler Spoofing Vulnerability Important 8.8 No No Spoofing
CVE-2021-40460 Windows Remote Procedure Call Runtime Security Feature Bypass Vulnerability Important 6.5 No No SFB
CVE-2021-36953 Windows TCP/IP Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-40465 Windows Text Shaping Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40483 Microsoft SharePoint Server Spoofing Vulnerability Low 7.6 No No Spoofing
* CVE-2021-37973 Chromium: CVE-2021-37973 Use after free in Portals High N/A No No RCE
* CVE-2021-37974 Chromium: CVE-2021-37974 Use after free in Safe Browsing High N/A No Yes RCE
* CVE-2021-37975 Chromium: CVE-2021-37975 Use after free in V8 High N/A No Yes RCE
* CVE-2021-37977 Chromium: CVE-2021-37977 Use after free in Garbage Collection High N/A No No RCE
* CVE-2021-37978 Chromium: CVE-2021-37978 Heap buffer overflow in Blink High N/A No No RCE
* CVE-2021-37979 Chromium: CVE-2021-37979 Heap buffer overflow in WebRTC High N/A No No RCE
* CVE-2021-37980 Chromium: CVE-2021-37980 Inappropriate implementation in Sandbox High N/A No No RCE
* CVE-2021-37976 Chromium: CVE-2021-37976 Information leak in core Medium N/A No No Info
* CVE-2020-1971 OpenSSL: CVE-2020-1971 EDIPARTYNAME NULL pointer de-reference Important N/A No No DoS
* CVE-2021-3449 OpenSSL: CVE-2021-3449 NULL pointer deref in signature_algorithms processing Important N/A No No DoS
* CVE-2021-3450 OpenSSL: CVE-2021-3450 CA certificate check bypass with X509_V_FLAG_X509_STRICT Important N/A No No Info

* 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.

Looking Ahead

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!

The October 2021 Security Update Review

CVE-2021-26420: Remote Code Execution in SharePoint via Workflow Compilation

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.   

The Vulnerability

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:

Picture2.png

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:

Picture3.png

Now click the “+ Create site” link:

Picture4.png

Choose Team Site.

Pick a name for the new site. Here we use testsiteofuser2.

Picture5.png

Click “Finish” and the new site will be created:

Picture6.png

Now we need to create a new list. Click on the “Site contents” link: 

Picture7.png

Then click “+ New” -> “List”:

Picture8.png

Enter any available name. For example, “NewList”:

Picture9.png

And click “Create”:

Picture10.png

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:

Picture11.png

We will be redirected to the listedit.aspx page:

Picture12.png

We need value of the List URL parameter. In my case it is:

28e11fd2-9f76-418c-83ea-dc0d8f3c184b 

We need to place this value into the ListId attribute in the workflow config file, WF02config.txt

Picture13.png

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:

Picture14.png

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:

Picture15.png

We are almost ready for the final step. But first, let’s check the C:\windows\temp folder on our target SharePoint server:

Picture16.png

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"

> SP_soap_RCE_PoC.exe http://sp2019/sites/testsiteofuser2/ user2 [email protected] contoso "Shared Documents/WF02config.xml"

Picture17.png

We received a “Success” result. Now to trigger the RCE, we just need to add a new item to NewList

Picture18.png

Click on the “Save” button there.

Let’s check C:\windows\temp folder on our target SharePoint server:

Picture19.png

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.

Picture20.png

Conclusion

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

CVE-2021-26084: Details on the Recently Exploited Atlassian Confluence OGNL Injection Bug

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.

The Vulnerability

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.

Conclusion

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

The September 2021 Security Update Review

14 September 2021 at 17:37

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:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-40444 Microsoft MSHTML Remote Code Execution Vulnerability Important 8.8 Yes Yes RCE
CVE-2021-36968 Windows DNS Elevation of Privilege Vulnerability Important 7.8 Yes No EoP
CVE-2021-38647 Open Management Infrastructure Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-26435 Windows Scripting Engine Memory Corruption Vulnerability Critical 8.1 No No RCE
CVE-2021-36965 Windows WLAN AutoConfig Service Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-36956 Azure Sphere Information Disclosure Vulnerability Important 4.4 No No Info
CVE-2021-38632 BitLocker Security Feature Bypass Vulnerability Important 5.7 No No SFB
CVE-2021-38661 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-40448 Microsoft Accessibility Insights for Android Information Disclosure Vulnerability Important 6.3 No No Info
CVE-2021-40440 Microsoft Dynamics Business Central Cross-site Scripting Vulnerability Important 5.4 No No XSS
CVE-2021-26436 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 6.1 No No EoP
CVE-2021-36930 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 5.3 No No EoP
CVE-2021-38669 Microsoft Edge (Chromium-based) Tampering Vulnerability Important 6.4 No No Tampering
CVE-2021-38641 Microsoft Edge for Android Spoofing Vulnerability Important 6.1 No No Spoofing
CVE-2021-38642 Microsoft Edge for iOS Spoofing Vulnerability Important 6.1 No No Spoofing
CVE-2021-38655 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38644 Microsoft MPEG-2 Video Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38646 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38657 Microsoft Office Graphics Component Information Disclosure Vulnerability Important 6.1 No No Info
CVE-2021-38658 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38660 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38659 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38650 Microsoft Office Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-38653 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38654 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38651 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-38652 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-38634 Microsoft Windows Update Client Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2021-38656 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-38645 Open Management Infrastructure Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38648 Open Management Infrastructure Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38649 Open Management Infrastructure Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-26437 Visual Studio Code Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2021-26434 Visual Studio Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36952 Visual Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-36975 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38639 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38628 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38638 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38629 Windows Ancillary Function Driver for WinSock Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-36959 Windows Authenticode Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2021-36954 Windows Bind Filter Driver Elevation of Privilege Vulnerability Important 8.8 No No EoP
CVE-2021-36963 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36955 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38633 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36964 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38630 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36961 Windows Installer Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-36962 Windows Installer Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-38625 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38626 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38624 Windows Key Storage Provider Security Feature Bypass Vulnerability Important 6.5 No No SFB
CVE-2021-38667 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-38671 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-40447 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36969 Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-38635 Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-38636 Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-36973 Windows Redirected Drive Buffering System Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36974 Windows SMB Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36960 Windows SMB Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-36972 Windows SMB Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-38637 Windows Storage Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-36966 Windows Subsystem for Linux Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36967 Windows WLAN AutoConfig Service Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-26439 Microsoft Edge for Android Information Disclosure Vulnerability Moderate 4.6 No No Info
CVE-2021-30606 Chromium: CVE-2021-30606 Use after free in Blink High N/A No No RCE
CVE-2021-30607 Chromium: CVE-2021-30607 Use after free in Permissions High N/A No No RCE
CVE-2021-30608 Chromium: CVE-2021-30608 Use after free in Web Share High N/A No No RCE
CVE-2021-30609 Chromium: CVE-2021-30609 Use after free in Sign-In High N/A No No RCE
CVE-2021-30610 Chromium: CVE-2021-30610 Use after free in Extensions API High N/A No No RCE
CVE-2021-30632 Chromium: CVE-2021-30632 Out of bounds write in V8 High N/A No Yes RCE
CVE-2021-30623 Chromium: CVE-2021-30623 Use after free in Bookmarks Low N/A No No RCE
CVE-2021-30624 Chromium: CVE-2021-30624 Use after free in Autofill Low N/A No No RCE
CVE-2021-30611 Chromium: CVE-2021-30611 Use after free in WebRTC Medium N/A No No RCE
CVE-2021-30612 Chromium: CVE-2021-30612 Use after free in WebRTC Medium N/A No No RCE
CVE-2021-30613 Chromium: CVE-2021-30613 Use after free in Base internals Medium N/A No No RCE
CVE-2021-30614 Chromium: CVE-2021-30614 Heap buffer overflow in TabStrip Medium N/A No No RCE
CVE-2021-30615 Chromium: CVE-2021-30615 Cross-origin data leak in Navigation Medium N/A No No Info
CVE-2021-30616 Chromium: CVE-2021-30616 Use after free in Media Medium N/A No No RCE
CVE-2021-30617 Chromium: CVE-2021-30617 Policy bypass in Blink Medium N/A No No SFB
CVE-2021-30618 Chromium: CVE-2021-30618 Inappropriate implementation in DevTools Medium N/A No No RCE
CVE-2021-30619 Chromium: CVE-2021-30619 UI Spoofing in Autofill Medium N/A No No Spoofing
CVE-2021-30620 Chromium: CVE-2021-30620 Insufficient policy enforcement in Blink Medium N/A No No SFB
CVE-2021-30621 Chromium: CVE-2021-30621 UI Spoofing in Autofill Medium N/A No No Spoofing
CVE-2021-30622 Chromium: CVE-2021-30622 Use after free in WebApp Installs Medium N/A No No RCE

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.

Looking Ahead

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!

The September 2021 Security Update Review

Analysis of a Parallels Desktop Stack Clash Vulnerability and Variant Hunting using Binary Ninja

9 September 2021 at 14:59

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.

Figure 1 - Variable size TG_PAGED_REQUEST structure in guest memory

Figure 1 - Variable size TG_PAGED_REQUEST structure in guest memory

Figure 2 - Variable size TG_PAGED_BUFFER structure in TG_PAGED_REQUEST

Figure 2 - Variable size TG_PAGED_BUFFER structure in TG_PAGED_REQUEST

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:

TG_DataBuffer *TG_GetBuffer(TG_ReqBuffer *buf, uint32_t index, uint32 writable) uint32_t TG_ReadBuffer(TG_DataBuffer *buf, uint64_t offset, void *dst, size_t size) uint32_t TG_WriteBuffer(TG_DataBuffer *buf, uint64_t offset, void *src, size_t size)
void *TG_GetInlineBytes(TG_DataBuffer *buf)

Return of the Stack Clash Vulnerability

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

Figure 3 - Normal stack operation (left) vs stack jumping due to large allocation (right)

Figure 3 - Normal stack operation (left) vs stack jumping due to large allocation (right)

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.

Figure 4 - Vulnerability in TG_REQUEST_INVSHARING handling

Figure 4 - Vulnerability in TG_REQUEST_INVSHARING handling

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.

Figure 5 - Sample code with stack clash mitigation

Figure 5 - Sample code with stack clash mitigation

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:

Figure 6 - LC_VERSION_MIN_MACOSX&nbsp; information of prl_vm_app

Figure 6 - LC_VERSION_MIN_MACOSX  information of 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:

Figure 7 - Backward compatibility with 10.13 disables ___chkstk_darwin() (right)

Figure 7 - Backward compatibility with 10.13 disables ___chkstk_darwin() (right)

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.

Figure 8 - Fig 8. Apple Clang calls ___chkstk_darwin (left) vs GCC mitigation inlined (right)

Figure 8 - Fig 8. Apple Clang calls ___chkstk_darwin (left) vs GCC mitigation inlined (right)

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.

Figure 9 - Fig 9. Known stack offset (left) vs Undetermined value after alloca() (right)

Figure 9 - Fig 9. Known stack offset (left) vs Undetermined value after alloca() (right)

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.

      0x1001c6e35 - ZDI-21-1056 - TG_REQUEST_GL_CREATE_CONTEXT
      0x10025591a - ZDI-21-1055 - TG_REQUEST_DIRECT3D_CREATE_CONTEXT
      0x10080bcd9 - ZDI-21-937 - (Pwn2Own) - TG_REQUEST_INVSHARING

Figure 10 - Pwn2Own bug and its variants found using Binary Ninja

Figure 10 - Pwn2Own bug and its variants found using Binary Ninja

Conclusion

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

CVE-2021-2429: A Heap-based Buffer Overflow Bug in the MySQL InnoDB memcached Plugin

2 September 2021 at 16:05

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 Vulnerability

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:

The keys specified in the GET command are tokenized by process_get_command() and then handled one by one in innodb_get() .

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 Trigger

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 Patch

The vulnerability was fixed in version 8.0.26. The patch is straightforward. It explicitly checks the length before copying.

Conclusion

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

ProxyToken: An Authentication Bypass in Microsoft Exchange Server

30 August 2021 at 12:59

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 Trigger

The essential HTTP traffic needed to trigger the vulnerability is as follows:

Picture1.png

“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:

In Microsoft.Exchange.HttpProxy.ProxyModule.SelectHandlerForUnauthenticatedRequest:

Picture2.png
Picture3.png

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:

Picture4.png

An example of the final request would then be as follows:

Picture5.png

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.

Conclusion

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

From Pwn2Own 2021: A New Attack Surface on Microsoft Exchange - ProxyShell!

18 August 2021 at 14:54

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.

ProxyShell consists of 3 vulnerabilities:

CVE-2021-34473 - Pre-auth Path Confusion leads to ACL Bypass
CVE-2021-34523 - Elevation of Privilege on Exchange PowerShell Backend
CVE-2021-31207 - Post-auth Arbitrary-File-Write leads to RCE

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:

         https://exchange/OWA/[email protected]/Default.aspx

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.

HttpProxy/EwsAutodiscoverProxyRequestHandler.cs

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:

         https://exchange/autodiscover/[email protected]/?&          Email=autodiscover/autodiscover.json%[email protected]

upload_478912a7f6e2273a32eb713e9bce6e25.png

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.

upload_904b9bf84f3227a749234404c6062591.png

CVE-2021-34523 - Exchange PowerShell Backend Elevation-of-Privilege

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.

Configuration\RemotePowershellBackendCmdletProxyModule.cs

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.

  New-MailboxExportRequest -Mailbox [email protected] -FilePath
  \\127.0.0.1\C$\path\to\shell.aspx

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.

The Exploit

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:

  1. New-ManagementRoleAssignment to grant ourselves the Mailbox Import Export role
  2. New-MailboxExportRequest to export the mailbox containing our malicious payload to webroot, to act as our web shell

Additional notes

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:

The Patch

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:

Msft.png

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.

upload_7c2d5577bfa74e8024f562bc3154f40c.png

Conclusion

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!

Pwn2Own Austin 2021: Phones, Printers, NAS, and more!

12 August 2021 at 15:00

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:

Google Pixel 5
Samsung Galaxy S21
Apple iPhone 12

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:

Printers:

HP Color LaserJet Pro MFP M283fdw
Lexmark MC3224i
Canon ImageCLASS MF644Cdw

Home Automation:

Portal from Facebook
Amazon Echo Show 10
Google Nest Hub (2nd Gen)
Sonos One Speaker
Apple HomePod mini

Televisions:

Sony X80J Series - 43”
Samsung Q60A Series – 43”

Routers:

TP-Link AC1750 Smart Wi-Fi Router
NETGEAR Nighthawk Smart Wi-Fi Router (R6700 AC1750)
Cisco RV340
Mikrotik RB4011iGS+RM
Ubiquiti Networks EdgeRouter 4

Network Attached Storage (NAS):

Synology DiskStation DS920+
Western Digital My Cloud Pro Series PR4100 
Western Digital 3TB My Cloud Home Personal Cloud

External Storage:

SanDisk Professional G-DRIVE ArmorLock SSD 1TB

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:

Phone_Table.png

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.

Printer Category

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.

Printer_Table.png

NAS Category

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. 

NAS_Table2.png

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.   

Drive_Table.png

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.

Speaker_Table-2.png

Router 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.

Router_Table-2.png

Contestants can register for attempts against the WAN interface, the LAN interface, or both interfaces on the same device.

Television Category

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.

TV_Table.png

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.

The Results

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.

WesternDigital_Logo_1L_B[1].jpg

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

Pwn2Own Austin 2021: Phones, Printers, NAS, and more!

The August 2021 Security Update Review

10 August 2021 at 17:22

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:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-36948 Windows Update Medic Service Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-36936 Windows Print Spooler Remote Code Execution Vulnerability Critical 8.8 Yes No RCE
CVE-2021-36942 Windows LSA Spoofing Vulnerability Important 9.8 Yes No Spoofing
CVE-2021-34535 Remote Desktop Client Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-34480 Scripting Engine Memory Corruption Vulnerability Critical 6.8 No No RCE
CVE-2021-34530 Windows Graphics Component Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34534 Windows MSHTML Platform Remote Code Execution Vulnerability Critical 6.8 No No RCE
CVE-2021-26432 Windows Services for NFS ONCRPC XDR Driver Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-26424 Windows TCP/IP Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-26423 .NET Core and Visual Studio Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34485 .NET Core and Visual Studio Information Disclosure Vulnerability Important 5 No No Info
CVE-2021-34532 ASP.NET Core and Visual Studio Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-33762 Azure CycleCloud Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-36943 Azure CycleCloud Elevation of Privilege Vulnerability Important 4 No No EoP
CVE-2021-26430 Azure Sphere Denial of Service Vulnerability Important 6 No No DoS
CVE-2021-26429 Azure Sphere Elevation of Privilege Vulnerability Important 7.7 No No EoP
CVE-2021-26428 Azure Sphere Information Disclosure Vulnerability Important 4.4 No No Info
CVE-2021-36949 Microsoft Azure Active Directory Connect Authentication Bypass Vulnerability Important 7.1 No No SFB
CVE-2021-36950 Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability Important 5.4 No No XSS
CVE-2021-34524 Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-36946 Microsoft Dynamics Business Central Cross-site Scripting Vulnerability Important 5.4 No No XSS
CVE-2021-34478 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-36940 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-34471 Microsoft Windows Defender Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36941 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34536 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36945 Windows 10 Update Assistant Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2021-34537 Windows Bluetooth Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36938 Windows Cryptographic Primitives Library Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-36927 Windows Digital TV Tuner device registration application Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26425 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34486 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34487 Windows Event Tracing Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34533 Windows Graphics Component Font Parsing Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-36937 Windows Media MPEG-4 Video Decoder Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34483 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-36947 Windows Print Spooler Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-26431 Windows Recovery Environment Agent Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26433 Windows Services for NFS ONCRPC XDR Driver Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-36926 Windows Services for NFS ONCRPC XDR Driver Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-36932 Windows Services for NFS ONCRPC XDR Driver Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-36933 Windows Services for NFS ONCRPC XDR Driver Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-26426 Windows User Account Profile Picture Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34484 Windows User Profile Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-30590 Chromium: CVE-2021-30590 Heap buffer overflow in Bookmarks High N/A No No RCE
CVE-2021-30591 Chromium: CVE-2021-30591 Use after free in File System API High N/A No No RCE
CVE-2021-30592 Chromium: CVE-2021-30592 Out of bounds write in Tab Groups High N/A No No RCE
CVE-2021-30593 Chromium: CVE-2021-30593 Out of bounds read in Tab Strip High N/A No No Info
CVE-2021-30594 Chromium: CVE-2021-30594 Use after free in Page Info UI High N/A No No RCE
CVE-2021-30596 Chromium: CVE-2021-30596 Incorrect security UI in Navigation Medium N/A No No SFB
CVE-2021-30597 Chromium: CVE-2021-30597 Use after free in Browser UI Medium N/A No No RCE

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.

Looking Ahead

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!

The August 2021 Security Update Review

CVE-2021-27077: Selecting Bitmaps into Mismatched Device Contexts

28 July 2021 at 15:28

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:

1) SeCreateTokenPrivilege
2) SeSecurityPrivilege
3) SeAssignPrimaryTokenPrivilege
4) SeTcbPrivilege

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:

0x6c0859b2

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.

The Patch

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:

reg.exe add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Policies /v {b7ca08da-d52e-4acb-9866-7dad281e4489} /t REG_DWORD /d 1

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

CVE-2021-31969: Underflowing in the Clouds

21 July 2021 at 15:16

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:

Figure 1 - The HsmFltProcessHSMControl Function

Figure 1 - The HsmFltProcessHSMControl Function

For an operation with code 0xC0000003, it will eventually call HsmFltProcessUpdatePlaceholder:

Figure 2 - Call to HsmFltProcessUpdatePlaceholder

Figure 2 - Call to 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:

Figure 3 - Calling HsmpRpiDecompressBuffer

Figure 3 - Calling 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.

Figure 4 - Showing the integer underflow

Figure 4 - Showing the integer underflow

The Patch

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.

Figure 5 - Patch from Microsoft

Figure 5 - Patch from Microsoft

Final notes

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.

CVE-2021-31969: Underflowing in the Clouds

The July 2021 Security Update Review

13 July 2021 at 17:24

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:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-34527 Windows Print Spooler Remote Code Execution Vulnerability Critical 8.8 Yes Yes RCE
CVE-2021-34448 Scripting Engine Memory Corruption Vulnerability Critical 6.8 No Yes RCE
CVE-2021-31979 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-33771 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-34473 Microsoft Exchange Server Remote Code Execution Vulnerability Critical 9.1 Yes No RCE
CVE-2021-33781 Active Directory Security Feature Bypass Vulnerability Important 8.1 Yes No SFB
CVE-2021-34523 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 9 Yes No EoP
CVE-2021-33779 Windows ADFS Security Feature Bypass Vulnerability Important 8.1 Yes No SFB
CVE-2021-34492 Windows Certificate Spoofing Vulnerability Important 8.1 Yes No Spoofing
CVE-2021-34474 Dynamics Business Central Remote Code Execution Vulnerability Critical 8 No No RCE
CVE-2021-34464 Microsoft Defender Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34522 Microsoft Defender Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34439 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34503 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34494 Windows DNS Server Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2021-34450 Windows Hyper-V Remote Code Execution Vulnerability Critical 8.5 No No RCE
CVE-2021-34458 Windows Kernel Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-33740 Windows Media Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-34497 Windows MSHTML Platform Remote Code Execution Vulnerability Critical 6.8 No No RCE
CVE-2021-34476 Bowser.sys Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34489 DirectWrite Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34440 GDI+ Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31947 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33775 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33776 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33777 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33778 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33760 Media Foundation Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-33753 Microsoft Bing Search Spoofing Vulnerability Important 4.7 No No Spoofing
CVE-2021-34501 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34518 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33766 Microsoft Exchange Information Disclosure Vulnerability Important 7.3 No No Info
CVE-2021-33768 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-34470 Microsoft Exchange Server Elevation of Privilege Vulnerability Important 8 No No EoP
CVE-2021-31196 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2021-31206 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.6 No No RCE
CVE-2021-34451 Microsoft Office Online Server Spoofing Vulnerability Important 5.3 No No Spoofing
CVE-2021-34469 Microsoft Office Security Feature Bypass Vulnerability Important 8.2 No No SFB
CVE-2021-34467 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-34468 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-34520 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-34517 Microsoft SharePoint Server Spoofing Vulnerability Important 5.3 No No Spoofing
CVE-2021-34479 Microsoft Visual Studio Spoofing Vulnerability Important 7.8 No No Spoofing
CVE-2021-34441 Microsoft Windows Media Foundation Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34452 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33767 Open Enclave SDK Elevation of Privilege Vulnerability Important 8.2 No No EoP
CVE-2021-31984 Power BI Remote Code Execution Vulnerability Important 7.6 No No RCE
CVE-2021-34521 Raw Image Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33751 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34460 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34510 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34512 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34513 Storage Spaces Controller Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34509 Storage Spaces Controller Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34477 Visual Studio Code .NET Runtime Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34528 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34529 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34449 Win32k Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34516 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34491 Win32k Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34504 Windows Address Book Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33785 Windows AF_UNIX Socket Provider Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34459 Windows AppContainer Elevation Of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34462 Windows AppX Deployment Extensions Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-33782 Windows Authenticode Spoofing Vulnerability Important 5.5 No No Spoofing
CVE-2021-33784 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34488 Windows Console Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34461 Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33759 Windows Desktop Bridge Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33745 Windows DNS Server Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-34442 Windows DNS Server Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34444 Windows DNS Server Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-34499 Windows DNS Server Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2021-33746 Windows DNS Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2021-33754 Windows DNS Server Remote Code Execution Vulnerability Important 8 No No RCE
CVE-2021-33780 Windows DNS Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-34525 Windows DNS Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33749 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33750 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33752 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33756 Windows DNS Snap-in Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-33774 Windows Event Tracing Elevation of Privilege Vulnerability Important 7 No No EoP
CVE-2021-34455 Windows File History Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34438 Windows Font Driver Host Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-34498 Windows GDI Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34496 Windows GDI Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34466 Windows Hello Security Feature Bypass Vulnerability Important 5.7 No No SFB
CVE-2021-34446 Windows HTML Platform Security Feature Bypass Vulnerability Important 8 No No SFB
CVE-2021-33755 Windows Hyper-V Denial of Service Vulnerability Important 6.3 No No DoS
CVE-2021-33758 Windows Hyper-V Denial of Service Vulnerability Important 7.7 No No DoS
CVE-2021-34511 Windows Installer Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33765 Windows Installer Spoofing Vulnerability Important 6.2 No No Spoofing
CVE-2021-31961 Windows InstallService Elevation of Privilege Vulnerability Important 6.1 No No EoP
CVE-2021-34514 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34500 Windows Kernel Memory Information Disclosure Vulnerability Important 6.3 No No Info
CVE-2021-34508 Windows Kernel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-33764 Windows Key Distribution Center Information Disclosure Vulnerability Important 5.9 No No Info
CVE-2021-33788 Windows LSA Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-33786 Windows LSA Security Feature Bypass Vulnerability Important 8.1 No No SFB
CVE-2021-34447 Windows MSHTML Platform Remote Code Execution Vulnerability Important 6.8 No No RCE
CVE-2021-34493 Windows Partition Management Driver Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2021-33743 Windows Projected File System Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33761 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33773 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34445 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-34456 Windows Remote Access Connection Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-33763 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34454 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34457 Windows Remote Access Connection Manager Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-34507 Windows Remote Assistance Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2021-33744 Windows Secure Kernel Mode Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2021-33757 Windows Security Account Manager Remote Protocol Security Feature Bypass Vulnerability Important 5.3 No No SFB
CVE-2021-33783 Windows SMB Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31183 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-33772 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34490 Windows TCP/IP Driver Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-34519 Microsoft SharePoint Server Information Disclosure Vulnerability Moderate 5.3 No No Info

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.

Looking Ahead

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!

The July 2021 Security Update Review

CVE-2021-28474: SharePoint Remote Code Execution via Server-Side Control Interpretation Conflict

In May of 2021, Microsoft released a patch to correct CVE-2021-28474, a remote code execution bug in supported versions of Microsoft SharePoint Server. This bug was reported to ZDI by an anonymous researcher and is also known as ZDI-21-574. This blog takes a deeper look at the root cause of this vulnerability.

The vulnerability allows authenticated users to execute arbitrary .NET code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker needs SPBasePermissions.ManageLists permissions for a SharePoint site. By default, authenticated SharePoint users can create sites/subsites and will have all necessary permissions.   

The Vulnerability

This problem exists due to an inconsistency between code that is used for security verification and code that is used for the actual processing of user input.

Security verification is performed by EditingPageParser.VerifyControlOnSafeList(). This function verifies that the provided input does not contain unsafe controls, meaning any control that is not marked as safe by SafeControl elements in web.config file.

The EditingPageParser.ParseStringInternal() function parses user input from dscXml and populates hashtable with information from the Register directives and hashtable2 with values from the tags of server controls. In the next step, it tries to verify each element of hashtable2 against the SafeControl elements from the web.config file. If a control is not marked there as safe, it throws an exception.

Let’s take a closer look at how values in hashtable2 are populated:

As we can see, the SharePoint server verifies only server-side controls (tags with the runat="server" attribute). This is reasonable since client-side elements do not require verification.

 If verification passes, SharePoint will process the provided markup. Let’s review the code that performs the processing:

As you can see, the steps for parsing content at processing time are very similar to the parsing steps at verification time. However, there is a critical one-line difference:

      text4 = HttpUtility.HtmlDecode(text4);

At processing time, attribute values are HTML-decoded by the parser, but there is no corresponding line at verification time. This means that if we have an ASPX tag with an attribute such as runat="&#115;erver", the EditingPageParser.VerifyControlOnSafeList() function will not consider it a server-side control and will not check it for safety. At processing time, however, it will be recognized and executed as a server-side control.

Exploitation

For our attack, we will use the System.Web.UI.WebControls.Xml control. It allows us to retrieve information from an arbitrary XML file. We can use this to exfiltrate the machineKey section from web.config, which we allow us to forge an arbitrary ViewState and achieve remote code execution via ViewState deserialization.

We can see that System.Web.UI.WebControls.Xml is marked as unsafe via a SafeControl element in web.config:

To deliver our payload to the server, we will use the WebPartPagesWebService.ExecuteProxyUpdates web API method that is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It allows us to render ASPX markup from the OuterHtml attribute in Design mode. User input will be verified by the VerifyControlOnSafeList method.

For a successful attack, we need to provide a relative path to any existing site page:

We can use information from the machinekey section from web.config to create a valid ViewState that will be deserialized by SharePoint. This allows us to run an arbitrary OS command via deserialization of untrusted data.

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 January 2021 patch (version 16.0.10370.20001‎) and a couple of users have been added, including “user2” as a regular, unprivileged user.

On the attacker side, we need any supported web browser, our PoC application for sending SOAP requests to the server, and the ysoserial.net tool. For this demonstration, we are using Firefox as our browser.

Getting Remote Code Execution

Let’s begin by visiting our SharePoint Server and authenticating as “user2”.

Picture1.png

Let’s create a site so we will be the owner and have all permissions.

Click on “SharePoint” on the top panel:

Picture2.png

Now click “+ Create site” link:

Picture3.png

Choose Team Site.

Now we need to pick a name for the new site. In this case, we use ts01.

Picture4.png

Click “Finish” and the new site will be created:

Picture5.png

Now we need a relative path to any site page in this site. We can see list of pages by going to /SitePages/Forms/ByAuthor.aspx:

Picture6.png

We can click on the desired page and take the relative path from the address bar (note that we omit the leading site name and “/” ) :

Picture7.png

In our case, it is SitePages/Home.aspx.

Now we use our custom executable to send a request to the server that triggers the vulnerability. We need to provide the URL to our site, credentials, and the relative path determined above. In this case:

      >SP_soap_RCE_PoC.exe http://sp2019/sites/ts01/ user2 [email protected] contoso "SitePages/Home.aspx"

Picture8.png

If our attack is successful, we receive the content of web.config:

Picture9.png

Within the file, we search for the machineKey element:

Picture10.png

For our RCE attack, we need the value of validationKey. In this case it is:

      validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”

We can also see the algorithm: validation="HMACSHA256".

Using this information, we can perform our remote code execution attack. Before the final step, let’s go to the target SharePoint server and open C:\windows\temp folder:

Picture11.png

We verify there is no SP_RCE_01.txt file yet.

Now let’s go back to the “attacker” machine, and open the Success.aspx page on our site:

In this case, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:

Picture12.png

Now we need to open the source code view for this page and find the value of __VIEWSTATEGENERATOR:

Picture13.png

In this example, it is AF878507.

We now have all the data needed to forge an arbitrary ViewState:

 __VIEWSTATEGENERATOR=AF878507

validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79

validationAlg=HMACSHA256

We generate the ViewState using ysoserial, as follows:

>ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo RCE > c:/windows/temp/SP_RCE_01.txt" --generator="AF878507" --validationkey="FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79" --validationalg="HMACSHA256" --islegacy --minify

Picture14.png

Here is the resulting payload:

We need to URL-encode it and send it as the __VIEWSTATE parameter in the query string in a request to our server:

We paste this URL into the browser. The response appears as an error:

Picture15.png

Nevertheless, when we check the C:\windows\temp folder on our target server again:

Picture16.png

Our target file was successfully created, demonstrating that we achieved code execution. In the same way, an attacker can execute any OS command in the context of the SharePoint web application.

Conclusion

Microsoft patched this in May and assigned identifier CVE-2021-28474, with a CVSS score of 8.8. SharePoint continues to be an attractive target for researchers and attackers alike, and several 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-28474: SharePoint Remote Code Execution via Server-Side Control Interpretation Conflict

CVE-2021-26892: An Authorization Bypass on the Microsoft Windows EFI System Partition

In October 2020, researcher Abdelhamid Naceri, also known as halov, submitted a unique vulnerability to the ZDI. This vulnerability in Windows 10 allows a low-privileged user to wipe out arbitrary files needed for UEFI boot. The attack can even be conducted from a low integrity level.

There is a great deal of mystery surrounding this case and I will explain the parts that I am able to.

The vulnerability is identified as ZDI-21-330/CVE-2021-26892 and was patched by Microsoft in March 2021.

Background

When any computer system starts up from a cold state, the very first instructions that the processor executes come from firmware. Although we would like to quickly transition to executing instructions that are stored on disk (e.g., the operating system), those instruction bytes are not yet available in memory upon a cold start. Hence the processor must start by executing firmware instructions. The firmware provides the needed instructions for retrieving OS boot instructions from disk, and eventually jumping into the OS.

UEFI is a type of firmware. An in-depth treatment of UEFI is beyond the scope of this article, but for our purposes, we need to know that UEFI firmware will look for a boot device (for example, the primary fixed drive) that contains a special partition known as the EFI System Partition or ESP. This partition is formatted with one of the variants of the FAT file system that the firmware can parse. Within this file system, the firmware expects to find a file with extension .EFI, known as a boot loader, from which it can read the further steps needed in order to continue starting the OS. There are often multiple .EFI files present corresponding to different architectures. A UEFI firmware is also capable of handling the case of multiple available boot devices.

The EFI System Partition and Security

As is known, FAT file systems do not record ACLs or any other security information for files. If a FAT file system is mounted on Windows, every file has, in effect, an empty security descriptor, making the file both world-readable and world-writable. Clearly this is unacceptable for the EFI System Partition. If the files on the ESP were world-writable, it would be trivial for any user to damage the system by deleting critical files needed for boot. An unprivileged user could even install a bootkit by replacing the .EFI file with one containing malicious instructions.

Accordingly, Windows does some behind-the-scenes work to impose special restrictions on access to the ESP. To begin with, the EFI partition is not mounted to any drive letter by default. If a non-administrative user attempts to mount it to a drive letter, access is denied. Even if an administrator mounts it to a driver letter (and there is, in fact, a special command-line syntax for mounting the EFI partition: mountvol F: /S), a non-administrative user will still not have any access to the mounted drive.

Bypassing the ESP Authorization Restrictions

Despite these restrictions, the researcher found that a low-privileged user, even running at low integrity, can still gain some access to the files on the EFI System Partition.

To avoid the need to assign a drive letter, an attacker can call the CreateFile API with a full volume name and path to a specific known file, for example:

      \\?\Volume{641e9a14-b3d6-425c-af6e-7d585169951e}\EFI\Microsoft\Boot\bootmgfw.efi

The volume GUID can be obtained via enumeration of volumes, using the FindFirstVolume and FindNextVolume APIs. In this way, an attacker can obtain a handle to an arbitrary file within the EFI partition, as long as the path is predictable, which is common. I did an experiment and called GetSecurityInfo on the resulting handle, and as would be expected, I received an empty security descriptor, indicating that the file is world-readable and writable: O:WDG:WDD:NO_ACCESS_CONTROL. Even so, Windows does not behave in the way that this security descriptor would imply. Attempts to open the file for reading or writing (GENERIC_READ or GENERIC_WRITE) are denied.

Despite this – and here is the researcher's key finding – there is still a way for an attacker to gain a limited amount of write access. The trick is to call CreateFile without requesting any access at all (neither GENERIC_READ nor GENERIC_WRITE) but specifying a disposition of CREATE_ALWAYS. This flag requests that if the destination file exists, it should be immediately truncated to zero length. Somehow, this combination slips past the authorization logic that Windows implements for the ESP. Although the access mask on the resulting handle does not permit the attacker to write any bytes to the file, Windows nevertheless truncates the file during the CreateFile call as requested. By wiping out the contents of critical .EFI files, the attacker can render the system unable to boot.

Difficulties in Reproduction of the Vulnerability

While analyzing this case, I was mystified to find that it cannot be reproduced on certain hypervisor platforms. I found it could be reproduced on bare metal as well as on HyperV. On ESXi, however, even though the security descriptor comes up as the world-writable O:WDG:WDD:NO_ACCESS_CONTROL, an attempt to truncate the .EFI files fails with ERROR_ACCESS_DENIED. I have no explanation for the difference in behavior between bare metal and ESXi.

Conclusion

When experimenting with this vulnerability it is a good idea to make backups of the .EFI files that will be deleted, particularly when running on bare metal. A successful reproduction results in a complete inability to boot the machine.

The researcher who submitted this bug (halov) is a frequent contributor to the ZDI program, and we hope to continue to see his always interesting research in the future.

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

CVE-2021-26892: An Authorization Bypass on the Microsoft Windows EFI System Partition

CVE-2021-1497: Cisco HyperFlex HX Auth Handling Remote Command Execution

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Kc Udonsi and Yazhi Wang of the Trend Micro Research Team detail a recent code execution vulnerability in the Cisco HyperFlex HX Data Platform. The bug was originally discovered by Nikita Abramov and Mikhail Klyuchnikov of Positive Technologies. The following is a portion of their write-up covering CVE-2021-1497, with a few minimal modifications.


Cisco HyperFlex HX Data Platform is a high-performance, extensible distributed file system that supports multiple hypervisors with a wide range of enterprise-grade data management and optimization services. A remote code execution vulnerability has been reported in the product due to improper input sanitization.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted request to the web-based management interface of the target server. Successful exploitation could lead to the execution of arbitrary code in the context of the root user. Cisco patched this vulnerability in May 2021.

The Vulnerability

Cisco HyperFlex HX Data Platform Installer uses an HTTP-based web console. It is accessible through the following address:

         https://<server_name>

Where <server_name> is the name of the machine on which Cisco HyperFlex HX is installed. 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 line terminator sequence consisting of a Carriage Return (CR) character followed by a Line Feed (LF) character, and 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 Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like this:

A similar request using the POST method might look like this:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

        var1=value1&var2=value2&var3=value3...

Remote users can submit a request to the /auth/ endpoint of the Cisco HyperFlex HX server to authenticate themselves before installation operations. Below is an example of a request submitted to /auth/ to perform a system restore-and-reboot operation:

The frontend NGINX server will forward the HTTP request to the backend HTTP server listening on TCP/8082:

The HTTP server is implemented in an ELF executable file /opt/springpath/auth/auth. When it receives an HTTP request sent to the /auth/ endpoint, it will call the function main_loginHandler() to handle the request. The function will first extract the salt value from the line of /etc/shadow file using the provided username value from the HTTP request. Then it will call the function main_validatePassword() to validate the user-supplied password. This function finally calls main_checkHash() function. To calculate the hash value of the supplied password, this function uses generated Python code as follows:

        python -c 'import crypt; print crypt.crypt("<somePass>", "<salt>")'

Here <somePass> is the password supplied in the HTTP request and <salt> is the value extracted from the /etc/shadow file.

A Python code injection vulnerability exists here. The code fails to correctly validate the value of password before using it to generate the Python code string. An attacker can include Python command injection characters in the value of the password parameter to inject arbitrary Python code. For example, a value like the following:

implies the generated Python code will be like:

Therefore, the OS command COMMAND will be executed when the generated Python code is called.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted request to the target server. Successful exploitation can result in the execution of arbitrary commands in the security context of the root user.

Conclusion

Cisco patched this vulnerability in May 2021. In their advisory, they mention there are no workarounds. Affected customers should apply the vendor patch to ensure they are protected from this vulnerability.

Special thanks to Kc Udonsi 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-1497: Cisco HyperFlex HX Auth Handling Remote Command Execution

❌