Before yesterdayZero Day Initiative - Blog

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

28 July 2021 at 15:28

In March 2021, Microsoft released a patch to correct a vulnerability in the Windows GDI subsystem. The bug could allow an attacker to execute code with escalated privileges. This vulnerability was reported to the ZDI program by security researcher Marcin Wiązowski. The patch for CVE-2021-27077 addresses several of his bug submissions. He has graciously provided this detailed write-up of the vulnerabilities and an analysis of the patch from Microsoft.

To handle devices on which drawing can be performed (pixel-based devices), Windows provides so-called device contexts (DCs). A device context object encapsulates a device object where a device object represents either a screen or a printer. Device contexts are an abstraction layer between user-mode code and low-level device drivers. They also act as containers, referencing various graphic objects used during drawing operations, such as pens, brushes, bitmaps, palettes, regions, and paths. To establish a connection between a device context and some other graphic object, the user-mode code calls SelectObject. For example:

In this example, we create a screen-related device context and three other GDI objects: a region, a font, and a bitmap. By selecting them into the device context, we cause them to be used during the ExtTextOut call below. This call will draw text on our TestBitmap by using our TestFont, and the drawing area will be clipped by our TestRegion.

For us, the important facts about device contexts are:

1 - They can be either screen-related or printer-related.
2 - To reference the screen or printer, each device context internally keeps a handle, referred to as hdev. Internally, a device context object resides in kernel memory, and its hdev field is a pointer to another object residing in kernel memory, this one being a device object.

Bitmaps selected into device contexts

Bitmaps are represented in kernel memory as surface objects. The partial structure definition shown here includes some fields documented by Microsoft, as well as some undocumented fields that have been reconstructed:

As we can see, bitmaps can contain a hdev value. This value is initially set to NULL, but selecting the bitmap into a device context copies the hdev value from the device context to the bitmap’s hdev field.

Now let’s do an experiment:

In this example:

1) We create one printer-related device context (DCPrn) and one screen-related device context (DCScr). For the printer DC, we used the printer named “Microsoft XPS Document Writer” which is available by default, but any installed printer could be used instead. If necessary, the EnumPrinters API could be used to get the names of all installed printers.
2) We create a bitmap (Bitmap). Note that it’s a monochrome (1 bit deep) bitmap, so it’s compatible with any device context. This includes 1-bit or 8-bit printer-related DCs and 32-bit screen-related DCs.
3) We select the bitmap into the printer-related DC. This sets the bitmap’s hdev field so that it points to the printer device object in kernel memory. The variable PrevBitmap is set to the default bitmap that was created together with the printer DC.
4) We deselect our bitmap (by selecting PrevBitmap instead), so we’ll be able to select Bitmap into some other device context again. Bitmaps are specific in that sense. They can be selected into only one device context at a time, so deselecting is required.
5) Finally, we select Bitmap into a screen-related DC. This updates bitmap’s hdev field so that it no longer points to the printer device object, but rather to the screen device object.

This code isn’t malicious, but we’ll make it malicious in the next step. But first, let’s look at some changes that were introduced in Windows 2000.

User-Mode Printer Drivers (UMPD)

Historically, both screens and printers used to be handled by kernel-mode drivers. While there are only a small number of vendors that manufacture graphic cards and write corresponding driver code, the world of printers is quite a different story. Undoubtedly there were plenty of printer manufacturers who introduced numerous security risks and instabilities in their drivers. To make things safer and more stable, Windows 2000 introduced an architecture that allowed printer drivers to work in user mode instead. Both kernel-mode and user-mode printer drivers coexisted until Windows Vista. Since then, Windows has supported only user-mode drivers for printing.

Consequently, only some stubs remained in kernel code for printer handling. These stubs mainly just make callbacks to user mode. In user mode, these calls are first passed to some internal code in user32.dll, then to some more code in gdi32.dll, then to yet more internal code in gdi32full.dll, which finally passes them to user-mode printer drivers for handling:

To provide user-mode drivers with the needed functionalities, some kernel-mode APIs now also have their user-mode API counterparts. One such API is EngAssociateSurface. Display drivers use calls to the kernel-mode function win32kbase.sys!EngAssociateSurface, whereas printer drivers use the user-mode function gdi32.dll!EngAssociateSurface:

For our purposes, we can consider the user-mode EngAssociateSurface function to be an extended version of the SelectObject API. When passing a bitmap as the first parameter, we can set not only the bitmap’s hdev field but also its dhpdev and flags fields. Here are a few things to consider:

1) The hdev parameter will be a valid value obtained from an existing printer-related device context. User-mode code can obtain this value since it’s forwarded by the kernel to the user-mode printer driver. This will be explained below in greater detail. After validation, the passed hdev parameter will be copied to the bitmap’s hdev field.
2) The flHooks parameter may contain any combination of HOOK_XXX flags, documented here. These flags will be set in the bitmap’s flags field.
3) The dhpdev value is not passed as a parameter. However, the kernel maintains its internal list of hdev-dhpdev pairs, so setting the bitmap’s hdev field will also set its dhpdev field.

During device initialization, the device driver can pass a dhpdev value of the driver’s choice to the operating system, thus creating a hdev-dhpdev pair. In practice, the dhpdev value points to a block of driver-allocated memory, which will be either kernel-mode memory for display drivers or user-mode memory for printer drivers. This observation is very important for us.

Whenever executing a GDI graphics primitive (for example, ExtTextOut, which renders text to a DC), there are two code paths that could be chosen. One code path implements the primitive via a call to a corresponding driver function (supposing one exists) that knows how to perform that graphics primitive natively. The other code path uses a generic implementation of the primitive as supplied by win32k. The bitmap’s flags field, containing a combination of values from the HOOK_XXX enumeration, tells the operating system which GDI operations should be handled by the win32k subsystem and which should be directed to a corresponding device driver function. When so requested, the driver is identified by the device context’s hdev field.

Since we used ExtTextOut in our example above, let’s consider the HOOK_TEXTOUT flag. The ExtTextOut GDI function takes a device context as a parameter and passes it to the kernel-mode implementation of GDI. The kernel obtains the bitmap that is selected into this device context and checks if the bitmap’s flags field has the HOOK_TEXTOUT bit set. If this bit is not set, the kernel will pass our request to the generic win32kfull.sys!EngTextOut function to render the text. If HOOK_TEXTOUT is set, though, the kernel will forward our request to the device driver as specified by the bitmap’s hdev field. In this case, execution will be passed in kernel mode to one of three possible places (a few more are used in some specific cases, but they are not interesting for us):

Cdd.dll!DrvTextOut, which is a part of a top-level display driver, used for screen devices when only one monitor is active.
win32kfull.sys!MulTextOut, which is a part of a top-level display driver, used for multi-monitor configurations. This driver is embedded directly in the win32k subsystem.
win32kfull.sys!UMPDDrvTextOut, which is one of the printer stubs in the kernel. It uses a callback to pass the request through to user mode. This allows the request to be handled by the appropriate user-mode printer driver.

We are now ready to make our piece of code malicious. To achieve this, we’ll replace one of the SelectObject calls with a call to EngAssociateSurface call, passing HOOK_TEXTOUT as the flags parameter:

Other modifications are as follows:

1) We no longer need to call CreateCompatibleDC when creating DCPrn. This is because we no longer call SelectObject on DCPrn but rather EngAssociateSurface on DCPrn’s hdev value.
2) Because of internal EngAssociateSurface requirements, we can’t use the CreateBitmap call anymore. We must instead call CreateCompatibleBitmap on DCPrn.
3) We no longer need to deselect our bitmap from DCPrn. This is because there is no SelectObject call on DCPrn but rather EngAssociateSurface on DCPrn’s hdev value.
4) Note that we explicitly call a Unicode (wide) version of the ExtTextOut API. We also provide an ETO_IGNORELANGUAGE flag to this call, along with a very long string. This way, our ExtTextOut request will be passed directly to the kernel mode without any further user-mode handling.

Let’s look at the comments in the code snippet above. The EngAssociateSurface call sets the bitmap’s hdev field so it points to a printer device in kernel mode. As explained above, this will also affect the bitmap’s dhpdev field. As we remember, this value, in practice, points to a block of driver-allocated memory. Since printer drivers are handled in user mode, this will be some block of user-mode memory. Finally, the HOOK_TEXTOUT bit is set in the bitmap’s flags field.

The SelectObject call is then made, which ties the bitmap to DCScr and modifies the bitmap’s hdev field so it no longer points to the printer device but rather to a screen device. Other bitmap fields are not modified. In particular, SelectObject will not alter the dhpdev field.

Finally, we have the ExtTextOutW call on the screen-related DCScr. When handling this call, the kernel will see the HOOK_TEXTOUT flag set in the bitmap’s flags field, so drawing will not be handled by the win32k subsystem. Instead, our request will be passed to the device driver specified by the DCScr’s hdev value, which in our case is the display driver. This way, thanks to our manipulations, the display driver will get the bitmap containing a pointer to some user-mode memory in the bitmap’s dhpdev field while it expects to see a pointer to its own, kernel-mode memory there. We definitely found a security problem.

By preparing a block of user-mode memory appropriately, we can trick the display driver into overwriting kernel memory of our choice. This means privilege escalation is possible. But first, we must perform some interactions with a user-mode printer driver to help us fulfull the following four requirements:

Requirement 1: We must obtain the printer’s hdev value so we will be able to make the EngAssociateSurface call. This is a kernel-mode pointer.
Requirement 2: We must obtain the printer’s dhpdev pointer (note that this is a user-mode pointer), so we can prepare the memory that the display driver will access there. Even better, we can also modify this pointer at will, as explained below.
Requirement 3: Calling CreateCompatibleBitmap on DCPrn must return a bitmap that can be then selected into DCScr, so it must be either a 1-bit or a 32-bit bitmap. For this reason, we must force the user-mode printer driver to create either a 1-bit or a 32-bit device context, which will become our DCPrn.
Requirement 4: We must force the user-mode printer driver to report that it has a native text rendering function. Otherwise, calling EngAssociateSurface with HOOK_TEXTOUT will fail.

Hooking the UMPD implementation

Printer drivers are user-mode DLLs registered in the Registry. Printer drivers may implement functions that are defined in the winddi.h header file and are identified by integer constants:

To implement INDEX_DrvEnablePDEV functionality, device drivers provide a function with the following definition:

As we can see, this function gets the hdev value as a parameter and returns the dhpdev value. This means that we need to install some wrapper around this function in the printer driver to be able to obtain and modify these values.

To reach our goal, we could hook the user-mode printer driver itself, as described in detail here. However, this is quite a complex approach. Instead, we’ll try another solution that is both simpler and more universal. Instead of placing hooks in the driver itself, we will hook the user-mode code that is executed above the driver:

By injecting our own layer between user32.dll!ClientPrinterThunk and gdi32.dll!GdiPrinterThunk, we can obtain a central point at which all data passed to or returned from printer drivers can be read and modified. This can be achieved easily, since gdi32.dll!GdiPrinterThunk is a public export from the gdi32.dll module. Because user32.dll is a PE image mapped into memory, it’s enough to enumerate its import table and replace all pointers to gdi32.dll!GdiPrinterThunk with pointers to our own code. This gives us the ability to modify the incoming data, call the original gdi32.dll!GdiPrinterThunk function, and modify the returned data as needed.

The gdi32.dll!GdiPrinterThunk function, although exported by gdi32.dll, is not publicly defined. As of today, it has four parameters and can be reconstructed as:

In this call, the input buffer contains the identifier of the driver function to be called (i.e., one of the INDEX_XXX values) along with data needed for the call. The output buffer receives the results returned by the printer driver. The needed parts of the input and output buffer can be reconstructed as:

For our exploit, we need custom handling of the following INDEX_XXX requests in our GdiPrinterThunk wrapper:

1) INDEX_DrvEnablePDEV
2) INDEX_UMPDDrvDriverFn (undocumented, called from win32kfull.sys!UMPDDrvDriverFn)
3) INDEX_DrvDisablePDEV

Aside from the INDEX_XXX values defined in winddi.h, GdiPrinterThunk also receives a few undocumented commands. These have INDEX_XXX values greater than the highest documented value. Undocumented commands are never forwarded down to the lowest level (the user-mode printer driver DLL). They are designed for internal gdi32full.dll use only. The first command passed to the GdiPrinterThunk call is always a particular undocumented command, which, after increasing by 3, gives us the needed INDEX_UMPDDrvDriverFn value.

After using CreateDC to create a printer-related device context, we’ll catch many requests in our installed GdiPrinterThunk wrapper. Most of them should be just passed directly to the original gdi32.dll!GdiPrinterThunk implementation, with the three exceptions as mentioned above:

• When handling INDEX_DrvEnablePDEV, we can find the hdev value needed for the EngAssociateSurface call in the input buffer, which satisfies Requirement #1. Then, after calling the original gdi32.dll!GdiPrinterThunk function, we can find the dhpdev value in the output buffer, which points to some block of user-mode memory. Disassembling gdi32full.dll shows that this block of memory contains only two handles/pointers. At this moment, we can allocate some large (64 kB) block of user-mode memory, copy these two handles/pointers to our block, and overwrite the original dhpdev value with a pointer to our own block. By disclosing dhpdev as well as overwriting it with a new value to our liking, we have satisfied Requirement #2. Additionally, the output buffer contains a pointer to a pdi record. We should set pdi->iDitherFormat to BMF_1BPP and also ensure that pdi->flGraphicsCaps has the GCAPS_PALMANAGED flag cleared. This way, Requirement #3 will be met as well.

• When handling INDEX_UMPDDrvDriverFn, we get the DriverFn array in the output buffer. After calling the original gdi32.dll!GdiPrinterThunk function, we should set DriverFn[INDEX_DrvTextOut] to TRUE so the kernel will think that text drawing functionality is handled natively by the printer driver. Thanks to this, passing HOOK_TEXTOUT flag to our EngAssociateSurface call will succeed. This will satisfy Requirement #4.

• When handling INDEX_DrvDisablePDEV, we’ll find our own dhpdev value in the input buffer. It’s good to replace it with the original value before calling the original gdi32.dll!GdiPrinterThunk function to avoid problems with heap memory. gdi32full.dll treats this value as a pointer to its own block of heap memory and tries to release it.

Kernel Exploitation with a Fake dhpdev Block

We are now ready to pass our block of user-mode memory to the display driver. Our choice will be the multi-monitor display driver. More precisely, we will target its win32kfull.sys!MulTextOut function. This will limit our exploitation to multi-monitor machines only, but exploitation will be a bit tricky. The multi-monitor driver expects to see its own data structures in the dhpdev block, so we must craft this block of memory properly to obtain a controllable memory write. A detailed description of the needed memory contents would be quite boring and not really cutting-edge, so let’s immediately focus on the tricky part. There are some flags stored in the dhpdev block where we can set the RC_PALETTE bit. This informs the multi-monitor driver that our displays need a palette for drawing. A palette is used for dealing with 8-bit color modes. Enabling such modes for displays has not been possible since Windows 8. However, the code for handling them is still present. This allows us to use the RC_PALETTE flag and thus force the driver to create a palette object while, by preparing contents of the fake dhpdev block carefully, we can control the memory address where the palette object will be stored. In other words, we can overwrite kernel memory of our choice with a palette handle value.

Our target for overwriting will be our process token’s privileges – see here for details on how to obtain the address of our privileges in kernel memory. In short, we can treat privileges as two 64-bit bitfields located in kernel memory. One of these bitfields tells which privileges are present and another one tells which are enabled. For our purposes, it’s enough to gain the following four privileges:

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

To obtain these privileges, we need to set their corresponding bits in the present bitfield. Generally speaking, once a privilege is present in the token, it can be enabled by calling the AdjustTokenPrivileges API. However, not all privileges can be enabled so easily. Each process token contains not only its privileges but also a so-called integrity level. Normal processes don’t have an integrity level high enough to enable the most critical privileges just by making an API call. For this reason, we must perform our exploitation twice: once to overwrite the bitfield indicating which privileges are present and a second time to overwrite the bitfield indicating which privileges are enabled. This means we must:

