Mar 25, 2024NewsroomSupply Chain Attack / Cryptocurrency

Unidentified adversaries orchestrated a sophisticated attack campaign that has impacted several individual developers as well as the GitHub organization account associated with Top.gg, a Discord bot discovery site.

“The threat actors used multiple TTPs in this attack, including account takeover via stolen browser cookies, contributing malicious code with verified commits, setting up a custom Python mirror, and publishing malicious packages to the PyPI registry,” Checkmarx said in a technical report shared with The Hacker News.

The software supply chain attack is said to have led to the theft of sensitive information, including passwords, credentials, and other valuable data. Some aspects of the campaign were previously disclosed at the start of the month by an Egypt-based developer named Mohammed Dief.

It chiefly entailed setting up a clever typosquat of the official PyPI domain known as “files.pythonhosted[.]org,” giving it the name “files.pypihosted[.]org” and using it to host trojanized versions of well-known packages like colorama. Cloudflare has since taken down the domain.

“The threat actors took Colorama (a highly popular tool with 150+ million monthly downloads), copied it, and inserted malicious code,” Checkmarx researchers said. “They then concealed the harmful payload within Colorama using space padding and hosted this modified version on their typosquatted-domain fake-mirror.”

These rogue packages were then propagated via GitHub repositories such as github[.]com/maleduque/Valorant-Checker and github[.]com/Fronse/League-of-Legends-Checker that contained a requirements.txt file, which serves as the list of Python packages to be installed by the pip package manager.

One repository that continues to remain active as of writing is github[.]com/whiteblackgang12/Discord-Token-Generator, which includes a reference to the malicious version of colorama hosted on “files.pypihosted[.]org.”

Also altered as part of the campaign is the requirements.txt file associated with Top.gg’s python-sdk by an account named editor-syntax on February 20, 2024. The issue has been addressed by the repository maintainers.

It’s worth noting that the “editor-syntax” account is a legitimate maintainer of the Top.gg GitHub organization and has written permissions to Top.gg’s repositories, indicating that the threat actor managed to hijack the verified account in order to commit a malicious commit.

“The GitHub account of ‘editor-syntax’ was likely hijacked through stolen cookies,” Checkmarx noted.

“The attacker gained access to the account’s session cookies, allowing them to bypass authentication and perform malicious activities using the GitHub UI. This method of account takeover is particularly concerning, as it does not require the attacker to know the account’s password.”

What’s more, the threat actors behind the campaign are said to have pushed multiple changes to the rogue repositories in one single commit, altering as many as 52 files in one instance in an effort to conceal the changes to the requirements.txt file.

The malware embedded in the counterfeit colorama package activates a multi-stage infection sequence that leads to the execution of Python code from a remote server, which, in turn, is capable of establishing persistence on the host via Windows Registry changes and stealing data from web browsers, crypto wallets, Discord tokens, and sessions tokens related to Instagram and Telegram.

“The malware includes a file stealer component that searches for files with specific keywords in their names or extensions,” the researchers said. “It targets directories such as Desktop, Downloads, Documents, and Recent Files.”

The captured data is ultimately transferred to the attackers via anonymous file-sharing services like GoFile and Anonfiles. Alternately, the data is also sent to the threat actor’s infrastructure using HTTP requests, alongside the hardware identifier or IP address to track the victim machine.

“This campaign is a prime example of the sophisticated tactics employed by malicious actors to distribute malware through trusted platforms like PyPI and GitHub,” the researcher concluded.

“This incident highlights the importance of vigilance when installing packages and repositories even from trusted sources. It is crucial to thoroughly vet dependencies, monitor for suspicious network activity, and maintain robust security practices to mitigate the risk of falling victim to such attacks.”

Mar 07, 2024NewsroomCyber Espionage / Software Security

The China-linked threat actor known as Evasive Panda orchestrated both watering hole and supply chain attacks targeting Tibetan users at least since September 2023.

The end of the attacks is to deliver malicious downloaders for Windows and macOS that deploy a known backdoor called MgBot and a previously undocumented Windows implant known as Nightdoor.

The findings come from ESET, which said the attackers compromised at least three websites to carry out watering-hole attacks as well as a supply-chain compromise of a Tibetan software company. The operation was discovered in January 2024.

Evasive Panda, active since 2012 and also known as Bronze Highland and Daggerfly, was previously disclosed by the Slovak cybersecurity firm in April 2023 as having targeted an international non-governmental organization (NGO) in Mainland China with MgBot.

