Skip to main content

A team of security researchers from Aqua recently uncovered three critical vulnerabilities in Microsoft’s PowerShell Gallery that could enable attackers to conduct devastating supply chain attacks. Mor Weinberger, Yakir Kadkoda, and Ilay Goldman revealed flaws that allow threat actors to spoof legitimate packages and gain access to deleted secrets.

The researchers were able to upload a fake package mimicking a popular Azure module that received callbacks from numerous cloud environments. This highlights the ease with which attackers could potentially compromise countless organizations by poisoning the repository.

Despite responsible disclosure, Microsoft is yet to implement comprehensive fixes to the packaging system used by millions. The flaws enable typosquatting, metadata spoofing, and exposure of unpublished packages. Until addressed, PowerShell Gallery users are advised to implement cautionary measures to avoid becoming victims.

In this blog, we provide an overview of the flaws, their implications, and suggested countermeasures both vendors and users can take. Understanding these vulnerabilities is important given the ubiquitous use of PowerShell Gallery for cloud automation and system management across industries. We aim to raise awareness so organizations can ensure security hygiene and avoid supply chain compromise.

A Short Note About PowerShell Gallery and PowerShellGet

The PowerShell Gallery is the central repository for PowerShell content like scripts, modules, DSC resources etc. It contains packages authored by Microsoft, AWS, and the PowerShell community.

The PowerShellGet module provides commands to discover, install, update and publish packages from the gallery. It lets you search for useful PowerShell modules and scripts to automate tasks. PowerShellGet depends on the gallery as a source for packages.

Together, PowerShellGet and the PowerShell Gallery enable easy sharing and consumption of reusable PowerShell code to simplify management and automation.

Researchers talk about the three flaws in PowerShell Gallery in their discloser are:

Lax Package Naming Policy

The first major flaw uncovered by the researchers pertains to the package naming policy enforced by PowerShell Gallery. They found that the gallery allows arbitrary package names without any effective protection against typosquatting or spoofing of existing popular modules.

For instance, the Azure module named “AzTable” with over 10 million downloads could easily be impersonated with a similarly named package like “Az.Table” or “AzureTable”. The “.Az” prefix is commonly used for Azure modules, so this naming convention could trick users into installing the spoofed malicious version instead of the real module.

Other package registries like npm have strict moniker rules that prevent typographical variations of existing package names from being registered. However, PowerShell Gallery lacks any such protections. This enables attackers to freely capitalize on the name recognition of popular packages by uploading spoofed modules.

Once installed by unsuspecting users, especially system administrators or developers, these malicious packages can be used to execute arbitrary code within their environments. The researchers demonstrated this by uploading a fake Azure module that received several callbacks from cloud servers where it was installed.

This severe flaw provides attackers an easy avenue to conduct devastating supply chain attacks impacting thousands of organizations through poisoning of the PowerShell Gallery repository.

Flaw in Lax Package Naming Policy of PowerShell Gallery

Source: Aqua

Metadata Spoofing

The second flaw exposes the PowerShell Gallery to metadata spoofing due to lack of enforced integrity checks. The landing page of modules in the gallery allows arbitrary values to be entered for metadata fields like Author, Copyright, and Description without verification.

By entering an authoritative name like Microsoft or AWS in the Author field, attackers can make packages appear as if they were published by legitimate and trusted entities. The average user has no means to discern the actual package owner or publisher purely from the gallery page.

The documentation suggests using the Owner field, which links to the publishing account for verification. However, this is hidden by default, while the fakeable Author field is prominently displayed, misleading users. The only visible indicators are download count and last updated date, both of which can also be manipulated.

This flaw allows attackers to masquerade as trusted sources and maximize the deception of poisoned packages tailored using forged metadata aimed at tricking potential targets.

Metadata Spoofing in PowerShell Gallery

Source: Aqua

Access to Deleted Secrets

The final major finding revealed that packages marked as unpublished or unlisted remain discoverable and accessible through the gallery’s API. The documentation states that unlisting prevents packages from showing in search results.

However, the researchers demonstrated that all package names and versions remain enumerated in API responses, including those supposedly unlisted. This grants unauthorized access to unpublished packages, which often contain sensitive information removed intentionally by the publisher.

By accidentally uploading passwords, keys, or other secrets and then unlisting the versions, publishers expect to rectify the mistake. But the contents remain exposed via API to potential attackers.

This flaw completely negates unlisting as an effective remediation for accidental secret exposure. It also increases the attack surface by permitting access to supposedly deleted packages containing valuable reconnaissance data.

Access to Deleted Secrets in PowerShell Gallery

Source: Aqua

Together, these three flaws provide enormous opportunities for threat actors to conduct supply chain attacks by compromising the PowerShell Gallery at scale. They enable undetected injection of spoofed malicious packages, which are impossible to differentiate from legitimate trusted modules.

Countermeasures for Vendor and Users

Here are some common countermeasures that both Vendors and Users should consider to effectively mitigate the flaws.

Vendor Side Mitigations

To truly address these flaws at the root requires fixes and enhanced security from the vendor side:

  • Enforce strict package naming rules that prohibit typosquatting or spoofing existing names
  • Implement mandatory author verification, including validation of identity
  • Improve visibility of actual package ownership through verified badges and prominent display
  • Restrict API access to unlisted packages or properly scrub sensitive information
  • Perform comprehensive security audits to uncover additional vulnerabilities
  • Establish unified baseline standards for packaging security across the industry
  • Provide transparency on security issues and fixes to maintain user trust

User Side Mitigations

Until proper vendor fixes are implemented, PowerShell Gallery users can apply these cautionary measures to avoid becoming a victim:

  • Enforce a policy for only signed PowerShell modules to be installed from the gallery
  • Maintain private repositories with controlled internet and user access
  • Routinely scan module source code for exposed secrets before publishing
  • Monitor infrastructure and environments for anomalous activities indicating compromise
  • Mandate multi-factor authentication for publishing and changes to packages
  • Perform extensive input validation and sanitization for any data originating from the gallery
  • Consider the reputability of publishers and manually vet packages when possible
  • Report any suspicious packages or behavior on the platform to the vendor

With the vendor taking responsibility for securing the platform, users must also implement prudent measures to minimize the supply chain attack surface. Ensuring hygienic practices, limiting package origins, and monitoring for abnormalities will help avoid falling prey until the issues are fixed.

Bottom Line

The uncovered flaws in PowerShell Gallery pose severe supply chain attack risks to its extensive user base until remediated. While Microsoft addresses these issues, users are advised to implement the suggested defensive measures. Secure access control and continuous monitoring for anomalies is key to avoid being victimized. The findings highlight the need for unified baseline security standards across open-source platforms. With growing dependence on public repositories, maintaining their integrity is essential.

Leave a Reply