.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
CVE-2023-1177：MLflow中的LFI/RFILFI/RFI導致系統和雲帳戶被接管
所有CVE在版本2.2.2中已經被修復
已發布了漏洞利用工具和掃描工具
機器學習系統領域最流行的工具之一是MLflow（月下載量超過1300萬人次，且這個數字還在增長），它用於管理端到端機器學習生命週期。
Protect AI測試了MLflow的安全性，結果發現了一個混合型的本地文件包含/遠程文件包含(LFI/RFI)漏洞，可能導致整個系統或云提供商被人接管。強烈建議運行MLflow服務器的組織立即更新到最新版本，或者至少更新到2.2.2版本。版本2.2.1修復了CVE-2023-1177，版本2.2.2修復了CVE-2023-1176。我們在本博文中探討了該漏洞的影響、如何檢測它，以及我們發現這個嚴重漏洞的過程。如果你正在運行MLflow，請使用本博文中提供的免費工具，立即開始修補系統。使用傳統工具給系統打補丁可能是一個挑戰，因為許多自動化補丁管理系統並不枚舉或識別MLflow，就算枚舉或識別，可能也不會執行版本檢查。
立即升級到MLflow的最新版本非常重要，哪怕你的實例不在生產環境中，只在開發環境中使用。
影響如果利用該漏洞，未經身份驗證的遠程攻擊者可以讀取啟動了MLflow服務器的用戶可以訪問的這台服務器上的任何文件。
可以通過從MLflow服務器獲取私有SSH密鑰或云服務提供商憑據來獲得遠程代碼執行的機會。這讓攻擊者得以遠程登錄到服務器或云資源，並利用找到的憑據擁有的相應權限執行任意代碼。
漏洞細節不需要用戶交互。
不需要事先了解環境。
MLflow的所有自定義配置都易受攻擊，包括開箱即用的安裝環境。
MLflow 2.1.1之前的所有版本都容易受到LFI的攻擊。
漏洞利用工具適用於從MLflow v1.12到v2.1.1的所有版本。
MLflow 2.0之前的所有版本都容易受到LFI的攻擊，只需通過更簡單地利用：http://
MLflow維護者迅速響應了負責任披露的這個漏洞，在短短幾週內交付了修復程序。 MLflow 2.1.1之後的版本不再容易受到攻擊。
漏洞檢測若要檢查你的MLflow服務器是否容易受到攻擊，請使用我們的免費CVE-2023-117-scanner掃描工具（https://github.com/protectai/Snaike-MLflow）。
發現過程我們先安裝了MLflow，啟動攔截代理BurpSuite以攔截所有MLflow API調用，運行用數據填充MLflow的實驗，然後啟動UI服務器作進一步探索。
# Download MLflow source to get access to their example runs
git clone https://github.com/mlflow/mlflow
# Create and enter new directory outside the mlflow/directory
mkdir mlflowui
cd mlflowui
# Copy the example code from the MLflow source into this new directory
cp -r ./mlflow/examples/sklearn_elasticnet_wine .
# Setup a virtual environment for installing requirements
python3 -m venv venv
source venv/bin/activate
# Install mlflow in this virtual environment
pip install mlflow pandas
# Run the example experiment
mlflow run --env-manager=local sklearn_elasticnet_wine -P alpha=0.5
# Run the UI to see the experiment details
mlflow ui --host 127.0.0.1:8000
在創建實驗時，它給了我們指定存儲對象的目錄這一選項。這似乎是一個可配置的文件路徑，我們可以通過運行的示例實驗就可以看到：
圖1
這立即引起了我們的注意，因為這需要完美地實施過濾機制，以防止本地文件包含或任意文件覆蓋。然而，你無法從UI遠程運行MLflow實驗。由於當你通過UI創建實驗時，工件位置實際上沒有發生任何變化，因此這裡沒有任何安全考慮。然後，我們通過點擊單趟實驗運行繼續探索。
圖2
點擊上圖所示的運行名稱，將我們帶到實驗運行細節，在這裡我們可以看到實驗涉及的文件，並下載文件，如下圖所示。
在這裡，我們在工件文件中看到了一個很大的“Register Model”（註冊模型）按鈕。我們很好奇。
圖3
圖4
它似乎不是什麼特別值得關注的對象，因為它只是彈出一個模式，讓你選擇模型，然後將該模型的詳細信息保存為“Version 1”（版本1）。
圖5
但是底層到底發生了什麼？為此我們檢查了BurpSuite。
圖6
我們發現了在UI中並沒有顯示的另一個協議和文件路徑輸入。這似乎很可疑。我們將它手動更改為用戶的私有SSH密鑰：file: ///Users/danmcinerney/. ssh/id_rsa。訪問該文件將允許你以啟動了MLflow服務器的用戶的身份遠程登錄到MLflow主機。
圖7
新的source在響應中有所體現，這通常表明服務器端出現了變化。我們很想知道這實現了什麼操作，於是回過頭去查看已註冊的模型細節。實驗中沒有什麼運行工件，模型細節或模型版本細節中也沒有值得關注的對象。這似乎是另一條死胡同，類似我們發現你可以將實驗工件路徑指向任意位置，但UI隨後不讓你任何操作。然而在檢查BurpSuite請求和響應日誌後，我們發現了一些值得關注的異常。
攻擊者現在擁有訪問權
圖8
get-artifact API調用中的“500內部服務器錯誤”讓我們感到可疑。在安全測試的早期，get-artifact API調用值得注意，因為它是從工件存儲庫返回文件數據的調用。這是你從實驗運行下載模型的方法，我們發現它受到了一個防止本地文件包含漏洞的函數的保護，如下所示。
圖9
我們花了一些時間試圖繞過這個，但沒有成功。這個特殊的get-artifact調用的不同之處在於，它不是試圖從子文件夾獲取文件，而是直接訪問文件名。此外，它實際上不是同一個API調用。下面是記入文檔的get-artifact REST API調用：
圖10
下面是類似的model-version/get-artifact調用：
圖11
區別包括URL路徑、參數和值。這顯然不是同一個API調用。
我們注意到這個API調用不在說明文檔中。關鍵區別在於，它通過path URL參數直接查找文件名，而不是通過合法的get-artifact API調用中的相對文件路徑來查找。
這就意味著LFI防護機制並不存在，因為不需要執行目錄遍歷。只需要控制源文件夾的位置。在上面的幾個步驟中，當我們創建一個新的模型版本時，嘗試將API請求的source路徑位置修改為：file:///Users/danmcinerney/.ssh/id_rsa：
圖12
我們應該做的是將source位置更改為文件夾而不是更改為文件。我們糾正了這一點。
圖13
隨後我們重新發送了發現的這個未記入文檔的REST API調用，並將其指向id_rsa，這是新模型版本source位置中的文件以及提供遠程登錄服務器功能的私有SSH密鑰。
圖14
使用檢索到的SSH密鑰，我們就可以通過終端訪問運行MLflow服務器的主機。 MLflow最常被配置為使用S3存儲桶作為工件存儲區。如果是這種情況，那麼機器上另一個價值非常高的目標將是~/.aws/credentials文件，可想而知該文件存儲的是AWS憑據。
其他高價值目標可能包括包含明文密碼的Web服務器SQL配置文件或包含所有用戶密碼散列的/etc/shadow，這些用戶密碼散列可以通過hashcat之類的工具來破解。
漏洞利用工具為了幫助保護你的系統，我們創建了一個簡單的工具來發現潛在漏洞，這個工具名為MLFIflow.py（https://github.com/protectai/Snaike-MLflow）。
安裝git clone https://github.com/protectai/Snaike-MLflow
cd Snaike-MLflow/MLFIflow
python3 -m venv mlfiflow
source mlfiflow/bin/activate
pip install -r requirements.txt
使用默認情況下，MLFIflow將嘗試從MLflow服務器讀取/etc/passwd，並使用找到的用戶名搜索SSH密鑰和雲憑據文件：
python MLFIflow.py -s http://1.2.3.4:5000
若要指定待下載的文件的自定義單詞列表，使用-f標誌：
python MLFIflow.py -s http://1.2.3.4:5000 -f /path/to/wordlist.txt