本文僅增加了中文對照翻譯，原始來源地址為：
https://palant.info/2024/03/06/numerous-vulnerabilities-in-xunlei-accelerator-application/?continueFlag=b356b9302d211d309327b91395f5b9e4
迅雷加速器（迅雷客戶端）又名迅雷雷霆，由總部位於中國的迅雷有限公司開發，是一款廣受歡迎的應用程序。根據該公司的年度報告，2022 年 12 月統計了 5110 萬活躍用戶。該公司的 Google Chrome 擴展迅雷下載支持，雖然不是使用該應用程序的強制性要求，但在撰寫本文時擁有 2800 萬用戶。
我發現這個應用程序暴露了一個巨大的攻擊面。應用程序用戶碰巧正在訪問的任意網站在很大程度上可以訪問此攻擊面。其中一些也可以從同一網絡中的其他計算機訪問，或者由能夠攔截用戶網絡連接的攻擊者訪問（中間人攻擊）。
在此應用程序的設計中似乎沒有考慮安全問題。大量的內部接口在沒有充分保護的情況下暴露出來。一些現有的安全機制被禁用。該應用程序還包含大量第三方代碼，這些代碼似乎沒有收到任何安全更新。
我向迅雷報告了許多漏洞，其中大部分允許遠程執行代碼。儘管如此，考慮到攻擊面的大小，我感覺我幾乎沒有觸及表面。
迅雷上一次做安全新聞，是因為分發了一個惡意軟件組件。那時候是內部工作，有的員工叛變。但是，該應用程序的缺陷允許從該應用程序的用戶碰巧訪問的任何網站輕鬆實現相同的效果。
內容
什麼是迅雷加速器？
內置 Web 瀏覽器
基於 Chromium 的自定義瀏覽器的麻煩
已禁用保護
包括審查制度
原生 API
進入迅雷瀏覽器
修復
主要應用
過時的 Electron framework
跨站腳本漏洞
在渲染器進程中執行任意代碼的影響
（缺少）修復
XLLite 應用程序
應用概述
“泛身份驗證”
通過插件安裝實現代碼執行
修復
插件管理
怪異之處
示例方案：XLServicePlatform
（缺少？）修復
過時的組件
報告問題
什麼是迅雷加速器？
維基百科將迅雷有限公司的主要產品列為 Bittorrent 客戶端，也許十年前確實如此。然而，今天很難描述這個應用程序的作用。是下載管理器嗎？網絡瀏覽器？雲存儲服務？多媒體客戶端？遊戲平台？它似乎是所有這些東西，甚至更多。
將迅雷視為一個廣告平台可能更容易。這是一個應用程序，其目標是通過顯示廣告和銷售訂閱來最大化利潤。因此，它需要儘可能長時間地將用戶留在平台上。這就是為什麼它試圖實現用戶可能需要的每一項功能，當然也不是特別擅長其中任何一個。
因此，有一個經典的下載管理器可以劫持瀏覽器中啟動的下載，並承諾加快速度。還有一個基本的網絡瀏覽器（事實上是兩個截然不同的網絡瀏覽器），因此您無需返回常規網絡瀏覽器。您可以在內置媒體播放器中播放正在下載的任何內容，也可以將其上傳到內置存儲。我有沒有提到遊戲？是的，也有遊戲，只是為了讓你忙得不可開交。
總而言之，這是眾多應用程序的集合，這些應用程序使用各種不同的技術構建，通常為同一目標實現競爭機制，但努力保持單個應用程序的外觀。
內置 Web 瀏覽器
基於 Chromium 的自定義瀏覽器的麻煩
公司喜歡推出自己的網絡瀏覽器。原因不在於他們的瀏覽器比市場上已有的其他 812 瀏覽器更好。相反，網絡瀏覽器可以通過您的搜索獲利（如果您不那麼幸運，還可以通過您的瀏覽歷史記錄獲利），這是一項非常有利可圖的業務。
顯然，如果公司盡可能少地投入維護精力，那麼定制瀏覽器的利潤會更高。因此，他們採用了開源的 Chromium，在上面打上了自己的品牌，也許還有一些半心半意的功能，然後他們就收工了。
麻煩的是：瀏覽器具有巨大的攻擊面，根據定義，該攻擊面暴露在任意網頁（和廣告網絡）中。像 Mozilla 或 Google 這樣的公司投入了大量資源來快速堵塞漏洞，並每六周發布一次更新。而且，基於 Chromium 的自定義瀏覽器也需要每六周更新一次，否則它將使用戶暴露於已知的（並且經常被廣泛利用的）漏洞。
即使只是跟上 Chromium 的開發也很困難，這就是為什麼它幾乎從未發生過。事實上，當我查看 Xunlei 應用程序內置的未命名 Web 瀏覽器（內部名稱：TBC）時，它基於 Chromium 83.0.4103.106。這個特定的瀏覽器版本於 2020 年 5 月發布，當時已經有三年半的歷史了。供參考：僅在 2023 年，谷歌就修復了 Chromium 中八個被積極利用的零日漏洞。
除其他外，該瀏覽器被證明容易受到 CVE-2021-38003 的攻擊。本文解釋了此漏洞如何允許任何網站上的 JavaScript 代碼獲得對原始內存的讀 / 寫訪問權限。我可以在迅雷瀏覽器中重現這個問題。
已禁用保護
很難說在這個瀏覽器中沒有彈出窗口阻止程序是一個故意的選擇，還是僅僅是因為瀏覽器太基礎了。無論哪種方式，網站都可以自由打開任意數量的標籤。但是，添加 --autoplay-policy=no-user-gesture-required 命令行標誌肯定是故意發生的，關閉了視頻自動播放保護。
同樣值得注意的是，迅雷在他們的瀏覽器中恢復了 Flash Player。2020 年 12 月，由於各種原因（包括安全性），所有瀏覽器都禁用了對 Flash Player 的支持。迅雷不僅決定忽略這個推理，他們還隨瀏覽器一起發布了 Flash Player 29.0.0.140（2018 年 4 月發布）。Adobe 支持網站列出了 2018 年 4 月之後和支持終止前發布的大量 Flash Player 安全修復程序。
有趣的是，迅雷瀏覽器不允許用戶訪問該網站 example.com（而不是 example.net）。當您嘗試時，瀏覽器會將您重定向到 static.xbase.cloud 上的頁面。這是一個異步過程，因此您很有可能首先瞥見原始頁面。
文本的自動翻譯：“此網頁包含非法或非法內容，訪問已停止。”
事實證明，該應用程序會將您訪問的每個網站發送到 api-shoulei-ssl.xunlei.com。該終結點將接受您選擇的導航目標，或指示將您重定向到其他地址。因此，何時導航到 example.com 將發送以下請求：
POST /xlppc.blacklist.api/v1/check HTTP/1.1
Content-Length: 29
Content-Type: application/json
Host: api-shoulei-ssl.xunlei.com
{"url":"http://example.com/"}
而服務器響應如下：
{
"code": 200,
"msg": "ok",
"data": {
"host": "example.com",
"redirect": "https://static.xbase.cloud/file/2rvk4e3gkdnl7u1kl0k/xappnotfound/#/unreach",
"result": "reject"
}
}
有趣的是，給它地址 http://example.com./（注意尾隨點）將導致響應 {"code":403,"msg":"params error","data"}。由於端點無法處理此地址，瀏覽器將允許您訪問它。
在一個有趣的轉折中，迅雷瀏覽器向所有網頁公開了 window.native.CallNativeFunction () 方法。調用將被轉發到主應用程序，其中任何插件都可以註冊其本機函數處理程序。當我檢查時，有 179 個這樣的處理程序註冊，儘管這個數字可能因活動插件而異。
公開的功能包括 ShellOpen（使用 Windows shell API 打開文件）、QuerySqlite（查詢包含下載任務的數據庫）、SetProxy（配置用於所有下載的代理服務器）或 GetRecentHistorys（檢索迅雷瀏覽器的瀏覽歷史記錄）。
我的概念驗證漏洞將運行以下代碼：
native.CallNativeFunction("ShellOpen", "c:\windows\system32\calc.exe");
這將打開 Windows 計算器，正如您所期望的那樣。
現在這個 API 從來都不是要向所有網站公開的，而只是要向少數幾個非常 “受信任” 的網站公開。此處的允許列表是：
[
".xunlei.com",
"h5-pccloud.onethingpcs.com",
"h5-pccloud.test.onethingpcs.com",
"h5-pciaas.onethingpcs.com",
"h5-pccloud.onethingcloud.com",
"h5-pccloud-test.onethingcloud.com",
"h5-pcxl.hiveshared.com"
]
以下是訪問的驗證方式：
function isUrlInDomains(url, allowlist, frameUrl) {
let result = false;
for (let index = 0; index < allowlist.length; ++index) {
if (url.includes(allowlist[index]) || frameUrl && frameUrl.includes(allowlist[index])) {
result = true;
break;
}
}
return result;
}
您可能已經注意到，這實際上不會根據列表驗證主機名，而是在整個地址中查找子字符串匹配項。因此 https://malicious.com/?www.xunlei.com 也被認為是受信任的地址，允許對這種 “保護” 進行微不足道的規避。
現在，大多數用戶希望不會使用迅雷進行常規瀏覽。這些應該是安全的，對吧？
不幸的是，並非如此，因為網頁有多種方法可以打開迅雷瀏覽器。最簡單的方法是使用特殊 thunderx:// 地址。例如， thunderx://eyJvcHQiOiJ3ZWI6b3BlbiIsInBhcmFtcyI6eyJ1cmwiOiJodHRwczovL2V4YW1wbGUuY29tLyJ9fQ== 將打開迅雷瀏覽器並加載 https://example.com/ 到其中。然而，從攻擊者的角度來看，這種方法有一個缺點：現代瀏覽器在允許外部應用程序處理地址之前會要求用戶進行確認。
但是，還有其他選擇。例如，迅雷瀏覽器擴展程序（根據 Chrome 網上應用店的數據，有 2800 萬用戶）旨在將下載內容傳遞給迅雷應用程序。然而，它可以在沒有任何用戶交互的情況下傳遞 thunderx:// 鏈接，這些鏈接會立即在迅雷瀏覽器中打開任意網頁。
XLLite 應用程序的 API 也公開了實現此目的的更多方法，稍後將介紹。這甚至可能還沒有結束。
修復
雖然迅雷從未向我傳達過這些問題的任何解決方案，但從迅雷加速器 12.0.8.2392（根據可執行簽名判斷，於 2024 年 2 月 2 日構建）開始，已經實施了幾項更改。首先，該應用程序不再打包 Flash Player。如果 Flash Player 安裝在用戶的系統上，它仍會激活它，因此某些用戶仍會暴露。但是，這個 Flash Player 安裝很有可能至少是最新的（就像軟件在停產三年後可以是 “最新的” 一樣）。
isUrlInDomains () 函數已被重寫，當前邏輯顯得合理。它現在只會根據主機名的末尾檢查允許列表，不接受地址中其他地方的匹配項。因此，現在 “僅” 保留所有 xunlei.com 域可以訪問應用程序的內部 API。此域上任何位置的任何跨站點腳本漏洞都將再次使用戶面臨風險。
過時的 Chromium 基礎似乎保持不變。它仍然報告為 Chromium 83.0.4103.106，並且對 CVE-2021-38003 的利用仍然成功。
瀏覽器擴展迅雷下載支持也於 2024 年 1 月 3 日收到了更新，版本為 3.48。根據自動翻譯，此版本的更新日誌條目為：“修復了一些已知問題。” 該修復程序似乎為 event.isTrusted 屬性添加了一堆檢查，確保擴展不再那麼容易地檢測。鑑於這些限制，現在直接打開 thunderx:// 地址可能有更高的成功機會，尤其是當與社會工程相結合時。
主要應用
過時的 Electron framework
迅雷的主要應用程序基於 Electron 框架。這意味著它的用戶界面是用 HTML 編寫的，並通過 Chromium Web 瀏覽器（渲染器進程）顯示。在這裡，再次令人擔憂的是，使用的 Electron 版本是 83.0.4103.122（於 2020 年 6 月發布）。可以預期，它將與類似的舊 Chromium 瀏覽器共享大部分安全漏洞。
當然，像這樣的應用程序應該比 Web 瀏覽器暴露得更少，因為它不會只加載任何網站。但它確實適用於遠程網站，因此它處理 Web 內容的方式存在漏洞是個問題。
跨站腳本漏洞
由於基於 HTML，Xunlei 應用程序可能容易受到跨站腳本漏洞的影響。在大多數情況下，這可以通過使用 React 框架來緩解。React 通常不能處理原始 HTML 代碼，因此這裡沒有潛在的漏洞。
嗯，通常。除非 dangerouslySetInnerHTML 屬性正在使用，這通常應該避免使用。但似乎迅雷開發人員在一些地方使用了這個屬性，現在他們有代碼顯示這樣的消息：
$createElement("div", {
staticClass: "xly-dialog-prompt__text",
domProps: { innerHTML: this._s(this.options.content) }
})
如果消息內容恰好是一些惡意數據，它可能會創建 HTML 元素，從而導致執行任意 JavaScript 代碼。
惡意數據將如何最終到達這裡？最簡單的方法是通過瀏覽器。例如， MessageBoxConfirm 本機函數可以這樣調用：
native.CallNativeFunction("MessageBoxConfirm", JSON.stringify({
title: "Hi",
content: <img src="x" onerror="alert(location.href)">,
type: "info",
okText: "Ok",
cancelVisible: false
}));
當在迅雷瀏覽器中的 “受信任” 網站上執行時，這將使主應用程序顯示一條消息，並且作為副作用，運行 JavaScript 代碼 alert (location.href)。
Electron 通常對渲染器進程進行沙箱處理，確保這些進程只有有限的權限，並且漏洞更難被利用。此安全機制在迅雷應用程序中處於活動狀態。
然而，迅雷的開發者在某個時候一定認為它有一定的局限性。畢竟，他們的用戶界面需要執行大量操作。為每個此類操作提供受限接口太費力了。
因此，他們在應用程序中構建了一個通用接口。通過像 AR_BROWSER_REQUIRE 或 AR_BROWSER_MEMBER_GET 這樣的消息，渲染器進程可以指示應用程序的主（特權）進程執行任何操作。
我的概念驗證漏洞通過加載 Electron 的 shell 模塊（沙盒渲染器無法通過常規方式訪問）並調用其方法之一，成功地滥用了這個接口。換句話說，迅雷應用程序設法使這個安全邊界完全無用。
查看迅雷加速器 12.0.8.2392，我無法識別出這方面的任何改進。該應用程序仍然基於 Electron 83.0.4103.122。消息呈現代碼中潛在 XSS 漏洞的數量也沒有變化。
似乎迅雷在確定觸發具有任意內容的消息變得更加困難後就結束了一天。然而，我懷疑這是不可能的。
XLLite 應用程序
應用概述
XLLite 應用程序是在 Xunlei 框架內運行的插件之一。鑑於我從未創建迅雷帳戶來查看此應用程序的運行情況，因此我對其預期功能的理解是有限的。然而，它的目的似乎是將迅雷雲存儲集成到主應用程序中。
由於它不能直接修改主應用程序的用戶界面，因此它會在 10500 和 10599 之間隨機選擇的端口上將自己的用戶界面公開為本地 Web 服務器。該服務器實質上提供嵌入在應用程序中的靜態文件，所有功能都是在客戶端 JavaScript 中實現的。
特權操作由在端口 21603 上運行的單獨本地服務器提供。此處公開的一些 API 調用由應用程序直接處理，其他 API 調用則通過另一個本地服務器轉發到主應用程序。
我最初對 Web 界面如何訪問 API 服務器感到困惑，後者未能正確實現 CORS—— OPTION 請求沒有得到正確的響應，因此只有基本請求成功。迅雷開發人員似乎沒有設法解決這個問題，而是求助於在用戶界面服務器上代理 API 服務器。因此，API 服務器上可用的任何端點也由用戶界面服務器公開，在這裡正確（但似乎沒有必要）使用 CORS 允許從任何地方進行訪問。
所以通信的工作原理是這樣的：迅雷應用程序在一個幀中加載 http://127.0.0.1:105xx/。然後，該頁面在自己的端口上請求一些 API，例如 http://127.0.0.1:105xx/device/now。處理請求時，XLLite 應用程序在內部請求 http://127.0.0.1:21603/device/now。並且同一進程中的 API 服務器處理程序使用當前時間戳進行響應。
這種方法似乎沒有多大意義。但是，据我所知，迅雷也生產可以安裝在本地網絡上的存儲設備。據推測，這些設備運行相同的代碼來公開 API 服務器。這也可以解釋為什麼 API 服務器向網絡公開，而不是僅是本地主機服務器。
由於相當多的 API 調用可能會造成嚴重損害或至少暴露私人信息，因此需要以某種方式保護這些調用。如上所述，迅雷開發者選擇不使用 CORS 來限制訪問，而是決定將 API 暴露給所有網站。相反，他們實現了自己的 “泛身份驗證” 機制。
他們生成身份驗證令牌的方法是獲取當前時間戳，將其與長靜態字符串（在應用程序中硬編碼）連接起來，並使用 MD5 對結果進行哈希處理。此類令牌將在 5 分鐘後過期，顯然是為了阻止重放攻擊。
他們甚至執行時間同步，確保糾正網頁（在用戶計算機上運行）和 API 服務器（在用戶計算機上運行）感知到的當前時間之間的偏差。同樣，如果 API 服務器在某些情況下可以在網絡上的其他地方運行，這可能是有意義的。
毋庸置疑，這種 “身份驗證” 機制除了非常基本的混淆之外，不會提供任何價值。
這裡公開了不少有趣的 API 調用。例如， device/v1/xllite/sign 端點將使用應用程序中硬編碼的三個私有 RSA 密鑰中的一個對數據進行簽名。我不知道這個功能是做什麼用的，但我真誠地希望它儘可能遠離安全和隱私主題。
還有 device/v1/call 端點，這是在迅雷瀏覽器中打開頁面的另一種方式。兩者都 OnThunderxOpt OpenNewTab 允許這樣做，前者採用要處理的 thunderx:// 地址，後者採用要在瀏覽器中打開的原始頁面地址。
很明顯，API 公开了对用户云存储的完全访问权限。然而，我选择将注意力集中在端点 drive/v1/app/install 上，它看起来可能会造成更大的伤害。这个端点实际上被证明是一种安装二进制插件的方法。
除了已经提到的无用的 “泛身份验证” 之外，我找不到任何安全机制来阻止以这种方式安装恶意软件。但是，我找不到任何实际的插件作为示例。最后，我发现插件必须打包在包含如下 manifest.yaml 文件的存档中：
ID: Exploit
Title: My exploit
Description: This is an exploit
Version: 1.0.0
System:
- OS: windows
ARCH: 386
Service:
ExecStart: Exploit.exe
ExecStop: Exploit.exe
插件将成功安装， Thunder\Profiles\XLLite\plugin\Exploit\1.0.1\Exploit 但由于某种原因，二进制文件无法执行。也许我错过了一种安全机制，或者插件界面根本无法正常工作。
无论哪种方式，我都开始思考：如果不是让 XLLite 运行我的 “插件”，而是替换现有的二进制文件会怎样？生成具有 . ......\oops.exe 但是，这里使用的 Go 包存档器可以防止此类路径遍历攻击。
另一方面，决定将插件放入哪个文件夹的 XLLite 代码没有任何此类保护。文件夹由插件清单的 ID 和 Version 值确定。弄乱前者很不方便，它在路径中出现两次。但是将 “版本” 设置为类似 ...... 的东西达到了预期的结果。
要替换的应用程序无法运行，否则 Windows 文件锁定机制将阻止其被替换。插件安装只会替换整个文件夹。
最后，我选择用迅雷的媒体播放器来代替我的概念验证。这个通常不会运行，它包含在自己的文件夹中。使用 thunderx:// 链接让 Xunlei 运行媒体播放器也相当容易。看，在没有任何用户交互的情况下安装和执行恶意应用程序。
请记住，API 服务器向本地网络公开，这意味着网络上的任何设备也可以执行 API 调用。因此，这种攻击不仅可以从用户碰巧访问的任何网站执行，还可以由同一网络上的某个人发起，例如，当用户连接到公共 WiFi 时。
修复
从 XLLite 插件的 3.19.4 版本（根据其数字签名于 2024 年 1 月 25 日构建）开始，“泛身份验证” 方法更改为使用 JSON Web 令牌。身份验证令牌嵌入在用户界面服务器的主页中。如果不为此页面生成任何 CORS 标头，则其他网页无法提取令牌。
目前尚不清楚使用什么秘密来生成令牌。但是，如果重新启动 Xunlei 应用程序，身份验证令牌不会失效。这表示机密不是在应用程序启动时随机生成的。剩下的可能性是：随机生成的密钥存储在系统上的某个地方（正常）或应用程序中混淆的硬编码密钥（非常糟糕）。
虽然在调整身份验证后对其他终结点的调用成功，但对 drive/v1/app/install 终结点的调用现在会导致 “权限被拒绝” 响应。我没有调查端点是否已被禁用或添加了一些额外的安全机制。
XLLite 的插件系统实际上只是迅雷应用程序中至少五个完全不同的插件管理系统中的一个。另一个是主应用程序的插件系统，XLLite 应用程序作为这样的插件安装。还有更多，并 XLLiveUpdateAgent.dll 负责保持更新。它将从以下 http://upgrade.xl9.xunlei.com/plugin?os=10.0.22000&pid=21&v=12.0.3.2240&lng=0804 地址下载插件列表，并确保安装了适当的插件。
请注意，这里缺少 TLS 加密，这是非常典型的。部分问题似乎是迅雷决定为他们的下载实现自己的 HTTP 客户端。事实上，他们已经实现了许多不同的 HTTP 客户端，而不是使用 Windows API 提供的任何选项。其中一些 HTTP 客户端非常有限，甚至无法解析不常见的服务器响应，更不用说支持 TLS。其他人支持 TLS，但使用他们自己的 CA 证书列表，这恰好是 Mozilla 从 2016 年开始的列表（是的，这几乎是八年前的）。
另一个常见问题是，几乎所有这些不同的更新机制都作为常规应用程序流程的一部分运行，这意味着它们只有用户的权限。那么他们如何设法写入应用程序目录呢？那么，迅雷解决了这个问题：他们用用户的权限使应用程序目录可写！另一个安全机制被成功拆除。还有一个好处：他们可以将应用程序数据存储在同一个目录中，而不是像 AppData 那样诉诸于每个用户的废话。
总而言之，你最好不要在不受信任的网络上运行迅雷加速器（意思是：其中任何一个？您网络上的任何人或设法将自己插入您和迅雷更新服务器之间的路径的任何人都将能够操纵服务器响应。因此，该应用程序将安装恶意插件，而您甚至不会注意到任何事情。
您最好不要在与其他人共享的计算机上运行迅雷加速器。共享计算机上的任何人都可以向 Xunlei 应用程序添加恶意组件，因此下次运行它时，您的用户帐户将受到威胁。
我决定专注于 XLServicePlatform，因为与所有其他插件管理系统不同，这个系统以系统权限运行。这是因为它是一个系统服务，任何已安装的插件都将作为动态库加载到此服务进程中。显然，在这里注入恶意插件会导致整个系统受到损害。
管理服务从 http://plugin.pc.xunlei.com/config/XLServicePlatform_12.0.3.xml 下载插件配置。是的，这里没有 TLS 加密，因为有问题的 “HTTP 客户端” 不支持 TLS。因此，例如，与您在同一 WiFi 网络上的任何人都可以重定向此请求并给您恶意响应。
事实上，那个 HTTP 客户端写得相当糟糕，尽管我没有积极寻找它们，但我还是发现了多个越界读取漏洞。由于意外响应而使服务崩溃是相当容易的。
但不仅如此。XML 响应是使用 libexpat 2.1.0 解析的。由于该版本是在十多年前发布的，因此存在许多已知漏洞，包括许多关键的远程代码执行漏洞。
然而，我通常将二元利用留给其他人。继续高级问题，恶意插件配置将导致下载 DLL 或 EXE 文件，但它不会运行。这里有一个有效的安全机制：这些文件需要颁发给深圳市迅雷网络技术有限公司的有效代码签名。
但它仍然下载。还有我们的老朋友：路径遍历漏洞。选择该插件的文件名 ..\XLBugReport.exe 将覆盖 Xunlei 服务使用的合法 bug 报告器。然后，使用恶意服务器响应使服务崩溃将运行此具有系统权限的特洛伊木马错误报告程序。
我的概念验证漏洞只是在目录中 C:\Windows 创建了一个文件，只是为了证明它以足够的权限运行。但我们在这里谈论的是完整的系统妥协。
在撰写本文时，XLServicePlatform 仍然使用自己的 HTTP 客户端来下载插件，这些插件仍然没有实现 TLS 支持。服务器响应仍使用 libexpat 2.1.0 进行解析。据推测，越界读取和路径遍历漏洞已得到解决，但验证这一点需要的时间比我愿意投入的时间还要多。
应用程序仍将使其目录可写给所有用户。它还将生成许多未加密的 HTTP 请求，包括一些与下载应用程序组件相关的请求。
我已经提到过该浏览器基于过时的 Chromium 版本，主应用程序构建在过时的 Electron 平台之上，并且在整个应用程序中广泛使用了一个十年前的 XML 库。然而，这绝不是它的结束。应用程序打包了许多第三方组件，一般方法似乎是它们都不会更新。
以媒体播放器 XMP 为例，又名 Thunder Video，它是作为应用程序的一部分安装的，可以通过任何网站的 thunderx:// 地址启动。这也是一个基于 Electron 的应用程序，但它基于更旧的 Electron 59.0.3071.115（2017 年 6 月发布）。播放功能似乎是基于迅雷免费提供的 APlayer SDK，供其他应用使用。
现在您可能知道媒体编解码器是极其复杂的软件，以灾难性的安全问题而闻名。这就是为什么 Web 浏览器对它们包含哪些媒体编解码器非常谨慎的原因。然而，APlayer SDK 的媒体编解码器在十多年前就已经停产了，有些甚至很古老，我甚至无法弄清楚最初是谁开发的。有 FFmpeg 2021-06-30（可能是 4.4.4 版本左右的快照），它有数十个已知漏洞。libpng 1.0.56 于 2011 年 7 月发布，受到 7 个已知漏洞的影响。最后但并非最不重要的一点是，zlib 1.2.8-4 于 2015 年发布，受到至少两个严重漏洞的影响。这些只是一些例子。
因此，有一个非常真实的威胁，即迅雷用户可能会通过恶意媒体文件受到损害，要么是因为他们被诱骗使用迅雷的视频播放器打开它，要么是因为网站使用了几种可能的方式之一来自动打开它。
从迅雷加速器 12.0.8.2392 开始，我没有注意到这些组件的任何更新。
报告安全漏洞通常是一次冒险，语言障碍并没有让它变得更好。因此，我惊喜地发现迅雷安全响应中心甚至可以通过英语搜索找到，这要归功于网站标题的翻译。
不幸的是，有一个障碍：只有通过微信或 QQ 登录后才能提交漏洞。虽然这些社交网络在中国非常受欢迎，但事实证明，在中国境外创建一个账户几乎是不可能的。我花了太多时间来验证这一点。
就在那时，我仔细查看了一下，发现了页面上列出的电子邮件地址，作为无法登录的人的后备。因此，我在 2023-12-06 和 2023-12-07 总共发送了五份漏洞报告。报告的漏洞数量实际上更高，因为报告通常合并了多个漏洞。报告提到 2024-03-06 为出版截止日期。
一天后，我在 2023-12-08 收到了回复：
非常感谢您提交漏洞。迅雷安全响应中心已收到您的报告。一旦我们成功重现了该漏洞，我们将与您联系。
就像大多数公司一样，他们实际上没有再联系我。我看到我的概念验证页面被访问，所以我认为这些问题正在处理中，没有进一步询问。尽管如此，在 2024 年 2 月 10 日，我还是提醒说，距离出版截止日期只有一个月的时间。我这样做是因为根据我的经验，公司经常会 “忘记” 截止日期（更有可能的是：他们认为我没有认真对待它）。
一周后，我收到了另一封简洁的回复，上面写着：
迅雷安全响应中心已对漏洞进行了验证，但漏洞尚未完全修复。
通信到此结束。我真的不知道 Xunlei 认为修复了什么，以及他们仍然打算做什么。 关于这里的修复，我能说的是什么，都是通过查看当前的软件版本拼凑起来的，可能并不完全正确。
迅雷似乎没有在这次沟通后的一个月内发布任何进一步的更新。但是，鉴于该应用程序及其各种插件系统的性质，我不能完全确定。