US-CERT.gov

Feliratkozás US-CERT.gov hírcsatorna csatornájára
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.
Frissítve: 27 perc 22 másodperc

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

cs, 10/22/2020 - 17:46
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.

Kategóriák: Biztonsági hírek

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

h, 10/12/2020 - 22:33
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, 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.

Kategóriák: Biztonsági hírek

VU#257161: Treck IP stacks contain multiple vulnerabilities

cs, 10/08/2020 - 16:58
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.

Kategóriák: Biztonsági hírek

VU#636397: IP-in-IP protocol routes arbitrary traffic by default

sze, 09/30/2020 - 20:58
Overview

IP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device.

Description

IP-in-IP encapsulation is a tunneling protocol specified in RFC 2003 that allows for IP packets to be encapsulated inside another IP packets. This is very similar to IPSEC VPNs in tunnel mode, except in the case of IP-in-IP, the traffic is unencrypted. As specified, the protocol unwraps the inner IP packet and forwards this packet through IP routing tables, potentially providing unexpected access to network paths available to the vulnerable device. An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses. This unexpected Data Processing Error (CWE-19) by a vulnerable device can be abused to perform reflective DDoS and in certain scenarios used to bypass network access control lists. Because the forwarded network packet may not be inspected or verified by vulnerable devices, there are possibly other unexpected behaviors that can be abused by an attacker on the target device or the target device's network environment.

Impact

An unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls.

Solution Apply updates

The CERT/CC recommends that you apply the latest patch provided by the affected vendor that addresses this issue. Review the vendor information below or contact your vendor or supplier for specific mitigation advice. If a device has the ability to disable IP-in-IP in its configuration, it is recommended that you disable IP-in-IP in all interfaces that do not require this feature. Device manufacturers are urged to disable IP-in-IP in their default configuration and to require their customers to explicitly configure IP-in-IP as and when needed.

Disable IP-in-IP

Users can block IP-in-IP packets by filtering IP protocol number 4. Note this filtering is for the IPv4 Protocol (or IPv6 Next Header) field value of 4 and not IP protocol version 4 (IPv4).

Proof of Concept (PoC)

A proof-of-concept originally written by Yannay Livneh is available in the CERT/CC PoC respository.

Detection Signature (IDS)

This Snort IDS rule looks for any IP-in-IP traffic, whether intentional or not seen at upstream network path of a vulnerable device. This Snort or Suricata rule can be modified to apply filters that ignore sources and destinations that are allowed by policy to route IP-in-IP traffic.

alert ip any any -> any any (msg: "IP-in-IP Tunneling VU#636397 https://kb.cert.org"; ip_proto:4; sid: 1367636397; rev:1;)

Acknowledgements

Thanks to Yannay Livneh for reporting this issue to us.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#490028: Microsoft Windows Netlogon Remote Protocol (MS-NRPC) uses insecure AES-CFB8 initialization vector

sze, 09/16/2020 - 19:14
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).

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.

Kategóriák: Biztonsági hírek

VU#896979: IPTV encoder devices contain multiple vulnerabilities

k, 09/15/2020 - 19:56
Overview

Multiple vulnerabilities exist in various Video Over IP (Internet Protocol) encoder devices, also known as IPTV/H.264/H.265 video encoders. These vulnerabilities allow an unauthenticated remote attacker to execute arbitrary code and perform other unauthorized actions on a vulnerable system.

Description

IPTV/H.264/H.265 video encoder devices provide video streaming capability over IP networks. The underlying software in these devices seem to share common components that have multiple weaknesses in their design and default configuration.

The vulnerabilities occur primarily in the network services such as web and telnet interfaces. These vulnerabilities stem from software bugs, such as insufficient validation of user input and the use of insecure credentials through hard-coded passwords. https://owasp.org/www-project-top-ten/. The vulnerable components may also be present in other Internet of Things (IoT) devices.

