Recently, the cybersecurity world has been rattled by a series of critical vulnerabilities discovered in Ivanti Connect Secure VPN software. In the wake of these ongoing vulnerability issues, Ivanti has also faced criticism from members of the infosec community for its handling of vulnerability disclosures. Ivanti grouped multiple vulnerabilities under a single registered Common Vulnerabilities and Exposures (CVE) ID, rather than disclosing them as individual vulnerabilities. Juniper faced similar criticism for disclosing only two vulnerabilities instead of four.
These scenarios highlight the importance of accurate vulnerability disclosure. This article will examine how inconsistencies impact vulnerability remediation effectiveness and offer improvement suggestions.
Inaccuracies in Vulnerability Disclosures and Subsequent Risks
Vendors may choose to downplay the number of registered vulnerabilities for various reasons, such as simplifying their reporting process, minimizing public exposure of vulnerabilities, or reducing the perception of having a large number of individual vulnerabilities in their software.
However, grouping multiple vulnerabilities under a single registered CVE is a bad strategy as it makes it unclear for organizations which exact vulnerability needs to be addressed in the development cycle to resolve the CVE issue. This can result in communication problems within IT teams, leading to potential oversight of unpatched vulnerabilities. Ultimately, it complicates mitigation efforts for organizations, increases the risk of unnoticed vulnerabilities, and results in accusations against the vendor.
While Ivanti and Juniper faced public criticism, it’s worth noting that the damage from mishandling vulnerability disclosure was not critical because they did disclose vulnerabilities. However, there is an older case involving Microsoft, where a certain vulnerability was concealed, allowing threat actors to exploit it for years.
In May 2017, Microsoft silently patched the vulnerability known as “EpMo” without publicly disclosing it in 2013 when it was initially discovered. This lack of disclosure allowed APT31 (attributed to China’s Zirconium) to replicate the exploit in 2014 to form the “Jian” exploit and use it since at least 2015. The exploit was reported to Microsoft by Lockheed Martin’s Computer Incident Response Team, indicating a potential attack against American targets. The delayed disclosure enabled APT31 to exploit the vulnerability for years. This example underscores the importance of timely and transparent disclosure of vulnerabilities by vendors, as it enables users and organizations to take necessary measures to protect themselves against potential threats.
Other Issues with Vulnerability Handling
Sometimes vendors, after detecting vulnerabilities in their software, issue the upgrade while retaining the previous version’s public number. Consequently, it becomes unclear for a sysadmin whether the application in place is vulnerable or patched. Such cases often go unnoticed by the public, but they do happen. In June 2023, Dell Commander 4.9.0 was found to have CVE 2023-28071, with a NVD score of 7.1. The company released a new version internally marked as A02, but did not change the publicly available version number, which is visible in the Programs and Features view. A good practice would be to assign a new number to the updated version.
Best Practices to Disclose Vulnerabilities
When software vendors disclose vulnerabilities and assign CVEs, they should adhere to certain rules. First, they need to coordinate with CVE Numbering Authorities (CNAs), which are responsible for assigning CVE IDs and maintaining the CVE database. This ensures that the vulnerability meets the criteria for CVE assignment.
Entities discovering vulnerabilities should disclose them to relevant parties, including vendors, CERTs, and vulnerability databases, allowing vendors time to develop patches before public disclosure.
Following the designated process for requesting CVE IDs is crucial, as it requires providing accurate and detailed information about the vulnerability. When disclosing the vulnerability, vendors should provide a clear description, including its impact, affected versions, potential attack vectors, and any known mitigations. Assigning a Common Vulnerability Scoring System (CVSS) score helps quantify the severity of the vulnerability.
Errors in assigning CVE IDs are inevitable, with a resolution process involving rejection, merging, or splitting of entries. Organizations must adhere strictly to update rules, rejecting CVEs if research disproves a vulnerability, fixing typos causing misuse, or merging multiple IDs for one vulnerability. Selected CVE IDs incorporate information from others, while unselected ones are updated with rejected descriptions. Split CVE when assigning a single CVE ID when more than one is required, splitting the entry into multiple CVE entries. This is done to ensure accurate and granular identification of different vulnerabilities.
Vendors should also provide clear information about any subsequent updates if that’s applicable, such as new patches, versions or mitigations, or changes to the CVSS score.
It’s essential to conduct responsible disclosure, minimizing the risk of exploitation and prioritizing the security of affected users. Finally, vendors must ensure compliance with laws governing vulnerability disclosure practice.
Conclusion
In my opinion, vendors should not hesitate to disclose vulnerabilities with all pertinent information. They owe it to their customers to be transparent. This approach will result in more secure applications and clearer patch management processes.
About the Author
Mike Walters, President and co-founder of Action1 Corporation – managing product strategy for the company. Previously Co-CEO & Co-Founder of Netwrix Corporation, Michael was responsible for go-to-market strategy, sales and evangelism. At Netwrix Mike and Alex built a very successful cybersecurity business, and then they both left Netwrix after transition to a new CEO. Well known for its visibility and user behavior analytics platform, Netwrix became a leader with more than 10,000 customers worldwide. Mike lives in Laguna Beach, CA, and he has three kids. He is an avid surfer and philanthropist who cares about environmental protection.
Mike can be reached online at our company website https://www.action1.com/team/.