# BlueSmack Attack
###### tags: `Bluetooth Security`
## BlueSmack理論
#### 1. 這是什麼樣的attack?
* BlueSmack類似DOS攻擊，攻擊方在短時間內發送大量藍芽相關封包給受害方來影響其運作。
#### 2. 會在什麼情形發生此攻擊
* 當攻擊方與受害方建立連結後，攻擊方若惡意使用自動化程式發送大量的echo request時，受害方則會對於每個echo request進行發送echo response來回應，受害方由於要回應request過多則導致效能下降甚至是無法運作。
#### 3. 做了什麼實驗
* 攻擊實驗：一台電腦作為攻擊方，手機作為受害方，在藍芽體溫計傳遞體溫資料給手機時，電腦對手機進行BlueSmack
* 防禦實驗：兩台電腦一邊作為攻擊方另一邊作為受害方，受害方使用套件指令將攻擊方block住，使攻擊方無法攻擊。
#### 4. 實驗目前成果
* 攻擊實驗：當攻擊方對手機進行攻擊時，手機則無法接收體溫計資料。
* 攻擊前正常情況
* 攻擊時則會一直處於處理中...
* 結束攻擊則恢復正常情況
* 防禦實驗：當受害方block住攻擊方時，會使得攻擊方因為無法建立連線，而無法進一步進行攻擊。
* 參考下面BlueSmack實作觀察
* 攻擊方 (A)
1. Scan出B的MAC位置
2. DDOS B ([BlueSmack Github](https://github.com/guava0603/blue-smack-attack?fbclid=IwAR0LyauRVJ4Rrnb_6UYf-4-DDfmyy9kB2gbV5yGo7yqmvabyE9nWcWvc0Q8))
* 被攻擊方 (B)
1. 先將安全裝置與B成功pair與connect
2. 將安全裝置放入resolving list與white list中
* 大致流程
1. 首先B先進行初始化，將受信任裝置都放入到resolving list與white list內
2. 完成後，將address resolution enable打開，使得未來要與B溝通的設備都需要用Resolvable Private Address進行溝通
3. 最後，A對B進行DDOS攻擊，理論上會無法成功因為: (1)A並不在white list內，所以無法進行DDOS (2)若A要偽裝成受信任裝置對B進行DDOS，則會因為A的IRK與受信任裝置的位置經過hash運算後與B內的resolving list不相同，而導致A無法成功偽裝成信任裝置，更無法進行DDOS
* 問題
* 在hcitool只能將受信任裝置放入至resolving list與white list，但目前測試並沒有效果，例如：A即使不在white list內，也可以進行攻擊（或許可能需要有裝置先被新增至white list才開啟阻擋功能）
* 若需要解決攻擊者偽裝成受信任裝置，需要先完成偽裝部分（目前還沒實作完成）
* 如何得知BT_ADDR為random或public（gatttool貌似有類似設置指令）

## Bluesmack測試
:::info
* Attacker (外接dongle)
* 實作在VMware workstation
* 5.15.0-41-generic 20.04.1-Ubuntu
* Bluetooth 4.2
* Bluez 5.53
* 支援BLE scan
* Victim (intel NUC desktop)
* 原生Ubuntu
* 5.4.0-124-generic 18.04.1-Ubuntu
* Bluetooth 5.0
* Bluez 5.48
* CPU i7-1165G7 2.80Gz
* 不支援BLE scan，但可執行BLE相關功能
:::
:::warning
packet為600bytes，使用50個threads
throughput limit大概在660bytes，不然會出現`Message too long`
:::
* 測試一：一直跑bluesmack
* 最後Attacker output會出現：`Recv failed: connection reset by peer`
* 透過Wireshark觀察，從攻擊開始到被迫停止花了約120秒
* Attacker最後收到的Disconnect Complete封包如下，出現`Remote User Terminated Connection (0x13)`
* 透過Wireshark觀察，最後victim的host對victim的controller下了`Sent Disconnect`，使得Attacker失效
* **<font color='red'>(?)為何Victim會中斷連線</font>**
* 可能是遇到timeout [[ref]](https://marc.info/?l=linux-bluetooth&m=134437356211023&w=2)
* 測試二：Victim用block指令將attacker的封包擋掉
* Attacker output出現：`Can't connect: connection refused`
* Attacker透過Wireshark觀察，因連線無法建立(見下面Victim的資訊)，所以`Rcvd Connect Complete`回傳`Connection Rejected due to Unacceptable BD_ADDR (0x0f)`
* Victim透過btmon觀察如下，出現`Connection Rejected due to Unacceptable BD_ADDR (0x0f)`
* Victim透過Wireshark觀察，可以看到controller跟host說接收到Connect Request後，host回傳給controller `Sent Reject Connection Request`，使得Attacker無法連接Victim
* 結論：
* 沒block前，攻擊是否有成功？**可能有**，使用Wireshark觀察後，Attacker在攻擊當下是有對Victim傳送大量封包，且Victim在被攻擊當下也有接收到大量封包（可能由於Victim CPU太好，因此還能消化大量封包）
* block後，攻擊是否有成功？**沒有**，因在傳送封包前須建立connection，而connection沒建立成功，Attacker也不能夠傳送封包，由Wireshark觀察，Attacker連線遭拒後並無傳送任何封包，所以Victim也沒有接收任何封包