These devices are manufactured using components acquired from a complex supply chain and are often sold through common outlets such as retail stores and e-commerce websites. This makes it difficult to identify impacted devices and notify the appropriate stakeholders, thus illustrating the dire need for Software Bill of Materials SBOM in this growing and complex digital market.

Further details of these vulnerabilities can be found in this blog post by Alexei Kojenov.

Impact

The impact of these vulnerabilities are summarized in the following list:

  1. Full administrative access via backdoor password (CVE-2020-24215)
  2. Administrative root access via backdoor password (CVE-2020-24218)
  3. Arbitrary file read via path traversal (CVE-2020-24219)
  4. Unauthenticated file upload (CVE-2020-24217)
  5. Arbitrary code execution by uploading malicious firmware (CVE-2020-24217)
  6. Arbitrary code execution via command injection (CVE-2020-24217)
  7. Denial of service via buffer overflow (CVE-2020-24214)
  8. Unauthorized video stream access via RTSP (CVE-2020-24216)
Solution Apply Updates

Contact your vendor. See also the Vendor Information section below.

Restrict network access

Restrict network access of these devices to a well protect local area network (LAN) or through a firewall. Allowing direct Internet access to these devices increases the risk of compromise and potential abuse from an unauthorized remote attacker.

Acknowledgements

Alexei Kojenov https://kojenov.com/ researched and reported these vulnerabilities.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

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

sze, 09/09/2020 - 19:02
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.k

Acknowledgements

Thanks to the reporter who wishes to remain anonymous.

This document was written by Madison Oliver.

Kategóriák: Biztonsági hírek

VU#221785: Diebold Nixdorf ProCash 2100xe USB ATM does not adequately secure communications between CCDM and host

cs, 08/20/2020 - 16:21
Overview

Diebold Nixdorf 2100xe USB automated teller machines (ATMs) are vulnerable to physical attacks on the communication channel between the cash and check deposit module (CCDM) and the host computer. An attacker with physical access to internal ATM components may be able to exploit this vulnerability to commit deposit forgery.

Description

Diebold Nixdorf ProCash 2100xe USB ATMs running Wincor Probase version 1.1.30 do not encrypt, authenticate, or verify the integrity of messages between the CCDM and the host computer. An attacker with physical access to internal ATM components can intercept and modify messages, such as the amount and value of currency being deposited, and send modified messages to the host computer.

A similar vulnerability identified as CVE-2020-10124 is decribed in VU#815655. CVE-2020-10124 affects the bunch note acceptor (BNA) in ATMs supplied by a different vendor. The BNA is functionally similar to the CCDM.

Impact

By modifying deposit transaction messages, an attacker may be able to commit deposit forgery. Such an attack requires two separate transactions. The attacker must first deposit actual currency and modify messages from the CCDM to the host computer to indicate a greater amount or value than was actually deposited. Then the attacker must make a withdrawal for an artificially increased amount or value of currency. This second transaction may need to occur at an ATM operated by a different financial institution (i.e., a not-on-us or OFF-US transaction).

Solution Obtain advice from vendor

Diebold Nixdorf released a document titled "Potential CCDM Deposit Forgery" on February 27, 2020 that details the recommended procedures for addressing this vulnerability. Contact the vendor to obtain the document.

Apply an update

The vendor has released an update to secure communications between the CCDM and the host computer. Contact the vendor regarding this software update.

Consider additional countermeasures

In addition to applying a software update, the vendor recommends limiting physical access to the ATM (including internal components), adjusting deposit transaction business logic, and implementing fraud monitoring. For details about these additional recommended countermeasures, contact the vendor.

Acknowledgements

This vulnerability was researched and reported by Maxim Kozorez. At the time of the initial report, Maxim Kozorez was associated with Embedi.

Coordinating with Embedi was supported by U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC) License No. CYBER2-2019-359003-1, Cyber-Related Sanctions Regulations License issued April 2, 2019 to Licensees: CERT Coordination Center at Carnegie Mellon’s Software Engineering Institute (CERT), U.S. Department of Homeland Security, Cybersecurity and Infrastructure Security Agency (CISA), the National Cybersecurity and Communications Integration Center.

