欧美老熟,久久最新免费视频,曰本一级毛片

在Tesla Model S上實(shí)現(xiàn)Wi-Fi協(xié)議棧漏洞的利用

責(zé)編：gltian ｜2020-01-08 15:26:22

在過(guò)去的兩年里，騰訊科恩實(shí)驗(yàn)室對(duì)特斯拉汽車的安全性進(jìn)行了深入的研究并在Black Hat 2017與Black Hat 2018安全會(huì)議上兩次公開(kāi)分享了我們的研究成果。我們的研究成果覆蓋了車載系統(tǒng)的多個(gè)組件。我們展示了如何攻入到特斯拉汽車的CID、IC、網(wǎng)關(guān)以及自動(dòng)駕駛模塊。這一過(guò)程利用了內(nèi)核、瀏覽器、MCU固件、UDS協(xié)議及OTA更新過(guò)程中的多個(gè)漏洞。值得注意的是，最近我們?cè)谧詣?dòng)駕駛模塊上做了一些有趣的工作。我們分析了自動(dòng)雨刷和車道識(shí)別功能的具體實(shí)現(xiàn)細(xì)節(jié)并且在真實(shí)的世界中對(duì)其中的缺陷進(jìn)行了攻擊嘗試。為了更深入的了解特斯拉車載系統(tǒng)的安全性，我們研究了無(wú)線功能模塊（Model S上的Parrot模塊）并在其中找到了兩個(gè)漏洞。一個(gè)存在于無(wú)線芯片固件當(dāng)中，另一個(gè)存在于無(wú)線芯片驅(qū)動(dòng)當(dāng)中。通過(guò)組合這兩個(gè)漏洞，攻擊者可以在Parrot模塊的Linux系統(tǒng)當(dāng)中執(zhí)行任意命令。

介紹

本文會(huì)揭示這兩個(gè)漏洞的細(xì)節(jié)并介紹漏洞的利用過(guò)程來(lái)證明這兩個(gè)漏洞是可以被攻擊者用來(lái)通過(guò)無(wú)線協(xié)議遠(yuǎn)程攻入到特斯拉車載系統(tǒng)當(dāng)中的。

PARROT模塊

Tesla Model S上的Parrot模塊是一個(gè)第三方模塊，型號(hào)是FC6050W，它集成了無(wú)線及藍(lán)牙功能。Parrot通過(guò)USB協(xié)議與CID相連。Parrot運(yùn)行著Linux系統(tǒng)并使用了USB Ethernet gadget，因此Parrot與CID在USB協(xié)議基礎(chǔ)之上實(shí)現(xiàn)了以太網(wǎng)連接。當(dāng)Tesla Model S連接到無(wú)線網(wǎng)絡(luò)時(shí)，實(shí)際上Parrot模塊連接到該無(wú)線網(wǎng)絡(luò)中。這時(shí)，網(wǎng)絡(luò)流量被Parrot從CID路由到外部網(wǎng)絡(luò)。從一份公開(kāi)的資料[1]中，我們找到了Parrot模塊的硬件組成。

Parrot模塊的引腳定義也在這份datasheet中。Linux系統(tǒng)的shell可以通過(guò)Debug UART引腳得到。

其中的reset引腳連到到CID的GPIO上，因此CID有能力通過(guò)下列命令重置整個(gè)Parrot模塊

echo 1 > /sys/class/gpio/gpio171/value

sleep 1

echo 0 > ? /sys/class/gpio/gpio171/value

Marvell 無(wú)線芯片

Marvell 88W8688是一款低成本、低功耗、高度集成的支持IEEE802.11a/g/bMAC/基帶/射頻集無(wú)線和藍(lán)牙于一體的基帶/射頻系統(tǒng)級(jí)芯片[2]。Marvell官方網(wǎng)站[3]提供了一份該芯片的設(shè)計(jì)框圖。

Marvell 88W8688包含了一個(gè)嵌入式高性能Marvell Ferocean ARM9處理器。通過(guò)修改固件，我們獲得了Main ID寄存器中的數(shù)值0x11101556，據(jù)此推斷88W8688使用的處理器型號(hào)可能是Feroceon 88FR101 rev 1。在Parrot模塊上，Marvell 88w8688芯片通過(guò)SDIO接口與主機(jī)系統(tǒng)相連。

