OpenSSL Remediation Checklist

As you are probably aware, the security world collectively starting holding their breath on October 25th, when the OpenSSL project announced that an important security fix on the way in order to fix a critical security vulnerability in the open source cryptographic library that’s widely used across a range of commercial and in-house applications to provide encryption, security and privacy capabilities.

Finally, today, the OpenSSL project published details on the two vulnerabilities which were downgraded from “critical” to “high”. The OpenSSL vulnerabilities can be tracked as CVE-2022-3602 (remote code execution) and CVE-2022-3786 (Denial of Service). They are both categorised as buffer overflow vulnerabilities, which are typically hard to exploit and require specific exploits per target application. This is good news, as it means the likelihood of mass exploitation attempts of clients/servers using the vulnerable OpenSSL 3.0 library is pretty low. That said, "pretty low" is not a guarantee, and we highly recommend you upgrade to OpenSSL 3.0.7 to minimize the risk window as fast as possible.

‍

How to Find and Fix OpenSSL 3.0 Vulnerabilities

To help you streamline your internal remediation process as much as possible, DevOcean has created this easy-to-follow 10 step OpenSSL Remediation Checklist:

1. Find all vulnerable OpenSSL Instances

Map all of your in-house and third-party applications that are running impacted versions of OpenSSL. The Dutch Nationaal Cyber Security Centrum (NCSC-NL) has created a list of software (un)affected by the vulnerabilities. Check it out to see whether you are using some of the affected software.

2. Assess the Impact

‍Once you’ve created an inventory of vulnerable cloud assets, create a plan for remediation by prioritizing the vulnerable critical assets that carry the most impactful risks. You should prioritize assets in the following order:

1. Publicly exposed assets
2. Mission-critical assets (e.g. workloads that have access to sensitive resources)
3. Second hop (assets with high-privileges or lateral movement paths)

3. Collaborate with Developers

‍Have a clear process in place for communication between security and development teams. Map impacted assets to owners, identifying which team is responsible for which remediation tasks - which can sometimes be difficult in cloud-native environments  with fragmented infrastructure ownership.

4. Upgrade to OpenSSL v3.0.7

Once you have identified and prioritized the assets containing OpenSSL 3.x, it is advisable to upgrade to OpenSSL 3.0.7 which is available for download via HTTPS and FTP from the following master locations:

1. https://www.openssl.org/source/    
2. ftp://ftp.openssl.org/source/

5. Patch 3rd Party Software

Follow the steps provided by your 3rd party software vendor to fix and mitigate the OpenSSL vulnerability. In some cases, manual actions may be required.

6. If Patching isn’t Available

In cases where patching isn’t possible,e.g. when the OpenSSL is part of commercial/vendor provided software and the vendor hasn’t issued an update yet, you should segment the servers running that software to avoid propagation to the entire network. Adding NGINX or other proxies that do not use open SSL 3.X will reduce the attack until all of the applications are fully patched.

7. Disable TLS Client Authentication

Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication. If you are operating TLS servers, you should consider disabling TLS client authentication until fixes can be applied.

8. Test Your Work

Perform continuous testing of suspected assets for the vulnerability, including in-house apps. Plan for this process to continue for years as this vulnerability is in a ubiquitous open source technology.

9. Maintain Cloud-App Asset Inventory

To make sure you are prepared for any future security events, keep an asset inventory of all your applications, repositories and packages in the cloud and document how they are connected to each other, so you can quickly identify affected assets and prioritize remediation efforts on the ones that are at the greatest risk.

‍

10. Manage OpenSSL Remediation with DevOcean

DevOcean’s Cloud Remediation platform helps teams identify, prioritize and fix assets impacted by vulnerabilities like OpenSSL. For more information on using DevOcean in your organization, please click here.  

‍