低功耗、高風險:評估遠距廣域網路 (LoRaWAN) 裝置可能面臨的攻擊

遠距廣域網路 (Long Range Wide Area Network,簡稱 LoRaWAN) 裝置成為駭客攻擊對象已有好一段時間。本文深入探討 LoRaWAN 裝置漏洞如何遭到惡意攻擊,並檢視一下 LoRaWAN 目前的資安現況。本文是一系列三篇文章的第一篇。


不論智慧城市、工業廠房或連網農業園區都因物聯網(IoT ,Internet of Thing裝置的部署而實現了大規模的營運與遼闊的服務範圍,同時也帶來順暢而高效率的運作。許多企業機構正在尋求各種既經濟又能擴大 IoT 部署與穩定性的技術。而  LoRa (遠距) 通訊協定就是其中之一,它能讓企業將低功耗的 IoT 裝置透過無線方式連上網際網路。遠距廣域網路 (LoRaWAN)  是一種採用 LoRa 通訊協定的無線射頻技術。 LoRaWAN 能讓遼闊分散各區域的裝置經由無線電波連上網際網路。這項技術可用於氣象/追蹤監控感測器、資產設備管理、自動化控制、環境溫控等等。 

LoRaWAN 基礎架構為想要部署 IoT 解決方案的企業帶來了比現有蜂巢式行動網路基礎架構更經濟的選擇。全球許多城市都已採用 LoRaWAN 技術來管理水電公共建設與服務,例如在台灣就相當普遍:台北市政府早在 2016 年就開始鼓勵民間機構導入 LoRa 平台。台南市也在兩年多前開始使用 LoRaWAN 裝置來監控垃圾車及河川水位。還有其他城市也將 LoRaWAN 應用在各種不同情境,包括:水庫管理、生鮮食品運送,甚至是追蹤路上的腳踏車。2019 年,中國領先的網際網路服務供應商騰訊 (Tencent) 與 The Things Network 合作拓展中國的 LoRaWAN 生態系。英國政府於 2020 年撥了一筆新的基金來確保 LoRaWAN 網路與基礎架構未來能在進一步擴大至全國。德國許多城市也正在安裝 LoRaWAN 數位水表 。  

根據專門推廣 LoRaWAN 技術並由全球 500 多家企業共同參與的 LoRa Alliance 指出,全世界有 162 個國家都已出現 LoRaWAN 網路業者,這數字未來還將繼續成長。不過,雖然全球許多不同的企業都紛紛採用這項技術,但其相關的資安問題卻並未獲得徹底的探討和解決。也因如此,LoRaWAN 裝置成為駭客攻擊對象已有好一段時間。本文將探討幾起駭客利用 LoRaWAN 裝置漏洞發動攻擊的案例,並檢視一下 LoRaWAN 目前的資安現況。  

針對 LoRaWAN 的攻擊


採用  LoRaWAN 的機構大多是一些大型工業廠房、農業設施、水電公共事業或地方政府。採用這項技術的裝置都是低功耗裝置,而且通常分散於開闊的區域,也因此企業機構不一定會為這些裝置或網路提供妥善的安全防護。然而,LoRaWAN 裝置一旦遭到入侵,卻可能被駭客用來攻擊企業,進而導致作業停頓、資料外洩,或資訊遭到篡改。

例如,如果智慧水表與網路之間的通訊遭到入侵,駭客就能篡改水表的數值。同樣地,監控高速公路流量的感測器如果遭到攻擊,很可能將影響行車安全。  

ABP 模式的阻斷服務 (DoS) 攻擊


2018 年,荷蘭研究人員發布了一份有關多起 LoRaWAN 攻擊的報告。其中一起攻擊的起因是 LoRa 1.0 當中的 FRMPayload 計數器數值長度僅有 16 位元。研究人員示範,駭客可能回放 (replay) 一個預先擷取到的封包;他們會等候該計數器溢位之後再回放此封包,這樣就能造成阻斷服務 (DoS) 攻擊:

Figure 1. An example of a replay attack for ABP

圖 1:ABP 模式封包回放攻擊範例。


除非經過手動變更或韌體更新/升級,否則連線階段金鑰通常會維持不變。LoRaWAN 提供了兩種方式來讓裝置加入網路:Over the Air Activation (空中啟用,簡稱 OTAA) 或 Activation by Personalization (個人化啟用,簡稱 ABP)。其中,ABP 比 OTAA 更容易遭到加密分析攻擊。

位元翻轉 (Bit-Flipping)


不論是哪一個版本的 LoRaWAN,其訊息一致性都是依靠 Message Integrity Code (訊息一致性代碼,簡稱 MIC) 來防止訊息遭到蓄意篡改或加密。然而,訊息在網路伺服器將它解密再傳送至應用程式伺服器的途中卻已不再受到保護:

Figure 2. The setup of a bit-flipping attack, according to researchers from the Netherlands
圖 2:荷蘭研究人員指出的位元翻轉攻擊示意圖。

在這樣的情況下要確保通訊安全是一件複雜的工作,因為訊息會提早結束。若要確保訊息安全,就必須在設計上讓網路使用 SSL 通道 (最好使用用戶端 SSL 憑證) 或在 MAC 層酬載中插入另一個由 AppSKey 運算出來的 MIC 欄位。

假冒 ACK 確認封包 (ACK Spoofing)


為了延長電池續航力,LoRaWAN 加入了一個確認 (ACK) 機制來縮短無線射頻開啟的時間。但根據 Xueying Yang、Evgenios Karampatzakis、Christian Doerr 及 Fernando Kuiper 在一份 報告中指出,ACK 訊息並沒未指定它所確認的是哪一個訊息。

Figure 3. ACK messages may be repurposed to acknowledge frames other than those the application provider originally received
圖 3:ACK 訊息可能被用來確認與應用程式供應商原先收到的訊息不同的訊息。

為了示範這個問題,研究人員提出了一個方法:在終端裝置發送一個確認訊息給接收端閘道時,選擇性地干擾 (jam) 下行 (downlink) 流量。這樣終端裝置就永遠收不到回傳的確認訊息,所以它會再重新傳送七次確認訊息。接著它會認為訊息已經遺失或被拒絕,進而產生一個「mac_err」狀態。 

但是在訊號干擾的期間,駭客卻能擷取下行的確認訊息,後當終端裝置發送第二個確認訊息時,回放第一個訊息的確認訊息。

LoRa Class B 攻擊


絕大多數  LoRaWAN 環境都是採用 Class A  模式,此模式下,下行流量必須/可以跟隨在上行流量之後。Class B 則為了省電,會定期喚醒終端裝置以便在指定的收訊期間 (receiving time window) 接收訊息。 

收訊期間的長短是透過信標 (beacon) 廣播訊息來指定,包括一個 PHY 層標頭,再跟著一個信標酬載 (beacon payload):


Figure 4. Beacon frame content for the EU 863- 870MHz ISM band
圖 4:EU 863- 870MHz ISM 頻帶信標訊框 (beacon frame) 的內容。

研究人員指出,駭客可利用一些惡意的參數來輕易計算出不同的公開已知欄位,進而達到以下目的:

  • 找出 LoRa 閘道的位置 (藉由 GwSpecific 欄位再加一個包含 GPS 座標的 InfoDesc 子欄位)。
  • 發送內含極端喚醒時間的特製信標訊框來消耗裝置的電池。

根據他們的報告 (以及另一篇由 Frank Hessel、Lars Almon 與 Flor Álvarez 所發表的 LoRaWAN 安全性評估報告 ) 和 LoRaWAN v1.1 規格,信標訊框的一致性目前仍是個問題,因此最好使用 MIC 而非 CRC 來檢查時間欄位的一致性。

主金鑰 (root key) 管理


除了前述討論的所有安全機制之外,金鑰管理也是另一個安全問題。主金鑰 (root key) 用於 OTAA 裝置,該金鑰用來在 OTAA 裝置加入網路 (執行 Join Procedure) 時演算出連線階段金鑰 (session key)。 

由於網路的後端暴露於網際網路,因此歹徒可利用一些重大的弱點和漏洞 (LFI、SQL 資料隱碼攻擊、反序列化漏洞等等) 來取得機密的金鑰、讀取資料、製作下行資料封包,以及從事其他不法活動。 

為了防範這類風險,以下是 LoRaWAN 環境應落實的一些檢核項目:

  • 使用隨機產生的金鑰。
  • 避免金鑰管理伺服器和服務暴露在外 (也就是可從網際網路存取金鑰管理服務)。
  • 最好使用硬體安全模組 (HSM) 來保管金鑰。
  • 最好使用 OTAA 模式與 LoRa 1.1 版。

LoRaWAN 目前的資安現況


2020 年針對 LoRaWAN 技術推出的資安工具可說少之又少。IOActive 的研究人員發表了一個名為 LAF 的架構 (LoRaWAN Auditing Framework),並提供了一個工具來解譯、發送、製作、分析 LoRaWAN 封包並稽核一個環境,同時也用來破解某些使用低強度/預設金鑰的 LoRaWAN 封包。除此之外,研究人員還發表了一份探討 LoRaWAN 1.0.3 攻擊手法的報告,主要使用的就是這個工具。  

不過,該架構目前仍有一些限制尚待克服: 

  • 它只適用於閘道。
  • 它只能收聽上行封包。
  • 它只能收聽 64 個頻道之中的 8 個頻道。
  • Generation 和 Fuzzing 等測試技巧只對使用非彈性格式 (如 JSON) 的 LoRaWAN (Go) 有用。

同一期間也出現了另一個叫作「LoRa Craft」(與《古墓奇兵》電影女主角同名) 的工具,可用來攔截使用 Software Defined-Radio 的封包,並製作使用專為該工具開發的 LoRaWAN v1.0 與 v1.1 Scapy 層封包。然而這個工具主要還是得自己動手做,所以比之前已經流通的工具需要更多輔助工具才能使用,例如 Join-Accept 酬載的加密輔助工具,也需要 MIC 來協助破解低強度的金鑰。 

去年 5 月,SEEMOO Lab 發表了一個名為 ChirpOTLE 的架構,展示了兩項可破壞 LoRaWAN 網路可用性的攻擊,例如 LoRa class B 的時間偏移,以及一種新的篡改訊框 metadata 的假冒 ADR 攻擊。不過,研究人員的成果仍侷限於只選定幾個預設頻道來展示針對每一節點的攻擊。

這樣看來,儘管一些資安解決方案目前已在開發當中,但離全方位而容易取得的 LoRaWAN 防護仍有好長一段路要走。如欲進一步了解前述的 LoRaWAN 攻擊以及其他議題,請下載這份完整的技術簡報。  

這是一系列三篇文章的第一篇。下一篇,我們將討論如何克服研究人員所遭遇的限制。我們將探討歹徒如何運用 Software-Defined Radio (SDR) 與最佳化在多個頻道上攻擊上行及下行流量,以及利用一個非常便宜的 SDR 裝置來產生多個擴散因子 (spreading factor)。此外我們也將介紹一些可協助分析 LoRa PHY 以及 LoRaWAN 無線射頻通訊的工具。最後一篇文章將討論硬體攻擊與 LoRa 終端裝置相關的安全機制。

原文出處:Low Powered but High Risk:Evaluating Possible Attacks on LoRaWAN Devices 作者:Sébastien Dudek