VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

Overview

The Heimdal Software Kerberos 5 implementation is vulnerable to a null pointer dereferance. An attacker with network access to an application that depends on the vulnerable code path can cause the application to crash.

Description

A flawed logical condition allows a malicious actor to remotely trigger a NULL pointer dereference using a crafted negTokenInit token.

Impact

An attacker can use a specially crafted network packet to cause a vulnerable application to crash.

Solution

The latest version of code in the Heimdal master branch fixes the issue. However, the current stable release 7.7.0 does not include the fix.

Acknowledgements

Thanks to the International Continence Society for reporting this issue.

This document was written by Kevin Stephens.

Continue reading VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

Posted in Uncategorized

VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

Overview

The Heimdal Software Kerberos 5 implementation is vulnerable to a null pointer dereferance. An attacker with network access to an application that depends on the vulnerable code path can cause the application to crash.

Description

A flawed logical condition allows a malicious actor to remotely trigger a NULL pointer dereference using a crafted negTokenInit token.

Impact

An attacker can use a specially crafted network packet to cause a vulnerable application to crash.

Solution

The latest version of code in the Heimdal master branch fixes the issue. However, the current stable release 7.7.0 does not include the fix.

Acknowledgements

Thanks to the International Continence Society for reporting this issue.

This document was written by Kevin Stephens.

Continue reading VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

Posted in Uncategorized

VU#915563: Microsoft Exchange vulnerable to server-side request forgery and remote code execution.

Overview

Microsoft Exchange Server 2019, Exchange Server 2016 and Exchange Server 2013 are vulnerable to a server-side request forgery (SSRF) attack and remote code execution. An authenticated attacker can use the combination of these two vulnerabilities to elevate privileges and execute arbitrary code on the target Exchange server.

Description

Microsoft Exchange Server’s Autodiscover service is a web service widely available to any Microsoft Exchange Web Services (EWS) client. Since Microsoft Exchange version 2016, the Autodiscover service has become an integral part of the Microsoft Exchange system, and it is no longer independently provided by a Client Access server. The Autodiscover service and a number of other privileged mailbox services are hosted on the default Internet Information Services server running on the Mailbox server.

Cybersecurity company GTSC observed an abuse of the Autodiscover service in August of 2022 using a crafted URL SSRF attack, similar to the earlier ProxyShell vulnerability reported in August 2021. The observed attack appears to have implemented CVE-2022-41040 to gain privileged access and CVE-2022-41082 to perform remote code execution via PowerShell. Microsoft Security Research Center has acknowledged the vulnerability and provided guidance for mitigation. The guidance highlights that Microsoft Exchange Online customers will be provided with detection and mitigation defenses automatically from Microsoft’s managed Infrastructure, informing them of any attempts to exploit these vulnerabilities.

Impact

An authenticated remote attacker can perform SSRF attacks to escalate privileges and execute arbtirary PowerShell code on vulnerable Microsoft Exchange servers. As the attack is targeted against Microsoft Exchange Mailbox server, the attacker can potentially gain access to other resources via lateral movement into Exchange and Active Directory environments.

Solution

Workaround guidance

Microsoft has provided guidance in their recent blog post to address the issue. Note that Microsoft has updated their guidance for the Option 3 Step 6 with the URL filter to be .*autodiscover\.json.*Powershell.* (excluding the @ symbol) instead of the earlier .*autodiscover\.json.*\@.*Powershell.*. The recommended block pattern is a regular expression suggested by Jang to prevent known variants of the #ProxyNotShell attacks. Microsoft further updated their advisory on October 8th suggesting Condition Input should be changed from {URL} to {UrlDecode:{REQUEST_URI}} to ensure all encoded variations are evaluated before being blocked.

Apply update when available

As of October 3, 2022, there is no patch available to mitigate this issue. It is recommended that Microsoft Exchange administrators stay on alert for any advisory or patch released by Microsoft. Note the latest security updates from Microsoft on October 11th do not address the vulnerabilities highlighted here. Even with the workaround in place, many on-premise Microsoft Exchange instances remain at risk until Microsoft provides a patch and the patch has been applied.

On November 8th 2022, Microsoft has provided fixes as part of their Patch Tuesday rollout, see updated Microsoft’s guidance at CVE-2022-41082 and CVE-2022-41040.

Third-party web application protection

Exchange Administrators who use third-party Web Application Firewall (WAF) products can implement the recommended URL filters and blocks as part of their WAF policy.