Marvell 88W8688的內(nèi)存區(qū)域如下：

芯片固件

固件的下載過(guò)程包含兩個(gè)階段。首先是輔助固件“sd8688_helper.bin”的下載，然后是主固件“sd8688.bin”的下載。輔助固件負(fù)責(zé)下載主固件及驗(yàn)證主固件中每個(gè)數(shù)據(jù)塊是否正確。主固件中包含了很多的數(shù)據(jù)塊，每個(gè)塊的結(jié)構(gòu)定義如下。

struct fw_chunk {

int chunk_type;

int addr;

unsigned int length;

unsigned int crc32;

unsigned char [1];

} __packed;

88w8688固件的運(yùn)行基于ThreadX實(shí)時(shí)操作系統(tǒng)，該實(shí)時(shí)操作系統(tǒng)多用于嵌入式設(shè)備。ThreadX的代碼存在于ROM內(nèi)存區(qū)域，因此固件“sd8688.bin”實(shí)際上作為ThreadX的應(yīng)用運(yùn)行。在特斯拉上，固件“sd8688.bin”的版本ID是“sd8688-B1, RF868X, FP44, 13.44.1.p49”,本文的所有研究均基于此版本。在逆向識(shí)別出所有的ThreadX API之后，各個(gè)任務(wù)的信息便可以得到。

同時(shí)，內(nèi)存池的相關(guān)信息也可以得到。

日志及調(diào)試

芯片固件沒(méi)有實(shí)現(xiàn)Data Abort、Prefetch Abort、Undefine和SWI等CPU異常向量的處理過(guò)程。這意味著，固件崩潰后處理器會(huì)停止工作。我們不知道固件在哪里因何崩潰。所以我們修改了固件，并自己實(shí)現(xiàn)了這些異常處理過(guò)程。這些處理過(guò)程會(huì)記錄固件崩潰時(shí)的一些寄存器信息，包括通用寄存器，系統(tǒng)模式及中斷模式下的狀態(tài)寄存器和鏈接寄存器。通過(guò)這種方式，我們可以知道崩潰時(shí)系統(tǒng)模式或中斷模式下的一些寄存器信息。

我們將這些寄存器信息寫到末使用的內(nèi)存區(qū)域，例如0x52100~0x5FFFF。這樣，這些信息在芯片重置后仍然可以被讀取。

在實(shí)現(xiàn)了undefine異常處理過(guò)程及修改一些指令為undefine指令后，我們可以在固件運(yùn)行時(shí)獲取或設(shè)置寄存器的內(nèi)容。用這種方式，我們可以調(diào)試固件。

將新的固件下載到芯片中運(yùn)行，可在內(nèi)核驅(qū)動(dòng)中發(fā)送命令HostCmd_CMD_SOFT_RESET到芯片。隨后芯片會(huì)重置，新的固件會(huì)下載。

固件中的漏洞

88w8688芯片支持802.11e WMM (Wi-Fi Multimedia)協(xié)議。在這個(gè)協(xié)議中，STA會(huì)通過(guò)Action幀來(lái)發(fā)送ADDTS request給其他設(shè)備。請(qǐng)求中包含有TSPEC信息。然后其他設(shè)備同樣通過(guò)Action幀返回ADDTS response。下面是該Action幀的具體格式。ADDTS的整個(gè)過(guò)程如下：當(dāng)系統(tǒng)想要發(fā)送ADDTS請(qǐng)求時(shí)，內(nèi)核驅(qū)動(dòng)會(huì)發(fā)送HostCmd_CMD_WMM_ADDTS_REQ命令給芯片，然后芯片將ADDTS請(qǐng)求通過(guò)無(wú)線協(xié)議發(fā)送出去。當(dāng)芯片收到ADDTS response后，將該回復(fù)信息去掉Action幀頭部復(fù)制到HostCmd_CMD_WMM_ADDTS_REQ結(jié)構(gòu)體，作為ADDTS_REQ命令的結(jié)果在HostCmd_DS_COMMAND結(jié)構(gòu)體中返回給內(nèi)核驅(qū)動(dòng)。內(nèi)核驅(qū)動(dòng)來(lái)實(shí)際處理ADDTS response。

