We have come to the fifth and last part of this blog series on software supply chain attacks. Previously, we discussed four notorious supply chain attack methods, Vendor Compromise, Exploit Third Party Applications, Exploit Open Source Libraries, and Dependency Confusion and provided insight into how these methods are threatening software supply chains, passing an extraordinary amount of risk downstream to the organizations and users that trust and depend on them. Today, we will discuss Hostile Takeover.
Hostile Takeover
The final common vector for supply chain attacks is the least technical – the “Hostile Takeover”. It’s another case of bad actors taking advantage of our assumptions. In many ways this is similar to the previously discussed Dependency Confusion attack and can be surprisingly effective due to the use of open-source software in nearly all applications.
A well-documented example of this type of attack happened at the end of 2018 with the “event-stream” package used by Node.js developers. The event-stream package was originally released nearly 10 years ago, is downloaded 2 million times per week, and had been faithfully maintained by its original owner for many years.
Open source projects are typically maintained by the original developer and perhaps a small group of contributors altruistically and in their free time. Contributing to the betterment of the community and some recognition is the reward but it can be a thankless job.
After many years of handling feature requests, bug fixes, and publishing new releases, the original owner was approached by another member of the community offering to take over the management of the project. In good faith, the original author transferred control of the project to the new member and went on to other things. Within weeks, malicious code was attached to the project, downloaded via automated build tools, and deployed in an unknown number of software applications.
In this case, the malicious code was specifically crafted to steal credentials from Copay bitcoin wallets. Like backdoors and other malware, the attacker’s code used encryption to obfuscate its functionality and sent the stolen credential data to a remote server. If not for a few small mistakes that alerted the managers of the Node.js repository to a possible bug in the package, the malicious code would likely have remained in the package for more than the two months that it did.
The software development process is entirely based on the assumption that the software supply chain is trustworthy. In the case of open-source software, the foundational principle is that anyone can create a project or contribute. There is no formal vetting process. Although there are ways to mitigate this type of risk using build tool features, the features are either too esoteric or not practical enough to be used consistently.
Conclusion
Clearly, the convergence of wide-spread adoption of open source code, software build automation tooling, and illicit economic incentives have made attacks on the software supply chain attractive and effective. But why aren’t existing controls able to mitigate this risk?
Generally speaking, our existing process controls in the software development lifecycle and vendor management are simply too reliant upon time-consuming, error-prone manual procedures and self-attestation to be consistently effective. Technical controls are often “looking the other direction”. In the case of Web Application Firewalls, inspection is focused on inbound traffic. Endpoint Protection systems may not be installed in the application’s deployment environment or may intentionally be configured to “allow” privileged activity from trusted applications. Code scanning techniques find unintentional common mistakes but fail to identify intentionally malicious software.
Yes, improvements can be made to Vendor and Patch Management processes. Improvements can be made to Endpoint Protection systems and code scanning tools. It may even be possible to gather consensus in the open source community around a more uniform way of vetting open source projects, their creators, and the ownership chain of custody. But what do we do in the meantime?
If organizations that use software applications must assume all the risks associated with it, there must be a simple way for them to also mitigate those risks without requiring special expertise or the participation of the software supplier. A “set and forget” technical control that can be applied to any application, in any deployment environment, would go a long way toward minimizing the risks associated with the software supply chain.
Imperva RASP
Imperva Runtime Application Self-Protection (RASP) offers a compelling way forward. Delivered as a lightweight software plugin, RASP attaches to virtually any type of application whether a third party, open-source or bespoke. Tightly coupled with the application and requiring no external connectivity, RASP protections are consistently applied regardless of where the application is deployed today or in the future. Using a positive security approach, RASP mitigates risk from supply chain attacks by neutralizing malicious software activity including unauthorized network calls, file system access, and execution of commands on the underlying host operating system.
Perhaps this is why the National Institute of Standards and Technology recommends the use of RASP in Special Publication 800-53, section SI-7(17), Security and Privacy Controls for Information Systems and Organizations?
See Runtime Application Self-Protection for yourself.
Try Imperva for Free
Protect your business for 30 days on Imperva.
