Microsoft has released its December 2021 Patch Tuesday update, addressing a total of 67 security vulnerabilities, including a zero-day that has been exploited in the wild to deliver Emotet malware payloads.
Of all security flaws fixed this month, seven are listed as ‘critical’, while 60 are ‘important’ in severity.
The latest round of security update includes patches for 26 remote code execution (RCE) vulnerabilities, 21 elevation of privilege (EoP) bugs, 10 information disclosure bugs, seven spoofing bugs, and three denial of service bugs.
Products impacted by this month’s security update include Microsoft Office, Microsoft PowerShell, Microsoft Windows Codecs Library, Visual Studio Code, Windows DirectX, Windows Kernel, Windows Media, Windows Print Spooler Components, ASP.NET Core & Visual Studio, Microsoft Defender for IoT and others.
Some of the most serious security flaws resolved in the update are a total of six zero-days, although only one of them is known to be actively exploited in the wild.
Indexed as CVE-2021-43890, a ‘spoofing’ bug in the Windows AppX installer on Windows 10 is being weaponised to spread the Emotet/Trickbot/Bazaloader malware families, according to Microsoft.
The company says it is aware of attempts to exploit the flaw by using specially crafted packages.
“An attacker could craft a malicious attachment to be used in phishing campaigns. The attacker would then have to convince the user to open the specially crafted attachment,” Microsoft said.
Another zero-day patched this month is CVE-2021-41333, the Windows Print Spooler EoP bug that has been issued a CVSS score of 7.8. This bug is not known to be exploited in attacks.
The other four zero-days fixed are: CVE-2021-43880 (Windows Mobile Device Management EoP vulnerability); CVE-2021-43893 (Windows Encrypting File System EoP vulnerability; CVE-2021-43240 (NTFS Set Short Name EoP bug) and CVE-2021-43883 (Windows Installer EoP vulnerability).
Another serious vulnerability worth attention is CVE-2021-43215, a critical memory corruption bug in the Internet Storage Name Service (iSNS) protocol. According to Microsoft, an unauthenticated, remote attacker could exploit the bug by sending a specially crafted request to a vulnerable iSNS server.
It is assigned a CVSSv3 score of 9.8 and is rated ‘Exploitation More Likely’, by Microsoft.
Last week, security researchers also warned about the Log4Shell zero-day exploit in a popular Java library that web server administrators are now racing to patch amid its widespread exploitation.
The flaw, tracked as CVE-2021-44228, allows attackers to execute malicious code on Java applications and is poses a serious danger both because of the ubiquity of Log4j and because such an attack is easy to pull off.
“December 2021’s Patch Tuesday comes on the heels of the Apache Log4j zero-day vulnerability (CVE-2021-44228), so expect a lot of attention to be focused on vendors scrambling to resolve Log4j-related issues,” said Chris Goettl, VP of Product Management at Ivanti.
“Efforts to identify, mitigate, or remediate the Apache Log4j vulnerability continue. In this case it is leaving a lot of teams frustrated, not knowing exactly what they need to do.
“Apache Log4j is a development library, so you cannot just patch a specific Jar file and call it a day. It falls to your development team or the vendors whose products you may be using.
“As far as how organizations should be looking to resolve this vulnerability, that is a bit more tricky.”
“The best guidance is to continue to rely on your DevSecOps processes and vulnerability scanning, and supplement this with more direct action as there will likely be gaps for some time in detection. There are a few sources gathering lists of KB articles, security advisories, and mitigation guidance by vendors. Your organization should be assessing the vendors in your environment and determining if they have provided guidance and take those actions immediately. This could be more immediate mitigation by finding the vulnerable jar file and removing the code class, changing configuration to disable the vulnerable logging capabilities, or by applying an update from that vendor that updates the Log4j version to 2.15.
“If you do not find guidance from your vendors, either that they have mitigation or updates available, you should reach out to them to ensure you are not exposed as it may take some time before normal methods of detection are able to provide visibility once again.”
This content was originally published here.