This document was written by Eric Hatleback and Laurie Tyzenhaus.

Kategóriák: Biztonsági hírek

VU#815655: NCR SelfServ ATM BNA contains multiple vulnerabilities

cs, 08/20/2020 - 16:21
Overview

NCR SelfServ automated teller machines (ATMs) running APTRA XFS 04.02.01 and 05.01.00 are vulnerable to physical attacks on the communications bus between the host computer and the bunch note accepter (BNA).

Description

NCR ATM SelfServ devices running APTRA XFS 04.02.01 and 05.01.00 contain vulnerabilities that can be exploited by an attacker with physical access to the internal components of the ATM, specifically the BNA and the host computer.

CVE-2020-10124

NCR SelfServ ATMs running APTRA XFS 05.01.00 do not encrypt, authenticate, or verify the integrity of messages between the BNA and the host computer. A similar vulnerability is identified as CVE-2020-9062 in VU#221785. CVE-2020-9062 involves the cash and check deposit module (CCDM) in ATMs from a different vendor. The CCDM is functionally similar to the BNA.

CVE-2020-10125

NCR SelfServ ATMs running APTRA XFS 04.02.01 and 05.01.00 implement 512-bit RSA certificates to validate BNA software updates. Keys of this strengh can be broken by an attacker in a sufficiently short period of time, thereby enabling the attacker to sign arbitrary files and CAB archives used to update BNA software, as well as bypass application whitelisting, resulting in the ability to execute arbitrary code. (CWE-326)

CVE-2020-10126

NCR SelfServ ATMs running APTRA XFS 05.01.00 do not properly validate softare updates for the BNA. An attacker with physical access to internal ATM components can restart the host computer. During boot, the update process looks for CAB archives on removable media and executes a specific file without first validating the signature of the CAB archive. This allows an attacker to execute abitrary code with SYSTEM privileges. (CWE-305)

Impact

An attacker with physical access to the internal components of the ATM, including the BNA, can execute arbitrary code. An attacker may also be able to commit deposit forgery, with or without also executing arbitrary code.

A deposit forgery attack requires two separate transactions. The attacker must first deposit actual currency and manipulate the message from the BNA to the host computer to indicate a greater amount or value than was actually deposited. Then the attacker must make a withdrawal for an artificially increased amount or value of currency. This second transaction may need to occur at an ATM operated by a different financial institution (i.e., a not-on-us or OFF-US transaction).

Solution Apply an update

Update software to APTRA XFS 06.08. The update increases the strength of the RSA keys to limit the window of opportunity for an attacker to crack and misuse the keys (CVE-2020-10125). The update also provides protection against the bypass of the digital signature check (CVE-2020-10126).

Acknowledgements

These vulnerabilities were researched and reported by Roman Bazhin and Dmitry Turchenkov. At the time of the initial report, Roman Bazhin and Dmitry Turchenkov were associated with Embedi.

Coordinating with Embedi was supported by U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC) License No. CYBER2-2019-359003-1, Cyber-Related Sanctions Regulations License issued April 2, 2019 to Licensees: CERT Coordination Center at Carnegie Mellon’s Software Engineering Institute (CERT), U.S. Department of Homeland Security, Cybersecurity and Infrastructure Security Agency (CISA), the National Cybersecurity and Communications Integration Center.

This document was written by Eric Hatleback and Laurie Tyzenhaus.

Kategóriák: Biztonsági hírek

VU#116713: NCR SelfServ ATM dispenser software contains multiple vulnerabilities

cs, 08/20/2020 - 16:21
Overview

NCR SelfServ automated teller machines (ATMs) running APTRA XFS 05.01.00 or older are vulnerable to physical attacks on the communications bus between the currency dispenser component and the host computer.

Description

