序言

近期，在一項(xiàng)測(cè)試任務(wù)中遇到了一個(gè)控車app，想著能不能逆向一波實(shí)現(xiàn)遠(yuǎn)程控車的效果。由于涉及客戶的保密信息，相關(guān)內(nèi)容已打碼。

測(cè)試過程

初探

首先，使用客戶提供的賬號(hào)密碼登錄app，查看app具體功能，抓取正常數(shù)據(jù)包簡單進(jìn)行數(shù)據(jù)分析。

app能使用賬號(hào)密碼進(jìn)行登錄，沒有圖形驗(yàn)證碼，按道理應(yīng)該可以進(jìn)行賬號(hào)密碼爆破，但可惜賬號(hào)和密碼在發(fā)送到云端時(shí)會(huì)做加密處理，這個(gè)攻擊點(diǎn)只能暫緩，需要逆向看看相關(guān)加密的邏輯。登錄成功后，云端會(huì)返回一串JWT的身份令牌，為啥是JWT呢，因?yàn)樗雌饋砭褪荍WT，相關(guān)內(nèi)容我們放到下文詳細(xì)介紹?，F(xiàn)在我們可以進(jìn)行控車嘗試了，在控車界面先點(diǎn)擊“鳴笛”，抓取數(shù)據(jù)包查看一下數(shù)據(jù)包構(gòu)成。

nice，又是一個(gè)加密的參數(shù)，目前type類型指的應(yīng)該是控車功能類型，serixxx目測(cè)可能是token令牌或者用于簽名的數(shù)據(jù)，sign就不說了，目前看不出簽名的生成方式，vehicleId應(yīng)該是車輛標(biāo)識(shí)。登錄和控車的數(shù)據(jù)包里，關(guān)鍵參數(shù)都是經(jīng)過加密處理的，需要使用JEB或者JADX對(duì)app進(jìn)行逆向分析。兩個(gè)工具都挺好，使用教程網(wǎng)上一搜那是直接的nice，任選其一就行。

逆向分析

控車數(shù)據(jù)包中，serixxx是由云端返回的數(shù)據(jù)，數(shù)據(jù)包和代碼如下圖所示。

上圖中，云端返回的響應(yīng)中，serixxx數(shù)據(jù)也是加密的，即圖中的data字段。通過搜索請(qǐng)求的url，可以定位到這條響應(yīng)的處理流程，即上圖中的success函數(shù)，顯然這里需要使用RSA私鑰進(jìn)行解密。要獲取這個(gè)私鑰，最簡單的方式是Frida直接掛hook。我們的上一篇文章中已經(jīng)介紹了不少基于Frida實(shí)現(xiàn)的功能，但是Frida的能力遠(yuǎn)遠(yuǎn)不限于此。Frida 可以通過在目標(biāo)應(yīng)用程序的函數(shù)上設(shè)置 hook 來實(shí)現(xiàn)對(duì)應(yīng)用程序行為的監(jiān)控和修改，這對(duì)于查找敏感信息、繞過安全措施或者修改應(yīng)用程序邏輯非常有用。

回到主題，既然decrypt方法接受privateKey作為參數(shù)輸入，那我們就hook該方法，在觸發(fā)該方法后輸出privateKey以及解密后的serixxx數(shù)據(jù)。

以上腳本不僅hook了decrypt方法，將之前的getSerixxx方法以及它的處理函數(shù)success一并hook，這樣當(dāng)app觸發(fā)這個(gè)方法的同時(shí)我不僅能得到privateKey，還能得到云端返回的原始數(shù)據(jù)，方便于后續(xù)驗(yàn)證私鑰的正確性。

運(yùn)行app后，從Frida打印的信息中，可以看到原始數(shù)據(jù)、privateKey、serixxx，已經(jīng)成功被我們獲取。此外我們還可以編寫一個(gè)python腳本，使用privateKey來解密云端響應(yīng)的數(shù)據(jù)，方便后續(xù)直接發(fā)包實(shí)現(xiàn)控車功能。

除了serixxx數(shù)據(jù)外，遠(yuǎn)控?cái)?shù)據(jù)包中還剩sign簽名沒有搞定，繼續(xù)在源代碼里搜尋，同樣利用url的請(qǐng)求，可以快速定位到sign的計(jì)算方法。

doSign 方法接受三個(gè)參數(shù)：content（待簽名內(nèi)容）、charset（字符集，可選）、privateKey（私鑰）。此時(shí)我們還是使用hook大法，看看到底是對(duì)什么內(nèi)容進(jìn)行簽名，簽名的密鑰是什么。

