Microsoft PowerShell Gallery Littered with Critical Vulnerabilities

If you give a hoot about code security, you already know that popular code-package managers and repertories, such as Node Package Manager (npm) and Python Package Index (PyPI), are overstuffed with vulnerabilities and the malware that goes with them. What none of us knew is that PowerShell Gallery, Microsoft’s central repository for sharing PowerShell code, including PowerShell modules, scripts and Desired State Configuration resources, has the same kind of problems. That’s what Aqua Security’s Aqua Nautilus found when they checked the Gallery’s policies and discovered numerous serious security risks.

Now, you may have thought that that would only be a worry for Windows shops, where PowerShell is the default command line interface. You’d be wrong. The PowerShell Gallery’s code is primarily used to manage cloud resources not just for Azure, but for other major cloud vendors such as Amazon Web Services (AWS).

These flaws make PowerShell code susceptible to typosquatting attacks. This can lead to the inadvertent installation of malicious modules, which could be catastrophic for organizations, given PowerShell Gallery modules’ wide adoption in the cloud deployment process.

But wait, there’s more!

Attackers can also exploit vulnerabilities to detect unlisted packages and expose deleted secrets.

Specifically, Aqua uncovered the following flaws:

• Lax Naming Policy: Unlike stringent naming policies in other package managers like, ironically enough, troubled npm, PowerShell Gallery lacks protection against typosquatting. For example, while most Azure-related packages follow the “Az.<package_name>” pattern, not all do. Attackers can spoof genuine-looking modules, potentially running malicious code on unsuspecting users’ systems.
• Authorship Spoofing: The landing pages of PowerShell modules can be manipulated to display fake details. The only credible details available to users, the download count and the last published date, can be easily manipulated.
• Exposing Unlisted Modules: Despite Microsoft’s official documentation suggesting that unlisted packages in PowerShell Gallery remain hidden from public view, Aqua Nautilus’s research points otherwise. They could access both listed and unlisted packages and their respective versions.

Is it really that bad? Yes, it is. Aqua Nautilus created a package, “Az.Table,” imitating the highly popular “AzTable” package. When downloaded, the mimic package could gather metadata. Need I say more?  putting light on the potential harm malicious entities could inflict using these vulnerabilities.

Surprisingly, even after these vulnerabilities were reported to Microsoft’s Security Response Center (MSRC) twice, there’s been no significant rectification. The problem was first reported on September  27, 2022, and then again on January 3, 2023. Both times, MSRC confirmed the flaws but claimed they’ve been fixed. They haven’t been. As of August 2023, Aqua Nautilus could still reproduce the issues.

You’d think Microsoft, with all its resources, would be far more proactive than the comparatively poor npm and PyPI. It seems you’d be wrong.

First and foremost, Aqua demands that Microsoft Fix The Problem. This could include implementing a strict package naming policy, verifying authorship, restricting access to unlisted packages, and improving the visibility of package ownership.

I agree. Microsoft must take this seriously before it blows up in a customer’s face and then on their own.  With Microsoft’s recent major security snafus, they can’t afford

But, what can we do in the meantime? Aqua suggests:

1. Use Signed PowerShell Module Policy: 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.
2. 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.
3. 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 to prevent exploitation by attackers.
4. 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.

Yes, that’s a lot of work. But, consider the potentially disastrous alternatives. I think you’ll agree that this is one time when security safety trumps short-term savings.

Steven J. Vaughan-Nichols, aka sjvn, has been writing about technology and the business of technology since CP/M-80 was the cutting-edge PC operating system, 300bps was a fast internet connection, WordStar was the state-of-the-art word processor, and we liked it.

Read more from Steven J. Vaughan-Nichols