What Happened
U.S. Government agencies as well as many private companies were impacted by a rapidly expanding cyber attack attributed to Russian cybercriminals’ exploitation of Progress Software’s MOVEit file transfer platform. Initial attribution came from a joint cybersecurity advisory released on June 7 by the U.S. Cybersecurity and Infrastructure Agency (CISA) and the Federal Bureau of Investigations (FBI), which detailed a previously undisclosed structured query language (SQL) injection vulnerability being exploited by the Clop Ransomware Gang/TA505 as early as May 27. The vulnerability affected both the cloud and on-prem versions of the popular software. According to undisclosed sources, the LEMURLOOT web shell has been used by threat actors to access underlying MOVEit Transfer databases and perform successful data exfiltration.
Clop has released the names of 37 victims on its data-leak site. Victims span across government, financial services, healthcare, and pharma/biotech with the majority of victims being in the Northern Hemisphere. According to reports, two entities associated with Department of Energy were impacted and the personally identifiable information of potentially tens of thousands of individuals including DoE employees and contractors data was taken, though it does not appear DoE-managed systems or other internal data have been affected.
Progress Software publicly disclosed the first vulnerability (CVE-2023-34362) on May 31 and released a patch within 48 hours. On June 9, a second serious vulnerability (CVE-2023-35036) in the MOVEit software was disclosed with a patch being released the same day. This second vulnerability was also tied to SQL injection and was identified through detailed code reviews as Progress worked with third-parties to find additional vulnerabilities present in their software. On June 15, a third vulnerability (CVE-2023-35708) was disclosed, with Progress quickly patching the MOVEit Cloud instance as well as releasing a patch for the on-prem MOVEit Transfer version of their software.
Why it Matters
This attack on the U.S. Government and the commercial sector represents another example of software supply chain weaponization, where vulnerable or corrupted software is used as a stepping stone into victim environments. The 2021 Solarwinds attack was an inflection point for collective action against software supply chain subversion. Since then, a number of high-profile breaches (i.e., notPetya, Kaseya, 3CX) have further reinforced the need for product security vigilance. While the scope of the MOVEit attack is still being understood, the underlying lesson is that threat actors will continue to target widely used commercial software platforms as well as open-source software components (as shown in 2021’s Log4j critical vulnerability).
As we wrote in a recent blog on the National Cybersecurity Strategy released in March 2023, the U.S. Government is seeking to shift security accountability (and liability) to the makers of software products. As our April blog notes, CISA’s release of the Secure Software Self-Attestation Common Form formalizes the approach for organizations to document their software lifecycle security programs against the NIST Secure Software Development Framework (SSDF). Exploitation of the software supply chain, as evidenced in the MoveIT hack, will further reinforce the need for greater software security transparency, hygiene, and formalization. Earlier this month, the Office of Management and Budget issued M-23-16 which further clarifies the attestation and updates submission timelines.
What to do about it
While it is not possible to eliminate all software supply chain risk, organizations can help reduce exposure, subsequent data loss, and other serious consequences by implementing Tactical Recommendations:
- Implement vendor recommended mitigations and stop-gap measures in the dwell time between when a vulnerability is first identified and when the associated security patch can be applied. Ensure the organization’s change control processes support emergency review and approval of time-sensitive changes.
- Prioritize patching of all public-facing systems and applications.
- Maintain a comprehensive inventory of software used across the enterprise including all commercially developed applications running on-prem, in vendor-hosted environments, and by SaaS providers. Document all internally developed software to include all open-source and third-party components in use.
- For commercially-supplied software, subscribe to supplier/developer security alerts and take swift action when a new vulnerability is disclosed in a commercial product.
- Monitor the top cyber threat intelligence (CTI) sources to gain awareness of emerging software vulnerabilities for both commercial and open-source software.
Implement software security frameworks and tools: Leverage secure software development frameworks and security testing tools. Existing purpose-built secure software frameworks like the NIST Secure Software Development Framework (SSDF) and the Synopsys Building Security in Maturity Model (BSIMM) can serve as starting points for future guidance.
- Software producers can prepare for future requirements by comparing current practices against these frameworks. An SSDF gap assessment helps to understand current posture as well as readiness for future attestation against the SSDF Self-attestation Common Form.
- Non-Federal buyers should consider reflecting SSDF practices in their technology procurement process to incentivize stronger software security practices by builders.
- The MOVEit vulnerabilities further highlight the importance of third-party security testing and code reviews to find serious vulnerabilities that are not caught in internal security testing.
Achieve greater software transparency. Software producers will be expected to have a greater understanding of how their software is authored, tested, and secured. This includes maintaining an up-to-date understanding of the origin of each software component, attesting to testing outcomes and risks mitigated during testing, and employing automated processes to maintain trusted software supply chains throughout the software life cycle. In addition, a Software Bill of Materials (SBOM) offers a common framework for documenting and communicating an application’s “ingredients” to reduce code opacity, particularly for third-party and open-source components.
Build a threat-informed defense: The Chertoff Group recommends that security practitioners apply security controls based on anticipated adversary behavior and an assumption that a breach is inevitable or has likely already occurred. By understanding the anatomy of recent ransomware attacks and associated tactics, techniques and procedures (TTPs), defenders can ensure risk-based defenses are in place. The MITRE Corporation’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework can help through its library of mappings between TTPs and defensive countermeasure coverage.
Andreas Kurland is a senior associate in the Cybersecurity Strategic Advisory Services practice at The Chertoff Group. A version of this article appeared in Government Technology Insider on July 5.
