Author Archives: CERT

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 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.

This document was written by Madison Oliver.

Continue reading VU#799380: Devices supporting Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure→

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 the MySQL Windows installer version 8.0.24 and 5.7.34.

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.

Continue reading VU#567764: MySQL for Windows is vulnerable to privilege escalation due to OPENSSLDIR location→

Overview

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

Description

CVE-2021-22893

A use-after-free vulnerability that can be reached via a license server handling endpoint may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable Pulse Connect Secure gateway system.

Every system that is running PCS 9.0R3 or higher or 9.1R1 through 9.2R11.3 is affected. Having the license server configuration enabled is NOT a prerequisite to being vulnerable. The vulnerable endpoints are present regardless of whether the system is an actual license server or not.

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 with root privileges.

Solution

Apply an update

This vulnerability and others are addressed in Pulse Connect Secure 9.1R11.4.

Apply a workaround

If you are not using the features that the following workaround disables, we recommend applying the XML workaround even on systems that have been upgraded to 9.1R11.4 to reduce attack surface. Pulse Secure has published a Workaround-2104.xml file that contains mitigations to protect against this and other vulnerabilities. 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/+meeting
^/+dana/+fb/+smb
^/+dana-cached/+fb/+smb
^/+dana-ws/+namedusers
^/+dana-ws/+metric

Note that installing this workaround will block the ability to use the following features:

• Windows File Share Browser
• Pulse Secure Collaboration
• License Server

Instead of using the workaround to protect a PCS that is being used as a license server, we recommend updating such systems to PCS 9.1R11.4. If this is not possible, restrict which IP addresses are allowed to communicate with the system.

Run the PCS Integrity Assurance utility

A PCS administrator should run the PCS Integrity Assurance utility to help determine if a system has evidence that it has been compromised. Please be aware of two limitations of this tool:

1. Upon completion of the Integrity Assurance tool, the PCS device will automatically reboot.
2. Because running the Integrity Assurance tool relies on the use of the administrative web interface of the PCS device itself, it is reasonable to assume that it may be possible for a compromised device to display misleading results.

Enable Unauthenticated Request logging

By default, PCS devices do not log unauthenticated web requests. Additionally, the administrative interface for a PCS device will warn that: Selecting this can quickly fill up User access log space in case of attack.

Because this vulnerability is exploitable via an unauthenticated request to the PCS, evidence of exploitation may only be present if the “Unauthenticated Requests” logging option is enabled. Enable this feature in the PCS administrative web interface by visiting:
System -> Log/Monitoring -> User Access -> Settings
and enabling the “Unauthenticated Requests” option.

Enable remote logging

Attackers who have compromised a PCS device may delete on-device logs in the process. For this reason, configure a remote Syslog server to ensure that PCS log entries are not modified or deleted.

Acknowledgements

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

This document was written by Chuck Yarbrough and Will Dormann.

Continue reading VU#213092: Pulse Connect Secure contains a use-after-free vulnerability→

Overview

Atlassian Bitbucket on Windows fails to properly set ACLs, which can allow an unprivileged Windows user to run arbitrary code with SYSTEM privileges.

Description

The Atlassian Bitbucket Windows installer fails to set a secure access-control list (ACL) on the default installation directory, such as C:\Atlassian\Bitbucket\. By default, unprivileged users can create files in this directory structure, which creates a privilege-escalation vulnerability.

Impact

By placing a specially-crafted DLL file in the Bitbucket installation directory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Bitbucket software installed. See DLL Search Order Hijacking for more details.

Solution

Apply an update

This issue has been addressed in the Bitbucket Windows installer for versions 7.10.1, 7.6.4, and 6.10.9. Please see https://jira.atlassian.com/browse/BSERV-12753 for more details.

Acknowledgements

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

This document was written by Will Dormann.

Continue reading VU#240785: Atlassian Bitbucket on Windows is vulnerable to privilege escalation due to weak ACLs→

Overview

Siemens Totally Integrated Administrator (TIA) fails to properly set the module search path to be used by a privileged Node.js component, which can allow an unprivileged Windows user to run arbitrary code with SYSTEM privileges. The PCS neo administration console is reported to be affected as well.

Description

Siemens TIA runs a privileged Node.js component. The Node.js server fails to properly set the module search path. Because of this, Node.js will look for modules in the C:\node_modules\ directory when the server is started. Because unprivileged Windows users can create subdirectories off of the system root, a user can create this directory and place a specially-crafted .js file in it to achieve arbitrary code execution with SYSTEM privileges when the server starts.

Impact

