CERT/CC

McAfee Agent contains a privilege escalation vulnerability due to the use of an OPENSSLDIR variable that specifies a location where an unprivileged Windows user may be able to place files.

CVE-2022-0166

McAfee Agent, which comes with various McAfee products such as McAfee Endpoint Security, includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory that my be controllable by an unprivileged user on Windows. McAfee Agent contains a privileged service that uses this OpenSSL component. A user who can place a specially-crafted openssl.cnf file at an appropriate path may be able to achieve arbitrary code execution with SYSTEM privileges.

By placing a specially-crafted openssl.cnf in a location used by McAfee Agent, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable McAfee Agent software installed.

This vulnerability is addressed in McAfee Agent version 5.7.5.

This vulnerability was reported by Will Dormann of the CERT/CC.

This document was written by Will Dormann.

Various Silicon Labs Z-Wave chipsets do not support encryption, can be downgraded to not use weaker encryption, and are vulnerable to denial of service. Some of these vulnerabilities are inherent in Z-Wave protocol specifications.

Z-Wave devices based on Silicon Labs chipsets have multiple vulnerabilities. For further details, including specific devices tested, see Riding the IoT Wave With VFuzz: Discovering Security Flaws in Smart Homes.

CVE-2020-9057 Z-Wave devices based on Silicon Labs 100, 200, and 300 series chipsets do not support encryption.

CVE-2020-9058 Z-Wave devices based on Silicon Labs 500 series chipsets using CRC-16 encapsulation do not implement encryption or replay protection.

CVE-2020-9059 Z-Wave devices based on Silicon Labs 500 series chipsets using S0 authentication are susceptible to uncontrolled resource consumption which can lead to battery exhaustion.

CVE-2020-9060 Z-Wave devices based on Silicon Labs 500 series chipsets using S2 are susceptible to denial of service and resource exhaustion via malformed SECURITY NONCE GET, SECURITY NONCE GET 2, NO OPERATION, or NIF REQUEST messages.

CVE-2020-9061
Z-Wave devices using Silicon Labs 500 and 700 series chipsets are susceptible to denial of service via malformed routing messages.

Depending on the chipset and device, an attacker within Z-Wave radio range can deny service, cause devices to crash, deplete batteries, intercept, observe, and replay traffic, and control vulnerable devices.

Mitigations for these vulnerabilities vary based on the chipset and device. In some cases it may be necessary to upgrade to newer hardware, for example, 500 and 700 series chipsets that support S2 authentication and encryption.

Thanks to Carlos Nkuba Kayembe, Kim Seulbae, Sven Dietrich, and Heejo Lee for reporting these vulnerabilities.

This document was written by and Timur Snoke and Art Manion.

Saviynt Enterprise Identity Cloud contains user enumeration and authentication bypass vulnerabilities in the local password reset feature. Together, these vulnerabilities could allow a remote, unauthenticated attacker to gain administrative privileges if an SSO solution is not configured for authentication.

Saviynt Enterprise Identity Cloud contains two vulnerabilities in the password reset feature for the local authentication system. Specifying the id parameter returns user names and it is common that accounts with administrative privileges have low (often single digit) id values.

/ECM/maintenance/forgotpasswordstep1?otpConfig=false&id=5

It is then possible to either unhide a button or directly access a URL that bypasses verification and allows the password to be changed. Accessing a login URL with the new credentials yields cookies that can be used to authenticate to the Enerprise Identity Cloud instance.

If another authentication or SSO system is configured, then it is not possible to exploit these vulnerabilities.

A remote, unauthenticated attacker can enumerate users and bypass authentication to change the password of an existing administrative user. The attacker can then perform administrative actions and possibly make changes to other connected authentication systems.

Saviynt has deployed a backend update for the software that is intended to address the issue in Saviynt IGA Release v5.5 SP2.x and later versions. Saviynt has also blocked access to some of the URLs need to exploit these vulnerabilities.

Saviynt users should not need to take any action but might want to confirm they are running a fixed version.

This document was written by Eric Hatleback and Art Manion.

Apache Log4j allows insecure JNDI lookups that could allow an unauthenticated, remote attacker to execute arbitrary code with the privileges of the vulnerable Java application using Log4j.

CISA has published Apache Log4j Vulnerability Guidance and provides a Software List.

The default configuration of Apache Log4j supports JNDI (Java Naming and Directory Interface) lookups that can execute arbitrary code provided by remote services such as LDAP, RMI, and DNS.

More information is available from the Apache Log4j Security Vulnerabilities page, including these highlights:

Log4j 1.x

Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

log4j-core

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