Another report from Broadcom-owned Symantec around the same time implicated the adversary to a cyber espionage campaign aimed at infiltrating telecom services providers in Africa at least since November 2022.

The latest set of cyber assaults entails the strategic web compromise of the Kagyu International Monlam Trust’s website (“www.kagyumonlam[.]org”).

“The attackers placed a script in the website that verifies the IP address of the potential victim and if it is within one of the targeted ranges of addresses, shows a fake error page to entice the user to download a ‘fix’ named certificate,” ESET researchers said.

“This file is a malicious downloader that deploys the next stage in the compromise chain.” The IP address checks show that the attack is specifically designed to target users in India, Taiwan, Hong Kong, Australia, and the U.S.

It’s suspected that Evasive Panda capitalized on the annual Kagyu Monlam Festival that took place in India in late January and February 2024 to target the Tibetan community in several countries and territories.

The executable – named “certificate.exe” on Windows and “certificate.pkg” for macOS – serves as a launchpad for loading the Nightdoor implant, which, subsequently, abuses the Google Drive API for command-and-control (C2).

In addition, the campaign is notable for infiltrating an Indian software company’s website (“monlamit[.]com”) and supply chain in order to distribute trojanized Windows and macOS installers of the Tibetan language translation software. The compromise occurred in September 2023.

“The attackers also abused the same website and a Tibetan news website called Tibetpost – tibetpost[.]net – to host the payloads obtained by the malicious downloads, including two full-featured backdoors for Windows and an unknown number of payloads for macOS,” the researchers noted.

The trojanized Windows installer, for its part, triggers a sophisticated multi-stage attack sequence to either drop MgBot or Nightdoor, signs of which have been detected as early as 2020.

The backdoor comes equipped with features to gather system information, list of installed apps, and running processes; spawn a reverse shell, perform file operations, and uninstall itself from the infected system.

“The attackers fielded several downloaders, droppers, and backdoors, including MgBot – which is used exclusively by Evasive Panda – and Nightdoor: the latest major addition to the group’s toolkit and which has been used to target several networks in East Asia,” ESET said.

Feb 27, 2024NewsroomSupply Chain Attack / Data Security

Cybersecurity researchers have found that it’s possible to compromise the Hugging Face Safetensors conversion service to ultimately hijack the models submitted by users and result in supply chain attacks.

“It’s possible to send malicious pull requests with attacker-controlled data from the Hugging Face service to any repository on the platform, as well as hijack any models that are submitted through the conversion service,” HiddenLayer said in a report published last week.

This, in turn, can be accomplished using a hijacked model that’s meant to be converted by the service, thereby allowing malicious actors to request changes to any repository on the platform by masquerading as the conversion bot.

Hugging Face is a popular collaboration platform that helps users host pre-trained machine learning models and datasets, as well as build, deploy, and train them.

Safetensors is a format devised by the company to store tensors keeping security in mind, as opposed to pickles, which has been likely weaponized by threat actors to execute arbitrary code and deploy Cobalt Strike, Mythic, and Metasploit stagers.

It also comes with a conversion service that enables users to convert any PyTorch model (i.e., pickle) to its Safetensor equivalent via a pull request.

HiddenLayer’s analysis of this module found that it’s hypothetically possible for an attacker to hijack the hosted conversion service using a malicious PyTorch binary and compromise the system hosting it.

What’s more, the token associated with SFConvertbot – an official bot designed to generate the pull request – could be exfiltrated to send a malicious pull request to any repository on the site, leading to a scenario where a threat actor could tamper with the model and implant neural backdoors.

“An attacker could run any arbitrary code any time someone attempted to convert their model,” researchers Eoin Wickens and Kasimir Schulz noted. “Without any indication to the user themselves, their models could be hijacked upon conversion.”

Should a user attempt to convert their own private repository, the attack could pave the way for the theft of their Hugging Face token, access otherwise internal models and datasets, and even poison them.

Complicating matters further, an adversary could take advantage of the fact that any user can submit a conversion request for a public repository to hijack or alter a widely used model, potentially resulting in a considerable supply chain risk.

“Despite the best intentions to secure machine learning models in the Hugging Face ecosystem, the conversion service has proven to be vulnerable and has had the potential to cause a widespread supply chain attack via the Hugging Face official service,” the researchers said.

“An attacker could gain a foothold into the container running the service and compromise any model converted by the service.”

