Patching problems: The “return” of a Windows Themes spoofing vulnerability
Despite two patching attempts, a security issue that may allow attackers to compromise Windows user’s NTLM (authentication) credentials via a malicious Windows themes file still affects Microsoft’s operating system, 0patch researchers have discovered.
The path to discovery
The story starts with CVE-2024-21320, a Windows Themes spoofing vulnerability that was reported by Akamai security researcher Tomer Peled and fixed by Microsoft in January 2024.
The vulnerability could be triggered by a .theme file that specified a network file path for some of the theme properties (specifically BrandImage and Wallpaper), which would make Windows automatically send authenticated network requests to an attacker’s machine.
The targeted user would not even have to click or open the file for the attack to work: “Merely seeing a malicious theme file listed in a folder [in Windows Explorer] or placed on the desktop would be enough for leaking user’s credentials without any additional user action,” 0patch researchers explained.
Microsoft’s patch worked, but it leveraged the PathIsUNC function to check for and disregard network file paths, and this check could be bypassed (as security researcher James Forshaw pointed out many years ago).
Microsoft responded by issuing a new patch (CVE-2024-38030) that turned out to be incomplete, as it missed an additional instance of the same problem.
This bug variation was discovered by 0patch researchers and reported to Microsoft, whose spokesperson told Help Net Security that they “will take action as needed to help keep customers protected.”
Micropatches are available now
0patch’s major contribution to cybersecurity lays in the development of micropatches for vulnerabilities that are either exploited in the wild or have no official vendor patches. The micropatches are delivered to users via an endpoint agent.
“When we patch a vulnerability, we rely on our knowledge, make our own experiments, but also look at how the vendor has patched it (if a patch is available). If the vendor’s patch seems reasonable, we make our logically equivalent, otherwise we take our own approach,” says Mitja Kolsek, CEO at Acros Security – the creators of 0patch.
“CVE-2023-23397 is a good example of that: Microsoft decided to fix a really obscure and bizzare functionality in Outlook (attacker’s email can include a reference to a sound file that gets played when you receive it). We decided to just remove the functionality as we suspected that any fix for it was likely to be incomplete. Which turned out to be true as Microsoft has had to re-fix the issue three times (so far).”
In the case of CVE-2024-21320, they “trusted” Microsoft’s patch too quickly, he says. But CVE-2024-38030 made them realize a different approach is needed.
“We investigated all paths that get requested while viewing a theme file and wanted to find a common place in code they all go through. We did find such a function and patched it, but it did not really cover all cases so we had to keep additional patches on the functions that Microsoft (and us) have originally patched as well,” Kolsek told Help Net Security.
“The location of Microsoft’s patch(es) was – in our view – well chosen for the first two known vulnerable parameters. With the zero-day we have added to the pile now, they may choose to move the patch to the function we’re patching now. But, if they do, they should keep the original patches for CVE-2024-38030 or they’re up for yet another round of patching.”
With details about CVE-2024-21320, CVE-2024-38030 and a PoC for the former being publicly available, other motivated security researchers or attackers may be able to pinpoint the zero-day unearthed by 0patch. “In fact, I’d be very surprised if we were the only ones finding this,” Kolsek added.
Until Microsoft delivers the fix, all 0patch users will get this latest micropatch, whether they use one of the supported Windows versions or legacy ones that the company has “security-adopted“.
“Note that patches were only created for Windows Workstation but not for Windows Server. This is because for Windows Themes to work on a server, the Desktop Experience feature needs to be installed (it’s not by default). In addition, for credentials leak to occur on a server it’s not enough just to view a theme file in Windows Explorer or on desktop; rather, the theme file needs to be double-clicked and the theme thus applied,” 0patch researchers explained.
“Actually applying a Windows theme from an untrusted source is, from the security perspective, not very different from launching an untrusted executable. Getting a user to view a theme file in Windows Explorer, on the other hand, may be a simple matter of forcing a download of the theme file while the user is on attacker’s web page, then waiting for the user to open the Downloads folder (depending on the view type of the Downloads folder).”