struct _HostCmd_DS_COMMAND

{

??? u16 Command;

??? u16 Size;

??? u16 SeqNum;

??? u16 Result;

??? union

??? {

??????? HostCmd_DS_GET_HW_SPEC hwspec;

??????? HostCmd_CMD_WMM_ADDTS_REQ;

??????? …….

???? }

}

漏洞存在于將ADDTS response復(fù)制到HostCmd_CMD_WMM_ADDTS_REQ結(jié)構(gòu)體的過(guò)程中。函數(shù)wlan_handle_WMM_ADDTS_response在復(fù)制時(shí)，需要復(fù)制的長(zhǎng)度為Action幀的長(zhǎng)度減去4字節(jié)Action幀頭部。如果Action幀只有頭部且長(zhǎng)度為3。那么復(fù)制時(shí)的長(zhǎng)度會(huì)變?yōu)?xffffffff。這樣，內(nèi)存將會(huì)被完全破壞，導(dǎo)致穩(wěn)定的崩潰。?

驅(qū)動(dòng)中的漏洞

在芯片與驅(qū)動(dòng)之間，有三種數(shù)據(jù)包類型通過(guò)SDIO接口傳遞，MV_TYPE_DATA、 MV_TYPE_CMD和 MV_TYPE_EVENT。其定義可在源碼中找到。命令處理的過(guò)程大致如下。驅(qū)動(dòng)接收到用戶態(tài)程序如ck5050、wpa_supplicant發(fā)來(lái)的指令，在函數(shù)wlan_prepare_cmd()中初始化HostCmd_DS_COMMAND結(jié)構(gòu)體，該函數(shù)的最后一個(gè)參數(shù)pdata_buf指向與命令有關(guān)的結(jié)構(gòu)，函數(shù)wlan_process_cmdresp()負(fù)責(zé)處理芯片返回的結(jié)果并將相關(guān)信息復(fù)制到pdata_buf指向的結(jié)構(gòu)中。

int

wlan_prepare_cmd(wlan_private * priv,

u16 cmd_no,
u16 cmd_action,
u16 wait_option, WLAN_OID cmd_oid, void *pdata_buf);

漏洞存在于函數(shù)wlan_process_cmdresp()處理HostCmd_CMD_GET_MEM的過(guò)程中。函數(shù)wlan_process_cmdresp()沒(méi)有檢查HostCmd_DS_COMMAND結(jié)構(gòu)體中的成員size的大小是否合法。因此在把HostCmd_DS_COMMAND結(jié)構(gòu)中的數(shù)據(jù)復(fù)制到其他位置時(shí)發(fā)生了內(nèi)存溢出。

芯片內(nèi)代碼執(zhí)行

很顯然，固件中的漏洞是一個(gè)堆溢出。為了利用這個(gè)漏洞實(shí)現(xiàn)芯片內(nèi)代碼執(zhí)行，我們需要知道m(xù)emcpy()函數(shù)是怎樣破壞內(nèi)存的，以及芯片是怎樣崩潰的，在哪里崩潰的。為了觸發(fā)這個(gè)漏洞，action幀頭部的長(zhǎng)度應(yīng)該小于4。同時(shí)我們需要在Action幀中提供正確的dialog token，這意味著memcpy()接收的長(zhǎng)度只能是0xffffffff。源地址是固定的，因?yàn)樵搩?nèi)存塊是從內(nèi)存池pool_start_id_rmlmebuf分配的，并且這個(gè)內(nèi)存池只有一個(gè)內(nèi)存塊。目的地址是從內(nèi)存池pool_start_id_tx分配的，所以目的地址可能是四個(gè)地址中的某一個(gè)。

源地址及目的地址均位于RAM內(nèi)存區(qū)域0xC0000000~0xC003FFFF，但是內(nèi)存地址0xC0000000到0xCFFFFFFF都是合法的。結(jié)果就是，讀或?qū)懴旅孢@些內(nèi)存區(qū)域會(huì)得到完全一樣的效果。

