.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
SentinelLabs 在Microsoft Azure Defender for IoT 中發現了許多影響雲和本地客戶的嚴重漏洞。
未經身份驗證的攻擊者可以通過濫用Azure 密碼恢復機制中的漏洞遠程攻擊受Microsoft Azure Defender for IoT 保護的設備。
SentinelLabs的調查結果已於2021年6月主動報告給微軟，這些漏洞被定義為CVE-2021-42310、CVE-2021-42312、CVE-2021-37222、CVE-2021-42313 和CVE-2021-42311，且標記為嚴重，一些CVSS 得分甚至為10.0。
Microsoft 已發布安全更新以解決這些嚴重漏洞。鼓勵用戶立即採取行動。
目前，SentinelLabs 尚未發現野外濫用的證據。
技術細節運營技術(OT) 網絡雖然很流行，但是，其中許多技術在設計時並未考慮到安全性，並且無法通過傳統的IT 安全控制進行保護。與此同時，物聯網(IoT) 所連接的數十億設備大大增加了攻擊面和安全風險。
但供應商並沒有忽視這個問題，許多供應商都提供了安全解決方案以試圖解決這個問題，但如果安全解決方案本身就存在著漏洞怎麼辦？在本文中，我們將討論Microsoft Azure Defender for IoT 中發現的嚴重漏洞，這是Microsoft Azure 的IoT/OT 網絡安全產品。
首先，我們會介紹密碼重置機制中的漏洞如何被遠程攻擊者濫用以獲得未經授權的訪問。然後，我們討論了Defender for IoT 中的多個SQL 注入漏洞，這些漏洞允許遠程攻擊者無需身份驗證即可獲得訪問權限。最終，提出有關安全產品本身的安全性及其對易受攻擊部門安全態勢的整體影響的嚴重問題。
Microsoft Azure Defender for IoTMicrosoft Defender for IoT 是一種無代理網絡層安全性，用於持續的IoT/OT 資產發現、漏洞管理和威脅檢測，無需更改現有環境。它可以完全部署在本地或與Azure 連接的環境中。
該解決方案由兩個主要組件組成：
Microsoft Azure Defender For IoT Management——使SOC 團隊能夠管理和分析從多個傳感器聚合到單個儀表板的警報，並提供網絡安全狀況的整體視圖。
Microsoft Azure Defender For IoT Sensor – 發現並持續監控網絡設備。傳感器使用物聯網和OT 設備上的被動（無代理）監控來收集ICS 網絡流量。傳感器連接到SPAN 端口或網絡TAP，並立即開始對IoT 和OT 網絡流量執行DPI（深度數據包檢測）。
這兩個組件既可以安裝在專用設備上，也可以安裝在VM 上。
深度包檢測(DPI) 是通過負責分析網絡流量的Horizon 組件實現的。 Horizon 組件加載內置解析器，並且可以擴展以添加自定義網絡協議解析器。
物聯網Web 界面攻擊面防禦管理和傳感器共享大致相同的代碼庫，配置更改以適應設備的用途。這就是為什麼兩台設備都受到大多數相同漏洞影響的原因。
兩台設備上暴露的最吸引人的攻擊面是Web 界面，它允許以簡單的方式控制環境。該傳感器還暴露了另一個攻擊面，即解析網絡流量的DPI 服務。
安裝和配置管理和傳感器後，我們會看到Web 界面的登錄頁面。
相同的憑據也用作SSH 服務器的登錄憑據，這讓我們對系統的工作方式有了更多的了解。我們要做的第一件事是獲取資源以了解幕後發生的事情，那麼我們如何獲取這些資源呢？
Defender for IoT 是一款前身為CyberX 的產品，於2020 年被微軟收購。在“cyberx”用戶的主目錄中查找，我們發現了安裝腳本和一個包含系統加密文件的tar 壓縮文件。讀取腳本時，我們找到了解密壓縮文件的命令。簡化版如下：
解密密鑰在所有安裝中共享。
提取數據後，我們找到了Web 界面的源代碼（用Python 編寫）並開始工作。
首先，我們的目標是找到任何公開的未經身份驗證的API，並查找其中的漏洞。
尋找潛在的漏洞urls.py 文件包含Web 應用程序的主要路由：
使用Jetbrains IntelliJ 的類層次結構功能，我們可以輕鬆識別不需要身份驗證的路由控制器。
不需要身份驗證的路由控制器從BaseHandler 繼承並且不驗證身份驗證或需要秘密令牌的每個控制器在此時都是一個很好的候選者。
Azure 的密碼恢復機制管理和傳感器的密碼恢復機制操作如下：
1.訪問管理/傳感器URL（例如，https://ip/login#/dashboard）；
2.進入“密碼恢復”頁面；
3.將此頁面中提供的ApplianceID 複製到Azure 控制台，並獲取你在密碼重置頁面中上傳的密碼重置ZIP 文件。
4.使用步驟2 中提到的表格將簽名的ZIP 文件上傳到管理/傳感器密碼恢復頁面。這個ZIP包含數字簽名的證明，通過數字證書和簽名數據的方式，證明用戶是這台設備的所有者。
5.生成新密碼並顯示給用戶：
5.1實際過程分為對管理/傳感器服務器的兩個請求：
5.1.1上傳簽名的ZIP 證明；
5.1.2密碼恢復；
5.2當上傳ZIP文件時，它被解壓縮到/var/cyberx/reset_password目錄(由zipfileconfigationapihandler處理)；
5.3在處理密碼恢復請求時，服務器會執行以下操作：
5.3.1 PasswordRecoveryApiHandler 控制器驗證證書。這將驗證證書是否由根CA 正確簽名。此外，它還會檢查這些證書是否屬於Azure 服務器。
5.3.2向內部Tomcat 服務器發送請求以進一步驗證設備的屬性。
5.3.3如果所有檢查都正確通過，PasswordRecoveryApiHandler將生成一個新密碼並將其返回給用戶。
ZIP 包含以下文件：
IotDefenderSigningCertificate.pem – Azure 公鑰，用於驗證ResetPassword.json 中的數據簽名，由issuer.pem 簽名。
Issuer.pem – 簽署IotDefenderSigningCertificate.pem，由受信任的根CA 簽署。
ResetPassword.json – JSON 應用程序數據，設備的屬性。
ResetPassword.json 文件的內容如下所示：
根據步驟2，處理文件上傳到reset_password目錄（components\xsense-web\cyberx_web\api\admin.py:1508）的代碼如下：
如下所示，該代碼將用戶交付的ZIP解壓到上述目錄，並處理密碼恢復請求(cyberx python庫文件django_helper .py:576)：
該函數首先驗證提供的用戶並調用函數_try_reset_password：
在內部，此代碼會驗證證書，包括頒發者。
之後，對內部API http://127.0.0.1:9090/core/api/v1/login/reset-password 的請求由最終執行以下代碼的Java 組件發出和處理：
此代碼再次驗證密碼重置文件。這次它還驗證了ResetPassword.json 文件的簽名及其屬性。
如果一切順利並且Java API 返回200 OK 狀態碼，PasswordRecoveryApiHandler 控制器繼續並生成新密碼並將其返回給用戶。
Defender for IOT 中的漏洞如圖所示，密碼恢復機制由兩個主要部分組成：
Python Web API（外部）；
Java Web API（tomcat，內部）；
這引入了一個time-of-check-time-of-use(TOCTOU) 漏洞，原因是沒有應用同步機制。
如上所述，重置密碼機制從上傳ZIP 文件開始。這個原語允許我們將任何文件上傳到/var/cyberx/reset_password目錄並將其解壓縮。
可以在第一次驗證（Python API）和第二次驗證（Java API）之間更改/var/cyberx/reset_password 中的文件，Python API文件由Azure 證書正確簽名。然後，Java API 處理要替換的自定義文件，導致它錯誤地同意其真實性並返回200 OK 狀態代碼。
密碼恢復Java API包含邏輯漏洞，這些漏洞讓專門設計的有效負載繞過了所有驗證。
Java API 驗證JSON 文件的簽名（與上面的代碼相同）：
這裡的問題是它沒有驗證IotDefenderSigningCertificate.pem 證書，而不是Python API 驗證。它只檢查JSON 文件中的簽名是否由附加的證書文件簽名，這引入了一個重大漏洞。
因此，攻擊者可以生成自簽名證書並簽署將通過簽名驗證的ResetPassword.json 有效負載。
如前所述，ResetPassword.json 如下所示：
之後，有一個訂閱ID 檢查：
這是遠程攻擊者無法獲得的唯一屬性，並且在合理的時間內無法猜測。但是，可以輕鬆繞過此檢查。
該代碼從JSON 文件中獲取subscriptionId，並將其與machineSubscriptionId 進行比較。但是，這裡的代碼有漏洞。它檢查machineSubscriptionId 是否包含來自用戶控制的JSON 文件的subscriptionId，而不是相反。contains() 的使用是不安全的。 subscriptionId 採用GUID 格式，這意味著它必須包含連字符。這允許我們通過僅提供單個連字符來繞過此檢查。
接下來，檢查issueDate 和ApplianceId。這已經由密碼恢復頁面（在步驟2 中提到）提供給我們。
現在我們明白了，我們可以繞過Java API 中的所有檢查，這意味著我們只需要成功贏得競爭條件並最終在未經授權的情況下重置密碼。
ZIP上傳界面和密碼恢復界面分開的事實在開發階段派上了用場。
Azure Defender for IoT的被攻擊過程為了準備攻擊，我們需要執行以下操作。
從Azure 門戶獲取合法的密碼恢復ZIP 文件。顯然，我們無法訪問受害設備所屬的Azure 用戶，但我們可以使用任何Azure 用戶並生成一個“虛擬”ZIP 文件。我們只需要恢復ZIP 文件即可獲得合法證書。這可以通過以下URL 完成：
為此，我們可以創建一個新的試用Azure 帳戶並使用上述接口生成恢復文件。秘密標識符無關緊要，可能包含垃圾。
然後我們需要生成一個自定義的（“壞的”）ZIP 文件。此ZIP 文件將包含兩個文件：
IotDefenderSigningCertificate.pem – 自簽名證書。可以通過以下命令生成：
ResetPassword.json – 屬性數據JSON 文件，由上述自簽名證書籤名並進行相應修改以繞過Java API 驗證。
可以使用以下Java 代碼對該JSON 文件進行簽名：
如前所述，applianceId 是從密碼恢復頁面獲取的。 tenantId未經驗證，因此可以是任何內容。
issuanceDate參數是自解釋的。
一旦生成並簽名，可以將其添加到ZIP 壓縮文件並供以下Python 漏洞利用腳本使用：
benign.zip文件是從Azure 門戶獲取的ZIP 文件，而malicious.zip文件是如上所述的自定義ZIP 文件。
上面的漏洞利用腳本執行TOCTOU 攻擊以重置並接收cyberx用戶名的密碼，而無需任何身份驗證。它通過使用三個線程來實現：
looper_benign – 負責無限循環上傳良性ZIP 文件；
looper_malicious – 與looper_benign相同，但是上傳惡意ZIP，在這個配置中有1秒的超時時間；
looper_recover – 發送密碼恢復請求以觸發易受攻擊的代碼；
不幸的是，文檔提到ZIP 文件不能被篡改。
該漏洞在CVE-2021-42310中得到了恢復。
以root #1 身份執行未經身份驗證的遠程代碼至此，我們可以獲得特權用戶cyberx的密碼。這允許我們登錄到SSH 服務器並以root 身份執行代碼。即使沒有這個，攻擊者也可以使用更隱蔽的方法來執行代碼。
使用獲取的密碼登錄後，攻擊面大大增加。例如，我們在更改密碼機制中發現了一個簡單的命令注入漏洞：
來自components\xsense-web\cyberx_web\api\authentication.py:151：
該函數接收來自用戶的三個JSON 字段，“username”、“password”、“new_password”。
首先，它驗證我們已經擁有的用戶名和密碼。接下來，它只使用正則表達式檢查密碼的複雜性，但不清理命令注入原語的輸入。
在驗證之後，它使用攻擊者控制的用戶名和新密碼以root身份執行/usr/local/bin/cyberx-users-password-reset腳本。由於該函數沒有正確地對“new_password”的輸入進行清理，所以我們可以注入任何我們選擇的命令。我們的命令將在sudo的幫助下以root用戶的身份執行，這讓我們可以以root用戶的身份執行代碼：
這可以通過以下HTTP 數據包來利用：
該漏洞在CVE-2021-42312中被修復。
POC接下來，我們將介紹兩個額外的路由和新漏洞，以及流量處理框架中的一個漏洞。
這些漏洞是基本的SQL 注入（稍加改動），但它們對產品和組織網絡的安全性有很大影響。
CVE-2021-42313DynamicTokenAuthenticationBaseHandler類繼承自BaseHandler類，不需要身份驗證。這個類包含兩個容易被SQL注入的函數(get_version_from_db, uuid_is_connected)。
如上所示，UUI