RSS Security

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☑ ☆ ✇ Zero Day Initiative - Blog

The September 2021 Security Update Review

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Reno Robert

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Lucas Leong

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

☑ ☆ ✇ Zero Day Initiative - Blog

ProxyToken: An Authentication Bypass in Microsoft Exchange Server

By: Simon Zuckerbraun

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Guest Blogger

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!

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Brian Gorenc

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_Table.png

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

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!

☑ ☆ ✇ Zero Day Initiative - Blog

The August 2021 Security Update Review

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Guest Blogger

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

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-31969: Underflowing in the Clouds

By: Hossein Lotfi

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

☑ ☆ ✇ Zero Day Initiative - Blog

The July 2021 Security Update Review

By: Dustin Childs

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: The ZDI Research Team

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Simon Zuckerbraun

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

☑ ☆ ✇ Zero Day Initiative - Blog

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

By: Trend Micro Research Team

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

☑ ☆ ✇ Zero Day Initiative - Blog

ZDI-21-502: An Information Disclosure Bug in ISC BIND server

By: Lucas Leong

Last year, we received a submission of a remote code execution vulnerability in the ISC BIND server. Later, that same anonymous researcher submitted a second bug in this popular DNS server. Similar to the first bug, it exists within the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) component, and its location is quite close to the previous submission. The vendor categorized this bug as low severity, so they did not issue any CVE or advisory. However, this bug is still interesting and worth a closer examination.

This vulnerability affects BIND version prior to 9.11.31 and 9.16.15. It can be triggered remotely and without authentication. It leads to out-of-bounds (OOB) read on heap memory and could allow an information disclosure to remote attackers. It might be possible to leverage this vulnerability in conjunction with the previous submission to execute arbitrary code on an affected BIND server.

The Vulnerability

The root cause is in the der_match_tag_and_length() function. It is used for matching a tag and geting the following length field from network packet. Based on the normal usage of der_get_length() in BIND, the parsed length field, length_ret, should be validated by the caller. However, der_match_tag_and_length() is one of the exceptions.

The length_ret at (1) is under control and has not yet been validated. Let's see one of the callers for der_match_tag_and_length():

The untrusted len is then used to decode the negTokenInit at (2). Many checks within decode_NegTokenInit() are based on len. Now, those checks are incorrect, and could lead to OOB access on different sub-fields, such as mechTypes, reqFlags, mechToken, etc.

The Trigger

The configuration used to reproduce this bug is the same as in the previous submission. The following screenshot is the crafted SPNEGO request for this bug.

Figure 1 - Wireshark view of the crafted SPNEGO request

Figure 1 - Wireshark view of the crafted SPNEGO request

The length_ret at (1) is controlled from offset 0xa5 as 0x91929394. The sub-field mechToken is an octet string. Its length is the crafted value 0x727374, appearing at offset 0xcd.

Upon receiving this crafted request, an OOB read is triggered within the handling of the mechToken field. The following call stack is based on BIND version 9.16.13.

The Exploitation Plan

Here’s one possible method for gaining information disclosure on an affected server.

After decode_NegTokenInit() parses the negTokenInit and its sub-fields, the loop at (3) searches for valid OIDs within the parsed mechTypes. If a valid OID is found, the server responds with an accept message at (4). Otherwise, the server responds with a reject message at (5). This gives us the ability to get the offset for some heap chunks. It’s possible this bug could be used in conjunction with the heap overflow from the previous submission, but this requires more research.

The Patch

From version 9.16.15, the ISC implementation of SPNEGO was removed from BIND 9 source code. Instead, BIND 9 now always uses the SPNEGO implementation provided by the system GSSAPI library when it is built with GSSAPI support. Because of this, the related bugs are also removed. This feature change was also applied to version 9.11.31.

You should verify you have a patched version of BIND as many OS distributions provide BIND packages that differ from the official ISC release versions. In particular, it is not uncommon for a distribution to choose a stable base version for their BIND package then selectively apply chosen patches for only those issues they think merit inclusion.  A consequence of this is that BIND may contain a fix even if the version number is different (and possibly less) than the version number in which ISC patched the vulnerability.

Conclusion

ISC BIND is the most popular DNS server on the internet. The scope of impact is quite large, especially since the vulnerability can be triggered remotely and without authentication. All are advised to update their DNS servers as soon as possible. This same anonymous researcher also reported a remote code execution bug within the handling of TKEY queries, which was also fixed recently.

We are also looking forward to seeing a reliable full exploit method at some point. As a reminder, ISC BIND is a part of our Targeted Incentive Program and could earn some big payouts for full exploits. We certainly hope to see some in the future.

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

ZDI-21-502: An Information Disclosure Bug in ISC BIND server

