New Supply Chain Attack Technique Can Trojanize All Commands (Part 2)

Enhancing Attacks through Command Wrapping

In each command hijacking strategy, while it might be easier for attackers to simply overwrite CLI commands, the chances of remaining undetected are quite low. Once victims find themselves unable to execute commands, they are likely to become suspicious immediately. However, through a technique known as “command wrapping,” these attacks can become more effective and stealthy.

Command wrapping doesn’t just replace commands but creates an entry point that acts as a wrapper around the original command. Here’s how it works:

• When a user calls a command (whether impersonating a third-party tool or attempting to impersonate a system command), it triggers the malicious entry point.
• This entry point silently executes the attacker’s malicious code and then calls the original legitimate command using all the user’s parameters.
• Finally, it returns the legitimate command’s output and exit code to the user.

This method of command wrapping is particularly dangerous because it executes malicious code without the user’s knowledge while maintaining the appearance of normal operation.

Since the legitimate command still runs and its output and behavior are preserved, there are no immediate signs of intrusion through regular use, making the attack extremely difficult to detect.

This stealthy approach allows attackers to maintain long-term access and potentially steal sensitive information without arousing suspicion.

However, implementing command wrapping requires additional effort from the attacker.

They need to know the correct path to the target commands on different operating systems and consider potential errors in their code. This complexity increases with the diversity of the target systems.

Depending on the hijacked command, another method is for the malicious package to not only perform its covert operations but also replicate part or all of the original command’s functionality.

The wrapper doesn’t call the real command but emulates its behavior. This method can further reduce suspicion, especially for simpler commands, but it requires more effort from the attacker to accurately mimic the original command’s behavior in various scenarios.

The success of these attacks ultimately depends on the malicious package being installed and its script directory being prioritized in the system’s PATH.

Abusing Entry Points with Malicious Plugins and Extensions

Another powerful technique for abusing entry points is creating malicious plugins for popular Python tools and frameworks. This method is particularly dangerous as it targets the development and testing processes themselves.

Manipulating pytest

As an example, let’s consider how an attacker could target pytest, a widely used testing framework in the Python ecosystem. By creating a malicious pytest plugin, an attacker could compromise the integrity of the entire testing process. Such an attack might work as follows:

1. The attacker creates a plugin that injects malicious code using pytest’s entry point system.
2. The plugin is distributed as a seemingly useful testing tool.
3. Once installed, the plugin can manipulate various aspects of the testing process, such as assertion handling.
4. The malicious plugin can then quietly execute harmful code in the background during testing.

A malicious plugin could also override pytest’s assertion comparisons, causing, for example, all equality checks to pass regardless of their actual values, leading to false positives in test results. This allows flawed or vulnerable code to pass quality checks unnoticed.

Manipulating Flake8

Attackers can also target popular development tools, manipulating them to run malicious extensions.

Flake8, a widely used code checking tool in the Python ecosystem, is one example. Since Flake8 uses entry points to discover and load extensions, it becomes a potential target for malicious actors.

An attacker could exploit Flake8 by creating a malicious extension disguised as a useful code checking rule. The extension is defined as an entry point in the package’s setup configuration.

For instance, the setup file might specify an entry point named ‘MCH’ pointing to a malicious checker class within the package.

The implementation of this malicious checker could include harmful operations on the victim’s system, inject malicious “fix” code, or manipulate code check results to hide or create issues.

When users run Flake8 on their codebase, this malicious extension gets activated, allowing attackers to execute their harmful code.

This attack is particularly dangerous because code checking tools typically run across the entire codebase, giving attackers broad access.

Additionally, the attack can be masked as a seemingly useful code checking rule, making it less likely to arouse suspicion. It can be part of a larger supply chain attack aimed at gathering intelligence or introducing vulnerabilities into the target codebase.

Bypassing .whl File Restrictions

Python wheel (.whl) files have become increasingly popular due to their performance advantages in package installation.

However, they pose unique challenges for attackers. While .tar.gz and .whl files can both contain setup.py files, .whl files do not execute setup.py during installation. This characteristic has traditionally made it difficult for attackers to achieve arbitrary code execution during the installation of .whl files.

However, the entry point attack method we discuss provides a workaround for this limitation.

By manipulating entry points, attackers can ensure their code executes when specific commands run, even if the package is distributed as a .whl file.

This is particularly important as newer versions of pip automatically create both .tar.gz and .whl files when developers build Python packages using commands like “pip -m build.” Additionally, pip prioritizes delivering .whl files during installation.

This change in package format and installation behavior presents new opportunities for attackers. Many security tools focus on analyzing the execution of pre-install scripts typically associated with .tar.gz files.

Thus, they might miss malicious code in packages distributed as .whl files, especially when the malicious behavior is triggered through entry points rather than immediate execution.

Entry Points in Other Ecosystems

While this article focuses primarily on Python, vulnerabilities involving entry points are not limited to the Python ecosystem. Through our research, we have confirmed that this type of attack vector exists in several other major ecosystems, including npm (JavaScript), Ruby Gems, NuGet (.NET), Dart Pub, and Rust Crates, though the vulnerabilities may not be limited to these.

Understanding how entry points work in various programming languages and package managers is crucial to grasping the broad nature of this potential security risk and developing comprehensive defense strategies.

Conclusion

Entry points, while powerful and useful features for legitimate package development, can also be manipulated to deliver malicious code across multiple programming ecosystems. Attackers can exploit this mechanism in various ways, including command hijacking and creating malicious plugins and extensions for popular development tools.

It is essential to develop comprehensive security measures to address entry point exploitation. By understanding and addressing these risks, we can strive to create a safer Python package environment, protecting individual developers and enterprise systems from sophisticated supply chain attacks.

---

The End.

---

This article is written by Duyan Intelligence.

I'm Carrie, a cybersecurity engineer and writer, working for SafeLine Team. SafeLine is an open source web application firewall, self-hosted, very easy to use.