Other mitigations

Exchange Administrators can limit the outgoing connection from the Exchange Mailbox server using specific allowed list on an outgoing proxy to limit suspicious web requests.

This document was written by Vijay Sarvepalli.

Continue reading VU#915563: Microsoft Exchange vulnerable to server-side request forgery and remote code execution.

Posted in Uncategorized

VU#855201: L2 network security controls can be bypassed using VLAN 0 stacking and/or 802.3 headers

Overview

Layer-2 (L2) network security controls provided by various devices, such as switches, routers, and operating systems, can be bypassed by stacking Ethernet protocol headers. An attacker can send crafted packets through vulnerable devices to cause Denial-of-service (DoS) or to perform a man-in-the-middle (MitM) attack against a target network.

Description

This vulnerability exists within Ethernet encapsulation protocols that allow for stacking of Virtual Local Area Network (VLAN) headers. Network standards such as IEEE 802.1Q-1998 and IEEE 802.3 define a system of tagging Ethernet frames that help isolate networks to provide virtual networking capability. IEEE standard 802.1ad, also known as QinQ, allows for the stacking of these VLAN tags, extending the VLAN capability into multiple network segments. This widely adopted Ethernet feature is also referred to as “provider bridging” and “stacked VLANs”. In order to properly isolate and protect these virtual networks, many network devices and operating systems provide an L2 network filtering capability. It is important to note that in modern computing environments , such as Cloud based virtualization and virtual networking, the L2 network capability is extended beyond the local area networks. This can lead to exposure of this vulnerabilities in unintended ways to the larger Internet.

The identified vulnerabilities allow an attacker to bypass the security controls by stacking encapsulating headers. This is done by stacking a combination of one or more VLAN 0 (priority tag) headers and 802.2 LLC/SNAP headers. An attacker can send these crafted network packets and exploit vulnerable devices by bypassing their inspection and filtering capabilities. Some examples of bypassed L2 inspections include, but are not limited to, Dynamic ARP inspection, IPv6 Neighbor Discovery (ND) protection, and IPv6 RA Guard.

CVE-2021-27853
Layer 2 network filtering capabilities such as IPv6 RA guard or ARP inspection can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers.

CVE-2021-27854
Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using combinations of VLAN 0 headers, LLC/SNAP headers in Ethernet to Wifi frame translation and the reverse Wifi to Ethernet.

CVE-2021-27861
Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length (and optionally VLAN0 headers).

CVE-2021-27862
Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length and Ethernet to Wifi frame conversion (and optionally VLAN0 headers).

Impact

An attacker can bypass security controls and deceive a locally connected target host to route traffic to arbitrary destinations. Victim devices experience either a DoS (blackholing traffic) or MitM (observing the unencrypted traffic and maybe breaking encryption).

Solution

Apply Updates

Install vendor-provided patches and updates to ensure malicious content is blocked or rejected by the security controls (such as RA Guard), thereby blocking router advertisements or other network configuration related advertisements that originate on host ports.

Inspect and Block Router Advertisements

Utilize the interface security controls on your router or managed switch to perform DHCP snooping, IPv6 RA guard, IP source guard, and ARP/ND inspection. It is also recommended to only allow needed protocol on access ports (ARP/ICMP/IPv4/IPv6), some applications may have additional needs so be prepared to modify the allow list as needed.

Acknowledgements

Thanks to Etienne Champetier for reporting this vulnerability.

This document was written by Timur Snoke.

Continue reading VU#855201: L2 network security controls can be bypassed using VLAN 0 stacking and/or 802.3 headers

Posted in Uncategorized

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.

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

Posted in Uncategorized

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.

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

Posted in Uncategorized

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.

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

Posted in Uncategorized

VU#473698: uClibc, uClibc-ng libraries have monotonically increasing DNS transaction ID

Overview

The uClibc and uClibc-ng libraries, prior to uClibc-ng 1.0.41, are vulnerable to DNS cache poisoning due to the use of predicatble DNS transaction IDs when making DNS requests. This vulnerability can allow an attacker to perform DNS cache poisoning attacks against a vulnerable environment.

Description

The uClibc and the Uclibc-ng software are lightweight C standard libraries intended for use in embedded systems and mobile devices. The uClibc library has not been updated since May of 2012. The newer uClibc-ng is the currently maintained fork of uClibc, as announced on the OpenWRT mailing list in July 2014.

