建站
咨詢
售后
建站咨詢
新聞中心
在上周的CanSecWest安全會議上我論述了一種對Android4.3及其以上版本適用的藍牙協(xié)議棧(Bluedroid)的遠程攻擊。這篇文章簡單的描述了這個bug。
創(chuàng)新互聯(lián)建站是一家專注于網(wǎng)站制作、成都網(wǎng)站制作與策劃設計,梁河網(wǎng)站建設哪家好?創(chuàng)新互聯(lián)建站做網(wǎng)站,專注于網(wǎng)站建設十余年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:梁河等地區(qū)。梁河做網(wǎng)站價格咨詢:18980820575
如果讀者沒有耐心的話，可以點這里直接觀看攻擊視頻。
這個漏洞存在于Bluedroid的BLE數(shù)據(jù)包解析代碼中。要測試這個漏洞，攻擊者需要強制一名用戶連接到惡意的BLE(藍牙智能)設備上。連接時，該惡意設備會發(fā)布一個格式錯誤的GATT通知數(shù)據(jù)包，從而造成協(xié)議棧的崩潰。
這聽上去好像有點牽強——攻擊者能強制一名用戶連接到設備上。但考慮到這樣一個事實：很多Android的BLE應用會適時連接到任何廣告設備上來確定其是否是與該應用程序相關聯(lián)的設備。只要有應用是出于攻擊的目的連接就可以成功。
但這個漏洞沒有可利用性：崩潰是由一個FORTIFY_SOUCE檢測錯誤所造成的。此外，該漏洞已在Android4.4以上的版本中被修復。
問題代碼
問題代碼可以在stack/gatt/gatt_cl.c中的gett_process_notification(614行)處被找到。這段代碼用于解析通知包(BLE設備周期性的發(fā)送給BLE機主的消息)。在626行可以看到如下代碼：
- STREAM_TO_UINT16 (value.handle, p);
- value.len = len - 2;
- memcpy (value.value, p, value.len);
value.len是unit16_t。p和len都可由攻擊者控制，但我們只對len感興趣。p表示攻擊者發(fā)送的數(shù)據(jù)包內(nèi)容，len則是該數(shù)據(jù)包的大小。
這段代碼輸出一個至少2字節(jié)大小的數(shù)據(jù)包。如果攻擊者發(fā)送了只有一個字節(jié)的格式錯誤的數(shù)據(jù)包，那么value.len=len-2的計算結果將會下溢到65534。那么memcpy將會試圖從p中拷貝將近64000字節(jié)的數(shù)據(jù)。
演示
我為此做了一個演示視頻。
我用經(jīng)修改過的BlueZ(linux 藍牙協(xié)議棧)的版本搭建了一個攻擊平臺，BlueZ在這里作為一個運行GATT服務的BLE設備。當一個BLE機主連接時，它會自動發(fā)送一個只有單字節(jié)大小的通知數(shù)據(jù)包。
在視頻中，我使用一個BLE心跳監(jiān)控應用演示了這個漏洞。出于演示的目的，我手動連接該應用至惡意的BlueZ設備。當音樂結束時協(xié)議崩潰了。
adb logcat的輸出類似于如下顯示：
- F/libc (19174): FORTIFY_SOURCE: memcpy buffer overflow. Calling abort().
- F/libc (19174): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 19956 (BTU)
我再次注意到該攻擊是不可利用的——原因是FORTIFY_SOURCE的運行檢測機制。該代碼在編譯時已知目標緩沖區(qū)的長度。在運行時，該代碼會檢查memcpy的長度是否大于目標緩沖區(qū)，如果是則會調(diào)用abort()。
時間表
以下是bug追蹤時間表：
2013-09-30:向google披露該漏洞
2013-10-07:承諾解決
2013-10-30:Android 4.4 r0.9 標記該漏洞
2013-10-31:Android 4.4發(fā)布版修復
google并沒有在Android 4.3上發(fā)布修復版，原因是他們希望所有用戶都升級到4.4。
更多信息
如果你想要學習更多關于BLE主動攻擊和模糊化處理技術，可以觀看我的CanSecWest演講視頻。Outsmarting Bluetooth Smart.
分享題目：如何實現(xiàn)遠程攻擊 Android 藍牙
網(wǎng)址分享：http://www.fisionsoft.com.cn/article/coespoj.html
