SecTor 2025 | Sharing Is Caring About an RCE Attack Chain on Quick Share
三句話摘要
SafeBreach 研究員揭露 Google QuickShare Windows 版的 10 個漏洞，並組合出完整的遠端程式執行（RCE）攻擊鏈，全程無需受害者任何授權操作。 單一低風險漏洞的真正危險性在於與其他漏洞組合的潛力——QuickShare 案例證明，五個「看似無害」的能力足以拼出一條完整的零互動 RCE 鏈。 「石頭也能鑄成長矛」的漏洞組合哲學： 研究者發現的每個單一漏洞看似影響輕微，但透過創意組合——靜默寫檔、強制 Wi-Fi 連線、DoS 崩潰、重複開檔——形成完整 RCE 鏈，說明看似「低風險」的漏洞不能以孤立方式評估。
重點整理
重點- 1
「石頭也能鑄成長矛」的漏洞組合哲學： 研究者發現的每個單一漏洞看似影響輕微，但透過創意組合——靜默寫檔、強制 Wi-Fi 連線、DoS 崩潰、重複開檔——形成完整 RCE 鏈，說明看似「低風險」的漏洞不能以孤立方式評估。
- 2
HTTPS 加密無法隱藏下載行為的身份： 即使傳輸內容已加密，TLS Client Hello 中的 SNI（伺服器名稱指示）仍洩漏目標域名，加上 TCP 單一連線的傳輸大小，可以 ~99% 準確率判斷受害者正在下載哪個安裝檔。
- 3
Chrome 下載流程存在可利用的競爭視窗： Chrome 在下載完成前先確定最終檔名，以臨時 `.crdownload` 檔案存儲，完成後才重新命名。若在重新命名前用 QuickShare 寫入同名檔並「鎖住」它，Chrome 便無法覆蓋，實際執行的是惡意程式。
- 4
Google 的修補被成功繞過： 針對靜默寫檔的修補（下載後刪除「未知檔案」）被用相同 Payload ID 傳兩個不同檔案的方式繞過，顯示修補本身的邏輯仍有盲點。
實用技巧與重點
乾貨- 工具與技術：
- 模糊測試：WinAFL + DynamoRIO + libprotobuf-mutator
- 自製工具：QuickSniff（Hook read/write 函數，解析 Protobuf 封包為文字）
- 攻擊工具：QuickShell（完整 RCE 利用鏈工具，已開源至 GitHub）
- 協定：Nearby Connections API、Protobuf、uKey2（Google 加密庫）、WebRTC、Wi-Fi、Bluetooth、NFC
- 發現的 10 個漏洞類型：
- 檔案接受繞過（無需使用者確認即寫入下載資料夾）
- 強制連線 Wi-Fi 熱點（Windows 版可上網，Android 版已被鎖不能上網）
- 多個 DoS 漏洞（可遠端崩潰 QuickShare）
- 重複開啟指定檔案（null terminator 加在副檔名前）
- 有限路徑穿越（僅能跨到下載資料夾父目錄）
- 關鍵數字：
- Wi-Fi 劫持原本最多 30 秒；崩潰 QuickShare 後可無限延長
- QuickShare 安裝後有排程任務每 15 分鐘檢查是否在運行，崩潰後自動重啟
- VS Code 安裝檔約 95 MB，從 visualstudio.com 下載，可 ~99% 確定名稱
- Google 共發出 3 個 CVE（2 個對應原始 10 漏洞，1 個對應繞過修補）
- RCE 鏈 5 步驟：
- QuickShare 強制受害者 Wi-Fi 連至攻擊者熱點
- DoS 崩潰 QuickShare，使 Wi-Fi 永久劫持
- 監控 SNI + TCP 傳輸大小，推算下載中的安裝檔名
- 用靜默寫檔漏洞傳送同名惡意檔至下載資料夾
- 觸發「重複開檔」鎖住惡意檔，再放行最後一個 TCP 封包，Chrome 重新命名失敗，受害者執行的是惡意程式
結論
結論“單一低風險漏洞的真正危險性在於與其他漏洞組合的潛力——QuickShare 案例證明，五個「看似無害」的能力足以拼出一條完整的零互動 RCE 鏈。”
完整解析
詳細SafeBreach 的 Orya 與 Cohen 選擇 Google QuickShare 作為研究目標，原因是 Google 在 CES 2024 宣布將其預裝於各大 PC 品牌的 Windows 版本，等同大幅擴大了攻擊面。QuickShare 的底層使用 Nearby Connections API 搭配 Protobuf 封包結構與 uKey2 加密，且大部分程式碼為開源，這為研究帶來便利。研究者首先自製了 QuickSniff 工具，透過 Hook 底層 read/write 函數來即時解析所有傳輸封包，從而掌握整個協定流程：從連線握手、uKey2 加密交換，到裝置可見性驗證、檔案介紹封包、使用者接受確認，再到實際傳輸，完整還原了 QuickShare 的通訊邏輯。
在理解協定後，研究者以 WinAFL + DynamoRIO + libprotobuf-mutator 建立模糊測試環境，對整個檔案傳送流程進行變異測試。雖然速度較慢且最佳化嘗試引發 race condition 而放棄，模糊測試仍找到了數個可重現的 DoS 崩潰，以及一個特殊行為：在副檔名前插入 null terminator 可讓 QuickShare 持續重複開啟指定檔案。這些發現看似有限，促使研究者轉向純邏輯分析。邏輯研究的成果遠超預期：他們發現只要直接傳送 Payload Transfer 封包（跳過檔案介紹與使用者確認），QuickShare 就會默默將任意檔案寫入受害者的下載資料夾，且完全繞過裝置可見性設定，Windows 與 Android 皆受影響。另外，QuickShare 的頻寬升級協商機制允許一方傳送 Wi-Fi 熱點的 SSID 與密碼，強制對方連線，Windows 版更允許受害者透過此惡意 Wi-Fi 正常上網。
有了「靜默寫入下載資料夾」與「強制 Wi-Fi 連線」這兩個能力，研究者開始思考能否組合出 RCE。他們的核心洞察是：下載資料夾正是瀏覽器存放下載安裝檔的地方。若能在受害者執行安裝檔前以惡意版本替換，即可達成 RCE。要做到這一點，首先需要知道受害者下載了什麼：他們發現即便 HTTPS 加密了內容，TLS 握手的 SNI 欄位仍洩漏目標域名，而 TCP 連線的傳輸大小則能精確對應到特定安裝檔（例如從 visualstudio.com 下載約 95 MB 幾乎必然是最新版 VS Code 安裝檔）。接著，他們深入研究 Chrome 下載機制：Chrome 在開始下載前確定最終檔名，以 `.crdownload` 暫存，完成後再重新命名。他們的策略是：透過 Wi-Fi 中間人攔截最後一個 TCP 封包、趁機傳入同名惡意檔，並立即觸發「持續開啟該檔案」的 DoS 漏洞將其鎖定，再放行最後的封包。Chrome 完成下載嘗試重新命名時，因同名檔已被鎖定而失敗，介面顯示下載成功，使用者點擊後執行的是攻擊者的程式。至於 Wi-Fi 連線的 30 秒限制，則靠崩潰 QuickShare 來延長；QuickShare 有每 15 分鐘自動重啟的排程任務，確保後續攻擊步驟仍能繼續。
Google 在收到報告後配合度高，針對 10 個漏洞共發出 2 個 CVE 並提供修補。但研究者在驗證修補時發現：DoS 修補只過濾了 null terminator，換用其他無效 UTF-8 位元組仍可觸發；靜默寫檔的修補改為在傳輸結束後刪除「未知檔案」，研究者則以「兩個不同內容的檔案使用相同 Payload ID」的方式繞過，使系統只刪其中一個，另一個留存，並因此獲得第三個 CVE。研究者的三大結論是：看似無害的漏洞在創意組合下可能致命；廠商不應因單一漏洞「風險低」而延遲修補，因為它可能是更大攻擊鏈的一環；安全評估不應只聚焦記憶體破壞漏洞，設計層面的行為（如強制 Wi-Fi 連線）同樣可能成為攻擊入口。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
