Abstract:
The OpenSSL Project development community released vulnerability information on October 25th, 2022, regarding a pair of Denial-of-Service vulnerabilities in its 3.0.0 – 3.0.6 versions of the OpenSSL platform. On November 1st, 2022, the OpenSSL development community released a remediated version of OpenSSL (3.0.7) and advised all affected users and platforms to remediate the vulnerabilities in alignment with their tolerances and standards for remediated vulnerabilities categorized as “High Severity.”
Key Executive Communication Points:
- Security researchers have identified a weakness in a widely adopted encryption enablement solution that poses a severe threat to system availability if used against an organization
- The vulnerability allows attackers to reduce or definitively remove the availability of applications and infrastructure that use the affected version of the software
- Researchers have indicated that Availability is the primary impacted attribute and have not recognized impacts on data Confidentiality or Integrity related to this specific vulnerability
- A patch has been released by the development community which resolves the identified weaknesses, and application of the patch outside of standard patch cycles has been emphasized by a substantial number of industry experts
- Executives may recall the “Heartbleed” vulnerability in 2014. Similar to those circumstances, the affected platform is leveraged by many widely-adopted product suites (Cisco, Juniper, VMware, etc.) implemented at enterprise-class organizations – Stakeholders should partner with their critical vendors and partners to understand whether they’re affected and how they’re addressing this matter
Situation Report:
- Who: The OpenSSL Project, an open source project developing and maintaining the widely adopted software suite “OpenSSL,” has acknowledged and taken action to resolve a pair (2) of vulnerabilities identified in the OpenSSL product.
- What: Security researchers identified a pair of buffer overflow vulnerabilities in the OpenSSL software project which attackers can trigger in X.509 certification verification, specifically in name constraint checking, to enable a Denial of Service (DoS) attack in an affected implementation. The vulnerabilities are defined in CVE-2022-3602 and CVE-2022-3786.
- When: The issue, identified on Tuesday, October 25th, 2022, in a Product Release Bulletin, has received numerous media releases over the last week culminating in a series of updates published by the OpenSSL Project team on November 1st, 2022.
- Where: OpenSSL has identified product versions 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, and 3.0.6 as affected. Subsequently, OpenSSL has released a patch version of OpenSSL 3.0.7 to resolve both of the noted vulnerabilities. Security staff will want to focus not only on their own implementations but those of their critical vendor partners as well. Platforms such as Cisco, VMWare, Juniper, and others leverage OpenSSL in their product lines and will mutually require patch applications in a risk-based prioritization.
- Why: The vulnerabilities resolved in the latest OpenSSL patches focus on impacting the Availability (See CIA Triad) of an application’s operating infrastructure leveraging X.509 certificate services. Current research has not indicated that the Confidentiality or Integrity of data is affectable when exploiting this vulnerability.
- How: As noted by CVE.org: An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.’ character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
Recommendations/Action Plans:
Remediation of vulnerabilities within an affected environment should follow a predictable, defined, and structured vulnerability and patch management process. If your organization maintains such a program, leveraging this program to resolve this vulnerability as quickly as possible is advisable. In the absence of such a program, the following means should be considered as you address this threat posed to your organization. In either context, considering key points throughout this advisory to optimize your approach will serve your organization well in leveraging security as a business enabler.
Triage:
- Identify Affected Systems – Leveraging vulnerability scanning tools (Tenable, Rapid7, Qualys, etc.), asset inventories (you may have multiple), and public scanners (Qualys’ SSL Labs, PenTestTools, etc.) will enable you to identify affected assets in your environment to which the remediation patch (SSL 3.0.7) should be applied.
- Patch Systems As Soon As Possible – Partner with your business owners and stakeholders to identify a patch window that offers risk remediation in the timeliest manner; this may occur before or in alignment with your next standard patching cycle, given that most organizations center their patch cycles around Microsoft’s “Patch Tuesday.”
- Alternate Patching Methods – In addition to patching known systems with this vulnerability, it is recommended to update Next Generation Firewalls (NGFWs) and Intrusion Detection and Preventions Systems (IDPS) with detection/prevention signatures to mitigate risk to unknown systems or systems that do not have a patch readily available. It is essential to test these signatures before preventing traffic with them.
- Take a Risk-Based Approach – Partner with your business to understand the true risk posed to your organization. Consider the attack vectors posed by the threat, the architecture/design of your affected systems, the impact to the business to patch and refresh the services leveraging OpenSSL and the impact those actions may have on business operations, and perhaps most importantly, consider the compensating controls already present in your business which may be appreciably reducing the market-standard vulnerability risk rating assigned to these vulnerabilities.
- Adhere To Your Corporate Policies Where Available– Where corporate vulnerability and patch management policies, standards, processes, and guidelines already exist, use these as cornerstones to modeling your approach for this remediation tracking. These are policies that articulate the risk tolerance of your business, define the level of resourcing your organization is comfortable assigning to such matters, and define established intake and operational execution pathways that your organization is best equipped to leverage during the vulnerability management process.
Safeguard:
- Compensatory Controls – Search, inventory, and assess any compensatory controls which may already be working to reduce/mitigate your organization’s risk to this vulnerability. Your organization has invested significant cost, effort, and focus on implementing controls that broadly reduce risk to your organization – Do not fail to recognize the value and effectiveness of your organization’s investments as you work to evaluate the “True Risk” posed to your organization.
- Administrative Actions – Work with available resources to provide use-specific monitoring for critical systems or highly-exposed systems which are affected by the vulnerability as your organization progresses throughout the vulnerability remediation process. This may include critical application health checks, focused monitoring by a dedicated monitoring group (e.g., NOC, SOC, etc.), or similar focused-attention efforts to ensure the continuity of business-critical applications and assets.
- Communication Plans – Communicate openly and transparently with your affected stakeholders and relevant external agencies (e.g., Law Enforcement, Auditors, etc.) in a manner that is, ideally, already defined by your organization. In the absence of already-defined communication plans, work with your stakeholders to identify a tolerable cadence and make a note in your After-Action Review to establish a standard post-event.
Learn:
- After-Action Review – Following remediation of the vulnerability on affected systems, a focused After-Action Review of your organization’s response capabilities is advisable to recognize areas for process improvement and optimization. Specific categories of concern may include, but should not be limited to, asset and application inventory capabilities, resource readiness, threat intelligence response timeliness, scanning and reporting capabilities, and communication effectiveness.
- Artifact Updates – Following a constructive After-Action Review, your organization’s governance function should work to identify any artifact updates necessary to resolve any identified inefficiencies in your incident response process(es).
Additional Information:
There are many public resources available to assist. Besides the FBI, InfraGard, and IT-ISAC, the US Cybersecurity & Infrastructure Security Agency (CISA) is an excellent resource for all companies across the public and private sectors. CISA’s Shields Up campaign emphasizes that every organization must prepare, detect, respond, and mitigate the impact of attacks. Shields Up includes timely updates, guidance for all organizations, recommendations for CEOs and leaders, ransomware response, and even free tools and steps to protect yourself and your family.
Speak With Our Experts:
At EVOTEK, we have seasoned security practitioners and advisors who can help assess specific risks and advise on risk mitigation strategies and tactical steps to counter and respond to cyber threats. Be sure to reach out to info@evotek.com for more information.