☑ ☆ ✇ Zero Day Initiative - Blog

The June 2021 Security Update Review

By: Dustin Childs

It’s the second Tuesday of the month, which means the latest security updates from Adobe and Microsoft are here. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for June 2021

For June, Adobe released 10 patches addressing 39 CVEs in Adobe Connect, Acrobat and Reader, Photoshop. Photoshop Elements, Experience Manager, Creative Cloud, RoboHelp, Premiere Elements, Animate, and After Effects. A total of nine of these bugs came through the ZDI program. The two patches that stand out are the fixes for Reader and After Effects. In the case of Adobe Reader, the Critical-rated CVEs could allow code execution if an attacker can convince a user to open a specially crafted PDF file with an affected version of Reader. For the use-after-free (UAF) bugs reported through our program, the specific flaw exists within the handling of AcroForm fields. The issue results from the lack of validating the existence of an object prior to performing operations on the object. The update for After Effects fixes a large mix of Critical- to Moderate-rated bugs. The worst of these could allow code execution at the level of the logged-on user.

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 June 2021

For June, Microsoft released patches for 50 CVEs in Microsoft Windows, .NET Core and Visual Studio, Microsoft Office, Microsoft Edge (Chromium-based and EdgeHTML), SharePoint Server, Hyper-V, Visual Studio Code - Kubernetes Tools, Windows HTML Platform, and Windows Remote Desktop. A total of eight of these bugs came through the ZDI program. Of these 50 bugs, five are rated Critical and 45 are rated Important in severity. According to Microsoft, six of these bugs are currently under active attack while three are publicly known at the time of release.

Let’s take a closer look at some of the more interesting updates for this month, starting with some of the bugs listed as under active attack:

-       CVE-2021-33742 - Windows MSHTML Platform Remote Code Execution Vulnerability
This bug could allow an attacker to execute code on a target system if a user views specially crafted web content. Since the vulnerability is in the Trident (MSHTML) engine itself, many different applications are impacted – not just Internet Explorer. It’s not clear how widespread the active attacks are, but considering the vulnerability impacts all supported Windows versions, this should be at the top of your test and deploy list.

-       CVE-2021-31199/CVE-2021-31201 - Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability
These two bugs are linked to the Adobe Reader bug listed as under active attack last month (CVE-2021-28550). It’s common to see privilege escalation paired with code execution bugs, and it seems these two vulnerabilities were the privilege escalation part of those exploits. It is a bit unusual to see a delay between patch availability between the different parts of an active attack, but good to see these holes now getting closed.

-       CVE-2021-31956 - Windows NTFS Elevation of Privilege Vulnerability
This is another of the bugs listed as under active attack this month. This was reported by the same researcher who found CVE-2021-31955, an information disclosure bug also listed as under active attack. It's possible these bugs were used in conjunction, as that is a common technique - use a memory leak to get the address needed to escalate privileges. These bugs are important on their own and could be even worse when combined. Definitely prioritize the testing and deployment of these patches.

-       CVE-2021-31962 - Kerberos AppContainer Security Feature Bypass Vulnerability
This bug allows an attacker to bypass Kerberos authentication and potentially authenticate to an arbitrary service principal name (SPN). This vulnerability earns the highest CVSS for June at 9.4. This could allow an attacker to potentially bypass authentication to access any service that is accessed via an SPN. Given that SPN authentication is crucial to security in Kerberos deployments, this patch should be given highest priority.

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

