Security Intelligence Feed Your home for the latest cyber security developments.

On 11 January 2022, Microsoft released updates to address 122 vulnerabilities; nine classified as critical and six publicly disclosed. We recommend applying the latest updates in a timely manner.

Critical Vulnerabilities

Microsoft’s January 2022 Patch Tuesday fixed nine flaws classified as critical. None of the CVEs were reported to be actively abused at the time of reporting.

The most severe of the vulnerabilities that were labelled as critical include:

• CVE-2022-21907 fixes a boundary error within the HTTP Trailer Support feature of Hypertext Transfer Protocol (HTTP) Protocol Stack, HTTP.sys. Remote unauthenticated actors could trigger a buffer overflow and execute arbitrary code by sending maliciously crafted packets to a vulnerable system.
  • Http.sys is the kernel mode driver that handles HTTP requests and is used by various services that may be accessible to the Internet or Intranet. This includes the Windows Internet Information Services (IIS) web server, Web Services for Devices (WSDAPI), and Windows Remote Management (WinRM) service (where it is enabled by default on Enterprise versions of Windows).
  • The HTTP Trailer Support feature is enabled by default on Desktop versions in Windows 10 and later, as well as most recent versions of Windows Server 2019. The exceptions to that are Windows Server 2019 and Windows 10 version 1809, where the feature is available but not enabled by default. The vulnerability was assigned a CVSS:3.1 score of 9.8.

• Microsoft Windows Internet Key Exchange (IKE) Extension had six vulnerabilities fixed, including CVE-2022-21849, which is due to improper input validation in the Microsoft IKE Key Exchange. Only version 2 of the product is affected when it is running Internet Protocol Security (IPsec) service. This vulnerability could allow a remote threat actor to execute arbitrary code via a specially crafted request. CVSS:3.1 9.8
• Microsoft Exchange Server received three fixes, which Microsoft labelled as critical and marked that exploitation for these is likely. Although these flaws received a CVSS:3.0 rating of 9.0, a threat actor would need prior access to the target network in order to exploit them. A user on a local network could send specially crafted data to the Exchange server and execute arbitrary code on the system. All three, CVE-2022-21846, CVE-2022-21855, and CVE-2022-21969, exist due to an improper validation of user-supplied input.

Publicly Disclosed Vulnerabilities

Six of the vulnerabilities fixed this month have public details available, which increases the likelihood of them being leveraged by threat actors.

• CVE-2021-22947 – Open Source Curl Remote Code Execution Vulnerability
• CVE-2021-36976 – Libarchive Remote Code Execution Vulnerability
• CVE-2022-21919 – Windows User Profile Service Elevation of Privilege Vulnerability
• CVE-2022-21836 – Windows Certificate Spoofing Vulnerability
• CVE-2022-21839 – Windows Event Tracing Discretionary Access Control List Denial of Service Vulnerability
• CVE-2022-21874 – Windows Security Center API Remote Code Execution Vulnerability

Recommendations

We recommend timely patching of the Microsoft vulnerabilities noted as critical and publicly disclosed in order to decrease the likelihood of exploitation.

Microsoft has reported a number of known issues with this round of updates; testing should be conducted prior to patching. We recommend consulting the Known Issues section on the Microsoft Update Guide referenced below prior to applying the updates.

In order to expedite the updates, users should go to Settings > Windows Update > Check for Updates.

References

Microsoft Updates

Microsoft Update Catalog

This week brings more updates to the issues covered in our previous blogs describing vulnerabilities in Log4j, a Java-based logging utility. Apache has released Log4j version 2.17.0 to fix a recently discovered issue affecting Log4j version 2.16.0. This blog also includes new information for a previously reported vulnerability, and information on a list of third-party applications with Log4j vulnerabilities, compiled by the U.S. National Institute on Science and Technology (NIST). As this is a constantly developing situation, we recommend regular monitoring of the latest reports, vendor updates, and actioning the recommendations provided.

Details  

CVE-2021-45046

Our blog of 16 December 2021 covered an incomplete fix of a Log4j vulnerability attempted with the Log4j version 2.15.0 release.

The problem in the 2.15.0 version, tracked as CVE-2021-45046, was originally assessed to be of low severity but has now been updated with a CVSS score of 9. The newly-discovered issue in version 2.15.0 allows for information leak and Remote Code Execution (RCE), but is limited to certain non-default configurations and specific conditions. Local code execution is possible in all environments on 2.15.0 version, regardless of their configurations. Organizations running Log4j version 2.16.0 are protected against CVE-2021-45046, as this version removes support for message lookup patterns and disables JNDI functionality by default.

