Update November 1st, 2022:
The OpenSSL project team has now released version 3.0.7 and advises users of versions 3.0.0 – 3.06 to upgrade to 3.0.7 as soon as possible. The release includes fixes for two X.509 email address buffer overflow vulnerabilities, assigned with severity ‘high’: CVE-2022-3786 and CVE-2022-3602.
CVE-2022-3602 was previously assigned the severity ‘critical’, since it was thought that it allowed remote code execution (RCE) in common configurations. When more details were published, it became apparent that this bug is unlikely to be exploitable on modern systems that implement stack overflow protections. Therefore the OpenSSL project team downgraded the vulnerability to a ‘high’ severity.
Typically, cloud environments utilize modern operation systems with stack overflow protection mechanisms, so we expect the potential danger of CVE-2022-3602 in the cloud to be limited. With regards to the cloud instances that are still using older platforms, we expect these to be using the older version 1.1 of OpenSSL that is not affected by the CVE, as OpenSSL v.3 was just released in September 2021. In short, this vulnerability is much less critical than previously thought. Nevertheless, Orca Security still recommends customers running the affected versions to upgrade to 3.0.7.
The Orca Cloud Security Platform can help you find affected packages in your AWS, Azure, Google Cloud and Alibaba Cloud environments. Take our free, no obligation risk assessment to find out which OpenSSL instances need to be upgraded to version 3.0.7.
+++
On Tuesday, October 25th, the OpenSSL project team announced that they will be releasing a new version (3.0.7) of OpenSSL on Tuesday, November 1st, 2022, between 8 am – 12 pm Eastern time, which fixes a critical vulnerability in OpenSSL (but does not affect any versions before 3.0). No details on the vulnerability are available yet, as these will be disclosed once the patch is released. OpenSSL is a toolkit to secure network communications and is widely used by Internet servers, including the majority of HTTPS websites.
OpenSSL v.3 is the current version, however many servers are still running OpenSSL v.1, which is not affected by this vulnerability. Using data scanned by the Orca Cloud Security platform, we have found that 59% of organizations are running at least one server with an affected package of OpenSSL (version 3.x). Half of these assets (52%) are Internet facing and 58% contain Personally Identifiable Information (PII).
How Critical is this Vulnerability?
Although details on the actual vulnerability are scarce, it is important to note that this is only the second time, post-Heartbleed, that OpenSSL has categorized a vulnerability as ‘critical’. OpenSSL defines an issue of critical severity as one that “affects common configurations and is also likely exploitable”. OpenSSL further lists the following examples of vulnerabilities that would be labeled as ‘critical’: “significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations”.
Unlike the Log4Shell vulnerability that was published with no forewarning, the OpenSSL team is giving defenders the chance to prepare and know which assets need patching before they publish information about the vulnerability.
OpenSSL Patching Recommendations
Even though we don’t know how severe this vulnerability is, our advice is to be prepared by doing the following:
- Know which assets are running the vulnerable versions 3.0-3.0.6 in your organization.
- Understand which assets need to be prioritized for patching: Internet-facing assets, or assets that could create an attack path to your most critical assets should always be patched first.
- If you know a critical asset will be difficult to patch, be prepared to isolate the asset – depending on the severity of the vulnerability.
- Be ready on Tuesday between 8 am – 12 pm Eastern Time to get patching.
- After patching, verify that all vulnerable assets have been updated to OpenSSL 3.0.7.
Detect Vulnerable OpenSSL Packages in Your Cloud Environment
The Orca Cloud Security Platform can help organizations find all OpenSSL vulnerable resources in their AWS, Azure, Google Cloud, and Alibaba Cloud environments by clicking on the ‘From the News’ alert in Orca’s Risk Dashboard. The Orca team will continually monitor the situation and update the alerts if needed.
Once you click on the ‘From the News’ alert, Orca will automatically query your entire cloud estate and list the number of affected assets found. Once you click on ‘See Assets’, a detailed list will be shown of all the vulnerable assets, prioritized according to the level of risk exposure, so your teams can get ready to apply the updates in order of priority.
Orca is Here to Help Protect Your Cloud Estate
First and foremost, Orca is here to help organizations protect their cloud environments against breaches. If you currently don’t have visibility into your cloud environment, we are offering a free, no obligation risk assessment. Since the Orca platform is entirely agentless, after a quick 30 minute setup, Orca will immediately start scanning your environment and return complete results within a few hours, including a list of each asset that is running the vulnerable OpenSSL versions, prioritized according to risk exposure.
About Orca Security
Orca Security provides the industry-leading agentless Cloud Security Platform that identifies, prioritizes, and remediates risks and compliance issues across your cloud estate spanning AWS, Azure, Google Cloud, and Alibaba Cloud. Orca’s platform connects to your environment in minutes and provides 100% visibility of all your assets, detecting and prioritizing cloud risks across every layer of your cloud estate.
