Friday, November 24, 2023

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


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"
VULN_ID 7803
 PIT msvcrt.dll!wcsstr,msvcrt.dll!_wtoi,acecore.dll!0x195637,shlwapi.dll!StrStrIW


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



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, and email 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.


    Thursday, November 16, 2023

    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 for a free trial or demo.


    Friday, November 10, 2023

    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, and email 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.