CERT/CC

Overview

HCC Embedded's software called InterNiche stack (NicheStack) and NicheLite, which provides TCP/IP networking capability to embedded systems, is impacted by multiple vulnerabilities. The Forescout and JFrog researchers who discovered this set of vulnerabilities have identified these as "INFRA:HALT"

Description

HCC Embedded acquired NicheStack from Interniche in order to provide TCP/IP protocol capabilities to lightweight devices such as IoT. NicheStack has been made available since late 1990's to a widely varied customer base in multiple forms to support various implementations. This has made NicheStack to be part of a complex supply chain into major industries including devices in critical infrastructure.

Forescout and JFrog researchers have identified 14 vulnerabilities related to network packet processing errors in NicheStack and NicheLite versions 4.3 released before 2021-05-28. Most of these vulnerabilities stem from improper memory management commonly seen in lightweight operating systems. Of these 14 vulnerabilities, five involve processing of TCP and ICMP (OSI Layer-4 protocols) and the rest involve common application protocols such as HTTP and DNS (OSI Layer-7). The processing of these OSI layers involve a number of boundary checks and some specific "application" processing capabilities (such as randomization) commonly overlooked in development of lightweight networking software.

Various stakeholders, including HCC Embedded, have made attempts to reach impacted vendors to provide software fixes that address these issues. A lack of formalization of software OEM relationships and a lack of Software Bill of Materials (SBOM) has complicated this outreach and the much-needed identification of impacted devices.

Impact

The impact of exploiting these vulnerabilities will vary widely, depending on the implementation options used while developing embedded systems that use NicheStack or NicheLite. As these vulnerabilities involve processing of network packets, attackers can generally abuse these errors via remote network access. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, or in some cases be able to execute arbitrary code on the target device.

Solution Apply updates

The most reliable way to address these vulnerabilities is to update to the latest stable version of NicheStack software mentioned in HCC Embedded mentioned in their Security Advisories. If you are unsure or have discovered NicheStack using open-source tools provided by Forescout, reach out to HCC Embedded via their PSIRT security team or to your upstream vendor in your supply chain to obtain the software fixes. HCC has also provided a register to be notified web page for sustaining this outreach for their long-standing customers.

Block anomalous IP traffic

CERT/CC recognizes that many implementations of NicheStack involve longer lifecycles for patching. In the meantime, if feasible, organizations can consider isolating impacted devices and blocking network attacks using network inspection, as detailed below, when network isolation is not feasible. It is recommended that security features available to you in devices such as router, firewalls for blocking anomalous network packets are enabled and properly configured. Below is a list of possible mitigations that address some specific network attacks that attempt to exploit these vulnerabilities.

• Provide DNS recursion services to the embedded devices using recursive DNS servers that are securely configured, and well-maintained with patches and updates.
• Provide HTTP access to embedded devices that are in an isolated network via securely configured HTTP reverse proxy or using HTTP deep packet inspection firewalls.
• Filter ICMP and TFTP access to embedded devices from the wider Internet and use stateful inspection of these protocols when accessible to wider Internet to avoid abuse.
• Enforce TCP stateful inspection for embedded device and reject malformed TCP packets using router, firewall features as available to the operational environment.

When blocking or isolating is not an option, perform passive inspection using IDS that can alert on anomalous attempts to exploit these vulnerabilities. See also our recommendations and IDS rules that were made available for Treck TCP/IP stack related vulnerabilities VU#257161 for examples.

Acknowledgements

Thanks to Amine Amri, Stanislav Dashevskyi, and Daniel dos Santos from Forescout, and Asaf Karas and Shachar Menashe from JFrog who reported these vulnerabilities and supported coordinated disclosure. HCC Embedded, the primary OEM vendor, also supported our efforts to coordinate and develop security fixes to address these issues.

This document was written by Vijay Sarvepalli.

Overview

HTTP web proxies and web accelerators that support HTTP/2 for an HTTP/1.1 backend webserver are vulnerable to HTTP Request Smuggling.

Description

The affected systems allow invalid characters such as carriage return and newline characters in HTTP/2 headers. When an attacker passes these invalid contents to a vulnerable system, the forwarded HTTP/1 request includes the unintended malicious data. This is commonly known as HTTP Request Splitting. In the case of HTTP web proxies, this vulnerability can lead to HTTP Request smuggling, which enables an attacker to access protected internal sites.

