VU#506989: Microsoft Windows 10 gives unprivileged user access to system32\config files

Overview

Multiple versions of Windows 10 grant non-administrative users read access to files in the %windir%\system32\config directory. This can allow for local privilege escalation (LPE).

Description

With multiple versions of Windows 10, the BUILTIN\Users group is given RX permissions to files in the %windir%\system32\config directory.

If a VSS shadow copy of the system drive is available, a non-privileged user may leverage access to these files to achieve a number of impacts, including but not limited to:

  • Extract and leverage account password hashes.
  • Discover the original Windows installation password.
  • Obtain DPAPI computer keys, which can be used to decrypt all computer private keys.
  • Obtain a computer machine account, which can be used in a silver ticket attack.

Note that VSS shadow copies may not be available in some configurations, however simply having a system drive that is larger that 128GB in size and then performing a Windows Update or installing an MSI will ensure that a VSS shadow copy will be automatically created. To check if a system has VSS shadow copies available, run the following command from a privileged command prompt:

vssadmin list shadows

A system with VSS shadow copies will report details of at least one shadow copy that specifies Original Volume: (C:), such as the following:

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Contents of shadow copy set ID: {d9e0503a-bafa-4255-bfc5-b781cb27737e}
   Contained 1 shadow copies at creation time: 7/19/2021 10:29:49 PM
      Shadow Copy ID: {b7f4115b-4242-4e13-84c0-869524965718}
         Original Volume: (C:)\\?\Volume{4c1bc45e-359f-4517-88e4-e985330f72e9}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
         Originating Machine: DESKTOP-PAPIHMA
         Service Machine: DESKTOP-PAPIHMA
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

A system without VSS shadow copies will produce output like the following:

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

No items found that satisfy the query.

To check if a system is vulnerable, the following command can be used from a non-privileged command prompt:
icacls %windir%\system32\config\sam

A vulnerable system will report BUILTIN\Users:(I)(RX) in the output like this:


C:\Windows\system32\config\sam BUILTIN\Administrators:(I)(F)
                               NT AUTHORITY\SYSTEM:(I)(F)
                               BUILTIN\Users:(I)(RX)
                               APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                               APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

A system that is not vulnerable will report output like this:

C:\Windows\system32\config\sam: Access is denied.
Successfully processed 0 files; Failed processing 1 files

This vulnerability has been publicly referred to as both HiveNightmare and SeriousSAM, while Microsoft has assigned CVE-2021-36934 to the vulnerability.

Impact

By accessing files in the Windows %windir%\system32\config directory on a vulnerable system with at least one VSS shadow copy of the system drive, a local authenticated attacker may be able to achieve LPE, masquerade as other users, or achieve other security-related impacts.

Solution

Please see the Microsoft bulletin for CVE-2021-36934, which contains a workaround. Specifically:

Restrict access to %windir%\system32\config and remove VSS shadow copies

Vulnerable systems can enable ACL inheritance for files in the %windir%\system32\config directory by running the following command from an elevated prompt:

icacls %windir%\system32\config\*.* /inheritance:e

Once the ACLs have been corrected for these files, any VSS shadow copies of the system drive must be deleted to protect a system against exploitation. This can be accomplished with the following command:

vssadmin delete shadows /for=%systemdrive% /Quiet

Confirm that VSS shadow copies were deleted by running vssadmin list shadows again. Note that any capabilities relying on existing shadow copies, such as System Restore, will not function as expected. Newly-created shadow copies, which will contain the proper ACLs, will function as expected. Please see KB5005357 for more details.

Acknowledgements

This vulnerability was publicly disclosed by Jonas Lyk, with additional details provided by Benjamin Delpy.

This document was written by Will Dormann.

Continue reading VU#506989: Microsoft Windows 10 gives unprivileged user access to system32\config files

Posted in Uncategorized

VU#131152: Microsoft Windows Print Spooler Point and Print allows installation of arbitrary queue-specific files

Overview

Microsoft Windows allows for non-admin users to be able to install printer drivers via Point and Print. Printers installed via this technique also install queue-specific files, which can be arbitrary libraries to be loaded by the privileged Windows Print Spooler process.

Description

