EDRIdentify, contain, respond, and stop malicious activity on endpoints
SIEM powered by PerchCentralize threat visibility and analysis, backed by cutting-edge threat intelligence
Risk Assessment & Dark Web MonitoringIdentify and quantify unknown cyber risks and vulnerabilities
Cloud App SecurityMonitor and manage security risk for SaaS apps
SOC ServicesProvide 24/7 threat monitoring and response backed by ConnectWise SOC experts
Policy ManagementCreate, deploy, and manage client security policies and profiles
First Patch Tuesday of 2022
Yesterday, January 11, was the first Patch Tuesday of 2022. Patch Tuesday is the second Tuesday of every month where Microsoft and other vendors, such as Adobe, release updates to their products to patch vulnerabilities discovered in their products. This month Microsoft released patches for 126 different vulnerabilities with 9 critical vulnerabilities, but none have been publicly exploited so far according to Microsoft, so no 0-days to worry about this month. As usual, SANS published a nice break-down of all the vulnerabilities addressed during this Patch Tuesday at https://isc.sans.edu/forums/diary/Microsoft+Patch+Tuesday+January+2022/28230/.
Among the vulnerabilities patched this month are three remote code execution (RCE) vulnerabilities in Microsoft Exchange. As we’ve discussed before, most recently in our 2021 Lookback, Exchange suffered a number of severe RCE vulnerabilities last year that led to wide-spread exploitation of on-premises Exchange servers across the globe. The good news is that these new vulnerabilities are not as severe as ProxyLogon, ProxyShell, and ProxyOracle which plagued us last year. The three new CVEs, CVE-2022-21846, CVE-2022-21855, and CVE-2022-21969, are not exploitable via the public Internet. According to Microsoft’s notifications for each of these (see links above):
This vulnerability's attack is limited at the protocol level to a logically adjacent topology. This means it cannot simply be done across the internet, but instead needs something specific tied to the target. Good examples would include the same shared physical network (such as Bluetooth or IEEE 802.11), logical network (local IP subnet), or from within a secure or otherwise limited administrative domain (MPLS, secure VPN to an administrative network zone). This is common to many attacks that require man-in-the-middle type setups or that rely on initially gaining a foothold in another environment.
According to Microsoft’s knowledgebase article, KB5008631, which addresses these vulnerabilities, the latest patch is an update to a previously disclosed vulnerability, CVE-2021-42321, previously addressed in KB5007409 from Patch Tuesday in November 2021 which did not completely resolve the issue.
The most sever vulnerability addressed this month is an RCE in http.sys, the default library in Windows for handling web server operations. HTTP.sys is the main component of Internet Information Services (IIS), Microsoft’s web server, but is also used by other Windows components that operate over the HTTP protocol. It is important to note that this is not an IIS vulnerability, but affects many other Windows components that use HTTP, such as WinRM (Windows Remote Management), WSDAPI (Web Services for Devices), as well as other 3rd party applications that rely on this library.
The vulnerability, CVE-2022-21907, is an uninitialized memory usage issue related to the “Trailer” HTTP header which allows the sender to send additional data at the end of chunked messages. According to Microsoft, this is a wormable vulnerability that can be exploited over a public Internet interface, and they recommend prioritizing this patch. No public proof-of-concepts have been made available yet and it has not yet been observed exploited in the wild, but this vulnerability is exploitable in several Windows versions in their default configuration. Windows Server 2019 and Windows 10 version 1809 do not have the Trailer feature enabled by default and are not vulnerable unless it is enabled; however, this feature is enabled in server 2022, 20H2 core, and various Windows 10 and 11 versions. The CRU is currently digging into this vulnerability to determine what detection signatures can be created to exploit this vulnerability and will publish any new signatures when they are available.
Patch management is a daunting task and is a much larger issue than simply enabling auto-updates on all your systems. Sometimes, the patch doesn’t fix the initial issue, as we saw last year with PrintNightmare, and sometimes the patch can introduce new problems or even break things. According to several users on Reddit, and reports from users of MSPGeek, some systems running Windows Server versions 2012/R2, 2016 and 2019 are stuck in a boot loop after patching. Some reports suggest the boot loop issue only affects hosts running Hyper-V and possibly some Windows 2012 domain controllers; however, no official word has come down from Microsoft and reports are still scattered. If you do apply the latest patches and run into a boot loop, the general recommendation from the community is to boot into safe mode and then uninstall the latest patches. If the issue is indeed restricted to Hyper-V, then we would recommend trying to only uninstall the patches related to Hyper-V first, as none of these CVEs are critical.
Additional reports from users on Reddit suggest that there is a bug in KB5009543 that breaks Layer Two Tunneling Protocol (L2TP) and as a result is causing many VPN clients to fail with the error, "The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer". This issue is affecting the underlying protocol that VPN clients rely on and as a result is affecting VPN clients by multiple vendors, SonicWall, Cisco Meraki, and WatchGuard are a few that are specifically mentioned that are affected by this issue. In a time when working from home has become the new norm, this can be a major issue for many users.
All this brings us back to the difficulty of patch management. In an ideal world, we all have a test environment where we can apply patches and run them through a rigorous series of tests to weed out any potential bugs before they apply to production, but most organizations don’t have the time, resources, or personnel to employ this tactic. This is even more difficult for MSPs with potentially hundreds of clients, each with their own unique environment. Take our poll and let us know how your MSP handles patch management.