重點摘要
- Trend™ Research 發現了 Axis Communications 不小心暴露在外的 Azure Storage Account 雲端登入憑證,這是一家專門生產網路攝影機、存取控管以及網路音訊裝置的實體保全與視訊監控廠商。這些登入憑證是在一個給客戶使用的 Autodesk® Revit® 擴充元件當中的已簽署 DLL 內發現。
- 此擴充元件的 MSI 安裝程式含有一些 .NET DLL 裡面就存放著 Storage Account 的登入憑證,包括:存取金鑰 (access key) 和 SAS 權杖 (token)。這些登入憑證萬一外流,很可能讓該廠商的三個儲存帳號遭到未經授權的讀取和寫入。這些帳號當中含有 MSI 安裝程式和 Autodesk Revit 建築模型檔案 (副檔名為 .RFA,也就是 Revit Family Architecture),因此有可能散播到其他客戶。
- Trend Zero Day Initiative™ (ZDI) 已經在 Autodesk Revit 當中發現多個遠端程式碼執行漏洞,這些漏洞可經由匯入惡意 RFA 檔案來觸發。所以,駭客可上傳一些精心製作的 RFA 檔案到 Axis 的儲存帳號來發動供應鏈攻擊,大量入侵那些使用 Autodesk Revit 的 Axis Communications 客戶。
- Axis Communications 已確認其雲端儲存並未遭到未經授權的存取,也未曾發生跟已通報漏洞相關的攻擊和入侵。他們已採取必要的步驟來解決此問題,目前提供的最新版本 (25.3.718) 已解決了所有已通報的漏洞。
2024 年 7 月,我們在某個 Autodesk® Revit® 擴充元件的一些已簽署 DLL 當中發現了內嵌的 Azure Storage Account 登入憑證,Autodesk® Revit® 是一款業界廣泛使用的建築資訊模型 (BIM) 軟體。這些登入憑證所屬的帳號為瑞典跨國公司 Axis Communications 所有,該公司專門提供網路視訊解決方案與監控技術,為各種商業和公共安全領域的應用提供 IP 攝影機、存取控制系統、音訊設備,以及影像數據分析軟體。Trend Zero Day Initiative™ (ZDI) 漏洞懸賞計畫已將這些發現通報給 Axis Communications (編號:ZDI-24-1181),隨後幾個月內更持續交換有關修補更新的資訊,並通報其他問題,包括 2024 年 10 月通報的 ZDI-24-1328 和 ZDI-24-1329,以及 2025 年 3 月通報的 ZDI-25-858。
本文說明這次發生的問題在哪裡,並重新回顧最終完成修正的過程,同時也稍微討論一下 Autodesk Revit 軟體可被利用的 RCE 漏洞,藉此說明像這樣的情況可能造成多大的潛在衝擊與風險。
AXIS 擴充元件內含暴露在外的雲端登入憑證
2024 年 7 月 8 日,我們一個用來偵測 Azure 共用存取簽章 (Shared Access Signature,簡稱 SAS) 權杖 (token) 的 VirusTotal 規則偵測到一個含有數位簽章的 DLL 叫做「AzureBlobRestAPI.dll」,其簽章是核發給「AEC Advanced Engineering Computation Aktiebolag」,如圖 1 所示。
該 DLL 是由 AEC AB 公司所簽署,AEC AB 是 Autodesk 的一家合作夥伴,專門為客戶提供 AutoCAD 和 Revit 平台的相關諮詢。在已簽署的 DLL 當中發現暴露在外的登入憑證是一件很罕見的事,因此我們決定進一步調查。
我們在「AzureBlobRestAPI.DataTypes.Classes.Global」這個類別 (class) 的「internalSetEnvironment」私密方法 (private method) 中發現了兩個 Azure 儲存帳號的 Azure SAS 權杖和共用存取金鑰,分別以明碼方式儲存在「axisfiles」和「axiscontentfiles」兩個帳號名稱之下,如圖 2 所示。
事實證明,這些登入憑證是確實可用且有效的,這意味著,使用者可以利用這些登入憑證來掌控這兩個儲存帳號:從變更組態設定到讀取/寫入存取儲存帳號中的內容。當我們在檢查並評估其衝擊時,發現儲存帳號內含有以下內容:
我們在一個名為「installs」的容器中發現了一些 MSI 安裝程式。這些是一套名為「AXIS Plugin for Autodesk Revit」的擴充元件的安裝程式,這是給 Autodesk Revit 軟體使用的擴充元件。
Autodesk Revit 是一套用於建築、結構工程以及建築設計許多其他層面的 3D 模型設計軟體。這個擴充元件可讓客戶瀏覽 Axis 產品的模型,並下載相關的模型資料,以便加入 Revit 建構的模型當中。這個擴充元件僅提供給 Axis 的客戶使用。
我們是在 25.3.708 版當中發現了含有前述登入憑證的 DLL。根據儲存帳號中發現的 MSI 安裝程式看來,每個安裝了 AXIS Plugin for Autodesk Revit 的使用者,其系統上都含有包含前述登入憑證的 DLL。
ZDI 的通報與廠商修正
由於這些登入憑證可能會讓廠商的儲存帳號遭到非預期的存取,因此我們立即將這情況通報給 Axis Communications,並編號為 ZDI-24-1181。隨後便開啟了雙方之間的一系列交流,最終也修正了這項問題。
廠商第一次修正
為了修正問題,廠商釋出了一個新版 (25.3.710) 的擴充元件。在這個新版本當中,他們對登入憑證做了加密編碼,有可能是使用 Eazfuscator。但這樣的措施仍遠遠不足,因為登入憑證還是可以被 De4dot 這類公開工具解開。我們在圖 9 當中示範了這一點。
除此之外,MSI 所安裝的「AxisAddin.v25.3.dll」當中還被發現一個連上「axisapphelpfiles」這個儲存帳號的連線字串。連線字串當中通常含有認證詳細資料、端點以及選擇性的組態設定參數。
這個 DLL 會在 Autodesk Revit 載入此擴充元件時被用於顯示使用者介面。這個儲存帳號含有一些網站資源,包括 HTML 網頁以及擴充元件的「說明」(Help) 網頁所用到的靜態資產。
目前,儲存帳號「axisfiles」的登入憑證已失效,但儲存帳號「axiscontentfiles」的存取金鑰卻依然有效。這表示,新釋出的版本並未成功修補 ZDI-24-1181 所通報的問題。為此,我們又遞交了一份新的漏洞報告。
加密編碼固然有助於躲避那些只在明碼文字當中尋找固定模式的靜態掃描工具,但動機強烈的駭客還是可以輕易取得其中的登入憑證。因此,我們告訴廠商光靠加密並無法解決此問題。
取而代之的作法是,廠商可使用最低權限的登入憑證組合,例如利用唯讀的 SAS 權杖,讓唯有經過授權的客戶才能存取 RFA 檔案、影像、擴充元件等等。一般使用者不應該能修改廠商儲存帳號上的檔案,也不能將廠商的儲存用於非未經授權的存取/儲存,然而我們找到的登入憑證卻可以讓使用者做這些事。因此,我們再遞交兩項通報:ZDI-24-1328 和 ZDI-24-1329,並提出了我們的建議。
廠商第二次修正
隨後廠商又發布了一個新版 (25.3.711) 的擴充元件。這一次,他們完全移除了儲存帳號的存取金鑰,並建立了新的 SAS 權杖 (仍然使用加密編碼),但卻不提供「寫入」的權限。相較於廠商的第一次回應,這次有很大的改進。
儘管這樣的變更似乎已經解決了問題,但 25.3.711 版的 SAS 權杖還是可以用來列出並讀取儲存帳號內的容器內儲存的二進位大物件 (Blob)。其中一個名為「installs」的 Blob 容器含有 AXIS Plugin for Autodesk Revit 先前版本的 MSI 安裝程式,包括先前通報的 MSI 25.3.710 版安裝程式。這個 25.3.710 版本含有第二次通報 (ZDI-24-1328) 時提到的「axiscontentfiles」儲存帳號依然有效的登入憑證。
所以,駭客還是可以透過權限較低的 25.3.711 版 SAS 權杖來找到先前版本權限較高的登入憑證,就能再次取得儲存帳號的完整存取權限。我們又再次將研究發現通報給廠商 (ZDI-25-858),並促使廠商撤銷了儲存帳號的存取金鑰。
這一連串的互動顯示,即使是成熟的企業,當他們在使用第三方廠商的雲端服務時,有時並不曉得雲端登入憑證萬一外流或遭到濫用時可能帶來的災難性後果。
Axis Communications 已確認我們通報的 Axis Autodesk Revit 擴充元件相關漏洞已經全部修正完畢。目前在 3 月份釋出的最新版本 (25.3.718) 已經解決了所有先前通報的問題。此外,含有漏洞的版本 (25.3.710) 也已經從其儲存帳號移除,確保它不再被用來上傳或下載內容。使用者必須升級至 25.3.711 或更新版本才能使用這些功能。總而言之,從 25.3.711 版開始,所有前述問題都已經獲得解決,後續的更新版本只是包含一些小幅、不相干的變更。
此外,該公司也主動通知了受影響的合作夥伴和客戶。同時也表示,Autodesk Revit 擴充元件僅提供給特定合作夥伴使用,而非公開給一般使用者存取。
經由 Autodesk Revit RCE 漏洞的潛在供應鏈入侵
我們認為前述問題可能造成影響是:只要是基於儲存帳號的供應機制,就有可能讓駭客假扮成擴充元件來散布惡意的 MSI 安裝程式。此外,駭客也可能篡改經由 AXIS 擴充元件開啟的 HTML 檔案。
至於 Autodesk Revit RFA 檔案,我們要再追問另一個問題:駭客篡改儲存帳號內的 RFA 檔案可達成什麼目標?
儲存帳號中的 RFA 檔案是給 Autodesk Revit 的終端客戶使用。這類檔案格式中的漏洞通常會讓駭客能夠執行任意程式碼。Trend ZDI 在檢視 Autodesk Revit 所使用的 RFA 解析器時,發現了多個可能被用來執行任意程式碼的漏洞。如需這些發現的更完整資訊,請參閱 ZDI 部落格。
衝擊:供應鏈攻擊
開放給客戶使用的基礎架構萬一發生登入憑證外洩的情況,不僅會讓雲端儲存暴露在外,還可能成為多重階段供應鏈攻擊的入口。這已不是我們第一次看到這樣的案例。2023 年,我們曾經向 Microsoft 通報過有關其 PC Manager 軟體的一個類似問題,也就是只要使用暴露在外的金鑰,就能完全掌控 PC Manager 的多重散布管道,包括:WinGet 套件、一個官方子網域,以及一個 Microsoft 擁有的縮短網址服務。
到頭來,像這樣的案例不只關乎特定廠商或漏洞,而是強烈提醒著我們:在軟體供應鏈當中,「信任」是必須主動贏得、驗證、並不斷重新評估的。不論是擴充元件的安全性、登入憑證的處理方式、或是檔案對外公開的方式,只要有一步出差錯,就可能導致嚴重的後果。企業必須在駭客和資安事件迫使企業行動之前,預先了解並達成供應鏈的資安要求。
結論與建議
這次事件暴露的風險突顯出值得信賴的第三方軟體廠商有可能帶來怎樣不可預見的風險。沒想到一個給 Autodesk Revit 客戶使用的擴充元件當中包含的已簽署 DLL 函式庫竟然會含有寫死的 Azure Storage Account 登入憑證。這類機密會讓駭客在未經授權的情況下讀取/寫入 MSI 安裝程式和 RFA 模型檔案,並散布至其他客戶。
此外,Autodesk Revit 本身的漏洞也可能導致駭客能夠執行任意程式碼,因為客戶會使用擴充元件從 Axis 的儲存帳號下載模型檔案。這些發現突顯出一種危險的錯誤交集,可能導致全面的供應鏈攻擊。此案例再次重申了以下幾個重點:
- 並非含有數位簽章就代表 DLL 本身是安全的,而是必須在整個開發過程當中透過內部的徹底檢查與靜態分析才能建立信任。
- 權限過高的登入憑證暴露在外將放大風險,遵循最低授權原則有助於大幅縮小遭到入侵的範圍。
- 以檔案格式作為攻擊途徑,再搭配廣受信賴的雲端資源作為可擴充的散布機制,就能造成更大的衝擊 (如同此次案例所見)。
開放給客戶使用的基礎架構萬一發生登入憑證外洩的情況,不僅會讓雲端儲存暴露在外,還可能成為多重階段供應鏈攻擊的入口。這已不是我們第一次看到這樣的案例。2023 年,我們曾經向 Microsoft 通報過有關其 PC Manager 軟體的一個類似問題,也就是只要使用暴露在外的金鑰,就能完全掌控 PC Manager 的多重散布管道,包括:WinGet 套件、一個官方子網域,以及一個 Microsoft 擁有的縮短網址服務。
到頭來,像這樣的案例不只關乎特定廠商或漏洞,而是強烈提醒著我們:在軟體供應鏈當中,「信任」是必須主動贏得、驗證、並不斷重新評估的。不論是擴充元件的安全性、登入憑證的處理方式、或是檔案對外公開的方式,只要有一步出差錯,就可能導致嚴重的後果。企業必須在駭客和資安事件迫使企業行動之前,預先了解並達成供應鏈的資安要求。
以下是我們建議採取的一些主動式措施來防範類似情況:
- 將一套程式碼掃描解決方案 (如 Trend Vision One™ Code Security 當中的 Artifact Scanner) 整合至 CI/CD 流程當中,在發布之前預先偵測並矯正暴露在外的登入憑證。
- 將對外公開的資產與用來提供軟體版本的系統分開,以盡可能縮小攻擊面。
- 運用縱深防禦的策略來保護檔案格式解析器,定期執行漏洞評估與程式碼審查。
以下提供一些萬一發生類似的暴露事件時可採取的應變措施:
- 持續掃描現有及最新的軟體版本來查看是否有內嵌的登入憑證,以確保敏感資訊不會意外暴露在外。
- 在公開發布之前,所有版本都要經過沙盒模擬分析以及徹底的 QA 測試來發掘潛在的資安問題。
趨勢科技解決方案
Trend Vision One™ Cloud Risk Management 是一套持續性確保工具,提供超過 750 項的自動化最佳實務原則檢查,能讓企業對其雲端基礎架構感到安心。Cloud Risk Management 使用者可善用以下 Azure Storage Account 規則:
- Check for Overly Permissive Stored Access Policies (StorageAccounts-015)
確保 Azure Storage 的共用存取簽章 (SAS) 權杖未使用過度授權的存取政策。 - Allow Shared Access Signature Tokens Over HTTPS Only (StorageAccounts-005)
確保共用存取簽章 (SAS) 權杖只能搭配 HTTPS 通訊協定使用。 - Disable Shared Key Authorization (StorageAccounts-028)確保已停用「Allow storage account key access」(允許儲存帳號金鑰存取) 設定,防止共用金鑰授權。
- Enable Microsoft Entra Authorization By Default (StorageAccounts-030)確保已啟用 Azure Storage 帳號的「Default to Microsoft Entra authorization in the Azure portal」(在 Azure 入口網站預設使用 Microsoft Entra 授權) 設定。
- Enable Secure Transfer in Azure Storage (StorageAccounts-001)確保您 Azure Storage 帳號的組態設定中已啟用「Secure transfer required」(需要安全傳輸) 功能。
- Regenerate Storage Account Access Keys Periodically (StorageAccounts-002)定期重新產生儲存帳號存取金鑰來協助您確保儲存帳號的安全。
- Enable Logging for Azure Storage Blob Service (StorageAccounts-019)確保 Azure Storage Blob 服務的儲存記錄檔已經啟用。
- Check for Publicly Accessible Web Containers (StorageAccounts-016)確保用來存放靜態網站的 Azure Storage 容器不會開放公開存取。
- Disable Anonymous Access to Storage Accounts with Blob Containers (StorageAccounts-016)確保在儲存帳號層次停用 Blob 的匿名存取,藉此覆蓋任何允許公開存取的 ACL 設定。
- Enable Immutable Blob Storage (StorageAccounts-012)確保重要的 Azure Blob Storage 資料受到保護,不會被意外刪除或修改。
- Enable Soft Delete for Azure Blob Storage (StorageAccounts-010)確保您的 Microsoft Azure Storage Blob 物件已經啟用了 Soft Delete (軟性刪除) 功能。
- Review Storage Accounts with Static Website Configuration (StorageAccounts-017)確保使用靜態網站組態設定的 Azure 儲存帳號定期接受檢視 (資訊性質)。
- Disable Public Network Access to Storage Accounts (StorageAccounts-029)確保停用 Microsoft Azure Storage 帳號的公共網路存取功能,以防止未經授權的存取,進而提升安全性。
- Disable Anonymous Access to Blob Containers (StorageAccounts-006)確保 Azure Storage 帳號內的 Blob 容器已停用匿名存取。