Impact

An attacker can send a crafted HTTP/2 request with malicious content to bypass network security measures, thereby reaching internal protected servers and accessing sensitive data.

Solution Apply updates

Install vendor-provided patches and updates to ensure malicious HTTP/2 content is blocked or rejected as described in RFC 7540 (Section 8.1.2.6) and RFC 7540 (Section 10.3). Both "request" and "response" should be inspected by the web proxy and rejected in accordance with Stream Error Handling as described in RFC 7450 (Section 5.4.2).

Inspect and block anomalous HTTP/2 traffic

If HTTP/2 is not supported, block the protocol on the web proxies to avoid abuse of HTTP/2 protocol. Where HTTP/2 is supported, enforce strict rules for HTTP header checks to ensure malicious headers are normalized or rejected.
Checks of this type include: * HTTP Headers with invalid Header name or value * HTTP Headers with invalid or no content-length * Unsupported or invalid HTTP methods

Test and verify your web proxy

Scan your public web server proxy with OWASP recommended tests to ensure your web servers are not vulnerable to abuse via HTTP response splitting.

Acknowledgements

Thanks to the reporter James Kettle of PortSwigger for the information about this vulnerability.

This document was written by Timur Snoke.

Overview

Microsoft Windows Active Directory Certificate Services (AD CS) by default can be used as a target for NTLM relay attacks, which can allow a domain-joined computer to take over the entire Active Directory.

Description

PetitPotam is a tool to force Windows hosts to authenticate to other machines by using the Encrypting File System Remote (EFSRPC) EfsRpcOpenFileRaw method. When a system handles an EfsRpcOpenFileRaw request, it will by default use NTLM to authenticate with the host that is specified within the path to the file specified in the EfsRpcOpenFileRaw request. The user specified in the NTLM authentication information is the computer account of the machine that made the EfsRpcOpenFileRaw request.

The EfsRpcOpenFileRaw() function does not require credentials to be explicitly specified for it to be dispatched. Code running on any domain-joined system can trigger this function to be called on a domain controller without needing to know the credentials of the current user or any other user in an Active Directory. And because the EfsRpcOpenFileRaw method authenticates as the machine dispatching the request, this means that a user of any system connected to an AD domain can trigger an NTLM authentication request as the domain controller machine account to an arbitrary host, without needing to know any credentials. This can allow for NTLM relay attacks.

One publicly-discussed target for an NTLM relay attack from a domain controller is a machine that hosts Microsoft AD CS. By relaying an NTLM authentication request from a domain controller to the Certificate Authority Web Enrollment or the Certificate Enrollment Web Service on an AD CS system, an attacker can obtain a certificate that can be used to obtain a Ticket Granting Ticket (TGT) from the domain controller. This attack, known as a "Golden Ticket" attack, can be used to fully compromise the entire Active Directory infrastructure.

Although Microsoft refers to this entire attack chain as "PetitPotam" in KB5005413, it is important to realize that PetitPotam is simply the single PoC exploit used to invoke an NTLM authentication request by way of a EfsRpcOpenFileRaw request. It should be noted that:

1. There may be other techniques that may cause a Windows system to initiate a connection to an arbitrary host using privileged NTLM credentials.
2. There may be services other than AD CS that may be leveraged to use as a target for a relayed NTLM authentication request.

Impact

By making a crafted RPC request to a vulnerable Windows system, a remote attacker may be able to leverage the NTLM authentication information that is included in the request that is generated. In the case of AD CS, this can allow an attacker on any domain-joined system to be able to compromise the Active Directory.

Solution

The CERT/CC is currently unaware of a practical solution to this problem. Please see KB5005413 for several workarounds.

Enable Extended Protection for Authentication (EPA) and Require SSL on AD CS systems

Please see KB5005413 for more details about enabling EPA to help protect against this weakness. It is important to note:

1. In addition to configuring EPA through the IIS Manager GUI, the Certificate Enrollment Web Service (CES) also requires modifying the web.config file to successfully enable EPA.
2. The CES and the CertSrv applications must be configured to enable the Require SSL option for EPA protection to work. If Require SSL is not enabled, then any changes to the EPA settings will not have any effect.

Disable NTLM Authentication on your Windows domain controller

Instructions for disabling NTLM authentication in your domain can be found in the article Network security: Restrict NTLM: NTLM authentication in this domain.

Disable incoming NTLM on AD CS servers