Researchers at the Nozomi Networks Security Research Team discovered that all existing versions of uClibc and uClibc-ng libraries are vulnerable to DNS cache poisoning. These libraries do not employ any randomization in the DNS Transaction ID (DNS TXID) field when creating a new DNS request. This can allow an attacker to send maliciously crafted DNS packets to corrupt the DNS cache with invalid entries and redirect users to arbitrary sites. As uClibc and uClibc-ng are used in devices such as home routers and firewalls, an attacker can perform attacks against multiple users in a shared network environment that relies on DNS responses from the vulnerable device.

The DNS cache poisoning scenarios and defenses are discussed in IETF RFC5452.

Impact

The lack of DNS response validation can allow an attacker to use unsolicited DNS responses to poison the DNS cache and redirect users to malicious sites.

Solution

Apply a patch

If your vendor has developed a patched version of uClibc or uClibc-ng to address this issue, apply the updates provided by your vendor. uClibc-ng was updated to 1.0.41 on 05/20/2022.

Product Developers

If you have a forked or customized version of uClibc or uClibc-ng, develop or adopt a patch to ensure the dns_lookup function provides adequate randomization of DNS TXID’s while making DNS requests. Review and consider applying the patch has been made available in patchwork repository of uClibc-ng with VU#638879 tag.

Follow security best practices

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

  • Prevent direct exposure of IoT devices and lightweight devices over the Internet to minimize attacks against a caching DNS server.
  • Provide secure DNS recursion service with features such as DNSSEC validation and the interim 0x20-bit encoding as part of enterprise DNS recursion services where applicable.
  • 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

Thanks to the Nozomi Networks Security Research Team for this report

This document was written by Vijay Sarvepalli and Timur Snoke.

Continue reading VU#473698: uClibc, uClibc-ng libraries have monotonically increasing DNS transaction ID

Posted in Uncategorized

VU#730007: Tychon is vulnerable to privilege escalation due to OPENSSLDIR location

Overview

Tychon contains a privilege escalation vulnerability due to the use of an OPENSSLDIR variable that specifies a location where an unprivileged Windows user may be able to place files.

Description

Tychon includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory that my be controllable by an unprivileged user on Windows. Tychon contains a privileged service that uses this OpenSSL component. A user who can place a specially-crafted openssl.cnf file at an appropriate path may be able to achieve arbitrary code execution with SYSTEM privileges.

Impact

By placing a specially-crafted openssl.cnf in a location used by Tychon, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Tychon software installed.

Solution

Apply an update

This issue is addressed in Tychon 1.7.857.82

Acknowledgements

This document was written by Will Dormann.

Continue reading VU#730007: Tychon is vulnerable to privilege escalation due to OPENSSLDIR location

Posted in Uncategorized

VU#411271: Qt allows for privilege escalation due to hard-coding of qt_prfxpath value

Overview

Prior to version 5.14, Qt hard-codes the qt_prfxpath value to a fixed value, which may lead to privilege escalation vulnerabilities in Windows software that uses Qt.

Description

Prior to version 5.14, Qt hard-codes the qt_prfxpath value to a value that reflects the path where Qt exists on the system that was used to build Qt. For example, it may refer to a specific subdirectory within C:\Qt\, which is the default installation location for Qt on Windows. If software that is built with Qt runs with privileges on a Windows system, this may allow for privilege escalation due to the fact that Windows by default allows unprivileged users to create subdirectories off of the root C:\ drive location.

In 2015, a patch was made to windeployqt to strip out any existing qt_prfxpath value from Qt5Core.dll. If Windows software that uses Qt prior to version 5.14 is not properly packaged using windeployqt, then it may be vulnerable to privilege escalation.

Impact

By placing a file in an appropriate location on a Windows system, an unprivileged attacker may be able to execute arbitrary code with the privileges of the software that uses Qt.

Solution

Apply an update

This issue is addressed in Qt 5.14. Starting with this version, Qt no longer hard-codes the qt_prfxpath value in Qt5Core.dll.

Run windeployqt to prepare Windows Qt software for deployment

The windeployqt utility will replace the qt_prfxpath value in the Qt core DLL with the value of ., which helps prevent this path from being used to achieve privilege escalation.

Acknowledgements

This document was written by Will Dormann.

Continue reading VU#411271: Qt allows for privilege escalation due to hard-coding of qt_prfxpath value

Posted in Uncategorized