因?yàn)閮?nèi)存區(qū)域0xC0000000到0xCFFFFFFF都是可讀可寫的，所以復(fù)制過(guò)程幾乎不會(huì)碰到內(nèi)存的邊界。在復(fù)制了0x40000個(gè)字節(jié)后，整個(gè)內(nèi)存可被看作是整體移位了，其中有些數(shù)據(jù)被覆蓋并且丟失了。

88w8688中的CPU是單核的，所以復(fù)制過(guò)程中芯片不會(huì)崩潰直到有中斷產(chǎn)生。因?yàn)檫@時(shí)內(nèi)存已被破壞，在大多數(shù)情況下，芯片崩潰在中斷過(guò)程中。

中斷控制器給中斷系統(tǒng)提供了一個(gè)接口。當(dāng)一個(gè)中斷產(chǎn)生時(shí)，固件可從寄存器中獲取中斷事件類型并調(diào)用相應(yīng)的中斷處理過(guò)程。

中斷源有很多，所以漏洞觸發(fā)后，芯片可能崩潰在多個(gè)位置。

一個(gè)可能性是中斷0x15的處理過(guò)程中，函數(shù)0x26580被調(diào)用。0xC000CC08是一個(gè)鏈表指針，這個(gè)指針在漏洞觸發(fā)后可能會(huì)被篡改。然而，對(duì)這個(gè)鏈表的操作很難給出獲得代碼執(zhí)行的機(jī)會(huì)。

另一個(gè)崩潰位置在時(shí)鐘中斷的處理過(guò)程中。處理過(guò)程有時(shí)會(huì)進(jìn)行線程的切換，這時(shí)其他任務(wù)會(huì)被喚醒，那么復(fù)制過(guò)程就會(huì)被暫停。然后芯片可能崩潰在其他任務(wù)恢復(fù)運(yùn)行之后。在這種情況下，固件通常崩潰在函數(shù)0x4D75C中。

這個(gè)函數(shù)會(huì)讀取一個(gè)指針0xC000D7DC，它指向結(jié)構(gòu)TX_SEMAPHORE。觸發(fā)漏洞后，我們可以覆蓋這個(gè)指針，使其指向一個(gè)偽造的TX_SEMAPHORE結(jié)構(gòu)。

typedef struct TX_SEMAPHORE_STRUCT

{

ULONG?????? tx_semaphore_id;
CHAR_PTR??? tx_semaphore_name;
ULONG???????tx_semaphore_count;
struct TX_THREAD_STRUCT? *tx_semaphore_suspension_list;
ULONG???????tx_semaphore_suspended_count;
struct???????TX_SEMAPHORE_STRUCT *tx_semaphore_created_next;?
struct???????TX_SEMAPHORE_STRUCT *tx_semaphore_created_previous;
} TX_SEMAPHORE;

如果偽造的TX_SEMAPHORE結(jié)構(gòu)中的tx_semaphore_suspension_lis指針剛好指向偽造的TX_THREAD_STRUCT結(jié)構(gòu)。那么當(dāng)函數(shù)_tx_semaphore_put()更新TX_THREAD_STRUCT結(jié)構(gòu)中的鏈表的時(shí)候，我們可以得到一次任意地址寫的機(jī)會(huì)。我們可以直接將“BL os_semaphore_put”指令的下一條指令改成跳轉(zhuǎn)指令來(lái)實(shí)現(xiàn)任意代碼執(zhí)行，因?yàn)镮TCM內(nèi)存區(qū)域是RWX的。困難在于我們需要同時(shí)在內(nèi)存中堆噴兩種結(jié)構(gòu)TX_SEMAPHORE和TX_THREAD_STRUCT，并且還要確保指針 tx_semaphore_suspension_list 指向TX_THREAD_STRUCT結(jié)構(gòu)。這些條件可以被滿足，但是利用成功率會(huì)非常低。

我們主要關(guān)注第三個(gè)崩潰位置，在MCU中斷的處理過(guò)程中。指向struct_interface 結(jié)構(gòu)的指針g_interface_sdio會(huì)被覆蓋。

struct struct_interface

{

? int field_0;

? struct struct_interface *next;

? char *name_ptr;

? int sdio_idx;

? int fun_enable;

? int funE;

? int funF;

? int funD;

? int funA;

? int funB; // 0x24

? int funG;

? int field_2C;

};

