Vulnerabilities

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

9 hours 34 minutes ago
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.

CERT

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

1 week 1 day ago
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.

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.

CERT

VU#815128: Embedded TCP/IP stacks have memory corruption vulnerabilities

1 week 3 days ago
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:

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.

CERT

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

2 weeks 2 days ago
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.

CERT

VU#724367: VMware Workspace ONE Access and related components are vulnerable to command injection

1 month 2 weeks ago
Overview

VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector are vulnerable to command injection in the administrative configurator. This could allow a remote attacker to execute commands with unrestricted privileges on the underlying operating system.

Description

VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector are vulnerable to command injection in the administrative configurator. This could allow a remote attacker with access to the administrative configurator on port 8443 and a valid password to execute commands with unrestricted privileges on the underlying operating system. For additional details, please see VMSA-2020-0027 and CVE-2020-4006.

Impact

This could allow a malicious actor with network access to the administrative configurator on port 8443 and a valid password for the configurator admin account to execute commands with unrestricted privileges on the underlying operating system.

Active exploitation of this vulnerability has been reported.

Solution

VMware has released updates as described in VMSA-2020-0027.

Workarounds

VMware has documented workarounds in VMSA-2020-0027.

Acknowledgements

Thanks to VMware for coordinating this vulnerability.

This document was written by Madison Oliver.

CERT

VU#231329: Replay Protected Memory Block (RPMB) protocol does not adequately defend against replay attacks

2 months ago
Overview

The Replay Protected Memory Block (RPMB) protocol found in several storage specifications does not securely protect against replay attacks. An attacker with physical access can deceive a trusted component about the status of an RPBM write command or the content of an RPMB area.

Description

The RPMB protocol "...enables a device to store data in a small, specific area that is authenticated and protected against replay attack." RPMB is most commonly found in mobile phones and tablets using flash storage technology such as eMMC, UFS, and NVMe. The RPMB protocol allows an attacker to replay stale write failure messages and write commands, leading to state confusion between a trusted component and the contents of an RPMB area. Additional details are available in Replay Attack Vulnerabilities in RPMB Protocol Applications.

Impact

An attacker with physical access to a device can cause a mismatch between the write state or contents of the RPMB area and a trusted component of the device. These mismatches can lead to the trusted component believing a write command failed when in fact it succeeded, or the trusted component believing that certain content was written when in fact different content (unmodified by the attacker) was written. Further implications depend on the specific device and use of RPMB. At least one affected vendor has confirmed that denial of service

Solution

Please see the Vendor Information section below. Further vendor information is available in Replay Attack Vulnerabilities in RPMB Protocol Applications.

Acknowledgements

Rotem Sela and Brian Mastenbrook of Western Digital identified this vulnerability. Western Digital coordinated its disclosure with the affected vendors. Thanks Western Digital PSIRT!

This document was written by Eric Hatleback.

CERT

VU#760767: Macrium Reflect is vulnerable to privilege escalation due to OPENSSLDIR location

2 months 1 week ago
Overview

Macrium Reflect 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-2020-10143

Macrium Reflect includes an OpenSSL component that specifies an OPENSSLDIR variable as C:\openssl\. Macrium Reflect 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:\openssl\ directory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Macrium software installed.

Solution Apply an update

This vulnerability is addressed in Macrium Reflect v7.3.5281.

Acknowledgements

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

This document was written by Will Dormann.

CERT

VU#208577: Chocolatey Boxstarter is vulnerable to privilege escalation due to weak ACLs

2 months 1 week ago
Overview

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

Description

CVE-2020-15264

The Chocolatey Boxstarter installer fails to set a secure access-control list (ACL) on the C:\ProgramData\Boxstarter directory, which is added to the system-wide PATH environment variable. A privilege escalation vulnerability is introduced since any location in the system-wide PATH environment variable may be used to load code that runs with privileges.

Impact

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

Solution Apply an update

This vulnerability is addressed in Chocolatey Boxstarter version 2.13.0. Please see the security advisory for more details.