The stage of leveraging an AD CS server to achieve the ability to get a TGT can be mitigated by disabling incoming NTLM support on AD CS servers. To configure this GPO setting, go to: Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and set Network security: Restrict NTLM: Incoming NTLM traffic to Deny All Accounts or Deny All domain accounts

Disable the NTLM provider in IIS

For both the "Certificate Authority Web Enrollment" (CES) service (<CA_INFO>-CA_CES_Kerberos in IIS Manager) and the "Certificate Enrollment Web Service" (CertSrv in IIS Manager) services:

1. Open IIS Manager
2. Select Sites -> Default Web Site (or another name if it was manually reconfigured -> *-CA_CES_Kerberos and CertSrv
3. Select Windows Authentication
4. Click the Providers... link on the right side
5. Select NTLM
6. Click the Remove Button
7. Restart IIS from an Administrator CMD prompt: iisreset /restart

Acknowledgements

The PetitPotam aspect of this attack chain was publicly disclosed by topotam. The AD CS aspect was publicly disclosed by harmj0y and tifkin_.

This document was written by Will Dormann.

Overview

A path traversal vulnerability exists in numerous routers manufactured by multiple vendors using Arcadyan based software. This vulnerability allows an unauthenticated user access to sensitive information and allows for the alteration of the router configuration.

Description

The vulnerability, identified as CVE-2021-20090, is a path traversal vulnerability. An unauthenticated attacker is able to leverage this vulnerability to access resources that would normally be protected. The researcher initially thought it was limited to one router manufacturer and published their findings, but then discovered that the issue existed in the Arcadyan based software that was being used in routers from multiple vendors.

Impact

Successful exploitation of this vulnerability could allow an attacker to access pages that would otherwise require authentication. An unauthenticated attacker could gain access to sensitive information, including valid request tokens, which could be used to make requests to alter router settings.

Solution

The CERT/CC recommends updating your router to the latest available firmware version. It is also recommended to disable the remote (WAN-side) administration services on any SoHo router and also disable the web interface on the WAN.

Acknowledgements

Thanks to the reporter Evan Grant from Tenable.

This document was written by Timur Snoke.

Overview

Starting with Windows 10 build 1809, non-administrative users are granted access to SAM, SYSTEM, and SECURITY files. This can allow for local privilege escalation (LPE).

Description

Starting with Windows 10 build 1809, the BUILTIN\Users group is given RX permissions to the following files:

c:\Windows\System32\config\sam c:\Windows\System32\config\system c:\Windows\System32\config\security

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 account: 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 Impact

By accessing a Windows 10 system's sam, system, and security files 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

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workaround:

Restrict access to sam, system, and security files and remove VSS shadow copies

Vulnerable systems can remove the Users ACL to read these sensitive files by executing the following commands:

icacls %windir%\system32\config\sam /remove "Users" icacls %windir%\system32\config\security /remove "Users" icacls %windir%\system32\config\system /remove "Users"

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, assuming that your system drive is c::

vssadmin delete shadows /for=c: /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.

Acknowledgements

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

This document was written by Will Dormann.

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 ICM files. These files, which are copied over with the digital-signature-enforced printer driver files are not covered by any signature requirement. That is, any file can be copied to a client system via Point and Print printer driver installation, where it can be used by another printer with SYSTEM privileges. This allows for LPE 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

The CERT/CC is currently unaware of a practical solution to this problem. Please 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 Microsoft indicates that printers can be shared via the [MS-WPRN] Web Point-and-Print Protocol, which may allow installation of arbitrary printer drivers without relying on SMB traffic. Also, 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 PackagePointAndPrintServerList

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.

Acknowledgements

This vulnerability was publicly disclosed by Benjamin Delpy.

This document was written by Will Dormann.

Overview

The Microsoft Windows Print Spooler service fails to restrict access to the RpcAddPrinterDriverEx() function, 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.

While Microsoft has released an update for CVE-2021-1675, it is important to realize that this update does NOT address the public exploits that also identify as CVE-2021-1675.

Exploit code for this vulnerability that targets Active Directory domain controllers is publicly available as PrintNightmare.

Impact

By sending an RpcAddPrinterDriverEx() RPC request, e.g. over SMB, a remote, authenticated attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system.

Solution

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workaround:

Stop and disable the Print Spooler service

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

Acknowledgements

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

This document was written by Will Dormann.