What went wrong with the 3CX software supply chain attack — and how it could have been prevented

Software supply chain attacks are happening all too frequently now, especially ones that occur due to the inclusion of malicious dependencies found in open source repositories. While this kind of supply chain attack is common, other forms of these attacks, such as targeted tampering incidents that impact the end user, are not as common, but carry a great impact as well.

In late March, the cybersecurity community was rocked by one of these uncommon software supply chain attacks, in which malicious code was added to the build process of a voice over IP (VOIP) solution’s software. 3CX, the company that was targeted, released a maliciously tampered version of their 3CXDesktopApp to its customers.

This 3CX attack carries serious weight for several reasons, and the industry is still grappling with the details on how this attack occurred and what it means for the future of software supply chain security. ReversingLabs researchers were able to use the company's Software Supply Chain Security platform to analyze what went wrong with the 3CX supply chain attack.

Here are takeaways from a recent conversation with ReversingLabs Field CISO Matt Rose and co-founder and chief software architect Tomislav Peričin about how this attack occurred — and what could have been done to prevent it.

SEE RELATED:

• Research: Red flags flew over 3CX update
• Analysis: The 3CX attack was targeted — but the plan was broader
• Webinar: Deconstructing the 3CX Software Supply Chain Attack
• Deminar: Analyzing the 3CX Software Package

The software supply chain: It's complicated

Peričin, who has been integral in leading the creation and execution of ReversingLabs Software Supply Chain Security platform, is a developer himself, making him aware of how development processes have changed in recent years. He understands how this growing complexity in software supply chains has come from advances in the continuous integration and delivery (CI/CD) processes used to make software artifacts.

However, quickened processes and more complicated builds have brought new threats to software supply chains in recent years that security teams have been ill-equipped to handle. He noted to Rose that the attack on 3CX demonstrates how multifaceted and complicated software supply chains are, leaving ample opportunity for malicious actors to tamper with various parts of the chain. There are now several areas of the software supply chain that need to be vetted and protected against threats, and for the case of 3CX, this attack occurred as a result of gaps in security coverage in all of the supply chain’s vulnerable areas.

At every single stage (of the chain) you can have a software supply chain incident, and every single stage needs to be verified.

Tomislav Peričin

In the past, software publishers and consumers only took notice of vulnerabilities found in software artifacts that could be exploited by malicious actors. While vulnerabilities are still important to detect and patch, there are at least five other aspects of the software supply chain process that need to be vetted as well, Peričin said.

Because many software teams are not held accountable to check for all of these possible threats before releasing an artifact, Peričin shared that unfortunately, users are now forced to vet software on their own. This shift in the software industry in how complex the software build process has become, along with a lack of vetting of these complex stages of the build process, has made the relationship between software publishers and consumers vulnerable.

Peričin stressed that malicious actors are aware and prepared to take advantage of this:

They (malicious actors) are after users, and if that trust gets broken, the user is going to go somewhere else.

Tomislav Peričin

With the 3CX incident, which was isolated to just the build process of 3CX’s software, malicious actors specifically wanted to target this company and its customers. And in doing so, these threat actors have been able to take advantage of the fragile trust that consumers currently have with software publishers.

Supply chain security is a big job. Use the right tools.

While a lack of security coverage for software supply chains is currently plaguing the industry, hurting both publishers and consumers, there are ways in which organizations can become more proactive and strategic in handling this problem. Much of Rose and Peričin’s conversation proved that in order to minimize software supply chain attacks, such as the one on 3CX, organizations need to reassess the tools they are using.

Software publishers for years have been using traditional application security (app sec) tooling to vet their software before release. These tools, such as static and dynamic application security testing (SAST/DAST) as well as software composition analysis (SCA), are helpful in spotting threats to software supply chains.

However, Peričin said that traditional app sec tools have aged out of the current state of software production, and don’t take into account every kind of supply chain threat that publishers should be detecting. They also aren’t equipped to handle the complexity and size of software artifacts today, which can have huge binaries that need to be fully vetted, Peričin said.

For software teams that only use these traditional app sec tools to vet their software, “you end up chasing your tail quite a bit,” said Peričin. That is because these tools track important factors like inventory and weaknesses, but miss the mark on tracking “intent” behind any changes that could be malicious, he said.

For software development teams to actually find malicious changes to their software artifacts before they’re released, modern tooling needs to be adopted, said Peričin.

You need a dedicated set of tools which understand code intent, track that intent and then triage that intent to see what kind of changes were added to the code.

Tomislav Peričin

App sec tools are evolving, and can now give software teams the ability to vet all software artifacts before release, helping to minimize the risk of supply chain attacks. And while vetting all software releases in this manner will inevitably slow down software production, Peričin said that using more comprehensive tooling and paying attention to every threat is worth it to combat the rise of software supply chain security attacks.

Special report: The State of Software Supply Chain Security 2022-23

Why now? Now is the time to take action

The industry is still trying to understand what the full impact of the recent software supply chain attack on 3CX is. However, Peričin shared that we won’t know the full consequences of this attack for weeks, maybe even months, as was the case with the SolarWinds attack, which was similar in execution to 3CX’s.

What organizations can do right now: Learn where their current gaps in coverage are and take the right steps to adopt tooling that secures all of these areas.

Organizations should start by using available resources such as the Supply-chain Levels for Software Artifacts (SLSA) framework, a checklist of security standards and protocols, as well as the U.S. Federal Government’s Enduring Security Framework, which lists best practices for the implementation of software supply chain security. Once organizations use available resources and become aware of the threats facing them, they should then take the responsibility of implementing modern tools that provide full software supply chain security coverage.

Ultimately, it is the software publisher’s responsibility to ensure that no harm can come to its users.

Tomislav Peričin