CVE-2021-45105

On 18 December, Log4j received a further update, version 2.17.0, to address a high-severity vulnerability allowing a Denial-of-service (DoS) in Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3).

The issue, tracked as CVE-2021-45105, is rated with a CVSS score of 7.5. It was fixed in Log4j version 2.17.0 (for Java 8) and 2.12.3 (for Java version 7).
This CVE describes another method that abuses lookups in logged data, that are non-JNDI. This method is separate from, and not a variant of the original Log4Shell vulnerability.

Third Parties Affected

The National Institute of Standards and Technology (NIST) has now started adding Common Platform Enumeration (CPE) entries for the third-party applications and services affected by CVE-2021-45046, CVE-2021-44228, and CVE-2021-45105. These entries can be used to identify some of the vulnerable services in your environment.

Recommendations

We strongly advise following the guidance below and updating the affected products to the latest version as soon as possible.

If you have already updated Log4j to version 2.16.0 or you are still running versions prior to 2.16.0, we recommend updating to 2.17.0 as soon as possible. Although version 2.16.0 does protect from the RCE vector, given the heightened interest in this set of vulnerabilities, systems may be targeted for the DoS condition as well. The 2.17.0 update fully remediates all of the currently known vulnerabilities in Log4j. When an update to the log4j-core is applied, other JAR files (e.g.log4j-api) need to be updated as well.

We also recommend monitoring for third-party application updates and applying them when they become available.
For any products deployed on your network that are known to use Log4j but are not on the NIST list, we recommend contacting the vendor to inquire about the security status of their application in relation to this set of vulnerabilities.

We recommend reviewing the list of mitigations provided by the vendors and applying them in the event that you are unable to apply the updates immediately. Please keep in mind that these remediations only provide temporary and partial protection against this threat and should not be relied on as a replacement for a product update.

References
Apache Advisory
CISA Advisory
CVE-2021-44228
CVE-2021-45046
Limitations of CVE-2021-45046 Explained
NCSC-NL Advisory
Center for Internet Security Response Guide

Since our last blog on a flaw in Apache Log4j, Apache has released Log4j version 2.16.0 which provides further fixes in the vulnerable library. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a Log4j guidance page which tracks vendor vulnerability information and mitigation advice. We recommend reviewing the latest reports and actioning the recommendations.

Details

Log4j Versions 2X

CVE-2021-44228

Field Effect’s 10 December 2021 blog post detailed a critical Remote Code Execution (RCE) vulnerability within Apache Log4j, tracked as CVE-2021-44228. This vulnerability affected Log4j versions:

• 2.0-beta9 to 2.12.1
• 2.13.0 to 2.14.1

In describing this flaw, the National Vulnerability Database (NVD) indicated that a “threat actor who can control log messages or log message parameters” can execute arbitrary code from Lightweight Directory Access Protocol (LDAP) servers. The flaw allows improper input validation when Java Naming and Directory Interface (JNDI) message lookup substitution functionality is enabled. JNDI injection also works with services including Remote Method Invocation (RMI), Domain Name Service (DNS), and Secure LDAP (LDAPS) making exploitation with these services possible.

As of 15 December 2021, there are 242 proof-of-concept (POC) implementations published on GitHub. Using these POC implementations and various obfuscation techniques, multiple threat groups and security researchers have been scanning for systems vulnerable to this flaw. Exploits are likely to take advantage of systems that have external connections open, are using Java 7 (reaching end-of-life in December 2021), and running Java Runtime Environment version 8u191 and prior. Organisations running these systems should isolate their systems from the internet and apply the latest updates now to prevent being targeted.

In October 2018, Java versions 8u191 introduced restrictions for LDAP and RMI-based JNDI calls, making it harder to exploit JNDI. Later versions of Java versions contain existing application classes that could still be vulnerable to remote execution. It is possible that that exploits using this vulnerability on other versions of Java will be used soon.

Log4j is a dependency within many third-party applications. Multiple vendors have reported being affected and are either working on updates or have already released them. The list of vendors is being continually updated and we recommend monitoring for, and applying the updates as they become available.

It is worth noting that only applications that include log4j-core JAR file are directly impacted by this vulnerability. Applications that use `log4j-api` and `log4j-to-slf4j` without the log4j-core JAR file are not impacted as they do not contain the Log4J implementation.

CVE-2021-45046