Microsoft Windows allows for users who lack administrative privileges to still be able to install printer drivers, which execute with SYSTEM privileges via the Print Spooler service. This ability is achieved through a capability called Point and Print. Starting with the update for MS16-087, Microsoft requires that printers installable via Point are either signed by a WHQL release signature, or are signed by a certificate that is explicitly trusted by the target system, such as an installed test signing certificate. The intention for this change is to avoid installation of malicious printer drivers, which can allow for Local Privilege Escalation (LPE) to SYSTEM.

While Windows enforces that driver packages themselves are signed by a trusted source, Windows printer drivers can specify queue-specific files that are associated with the use of the device. For example, a shared printer can specify a CopyFiles directive for arbitrary files. These files, which may be copied over alongside the digital-signature-enforced printer driver files are not covered by any signature requirement. Furthermore, these files can be used to overwrite any of the signature-verified files that were placed on a system during printer driver install. The remote printer can also be configured to automatically execute code in any files dropped by the CopyFiles directive. This can allow for LPE to SYSTEM on a vulnerable system.

An exploit for this vulnerability is publicly available.

Impact

By connecting to a malicious printer, an attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system.

Solution

Microsoft has published updates for CVE-2021-36958 regarding this issue. Please also consider the following workarounds:

Block outbound SMB traffic at your network boundary

Public exploits for this vulnerability utilize SMB for connectivity to a malicious shared printer. If outbound connections to SMB resources are blocked, then this vulnerability may be mitigated for malicious SMB printers that are hosted outside of your network. Note that an attacker local to your network would be able to share a printer via SMB, which would be unaffected by any outbound SMB traffic rules.

Configure both PackagePointAndPrintServerList and PackagePointAndPrintOnly settings

Microsoft Windows has a Group Policy called “Package Point and Print – Approved servers”, which is reflected in the HKLM\Software\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\PackagePointAndPrintServerList and HKLM\Software\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\ListofServers registry values. This policy can restrict which servers can be used by non-administrative users to install printers via Point and Print. Configure this policy to prevent installation of printers from arbitrary servers.

To ensure that Microsoft Windows only attempts to install Package Point and Print printers, and therefore restricting printer connections to the approved servers list, you must also set the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PackagePointAndPrint\PackagePointAndPrintOnly registry value to 1. The Group Policy setting that corresponds to this value is called “Use only Package Point and print”. Setting this value to “Enabled” will enforce that only Package Point and Print printers will be used.

Both of these settings must be configured to protect against exploitation of this vulnerability.

Block the ability to modify the print spooler drivers directory

Courtesy of the TRUESEC Blog, this vulnerability can be mitigated by preventing the SYSTEM account from being able to modify the C:\Windows\System32\spool\drivers directory contents.

To enable this mitigation, from a privileged PowerShell session, run:

$Path = "C:\Windows\System32\spool\drivers"
$Acl = (Get-Item $Path).GetAccessControl('Access')
$Ar = New-Object  System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")
$Acl.AddAccessRule($Ar)
Set-Acl $Path $Acl

To revert the mitigation to allow printer driver installation or modification, run:

$Path = "C:\Windows\System32\spool\drivers"
$Acl = (Get-Item $Path).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")
$Acl.RemoveAccessRule($Ar)
Set-Acl $Path $Acl

Stop and disable the Print Spooler

The Print Spooler can be disabled in a privileged PowerShell session by running the following commands:

Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

Impact of workaround Disabling the Print Spooler service disables the ability to print both locally and remotely.

Acknowledgements

This vulnerability was publicly disclosed by Benjamin Delpy. Microsoft credits Victor Mata with reporting this issue to them.

This document was written by Will Dormann.

Continue reading VU#131152: Microsoft Windows Print Spooler Point and Print allows installation of arbitrary queue-specific files

Posted in Uncategorized

VU#383432: Microsoft Windows Print Spooler allows for RCE via AddPrinterDriverEx()

Overview

The Microsoft Windows Print Spooler service fails to restrict access to functionality that allows users to add printers and related drivers, which can allow a remote authenticated attacker to execute arbitrary code with SYSTEM privileges on a vulnerable system.

Description