NCR SelfServ ATMs running APTRA XFS 05.01.00 or older contain vulnerabilities that can be exploited by an attacker with physical access to the internal components of the ATM.

CVE-2020-9063

USB HID communications between the currency dispenser and the host computer are not authenticated or integrity protected and can be manipulated to cause a buffer overflow on the host. An attacker with physical access to internal ATM components can inject a malicious payload and execute arbitrary code with SYSTEM privileges on the host computer.

CVE-2020-10123

The currency dispenser component does not adequately authenticate session key generation requests from the host computer. An attacker with physical access to internal ATM components can generate a new session key that the attacker knows. This allows the attacker to issue valid commands to dispense currency. (CWE-305)

Impact

An attacker with physical access to the internal components of the ATM can execute arbitrary code on the host computer or withdraw currency.

Solution

Software, hardware, firmware, and configuration updates may be necessary, depending upon the current state of a specific vulnerable ATM.

Update software and hardware

APTRA XFS 05.01 stopped receiving support in 2015. Any customers still using unsupported software and hardware should upgrade at the earliest possible opportunity.

Update firmware

APTRA XFS Dispenser Security Update 01.00.00 contains the following firmware updates:

  1. USBCurrencyDispenser 04.01.01, firmware 0x0167 (for S1 dispensers)
  2. USBMediaDispenser 03.04.00, firmware 0x0118 (for S2 dispensers)
Update configuration

In addition to Dispenser Security Update 01.00.00, the Dispenser Protection Level and Dispenser Authentication Sequence parameters should be properly configured. The recommended configurations are:

  1. Dispenser Protection Level: Level 3 (Physical Protection) for S1 and S2 dispensers
  2. Dispenser Authentication Sequence: Sequence 2 or higher (for S1 dispensers), or Sequence 1 or higher (for S2 dispensers)

See the NCR Secure Whitepaper for further information.

When implemented together, these mitigations address both CVE-2020-9063 and CVE-2020-10123.

Acknowledgements

These vulnerabilities were researched and reported by Maxim Kozorez. At the time of the initial report, Maxim Kozorez was associated with Embedi.

Coordinating with Embedi was supported by U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC) License No. CYBER2-2019-359003-1, Cyber-Related Sanctions Regulations License issued April 2, 2019 to Licensees: CERT Coordination Center at Carnegie Mellon’s Software Engineering Institute (CERT), U.S. Department of Homeland Security, Cybersecurity and Infrastructure Security Agency (CISA), the National Cybersecurity and Communications Integration Center.

This document was written by Eric Hatleback and Laurie Tyzenhaus.

Kategóriák: Biztonsági hírek

VU#174059: GRUB2 bootloader is vulnerable to buffer overflow

sze, 07/29/2020 - 19:02
Overview

The GRUB2 boot loader is vulnerable to buffer overflow, which results in arbitrary code execution during the boot process, even when Secure Boot is enabled.

Description

GRUB2 is a multiboot boot loader that replaced GRUB Legacy in 2012. A boot loader is the first program that runs upon boot and loads the operating system. Many vendors also use a shim, a signed software package that contains the vendor’s certificate and code that verifies and runs the boot loader. This means that firmware Certificate Authority providers can just sign the shim as opposed to all of the other supported programs.

GRUB2 is vulnerable to a buffer overflow when parsing content from the GRUB2 configuration file (grub.cfg). This configuration file is an external file commonly located in the EFI System Partition and can therefore be modified by an attacker with administrator privileges without altering the integrity of the signed vendor shim and GRUB2 boot loader executables. This could allow an authenticated, local attacker to modify the contents of the GRUB2 configuration file to ensure that the attacker's chosen code is run before the operating system is loaded. This could allow the attacker to gain persistence on the device, even with Secure Boot enabled. All versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.

Impact