On 13 December 2021, Apache released Log4j version 2.16.0, which contained a further fix to address a subsequent vulnerability. Researchers found that Log4j version 2.15.0 in certain non-default configurations was susceptible to exploitation, making the previous fix incomplete. This problem is tracked separately from CVE-2021-44228 and was assigned its own identifier, CVE-2021-45046. Log4j version 2.16.0 disables access to JNDI by default and limits the default protocols to Java, LDAP, and LDAPS.

Log4j Versions 1.x

Several sources mistakenly reported Apache Log4j in version 1.x as vulnerable to CVE-2021-44228. Log4j version 1.2 is affected by another flaw, tracked as CVE-2021-4104, that can only be exploited when specific non-default configurations are in place. When the JMS Appender component is configured in the application’s Log4j configuration, it allows deserialization of untrusted data. A threat actor could use that for RCE on the server if they had Write access to the Log4j configuration. Apache Log4j 1.2 reached End of Life in August 2015.

Log4j versions up to 1.2.17 are also vulnerable to a 2019 vulnerability tracked as CVE-2019-17571 rated with a CVSS score 9.8. The flaw is due to deserialization of untrusted data which can be exploited to remotely execute arbitrary code.

Logback

Logback is a logging framework for Java applications which was created as a successor to the Log4j project. On 14 December 2021, Logback released version 1.2.8 which addressed some vulnerabilities.

Sources reported that Logback 1.2.7 was affected by JNDI attacks. According to the project developers, Logback does not offer a lookup mechanism at the message level and is not vulnerable to CVE-2021-44228. However, it is vulnerable to another, less severe issue, tracked as LOGBACK-1591. Logback may make JNDI calls from within its configuration file. Exploitation requires Write access to the logging configuration Logback.xml and access to the classpath. It is exploitable on Java versions 6u211, 7u201, 8u191, 11.0.1, and earlier.

Field Effect Posture

Field Effect has completed an internal review and confirmed that Apache Log4j is not used within our software and is not affected by these vulnerabilities. Field Effect deployed new network and endpoint-based rules to detect malicious activity associated with this vulnerability.

Covalence clients will have received an ARO if the affected software has been identified within their environment. Covalence’s network-based detection identifies exploitation attempts over non-encrypted communications. Covalence endpoint agent policies were updated to detect more potentially malicious behavior originating from Java programs, to increase identification of post-exploitation activities.

The Field Effect team continues to monitor for evidence of exploitation related to the vulnerabilities in Apache Log4j. If you believe a system in your environment may have been a victim of this attack, please contact forensics@fieldeffect.com for support and analysis.

Recommendations

We strongly advise following the guidance below and updating the affected products to the latest version immediately.

We recommend affected system owners should not only upgrade to the latest version of the Java Runtime Environment but also update Log4j to version 2.16.0 immediately. This update fully remediates the most severe vulnerability, CVE-2021-44228 as it fully disables JNDI and removes support for Message Lookups. When update to the log4j-core is applied, other JAR files (e.g.log4j-api) need to be updated as well.

If you are using Apache Log4j 1.2, we recommend upgrading to version 2.16 as soon as possible.

We also recommend monitoring for third-party updates and applying them when they become available. If a product you are using is not on the list, we recommend contacting your vendor or developer to inquire about their exposure.

We recommend reviewing the list of mitigations provided by the vendors and applying them in the event that you are unable to apply the updates.

References 
CISA Advisory
Apache Advisory
Vendors Affected
Download Version 2.16
CVE-2021-45046 Explained
Version 2.16 Release Notes
CVE-2019-17571
Log4j2 architecture
LOGBACK-1591
Logback 1.2.8

16 December 2021 Update: There have been several notable updates since this blog was published. Please see part 2 of the blog which includes information on another vulnerability which was fixed in version 2.16.0 of Log4j. Log4j 2.15.0 which was recommended here may still be vulnerable under certain non-default configurations.

On 6 December 2021, Apache Software Foundation released an urgent fix for a critical vulnerability in Apache Log4j. Since then, multiple sources reported active scanning for this flaw heightening the risk of immediate exploitation of vulnerable systems. We recommend updating the affected product to the latest version as soon as possible and, as required, following additional mitigation advice provided by Apache.

Details
Apache log4j2 version log4j-2.15.0-rc2 contains an out-of-band security update that fixes a critical flaw in Log4j. The vulnerability, tracked as CVE-2021-44228 and known by the names of Log4Shell or LogJam, is rated with a maximum Base CVSS Score of 10. With this vulnerability, a threat actor could perform Remote Code Execution (RCE) by constructing a special data request packet, and gain full control of the server.