The development comes a little over a month after Trail of Bits disclosed LeftoverLocals (CVE-2023-4969, CVSS score: 6.5), a vulnerability that allows recovery of data from Apple, Qualcomm, AMD, and Imagination general-purpose graphics processing units (GPGPUs).

The memory leak flaw, which stems from a failure to adequately isolate process memory, enables a local attacker to read memory from other processes, including another user’s interactive session with a large language model (LLM).

“This data leaking can have severe security consequences, especially given the rise of ML systems, where local memory is used to store model inputs, outputs, and weights,” security researchers Tyler Sorensen and Heidy Khlaaf said.

Jan 24, 2024The Hacker NewsVulnerability / Software Security

In a world where more & more organizations are adopting open-source components as foundational blocks in their application’s infrastructure, it’s difficult to consider traditional SCAs as complete protection mechanisms against open-source threats.

Using open-source libraries saves tons of coding and debugging time, and by that – shortens the time to deliver our applications. But, as codebases become increasingly composed of open-source software, it’s time to respect the entire attack surface – including attacks on the supply chain itself – when choosing an SCA platform to depend upon.

The Impact of One Dependency

When a company adds an open-source library, they are probably adding not just the library they intended to, but also many other libraries as well. This is due to the way open-source libraries are built: just like every other application on the planet, they aim for a speed of delivery and development and, as such, rely on code other people built – i.e., other open-source libraries.

The actual terms are direct dependency – a package you add to your application, and a transitive dependency – which is a package added implicitly by your dependencies. If your application uses package A, and package A uses package B, then your application indirectly depends on package B.

And if package B is vulnerable, your project is vulnerable, too. This problem gave rise to the world of SCAs – Software Composition Analysis platforms – that can help with detecting vulnerabilities and suggesting fixes.

However, SCAs solve only the problem of vulnerabilities. What about supply chain attacks?

Attacks VS. Vulnerabilities

It might not be obvious what we mean by an “unknown” risk. Before we dive into the differentiation, let’s first consider the difference between vulnerabilities and attacks:

A vulnerability:

• A non-deliberate mistake (aside from very specific sophisticated attacks)
• Identified by a CVE
• Recorded in public databases
• Defense possible before exploitation
• Includes both regular vulns and zero-day ones
• Example: Log4Shell is a vulnerability

A supply chain attack:

• A deliberate malicious activity
• Lacks specific CVE identification
• Untracked by standard SCAs and public DBs
• Typically already attempted to be exploited or activated by default.
• Example: SolarWinds is a supply chain attack

An unknown risk is, almost by definition, an attack on the supply chain that is not easily detectable by your SCA platform.

SCA Tools Aren’t Enough!

SCA tools might seem to solve the issue of protecting you from supply chain risks, but they do not address any of the unknown risks – including all major supply chain attacks – and leave you exposed in one of the most critical pieces of your infrastructure.

Thus, a new approach is needed to mitigate the known and unknown risks in the ever-evolving supply chain landscape. This guide reviews all the known and unknown risks in your supply chain, suggests a new way to look at things, and provides a great reference (or introduction!) to the world of supply chain risks.

Jan 18, 2024NewsroomSupply Chain Attacks / AI Security

Continuous integration and continuous delivery (CI/CD) misconfigurations discovered in the open-source TensorFlow machine learning framework could have been exploited to orchestrate supply chain attacks.

The misconfigurations could be abused by an attacker to “conduct a supply chain compromise of TensorFlow releases on GitHub and PyPi by compromising TensorFlow’s build agents via a malicious pull request,” Praetorian researchers Adnan Khan and John Stawinski said in a report published this week.

Successful exploitation of these issues could permit an external attacker to upload malicious releases to the GitHub repository, gain remote code execution on the self-hosted GitHub runner, and even retrieve a GitHub Personal Access Token (PAT) for the tensorflow-jenkins user.

TensorFlow uses GitHub Actions to automate the software build, test, and deployment pipeline. Runners, which refer to machines that execute jobs in a GitHub Actions workflow, can be either self-hosted or hosted by GitHub.

“We recommend that you only use self-hosted runners with private repositories,” GitHub notes in its documentation. “This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.”

Put differently, this allows any contributor to execute arbitrary code on the self-hosted runner by submitting a malicious pull request.

This, however, does not pose any security concern with GitHub-hosted runners, as each runner is ephemeral and is a clean, isolated virtual machine that’s destroyed at the end of the job execution.

