Free Micropatches For Microsoft Access Forced Authentication Through Firewall (0day)

 

Update 2/14/2024: Either January 30 or February 1 Office update brought a fix for this issue: now, Access warns the user for any ODBC connection to SQL Server. Our patch only shows a warning when such connection is made on non-standard ports 80 or 443, because these would carry user's NTLM hash through a company firewall, so Microsoft's patch might display more - in our view unnecessary - warnings. So what CVE ID did this issue get? Well, it doesn't seem to have gotten one: neither January 30 nor February 1 Office update mention any changes in Access, and February Windows Updates also have no suitable match. So far, this issue seems to have been fixed silently. With official patch available, our patches for this issue are no longer FREE and require a PRO or Enterprise license. Our patch was available 66 days before Microsoft's.

On November 9, 2023, Check Point Research published an article about an "information disclosure" / "forced authentication" vulnerability in Microsoft Access that allows an attacker to obtain the victim's NTLM hash by having them open a Microsoft Office document (docx, rtf, accdb, etc.) with an embedded Access database.

Many similar vulnerabilities have been disclosed in the last few years, all having a common theme of forcing a Windows process to authenticate to attacker's server and thereby disclose credentials of Windows user or a privileged service account to the attacker. Microsoft has patched some of them, but decided not to patch others: DFSCoerce, PrinterBug/SpoolSample and PetitPotam still don't have an official patch today and our micropatches remain the only patches available for these (our customers who can't stop using NTLM really appreciate them). RemotePotato0 was initially experiencing a similar fate but was then silently fixed 9 months after publication. ShadowCoerce was just as silently fixed 6 months after publication. On the other hand, a WordPad vulnerability from this same category, leaking user's NTLM hash to a web share upon opening an RTF document, was openly patched by Microsoft just last month.

It's hard to tell how Microsoft decides whether to patch a forced authentication vulnerability or not - and this one in Microsoft Access just adds to the confusion. Let's see how.

The Vulnerability

As Haifei Li, security researcher at Check Point, describes in their detailed article, a remote SQL Server database link can be inserted to a Microsoft Access database with "Windows NT authentication", which will force such authentication - and leak user's NTLM hash - every time the table with such link is refreshed in Access. So far, this would be a "classic" forced authentication issue, only different from most others in the fact that the connection isn't established on "classic" SMB and RPC ports but on SQL Server's port 1433. Which is expected to be filtered for outbound traffic from internal network towards the Internet.

But as Haifei noted, the database link can override the default port and specify an arbitrary port, including 80 or 443 - which are both typically allowed by firewalls for outbound connections so users in the network can browse the Internet. This makes things more interesting, and impact-wise almost comparable to the previously mentioned WordPad issue. Why "almost"? Because it's not enough just to open a Word document with such Access database embedded: to force a refresh of the database link, the user has to "open" the linked Access table by clicking on it.

To overcome this limitation, Haifei found that the AutoExec macro can be used to automatically open the table and force a refresh. But hey, macros have already been blocked for documents coming from the Internet, so how would this even work?

Well, we first need to understand something Haifei calls "simple Access macros". Admittedly, we did not know that Access macros come in two flavors, and we couldn't find any relevant results on this phrase on the Internet, but that's probably because Haifei usually knows more about the targeted product than the Internet does.

"Simple Access macros" are limited macros that only allow you to perform a set of predefined harmless actions, in contrast to "full-fledged regular macros" (sorry, another unofficial term) that are actual VBScript code capable of doing pretty much anything on the computer, including downloading and executing ransomware. It turned out that simple Access macros are blocked neither by the Access macro policy nor by the Protected View. In addition, if you name such macro AutoExec, it will get executed upon opening the Access database.

Putting two and two together, Haifei created an Access database with a remote SQL Server database link, Windows NT authentication, and an AutoExec macro that opened the linked table - and embedded that in a Word document because users prefer opening Word documents to Access databases. Now, there is no "almost" there anymore: this issue is impact-wise identical to the WordPad issue.

Checkpoint reported this vulnerability to Microsoft in January 2023 and were in July still "unable to obtain conclusive answer because the issue is considered as “low/none severity”, according to the MSRC reply." They did notice, however, that at some point during this period, Access started showing this security dialog when opening their PoC file:

 

So, was this issue silently fixed too? Nope, at least not successfully: while the above dialog is certainly triggered by the presence of the AutoExec macro (it shows even when AutoExec is the only active content), closing this informational dialog either by pressing OK or clicking the X still leads to the AutoExec macro being executed and user's credentials being sent to attacker's server. The only way to block the exploit when this dialog is displayed is to forcefully kill the msaccess.exe process, e.g. using Windows Task Manager.

In summary, we have active content that is detected, user informed about it being blocked, and then still getting executed unless the user kills Access with Task Manager. Not ideal.

Our Analysis

We tried to make sense of all this and here's what we think happened.

We think Microsoft never intended to patch the reported issue due to its "low/none severity" assessment, which we think was wrong because its impact is comparable to the WordPad issue they had patched last month with severity "important".

We think the security dialog that started appearing in Access is part of Microsoft's slow and painful process of gradually restricting malicious macros while not getting hammered by customers whose Office documents they might break along the way. (See here and here for examples.) Microsoft is doing the right but difficult thing here, addressing a very popular attack avenue, and they deserve huge credit for that.

We think that the current macro-blocking logic in Access is flawed: it clearly detects the AutoExec "simple" macro, it tells the user that macros are blocked - but then doesn't block it. Microsoft needs to fix this, but it's not hard to imagine thousands of enterprises using "simple" macros on a daily basis, and thousands of angry calls to the Office PM the next day if they actually start getting blocked. Still, this needs to be fixed this because it's confusing and useless: either don't trip on simple macros, or trip on them and block them.

We expect Microsoft will do something about this all; they will probably fix the macro logic and the dialog, but will they revise the severity of the issue reported by CheckPoint and fix it too?

Maybe they will, maybe they won't - but we did.

Our Micropatch

We pondered on how to address this: shall we fix Microsoft's macro logic so that simple macros will indeed be blocked when the dialog says they would be? If we did, and broke "simple" macros for our users, they would probably blame Microsoft and make angry calls to the surprised Office PM. We don't presume we understand the complex dynamics between a huge software vendor who decades ago made a convenient powerful feature that boosted product usability but has since become a major security risk, and organizations that have this feature embedded in critical processes but can at the same time be seriously harmed because of it.

So we decided on a different approach: we would block database connections from Access to SQL Server on ports 80 and 443. While it is not impossible for some real, legitimate SQL Server to be accessible on port 80/443 and some real, legitimate Access database being linked to it, we think it's realy unlikely. Note that such patch would not block SQL Server connections on port 80/443 from any other client, just Microsoft Access.

"How about other database servers that could be linked to remotely," you ask, "some of them may also support Windows NT authentication and be accessible on arbitrary port?"

Well, the main risk is posed by the ones supported on Windows by default, without a non-default ODBC driver having to be installed on user's computer. And SQL Server is the only one that fits the bill.

This is our micropatch:

MODULE_PATH "..\Affected_Modules\acecore.dll_16.0.16924.20054_64bit_u202311_Office2016_2019_2021_365\acecore.dll"
PATCH_ID 1569
PATCH_FORMAT_VER 2
VULN_ID 7803
PLATFORM win64
       
patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0x1955a0
 N_ORIGINALBYTES 5
 JUMPOVERBYTES 0
 PIT msvcrt.dll!wcsstr,msvcrt.dll!_wtoi,acecore.dll!0x195637,shlwapi.dll!StrStrIW

 code_start

  push r15                 ;save the original r15 value
  sub rsp, 0x28            ;create shadowspace
  lea r15, [rbp+0x60]      ;move the connection string pointer to r15
  mov rcx, r15             ;move the connection string pointer to the first argument
  call STR1                ;get the string "SQL Server" to the stack
  db __utf16__('SQL Server'),0,0
 STR1:
  pop rdx                  ;pop the "SQL Server" string pointer from the stack
  call PIT_StrStrIW        ;call case insensetive string search
  cmp rax, 0x0             ;check if SQL Server substring exists
  je SKIP                  ;if not skip the patch
       
 LOOP:                     ;the port searching loop
  mov rcx, r15             ;move the connection string pointer to the first argument
  call STR2                ;load the "," character onto stack
  db __utf16__(','),0,0
 STR2:
  pop rdx                  ;pop the "," character to rdx
  call PIT_wcsstr          ;call wcsstr to search for "," and if found return the addres to rax
  cmp rax, 0x0             ;check if "," was found
  je SKIP                  ;if no matches, we're done
  add rax, 0x2             ;if match was found increment the pointer to string by 1 char
  mov r15, rax             ;move the incremented pointer to r15 for next iteration
  mov rcx, rax             ;move the incremented pointer to the first arg
  call PIT__wtoi           ;convert the string after the "," to a number
  cmp rax, 0x50            ;check if that number is 80 (decimal)
  je BLOCK                 ;if it is, block the connection
  cmp rax, 0x1bb           ;check if that number is 443 (decimal)
  je BLOCK                 ;if it is, block the connection
       
  jmp LOOP                 ;if nothing was found repeat the search
       
 BLOCK:                    ;block the connection
  call PIT_ExploitBlocked  ;popup the Exploit Blocked notification
  add rsp, 0x28            ;clear shadowspace
  pop r15                  ;restore the original r15 value
  jmp PIT_0x195637         ;jump to the error block
       
 SKIP:                     ;skip the patch and continue normal execution
  add rsp, 0x28            ;clear shadowspace
  pop r15                  ;restore the original r15 value

 code_end
    
patchlet_end

 

Let's see our micropatch in action. In the video below we can see attacker's computer on the left and user's computer on the right. The user is running fully updated Office 365. On attacker's computer we can see Wireshark, a network monitoring tool, that is filtered to only show communication with the IP address of user's computer.

First, with 0patch disabled, the user opens a malicious Access file in Microsoft Access, and as described above, a security dialog is displayed informing them that active content in the file has been blocked (we know it wasn't). As the user closes this dialog, the linked database connection is established with attacker's computer on port 80 due to the AutoExec macro being executed.

Next, with 0patch enabled, the user again opens attacker's Access file. This time, as the "blocked active content" security dialog is closed, our patch detects that a connection to a SQL Server is attempted on port 80 and blocks it. It also records an "Exploit blocked" event and shows an alert to the user.

Micropatch Availability

Micropatches were written for the following versions of Microsoft Office with all available Updates installed:

1. Office 2010*
2. Office 2013*
3. Office 2016
4. Office 2019
5. Office 2021
6. Office 365
   

 

(* Office 2010 and 2013 were security-adopted by 0patch and are receiving critical security patches from us after their support by Microsoft was terminated.)

As always, since this is a 0day, our micropatches are part of the 0patch FREE plan, and will remain free until Microsoft has fixed this issue with their official patch.

 

These micropatches have already been distributed to, and applied on, all online 0patch Agents (unless Enterprise group settings prevented that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. If you're using Windows or Office that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers. (By the way, still using Windows Server 2012? 0patch has you covered!)

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Haifei Li with Check Point for sharing the details of this vulnerability, which made it possible for us to create a micropatch for our users.

To learn more about 0patch, please visit our Help Center.

 

We Patched CVE-2023-28244 Before It Was Cool

How Our Patch For CVE-2022-33647 Fixed CVE-2023-28244 Five Months In Advance

By Blaz Satler of 0patch Team

The Initial Vulnerability - CVE-2022-33647

In September 2022, Microsoft released patches for CVE-2022-33647, a Kerberos vulnerability that allows a MITM (Man-In-The-Middle) attacker to hijack a user's Kerberos ticket and achieve domain privilege escalation. James Forshaw of Google Project Zero was attributed with the discovery of this issue, and shortly after the issue was fixed also published a writeup on the official Project Zero bug tracking page. James also forked a branch of GhostPacks Rubeus tool and added a sample POC (Proof-of-Concept) code that demonstrated this issue in action and allowed users to check if their KDC (Key Distribution Center) was affected.

Testing revealed that this issue affected all Kerberos versions that have not configured any restrictions for the use of old cryptographic algorithms, specifically RC4-MD4. This algorithm is particularly dangerous as it contains multiple known vulnerabilities, such as using only the first 8 key bytes for encryption and only 40 bits of randomness in session keys. Such security deficiencies could make you wonder why the algorithm is even allowed to be used in Kerberos. Nevertheless, Kerberos allowed its use by default and also didn't seem to mind being downgraded from a stronger protocol to RC4-MD4 mid-session, which was why the POC worked.

 

Microsoft's Patch

We analyzed Microsoft's patches for CVE-2022-33647 and the exploit's execution flow. All signs seemed to point to a patch in kdcsvc.dll, specifically in the KerbInitPreferredCryptList function. This function executes when the KDC service starts which is with the start of lsass.exe. Its job is to initialize the PrefferedCryptList (yes, we know, it's a typo in the code too) variable and two other lists with cryptographic algorithms that the KDC will prefer. Microsoft patched this by not including RC4-MD4 and RC4_HMAC_OLD to these lists. At the time this fix seemed sufficient with the only apparent flaw being that it would only come into effect after the system that applied the patch had been restarted. 

 

Our Micropatch

Our own patch, in contrast, needed to be able to protect the system from the moment that the user decided to apply it, so we needed to find a better way of blocking these protocols. During the analysis, we stumbled upon the KerbGetEncTypeBitmask function which supplies bit masks of all supported encryption algorithms to other parts of the code. It has the ability to refuse unknown encryption types, so we decided to take a closer look. Upon further investigation, we found that it was invoked on every request to the KDC, so it made for a perfect candidate for patching this exploit in real time (without a reboot). Our patch was injected at the start of this function and checked if the passed cryptographic algorithm was one of the two that Microsoft had blocked; if it was, we simply executed the "return 0" command which returns KDC_ERR_ETYPE_NOTSUPP ("type not supported"). This had the effect of completely blocking any use of RC4_MD4 and RC4_HMAC_OLD, and our patches were released in October 2022.

The New Vulnerability - CVE-2023-28244

6 months later, Microsoft released a fix for another similar vulnerability CVE-2023-28244, acknowledging John Askew with Terrapin Labs as the discoverer. Subsequently John also published a POC on GitHub which seemed eerily similar to James' POC for CVE-2022-33647. Our tests revealed that this new exploit attacked the same RC4-MD4 encryption algorithm but with a slight modification to the AS-REQ packet. This new exploit included a timestamp encrypted with the user's password inside the AS-REQ, which changed the execution flow in kdcsvc.dll.

This modification caused the exploit to bypass Microsoft's patch that had caught its predecessor. Microsoft's patch only changed how a few crypt lists were initialized, but left some relevant global variables like KdcGlobalSupportedEnctypes unchanged. Although there were other checks in place for unsupported encryption types that were executed later, none of them used the patched PrefferedCryptList variable that was stripped of RC4-MD4 and RC4_HMAC_OLD. This again resulted in RC4-MD4 being used for encrypting the session and tickets.

 

 

A Pretty Decent Patch

The micropatch we had released for CVE-2022-33647, on the other hand, proved to be remarkably robust, effectively neutralizing the new, modified exploit. It was particularly gratifying to find that Microsoft's fix for the new vulnerability targeted the same function as our original patch (KerbGetEncTypeBitmask), and closely resembled our own patch for this vulnerability: it removed the validation for RC4-MD4 and RC4_HMAC_OLD encryption algorithms within the KerbGetEncTypeBitmask function, returning a '0' as the function's result when these algorithms were passed to it. This behavior is logically equivalent to our patch.

Effectively, our patch for CVE-2022-33647 fixed CVE-2023-28244 entire 157 days before it was patched by Microsoft. 

Looking for a way to keep using Windows Server 2012 securely, and don't want to purchase expensive Extended Security Updates? Want to protect your legacy Windows 7, Server 2008 R2 machines and Microsoft Office installations with actual security patches that don't even need a computer restart and can get applied or un-applied in seconds? Not objecting to having occasional vulnerabilities fixed before those running still-supported Windows versions? 0patch has your back!

Learn more about 0patch on our web site, in our Help Center, or contact us at sales@0patch.com for a free trial or demo.

 

Micropatches Released For Microsoft WordPad Information Disclosure (CVE-2023-36563)

 

 

October 2023 Windows Updates brought a patch for CVE-2023-36563, an "Information Disclosure" vulnerability in WordPad that was found by Microsoft Threat Intelligence as being exploited in the wild. A better name for this vulnerability would be "Coerced authentication" or "Forced authentication", as it falls in the same class of vulnerabilities as various similar issues that we've patched before.

In any case, the vulnerability allows an attacker to create a Rich Text Format (RTF) document which, when opened by the victim in WordPad*, sends user's NTLM hash to attacker's server - where the attacker can receive it and send it to some other NTLM-enabled service in victim's network to impersonate the victim.

(* WordPad is the default application for RTF files when Office is not installed.)

While WordPad warns the user that the document contains potentially harmful remote content, and the user can choose to block such content, WordPad sends out user's NTLM hash before showing this warning - which is a bit out of order, so to speak.

 

The Vulnerability and the Official Patch

Two weeks later, security researcher Dillon Franke publish their reverse engineering analysis of this vulnerability. In this article, Dillon describes reverse engineering Microsoft's patch and tracing back to the vulnerability. They not only discovered what the issue was but also that Microsoft created new Windows API functions to fix it: the underlying problem turned out to be systemic, namely that simply initializing an OLE object could result in Windows trying to authenticate to a remote server without any way for the initializing application - or its user - to decide whether they were okay with that. Microsoft therefore created new functions that included this functionality using "callback functions", and fixed WordPad by using these new functions instead of the old ones.

Our Micropatch

As for our patching this issue, we really didn't want to implement new functions in ole32.dll because our thing is, you know, MICROpatching.

Instead, we decided to do something different, something that we thing WordPad should have been doing for years now: we implemented Mark-of-the-Web checking in WordPad.

Mark-of-the-Web (MotW) is a flag that gets set by all major web browsers and mail clients on Windows on all files that originate from the Internet, and allows applications opening such files to alert the user about opening a potentially harmful document. Most major document-handling applications on Windows check the MotW and do something about it, but WordPad never got this feature.

We decided that implementing a MotW check in WordPad would not only provide effectively identical level of protection against the issue at hand as Microsoft's patch, but would also show users a security alert for any other malicious document originating from the Internet. We consider this a good thing.

Let's see our micropatch in action. On the left side of the screen is the victim's computer, vulnerable to CVE-2023-36563, where the user is about to open attacker's RTF document. On the right side is the attacker's server running a tool that is waiting to collect user's NTLM hash. Without 0patch, opening the RTF document results in attacker's server receiving user's NTLM hash even before WordPad shows the security warning. With 0patch, a new "Mark-of-the-Web" warning is shown to the user upon opening the document, and if the user decides not to proceed with opening the document, no NTLM hash is sent to attacker's server.

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1 
2. Windows 10 v20H2
   
3. Windows 10 v2004
4. Windows 10 v1909
5. Windows 10 v1809
6. Windows 10 v1803 
7. Windows 7 (without ESU, with years 1, 2 or 3 of ESU)
8. Windows Server 2008 R2 (without ESU, with years 1, 2 or 3 of ESU)
   

 

Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Dillon Franke for sharing their analysis, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

 

Micropatches Released For Microsoft Office Security Feature Bypass (CVE-2023-33150) - Plus a Small 0day

 

In July 2023, Microsoft released a patch for CVE-2023-33150, a vulnerability in Microsoft Office that allowed an attacker to create a malicious Word document which would not open in Protected View even though it had the Mark-of-the-Web ("MotW") set.

The first public detail about this vulnerability came from security researcher Eduardo B. Prado, noting that adding a non-breaking space character to the end of a Word document's extension prevents Word from opening the document in Protected View.

Subsequently, Will Dormann published his own research. Will noticed that in the process of opening a file with a non-breaking space in the extension, Word at some point - after normalizing the file path - tried to find the Mark-of-the-Web in a file without the non-breaking space, and failed because no such file existed. Using a flawed logic "no file, no Mark-of-the-Web", Word then decided that it was safe to open the document without Protected View.

To illustrate the issue, suppose a downloaded malicious file with Mark-of-the-Web is named PoC.doc<nbsp>, whereby <nbsp> denotes a non-breaking space. (One can create such file manually by editing the name of the file, placing the cursor at the end of the file name, holding down Alt and typing 255 on the numeric keypad.) Opening such file in Word would lead to Word normalizing the file name at some point (which removes the non-breaking space), and trying to read Mark-of-the-Web from PoC.doc. Since this file does not exist, Word would assume there was no Mark-of-the-Web, even though this mark existed on the malicious file. Believing there was no Mark-of-the-Web, Word would open the file without Protected View.

Microsoft's patch fixed this flawed logic: fully updated Word now still tries to open the file without the trailing non-breaking space, still fails (of course, such file is not there), but then defaults to "Mark-of-the-Web is present" and opens the document in Protected View.

The following video demonstrates the vulnerability on fully updated Office 2013, and shows that 0patch removes it. A PoC.doc file on the desktop has the Mark-of-the-Web and also has a non-breaking space appended to the end of the file name. Opening such file doesn't automatically launch Word, because this exact file extension is not associated with any application, but Windows very friendly offer Microsoft Word as the most likely candidate for opening the file. Word then opens this file without Protected View. With 0patch enabled, opening the same file results in the file being opened in Protected View.

 

 

Since users of Office 2010 and 2013 didn't receive Microsoft's patch for this issue, we created our own micropatches for these versions that fix CVE-2023-33150. All PRO and Enterprise users had these patches automatically applied without even having to relaunch Word.

And now, the 0day....

 

While working on the above vulnerability and its patch, our researchers noticed something strange in the patched version of Word. While Microsoft's patch for CVE-2023-33150 changed the flawed logic of "no file, no Mark-of-the-Web" to a more secure "no file, yes Mark-of-the-Web", the underlying assumption in both cases was that there was no file.

In our tests, while frequently moving, copying and renaming files, fully patched Word sometimes behaved strangely, seemingly randomly not opening the file in Protected View when it should have. It turned out there is another flaw in the other half of the above logic: the half where a file without the non-breaking space at the end happens to exist.

What happens in that case? Well, Word tries to read the Mark-of-the-Web from it and uses it for deciding whether to open the file in Protected View or not.

Suppose we have, like before, a malicious file with the Mark-of-the-Web named PoC.doc<nbsp>: a fully patched Word correctly opens it in Protected View. Suppose we then place another file named PoC.doc next to it without the Mark-of-the-Web and open the first file with Word: Word checks PoC.doc for Mark-of-the-Web and, not finding it, opens the malicious file without Protected View.

Is this a security issue? Let's discuss exploitability. 

Could the attacker who tricked the user into opening a malicious PoC.doc<nbsp> (a file with Mark-of-the-Web) also plant PoC.doc (without Mark-of-the-Web) next to it to make Word open the former without Protected View? If they could, they might as well just plant PoC.doc and have the user open it for the same effect without having to exploit anything.

Alternatively, could the attacker plant a malicious MeetingMinutes.doc<nbsp> (a file with Mark-of-the-Web) next to a previously existing, legitimate MeetingMinutes.doc (without Mark-of-the-Web) on user's computer? Potentially yes: our best attack scenario is for the user to have downloaded a Word document from an intranet web server, which would end up in the Downloads folder without Mark-of-the-Web. The attacker would then trick the user to open MeetingMinutes.doc<nbsp> from their own web server on the Internet, which would result in Word opening this file from the Downloads folder, but would read the Mark-of-the-Web from the legitimate MeetingMinutes.doc, and decide to open the malicious file without Protected View.

This is arguably a pretty far-fetched scenario, and perhaps someone else will think of a better one. With this in mind we reported the issue to Microsoft and expect it to be fixed soon, but did not wait with publication due to very limited exploitability. We did, however, write a micropatch for all supported Word versions (Word 2016, 2019, 2021 and 365) and made it freely available until Microsoft has provided their official fix. Our CVE-2023-33150 patches for Word 2010 and 2013 also fix this vulnerability on these Office versions.

The following video demonstrates the vulnerability and how our patch removes it.

Micropatch Availability

Micropatches were written for the following versions of Microsoft Office with all available updates installed:

1. Office 2010 (PRO or Enterprise license required)
   
2. Office 2013 (PRO or Enterprise license required)
3. Office 2016 (free until Microsoft provides an official patch)
   
4. Office 2019 (free until Microsoft provides an official patch)
5. Office 2021 (free until Microsoft provides an official patch)
6. Office 365 (free until Microsoft provides an official patch)

 

 

Micropatches have already been distributed to, and applied on all computers with registered 0patch Agents, unless Enterprise group settings prevent that. 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Eduardo B. Prado and Will Dormann for sharing their knowledge, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

 

0patch Security-Adopts Windows 11 v21H2 Home and Pro to Keep it Running Securely

 

 

This October brought the last security updates for Windows 11 version 21H2 Home and Pro versions. Windows 11 require a Trusted Platform Module (TPM) 2.0 to be present on the computer, but for some time, it was possible to install Windows 11 version 21H2 without TPM. Many users have done that and now that this version went out of support, they cannot upgrade to Windows 11 v22H2, and thus cannot receive future security fixes. While many modern CPU versions are supported by Windows 11, computers with unsupported CPU versions are still happily doing their work in large numbers around the World.

To keep these computers secure, we security-adopted Windows 11 v21H2 and will provide critical security patches for it from this month on, for at least one year (and longer if there is sufficient demand).

We have previously security-adopted many other Windows versions, including Windows Server 2012, which has also reached its end of support this month.

If you're running Windows 11 v21H2, all you need to do is install 0patch Agent on the computer and register it to an account with PRO or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them. In order to have our micropatches applied, Windows 11 v21H2 will have to have October 2023 Windows Updates (the last official updates for this version) installed.

These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 11 v21H2 with 0patch will also receive our micropatches for "0day" vulnerabilities in various products.

We welcome all interested organizations to contact sales@0patch.com for information about pricing, deployment, or setting up a trial.

To learn more about 0patch, please visit our Help Center.

 

Micropatches Released For Two Windows CNG Key Isolation Service Vulnerabilities (CVE-2023-28229, CVE-2023-36906)

 

Last month, security researcher @k0shl of Cyber Kunlun published a proof-of-concept for CVE-2023-28229, an elevation of privilege vulnerability in CNG Key Isolation Service. The same POC also demonstrated exploitation of CVE-2023-36906, an information disclosure vulnerability in the same service discovered by the same researcher.

Microsoft had previously provided fixes for these issues in April and August 2023, respectively. According to CISA, CVE-2023-28229 was found to be exploited in the wild.

 

CVE-2023-28229

This bug is a race condition in the Key Isolation service running in lsass.exe that allows an attacker to use already-freed memory inside a structure. Its root cause is flawed critical section management that protects heap-based data structures from concurrent access but for some reason excludes reference counter initializations and updates. When a user spawns many concurrent threads that call SrvCryptCreatePersistedKey and SrvCryptFreeKey, these threads eventually cause the execution of said functions such that a key data structure is freed in one thread but then still used in another thread by calling the structure destructor method from already deallocated vftable. 

Microsoft patched this bug in April 2023, and their patch included relocating several critical sections over various pieces of code. Our approach to patching this issue was more minimalistic as we only switched two instructions to place the increasing of the reference counter in function SrvAddKeyToList inside the critical section. It was our assessment that this very instruction was the most critical enabler of exploitability.

During the analysis, we also noticed that this bug doesn't affect Windows 7 and Server 2008 R2 systems as the relevant code in keyiso.dll is completely different there and does not use critical sections in the same way as in newer versions of Windows.

Source code of our patch:

MODULE_PATH "..\AffectedModules\keyiso.dll_10.0.19041.388_Win10-2004_64-bit_u2021-12\keyiso.dll"
PATCH_ID 1509
PATCH_FORMAT_VER 2
VULN_ID 7723
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2d2f
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 16                       ; remove these two instructions
    PIT ntdll.dll!RtlLeaveCriticalSection
    
    code_start
       
        lock inc dword[rdi+0x8]            ; and re-add them in the reverse order
        call PIT_RtlLeaveCriticalSection
       
    code_end
    
patchlet_end

CVE-2023-36906

This information disclosure issue stems from the way the Key Isolation Service implements SetProviderProperty and GetProviderProperty functions. When calling SetProviderProperty, the attacker can specify a string of some length, but can then request its value using GetProviderProperty specifying a larger length.When this happens, the Key Isolation Service reads the referenced buffer without any additional checks and reveals the content of memory beyond the designated buffer. This allowed the POC to obtain an internal object address, which it can then use to exploit  CVE-2023-28229 in a more reliable way.

Microsoft's patch for this issue added a forced zero-termination of the user-supplied string such that subsequent reading from the buffer could not extract information beyond the bounds of the buffer.

We chose a similar but more minimalistic approach by setting the HEAP_ZERO_MEMORY flag to the RtlAllocateHeap call, causing the allocated space to be initialized with zeroes.

Source code of our patch:

 

 

MODULE_PATH "..\AffectedModules\ncryptprov.dll_10.0.19041.2193_Win10-21H1_64-bit_u2022-12\ncryptprov.dll"
PATCH_ID 1519
PATCH_FORMAT_VER 2
VULN_ID 7795
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x6bf6
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
            
    code_start
        add r8, 0x2   ; increase the size of the allocated buffer
        mov edx, 0x8  ; set the HEAP_ZERO_MEMORY flag for the upcoming
                      ; RtlAllocateHeap  call
    code_end
patchlet_end

 

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1 
2. Windows 10 v20H2
   
3. Windows 10 v2004
4. Windows 10 v1909
5. Windows 10 v1809
6. Windows 10 v1803
   

 

We were unable to reproduce this issue on Windows 7 and Server 2008 R2, and believe it is not exploitable there.

 

Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank @k0shl of Cyber Kunlun for sharing their proof of concept, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

 

Micropatches Released For Windows Error Reporting Service Elevation of Privilege (CVE-2023-36874)

  

With July 2023 Windows Updates, Microsoft brought a fix for CVE-2023-36874, a local privilege escalation vulnerability in Windows Error Reporting Service that was found both by Google TAG and CrowdStrike to be exploited in the wild in the previous month.

When security researcher Filip Dragovic released a proof of concept for this issue, we could reproduce it and start working on a patch.

The Vulnerability

In short, the Windows Error Reporting Service has a number of functions exposed via its RPC interface, so a local process can ask it to submit a chosen error report via function SubmitReport. This function impersonates the calling process' user and at some point launches wermgr.exe, one of the WER executables. Normally, wermgr.exe would be launched from C:\Windows\System32\, but since the service is impersonating the caller (i.e., the attacker), the CreateProcess function honors any symbolic links the caller may have in place. The attacker can, for instance, create a symbolic link mapping C:\ to an arbitrary location such as C:\Users\public\test , which will be used by the CreateProcess call. Consequently, the WER service would launch C:\Users\public\test\Windows\System32\wermgr.exe, attacker's executable with the same name - and according to the documented behavior of CreateProcess, the executable would be launched with the token of the service (not the impersonation token). In other words: as Local System.

 

The Official Patch

Microsoft's fix for this issue was very simple: they effectively disabled the SubmitReport function by immediately returning error "Not implemented" (0x80004001). This means that it is no longer possible to submit an error report via RPC - and perhaps this was never really needed anyway.

Our Micropatch

Our micropatch is logically identical to Microsoft's, and produces the same behavior.

MODULE_PATH "..\AffectedModules\wercplsupport.dll_10.0.17134.1967_Win10-1803_32-bit_u2021-05\wercplsupport.dll"
PATCH_ID 1488
PATCH_FORMAT_VER 2
VULN_ID 7774
PLATFORM win32
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x82ac
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT wercplsupport.dll!0x82eb        
    code_start
        
        mov eax, 80004001h   ; Error code for "Not Implemented"
        jmp PIT_0x82eb       ; Jump directly to end of function
       
    code_end
patchlet_end

 

Let's see our micropatch in action. With 0patch disabled, the POC manages to create a new user "test" on the computer by launching a fake C:\Users\public\test\Windows\System32\wermgr.exe. With 0patch enabled, the POC fails to do that because wermgr.exe is not being launched from function SubmitReport at all.

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1 
2. Windows 10 v20H2
   
3. Windows 10 v2004
4. Windows 10 v1909
5. Windows 10 v1809
6. Windows 10 v1803
   

 

We were unable to reproduce this issue on Windows 7 and Server 2008 R2, and believe it is not exploitable there.

 

Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Filip Dragovic for sharing their proof of concept, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.

 

Micropatches Released For Windows Search Remote Code Execution (CVE-2023-36884)

 

Alongside July 2023 Windows Updates, Microsoft revealed the existence of a 0day that was detected in the wild and assigned it CVE-2023-36884. Without issuing a patch, they titled their original advisory "Office and Windows HTML RCE vulnerability" as exploitation was performed using malicious Word documents, and provided workarounds that could block exploitation.

Very little information was publicly available and exploit samples that were referenced by those who claimed to be in the know seemed convoluted, comprising numerous exploits of old known vulnerabilities. The main source of useful information was security researcher Will Dormann who invested a great deal of effort in publicly dissecting many of these samples and reviewing numerous sources to meticulously separate the wheat from the chaff (see his super long Twitter thread).

In absence of sufficient information on the vulnerability itself, we initially decided to issue a patch that  implemented one of the most effective workarounds recommended by Microsoft - the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION mitigation for all Office executables. This patch - free for everyone as the issue was still an unpatched 0day - enabled said workaround on all 0patch customers' computers so they didn't have to do that manually (or even know about this 0day).

 

The Official Patch

In August, Microsoft finally provided a patch for CVE-2023-36884, and updated their advisory to reveal that the issue lied in Microsoft Search and that "An attacker can plant a malicious file evading Mark of the Web (MOTW) defenses which can result in code execution on the victim system."

This, combined with Will's analysis of the changed behavior in Windows ZIP file extraction (mostly the latter, really), led us to conclusion that Microsoft's patch for CVE-2023-36884 was focused on randomizing the temporary path where files from a ZIP archive are extracted. Before the August update, a file.txt file opened directly from an archive.zip ZIP file would be extracted to a location like:

C:\Users\username\AppData\Local\Temp\Temp1_archive.zip\file.txt

For a local exploit script running on user's computer this is a predictable location, and if extraction process was terminated by exploit code at the right time, Windows would not put the Mark of the Web (MotW) on the file even if the ZIP file came from the Internet and should not be trusted. The absence of this mark on the extracted file would later result in no security warning when the file was opened. (In the actual exploit, the extracted file would be an executable launched without any warning.)

After the August Windows Update, file extraction was different. The same file would be extracted to this location:

C:\Users\username\AppData\Local\Temp\Temp1710d72f-7438-40d0-be9b-52f7e0651fe9_archive.zip\file.txt

Whereby the added GUID part is random and different each time. This blocks exploitation because the exploit code cannot guess the correct path of the extracted file and can therefore not launch it.

We located Microsoft's patch that introduced this change in zipfldr.dll, inside the CTempFileNameArray::_TryCreatingInPath function.

 

 

Our Micropatch

Our micropatch is logically identical to Microsoft's, and produces the same behavior with extracted files.

PATCH_ID 1487
PATCH_FORMAT_VER 2
VULN_ID 7772
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x18514
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    PIT zipfldr.dll!0x180a0,zipfldr.dll!0x186ad,rpcrt4.dll!UuidCreate,rpcrt4.dll!RpcStringFreeW,rpcrt4.dll!UuidToStringW
    ;zipfldr.dll!0x180a0 __int16 *ConstructString(HINSTANCE, unsigned int, ...)
    ;zipfldr.dll!0x186ad ErrorBlock
    
    code_start

        sub rsp, 0x50             ;Create shadowspace and 2 variables
       
        mov [rsp+0x48], rcx       ;Save rcx
        mov [rsp+0x40], rdx       ;Save rdx
        mov [rsp+0x38], r9        ;Save r9
       
       
        lea rcx, [rsp+0x28]       ;Move var1 to rcx to receive UUID
        call PIT_UuidCreate       ;Call UuidCreate
        cmp eax, 0                ;Check if call succeeded
        jne ERROR                 ;Jump to error block if result != 0
       
        lea rdx, [rsp+0x20]       ;Move var2 to rdx to receive pointer to UUID_STRING
        lea rcx, [rsp+0x28]       ;Move var1 with UUID to rdx
        call PIT_UuidToStringW    ;Call UuidToStringW to convert UUID on var1 to UUID_STRING and move it to var2
        cmp eax, 0                ;Check if the call succeeded
        jne ERROR                 ;Jump to error block if result != 0
       
        mov rcx, [rsp+0x48]       ;Restore rcx
        mov rdx, [rsp+0x40]       ;Restore rdx
        mov r9, [rsp+0x38]        ;Restore r9
        mov r8, [rsp+0x20]        ;Replace r8 with UUID_STRING from var2
        call PIT_0x180a0          ;Call ConstructString that output a full path pointer to rax
        mov qword[rsp+0x38], rax  ;save rax for later
       
        lea rcx, [rsp+0x20]       ;Get the pointer to UUID_STRING from var2 and move it to rcx
        call PIT_RpcStringFreeW   ;Free the UUID_STRING buffer
       
        mov rax, [rsp+0x38]       ;Restore rax we saved earlier
       
        jmp END                   ;Continue normal execution
       
    ERROR:                        ;Error block
        add rsp, 0x50             ;Restore the stack pointer
        jmp PIT_0x186ad           ;Jump to the error block
       
    END:                          ;Normal execution
        add rsp, 0x50             ;Restore stack pointer
       
    code_end
    
patchlet_end

 

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1 
2. Windows 10 v20H2
   
3. Windows 10 v2004
4. Windows 10 v1909
5. Windows 10 v1809
6. Windows 10 v1803
   
7. Windows 7 (without ESU, with ESU year 1, 2 and 3)
8. Windows Server 2008 R2 (without ESU, with ESU year 1, 2 and 3)

 

Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Will Dormann for his extensive analysis of exploit samples, related publications, and Microsoft's patch, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.