結(jié)構(gòu)中函數(shù)指針funB會(huì)被使用。如果g_interface_sdio被篡改，那么就會(huì)直接實(shí)現(xiàn)代碼執(zhí)行。這是當(dāng)函數(shù)interface_call_funB()中的指令“BX R3” 在地址0x3CD4E執(zhí)行時(shí)的一份寄存器日志信息。此時(shí)，g_interface_sdio被覆蓋成了0xabcd1211。

函數(shù)interface_call_funB()在地址0x4E3D0處被MCU中斷的處理過(guò)程使用。

當(dāng)復(fù)制的源地址到達(dá)0xC0040000時(shí)，整個(gè)內(nèi)存可被看作是做了一次偏移。當(dāng)復(fù)制的源地址到達(dá)0xC0080000時(shí)，整個(gè)內(nèi)存偏移了兩次。每次偏移的距離如下。

0xC0016478-0xC000DC9B=0x87DD

0xC0016478-0xC000E49B=0x7FDD

0xC0016478-0xC000EC9B=0x77DD

0xC0016478-0xC000F49B=0x6FDD

在多數(shù)情況下，漏洞觸發(fā)后再產(chǎn)生中斷時(shí)，這樣的內(nèi)存偏移會(huì)發(fā)生3至5次。所以指針g_interface_sdio會(huì)被來(lái)自下列地址的數(shù)據(jù)所覆蓋。

0xC000B818+0x87DD*1=0xC0013FF5

0xC000B818+0x87DD*2=0xC001C7D2

0xC000B818+0x87DD*3=0xC0024FAF

0xC000B818+0x87DD*4=0xC002D78C

…

0xC000B818+0x7FDD*1=0xC00137F5

0xC000B818+0x7FDD*2=0xC001B7D2

0xC000B818+0x7FDD*3=0xC00237AF

0xC000B818+0x7FDD*4=0xC004B700

…

0xC000B818+0x77DD*1=0xC0012FF5

0xC000B818+0x77DD*2=0xC001A7D2

0xC000B818+0x77DD*3=0xC0021FAF

0xC000B818+0x77DD*4=0xC002978C

…

0xC000B818+0x6FDD*1=0xC00127F5

0xC000B818+0x6FDD*2=0xC00197D2

0xC000B818+0x6FDD*3=0xC00207AF

0xC000B818+0x6FDD*4=0xC002778C

…

地址0xC0024FAF、 0xC00237AF和0xC0021FAF剛好位于一個(gè)巨大的DMA buffer 0xC0021F90~0xC0025790之中。這個(gè)DMA buffer用于存儲(chǔ)無(wú)線芯片接收到的802.11數(shù)據(jù)幀。所以這個(gè)DMA buffer可以用來(lái)堆噴偽造的指針。為了堆噴偽造的指針，我們可以發(fā)送許多正常的802.11數(shù)據(jù)幀給芯片，其中填滿了偽造的指針。DMA buffer非常大，因此shellcode也可以直接放在數(shù)據(jù)幀中。為了提高利用的成功率，我們用了Egg Hunter在內(nèi)存中查找真正的shellcode。

如果g_interface_sdio被成功的覆蓋。Shellcode或egg hunter會(huì)非常的接近0xC000B818。我們所使用的偽造指針是0x41954，因?yàn)樵诘刂?x41954+0x24處有一個(gè)指針0xC000B991。這樣，我們可以劫持$PC到0xC000B991。同時(shí)，指針0x41954可被作為正常的指令執(zhí)行。

54 19 ADDS??????????? R4, R2, R5

04 00 MOVS??????????? R4, R0

用這種方法有25%的成功率獲得代碼執(zhí)行。?

攻擊主機(jī)系統(tǒng)

內(nèi)核驅(qū)動(dòng)中的漏洞可通過(guò)由芯片發(fā)送命令數(shù)據(jù)包給主機(jī)系統(tǒng)來(lái)觸發(fā)。命令HostCmd_CMD_GET_MEM通常由函數(shù)wlan_get_firmware_mem()發(fā)起。這種情況下，pdata_buf指向的buffer由kmalloc()分配，所以這是一個(gè)內(nèi)核堆溢出。在真實(shí)環(huán)境中函數(shù)wlan_get_firmware_mem()不會(huì)被用到，并且堆溢出的利用較復(fù)雜。