CVE Title Severity CVSS Public Exploited Type
CVE-2021-33742 Windows MSHTML Platform Remote Code Execution Vulnerability Critical 7.5 Yes Yes RCE
CVE-2021-33739 Microsoft DWM Core Library Elevation of Privilege Vulnerability Important 8.4 Yes Yes EoP
CVE-2021-31199 Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability Important 5.2 No Yes EoP
CVE-2021-31201 Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability Important 5.2 No Yes EoP
CVE-2021-31955 Windows Kernel Information Disclosure Vulnerability Important 5.5 No Yes Info
CVE-2021-31956 Windows NTFS Elevation of Privilege Vulnerability Important 7.8 No Yes EoP
CVE-2021-31968 Windows Remote Desktop Services Denial of Service Vulnerability Important 7.5 Yes No DoS
CVE-2021-31985 Microsoft Defender Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-31963 Microsoft SharePoint Server Remote Code Execution Vulnerability Critical 7.1 No No RCE
CVE-2021-31959 Scripting Engine Memory Corruption Vulnerability Critical 6.4 No No RCE
CVE-2021-31967 VP9 Video Extensions Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-31957 .NET Core and Visual Studio Denial of Service Vulnerability Important 5.9 No No DoS
CVE-2021-31944 3D Viewer Information Disclosure Vulnerability Important 5 No No Info
CVE-2021-31942 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31943 3D Viewer Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31972 Event Tracing for Windows Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31962 Kerberos AppContainer Security Feature Bypass Vulnerability Important 9.4 No No SFB
CVE-2021-31978 Microsoft Defender Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-33741 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 8.2 No No EoP
CVE-2021-31939 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31980 Microsoft Intune Management Extension Remote Code Execution Vulnerability Important 8.1 No No RCE
CVE-2021-31940 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31941 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31949 Microsoft Outlook Remote Code Execution Vulnerability Important 6.7 No No RCE
CVE-2021-31965 Microsoft SharePoint Server Information Disclosure Vulnerability Important 5.7 No No Info
CVE-2021-26420 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.1 No No RCE
CVE-2021-31966 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2021-31948 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31950 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31964 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31938 Microsoft VsCode Kubernetes Tools Extension Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2021-31945 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31946 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31983 Paint 3D Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31974 Server for NFS Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2021-31975 Server for NFS Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-31976 Server for NFS Information Disclosure Vulnerability Important 7.5 No No Info
CVE-2021-31960 Windows Bind Filter Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31969 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31954 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-26414 Windows DCOM Server Security Feature Bypass Important 4.8 No No SFB
CVE-2021-31953 Windows Filter Manager Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31973 Windows GPSVC Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31971 Windows HTML Platform Security Feature Bypass Vulnerability Important 6.8 No No SFB
CVE-2021-31977 Windows Hyper-V Denial of Service Vulnerability Important 8.6 No No DoS
CVE-2021-31951 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31952 Windows Kernel-Mode Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31958 Windows NTLM Elevation of Privilege Vulnerability Important 7.5 No No EoP
CVE-2021-1675 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31970 Windows TCP/IP Driver Security Feature Bypass Vulnerability Important 5.5 No No SFB

Looking at the remaining Critical-rated bugs, the update for Defender stands out even though 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. You should still verify the version and manually apply the update if needed. Similarly, the update for the VP9 codecs should be automatically updated through the Microsoft store. Again, if you’re in a disconnected environment, you’ll need to manually apply the patch. The remaining Critical-rated bugs include a browse-and-own bug in the scripting engine and a remote code execution vulnerability in SharePoint. The SharePoint bug requires no user interaction but does require some level of privilege. The attack complexity is listed as high, but considering the target, attackers are likely to do everything possible to turn this into a practical exploit.

Moving on to the Important-rated updates, there are a couple of SharePoint code execution bugs here as well. One of these came through the ZDI program, and we’ll post more details about it in the near future. We blogged about a similar bug last week, so you can check that out in the meantime. There are several patches impacting Office components with the most notable being the update for Outlook. Fortunately, the Preview Pane is not affected. An attacker would need to convince someone to open a specially crafted file with an affected version of Outlook. Those using Microsoft Intune for device management should ensure they apply the patch as soon as possible. While the attack scenario is not defined, it does not require authentication or user interaction. If you use Intune, I recommend treating this patch as Critical and deploy it quickly. The Important-rated code execution patches are rounded out by a couple of patches for the 3D Viewer and Paint 3D. One of the Paint bugs was reported by ZDI researcher Mat Powell and exists within the parsing of STL files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated data structure.

There are 10 additional elevation of privilege (EoP) bugs receiving patches this month beyond those previously mentioned. The bug fixed by the Desktop Windows Manager (DWM) patch is also listed as publicly known and under active attack. Again, it’s not clear how widespread these attacks are, but they are likely more targeted at this point. The update for the Chromium-based Edge actually went live on Friday, June 4. It’s not clear how this bug is an EoP rather than code execution, but either way, user interaction is required. The other EoPs addressed this month require the attacker to run their code on an affected system to escalate privileges. Several Windows components are impacted by these bugs, including the Windows Kernel and Microsoft’s Kubernetes tools.

There are seven patches fixing information disclosure bugs this month, with the vulnerability for the Windows Kernel listed as under active attack. For the most part, all of these bugs only lead to leaks consisting of unspecified memory contents. The one exception is the info leak in SharePoint that could lead to exposing Personally Identifiable Information (PII).

There are five patches fixing denial-of-service (DoS) bugs in the release. The most notable affected components are Hyper-V and Windows Defender. Again, you should have already received the Defender update. Even if you have Defender disabled, a vulnerability scanner may detect systems as vulnerable due to the presence of the impacted files. However, Microsoft states systems with Defender disabled are not in a “vulnerable state.” The DoS bug fixed in the Windows Remote Desktop Protocol is listed as publicly known, but it’s not clear what public information is available.

