Solana or Solana-Py? Understanding the Confusion

The Solana Python API project is known for its reliable tools to interact with the Solana blockchain. But a recent mix-up in naming has caused quite a stir in the developer community. The legitimate Solana tool is called "solana-py" on GitHub and simply "solana" on PyPI, the Python software registry. However, a threat actor saw this as an opportunity to create a malicious package named "solana-py" on PyPI. This counterfeit package not only borrowed the legitimate code but also included sneaky scripts to steal sensitive information.

What Happened with Solana-Py?

Tracked as "sonatype-2024-3214," the Sonatype Security Research team discovered the suspicious "solana-py" package on PyPI. With the help of their automated malware detection system, part of their Sonatype Repository Firewall, they flagged this package. Carlos Fernandez, a security researcher at Sonatype, led the investigation and found some alarming details.

At first glance, the counterfeit project seemed genuine. It shared the same name as the legitimate "solana-py" on GitHub, which made it look credible. However, the package on PyPI was a cleverly disguised trap. This discrepancy in naming between the GitHub project and PyPI was enough to confuse developers and expand the attack surface.

Fernandez noted that legitimate libraries like "solders" referenced "solana-py" in their documentation. This increased the chances of developers mistakenly downloading the malicious "solana-py" from PyPI, thinking it was the real deal.

The legitimate "Solders" project mentioned "solana-py" in its documentation, making it easier for attackers to impersonate the package name on PyPI. Carlos Fernandez observed that the real "solana" project’s latest version was 0.34.3, while the fake "solana-py" boasted a version number of 0.34.5. This misled developers into thinking the counterfeit package was a newer, updated version.

"The malicious maintainer is ‘treefinder,’ but the legitimate project is maintained by ‘michaelhly,’" Fernandez explained. Additionally, no recent code changes were observed in the "init.py" file of the real project on GitHub, while the counterfeit package had altered files.

How the Malicious Package Abuses Hugging Face Spaces

The counterfeit package’s "init.py" file imported a "solana.exceptions" library that seemed like a harmless error-handling library, but it was far from innocent.

Upon inspecting the "exceptions.py" file, the true intentions of the package author were revealed. Hidden in the code was a network call to a URL (defanged for safety): hxxps://treeprime-gen.hf[.]space/image?s=.... This URL was part of the Hugging Face Spaces, a platform for hosting AI/ML models and applications. The malicious package used this to exfiltrate data from the system.

The *.hf.space domains, offered by Hugging Face, became a convenient tool for attackers to create rogue APIs and exfiltrate sensitive information. This wasn’t the first time Hugging Face was misused by adversaries to distribute malicious AI/ML models.

A previous version (0.34.3) of the counterfeit "solana-py" package showed evidence of these network calls. In this version, the "init.py" file made direct calls to the threat actor’s *.hf.space subdomain.

Fernandez explained that the package publisher attempted to override a key function used by the "solders" library to exfiltrate secrets like Solana’s blockchain wallet keys from the system. The "solders.keypair.Keypair.init" method was replaced by the attacker’s "new_method()" function, which sought to steal the "self.to_bytes_array" value to a rogue domain.

This value was crucial as it was used by "solders" to interact with the Solana Core SDK. Having access to it allowed attackers to steal Solana’s blockchain wallets. In other words, if a developer using the legitimate "solders" PyPI package was misled by the documentation to download the counterfeit "solana-py," they would unknowingly introduce a crypto stealer into their application. This would not only compromise their secrets but also those of any user running the developer’s application.

Sonatype Repository Firewall to the Rescue

This incident is a stark reminder of how threat actors continuously evolve their tactics to exploit the open-source ecosystem for malicious purposes. It underscores the critical need for improved supply chain security measures and vigilant monitoring of third-party software registries. Developers and organizations must prioritize security at every stage of the development process to mitigate risks associated with third-party dependencies.

Malicious open-source packages are designed to evade typical software composition analysis (SCA) scanners. However, users of Sonatype Repository Firewall can rest easy knowing that these packages would automatically be blocked from reaching their development builds, ensuring a hygienic software development life cycle (SDLC).

If you’re not already protected with Sonatype, consider reaching out to see how the Repository Firewall can safeguard your development environment.