黑客10秒無鑰匙開走特斯拉：重大漏洞曝出！

如今，很多特斯拉車主都已習慣不帶鑰匙用手機解鎖車輛，但最近一位網絡安全研究人員已經展示了「無鑰匙進入」把電動汽車開走的技術，新的漏洞為人們敲響了警鐘。

總部位于英國曼徹斯特的安全公司 NCC Group 首席安全顧問 Sultan Qasim Khan 表示，有一種方法能黑進特斯拉 Model 3 和 Model Y ，解鎖、啟動車輛并踩油門開走。通過重定向車主的手機或密鑰卡與汽車之間的通信，外人可以欺騙進入系統，使其認為車主就位于車輛附近。

目前有無鑰匙啟動功能的車輛遠不止特斯拉一種，Khan 表示，這種黑客攻擊并不是特斯拉獨有的。相反，這是他對特斯拉無鑰匙進入系統進行修補嘗試的結果，該系統依賴于藍牙低功耗協議（BLE）。

這是全球第一次對于 BLE 的鏈路層中繼攻擊，其破解了基于 BLE 的接近身份驗證機制。通過在鏈路層從基帶轉發數據，黑客可以繞過已知的中繼攻擊保護，包括加密的 BLE 通信，因為它繞過了藍牙堆棧的上層和解密需求。

NCC 在周日的一份報告中向其客戶提供了調查結果的詳細信息。所幸目前沒有證據表明已有竊賊利用該方式攻擊了特斯拉汽車。這家汽車制造商沒有回應置評請求。

該安全公司已經向特斯拉披露了攻擊的可能方法，但后者并不認為存在重大風險。NCC 表示，若想解決這個問題，不能簡單地通過軟件補丁進行修復，這家汽車制造商需要改變其硬件并修改無鑰匙進入系統的邏輯。

雖然特斯拉在新技術應用上經常走在行業前端，但時常會被曝出安全等方面的問題。今年 1 月，19 歲的德國的安全研安全研究員 David Colombo 也曾透露一種劫持特斯拉汽車某些功能的方法，例如開關門和控制音樂音量。他使用遠程指令控制了全球各地超過 25 輛特斯拉。

相較常規的藍牙通信，BLE 在保持同等通信范圍的同時顯著降低了功耗和成本，是將不同傳感器和控制設備連接在一起的理想選擇。

該協議旨在通過局域聯網方便地將設備高效連接在一起，面向智能門鎖、汽車、手機、筆記本電腦以及很多 IoT 設備，但這也意味著它成為了黑客潛在解鎖智能技術的方法。NCC 表示，其已能夠對其他幾家汽車制造商和科技公司的設備實現攻擊。

Khan 表示，在 iPhone 或安卓手機上使用藍牙無鑰匙開門的 Kwikset Kevo 智能鎖也受到同樣問題的影響。Kwikset 對此表示，使用 iPhone 開門的用戶可以在鎖具應用中開啟雙重身份驗證。一位發言人還補充說，iPhone APP 上操作的鎖有 30 秒的超時時間，有助于防止入侵。

該公司表示，Kwikset 將在「夏季」更新其安卓應用程序。

「Kwikset 產品的安全性至關重要，我們與知名安全公司合作評估自身產品并持續合作，以確保為消費者提供盡可能高的安全性，」一位發言人說道。

管理涉事技術的機構，藍牙技術聯盟 SIG 的一位代表表示：「SIG 優先考慮安全性，我們提供的規范包括一系列功能，為產品開發人員提供保護藍牙設備之間通信安全所需的工具 SIG 還向開發人員社區提供教育資源，以幫助他們在其藍牙產品中實施適當級別的安全性，并為安全研究社區合作的漏洞響應計劃，以負責任的方式解決藍牙規范中發現的漏洞。」

NCC 表示，由于低功耗藍牙普遍存在于消費級設備中，新漏洞的潛在攻擊面很大，這包括：

• 具有無鑰匙進入功能的汽車 —— 攻擊者可以解鎖、啟動和駕駛汽車。
• 啟用了藍牙近距離解鎖功能的筆記本電腦（配合智能手環、手機免輸密碼機制）。
• 手機 —— 犯罪分子可以阻止手機鎖定。
• 家庭智能門鎖 —— 攻擊者無需機械撬開或斷電即可解鎖與開門。
• 訪問控制系統 —— 允許攻擊者解鎖和打開門，同時冒充他人。
• 資產和醫療患者跟蹤系統 —— 有人可能會欺騙資產或患者的位置。

