Software supply chains at risk: The account takeover threat

As recently exposed by Cisco Talos, software supply chain attacks have gained popularity amongst all kinds of cyber criminals. Once exclusively used by cyberespionage threat actors, these attacks have now also become attractive for any kind of cyber criminal, who sees in this threat a way to compromise hundreds or thousands of computers with one single operation.

This explains why the software supply chain attack threat has more than tripled in 2021 when compared to 2020, researchers report.

What are software supply chain attacks?

A software supply chain attack consists of targeting software repositories or download locations, in order to spread malware instead of or in addition to legitimate software. Attackers might use several ways to compromise a software supply chain.

One way would be to find vulnerabilities to compromise the storage of downloadable software, especially when stored on a third-party website. Yet, it might not be successful at code repositories storing pieces of software.

Another method consists of attacking developers accounts and gaining access to it or accessing a software or website maintainer account. Once the access is compromised, the attacker might then publish malicious updates of the software, affecting every user and company that would download the new update and install it.

This can be particularly disastrous in the case of a compromised and modified library, which could be used by hundreds of different pieces of software all around the globe. It might happen on actual software packages as well as old packages suddenly pushing new updates after years of inactivity.

SEE: Password breach: Why pop culture and passwords don’t mix (free PDF) (TechRepublic)

Most developers aim at gaining efficiency and therefore use a lot of third-party code, generally libraries, to avoid having to redevelop something that is already done and freely available. Yet, those third parties’ software are almost never reviewed by developers and are fully trusted.

Account takeover risks at current code repositories

Talos researchers have analyzed the most frequently used code repositories, with a sharp eye on how difficult it would be for an attacker to successfully compromise a developer account. The researchers have also worked with these repositories to resolve major issues when found.

NPM

NPM, or Node Package Manager, is a code repository specific to the JavaScript programming language that provides more than two million packages. Those packages contain metadata such as a description, a link to the package archive file and a list of the package maintainers, including the developers username and email address (Figure A).

Figure A

The NPM repository has been independently audited recently, and it seems that it is not prone to attacks on developers’ email addresses. Expired developer accounts could not be retrieved, with specific security measures taken by NPM.

PyPI

Python Package Index stores almost 400,000 different projects written in the Python programming language. Developers’ email addresses are not exposed publicly by default on that repository. Yet, many developers enable that feature, since they need or want to interact with other people running their code for various reasons, such as functionality feedback, improvement suggestions, and bug reports.

Multi-factor authentication is not enabled by default for the biggest part of the repository. It is only mandatory to “critical projects,” which represents the top 1% of the PyPI projects, based on the number of downloads. PyPI has distributed 4,000 hardware security keys for MFA for those critical projects.

Account takeover at PyPI has already happened, yet changes made by admins recently seem to be moving account security in the right direction, according to Talos researchers.

CPAN

More than 200,000 Perl programming language modules are stored on the Comprehensive Perl Archive Network. Module developers have their own homepage listing their contributions and their email address (Figure B).

Figure B

It is possible on that repository to gain access to abandoned email addresses of developers, in the case they have used a domain that no longer exists. An attacker may register the domain and set up email for it and ask for a password reset.

Talos reached out to CPAN and provided them with a list of vulnerable accounts, which CPAN disabled.

NuGet

NuGet is a .NET software repository, with more than 317,000 packages. Developers have their email addresses hidden by default on the platform. Instead, NuGet offers a form on the website to reach the developers without leaking their email address. An option for the developers to add their Twitter handle is provided but can not be considered as a direct way to try to compromise a developer.

RubyGems

Ruby developers might use the RubyGems repository, composed of approximately 172,000 packages (also called gems). The developers’ email addresses are hidden by default. Yet, some gems contain a maintainer file, which indicates a contact email address for the developer. Although, it is not consistent across gems.

RubyGems has recently announced the enforcement of MFA for top developers accounts to fight against account takeovers.

What can be done against this threat?

For starters, developers’ and maintainers’ accounts need to be protected from account takeover. This could be done by having all code repositories push MFA and make it mandatory to access the code. Several repositories have already enforced that policy but mainly for their top developers.

Second, code repositories should not reveal developers’ or maintainers’ email addresses. Providing a form to reach the developers is a safer method.

Code signing keys should also be deployed, to ensure a developer’s expired domain name could not be used by an attacker, since they would not own the code signing key.

At a consumer level, organizations should carefully analyze what software they use and segment a group of systems running particular pieces of software from the rest of the internal network. Although, this has limitations too.

Ideally, new updates from any software should be reviewed before deployment by looking at code differences between the old and new code. While ideal, this technique would certainly use a high amount of resources within the company.

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.