WILL DORMANN | Oct. 16, 2023
On July 11, 2023, Microsoft released a publication for CVE-2023-36884 and associated blog post related to an attack chain that was credited to both Volexity and the Google Threat Analysis group (TAG).
Rather than sharing an IOC that can be used by
defenders, Microsoft chose to share a picture of what the exploit document looked like when it's
rendered by Word:
This misstep by Microsoft is just one aspect of this exploit chain that has led to difficulty in analyzing exactly how it works. For example, at least one lookalike malicious document has been reported that exploits an altogether different vulnerability (CVE-2017-11882). The existence of this lookalike exploit might be attributable to the lack of public information about what the exploit document hash is.
Three days prior to Microsoft's publication of CVE-2023-36884, BlackBerry published a report called RomCom Threat Actor Suspected of Targeting Ukraine's NATO Membership Talks at the NATO Summit. The image of the exploit document referenced by this blog post is the same as what Microsoft published on July 11. While BlackBerry shared hashes of the files discussed in their blog post, Microsoft’s lack of hashes made it impossible to definitively conclude that the BlackBerry report is referring to the same document as Microsoft.
BlackBerry's publication also indicated that the execution chain utilizes CVE-2022-30190, which is also known as Follina. If this were the case, this would mean that any system that has the June 2022 updates from Microsoft would not be affected by this exploit document. With the June 2022 Windows updates installed, the Microsoft Support Diagnostic tool will no longer allow PowerShell command injection. For this reason, one might conclude that the BlackBerry publication is describing a different exploit chain than what Microsoft described as CVE-2023-36884.
While Microsoft credits Volexity with reporting CVE-2023-36884 to them, Volexity has not published a
blog post or traditional publication that outlines the attack chain. However,
a Tweet from Paul
Rascagnères contained a diagram that outlined the exploit chain:
While this diagram was at the time the best source of information about how the exploit chain allegedly
works, it is missing some stages used in the chain.
I have reproduced the CVE-2023-36884 exploit chain, with several caveats. The 25 stages of the exploit chain are outlined in a spreadsheet online. Here is a selection of stages that are noteworthy, either due to inability to function with default Windows configurations or due to behaviors that may themselves be distinct vulnerabilities.
There are multiple stages of the exploit chain that do not appear to work on default Windows installations. The problematic stages of the exploit chain are as follows, in order as they appear on the chain.
By default, when Microsoft Office opens a document from the internet, including email, it will open in
Protected View.
While in Protected View, an Office document is severely restricted in what capabilities
the document content is allowed to perform.
If a document is opened in Protected View, the user is presented with a warning bar that states: "Be careful-files from the Internet can contain viruses. Unless you need to edit, it's safer to stay in Protected view."
Only if a user disregards the warning and clicks "Enable Editing" will the exploit chain proceed beyond
the first step. Alternatively, if Office is configured to disable the Protected View mitigations, then explicit
user interaction will not be required to proceed beyond this first stage.
Starting with Windows 10 version 1709, which was released in 2017,
guest access in SMB2 and SMB3 is disabled by default.
Note that as of this version, SMBv1 is not installed by default. With this
configuration, Windows will not successfully negotiate a connection with an SMB server that is not
configured to accept the current user's credentials. As such, the first thing that the exploit chain
attempts to do (retrieval of file001.url over SMB) will fail with a default Windows configuration. For
example, a default Windows configuration would display this error if using Windows Explorer to make
the connection:
For programs not configured to display the error to the user, this event can be viewed in the Windows
Event Viewer:
Unless Windows is configured to enable the "Allow insecure guest logons" feature for Lanman Workstation, this stage of the exploit chain will fail. Alternatively, it is possible that the exploit chain targets older versions of Windows, such as Windows 10 2015 LTSB or Windows 10 2016 LTSB. While these Windows versions still receive CVE-assigned security updates, they do not receive general security improvements that have not been assigned CVE IDs, such as the blocking of SMB guest access.
Due to the challenge-response nature of SMB authentication , it should not be possible to create an SMB server that will accept any credentials provided by the client. Therefore, if SMB is used for communication with the attacker's server, then SMB guest access must be enabled to allow the exploit chain to proceed.
When the Microsoft publication for CVE-2023-36884 was originally published, it did not contain information about which versions of Office were affected. On July 12, 2023, Microsoft updated the CVE- 2023-36884 advisory to indicate that the following versions of the Office365 Semi-Annual Channel Extended are affected:
The 2302 version of the Office365 Semi-Annual Channel Extended is not listed as being affected.
The reason that only the older two versions of the Semi-Annual Channel are affected is because Microsoft deployed a defense-in-depth improvement to Current-channel Office in January that prevents Javascript from running in web content. This security improvement was not assigned a CVE, and as such it was not included in the monthly security updates that the slower release channels receive on a monthly basis. Any current-channel version of Office that has received updates in 2023 will not be vulnerable to this exploit chain, due to the pervasive reliance on JavaScript throughout the exploit chain.
My testing of the behavior of Windows dropping files without a Mark of the Web (MotW), which is explained in the upcoming section labeled CVE-2023-36884, has shown that only the first Windows-Search-indexable file contained within a ZIP file may get planted without MotW protection. By utilizing the PCAP of the network traffic for the known exploit document for CVE-2023- 36884, we can see what files were being provided by the malicious servers involved at the time.
Looking at the network traffic that was captured live, the ZIP file provided by the malicious server has two different forms, differing only in the filenames contained within the ZIP. The file that is served first has the ZIP contents:
1111.txt2222.txtThe second time the ZIP file is retrieved, the file is identical to the first instance except for the file names that are specified for the contents. Specifically, this second instance has the file names:
1111.htm2222.chm
Given that only the first searchable file contained with a ZIP appears to be dropped during the phase
were the MotW may not be present, this means that the only unmarked files that may be used are
1111.txt and 1111.htm. Since the next stage of the exploit chain refers to
1111.htm by name, the ZIP
file provided by the malicious server the first time has no obvious function.
Windows Search
is a capability that was introduced with Windows Vista to enable searching of files and
their contents. When performing a search in a location accessible from Windows, this search can be
saved as a .search-ms file. The exploit chain for CVE-2023-36884 utilizes
a .search-ms file that
specifies a search within a ZIP file that is hosted on a remote SMB server.
For a file to be searchable with Windows Search, Windows must have an
iFilter
present to perform the indexing.
A stock Windows 11 machine with Microsoft Office installed has 14 iFilter libraries installed,
which allow for indexing of 290 types of files. Notably absent from this list is the CHM file format. As
such, a stock Windows system will not search files with a .CHM extension. Testing has
shown that the use of the ms-its: protocol handler requires that the target
CHM file have a .CHM file
extension. Otherwise it will not be parsed as expected.
While it is possible to install a 3rd-party CHM iFilter to enable this part of the exploit
chain, the stages that rely on a .CHM file being planted by Windows Search will fail on
systems without such a 3rd-party iFilter installed.
The core of CVE-2023-36884 relies on a period of time between the first searchable file being extracted from a ZIP and the rest of the files being extracted along with the MotW tags that indicates where they came from. Limited testing indicates that this window is approximately 20 seconds on average, with some invocations significantly longer and some invocations significantly shorter. This means that there is a race condition that will determine if the exploit chain is successful or not. If all the above limitations that interfere with successful exploitation are satisfied, the exploit still may not succeed if the delays chosen by the attacker's systems are longer than the window of vulnerability on the victim’s system.
The exploit chain takes advantage of several behaviors which might be considered vulnerabilities in and of themselves. The suspicious stages of the exploit chain are as follows, in order as they appear on the chain.
One of the first stages of the exploit chain is to load start.xml using
an StdOleLink object in the
Word document. The StdOleLink object, represented by CLSID
{00000300-0000-0000-C000-000000000046}, has been used to exploit several vulnerabilities
in the past. Specifically, this object is
known to
be utilized in exploitation of CVE-2017-0199, CVE-2017-8570, CVE-2017-8759 and CVE-2018-
8174. Several of the stages of the exploit chain will not function when MSHTML is hosted by Internet
Explorer, however when the attack chain starts out as an StdOleLink object in an Office document,
the web content appears to be granted capabilities beyond what would be granted to a web browser.
At some point the exploit chain for CVE-2023-36884 leverages a cross-protocol file navigation to switch
from using the HTTP protocol to using SMB. Specifically, the file RFile.asp, which is retrieved using the
HTTP protocol, will redirect to a file://<IP_Address>/ URI, which represents an SMB-accessible resource.
While this capability can be restricted by using FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION
registry entries, these restrictions are not present in Windows by default.
When Microsoft redefined what CVE-2023-36884 represents, its meaning went from representing the exploit chain in its entirety to meaning only one specific part of the chain. Specifically, Windows Search can be used to plant a remote file on the local filesystem without being tagged with a MotW for a brief period. A file from the internet that can be placed on the local filesystem without a MotW can perform actions that might be more dangerous than what is allowed with one that is tagged with MotW.
The first step in the exploit chain where the lack of MotW is leveraged is the use of the Microsoft Web
Browser control, represented by CLSID {8856F961-340A-11D0-A96B-00C04FD705A2}. This COM
object is not safe for scripting and is not safe for initialization using persistent data. 18 As such, it would
be unable to be controlled by content on the web. However, this exploit chain can initialize the object
with persistent data if the MotW is not present on the file that attempts to use it, which is 1111.htm.
The file 1111.htm subsequently attempts to use the HHCtrl Object, which is represented
by CLSID {ADB880A6-D8FF-11CF-9377-00AA003B7A11}. This object is also not safe for scripting and is not
safe for initialization using persistent data. However, the file 1111.htm both attempts to initialize it
with persistent data and also control it with scripting. If 1111.htm is present without a MotW, then it
will be allowed by Windows to perform both actions that would otherwise be prevented.
Finally, the file 2222.chm is processed by way of an ms-its: URI handler.
If 2222.chm was tagged
with a MotW that indicated that it came from the internet, the functionality provided by the ms-its:
URI handler will not be allowed. However, if the MotW is missing, then ms-its: can be used to
proceed through a sequence of events that ends in arbitrary code execution.
Web browsers and similar technologies enforce a same-origin policy to restrict how content in one origin can interact with content in another. A simple example of same-origin policy being enforced would be the browser's refusal of a web page living on https://example.com from being able to access your bank's website's cookies. Similarly, a web page that lives on https://example.com is not granted permission to redirect to web content on the local filesystem, for security reasons.
One of the stages of the CVE-2023-36884 exploit chain is to take web content that lives on a remote
SMB server and redirect to web content that lives on the local filesystem. While normally this action
would be refused, the exploit chain avoids this restriction by leveraging knowledge of the victim's
hostname. While web content on a remote SMB host will not be allowed to redirect to a file://c:/ URI,
which represents the computer's local C: drive, the content on a remote SMB host is allowed to redirect
to a file://<hostname>/c$/ URI, which also represents the computer's local C: drive. However since the
address makes it seem like another SMB host rather than the local filesystem, the request is allowed by
Windows.
One of the final steps of the CVE-2023-36884 exploit chain involves opening a .URL file that points to a
remote server, which can be accessible over SMB or WebDAV. Consider the case where a URL file has
the following contents:
direct.url |
[InternetShortcut] |
Because Windows considers VBS files unsafe, and the target of the .URL file is remote, Windows
presents a warning dialog to the user. This is the same sort of dialog that Windows would present to the
user if they tried to open calc.vbs after downloading it from a website.
Now consider the scenario where the .URL file target is inside of a ZIP file on a remote SMB or WebDAV
host:
inzip.url |
[InternetShortcut] |
When this .URL file is clicked on, the user is not presented with any warning.
The calc.vbs file is
executed, resulting in the execution of calc.exe in our example.
By convincing a user to open a crafted Microsoft Office document and clicking out of Protected View, a remote attacker may be able to run arbitrary code on certain Windows systems.
When Microsoft first published CVE-2023-36884 to describe the entire exploit chain, they recommended
creating several FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry entries to stop the
exploit chain at the stage where it transitions from HTTP to SMB traffic. 2 The following batch file can be
used to make these changes:
block_cross_protocol_nav.bat |
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
reg add "HKLM\Software\Policies\Microsoft\Internet
|
Microsoft has addressed the parts of the exploit chain that rely on not having a MotW on files planted by Windows Search with the update for CVE-2023-36884.
Although the Microsoft description of CVE-2023-36884 indicates that it can allow an attacker to plant a malicious file evading Mark of the Web (MOTW) defenses, the update for CVE-2023-36884 performs two protective actions:
zipfldr.dll will now explicitly contain a MotW at the
time that they're first written to the filesystem.zipfldr.dll will now contain a UUID in the
path, preventing their location from being guessable by an attacker.Combined, these two protections solve the problem of the ability for a MotW-free file being able to be planted in a predictable location.
Note that the other suspicious parts of the exploit chain are not addressed with this update.
Users of the current version of Office were not affected by this exploit chain because JavaScript support was removed in January 2023. 13 Although the Semi-Annual Channel of Office does get monthly updates to address vulnerabilities that have had CVEs assigned to them, this update channel will not receive general security improvements in the product that were not assigned CVEs.
It is possible to still run older versions of Windows and still have them receive CVE-assigned security updates monthly for no additional cost. For example, it is possible to run the original 1507 version of Windows 10 from the year 2015 and have it be up to date with respect to CVEs by way of using the Windows 10 2015 LTSB version. This version will continue to receive updates for CVEs until Oct 14, 2025.
However, like how the Semi-Annual Channel of Office only receives security updates for vulnerabilities that have been assigned CVEs, it's important to realize the security impact of using a Windows version with such a limited subset of updates. Just like over time Microsoft Office gets mitigations and other security improvements added to it that don't have an associated CVE, Microsoft Windows is in a similar situation where security improvements are made over time in the form of features that do not have associated CVEs.
As the exploit chain for CVE-2023-36884 is concerned, Windows 10 2015 LTSB and Windows 10 2016 LTSB are more vulnerable because they never received the security improvement of blocking guest SMB traffic by default, since this change did not have a CVE associated with it.
The exploit chain for CVE-2023-36884 was problematic to analyze for multiple reasons. The original cause of trouble was Microsoft's decision to share an image of the rendered exploit document as an indication of compromise (IOC), as opposed to sharing a hash of the data. This decision was disrespectful to any analyst who works in the security field. It both caused copycat exploits to appear in the wild, as well as added to uncertainty among anyone investigating the exploit.
The other aspect that complicated the matter was the lack of detail about what platforms and configurations are affected. Microsoft's original publication did not even mention which versions of Office were affected, which led to speculation and unnecessary fear about the exploit.
Finally, there has yet to be public information revealed that indicates what real-world systems were successfully compromised with the exploit chain, if there even were any. The best we know at this point is that Volexity shared an exploit chain with Microsoft, and Microsoft created the CVE-2023-36884 ID as a placeholder for the chain. One month after its original publication, CVE-2023-36884 was then redefined to cover only the MotW bypass by way of Windows Search part of the exploit chain.
It is unclear whether any up-to-date real-world systems were successfully compromised using the CVE- 2023-36884 exploit chain. The situation may be as simple as Volexity having contacting Microsoft about a complicated exploit chain, and Microsoft did indeed find a stage of the chain that they considered to be a vulnerability. Given the long list of requirements for successful exploitation, including having an old version of Microsoft Office on an old or misconfigured version of Microsoft Windows, plus having some obscure 3 rd -party software installed, plus adding the need for luck in the mix to win the race condition, it's hard to imagine that this exploit chain was worthy of the attention that it received.
This report was created using information provided by Microsoft, BlackBerry, and Volexity.
Additional analysis and sample files were provided by @tlansec of Volexity.