Sultan Qasim Khan 是開源藍牙 5 嗅探器 Sniffle 的創建者。該嗅探器可用于跟蹤藍牙信號，幫助識別設備。該技術現在經常被管理道路的政府機構用來匿名監控穿過市區的司機。

2019 年，英國消費者組織 Which 進行的一項研究曾發現，超過 200 種車型容易受到無鑰匙進入系統攻擊的影響，竊賊使用的攻擊方法相似，但細節相略有不同。

在本次攻擊特斯拉車輛的演示中，Khan 進行了「中繼攻擊」，其中黑客使用兩個小型硬件設備來轉發通信。為解鎖汽車，Khan 在距離特斯拉車主的智能手機或遙控鑰匙大約 15 碼的范圍內放置了一個中繼設備，并將第二個設備插入他的筆記本電腦再靠近汽車。該技術利用了 Khan 為藍牙開發套件設計的定制計算機代碼，這些套件在網上的售價不到 50 美元。

除專門編寫的軟件外，攻擊所需的硬件總共花費大約 100 美元，并且可以很容易地在網上買到。Khan 表示，一旦通信中繼建立起來，黑客只需「十秒鐘」就能解鎖車輛。

「攻擊者可以在晚上走到人們的家門口 —— 如果車主的手機在家里，并利用這種攻擊來解鎖和啟動停在外面的汽車…… 又或者，一旦黑客設備安裝在遙控鑰匙或手機附近，攻擊者就可以從世界任何地方發送命令，」Khan 補充道。\

參考內容：

https://www.bloomberg.com/news/articles/2022-05-16/hacker-shows-off-a-way-to-unlock-tesla-models-start-the-engine

https://newsroom.nccgroup.com/news/ncc-group-uncovers-bluetooth-low-energy-ble-vulnerability-that-puts-millions-of-cars-mobile-devices-and-locking-systems-at-risk-447952

防不勝防！在Firefox中觸發UAF漏洞

安全防護人員早已開發出各種方法來預防各類內存損壞漏洞。不過就算這樣，UAF漏洞也很難被防護，原因是它的攻擊面太多！由于它無法與源代碼中的任何特定模式相關聯，因此預防此漏洞類并非易事。在本文中，我將分析 Mozilla Firefox 中的一個UAF漏洞，該漏洞已被命名為 CVE-2022-26381。在撰寫本文時，Mozilla 錯誤條目 1756793 仍然不對公眾開放。

什么是UAF漏洞？

當訪問指向已釋放對象的指針時，就會發生UAF漏洞。它沒有任何意義！為什么程序員要釋放一個對象，然后再次訪問它？

這種情況的發生是由于當今軟件的復雜性。例如，一個瀏覽器有很多組件，每個組件都可以分配不同的對象。它們甚至可以互相傳遞這些對象以進行處理。當組件使用一個對象時，它可以釋放該對象，而其他組件仍然有一個指向該對象的指針。該指針的任何解除引用都可能導致UAF漏洞。

概念驗證

讓我們先來看看最小化的概念驗證，當在最新版本的Mozilla Firefox(97.0.1)上運行時，很有可能會崩潰。這就是 IDA 中崩潰時的示例。它發生在一個循環中：

它從內存中解除引用一個值，然后使用獲取的值進行間接調用（虛函數調用）。因此，這被認為是一個遠程代碼執行漏洞。在解除引用期間使用的“rax”寄存器的值特別有趣：0xE5E5E5E5E5E5E5E5。這是一個神奇的值，Firefox 使用它來“毒化”已釋放對象的內存，這樣從釋放對象獲取的值的解除引用將導致崩潰，因為這個值從來都不是有效的內存地址。這有助于檢測UAF的發生。

要分析UAF漏洞，就必須獲得有關釋放對象的更多信息，比如類型、大小、分配位置、釋放位置以及隨后使用的位置。在 Windows 上，這通常通過使用 GFlags 工具啟用高級調試功能來啟用各種全局標志來完成。具體來說，它可用于啟用 pageheap 并創建用戶模式堆棧跟蹤以在分配特定對象時捕獲堆棧跟蹤。不幸的是，這對 Mozilla Firefox 沒有幫助，因為 Firefox 有自己的內存管理機制，稱為 jemalloc。我們可以獲得有關該對象的更多信息的方法是在 ASAN 版本的 Firefox 上運行 PoC。你可以看到如下結果：