1) Prepare our fake dhpdev block in such a way that the handle to the palette object will be stored in the present bitfield.
2) Call ExtTextOutW.
3) Prepare our fake dhpdev block once again so the handle to the palette object will be stored in the enabled bitfield.
4) Call ExtTextOutW again.

For successful exploitation, we need to hold only the four privileges listed above. All other privileges may be either set or cleared. Having these four privileges is enough to make a successful call to an undocumented NtCreateToken native API. This allows us to create a token with all privileges present and enabled and with the highest possible integrity level. Passing such a token to a CreateProcessAsUser call allows us to create a maximally powerful user-mode process.

Our last task is to force the kernel to create palettes with the proper handle values so that writing so those values to the privileges bitfields will set the required bits.

Controlling GDI handle values

The lowest 16 bits of each GDI handle act as an index to a so-called global GDI table. For example, a handle value may be:

0x6c0859b2

where:
1) 0x59b2 is an index to a slot in the global GDI table.
2) 0x08 is an object type. 0x08 stands for a palette object.
3) 0x6c is a counter that is incremented each time a slot is assigned for a new object.

Slots in the global GDI table are used in a LIFO (Last In, First Out) manner. We can experiment and create 3 GDI objects: Object1, Object2, and Object3. Obtained handle values may be, for example:

0x74xx25c8
0x21xx1287
0x15xx4f34

Now we can delete these objects in reverse order (Object3, Object2, and Object1) and recreate them in the original order again. The handle values will most probably still reference the same slots, and their values will now be:

0x75xx25c8
0x22xx1287
0x16xx4f34

To achieve our goal, we should:
1) Create many GDI objects of any type. Since there is a per-process limit of 10,000 GDI handles, we can create 9,500 objects. Assuming a linear distribution, 1/16 of the obtained handle values (nearly 600 of them) will have the needed bit combination.
2) Delete the objects that don’t have the needed bit combination in their lowest 16 bits.
3) Delete the objects that do have the needed bit combination in their lowest 16 bits.

The slots of the most recently deleted objects will be first to be reused again when the multi-monitor driver allocates its palette objects during exploitation. Since the most recently deleted objects have the required bit combination in their handle values, the kernel-generated palette objects will also have this same bit combination.

Due to multitasking, other processes may interfere with our manipulations and release additional slots or reuse our just-released slots before they are used by the multi-monitor driver when creating its internal palette objects. This is not a big problem. We can call PrivilegeCheck to see if our process token’s privileges have been overwritten as expected. In case of failure, we can just attempt our exploitation once again.

As a result of our exploitation:
1) The needed privileges in our process token will always be set.
2) There are some other privileges that will always be in a predictable state (set or cleared) due to their being overwritten by the 0x08 part of the handle value.
3) The remaining privileges will be overwritten randomly.

The Patch

When the vulnerability was found, it was first thought that the problem was that the multi-monitor driver doesn’t validate that the dhpdev pointer in the received bitmaps falls within the kernel-mode memory range. We should note that some other HOOK_XXX flags could also be used for exploitation, for example, HOOK_LINETO along with a LineTo call. Therefore, the validation would need to be implemented in multiple places in the multi-monitor driver.

However, under the hood, things are probably more complicated than they appear, so another solution has been implemented. Now, when a bitmap’s dhpdev field is non-NULL (which would be a consequence of making an EngAssociateSurface call), and the bitmap is also printer-compatible (one of the bitmap’s undocumented flags indicates this), selecting the bitmap into a screen-related device context is no longer possible. A newly-added win32kbase.sys!bIsSurfaceAllowedInDC function checks these conditions and causes the SelectObject call to fail. The introduced change shouldn’t cause any problems in real-life scenarios, since the algorithm used for the exploitation is highly artificial. However, this change still breaks compatibility to some extent. For this reason, the patch can be disabled by adding an undocumented registry key from an elevated command prompt and rebooting:

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

Another newly-added function named win32kbase.sys!UMPDAllowPrinterSurfaceInDisplayDC is now called during system initialization. It reads the registry key (if it exists) and stores the result in a global variable called win32kbase.sys!gAllowPrinterSurfaceInDisplayDC. This variable is then read by the aforementioned win32kbase.sys!bIsSurfaceAllowedInDC function, which is internally called during each SelectObject call.

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

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

# The August 2021 Security Update Review

10 August 2021 at 17:22

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

Adobe Patches for August 2021

For August, Adobe released two patches addressing 29 CVEs in Adobe Connect and Magento. The update for Connect is rated Important and fixes a single security feature bypass and two cross-site scripting bugs. The Critical-rated patch for Magento fixes a wide range of bugs, the worst of which could allow remote code execution.

None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.

Microsoft Patches for August 2021

For August, Microsoft released patches today for 44 CVEs in Microsoft Windows and Windows components, Office, .NET Core and Visual Studio, Windows Defender, Windows Update and Update Assistant, Azure, and Microsoft Dynamics. This is in addition to seven CVEs patched in Microsoft Edge (Chromium-based) earlier this month. A total of eight of these bugs were submitted through the ZDI program. Of the 44 CVEs patched today, seven are rated Critical and 37 are rated Important in severity. This is the smallest release for Microsoft in 2021 and could be due to resource constraints since Microsoft spent so much time in July responding to events like PrintNightmare and PetitPotam. In fact, this is the smallest release since December 2019. It will be interesting to see if the September patch volume rebounds to triple digits or remains on the smaller side.

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

-       CVE-2021-36948 - Windows Update Medic Service Elevation of Privilege Vulnerability
This bug could allow a local privilege escalation through the Windows Update Medic Service – a new feature introduced in Windows 10 designed to repair Windows Update components from damage so that the computer can continue to receive updates. An attacker would need to log on to an affected system and run a specially crafted program to escalate privileges. Microsoft does not say how widespread the attacks are, but they are most likely targeted at this point.

-       CVE-2021-36942 - Windows LSA Spoofing Vulnerability
Speaking of PetitPotam, Microsoft released this patch to further protect against NTLM relay attacks by issuing this update to block the LSARPC interface. This will impact some systems, notably Windows Server 2008 SP2, that use the EFS API OpenEncryptedFileRawA function. You should apply this to your Domain Controllers first and follow the additional guidance in ADV210003 and KB5005413. This has been an ongoing issue since 2009, and, likely, this isn’t the last we’ll hear of this persistent issue.

-       CVE-2021-36936 - Windows Print Spooler Remote Code Execution Vulnerability
Another month, another remote code execution bug in the print spooler. This bug is listed as publicly known, but it’s not clear if this bug is a variant of PrintNightmare or a unique vulnerability all on its own. There are quite a few print spooler bugs to keep track of. Either way, attackers can use this to execute code on affected systems. Microsoft does state low privileges are required, so that should put this in the non-wormable category, but you should still prioritize testing and deployment of this Critical-rated bug.

UPDATE: Microsoft has released KB5005652 to provide guidance on managing new Point and Print default driver installation behavior. This is an update for CVE-2021-34481, which was originally released in July, 2021. Sysadmins should review this KB along with applying the Print Spooler related updates in this release.

-       CVE-2021-34535 - Remote Desktop Client Remote Code Execution Vulnerability
Before you start having flashbacks to BlueKeep, this bug affects the RDP client and not the RDP server. However, the CVSS 9.9 bug is nothing to ignore. An attacker can take over a system if they can convince an affected RDP client to connect to an RDP server they control. On Hyper-V servers, a malicious program running in a guest VM could trigger guest-to-host RCE by exploiting this vulnerability in the Hyper-V Viewer. This is the more likely scenario and the reason you should test and deploy this patch quickly.

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

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

You’ll notice this month’s table includes the Chromium updates for Edge. These vulnerabilities are listed with the severity as assigned by Google, which is different from the standard Microsoft nomenclature. Google does not assign a CVSS score, so none is listed in the table.

Looking at the remaining Critical-rated updates, most are of the browse-and-own variety, meaning an attacker would need to convince a user to browse to a specially crafted website with an affected system. One exception would be CVE-2021-26432, which is a patch for the Windows Services for NFS ONCRPC XDR Driver. Microsoft provides no information on how the CVSS 9.8 rated vulnerability could be exploited, but it does note  it needs neither privileges or user interaction to be exploited. This may fall into the “wormable” category, at least between servers with NFS installed, especially since the open network computing remote procedure call (ONCRPC) consists of an External Data Representation (XDR) runtime built on the Winsock Kernel (WSK) interface. That certainly sounds like elevated code on a listening network service. Don’t ignore this patch.

Another interesting Critical-rated bug affects the TCP/IP stack. Despite its CVSS rating of 9.9, this may prove to be a trivial bug, but it’s still fascinating. An attacker on a guest Hyper-V OS could execute code on the host Hyper-V server by sending a specially crafted IPv6 ping. This keeps it out of the wormable category. Still, a successful attack would allow the guest OS to completely take over the Hyper-V host. While not wormable, it’s still cool to see new bugs in new scenarios being found in protocols that have been around for years.

The remaining patches for RCE bugs primarily address open-and-own types of bugs in Microsoft Dynamics (on-prem), Office, Word, and Windows media components. For example, the vulnerability in Word would require someone to open a specially crafted Word doc with an affected version, resulting in code execution at the logged-on user lever. There’s also an Important-rated RCE bug in the print spooler, however, it’s not clear why this one is rated Important while the other is rated Critical. Both have the exact same CVSS rating. One is publicly known, but that shouldn’t affect severity. Best to treat both print spooler bugs as Critical, just to be on the safe side.

There are a total of 16 Elevation of Privilege (EoP) patches in this month’s release. Most of these exist in Windows components and require an attacker to log on to an affected system and execute their specially crafted program. Six of these bugs were reported through the ZDI program by Abdelhamid Naceri (halov) and deal with improper link resolution before file access (Link Following) vulnerabilities. For example, by creating a directory junction, an attacker can abuse the Windows Update Assistant to delete a file. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the Administrator. Altogether, there are EoP fixes for Windows Defender, Azure Sphere and CycleCloud, Storage Spaces, the Update Assistant, the Bluetooth service, Windows Event Tracing, and the aforementioned Print Spooler.

Looking at the eight information disclosure bugs in this month’s release, more simply result in leaks consisting of unspecified memory contents. A notable exception is the patch for .NET Core and Visual Studio that could disclose data inside the targeted website like IDs, tokens, nonces, and other sensitive information. Microsoft does not specify what information is disclosed by the bug in the Windows Cryptographic Primitives Library, but judging by the title alone, it’s possible (though unlikely) that an attacker could recover plaintext data from encrypted content. Let’s hope we receive more information on this bug in the future.

Only two patches this month result in Denial-of-Service (DoS) conditions, but you likely only need to act on one. The update for Azure Sphere should have been automatically delivered to your device provided it is connected to the Internet. The other patch fixes a DoS bug in .NET Core and Visual Studio and needs to be installed as per usual.

There are also just two security feature bypasses getting fixes this month. The first is for Azure Active Directory Connect, but you’ll need to do more than just patch to prevent a Man-in-The-Middle (MiTM) attack between your Azure AD Connect server and a domain controller. You will also need to disable NTLM as laid out in this document. The other spoofing bug occurs in SharePoint Server and likely manifests as a cross-site scripting (XSS) issue. Speaking of XSS bugs, this month’s release is rounded out by two patches for XSS vulnerabilities in Microsoft Dynamics.

As expected, the servicing stack advisory (ADV990001) was revised for multiple versions of Windows this month. No new advisories were released this month.

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

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

12 August 2021 at 15:00

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

Since its inception, our Fall Pwn2Own contest has focused on consumer devices – even as the contest itself has wandered around the world. It started in Amsterdam in 2012 with just mobile phones. The next year, the contest moved to Tokyo to be held concurrently with the PacSec Applied Security conference and, over the years, grew to include TVs, wearable, and smart speakers. Last year, the contest moved to Toronto and expanded again to include Network Attached Storage (NAS) devices. For 2021, we’re on the move again. This year, we’ll be hosting Pwn2Own for our headquarters in Austin, Texas on November 2-4, 2021. For this year’s event, we’re growing again to reflect the home-office environment many currently find themselves in by expanding the router category and implementing the printer category. In all, we’ll have 22 devices available as targets and be offering more than $500,000 USD in prize money. Similar to how we’ve conducted our last few Pwn2Own events, we will allow remote participation in this inaugural Pwn2Own Austin. As of now, we are planning on having contestants in person if possible. However, if you have either travel restrictions or travel safety concerns, you can opt to compete remotely. You will still need to register before the contest deadline (October 29, 2021) and submit a detailed whitepaper completely explaining your exploit chain and instructions on how to run the entry by November 1, 2021. A member of the ZDI staff in Austin will run your exploit for you. All attempts will be filmed and available for viewing by the contestant and the vendor. As in the past, we will work with remote contestants to monitor the attempt in real-time via a phone call or video chat. Please note that since you are not in person, changes to exploits/scripts/etc. will not be possible, which could lower your chance of winning should something unexpected occur. Otherwise, the contest will run as we have in the past. We will have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there. Our intention with allowing remote participation is to provide as many people as possible with the benefits of participating in Pwn2Own while still treating all contestants as equally as possible. As always, if you have questions, please contact us at [email protected]. We will be happy to address your issues or concerns directly. As for the contest itself, we’re pleased to announce Western Digital has joined us as an Event Partner this year, offering three of its devices as targets. We’ve also signed on Synology to co-sponsor the competition. Western Digital and Synology devices will be prime targets for researchers. Both vendors had NAS devices featured in last year’s event, and we’re thrilled they decided to expand their participation in this year’s contest. Vendor participation remains a key component to the success of these contests. As with our other Pwn2Own competitions, Pwn2Own Austin seeks to harden these consumer-focused devices and their operating systems by revealing vulnerabilities and providing that knowledge to the vendors. As always, the goal is to get these bugs identified and fixed before they’re exploited by threat actors. The Target Handsets At its heart, Pwn2Own Austin (once known as Pwn2Own Mobile) looks at mobile phones, and our move to Texas doesn’t change this fact. Here are the target handsets for Pwn2Own Austin 2021: 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: Home Automation: Televisions: Routers: Network Attached Storage (NAS): External Storage: As with the phones, these devices will be updated to the most recent patch level or system update, and all will be in their default configuration. Pwn2Own Austin Challenges for 2021 Now that you know the devices available, let’s look at the different categories of challenges, starting with the mobile handsets. Mobile Phone Category In this category, contestants must compromise the device by browsing to web content in the default browser for the target under test or by communicating with the following short distance protocols: near field communication (NFC), Wi-Fi, or Bluetooth. The awards for this category are: This category also includes an add-on bonus. If your exploit payload executes with kernel-level privileges, you earn an additional$50,000 and 5 more Master of Pwn points. That means a full iPhone or Pixel browser exploit with kernel-level access will earn $200,000. Challenges Involving Other Devices This is our fourth year including other types of consumer and home automation devices, and each year brings new research that exceeds our expectations. Last year we saw NAS devices compromised as a part of the contest. They return along with an expanded routers list and the aforementioned printers. It should be a great contest. 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. 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. For details about the 3TB My Cloud Home Personal Cloud from WD - firmware version 8.xx.xx-xxx (Beta), see the supplemental blog here. External Storage Category While not as complex as a NAS server, external storage devices offer a tempting target for attackers. This year’s contest adds a single device in this category. An attempt in this category must be launched against the target’s exposed interfaces and result in arbitrary code execution. Home Automation Category Smart speakers continue to play a large part in our daily interactions with music, news, and more. Pwn2Own Austin has five targets available in this category. 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. Contestants can register for attempts against the WAN interface, the LAN interface, or both interfaces on the same device. Television Category These days, it’s difficult to find a television set that doesn’t include a web browser and network applications. Pwn2Own Austin 2021 has two devices under test this year. 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. ©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! # From Pwn2Own 2021: A New Attack Surface on Microsoft Exchange - ProxyShell! 18 August 2021 at 14:54 In April 2021, Orange Tsai from DEVCORE Research Team demonstrated a remote code execution vulnerability in Microsoft Exchange during the Pwn2Own Vancouver 2021 contest. In doing so, he earned himself$200,000. Since then, he has disclosed several other bugs in Exchange and presented some of his findings at the recent Black Hat conference. Now that the bugs have been addressed by Microsoft, Orange has graciously provided this detailed write-up of the vulnerabilities he calls “ProxyShell”.

