Aqua Nautilus最新報告指出，PowerShell Gallery關于包名稱和所有者的政策中仍然存在重大缺陷，這些缺陷使得在該注冊表中不可避免地發(fā)生typosquatting攻擊，同時也使用戶極難辨別軟件包的真實所有者。最終，這些缺陷將為潛在的針對注冊表龐大用戶群的供應鏈攻擊鋪平道路。

PowerShell Gallery模塊通常用作云部署過程的一部分，特別是在AWS和Azure中流行，用于和云資源進行交互和管理。因此，安裝惡意模塊對組織來說可能是致命的。此外，攻擊者還可以利用另一個缺陷，以發(fā)現(xiàn)未列出的包和注冊表中已刪除的秘密。

盡管研究人員已經(jīng)向微軟安全響應中心報告了這些漏洞，并確認了所報告的行為和正在進行的修復，但截至2023年8月，這些問題仍然存在，這表明微軟方面并未實施任何切實的更改。

在本文中，我們將詳細分析這些缺陷，討論其風險，并提出一些緩解措施。

PowerShell Gallery中的三大缺陷

PowerShell是微軟開發(fā)的命令行shell和腳本語言，用于自動化任務和系統(tǒng)管理。PowerShell Gallery是用于分享和獲取PowerShell代碼（如PowerShell 模塊、腳本和DSC資源）的中央存儲庫。這些軟件包由不同的實體編寫，包括微軟、AWS、VMware和PowerShell社區(qū)的其他成員。

PowerShell Gallery的重要性不言而喻。然而，最近，研究人員在其中發(fā)現(xiàn)了三個關鍵漏洞。接下來，我們將深入研究它們：

缺陷1：松散的包名稱策略

研究發(fā)現(xiàn)，PowerShell Gallery有一個寬松的模塊名稱策略。例如，在分析過程中，研究人員已經(jīng)確定PowerShell Gallery缺乏任何形式的防止模塊TypoSquatting攻擊的防護措施，這與其他流行的包管理器（如npm）截然不同。

這個漏洞可能為供應鏈攻擊打開大門，使惡意行為者能夠上傳惡意的PowerShell模塊，這些模塊在毫無戒心的用戶看來是無比真實的。因此，他們可以在其他用戶的系統(tǒng)上執(zhí)行代碼，特別是在云環(huán)境中。

研究人員發(fā)現(xiàn)，大多數(shù)Azure包都是用Az.<package_name>模式創(chuàng)建的。但是，非常流行的模塊“Aztable”并不符合這一慣例，因為缺少了點（并非Az.）。AzTable是一個關鍵模塊，它提供了操作表的示例函數(shù)（在Azure Storage Table上添加、檢索和更新實體）。考慮到其在生產(chǎn)中起到的關鍵作用，它已積累超過1000萬的下載量也就不足為奇了。

但是，如果有人創(chuàng)建了另一個遵循慣例的“Az.Table”新模塊怎么辦？這個新模塊可以欺騙那些安裝完全在攻擊者控制下的PowerShell模塊的用戶。

“Az.”前綴可能看起來像一個只有包所有者才能控制的作用域，類似于其他平臺（例如npm）。但是，這里的情況并非如此，任何人都可以控制其包的前綴。

需要注意的是，這個缺陷超出了前面提到的特定示例，因為PowerShell Gallery注冊表中有許多包可以使用這個向量和混淆來欺騙。

其他包管理器（如npm）會采取措施來降低這種風險，并禁止攻擊者對流行的包名執(zhí)行鍵入。這里有一些來自npm博客的例子來說明它是如何工作的。

由于“react-native”的存在，沒有人可以發(fā)布這樣的變體：

• reactnative
• react_native
• native

類似地，因為“jsonstream”的存在，所以沒有人可以發(fā)布這樣的變體：

• json-stream
• stream
• json_stream
• js-on-stream

如果攻擊者或其他人試圖這樣做，服務器將以“403 Forbidden”狀態(tài)響應，表明新包名稱與現(xiàn)有包名稱太相似。