Four security feature bypasses are fixed in this month’s release, including the previously mentioned Kerberos bypass. The update for Windows DCOM requires special attention. The patch doesn’t automatically fix the vulnerability. Instead, it provides enterprises the ability to enable hardening for protections from the bug. Microsoft plans another release in Q4 2021 that enables the protections by default while allowing the hardened to be disabled via the registry. In late 2021 or early 2022, the ability to disable the protections will be removed. It seems Microsoft anticipates some application compatibility problems may arise from this fix, so definitely test this update thoroughly.

This month’s release is rounded out by three patches to address spoofing bugs in SharePoint Server. As per usual, the servicing stack advisory (ADV990001) was revised for versions of Windows 10 and Server 2019. No new advisories were released this month.

Looking Ahead

The next Patch Tuesday falls on July 13, 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 June 2021 Security Update Review

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability

By: The ZDI Research Team

In May of 2021, Microsoft released a patch to correct CVE-2021-31181 – 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-573. 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 code on the server in the context of the service account of the SharePoint web application. For a successful attack, the attacker must have SPBasePermissions.ManageLists permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permission.   

The Vulnerability

This attack is possible due to insufficient validation of user input in the EditingPageParser.VerifyControlOnSafeList() method. This method verifies user input against a list of unsafe controls and should raise an exception if any control is not marked as safe by the SafeControl elements as specified in web.config.

A good example of an unsafe control that is forbidden by SharePoint is System.Web.UI.WebControls.XmlDataSource. This control is dangerous because it would allow an attacker to get information from an arbitrary XML file on the server. As we will see, this could be used not only for information disclosure but even for code execution.

We can see that it is marked as unsafe via a SafeControl element in web.config:

Because of this, an attacker should not be able to instantiate this control. However, we will see how we can bypass verification in EditingPageParser.VerifyControlOnSafeList().

EditingPageParser.ParseStringInternal() parses user input (dscXml) and populates hashtable with information from Register directives and hashtable2 with values from tags that represent server controls. In the next step, it tries to create a Type object for each element from hashtable2 and checks it against an allowed list of SafeControls. However, it will ignore the tag of the server control if the Type cannot be resolved. Normally, this would not create a hazard. If a Type cannot be resolved at the verification stage, then it should similarly fail to resolve later during the actual processing of markup. However, an inconsistency between the code in EditingPageParser and TemplateParser breaks this assumption.

Let’s look closer at how the values in hashtable are populated, and let’s pay attention to the namespace attribute of the Register directive:

The value of the namespace attribute will be stored in triplet.First. Let’s suppose that we have Namespace="System.Web.UI.WebControls " (note the trailing space) in our Register directive, and a tag named XmlDataSource. As you can see, there are no Trim() calls for the namespace attribute. Due to the trailing space, VerifyControlOnSafeList will not be able to resolve the Type System.Web.UI.WebControls .XmlDataSource and consequently it will not be blocked. Later, though, during actual processing of the Register directive, the following code executes:

At this stage, the Namespace will be trimmed and a Type for System.Web.UI.WebControls.XmlDataSource will be successfully resolved. This means the unsafe control will be processed by the server.

For our attack, we will use the WebPartPagesWebService.RenderWebPartForEdit webapi method. It is accessible via the /_vti_bin/WebPartPages.asmx endpoint. It takes ASPX markup as an input, verifies it using EditingPageParser.VerifyControlOnSafeList, and, if there are no unsafe elements, processes the markup in Design mode. The resulting HTML will be returned to the web client.

We will use the WebPart Microsoft.SharePoint.WebPartPage.XsltListFormWebPart with our unsafe XmlDataSource, specifying a simple XSL transformation to copy the result verbatim to our output. In this way we can obtain the contents of an arbitrary XML file from the server. We choose to disclose the contents of web.config. This will provide us with the validation key needed to forge a VIEWSTATE parameter, providing a path to remote code execution.

To proceed, we will also need to provide the Title of any existing SPList from the current site, as well as the site’s webID. These can be obtained easily. We will see how to do this in the PoC section.

Here is an example of a RenderWebPartForEdit request:

We can use the machinekey section from web.config to create a valid VIEWSTATE parameter that causes an arbitrary OS command to be executed when the ViewState is deserialized on the server.

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 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 that we will be the owner and have all permissions.

Click on “SharePoint” on the top panel:

Picture2.png

Now click the “+ Create Site” link:

Picture3.png

Choose Team Site.

Choose a name for the new site. In this example, it is ts01.

Picture4.png

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

Picture5.png

Now let’s get the webId for the site. This can be done with a request to /_api/web/id :

Picture6.png

In this example, it is 6e7040c8-0338-4448-914d-a7061e0fc347.

We also need the title of any existing SPlist in the current site. The “Documents” SPlist is available on most sites, but we can use any item from the /_layouts/15/viewlsts.aspx page:

Picture7.png

Now we use our PoC to send a request to the server. We need to provide the base URL for our site, valid user credentials, the title of an SPList, and the webId. In our case:

>PoC.exe http://sp2019/sites/ts01/ user2 [email protected] contoso "Documents" "{6e7040c8-0338-4448-914d-a7061e0fc347}"

If this step successful, we will get the machineKey section of web.config:

Picture9.png

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

validationKey=”FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79”

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

Using this information, we can proceed to get remote code execution. Before the actual attack, let’s go to the target SharePoint Server and open C:\windows\temp folder:

Picture10.png

Note that there is no PoC_SPRCE01.txt file yet.

Now let’s go back to the attacker machine. We need to collect one more piece of information, which is the value of __VIEWSTATEGENERATOR. We can get this by browsing to the success.aspx page on our site. In this example, the URL is http://sp2019/sites/ts01/_layouts/15/success.aspx:

Picture11.png

Viewing the source code, we can find the value of __VIEWSTATEGENERATOR:

Picture12.png

In this example it is AF878507.

In summary, the values needed to forge a VIEWSTATE are as follows:

__VIEWSTATEGENERATOR=AF878507 validationKey=FAB45BC67E06323C48951DA2AEAF077D8786291E2748330F03B6601F09523B79 validationAlg=HMACSHA256

We provide these values on the command line of ysoserial, as follows:

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

Picture13.png

The result is a valid VIEWSTATE.

We need to URL-encode this ViewState and send it as a __VIEWSTATE parameter to our server. For example, this can be done by composing a URL with a __VIEWSTATE query string parameter, as follows:

Browsing to this URL, an error page is returned.

Picture14.png

However, when we check the C:\Windows\temp folder on the SharePoint server:

Picture15.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-31181, 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-31181: Microsoft SharePoint WebPart Interpretation Conflict Remote Code Execution Vulnerability

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-31440: An Incorrect Bounds Calculation in the Linux Kernel eBPF Verifier

By: Lucas Leong

In April 2021, the ZDI received a Linux kernel submission that turned out to be an incorrect bounds calculation bug in the extended Berkeley Packet Filter (eBPF) verifier. This bug was submitted to the program by Manfred Paul (@_manfp) of the RedRocket CTF team (@redrocket_ctf). Manfred Paul had successfully exploited two other eBPF verifier bugs in Pwn2Own 2020 and 2021 respectively.

This particular bug bypassed the eBPF verification and resulted in an out-of-bounds (OOB) access in the Linux kernel. The researcher exploited this bug and demonstrated a Kubernetes container escape. The patch was recently released as CVE-2021-31440 . Linux kernel versions from 5.7 and on were affected.

The Vulnerability

After CVE-2020-8835, one significant change was added to the verifier, namely 32-bit bound tracking. For the unsigned and signed minimum and maximum bounds, the 32-bit bounds u32_min_value, u32_max_value, s32_min_value and s32_max_value additionally and exclusively apply to the lower 32 bits of each tracked register.

However, a very similar mistake was reintroduced in __reg_combine_64_into_32(). This function uses the known bounds on a 64-bit register to infer bounds for the register’s lower 32 bits.

If the smin_value and smax_valueat (1) are both within in the range of signed 32-bit integers, the 32-bit signed bounds are updated accordingly. In all other cases the 32-bit signed bounds remain in the “unbounded” state. This logic is proper. However, in the corresponding logic for unsigned bounds, the checks on umin_value and umax_value are performed separately at (2) and (3). This logic is incorrect. For example, consider what happens if a register has umin_value = 1 and umax_value = 1<<32. data-preserve-html-node="true" At (2), the verifier will set u32_min_value to 1. At runtime, the register’s actual value can be 1<<32, data-preserve-html-node="true" making the lower 32 bits equal to 0. This violates the correctness of the register’s bounds, which indicate that the minimum value of the lower 32 bits is 1.

Notably, there was already a fix for the case of signed bounds at (1) from December 2020, but it missed the case of unsigned bounds.

Exploitation

The bug can be exploited as follows. Begin with these eBPF instructions:

These instructions set BPF_REG_2 as 1<<32. data-preserve-html-node="true" The two successive NEG instructions cause the verifier to lose track of all bounds for BPF_REG_2, while keeping its runtime value unchanged.

Next:

This conditional branch tests whether BPF_REG_2 is greater than or equal to 1. For the true side of the branch, the verifier sets the register’s umin_value to 1. Furthermore, the verifier calls __reg_combine_64_into_32(), which sets u32_min_value to 1 as well. This is the branch that will be followed at runtime.

Next:

This second conditional branch tests whether BPF_REG_2 is less than or equal to 1, so for the true side of the branch, the verifier sets the register’s u32_max_value to 1. At this point, for the true path, u32_max_value and u32_min_value are both set to 1, meaning that the verifier believes that the value of the lower 32 bits is known to be exactly 1. Recall, though, that the runtime value of BPF_REG_2 has been set to 1<<32 data-preserve-html-node="true" from the beginning, so that the true value of the lower 32 bits is 0. Thus, the verifier has inferred incorrect bounds for the register.

Finally, we can use this to produce an out-of-bounds access:

The BPF_MOV32_REG extends the wrong knowledge to the whole 64-bit register. After two ALU (arithmetic) operations, the register value is believed by the verifier to be 0, but is actually 1. This situation is the same as in the exploit steps in CVE-2020-8835, and the later steps of that exploit can be reused here. The out-of-bounds read/write access is achieved by using the wrongly bounded register, followed by an arbitrary read/write, and privilege escalation to root.

Demonstrating Exploitation

Since the Kubernetes container by default allows access to all system calls, a container escape can be achieved by exploiting this bug. The researcher set the current UID and GID to 0 and obtained the CAP_SYS_MODULE capability. This allowed the program to load an arbitrary kernel module outside of the container.

Conclusion

The eBPF module is still a good place for kernel bug hunting. It was also recently introduced to Windows. This attack surface is usable not only for local privilege escalation but also for container escapes. Those running systems affected by this bug should apply this mitigation, or even better, upgrade the kernel to an unaffected version. Thanks again to Manfred Paul(@_manfp) of the RedRocket CTF team (@redrocket_ctf) for submitting this bug. He’s submitted a few other reports to the program, and each has been great. We hope to see more from him in the future.

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

CVE-2021-31440: An Incorrect Bounds Calculation in the Linux Kernel eBPF Verifier

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-22909- Digging into a Ubiquiti Firmware Update bug

By: Vincent Lee

Back In February, Ubiquiti released a new firmware update for the Ubiquiti EdgeRouter, fixing CVE-2021-22909/ZDI-21-601. The vulnerability lies in the firmware update procedure and allows a man-in-the-middle (MiTM) attacker to execute code as root on the device by serving a malicious firmware image when the system performs an automatic firmware update. The vulnerability was discovered and reported to the ZDI program by the researcher known as awxylitol.

This vulnerability may sound contrived; a bad actor gives bad firmware to the device and bad things happen. However, insecure download vulnerabilities have been the backbone of multiple Pwn2Own winning entries in the router category since its inception. The impact of this vulnerability is quite nuanced and worthy of further discussion.

How exactly does the router perform a firmware update?

According to Ubiquiti documentation, the new templated operational command add system image can be used to update the firmware of the router through the command line interface (CLI). A templated operational command allows the user to quickly modify the operational state of the router without fiddling with complex command-line parameters. This simplifies the process for day-to-day operations and minimizes user errors. I am sure we have all heard of horror stories of system administrators who accidentally deleted critical files, locked themselves out of equipment that is far away from civilization, and so forth. Templated commands attempt to mitigate these issues.

The templating system used by the Ubiquiti EdgeRouter is provided by the vyatta-op package. The command add system image is defined in the /opt/vyatta/share/vyatta-op/templates/add/system/image/node.def file.

By running this operational command, the user is effectively invoking the ubnt-fw-latest script with the --upgrade option. This option causes the ubnt-fw-latest script to run the upgrade_firmware() function, which will check with a Ubiquiti update server to get information about the latest firmware release, including the firmware download URLs.

The function proceeds to parse and compare the results from the server with the current firmware version. If an update is available, the script will invoke ubnt-upgrade to fetch the firmware from the fw-download.ubnt.com domain provided by the upgrade server. It will then perform the actual firmware upgrade.

The Bug - ZDI-21-601

The issue lies in the way the /usr/bin/ubnt-upgrade bash script downloads the firmware. The get_tar_by_url() function uses the curl command to perform the fetch. However, the developers specified the -k option (also known as the –insecure option), which disables certificate verification for TLS connections.

Since /usr/sbin/ubnt-upgrade does not check for the validity of the certificate, an attacker can use a self-signed certificate to spoof the fw-download.ubnt.com domain without triggering any warnings or complaints on the device to alert the user. This vulnerability significantly reduces the skill barrier needed to launch a successful attack.

To exploit this vulnerability, the attacker can modify an existing EdgeRouter firmware image and fix up the checksum contained in the file. In the submitted proof-of-concept, the researcher modified the rc.local file to connect back to the attacker with a reverse shell. A reboot is part of the upgrade process, triggering the rc.local script.

Conclusion

