The Bug Report - January 2022

By Trellix · February 2, 2022

This story was written by Kevin McGrath

Your Cybersecurity Comic Relief

Image courtesy of https://toggl.com/

Why am I here?

Omicron is the 15th letter in the Greek alphabet, used by Donald Knuth to denote Big-O notation, represented zero in Ptolemy’s Almagest, had the value of 70 in the practice of isopsephy. But for most of us, it simply represents the pandemic that JUST. WILL. NOT. END. Wait, you weren’t interested in philosophical ramblings on the most mentioned word in January of 2022? You actually came here to read about some vulnerabilities? But, but…never mind. Welcome to the January Bug Report: Surge edition!

• CVE-2022-0185: Because Java devs aren’t alone in forgetting to validate input!
• CVE-2021-42392: What? You thought Log4shell would go away?
• CVE-2022-21907: I didn’t forget about you, my little worm.
• CVE-2021-4034: PwnKit, what happens when you decide sudo is insufficient.

CVE-2022-21907: HTTP.sys wormable bug

What is it?

For Patch Tuesday in January 2022, Microsoft welcomed us to this new year with a wormable vulnerability in the HTTP.sys kernel driver. This is the second wormable vulnerability found in HTTP.sys in a seven-month span. That’s pretty impressive, considering the code maturity of this driver. CVE-2021-31166 didn’t implode the internet; hopefully, 21907 won’t either! '21907 leverages the incomplete fix from '31166,taking advantage of HTTP trailer support (metadata at the end of a chunked message). It’s unclear if this exploit relies on the presence of a TRAILER header in the final chunk or not – the RFC denotes it as OPTIONAL. This is potentially a problem for network product signature writers if they can’t rely on the TRAILER header.

Fun fact: PoCs are on GitHub for this!

Another fun fact: We are beginning to see exploitation in the wild! If you would like to receive up-to-date information on current threats, McAfee Insights is something you should definitely look into!

While it might seem sensible that only IIS uses HTTP.sys, that isn’t actually the case. HTTP.sys is the kernel driver that provides core HTTP handling code. Other subsystems make use of this code:

• ADFS *WinRM *Intel Support Assistant

You can see what services are leveraging the driver with:

PS > netsh http show servicestate

This will list the request queues and URLs associated with them running on the current system.

Fortunately for those who haven’t bothered to update past Server 2019 or Windows 10 1809, you’re in the clear…unless you enabled trailer support in the registry.

Who cares?

2.4 million Twitter users. Anyone with IIS running in their environment. Anyone who uses Docusign (this is a rather large deal, considering the number of legally binding contracts that flow through Docusign, especially during the pandemic). According to a recent market report,approximately 7% of Internet sites use IIS. Even Microsoft doesn’t have that many internet-facing systems, meaning there are a lot of sites besides MS using IIS. Oh, and anyone usingvulnerable-by-default versions of Windows:

• Windows 10 2004 and up (both ARM and x64)
• Windows Server 20H2 and up

What can I do?

Patch! Microsoft released a patch for this vulnerability along with their announcement. Should that not be possible, it would be best to remove those systems from Internet-facing roles. Unfortunately, there is no host-based mitigation available for current versions of Windows.

If you are running Windows Server 1909 or Windows 10 1809, you are not vulnerable by default. To determine vulnerability status, execute

PS > Get-ItemProperty “HKLM:\System\CurrentControlSet\Services\HTTP\Parameters” | Select-Object EnableTrailerSupport

If a value is returned and is non-zero, your system is vulnerable. To mitigate this, execute:

PS > Set-ItemProperty “HKLM:\System\CurrentControlSet\Services\HTTP\Parameters” -name EnableTrailerSupport -Value 0

Or simply delete that registry key.

The Gold Standard

The good news is there is a patch available. Please apply it! If you can’t apply the patch for…reasons… don’t fret. Trellix has you covered with Network Security Platform (NSP) signatures for this vuln. So, make sure you have at least updated your signature database!

CVE-2021-42392: H2 wants in on this Log4Shell action!

What is it?