缺陷2：在PowerShell Gallery中偽造模塊元數(shù)據(jù)

這一缺陷導致惡意人員嗅探模塊的元數(shù)據(jù)，包括作者、版權和描述字段，使其看似更加合法，從而誘騙不知情用戶安裝。

研究人員指出，用戶判斷真正作者/所有者的唯一方法是打開“Package Details”標簽。然而，這只會將他們引向虛假作者的配置文件，因為攻擊者在PowerShell Gallery中創(chuàng)建用戶時可以自由選擇任何名稱。因此，確定PowerShell庫中PowerShell模塊的實際作者是一項極具挑戰(zhàn)性的任務。

【合法的 VS 偽造的（Masquerading）】

盡管Microsoft在PowerShell Gallery文檔中建議稱，“Author”（作者）元數(shù)據(jù)是由包的作者提供的，且沒有經(jīng)過Microsoft的驗證，只有“Owner”（所有者）字段與用于發(fā)布包的Gallery帳戶強綁定，這使得它比“Author”字段更值得信賴。但默認情況下顯示Author字段，隱藏Owner字段，這給已經(jīng)感到困惑的用戶增加了挑戰(zhàn)。

唯一可用的指標是可以操縱的下載計數(shù)和最后發(fā)布日期。只有當用戶打開默認隱藏的“Package Details”部分時，他們才能獲得上傳Masquerading模塊的用戶的真實個人資料。

缺陷3：暴露未列出的模塊及其秘密

在對PowerShell Gallery的持續(xù)研究中，研究人員還發(fā)現(xiàn)了另一個漏洞，它允許攻擊者枚舉所有包的名稱和版本，包括那些未列出且試圖隱藏的軟件包。

這個缺陷的重要性在于它能夠暴露未列出的包，這些包通常出于各種原因被隱藏在公眾視野之外。

微軟關于PowerShell Gallery中未列出包的官方文檔表明，未列出的包不會出現(xiàn)在搜索API中，只有那些已經(jīng)知道確切包名稱和版本的人才可以訪問和下載未列出的包。然而，我們的研究結果推翻了這一假設。

該漏洞會帶來安全風險，因為它允許對敏感信息進行未經(jīng)授權的訪問。用戶無意中暴露了PowerShell模塊特定版本中的秘密，并試圖通過刪除仍然暴露于潛在漏洞的包來隱藏這些秘密。

在訪問URL“https://www.powershellgallery.com/api/v2/Packages”時，研究人員發(fā)現(xiàn)了一個XML文件，其中包含關于PowerShell Gallery中所有包的全面信息。令人驚訝的是，這包括列出的和未列出的包，以及它們各自的版本。

通過利用位于xml響應底部的API鏈接，特別是“https://www.powershellgallery.com/api/v2/Packages?$skip=number”，攻擊者可以不受限制地訪問完整的PowerShell包數(shù)據(jù)庫，包括相關版本。這種不受控制的訪問為惡意參與者提供了在未列出的包中搜索潛在敏感信息的能力。因此，任何包含機密數(shù)據(jù)的未列出的包都非常容易受到損害。

在研究報告中，研究人員列舉了一些未列出的秘密包，并驚訝地看到發(fā)布者錯誤地上傳了包含Github API密鑰的.git/config文件，或者包含Gallery本身API密鑰的模塊發(fā)布腳本。其中一項機密屬于一家要求匿名的大型科技公司。

【一個帶有明文API密鑰的發(fā)布腳本】

這些發(fā)布者注意到了他們的錯誤，并取消了該模塊的特定版本，認為他們已經(jīng)降低了風險。然而，使用我們上面展示的API，任何人都可以輕松地接收包的所有版本，包括未列出的版本，并列舉它們作為秘密。

需要注意的是，PowerShell Gallery中的包所有者可以選擇請求刪除他們的包，而不是取消它們的列表。但是，此操作只能由gallery的支持團隊執(zhí)行。