然而，一個(gè)被攻陷的芯片在返回某個(gè)命令的結(jié)果時(shí)可以更改命令I(lǐng)D。因此漏洞可以在許多命令的處理過(guò)程中被觸發(fā)。這時(shí)，根據(jù)pdata_buf指向的位置，漏洞即可以是堆溢出也可以是棧溢出。我們找到了函數(shù)wlan_enable_11d()，它把局部變量enable的地址作為pdata_buf。因此我們可以觸發(fā)一個(gè)棧溢出。

函數(shù)wlan_enable_11d()被wlan_11h_process_join()調(diào)用。顯然HostCmd_CMD_802_11_SNMP_MIB會(huì)在與AP的連接過(guò)程中被使用。固件中的漏洞只能在Parrot已經(jīng)加入AP后使用。為了觸發(fā)wlan_enable_11d()中的棧溢出，芯片需要欺騙內(nèi)核驅(qū)動(dòng)芯片已經(jīng)斷開(kāi)與AP的連接。接著，驅(qū)動(dòng)會(huì)發(fā)起重連，在這個(gè)過(guò)程中HostCmd_CMD_802_11_SNMP_MIB會(huì)發(fā)送給芯片。于是，為了觸發(fā)重連過(guò)程，芯片需要發(fā)送EVENT_DISASSOCIATED事件給驅(qū)動(dòng)。

當(dāng)在芯片中觸發(fā)漏洞并獲得代碼執(zhí)行之后芯片不能再正常工作。所以我們的shellcode需要自己處理重連過(guò)程中的一系列命令并返回相應(yīng)的結(jié)果。在命令HostCmd_CMD_802_11_SNMP_MIB來(lái)到之前，唯一一個(gè)我們要構(gòu)造返回結(jié)果的命令是HostCmd_CMD_802_11_SCAN。下面是斷開(kāi)連接到觸發(fā)內(nèi)核漏洞的整個(gè)過(guò)程。

SDIO接口上事件和命令數(shù)據(jù)包的發(fā)送可直接通過(guò)操作寄存器SDIO_CardStatus和SDIO_SQReadBaseAddress0來(lái)完成。SDIO接口上獲得內(nèi)核發(fā)來(lái)的數(shù)據(jù)可借助SDIO_SQWriteBaseAddress0寄存器。

Linux系統(tǒng)中命令執(zhí)行

Parrot的Linux內(nèi)核2.6.36不支持NX，所以可以直接在棧上執(zhí)行shellcode。同時(shí)結(jié)構(gòu)HostCmd_DS_COMMAND中的size是u16類型，所以shellcode可以足夠大來(lái)做許多事情。在觸發(fā)棧溢出并控制$PC之后，$R7剛好指向內(nèi)核棧，所以可以很方便的執(zhí)行shellcode。在shellcode中的函數(shù)run_linux_cmd調(diào)用了Usermode Helper API來(lái)執(zhí)行Linux命令。

遠(yuǎn)程獲取shell

在漏洞觸發(fā)后，芯片中的內(nèi)存被完全破壞無(wú)法繼續(xù)正常工作。同時(shí)內(nèi)核棧已損壞，無(wú)法正常工作。為了讓Parrot的無(wú)線功能可以重新正常工作，我們做了如下事情：

1	在向內(nèi)核發(fā)送完payload之后，我們通過(guò)如下命令重置了芯片。在這之后，內(nèi)核驅(qū)動(dòng)會(huì)重新發(fā)現(xiàn)芯片然后重新下載固件。 `(unsigned int )0x8000201c\|=2; (unsigned int )0x8000a514=0; (unsigned int )0x80003034=1;`
2	在shellcode的函數(shù)fun_ret()中調(diào)用內(nèi)核函數(shù)rtnl_unlock()來(lái)解開(kāi)rtnl_mutex鎖。否則Linux的無(wú)線功能會(huì)無(wú)法正常功能，導(dǎo)致Parrot被CID重啟。
3	在shellcode的函數(shù)fun_ret()中調(diào)用do_exit()來(lái)終止用戶態(tài)進(jìn)程wpa_supplicant并重新運(yùn)行，這樣就不需要修復(fù)內(nèi)核棧。
4	殺掉進(jìn)程ck5050并重新運(yùn)行，否則稍后ck5050會(huì)因芯片重置而崩潰，導(dǎo)致Parrot被CID重啟。