An authenticated, local attacker could modify the contents of the GRUB2 configuration file to execute arbitrary code that bypasses signature verification. This could allow the attacker to gain persistence on the device, even with Secure Boot enabled. Because the attacker's code runs before the operating system, the attacker could control how the operating system is loaded, directly patch the operating system, or even direct the bootloader to alternate OS images. All versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.

Solution

Apply an update

Update GRUB2 to the latest version to address this vulnerability. Linux distributions and other vendors using GRUB2 will need to update their installers, boot loaders, and shims. New shims will need to be signed by the Microsoft 3rd Party UEFI Certificate Authority. Administrators of affected devices will need to update installed versions of operating systems as well as installer images, including disaster recovery media. Until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2. Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.

Acknowledgements

Thanks to Mickey Shkatov and Jesse Michael from Eclypsium for reporting this vulnerability.

This document was written by Madison Oliver.

Kategóriák: Biztonsági hírek

VU#127371: iOS, iPadOS, tvOS, watchOS, and macOS contain a double-free vulnerability in the XNU kernel lio_listio() function

cs, 07/09/2020 - 19:58
Overview

iOS, iPadOS, tvOS, watchOS, and macOS contain a double-free vulnerability in the GNU kernel's lio_listio() function, which can allow a malicious application to achieve unsandboxed, kernel-level code execution.

Description

iOS, iPadOS, tvOS, watchOS, and macOS contain an a double-free vulnerability in the GNU kernel's lio_listio() function. This can lead to triggering a use-after-free condition. This vulnerability can allow code execution with kernel privileges. This vulnerability is being used by the public unc0ver 5.0 jailbreak utility, which claims to support all devices from iOS 11 through 13.5, excluding versions 12.3-12.3.2 and 12.4.2-12.4.5. It is also reported that this jailbreak works on modern iOS devices that use a CPU that supports Pointer Authentication Code (PAC), which indicates that PAC does not prevent exploitation of this vulnerability.

It is reported that this vulnerability is a regression of the vulnerability known as LightSpeed.

Impact

By convincing a user to run a malicious application on a device running iOS, iPadOS, tvOS, watchOS, or macOS, an attacker may be able to achieve arbitrary code execution in the kernel that is not restricted by sandboxes or other OS protections.

Solution Apply updates

This issue is addressed in the following OS updates from Apple:
macOS Catalina 10.15.5 Supplemental Update, Security Update 2020-003 High Sierra
tvOS 13.4.6
watchOS 6.2.6
iOS 13.5.1 and iPadOS 13.5.1

Acknowledgements

This document was written by Will Dormann.

Kategóriák: Biztonsági hírek

VU#339275: Universal Plug and Play (UPnP) SUBSCRIBE can be abused to send traffic to arbitrary destinations

sze, 07/08/2020 - 23:44
Overview

The Universal Plug and Play (UPnP) protocol in effect prior to April 17, 2020 can be abused to send traffic to arbitrary destinations using the SUBSCRIBE functionality.

Description

The UPnP protocol, as specified by the Open Connectivity Foundation (OCF), is designed to provide automatic discovery and interaction with devices on a network. The UPnP protocol is designed to be used in a trusted local area network (LAN) and the protocol does not implement any form of authentication or verification.