The RpcAddPrinterDriverEx() function is used to install a printer driver on a system. One of the parameters to this function is the DRIVER_CONTAINER object, which contains information about which driver is to be used by the added printer. The other argument, dwFileCopyFlags, specifies how replacement printer driver files are to be copied. An attacker can take advantage of the fact that any authenticated user can call RpcAddPrinterDriverEx() and specify a driver file that lives on a remote server. This results in the Print Spooler service spoolsv.exe executing code in an arbitrary DLL file with SYSTEM privileges.

Note that while original exploit code relied on the RpcAddPrinterDriverEx to achieve code execution, an updated version of the exploit uses RpcAsyncAddPrinterDriver to achieve the same goal. Both of these functions achieve their functionality using AddPrinterDriverEx.

While Microsoft has released an update for CVE-2021-1675, it is important to realize that this update does NOT protect against public exploits that may refer to PrintNightmare or CVE-2021-1675.

On July 1, Microsoft released CVE-2021-34527. This bulletin states that CVE-2021-34527 is similar but distinct from the vulnerability that is assigned CVE-2021-1675, which addresses a different vulnerability in RpcAddPrinterDriverEx(). The attack vector is different as well. CVE-2021-1675 was addressed by the June 2021 security update.

Impact

By sending a request to add a printer, e.g. by using RpcAddPrinterDriverEx() over SMB or RpcAsyncAddPrinterDriver() over RPC, a remote, authenticated attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system. A local unprivileged user may be able to execute arbitrary code with SYSTEM privileges as well. We have created a flowchart to indicate exploitability of PrintNightmare across various platform configurations:

PrintNightmare exploitability flowchart

Solution

Apply an update

Microsoft has addressed this issue in the updates for CVE-2021-34527. Note that the Microsoft update for CVE-2021-34527 does not effectively prevent exploitation of systems where the Point and Print NoWarningNoElevationOnInstall is set to a non-0 value. Microsoft indicates that systems that have NoWarningNoElevationOnInstall is set to a non-0 value are vulnerable by design. For systems that do not have the CVE-2021-34527 installed, or have Point and Print configured insecurely, please consider the following workarounds:

Apply a workaround

Microsoft has listed several workarounds in their advisory for CVE-2021-34527. Specifically:

Microsoft Option 1 – Stop and disable the Print Spooler service

This vulnerability can be mitigated by stopping and disabling the Print Spooler service in Windows.

If disabling the Print Spooler service is appropriate for your enterprise, use the following PowerShell commands:

Stop-Service -Name Spooler -Force

Set-Service -Name Spooler -StartupType Disabled

Impact of workaround Disabling the Print Spooler service disables the ability to print both locally and remotely.

Microsoft Option 2 – Disable inbound remote printing through Group Policy

Disable the “Allow Print Spooler to accept client connections:” policy to block remote attacks.

Impact of workaround This policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible.

Note: The Print Spooler service must be restarted for this workaround to be activated.

Block RPC and SMB ports at the firewall

Limited testing has shown that blocking both the RPC Endpoint Mapper (135/tcp) and SMB (139/tcp and 445/tcp) incoming traffic at a host-based firewall level can prevent remote exploitation of this vulnerability. Note that blocking these ports on a Windows system may prevent expected capabilities from functioning properly, especially on a system that functions as a server.

Enable security prompts for Point and Print

Ensure that the Windows Point and Print Restrictions are set to Show warning and elevation prompt for both installing and updating drivers in the Windows Group Policy. Specifically the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\ key should have NoWarningNoElevationOnInstall and UpdatePromptSettings entries that are both set to 0.

Restrict printer driver installation ability to administrators

After the Microsoft update for CVE-2021-34527 is installed, a registry value called RestrictDriverInstallationToAdministrators in the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\ key is checked, which is intended to restrict printer driver installation to only administrator users. Please see KB5005010 for more details.

Acknowledgements

This issue was publicly disclosed by Zhiniang Peng and Xuefeng Li.

This document was written by Will Dormann.

Continue reading VU#383432: Microsoft Windows Print Spooler allows for RCE via AddPrinterDriverEx()

Posted in Uncategorized

VU#706695: Checkbox Survey insecurely deserializes ASP.NET View State data

Overview

Checkbox Survey prior to version 7.0 insecurely deserializes ASP.NET View State data, which can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable server.

Description

CVE-2021-27852
Checkbox Survey insecurely deserializes ASP.NET View State data.