If an attacker inserts themselves as MiTM, they can then impersonate the `fw-download.ubnt.com` domain controlled by Ubiquiti. However, to successfully serve up malicious firmware from this domain, the attackers would normally need to obtain a valid certificate with private key for the domain. To proceed, the attackers would probably need to hack into Ubiquiti or convince a trusted certificate authority (CA) to issue the attackers a certificate for the Ubiquiti domain, which is no insignificant feat. However, due to this bug, there is no need to obtain the certificate.

The heart of the problem is the lack of authentication on the firmware binary. The function of a secure communications channel is to provide confidentiality, integrity, and authentication. In TLS, encryption provides confidentiality, a message digest (or AEAD in the case of TLS 1.3) provides integrity, and certificate verification provides authentication. Without the verification of certificates, clients are foregoing authentication in the communications channel. In this scenario, it is possible for the client to be speaking to a malicious actor “securely”, as it were.

It should also be noted how checksums are not replacements for cryptographic signatures. Checksums can help to detect random errors in transmission but do not provide hard proof of data authenticity.

One final consideration is the possibility that a vendor's website could become compromised. In that case, the firmware along with its associated hash could both be replaced with malicious versions. This situation can be mitigated only by applying a cryptographic signature to the firmware file itself. Perhaps Ubiquity will make the switch to signing their firmware binaries cryptographically, which would improve the overall security of its customers.

Ubiquity addressed this bug in their v2.0.9-hotfix.1 security update by removing the -k (--insecure) flag from the templated command.

This was the first submission to the program from awxylitol, and we hope to see more research from them in the future. Until then, you can find me on Twitter @TrendyTofu, and follow the team for the latest in exploit techniques and security patches.

Footnote

Cautious users of the EdgeRouter seeking advice on how to upgrade the device properly should avoid the use of automatic upgrade feature for this update. They may want to download the firmware file manually from a browser and verify the hashes of the firmware before performing a manual upgrade by uploading the firmware file to the device through the web interface.

CVE-2021-22909- Digging into a Ubiquiti Firmware Update bug

☑ ☆ ✇ Zero Day Initiative - Blog

CVE-2021-31166: A Wormable Code Execution Bug in HTTP.sys

By: Trend Micro Research Team

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 Microsoft Internet Information Services (IIS) for Windows. The bug was originally discovered by the Microsoft Platform Security & Vulnerability Research team. The following is a portion of their write-up covering CVE-2021-31166, with a few minimal modifications.


The Internet Information Services (IIS) for Windows Server is a flexible, scalable, secure, and manageable web server for hosting static as well as dynamic content on the web. IIS supports various web technologies including HTML, ASP, ASP.NET, JSP, PHP, and CGI. IIS features an HTTP listener as part of the networking subsystem of Windows. This functionality is implemented as a kernel-mode device driver called the HTTP Protocol Stack (HTTP.sys). This driver is responsible for parsing HTTP requests and crafting responses to the clients.

Note that the driver http.sys is a mature technology that provides the robustness, security, and scalability of a full-featured web server. It is also used by Windows Remote Management WS-Management (WinRM) and Web Services for Devices (WSD) associated with Network Discovery. It could also be used by any other web servers that need to be exposed to the internet without using IIS. Therefore this vulnerability is reachable via any system utilizing http.sys.

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) 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 POST method might look like this:

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

Of relevance to this vulnerability is the HTTP request header “Accept-Encoding”. This header advertises to a web server compression algorithm it can understand. The server selects a proposal from advertised choices, uses it, and informs the client of its decision using the HTTP response header “Content-Encoding”.

The advertised compression algorithms are known as content-coding. The content-codings could be specified in the order of preference with qvalue weighting which describes the order of priority of values in a comma-separated list.

The “Accept-Encoding” HTTP header Field-Value has the following format:

Example "Accept-Encoding" headers are as follows:

where the Field-Value strings are gzip, identity, *, deflate, gzip;q=1.0, *;q=0.5
In HTTP.sys the routines HTTP!UlAcceptEncodingHeaderHandler, HTTP!UlpParseAcceptEncoding and HTTP!

UlpParseContentCoding are responsible for parsing the "Accept-Encoding" HTTP request header.

Upon receiving an HTTP request, the routine HTTP!UlAcceptEncodingHeaderHandler is invoked for each “Accept-Encoding” header present in the request headers. This routine then invokes HTTP!UlpParseAcceptEncoding on the “Accept-Encoding” HTTP header Field-Value.

The HTTP!UlpParseAcceptEncoding routine walks the Field-Value string by invoking HTTP! UlpParseContentCoding. The HTTP!UlpParseContentCoding routine, among other functionalities, returns a reference to the next content-coding string within the Field-Value for the next iteration and determines if the current reference into the Field-Value string is either an unknown, a supported, or an invalid content-coding string.