概念驗證（PoC）

研究人員決定為缺陷1和2創(chuàng)建一個PoC，并上傳一個旨在模仿現(xiàn)有流行軟件包“AzTable”的完美復制品“Az.Table”。

作為PoC的一部分，研究人員利用了PowerShell“ScriptsToProcess”元素，它允許在導入PowerShell模塊期間執(zhí)行腳本。請注意，這與npm preinstall/postinstall的概念類似。

在“ScriptsToProcess”命令中，研究人員合并了一個收集基本元數(shù)據(jù)（包括主機名、pwd和whoami）的腳本。目的是跟蹤模擬包的下載，并在其導入時啟動回調(diào)。

在幾個小時內(nèi)，研究人員便收到了來自不同云服務的幾臺主機的回復，這強調(diào)了TypoSquatting的有效性，并強調(diào)了與這些安全漏洞相關的危險。

披露時間表

2022年9月27日——Aqua研究團隊向MSRC報告了缺陷。

2022年10月20日——MSRC證實了研究人員報告的行為。

2022年11月2日——MSRC表示該問題已經(jīng)修復（無法在在線服務中提供產(chǎn)品修復的詳細信息）。

2022年12月26日——Aqua研究團隊復制了缺陷（并沒有預防措施）。

2023年1月3日——Aqua研究團隊重新上述了關于MSRC缺陷的報告。

2023年1月3日——MSRC再次證實研究人員報告的行為。

2023年1月10日——MSRC將該報告標記為“已解決”。

2023年1月15日—— MSRC回應稱，“工程團隊仍在努力修復typposquatting和軟件包細節(jié)欺騙。我們目前有一個短期的解決方案，用于發(fā)布到PSGallery的新模塊。”

2023年3月7日——MSRC回應稱，“響應性修復已經(jīng)到位”。

2023年8月16日——缺陷仍可用。

緩解和建議

如上所述，這個問題仍然是可重復出現(xiàn)的，所以在使用PowerShell Gallery中的包時需要更加注意和謹慎，直到微軟修復了這些缺陷。在此之前，安全專家提供了一些可行建議：

• 平臺責任：首先，最好的解決方案是平臺修復缺陷。這可能包括實現(xiàn)嚴格的包命名策略、驗證作者、限制對未列出的包的訪問，以及改進包所有權的可見性。當然，作為用戶，我們要對我們安裝的東西負責，我們需要在安裝之前檢查我們下載的代碼。然而，平臺的責任是盡可能地減少攻擊面。
• 使用簽名PowerShell模塊策略：考慮到在PowerShellgallery中發(fā)現(xiàn)的漏洞，建議強制執(zhí)行只允許執(zhí)行簽名腳本的策略。這確保了任何腳本或模塊（包括從PowerShell Gallery下載的腳本或模塊）在運行之前必須使用受信任的證書進行數(shù)字簽名，從而為防止惡意腳本的執(zhí)行提供了額外的安全層。
• 使用可信私有存儲庫：這可以確保存儲庫具有有限的互聯(lián)網(wǎng)訪問和用戶訪問，用戶可以在其中管理和使用自己的私有模塊，同時還可以以更安全的方式存儲來自公共PowerShell gallery的模塊。
• 定期掃描敏感數(shù)據(jù)：這包括掃描模塊源代碼中的秘密，并在存儲和管理模塊代碼的存儲庫中進行定期安全評估。為了防止攻擊者利用，及時處理和輪換任何暴露的秘密也是很重要的。
• 在云環(huán)境中檢測可疑行為：實現(xiàn)一個強大的連續(xù)監(jiān)控系統(tǒng)，在CI/CD管道和云基礎設施中實時跟蹤活動。這種主動的方法不僅允許組織檢測潛在的威脅和可疑行為，還能夠檢測與已建立的正常配置文件的任何偏差。

原文鏈接：https://blog.aquasec.com/powerhell-active-flaws-in-powershell-gallery-expose-users-to-attacks