Praetorian said it was able to identify TensorFlow workflows that were executed on self-hosted runners, subsequently finding fork pull requests from previous contributors that automatically triggered the appropriate CI/CD workflows without requiring approval.

An adversary looking to trojanize a target repository could, therefore, fix a typo or make a small but legitimate code change, create a pull request for it, and then wait until the pull request is merged in order to become a contributor. This would then enable them to execute code on the runner sans raising any red flag by creating a rogue pull request.

Further examination of the workflow logs revealed that the self-hosted runner was not only non-ephemeral (thus opening the door for persistence), but also that the GITHUB_TOKEN permissions associated with the workflow came with extensive write permissions.

“Because the GITHUB_TOKEN had the Contents:write permission, it could upload releases to https://github[.]com/tensorflow/tensorflow/releases/,” the researchers said. “An attacker that compromised one of these `GITHUB_TOKEN’s could add their own files to the Release Assets.”

On top of that, the contents:write permissions could be weaponized to push code directly to the TensorFlow repository by covertly injecting the malicious code into a feature branch and getting it merged into the main branch.

That’s not all. A threat actor could steal the AWS_PYPI_ACCOUNT_TOKEN used in the release workflow to authenticate to the Python Package Index (PyPI) registry and upload a malicious Python .whl file, effectively poisoning the package.

“An attacker could also use the GITHUB_TOKEN’s permissions to compromise the JENKINS_TOKEN repository secret, even though this secret was not used within workflows that ran on the self-hosted runners,” the researchers said.

Following responsible disclosure on August 1, 2023, the shortcomings were addressed by the project maintainers as of December 20, 2023, by requiring approval for workflows submitted from all fork pull requests and by changing the GITHUB_TOKEN permissions to read-only for workflows that ran on self-hosted runners.

“Similar CI/CD attacks are on the rise as more organizations automate their CI/CD processes,” the researchers said.

“AI/ML companies are particularly vulnerable as many of their workflows require significant compute power that isn’t available in GitHub-hosted runners, thus the prevalence of self-hosted runners.”

The disclosure comes as both researchers revealed that several public GitHub repositories, including those associated with Chia Networks, Microsoft DeepSpeed, and PyTorch, are susceptible to malicious code injection via self-hosted GitHub Actions runners.

Jan 04, 2024The Hacker NewsEthical Hacking / Vulnerability Assessment

Section four of the “Executive Order on Improving the Nation’s Cybersecurity” introduced a lot of people in tech to the concept of a “Software Supply Chain” and securing it. If you make software and ever hope to sell it to one or more federal agencies, you have to pay attention to this. Even if you never plan to sell to a government, understanding your Software Supply Chain and learning how to secure it will pay dividends in a stronger security footing and the benefits it provides. This article will look at three ways to supercharge your Software Supply Chain Security.

What is your Software Supply Chain? It’s essentially everything that goes into building a piece of software: from the IDE in which the developer writes code, to the third-party dependencies, to the build systems and scripts, to the hardware and operating system on which it runs. Instabilities and vulnerabilities can be introduced, maliciously or not, from inception to deployment and even beyond.

1: Keep Your Secrets Secret

Some of the bigger cybersecurity incidents of 2023 occurred because bad actors found secrets in plain text. Secrets, in this context, are things like username and password combos, API keys, signing keys, and more. These keys to corporate kingdoms were found laying around where they shouldn’t be.

Sourcegraph got pwned when they published code to a public instance containing a hardcoded access token. The token was used to create other accounts and give people free access to the Sourcegraph API. A hacker group got access to a Microsoft internal debugging environment and found a signing key in a crash dump that let them create email credentials.

Tools like GitGuardian allow you to check your code, both legacy and bleeding edge, for accidentally published secrets or attempts to publish them. It’s important to know which secrets might have been released and remediate them, as well as put in safeguards in the form of automated tools and code reviews to ensure other keys don’t get out.

2: Use SCA to Help Build Your BOM

In manufacturing, a Bill of Materials (BOM) is a comprehensive inventory that includes all raw materials, components, and guidelines necessary for the construction, manufacturing, or repair of a product or service. Both cybersecurity regulations and best practices are embracing the idea of a software BOM that provides transparency and provenance of all the pieces that go into building your software.

But you just can’t build a BOM from your list of declared dependencies.

Package repositories like NPM, PyPI and the incorporation of open-source frameworks and libraries were hailed for making software development more efficient by not having to reinvent the wheels. Instead, developers could find free packages that implemented the functionality they needed and incorporate them into their software easily.

