CERT/CC

Overview

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.

This document was written by Will Dormann.

Overview

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:

Critical ERR31093 2021-05-24 14:05:37 - ive - [127.0.0.1] Root::System()[] - Program smbclt recently failed.

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 indicates that the Files, Window[sic] access feature can be disabled for user roles in order to protect against this vulnerability. In our testing, 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. In our testing, an attacker would need a valid DSID and xsauth value from an authenticated user to successfully reach the vulnerable code on a PCS server that has an open Windows File Access policy.

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

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds:

Apply an XML workaround

Pulse Secure has published 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.

This document was written by Will Dormann.

Overview

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 Bluetooth SIG recommends that potentially vulnerable mesh provisioners restrict the authentication procedure and not accept provisioning random and provisioning confirmation numbers from a remote peer that are the same as those selected by the local device.

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.

This document was written by Madison Oliver.

Overview

MySQL for Windows contains a privilege escalation vulnerability due to the use of an OPENSSLDIR variable that specifies a location where an unprivileged Windows user can create files.

Description

CVE-2021-2307

MySQL includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory of /build_area/. On the Windows platform, this path is interpreted as C:\build_area. MySQL contains a privileged service that uses this OpenSSL component. Because unprivileged Windows users can create subdirectories off of the system root, a user can create the appropriate path to a specially-crafted openssl.cnf file to achieve arbitrary code execution with SYSTEM privileges.

Impact

By placing a specially-crafted openssl.cnf in a C:\build_area subdirectory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable MySQL software installed.

Solution Apply an update

This vulnerability is addressed in

Create a C:\build_area directory

In cases where an update cannot be installed, this vulnerability can be mitigated by creating a C:\build_area directory and restricting ACLs to prevent unprivileged users from being able to write to this location.

Acknowledgements

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

This document was written by Will Dormann.

Overview

Pulse Connect Secure (PCS) gateway contains a vulnerability that can allow an unauthenticated remote attacker to execute arbitrary code.

Description

CVE-2021-22893

An unspecified vulnerability exposed by the Windows File Share Browser and Pulse Secure Collaboration features of Pulse Connect Secure may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable Pulse Connect Secure gateway system. Products affected by this vulnerability are PCS version 9.0R3 and higher.

This vulnerability is being exploited in the wild.

Impact

By making a crafted request to a vulnerable Pulse Connect Secure system, an unauthenticated remote attacker may be able to execute arbitrary code on the gateway.

Pulse Secure has assigned this vulnerability a critical CVSS Score of 10.0 3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

Solution

While there is currently no patch for this vulnerability, Pulse Secure recommends upgrading to PCS Server version 9.1R.11.4 when it becomes available. In the meantime, Pulse Secure recommends disabling the two affected feature sets on existing PCS instances:

• Windows File Share Browser
• Pulse Secure Collaboration

Pulse Secure has published a Workaround-2104.xml file that reportedly contains mitigations to protect against this vulnerability. As outlined in the Pulse Secure advisory, be sure that the Windows File Share Browser feature is disabled after importing the XML workaround.

Acknowledgements

This vulnerability was publicly reported by Pulse Secure with additional details and context published by Fireye.

This document was written by Chuck Yarbrough.

Overview

Multiple open-source embedded TCP/IP stacks, commonly used in Internet of Things (IoT) and embedded devices, have several vulnerabilities stemming from improper memory management. These vulnerabilities are also tracked as ICS-VU-633937 and JVNVU#96491057 as well as the name AMNESIA:33.

Description

Embedded TCP/IP stacks provide essential network communication capability using TCP/IP networking to many lightweight operating systems adopted by IoT and other embedded devices. These software stacks can also be used in the latest technologies such as Edge Computing. The following embedded TCP/IP stacks were discovered to have 33 memory related vulnerabilities included in this advisory:

• uIP: https://github.com/adamdunkels/uip
• Contiki-OS and Contiki-NG: https://www.contiki-ng.org/
• PicoTCP and PicoTCP-NG: http://picotcp.altran.be
• FNET: http://fnet.sourceforge.net/
• Nut/OS: http://www.ethernut.de/en/software/

These networking software stacks can be integrated in various ways, including compiled from source, modified and integrated, and linked as a dynamic or static libraries, allowing for a wide variety of implementations. As an example, projects such as Apache Nuttx and open-iscsi have adopted common libraries and software modules, thus inheriting some of these vulnerabilities with varying levels of impact. The diversity of implementations and the lack of supply chain visibility has made it difficult to accurately assess the impact, usage as well as the potential exploitability of these vulnerabilities.