A valid content-coding string is a well-formatted string according to the “Accept-Encoding” HTTP header Field- Value format illustrated above. It can either be unknown or supported. A supported content-coding string is a valid content-coding string specifying a compression algorithm supported by IIS.

In the following “Accept-Encoding” HTTP request header example:

       Accept-Encoding: gzip, aaaa, bbbb;

“gzip” is a supported content-coding string, “aaaa” is an unknown content-coding string, and finally “bbbb;” is an invalid content-coding string because it is improperly formatted.

During the processing of the Field-Value string, the routine HTTP!UlpParseAcceptEncoding maintains a circular doubly linked list of unknown content-codings. However, the presence of an invalid content-coding string will result in an HTTP Bad Request server response.

A circular doubly linked list is a data structure that exhibits properties of both doubly linked lists and circular linked lists. In a circular doubly linked list, two consecutive nodes are connected by previous and next links. Distinctively, the last node connects to the first node by its next link and the first node connects to the last node by its previous link. If the circular doubly linked list contains only one node, the next and previous links connect to itself.

A remote code execution vulnerability exists in the HTTP Protocol Stack for Microsoft Internet Information Services implemented in http.sys. The vulnerability is due to a design flaw in the maintenance of a circular doubly linked list in UlpParseAcceptEncoding.

In the routine HTTP!UlpParseAcceptEncoding, the list of unknown content-codings is initialized to contain just a root node. This root node resides in the function's stack memory region. While processing the Field-Value string, subsequent nodes are allocated for unknown content-codings in the paged memory pool (i.e virtual memory addresses that can be paged in and out of the system). In the event that HTTP!UlpParseAcceptEncoding failed to acquire memory within the paged pool or that HTTP!UlpParseContentCoding determined that a content-coding string is invalid, nodes allocated within the paged pool will be freed and in all but one case, immediately by the routine HTTP!UlFreeUnknownCodingList via the root node residing on the function's stack memory region (original root node).

The routine HTTP!UlFreeUnknownCodingList unlinks and frees nodes in the order they were added to the circular doubly linked list. It begins with the first non-root node and will perform various integrity checks on the node to be deleted effectively in a bid to determine if the circular doubly linked list has been corrupted. If the checks succeed, the node will be freed otherwise the routine aborts with __fastfail leading to a kernel crash.

After fully parsing all content-codings specified in the Field-Value string, if the list of unknown content-codings contains additional nodes, the additional nodes are unlinked from the root node that resides on the function's stack memory region and relinked to a root node in an internal structure. During unlinking, HTTP! UlpParseAcceptEncoding failed to reset the next and previous links of the initial root node such that they connect to itself. Hence, the next and previous links of the original root node still connected to the now migrated nodes.

An attacker could craft an “Accept-Encoding” HTTP request header such that the unknown content-coding list is migrated to the internal structure but also passed to HTTP!UlFreeUnknownCodingList via the original root node as a result of an invalid content-coding string passed to HTTP!UlpParseContentCoding. This scenario occurs because a special error code 0x0c0000225 is returned by HTTP!UlpParseContentCoding when the only non-tab, non-space character in the content-coding string currently being processed is the comma character (,). This error code does not result in the immediate freeing of the unknown content-coding list in HTTP!UlpParseAcceptEncoding. The unknown content-coding list will still be migrated to the internal structure before the error is handled.

Since the original root node's next and previous links still connect to the migrated nodes, the free operation will be performed for the first added node connected by the original root's next link because the integrity checks performed on the node will succeed. However, since the first node is connected to the internal structure’s root node via its previous link, the routine HTTP!UlFreeUnknownCodingList unlinks this node from the internal structure root node instead of the passed in the original root node. On the next iteration, the same node is to be freed again since the routine parses the passed-in initial root node. This time, a non-crashing use-after-free occurs, the integrity checks are performed again on the node but this time they fail. This is because when the routine checks the node connected to the previous link of the already deleted and unlinked node, it finds the internal structure's root node. However, when it checks the node connected to the internal structure root node's next link, it finds a node different from the one specified for freeing. The routine HTTP!UlFreeUnknownCodingList aborts via __fastfail with FAST_FAIL_CORRUPT_LIST_ENTRY. This results in a blue screen of death (BSOD) with stopcode KERNEL SECURITY CHECK FAILURE.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted Accept-Encoding HTTP header in a web request to the target system. Successful exploitation of this vulnerability can result in denial-of-service conditions or code execution with kernel privileges in the worst case.

Conclusion

Microsoft addressed this vulnerability in the May patch release cycle. They recommend prioritizing the patching of affected servers.

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-31166: A Wormable Code Execution Bug in HTTP.sys

❌