Recent findings by Aqua Nautilus have exposed significant flaws that are still active in the PowerShell Gallery’s policy regarding package names and owners. These flaws make typosquatting attacks inevitable in this registry, while also making it extremely difficult for users to identify the true owner of a package. Consequently, these flaws pave the way for potential supply chain attacks on the registry’s vast user base.
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. Therefore, the installation of a malicious module could be fatal to organizations.
Moreover, attackers can exploit another flaw, allowing them to discover unlisted packages and uncover deleted secrets within the registry, which users attempt to hide by unlisting their packages.
These findings have enabled us to create a proof of concept (POC) and mimic popular Microsoft PowerShell modules, which have been downloaded millions of times. These forge modules have been downloaded by various organizations across a range of cloud services.
Despite reporting the flaws to the Microsoft Security Response Center on two separate occasions, with confirmation of the reported behavior and claims of ongoing fixes, as of August 2023, the issues remain reproducible, indicating that no tangible changes have been implemented.
In this blog, we will describe the flaws, discuss the risks, and suggest some mitigations.
What is PowerShell Gallery?
PowerShell is a Microsoft-developed command-line shell and scripting language for automating tasks and system management. The PowerShell Gallery is the central repository for PowerShell content.
It hosts PowerShell scripts, modules containing PowerShell cmdlets and more.
These packages are authored by various entities, including Microsoft, AWS, VMware and other members of the PowerShell community.
To install PowerShell packages from the PowerShell Gallery, you need to use the PowerShellGet module, which contains cmdlets that utilize the PowerShell Gallery for discovering, installing, updating, and publishing PowerShell packages.
In this example, we will demonstrate the installation of the AZ.Accounts (which is used for Accounts credential management) using the PowerShell CLI.
DevOps and engineers leverage PowerShell Gallery modules as part of cloud deployment, similar to other package registries integrated into the development lifecycle.
Furthermore, certain packages receive millions of downloads, resulting in a total package download count of over nine billion in this registry.
Now that we have established the significance of the PowerShell Gallery, we have made the decision to conduct research on the existence of flaws within the gallery that could potentially be exploited by attackers. We have identified 3 flaws in the gallery. Next, we will delve into them:
Flaw 1: Lax package name policy
The PowerShell Gallery has a lax module name policy. For instance, during our research we have established that the PowerShell Gallery lacks any form of protection against TypoSquatting of modules in contrary to other popular package managers such as npm.
In addition to that there are some conventions that have become very popular. For example, most Azure-related packages are created with a specific pattern – “Az.<package_name>”. Which resembles the scope concept and may confuse some users.
Some modules don’t follow these conventions, but this doesn’t impact their popularity as some of them have become really popular.
This flaw may open the door for supply chain attacks, enabling malicious actors to upload malicious PowerShell modules that appear genuine to unsuspecting users. Consequently, they can execute code on other users’ systems and specifically in cloud environments.
In our research we explored this further. As mentioned above most Azure packages are created with this pattern – Az.<package_name>. We found that the highly popular module Aztable is not aligned with this convention, since the dot is missing. AzTable is a key module that provides sample functions to manipulate tables (add, retrieve and update entities on Azure Storage Table). No wonder it has accumulated more than 10 million downloads, since it has a key role in production.
But what if someone creates another new module that follows the convention meaning Az.Table. This new module can deceive users who follow the convention to install a PowerShell module which is totally under the control of an attacker.
The Az. prefix may look like a scope that only the package owner can control, similar to other platforms (for example, npm). However, that’s not the case here, and anyone can control the prefix of his package.
It’s important to note that this flaw extends beyond the specific example mentioned, as there are numerous packages within the PowerShell Gallery registry that can be spoofed using this vector and confusion.
Other package managers like npm take steps to mitigate this risk and disallow attackers from performing typosquatting against popular package names. You can read more about npm Package Moniker rules.
Here are some examples from the npm blog to illustrate how this works.
Due to the existence of react-native no one can publish variations like:
reactnativereact_nativereact.native
Similarly, because jsonstream exists, no one can publish variations like:
json-streamjson.streamjson_streamjs-on-stream
If an attacker or someone tries to do so, the server will respond with a 403 Forbidden status, indicating that the new package name is too similar to an existing package name.
Flaw 2: Forged Module Meta-data in PowerShell Gallery
When visiting a PowerShell module landing page, it is possible to fake almost every detail, including Author(s), Copyright, and Description fields, thereby making the spoofed package appear legitimate. One problematic aspect is the attacker’s ability to change the Author(s) field in a new malicious package.
Consequently, unsuspecting users who come across these malicious packages might be deceived into installing them because the attacker can make the package appear to be owned by an authoritative entity like Microsoft, AWS, etc. The only way for users to determine the real author/owner is to open the “Package Details” tab. However, this will only lead them to the profile of the fake author, as the attacker can freely choose any name when creating a user in the PowerShell Gallery. Therefore, determining the actual author of a PowerShell module in the PowerShell Gallery poses a challenging task.
| Legitimate | Masquerading |
Although 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 Author field is shown by default, while the Owner field is hidden by default, adding to the challenges faced by already confused users.
The only available indicators are the download count, which can be manipulated, and the last published date. Only when users open the Package Details section, which is hidden by default, will they get the real profile of the user who uploaded the Masquerading module.
| Legitimate | Masquerading |
Flaw 3: Exposing Unlisted Modules and Their Secrets
In our ongoing research of the PowerShell Gallery, we have discovered another flaw that allows attackers to enumerate all package names and versions, including those that are unlisted.
The significance of this flaw lies in its ability to expose unlisted packages, which are typically intended to be hidden from public view for various reasons.
Microsoft’s official documentation on unlisting packages in the PowerShell Gallery suggests that unlisted packages does not appear in the search API and only those who already know the exact package name and version can access and download an unlisted package. However, our findings challenge this assumption.
This flaw poses a security risk as it grants unauthorized access to sensitive information. Users who inadvertently exposed secrets in specific versions of the PowerShell module and attempted to hide them by unlisting the packages that are still exposed to potential exploitation.
How is this possible? Upon accessing the URL https://www.powershellgallery.com/api/v2/Packages we encountered an XML file containing comprehensive information about all packages within the PowerShell Gallery. Surprisingly, this included both listed and unlisted packages, along with their respective versions.
For instance, within the XML file, there is a reference to an unlisted package called Microsoft.Graph.Identity.Organization By extracting the package ID and version from the provided URL and inputting them into the subsequent URL.
We successfully verified that the package had been unlisted based on the displayed result and by the fact that it does not appear in the search API of the gallery. This process also unveiled additional versions of the package, for example Microsoft.Graph.Identity.Organization/0.5.0 and more.
By utilizing the API link located at the bottom of the xml response, specifically https://www.powershellgallery.com/api/v2/Packages?$skip=number an attacker can gain unrestricted access to the complete PowerShell package database, including associated versions. This uncontrolled access provides malicious actors with the ability to search for potentially sensitive information within unlisted packages. Consequently, any unlisted package that contains confidential data becomes highly susceptible to compromise.
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. One of these secrets belonged to a big technology company which requested to remain anonymous.
A publishing script with plaintext API key
These publishers noticed their mistake and unlisted that specific version of the module, thinking they have mitigated the risk. However, using the API we have shown above anyone can easily receive all the versions of a package including the unlisted ones and enumerate them for secrets.
It is important to note that package owners in the PowerShell Gallery have the option to request the deletion of their packages, instead of unlisting them. However, this action can only be performed by the support team of the gallery.
The POC
We decided to create a PoC for flaws 1 and 2 by uploading a package designed to imitate an existing popular one.
We uploaded the package named Az.Table, which is a replica of the popular AzTable package with over 10 million downloads.
This package was crafted as a nearly perfect replica of the original package.
As part of our PoC, we leveraged the PowerShell ScriptsToProcess manifest elements, which enables the execution of scripts during the import of the PowerShell module. 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.
The purpose was to track the downloads of the mimic package and initiate a callback upon its import.
Within a few hours, we received responses from several hosts across various cloud services, highlighting the effectiveness of TypoSquatting and emphasizing the dangers associated with these security flaws.
Consider the implications of an actual attacker utilizing a malicious PowerShell module to breach multiple cloud environments and compromise numerous organizations.
The severity of the impact will be fatal.
Disclosure timeline
- 27 September 2022 – Aqua Research team reported flaws to MSRC.
- 20 October 2022 – MSRC confirmed the behavior we reported.
- 2 November 2022 – MSRC stated that the issue has been fixed (cannot provide details of product fixes in Online Services).
- 26 December 2022 – We reproduced the flaws (no prevention).
- 03 January 2023 – Aqua Research team reopened the report about flaws MSRC.
- 03 January 2023 – MSRC confirmed the behavior we reported.
- 10 January 2023 – MSRC marked the report as Resolved.
- 15 January 2023 – MSRC responded, “The engineering team is still working on fixing the Typosquatting and package detail spoofing. We currently have a short-term solution in place for new modules published to PSGallery“.
- 07 March 2023 – MSRC responded, “Reactive fixes have been put in place”.
- 16 August 2023 – Flaws are still reproducible.
Mitigations and Suggestions
As we mentioned in the disclosure section, this issue is still reproducible, so you need to be more aware and cautious when using packages from the PowerShell Gallery until Microsoft fixes the flaws. However, we still have some mitigations and suggestions.
- Platform Responsibility: 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.
- Use Signed PowerShell Module Policy: 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.
- Detecting Suspicious Behavior in Cloud Environments: 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.
Summary
As we increasingly depend on open-source projects and registries, the security risks associated with them become more prominent. It’s crucial that flaws, like those highlighted in this blog, are addressed promptly. We urge all users to exercise caution when downloading modules/scripts from registries like the PowerShell Gallery.
The responsibility for securing users primarily lies with the platform. It’s essential that PowerShell Gallery, and similar platforms, take the necessary steps to enhance their security measures.
We also advocate for the establishment of unified security standards across different platforms. This would align the security levels of all open-source registries/platforms, ensuring a safer environment for users worldwide.
We hope our findings will lead to necessary improvements in the PowerShell Gallery, enhancing its security and reliability for its millions of users globally.