A Log4Shell-like vulnerability in the handling of JNDI remote class loading. While it does not leverage the bug present in Log4j (Log4j is not even required), it leverages the same underlying technology (JNDI). Any attacker-controlled URL that manages to get to the database (you sanitized your input, though…Right?) can gainremote code execution in the context of the H2 RDBMS. But of course, that won’t happen to you because all queries against the database are sanitized, parameterized, and stored. Obviously.

Who cares?

Some estimates put the usage of H2 at nearly 7,000 projects – including Log4J. Makes you wonder if Log4jJ was ever really the problem at all, eh? Log4Shell may need renaming and have legs beyond Log4j users if that’s the case. Nature always finds a way…

What can I do?

H2 database versions 1.1.100 to 2.0.204 are impacted. Version 2.0.206, shipped on January 5th, 2022, remediates this vulnerability. Updating to at least version 2.0.206 would be ideal.

You could switch database engines, but that seems rather an extreme solution. Curing the disease by killing the host isn’t recommended practice in IT any more than in medicine.

You could also stop using Java? While it seems similar to the above, in this case, it seems warranted. In fact, this is the best solution, clearly. Java belongs in coffee cups, not on servers.

The Gold Standard

If patching, scrapping all Java code and switching to some other language, or swapping database engines is not possible, Trellix has you covered, as the exploits themselves will look very similar to Log4Shell.

Trellix customers are protected from many different angles (for the specifics, please visit this Knowledge Base article):

• Expert Rules on Endpoint Security (ENS) can pick up dangerous patterns in memory, as described in this blog.
• Endpoint Security (ENS), VirusScan Enterprise (VSE), McAfee Web Gateway (MWG) can provide generic detection under the tile Exploit-CVE-2021-44228.C via a “Potentially Unwanted Software” detection. This detection is also augmented by a list of hashes of samples related to in-the-wild campaigns exploiting this vulnerability.
• Network Security Platform (NSP) can also detect the attack via User-Defined signature (provided in the KB article linked previously)
• MVISION Endpoint Detection and Response (EDR), McAfee Active Response (MAR) can also be used to look for vulnerable systems with Real-Time Search (RTS) queries
• McAfee SIEM got an update (Exploit Content Pack version 4.1.0) that will raise an alarm on potential exploit attempts.

CVE-2022-0185: Linux kernel namespace underfl…

What is it?

On its surface, CVE-2022-0185 is a simple integer underflow in a legacy code path. Fortunately for anyone using containers, that legacy code path is in the File System Context (FSC). While the FSC was replaced with the File Context API (FCAPI), some functionality was retained to support backwards compatibility – including the vulnerable path. The integer underflow creates an unbounded write for an attacker in the context of the container process itself. An attacker with access to a container can leverage this flaw toattack the underlying host, gaining access to all other containers running on this node. Given how popular tools like Kubernetes (k8s) have become, this is potentially concerning for anyone who uses containers for process isolation in the presence of untrusted users. This issue only affects containers using unprivileged namespaces, containers that allow the unshare command, or containers with the CAP_SYS_ADMIN privilege (off by default). The unshare command is blocked by default on Docker containers by the seccomp filter. Unfortunately for k8s users,the seccomp filter is not on by default, meaning any Kubernetes cluster is at risk.

The past is a garrote around the neck of progress, slowly strangling the life from all that is good in this world. In other words, backwards compatibility is frequently why we can’t have nice things.

Who cares?

Anyone running a container, potentially. And even admins who aren’t but allow users to run them. Or even using a container to store leftovers in – ok, that may be taking it too far. At the least, anyone running a container on a shared server should be very concerned about this, potentially removing anything mission-critical from that server until they know the underlying kernel has been updated.

The authors have written a detailed blog and released PoC code for this vulnerability. So, at this point, we all should care, as it’s only a matter of time before malicious actors weaponize it.

What can I do?

If you control the host, you need to update the kernel. If that’s not an option (or the owner refuses), executing

sysctl -w kernel.unprivileged_userns_clone = 0

---

will limit this vulnerability to only those containers with the CAP_SYS_ADMIN privilege. Removing that privilege from your containers will also mitigate this vulnerability (it is off by default).