They also exposed developers to a growing web of dependencies. You may find it feels like “turtles all the way down” as your dependencies have dependencies that have dependencies… You might even have sub-dependencies on four different releases of the same package, all of which have different vulnerabilities.

Software Composition Analysis tools automatically scan your project’s codebase and identify all the external components you’re using, including all the turtles as far down as they go. They then perform checks to make sure these components are up-to-date, secure, and compliant with licensing requirements.

This not only helps to identify which dependencies have known exploits so you can update or replace them, but that’s a big help when you need to generate a clean BOM for inspection by potential customers and regulators.

3: Go Hack Yourself

Ethical hacking is older than most recent CS grads. As stated in a recent webinar on ethical hacking, it is “identifying and exploiting vulnerabilities in computer systems or networks in a responsible and lawful manner.” Note the emphasis on “responsible” and “lawful.”

Essentially, ethical hackers use most of the same techniques as “black hat” hackers to find and exploit vulnerabilities in a system. The difference that cannot be stressed enough is that they do it with permission. They stick to the systems they’ve been given permission to hack, then document everything so that their discoveries can be reproduced and analyzed by the team/client to whom they report them.

While this can often come in a later stage in the development process, it’s important. If they can determine your dependencies and do their own SCA that identifies vulnerable dependencies, game over. If they can find an unguarded point of entry, game over. If they test a web app and find debug code outputting confidential output in the console, game over. Some vulnerabilities can be show-stoppers, some might be just needing to remove a line of debug code.

Making ethical hacking part of the release process, joining bug bounty programs, and more can make sure you’re fixing things before you’re having to apologize for them, report them to regulators, and do clean-up.

Summary

Whether you’re trying to please regulators or customers, beefing up your Software Supply Chain Security will let you spend more time selling your software and less time apologizing for it. And while these three tips get you a good foundation, you can find a lot more in the SLSA security framework. Working the framework and securing your supply chain is how you get (in the words of the SLSA site) “from ‘safe enough’ to being as resilient as possible, at any link in the chain.”

Dec 15, 2023NewsroomCryptocurrency / Malware

Crypto hardware wallet maker Ledger published a new version of its “@ledgerhq/connect-kit” npm module after unidentified threat actors pushed malicious code that led to the theft of more than $600,000 in virtual assets.

The compromise was the result of a former employee falling victim to a phishing attack, the company said in a statement.

This allowed the attackers to gain access to Ledger’s npm account and upload three malicious versions of the module – 1.1.5, 1.1.6, and 1.1.7 — and propagate crypto drainer malware to other applications that are dependent on the module, resulting in a software supply chain breach.

“The malicious code used a rogue WalletConnect project to reroute funds to a hacker wallet,” Ledger said.

Connect Kit, as the name implies, makes it possible to connect DApps (short decentralized applications) to Ledger’s hardware wallets.

According to security firm Sonatype, version 1.1.7 directly embedded a wallet-draining payload to execute unauthorized transactions in order to transfer digital assets to an actor-controlled wallet.

Versions 1.1.5 and 1.1.6, while lacking an embedded drainer, were modified to download a secondary npm package, identified as 2e6d5f64604be31, which acted as a crypto drainer. The module is still available for download as of writing.

“Once installed into your software, the malware presents the users with a fake modal prompt that invites them to connect wallets,” Sonatype researcher Ilkka Turunen said. “Once the users click through this modal, the malware begins draining funds from the connected wallets.”

The malicious file is estimated to have been live for around five hours, although the active exploitation window during which the funds were drained was limited to a period of less than two hours.

Revoke.cash, which was one of the companies affected by the incident, said Ledger lacked two-factor authentication (2FA) protections for its deployment systems, thereby allowing an attacker to use the developer’s compromised account to publish a malicious version of the software.

Ledger has since removed all three malicious versions of Connect Kit from npm and published 1.1.8 to mitigate the issue. It has also reported the threat actor’s wallet addresses and noted that stablecoin issuer Tether has frozen the stolen funds.

If anything, the development underscores the continued targeting of open-source ecosystems, with software registries such as PyPI and npm increasingly used as vectors for installing malware through supply chain attacks.

“The specific targeting of cryptocurrency assets demonstrates the evolving tactics of cybercriminals to achieve significant financial gains within the space of hours, directly monetising their malware,” Turunen noted.

Update

The fraudulent npm module in question, 2e6d5f64604be31, has now been removed from the package repository by its security team for containing “malicious code.”