The OpenSSL project team recently patched two buffer overflow vulnerabilities that affect 3.0.0 through 3.0.6 releases of  OpenSSL. These vulnerabilities exist within X.509 certificate verification (specifically within name constraint checking logic) and affect both client and server side applications. Attackers can exploit these vulnerabilities to cause a denial-of-service by crashing applications/services (CVE-2022-3786, CVE-2022-3602) or potentially achieve remote code execution (CVE-2022-3602). The OpenSSL project team fixed these vulnerabilities in OpenSSL 3.0.7. OpenSSL 1.x versions do NOT contain these vulnerabilities.

Is runZero affected by these OpenSSL vulnerabilities?

The runZero platform does not use OpenSSL. The runZero operations team is ensuring that appropriate updates and mitigations are being rolled out to all of our supporting systems, including endpoints, infrastructure, and supporting services.

What are the details around these vulnerabilities?

The OpenSSL project team put together a thorough blog post that covers the details.

How to find vulnerable OpenSSL 3.0.x in your network

You can use runZero to discover vulnerable 3.0.x versions of OpenSSL in your environment. We shipped initial support for remote OpenSSL version detection in runZero version v3.2.6 on Sunday, October 30th, and scans run by our SaaS users after this time will report OpenSSL in the software inventory along with the version number when possible. Self-hosted users can enable this feature by applying the v3.2.6 (or later) update and rescanning their environment. In both cases, the runZero Explorer will be automatically upgraded as needed before the scan is launched.

After your scans complete, you can find assets running OpenSSL endpoints using the query: product:openssl. This query also works for the services and software inventory.

The server-side exposure only applies to services that process client certificates. This is not a common configuration, but runZero already performs checks for it. To identify services running OpenSSL 3.0.x variants that may be vulnerable to exploitation, use the query _service.product:"OpenSSL:OpenSSL:3" AND tls.requiresClientCertificate:"true" in the service inventory search.

The runZero scanner will reliably detect OpenSSL 3.0.x versions on any TLS-enabled ports identified during a normal scan. This includes both 3.0.x and 1.1.x OpenSSL versions when TLS-enabled service uses either TLS 1.2 or 1.3. The current fingerprints handle protocols that expose TLS directly. STARTTLS and additional service support are due in the near future.

What is the impact of these vulnerabilities?

The two issues are in the punycode parsing function used to process email addresses within certificates. Punycode is a way to transform a domain name using a non-ASCII character set into a standardized label. Punycode formatting can also convert emoji unicode characters into usable domain names. For example, ☃.net is encoded as xn--n3h.net.

Both client and server applications using OpenSSL 3.0.x include the vulnerability. Exploitation requires presenting a malicious certificate to the application. This only occurs after certificate validation, which is a mitigating control, in theory. Unfortunately, some applications disable certificate validation, either entirely (in insecure mode) or via a custom validator in the application.

To attack an exposed service:

1. An attacker would need to present a client-side certificate that triggers this issue, and
2. The server would need to have client certificate authentication enabled.

Even under these conditions, the client certificate would either need a valid signature or the application would need to be configured to skip validation. The number of applications that meet these requirements vary from organization to organization.runZero automatically checks for the use of both OpenSSL 3.0.x and client-side certificate support (tls.requiresClientCertificate) by default.

The client-side scenario may be harder to solve. Utilities like curl and wget, system update frameworks like apt and yum, and other client-side applications, may be impacted if they disable certificate validation. Some scripts may disable validation (e.g., using curl -k) to work around missing root certificates. The script can validate the hash of the received file, but still potentially exposes the script’s host to attack by a server presenting a malicious certificate with a punycode email address attribute.

Servers that make outbound calls to other HTTP endpoints (e.g., APIs and webhooks) also fall under this client-side scenario. Finding these embedded client-side instances are trickier, since every binary on every platform is suspect until proven otherwise. While many applications use the system library for OpenSSL, quite a few also statically link the library. These instances must be individually patched even if the system libraries are up-to-date.

How to respond

First things first: identify any externally exposed network services using OpenSSL 3.0.x that support client certificate authentication. This is the most likely scenario for remote exploitation today. runZero Enterprise customers can use our hosted scan engines to quickly scan their externally-facing assets.

Next, categorize internal services using OpenSSL 3.0.x and leverage existing software inventory capabilities (like the SentinelOne and Miradore integrations in runZero) to make a list of systems that use OpenSSL 3.0.x. Ensure that these systems are configured to receive frequent updates. Spot check that updates are applied once available.

Finally, identify third-party, statically-linked applications that might be using OpenSSL. There is great work happening with YARA rules that can help.

How to remediate

Thorough remediation of this vulnerability requires:

• Shifting all applications/services that use vulnerable OpenSSL 3.0.x software to OpenSSL 3.0.7.
• Deleting all files associated with vulnerable OpenSSL 3.0.x software, to ensure nothing attempts to use them.

You can accomplish the above by doing the following per asset:

• Update system and non-system OpenSSL 3.0.x libraries to 3.0.7.
• Update installed a
  pplications that are statically linked to (or are packaged with) a vulnerable OpenSSL version.
• Ensure older files associated with vulnerable OpenSSL 3.0.x versions are gone.

If your organization maintains applications or services which use OpenSSL:

• Rebuild applications/services that statically link to a vulnerable OpenSSL 3.0.x version to link with 3.0.7.
• Rebuild applications/services that repackage or specify a vulnerable OpenSSL 3.0.x version.

Software developers might also consider switching to a non-vulnerable TLS implementation, including the older OpenSSL 1.1.x branch, the LibreSSL project, or the BoringSSL project.

How to mitigate

If remediation in the near term is not an option, doing one of the following can help reduce your attack surface:

• Disable TLS client authentication for services using a vulnerable OpenSSL version that have it enabled.
• Stop running applications/services that use a vulnerable OpenSSL version (e.g., sshd, httpd, etc.).
• Use access control rules in your firewalls or routers to block access to ports associated with services that use a vulnerable OpenSSL version on affected assets.
• Disconnect from the network (or power down) devices that have services/applications/OSes using a vulnerable OpenSSL version.

Mitigation should be considered a temporary measure until remediation is possible.

How to stay on top of these vulnerabilities

Many individuals and organizations are compiling information on software affected by these OpenSSL vulnerabilities. See our Acknowledgements section below for links to those resources.

Acknowledgements

• Thanks to the OpenSSL team for all of their work, including the excellent blog post
• Thanks to SANS Internet Storm Center for reporting affected operating systems.
• Thanks to Royce Williams for his extensive lists of affected software.
• Thanks to National Cyber Security Centrum (NCSC-NL) for centralizing techniques to discover OpenSSL 3.0.x and affected/unaffected software lists.