In December of 2022, Ben Barnea of Akamai posted an X thread about a bug they had found in Windows Local Service Manager (LSM) that can lead to local privilege escalation from regular user account to Local System. Ben discovered that code in LSM was missing a return value check after a call is made to RpcImpersonateClient to impersonate the caller: a failed impersonation attempt would therefore keep the code running as Local System.
After trying out several ideas to make the RpcImpersonateClient function fail, Ben succeeded with an interesting race condition trick, changing the caller's token after the call has been accepted by LSM, but before the impersonation is attempted.
Microsoft assigned this issue CVE-2023-21771, and issued a fix for it with January 2023 Windows Updates.
Ben's X thread and proof of concept
allowed us to reproduce the issue and create a micropatch for
users of legacy Windows systems, which are no longer receiving security
updates from Microsoft.
Microsoft's Patch
Microsoft patched this issue by adding a check for the return value of RpcImpersonateClient call, and skipping the processing if the call fails.
cmp rax, 0x0 ;check if RpcImpersonateClient returned 0 for success jne PIT_0x58a7a ;if not, jump to the error block
code_end patchlet_end
Micropatch Availability
Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:
Windows 10 v21H1 - fully updated
Windows 10 v2004 - fully updated
Older Windows 10 versions, Windows 7 and Server 2008 R2 were not affected by this issue. Newer Windows 10 versions received an official patch from Microsoft.
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 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 Ben Barnea of Akamai 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.
January 2024 Windows Updates brought a patch for CVE-2024-21320, a privilege escalation vulnerability in Windows. The vulnerability allows a remote attacker to acquire user's NTLM credentials when the victim simply downloads a Theme file or views such file in a network folder.
Security researcher Tomer Peled of Akamai discovered this issue, reported it to Microsoft, and later published a detailed article along with a proof of concept.
These allowed us to reproduce the issue and create a micropatch for
users of legacy Windows systems, which are no longer receiving security
updates from Microsoft.
The Vulnerability
In short, the Theme file format allows a .theme file to specify two images, BrandImage and Wallpaper, which can also be on a remote network share and which Windows Explorer will automatically try to load when a Theme file is downloaded or displayed in a folder. A malicious Theme file could have these images point to a shared folder on attacker's computer, where user's NTLM credentials would be harvested and used for impersonating the user.
Note that Theme files are already generally considered "dangerous", and you cannot, for example, receive one as an email attachment through Outlook any more than you cannot receive an attached EXE file. This is for a good reason: a Theme file can specify a malicious screen saver, which is essentially an EXE file, so double-clicking such Theme file would be effectively as dangerous as double-clicking a malicious EXE. The vulnerability at hand, in contrast, is about simply downloading or viewing a Theme file in a folder, which is a much easier thing for an attacker to achieve than getting the user to actually apply a malicious theme.
Microsoft's Patch
As Tomer notes in their article, Microsoft patched this bug by implementing a registry value called DisableThumbnailOnNetworkFolder, which controls a security check for both image paths by calling PathIsUNC. In case DisableThumbnailOnNetworkFolder is 1 and PathIsUNC returns true, images are not loaded if located on a shared folder.
Our Micropatch
Our patch is logically identical to Microsoft's, only that the decision to block images on network path is hard-coded and not configurable via the registry. The patch consists of two small patchlets located in ThumbnailLoadImage and CFileSource::s_LoadPIDLFromPath functions of themeui.dll, both calling PathIsUNC and preventing the image from loading if its path is on a network share.
push dword[ebp+0x8] ;push patch string pointer as first arg call PIT_PathIsUNCW ;call PathIsUNCW to check if the string from ;the theme file is a UNC path cmp eax, 0x0 ;check if the function returned TRUE or FALSE jne PIT_0xbc00 ;if TRUE, jump to an error block
push dword[ebp-0x294] ;push patch string pointer as first arg call PIT_PathIsUNCW ;call PathIsUNCW to check if the string from ;the theme file is a UNC path cmp eax, 0x0 ;check if the function returned TRUE or FALSE jne PIT_0x4c26 ;if TRUE, jump to an error block
code_end patchlet_end
It is worth noting that neither Microsoft's nor our patch prevents the remote loading of these images in case the user actually opens a Theme file (e.g., by double-clicking on it) in order to apply the theme. While Windows do show a Mark-of-the-Web warning in such case for Theme files originating from the Internet, it would make little sense to add code for preventing NTLM leaks there because a malicious Theme file would probably install a malicious screen saver instead of just leak user's credentials.
Let's
see our
micropatch in action.
The attacker's computer on the right side of the video is waiting to collect user's NTLM credentials. A Windows user on the left opens the Downloads folder where a malicious Theme file was previously automatically downloaded while they visited attacker's web site. With 0patch disabled, just viewing the Theme file in the Downloads folder results in Windows Explorer trying to load the two images from attacker's computer, resulting in their NTLM credentials being captured there.
With 0patch enabled, viewing a Theme file no longer results in leaking user's NTLM credentials.
Micropatch Availability
Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:
Windows 11 v21H1 - fully updated
Windows 10 v20H2 - fully updated
Windows 10 v2004 - fully updated
Windows 10 v1909 - fully updated
Windows 10 v1809 - fully updated
Windows 10 v1803 - fully updated
Windows 7 - no ESU, ESU 1 to 3
Windows Server 2012 - fully updated
Windows Server 2012 R2 - fully updated
Windows Server 2008 - no ESU, ESU 1 to 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 Tomer Peled of Akamai 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.
In February 2024, still-Supported Microsoft Outlook versions got an official patch for CVE-2024-21413,
a vulnerability that allowed an attacker to execute arbitrary code on user's computer when the user opened a malicious hyperlink in attacker's email.
The vulnerability was discovered by Haifei Li of Check Point Research, who also wrote a detailed analysis. Haifei reported it as a bypass for an existing security mechanism, whereby Outlook refuses to open a file from a shared folder on the Internet (which could expose user's NTLM credentials in the process). The bypass works by adding an exclamation mark ("!") and some arbitrary text to the end of the file path, which turns the link into a "Moniker link". When opening moniker links, Windows download the file, open it and attempt to instantiate the COM object referenced by the text following the exclamation mark. An immediate result of this is that an SMB request is automatically sent to the remote (attacker's) server, revealing user's NTLM credentials. An additional risk is that this could lead to arbitrary code execution.
Official Patch
Microsoft patched this issue by effectively cutting off "Moniker link" processing for Outlook email hyperlinks. They did this in an unusual way, however. In contrast to their typical approach - changing the source code and rebuilding the executable file -, they ventured deep into "our" territory and hot-patched this issue with an in-memory patch. Hmm, why would they do that?
The answer lies in the fact that the behavior they wanted to change is implemented in ole32.dll, but this DLL is being used by many applications and they didn't want to affect them all (some of them may rely on moniker links being processed). So what they did was use their Detours package to replace ole32.dll's MkParseDisplayName function (the one parsing moniker links) with an essentially empty function - but only in Outlook.
Our Micropatch
While
still-supported Microsoft Office versions have received the official
vendor fix for this vulnerability, Office 2010 and 2013 - which we have security-adopted - are also vulnerable. In order to
protect our users, we have created our own micropatch for this
vulnerability.
We could implement a logically identical patch to Microsoft's by patching ole32.dll and checking in the patch if the running process is outlook.exe - but since ole32.dll is a Windows system file, this would require creating a patch for all Windows versions and then porting the patch every time this file is updated by Windows updates in the future. Not ideal.
Instead, we decided to take a different route. When parsing the hyperlink, Outlook at some point calls the HlinkCreateFromString function, which then calls further into ole32.dll and eventually to MkParseDisplayName, which we wanted to cut off.
A quick detour (pun intended) of our own here: The HlinkCreateFromString documentation states the following:
[Never pass strings from a non-trusted source. When creating a hyperlink with HlinkCreateFromString, the pwzTarget parameter is passed to MkParseDisplayNameEx. This call is safe, but the less safe MkParseDisplayName will be called for the string under the following circumstances:
Not a file or URL string. Does not contain a colon or forward slash. Less than 256 characters.
A pwzTarget string of the form "@progid!extra" will instantiate the object registered with the specified progid and, if it implements the IMoniker interface, invoke IMoniker::ParseDisplayName with the "extra" string. A malicious object could use this opportunity to run unexpected code. ]
This, we believe, is the reason why Microsoft categorized the flaw at hand as "remote code execution."
Okay, back to our patch. There exists a function very similar to HlinkCreateFromString called HlinkCreateFromMoniker. This function effectively does the same with a moniker as the former does with a string, but without ever calling MkParseDisplayName. Our patch now simply replaces the call to (unsafe) HlinkCreateFromString with a call to (safe) HlinkCreateFromMoniker using a moniker that it first creates from the hyperlink string. To minimize the impact, this is only done for "file://" URLs containing an exclamation mark.
Micropatch Availability
The micropatch was written for the following security-adopted versions of Office with all available updates installed:
Microsoft Office 2013
Microsoft Office 2010
This
micropatch has already been distributed to, and applied on, all
online 0patch Agents in PRO or Enterprise accounts (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 Office 2010 or
2013, 0patch will make sure such vulnerabilities won't be exploited on
your computers - and you won't
even have to know or care about updating.
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.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Haifei Li for sharing their analysis, which allowed us to
create a micropatch and protect our users against this attack. We also
encourage all security researchers to privately share their analyses
with us
for micropatching.
In December 2023, still-Supported Microsoft Outlook versions got an official patch for CVE-2023-35636, a vulnerability that allowed an attacker to coerce user's Outlook to authenticate to attacker's remote server, revealing user's NTLM hash in the process.
The vulnerability was discovered by Varonis researcher Dolev Taler, who wrote up a detailed article about it. In summary, a calendar file attached to an email can point to any URL, including a UNC path on a remote computer - and when the user tried to open such file, their computer would connect to the remote network share and, upon request, authenticate to it and reveal user's NTLM hash.
Microsoft's December patch changed Outlook's behavior such that whenever an ICS (calendar) file is opened from a specified location (instead of as an attachment), Outlook would display a security warning alerting the user about the potentially harmful content and asking their approval to continue.
While
still-supported Microsoft Office versions have received the official vendor fix for this vulnerability, Office 2010 and 2013 - which we have security-adopted - are also vulnerable. In order to
protect our users, we have created our own micropatch for this
vulnerability.
Our patch is logically identical to Microsoft's.
Micropatch Availability
The micropatch was written for the following security-adopted versions of Office with all available updates installed:
Microsoft Office 2013
Microsoft Office 2010
This
micropatch has already been distributed to, and applied on, all
online 0patch Agents in PRO or Enterprise accounts (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 Office 2010 or
2013, 0patch will make sure such vulnerabilities won't be exploited on
your computers - and you won't
even have to know or care about updating.
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.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Dolev Taler for sharing their analysis, which allowed us to
create a micropatch and protect our users against this attack. We also
encourage all security researchers to privately share their analyses
with us
for micropatching.
We recently delivered patches for the "LogCrusher" vulnerability that allows an attacker to remotely crash Windows Event Log service on some older Windows systems that we have security-adopted. Varonis researcher Dolev Taler, who found and reported that issue to Microsoft, also found another related issue they called "OverLog" (described in the same article).
OverLog allows a remote attacker to backup Internet Explorer logs to a chosen location on the remote computer, which can lead to all disk space being consumed.
OverLog was officially patched by Microsoft in October 2022 and assigned CVE-2022-37981.
Analysis
This one was a bit tougher to crack as the flaw is a missing privilege check in the server-side BackupEventLog function. As stated by Varonis and Microsoft in their official documentation, the BackupEventLog function allegedly checks if the calling user possesses the SE_BACKUP_NAME/SeBackupPrivilege privilege, and errors out if they don't. Varonis discovered that these checks in fact did not exist, so any user who could access an event source could call this function and create a horde of files on the target computer.
Although creating files is the intended functionality of the BackupEventLog function (it should allow privileged users the creation of log backups), it contains no failsafe for when the disk space is low. This can allow a remote user to effectively DOS any machine in the same domain that contains a writable location for their account.
Microsoft patched this by restricting the Internet Explorer log interface access to deny non-admin users from opening it and performing such operations. The following images show the effect of their patch.
Old security descriptor, allowing everyone access to Internet Explorer logs
New security descriptor, only allowing local and domain administrators to access Internet Explorer logs
Our Micropatch
We wanted to patch this in a way that doesn't permanently affect our users' machines and allows the patch to be applied without any restarts. We decided to create a patch that would bring the behavior "into spec" set by Microsoft's documentation on the BackupEventLog function. Our patch is applied directly to this function and checks the calling user's token for the SE_BACKUP_NAME/SeBackupPrivilege privilege. If the user does not possess it, the function errors out and doesn't create the backup file.
It is also worth noting that even empty logs with incorrect security descriptors are vulnerable to this attack. Our tests showed that a backup of an empty log creates a file with 68KB of data, which can still be used to DOS a machine given some time and patience.
While supported Windows versions got an official patch for OverLog in October 2022, several of our security-adopted versions haven't. We therefore made our own patch for these.
Our
patch is logically identical to Microsoft's.
Micropatch Availability
Micropatches were written for:
Windows 10 v2004 - fully updated
Windows 10 v1909 - fully updated
Windows 10 v1809 - fully updated
Windows 10 v1803 - fully updated
Windows 7 - no ESU, ESU1, ESU2
Windows Server 2008 R2 - no ESU, ESU1, ESU2
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.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Dolev Taler of Varonis
for
sharing vulnerability details, which allowed us to reproduce it and
create a micropatch. We also
encourage all security researchers who want to see their vulnerabilities
patched to share them with us or alert us about their publications.
The interesting parts of this post were written by our patching expert Blaz Satler ;)
While recently patching the (still 0day) "EventLogCrasher" vulnerability, we came across another similar vulnerability published in January 2023 by Dolev Taler, a security researcher at Varonis.
Dolev's article details two Windows Event Log-related vulnerabilities they had reported to Microsoft in May 2022: one ("LogCrusher") allowing a remote attacker to crash the Event Log service on any computer in a Windows domain, and the other ("OverLog") allowing for remotely filling up the disk on any domain computer by misusing a log backup function. Both vulnerabilities were targeting the Internet Explorer log that had permissions set such that any domain user could access it remotely.
Dolev's article states that OverLog was officially patched by Microsoft in October 2022 and assigned CVE-2022-37981, while the fate of LogCrusher remained unclear. Interestingly though, the title of Microsoft's advisory was "Windows Event Logging Service Denial of Service Vulnerability", which would match LogCrusher more than OverLog. In addition, it stated "the performance can be interrupted and/or reduced, but the attacker cannot fully deny service," which describes what happens with Event Log service when it crashes (see our EventLogCrasher post for details on that) and doesn't make much sense in the context of OverLog.
And what did the October 2022 patch do exactly? It simply changed the permissions on the Internet Explorer log such that non-administrative domain users could no longer access it. This may explain why, according to Dolev's article, Microsoft "closed “LogCrusher” [and] stated that they rated it as moderate severity because it required an administrator privilege [...] to exploit." Perhaps at that point, they had already decided to close the Internet Explorer log for non-admins, which would also protect the LogCrusher from non-admin exploitation.
That would make sense. But it wouldn't be exactly in line with Microsoft's documentation: the BackupEventLog capability, affected by OverLog, should only be available to users with SE_BACKUP_NAME privilege. Prior to the patch, all domain users had access (which is wrong), but after the patch, only Administrators have access (which is also not aligned with the documentation; non-admin users can be given SE_BACKUP_NAME privilege, too).
In any case, we were still interested in LogCrusher, so we did a quick analysis and learned the following:
LogCrusher is very similar to EventLogCrasher in terms of exploitation: providing a NULL string to the remote Event Log service via RPC results in memory access violation which crashes the service. In addition, attacker's required access is the same in both cases: any domain user can remotely crash Event Log service on all domain computers. The impact of both vulnerabilities is therefore comparable.
LogCrusher got patched with November 2022 Windows updates, one month after CVE-2022-37981. We "diffed" Windows updates and noticed a change to wevtsvc.dll that removed this vulnerability by adding a check for a NULL pointer as shown below. (Which is what our patch for EventLogCrasher does as well, and Microsoft's future patch for it surely will, too.)
Microsoft assigned no CVE to LogCrusher in November 2022 updates, and extended no public acknowledgment to the reporting researcher for it. (See this list of all CVEs patched in November 2022 - nothing related to Event Log service.) We find it likely that Microsoft decided to cover both OverLog and LogCrusher with CVE-2022-37981, although these are two distinct vulnerabilities.
Let's look at Microsoft's November 2022 patch for LogCrusher in function PerformClearRequest (wevtsvc.dll): at some point in the code, the pointer to the "Backup file name" string, provided by the remote user, is loaded in register rcx. But the attacker was able to make this a NULL pointer, and before the patch, this pointer was blindly used in a subsequent mov r9, [rcx+8] instruction - which clearly caused an access violation if rcx was NULL. Microsoft's patch added a check for NULL and now puts a NULL into r9 if that happens. Function ClearChannelLogs, which then uses this value, is expecting the possibility of a NULL argument, so all is well.
Our Micropatch
While supported Windows versions got an official patch for LogCrusher in November 2022, several of our security-adopted versions haven't. We therefore made our own patch for these.
Our
patch is logically identical to Microsoft's.
Micropatch Availability
Micropatches were written for:
Windows 10 v2004 - fully updated
Windows 10 v1909 - fully updated
Windows 10 v1809 - fully updated
Windows 10 v1803 - fully updated
Windows 7 - no ESU, ESU1, ESU2
Windows Server 2008 R2 - no ESU, ESU1, ESU2
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.
To learn more about 0patch, please visit our Help Center.
We'd like to thank Dolev Taler of Varonis for
sharing vulnerability details, which allowed us to reproduce it and
create a micropatch. We also
encourage all security researchers who want to see their vulnerabilities patched to share them with us or alert us about their publications.
December 2023 Windows Updates brought a patch for CVE-2023-36003, a privilege escalation vulnerability in Microsoft Windows XAML diagnostics API. The vulnerability allows a low-privileged Windows process to execute arbitrary code in a higher-privileged process running in the same user session, and is therefore useful for elevating from a non-admin to admin user.
Security researcher Michael Maltsev, who found this vulnerability and reported it to Microsoft in July 2023, wrote a detailed article and published a POC. These allowed us to reproduce the issue and create a micropatch for users of legacy Windows systems, which are no longer receiving security updates from Microsoft.
Our Micropatch
As Michael has already noted, there were two changes in the December version of Windows.UI.Xaml.dll, but only one seems to be related to this issue: namely the one that sets the security descriptor of the process's XAML diagnostics API interface to the current process's integrity level. Consequently, only processes that have at least the same integrity level as the target process will be allowed to utilize the affected functionality (and have arbitrary code executed in the target process).
Our micropatch is functionally identical to Microsoft's.
Let's see our
micropatch in action. A local unprivileged user launches the POC, which periodically attempts to locate a privileged process to sent the offensive XAML diagnostics request to. Another process (Windows Magnifier) is then launched as administrator; the POC quickly finds it and requests that it loads a malicious DLL that then spawns a new command window - as Administrator. This demonstrates that arbitrary code could be executed in the privileged process. With 0patch enabled, the POC fails to attack the privileged process as our patch makes sure that only high-integrity processes could send XAML diagnostics requests to the high-integrity process (Magnifier).
Note that in a real attack, the attacker would actually be malware silently running in the background, waiting for the user to launch another process with higher privileges and then attacking that process.
Micropatch Availability
Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:
Windows 11 v21H1 - fully updated
Windows 10 v21H1 - fully updated
Windows 10 v20H2 - fully updated
Windows 10 v2004 - fully updated
Windows 10 v1909 - fully updated
Windows 10 v1809 - fully updated
Windows 10 v1803 - fully updated
We were unable to reproduce the vulnerability on Windows Server 2012, Windows 7 and Server 2008 R2.
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 Michael Maltsev 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.