By placing a specially-crafted JS file in the C:\node_modules\ directory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Siemens TIA or PCS neo administration console software installed.

Solution

Apply an update

This issue is addressed in TIA Administrator V1.0 SP2 Upd2. PCS neo administration console users should apply the mitigations described in Industrial Security in SIMATIC PCS neo.

For more details see Siemens Security Advisory SSA-428051.

Acknowledgements

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

This document was written by Will Dormann.

Continue reading VU#466044: Siemens Totally Integrated Automation Portal vulnerable to privilege escalation due to Node.js paths→

Overview

A heap-based overflow has been discovered in the set_cmd() function in sudo, which may allow a local attacker to execute commands with elevated administrator privileges.

Description

From the Sudo Main Page:

Sudo (su “do”) allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.

It is possible for a local Non-administrative user to exploit this vulnerability to elevate their privileges so that they can execute commands with administrator privileges. The team at Qualys assigned this vulnerability CVE-2021-3156 and found multiple *nix operating systems were vulnerable, including Fedora, Debian, and Ubuntu. A blog update from February 3, 2021, reports that macOS, AIX, and Solaris may be vulnerable, but Qualys had not yet confirmed this.
There is additional reporting that other operating systems are affected, including Apple’s Big Sur.

Impact

If an attacker has local access to an affected machine then it is possible for them to execute commands with administrator privileges.

Solution

Apply an Update

Update sudo to the latest version to address this vulnerability when operationally feasible. This issue is resolved in sudo version 1.9.5p2. Please install this version, or a version from your distribution that has the fix applied to it

Acknowledgements

This vulnerability was researched and reported by the Qualys Research Team.

This document was written by Timur Snoke.

Continue reading VU#794544: Sudo set_cmd() is vulnerable to heap-based buffer overflow→

Overview

Adobe ColdFusion fails to properly set ACLs, which can allow an unprivileged Windows user to be able to run arbitrary code with SYSTEM privileges.

Description

The Adobe ColdFusion installer fails to set a secure access-control list (ACL) on the default installation directory, such as C:\ColdFusion2021\. By default, unprivileged users can create files in this directory structure, which creates a privilege-escalation vulnerability.

Impact

By placing a specially-crafted DLL file in the ColdFusion installation directory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable ColdFusion software installed. See DLL Search Order Hijacking for more details.

Solution

Use the Server Auto-Lockdown Installer

By default, ColdFusion does not configure itself securely. In order to secure ColdFusion with respect to service privileges, ACLs, and other attributes, the ColdFusion Server Auto-Lockdown installer must be installed in addition to installing ColdFusion itself.

Mitigation steps will vary based on the version of ColdFusion being used:
ColdFusion 2016: Apply the changes outlined in the ColdFusion 2016 Lockdown Guide.
ColdFusion 2018: Run the ColdFusion 2018 Auto-Lockdown installer and ensure that it completes without error.
ColdFusion 2021: Run the ColdFusion 2021 Auto-Lockdown installer and ensure that it completes without error.

Acknowledgements

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

This document was written by Will Dormann.

Continue reading VU#125331: Adobe ColdFusion is vulnerable to privilege escalation due to weak ACLs→

Overview

Dnsmasq is vulnerable to a set of memory corruption issues handling DNSSEC data and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on a vulnerable system and perform cache poisoning attacks against a vulnerable environment.

These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq.

Description

Dnsmasq is widely used open-source software that provides DNS forwarding and caching (and also a DHCP server). Dnsmasq is common in Internet-of-Things (IoT) and other embedded devices.

JSOF reported multiple memory corruption vulnerabilities in dnsmasq due to boundary checking errors in DNSSEC handling code.

• CVE-2020-25681: A heap-based buffer overflow in dnsmasq in the way it sorts RRSets before validating them with DNSSEC data in an unsolicited DNS response
• CVE-2020-25682: A buffer overflow vulnerability in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data
• CVE-2020-25683: A heap-based buffer overflow in get_rdata subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
• CVE-2020-25687: A heap-based buffer overflow in sort_rrset subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries

JSOF also reported vulnerabilities in DNS response validation that can result in DNS cache poisoning.

• CVE-2020-25684: Dnsmasq does not validate the combination of address/port and the query-id fields of DNS request when accepting DNS responses
• CVE-2020-25685: Dnsmasq uses a weak hashing algorithm (CRC32) when compiled without DNSSEC to validate DNS responses
• CVE-2020-25686: Dnsmasq does not check for an existing pending request for the same name and forwards a new request thus allowing an attacker to perform a “Birthday Attack” scenario to forge replies and potentially poison the DNS cache