Checkbox Survey is an ASP.NET application that can add survey functionality to a website. Prior to version 7.0, Checkbox Survey implements its own View State functionality by accepting a _VSTATE argument, which it then deserializes using LosFormatter. Because this data is manually handled by the Checkbox Survey code, the ASP.NET ViewState Message Authentication Code (MAC) setting on the server is ignored. Without MAC, an attacker can create arbitrary data that will be deserialized, resulting in arbitrary code execution.

This vulnerability is reportedly being exploited in the wild.

Impact

By making a specially-crafted request to a server that uses Checkbox Survey 6.x or earlier, a remote, unauthenticated attacker may be able to execute arbitrary code with the privileges of the web server.

Solution

Apply an update

Starting with Checkbox Survey 7.0, View State data is not used. Therefore, Checkbox Survey versions 7.0 and later do not contain this vulnerability.

Remove Checkbox Survey versions older than 7

Checkbox is no longer developing Checkbox Survey version 6, so this version is no longer safe to use. If you are unable to update to an unaffected version of Checkbox Survey, this software should be removed from any systems that have it installed.

Acknowledgements

Thanks to the reporter who wishes to remain anonymous.

This document was written by Will Dormann.

Continue reading VU#706695: Checkbox Survey insecurely deserializes ASP.NET View State data

Posted in Uncategorized

VU#667933: Pulse Connect Secure Samba buffer overflow

Overview

Pulse Connect Secure (PCS) gateway contains a buffer overflow vulnerability in Samba-related code that may allow an authenticated remote attacker to execute arbitrary code.

Description

CVE-2021-22908

PCS includes the ability to connect to Windows file shares (SMB). This capability is provided by a number of CGI scripts, which in turn use libraries and helper applications based on Samba 4.5.10. When specifying a long server name for some SMB operations, the smbclt application may crash due to either a stack buffer overflow or a heap buffer overflow, depending on how long of a server name is specified. We have confirmed that PCS 9.1R11.4 systems are vulnerable, targeting a CGI endpoint of: /dana/fb/smb/wnf.cgi. Other CGI endpoints may also trigger the vulnerable code.

Specifying a long server name to this endpoint may result in a PCS events log entry that may look like the following:

Critical ERR31093 2021-05-24 14:05:37 - ive - [127.0.0.1] Root::System()[] - Program smbclt recently failed. 

Successful exploitation of this vulnerability may not produce such a log entry if the program is cleanly exited during exploitation, or if the log files are sanitized after successful exploitation.

In order to be vulnerable, a PCS server must have a Windows File Access policy that allows \\* or it must have some other policy set that would allow an attacker to connect to an arbitrary server. In the administrative page for the PCS, see Users -> Resource Policies -> Windows File Access Policies to view your current SMB policy. Any PCS device that started as version 9.1R2 or earlier will have a default policy that allows connecting to arbitrary SMB hosts. Starting with 9.1R3, this policy was changed from a default allow to a default deny.

Note that the vendor implies that the Files, Window[sic] access feature can be disabled for user roles in order to protect against this vulnerability. This is NOT the case. The vulnerable CGI endpoints are still reachable in ways that will trigger the smbclt application to crash, regardless of whether the Files, Windows user role is enabled or not. These steps are only included in the advisory to limit excessive errors showing up in PCS logs after the XML workaround has been installed.

In our testing, an attacker would need either valid PCS user credentials, or a DSID value from an authenticated user to successfully reach the vulnerable code on a PCS server that has an open Windows File Access policy. We have created a PoC utility to test for PCS systems vulnerable to CVE-2021-22908 as well as which mitigations may be applied.

Impact

By performing certain SMB operations with a specially-crafted server name, an authenticated attacker may be able to execute arbitrary code with root privileges on a vulnerable PCS server.

Solution

Apply an update

This issue is addressed in PCS 9.1R11.5. Please see advisory SA44800 for more details.

Apply an XML workaround

Pulse Secure has published advisory SA44800 that mentions a Workaround-2105.xml file that contains a mitigation to protect against this vulnerability. Importing this XML workaround will activate the protections immediately and does not require any downtime for the VPN system. This workaround will block requests that match the following URI patterns:

^/+dana/+fb/+smb
^/+dana-cached/+fb/+smb

Workaround-2105.xml will automatically deactivate the mitigations applied by Workaround-2104.xml when it is installed. As such, it is imperative that a PCS system is running 9.1R11.4 before applying the Workaround-2105.xml mitigation, which will ensure that the vulnerabilities outlined in SA44784 are not reintroduced as the result of applying this workaround.

Note that installing this workaround will block the ability to use the following feature:

  • Windows File Share Browser

Set a Windows File Access Policy

This vulnerability relies on the ability to connect to an arbitrary SMB server name to trigger the vulnerability. A PCS system that started as version 9.1R3 or later will have a default Initial File Browsing Policy of Deny for \\* SMB connections. If you have a PCS system that started as 9.1R2 or earlier, it will retain the default Initial File Browsing Policy of Allow for \\* SMB connections, which will expose this vulnerability. In the administrative page for the PCS, see Users -> Resource Policies -> Windows File Access Policies to view your current SMB policy.

If your PCS has a policy that explicitly allows \\* or otherwise may allow users to initiate connections to arbitrary SMB server names, you should configure the PCS to Deny connections to such resources to minimize your PCS attack surface.

Acknowledgements

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

This document was written by Will Dormann.

Continue reading VU#667933: Pulse Connect Secure Samba buffer overflow

Posted in Uncategorized

VU#799380: Devices supporting Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure

Overview

Devices supporting the Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure that could allow an attacker to impersonate a legitimate device during pairing.

Description

The Bluetooth Core Specification and Mesh Profile Specification are two specifications used to define the technical and policy requirements for devices that want to operate over Bluetooth connections. Researchers at the Agence nationale de la sécurité des systèmes d’information (ANSSI) have identified a number of vulnerabilities in each specification that allow impersonation attacks and AuthValue disclosures.

Devices supporting the Bluetooth Core Specification are affected by the following vulnerabilities:

Impersonation in the Passkey Entry Protocol

The Passkey Entry protocol used in Secure Simple Pairing (SSP), Secure Connections (SC), and LE Secure Connections (LESC) of the Bluetooth Core Specification is vulnerable to an impersonation attack that enables an active attacker to impersonate the initiating device without any previous knowledge (CVE-2020-26558). An attacker acting as a man-in-the-middle (MITM) in the Passkey authentication procedure could use a crafted series of responses to determine each bit of the randomly generated Passkey selected by the pairing initiator in each round of the pairing procedure, and once identified, the attacker can use these Passkey bits during the same pairing session to successfully complete the authenticated pairing procedure with the responder. Devices supporting BR/EDR Secure Simple Pairing in Bluetooth Core Specifications 2.1 through 5.2, BR/EDR Secure Connections Pairing in Bluetooth Core Specifications 4.1 through 5.2 and LE Secure Connections Pairing in Bluetooth Core Specifications 4.2 through 5.2 are affected by this vulnerability.

Impersonation in the Pin Pairing Protocol

The Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack (CVE-2020-26555). An attacker could connect to a victim device by spoofing the Bluetooth Device Address (BD_ADDR) of the device, reflect the the encrypted nonce, and complete BR/EDR pin-code pairing with them without knowledge of the pin code. A successful attack requires the attacking device to be within wireless range of a vulnerable device supporting BR/EDR Legacy Pairing that is Connectable and Bondable. Devices supporting the Bluetooth Core Specification versions 1.0B through 5.2 are affected by this vulnerability.

Devices supporting Bluetooth Mesh Profile Specification, versions 1.0 and 1.0.1, are affected by the following vulnerabilities:

Impersonation in Bluetooth Mesh Provisioning

The Mesh Provisioning procedure could allow an attacker without knowledge of the AuthValue, spoofing a device being provisioned, to use crafted responses to appear to possess the AuthValue and to be issued a valid NetKey and potentially an AppKey (CVE-2020-26560). For this attack to be successful, an attacking device needs to be within wireless range of a Mesh Provisioner and either spoof the identity of a device being provisioned over the air or be directly provisioned onto a subnet controlled by the provisioner.

Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM

The Mesh Provisioning procedure could allow an attacker observing or taking part in the provisioning to brute force the AuthValue if it has a fixed value, or is selected predictably or with low entropy (CVE-2020-26557). Identifying the AuthValue generally requires a brute-force search against the provisioning random and provisioning confirmation produced by the Provisioner. This brute-force search, for a randomly selected AuthValue, must complete before the provisioning procedure times out, which can require significant resources. If the AuthValue is not selected randomly with each new provisioning attempt, then the brute-force search can occur offline and if successful, would permit an attacker to identify the AuthValue and authenticate to both the Provisioner and provisioned devices, permitting a MITM attack on a future provisioning attempts with the same AuthValue.

Malleable Commitment

The authentication protocol is vulnerable if the AuthValue can be identified during the provisioning procedure, even if the AuthValue is selected randomly (CVE-2020-26556). If an attacker can identify the AuthValue used before the provisioning procedure times out, it is possible to complete the provisioning operation and obtain a NetKey. Similar to CVE-2020-26557, identifying the AuthValue generally requires a brute-force search against the provisioning random and provisioning confirmation produced by the Provisioner. This brute-force search for a randomly selected AuthValue, which can require significant resources, must complete before the provisioning procedure times out.

AuthValue Leak

The Mesh Provisioning procedure could allow an attacker that was provisioned without access to the AuthValue to identify the AuthValue directly without brute-forcing its value (CVE-2020-26559). Even when a randomly generated AuthValue with a full 128-bits of entropy is used, an attacker acquiring the Provisioner’s public key, provisioning confirmation value, and provisioning random value, and providing its public key for use in the provisioning procedure, will be able to compute the AuthValue directly.

Impact

Impersonation in the Passkey Entry Protocol

This vulnerability could allow an attacker to authenticate to the response victim device and act as a legitimate encrypted device. The attacker cannot pair with the initiating device using this method of attack, which prevents a fully transparent man-in-the-middle attack between the initiator and responder. For this attack to be successful, an attacking device needs to be within wireless range of two vulnerable Bluetooth devices that are initiating pairing or bonding for which a BR/EDR IO Capabilities exchange or LE IO Capability in the pairing request and response results in the selection of the Passkey pairing procedure.

Impersonation in the Pin Pairing Protocol

This vulnerability could allow an attacker to complete pairing with a known link key, encrypt communications with the vulnerable device, and access any profiles permitted by a paired or bonded remote device supporting Legacy Pairing.

Impersonation in Bluetooth Mesh Provisioning

This vulnerability could allow an attacker to successfully authenticate without the AuthValue. Once authenticated, the attacker could perform any operation permitted to a node provisioned on the subnet until it is either denied access or a new subnet is formed without the attacking node present.

Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM

This vulnerability could allow an attacker to successfully brute force the AuthValue and authenticate to both the Provisioner and provisioned devices, permitting a MITM attack on a future provisioning attempt with the same AuthValue.

Malleable Commitment

This vulnerability could allow an attacker to obtain a NetKey, which could be used to decrypt and authenticate up to the network layer, allowing the relay of messages, but no application data decryption.

AuthValue Leak

This vulnerability could allow an attacker to compute the AuthValue and authenticate to the Provisioner and provisioned devices.

Solution

Bluetooth users should ensure that they have installed the latest recommended updates from device and operating system manufacturers.

In addition to the two vulnerabilities affecting the Bluetooth Core Specification, the researchers also identified a potential security vulnerability related to LE Legacy Pairing authentication in Bluetooth Core Specification versions 4.0 through 5.2. The researchers claim that an attacker can reflect the confirmation and random numbers of a peer device in LE legacy pairing to successfully complete legacy authentication phase 2 without knowledge of the temporary key (TK). Because the attacker does not acquire a TK, or valid short-term key (STK) during this attack, completing authentication phase 2 is not sufficient for an encrypted link to be established. While the Bluetooth SIG does not consider this to be a method which can provide unauthorized access to a device, they still recommend that LE implementations requiring pairing and encryption use LE Secure Connections. The Bluetooth SIG also recommends that, where possible, implementations enable and enforce Secure Connections Only Mode, ensuring that LE legacy pairing cannot be used.

The Bluetooth SIG additionally makes the following recommendations for each vulnerability:

Impersonation in the Passkey Entry Protocol

