藍(lán)牙安全與攻擊案例分析
本文是 2020 年中旬對于藍(lán)牙技術(shù)棧安全研究的筆記，主要針對傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙在協(xié)議層和軟件安全性上攻擊面分析，并介紹了一些影響較大的藍(lán)牙漏洞原理，比如協(xié)議層的 KNOB、BIAS 漏洞，軟件實現(xiàn)上的 BlueBorne、SweynTooth 以及 BlueFrag 漏洞等。
前言
藍(lán)牙(Bluetooth)是一個短距離無線傳輸?shù)募夹g(shù)，工作在免證的ISM頻段。最初名字為Wibree，在90年代由Nokia設(shè)計開發(fā)，隨后轉(zhuǎn)交給藍(lán)牙特別興趣小組(SIG)專門維護(hù)。
藍(lán)牙標(biāo)準(zhǔn)經(jīng)過了數(shù)十年不慍不火的發(fā)展，核心版本從1.0迭代了到目前的5.2，其中在2010年推出的藍(lán)牙4.0版本標(biāo)準(zhǔn)中引進(jìn)了Bluetooth Smart或者Buletooth Low Energy(BLE)。由于在功耗上有了極大改善，加上智能手機(jī)和智能設(shè)備的發(fā)展，BLE的應(yīng)用也進(jìn)入了爆發(fā)期。
4.0之前藍(lán)牙通常稱為經(jīng)典藍(lán)牙(Classic Bluetooth)，包括1.0提出的BR(Basic Rate，基礎(chǔ)速率)以及2.0提出的EDR(Enhanced Data Rate，增強(qiáng)數(shù)據(jù)速率)，兩者往往放在一起表示與低功耗藍(lán)牙相對的傳統(tǒng)藍(lán)牙。BR/EDR常用于相對短距離無線的連續(xù)連接，比如耳機(jī)的音頻傳輸。
為了進(jìn)一步提高藍(lán)牙傳輸速率，在3.0中又提出了基于802.11的AMP(Alternate MAC and PHY layer extension)拓展，這是和BR/EDR不并存的一種傳輸模式。
核心系統(tǒng)
BR/EDR和BLE雖然都稱為藍(lán)牙，但它們在實現(xiàn)上大相徑庭。前者主要側(cè)重于點對點的通信，連接性和傳輸速率是考慮的重點；而BLE則側(cè)重于低功耗的設(shè)計，在射頻層和基帶層上優(yōu)化了多播和廣播的支持。傳統(tǒng)上Controller芯片只支持一種射頻模式，但越來越多設(shè)備中也同時支持兩種系統(tǒng)，以覆蓋盡量多的使用場景。
藍(lán)牙的核心系統(tǒng)架構(gòu)包含一個Host和一個或多個Controller，Host可以理解為主核或者主板，運行主流的富操作系統(tǒng)；而Controller可以看做是藍(lán)牙芯片，運行的是裸機(jī)程序或者RTOS，主要功能是對射頻信號進(jìn)行編解碼。Host和Controller之間通過HCI接口(Host Controller Interface)進(jìn)行通信，可通過UART、USB等物理接口進(jìn)行傳輸。核心系統(tǒng)中包含的組件和之間的關(guān)系如下圖所示：
其中Host部分主要是基于L2CAP抽象出的邏輯信道實現(xiàn)應(yīng)用層的協(xié)議和功能，涉及的關(guān)鍵組件和協(xié)議有：
?Channel Manager：負(fù)責(zé)創(chuàng)建、管理和釋放L2CAP channel。?L2CAP Resource Manager：負(fù)責(zé)管理PDU數(shù)據(jù)的順序、調(diào)度、分片、重組等功能，是L2CAP核心功能的一部分。?SMP：Security Manager Protocol，實現(xiàn)BLE系統(tǒng)中的點對點安全認(rèn)證功能，包括秘鑰生成和認(rèn)證等；BR/EDR系統(tǒng)的對應(yīng)功能則在Controller的Link Manager中實現(xiàn)。?ATT：Atrribute Protocol，應(yīng)用層attribute client和server之間的協(xié)議。?GATT：Generic Attribute Profile，表示ATT server或者client的功能，profile描述了服務(wù)和屬性的層級結(jié)構(gòu)，主要用于LE profile服務(wù)發(fā)現(xiàn)中。?GAP：Generic Access Profile，表示所有藍(lán)牙設(shè)備通用的基礎(chǔ)功能，比如傳輸層、協(xié)議、應(yīng)用所使用的模式或流程等。GAP服務(wù)包括設(shè)備和服務(wù)發(fā)現(xiàn)、連接模式、安全認(rèn)證和關(guān)聯(lián)模型等。
Controller部分中更多是邏輯鏈路和物理鏈路的管理，包括：
?Device Manager：基帶(baseband)中控制設(shè)備行為的模塊，主要負(fù)責(zé)不與傳輸直接相關(guān)的部分，比如查詢周圍藍(lán)牙設(shè)備，連接藍(lán)牙設(shè)備，切換藍(lán)牙設(shè)備的狀態(tài)(discoverable/connectable)，以及修改藍(lán)牙名稱、屬性等。?Link Manager：負(fù)責(zé)創(chuàng)建、修改和釋放邏輯鏈路(logical links)以及對應(yīng)的邏輯傳輸(logical transports)，并更新設(shè)備之間對應(yīng)物理鏈路(physical links)的相關(guān)參數(shù)。在BR/EDR系統(tǒng)中，與對端的Link Manager通過LMP協(xié)議(Link Manager Protocol)進(jìn)行通信；在BLE系統(tǒng)中則使用的是LL協(xié)議(Link Layer Protocol)。?Baseband Resource Manager：負(fù)責(zé)管理所有到射頻媒介的訪問。在鏈路層中，有兩種類型的“連接”：?SCO：Synchronous Connection Orientated，實時窄帶數(shù)據(jù)傳輸，如電話音頻等，無重傳?ACL：Asynchronous Connection-Less，異步無連接，用以其他所有數(shù)據(jù)的傳輸?Link Controller：負(fù)責(zé)對指定物理信道(邏輯鏈路和邏輯傳輸)的藍(lán)牙數(shù)據(jù)進(jìn)行編解碼。
藍(lán)牙核心系統(tǒng)的每個組件或協(xié)議都可以用獨立的章節(jié)去介紹，整個結(jié)構(gòu)的宏觀理解對后面梳理藍(lán)牙的攻擊面是非常有必要的。從前面的圖中我們可以看到，BR/EDR和BLE在鏈路層以下是相當(dāng)不同的，前者為LM而后者為LL，下面分別進(jìn)行介紹。
BR/EDR
在傳統(tǒng)藍(lán)牙(即BR/EDR)中，2.4GHz的ISM頻段分成79個頻段，每個大小為1MHz，并使用特定的跳頻模式(Hopping Pattern)來決定一條物理信道，從而減少不同臨近終端之間的射頻干擾。BR/EDR使用點對點的主從模式，其中Master為確定跳頻模式的一方，Slave為與Master時鐘和跳頻模式同步的其他端點。
傳統(tǒng)藍(lán)牙建立鏈路層連接主要經(jīng)歷兩個階段：Inquiry和Paging。
Inquiry階段，Master發(fā)送查詢請求，周圍(10米內(nèi))可被發(fā)現(xiàn)的設(shè)備(discoverable)收到請求后會發(fā)送查詢響應(yīng)(Inquiry Response)。在查詢過程中，因為與周圍設(shè)備還未連接，因此它們很可能處于不同的信道(跳頻序列)，實際上發(fā)送查詢的設(shè)備會在不同的頻率進(jìn)行發(fā)送，而接收方(處于standby模式)則以更高地頻率進(jìn)行足夠長時間的查詢掃描(Inquiry Scan)以確保能被正確喚起。查詢響應(yīng)中包含設(shè)備ID和時鐘等信息。
Paging階段，主要解決的是鏈路層的連接問題。與Inquiry類似，此時各方同樣沒有進(jìn)行時鐘和頻率的同步。Master與Slave的連接需要經(jīng)過以下六步：
連接狀態(tài)的兩個設(shè)備所處于的抽象網(wǎng)絡(luò)稱為piconet，這是一個星狀網(wǎng)絡(luò)，一個Master可以有最多七個Slave，但是Master本身也可以是其他piconet的Slave，這種網(wǎng)絡(luò)拓?fù)浞Q為scatternet。傳統(tǒng)藍(lán)牙處理鏈路層連接的管理器稱為LM，即Link Manager，兩個LM之間通過LMP協(xié)議進(jìn)行通信。
這只是鏈路層的連接，和我們平常所說的藍(lán)牙配對(pairing)并不是一回事。Paging只是保證了在物理層鏈路的連通性，進(jìn)行應(yīng)用層的通信往往還需要經(jīng)歷兩步：
?服務(wù)發(fā)現(xiàn)(Service Discovery)：用以確認(rèn)對端所支持的服務(wù)?服務(wù)連接(Service Connection)：使用某個對端設(shè)備特定的服務(wù)或者配置(Profile)
但是實際上在服務(wù)發(fā)現(xiàn)之前，藍(lán)牙引入了一層安全性保障，確保雙方是自愿連接的，溝通連接意愿的過程就稱為配對。經(jīng)過配對后的設(shè)備會分別記住對方，在下一次連接時就不需要進(jìn)行重新配對，而是使用之前保存的連接秘鑰(Link Key)直接進(jìn)行認(rèn)證和連接：
藍(lán)牙Spec中定義了legacy authentication和secure authentication情況下的認(rèn)證流程和狀態(tài)。當(dāng)兩個設(shè)備沒有共同的link key時，就需要使用pairing流程來協(xié)商創(chuàng)建初始化秘鑰Kinit。關(guān)于配對流程的分析在后面會詳細(xì)介紹。
?https://courses.cs.washington.edu/courses/cse474/18wi/pdfs/lectures/BlueTooth.pdf?https://stackoverflow.com/questions/36396456/bluetooth-difference-between-pairing-and-paging-bonding
BLE
在BLE中，2.4GHz的ISM頻段分成40個頻段，每個大小為2MHz，其中3個信道為廣播信道(advertising channel)，其余37個為通用信道(general purpose channel)。BLE也支持對建立連接后的端點在通用信道中進(jìn)行跳頻通信。
各個信道的頻率為:
f = 2402 + k * 2 MHz, k = 0, 1, ... , 39
BLE鏈路層的狀態(tài)機(jī)包括以下狀態(tài)：
?Standby State?Advertising State?Scanning State?Initiating State?Connection State?Synchronization State?Isochronous Broadcasting State
任一時刻只能處于其中的一種狀態(tài)，有限狀態(tài)機(jī)的轉(zhuǎn)換過程如下：
實際中的鏈路層的狀態(tài)機(jī)不一定要實現(xiàn)上述完整的狀態(tài)，但藍(lán)牙標(biāo)準(zhǔn)中定義了一些相互依賴的狀態(tài)組合，實現(xiàn)了其中一種就必須要實現(xiàn)另外一種。任何其他狀態(tài)都可以直接進(jìn)入Standby狀態(tài)，而只有Advertising和Initiating狀態(tài)才能進(jìn)入Connection狀態(tài)。Connection狀態(tài)中連接的雙方分別根據(jù)來源狀態(tài)定義為：
?Master Role：從Initiating狀態(tài)進(jìn)入?Slave Role：從Advertising狀態(tài)進(jìn)入
與傳統(tǒng)藍(lán)牙類似，一個Slave只能與一個Master進(jìn)行連接。在BLE中，鏈路層數(shù)據(jù)包所包含的數(shù)據(jù)稱為協(xié)議數(shù)據(jù)單元(PDU)，Advertising的三個物理信道包含Advertising PDU、Scanning PDU和Initiating PDU，數(shù)據(jù)信道包含LL Data PDU和LL Control PDU等，不同的PDU包含不同類型的Payload。當(dāng)然這都是發(fā)生在雙方Controller端的LL之間，Host端還是主要使用HCI協(xié)議對其進(jìn)行封裝，根據(jù)不同的場景我們可能需要專注某一端的的實現(xiàn)，比如對于藍(lán)牙芯片固件的研究更多是對LL端的數(shù)據(jù)進(jìn)行分析，其他情況下對于應(yīng)用層或者開發(fā)者則更多地關(guān)注Host端的HCI、L2CAP、ATT等協(xié)議。
Security
藍(lán)牙的服務(wù)發(fā)現(xiàn)和調(diào)用不考慮安全性的話可以直接在同步完物理信道后直接進(jìn)行應(yīng)用層交互，但為了避免竊聽和中間人等攻擊，甚至是為了避免錯誤連接到其他同名設(shè)備，藍(lán)牙服務(wù)也是必須要有安全性保障的。初次接觸藍(lán)牙Spec的人可能會對藍(lán)牙連接和配對的概念比較困惑，因為藍(lán)牙標(biāo)準(zhǔn)在不同版本中定義了不同的配對模型，而BR/EDR和BLE的配對過程又發(fā)生在不同的模塊中。比如BR/EDR配對過程由雙方Controller端的LM(Link Manager)使用LMP協(xié)議進(jìn)行協(xié)商，而BLE的配對過程則主要通過Host端的協(xié)議棧(Security Manager)進(jìn)行協(xié)商。
從時間線上來看，BR/EDR分為幾個階段：
?2.1之前：使用Legacy Pairing，后續(xù)版本中稱為BR/EDR legacy?2.1：使用 Secure Simple Pairing?4.2：使用 Secure Connection
BLE也經(jīng)歷了幾個階段的變化：
?4.0和4.1：使用 Secure Simple Pairing，后續(xù)版本中稱為BLE legacy?4.2：使用 Secure Connection
Legacy Pairing 使用雙方輸入或者固定的PIN CODE來進(jìn)行認(rèn)證，現(xiàn)在已經(jīng)非常少見，因此可以不用關(guān)注。
Secure Simple Pairing 的配對方式主要經(jīng)過以下4步(以BR/EDR為例)：
1.IO capabilities exchange：交換對方的特性，比如是否支持顯示和鍵盤輸入等，用以后續(xù)協(xié)商認(rèn)證手段2.Public key exchange：交換橢圓曲線的公鑰3.Authentication stage 1：身份認(rèn)證4.Authentication stage 2：ECDH Key校驗
對于身份認(rèn)證，BR/EDR定義了4種認(rèn)證方式：
?Just Works：靜默認(rèn)證，主要用于沒有顯示和輸入功能的設(shè)備，如耳機(jī)等?Numeric Comparison：雙方生成隨機(jī)數(shù)并計算出一個6位數(shù)字進(jìn)行比對確認(rèn)?Passkey Entry Authentication：主要用于一方有顯示功能另外一方有輸入功能的場景?OOB(Out Of Band)：使用藍(lán)牙射頻以外的其他通道(如NFC)來交換認(rèn)證信息
前面說了BR/EDR 2.1和BLE4.0/4.1都使用Secure Simple Pairing進(jìn)行配對，為什么還特地強(qiáng)調(diào)是BR/EDR呢？因為雖然他們都叫做SSP，但實際上也存在不同的地方，比如BLE的SSP沒有使用ECDH，因此數(shù)字的認(rèn)證只能防止被動竊聽(passive eavesdropping)，不能防止中間人攻擊，并且BLE中沒有Numeric Comparison的認(rèn)證方式。
不過，這也只是過去式了。在4.2以后，BLE和BR/EDR終于統(tǒng)一了配對流程，稱為Secure Connection。其在SSP的基礎(chǔ)上進(jìn)行了安全性的增強(qiáng)，下面是BR/EDR的對比：
| 安全特性\配對類型 | Legacy | Secure Simple Pairing | Secure Connection |
| 加密 | E0 | E0 | AES-CCM |
| 認(rèn)證 | SAFER+ | SAFER+ | HMAC-SHA256 |
| 秘鑰生成 | SAFER+ | P-192 ECDH HMAC-SHA-256 | P-256 ECDH HMAC-SHA-256 |
而BLE也是殊途同歸，最新實現(xiàn)的配對方式也升級成了功能相同的 Secure Connection。
?https://stackoverflow.com/questions/39592435/pairing-differences-between-bluetooth-and-bluetooth-le?https://security.stackexchange.com/questions/116027/difference-between-secure-simple-pairing-and-secure-connections-in-bluetooth
常見協(xié)議
在前面的介紹中我們已經(jīng)多次提到，主機(jī)系統(tǒng)稱為Host，藍(lán)牙射頻芯片的系統(tǒng)稱為Controller，它們之間的通信接口稱為HCI(Host Controller Interface)，同時這也是其傳輸協(xié)議的名字。HCI是Host端所能接觸的最底層協(xié)議，通過內(nèi)核的HCI驅(qū)動進(jìn)行操作，基于HCI逐步往上封裝和實現(xiàn)了一系列高級協(xié)議，本節(jié)就以自底向上的角度去進(jìn)行介紹。
HCI
HCI協(xié)議是HCI接口最底層的協(xié)議，可根據(jù)傳輸層的介質(zhì)分為不同類型，例如：
?UART傳輸層：在btsnoop中表示為hci_h4?USB傳輸層：在btsnoop中表示為hci_h5?SD傳輸層：Secure Digital?...
HCI數(shù)據(jù)包分為command、event和data三種類型。command表示Host發(fā)送給Controller的命令，event為Controller發(fā)送給Host的事件，data通常是實際的藍(lán)牙傳輸數(shù)據(jù)。
HCI command的格式為：
16bit opcode | 8bit 參數(shù)長度 | 可變參數(shù)其中opcode又分為兩部分，高6位為OGF(Opcode Group Field)，低10位為OCF(Opcode Command Field)。在Linuz中我們常用的bluez框架也可以直接發(fā)送hci命令：
$ hcitool cmd --helpUsage:cmd <ogf> <ocf> [parameters]Example:cmd 0x03 0x0013 0x41 0x42 0x43 0x44
HCI event的格式為：
1bit event code | 1bit 參數(shù)長度 | 可變參數(shù)通常Host發(fā)送的command都會收到Controller的返回event，提示命令的執(zhí)行結(jié)果。例如，HCI命令0x200c表示LE Set Scan Enable，并通過參數(shù)控制開啟和關(guān)閉BLE的掃描，Controller執(zhí)行完畢后返回event code 0x0e，即Command Complete，并附帶status作為參數(shù)表示結(jié)果是否成功。詳細(xì)的命令和事件列表可以參考Core_v5.2 Vol 4: Host Controller Interface, Part E-7 HCI commands and events。
除了command和event，HCI中還包括的一大載荷就是數(shù)據(jù)，比如前面提到的同步數(shù)據(jù)包SCO、ISO(isochronous)和無連接數(shù)據(jù)包ACL等。
ACL
HCI的ACL協(xié)議主要用于在Host和Controller之間傳輸數(shù)據(jù)，ACL數(shù)據(jù)包的格式如下：
12bit | 2bit | 2bit | 16bit | varlenHandle | PB flag | BC flag | Data Total Length | data
其中，Handle用于區(qū)分Host與Controller之間的邏輯鏈路，PB為Packet Boundary即包邊界標(biāo)志，BC(Broadcast)為廣播標(biāo)志。由于數(shù)據(jù)總長度只用2個字節(jié)表示，因此數(shù)據(jù)加上頭部最多也只有65535字節(jié)，這意味著在發(fā)送過大的數(shù)據(jù)時需要在ACL層進(jìn)行分包和重組，PB Flag就是為了這個目的而設(shè)置的，根據(jù)PB Flag的值可以表示當(dāng)前數(shù)據(jù)包在完整數(shù)據(jù)中所處的位置。
L2CAP
ACL只提供了一個數(shù)據(jù)傳輸協(xié)議，類比于網(wǎng)絡(luò)協(xié)議棧中的IP協(xié)議，在其之上使用的L2CAP協(xié)議可以類比于TCP/UDP協(xié)議，實現(xiàn)了更為完善的數(shù)據(jù)傳輸功能，包括：
1.協(xié)議/信道(L2CAP channel)多路復(fù)用2.分段(segmentation)和重組(reassembly)3.基于L2CAP channel的流量控制機(jī)制4.錯誤控制重傳機(jī)制5.支持流式傳輸(streaming)6.分片(fragmentation)和重組(recombination)7.QoS(Quality of Service)8....
L2CAP channel表示兩個設(shè)備之間的一條邏輯鏈路，使用channel id(CID)進(jìn)行區(qū)分，并以此為基本單元在Controller邏輯鏈路上進(jìn)行多路復(fù)用。在基于連接的信道(connection-oriented channels)中，L2CAP PDU也稱為B-Frame，其格式如下：
16bit length | 16bit CID | information payload前32bit稱為L2CAP header，length是除了header以外的payload長度。在不同的L2CAP模式中，information payload的內(nèi)容也不盡相同，比如在Supervisor Frame(S-Frame)、Information Frame(I-Frame)。而對于無連接的L2CAP數(shù)據(jù)包，在payload之前還包含大于等于2字節(jié)的PSM(Protocol/Service Multiplexer)，頭部還是和B-Frame一致的。
在L2CAP之上，有著各種各樣的應(yīng)用層協(xié)議，比如服務(wù)發(fā)現(xiàn)協(xié)議SDP，藍(lán)牙傳輸協(xié)議RFCOMM/OBEX，BLE的屬性協(xié)議ATT，甚至是通用以太網(wǎng)協(xié)議BNEP以及其上的TCP/IP網(wǎng)絡(luò)棧等。通過分層和抽象使得上層應(yīng)用無需關(guān)心底層的細(xì)節(jié)，從而實現(xiàn)了整個藍(lán)牙協(xié)議棧的普適性和拓展性。
協(xié)議安全
這里的協(xié)議安全不是指網(wǎng)絡(luò)協(xié)議棧的安全性，而是藍(lán)牙核心協(xié)議，或者說藍(lán)牙標(biāo)準(zhǔn)本身的安全性。雖然藍(lán)牙SIG小組在制定標(biāo)準(zhǔn)前都經(jīng)過了多方討論和研究，可依然可能存在一些沒有考慮周到的臨界情況。
KNOB
KNOB Attack是2018年3月發(fā)現(xiàn)，并在同年10月報告給藍(lán)牙SIG和CERT的一個通用協(xié)議漏洞。漏洞點主要出現(xiàn)在LMP協(xié)議的秘鑰協(xié)商階段，正常來說，兩個藍(lán)牙設(shè)備連接和配對的過程如下：
配對之后會先進(jìn)行藍(lán)牙秘鑰協(xié)商，協(xié)商過程使用的是配對過程協(xié)商的ECDH臨時秘鑰以保證協(xié)商過程保密。協(xié)商過程使用LMP協(xié)議，在各自的Controller端實現(xiàn)：
問題就出在LMP entropy（熵)協(xié)商的階段，因為這部分的協(xié)商過程是沒有經(jīng)過ECDH秘鑰保護(hù)的，所以就容易受到中間人攻擊，惡意的攻擊者可以將熵設(shè)置得盡可能小，從而可以在后面快速地爆破出Kc并實時解密藍(lán)牙的傳輸數(shù)據(jù)。這也是為什么該攻擊稱為KNOB(Key Negotiation of Bluetooth) Attack的原因。
該漏洞的編號為CVE-2019-9506[1]，由于是藍(lán)牙核心協(xié)議中的設(shè)計漏洞，因此影響了大量的藍(lán)牙設(shè)備，比如Broadcom、CYW、Apple、Snapdragon等藍(lán)牙芯片。修復(fù)方法自然是對秘鑰熵協(xié)商的過程進(jìn)行加密，不過這個要等SIG更新進(jìn)標(biāo)準(zhǔn)中，而標(biāo)準(zhǔn)的更新和推進(jìn)又相對緩慢，因此很多藍(lán)牙芯片廠商也各自更新了固件做簡單的patch。該漏洞的直接危害就是導(dǎo)致藍(lán)牙鏈路的中間人攻擊，導(dǎo)致傳輸信息泄露或者劫持，實際攻擊場景比如藍(lán)牙鍵盤、藍(lán)牙鼠標(biāo)等應(yīng)該是受影響比較大的。
參考資料：
?https://knobattack.com/?https://github.com/francozappa/knob?https://francozappa.github.io/publication/knob/slides.pdf
BIAS
BIAS全稱為Bluetooth Impersonation Attacks，是2020年5月左右公開的另外一個藍(lán)牙協(xié)議的漏洞，CERT編號為CVE-2020-10135[2]。該漏洞實際上是一系列協(xié)議設(shè)計缺陷導(dǎo)致的認(rèn)證錯誤，最終導(dǎo)致對未配對的設(shè)備進(jìn)行連接(或者說偽造成已配對的設(shè)備)。
該漏洞主要是針對傳統(tǒng)藍(lán)牙(BR/EDR)的配對過程。前面已經(jīng)說過，在藍(lán)牙協(xié)議的發(fā)展中，安全配對主要分為三個階段，即Legacy Pairing、SSP和Secure Connection。配對的作用是讓從未見過的設(shè)備建立可信、安全的鏈路層鏈接，宏觀來看就是我們常見的輸入配對數(shù)字過程，微觀上是協(xié)商了一個雙方持有的長期秘鑰LTK(Long Term Key，或者說鏈接秘鑰LK(Link Key)，LTK用來生成后續(xù)安全鏈接的會話秘鑰(Session Key)。兩個設(shè)備只用配對一次，但可使用保存的LTK進(jìn)行多次安全連接。
在藍(lán)牙連接的過程中，數(shù)據(jù)是不經(jīng)過加密或者校驗的。連接建立的主要作用是讓兩個設(shè)備交換它們公開的capability信息、互相校驗對方的長期秘鑰并計算會話秘鑰。如果連接的設(shè)備支持Secure Connection，就使用安全連接方法建立鏈接，連接的過程使用AES-CCM經(jīng)過加密和完整性保護(hù)；否則，就使用Legacy Secure Connection(簡稱為LSC)，連接過程使用E0流加密方法進(jìn)行加密，并按照對應(yīng)的流程進(jìn)行連接。安全連接的建立同樣通過LMP協(xié)議進(jìn)行。
之所以介紹這些背景，是因為漏洞的成因與背景相關(guān)性較大，在上面的基礎(chǔ)上，BIAS漏洞可以描述為以下問題：
1.LSC過程中master發(fā)起連接請求，slave返回自己的LTK認(rèn)證響應(yīng)，但master可以不進(jìn)行校驗，也就是說在LSC中對LTK的校驗只是單向的，即master校驗slave的LTK即可。因此在LSC中攻擊者可以輕易偽造成master進(jìn)行連接。2.在LSC過程中，攻擊者若想偽造成slave，則可以在收到master的連接請求后發(fā)起Role Switch角色互換請求，將自己變成master，從而在1的基礎(chǔ)上偽造成Slave。3.在Secure Connection的情況下，攻擊者可以通過返回Secure Connection not Support來發(fā)起降級攻擊，從而使用LSC進(jìn)行后續(xù)連接，即回退到1/2的場景中進(jìn)行對端偽造。4.在Secure Connection的情況下，另一種攻擊方法是反射攻擊。即在收到Secure Connection的請求后發(fā)起Role Switch操作，并且偽造對端的認(rèn)證請求，由于兩端的LTK相同，因此對端可以返回合法的認(rèn)證響應(yīng)；之后再發(fā)起一次Role Switch，將合法的認(rèn)證響應(yīng)轉(zhuǎn)發(fā)給對端，從而完成安全鏈接。
BIAS漏洞產(chǎn)生的根源是藍(lán)牙協(xié)議中不嚴(yán)謹(jǐn)?shù)亩x，比如為了兼容性允許Secure Connection降級，并且Role Switch的設(shè)計完全沒有考慮安全性，對其發(fā)起的時機(jī)不加判斷導(dǎo)致被濫用。從漏洞危害來看，BIAS的直接影響是可以繞過了手動確認(rèn)的配對認(rèn)證與目標(biāo)設(shè)備進(jìn)行連接，一個典型的例子是可以偽造成目標(biāo)電腦或手機(jī)曾經(jīng)配對過的藍(lán)牙耳機(jī)設(shè)備，并靜默地與目標(biāo)進(jìn)行連接，從而實現(xiàn)間接控制揚(yáng)聲器和麥克風(fēng)的效果。
參考資料：
?https://francozappa.github.io/about-bias/?Bluetooth SIG Statement Regarding the Bluetooth Impersonation Attacks (BIAS) Security Vulnerability[3]
其他
上面介紹的只是兩個比較知名的協(xié)議漏洞，類似的協(xié)議設(shè)計問題還有很多，比如《Breaking Secure Pairing of Bluetooth Low Energy Using Downgrade Attacks[4]》中就介紹了一種針對SCO(Secure Connection Only)模式的降級攻擊。實際上藍(lán)牙核心協(xié)議的每次修訂，都或多或少對以前版本的疏漏進(jìn)行了修補(bǔ)。藍(lán)牙協(xié)議上出現(xiàn)的安全問題往往影響廣泛并且難以修復(fù)，因為SIG更新協(xié)議需要一定時間，從協(xié)議更新到各個廠商的實現(xiàn)和測試也曠日持久。通常這類問題出現(xiàn)后都是廠商自身根據(jù)自己的理解進(jìn)行緩解性修補(bǔ)，這也另一方面影響了漏洞修復(fù)的質(zhì)量。
實現(xiàn)安全
由于藍(lán)牙協(xié)議是如此復(fù)雜，而且協(xié)議本身還隨著時間的變遷而不斷更新進(jìn)化，這對于藍(lán)牙的實現(xiàn)造成了巨大挑戰(zhàn)。這要求藍(lán)牙固件的開發(fā)者一方面要深入理解藍(lán)牙協(xié)議的實現(xiàn)過程，另一方面也要對軟件安全開發(fā)本身有一定認(rèn)識。尤其是在Controller端，目前還沒有一個公開的藍(lán)牙參考實現(xiàn)，藍(lán)牙芯片的內(nèi)部代碼都是各個廠商珍藏的intellectual property。
藍(lán)牙的協(xié)議本身都復(fù)雜到經(jīng)常出現(xiàn)非預(yù)期的安全問題，那藍(lán)牙的實現(xiàn)就更不用說了。從諾基亞時代開始，就出現(xiàn)過許多代碼實現(xiàn)導(dǎo)致的藍(lán)牙軟件安全漏洞，比如BlueJack、BlueBugging、BlueBump、Bluesmack、SweynTooth、BlueBorne、BlueFrag等等，……下面挑選幾個比較著名的漏洞進(jìn)行分析。
BlueBorne
BlueBorne是2017年左右公開的一組藍(lán)牙漏洞，當(dāng)年影響了多個平臺和系統(tǒng)，甚至包括IoT設(shè)備如Amazon Echo和Google Home等。雖然時過境遷了，但也值得回顧一下。涉及到的漏洞如下：
?CVE-2017-0781/CVE-2017-0782：Android中l(wèi)2cap/bnep的內(nèi)存破壞，可導(dǎo)致RCE?CVE-2017-0785：Android中SDP協(xié)議continuation請求偏移校驗不當(dāng)導(dǎo)致的信息泄露?CVE-2017-0783：Android中PANU交互不當(dāng)導(dǎo)致的中間人攻擊?CVE-2017-8628：Windows中藍(lán)牙驅(qū)動實現(xiàn)不當(dāng)導(dǎo)致的中間人攻擊?CVE-2017-1000250：Linux BlueZ中SDP實現(xiàn)不當(dāng)導(dǎo)致的信息泄露，與前面Android中的SDP漏洞原理類似?CVE-2017-1000251：Linux BlueZ中處理L2CAP配置響應(yīng)不當(dāng)導(dǎo)致的棧溢出，可進(jìn)一步造成RCE?CVE-2017-14315：iOS中LEAP (Low Energy Audio Protocol)協(xié)議的堆溢出，可進(jìn)一步造成RCE
印象中這是首次在藍(lán)牙實現(xiàn)上批量公開的嚴(yán)重漏洞，在審計藍(lán)牙協(xié)議實現(xiàn)時可以發(fā)現(xiàn)一些常見的錯誤模式，比如用戶可控長度字段時導(dǎo)致的信息泄露和溢出，這些模式在不同平臺的實現(xiàn)中可能都有類似的紕漏，因此所產(chǎn)生的安全問題在不同平臺中的遷移性是比較高的。
參考資料：
?https://www.armis.com/blueborne/?https://info.armis.com/rs/645-PDC-047/images/BlueBorne%20Technical%20White%20Paper_20171130.pdf?https://source.android.com/security/bulletin/2017-09-01
SweynTooth
SweynTooth漏洞[5]也是一系列漏洞的集合，在2019年左右公開。雖然把它歸類到實現(xiàn)安全中，但其中大部分漏洞的本質(zhì)是各個廠商在實現(xiàn)藍(lán)牙核心協(xié)議未定義行為時引發(fā)的異常。低功耗藍(lán)牙BLE的消息交互流程如下圖所示：
messages
從這個圖中可以引申出許多有趣的問題，比如：”如果LL加密流程在配對的過程中發(fā)起會怎么樣？“……直覺來看有可能會造成全零LTK的安裝、秘鑰大小溢出、公鑰不合法等錯誤。但由于藍(lán)牙核心協(xié)議中對這種情況沒有明確說明，因此這類的錯誤處理就全由廠商安裝自己的理解去實現(xiàn)了。
一個藍(lán)牙產(chǎn)品在打上藍(lán)牙Logo之前需要經(jīng)過藍(lán)牙的認(rèn)證，進(jìn)行一系列基線兼容性檢查，但這個檢查也不是面面俱到的。因此，有的即便藍(lán)牙核心協(xié)議中有明確定義的行為，在實際測試中也會發(fā)現(xiàn)一些SoC廠商的實現(xiàn)不一致。比如，藍(lán)牙核心協(xié)議中定義peripheral在同一個central-peripheral連接中應(yīng)該只響應(yīng)一次version request請求，但實際上Telink的設(shè)備會響應(yīng)多次，這都是基線測試難以顧及到的地方。
作者也就是在測試這些Corner Case的情況下，發(fā)現(xiàn)了一系列Bug/漏洞，命名為SweynTooth，例如：
?CVE-2019-16336, CVE-2019-17519：鏈路層Length字段溢出，導(dǎo)致DoS和潛在的RCE?CVE-2019-17061, CVE-2019-17060：鏈路層的LLID處理不當(dāng)導(dǎo)致死鎖?CVE-2019-17517：處理L2CAP包時對長度字段的校驗錯誤導(dǎo)致內(nèi)存越界拷貝?....?CVE-2019-19194[6]：Telink SMP的Secure Connection實現(xiàn)在配對過程中發(fā)起LE加密流程時會導(dǎo)致全零LTK的安裝
加起來一共12個公開漏洞，不過利用場景都很有限，除了全零LTK漏洞外，大部分只能造成藍(lán)牙芯片的固件崩潰重新啟動或者死鎖。不過，從這組漏洞中我們也能看到藍(lán)牙固件的實現(xiàn)也是有不少問題的，藍(lán)牙芯片固件的代碼本身難以進(jìn)行熱更新，在一些特殊的HCI Event配合下，我們甚至可以從Controller中獲取Host的命令執(zhí)行權(quán)限。
BlueFrag
BlueFrag是2020年2月在Android安全通告中披露的一個嚴(yán)重漏洞，影響藍(lán)牙子系統(tǒng)可實現(xiàn)遠(yuǎn)程命令執(zhí)行。該漏洞主要是在Android中的L2CAP層實現(xiàn)上，是由于L2CAP的分片和重組包長度計算出錯導(dǎo)致的內(nèi)存破壞。
漏洞修復(fù)如下：
diff --git a/hci/src/packet_fragmenter.cc b/hci/src/packet_fragmenter.ccindex 5036ed5..143fc23 100644--- a/hci/src/packet_fragmenter.cc+++ b/hci/src/packet_fragmenter.cc@@ -221,7 +221,8 @@"%s got packet which would exceed expected length of %d. ""Truncating.",__func__, partial_packet->len);- packet->len = partial_packet->len - partial_packet->offset;+ packet->len =+ (partial_packet->len - partial_packet->offset) + packet->offset;projected_offset = partial_packet->len;}
值得一提的是，這個漏洞本身會導(dǎo)致memcpy拷貝負(fù)數(shù)長度，正常情況下會一直拷貝直至觸發(fā)非法內(nèi)存空間，但在Android的libc實現(xiàn)上memcpy優(yōu)化的實現(xiàn)會令拷貝前面的若干字節(jié)以及末尾的64字節(jié)退出，從而出現(xiàn)一個可控的內(nèi)存越界讀寫，在此基礎(chǔ)上可以進(jìn)一步實現(xiàn)控制流劫持導(dǎo)致遠(yuǎn)程命令執(zhí)行。Android中L2CAP的實現(xiàn)在用戶層中，稱為BlueDroid，用戶進(jìn)程為com.android.bluetooth，因此執(zhí)行命令后所獲得的權(quán)限也是bluetooth權(quán)限。
參考資料：
?https://insinuator.net/2020/04/cve-2020-0022-an-android-8-0-9-0-bluetooth-zero-click-rce-bluefrag/?https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf%5E%21/#F0[7]
應(yīng)用安全
前面介紹的都是比較底層的協(xié)議，而在一般安全論壇和關(guān)于藍(lán)牙安全的相關(guān)文章中介紹的通常更多是應(yīng)用相關(guān)的安全，比如藍(lán)牙智能門鎖的重放、越權(quán)等問題。這部分協(xié)議的交互主要在LTK協(xié)商之后，基于會話秘鑰加密的信道傳輸應(yīng)用層信息，當(dāng)然也可以是BLE中基于廣播的通信。
在上層的通信中，一個重要的概念就是Profile，表示設(shè)備所支持功能的一種垂直切分。其中既包括所有設(shè)備都通用的如Generic Access Profile(GAP)和Generic Attribute Profile(GATT)，也包括基于特定用途的Profile如Proximity Profile和Glucose Profile等。Profile本質(zhì)上定義了如何使用協(xié)議來實現(xiàn)某種通用或者特定的目的。
Profile的存在是藍(lán)牙協(xié)議與眾不同的一個地方，為什么會有這么多Profile，而不是像通用協(xié)議一樣，定義好協(xié)議結(jié)構(gòu)和字段，然后進(jìn)行通用拓展呢？在《計算機(jī)網(wǎng)絡(luò)》中有這么一段話:
真的有必要分清楚所有應(yīng)用的細(xì)節(jié)，并且為每一種應(yīng)用提供不同的協(xié)議棧嗎？也許沒有這個必要。但是，由于存在多個不同的工作組，他們分別負(fù)責(zé)設(shè)計標(biāo)準(zhǔn)的不同部分，因此，每個工作組都只關(guān)注特定的問題，從而形成了自己的Profile。你可以把這個看成是康威法則在起作用。或許藍(lán)牙標(biāo)準(zhǔn)根本不用25個協(xié)議棧，兩個就可以了，一個用于文件傳輸，另外一個用于流式實時通信。
可見SIG藍(lán)牙特別興趣小組各自為戰(zhàn)是藍(lán)牙Profile的形式發(fā)展至今的重要原因之一。
GATT定義了一個標(biāo)準(zhǔn)的數(shù)據(jù)模型與流程用以設(shè)備發(fā)現(xiàn)、讀寫和推送數(shù)據(jù)。一個GATT server中通常包含多個Service，而每個Service又可以包含多個Characteristic。每個Characteristic都有一個16位或者128位的UUID，并帶有可選的數(shù)據(jù)描述Descriptor。Characteristic是GATT通信中最小的數(shù)據(jù)單元，封裝了一個單一的數(shù)據(jù)點，其中可能包含一組相關(guān)的數(shù)據(jù)，比如加速傳感器x/y/z軸的坐標(biāo)數(shù)據(jù)。根據(jù)權(quán)限的不同，我們可以向Characteristic中讀寫數(shù)據(jù)。
舉個例子，對于心率計而言，可能有一個Heart Rate Service，其中包括兩個Characteristic，分別是HM(Heart Rate Measurement)和BSL(Body Sensor Location)，前者還包含一個Descriptor，CCCD(Client Characteristic Configuration Descriptor)，這是一個常見的descriptor，用來表示通知開關(guān)狀態(tài)。
其中大部分常用的屬性在藍(lán)牙SIG文檔中都定義了對應(yīng)的UUID，當(dāng)然也包括一部分Vendor Specific的UUID留給廠商自行去拓展和定義。
研究藍(lán)牙應(yīng)用安全的一個常用辦法是在收發(fā)數(shù)據(jù)時候進(jìn)行抓包，比如Android中支持在開發(fā)者模式中打開藍(lán)牙日志，iOS支持使用XCode的拓展工具PacketLogger進(jìn)行抓包。此外還可以通過對應(yīng)用進(jìn)行逆向或者動態(tài)追蹤的方式來觀察應(yīng)用層的交互數(shù)據(jù)，從而挖掘背后存在的安全漏洞。由于這類問題與具體的產(chǎn)品和應(yīng)用有關(guān)，這里就不舉例說明了，感興趣的朋友可以參考相關(guān)藍(lán)牙應(yīng)用設(shè)備的公開安全通告。
小結(jié)
從漏洞的影響面來看，協(xié)議類的藍(lán)牙漏洞通常影響廣泛且難以修復(fù)，因為需要修改協(xié)議并推進(jìn)各個藍(lán)牙廠商去進(jìn)行重新實現(xiàn)和更新；從危害性來看，協(xié)議類的漏洞往往影響的是藍(lán)牙信道的安全，在一般場景中危害相對有限；而實現(xiàn)類的漏洞通常導(dǎo)致內(nèi)存破壞，被攻擊者精心構(gòu)造利用則可以造成整個系統(tǒng)的淪陷，一旦被利用就很可能是個嚴(yán)重的 RCE；應(yīng)用類的漏洞通常是廠商的應(yīng)用開發(fā)者所造成的疏忽，在某些情況下可導(dǎo)致智能設(shè)備被劫持控制，雖然修復(fù)較為容易，但這類漏洞頻繁出現(xiàn)在不同的藍(lán)牙應(yīng)用中，因此其安全影響也是不可忽視的。
引用鏈接
[1] CVE-2019-9506: https://www.kb.cert.org/vuls/id/918987/[2] CVE-2020-10135: https://nvd.nist.gov/vuln/detail/CVE-2020-10135[3] Bluetooth SIG Statement Regarding the Bluetooth Impersonation Attacks (BIAS) Security Vulnerability: https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/bluetooth-security/bias-vulnerability/[4] Breaking Secure Pairing of Bluetooth Low Energy Using Downgrade Attacks: http://jin.ece.ufl.edu/papers/USENIX2020-BLE.PDF[5] SweynTooth漏洞: https://asset-group.github.io/disclosures/sweyntooth/[6] CVE-2019-19194: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19194[7] https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf%5E%21/#F0: https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf^!/#F0