What is Package Tampering and How to Prevent It

Photo by Markus Spiske on Unsplash

Modern software development pipelines are made up of many processes in the continuous integration and continuous delivery (CI/CD) process. To operate the process, numerous tools and services are often employed at each of these phases, introducing an additional layer of risk. Open-source products are a gold mine for attackers since they are, by definition, open and popular, making them easier to breach and affecting a larger group of people.

Attackers can acquire control of or access to an open-source package or library. This allows them to tamper with it, generally by inserting harmful code. It is then merged, updated, and downloaded by hundreds, if not millions, of people eager to use and benefit from the original open-source programme.

This is exactly how they poison the well; they poison the open-source package and encourage developers to unwittingly taint the software they're working with, frequently exposing backdoors that the attacker may later access or exploit to obtain sensitive data.

The problem is simple; there are hundreds of thousands of open-source programmes with an even greater number of contributors. It's simple to lose track of and visibility over the packages you're utilizing, as well as their security levels. This causes software development teams to unwittingly incorporate harmful versions of the OS package they desire into their work.

To compound this danger, several vulnerabilities and misconfigurations are identified inside these packages on a weekly basis that attackers might exploit to launch assaults, even if the package that was first pulled in was "safe".

Steps to Prevent Package Tampering for Your Projects

There are some key points to keep in mind to protect your software against vulnerabilities. Maintain awareness of all current and new external pipeline dependencies. This involves creating a process for reviewing and approving new, unverified dependencies and scanning all packages for vulnerabilities, both known and undiscovered.

Also, make sure you notify the concerned people of any unusual activity or compromises. A good way to ensure all this happens in creating and enforcing a package usage policy for the firm.

Now, doing all these steps everytime you want to publish an upgrade to your package may seem unnecessary and hectic to do on a regular basis. But, worry not, many tools can assist us with this task. There are many famous well-tested tools used widely. A free tool that I usually use is Whitesource Diffend, which makes life a lot easier in terms of supply chain security and open-source software management.

WhiteSource Diffend

WhiteSource Diffend is a multifaceted tool. It detects and analyzes packages' behavior. It also gives you granular control over the dependencies allowed in your organization. Let's look at how we can use WhiteSource Diffend's malware detection, security scanning, and risk management platform to control the risks associated with employing open source third-party dependencies.

The best aspect about this programme is that it also has a free version, which implies that maintaining open source software is not only easier but also less expensive for smaller scale projects. For more information, you can check out the pricing plans and choose a plan that suits your organization the best.

For the purpose of this demonstration, we will work with a Ruby-jekyll static site.

After you set up the project on your local system, we can proceed with the working of Diffend and how it carries out its analysis on our project.

Getting Started

It is hard to miss the "Start for Free" button on the home screen, which is what we will use for this demo.

After a quick registration process, we can log in, and after a few easy-to-follow steps, we can create our open source project.

Integrating Diffend in Our Project Codebase

Once the project is created on the dashboard, we are automatically taken to this setup page with clear instructions on how to integrate the tool with our codebase.

So, in the root folder inside our project directory, we create a file titled diffend.yml and paste the given content given. This is what our project directory structure looks like right now:

After adding the .yml file, we will now edit our Gemfile to include Diffend as a plugin. Make sure to add it right after the source and before any gem declarations as shown below:

With the setup completed, we simply need to run bundle install to initialize the Diffend plugin. A successful install should look like this (please note that version numbers of various dependencies can differ):

After this is done, we go back to our WhiteSource dashboard to see that the plugin is successfully integrated.

Adding Unsafe Packages

Since we are working on a simple project, the plugin shows a Quality Score of 100, which means we are working totally safe packages or gems in Ruby's case. The Quality Score is a numeric score ranging from 0 to 100 that offers a fast snapshot of the status of your Gem file. The score is a composite of the sub-scores from each of the guards and gives us a handy way of tracking trends so we know to take action if there is a decrease in quality.

We go ahead and add this random package/gem to our project anywhere with the other gem declarations.

Diffend in Action

After adding the unsafe package, we run a bundle install and we receive warnings on the terminal as shown below:

Clicking on the link takes you back to the dashboard to see that the Quality score on the latest command run has decreased to 95:

You can always disable specific guards/actions for both packages and versions under the 'Gems and versions usage' portion of your organization settings, or by directly clicking on the version/gem name on the verdict screen.

Now our project is all set to protect us against any package tampering attacks any time someone runs one of the following commands:

• bundle install

• bundle exec (for environments other than test and development)

• bundle secure (introduced by the Ruby plugin)

Conclusion

According to Google's recent initiatives regarding package tampering in OSS, it's too easy to upload malicious packages. It has described some of the efforts made to detect malicious code packages that have been introduced into larger open-source software projects.

The Package Analysis Project is one of the Open Source Security Foundation's (OpenSSF) software supply chain efforts that help automate the process of spotting harmful packages released on major package repositories like npm for JavaScript and PyPl for Python. It performs a dynamic examination of all packages published to prominent open-source repositories. Its goal is to offer information about common forms of harmful packages and to advise others working on open-source software supply chain security on how to enhance it.

Prevention being better than cure, we should always keep an eye out apart from using tools like Diffend. For crucial software, try to stick to trustworthy, well-recommended, well-supported, and actively developing OSS products. We're dealing with odds in all of these instances.