Surprisingly normal behaviour in enterprise software development is to allow arbitrary code to run on local systems and production servers that no one in your organisation has reviewed or verified is safe.

In a recent article, I examined how supply chain attacks can inject malicious software into your codebases. In this post, I will go through some common examples of how easily this happens as part of the day-to-day development of modern teams.

Debian Security and PPAs

Package managers are trusted applications that install other pieces of software to a computer system. For example, Canonical - the developers and distributors of the popular Linux Ubuntu operating system - uses a relatively locked-down and secure package manager called APT, which, by default, only allows users to download and install trusted software from known sources.

However, developers often need third-party code in their systems that are not part of the trusted package management ecosystem, so they extend the package manager by allowing application installations from APT "Personal Package Archives" (PPA). These PPAs are the code archives of any organisation that wishes to publish code for others to use - which could be viruses or could be useful software.

At a high level, this is similar to Windows and Mac systems, where users can theoretically download anything they want. The difference is that developers should know better and not incorporate insecure practices into their day-to-day development workflow.

For example, answers on Stack Overflow frequently suggest developers install code from random authors, purporting to be specific organisations with specific code archives. Still, the underlying code could be viruses and malware, and it would not be immediately obvious if this were the case. One suggestion is to install Java 8 by downloading code managed by a Greek school support company:

# Allow code to be downloaded from the Greek company
sudo add-apt-repository ppa:ts.sch.gr/ppa

# Update the local system
sudo apt-get update

# Install code purporting to be a Java installer (but could be anything) with superuser privileges
sudo apt-get install oracle-java8-installer

Stopping to think about what is going on here, this is a pretty crazy way to handle installing Java - one of the most prevalent technologies in the world - on your system by delegating the procedure to an unknown Greek organisation. Also, bear in the mind that the use of sudo in these commands means these installations are running as the superuser with full privileges to the underlying system.

Fortunately, Canonical does give a warning about this behaviour:

Only add software repositories from sources that you trust!

Third-party software repositories are not checked for security or reliability by Ubuntu members, and may contain software which is harmful to your computer.

Regrettably, this is often ignored, and many developers frequently install arbitrary code from various publishers on their systems.

Pipe Installers

A "pipe installer" is an unofficial term for the two-stage process of installing an application by:

Downloading an installation script from the internet
Executing the downloaded script as a privileged superuser

In other words, it's a way of running arbitrary code with full privileges (with the intention to install a specific piece of software but not having surety).

The syntax of a pipe installer is:

curl -sL <URL> | sudo -E bash -

This command fetches a file from the internet with curl, a downloader utility, and pipes the contents to bash for execution with super admin privileges, afforded bysudo.

A widespread use case for this type of installation is to download programming tools and languages like node.js and Rust:

curl -sL https://deb.nodesource.com/setup_18.x | sudo -E bash -

In this example, the script to install node.js is hosted on thedeb.nodesource.com domain, downloaded and then immediately executed with superuser privileges. (You can safely open the file https://deb.nodesource.com/setup_18.x in your browser.)

For anyone with a hint of security awareness, it is feasible that an arbitrary script downloaded from the internet and executed with the greatest permissions achievable could wreak havoc on your machine, wipe your filesystem, install viruses, install crypto miners or anything else. Yet, this is recommended by various organisations and popularised by developers without necessary care and attention.

If using pipe installers, there are many security considerations:

The company developing the program you want to install: You should only install applications from trusted sources.
The distribution source and medium: You should only download applications from distributors your trust, using secure transport mechanisms.
The privileges required to install and run the program: You should only grant the limited permissions necessary for the application to be installed and run.

For the example of the node.js installation, having this application installed is a requirement when developing and running JavaScript applications and it is maintained by the reputable OpenJS Foundation, so it is very unlikely to contain any malware.

In terms of the distribution, deb.nodesource.com uses HTTPS, which grants transport-level security and the avoidance of most man-in-the-middle attacks. However, the website could become compromised at any time, with updates to distribute malware scripts rather than node.js installation scripts. If this were to happen, the pipe installer would offer no protection as it would still execute whatever script is downloaded. Ideally, developers would review the source code, validate known checksums or use a cached version of the installation script to improve overall security.

Finally, agreeing to run the downloaded code with the maximum possible privileges of the system is, frankly, absurd from a security perspective - and remember, these types of scripts are executed not only on your personal machine but also on production servers as part of set up requirements. These types of scripts could be granting hackers easy access to your data.

Insecure Docker Images

Docker is a containerisation technology that helps teams distribute entire working systems, including an operating system, port configurations, firewall rules and a software application. From an operations perspective, deploying a set of homogenous Docker images to production servers is considerably easier to maintain and scale, compared to managing multiple, lower-level applications written in different languages, with different deployment requirements. In large part, this is why Docker has become a standard part of the enterprise software stack.

To get started and use Docker more easily, there is a centralised repository of docker images at Docker Hub where anyone can download pre-made systems (called images) and publish their own for others to use. In particular, this helps a developer's work flow when using different databases, messaging systems and other infrastructure. Unfortunately, there is no verification process that any images published on the site are safe or secure, so developers frequently use them at their own risk.

Like any other code created and distributed by third-parties, we should be vigilant that we verify what we have downloaded and only run trusted applications from known sources. Otherwise, we risk running arbitrary code that could log keystrokes, steal data, lock systems and much more.

Summary

Developers can be seemingly too willing to download and run code on their systems which is rarely verified and often granted full administrator access - even to production servers. Although we cannot take the opposite approach and never leverage the work of other organisations, I recommend that development teams take caution when using unknown systems, keep important information backed up and be hesitant to grant elevated privileges to any service.