Currently browsing: General

VU#309662: Signed third party UEFI bootloaders are vulnerable to Secure Boot bypass

VU#309662: Signed third party UEFI bootloaders are vulnerable to Secure Boot bypass

Overview
A security feature bypass vulnerability exists in signed 3rd party UEFI bootloaders that allows bypass of the UEFI Secure Boot feature. An attacker who successfully exploits this vulnerability can bypass the UEFI Secure Boot feature and execute unsigned code during the boot process.
Description
UEFI firmware is software written by vendors in the UEFI ecosystem to provide capabilities in the early start up phases of a computer. Secure Boot is a UEFI standard that can be enabled and used to verify firmware and to protect a system against malicious code being loaded and executed early in the boot process, prior to the loading of the operating system.
Security researchers at Eclypsium have found three specific UEFI bootloaders that are signed and authenticated by Microsoft to be vulnerable to a security feature bypass vulnerability allowing an attacker to bypass Secure Boot when it is enabled. The vulnerable bootloaders can be tricked to bypass Secure Boot via a custom installer (CVE-2022-34302) or an EFI shell (CVE-2022-34301 and CVE-2022-34303). As a vulnerable bootloader executes unsigned code prior to initialization of the the Operating System’s (OS) boot process, it cannot be easily monitored by the OS or common Endpoint Detection and Response (EDR) tools.
The following vendor-specific bootloaders were found vulnerable:

Inherently vulnerable bootloader to bypass Secure Boot
New Horizon Datasys Inc (CVE-2022-34302)

UEFI Shell execution to bypass Secure Boot
– CryptoPro Secure Disk (CVE-2022-34301)
– Eurosoft (UK) Ltd (CVE-2022-34303)

Impact
An attacker can bypass a system’s Secure Boot feature at startup and execute arbitrary code before the operating system (OS) loads. Code executed in these early boot phases can provide persistence to an attacker, potentially loading arbitrary kernel extensions that survive both reboot and re-installation of an OS. It may also evade common OS-based and EDR security defenses.
Solution
Apply a patch
Apply your vendor-provided security updates that address these vulnerabilities to block vulnerable firmware from bypassing Secure Boot. Microsoft has provided details with their KB5012170 article released on August 9th 2022. Note, these updates can be delivered from your OEM vendor or the OS vendor to install an updated Secure Boot Forbidden Signature Database (DBX) .
Enterprise and Product Developers
As DBX file changes can cause a system to become unstable, Vendors are urged to verify the DBX updates do not cause the machine to be unusable. Enterprises and Cloud Providers that manage large number of computers are also urged to do the required security updates and ensure DBX files are implemented reliably without any risk of boot failure.
Acknowledgements
Thanks to Mickey Shkatov and Jesse Michael of Eclypsium who researched and reported these vulnerabilities.
This document was written by Brad Runyon & Vijay Sarvepalli.

Read more
VU#309662: Signed third party UEFI bootloaders are vulnerable to Secure Boot bypass

VU#309662: Signed third party UEFI bootloaders are vulnerable to Secure Boot bypass

Overview
A security feature bypass vulnerability exists in signed 3rd party UEFI bootloaders that allows bypass of the UEFI Secure Boot feature. An attacker who successfully exploits this vulnerability can bypass the UEFI Secure Boot feature and execute unsigned code during the boot process.
Description
UEFI firmware is software written by vendors in the UEFI ecosystem to provide capabilities in the early start up phases of a computer. Secure Boot is a UEFI standard that can be enabled and used to verify firmware and to protect a system against malicious code being loaded and executed early in the boot process, prior to the loading of the operating system.
Security researchers at Eclypsium have found three specific UEFI bootloaders that are signed and authenticated by Microsoft to be vulnerable to a security feature bypass vulnerability allowing an attacker to bypass Secure Boot when it is enabled. The vulnerable bootloaders can be tricked to bypass Secure Boot via a custom installer (CVE-2022-34302) or an EFI shell (CVE-2022-34301 and CVE-2022-34303). As a vulnerable bootloader executes unsigned code prior to initialization of the the Operating System’s (OS) boot process, it cannot be easily monitored by the OS or common Endpoint Detection and Response (EDR) tools.
The following vendor-specific bootloaders were found vulnerable:

Inherently vulnerable bootloader to bypass Secure Boot
New Horizon Datasys Inc (CVE-2022-34302)

UEFI Shell execution to bypass Secure Boot
CryptoPro Secure Disk (CVE-2022-34301)
Eurosoft (UK) Ltd (CVE-2022-34303)

