Supply Chain Attacks

A while back supply-chain attacks were all the rage, but this attack vector has been around well before these attacks made the news and seen in Stuxnet attack, as well as with the SUNBURST attack that targeted SolarWinds's Orion software.

Supply-Chain Attacks

Software applications implement software components, and some of the most known components are libraries which can be extracted from repositories (i.e. NPM, PyPi, etc.). Libraries allow applications to abstract functionalities and logic. This happens for reasons such as:

• Not having enough time to develop the functionality in-house.
• Not having enough expertise to build the logic, for example crypto-libraries.

These libraries are mostly built by third-parties, and thus are external to one's organization. Each library will have its own flow, its own security practices, and create a wide attack surface for the organization if not careful in implementing them.

In supply-chain attacks, the attacker targets one of those software components that is used and implemented by organizations. Once that component is compromised, the attacker has gained a foothold within the company infrastructure. Depending on the organisation's implementations & dependency management, the attacker can either inflict tremendous damage by pivoting from their foothold or be extremely restrained to that component.

Organizations' Shortcomings

As organizations implement more dependencies into their technology stacks, they are putting more trust in the package and library maintainers, giving them power over their tools without a second thought. They go to say that "since this is coming from a known source, it is safe to use and implement", without:

• reviewing when the last code update was done,
• understanding their code practices,
• asking about their patch flow and how they ensure the safety of their codebase.

Some mention that open-source software is more secure because more contributors review the code, while others believe in the security of proprietary solutions. We will come to see that in both cases, security is still dependent on the implementing organization. No third-party dependency is ever fully secure and trustworthy, and it never should be.

Recent Attacks

From the start of December 2020, three major attacks were identified. Two of those were through open-source development libraries, and one was through a proprietary DLL.

SUNBURST

Needless to say, the proprietary DLL was the root cause of one of the most devastating attacks for 2020 where several US departments, FireEye, Microsoft, and several other companies were compromised. This attack is named SUNBURST and it was targeted against a DLL inside of SolarWinds' Orion software.

FireEye released a threat research article on this attack detailing the attack and ways that organizations can protect themselves. A couple of days after that, Microsoft released an analysis of the compromised DLL and the ways that the company is working to protect its users and clients.

Golang XML Parser Bug

A week ago it was reported that Golang's XML parser that was used in SAML authentication was broken due to the encoder and decoder functions. In every encoding and decoding round-trip, the results were inconsistent and didn't return the proper data, which led to bypasses to the SAML implementations. Three advisories were created, and more can be read through the Mattermost blog.

Bouncy Castle's OpenBSDBcrypt Class

A couple of days ago, Synopsys identified a weakness in the Bcrypt implementation provided by Bouncy Castle, which allows an abuser to bypass the Bcrypt hash verification in a couple of attempts instead of using exhaustive resources (and fail). The issue was in their implementation of indexOf instead of using charAt. Refer to the Synopsys blog for further reading.

Security Measures

It is apparent that this attack vector can be deadly to most if not all software applications, and on that note, several practices should be implemented:

• Create a secure baseline using OWASP Software Component Verification Standard while trying to achieve the highest maturity level in stages.
• Review and ensure that the Software Bill of Materials (SBOM) is scanned regularly to identify known vulnerable components. An open-source tool is OWASP Dependency-Track.
• Run the software componRemove the fussents through linters and SAST tools, and where critical libraries are used, manual review could be required to ensure the highest levels of security are available. By reviewing version snapshots, code differences can be easily seen and reviewed in a quick fashion.
• Restrict the user and network accesses to limit the spread of the attack.
• Ensure proper logging mechanisms are in place to help security analysts do identify whenever an anomalie occurs.

Conclusion

Supply-chain attacks are definitely on the rise as more software is written by the day. Organizations should ensure their awareness of dependencies they're injecting into their networks and applications, as they could be running a threat actor's code unknowingly throughout their network.