通過輸出的結(jié)果可以知道，該簽名方法僅僅是對(duì)Serixxx和vehicleId進(jìn)行簽名，并且簽名的privateKey和解密數(shù)據(jù)的privateKey是同一個(gè)（干得漂亮(⊙ω⊙)）。這里我們同樣可以編寫python腳本實(shí)現(xiàn)簽名算法。

至此，所有參數(shù)的邏輯已經(jīng)理清，我們便可以嘗試偽造控車指令了。此時(shí)，肯定有大佬要問，即便是發(fā)送了偽造的控車指令，但是你的身份信息怎么偽造，身份信息偽造不了這個(gè)控車有啥意義呢，難不成讓用戶自己給你賬號(hào)密碼登錄再進(jìn)行控車。。。。。。。其實(shí)最開始我們登錄的時(shí)候就發(fā)現(xiàn)該app進(jìn)行登錄的時(shí)候沒有通過圖形驗(yàn)證碼進(jìn)行校驗(yàn)，那就存在賬號(hào)密碼爆破的風(fēng)險(xiǎn)，雖然數(shù)據(jù)進(jìn)行了加密，但是沒有問題是逆向分析解決不了的~~~同樣利用登錄的url，可以定位到相關(guān)代碼。

同樣的套路，使用Frida hook關(guān)鍵函數(shù)拿到加密密鑰進(jìn)行爆破，這不就來了嘛，能不能成功就看運(yùn)氣！

JWT

抓取登錄數(shù)據(jù)包時(shí)我們就發(fā)現(xiàn)云端返回的令牌是JWT了。JWT(JSON Web Tokens)是一個(gè)應(yīng)用層消息保護(hù)開放標(biāo)準(zhǔn)(RFC 7519)，規(guī)定了一種Token實(shí)現(xiàn)方式，采用JSON格式。它在近年來被廣泛應(yīng)用于各種認(rèn)證機(jī)制中，但也存在被誤用的風(fēng)險(xiǎn)及由此產(chǎn)生的安全問題。JWT本質(zhì)上是一個(gè)字符串，分為三個(gè)部分:

（1）Header: 存放Token類型和加密的方法

（2）Payload: 包含一些用戶身份信息.

（3）Signature: 簽名是將前面的Header,Payload信息以及一個(gè)密鑰組合起來并使用Header中的算法進(jìn)行加密

JWT是一種非常復(fù)雜的機(jī)制，包含JWT、JWS、JWE、JWK、多種密碼算法、兩種不同的編碼方式（或者說序列化）、壓縮、可能采用不止一種簽名、對(duì)多個(gè)收件人的加密······其中各個(gè)部分出問題都可能導(dǎo)致漏洞產(chǎn)生。

（1）Header部分

是否支持修改算法為none/對(duì)稱加密算法

是否可以刪除簽名

插入錯(cuò)誤信息

kid字段是否有SQL注入/命令注入/目錄遍歷

jwk元素是否可信是否強(qiáng)制使用白名單上的加密算法

（2）Payload部分

是否存在敏感信息檢查過期策略，比如 exp, iat

（3）Signature部分

檢查是否強(qiáng)制檢查簽名

密鑰是否可以爆破（如HMAC)

是否可以通過其他方式拿到密鑰

采用了自身存在脆弱性的算法（如ECDH-ES）簽名方法之間是否存在沖突

（4）其他

重放

通過匹配校驗(yàn)的時(shí)間做時(shí)間攻擊

修改算法非對(duì)稱算法為對(duì)稱算法（如修改RS256為HS256）

弱密鑰破解不安全的配置所導(dǎo)致的敏感信息泄露（如在報(bào)錯(cuò)信息中泄露簽名）

所以說能實(shí)現(xiàn)控車的攻擊路徑是很多的，當(dāng)然本次就不一一展示了。

總結(jié)

在當(dāng)前智能網(wǎng)聯(lián)汽車領(lǐng)域，隨著網(wǎng)絡(luò)技術(shù)的不斷演進(jìn)，安全環(huán)境的復(fù)雜性也在不斷提升。網(wǎng)絡(luò)連接的便利性使得攻擊威脅面日益擴(kuò)大，從個(gè)體移動(dòng)終端的安全性到更廣泛的信號(hào)干擾、攔截和偽基站等威脅，都對(duì)汽車安全構(gòu)成潛在威脅。因此，我們迫切需要共同努力，不斷創(chuàng)新，以共同打造一個(gè)更加安全可靠的智能汽車環(huán)境。這需要全體同仁的不懈奮斗，共同為構(gòu)建安全的汽車網(wǎng)絡(luò)生態(tài)貢獻(xiàn)力量。