January 2022 Patch Tuesday forecast: Old is new again

Welcome to 2022 and a new year of patch management excitement! I’m rapidly approaching 40 years working in this industry and I can honestly say there is rarely a dull day. If you are willing to take on the challenges presented, it is a great industry to work in and I hope you all are excited to start the new year too. Let’s look at some recent events which will be influencing this month’s patch releases.

I closed out last month’s forecast article calling 2021 the ‘year of supply chain attacks’ and that trend is continuing. Malware in the Atera Remote Management Software is taking advantage of Microsoft’s digital signature verification vulnerabilities from as far back as 2012 to load ZLoader and steal account credentials.

Even though these vulnerabilities were fixed, the changes are not enabled by default. Microsoft Security Advisory 2915720 from 2017 provides more details on the Authenticode and WinVerify Trust functionality with recommendations for action. Despite the old vulnerabilities, this is a new attack and I’m sure we will be hearing more from Microsoft, with potential changes in next week’s patches.

The zero-day vulnerability in the Apache Log4j Java-based logging library took the software industry by storm in mid-December. This library is widely used in both enterprise and cloud service software. Even though Apache released the zero-day fix for CVE-2021-44228, it takes a while for companies who use this library to update, test, and release a new version.

To complicate the situation, a total of four additional CVEs associated with the Log4Shell bug have been identified in the last month, the latest being CVE-2021-44832. Keeping the industry churning, Apache released multiple updates with this library, now up to version 2.17.1. SaaS products can be quickly updated under DevOps but updating traditional software products in the field can take much longer, leaving them vulnerable to exploitation.

Microsoft has been busy leading up to the first Patch Tuesday of 2022. It released an out-of-band update for Windows servers that “experience a black screen, slow sign in, or general slowness,” These updates were initially a limited release, but are now available for all servers. It also released a script to run on Exchange Server 2016 and Exchange Server 2019, which fixes a problem related to date checking that leaves messages stuck in the transport queue. We’ll have to see if these updates manifest in any upcoming cumulative patches.

January 2022 Patch Tuesday forecast

• I mentioned Microsoft has been busy addressing several issues already this year, so we may see more than the 29 and 30 vulnerabilities addressed in Windows 11 and 10 respectively. I anticipate we’ll see updates for Exchange Server and maybe .NET too.
• The final Year 2 Extended Security Updates (ESU) for Windows 7 and Server 2008/2008 R2 will be released next week. If you still need support for Year 3, make sure you renew all your licensing to ensure no interruptions come February.
• Expect an Adobe Acrobat and Reader update next week. Updates for most Adobe products were released back on December 14th, so make sure you’ve included those in your update plan.
• Apple released security updates for Safari, macOS Catalina, Big Sur, and Monterey in December. Barring any new zero-day vulnerabilities, it should be a quiet January for Mac users.
• Google released a stable channel Desktop update for Chrome 97.0.4692.71 which addressed 37 vulnerabilities. One of these vulnerabilities was rated Critical and 10 were High, so definitely update your systems this patch cycle. The Extended Stable Channel Update for Desktop has also been updated to 96.0.4664.131 for Windows and Mac.
• Mozilla did not release their usual pre-Patch Tuesday updates for Firefox, Firefox ESR, and Thunderbird, so expect those security updates next week.

I looked back at my January 2021 forecast article and surprisingly the focus was on identifying and maintaining third-party software embedded in enterprise products. With the malicious code in the Atera product and the scramble to update Apache’s Log4Shell vulnerability, this old advice is really new again!