Impact
An attacker can bypass a system’s Secure Boot feature at startup and execute arbitrary code before the operating system (OS) loads. Code executed in these early boot phases can provide persistence to an attacker, potentially loading arbitrary kernel extensions that survive both reboot and re-installation of an OS. It may also evade common OS-based and EDR security defenses.
Solution
Apply a patch
Apply your vendor-provided security updates that address these vulnerabilities to block vulnerable firmware from bypassing Secure Boot. Microsoft has provided details with their KB5012170 article released on August 9th 2022. Note, these updates can be delivered from your OEM vendor or the OS vendor to install an updated Secure Boot Forbidden Signature Database (DBX) .
Enterprise and Product Developers
As DBX file changes can cause a system to become unstable, Vendors are urged to verify the DBX updates do not cause the machine to be unusable. Enterprises and Cloud Providers that manage large number of computers are also urged to do the required security updates and ensure DBX files are implemented reliably without any risk of boot failure.
Acknowledgements
Thanks to Mickey Shkatov and Jesse Michael of Eclypsium who researched and reported these vulnerabilities.
This document was written by Brad Runyon & Vijay Sarvepalli.

Read more
VU#495801: muhttpd versions 1.1.5 and earlier are vulnerable to path traversal

VU#495801: muhttpd versions 1.1.5 and earlier are vulnerable to path traversal

Overview
Versions 1.1.5 and earlier of the mu HTTP deamon (muhttpd) are vulnerable to path traversal via crafted HTTP request from an unauthenticated user. This vulnerability can allow unauthenticated users to download arbitrary files and collect private information on the target device.
Description
The muhttpd, hosted at SourceForge as an opensource project, is a lightweight webserver. This software is commonly used in customer premise equipment (CPE), such as home routers and small office routers, to provide device management capability through a web interface. The muhttpd supports the use of CGI scripts that enable remote management of CPE devices.
A path traversal vulnerability in muhttpd (version 1.1.5 and earlier) could allow an unauthenticated attacker to read arbitrary content on the target device, including usernames and passwords, Wireless SSID configurations, ISP connection information, and private keys. If remote management is enabled on a device running vulnerable version of muhttpd, this attack is possible from a remote network. Even in cases with restricted Local Area Network access, a vulnerable version of muhttpd can be accessed using other attack methods such as DNS Rebinding.
Impact
An unauthenticated attacker can use crafted HTTP request to download arbitrary files or gather sensitive information from a vulnerable target device. In cases where remote management is enabled on a vulnerable device, a remote unauthenticated attacker can perform these attacks.
Solution
Apply Updates
Update to the latest version of firmware/software provided by your vendor; see Vendor Information section for details. Downstream developers of embedded systems should update muhttpd software (to version 1.1.7 or later) from SourceForget git repository.
Disable remote management
Disabling remote management access, which thereby limits access strictly to local area network, can minimize the exposure introduced by the vulnerable software. Use access control to limit remote management if remote management is desired from specific IP network locations. Additional mitigations are described in the security researcher’s advisory.
Acknowledgements
Thanks to Derek Abdine for reporting this vulnerability.
This document was written by Brad Runyon, Vijay Sarvepalli, and Eric Hatleback.

Read more
VU#142546: SMA Technologies OpCon UNIX agent adds the same SSH key to all installations

VU#142546: SMA Technologies OpCon UNIX agent adds the same SSH key to all installations

Overview
SMA Technologies OpCon UNIX agent adds the same SSH key on every installation and subsequent updates. An attacker with access to the private key can gain root access on affected systems.
Description
During OpCon UNIX agent installation and updates, an SSH public key is added to the root account’s authorized_keys file. The corresponding private key titled sma_id_rsa is included with the installation files and is not encrypted with a passphrase. Removal of the OpCon software does not remove the entry from the authorized_keys file.
Impact
An attacker with access to the private key included with the OpCon UNIX agent installation files can gain SSH access as root on affected systems.
Solution
Remove private key
SMA Technologies has provided a tool to address the issue.
Another option is to manually remove the SSH key entry from root’s authorized_keys file. The key can be identified by its fingerprints:
SHA256:qbgTVNkLGI5G7erZqDhte63Vpw+9g88jYCxMuh8cLeg
MD5:f1:6c:c9:ba:21:66:ce:7c:5a:55:e2:4d:07:72:cc:31
Depending on the shell and operating system there are various ways to generate fingerprints for public keys listed in authorized_keys.
Upgrade
SMA Technologies reports that “We have updated our UNIX agent version 21.2 package to no longer include (and also remove) any existing vulnerability.”
Acknowledgements
Thanks to Nick Holland at Holland Consulting for researching and reporting this vulnerability.
This document was written by Kevin Stephens.

Read more