TL博士
一組 PyPI 軟體包借用了以下名稱 uv使用快速且極為流行的基於 Rust 的 Python 套件管理器偽裝成 uv 助理。它們幾乎沒有任何實際功能。它們攜帶的只是一個 Windows 有效載荷,該載荷會啟動一個 JupyterLab 伺服器(已關閉驗證) 在後續版本中,它會透過反向隧道將其發佈到公共互聯網上。
這就是全部故事,一句話概括: 以值得信賴的工具名稱作為誘餌,以 JupyterLab 作為遠端程式碼執行引擎。 Jupyter 伺服器會執行你在 Jupyter 中輸入的任何程式碼。ebook 一個使用空令牌啟動並綁定到每個網路介面的單元是一個開放解釋器,任何能夠存取該連接埠的人都可以驅動它。
我們追蹤集群 仿紫外線檢查的兩個軟體包是: moon-uv (0.0.1-0.0.16)和 my-magic-uv-helper (0.0.1),由同一業者發布,在分析時可在 PyPI 上運作。
| 生態系統 | 的PyPI |
| 配套 | moon-uv (0.0.1-0.0.16), my-magic-uv-helper (0.0.1) |
| 目標平台 | Windows |
| 核心行為 | 未經身份驗證的 JupyterLab 伺服器,透過反向隧道發佈到網際網路。 |
| 合法工具被濫用 | uv、JupyterLab、Cloudflare、Pingly |
誘因:一個你已經信任的名字
uv 是過去兩年安裝量最高的 Python 工具之一,因此,“一個輔助工具” uv「 」是一個開發者會毫不猶豫地安裝的軟體包。 FauxUV 的信譽完全建立在這個名字之上。這些軟體包封裝了 真正 uv Astral 的安裝程式——有效載荷中的 URL 指向真實可靠的主機——因此只需快速瀏覽一下,就能看到所有可信任的參考。實際上,這些軟體包都不會添加任何內容。 uv 功能性;名稱完全是偽裝。
JupyterLab 作為 RCE 引擎
此酬載的核心是一個啟動器,它會在啟動 JupyterLab 時移除所有限制條件:
jupyter server --with jupyterlab --ip=0.0.0.0 # listen on every interface --ServerApp.token="" # no password, no token --allow_origin='*' # accept cross-origin connections --disable_check_xsrf # allow a remote browser/WebSocket to drive it 每個標記都會移除一層保護,而且附帶的腳本甚至對其進行了註釋(原文為中文):空標記 “關閉密碼和令牌檢查——任何人都可以連接。” Jupyter實驗室 是一個合法的數據科學整合開發環境,但並非ebook 單元格依設計執行任意程式碼。已按此方式配置並綁定到 0.0.0.0它不再是 IDE,而是變成了主機上未經身份驗證的遠端 shell——不需要自訂惡意軟體二進位文件,只是一個指向錯誤方向的主流工具。
兩個支撐因素使得這一切成為可能且可重複實現:
- 靜默安裝觸發器。 早期版本運行 PowerShell -ExecutionPolicy繞過 直接來自 設置文件 on 點安裝在背景運行,錯誤已被抑制。 點子 看起來很正常。後續版本將相同的基本元素移至 pip-uv 使用命令列工具-並完全取消安裝時自動執行。
- 一條公共反向隧道。 伺服器上 0.0.0.0 仍然只有能夠路由到該機器的主機才能存取它。捆綁的模組打開一個 [Pinggy](https://pinggy.io/SSH反向隧道會將本機Jupyter連接埠轉送至公用位址,從而解除連接埠限制。提供的腳本還包含一個備用路徑(已註解掉),使用Cloudflare的服務。 Cloudflare 配備 的netsh 透過連接埠代理將連接埠轉送至 Linode IP,透過不同的基礎架構實現相同的目標。
綜上所述:安裝軟體套件後,Windows 主機最終會執行一個無需密碼的 JupyterLab 並將其發佈到開放的網路上。
FauxUV是如何演變的
FauxUV 的版本接連快速發布,有效載荷的觸發點也隨之移動——這提醒我們,一個標記的版本很少能完整地反映出一個軟體包系列的情況。
| 階段 | 版本 | 觸發 | 它增加了什麼 |
|---|---|---|---|
| 安裝鉤子 | moon-uv 0.0.1-0.0.3, my-magic-uv-helper 0.0.1 | setup.py 在 pip 安裝中 | uv 安裝 + PATH 前綴 |
| CLI運行時 | moon-uv 0.0.5-0.0.13 | pip-uv 命令 | 無需密碼的 JupyterLab 啟動器 |
| 隧道 | moon-uv 0.0.14-0.0.16 | pip-uv 命令 | 活躍的Pingy反向隧道 |
值得注意的是,安裝時自動運行是 刪除 在後來的、更強大的版本中——因此,掃描器僅以生命週期為關鍵訊息 hooks 會為新發行的版本評分 少 冒險,恰恰相反。
妥協指標
已透過閱讀軟體包原始碼確認;端點已標記 評論 這些指標存在於文件中,但不會被分析版本執行。網路指標已被停用。
| 類型 | 指標 |
|---|---|
| 安裝命令 | powershell -ExecutionPolicy Bypass 在 pip 安裝時取得真正的 UV 安裝程序 |
| JupyterLab 標誌 | --ip=0.0.0.0 --ServerApp.token="" --allow_origin='*' --disable_check_xsrf |
| 反向隧道(已啟動) | free[.]pinggy[.]io:443 本地轉發 127.0.0.1:8888 |
| 隧道主機(已註) | cloudflared tunnel --url hxxp://127[.]0[.]0[.]1:2718 |
| IP(已註) | 45[.]79[.]134[.]161 (Linode)透過 netsh port-proxy |
| 堅持 | 準備 %USERPROFILE%\.local\bin 新增到使用者路徑 |
值得關注的行為訊號,與這些具體字串無關: 點安裝 產生的 powershell -ExecutionPolicy Bypass; 任何 朱皮特 發射組合 token=”” - –ip=0.0.0.0;以及出站 SSH 到 *.pinggy.io 來自開發人員或 CI 伺服器。
觀察到的行為和來源
這兩個軟體包的作者和方法相同:它們都使用了一個可信任工具的名稱,僅限 Windows 系統,在後台執行並抑制錯誤,並且依賴信譽良好的工具,因此只需快速查看即可發現所有 URL 都是可信的。原始碼中包含中文註釋,清楚地描述了與安全相關的標誌;我們將其作為文件中可觀察到的語句進行報告,而不是作為關於動機的斷言。 允許來源 價值和 colab.bat 檔案名稱呼應了在 Google Colab 中流傳的非正式「共享本地運行時」工作流程。無論其來源為何,打包後的結果都是一樣的。
對防守者的影響與指導
誰會接觸到 FauxUV? Windows 開發人員和 CI 運行人員 點安裝 這些軟體包之一。無需密碼即可在 JupyterLab 上運作。 0.0.0.0 遠端程式碼執行允許任何能夠存取該連接埠的人執行;隧道則消除了「誰可以存取」的限制。伺服器以安裝使用者的身分運行,並繼承該使用者的檔案、令牌和雲端憑證。
為什麼很容易錯過它。 每個網頁字串都指向一個信譽良好的主機-Astral、JupyterLab、 CloudflarePinggy、Colab 等工具都無法做到這一點。這裡既沒有惡意軟體二進位檔案需要雜湊處理,也沒有混淆的資料區塊需要解碼。基於信譽和基於特徵碼的掃描都低估了這一點,這就是為什麼需要關注行為問題的原因—— 安裝此軟體包後,機器會做什麼? ——就是那個抓住它的人。
指導:
- 處理任何安裝時間 powershell -ExecutionPolicy Bypass 無論它獲取的是哪個 URL,都會發出破壞構建的信號。
- 警報開啟 朱皮特 使用空令牌啟動 –ip=0.0.0.0;這種組合絕對不應該出現在工作站或運行器上。
- 監控到隧道提供者的出站 SSH 連線(*.pinggy.io, *.trycloudflare.com來自開發人員和 CI 環境。
- 安裝 uv 來自[其官方來源](https://docs.astral.sh/uv/)並且對那些包裝了原本安裝起來就很簡單的工具的第三方「輔助」軟體包持懷疑態度。
- 升級時鎖定並重新審查依賴項—軟體包系列可能會隨著版本更新而增加新功能。