Hi, I am Orange Tsai from DEVCORE Research Team. In this article, I will introduce the exploit chain we demonstrated at the Pwn2Own 2021. It’s a pre-auth RCE on Microsoft Exchange Server and we named it ProxyShell! This article will provide additional details of the vulnerabilities. Regarding the architecture, and the new attack surface we uncovered, you can follow my talk on Black Hat USA and DEFCON or read the technical analysis in our blog.

ProxyShell consists of 3 vulnerabilities:

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

With ProxyShell, an unauthenticated attacker can execute arbitrary commands on Microsoft Exchange Server through an exposed 443 port!

CVE-2021-34473 - Pre-auth Path Confusion

The first vulnerability of ProxyShell is similar to the SSRF in ProxyLogon. It too appears when the frontend (known as Client Access Services, or CAS) is calculating the backend URL. When a client HTTP request is categorized as an Explicit Logon Request, Exchange will normalize the request URL and remove the mailbox address part before routing the request to the backend.

Explicit Login is a special feature in Exchange to make a browser embed or display a specific user’s mailbox or calendar with a single URL. To accomplish this feature, this URL must be simple and include the mailbox address to be displayed. For example:

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

Through our research, we found that in certain handlers such as EwsAutodiscoverProxyRequestHandler, we can specify the mailbox address via the query string. Because Exchange doesn’t conduct sufficient checks on the mailbox address, we can erase a part of the URL via the query string during the URL normalization to access an arbitrary backend URL.

HttpProxy/EwsAutodiscoverProxyRequestHandler.cs

From the above code snippet, if the URL passes the check of IsAutodiscoverV2PreviewRequest, we can specify the Explicit Logon address via the Email parameter of the query string. It’s easy because this method just performs a simple validation of the URL suffix.

The Explicit Logon address will then be passed as an argument to method RemoveExplicitLogonFromUrlAbsoluteUri, and the method just uses Substring to erase the pattern we specified.