In general, most of these vulnerabilities are caused by memory management bugs, commonly seen in lightweight software implementations in Real Time Operating Systems (RTOS) and IoT devices. For specific details on these vulnerabilities, see the Forescout advisory that provides technical details. Due to the lack of visibility of these software usage, Forescout has released an open source version of Detector that can be used to identify potentially vulnerable software.

Impact

The impact of these vulnerabilities vary widely due to the combination of build and runtime options customized while including these in embedded devices. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause the vulnerable device to behave in unexpected ways such as a failure (denial of service), disclosure of private information, or execution of arbitrary code.

Solution Apply updates

Update to the latest stable version of the affected embedded TCP/IP software that address these recently disclosed vulnerabilities. If you have adopted this software from an upstream provider, contact the provider to get appropriate updates that need to be integrated into your software. Concerned end-users of IoT and embedded devices that implement these vulnerable TCP/IP software stacks should contact their vendor or the closest reseller to obtain appropriate updates.

Follow best-practices

We recommend that you follow best practices when connecting IoT or embedded devices to a network:

• Avoid exposure of IoT and embedded devices directly over the Internet and use a segmented network zone when available.
• Enable security features such as deep-packet inspection and firewall anomaly detection when available to protect embedded and IoT devices.
• Ensure secure defaults are adopted and disable unused features and services on your embedded devices.
• Regularly update firmware to the vendor provided latest stable version to ensure your device is up to date.

Acknowledgements

Jos Wetzels, Stanislav Dashevskyi, Amine Amri and Daniel dos Santos of Forescout Technologies researched and reported these vulnerabilities.

This document was written by Vijay Sarvepalli.

Overview

The Microsoft Windows Netlogon Remote Protocol (MS-NRPC) reuses a known, static, zero-value initialization vector (IV) in AES-CFB8 mode. This allows an unauthenticated attacker to impersonate a domain-joined computer, including a domain controller, and potentially obtain domain administrator privileges.

Description

The Microsoft Windows Netlogon Remote Protocol (MS-NRPC) is a core authentication component of Active Directory that provides authentication for user and computer accounts. MS-NRPC uses an initialization vector (IV) of 0 (zero) in AES-CFB8 mode when authenticating computer accounts.

Zerologon: Unauthenticated domain controller compromise by subverting Netlogon cryptography (CVE-2020-1472) describes how this cryptographic failure allows a trivial statistical attack on the MS-NRPC authentication handshake:

The ComputeNetlogonCredential function, however, defines that this IV is fixed and should always consist of 16 zero bytes. This violates the requirements for using AES-CFB8 securely: its security properties only hold when IVs are random.

...

When encrypting a message consisting only of zeroes, with an all-zero IV, there is a 1 in 256 chance that the output will only contain zeroes as well.

By choosing a client challenge and ClientCredential of all zeros, an attacker has a 1 in 256 chance of successfully authenticating as any domain-joined computer. By impersonating a domain controller, an attacker can take additional steps to change a computer's Active Directory password (Exploit step 4: changing a computer’s AD password) and potentially gain domain administrator privileges (Exploit step 5: from password change to domain admin).

Because Samba has implemented the MS-NRPC protocol as it has been designed by Microsoft, Samba domain controllers are also affected by this vulnerability.

Impact

An unauthenticated attacker with network access to a domain controller can impersonate any domain-joined computer, including a domain controller. Among other actions, the attacker can set an empty password for the domain controller's Active Directory computer account, causing a denial of service, and potentially allowing the attacker to gain domain administrator privileges.

The compromise of Active Directory infrastructure is likely a significant and costly impact.

Solution Apply an update

On August 11, 2020, Microsoft issued an advisory that provides updates for this vulnerability.

Enable secure RPC enforcement mode

The August 2020 updates for CVE-2020-1472 include changes to domain controllers that can optionally be enabled to require secure RPC for Netlogon secure channel connections. The changes to require secure RPC must be made to receive the most complete protection from this vulnerability. For systems that have the August 2020 update for CVE-2020-1472, enabling secure RPC enforcement mode will change domain controller behavior to require Netlogon secure channel connections using secure MS-NRPC. This change to enable enforcement mode will be deployed automatically on or after February 9, 2021.

Acknowledgements

Microsoft acknowledges Tom Tervoort of Secura for reporting this vulnerability.

This document was written by Eric Hatleback, Art Manion, and Will Dormann.