For the attack to succeed the pairing device needs to accept the same public key that it provided to the remote peer as the remote peer’s public key. The Bluetooth SIG recommends that potentially vulnerable implementations restrict the public keys accepted from a remote peer device to disallow a remote peer to present the same public key chosen by the local device, and the pairing procedure should be terminated with a failure status if this occurs.

Impersonation in the Pin Pairing Protocol

The Bluetooth SIG recommends that potentially vulnerable devices not initiate or accept connections from remote devices claiming the same BD_ADDR as the local device. They also continue to recommend that devices use Secure Simple Pairing or BR/EDR Secure Connections to avoid known vulnerabilities with legacy BR/EDR pairing.

Impersonation in Bluetooth Mesh Provisioning

The Bluetooth SIG recommends that potentially vulnerable mesh provisioners restrict the authentication procedure and not accept provisioning both random and confirmation numbers from a remote peer that are the same as those selected by the local device.

Predictable AuthValue in Bluetooth Mesh Provisioning Leads to MITM

The Bluetooth SIG recommends that mesh implementations enforce a randomly selected AuthValue using all of the available bits, where permitted by the implementation. A large entropy helps ensure that a brute-force of the AuthValue, even a static AuthValue, cannot normally be completed in a reasonable time.

Malleable Commitment

The statement from the Bluetooth SIG notes: “AuthValues selected using a cryptographically secure random or pseudorandom number generator and having the maximum permitted entropy (128-bits) will be most difficult to brute-force. AuthValues with reduced entropy or generated in a predictable manner will not grant the same level of protection against this vulnerability. Selecting a new AuthValue with each provisioning attempt can also make it more difficult to launch a brute-force attack by requiring the attacker to restart the search with each provisioning attempt.”

AuthValue Leak

The Bluetooth SIG recommends that potentially vulnerable mesh provisioners use an out-of-band mechanism to exchange the public keys.

Acknowledgements

Thanks to researchers at the Agence nationale de la sécurité des systèmes d’information (ANSSI) for reporting these vulnerabilities.

This document was written by Madison Oliver.

Continue reading VU#799380: Devices supporting Bluetooth Core and Mesh Specifications are vulnerable to impersonation attacks and AuthValue disclosure

Posted in Uncategorized

VU#567764: MySQL for Windows is vulnerable to privilege escalation due to OPENSSLDIR location

Overview

MySQL for Windows 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-2021-2307

MySQL includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory of /build_area/. On the Windows platform, this path is interpreted as C:\build_area. MySQL 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 a C:\build_area subdirectory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable MySQL software installed.

Solution

Apply an update

This vulnerability is addressed in the MySQL Windows installer version 8.0.24 and 5.7.34.

Create a C:\build_area directory

In cases where an update cannot be installed, this vulnerability can be mitigated by creating a C:\build_area 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.

Continue reading VU#567764: MySQL for Windows is vulnerable to privilege escalation due to OPENSSLDIR location

Posted in Uncategorized

VU#213092: Pulse Connect Secure contains a use-after-free vulnerability

Overview

Pulse Connect Secure (PCS) gateway contains a use-after-free vulnerability that can allow an unauthenticated remote attacker to execute arbitrary code.

Description

CVE-2021-22893

A use-after-free vulnerability that can be reached via a license server handling endpoint may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable Pulse Connect Secure gateway system.

Every system that is running PCS 9.0R3 or higher or 9.1R1 through 9.2R11.3 is affected. Having the license server configuration enabled is NOT a prerequisite to being vulnerable. The vulnerable endpoints are present regardless of whether the system is an actual license server or not.

This vulnerability is being exploited in the wild.

Impact

By making a crafted request to a vulnerable Pulse Connect Secure system, an unauthenticated remote attacker may be able to execute arbitrary code on the gateway with root privileges.

Solution

Apply an update

This vulnerability and others are addressed in Pulse Connect Secure 9.1R11.4.

Apply a workaround

If you are not using the features that the following workaround disables, we recommend applying the XML workaround even on systems that have been upgraded to 9.1R11.4 to reduce attack surface. Pulse Secure has published a Workaround-2104.xml file that contains mitigations to protect against this and other vulnerabilities. Importing this XML workaround will activate the protections immediately and does not require any downtime for the VPN system. This workaround will block requests that match the following URI patterns:

^/+dana/+meeting
^/+dana/+fb/+smb
^/+dana-cached/+fb/+smb
^/+dana-ws/+namedusers
^/+dana-ws/+metric

Note that installing this workaround will block the ability to use the following features:

  • Windows File Share Browser
  • Pulse Secure Collaboration
  • License Server

Instead of using the workaround to protect a PCS that is being used as a license server, we recommend updating such systems to PCS 9.1R11.4. If this is not possible, restrict which IP addresses are allowed to communicate with the system.

Run the PCS Integrity Assurance utility

A PCS administrator should run the PCS Integrity Assurance utility to help determine if a system has evidence that it has been compromised. Please be aware of two limitations of this tool:

  1. Upon completion of the Integrity Assurance tool, the PCS device will automatically reboot.
  2. Because running the Integrity Assurance tool relies on the use of the administrative web interface of the PCS device itself, it is reasonable to assume that it may be possible for a compromised device to display misleading results.

Enable Unauthenticated Request logging

By default, PCS devices do not log unauthenticated web requests. Additionally, the administrative interface for a PCS device will warn that: Selecting this can quickly fill up User access log space in case of attack.

Because this vulnerability is exploitable via an unauthenticated request to the PCS, evidence of exploitation may only be present if the “Unauthenticated Requests” logging option is enabled. Enable this feature in the PCS administrative web interface by visiting:
System -> Log/Monitoring -> User Access -> Settings
and enabling the “Unauthenticated Requests” option.

Enable remote logging

Attackers who have compromised a PCS device may delete on-device logs in the process. For this reason, configure a remote Syslog server to ensure that PCS log entries are not modified or deleted.

Acknowledgements

This vulnerability was publicly reported by Pulse Secure with additional details and context published by Fireye.

This document was written by Chuck Yarbrough and Will Dormann.

Continue reading VU#213092: Pulse Connect Secure contains a use-after-free vulnerability

Posted in Uncategorized

VU#240785: Atlassian Bitbucket on Windows is vulnerable to privilege escalation due to weak ACLs

Overview

Atlassian Bitbucket on Windows fails to properly set ACLs, which can allow an unprivileged Windows user to run arbitrary code with SYSTEM privileges.

Description

The Atlassian Bitbucket Windows installer fails to set a secure access-control list (ACL) on the default installation directory, such as C:\Atlassian\Bitbucket\. By default, unprivileged users can create files in this directory structure, which creates a privilege-escalation vulnerability.

Impact

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

Solution

Apply an update

This issue has been addressed in the Bitbucket Windows installer for versions 7.10.1, 7.6.4, and 6.10.9. Please see https://jira.atlassian.com/browse/BSERV-12753 for more details.

Acknowledgements

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

This document was written by Will Dormann.

Continue reading VU#240785: Atlassian Bitbucket on Windows is vulnerable to privilege escalation due to weak ACLs

Posted in Uncategorized

VU#466044: Siemens Totally Integrated Automation Portal vulnerable to privilege escalation due to Node.js paths

Overview

Siemens Totally Integrated Administrator (TIA) fails to properly set the module search path to be used by a privileged Node.js component, which can allow an unprivileged Windows user to run arbitrary code with SYSTEM privileges. The PCS neo administration console is reported to be affected as well.

Description

Siemens TIA runs a privileged Node.js component. The Node.js server fails to properly set the module search path. Because of this, Node.js will look for modules in the C:\node_modules\ directory when the server is started. Because unprivileged Windows users can create subdirectories off of the system root, a user can create this directory and place a specially-crafted .js file in it to achieve arbitrary code execution with SYSTEM privileges when the server starts.

Impact

By placing a specially-crafted JS file in the C:\node_modules\ directory, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Siemens TIA or PCS neo administration console software installed.

Solution

Apply an update

This issue is addressed in TIA Administrator V1.0 SP2 Upd2. PCS neo administration console users should apply the mitigations described in Industrial Security in SIMATIC PCS neo.

For more details see Siemens Security Advisory SSA-428051.

Acknowledgements

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

This document was written by Will Dormann.

Continue reading VU#466044: Siemens Totally Integrated Automation Portal vulnerable to privilege escalation due to Node.js paths

Posted in Uncategorized