Android系統(tǒng)https抓包問題分析
每次分析app時(shí)都免不了抓包這一環(huán)節(jié)。想要抓到包就要看app采取的什么通信協(xié)議了。由于http存在的種種不安全性,當(dāng)前大部分的app基本都已經(jīng)是采用https的通信協(xié)議。所以連抓包也變得越來越不友好。不論是使用burpsuite還是fiddler,當(dāng)前的抓包工具基本原理都是采用的中間人的方式。原理就是這些工具作為中間人,對客戶端偽裝成服務(wù)端,對服務(wù)端偽裝成客戶端。
HTTPS
http即超文本傳輸協(xié)議,是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議 ,是一個(gè)客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)(TCP),用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議,它可以使瀏覽器更加高效,使網(wǎng)絡(luò)傳輸減少。然而他也存在著一些缺點(diǎn),比如通信使用明文,內(nèi)容極易被竊聽;不驗(yàn)證通信方的身份,因此有可能遭遇偽裝;無法證明報(bào)文的完整性,所以有可能遭到篡改。因此,http的加強(qiáng)版https應(yīng)運(yùn)而生。https中的s是ssl或者tls,就是在原HTTP的基礎(chǔ)上加上一層用于數(shù)據(jù)加密、解密、身份認(rèn)證的安全層。
HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS
https需要CA證書,我們之前說的中間人需要對客戶端偽裝成真正的服務(wù)端,要求就是當(dāng)客戶端向我們發(fā)送網(wǎng)絡(luò)請求時(shí),我們必須能夠給指定域名簽發(fā)公鑰證書,且公鑰證書能夠通過系統(tǒng)的安全校驗(yàn)。對于我們是不是真正的客戶端,通常來說服務(wù)器是不太會關(guān)心的,他是不會去關(guān)心你是谷歌瀏覽器還是百度瀏覽器,當(dāng)然了也會有例外。接下來要說的雙向驗(yàn)證就是如此。
單向驗(yàn)證與雙向驗(yàn)證
首先了解一下什么是https的單雙向驗(yàn)證,主要說一下雙向驗(yàn)證,雙向驗(yàn)證相比較單向驗(yàn)證,增加了服務(wù)端對客戶端的認(rèn)證。
雙向認(rèn)證詳細(xì)過程如下:
(1)客戶端發(fā)起HTTPS請求,將SSL協(xié)議版本的信息發(fā)送給服務(wù)端。
(2)服務(wù)端去CA機(jī)構(gòu)申請來一份CA證書,在前面提過,證書里面有服務(wù)端公鑰和簽名。將CA證書發(fā)送給客戶端
(3)客戶端讀取CA證書的明文信息,采用相同的hash散列函數(shù)計(jì)算得到信息摘要(hash目的:驗(yàn)證防止內(nèi)容被修改),然后用操作系統(tǒng)帶的CA的公鑰去解密簽名(因?yàn)楹灻怯肅A的私鑰加密的),對比證書中的信息摘要。如果一致,則證明證書是可信的,然后取出了服務(wù)端公鑰
(4)客戶端發(fā)送自己的客戶端證書給服務(wù)端,證書里面有客戶端的公鑰:C_公鑰
(5)客戶端發(fā)送支持的對稱加密方案給服務(wù)端,供其選擇
(6)服務(wù)端選擇完加密方案后,用剛才得到的C_公鑰去加密選好的加密方案
(7)客戶端用自己的C_私鑰去解密選好的加密方案,客戶端生成一個(gè)隨機(jī)數(shù)(密鑰F),用剛才等到的服務(wù)端B_公鑰去加密這個(gè)隨機(jī)數(shù)形成密文,發(fā)送給服務(wù)端。
(8)服務(wù)端和客戶端在后續(xù)通訊過程中就使用這個(gè)密鑰F進(jìn)行通信了。和之前的非對稱加密不同,這里開始就是一種對稱加密的方式
SSL pinning
SSL Pinning是一種防止中間人攻擊的技術(shù),主要機(jī)制是在客戶端發(fā)起請求–>收到服務(wù)器發(fā)來的證書進(jìn)行校驗(yàn),如果收到的證書不被客戶端信任,就直接斷開連接不繼續(xù)求情。可以發(fā)現(xiàn)中間人攻擊的要點(diǎn)的偽造了一個(gè)假的服務(wù)端證書給了客戶端,客戶端誤以為真。解決思路就是,客戶端也預(yù)置一份服務(wù)端的證書,比較一下就知道真假了。
SSL-pinning有兩種方式:
證書鎖定(Certificate Pinning) 和公鑰鎖定( Public Key Pinning)。
證書鎖定
需要在客戶端代碼內(nèi)置僅接受指定域名的證書,而不接受操作系統(tǒng)或?yàn)g覽器內(nèi)置的CA根證書對應(yīng)的任何證書,通過這種授權(quán)方式,保障了APP與服務(wù)端通信的唯一性和安全性,因此客戶端與服務(wù)端(例如API網(wǎng)關(guān))之間的通信是可以保證絕對安全。但是CA簽發(fā)證書都存在有效期問題,缺點(diǎn)是在
證書續(xù)期后需要將證書重新內(nèi)置到APP中。
公鑰鎖定
提取證書中的公鑰并內(nèi)置到客戶端中,通過與服務(wù)器對比公鑰值來驗(yàn)證連接的正確性。制作證書密鑰時(shí),公鑰在證書的續(xù)期前后都可以保持不變(即密鑰對不變),所以可以避免證書有效期問題,一般推薦這種做法。
雙向驗(yàn)證與SSL pinning的區(qū)別
一定要注意雙向驗(yàn)證與SSL pinning的區(qū)別!
SSL pinning實(shí)際上是客戶端鎖定服務(wù)器端的證書, 在要與服務(wù)器進(jìn)行交互的時(shí)候, 服務(wù)器端會將CA證書發(fā)送給客戶端, 客戶端會調(diào)用函數(shù)對服務(wù)器端的證書進(jìn)行校驗(yàn), 與本地的服務(wù)器端證書(存放在.\asset目錄或\res\raw下)進(jìn)行比對。而雙向認(rèn)證是添加了客戶端向服務(wù)器發(fā)送CA證書, 服務(wù)器端對客戶端的證書進(jìn)行校驗(yàn)的部分。在app上,https雙向認(rèn)證的方案也可以防止中間人劫持,但這種雙向認(rèn)證開銷較大,且安全性與SSL pinning一致,目前大多數(shù)app都采用SSL Pinning這種方案。
突破雙向認(rèn)證抓包
由于私鑰是受密碼保護(hù)的,所以主要的逆向目標(biāo)就是找到key--密碼。看了好多表哥的文章,終于學(xué)會了一些奇淫巧計(jì)。由于當(dāng)前的app都會有加殼混淆等等防護(hù)手段。所以可以到一些應(yīng)用商店(如360手機(jī)助手,豌豆莢等等)下載應(yīng)用的歷史版本。低版本的保護(hù)不多分析難度相對較低。容易找到目標(biāo)。
首先是到./assets目錄下尋找證書。
確實(shí)是有密碼保護(hù)的。
繼續(xù)往下看可以看到一些相關(guān)信息
這個(gè)getSocketFactory就是關(guān)鍵函數(shù)
可以看到EncryptUtils函數(shù)。
看到native需要分析so層。進(jìn)入so后。
解密即可找到。
找到密碼后,輸入密碼即可
使用xposed hook繞過SSL證書驗(yàn)證
在全球最大的同性交流網(wǎng)站某hub 下載JustTrustMe
然后在xposed上安裝這個(gè)框架就可以了。JustTrustMe的原理就是將各種已知的的HTTP請求庫中用于校驗(yàn)證書的API都進(jìn)行Hook,使無論是否是可信證書的情況,校驗(yàn)結(jié)果返回都為正常狀態(tài),從而實(shí)現(xiàn)繞過證書檢查的效果。
總結(jié)
抓包是進(jìn)行app逆向分析的第一步,走好每一步才能走向最后的成功。