我們得到了很多信息。讓我們通過檢查對象的分配位置來進一步分解它：

讓我們通過查看源代碼（/builds/worker/checkouts/gecko/layout/svg/SVGObserverUtils.cpp 的第 1164 行）來進一步檢查這個問題。你可以下載Firefox 97.0.1的源代碼或使用在線版本（注意在線版本的行號可能不匹配，因為它會不斷更新）：

這是它在編譯后發布版本中的樣子。因此對象大小為 0x70 (112) 字節，用于在滾動觸發的reflow期間存儲和跟蹤幀的屬性。

然后我們想知道它在哪里被釋放和重用。ASAN提供了一個很長的堆棧跟蹤。仔細觀察就會得到一個很好的提示。讓我們首先檢查當對象被釋放時的堆棧跟蹤：

現在是隨后使用該對象時的堆棧跟蹤：

當崩潰發生和啟動對象釋放時，我們可以在堆棧跟蹤中看到" mozilla::SVGRenderingObserverSet::InvalidateAll "函數。這也與 OnNonDOMMutationRenderingChange 函數內部的發布版本的崩潰點相匹配（它表示它已內聯在 xul!mozilla::SVGRenderingObserverSet::InvalidateAll 中）。我們現在可以做一個初步的有根據的猜測：當一個對象在“mozilla::SVGRenderingObserverSet::InvalidateAll”函數中循環處理時，就會到達一個釋放正在處理的對象的代碼路徑，從而觸發了一個UAF漏洞。

現在我們已經掌握了所有實施過程，就可以通過在Firefox發布的版本上運行PoC一步一步地驗證這個假設。

首先，要知道分配對象的地址，以便我們可以監控它。這可以通過設置一個斷點來輕松實現，該斷點在分配時會打印對象的地址：

然后，讓我們看看這些對象是如何在IDA中的“mozilla::SVGRenderingObserverSet::InvalidateAll”函數的循環中被處理的。我們將打印將要被處理的對象的地址，并在隨后的虛函數調用中設置了一個斷點：

我們運行 PoC，調試器在調用虛函數之前停止。如上所示，分配了兩個對象，這兩個對象將在循環中處理。首先，處理一個對象并調用“SVGTextPathObserver::OnRenderingChange”函數，最終釋放各種分配的對象，包括等待處理的第二個對象！

我們可以在下圖中清楚地看到這一點，這是在調用返回后立即拍攝的。正如你所看到的，在處理第一個對象時，第二個對象已經被釋放(并且被0xe5毒化）：

在第二次迭代中，被釋放的對象被加載進行處理，導致有毒值的加載，并導致崩潰：

在針對發布版本運行 PoC 時，我們在解除引用 0xE5E5E5E5E5E5E5E5 期間發生了崩潰。但是，在 ASAN 版本中，它在寫入內存時崩潰。為什么有區別？原因如下：

在release(非asan)構建中，當釋放一個對象時，它的內存仍然是可訪問的(而不是未映射的)，因此對該內存的任何讀取和寫入仍然可正常進行，而不會立即觸發崩潰。這就是為什么指令“mov byte ptr [rcx+8], 0”在上圖中沒有錯誤的執行。不過，崩潰可能會在更長的時間內發生。在本文的示例中，如果從釋放的對象中獲取一個值，然后解除引用，那么解除引用可能會導致崩潰。如果釋放的對象內容被上面看到的毒值覆蓋，則尤其如此。請注意，有可能根本不會發生崩潰，例如，如果只對釋放的對象進行讀取和寫入，而沒有對獲取的值進行任何解除引用操作，或者有毒的值被不相關的數據覆蓋。這意味著，如果我們對發布版本進行模糊處理，就有可能錯過一個漏洞。

另一方面，ASAN監視內存上的所有讀、寫和解除引用，可以盡快捕獲此類漏洞。這就是為什么推薦使用ASAN版本進行模糊測試的原因。

漏洞修復

UAF漏洞通常通過將原始指針轉換為智能指針或通過更正對象引用計數的管理來修復。這樣就可以通過更改引擎中處理連續幀循環的方式來修復它：

總結

開發人員已經花費了大量的精力來消除源代碼中與已知模式相關的漏洞，并且他們基本上成功地降低了這些漏洞的影響。然而，有一些類型的漏洞更難預防，UAF就是其中之一。確保對具有一百萬行代碼的軟件中的對象生命周期進行完美管理是極其困難的。