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.
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 based on Silicon Labs 500 and 700 series chipsets are susceptible to denial of service via malformed routing messages.
CVE-2020-10137 Z-Wave devices based on Silicon Labs 700 series chipsets using S2 do not adequately authenticate or encrypt FIND_NODE_IN_RANGE frames.
Impact
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.
Solution
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.
Acknowledgements
Thanks to Carlos Kayembe Nkuba, Seulbae Kim, Sven Dietrich, and Heejo Lee for researching and reporting these vulnerabilities.
This document was written by 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.
Description
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.
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.
Impact
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.
Solution
Saviynt has deployed a backend update for the software that resolves the issue in Saviynt IGA Release v5.5 SP2.x and later versions. As an additional layer of security, as the impacted URLs are not commonly used by customers leveraging SSO, Saviynt has blocked access to the URLs needed to exploit these vulnerabilities.
Saviynt users should not need to take any action but might want to confirm they are running a fixed version.
Acknowledgements
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.
The default configuration of Apache Log4j supports JNDI (Java Naming and Directory Interface) lookups that can be exploited to exfiltrate data or execute arbitrary code via remote services such as LDAP, RMI, and DNS.
This vulnerability note includes information about the following related vulnerabilities.
CVE-2021-44228 tracks the initial JNDI injection and RCE vulnerability in Log4j 2. This vulnerability poses considerabily more risk than the others.
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.
Certain conditions must be met to make Log4j 1.x vulnerable:
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 API code alone is not affected:
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.
Impact
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.
Solution
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.
Workarounds
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 less effective or incomplete. See "Older (discredited) mitigation measures" on the Apache Log4j Security Vulnerabilities page.
SLF4J also recommends write-protecting Log4j configuration files.
Acknowledgements
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.
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.
Description
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.
Impact
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.
Solution
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.
Acknowledgements
Thanks to the reporters, Nicholas Boucher and Ross Anderson of The University of Cambridge (UK).
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.
Description
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.
Impact
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.
Solution
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.
Acknowledgements
Thanks to the reporter, who wishes to remain anonymous, for reporting this vulnerability.
HCC Embedded's software called InterNiche stack (NicheStack) and NicheLite, which provides TCP/IP networking capability to embedded systems, is impacted by multiple vulnerabilities. The Forescout and JFrog researchers who discovered this set of vulnerabilities have identified these as "INFRA:HALT"
Description
HCC Embedded acquired NicheStack from Interniche in order to provide TCP/IP protocol capabilities to lightweight devices such as IoT. NicheStack has been made available since late 1990's to a widely varied customer base in multiple forms to support various implementations. This has made NicheStack to be part of a complex supply chain into major industries including devices in critical infrastructure.
Forescout and JFrog researchers have identified 14 vulnerabilities related to network packet processing errors in NicheStack and NicheLite versions 4.3 released before 2021-05-28. Most of these vulnerabilities stem from improper memory management commonly seen in lightweight operating systems. Of these 14 vulnerabilities, five involve processing of TCP and ICMP (OSI Layer-4 protocols) and the rest involve common application protocols such as HTTP and DNS (OSI Layer-7). The processing of these OSI layers involve a number of boundary checks and some specific "application" processing capabilities (such as randomization) commonly overlooked in development of lightweight networking software.
Various stakeholders, including HCC Embedded, have made attempts to reach impacted vendors to provide software fixes that address these issues. A lack of formalization of software OEM relationships and a lack of Software Bill of Materials (SBOM) has complicated this outreach and the much-needed identification of impacted devices.
Impact
The impact of exploiting these vulnerabilities will vary widely, depending on the implementation options used while developing embedded systems that use NicheStack or NicheLite. As these vulnerabilities involve processing of network packets, attackers can generally abuse these errors via remote network access. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, or in some cases be able to execute arbitrary code on the target device.
Solution
Apply updates
The most reliable way to address these vulnerabilities is to update to the latest stable version of NicheStack software mentioned in HCC Embedded mentioned in their Security Advisories. If you are unsure or have discovered NicheStack using open-source tools provided by Forescout, reach out to HCC Embedded via their PSIRT security team or to your upstream vendor in your supply chain to obtain the software fixes. HCC has also provided a register to be notified web page for sustaining this outreach for their long-standing customers.
Block anomalous IP traffic
CERT/CC recognizes that many implementations of NicheStack involve longer lifecycles for patching. In the meantime, if feasible, organizations can consider isolating impacted devices and blocking network attacks using network inspection, as detailed below, when network isolation is not feasible. It is recommended that security features available to you in devices such as router, firewalls for blocking anomalous network packets are enabled and properly configured. Below is a list of possible mitigations that address some specific network attacks that attempt to exploit these vulnerabilities.
Provide DNS recursion services to the embedded devices using recursive DNS servers that are securely configured, and well-maintained with patches and updates.
Provide HTTP access to embedded devices that are in an isolated network via securely configured HTTP reverse proxy or using HTTP deep packet inspection firewalls.
Filter ICMP and TFTP access to embedded devices from the wider Internet and use stateful inspection of these protocols when accessible to wider Internet to avoid abuse.
Enforce TCP stateful inspection for embedded device and reject malformed TCP packets using router, firewall features as available to the operational environment.
When blocking or isolating is not an option, perform passive inspection using IDS that can alert on anomalous attempts to exploit these vulnerabilities. See also our recommendations and IDS rules that were made available for Treck TCP/IP stack related vulnerabilities VU#257161 for examples.
Acknowledgements
Thanks to Amine Amri, Stanislav Dashevskyi, and Daniel dos Santos from Forescout, and Asaf Karas and Shachar Menashe from JFrog who reported these vulnerabilities and supported coordinated disclosure. HCC Embedded, the primary OEM vendor, also supported our efforts to coordinate and develop security fixes to address these issues.
HTTP web proxies and web accelerators that support HTTP/2 for an HTTP/1.1 backend webserver are vulnerable to HTTP Request Smuggling.
Description
The affected systems allow invalid characters such as carriage return and newline characters in HTTP/2 headers. When an attacker passes these invalid contents to a vulnerable system, the forwarded HTTP/1 request includes the unintended malicious data. This is commonly known as HTTP Request Splitting. In the case of HTTP web proxies, this vulnerability can lead to HTTP Request smuggling, which enables an attacker to access protected internal sites.
Impact
An attacker can send a crafted HTTP/2 request with malicious content to bypass network security measures, thereby reaching internal protected servers and accessing sensitive data.
Solution
Apply updates
Install vendor-provided patches and updates to ensure malicious HTTP/2 content is blocked or rejected as described in RFC 7540 (Section 8.1.2.6) and RFC 7540 (Section 10.3). Both "request" and "response" should be inspected by the web proxy and rejected in accordance with Stream Error Handling as described in RFC 7450 (Section 5.4.2).
Inspect and block anomalous HTTP/2 traffic
If HTTP/2 is not supported, block the protocol on the web proxies to avoid abuse of HTTP/2 protocol. Where HTTP/2 is supported, enforce strict rules for HTTP header checks to ensure malicious headers are normalized or rejected. Checks of this type include:
* HTTP Headers with invalid Header name or value
* HTTP Headers with invalid or no content-length
* Unsupported or invalid HTTP methods
Test and verify your web proxy
Scan your public web server proxy with OWASP recommended tests to ensure your web servers are not vulnerable to abuse via HTTP response splitting.
Acknowledgements
Thanks to the reporter James Kettle of PortSwigger for the information about this vulnerability.
Microsoft Windows Active Directory Certificate Services (AD CS) by default can be used as a target for NTLM relay attacks, which can allow a domain-joined computer to take over the entire Active Directory.
Description
PetitPotam is a tool to force Windows hosts to authenticate to other machines by using the Encrypting File System Remote (EFSRPC)EfsRpcOpenFileRaw and other methods. When a system handles certain EFSRPC requests, it will by default use NTLM to authenticate with the host that is specified within the path to the file specified in the EFSRPC request. The user specified in the NTLM authentication information is the computer account of the machine that made the EFSRPC request.
Code running on any domain-joined system will leverage Single Sign-On (SSO) to call these EFSRPC functions on a domain controller without needing to know the credentials of the current user or any other user in an Active Directory. And because the EFSRPC methods authenticate as the machine dispatching the request, this means that a user of any system connected to an AD domain can trigger an NTLM authentication request as the domain controller machine account to an arbitrary host, without needing to know any credentials. This can allow for NTLM relay attacks. Furthermore, the EfsRpcOpenFileRaw function can be invoked in a truly anonymous manner, without requiring credentials via SSO or other means.
One publicly-discussed target for an NTLM relay attack from a domain controller is a machine that hosts Microsoft AD CS. By relaying an NTLM authentication request from a domain controller to the Certificate Authority Web Enrollment or the Certificate Enrollment Web Service on an AD CS system, an attacker can obtain a certificate that can be used to obtain a Ticket Granting Ticket (TGT) from the domain controller. This attack, known as a "Golden Ticket" attack, can be used to fully compromise the entire Active Directory infrastructure.
Although Microsoft refers to this entire attack chain as "PetitPotam" in KB5005413, it is important to realize that PetitPotam is simply the single PoC exploit used to invoke an NTLM authentication request by way of a EfsRpcOpenFileRaw request. It should be noted that:
There may be other techniques that may cause a Windows system to initiate a connection to an arbitrary host using privileged NTLM credentials.
There may be services other than AD CS that may be leveraged to use as a target for a relayed NTLM authentication request.
Impact
By making a crafted RPC request to a vulnerable Windows system, a remote attacker may be able to leverage the NTLM authentication information that is included in the request that is generated. In the case of AD CS, this can allow an attacker on any domain-joined system to be able to compromise the Active Directory.
Solution
Apply an update
This issue is partially addressed in the Microsoft update for CVE-2021-36942. This update blocks the unauthenticated EfsRpcOpenFileRaw API call that is exposed through the LSARPC interface. Note that the EFSRPC interface for accessing EfsRpcOpenFileRaw is still reachable to authenticated users after installing this update. In addition, other EFSRPC functions that require authentication to exploit are still exposed to users via LSARPC after this update is installed. This required authentication may take place silently via SSO on domain-joined systems. Please see KB5005413 for several additional workarounds that can help mitigate other techniques for relaying NTLM credentials using an AD CS server.
Enable Extended Protection for Authentication (EPA) and Require SSL on AD CS systems
Please see KB5005413 for more details about enabling EPA to help protect against this weakness. It is important to note:
In addition to configuring EPA through the IIS Manager GUI, the Certificate Enrollment Web Service (CES) also requires modifying the web.config file to successfully enable EPA.
The CES and the CertSrv applications must be configured to enable the Require SSL option for EPA protection to work. If Require SSL is not enabled, then any changes to the EPA settings will not have any effect.
Disable incoming NTLM on AD CS servers
The stage of leveraging an AD CS server to achieve the ability to get a TGT can be mitigated by disabling incoming NTLM support on AD CS servers. To configure this GPO setting, go to: Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and set Network security: Restrict NTLM: Incoming NTLM traffic to Deny All Accounts or Deny All domain accounts
Note that the group policy may need to be refreshed on the AD CS server for this mitigation to take effect.
Disable the NTLM provider in IIS
For both the "Certificate Authority Web Enrollment" (CES) service (<CA_INFO>-CA_CES_Kerberos in IIS Manager) and the "Certificate Enrollment Web Service" (CertSrv in IIS Manager) services:
Open IIS Manager
Select Sites -> Default Web Site (or another name if it was manually reconfigured) -> *-CA_CES_Kerberos and CertSrv
Select Windows Authentication
Click the Providers... link on the right side
Select NTLM
Click the Remove Button
Restart IIS from an Administrator CMD prompt: iisreset /restart
Block [MS-ESFR] (EFSRPC) using RPC filters
RPC filters can be used to block the (remote) EFSRPC functionality that PetitPotam uses. This can be done by blocking the RPC interface UUIDs for EFSRPC.
First create a file called block_efsr.txt and place the following contents in it:
Then import the filter using the following command from an elevated-privileged command prompt: netsh -f block_efsr.txt
Alternatively, the above text block can be pasted into an interactive netsh session if you wish to avoid the use of a file to import the rules from.
The current filters can be viewed by running the following command: netsh rpc filter show filter.
All RPC filters can be removed using the following command: netsh rpc filter delete filter filterkey= This will restore Windows to its default configuration of not having any RPC filters. If you have other RPC filters in place and wish to remove only the EFSRPC filters, you can specify the specific filterKey values that are reported by the show filter command listed above.
Disable NTLM Authentication on your Windows domain controller
Note that existing logins may need to be terminated for this mitigation to take effect. Also note that disabling NTLM has been reported by some to be disruptive to expected network functionality. For this reason, please consider the other workarounds in this vulnerability note.
Acknowledgements
The PetitPotam aspect of this attack chain was publicly disclosed by topotam. The AD CS aspect was publicly disclosed by harmj0y (Will Schroeder) and tifkin_ (Lee Christensen).
A path traversal vulnerability exists in numerous routers manufactured by multiple vendors using Arcadyan based software. This vulnerability allows an unauthenticated user access to sensitive information and allows for the alteration of the router configuration.
Description
The vulnerability, identified as CVE-2021-20090, is a path traversal vulnerability. An unauthenticated attacker is able to leverage this vulnerability to access resources that would normally be protected. The researcher initially thought it was limited to one router manufacturer and published their findings, but then discovered that the issue existed in the Arcadyan based software that was being used in routers from multiple vendors.
Impact
Successful exploitation of this vulnerability could allow an attacker to access pages that would otherwise require authentication. An unauthenticated attacker could gain access to sensitive information, including valid request tokens, which could be used to make requests to alter router settings.
Solution
The CERT/CC recommends updating your router to the latest available firmware version. It is also recommended to disable the remote (WAN-side) administration services on any SoHo router and also disable the web interface on the WAN.
Multiple versions of Windows 10 grant non-administrative users read access to files in the %windir%\system32\config directory. This can allow for local privilege escalation (LPE).
Description
With multiple versions of Windows 10, the BUILTIN\Users group is given RX permissions to files in the %windir%\system32\config directory.
If a VSS shadow copy of the system drive is available, a non-privileged user may leverage access to these files to achieve a number of impacts, including but not limited to:
Extract and leverage account password hashes.
Discover the original Windows installation password.
Obtain DPAPI computer keys, which can be used to decrypt all computer private keys.
Note that VSS shadow copies may not be available in some configurations, however simply having a system drive that is larger that 128GB in size and then performing a Windows Update or installing an MSI will ensure that a VSS shadow copy will be automatically created. To check if a system has VSS shadow copies available, run the following command from a privileged command prompt:
vssadmin list shadows
A system with VSS shadow copies will report details of at least one shadow copy that specifies Original Volume: (C:), such as the following:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
Contents of shadow copy set ID: {d9e0503a-bafa-4255-bfc5-b781cb27737e}
Contained 1 shadow copies at creation time: 7/19/2021 10:29:49 PM
Shadow Copy ID: {b7f4115b-4242-4e13-84c0-869524965718}
Original Volume: (C:)\\?\Volume{4c1bc45e-359f-4517-88e4-e985330f72e9}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Originating Machine: DESKTOP-PAPIHMA
Service Machine: DESKTOP-PAPIHMA
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered
A system without VSS shadow copies will produce output like the following:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.
No items found that satisfy the query.
To check if a system is vulnerable, the following command can be used from a non-privileged command prompt: icacls %windir%\system32\config\sam
A vulnerable system will report BUILTIN\Users:(I)(RX) in the output like this:
This vulnerability has been publicly referred to as both HiveNightmare and SeriousSAM, while Microsoft has assigned CVE-2021-36934 to the vulnerability.
Impact
By accessing files in the Windows %windir%\system32\config directory on a vulnerable system with at least one VSS shadow copy of the system drive, a local authenticated attacker may be able to achieve LPE, masquerade as other users, or achieve other security-related impacts.
Restrict access to %windir%\system32\config and remove VSS shadow copies
Vulnerable systems can enable ACL inheritance for files in the %windir%\system32\config directory by running the following command from an elevated prompt:
Once the ACLs have been corrected for these files, any VSS shadow copies of the system drive must be deleted to protect a system against exploitation. This can be accomplished with the following command:
vssadmin delete shadows /for=%systemdrive% /Quiet
Confirm that VSS shadow copies were deleted by running vssadmin list shadows again. Note that any capabilities relying on existing shadow copies, such as System Restore, will not function as expected. Newly-created shadow copies, which will contain the proper ACLs, will function as expected. Please see KB5005357 for more details.
Acknowledgements
This vulnerability was publicly disclosed by Jonas Lyk, with additional details provided by Benjamin Delpy.
Microsoft Windows allows for non-admin users to be able to install printer drivers via Point and Print. Printers installed via this technique also install queue-specific files, which can be arbitrary libraries to be loaded by the privileged Windows Print Spooler process.
Description
Microsoft Windows allows for users who lack administrative privileges to still be able to install printer drivers, which execute with SYSTEM privileges via the Print Spooler service. This ability is achieved through a capability called Point and Print. Starting with the update for MS16-087, Microsoft requires that printers installable via Point are either signed by a WHQL release signature, or are signed by a certificate that is explicitly trusted by the target system, such as an installed test signing certificate. The intention for this change is to avoid installation of malicious printer drivers, which can allow for Local Privilege Escalation (LPE) to SYSTEM.
While Windows enforces that driver packages themselves are signed by a trusted source, Windows printer drivers can specify queue-specific files that are associated with the use of the device. For example, a shared printer can specify a CopyFiles directive for arbitrary files. These files, which may be copied over alongside the digital-signature-enforced printer driver files are not covered by any signature requirement. Furthermore, these files can be used to overwrite any of the signature-verified files that were placed on a system during printer driver install. The remote printer can also be configured to automatically execute code in any files dropped by the CopyFiles directive. This can allow for LPE to SYSTEM on a vulnerable system.
By connecting to a malicious printer, an attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system.
Solution
Microsoft has published updates for CVE-2021-36958 regarding this issue. Please also consider the following workarounds:
Block outbound SMB traffic at your network boundary
Public exploits for this vulnerability utilize SMB for connectivity to a malicious shared printer. If outbound connections to SMB resources are blocked, then this vulnerability may be mitigated for malicious SMB printers that are hosted outside of your network. Note that an attacker local to your network would be able to share a printer via SMB, which would be unaffected by any outbound SMB traffic rules.
Configure both PackagePointAndPrintServerList and PackagePointAndPrintOnly settings
Microsoft Windows has a Group Policy called "Package Point and Print - Approved servers", which is reflected in the HKLM\Software\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\PackagePointAndPrintServerList and HKLM\Software\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\ListofServers registry values. This policy can restrict which servers can be used by non-administrative users to install printers via Point and Print. Configure this policy to prevent installation of printers from arbitrary servers.
To ensure that Microsoft Windows only attempts to install Package Point and Print printers, and therefore restricting printer connections to the approved servers list, you must also set the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\PackagePointAndPrintOnly registry value to 1. The Group Policy setting that corresponds to this value is called "Use only Package Point and print". Setting this value to "Enabled" will enforce that only Package Point and Print printers will be used.
Both of these settings must be configured to protect against exploitation of this vulnerability.
Block the ability to modify the print spooler drivers directory
Courtesy of the TRUESEC Blog, this vulnerability can be mitigated by preventing the SYSTEM account from being able to modify the C:\Windows\System32\spool\drivers directory contents.
To enable this mitigation, from a privileged PowerShell session, run:
The Microsoft Windows Print Spooler service fails to restrict access to functionality that allows users to add printers and related drivers, which can allow a remote authenticated attacker to execute arbitrary code with SYSTEM privileges on a vulnerable system.
Description
The RpcAddPrinterDriverEx() function is used to install a printer driver on a system. One of the parameters to this function is the DRIVER_CONTAINER object, which contains information about which driver is to be used by the added printer. The other argument, dwFileCopyFlags, specifies how replacement printer driver files are to be copied. An attacker can take advantage of the fact that any authenticated user can call RpcAddPrinterDriverEx() and specify a driver file that lives on a remote server. This results in the Print Spooler service spoolsv.exe executing code in an arbitrary DLL file with SYSTEM privileges.
While Microsoft has released an update for CVE-2021-1675, it is important to realize that this update does NOT protect against public exploits that may refer to PrintNightmare or CVE-2021-1675.
On July 1, Microsoft released CVE-2021-34527. This bulletin states that CVE-2021-34527 is similar but distinct from the vulnerability that is assigned CVE-2021-1675, which addresses a different vulnerability in RpcAddPrinterDriverEx(). The attack vector is different as well. CVE-2021-1675 was addressed by the June 2021 security update.
Impact
By sending a request to add a printer, e.g. by using RpcAddPrinterDriverEx() over SMB or RpcAsyncAddPrinterDriver() over RPC, a remote, authenticated attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system. A local unprivileged user may be able to execute arbitrary code with SYSTEM privileges as well. We have created a flowchart to indicate exploitability of PrintNightmare across various platform configurations:
Solution
Apply an update
Microsoft has addressed this issue in the updates for CVE-2021-34527. Note that the Microsoft update for CVE-2021-34527 does not effectively prevent exploitation of systems where the Point and PrintNoWarningNoElevationOnInstall is set to a non-0 value. Microsoft indicates that systems that have NoWarningNoElevationOnInstall is set to a non-0 value are vulnerable by design. For systems that do not have the CVE-2021-34527 installed, or have Point and Print configured insecurely, please consider the following workarounds:
Microsoft Option 1 - Stop and disable the Print Spooler service
This vulnerability can be mitigated by stopping and disabling the Print Spooler service in Windows.
If disabling the Print Spooler service is appropriate for your enterprise, use the following PowerShell commands:
Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled
Impact of workaround Disabling the Print Spooler service disables the ability to print both locally and remotely.
Microsoft Option 2 - Disable inbound remote printing through Group Policy
Disable the “Allow Print Spooler to accept client connections:” policy to block remote attacks.
Impact of workaround This policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible.
Note: The Print Spooler service must be restarted for this workaround to be activated.
Block RPC and SMB ports at the firewall
Limited testing has shown that blocking both the RPC Endpoint Mapper (135/tcp) and SMB (139/tcp and 445/tcp) incoming traffic at a host-based firewall level can prevent remote exploitation of this vulnerability. Note that blocking these ports on a Windows system may prevent expected capabilities from functioning properly, especially on a system that functions as a server.
Enable security prompts for Point and Print
Ensure that the Windows Point and Print Restrictions are set to Show warning and elevation prompt for both installing and updating drivers in the Windows Group Policy. Specifically the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\ key should have NoWarningNoElevationOnInstall and UpdatePromptSettings entries that are both set to 0.
Restrict printer driver installation ability to administrators
After the Microsoft update for CVE-2021-34527 is installed, a registry value called RestrictDriverInstallationToAdministrators in the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\ key is checked, which is intended to restrict printer driver installation to only administrator users. Please see KB5005010 for more details.
Acknowledgements
This issue was publicly disclosed by Zhiniang Peng and Xuefeng Li.
Checkbox Survey prior to version 7.0 insecurely deserializes ASP.NET View State data, which can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable server.
Description
CVE-2021-27852 Checkbox Survey insecurely deserializes ASP.NET View State data.
Checkbox Survey is an ASP.NET application that can add survey functionality to a website. Prior to version 7.0, Checkbox Survey implements its own View State functionality by accepting a _VSTATE argument, which it then deserializes using LosFormatter. Because this data is manually handled by the Checkbox Survey code, the ASP.NET ViewState Message Authentication Code (MAC) setting on the server is ignored. Without MAC, an attacker can create arbitrary data that will be deserialized, resulting in arbitrary code execution.
This vulnerability is reportedly being exploited in the wild.
Impact
By making a specially-crafted request to a server that uses Checkbox Survey 6.x or earlier, a remote, unauthenticated attacker may be able to execute arbitrary code with the privileges of the web server.
Solution
Apply an update
Starting with Checkbox Survey 7.0, View State data is not used. Therefore, Checkbox Survey versions 7.0 and later do not contain this vulnerability.
Remove Checkbox Survey versions older than 7
Checkbox is no longer developing Checkbox Survey version 6, so this version is no longer safe to use. If you are unable to update to an unaffected version of Checkbox Survey, this software should be removed from any systems that have it installed.
Acknowledgements
Thanks to the reporter who wishes to remain anonymous.
Pulse Connect Secure (PCS) gateway contains a buffer overflow vulnerability in Samba-related code that may allow an authenticated remote attacker to execute arbitrary code.
Description
CVE-2021-22908
PCS includes the ability to connect to Windows file shares (SMB). This capability is provided by a number of CGI scripts, which in turn use libraries and helper applications based on Samba 4.5.10. When specifying a long server name for some SMB operations, the smbclt application may crash due to either a stack buffer overflow or a heap buffer overflow, depending on how long of a server name is specified. We have confirmed that PCS 9.1R11.4 systems are vulnerable, targeting a CGI endpoint of: /dana/fb/smb/wnf.cgi. Other CGI endpoints may also trigger the vulnerable code.
Specifying a long server name to this endpoint may result in a PCS events log entry that may look like the following:
Successful exploitation of this vulnerability may not produce such a log entry if the program is cleanly exited during exploitation, or if the log files are sanitized after successful exploitation.
In order to be vulnerable, a PCS server must have a Windows File Access policy that allows\\* or it must have some other policy set that would allow an attacker to connect to an arbitrary server. In the administrative page for the PCS, see Users -> Resource Policies -> Windows File Access Policies to view your current SMB policy. Any PCS device that started as version 9.1R2 or earlier will have a default policy that allows connecting to arbitrary SMB hosts. Starting with 9.1R3, this policy was changed from a default allow to a default deny.
Note that the vendor implies that the Files, Window[sic] access feature can be disabled for user roles in order to protect against this vulnerability. This is NOT the case. The vulnerable CGI endpoints are still reachable in ways that will trigger the smbclt application to crash, regardless of whether the Files, Windows user role is enabled or not. These steps are only included in the advisory to limit excessive errors showing up in PCS logs after the XML workaround has been installed.
In our testing, an attacker would need either valid PCS user credentials, or a DSID value from an authenticated user to successfully reach the vulnerable code on a PCS server that has an open Windows File Access policy. We have created a PoC utility to test for PCS systems vulnerable to CVE-2021-22908 as well as which mitigations may be applied.
Impact
By performing certain SMB operations with a specially-crafted server name, an authenticated attacker may be able to execute arbitrary code with root privileges on a vulnerable PCS server.
Solution
Apply an update
This issue is addressed in PCS 9.1R11.5. Please see advisory SA44800 for more details.
Apply an XML workaround
Pulse Secure has published advisory SA44800 that mentions a Workaround-2105.xml file that contains a mitigation to protect against this vulnerability. Importing this XML workaround will activate the protections immediately and does not require any downtime for the VPN system. This workaround will block requests that match the following URI patterns:
^/+dana/+fb/+smb
^/+dana-cached/+fb/+smb
Workaround-2105.xml will automatically deactivate the mitigations applied by Workaround-2104.xml when it is installed. As such, it is imperative that a PCS system is running 9.1R11.4 before applying the Workaround-2105.xml mitigation, which will ensure that the vulnerabilities outlined in SA44784 are not reintroduced as the result of applying this workaround.
Note that installing this workaround will block the ability to use the following feature:
Windows File Share Browser
Set a Windows File Access Policy
This vulnerability relies on the ability to connect to an arbitrary SMB server name to trigger the vulnerability. A PCS system that started as version 9.1R3 or later will have a default Initial File Browsing Policy of Deny for \\* SMB connections. If you have a PCS system that started as 9.1R2 or earlier, it will retain the default Initial File Browsing Policy of Allow for \\* SMB connections, which will expose this vulnerability. In the administrative page for the PCS, see Users -> Resource Policies -> Windows File Access Policies to view your current SMB policy.
If your PCS has a policy that explicitly allows \\* or otherwise may allow users to initiate connections to arbitrary SMB server names, you should configure the PCS to Deny connections to such resources to minimize your PCS attack surface.
Acknowledgements
This vulnerability was reported by Will Dormann of the CERT/CC.
Devices supporting the Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure that could allow an attacker to impersonate a legitimate device during pairing.
Description
The Bluetooth Core Specification and Mesh Profile Specification are two specifications used to define the technical and policy requirements for devices that want to operate over Bluetooth connections. Researchers at the Agence nationale de la sécurité des systèmes d'information (ANSSI) have identified a number of vulnerabilities in each specification that allow impersonation attacks and AuthValue disclosures.
Devices supporting the Bluetooth Core Specification are affected by the following vulnerabilities:
Impersonation in the Passkey Entry Protocol
The Passkey Entry protocol used in Secure Simple Pairing (SSP), Secure Connections (SC), and LE Secure Connections (LESC) of the Bluetooth Core Specification is vulnerable to an impersonation attack that enables an active attacker to impersonate the initiating device without any previous knowledge (CVE-2020-26558). An attacker acting as a man-in-the-middle (MITM) in the Passkey authentication procedure could use a crafted series of responses to determine each bit of the randomly generated Passkey selected by the pairing initiator in each round of the pairing procedure, and once identified, the attacker can use these Passkey bits during the same pairing session to successfully complete the authenticated pairing procedure with the responder. Devices supporting BR/EDR Secure Simple Pairing in Bluetooth Core Specifications 2.1 through 5.2, BR/EDR Secure Connections Pairing in Bluetooth Core Specifications 4.1 through 5.2 and LE Secure Connections Pairing in Bluetooth Core Specifications 4.2 through 5.2 are affected by this vulnerability.
Impersonation in the Pin Pairing Protocol
The Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack (CVE-2020-26555). An attacker could connect to a victim device by spoofing the Bluetooth Device Address (BD_ADDR) of the device, reflect the the encrypted nonce, and complete BR/EDR pin-code pairing with them without knowledge of the pin code. A successful attack requires the attacking device to be within wireless range of a vulnerable device supporting BR/EDR Legacy Pairing that is Connectable and Bondable. Devices supporting the Bluetooth Core Specification versions 1.0B through 5.2 are affected by this vulnerability.
Devices supporting Bluetooth Mesh Profile Specification, versions 1.0 and 1.0.1, are affected by the following vulnerabilities:
Impersonation in Bluetooth Mesh Provisioning
The Mesh Provisioning procedure could allow an attacker without knowledge of the AuthValue, spoofing a device being provisioned, to use crafted responses to appear to possess the AuthValue and to be issued a valid NetKey and potentially an AppKey (CVE-2020-26560). For this attack to be successful, an attacking device needs to be within wireless range of a Mesh Provisioner and either spoof the identity of a device being provisioned over the air or be directly provisioned onto a subnet controlled by the provisioner.
Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM
The Mesh Provisioning procedure could allow an attacker observing or taking part in the provisioning to brute force the AuthValue if it has a fixed value, or is selected predictably or with low entropy (CVE-2020-26557). Identifying the AuthValue generally requires a brute-force search against the provisioning random and provisioning confirmation produced by the Provisioner. This brute-force search, for a randomly selected AuthValue, must complete before the provisioning procedure times out, which can require significant resources. If the AuthValue is not selected randomly with each new provisioning attempt, then the brute-force search can occur offline and if successful, would permit an attacker to identify the AuthValue and authenticate to both the Provisioner and provisioned devices, permitting a MITM attack on a future provisioning attempts with the same AuthValue.
Malleable Commitment
The authentication protocol is vulnerable if the AuthValue can be identified during the provisioning procedure, even if the AuthValue is selected randomly (CVE-2020-26556). If an attacker can identify the AuthValue used before the provisioning procedure times out, it is possible to complete the provisioning operation and obtain a NetKey. Similar to CVE-2020-26557, identifying the AuthValue generally requires a brute-force search against the provisioning random and provisioning confirmation produced by the Provisioner. This brute-force search for a randomly selected AuthValue, which can require significant resources, must complete before the provisioning procedure times out.
AuthValue Leak
The Mesh Provisioning procedure could allow an attacker that was provisioned without access to the AuthValue to identify the AuthValue directly without brute-forcing its value (CVE-2020-26559). Even when a randomly generated AuthValue with a full 128-bits of entropy is used, an attacker acquiring the Provisioner’s public key, provisioning confirmation value, and provisioning random value, and providing its public key for use in the provisioning procedure, will be able to compute the AuthValue directly.
Impact
Impersonation in the Passkey Entry Protocol
This vulnerability could allow an attacker to authenticate to the response victim device and act as a legitimate encrypted device. The attacker cannot pair with the initiating device using this method of attack, which prevents a fully transparent man-in-the-middle attack between the initiator and responder. For this attack to be successful, an attacking device needs to be within wireless range of two vulnerable Bluetooth devices that are initiating pairing or bonding for which a BR/EDR IO Capabilities exchange or LE IO Capability in the pairing request and response results in the selection of the Passkey pairing procedure.
Impersonation in the Pin Pairing Protocol
This vulnerability could allow an attacker to complete pairing with a known link key, encrypt communications with the vulnerable device, and access any profiles permitted by a paired or bonded remote device supporting Legacy Pairing.
Impersonation in Bluetooth Mesh Provisioning
This vulnerability could allow an attacker to successfully authenticate without the AuthValue. Once authenticated, the attacker could perform any operation permitted to a node provisioned on the subnet until it is either denied access or a new subnet is formed without the attacking node present.
Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM
This vulnerability could allow an attacker to successfully brute force the AuthValue and authenticate to both the Provisioner and provisioned devices, permitting a MITM attack on a future provisioning attempt with the same AuthValue.
Malleable Commitment
This vulnerability could allow an attacker to obtain a NetKey, which could be used to decrypt and authenticate up to the network layer, allowing the relay of messages, but no application data decryption.
AuthValue Leak
This vulnerability could allow an attacker to compute the AuthValue and authenticate to the Provisioner and provisioned devices.
Solution
Bluetooth users should ensure that they have installed the latest recommended updates from device and operating system manufacturers.
In addition to the two vulnerabilities affecting the Bluetooth Core Specification, the researchers also identified a potential security vulnerability related to LE Legacy Pairing authentication in Bluetooth Core Specification versions 4.0 through 5.2. The researchers claim that an attacker can reflect the confirmation and random numbers of a peer device in LE legacy pairing to successfully complete legacy authentication phase 2 without knowledge of the temporary key (TK). Because the attacker does not acquire a TK, or valid short-term key (STK) during this attack, completing authentication phase 2 is not sufficient for an encrypted link to be established. While the Bluetooth SIG does not consider this to be a method which can provide unauthorized access to a device, they still recommend that LE implementations requiring pairing and encryption use LE Secure Connections. The Bluetooth SIG also recommends that, where possible, implementations enable and enforce Secure Connections Only Mode, ensuring that LE legacy pairing cannot be used.
The Bluetooth SIG additionally makes the following recommendations for each vulnerability:
Impersonation in the Passkey Entry Protocol
For the attack to succeed the pairing device needs to accept the same public key that it provided to the remote peer as the remote peer’s public key. The Bluetooth SIG recommends that potentially vulnerable implementations restrict the public keys accepted from a remote peer device to disallow a remote peer to present the same public key chosen by the local device, and the pairing procedure should be terminated with a failure status if this occurs.
Impersonation in the Pin Pairing Protocol
The Bluetooth SIG recommends that potentially vulnerable devices not initiate or accept connections from remote devices claiming the same BD_ADDR as the local device. They also continue to recommend that devices use Secure Simple Pairing or BR/EDR Secure Connections to avoid known vulnerabilities with legacy BR/EDR pairing.
Impersonation in Bluetooth Mesh Provisioning
The Bluetooth SIG recommends that potentially vulnerable mesh provisioners restrict the authentication procedure and not accept provisioning both random and confirmation numbers from a remote peer that are the same as those selected by the local device.
Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM
The Bluetooth SIG recommends that mesh implementations enforce a randomly selected AuthValue using all of the available bits, where permitted by the implementation. A large entropy helps ensure that a brute-force of the AuthValue, even a static AuthValue, cannot normally be completed in a reasonable time.
Malleable Commitment
The statement from the Bluetooth SIG notes: "AuthValues selected using a cryptographically secure random or pseudorandom number generator and having the maximum permitted entropy (128-bits) will be most difficult to brute-force. AuthValues with reduced entropy or generated in a predictable manner will not grant the same level of protection against this vulnerability. Selecting a new AuthValue with each provisioning attempt can also make it more difficult to launch a brute-force attack by requiring the attacker to restart the search with each provisioning attempt."
AuthValue Leak
The Bluetooth SIG recommends that potentially vulnerable mesh provisioners use an out-of-band mechanism to exchange the public keys.
Acknowledgements
Thanks to researchers at the Agence nationale de la sécurité des systèmes d'information (ANSSI) for reporting these vulnerabilities.
The International Committee of the Red Cross was the victim of a massive cyberattack in which hackers seized the data of more than 515,000 extremely vulnerable people, some of whom had fled conflicts, it said on Wednesday.
A prominent security researcher poking around at the Zoom video conferencing platform found worrying signs the company failed to enable a decades-old anti-exploit mitigation, a blunder that greatly increased exposure to malicious hacker attacks.
The FBI and other federal agencies are increasingly looking to counter cyber threats through tools other than criminal indictments, the head of the bureau’s cyber division said in an interview with The Associated Press.
Thousands of industrial organizations worldwide have been hit in campaigns that leverage short-lived malware to harvest corporate credentials that are then sold by threat actors for a profit, according to Kaspersky.
Tel Aviv, Israel-based cloud security firm Polar Security has emerged from stealth with $8.5 million seed funding in a round led by Glilot Capital Partners with participation from IBI Tech Fund.
Oracle on Tuesday announced its first set of quarterly security updates for 2022, which include a total of 497 new patches. More than half of the addressed vulnerabilities can be exploited remotely without authentication.
BlackBerry’s security researchers have closely analyzed the Prometheus TDS (Traffic Direction System) and discovered a correlation with a leaked Cobalt Strike SSL key pair, as well as with various malware families.
Private equity giant Symphony Technology Group (STG) on Wednesday announced the launch of Trellix, an extended detection and response (XDR) solutions provider created following the merger of McAfee Enterprise and FireEye.
Zero trust network access (ZTNA) solutions provider Banyan Security on Tuesday announced that it has raised $30 million in Series B funding, which brings the total raised by the company to $47 million.
The funding round was led by Third Point Ventures, with participation from Alter Venture Partners, SIG, Shasta Ventures, and Unusual Ventures.
An app all attendees of the upcoming Beijing Olympics must use has encryption flaws that could allow personal information to leak, a cyber security watchdog said Tuesday.
A vulnerability in Box's implementation of multi-factor authentication (MFA) allowed attackers to take over accounts without having access to the victim’s phone, according to new research from Varonis.