Note: These cache poisoning scenarios and defenses are discussed in IETF RFC5452.

Impact

The memory corruption vulnerabilities can be triggered by a remote attacker using crafted DNS responses that can lead to denial of service, information exposure, and potentially remote code execution. The DNS response validation vulnerabilities allow an attacker to use unsolicited DNS responses to poison the DNS cache and redirect users to arbitrary sites.

Solution

Apply updates

These vulnerabilities are addressed in dnsmasq 2.83. Users of IoT and embedded devices that use dnsmasq should contact their vendors.

Follow security best-practices

Consider the following security best-practices to protect DNS infrastructure:

• Protect your DNS clients using stateful-inspection firewall that provide DNS security (e.g.,
  stateful firewalls and NAT devices can block unsolicited DNS responses, DNS application layer inspection can prevent forwarding of anomalous DNS packets).
• Provide secure DNS recursion service with features such as DNSSEC validation and the interim 0x20-bit encoding as part of enterprise DNS services where applicable.
• Prevent exposure of IoT devices and lightweight devices directly over the Internet to minimize abuse of DNS.
• Implement a Secure By Default configuration suitable for your operating environment (e.g., disable caching on embedded IoT devices when an upstream caching resolver is available).

Acknowledgements

Moshe Kol and Shlomi Oberman of JSOF researched and reported these vulnerabilities. Simon Kelley (author of dnsmasq) worked closely with collaborative vendors (Cisco, Google, Pi-Hole, Redhat) to develop patches to address these security vulnerabilities. GitHub also supported these collaboration efforts providing support to use their GitHub Security Advisory platform for collaboration.

This document was written by Vijay Sarvepalli.

Continue reading VU#434904: Dnsmasq is vulnerable to memory corruption and cache poisoning→

Overview

The SolarWinds Orion API is vulnerable to authentication bypass that could allow a remote attacker to execute API commands.

Description

The SolarWinds Orion Platform is a suite of infrastructure and system monitoring and management products. The SolarWinds Orion API is embedded into the Orion Core and is used to interface with all SolarWinds Orion Platform products. API authentication can be bypassed by including specific parameters in the Request.PathInfo portion of a URI request, which could allow an attacker to execute unauthenticated API commands. In particular, if an attacker appends a PathInfo parameter of WebResource.axd, ScriptResource.axd, i18n.ashx, or Skipi18n to a request to a SolarWinds Orion server, SolarWinds may set the SkipAuthorization flag, which may allow the API request to be processed without requiring authentication.

This vulnerability, also known as CVE-2020-10148, is the vulnerability that SolarWinds has indicated to have been used to install the malware known as SUPERNOVA.

We have created a python3 script to check for vulnerable SolarWinds Orion servers: swcheck.py

Impact

This vulnerability could allow a remote attacker to bypass authentication and execute API commands which may result in a compromise of the SolarWinds instance.

Solution

Apply an Update

Users should update to the relevant versions of the SolarWinds Orion Platform:

• 2019.4 HF 6 (released December 14, 2020)
• 2020.2.1 HF 2 (released December 15, 2020)
• 2019.2 SUPERNOVA Patch (released December 23, 2020)
• 2018.4 SUPERNOVA Patch (released December 23, 2020)
• 2018.2 SUPERNOVA Patch (released December 23, 2020)

More information can be found in the SolarWinds Security Advisory.

Harden the IIS Server

Especially in cases when updates cannot be installed, we recommend that users implement these mitigations to harden the IIS server.

Acknowledgements

This document was written by Madison Oliver and Will Dormann.

Continue reading VU#843464: SolarWinds Orion API authentication bypass allows remote command execution→

Overview

Veritas Backup Exec 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-2019-1552

Veritas Backup Exec includes an OpenSSL component that specifies an OPENSSLDIR variable as /usr/local/ssl/. On the Windows platform, this path is interpreted as C:\usr\local\ssl. Backup Exec 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 the C:\usr\local\ssl directory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Veritas software installed.

Solution

Apply an update

This vulnerability is addressed in Backup Exec 21.1 Hotfix 657517 (Engineering version 21.0.1200.1217) and Backup Exec 20.6 Hotfix 298543 (Engineering version 20.0.1188.2734).

Create a C:\usr\local\ssl directory

In cases where an update cannot be installed, this vulnerability can be mitigated by creating a C:\usr\local\ssl 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.

Continue reading VU#429301: Veritas Backup Exec is vulnerable to privilege escalation due to OPENSSLDIR location→