Many common Internet-connected devices support UPnP, as noted in previous research from Daniel Garcia (VU#357851) and Rapid7. Garcia presented at DEFCON 2019 and published a scanning and portmapping tool. The UPnP Device Protection service was not widely adopted.

A vulnerability in the UPnP SUBSCRIBE capability permits an attacker to send large amounts of data to arbitrary destinations accessible over the Internet, which could lead to a Distributed Denial of Service (DDoS), data exfiltration, and other unexpected network behavior. The OCF has updated the UPnP specification to address this issue. This vulnerability has been assigned CVE-2020-12695 and is also known as Call Stranger.

Although offering UPnP services on the Internet is generally considered to be a misconfiguration, a number of devices are still available over the Internet according to a recent Shodan scan.

Impact

A remote, unauthenticated attacker may be able to abuse the UPnP SUBSCRIBE capability to send traffic to arbitrary destinations, leading to amplified DDoS attacks and data exfiltration. In general, making UPnP available over the the Internet can pose further security vulnerabilities than the one described in this vulnerability note.

Solution Affected devices

A number of devices have been identified as vulnerable by the security researcher and have been posted at the CallStranger website. There is more information on affected devices in Tenable's blog on cve-2020-12695.

Apply updates

Vendors are urged to implement the updated specification provided by the OCF.. Users should monitor vendor support channels for updates that implement the new SUBSCRIBE specification.

Disable or Restrict UPnP

Disable the UPnP protocol on Internet-accessible interfaces. Device manufacturers are urged to disable the UPnP SUBSCRIBE capability in their default configuration and to require users to explicitly enable SUBSCRIBE with any appropriate network restrictions to limit its usage to a trusted local area network.

IDS Signature

This Surricata IDS rule looks for any HTTP SUBSCRIBE request to what is likely to be an external network (i.e., not RFC1918 and RFC4193 addresses). Network administrators and ISPs can deploy this signature at the Internet access point to detect any anomalous SUBSCRIBE requests reaching their users.

alert http any any -> ![fd00::/8,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12] any (msg:"UPnP SUBSCRIBE request seen to external network VU#339275: CVE- 2020-12695 https://kb.cert.org "; content: "subscribe"; nocase; http_method; sid:1367339275;)

Acknowledgements

This vulnerability was reported by Yunus Çadirci from EY Turkey.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek

VU#290915: F5 BIG-IP contains multiple vulnerabilities including unauthenticated remote command execution

sze, 07/08/2020 - 22:03
Overview

F5 BIG-IP provides a Traffic Management User Interface (TMUI), also referred to as the Configuration utility, that has multiple vulnerabilities including a remotely exploitable command injection vulnerability that can be used to execute arbitrary commands and subsequently take control of a vulnerable system.

Description

F5 BIG-IP devices provide load-balancing capability to application services such as HTTP and DNS. The F5 BIG-IP TMUI management web interface improperly neutralizes untrusted user input and can be abused by unauthenticated remote attackers to perform malicious activities such as cross-site scripting (XSS), cross-site request forgery (CSRF), and command injection CWE-74. F5 has also announced that BIG-IP devices do not properly enforce access controls to sensitive configuration files that be read and overwritten by an authenticated user via Secure Copy (SCP). The vulnerability identified by CVE-2020-0592 can be abused to achieve arbitrary code execution on the target device with root privileges.

Underlying causes and factors in these vulnerabilities include:

F5 recommends that the TMUI web interface should be accessible only from a secure or an out-of-band network and not directly from the Internet (K13092). However, many installations, as observed by Bad Packets, do not seem to follow this recommendation.

Impact

An unauthenticated attacker with network access to the TMUI may be able to execute arbitrary system commands, create or delete files, disable services, and subsequently execute arbitrary code with high privileges such as root. An authenticated user is also be able to perform unexpected activities such as changing configuration files on a vulnerable device.

Solution Apply updates

F5 has provided updated software for the several impacted versions of BIG-IP devices. Note that BIG-IP appliances as well as virtual instances are also vulnerable as identified by F5 advisories. It is highly recommended that you upgrade to the latest secure and stable software provided by F5. These updates are essential to your device's security, even if the TMUI is not accessible over the Internet. The upgrade reduces the risk to your device being compromised using CSRF or XSS attacks.

Workarounds

In many cases, an attack against BIG-IP's recent vulnerabilities require access to TMUI. Blocking or disabling access to TMUI from untrusted networks is highly recommended. F5 has also provided multiple temporary workaround options in their advisory.

Acknowledgements

Several of these vulnerabilities were reported by Mikhail Klyuchnikov of Positive Technologies, who worked with F5 on a coordinated disclosure.

This document was written by Vijay Sarvepalli.

Kategóriák: Biztonsági hírek