A trio of PowerShell Gallery design flaws reported to Microsoft almost a year ago remain unfixed, leaving registry users vulnerable to typosquatting and supply chain attacks, according to Aqua Nautilus.
In a report issued Wednesday, the security shop's software engineer Mor Weinberger and flaw finders Yakir Kadkoda and Ilay Goldman said they tipped off Microsoft in late September.
Yet despite the IT goliath apparently confirming the existence of the flaws - and telling the Aqua team twice that fixes were in place and the issues had been resolved - as of today the bugs are still reproducible, it's claimed. The Aqua trio say they've made a proof-of-concept exploit for two of the three security issues.
The Windows giant did not immediately respond to The Register's inquiries, and we will update this story if or when we hear back.
Microsoft's PowerShell Gallery is a huge repository of scripts, modules, and desired state configuration (DCS) resources. It boasts it has had nearly 10 billion package downloads to date. This makes it an attractive target for miscreants: if they can abuse the gallery to get malicious code into people's deployments, there could be widespread compromises of information security as well as data theft.
The first problem has to do with PowerShell Gallery's module name policy. It is, we're told, all too easy for someone to create a package in the gallery with a name close to a legit package, have the bogus one stuffed with malware, and wait for developers, power users, and administrators to pull in the bad dependency.
"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," the three Aqua bods noted.
For instance: most official Microsoft Azure packages use a specific naming pattern "Az[dot]package_name," they explained, such as Az.Accounts. But one popular module maintained by a Microsoftie with more than 10 million downloads, Aztable, doesn't follow this pattern because it doesn't have the dot after "Az."
This makes it relatively easy for miscreants to pull off a typosquatting attack by uploading a new package named Az.Table — note the dot — and trick users into installing a malicious PowerShell module under the attacker's control. To prove the point the team did just that with a proof-of-concept module that phoned home from machines that had the package installed.
Within hours, they received responses from "several hosts across various cloud services, highlighting the effectiveness of typosquatting and emphasizing the dangers associated with these security flaws," the analysts wrote.
This flaw could be used to pull off a massive supply-chain attack, breach multiple clouds, and compromise many organizations, they opined: "The severity of the impact will be fatal."
Funnily enough, Microsoft must be aware of this issue – which does plague other code warehouses – because one of its engineers created Az.Table to catch typos of AzTable, though the package is unlisted, or hidden from search – more on that later.
The second issue exists in the landing pages for PowerShell modules – eg, this one – in that it's not immediately obvious who actually wrote and uploaded the resource.
This is because miscreants can upload a malicious package, and write whatever they want in the author, copyright, and description fields on the landing page. Thus anyone could create a bad package, and share in the gallery with Microsoft or AWS supplied as the author. If a user expands the "Package details" section of the page, they'll see a list of user accounts connected to that upload, but these profiles can spoofed, too.
As Aqua put it, "determining the actual author of a PowerShell module in the PowerShell Gallery poses a challenging task." It means it's a bit easier for crooks to masquerade bad packages as code from a legit, trusted developer.
The third flaw allows access to unlisted or hidden packages — such as those containing sensitive data — to anyone willing to do enough digging to find the occasional needle in a haystack.
Although unlisted packages are not supposed to appear in the gallery's search API, the Aqua team found an XML file at /api/v2/Packages that contained "comprehensive information about all packages within the PowerShell Gallery" including unlisted ones.
There's a URL at the end of the XML file of the format /api/v2/Packages?$skip=[number]. By varying [number], one can wade through every package, listed or unlisted, and their specific versions. This type of access could be especially useful to criminals looking for highly sensitive data to steal for extortion or espionage purposes, the researchers posit.
"This uncontrolled access provides malicious actors with the ability to search for potentially sensitive information within unlisted packages," the Aqua team said. "Consequently, any unlisted package that contains confidential data becomes highly susceptible to compromise."
They continued: "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."
As all three of these shortcomings are still present, according to Aqua, the researchers urge caution when using PowerShell Gallery "until Microsoft fixes the flaws."
We've seen that crooks will use typosquatting and other package repository scouring to infect developers and applications with malware; fingers crossed miscreants don't move from GitHub, NPM, PyPI and others to PowerShell Gallery. ®
0 Comments