Here we designed the following URL to abuse the normalization process of Explicit Logon URL:

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

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.

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: 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. 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! # ProxyToken: An Authentication Bypass in Microsoft Exchange Server 30 August 2021 at 12:59 Continuing with the theme of serious vulnerabilities that have recently come to light in Microsoft Exchange Server, in this article we present a new vulnerability we call ProxyToken. It was reported to the Zero Day Initiative in March 2021 by researcher Le Xuan Tuyen of VNPT ISC, and it was patched by Microsoft in the July 2021 Exchange cumulative updates. Identifiers for this vulnerability are CVE-2021-33766 and ZDI-CAN-13477. With this vulnerability, an unauthenticated attacker can perform configuration actions on mailboxes belonging to arbitrary users. As an illustration of the impact, this can be used to copy all emails addressed to a target and account and forward them to an account controlled by the attacker. The Trigger The essential HTTP traffic needed to trigger the vulnerability is as follows: “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: Thus, for requests within /ecp, if the front end finds a non-empty cookie named SecurityToken, it delegates authentication to the back end. Code on the back end that examines and validates the SecurityToken cookie is found in the class Microsoft.Exchange.Configuration.DelegatedAuthentication.DelegatedAuthenticationModule. What goes wrong on the validation side? To see the answer, have a look at /ecp/web.config on the back end: As you can see, in a default configuration of the product, a <remove> element appears, so that the module DelegatedAuthModule will not be loaded at all for the back-end ECP site. In summary, when the front end sees the SecurityToken cookie, it knows that the back end alone is responsible for authenticating this request. Meanwhile, the back end is completely unaware that it needs to authenticate some incoming requests based upon the SecurityToken cookie, since the DelegatedAuthModule is not loaded in installations that have not been configured to use the special delegated authentication feature. The net result is that requests can sail through, without being subjected to authentication on either the front or back end. Bagging a Canary There is one additional hurdle to clear before we can successfully issue an unauthenticated request, but it turns out to be a minor one. Each request to an /ecp page is required to have a ticket known as the “ECP canary”. Without a canary, the request will come back with an HTTP 500. However, the attacker is still in luck, because the 500 error response is accompanied by a valid canary: An example of the final request would then be as follows: This particular exploit assumes that the attacker has an account on the same Exchange server as the victim. It installs a forwarding rule that allows the attacker to read all the victim’s incoming mail. On some Exchange installations, an administrator may have set a global configuration value that permits forwarding rules having arbitrary Internet destinations, and in that case, the attacker does not need any Exchange credentials at all. Furthermore, since the entire /ecp site is potentially affected, various other means of exploitation may be available as well. 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 # CVE-2021-2429: A Heap-based Buffer Overflow Bug in the MySQL InnoDB memcached Plugin 2 September 2021 at 16:05 In April 2021, the ZDI received a submission of a vulnerability in the MySQL database. It turned out to be a heap-based buffer overflow bug in the InnoDB memcached plugin. It was submitted to the program by an anonymous researcher. The vulnerability affects MySQL versions 8.0.25 and prior. It can be triggered remotely and without authentication. Attackers can leverage this vulnerability to execute arbitrary code on the MySQL database server. Oracle patched it in July and assigned it CVE-2021-2429, while ZDI’s identifier is ZDI-2021-889. The Vulnerability The following analysis is based on the source code of MySQL Community Server version 8.0.25. The bug is in the memcached GET command, which is used for retrieving data from a table. For performance, the GET command supports fetching multiple key-value pairs in a single memcached query. Here is an example: The keys specified in the GET command are tokenized by process_get_command() and then handled one by one in innodb_get() . If a key in the GET command has the form @@containers.name, then the variable report_table_switch will have been set to true, satisfying the branch at (1). The memcpy at (3) copies table_name to the row_buf buffer. Before performing the memcpy, the code at (2) validates that there is still enough space in row_buf. However, this validation is performed with an assert() only. Since assert is a macro that produces code only in debug builds but not in release builds, this leads to a buffer overflow that can be reached when running a release build. The Trigger The InnoDB memcached plugin is not enabled by default. One must build MySQL from source with -DWITH_INNODB_MEMCACHED=ON. Here is the build detail. By default, the memcached daemon listens on TCP and UDP port 11211. The payload is a single GET command as seen in the example below. get @@aaa @@aaa @@aaa ... @@aaa is one of the default rows in the innodb_memcache database. Each @@aaa is replaced with the table name test/demo_test at (5) within the innodb_get() function shown above. The resulting overflow content has the form test/demo_testtest/demo_testtest/demo_test.... The length of the overflow is controllable by the attacker. After sending the payload, the heap overflow is triggered in the mysqld process. The call stack is shown below. The Patch The vulnerability was fixed in version 8.0.26. The patch is straightforward. It explicitly checks the length before copying. Conclusion Although the InnoDB memcached plugin is not enabled by default, it is nonetheless wise to apply the patch as soon as possible. It would not surprise me to see a reliable full exploit in the near future. You can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches. CVE-2021-2429: A Heap-based Buffer Overflow Bug in the MySQL InnoDB memcached Plugin # Analysis of a Parallels Desktop Stack Clash Vulnerability and Variant Hunting using Binary Ninja 9 September 2021 at 14:59 Parallels Desktop uses a paravirtual PCI device called the “Parallels ToolGate” for communication between guest and host OS. This device is identified by Vendor ID 0x1AB8 and Device ID 0x4000 in a Parallels guest. The guest driver provided as part of Parallels Tools and the host virtual device communicate using a ToolGate messaging protocol. To provide a summary, the guest driver prepares a message and writes the physical address of the message to TG_PORT_SUBMIT [PORT IO ADDRESS+0x8]. The host then maps the guest provided physical address, parses the message, and transfers control to the respective request handlers for further processing. Many of the bugs received by the ZDI program in Parallels are in these request handlers. ToolGate Interface and Protocol Format The ToolGate request format is a variable size structure that could span across multiple pages. The guest sends data to the host as inline bytes or pointers to paged buffers by writing the physical address of TG_PAGED_REQUEST structure to the IO port of the virtual device. 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). When handling TG_REQUEST_INVSHARING (0x8420), Parallels Desktop does not validate the ByteCount value provided by the guest as part of TG_PAGED_BUFFER. When allocated in stack, this untrusted size value can be used for shifting the stack top of thread processing the ToolGate request into another victim thread to overwrite its contents. There is a guard page that is 4KB in size, however it is possible to jump over this small allocation without accessing it. Qualys published a detailed paper titled The Stack Clash on this bug class back in 2017, which also leads to various compiler mitigations to prevent such guard page jumps. Below is the vulnerable section of code from Parallels Desktop 16.1.3. During the call to TG_ReadBuffer(), the stack memory of another thread can be overwritten with guest-controlled values. Backward Compatibility and Compiler Mitigations The most interesting question here is what happened to the stack clash compiler mitigation in Apple Clang? When a variable size allocation is made in stack like alloca(value) or char buffer[value], the Apple Clang compiler instruments the allocation with ___chkstk_darwin() to validate the size of allocation request. ___chkstk_darwin() essentially allocates a PAGE_SIZE of memory in stack, and then, for each page allocated, probes the new stack top if it is accessible. If the case guard page is reached, the probing step will fail leading to a safe crash. It is no longer possible to shift the stack pointer into an arbitrary location. It is clear that Parallels Desktop did not have this mitigation enabled because there is no call to ___chkstk_darwin() during the variable size stack allocation. At this point there are couple of open questions: -- Did Parallels disable the mitigation using -fno-stack-check compiler flag? -- Did they use an old build configuration which disabled the mitigation? Mac OS otool can be used to get a fair amount of information regarding the build environment. Specifically, LC_VERSION_MIN_MACOSX can provide information regarding the macOS versions supported. Here is the output of otool -l prl_vm_app: The SDK used is 10.15 (Catalina), which is quite new. Moreover, Parallels has also set the minimal macOS version supported to 10.13, which makes it compatible with High Sierra. This aligns with the compatibility information provided in their KB article. Still, does backward compatibility for 10.13 disable the compiler mitigation? Here is a comparison of sample code compiled with and without -mmacosx-version-min=10.13: It is unclear if Parallels had ___chkstk_darwin() explicitly disabled using -fno-stack-check, but setting -mmacosx-version-min=10.13 has the same effect and silently drops the mitigation. The same behavior is also observed with -mmacosx-version-min=10.14 (Mojave). Interestingly, GCC has inlined the stack probe check instead of depending on an external library function. This is possibly due to an external dependency, as compiling in Apple Clang with the backward compatibility flags (macosx-version-min, target etc.) ended up removing the mitigation. Saying that, Mojave (10.14.6) did not give any symbol errors when running executables with calls to ___chkstk_darwin(). One can find many such issues in High Sierra (10.13.6). It is noticed that, in older compilers (e.g. Apple LLVM version 10.0.1 on Mojave), the stack clash mitigation is not enabled by default unless the -fstack-check flag is explicitly provided. Therefore, the recent compilers seem to drop the mitigation entirely when compiled with macosx-version-min for any version less than 10.15. This can be worked around by providing both the -fstack-check and -mmacosx-version-min flags together. However, High Sierra compatibility is questionable. The highlight is that using macosx-version-min alone can make the bug exploitable even on latest versions of Mac OS. Variant hunting using Binary Ninja The next question is, are there other similar bugs in Parallels Desktop? How can we automate this process? The size of a stack frame is generally known during compile time. Moreover, any operations that shift the stack pointer can also be tracked. Binary Ninja has static data flow capability which keeps track of the stack frame offset at any point in a function. However, when there is a variable size allocation in stack, the stack offsets cannot be determined statically. This exact property can be used to look for variants of the bug. Consider the index 88 in the above Low-Level IL, where RSP register is loaded. Here, the new stack top is calculated using a guest-provided size and loaded into RSP. Binary Ninja provides get_possible_reg_values() and get_possible_reg_values_after() python APIs to fetch statically determined values for registers. The register values are also associated with type information (RegisterValueType). Here is the stack frame offset value in RSP before and after the load operation: The RSP is always associated with StackFrameOffset RegisterValueType. However, when the RSP value is not known, it is marked as UndeterminedValue. With this value type information, search for all references to TG_ReadBuffer() where RSP value is undetermined. If RSP is undetermined before the call to TG_ReadBuffer(), its deduced that a variable size allocation was made in stack prior to the call. The above query yielded 3 results; one was the Pwn2Own submission and 2 other previously unknown vulnerabilities. 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 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 # The September 2021 Security Update Review 14 September 2021 at 17:37 It’s the second Tuesday of the month, and that means the latest security updates from Adobe and Microsoft have been released. Apple and Google Chrome also released updates yesterday to fix bugs under active attack. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings. Adobe Patches for September 2021 For September, Adobe released 15 patches covering 59 CVEs in Adobe Acrobat Reader, XMP Toolkit SDK, Photoshop, Experience Manager, Genuine Service, Digital Editions, Premiere Elements, Photoshop Elements, Creative Cloud Desktop, ColdFusion, Framemaker, InDesign, SVG-Native-Viewer, InCopy, and Premiere Pro. A total of 17 of these bugs came through the ZDI program. The update for Adobe Acrobat fixes 26 bugs in total. Of these 26 bugs, 13 are rated Critical, 9 are rated Important, and four are rated Moderate in severity. The most severe of these bugs could allow remote code execution through either a type confusion, heap-based buffer overflow, or a use after free vulnerability. The single bug fixed by the Photoshop patch could also lead to code execution when opening a specially crafted file. The update for Framemaker includes five bugs found by ZDI researcher Mat Powell. The most severe of these issues result from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. If you’re still using ColdFusion, you’ll definitely want to patch the two Critical rated security feature bypass bugs being fixed today. You can check out all of Adobe’s patches on their PSIRT page. None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release. Apple Patches for September 2021 Although Apple does not follow the second Tuesday patch release cycle, they did release patches yesterday fixing a couple of significant bugs. CVE-2021-30860 fixes an input validation bug in CoreGraphics that could allow remote code execution. Apple notes they are aware of a report this bug is being actively exploited. This was reported by the Citizen Lab, and public accounts indicate this bug was used to target a Saudi activist’s iPhone. While the likelihood of widespread attack using this bug is low, it should still be taken seriously. Apple also notes CVE-2021-30858 – a Use-After-Free (UAF) bug in Webkit – has also been detected in the wild. These bugs impact several different Apple products, including iOS, iPad OS, watchOS, Safari, Catalina, and Big Sur. Definitely take some time to review all of the patches and apply the applicable updates once tested. Google Chrome Patches for September 2021 Not to be outdone by Apple, Google also released a new version of Chrome yesterday to address a total of nine CVEs – two of which are listed as under active attack. CVE-2021-30632 fixes an Out-of-Bounds (OOB) Write, while CVE-2021-30633 fixes a UAF bug. Both were reported by an anonymous researcher, and both could lead to code execution at the level of the logged-on user. All of the bugs fixed in this release receive a “High” severity rating from Google. If you are running Chrome, definitely update to ensure you are on the latest stable version. Side note: As of today, not all these fixes have not been absorbed by Microsoft Edge (Chromium) and are unrelated to the Edge (Chromium) fixes discussed below. Microsoft did list CVE-2021-30632 on September 11 but appears to have jumped the gun a bit on this release as it currently shows a September 14 release date. Microsoft Patches for September 2021 For September, Microsoft released patches today for 66 CVEs in Microsoft Windows and Windows components, Microsoft Edge (Chromium, iOS, and Android), Azure, Office and Office Components, SharePoint Server, Microsoft Windows DNS, and the Windows Subsystem for Linux. This is in addition to the 20 CVEs patched by Microsoft Edge (Chromium-based) earlier this month, which brings the September total to 86 CVEs. A total of 11 of these bugs were submitted through the ZDI program. Of the 66 new CVEs patched today, three are rated Critical, 62 are rated Important, and one is rated Moderate in severity. This volume is slightly higher than the average for 2021, which is below the 2020 volume while still above what was seen in 2019. As with last month, Microsoft spent significant resources responding to bugs under active attack, most notably CVE-2021-40444. One other bug is listed as publicly known but not being exploited (for now). Let’s take a closer look at some of the more interesting updates for this month, starting with the MSHTML bug that’s listed as under active attack: - CVE-2021-40444 - Microsoft MSHTML Remote Code Execution Vulnerability This patch fixes a bug currently being exploited via Office documents. A specially crafted ActiveX control is embedded in an Office doc then sent to a target. If opened on an affected system, code executes at the level of the logged-on user. Microsoft lists disabling ActiveX as a workaround, but other reports state this may be ineffective. As of now, the most effective defense is to apply the patch and avoid Office docs you aren’t expecting to receive. There are multiple updates for specific platforms, so be sure to carefully review and install all needed patches to ensure you are covered. - CVE-2021-36965 - Windows WLAN AutoConfig Service Remote Code Execution Vulnerability This patch fixes a vulnerability that could allow network adjacent attackers to run their code on affected systems at SYSTEM level. This means an attacker could completely take over the target – provided they are on an adjacent network. This would be highly useful in a coffee shop scenario where multiple people are using an unsecured WiFi network. Still, this requires no privileges or user interaction, so don’t let the adjacent aspect of this bug diminish the severity. Definitely test and deploy this patch quickly. - CVE-2021-38647 - Open Management Infrastructure Remote Code Execution Vulnerability This patch rates the highest CVSS (9.8) for this month and fixes an RCE bug in the Open Management Infrastructure (OMI). If you aren’t familiar with OMI, it’s an open-source project to further the development of a production-quality implementation of the DMTF CIM/WBEM standards. You can read all about it here. This vulnerability requires no user interaction or privileges, so an attacker can run their code on an affected system just by sending a specially crafted message to an affected system. OMI users should test and deploy this one quickly. Here’s the full list of CVEs released by Microsoft for September 2021:  CVE Title Severity CVSS Public Exploited Type CVE-2021-40444 Microsoft MSHTML Remote Code Execution Vulnerability Important 8.8 Yes Yes RCE CVE-2021-36968 Windows DNS Elevation of Privilege Vulnerability Important 7.8 Yes No EoP CVE-2021-38647 Open Management Infrastructure Remote Code Execution Vulnerability Critical 9.8 No No RCE CVE-2021-26435 Windows Scripting Engine Memory Corruption Vulnerability Critical 8.1 No No RCE CVE-2021-36965 Windows WLAN AutoConfig Service Remote Code Execution Vulnerability Critical 8.8 No No RCE CVE-2021-36956 Azure Sphere Information Disclosure Vulnerability Important 4.4 No No Info CVE-2021-38632 BitLocker Security Feature Bypass Vulnerability Important 5.7 No No SFB CVE-2021-38661 HEVC Video Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-40448 Microsoft Accessibility Insights for Android Information Disclosure Vulnerability Important 6.3 No No Info CVE-2021-40440 Microsoft Dynamics Business Central Cross-site Scripting Vulnerability Important 5.4 No No XSS CVE-2021-26436 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 6.1 No No EoP CVE-2021-36930 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Important 5.3 No No EoP CVE-2021-38669 Microsoft Edge (Chromium-based) Tampering Vulnerability Important 6.4 No No Tampering CVE-2021-38641 Microsoft Edge for Android Spoofing Vulnerability Important 6.1 No No Spoofing CVE-2021-38642 Microsoft Edge for iOS Spoofing Vulnerability Important 6.1 No No Spoofing CVE-2021-38655 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38644 Microsoft MPEG-2 Video Extension Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38646 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38657 Microsoft Office Graphics Component Information Disclosure Vulnerability Important 6.1 No No Info CVE-2021-38658 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38660 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38659 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38650 Microsoft Office Spoofing Vulnerability Important 7.6 No No Spoofing CVE-2021-38653 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38654 Microsoft Office Visio Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38651 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing CVE-2021-38652 Microsoft SharePoint Server Spoofing Vulnerability Important 7.6 No No Spoofing CVE-2021-38634 Microsoft Windows Update Client Elevation of Privilege Vulnerability Important 7.1 No No EoP CVE-2021-38656 Microsoft Word Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-38645 Open Management Infrastructure Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38648 Open Management Infrastructure Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38649 Open Management Infrastructure Elevation of Privilege Vulnerability Important 7 No No EoP CVE-2021-26437 Visual Studio Code Spoofing Vulnerability Important 5.5 No No Spoofing CVE-2021-26434 Visual Studio Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36952 Visual Studio Remote Code Execution Vulnerability Important 7.8 No No RCE CVE-2021-36975 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38639 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38628 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38638 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38629 Windows Ancillary Function Driver for WinSock Information Disclosure Vulnerability Important 6.5 No No Info CVE-2021-36959 Windows Authenticode Spoofing Vulnerability Important 5.5 No No Spoofing CVE-2021-36954 Windows Bind Filter Driver Elevation of Privilege Vulnerability Important 8.8 No No EoP CVE-2021-36963 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36955 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38633 Windows Common Log File System Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36964 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38630 Windows Event Tracing Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36961 Windows Installer Denial of Service Vulnerability Important 5.5 No No DoS CVE-2021-36962 Windows Installer Information Disclosure Vulnerability Important 5.5 No No Info CVE-2021-38625 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38626 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38624 Windows Key Storage Provider Security Feature Bypass Vulnerability Important 6.5 No No SFB CVE-2021-38667 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-38671 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-40447 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36969 Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability Important 5.5 No No Info CVE-2021-38635 Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability Important 5.5 No No Info CVE-2021-38636 Windows Redirected Drive Buffering SubSystem Driver Information Disclosure Vulnerability Important 5.5 No No Info CVE-2021-36973 Windows Redirected Drive Buffering System Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36974 Windows SMB Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36960 Windows SMB Information Disclosure Vulnerability Important 7.5 No No Info CVE-2021-36972 Windows SMB Information Disclosure Vulnerability Important 5.5 No No Info CVE-2021-38637 Windows Storage Information Disclosure Vulnerability Important 5.5 No No Info CVE-2021-36966 Windows Subsystem for Linux Elevation of Privilege Vulnerability Important 7.8 No No EoP CVE-2021-36967 Windows WLAN AutoConfig Service Elevation of Privilege Vulnerability Important 8 No No EoP CVE-2021-26439 Microsoft Edge for Android Information Disclosure Vulnerability Moderate 4.6 No No Info CVE-2021-30606 Chromium: CVE-2021-30606 Use after free in Blink High N/A No No RCE CVE-2021-30607 Chromium: CVE-2021-30607 Use after free in Permissions High N/A No No RCE CVE-2021-30608 Chromium: CVE-2021-30608 Use after free in Web Share High N/A No No RCE CVE-2021-30609 Chromium: CVE-2021-30609 Use after free in Sign-In High N/A No No RCE CVE-2021-30610 Chromium: CVE-2021-30610 Use after free in Extensions API High N/A No No RCE CVE-2021-30632 Chromium: CVE-2021-30632 Out of bounds write in V8 High N/A No Yes RCE CVE-2021-30623 Chromium: CVE-2021-30623 Use after free in Bookmarks Low N/A No No RCE CVE-2021-30624 Chromium: CVE-2021-30624 Use after free in Autofill Low N/A No No RCE CVE-2021-30611 Chromium: CVE-2021-30611 Use after free in WebRTC Medium N/A No No RCE CVE-2021-30612 Chromium: CVE-2021-30612 Use after free in WebRTC Medium N/A No No RCE CVE-2021-30613 Chromium: CVE-2021-30613 Use after free in Base internals Medium N/A No No RCE CVE-2021-30614 Chromium: CVE-2021-30614 Heap buffer overflow in TabStrip Medium N/A No No RCE CVE-2021-30615 Chromium: CVE-2021-30615 Cross-origin data leak in Navigation Medium N/A No No Info CVE-2021-30616 Chromium: CVE-2021-30616 Use after free in Media Medium N/A No No RCE CVE-2021-30617 Chromium: CVE-2021-30617 Policy bypass in Blink Medium N/A No No SFB CVE-2021-30618 Chromium: CVE-2021-30618 Inappropriate implementation in DevTools Medium N/A No No RCE CVE-2021-30619 Chromium: CVE-2021-30619 UI Spoofing in Autofill Medium N/A No No Spoofing CVE-2021-30620 Chromium: CVE-2021-30620 Insufficient policy enforcement in Blink Medium N/A No No SFB CVE-2021-30621 Chromium: CVE-2021-30621 UI Spoofing in Autofill Medium N/A No No Spoofing CVE-2021-30622 Chromium: CVE-2021-30622 Use after free in WebApp Installs Medium N/A No No RCE As we did last month, this month’s table also lists the Chromium updates for Edge. These vulnerabilities are listed with the severity as assigned by Google, which is different from the standard Microsoft nomenclature. Google does not assign CVSS scores, so none are listed in the table. Again, these bugs are different than the ones fixed by Google Chrome in yesterday’s release. Those bugs should be incorporated into a future version of Edge (Chromium). The remaining Critical-rated bug fixes a code execution vulnerability in the Scripting Engine. An attacker would need to convince a user to browse to a specially crafted website or open a file to get code execution. Looking at the other RCE bugs addressed in this release, many impact Office or an Office component. Visio receives some rare updates to go along with the more common fixes for Word, Access, and Excel. This month’s release brings a total of 27 Elevation of Privilege (EoP) patches with it. The most notable is one listed as publicly known impacting DNS. Microsoft provides no details about the nature of the bug other than to say local privileges are required to successfully exploit it. This is not to be confused with the patch for an EoP in the Bind Filter Driver, which is completely different from the ISC BIND DNS system. Other notable EoP bugs include updates for Edge (Chromium) that seem unique to Edge – meaning the bugs weren’t from the port of Chromium and patched by Google. Visual Studio receives a patch to fix an EoP reported by ZDI researcher Michael DePlante. The issue results from incorrect permissions set on a resource used by the installer. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of SYSTEM. There are some patches for the Print Spooler, but these don’t appear to have the impact or urgency as the PrintNightmare series of bugs. The other EoP fixes address various Windows components. In almost all cases, an attacker would need to log on to an affected system and run specially crafted code. There are only two patches for security feature bypasses (SFBs) in this month’s release, but one seems awfully familiar. CVE-2021-38632 fixes a bug that could allow an attacker with physical access to a powered-off system to gain access to encrypted data. This sounds vaguely like the “cold boot” attacks widely discussed back in 2008. The other SFB bug being fixed this month could allow an attacker to bypass the Windows Key Storage Provider that issues key certificates for trust in attestation scenarios. This one’s a bit more vague, but surprisingly, Microsoft lists the attack complexity as Low for this bug. Definitely something to look out for. Looking at the 12 information disclosure bugs in this month’s release, more simply result in leaks consisting of unspecified memory contents. A notable exception is a bug in the Windows Installer that could allow an attacker to read from the file system. The Windows Storage component has a bug with a similar impact. It’s not clear if any file can be read by an attacker or just specifical files and locations. The info disclosure being fixed in the Microsoft Accessibility Insights for Android is even more vague. According to Microsoft, the type of info disclosed is “sensitive information.” Well then. Plan accordingly. The September release includes fixes for seven spoofing bugs and one for a cross-site scripting (XSS) bug. Microsoft provides no details on what may be spoofed for any of these vulnerabilities, but some have intriguing titles. There are fixes for Microsoft Edge for iOS and Android, so for those of you who use Edge on your phone, hit up the appropriate store to update your apps. There is a fix for a spoofing bug in Windows Authenticode, but the attacker vector is listed as local with privileges required. It’s possible this could allow an attacker access to something otherwise prohibited, but without further details, we can only speculate. This month’s release is rounded out by a fix for a Denial-of-Service (DoS) bug in the Windows Installer and by a fix for Microsoft Edge (Chromium) in the mercurial Tampering category. Again, no information on what sort of tampering this vulnerability would allow. However, tampering bugs in the browser usually means an attacker could view and/or alter data within the browser. Interestingly, Microsoft appears to have released this update on September 9, but it does not appear to map to any bug fix released by the Chrome team. No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV990001. Looking Ahead The next Patch Tuesday falls on October 12, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean! The September 2021 Security Update Review # CVE-2021-26084: Details on the Recently Exploited Atlassian Confluence OGNL Injection Bug 22 September 2021 at 15:28 In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Yazhi Wang of the Trend Micro Research Team detail a recent code injection bug in the Atlassian Confluence server. Since the publication of the vendor advisory, U.S. Cybercom has reported that mass exploitation of this bug for crypto mining is ongoing and expected to accelerate. The following is a portion of their write-up covering the root cause CVE-2021-26084, with a few minimal modifications. An Object-Graph Navigation Language (OGNL) injection has been reported in the Webwork module of Atlassian Confluence Server and Data Center. The vulnerability is due to insufficient input validation leading to OGNL evaluation of user-supplied input. A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation can result in arbitrary code execution in the security context of the affected server. The Vulnerability Atlassian Confluence is a collaboration platform written in Java. Users can create content using spaces, pages, and blogs that other users can comment on and edit. It is written primarily in Java and runs on a bundled Apache Tomcat application server. By default, Confluence is accessible via HTTP on port 8090/TCP. HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body: where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF). SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like: A corresponding HTTP request using the POST method might look as follows: Confluence uses the Webwork web application framework to map URLs to Java classes, creating what is known as an “action”. Action URLs end with the “.action” suffix and are defined in the xwork.xml file in confluence- <version>.jar (where <version> is the Confluence version number) and in the atlassian-plugin.xml file in JAR files of included plugins. Each action entry contains at least a name attribute, defining the action name, a class attribute, defining the Java class implementing the action, and at least one result element which decides the Velocity template to render after the action is invoked based on the result of the action. Common return values from actions are “error”, “input”, and “success”, but any value may be used if there is a matching result element in the associated XWork XML. Action entries can contain a method attribute, which allows invocation of a specific method of the specified Java class. When no command is specified, the doDefault() method of the action class is called. The following is a sample action entry for the doenterpagevariables action: In the above example, the doEnter() method of the com.atlassian.confluence.pages.actions.PageVariablesAction class handles requests to “doenterpagevariables.action” and will return values such as “success”, “input”, or “error”. This results in the appropriate Velocity template being rendered. Confluence supports the use of Object Graph Navigational Language (OGNL) expressions to dynamically generate web page content from Velocity templates using the Webwork library. OGNL is a dynamic Expression Language (EL) with terse syntax for getting and setting properties of Java objects, list projections, lambda expressions, etc. OGNL expressions contain strings combined to form a navigation chain. The strings can be property names, method calls, array indices, and so on. OGNL expressions are evaluated against the initial, or root context object supplied to the evaluator in the form of OGNL Context. Confluence uses a container object of class com.opensymphony.webwork.views.jsp.ui.template.TemplateRenderingContext to store objects needed to execute an Action. These objects include session identifiers, request parameters, spaceKey, etc. TemplateRenderingContext also contains a com.opensymphony.xwork.util.OgnlValueStack object to push and store objects against which dynamic Expression Languages (EL) are evaluated. When the EL compiler needs to resolve an expression, it searches down the stack starting with the latest object pushed into it. OGNL is the EL used by the Webwork library to render Velocity templates defined in Confluence, allowing access to Confluence objects exposed via the current context. For example, the action variable returns the current Webwork action object.