The Redhat recommendation for systems which don’t run containers is to simply disable namespaces entirely:

echo “user.max_user_namespaces=0” > /etc/sysctl.d/userns.conf

sysctl -p /etc/sysctl.d/userns.conf

---

This also renders that host unable to run containers. Which, if you aren’t using them, is probably a good idea anyway.

The Gold Standard

At this point, patching or applying mitigations are your best options. Since containers are used as an isolation mechanism, an external process having visibility into a running container is unlikely. Ensure you run on a patched host or enable the seccomp filter on k8s.

CVE-2021-4034: PwnKit

What is it?

CVE-2021-4034, affectionately known as PwnKit, leverages a logic bug in PolKit (formerly known as PolicyKit). PolKit is a system-wide policy management kit which provides unprivileged processes safe (or so it was believed) access to privileged processes. The bug exists specifically in the tool pkexec (because for some reason sudo wasn’t enough, and we felt the need for another setuid program to do… precisely the same thing as sudo) – an assumption is made that the argc variable is at least 1. In typical program invocation, this is obviously true. There are ways…nearly all of which are indications of compromise and should be rejected by the runtime, but, hey, here we are!

Typically, when using pkexec, a pop-up window appears asking for credentials. This vulnerability bypasses that credential check and just runs as root. Because clearly, the way to handle failure is to just hand over the keys to the kingdom and pat yourself on the back!

This is the second polkit vulnerability in 6 months. CVE-2021-3560 also bypassed the credential check using the dbus mechanism to invoke polkit. Both seem to have leveraged the same root flaw. While we’re on the subject, the root cause was initially reported in 2013, but the author didn’t see a direct path to exploitation. And so, the patch languished in forsaken misery, awaiting its day to shine. It took nine long years, but shine on sweet patch! Embrace your time in the sun!

Who cares?

It would be hard to argue this isn’t the biggest local privilege escalation bug of the last year (get it?). This vulnerability works on most major Linux distributions running out-of-date polkit binaries, so anyone running Linux who hasn’t patched since January 25th is vulnerable. The version numbers of polkit are a little wonky, as Debian maintains its own fork, but if you are running

• less than 0.105-26ubuntu1.2 on Ubuntu 20.04 (LTS),
• less than 0.105-31ubuntu0.1 on Ubuntu 21.10,
• less than 0.105-31+deb11u1 on Debian bullseye, or
• less than polkit-0.115-11.el8_4.2 on RedHat Enterprise Linux (RHEL) 8.4 EUS

then you are vulnerable. Again, you are vulnerable if you haven’t patched since January 25th. There’s also PoC code in the wild, so it won’t be long before this is actively exploited.

Oh, you trust all of your users? In that case, you have nothing to worry about. Compromised accounts are readily available. Whether it was through phishing, cracking, compromised accounts elsewhere that share the same credentials, or some other avenue of account compromise, trusting users isn’t an indication that you should trust user accounts.

While this bug was found on Linux, other UNIX distributions use polkit, including the BSDs. OpenBSD, at least, has always had mitigations in place for this – it refuses to execute a program with an argc of 0. Solaris also uses polkit, but Oracle is so secretive about Solaris that they have a paywall up even on security bulletins. Because clearly, that’s the best way to hold on to customers!

What can I do?

Update! The patches are available from all major Linux vendors and should be applied. No reboots are required. If you choose instead to not patch, you can remove the setuid bit on pkexec:

chmod 0755 /usr/bin/pkexec

---

Unfortunately, this will also break pkexec from doing what it was designed to do. But better that than compromise, right?

RedHat has a specific-to-RHEL mitigation guide in its security bulletin.

The Gold Standard

Since this was a coordinated release from all the Linux distributions, it really should just be applied. It’s worth pointing out that anomalous login points-of-origin should be recorded, flagged, and possibly blocked without some other form of authentication. You are using multi-factor authentication, right? MFA would stop non-insider-threats from exploiting this, as they wouldn’t be able to access the system. As for insider threats, well, that’s left as an exercise for the reader.