Acknowledgements

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

This document was written by Will Dormann.

CERT

VU#589825: Devices supporting Bluetooth BR/EDR and LE using CTKD are vulnerable to key overwrite

3 months 1 week ago
Overview

Devices supporting both Bluetooth BR/EDR and LE using Cross-Transport Key Derivation (CTKD) for pairing are vulnerable to key overwrite, which enables an attacker to to gain additional access to profiles or services that are not restricted by reducing the encryption key strength or overwriting an authenticated key with an unauthenticated key. This vulnerability is being referred to as BLURtooth.

Description

As detailed in both the Bluetooth Core Specification versions 4.2 and 5.0, Bluetooth CTKD can be used for pairing by devices that support both Low Energy (BLE) and Basic Rate/Enhanced Data Rate (BR/EDR) transport methods, which are known as "dual-mode" devices. CTKD pairing allows the devices to pair once using either transport method while generating both the BR/EDR and LE Long Term Keys (LTK) without needing to pair a second time. Dual-mode devices using CTKD to generate a LTK or Link Key (LK) are able to overwrite the original LTK or LK in cases where that transport was enforcing a higher level of security.

Impact

Several potential attacks could be performed by exploiting CVE-2020-15802, including a Man in the Middle (MITM) attack. The vulnerability is being referred to as BLURtooth and the group of attacks is being referred to as the BLUR attacks. Vulnerable devices must permit a pairing or bonding to proceed transparently with no authentication, or a weak key strength, on at least one of the BR/EDR or LE transports in order to be susceptible to attack. For example, it may be possible to pair with certain devices using JustWorks pairing over BR/EDR or LE and overwriting an existing LTK or LK on the other transport. When this results in the reduction of encryption key strength or the overwrite of an authenticated key with an unauthenticated key, an attacker could gain additional access to profiles or services that are not otherwise restricted.

Solution

The Bluetooth SIG has released recommendations for mitigating this issue that include additional conformance tests to ensure that the overwrite of an authenticated key or a key of a given length with an unauthenticated key or a key of reduced length is not permitted in devices supporting Bluetooth Core Specification version 5.1 or greater. They also recommend that potentially vulnerable implementations introduce the restrictions on CTKD mandated in Bluetooth Core Specification versions 5.1 and later. Implementations should disallow overwrite of the LTK or LK for one transport with the LTK or LK derived from the other when this overwrite would result in either a reduction of the key strength of the original bonding or a reduction in the MITM protection of the original bonding (from authenticated to unauthenticated). This may require that the host track the negotiated length and authentication status of the keys in the Bluetooth security database.

The Bluetooth SIG further recommends that devices restrict when they are pairable on either transport to times when user interaction places the device into a pairable mode or when the device has no bonds or existing connections to a paired device. In all cases, it is recommended that devices restrict the duration of pairing mode and overwrite an existing bonding only when devices are explicitly in pairing mode.

Acknowledgements

Thanks to the reporter who wishes to remain anonymous.

This document was written by Madison Oliver.

CERT

VU#114757: Acronis backup software contains multiple privilege escalation vulnerabilities

3 months 1 week ago
Overview

Acronis True Image, Cyber Backup, and Cyber Protection all contain privilege escalation vulnerabilities, which can allow an unprivileged Windows user to be able to run arbitrary code with SYSTEM privileges.

Description

CVE-2020-10138

Acronis Cyber Backup 12.5 and Cyber Protect 15 include an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory within C:\jenkins_agent\. Acronis Cyber Backup and Cyber Protect contain 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.

CVE-2020-10139

Acronis True Image 2021 includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory within C:\jenkins_agent\. Acronis True Image 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.

CVE-2020-10140

Acronis True Image 2021 fails to properly set ACLs of the C:\ProgramData\Acronis directory. Because some privileged processes are executed from the C:\ProgramData\Acronis directory, an unprivileged user can achieve arbitrary code execution with SYSTEM privileges by placing a DLL in one of several paths within C:\ProgramData\Acronis.

Impact

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