Proof-of-concept (POC) implementation for this CVE is publicly available on GitHub. Several reports have emerged indicating that threat actors are already scanning the internet in an attempt to locate vulnerable servers. The researcher who published the POC stated that the flaw can only be exploited when ‘log4j2.formatMsgNoLookups’ option in the library’s configuration is set to false.

The feature causing this vulnerability has been disabled by default in version 2.15.0. The original version of the fix, log4j-2.15.0-rc1, was reported to be insufficient, and log4j-2.15.0-rc2 was issued to correct it. Several workarounds are available for those who are unable to fix the vulnerability now.

Apache Log4j is a Java-based logging framework used by multiple internet services and third-party applications, which are reported to be affected by this flaw, including:

• Apple iCloud, Tencent, Steam, Twitter, Baidu, DIDI,JD, NetEase, CloudFlare, Amazon, and Tesla.
• Apache Solr, Apache Druid, Apache Flink, Apache Struts2, Flume, Dubbo, Redis, Logstash, ElasticSearch, Kafka, Ghidra, and Minecraft.
•  Depending on the specifics of each application, Java versions greater than 6u211, 7u201, 8u191, and 11.0.1 are reported to be less affected by this attack vector.

Recommendations

We strongly advise following Apache’s guidance and updating the affected product to the latest version (Apache log4j2 version log4j-2.15.0-rc2) as soon as possible.

We recommend reviewing the list of mitigations provided by Apache and applying them in the event that you are unable to apply the updates immediately. One of the mitigations listed is setting ‘log4j2.formatMsgNoLookups’ to True. This may impact the behavior of your system’s logging if it relies on Lookups for message formatting.

We also recommend monitoring for third-party updates and applying them when they become available.

References 

Apache Advisory

Version 2.15

Vulnerability Details and Remediation Advice

Researchers published details on a critical vulnerability affecting Network Security Services (NSS), a set of cryptographic libraries that support a range of security standards in multiple applications. Some vendors that distribute NSS in their products have already released advisories or updates to fix the flaw. Timely updates are recommended.

Details
NSS is a set of open source cryptographic libraries used for cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.

Tracked as CVE-2021-43527, the vulnerability affects any standard use of NSS released since October 2012 (versions 3.14 and later). On 1 December 2021, Mozilla fixed the issue in NSS versions 3.68.1 ESR and 3.73.3.

Researcher Tavis Ormandy, who dubbed this flaw BigSig, described the issue as a heap overflow occurring when handling DER-encoded DSA or RSA-PSS signatures. Depending on how NSS is configured, the problem occurs in the way NSS verifies certificates, both when a client reads the certificate message from the server, and when the server is configured to ask for client certificates.

Disabled signature methods or certificate types would not prevent the exploitation, as NSS parses the certificates before performing any other checks. This could allow remote execution of arbitrary code, denial of service, and more.

Mozilla Firefox web browser is not vulnerable as it uses the mozilla::pkix for certificate verification. Chromium, Tor Browser, and Brave are also not affected by this flaw.

TLS and DTLS clients using NSS in certificate verification routines and servers that have certificate-based client authentication enabled are affected. Applications using NSS for handling signatures encoded within CMS, S/MIME, PKCS #7, or PKCS #12 are likely to be impacted. Applications using NSS for certificate validation or other TLS, X.509, OCSP or CRL functionality may be impacted, depending on how they configure NSS.

Some vendors that distribute NSS in their products have already released advisories or updates:

•  Red Hat
•  Fedora
•  Ubuntu Advisory on Thunderbird
•  SUSE/OpenSUSE updates
•  Debian
• Arch Linux
• Gentoo
• FreeBSD

Other applications that rely on NSS for signature verification are believed to be vulnerable:

• AOL Instant Messenger (AIM)
• Open-source client applications such as Evolution, Pidgin, Apache OpenOffice, and LibreOffice
• Server products from Red Hat, including Red Hat Directory Server, Red Hat Certificate System, and the mod_nss SSL module for the Apache web server
• Server products from Oracle, including Oracle Communications Messaging Server and Oracle Directory Server Enterprise Edition

Recommendations
We recommend monitoring for vendor update releases and timely patching of affected products.

The vfychain tool distributed with NSS can be used to test for this vulnerability. Running `vfychain -a {input.cert}` will cause a segmentation fault condition on vulnerable versions and a failed verification condition on fixed versions.

References 

Vulnerability Details

Mozilla Advisory