Wormable Windows HTTP hole – what you need to know

Yesterday was the first Patch Tuesday of 2022, with more than 100 security bugs fixed.

We wrote up an overview of the updates, as we do every month, over on our sister site news.sophos.com: First Patch Tuesday of 2022 repairs 102 bugs.

For better or for worse, one update has caught the media’s attention more than any other, namely CVE-2022-21907, more fully known as HTTP Protocol Stack Remote Code Execution Vulnerability.

This bug was one of seven of this month’s security holes that could lead to remote code execution (RCE), the sort of bug that means someone outside your network could trick a computer inside your network into running some sort of program without asking for permission first.

No need to log in up front; no pop-up warning at the other end; no Are you sure (Y/N)? questions.

Just give the order, and the malware runs.

That’s the theory, anyway.

RCE bugs considered wormable

One thing to remember about most RCE vulnerabilities is that if you can attack someone else’s computer from outside and instruct it to run a malicious program of your choice…

…then it’s possible, perhaps even probable, that you could tell it to run the very same program that you yourself just used to launch your own attack.

In other words, you might be able to use the vulnerability to locate and infect Victim 1 with malicious program W that instructs Victim 1 to locate and infect Victim 2 with malicious program W that instructs Victim 2 to locate and innfect Victim 3… and so on, perhaps even ad infinitum.

In an attack like this, we give the program W a special name: we call it a worm.

Worms form a proper subset of a type of malicious software (or malware for short) known generally as computer viruses, the overarching term for self-replicating malware of any sort.

This means that most RCE bugs are, in theory at least, wormable, meaning that they could potentially be exploited to initiate a chain of automatic, self-spreading and self-sustaining malware infections.

The reasoning here is obvious: if an RCE bug allows you to run an arbitrary program of your own choice on someone else’s computer, such as popping up CALC.EXE or launching NOTEPAD, then it almost certainly allows you to run a specific program of your choice, such as a worm.

Some bugs are more wormable than others

As you can imagine, some classes of RCE bug are considered much more wormable than others, especially bugs that can be triggered directly via a simple network interaction.

That was a risk of considerable concern in the recent Log4Shell saga, where a single booby-trapped web request with some curious but otherwise unexceptionable ASCII text in it could trigger arbitrary remote code execution.

Unfortunately, CVE-2022-21907 is a bug in the same category, with Microsoft’s own security bulletin explicitly saying the following in its FAQ section:

*How could an attacker exploit this vulnerability?*

In most situations, an unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (HTTP.sys) to process packets.

*Is this wormable?*

Yes. Microsoft recommends prioritizing the patching of affected servers.

Does this have anything to do with IIS?

Where and how does the HTTP Protocol Stack get activated?

Is this an issue unique to Windows servers, as Microsoft’s bulletin implies when it talks about patching “affected servers”?

Does the attack depend on you having a known web server such as Microsoft IIS (Internet Information Services) already installed and activated?

The answers to these questions are as follows:

• HTTP.sys is part of Windows and is available to any program that uses ASP.NET.
• HTTP.sys works on Windows 7 clients and later.
• HTTP.sys works on Windows 2008 R2 servers and later.
• HTTP.sys is not part of IIS, and doesn’t require IIS to be installed.

The last point above makes it clear that that you may have any number of apps in use – perhaps without realising it – that provide an HTTP-based interface via HTTP.sys, whether you have deployed IIS or not.

In fact, Microsoft’s own documentation notes that “HTTP.sys is useful […] where there’s a need to expose the server directly to the Internet without using IIS.”

Indeed, IIS is based on HTTP.sys, not the other way around, as Microsoft explains:

HTTP.sys is mature technology that protects against many types of attacks and provides the robustness, security, and scalability of a full-featured web server. IIS itself runs as an HTTP listener on top of HTTP.sys.

Simply put: you could, in theory, have apps installed, even on a desktop or laptop computer, that provide some sort of web-based interface that is serviced by the HTTP.sys driver code.

The silver lining, for some users at least, is that the part of HTTP.sys that contains the CVE-2022-21907 bug:

• Affects only Windows 10 and later desktop versions.
• Affects only Windows Server 2019 and later server versions.
• Is not enabled by default on Windows Server 2019.
• Can be immunised against this bug simply by installing the January 2022 Patch Tuesday updates.

As far as we can tell, the reason that this vulnerability isn’t present in earlier versions of Windows and Windows Server is that the bug was found in the code that deals with HTTP Trailers (these are like HTTP Headers, except that they are sent after the HTTP data instead of before it); HTTP Trailer support was only added after support for HTTP/2; and HTTP/2 support only arrived in the Windows 10 era.

What to do?

If you are truly unable to patch right away, and if you know that you are not running (or at least do not intend to run) any web-based software that uses HTTP.sys, you can temporarily block HTTP.sys on your computer by setting the following registry entry:

HKLM\SYSTEM\CurrentControlSet\Service\HTTP\Start = DWORD(4)

The usual value of this registry entry is 3, denoting “start on demand”; changing the value to 4 marks the driver as “service disabled”.

After a reboot, you can check the status of HTTP.sys from a regular command prompt with the SC (Service Control) command:

C:\Users\duck> sc query HTTP
SERVICE_NAME: HTTP 
   TYPE               : 1  KERNEL_DRIVER  
   STATE              : 1  STOPPED    <--before applying the registry hack above, this line said: "4 RUNNING"
   WIN32_EXIT_CODE    : 1077  (0x435)
   SERVICE_EXIT_CODE  : 0  (0x0)
   CHECKPOINT         : 0x0
   WAIT_HINT          : 0x0
C:\Users\duck>

Note that we have tested this workaround in only the most cursory fashion. We installed Server 2022, enabled IIS, created a home page and verified from another computer that it worked. We changed the service start value for HTTP to 4, as suggested above, and rebooted. Our IIS server was no longer accessible. We reverted the registry entry to 3, rebooted once more and verified that IIS came back to life automatically. From this we infer that disabling the HTTP service does indeed block HTTP-based network access to higher-level software that might otherwise be exposed to this bug, and we assume that this renders the vulnerability temporarily “untriggerable”.

Our primary recommendations are:

• Assume that all RCE vulnerabilities are wormable. As mentioned, bugs than can be triggered directly via routine network connections pose by far the greatest risk of “getting wormed”, but in theory any bug that allows arbitrary remote code execution could allow worm code execution.
• Assume that cybercriminals are already actively digging into this and all the other RCE vulns announced this Patch Tuesday. You have probably heard the joke about Patch Tuesday being followed by Exploit Wednesday. There’s more that a touch of truth to that, given that even closed-source patches can be often wrangled backwards – reverse engineered, in the jargon – to reveal the inner details of the bug that they prevent. (And see point 1.)
• Patch early, patch often. Don’t use workarounds as a routine part of your patching process to buy extra time every time. Patch out of preference, and keep workarounds for situations where you genuinely need to delay patching for a while. (And see points 1 and 2.)

Don’t delay… do it today!

LEARN MORE ABOUT THE JANUARY 2022 PATCH TUESDAY