Solution Apply an update

These vulnerabilities are addressed in Acronis True Image 2021 build 32010 (release notes), Acronis Cyber Backup 12.5 build 16363 (release notes), and Acronis Cyber Protect 15 build 24600 (release notes).

Acknowledgements

This vulnerability was reported by Will Dormann of the CERT/CC. Acronis also credits HackerOne researchers @adr, @mmg, @vanitas, @xnand with independently discovering and reporting the vulnerabilities.

This document was written by Will Dormann.

CERT

VU#257161: Treck IP stacks contain multiple vulnerabilities

3 months 2 weeks ago
Overview

Treck IP stack implementations for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by JSOF, who calls them Ripple20.

Description

Treck IP network stack software is designed for and used in a variety of embedded systems. The software can be licensed and integrated in various ways, including compiled from source, licensed for modification and reuse and finally as a dynamic or static linked library. Treck IP software contains multiple vulnerabilities, most of which are caused by memory management bugs. For more details on the vulnerabilities introduced by these bugs, see Treck's Vulnerability Response Information and JSOF's Ripple20 advisory.

Historically-related KASAGO TCP/IP middleware from Zuken Elmic (formerly Elmic Systems) is also affected by some of these vulnerabilities.

These vulnerabilities likely affect industrial control systems and medical devices. Please see ICS-CERT Advisory ICSA-20-168-01 for more information.

Impact

The impact of these vulnerabilities will vary due to the combination of build and runtime options used while developing different embedded systems. This diversity of implementations and the lack of supply chain visibility has exasperated the problem of accurately assessing the impact of these vulnerabilities. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, or execute arbitrary code.

Solution Apply updates

Update to the latest stable version of Treck IP stack software (6.0.1.67 or later). Please contact Treck at security@treck.com. Downstream users of embedded systems that incorporate Treck IP stacks should contact their embedded system vendor.

Block anomalous IP traffic

Consider blocking network attacks via deep packet inspection. In some cases, modern switches, routers, and firewalls will drop malformed packets with no additional configuration. It is recommended that such security features are not disabled. Below is a list of possible mitigations that can be applied as appropriate to your network environment.

  • Normalize or reject IP fragmented packets (IP Fragments) if not supported in your environment
  • Disable or block IP tunneling, both IPv6-in-IPv4 or IP-in-IP tunneling if not required
  • Block IP source routing and any IPv6 deprecated features like routing headers (see also VU#267289)
  • Enforce TCP inspection and reject malformed TCP packets
  • Block unused ICMP control messages such MTU Update and Address Mask updates
  • Normalize DNS through a secure recursive server or application layer firewall
  • Ensure that you are using reliable OSI layer 2 equipment (Ethernet)
  • Provide DHCP/DHCPv6 security with feature like DHCP snooping
  • Disable or block IPv6 multicast if not used in switching infrastructure

Further recommendations are available here.

Detect anomalous IP traffic

Suricata IDS has built-in decoder-event rules that can be customized to detect attempts to exploit these vulnerabilities. See the rule below for an example. A larger set of selected vu-257161.rules are available from the CERT/CC Github repository.

#IP-in-IP tunnel with fragments
alert ip any any -> any any (msg:"VU#257161:CVE-2020-11896, CVE-2020-11900 Fragments inside IP-in-IP tunnel https://kb.cert.org/vuls/id/257161"; ip_proto:4; fragbits:M; sid:1367257161; rev:1;)

Acknowledgements

Moshe Kol and Shlomi Oberman of JSOF https://jsof-tech.com researched and reported these vulnerabilities. Treck worked closely with us and other stakeholders to coordinate the disclosure of these vulnerabilities.

This document was written by Vijay Sarvepalli.

CERT
Checked
1 hour 43 minutes ago
CERT publishes vulnerability advisories called "Vulnerability Notes." Vulnerability Notes include summaries, technical details, remediation information, and lists of affected vendors. Many vulnerability notes are the result of private coordination and disclosure efforts.
Subscribe to Vulnerabilities feed