In-depth studies on cybersecurity have recently uncovered a new malicious package hiding in the Python Package Index (PyPI) repository. This package was participating in a campaign known as SentinelSneak, in which it pretended to be a software development kit (SDK) for SentinelOne, a major company in the field of cybersecurity. The discovery throws more light on the SentinelSneak threat, the dangers of “API key harvesting,” and the ways in which businesses and organizations can protect themselves from attacks that target the software supply chain. As the process of software development continues to advance and become more complicated, the necessity to safeguard the software supply chain is becoming an increasingly pressing concern.
A New Danger for the Python Package Index (PyPI) Repository, Known as SentinelSneak:
The software package, which was known as SentinelOne and has since been taken offline, was initially released between December 8 and December 11, 2022, with nearly two dozen versions being released in rapid succession over the course of two days. It made the claim that it provided an easier method to access the company’s APIs, but in reality, it contained a malicious backdoor that was designed to collect sensitive information from development systems. This information could include access credentials, SSH keys, and configuration data. The fact that the threat actor was also seen releasing two more packages with variations in their names — SentinelOne-SDK and SentinelOneSDK — brings to light the persistent dangers that are present in open-source repositories.
This SentinelOne imposter package is just the latest threat to leverage the PyPI repository, and it exemplifies the growing threat to software supply chains. Malicious actors are increasingly employing strategies such as “typosquatting” to take advantage of developer confusion and insert malicious code into development pipelines and legitimate applications.
The Risks Associated with “API Key Harvesting”
Hacker-in-Residence at Cequence Security Jason Kent explains that this type of attack, known as “API key harvesting,” is a growing concern as attackers look for ways to contextually harvest API keys from organizations that have specific technology deployed. This type of attack is a growing concern because attackers look for ways to harvest API keys from organizations that have specific technology deployed. Attackers are able to find API keys by crawling through git repositories, as Kent points out. However, by utilizing API key harvesting SDKs that mimic SDKs from well-known security companies, attackers are able to gain even more context and potentially harvest keys from organizations that are running the technology that they are interested in.
How organizations can defend against Attacks on the Software Supply Chain
Even though it was fortunate that this particular attack was discovered, it should serve as a reminder to all organizations that they need to be vigilant in validating tools and frequently invalidating and regenerating API keys in order to prevent attacks of this type. The software supply chain security company made the observation that the SDK client code for the fraudulent package was “probably obtained from the company by way of a legitimate customer account.” A history of shell commands that were executed, SSH keys, and other files of interest was among the data that was exfiltrated by the malware to a remote server. This suggests that the threat actor was attempting to steal sensitive information from development environments, as indicated by the data that was exfiltrated.
Although it was downloaded over a thousand times before it was taken down, it is not immediately clear whether the package was weaponized as part of an active supply chain attack. SentinelOne responded to a request for comment from The Hacker News by stating that it is “not involved with the recent malicious Python package leveraging our name,” and that the attempts made by the threat actors were unsuccessful. “Attackers will put any name on their campaigns that they think may help them deceive their intended targets,” the company said in their statement. “However, this package is in no way affiliated with SentinelOne in any way.” “PyPI has removed the package, and our customers can feel safe knowing that there has been no evidence of a compromise as a result of this campaign,” the company stated.
How to Maintain Vigilance in the Lightning-Fast World of Software Development?
According to a threat researcher from ReversingLabs named Karlo Zanki, “Though limited in scope and having little impact, this campaign serves as a reminder to development organizations of the continued existence of threats to the software supply chain.” “Just like with previous malicious campaigns, this one plays on tried and true social engineering tactics in order to confuse and mislead developers into downloading a malicious module,” the author of the article says.
In conclusion, the SentinelSneak campaign serves as a reminder of the significance of protecting the software supply chain as well as the requirement for organizations to maintain vigilance in the fast-paced world of software development. Organizations can better protect themselves from malicious packages and attacks on the software supply chain by validating the tools they use and regularly invalidating and regenerating API keys. Validation should be done on a regular basis. It is essential to perform constant monitoring and protection of the software supply chain in order to guarantee that it will continue to be safe and sound for all parties involved.
“The interesting part of this story is the volume of malicious packages that were uploaded to mainstream package repositories. For the uninitiated, a package repository is the location where developers obtain libraries of code to help accelerate innovation within their application. For every new feature, a developer could either create all the functionality as custom code, or find a pre-built library that gets them most of what they need and then customise the rest. Obviously the latter is more efficient, but it requires the developer to search for pre-existing libraries that meet their needs. It is that research phase these attackers were targeting in what is really more of a spam effort very similar to the email spam we are all familiar with. These attackers hoped that victims researching code libraries in these popular package repositories would be enticed by their spam message and go down the rabbit hole the attackers created. Normally an individual would infrequently upload a new package to a package manager, but in this case it appears the attackers used automation to bulk upload their malicious packages. This was likely done to have the broadest coverage of potential library searches by developers, knowing that once discovered, their attack would be easily disabled. Given the nature of this attack, its unlikely that developers working on legitimate applications would include those malicious packages in their applications.”
When asked why he robbed banks, Willie Sutton said “cuz that’s where the money is”. When looking to find magic keys to the kingdom, for an organization, the attacker is going to look where the API Keys are. Since you can’t get API Keys from Developers just by using Charm and Personality. Like Willie, you have to employ the right weapons.
It is possible to crawl through git repos and find API keys, we read about these sorts of attacks all the time. What if you could put some context around the API keys and harvest keys from organizations that will have specific technology deployed? Enter the world of API Key harvesting SDKs that mimic SDKs from well-known security companies. This gives us the ability to contextually harvest API keys from those that are running the technology we care about.
Fortunately for us, this was noticed. Unfortunately, this is what we are now up against. Everything we do and every tool we use needs to be validated. Any API Key we use needs to be invalidated and regenerated every time we need it. The days of having high-privilege API keys that last forever, need to go away into the past. If someone can write code that can harvest API Keys from our own code, we need to stop allowing API Keys to last more than a few minutes.