OGNL expressions in Velocity templates are parsed using the ognl.OgnlParser.expression() method. The expression is parsed into a series of tokens based on the input string. The ognl.JavaCharStream.readChar() method, called by the OGNL parser, evaluates Unicode escape characters in the form of “\uXXXX” where “XXXX” is the hexadecimal code of the Unicode character represented. Therefore, if an expression includes the character “\u0027”, the character is evaluated as a closing quote character ('), escaping the context of evaluation as a string literal, allowing to append an arbitrary OGNL expression. If an OGNL expression is parsed in a Velocity template within single quotes and the expression’s value is obtained from user input without any sanitization, an arbitrary OGNL expression can be injected.

An OGNL injection vulnerability exists in Atlassian Confluence. The vulnerability is due to insufficient validation of user input used to set variables evaluated in Velocity templates within single quotes. By including the “\u0027” character in user input, an attacker can escape the string literal and append an arbitrary OGNL expression.

Before OGNL expressions are evaluated by Webwork, they are compared against a list of unsafe node types, property names, method names, and variables names in the com.opensymphony.webwork.util.SafeExpressionUtil.containsUnsafeExpression() method. However, this list is not exhaustive, and arbitrary Java objects can be instantiated without using any of the unsafe elements listed. For example, the following expression, executing an OS command, would be accepted as a safe expression by this method:

A remote attacker can exploit this vulnerability by sending a crafted HTTP request containing a malicious parameter to a vulnerable server. Successful exploitation can result in the execution of arbitrary code with the privileges of the server.

Remote Detection of Generic Attacks

To detect this attack, you should monitor all HTTP traffic requests where the path component of the request-URI contains one of the strings in the “URI path” column of the following table:

If such a request is found, you should inspect the HTTP request method. If the request method is POST, look for the respective vulnerable parameters from the table above in the body of the HTTP request, and if the request method is GET, you should look for the parameters in the request-URI of the HTTP request. Check to see if the value of any of the vulnerable parameters contains the string "\u0027" or its URL-encoded form. If so, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway.

Conclusion

Atlassian patched this vulnerability on August 25, 2021. Since the initial publication of their advisory, they have updated it multiple times to note the active attacks and to add clarification on how customers can identify if they are using Confluence Cloud. They do list some mitigations, but considering how widespread this bug is currently being exploited, the best course of action is to apply the patch and enhance system monitoring.

Special thanks to Guy Lederfein and Yazhi Wang of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

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

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

6 October 2021 at 16:30

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

Before this patch being made available, this vulnerability could be used by an authenticated user to execute arbitrary .NET code on the server in the context and permissions of service account of SharePoint web application. For successful attack, the attacker should have “Manage Lists” permissions on any SharePoint site. By default, any authenticated user can create their own site where they have the necessary permissions.

The Vulnerability

SharePoint workflows are pre-programmed mini-applications that streamline and automate a wide variety of business processes. An organization can use workflows to attach business logic to documents or items in a SharePoint list or library.

For security purposes, Workflow Foundation (WF) on SharePoint runs workflows only when all dependent types and assemblies are authorized in the authorizedTypes list in the web.config file. Along with allowed types, this list also contains items that block specific types from allowed namespaces that are considered dangerous. One example is System.Workflow.ComponentModel.Compiler. The Compile() method offered by WorkflowCompiler compiles a workflow based on parameters. Workflows in SharePoint are normally compiled in very restricted context (no code, types restricted by the authorizedTypes list, etc.), but invoking WorkflowCompiler would allow attackers to create a new context without these restrictions by specifying appropriate parameters. Because of this, WorkflowCompiler is blocked by the authorizedTypes list in web.config:

Therefore, we cannot mount an attack using WorkflowCompiler type. However, examining the .NET code of WorkflowCompiler.Compile reveals something interesting:

From here we see that the bulk of the implementation of WorkflowCompiler.Compile resides a different class named WorkflowCompilerInternal. This class is not blocked by authorizedTypes list. Furthermore, since it is found within the System.Workflow namespace, it is allowed by the line:

Therefore, we can compile an arbitrary workflow by invoking the WorkflowCompilerInternal type directly.

For arbitrary code execution, we can use the following XOML file (Attck.xoml). When compiled, it will execute the desired .NET commands, provided that the noCode flag is not specified:

Here is the .rules file (WF02.rules) of a SharePoint workflow that invokes the WorkflowCompilerInternal.Compile to compile an arbitrary XOML workflow definition, provided that the XOML file can be retrieved from an SMB share:

This rule will be triggered by the following lines from the XOML file of our SharePoint workflow (WF02.xoml):

An attacker could store Attck.xoml in a shared SMB folder controlled by the attacker and upload the WF02.xoml and WF02.rules files to a location on the SharePoint site, for example, to the Documents folder. Also, the attacker would need a workflow configuration file (WF02config.xml) that points to the uploaded XOML and rules files, and associates them with the ListID of a list in the site where the attacker can add new items:

An attacker would need to associate this new workflow with the SharePoint list. This can be done by using the AssociateWorkflowMarkup method from the WebPartPages WebService (/_vti_bin/WebPartPages.asmx) and providing the relative path to the uploaded config file.

To trigger workflow execution, the attacker adds a new item to the target SharePoint list.

Proof of Concept

For this demonstration, we use Microsoft SharePoint Server 2019 installed with all default options on Windows Server 2019 Datacenter. The server’s computer name is sp2019.contoso.lab and it is a member of the contoso.lab domain. The domain controller is a separate virtual machine. It has been updated to the February 2021 patch level (version 16.0.10371.20043) and a couple of users have been added, including “user2” as a regular, unprivileged user.

On the attacker side, we need:
-- an SMB server hosting the Attck.xoml file containing the .NET code we want to execute. It must be hosted on a share that can be accessed by the SharePoint server
-- our PoC application for sending SOAP requests to the server (SP_soap_RCE_PoC.exe) that calls the AssociateWorkflowMarkup method of the WebPartPages web service
-- the workflow config file, WF02config.xml
-- The XOML and .rules files referenced by the workflow config file
-- any supported web browser. For this demonstration, we are using Firefox.

Achieving Remote Code Execution

Let’s visit our SharePoint Server and authenticate as a regular user. In my case it is user2:

Before our attack, we need to prepare a few things. We could try to do this with current user sites, but if possible, we recommend creating a new site so that we will be the owner and have all permissions.

Click on “SharePoint” on the top panel:

Now click the “+ Create site” link:

Choose Team Site.

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

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

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

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

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

And click “Create”:

We will need the ListID of this new list. Let’s go back to the “Site contents” page and click on “Settings” in the dropdown menu for our new list:

We will be redirected to the listedit.aspx page:

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

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

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

Now we need to upload the Attck.xoml file, containing the .NET code we want to run, into an SMB folder that is accessible from the SharePoint server.

We should place the remote path to the Attck.xoml file into WF02.rules:

Save changes in both files (WF02config.txt and WF02.rules) and upload them together with the WF02.xoml file to the Documents folder of our SharePoint site:

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

There is no PoC_SPRCE02.txt file yet.

For our attack, we will use the SP_soap_RCE_PoC.exe application. We need to provide the following information:

— BaseUrl of the target SharePoint Site (in this case http://sp2019/sites/testsiteofuser2/)
UserName (in this case user2
— Domain

Relative path to the workflow config file on our site - "Shared Documents/WF02config.txt"

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

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

Click on the “Save” button there.

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

The file PoC_SPRCE02.txt has been created, demonstrating the success of our code execution. In this manner, our attacker can execute arbitrary OS commands in the context of the SharePoint web application account.

To run additional OS commands, we would need to place them into Attck.xoml file in the shared folder and create another new item in NewList.

Conclusion

Microsoft patched this in June and assigned identifier CVE-2021-26420, with a CVSS score of 7.1. While the inclusion of an attacker-controlled SMB server adds a level of complexity, this bug can still be used for code execution in many scenarios. Since SharePoint is generally considered an attractive target for attackers, it would not be surprising if this bug were to be found in the wild. SharePoint continues to be an attractive target for security researchers, and many SharePoint-related disclosures are currently in our Upcoming queue. Stay tuned to this blog for details about those bugs once they are disclosed.

Until then, follow the team for the latest in exploit techniques and security patches.

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

# The October 2021 Security Update Review

12 October 2021 at 17:28

The second Tuesday of the month is here, and that means the latest security updates from Adobe and Microsoft have arrived. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for October 2021

For October, Adobe released six patches covering 10 CVEs in Adobe Reader, Acrobat Reader for Android, Adobe Campaign Standard, Commerce, Ops-CLI, and Adobe Connect. The update for Adobe Acrobat fixes four bugs in total – two rated Critical and two rated Moderate in severity. Two of these bugs were submitted through the ZDI program. The Critical-rated bugs could allow remote code execution while the Moderate-rated bugs could allow a privilege escalation. The update for Reader for Android fixes a single path traversal bug that could lead to code execution. All require some form of user interaction, such as browsing to a web page or opening a PDF.

Several cross-site scripting (XSS) bugs receive patches this month. The patch for Campaign Standard fixes a DOM-based XSS. The fix for Adobe Commerce addresses a stored XSS. The patch for Adobe Connect fixes two bugs, one of which is a reflective XSS. The other bug is more a more severe Critical-rated deserialization vulnerability that could allow remote code execution. The final Adobe patch for October fixes a Critical-rated deserialization bug in Ops-CLI, which is a python wrapper for Terraform, Ansible, and SSH for cloud automation.

None of the bugs fixed this month by Adobe are listed as publicly known or under active attack at the time of release.

Microsoft Patches for October 2021

For October, Microsoft released patches today for 71 new CVEs in Microsoft Windows and Windows Components, Microsoft Edge (Chromium-based), Exchange Server, .NET Core and Visual Studio, Microsoft Office Services and Web Apps, SharePoint Server, Microsoft Dynamics, InTune, and System Center Operations Manager. This is in addition to the eight CVEs patched by Microsoft Edge (Chromium-based) earlier this month and three previously released OpenSSL patches, which brings the October total to 82 CVEs – slightly down from last month. A total of 11 of these bugs were submitted through the ZDI program.

Of the 71 CVEs patched today, two are rated Critical, 68 are rated Important, and one is rated Low in severity. Three of today’s patches are listed as publicly known, while one is listed as being under active attack at the time of release. This is in addition to two of the Chromium bugs that were listed as under active attack when Chrome patched on September 30. For those wondering, this month does include patches for the recently released Windows 11 operating system.

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

-       CVE-2021-40449 - Win32k Elevation of Privilege Vulnerability
This patch corrected a kernel bug that could be used to escalate privileges on an affected system. Attackers typically use these types of bugs in conjunction with code execution bugs to take over a system. Considering the source of this report, this bug is likely being used in a targeted malware attack. We will also likely see more information about this bug and the associated attack within the next few days.

-       CVE-2021-26427 - Microsoft Exchange Server Remote Code Execution Vulnerability
The bug will certainly receive its fair share of attention, if nothing else, due to it being reported by the National Security Agency (NSA). Due to the similar CVE numbers, this bug was likely reported when they reported the more severe Exchange issues back in April. This bug is not as severe since this exploit is limited at the protocol level to a logically adjacent topology and not reachable from the Internet. This flaw, combined with the other Exchange bugs patched this month, should keep Exchange admins busy for a while.

-       CVE-2021-40486 - Microsoft Word Remote Code Execution Vulnerability
This patch corrects a bug that would allow code execution when a specially crafted Word document is viewed on an affected system. Although Microsoft lists user interaction required, the Preview Pane is also listed as an attack vector. This creates a much larger attack surface. When combined with a privilege escalation – like the one currently under active attack – this could be used to take over a target system. This bug came through the ZDI program and results from the lack of validating the existence of an object before performing operations on the object.

-       CVE-2021-40454 - Rich Text Edit Control Information Disclosure Vulnerability
We don’t often highlight information disclosure bugs, but this vulnerability goes beyond just dumping random memory locations. This bug could allow an attacker to recover cleartext passwords from memory, even on Windows 11. It’s not clear how an attacker would abuse this bug, but if you are using the rich text edit control in Power Apps, definitely test and deploy this bug quickly.

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

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

* Indicates this CVE had previously been released by a 3rd-party and is now being incorporated into Microsoft products.

The remaining Critical-rated bugs fix remote code execution vulnerabilities in Hyper-V server. One of these bugs could allow a guest OS to execute code on the host OS if the guest can cause a memory allocation error within the guest VM. Microsoft provides no details on the other bug, but it could also be used for a guest-to-host escape.

Looking at the remaining 18 code execution bugs, most are within the Office family and require a user to open a specially crafted file. One notable exception is a remote code execution bug in the DNS server. No user interaction is required to exploit this bug, but it does require high privileges, knocking this from Critical rated to Important. Microsoft lists this as publicly known but doesn’t state where which is frustrating. Knowing how widespread the knowledge of this vulnerability could benefit network defenders in creating a true risk assessment for their enterprise. There are also a couple of SharePoint code execution bugs receiving patches, but both require local privileges to exploit. These bugs came through the ZDI program, and we’ll have more details about them in the future. Another interesting RCE bug impacts the MSHTML platform. Although Internet Explorer is now “retired”, it lives on as the underlying MSHTML, EdgeHTML, and scripting platforms are still supported. There are even patches here for Windows 11. The legacy of IE hasn’t quite left us after all.

Moving on to the privilege escalation bugs, most require an attacker to log on to a system and run their own code to take advantage of an affected component. There’s another kernel bug here, and it is listed as publicly known – again with no additional information or details on the public disclosure. There’s also a privilege escalation in Exchange that also requires the attacker to be on an adjacent network. No user interaction is listed, so the likely scenario would be an insider threat.

There are five security feature bypass (SFB) bugs patched in this month’s release. The first is a vulnerability in RPC Runtime that could allow an attacker to bypass Extended Protection for Authentication provided by Service Principal Name (SPN) target name validation. A different bug in the Windows active directory could allow an attacker to bypass the Active Directory Federation Services (AD FS) BannedIPList entries for WS-Trust workflows. A different Active Directory bug could allow an attacker to bypass Active Directory domain permissions for Key Admins groups. The bypass in Intune requires the Intune Management Extension to be installed, but Microsoft provides no further details on what is being bypassed. Microsoft provides no details on what security feature is being bypassed on either the console Windows host or the Windows AppContainer Firewall. The lack of details around the container firewall vulnerability is especially frustrating since Microsoft lists this bug as publicly known.

The October release contains fixes for three new Denial-of-Service (DoS) bugs, each of which is significant. The first patch fixes a DoS vulnerability in TCP/IP that impacts all supported versions of Windows – including Windows 11. It’s not clear if this would allow an attacker to completely shut down a system, but without further details from Microsoft, network defenders should assume this worst-case scenario is likely. There’s a DoS bug in Exchange Server, and again, details are scarce. Since the CVSS score lists Availability=High, assume an attacker can abuse this bug to shut down an Exchange server. The final DoS bug getting fixed this month impacts Windows Network Address Translation (NAT) and was discovered by the same researchers that found the TCP/IP bug. Again, the CVSS score indicates this vulnerability could be used to take down a system, so test and deploy these patches quickly.

In addition to the one previously mentioned, there are 13 information disclosure bugs receiving fixes in this month’s release. Most of these simply result in leaks consisting of unspecified memory contents. However, if you’re running the web console of the System Center Operations Manager (SCOM), you definitely want to pay attention to the bug that could disclose file content on an affected system.

The October release is rounded out by fixes for six spoofing bugs and two cross-site scripting (XSS) bugs. Microsoft provides no details on what may be spoofed for any of these vulnerabilities, but the ones for Print Spooler and Exchange stand out. There are only a couple of print spooler bugs in this month’s release, so perhaps the days of PrintNightmare are finally behind us. The only clue we have for the impact of the Exchange spoofing bug is the CVSS rating of Confidentiality=High. This implies a total loss of confidentiality, which is not something you want to be associated with your Exchange server. The remaining spoofing bugs read very close to XSS bugs, including the rare Low severity fix for SharePoint Server.

No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV90001.

The next Patch Tuesday falls on November 9, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The October 2021 Security Update Review

# Adding a Beta NAS Device to Pwn2Own Austin

14 October 2021 at 20:26

Today, we are announcing the inclusion of the beta version of the Western Digital 3TB My Cloud Home Personal Cloud in our upcoming Pwn2Own Austin competition. Normally, devices under test are updated to the most recent publicly available patch level. This is still the case. However, our partners over at Western Digital wanted to include their upcoming beta software release in this year’s event. Consequently, we are adding the beta version as an available target in addition to the existing current version of the NAS device.

If a contestant can get code execution on the beta release of the Western Digital 3TB My Cloud Home Personal Cloud, they will earn $45,000 (USD) and 5 Master of Pwn points. There are some significant differences between the released software version and the beta version, so we suggest contestants upgrade their systems to test their exploits prior to the contest. To get the beta version installed on your NAS, you will need to enter your email address and the MAC address of your device in this form. Within a few hours, an automated process to update the NAS will begin. The updates will take you from 7.15.1-101 (current) to 7.16.0-216 and then the beta 8.0.0-301. Please note that not all features and applications included in the current version of the software release are available in the beta version. Again, registration for the contest closes at 5:00 p.m. Eastern Daylight Time on October 29, 2021. A full copy of the rules – including this new change – is available here. They may be changed at any time without notice. We highly encourage potential entrants to read the rules thoroughly and completely should they choose to participate. If you have any questions, please forward them to [email protected]. We believe exploiting the beta version of this software will not be trivial, but we certainly hope some tries. We look forward to seeing all the attempts to learn about the latest exploits and attack techniques on these devices. Good luck, and we’ll see you in Austin. Adding a Beta NAS Device to Pwn2Own Austin # CVE-2021-28632 & CVE-2021-39840: Bypassing Locks in Adobe Reader 21 October 2021 at 16:12 Over the past few months, Adobe has patched several remote code execution bugs in Adobe Acrobat and Reader that were reported by researcher Mark Vincent Yason (@MarkYason) through our program. Two of these bugs, in particular, CVE-2021-28632 and CVE-2021-39840, are related Use-After-Free bugs even though they were patched months apart. Mark has graciously provided this detailed write-up of these vulnerabilities and their root cause. This blog post describes two Adobe Reader use-after-free vulnerabilities that I submitted to ZDI: One from the June 2021 patch (CVE-2021-28632) and one from the September 2021 patch (CVE-2021-39840). An interesting aspect about these two bugs is that they are related – the first bug was discovered via fuzzing and the second bug was discovered by reverse engineering and then bypassing the patch for the first bug. CVE-2021-28632: Understanding Field Locks One early morning while doing my routine crash analysis, one Adobe Reader crash caught my attention: After a couple of hours minimizing and cleaning up the fuzzer-generated PDF file, the resulting simplified proof-of-concept (PoC) was as follows: PDF portion (important parts only): JavaScript portion: The crash involved a use-after-free of CPDField objects. CPDField objects are internal AcroForm.api C++ objects that represent text fields, button fields, etc. in interactive forms. In the PDF portion above, two CPDField objects are created to represent the two text fields named fieldParent and fieldChild. Note that the created objects have the type CTextField, a subclass of CPDField, which is used for text fields. To simplify the discussion, they will be referred to as CPDField objects. An important component for triggering the bug is that fieldChild should be a descendant of fieldParent by specifying it in the /Kids key of the fieldParent PDF object dictionary (see [A] above) as documented in the PDF file format specification: Another important concept relating to the bug is that to prevent a CPDField object from being freed while it is in use, an internal property named LockFieldProp is used. Internal properties of CPDField objects are stored via a C++ map member variable. If LockFieldProp is not zero, it means that the CPDField object is locked and can't be freed; if it is zero or is not set, it means that the CPDField object is unlocked and can be freed. Below is the visual representation of the two CPDField objects in the PoC before the field locking code (discussed later) is called: fieldParent is unlocked (LockFieldProp is 0) and is in green, and fieldChild is also unlocked (LockFieldProp is not set) and is also in green: On the JavaScript portion of the PoC, the code sets up a JavaScript callback so that when the “Format” event is triggered for fieldParent, a custom JavaScript function callback() will be executed [2]. The JavaScript code then triggers a “Format” event by setting the textSize property of fieldParent [3]. Internally, this executes the textSize property setter of JavaScript Field objects in AcroForm.api. One of the first actions of the textSize property setter in AcroForm.api is to call the following field locking code against fieldParent: The above code locks the CPDField object passed to it by setting its LockFieldProp property to 1 [AA]. After executing the field locking code, the lock state of fieldParent (locked: in red) and fieldChild (unlocked: in green) are as follows: Note that in the later versions of Adobe Reader, the value of LockFieldProp is a pointer to a counter instead of being set with the value 1 or 0. Next, the textSize property setter in AcroForm.api calls the following recursive CPDField method where the use-after-free occurs: On the first call to the above method, the this pointer points to the locked fieldParent CPDField object. Because it has no associated widget [aa], the method performs a recursive call [cc] with the this pointer pointing to each of fieldParent's children [bb]. Therefore, on the second call to the above method, the this pointer points to the fieldChild CPDField object, and since it has an associated widget (see [B] in the PDF portion of the PoC), a notification will be triggered [dd] that results in the custom JavaScript callback() function to be executed. As shown in the previous illustration, the locking code only locked fieldParent while fieldChild is left unlocked. Because fieldChild is unlocked, the removeField("fieldChild") call in the custom JavaScript callback() function (see [1] in the JavaScript portion of the PoC) succeeds in freeing the fieldChild CPDField object. This leads to the this pointer in the recursive method to become a dangling pointer after the call in [dd]. The dangling this pointer is later dereferenced resulting in the crash. This first vulnerability was patched in June 2021 by Adobe and assigned CVE-2021-28632. CVE-2021-39840: Reversing Patch and Bypassing Locks I was curious to see how Adobe patched CVE-2021-28632, so after the patch was released, I decided to look at the updated AcroForm.api. Upon reversing the updated field locking code, I noticed an addition of a call to a method that locks the passed field’s immediate descendants: With the added code, both fieldParent and fieldChild will be locked and the PoC for the first bug will fail in freeing fieldChild: While assessing the updated code and thinking, I arrived at a thought: since the locking code only additionally locks the immediate descendants of the field, what if the field has a non-immediate descendant?... a grandchild field! I quickly modified the PoC for CVE-2021-28632 to the following: PDF portion (important parts only): JavaScript portion: And then loaded the updated PoC in Adobe Reader under a debugger, hit go... and crash! The patch was bypassed, and Adobe Reader crashed at the same location in the previously discussed recursive method where the use-after-free originally occurred. Upon further analysis, I confirmed that the illustration below was the state of the field locks when the recursive method was called. Notice that fieldGrandChild is unlocked, and therefore, can be freed: The recursive CPDField method started with the this pointer pointing to fieldParent, and then called itself with the this pointer pointing to fieldChild, and then called itself again with the this pointer pointing to fieldGrandChild. Since fieldGrandChild has an attached widget, the JavaScript callback() function that frees fieldGrandChild was executed, effectively making the this pointer a dangling pointer. This second vulnerability was patched in September 2021 by Adobe and assigned CVE-2021-39840. Controlling Field Objects Control of the freed CPDField object is straightforward via JavaScript: after the CPDField object is freed via the removeField() call, the JavaScript code can spray the heap with similarly sized data or an object to replace the contents of the freed CPDField object. When I submitted my reports to ZDI, I included a second PoC that demonstrates full control of the CPDField object and then dereferences a controlled, virtual function table pointer: Conclusion Implementation of object trees, particularly those in applications where the objects can be controlled and destroyed arbitrarily, is prone to use-after-free vulnerabilities. For developers, special attention must be made to the implementation of object reference tracking and object locking. For vulnerability researchers, they represent opportunities for uncovering interesting vulnerabilities. Thanks again to Mark for providing this thorough write-up. He has contributed many bugs to the ZDI program over the last few years, and we certainly hope to see more submissions from him in the future. Until then, follow the team for the latest in exploit techniques and security patches. CVE-2021-28632 & CVE-2021-39840: Bypassing Locks in Adobe Reader # Our ICS-Themed Pwn2Own Contest Returns to Miami in 2022 25 October 2021 at 13:14 UPDATE: The S4 Conference has been rescheduled to April 19 through April 21. Consequently, the Pwn2Own Miami competition is also moving to these days. The new deadline for registration is April 14, 2022. We have also clarified the rules around participation as an individual, team, or company and expanded available security policies in the OPC UA Server category. For full details, see the rules. ¡Bienvenidos de nuevo a Miami! Our inaugural Pwn2Own Miami was held back in January 2020 at the S4 Conference, and we had a fantastic time as we awarded over$280,000 USD in cash and prizes for 24 unique 0-day vulnerabilities. At the time, we couldn’t wait to get back to South Beach for the next contest. Of course, the rest of 2020 happened, so those plans were put on hold. Today, we are excited to announce Pwn2Own Miami returns in person to S4 on January 25-27, 2022 April 19-21, 2022. As of now, we are planning on running the contest in Miami and hope to have contestants in the room with us. However, we know not everyone is ready to hit the road again, so we will also still allow remote participation.

This will be our first “hybrid” event with contestants participating locally (hopefully) and remotely. Even though we will be at the Fillmore, we realize not everyone can be there with us. If you have either travel restrictions or travel safety concerns, you can opt to compete remotely. You will still need to register before the contest registration deadline (January 21, 2022 April 14, 2022) and submit a detailed whitepaper completely explaining your exploit chain and instructions on how to run the entry. A member of the ZDI staff in Miami will run your exploit for you. All attempts will be filmed and available for viewing by the contestant and the vendor. As in the past, we will work with remote contestants to monitor the attempt in real-time via a phone call or video chat. Please note that since you are not in person, changes to exploits/scripts/etc. will not be possible, which could lower your chance of winning should something unexpected occur. Otherwise, the contest will run as we have in the past. We will have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there.

This contest is not possible without the participation and help from our partners within the ICS community, and we would like to especially thank Schneider Electric, OPC Foundation, Inductive Automation, and Triangle Microworks for their expertise and guidance. Their cooperation is essential in ensuring we have the right categories and targets to create a meaningful test of the security of these products and protocols. Pwn2Own Miami seeks to harden these platforms by revealing vulnerabilities and providing that research to the vendors. The goal is always to get these bugs fixed before they’re actively exploited by attackers. These vendors have been instrumental in making that goal a reality.

The 2022 edition of Pwn2Own Miami has four categories:

- Control Server
- OPC Unified Architecture (OPC UA) Server
- Data Gateway
- Human Machine Interface (HMI)

Control Server Category

The Control Server category covers server solutions that provide connectivity, monitoring, and control across disparate Programmable Logic Controller (PLC) and other field systems. An attacker who took over a control server could alter the process in any way they wanted and would only be limited by their engineering and automation skills. The targets in this category include the control servers from Iconics and Inductive Automation.

An attempt in this category must be launched against the target’s exposed network services from the contestant’s laptop within the contest network or by opening a file within the target on the contest laptop. The files that are eligible to be opened must be file types that are handled by default by the target application.  A successful entry in the category must result in arbitrary code execution.

OPC UA Server Category

The OPC Unified Architecture (UA) is a platform-independent, service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. OPC UA serves as the universal translator protocol in the ICS world. It is used by almost all ICS products to send data between disparate vendor systems. OPC UA was designed to be more secure than the previously used DCOM and is gaining in popularity. This category has four products: the Unified Automation C++ Demo Server, the OPC Foundation OPC UA .NET Standard, the Prosys OPC US SDK for Java, and the Softing Secure Integration Server.

A successful entry in the category must result either in a denial-of-service condition, arbitrary code execution or in a bypass of the trusted application check that occurs after the creation of a secure channel. These types of devices usually restrict who can connect, so bypassing the application check becomes a prime target for attackers.

Data Gateway Category

This category focuses on devices that connect other devices of varying protocols. There are two products in this category. The first is the Triangle Microworks SCADA Data Gateway product. Triangle Microworks makes the most widely used DNP3 protocol stack.  The other is the Kepware KEPServerEx server. KEPServerEX is an industry-leading connectivity platform that provides a single source of industrial automation data to multiple applications.

A successful entry in the category must result in arbitrary code execution.

Human Machine Interface (HMI)

If you’re familiar with ICS at all, you’ve likely heard of the Human Machine Interface (HMI) system. The HMI connects the operator of an ICS to the various hardware components of the ICS. Attackers that take over the HMI can also prevent the operator from seeing process issues in the ICS until it is too late. Our HMI category consists of the AVEVA Edge and the Schneider Electric EcoStruxure Operator Terminal Expert.

A successful entry in this category must result in arbitrary code execution.

Master of Pwn

No Pwn2Own contest would be complete without crowning a Master of Pwn, and Pwn2Own Miami is no exception. Earning the title results in a slick trophy and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2023, which includes a one-time bonus estimated at $25,000). For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it. If a contestant decides to withdraw from the registered attempt before the actual attempt, the Master of Pwn points for that attempt will be divided by 2 and deducted from the contestant's point total for the contest. Since Pwn2Own is now often a team competition, along with the initial deduction of points, the same number of Master of Pwn points will also be deducted from all contestant teams from the same company. The Complete Details The full set of rules for Pwn2Own Miami 2022 are available here. They may be changed at any time without notice. We encourage entrants to read the rules thoroughly and completely should they choose to participate. Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at [email protected] to begin the registration process. (Email only, please; queries via Twitter, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing to determine the contestant order. Again, this random drawing will not impact awards. Contest registration closes at 5:00 p.m. Eastern Standard Time on January 21st, 2022 April 14, 2022. The Results We’ll be live blogging and tweeting results throughout the competition. Be sure to keep an eye on the blog for the latest results. Follow us on Twitter at @thezdi and @trendmicro, and keep an eye on the #P2OMiami hashtag for continuing coverage. We look forward to seeing everyone again in Miami, and we look forward to seeing what new exploits and attack techniques they bring with them. Our ICS-Themed Pwn2Own Contest Returns to Miami in 2022 # Pwn2Own Austin 2021 - Schedule and Live Results 2 November 2021 at 01:53 Welcome to Pwn2Own Austin 2021! This year’s consumer-focused event is our largest ever with 58 total entries from 22 different contestants. As with all of our contests now, you can follow along live on YouTube and Twitch. With attempts going every 30 minutes, is should be an exciting few days. As always, we started the contest with a random drawing to determine the order of attempts. You can view the results here. Our schedule is so packed, we’ve extended to contest to a fourth day. The complete schedule for the contest is below (all times Eastern [GMT -4:00]). We will update this schedule with results as they become available. Note: All times subject to change - You can watch the event live here. Jump to Day Two Results; Day Three Results; Day Four Results Tuesday, November 2 For a quick review of Day One, check out our recap video here. 1000 - Sam Thomas (@_s_n_t) from team Pentest Limited (@pentestltd) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category SUCCESS - Sam used a three-bug chain that included an unsafe redirect and a command injection to get code execution on the Western Digital My Cloud Pro Series PR4100. This successful demonstration earns him$40,000 and 4 Master of Pwn points.

1030 - Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the WAN interface of the Cisco RV340 in the router category

SUCCESS - Bien Pham leveraged a logic error to compromise the WAN interface of the Cisco RV340 router. He earns $30,000 and 3 Master of Pwn points. 1100 - The Synacktiv (@Synacktiv) team targeting the Canon ImageCLASS MF644Cdw in the printer category SUCCESS - The Synacktiv team used a heap overflow to take over the Canon ImageCLASS printer and bring home the first Printer Category win in Pwn2Own history. They earn$20,000 and 2 points towards Master of Pwn.

1130 - trichimtrich and nyancat0131 targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi in the router category

SUCCESS - trichimtrich used an Out-Of-Bounds (OOB) Read to get a root shell via the LAN interface of the TP-Link AC1750 router. This earns him $5,000 and 1 point towards Master of Pwn. 1200 - The THEORI Team (@theori_io) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category SUCCESS - The THEORI team combined an OOB Read and a stack-based buffer overflow to take over the Western Digital My Cloud Pro Series PR4100 NAS device. They used a unique bug chain, so they earn the full$40,000 and 4 points towards Master of Pwn.

1230 - Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the LAN interface of the Cisco RV340 in the router category

SUCCESS - Bien Phamfrom Team Orca of Sea Security used a three-bug chain, including an auth bypass and a command injection, to take over the LAN interface of the Cisco RV340. This effor earns him $15,000 and 2 more Master of Pwn points. 1300 - Ken Gannon (@yogehi) of F-Secure Labs (@fsecurelabs) targeting the Samsung Galaxy S21 in the Mobile Phone category FAILURE - Unfortunately, Ken could not get his exploit to work within the time allotted. 1400 - Bugscale targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category COLLISION - The exploit chain used by Bugscale included known bugs. They still earn$20,000 and 2 Master of Pwn points.

1430 - Benjamin Grap (@blightzero), Hanno Heinrichs (@HeinrichsH), and Lukas Kupczyk (@___luks___) of CrowdStrike Intelligence targeting the LAN interface of the Cisco RV340 in the router category

COLLISION - The exploit chain used by the CrowdStrike team included some known bugs. They still earn $10,000 and 1.5 Master of Pwn points. 1500 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the Canon ImageCLASS MF644Cdw in the printer category SUCCESS - The DEVCORE team used a stack-based buffer overflow to take over the Canon ImageCLASS printer. This unique bug chain earned them$20,000 and 2 Master of Pwn points.

1530 - Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi Router in the router category

SUCCESS - Bien Pham finishes Day 1 by using an OOB Read bug to take control of the TP-Link AC1750 router via the LAN interface. This earns him another $5,000 and 1 Master of Pwn point. 1630 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the Sonos One Speaker in the home automation category SUCCESS - The DEVCORE team used an integer underflow to gain code execution on the Sonos One Speaker. They earn$60,000 and 6 points towards Master of Pwn.

1700 - Gaurav Baruah (@_gauravb_) targeting the WAN interface of the Cisco RV340 in the router category

COLLISION - A partial collision. One of the bugs used by Gaurav was previously known. He still $22,500 and 2.5 Master of Pwn points. 1730 - The THEORI Team (@theori_io) targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category SUCCESS - The THEORI Team used a stack-based buffer overflow to get code execution on the 3TB My Cloud Home Personal Cloud from WD. This earns them$40,000 and 4 Master of Pwn points, giving them a 1 day total of $80,000 and 8 points. 1800 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the HP Color LaserJet Pro MFP M283fdw in the printer category SUCCESS - The DEVCORE team used a stack-based buffer overflow to gain code execution on the HP Color LaserJet Pro. They earn another$20,000 and 2 Master of Pwn points, bringing their day 1 total to $100,000 and 10 Master of Pwn points. Due to time limitations and resource constraints, the following attempts will occur off the live stream during the evening. Results of these attempts will still be reported here and on Twitter. — trichimtrich and nyancat0131 targeting the LAN interface of the NETGEAR R6700v3 in the router category SUCCESS - trichimtrich leveraged an integer overflow to gain code execution via the LAN interface of the NETGEAR R6700v3 router. They win another$5,000 and 1 more point towards Master of Pwn.

— Flashback Team of Pedro Ribeiro (@pedrib1337) && Radek Domanski (@RabbitPro) targeting the WAN interface of the NETGEAR R6700v3 in the router category

FAILURE - Unfortunately, Team Flashback could not get their exploit to work within the time allotted.

— Bugscale targeting the LAN interface of the NETGEAR R6700v3 in the router category

SUCCESS - The Bugscale team combined an authorization bypass with a command injection bug to get code execution on the LAN interface of the NETGEAR router. They earn $5,000 and 1 Master of Pwn point. — crixer (@pwning_me), Axel Souchet (@0vercl0k), @chillbro4201, and friends from Mofoffensive Research Team targeting the LAN interface of the NETGEAR R6700v3 in the router category SUCCESS - The Mofoffensive Research Team combining a heap overflow and a stack-based buffer overflow to gain code execution on the LAN interface of the NETGEAR R6700 router. Their efforts earn$5,000 and 1 Master of Pwn point.

Wednesday, November 3

For a video overview of the Day Two results, see here.

1000 - NCC Group EDG (Alex Plaskett, Cedric Halbronn, Aaron Adams) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category

SUCCESS - The NCC Group leveraged a memory corruption bug three different ways (and overcame a timing issue) to get code execution on the Western Digital My Cloud Pro Series PR4100. They earn themselves $40,000 and 4 Master of Pwn points. 1030 - Flashback Team of Pedro Ribeiro (@pedrib1337) && Radek Domanski (@RabbitPro) targeting the WAN interface of the Cisco RV340 in the router category SUCCESS - The Flashback team of Pedro and Redek used an impressive stack-based buffer overflow to get code execution on the WAN interface of the Cisco RV340 router. They earn$30,000 and 3 Master of Pwn points.

1100 - Nicolas Devillers (@nikaiw), Jean-Romain Garnier, and Raphael Rigo (@_trou_) targeting the Canon ImageCLASS MF644Cdw in the printer category

SUCCESS - The team of Nicolas Devillers, Jean-Romain Garnier, and Raphael Rigo obtained code execution on the Canon ImageCLASS printer through a stack-based buffer overflow. This unique bug chain earns them $20,000 and 2 Master of Pwn points. 1130 - crixer (@pwning_me), Axel Souchet (@0vercl0k), @chillbro4201, and friends from Mofoffensive Research Team targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi Router in the router category FAILURE - Unfortunately, the Mofoffensive Team could not get his exploit to work within the time allotted. 1200 - The Synacktiv (@Synacktiv) team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category SUCCESS - The Synacktiv team leveraged a configuration error bug to get code execution on the PR411. They earn$40,000 and 4 Master of Pwn points.

1230 - Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab targeting the LAN interface of the Cisco RV340 in the router category

SUCCESS - Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab used 3 unique bugs, incuding an authorization bypass and a commange injection, to get code execution on the Cisco RV340 via the LAN interface. They earn $15,000 and 2 Master of Pwn points. 1300 - The STARLabs Team targeting the Samsung Galaxy S21 in the mobile phone category COLLISION - The exploit chain used by the STARLabs team included a bug known by the vendor. They still earn$25,000 and 2.5 Master of Pwn points.

1400 - The Synacktiv (@Synacktiv) team targeting the Sonos One Speaker in the home automation category

SUCCESS - The Synacktiv team used a stack-based buffer over to compromise the Sonos One speaker and play us a tune. They earn $60,000 and 6 Master of Pwn points. 1430 - trichimtrich and nyancat0131 targeting the WAN interface of the Cisco RV340 in the router category SUCCESS - trichmitrich used nearly all the time on the clock, but his command injection bug is unique. His takeover of the Cisco RV340 via the WAN interface earns him$30,000 and 3 Master of Pwn points.

1500 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category

COLLISION - The DEVCORE team successfully exploited the WD PR411, but the bugs they leveraged had been previously used in the competition. Their work still earns them $20,000 and 2 Master of Pwn points. 1530 - The STARLabs Team targeting the LAN interface of the TP-Link AC1750 Smart Wi-Fi Router in the router category COLLISION - The STARLabs team exploited the LAN interface of the TP-Link AC1750 router, but they used a known bug. This still nets them$2,500 and .5 Master of Pwn points.

1600 - The Synacktiv (@Synacktiv) team targeting the Lexmark MC3224i in the printer category

SUCCESS - The Synacktiv team combined three unique bugs, including an unprivileged access bug and a command injection bug, to get code execution on the Lexmark MC3224i printer. They earn $20,000 and 2 more Master of Pwn points. 1700 - The STARLabs Team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category COLLISION - The exploit chain used by Nguyễn Hoàng Thạch (hi_im_d4rkn3ss) of STARLabs team included bugs previously used in the contest. They still earn$20,000 and 2 Master of Pwn points.

1745 - The Synacktiv (@Synacktiv) team targeting the HP Color LaserJet Pro MFP M283fdw in the printer category

COLLISION - The exploit chain used by the Synacktiv team included a bug used earlier in the competition. They still earn $10,000 and 1 Master of Pwn point. Due to time limitations and resource constraints, the following attempts will occur off the live stream during the evening. Results of these attempts will still be reported here and on Twitter. Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category FAILURE - Unfortunately, the IoT Inspector Research team could not get their exploit to work within the time allotted. — The STARLabs Team targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category COLLISION - The exploit chain used by Nguyễn Hoàng Thạch (hi_im_d4rkn3ss) and Phan Thanh Duy (PTDuy) of STARLabs took over the 3TB My Cloud Home Personal Cloud from WD using a bug previously seen in the competition. They still earn$20,000 and 2 Master of Pwn points.

— Diffense Team targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category

COLLISION - In their Pwn2Own debut, the Diffense Team runs into a collision. They were able to exploit the Western Digital My Cloud Pro Series PR4100, but the bug they leveraged was also used on Day 1. They still earn $20,000 and two Master of Pwn points in their debut effort. — Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the Lexmark MC3224i in the printer category SUCCESS - The DEVCORE team used a code injection bug to take over the Lexmark MC3224i printer. This unique bug chain earned them$20,000 and 2 Master of Pwn points.

— NCC Group EDG (Alex Plaskett, Cedric Halbronn, Aaron Adams) targeting the Lexmark MC3224i in the printer category in the printer category

SUCCESS - The NCC Group again needed multiple attempts, but they successfully exploited the Lexmark MC3224i with a file write bug. The earn $20,000 and 2 Master of Pwn points. — Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the WAN interface of the NETGEAR R6700v3 in the router category FAILURE - Unfortunately, Bien could not get his exploit to work within the time allotted. — Bien Pham (@bienpnn) from Team Orca of Sea Security (security.sea.com) targeting the LAN interface of the NETGEAR R6700v3 in the router category COLLISION - The two-bug exploit chain used by Bien included bugs used earlier in the competition. He still earn$2,500 and .5 Master of Pwn points.

— Q. Kaiser & T. Shiomitsu from IoT Inspector Research Lab targeting the WAN interface of the NETGEAR R6700v3 in the router category

FAILURE - Unfortunately, the IoT Inspector Research team could not get their exploit to work within the time allotted.

— Diffense Team targeting the LAN interface of the NETGEAR R6700v3 in the router category

FAILURE - Unfortunately, the Diffense Team could not get their exploit to work within the time allotted.

Thursday, November 4

For a quick overview of Day Three results, see the recap video here.

1000 - Martin Rakhmanov (@mrakhmanov) targeting the Western Digital My Cloud Pro Series PR4100 in the NAS category

SUCCESS - Martin used a unique two-bug chain that included a command injection to compormise the NAS device. He earns himself $40,000 and 4 points towards Master of Pwn. 1030 - The Synacktiv (@Synacktiv) team targeting the LAN interface of the Cisco RV340 in the router category COLLISION - The three-bug exploit chain used by the Synacktiv team included some known bugs. They still earn$7,500 and 1 Master of Pwn points.

1100 - Alexander Bolshev (@dark_k3y), Timo Hirvonen (@TimoHirvonen), and Dmitry Janushkevich (@InfoSecDJ) of F-Secure Labs (@fsecurelabs) targeting the HP Color LaserJet Pro MFP M283fdw in the printer category

SUCCESS - The team from F-Secure Labs used a single stack-based buffer overflow to take over the printer and turn it into a jukebox. They earn $20,000 and 2 Master of Pwn points. 1200 - The STARLabs Team targeting the beta version of the 3TB My Cloud Home Personal Cloud from WD in the NAS category SUCCESS - The STARLabs team of Nguyễn Hoàng Thạch (@hi_im_d4rkn3ss) and Billy Jheng Bing-Jhong (@st424204) combined an OOB Read and a heap-based buffer overflow to exploit the beta version of the 3TB My Cloud Home Personal Cloud from WD. They earn$45,000 and 5 Master of Pwn points.

1230 - Stephen Fewer (@stephenfewer) of Relyze Software Limited (www.relyze.com) targeting the LAN interface of the Cisco RV340 in the router category

COLLISION - The four-bug exploit chain used by the Stephen included some known bugs. His successful demonstration still earns him $10,000 and 1.5 Master of Pwn points. 1300 - Sam Thomas (@_s_n_t) from team Pentest Limited (@pentestltd) targeting the Samsung Galaxy S21 in the mobile phone category SUCCESS - Sam used a three-bug chain to get code execution on the Sumsung Galaxt S21. This successful demonstration earns him$50,000 and 5 Master of Pwn points.

1400 - The Synacktiv (@Synacktiv) team targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category

COLLISION - The Synacktiv team used a two-bug chain to compromise the 3TB My Cloud Home Personal Cloud, but one of the bugs had been used prior in the contest. Their demonstration still earns them $20,000 and 2 Master of Pwn points. 1500 - Chris Anastasio (@mufinnnnnnn) targeting the Lexmark MC3224i in the printer category COLLISION - Chris used a four-bug chain to compromise the Lexmark printer, but one of the bugs had been used prior in the contest. His efforts still earns him$17,500 and 1.75 Master of Pwn points.

1600 - The STARLabs Team targeting the LAN interface of the NETGEAR R6700v3 in the router category

FAILURE - Unfortunately, the STARLabs Team could not get their exploit to work within the time allotted.

1700 - Stephen Fewer (@stephenfewer) of Relyze Software Limited (www.relyze.com) targeting the LAN interface of the NETGEAR R6700v3 in the router category

SUCCESS - Stephen used an uninitialized variable to get a root shell via the LAN interface of the NETGEAR R6700v3 router. He earns $5,000 and 1 Master of Pwn point. Due to time limitations and resource constraints, the following attempts will occur off the live stream during the evening. Results of these attempts will still be reported here and on Twitter. The Synacktiv (@Synacktiv) team targeting the WAN interface of the NETGEAR R6700v3 in the router category SUCCESS - The Synactiv team used an improper certificate validation and a stack-based buffer overflow to compromise the NETGEAR router via the WAN interface. They earn$20,000 and 2 critical Master of Pwn points.

— Flashback Team of Pedro Ribeiro (@pedrib1337) && Radek Domanski (@RabbitPro) targeting the LAN interface of the NETGEAR R6700v3 in the router category

COLLISION - Pedro and Radek leveraged 2 bugs to exploit the NETGEAR R6700 router via the LAN interface, but the path traversal they chose was an N-day. This still earns them $3,750 and .75 Master of Pwn points. Friday, November 5 For a quick overview of Day Four results, see the recap video here. 1000 - Orange Tsai (@orange_8361), Angelboy (@scwuaptx) and Meh Chang (@mehqq_) from the DEVCORE Research Team targeting the 3TB My Cloud Home Personal Cloud from WD in the NAS category SUCCESS - The DEVCORE team combined an OOB Read and an OOB Write to sucessfully exploit the 3TB My Cloud Home Personal Cloud from WD. This unique bug chain earned them$40,000 and 4 Master of Pwn points.

1030 - Diffense Team targeting the LAN interface of the Cisco RV340 in the router category

COLLISION - The Diffense Team leveraged 4 bugs to exploit the Cisco RV340 router via the LAN interface, but some of the bugs had been seen earlier in the conference. This still earns them $10,000 and 1.5 Master of Pwn points. 1100 - Benjamin Grap (@blightzero), Hanno Heinrichs (@HeinrichsH), and Lukas Kupczyk (@___luks___) of CrowdStrike Intelligence targeting the Lexmark MC3224i in the printer category COLLISION - The team from CrowdStrike had no problem taking over the Lexmark printer using a three-bug chain, however all of the bused used had been seen earlier in the contest. Their effort wins them$10,000 and 1 Masrer of Pwn point.

1200 - The NullRiver team of Xin’an Zhou, Xiaochen Zou, Zhiyun Qian targeting the LAN interface of the NETGEAR R6700v3 in the router category

At our Pwn2Own Vancouver contest this year, the web browser category included the Google Chrome and Microsoft Edge (Chromium) browsers as targets. For this year’s event, a successful demonstration no longer required a sandbox escape. There was also a special bonus for exploits that worked against both Chrome and Edge. On Day Two of the event, Bruno Keith and Niklas Baumstark successfully demonstrated their V8 JIT vulnerability on both the Chrome and Microsoft Edge renderers with a single exploit. This earned them $100,000 USD and 10 Master of Pwn points. In this blog series, we’ll be covering this exploit in three separate entries: 1 - Two Birds with One Stone: An Introduction to V8 and JIT Exploitation 2 - Understanding the Root Cause of CVE-2021-21220 – A Chrome Bug from Pwn2Own 2021 3 - Exploitation of CVE-2021-21220 – From Pwn2Own to Active Exploit We’ll begin with the basics of V8 and JIT exploitation. Gathering Information This vulnerability has been addressed by Google. More information about the bug can be found on the ZDI advisory page as ZDI-21-411, where there is a link to the Google fix: This provides us with the Chromium bug entry amongst other details. There are some details provided by the researchers and the actual exploit tested on Chrome 89.0.4389.114 and Edge version 89.0.774.63 (which we will cover in-depth in the final blog in this series). You can see the developers fixed this issue in a commit by making changes in just one file. There is also a proof of concept (PoC) for us to review. Great! Now that we have a PoC, we can have a deeper look at the vulnerability, but we need to set up our analysis environment first. Setting Up the Environment It was possible to exploit both the Google Chrome and Microsoft Edge (Chromium) renderer processes with one exploit since both are using V8 as the JavaScript and WebAssembly engine. V8 is developed by Google in C++ and runs on Windows 7 or later, macOS 10.12 and newer, and Linux systems that use x64, IA-32, ARM, or MIPS processors. V8 is an open-source project. This means you can compile it from the source code. Usually, it is easier to compile such projects on Linux. Thus, I am going to use Ubuntu 18.04.5 to compile V8 (see below): You can use any other supported operating system you want. The official build document is pretty good and provides abundant detail. To begin, we need to install a package of scripts called depot_tools to manage checkouts and other tasks: We then add “depot_tools” path to the list of available paths: It is now time to download the V8 source code, which may take a while based on your internet speed. After the download is complete, there will be a new folder called v8. You will need to navigate to this directory to make it the working directory: This gives us the latest version of V8. However, for this blog series, we need the vulnerable version of V8. We need to first find the affected version of Google Chrome which was available in the Chromium bug entry: 89.0.4389.114. Cool. Now that we have an affected version of Google Chrome, we can look up information about that version in a service called omahaproxy. Just enter 89.0.4389.114 in the lookup field and press enter: It gives us some information, including the affected V8 commit: Now that we have the affected V8 commit, we can checkout that version. You may want to take a snapshot of the latest version of V8 first: Now it is time to build V8. You can have a release or a debug build. A release build will give you a clean, optimized build that is faster but provides fewer details when running commands. A debug build is an unoptimized, slower build. However, it provides a lot of debug information that can help us to understand this vulnerability. Thus, we are going to choose the debug build: If all went well, there will be an executable called “d8” in the “out/x64.debug” directory: You should see this: V8 is an astonishing piece of engineering that has tons of documentation and details. We can’t go too much into all these details of course, but some concepts need to be covered as they are relevant to this blog series. Like many other Linux executables, you can pass “--help” to the compiled “d8” to provide you with a long list of all supported options. For this blog post, we are interested in just two of them: 1 - allow_natives_syntax: By adding this as an argument when running d8, you can access special runtime functions that can be called from JavaScript using the % prefix. To find all supported runtime functions, just go to the “src/runtime” directory and grep for the string “RUNTIME_FUNCTION”. We are just interested in two of them, both of which are available in the “src/runtime/runtime-test.cc” file: PrepareFunctionForOptimization: Prepares a specified JavaScript function for JIT optimization. As we will explain below, JIT optimization has certain prerequisites: the function being optimized must first have been translated to bytecodes, and the engine must have collected data regarding runtime type informtion.. OptimizeFunctionOnNextCall: This function marks the target function so that the JIT engine will compile the function into an optimized form immediately before the next execution of the target function. We will detail how these two are used in our next blog. If you do not want to use these two runtime functions, it is usually enough to call the target function many times in a loop. 2 - trace-turbo-graph: This argument can be used to trace the generated graph (see below) when it goes through various optimizations. We will see this in action in the second blog. When the V8 engine loads a JavaScript file, it parses the input and builds an Abstract Syntax Tree (AST). The V8 engine interpreter called “Ignition” generates bytecode from this syntax tree. Check the header file “bytecodes.h” (located inside the “src/interpreter” directory) for a complete list of V8 bytecodes. These bytecodes are then executed (interpreted) by Ignition handlers (check src/interpreter/interpreter-generator.cc). The interpreter has little to do with our vulnerability and thus we do not discuss it any further. There are lots of resources available if you want to study this topic more. If a function is called many times, or optimization is explicitly requested using runtime functions as described above, the V8 engine will optimize (compile) that function. Optimization is heavily dependent upon information that the engine has previously collected during interpreted executions of the function, especially concerning the data types found in variables. Note that variables in JavaScript are not strongly typed, and to achieve meaningful optimizations, the engine needs to speculate that the types that were encountered in variables during interpreted execution will usually be the same as the types encountered in the future. The optimizing compiler’s first step is to convert the bytecode into an intermediate representation, which has the form of a graph. This step is performed in PipelineImpl::CreateGraph, found within src/compiler/pipeline.cc: As you can see, the graph creation has 3 main phases: 1 - GraphBuilderPhase: A graph is generated by visiting bytecodes previously generated. 2 - InliningPhase: An initial attempt is made to optimize the generated graph by eliminating dead code, reducing calls, inlining, etc. 3 - EarlyGraphTrimmingPhase: This phase removes dead->live edges from the graph. More sophisticated optimizations are performed by PipelineImpl::OptimizeGraph, found in src/compiler/pipeline.cc: Discussing all the optimizations implemented by V8 is out of scope for this blog series. Instead, we’ll just cover some of the ones we will see in the second blog in this series: 1 - Typer: The nodes in the graph will get a type which covers possible values of that node. For example, a variable that has values like false or true is typed as a Boolean. As another example, a numeric value that is known to always equal 1 will have a type of range(1, 1). 2 - Simplified lowering: Some operations are lowered (reduced) to a simplified series of nodes. The example below shows how the Math.abs operation is lowered: 3 - Early Optimization: Various optimizations are done in this stage, which is clear when looking at the EarlyOptimizationPhase struct: As you can see, further optimizations are done in this phase including dead code elimination, redundancy elimination, and something called the MachineOperatorReducer. In the next blog, we will detail how the MachineOperatorReducer plays a major role in this vulnerability. After all optimizations are completed on the graph, the compiler translates the graph to assembler. All future calls to the optimized function will invoke the assembly version and not the interpreted (bytecode) version. As explained above, though, optimization is performed using speculated assumptions. As a result, the assembly version of the function must contain guards to detect all possible situations where an assumption has been violated. In that circumstance, the assembly version falls back to the interpreter again. This is known as a “bailout”. This way the V8 engine can run any (optimized) function much faster. Please note this blog is a simplification of the process, and the whole procedure is much more complex. The V8 turbofan documentation is a good starting point if you want to explore it any further. Conclusion of Part One In this blog, we set up the V8 environment and played a bit with some of its features. In the next blog, we will analyze the vulnerability used at Pwn2Own. Expect to see that blog in just two days from now. Until then, you can find me on Twitter at @hosselot and follow the team for the latest in exploit techniques and security patches. Two Birds with One Stone: An Introduction to V8 and JIT Exploitation # Understanding the Root Cause of CVE-2021-21220 – A Chrome Bug from Pwn2Own 2021 9 December 2021 at 16:59 In this second blog in the series, ZDI Vulnerability Researcher Hossein Lotfi looks at the root cause of CVE-2021-21220. This bug was used by Bruno Keith (@bkth_) and Niklas Baumstark (@_niklasb) of Dataflow Security (@dfsec_com) during Pwn2Own Vancouver 2021 to exploit both Chrome and Edge (Chromium) to earn$100,000 at the event. Today’s blog starts with a look at how to trigger the vulnerability and goes on to describe why the bug occurs.

I begin Part 2 of this blog series with a discussion of how to trigger the vulnerability. For clarity, I modified the PoC slightly and came up with the following:

I covered lines 3 through 5 in our first blog. Lines 4 and 6 simply use “console.log” to print data. Let’s see what happens in the first and second line:

Line 1: Constructs a Uint32Array (a typed array that can hold 32-bit unsigned integers). The array contains just one element, having the value 231 (2,147,483,648 in decimal or 0x80000000 in hex). The array is assigned to variable arr.

Line 2: A function called “foo” will take the first element of arr (which is 231), XOR it with a constant integer 0, add a constant integer 1, and return the result.

There are some interesting points in these two lines:

1 - 0x80000000 has its most significant bit set. This is known as the sign bit when handling signed integers.
2 - XORing any value with zero will return the original value unchanged. If this XOR does not have any effect, then why was it necessary to include it? We will answer this soon.

Save this PoC as “poc.js” and run it with the following command:

\$ ./d8 --allow_natives_syntax '/home/lab/Desktop/poc.js'

It should print the following output:

Interesting! Results of the interpreted and JITted versions are different, which should not happen. JIT supposed to speed up the function but should never change the results.

Now that we are here, let’s have a look at the patch as it may give us some hints as to why this is happening:

The only change is inside the function InstructionSelector::VisitChangeInt32ToInt64, found within the file src/compiler/backend/x64/instruction-selector-x64.cc. There is also a nice comment, which can provide us an educated guess. As mentioned in the first blog, a JITted function will be compiled to assembly to achieve maximum speed. Before the patch, on the x64 platform, if there was a load of a signed int32 into a 64-bit register, the kX64Movsxlq opcode would be selected. Conversely, when an unsigned int32 was loaded into a 64-bit register, the kX64Movl opcode would be used. This choice between two opcodes is intended to ensure that the upper 32 bits of the destination register are set properly by the load: When loading an unsigned 32-bit value, the upper 32 bits in the destination should be set to all zeros, whereas when loading a signed 32-bit value, the upper 32 bits in the destination should all be set to match the sign bit of the source value. After the patch, the kX64Movsxlq opcode is used in all cases. As the function name denotes, it expects a signed int32 input, so the kX64Movsxlq opcode is always the correct choice.

Apparently, though, the PoC somehow managed to provide an unsigned input to this function! How is this possible? This is what we must investigate next.

Deep Blue Sea of Nodes

To find the root cause of this vulnerability, we can pass the “--trace-turbo-graph” argument to d8 to see generated turbofan graphs:

./d8 --allow_natives_syntax --trace_turbo_graph '/home/lab/Desktop/poc.js'

As this vulnerability has something to do with the type of input, it seems like a good idea to first check how the typer assigned types the nodes. For this purpose, we need to find “Graph after V8.TFTyper” in the graph and check its data:

This is what we see:

LoadTypedElement: This shows loading the element from our typed array. The type is Unsigned32.
SpeculativeNumberBitwiseXor: For the XOR operation. The type is Signed32.
NumberConstant[1]: For the constant number 1.
SpeculativeNumberAdd: For adding 1 to the result of the XOR.

All types make sense. Let’s move on to a later phase called “simplified lowering”:

After the simplified lowering phase this becomes:

LoadTypedElement: Type is still Unsigned32.
Word32Xor: Type is still Signed32.
ChangeInt32ToInt64 (#31:Word32Xor): This node is new. It takes the result of the XOR and converts it to Int64. Remember that the patch fixed this vulnerability by changing the InstructionSelector::VisitChangeInt32ToInt64 function. That means this node will be important in our analysis. For now, it seems OK as this node takes a Word32Xor node that is signed.
Int64Constant[1]: For the constant number 1.
Int64Add: For adding 1 to the result of the XOR.

The “--trace-turbo-graph” output shows how the engine optimizes the graph by performing numerous transformations. During the early optimization phase, the execution flow reaches a function called MachineOperatorReducer::ReduceWordNXor within v8/src/compiler/machine-operator-reducer.cc to deal with the XOR operation in our PoC:

Let’s have a quick look at the XOR in our PoC again. We XOR arr[0] by 0, and we know that XOR by 0 has no effect and returns arr[0]. Now check the highlighted section in the picture above. Here the engine checks if the right operand is provably equal to 0 and, if so, it replaces the XOR operation with the left node (arr[0]). In this way, the engine removes the no-op XOR to achieve better speed. How cool! Unfortunately, there is a small problem: the replaced XOR operation had an output type of Signed32, but arr[0] has a types of Unsigned32. The EarlyOptimization phase output shows this clearly:

The nodes now are:

When you compare this output with output of simplified lowering phase, we can see 2 major changes:

1 - The Word32Xor node is not available anymore. It has been replaced.
2 - The ChangeInt32ToInt64 (#31:Word32Xor) node has been changed to ChangeInt32ToInt64 (#45:LoadTypedElement). This is where the vulnerability occurs. ChangeInt32ToInt64 needs a Signed32 node. This was ok before, because Word32Xor was signed, but now it gets a LoadTypedElement node, which is unsigned.

As a side note: Now that we know the root cause of this vulnerability, we can develop some variants. For example, we can replace the XOR with a SAR using the “>>” operand (check the “MachineOperatorReducer::ReduceWord64Sar” function) or a SHL using the “<<” data-preserve-html-node="true" data-preserve-html-node="true" operand (check the “MachineOperatorReducer::ReduceWord64Shl” function).

Later, execution reaches the vulnerable function InstructionSelector::VisitChangeInt32ToInt64:

It checks if it is a signed load, but we changed the type to unsigned, and thus kX64Movl is chosen.

How can this cause a problem? The kX64Movsxlq opcode translates to an Intel movsxd instruction, while the kX64Movl opcode translates to an intel mov instruction. For a 32-bit source value with the most significant bit not set, there are no differences between these two. However, if the source has a 1 as the most significant bit, these deliver two very different results. Recall that the value stored in the array is 0x80000000, which has the most significant bit set. Let’s illustrate the difference between movsxd and mov by doing a small experiment in x64dbg. We will perform a ‘movsxd’ of a 32-bit value 0x80000000 to ‘rbx” and ‘mov’ of the same 32-bit value 0x80000000 to rcx. Here are the registers before the move instructions:

And here are the results after the moves:

As you can see, the value of rbx is very different than rcx. As opposed to the mov instruction, the movsxd instruction sign-extended the value. Now if the engine chooses the wrong instruction, it may load incorrect value into registers causing various problems.

Before finishing this blog, I would like to clarify one more point. Why is it needed to have an “add 1”? In fact, if you remove it, this vulnerability is not triggered anymore, and the PoC does not reach to the vulnerable function! Why is that?

To answer this question, we can remove the “add 1” from the PoC and examine the effect on the graph.

First, the graph if the “add 1” is removed:

When the “add 1” is removed, there is no need for a “ChangeInt32ToInt64” node in the graph anymore. Instead, a “ChangeInt32ToTagged” node is used to directly convert the result of the XOR to a tagged value and return.

Compare with the graph of the PoC including the “add 1”:

By including an “add 1” operation, the result of XOR (which is Signed32) needs to be first converted to int64 using a ChangeInt32ToInt64 node in preparation for the addition. Note that 1 is an Int64Constant. After the add, the result is changed to a tagged value and returned.

Therefore, we conclude that the “add 1” is needed to trigger insertion of a “ChangeInt32ToInt64” node.

Conclusion

In this blog post we identified the root cause of the vulnerability used at Pwn2Own and saw how the contestants chained a series of clever values and operations to trigger an incorrect behavior in the JIT engine. In the final blog in this series, we will explore how this issue was exploited. That blog will be published one week from today.

Until then, you can find me on Twitter at @hosselot and follow the team for the latest in exploit techniques and security patches.

Understanding the Root Cause of CVE-2021-21220 – A Chrome Bug from Pwn2Own 2021