CVE-2021-44228 tracks the initial JNDI injection and RCE vulnerability in Log4j 2. CVE-2021-4104 tracks a very similar vulnerability that affects Log4j 1 if JMSAppender and malicious connections have been configured. CVE-2021-45046 tracks an incomplete fix for CVE-2021-44228 affecting Log4j 2.15.0 when an attacker has "...control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern."

We provide tools to scan for vulnerable jar files.

A remote, unauthenticated attacker with the ability to log specially crafted messages can cause Log4j to connect to a service controlled by the attacker to download and execute arbitrary code.

In Log4j 2.12.2 (for Java 7) and 2.16.0 (for Java 8 or later) the message lookups feature has been completely removed. In addition, JNDI is disabled by default and other default configuration settings are modified to mitigate CVE-2021-44228 and CVE-2021-45046.

For Log4j 1, remove the JMSAppender class or do not configure it. Log4j 1 is not supported and likely contains unfixed bugs and vulnerabilities such as CVE-2019-17571.

For applications, services, and systems that use Log4j, consult the appropriate vendor or provider. See the CISA Log4j Software List and the Vendor Information section below.

Remove the JndiLookup class from the classpath, for example:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

As analysis has progressed, certain mitigations have been found to be incomplete. See "Older (discredited) mitigation measures" on the Apache Log4j Security Vulnerabilities page.

SLF4J also recommends write-protecting Log4j configuration files.

Apache credits Chen Zhaojun of Alibaba Cloud Security Team for reporting CVE-2021-44228 and CVE-2021-4104 and Kai Mindermann of iC Consult for CVE-2021-45046.

Much of the content of this vulnerability note is derived from Apache Log4j Security Vulnerabilities and http://slf4j.org/log4shell.html.

This document was written by Art Manion.

Attacks that allow for unintended control of Unicode and homoglyphic characters, described by the researchers in this report leverage text encoding that may cause source code to be interpreted differently by a compiler than it appears visually to a human reviewer. Source code compilers, interpreters, and other development tools may permit Unicode control and homoglyph characters, changing the visually apparent meaning of source code.

Internationalized text encodings require support for both left-to-right languages and also right-to-left languages. Unicode has built-in functions to allow for encoding of characters to account for bi-directional, or Bidi ordering. Included in these functions are characters that represent non-visual functions. These characters, as well as characters from other human language sets (i.e., English vs. Cyrillic) can also introduce ambiguities into the code base if improperly used.

This type of attack could potentially be used to compromise a code base by capitalizing on a gap in visually rendered source code as a human reviewer would see and the raw code that the compiler would evaluate.

The use of attacks that incorporate maliciously encoded source code may go undetected by human developers and by many automated coding tools. These attacks also work against many of the compilers currently in use. An attacker with the ability to influence source code could introduce undetected ambiguity into source code using this type of attack.

The simplest defense is to ban the use of text directionality control characters both in language specifications and in compilers implementing these languages.

Two CVEs were assigned to address the two types of attacks described in this report.

CVE-2021-42574 was created for tracking the Bidi attack. CVE-2021-42694 was created for tracking the homoglyph attack.

Thanks to the reporters, Nicholas Boucher and Ross Anderson of The University of Cambridge (UK).

This document was written by Chuck Yarbrough.

The default security configuration in Salesforce allows an authenticated user with the Salesforce-CLI to create URL that will allow anyone, anywhere access to the Salesforce GUI with the same administrative credentials without a log trace of access or usage of the API.

The Salesforce-cli interface allows an authenticated user to create an access URL using the CLI interface. This URL can be shared as a link, so anyone who has the link can access this site from anywhere (any IP address or any device) with the same access rights as the creator or the URL. This access is only available for the duration of the access token, however this new access will not be logged or tracked in any way available to the user or to the user's organization. The generated URL requires no user/pass or any form of challenge/response, such as MFA, to verify the identity of the new access. OWASP API Security 2019 recommends a number of protections (relevant sections API2:2019, API6:2019 and API10:2019) of API endpoints that will prevent potential abuse of such API endpoints by malicious actors, including malicious insiders.

An unauthenticated user who gains access to an URL, generated by Salesforce-cli, can perform administrative actions as if logged in with the same rights as the account owner who generated the URL. This includes the ability to add user accounts that have administrative rights, manage existing users or applications, and any other action that is available to the user who generated the URL.

In the Salesforce GUI you can Modify Session Security Settings, it is possible to Lock Sessions to the IP address that the session originated on, which would limit the ability for the URL to be shared with other hosts. The default configuration does not have this lock enabled because it may impact various applications and some mobile devices. It is also possible to lock down sessions using domain names instead of IP addresses. It is recommended that Salesforce customers verify that their applications do not require such untethered or unmonitored access or that using custom generated URL's is currently required in their operations before enforcing the above recommended access control.

Thanks to the reporter, who wishes to remain anonymous, for reporting this vulnerability.

This document was written by Timur Snoke.