It happened again. Another software supply chain attack distributing malware to many customers.
3CX’s VoIP platform is widely used by businesses of all sizes worldwide. The company’s website shows that 3CX has over 250,000 customers in over 190 countries (including Mercedes Benz, McDonald’s, BMW, Holiday Inn, the NHS, American Express, Coca-Cola, and Air France). Researchers and security auditing teams are still looking into exactly what happened with the 3CX attack, but initial reports indicate a reasonably extensive breadth of compromised targets.
While Mandiant’s investigation is ongoing, they now have a much better understanding of the attack, which proposes an eventual compromise of 3CX’s CI/CD environment.
In the worst-case scenario, this attack results in malicious code spreading to hundreds of thousands of your customers. It is every CEO’s and CISO’s nightmare. I’ve been there — I was on the frontlines of the SolarWinds’ attack at Microsoft.
A software supply chain attack that leads to a software supply chain attack
Mandiant identified that the source of 3CX’s internal network compromise began in 2022 when an employee installed the Trading Technologies X_TRADER software on their personal computer.
The X_TRADER software was also under a software supply chain attack in early 2022. Although the X_TRADER installation software was digitally signed by a valid code signing certificate and downloaded from the Trading Technologies website, it contained VEILEDSIGNAL malware, which enabled the threat actor to initially compromise and maintain persistence on the employee’s personal computer. The software was reportedly retired in 2020 by Trading Technologies. However, it was still available for download on the Trading Technologies website in 2022.
Lateral Movement
The initial compromise of the employee’s personal computer was using VEILEDSIGNAL malware, a fully-featured malware that provided the threat actor with administrator-level access and persistence to the compromised system.
Mandiant assesses the threat actor stole the employee’s 3CX corporate credentials from his system. The earliest evidence of compromise uncovered within the 3CX corporate environment occurred through the VPN using the employee’s corporate credentials two days after their personal computer was compromised.
CI/CD Build Environment Compromise
Mandiant’s investigation reconstructed the threat actor’s steps through the environment as they harvested credentials and moved laterally. Eventually, the threat actor was able to compromise both the 3CX build environments (MAC/Windows) and finally inject malicious code into the company’s electron desktop application.
Why Didn’t SCA, SAST, and DAST Tools Detect This?
Software vulnerabilities aren’t the whole picture. Traditional code analysis and testing tools are valuable for application security. However, these tools are more oriented toward spotting vulnerabilities than malicious code. This distinction is vital because vulnerabilities are usually the result of human error, whereas malware is introduced intentionally.
A bit of a break-down:
- SCA (Software Composition Analysis) is a security practice that outlines which 3rd party components are used in your software (source or binary). The critical thing with traditional SCA is that its analysis finds known vulnerabilities and misses the extra mile today’s attackers are willing to go to access your software supply chain.
- SAST (Static Application Security Testing) solutions are designed to detect security flaws, vulnerabilities, and poor code quality in your own uncompiled code. SAST misses backdoors, malware, or other malicious intent introduced into the development process via modern software supply chain attacks.
- DAST stands for Dynamic Application Security Testing, a type of security “black-box” testing used to identify applications’ security flaws while running. DAST simulates automated attacks on an application, mimicking a malicious external attacker. The goal is to find outcomes or results that were not expected (e.g. – sql injection) and could therefore be used by attackers to compromise an application. In cases like this attack, where a malicious code is injected into the software, it’s not a matter of input/output, rather than a compromised code that has been injected into the software and will be executed by definition.
Removing Supply Chain Blind Spots
Any UNKNOWN malicious code introduced into your software by either abusing your software supply chain or abusing one of your dependencies’ software supply chain will ultimately reach your software and your customers. You need to be able to detect that malicious code, whether it’s in your source code, your dependencies’ source code, your binaries, or your dependencies’ binaries. These different supply chain layers can be breached with custom unknown malicious code, leaving you blind to it.
If SAST, DAST, and SCA Have Gaps — What Do I Do?
You need a new core capability to succeed against supply chain attacks that target the transitive risk inherent in your source and binaries. You must be able to identify an actual breach in real time before it reaches production or, even worse, your customers.
- Gain visibility into your development environments, tools, SDKs, and 3rd party dependencies from a single pane of glass.
- Third-party code you didn’t intend to have in your software must be detected and prevented from moving through your software supply chain in real time. You need to be able to attest to all the dependencies hierarchy you use, not only those YOUR product used directly.
- 3rd Party Packages should be selected because they are innocent and do their job, not because of random scoring mechanisms that might eventually allow a compromised package to enter your environment.
- Eventually, after checking your inherited supply chain, you must ensure that your build process is not compromised too.
In summary: You must ensure that “what you bring home” or share with others doesn’t contain malicious code and that there are no blind spots in your software supply chain.
Easy right?
It’s not. I can tell you because we’ve built that technology, and it’s freaking hard.
If you like to learn how we solve this problem, visit us at www.myrror.security or contact me directly, I’m always happy to talk.
A BIG THANKS TO MANDIANT FOR THE THOROUGH AND DETAILED REPORT.
