Report: PowerShell Gallery susceptible to typosquatting and other package-management attacks

Researchers are warning in a new report that PowerShell Gallery (PSGallery), the central repository for PowerShell modules and scripts, lacks package name and ownership protections that other popular registries such as npm put in place to prevent typosquatting attacks.

Furthermore, the report found that it is possible to find and access PowerShell Gallery packages that have been unlisted by their authors because they potentially contain sensitive information.

“PowerShell Gallery modules are commonly used as part of the cloud deployment process, especially popular around AWS and Azure, to interact with and manage cloud resources,” researchers from Aqua Security said in their report. “Therefore, the installation of a malicious module could be fatal to organizations.”

Typosquatting, brandjacking, and other software supply chain attacks that aim to trick developers to download rogue packages and modules from public repositories have exploded in recent years because they provide an easy route for attackers inside enterprise networks. As a result, the central registries for various programming languages such as npm, PyPI, NuGet, Java Central have been forced to deploy various defenses to limit abuse of their services.

PowerShell Gallery doesn’t block name variations

Typosquatting is an attack technique that involves registering malicious packages with names that are similar to those of existing popular packages. This is a passive attack that relies on developers making mistakes -- typos -- when typing package names in their scripts and automated tools.

PowerShell Gallery is run by Microsoft and some of the most popular modules published on it are authored by Microsoft teams, or by large technology companies such as Amazon Web Services (AWS) or VMware.

PowerShell itself is a powerful scripting language and interface built into Windows systems that was designed for automating system administration tasks. Unlike other programming languages, it’s not used for software development, but for deploying, managing, and monitoring IT infrastructure resources, including in cloud environments.

PowerShell modules extend the standard PowerShell command line interface with functionality for specific tasks. For example, on PowerShell Gallery there are many modules that allow DevOps engineers to use Microsoft Azure features via PowerShell. Many of these modules follow the “Az.<package_name>” convention -- for example Az.Accounts, Az.Storage, Az.KeyVault, Az.Resources.

Naming convention is not enforced

However, this naming convention is not strictly enforced, which can be confusing for users who employ repositories for other programming languages and where a prefix followed by a dot in a package name is known as a “scope” and is tied to a particular author or organization. On PSGallery, while many of the Az.<package_name> modules are authored by Microsoft teams, anyone can create packages with this prefix.

Moreover, not all Azure-related packages follow this naming convention. For example, AzTable (no dot) is a module created by a Microsoft developer that provides sample functions for manipulating entities in the Azure Storage Table service. The module has more than 10 million downloads.

The Aqua Security researchers were therefore able to create a rogue package called Az.Table (with dot) that is a replica of AzTable with some added functionality in the post-installation process, where it executed various commands to collect information about the system and sent it back to them. However, in a real attack, the commands could have had a much more malicious goal.

“As part of our PoC [proof-of-concept], we leveraged the PowerShell ‘ScriptsToProcess’ manifest elements, which enables the execution of scripts during the import of the PowerShell module,” the researchers said. “Mind that this is a similar concept to the npm preinstall/postinstall. Within the ScriptsToProcess command, we incorporated a script that gathered basic metadata, including the hostname, pwd, and whoami.”

After publishing the module, the researchers started receiving information collected from servers belonging to large companies, some of which were deployed on major cloud services platforms like Google Cloud, AWS, and Microsoft Azure. This indicates that it’s a viable attack and developers will easily be confused and tricked due to the inconsistency in naming policy.

By comparison, the npm registry for JavaScript packages blocks similar names by default when a package is registered. For example, because the “react-native” package exists, no one can register very close variations like reactnative, react_native or react.native. This protection is missing from PowerShell Gallery.

Confusing ownership information

Moreover, PowerShell Gallery gives module owners complete control over ownership metadata displayed alongside a package such as author name, copyright, and description. This allowed the Aqua Security researchers to create a rogue package, AzKeyVault (no dot), that lists the author and copyright as Microsoft Corp., just like the legitimate Az.KeyVault module.

In order to access the real owner’s PSGallery profile, a user would have to expand the Package Details section which is a collapsed (hidden) section of the page by default, and which lists the Owner information.

“Microsoft suggests in the PowerShell Gallery documentation that the Author metadata is provided by the package’s author and is not verified by Microsoft, and only the Owner field is strongly tied to the Gallery account used to publish the package, which makes it more trustworthy than the Author field,” the researchers said. “The Author field is shown by default, while the Owner field is hidden by default, adding to the challenges faced by already confused users.”

Essentially, the only indication that a package might be a rogue copy of a legitimate one would be the subtle name difference and the download count, which would be low for a newly published package. However, the download count could potentially be manipulated too by having automated bots to download the package.

Exposing unlisted packages and their secrets

A third issue identified by the Aqua Security researchers is that it’s possible for an attacker to discover unlisted packages or versions of packages even though the PowerShell Gallery documentation says such packages should not appear in search results on the site or through the API. To be clear, downloading these packages do not require additional authentication or special permissions, but the user would have to know the exact package name and version in order to access them.

The issue is that this encourages package authors to use the unlisting feature if they accidentally publish secret information as part of a version release and they might feel that’s enough protection to correct the mistake. The Aqua Security researchers found a way to enumerate and expose unlisted packages through the API.

“During our research, we enumerated some of the unlisted packages for secrets, and we were surprised to see publishers who by mistake uploaded their .git/config file containing API keys of Github, or a publishing script of the module containing the API key to the Gallery itself,” the researcher said. “One of these secrets belonged to a big technology company which requested to remain anonymous.”

Deleting a package instead of unlisting it can be done on PowerShell Gallery, but this operation needs to be performed by the PSGallery support team, so it’s not an automated process. Therefore, module authors are more likely to simply unlist it than going through the more involved deletion process.

Recommended steps to mitigate the vulnerability

Aqua Security claims to have reported these issues to Microsoft twice since September 2022 and each time they were told changes were made and some fixes were put in place to mitigate the risks. However, as of August 8, 2023 the researchers claimed the issues they found remain reproducible. As a result, they recommended the following mitigation steps:

• First and foremost, the best solution would be for the platform to fix the flaws. This could include implementing a strict package naming policy, verifying authorship, restricting access to unlisted packages, and improving the visibility of package ownership. Of course, as users, we are responsible for what we install, and we need to check the code we download before installing it. However, the platform’s responsibility is to reduce the attack surface as much as possible.
• Given the vulnerabilities identified in the PowerShell Gallery, it’s recommended to enforce a policy that only allows the execution of signed scripts. This ensures that any script or module, including those downloaded from the PowerShell Gallery, must be digitally signed with a trusted certificate before they can be run, providing an additional layer of security against the execution of malicious scripts.
• Use Trusted Private Repository: This can ensure that the repository has limited internet access and user access, where you can manage and consume your private modules while also storing modules from the public PowerShell Gallery in a more secure way.
• Regularly Scan for Sensitive Data: This includes scanning the modules’ source code for secrets and conducting regular security assessments in the repositories that store and manage the module's code. It's important to promptly address and rotate any exposed secrets in order to prevent exploitation by attackers.
• Implement a robust continuous monitoring system that tracks activities in real time across your CI/CD pipelines and cloud infrastructure. This proactive approach allows you to detect potential threats and suspicious behavior. It is also capable of detecting any deviations from established normal profiles.