On December 8, 2024, the U.S. Treasury Department suffered a cyberattack. CISA announced that China-sponsored hackers had breached the Treasury network and stolen unclassified documents. The attackers exploited a Zero Day critical vulnerability in the Beyond Trust application.
Apparently, this was a Zero Day vulnerability because Beyond Trust had not publicly announced the vulnerability when the attack occurred. Eight days later, Beyond Trust announced CVE-2024-12356. Since this was a state-sponsored attack, it is very difficult to prevent a Zero Day attack because even the vendor was unaware of the vulnerability.
Figure 1 – Beyond Trust CVE-2024-12356
What is a Zero Day Vulnerability?
A zero-day vulnerability is a security flaw in software or firmware that is unknown to the vendor. Because it is undiscovered or not yet publicly disclosed, there are “zero days” available to mitigate or patch the vulnerability before it can be exploited.
Breaking Down the Vulnerability
The vulnerability, detailed under Advisory ID BT24-10, affects all versions of PRA and RS prior to version 24.3.1. CVSS score of 9.8 out of 10 being the worst, shows how this is such a critical vulnerability. The reason is that it is exploitable over the network with no authorization required. When prioritizing Common Vulnerabilities and Exposures (CVEs), there are three specific indicators plus the next hop to determine the urgency of addressing a vulnerability.
- Attack Vector (AV:N)
- Attack Complexity (AC:L)
- Privileges Required (PR:N)
I cover the most important aspects of a vulnerability rating in my book CISO Guide to Cyber Resilience. One of the key metrics to consider in a CVSS score is the Attack Vector (AV). The Attack Vector metric describes an attacker’s method to access the vulnerable asset. An attack vector labeled “N” denotes a network-based attack, which means the vulnerability can be exploited over the internet. This type of vulnerability is also known as a remote code execution (RCE) flaw.
For instance, if your company operates an externally facing web server with a network-exploitable vulnerability, it is critical to patch the server immediately. Such an asset effectively becomes a ticking time bomb, vulnerable to discovery and exploitation by hackers.
The next CVSS metric – Attack Complexity (AC), pertains to the external conditions that must be met for an attacker to successfully exploit a vulnerability. Essentially, the attack complexity classifies whether the vulnerability can be easily be exploited by a less-experienced hacker (AC:L). The easier it is to exploit the vulnerability, the lower the skill level of a hacker needed to exploit it.
The CVSS metric – Privileges Required, is based on the privileges required to carry out an attack and leverage the vulnerability. In this case with a “N” (PR:N), no privileges are required to exploit the vulnerability. The attacker does not need to be signed in or have access to the system’s settings or files to initiate the attack.
These three indicators together (AV:N), (AC:L), (PR:N) mean this is an easily exploitable vulnerability from the internet. Other important aspects to take into consideration is the location and next hop of the device. For example, if the vulnerable device is externally visible on the internet, then it needs to be patched immediately or follow CISA’s known exploitable vulnerability (KEV) catalog guidance. CISA gives recommended dates to patch actively exploited vulnerabilities.
Back to the Treasury Breach
The Treasury department’s identity and access management system, Beyond Trust was compromised. What happened is that a critical vulnerability CVE-2024-12356 was exploited to gain unauthorized access to the Treasury’s network.
Through a malicious client request, attackers could execute operating system commands in the context of the site user. This flaw created a backdoor for hackers, enabling unauthorized access to sensitive Treasury workstations. As we learned above, there was no account or password required to exploit the vulnerability.
Lessons Learned
Because this was a Zero-Day exploit, there was no patch to apply. What this does highlight is that Regular penetration testing should be completed not just on production systems, but while the product is in development. I am a strong advocate of DevOps having a separate Penetration Team that is embedded in DevOps, but reports to the Information Security Team. This also highlights CISA’s new Secure by Design initiative. All software development firms need to be doing more robust quality assurance testing before code is published to production. In general, I think that quality assurance teams are not given the budget, adequate time, or influence to ensure that quality secure code is being released. DevOps managers are pressured to meet unrealistic release dates, rather than quality code. You can see in the chart below from cvedetails.com, the massive problem with vulnerabilities that has only gotten worse in the past few years.
Figure 2 – Courtesy of https://cvedetails.com
Moving Forward
The U.S. Treasury attack is a stark reminder of the risks posed by unpatched vulnerabilities in critical systems. CVE-2024-12356 should serve as a wake-up call for federal agencies and private organizations alike to prioritize cybersecurity, implement rigorous vendor assessments, and stay ahead of emerging threats.
Preventative Steps for Organizations
To prevent similar attacks, organizations should:
- Conduct Continuous Monitoring: Use advanced intrusion detection and prevention systems (IDS/IPS) to identify and mitigate anomalies in real-time.
- Conduct Regular Manual Penetration Tests: Use a reputable Penetration Company to conduct manual penetration tests on your SaaS Service. For such a high security SaaS as Beyond Trust, quarterly manual penetration tests should be conducted.
Conclusion
CVE-2024-12356 should serve as a wake-up call for federal agencies and private organizations alike to prioritize cybersecurity, implement rigorous vendor assessments, and stay ahead of emerging threats. Especially, software development companies need to put an emphasis on quality assurance and tie Key Performance Indicators (KPI) to vulnerabilities for DevOps all the way to the CEO. This should be a wakeup call to all software development companies that quality assurance is paramount and more important than meeting release dates. Until we get the software vulnerabilities under control, the attackers are at a great advantage.
About the Author
Debra Baker, CEO of TrustedCISO, is a seasoned cybersecurity leader with over 30 years of experience, including a distinguished career in the U.S. Air Force and senior roles at IBM and Cisco. As the CEO of TrustedCISO, she provides expert guidance in strategic cybersecurity, risk management, and compliance. Debra helps organizations tackle complex frameworks such as SOC 2, ISO 27001, FedRAMP, StateRAMP, and NIST. A CISSP and CCSP-certified professional, she also holds a provisional patent for an AI-powered vendor assessment tool. Founder of Crypto Done Right and recognized among the Top 100 Women in Cybersecurity, Debra is also the author of A CISO Guide to Cyber Resilience: A how-to guide for every CISO to build a resilient security program. Her book is available for purchase on Amazon.
