Currently browsing: General

Vista Net, Inc. > Blog > General
December 11, 2024 General, Security, Technology Comments Off on VU#164934: PDQ Deploy allows reuse of deleted credentials that can compromise a device and facilitate lateral movement

VU#164934: PDQ Deploy allows reuse of deleted credentials that can compromise a device and facilitate lateral movement

Overview
PDQ Deploy is a service intended for usage by system administrators for the deployment of software or updates to targeted machines within their network. PDQ Deploy uses “run modes” to deploy software to their target devices. The run mode “Deploy User” insecurely creates credentials on the target device. These credentials are deleted from the device following a full deployment of a software file, however, an attacker with access to the target device can compromise these credentials prior to deletion through common password tools such as Mimikatz. These credentials could then be used to gain administrator access on the target device, or to compromise any other device using these credentials that is enrolled through active directory and has previously had software deployed to it by PDQ Deploy.
Description
PDQ Deploy is a service intended for usage by system administrators and others for the deployment of software or updates to targeted machines within their network. PDQ Deploy has various configurations, including automated deployment and availability based deployments. PDQ Deploy also uses various “run modes” to deploy software to their target devices. The “Deploy User” run mode can use a domain or local account with administrator rights on the target computer during the deployment process.
The deployment process is as follows:
1: PDQ Deploy initiates an application deployment.
2: The central server connects to the target device remotely with the “Deploy User” credentials.
3: A local service is created on the device and is run as the selected domain or local user account specified as the deploy user.
4: PDQ follows the application deployment process, installing the requested software.
5: The service is removed from the remote device.
An attacker with access to the device can use a password dumping tool, such as Mimikatz, to dump these credentials during the deployment process, specifically during steps 2 to 4, prior to their deletion. If using a domain user, these credentials created by the Deploy User domain account are static and can be used to compromise any other device that is enrolled in PDQ Deploy through Active Directory sharing this user, allowing for lateral movement.
PDQ Deploy supports other “Run Modes” for use during the deployment process. These run modes alter how credentials are saved on the device. These include the “Local System” deploy mode, in which the service is ran as a Local System account. A Local System account has lower privileges than a domain account, but PDQ Deploy still uses the Deploy User Account to connect to the device and initiate the Local System account, resulting in the vulnerabilities still being present for that user.
Impact
An attacker with access to the PDQ Deploy service and the ability to execute common password tools such as Mimikatz can dump the Deploy User administrator credentials from a device during the deployment process, then use those credentials to either further compromise the current device, or move laterally and compromise other PDQ Deploy enrolled systems on the Active Directory system that share the user and use a domain account. The compromised machine must have been previously deployed to via PDQ Deploy.
Solution
The CERT/CC is creating this Vulnerability Note to advise and make users of PDQ Deploy aware of potential avenues of attack through the deploy service. System administrators that are using PDQ Deploy should employ LAPS to mitigate this vulnerability. System administrators could also follow the recommendations outlined in the How-to-Guides listed on the PDQ Deploy website. (https://help.pdq.com/hc/en-us/articles/360033877651-Adding-and-Using-Multiple-Credentials-in-PDQ-Deploy-Inventory) Additionally, alternate deploy modes could be used. The “Logged on User” deploy mode utilizes the active credentials of the device currently logged in to create the necessary services and deploy the requested software.This deploy mode does not create a service with the domain/local credentials, and as such, is an appropriate deployment mode to avoid the vulnerability. It should be noted this Run Mode is only available on the Enterprise mode, and requires user input to complete the deployment of the software.
Acknowledgements
Thanks to the reporter who wishes to remain anonymous. A French source validated and coordinated this vulnerability note and case with CERT/CC. This document was written by Christopher Cullen.

Read more
October 17, 2022 General Comments Off on VU#730793: Heimdal Kerbos vulnerable to remotely triggered NULL pointer dereference

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.

Read more
August 11, 2022 General Comments Off on 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 BootNew Horizon Datasys Inc (CVE-2022-34302)

UEFI Shell execution to bypass Secure BootCryptoPro 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
Follow us