為了遠(yuǎn)程獲取shell，我們強(qiáng)制讓Parrot連入我們自己的AP并修改iptables規(guī)則。之后，便可通過(guò)23端口訪問(wèn)到Parrot的shell。

最終拿到shell的成功率在10%左右。

完整的利用過(guò)程

01.攻擊者發(fā)送DEAUTH幀給附近的所有AP。

02.當(dāng)Tesla重連至AP時(shí)，攻擊者可以嗅探到特斯拉的MAC地址。

03.堆噴偽造的指針，然后發(fā)送Action幀來(lái)觸發(fā)固件中的漏洞。

04.函數(shù)memcpy()會(huì)一直工作直到有中斷產(chǎn)生。

05.在芯片內(nèi)成功執(zhí)行任意代碼。

06.第一階段shellcode發(fā)送EVENT_DISASSOCIATED事件給驅(qū)動(dòng)。

07.第一階段shellcode處理一系列命令并等待命令HostCmd_CMD_802_11_SNMP_MIB。

08.第一階段shellcode通過(guò)SDIO接口發(fā)送payload來(lái)觸發(fā)內(nèi)核棧溢出。

09.第二階段shellcode執(zhí)行并調(diào)用call_usermodehelper()函數(shù)。

10.成功執(zhí)行Linux系統(tǒng)命令并嘗試修復(fù)Parrot的無(wú)線功能。

11.攻擊者搭建自己的AP熱點(diǎn)及DHCP服務(wù)器。

12.通過(guò)Linux命令強(qiáng)制Parrot加入攻擊者建立的AP熱點(diǎn)并修改iptables規(guī)則。

13.攻擊者可通過(guò)Parrot的23端口獲得Parrot的shell。

總結(jié)

在這篇文章中，我們展示了Marvell無(wú)線芯片固件及驅(qū)動(dòng)中漏洞的具體細(xì)節(jié)，并演示了如何利用這兩個(gè)漏洞僅通過(guò)發(fā)送無(wú)線數(shù)據(jù)包的形式遠(yuǎn)程在Parrot系統(tǒng)內(nèi)部實(shí)現(xiàn)命令執(zhí)行。

負(fù)責(zé)任的漏洞披露

本文所提到的兩個(gè)漏洞已于2019年3月報(bào)告給Tesla，Tesla已經(jīng)在2019.36.2版本中對(duì)該漏洞進(jìn)行了修復(fù)。同時(shí)，Marvell也修復(fù)了該漏洞并針對(duì)該漏洞發(fā)布了安全公告[4]。漏洞研究報(bào)告的披露已事先與特斯拉溝通過(guò)，特斯拉對(duì)我們的發(fā)布知情。你可以通過(guò)下列鏈接來(lái)跟蹤本文提到的漏洞。

https://www.cnvd.org.cn/flaw/show/CNVD-2019-44105
http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201911-1040
http://www.cnnvd.org.cn/web/xxk/ldxqById.tag?CNNVD=CNNVD-201911-1038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13581
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13582

參考文獻(xiàn)

[1]https://fccid.io/RKXFC6050W/Users-Manual/user-manual-1707044[2]https://www.marvell.com/wireless/88w8688/[3]https://www.marvell.com/wireless/assets/Marvell-88W8688-SoC.pdf

[4]https://www.marvell.com/documents/ioaj5dntk2ubykssa78s/

轉(zhuǎn)載自安全加：https://mp.weixin.qq.com/s/rULdN3wVKyR3GlGBhunpoQ

上一篇：高效漏洞管理的七項(xiàng)基本原則

下一篇：威脅情報(bào)：網(wǎng)絡(luò)安全的下一個(gè)引爆點(diǎn)

压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

在Tesla Model S上實(shí)現(xiàn)Wi-Fi協(xié)議棧漏洞的利用

轉(zhuǎn)載自安全加：https://mp.weixin.qq.com/s/rULdN3wVKyR3GlGBhunpoQ

压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘免费看|www.tcsft.com