iOS App安全雜談

0x00 序

由于IOS是一種閉源的操作系統(tǒng),源碼恐怕也只有幾個人見過,其安全性究竟如何我們不得而知,突然想起一段話:恐懼來源于我們的無知。好在國內(nèi)早有大牛團(tuán)隊—盤古團(tuán)隊總是走在世界的前沿給我們帶來最新鮮的IOS安全詳解.

為了能讓文章具有原創(chuàng)性,如下我將結(jié)合我接觸過的APP進(jìn)行幾個簡單方面的詳細(xì)解釋。

0x01 敏感信息泄露之不定時炸彈

本地存儲的敏感數(shù)據(jù):首先我們需要一個越獄手機,還需要iTools工具來幫助我們。其實過程很簡單,用iTools連接你的iPhone,通過共享文件打開某一APP,里邊的結(jié)構(gòu)一目了然。其中Document目錄:目錄存儲用戶數(shù)據(jù)或其他應(yīng)該定期備份的信息。AppName.app目錄:這是應(yīng)用程序的程序包目錄,包括應(yīng)用程序本身,在AppStore上下載的APP是需要脫殼的才能將程序用IDA反編譯的。Library目錄:這個目錄下有兩個子目錄Caches和Preference,Caches目錄存儲應(yīng)用程序?qū)S玫闹С治募?,保存?yīng)用程序再次啟動過程中需要的信息,而Preference目錄包含程序的偏好設(shè)置。

招商銀行IOS客戶端目錄結(jié)構(gòu)

那么哪些文件是可能透露敏感信息的呢?以plist、db、xml、log、txt為后綴的文件需要重點監(jiān)控,例如中國銀聯(lián)的銀聯(lián)手機支付APP將用戶名和密碼居然以明文的方式存儲在了unionpay.db的文件中;蘇寧的某款理財APP同樣的也是將手機號碼和密碼存儲在了以plist為后綴的文件中;當(dāng)然也見過xml和log文件中存有敏感信息的APP。還有各種的txt或其他文檔,光大銀行的某款A(yù)PP里的111.txt文件中就記錄了交易明細(xì)、轉(zhuǎn)賬匯款、手機任意轉(zhuǎn)等多種操作的URL,這給滲透測試人員大大的方便。還有更奇葩的是見過某銀行APP中的某文件中記錄著“這個項目TMD難做了!”

銀聯(lián)支付IOS客戶端用戶名和密碼明文存儲

光大銀行IOS客戶端存在方便滲透測試的文件

還有一些敏感數(shù)據(jù)是需要一些腳本來處理的,例如Cookie.Binarycookies文件、keychain文件等。例如浦發(fā)銀行的某款A(yù)PP和團(tuán)貸網(wǎng)的APP就是將自己的cookie信息存儲于本地的Cookie.binarycookies中的,可以使用cookies-binarycookies-reader腳本讀取里邊的詳細(xì)內(nèi)容;keychain文件中存儲了ios系統(tǒng)及第三方應(yīng)用的一些信息,keychain數(shù)據(jù)庫是hacker們最關(guān)注的數(shù)據(jù)源頭之一,我們可以使用Keychain-Dumper導(dǎo)出keychain的值。

團(tuán)貸網(wǎng)IOS客戶端存有cookie信息

這里同時再介紹幾款較為給力的軟件:ikeymonitor、introspy、iFile,其中ikeymonitor軟件是可以監(jiān)控你的鍵盤的,如果銀行使用了自定義鍵盤可以使用該軟件來測試其是否起到了保護(hù)作用;introspy可以追蹤分析應(yīng)用程序,念茜在其微博里就記錄了如何使用該軟件查看支付寶APP采取了什么加密措施,你的手勢密碼是什么,銀行卡是什么都記錄在案,甚至記錄了哪些信息存儲在了什么文件中,親測好用;iFile可以在手機上直接查看某款A(yù)PP的目錄結(jié)構(gòu),也可以直接打開db文件,非常好用。

網(wǎng)絡(luò)上的敏感信息泄露:其實這一點本想放到下一節(jié)來說的,但是好多APP都有這個問題還是拿到這里來說吧。這里不是拿HTTP說事,而是說一種設(shè)計方式的缺陷。曾見過多款A(yù)PP是這樣設(shè)計的:每當(dāng)我在APP上進(jìn)行一次操作時APP會發(fā)數(shù)據(jù)包給服務(wù)端,其中每次發(fā)數(shù)據(jù)包時為了校驗身份都會把用戶名和密碼以明文的方式發(fā)出。這是一種什么樣的概念呢,我在公共場所連接wifi,使用某APP五分鐘,我的明文密碼就在網(wǎng)絡(luò)上明文傳輸了十幾次(因為每次操作都要校驗身份)。還有一種情況,蘇寧某產(chǎn)品因為涉及資金安全所以有手勢密碼的功能,盡管使用的是HTTPS協(xié)議,但是只要我未注銷我的賬戶再次打開APP時,APP跳轉(zhuǎn)到了輸入手勢密碼的頁面,你的用戶名和密碼已經(jīng)通過數(shù)據(jù)包發(fā)往了服務(wù)端,這樣手勢密碼就形同虛設(shè)。詳情見:http://www.wooyun.org/bugs/wooyun-2015-0119249。

蘇寧某IOS客戶端校驗手勢密碼時存在的問題

解決方案:數(shù)據(jù)盡量不要本地存儲或者用后即刪,可能要考慮用戶體驗有些敏感數(shù)據(jù)一定要存儲于本地,那么請將數(shù)據(jù)進(jìn)行加密,數(shù)據(jù)庫要添加訪問限制。前幾天銀聯(lián)忽略了我提交的賬戶密碼明文存儲的漏洞,其實這是不應(yīng)該的,因為移動設(shè)備和PC畢竟不一樣,移動設(shè)備容易丟失,如果不幸的話可能你的錢也會一起丟失的。在給銀行做安全審計的時候,其實這些都算是中危漏洞的,因為銀行要保證資金在最糟糕的情況下也是安全的。對于網(wǎng)絡(luò)上敏感數(shù)據(jù)的應(yīng)對策略,客戶端和服務(wù)端最好用加密后的數(shù)據(jù)進(jìn)行身份的校驗,就在我截稿的前三天,蘇寧的IOS開發(fā)小伙伴微信加我為好友說道:由于身份校驗的接口較老,所以無法處理加密后的用戶名和密碼,但是他們已經(jīng)向上級申請?zhí)岣呱矸菪r灲涌诘陌踩粤恕?/p>

0x02 HTTP or HTTPS更安全?

可能很多人看了這個標(biāo)題都想說一句:“這不是廢話么,如果HTTP安全的話那還要HTTPS有何用?”其實我并不是說哪個協(xié)議更安全,而是想說設(shè)計者不要過分的依賴于某種技術(shù)而放松對其他問題的警惕性,下面我將分別拿真實案例說一下。

雖然使用了HTTP卻依然很安全:這里拿華夏銀行來說吧,他的APP使用了HTTP協(xié)議,我使用Fiddler成功的攔截到了數(shù)據(jù)包,但是我卻發(fā)現(xiàn)無從下手。APP發(fā)出的數(shù)據(jù)和服務(wù)端發(fā)出的數(shù)據(jù)洋洋灑灑的很長最關(guān)鍵的是加鹽加密的,我們不知道哪段是你的用戶名,我們不知道哪段是你的轉(zhuǎn)款金額,我們不知道錢要轉(zhuǎn)給誰。我隨意更改一個字母,數(shù)據(jù)包自己的完整性校驗都過不去。那好,我轉(zhuǎn)款時重放數(shù)據(jù)包,會不會有源源不斷的錢轉(zhuǎn)到我的錢包里呢?APP設(shè)置了時間戳,我們能想到的地方基本上都無法攻破,曾經(jīng)見過最坑的APP:無論是發(fā)出的還是返回的數(shù)據(jù)從始至終均是密文,除非逆向否則你毫無思路。當(dāng)然這的確暴漏了一些問題的關(guān)鍵:即在這層面紗的掩護(hù)下很有可能存在越權(quán)的情況,如果逆向分析得到關(guān)鍵的key,那么后果不堪設(shè)想。

華夏銀行某IOS客戶端使用HTTP協(xié)議

華住酒店的IOS客戶端返回數(shù)據(jù)的可識別度極低

即使使用了HTTPS但很危險:終于可以講關(guān)于HTTPS的一些奇葩經(jīng)歷了。有很多APP包括銀行在內(nèi)的,盡管使用的是HTTPS協(xié)議但其漏洞卻多的可怕,究其原因是其過分的相信了某一技術(shù)。先從今年的四月份Freebuf轉(zhuǎn)載的一篇文章說起:《流行iOS網(wǎng)絡(luò)通信庫AFNetworking曝SSL漏洞,影響銀聯(lián)、中國銀行、交通銀行在內(nèi)的2.5萬個iOS應(yīng)用》,看到這篇文章我首先做的是看看哪些銀行中槍了,然后就是判斷其危險性。漏洞為:如果APP使用了AFNETworking框架的2.5.3之前的版本,攻擊者就可以使用任何可信的證書機構(gòu)(CA)發(fā)布的SSL證書解密和加密數(shù)據(jù);在此之前還有一個漏洞是:攻擊者可以使用自簽名的證書截聽iOS應(yīng)用與服務(wù)器之間的加密的敏感數(shù)據(jù)。

有人會問那這意味著什么?很簡單你的APP信任任何證書,如果你在星巴克連接上了wifi,而又信任了不該信任的證書,那么你在網(wǎng)上的行為早被一覽無余。其實說了這么多我一直沒有說到重點:好多使用了HTTPS協(xié)議的銀行IOS客戶端其數(shù)據(jù)都是明文,因為他認(rèn)為HTTPS足夠安全,所以在設(shè)計的時候根本就沒想到如果數(shù)據(jù)包在中途被改了怎么辦?這樣假設(shè)某APP的數(shù)據(jù)在傳輸過程中轉(zhuǎn)賬金額被篡改了,而自己卻渾然不知,因為發(fā)出的數(shù)據(jù)沒有完整性校驗,本想轉(zhuǎn)出10塊結(jié)果卻轉(zhuǎn)出了100塊。(此段是從受害者的角度出發(fā)的)

上海某銀行的理財客戶端使用了AFNetworking通信庫

這里可能又有人會說,沒事我們的APP沒有使用AFNetworing通信庫,我們的APP只信任自己的證書。但是做安全的都應(yīng)該聽說過hook技術(shù),沒錯這里我們可以hook IOS相關(guān)的API,以此來繞過APP校驗證書合法性的過程,這樣APP就可以信任任何證書,我們一樣可以正常抓到包,這給滲透或者惡意者極大的便利。這里舉個例子:某電商的理財產(chǎn)品,雖然其APP只信任自己的證書,但是仍然可以通過hook一些關(guān)鍵函數(shù)來繞過證書的校驗過程,在對通信數(shù)據(jù)的審計過程中發(fā)現(xiàn),存在越權(quán)可泄露任意用戶的姓名、銀行卡號和手機號。由于返回的數(shù)據(jù)也都是明文未做加密處理,我們甚至可以通過修改幾個關(guān)鍵參數(shù)繞過安全問題,達(dá)到重置支付密碼的目的。(此段是從惡意者角度出發(fā)的) 這里我不放截圖了因為廠商還沒有修復(fù),請參考蘇寧易付寶錢包IOS客戶端存在賬戶越權(quán)可泄漏任意用戶姓名/銀行卡號/手機號等;中國銀聯(lián)某移產(chǎn)品設(shè)計不當(dāng)可繞過密保問題重置任意用戶密碼,另外推薦深度好文

So,不是HTTPS不安全,而是工程師過分的信任了某項技術(shù)的安全性而忽略了潛在的危險,在這里提醒開發(fā)者參數(shù)校驗要放到服務(wù)端來做,安全要做到雙保險。還有就是要警惕一些開源的開發(fā)庫,盡管這些開源開發(fā)庫給我?guī)砹酥T多便利,但是他也是一顆定時炸彈。

解決方案:只使用HTTP協(xié)議的采用HTTPS,采用HTTPS協(xié)議的工程師學(xué)習(xí)學(xué)習(xí)只使用HTTP協(xié)議的小伙伴的安全方案,通信數(shù)據(jù)要做到讓人看了就煩的地步。總之安全要做到雙保險。如果有機會,希望以后可以詳細(xì)的講一下繞過認(rèn)證的幾種方法。

0x03 中間人攻擊之放長線釣大魚

這里可能和上面的內(nèi)容有些重復(fù),不過這的重點是如何釣魚。在烏云上看到好多廠商對PC端的中間人攻擊漏洞采取了積極處理,而移動端的卻總是被忽略,在這里我想為移動端討些說法。隨著時代的變遷wifi已經(jīng)變得越來越普及了,當(dāng)然如果你是土豪一直用流量那么我無話可說,但是畢竟土豪總是少數(shù)人么,今年的315就現(xiàn)場演示了一把什么是黑wifi。所謂黑wifi并不只是在你和服務(wù)器之間有一雙眼在偷偷的看著你在干什么,更有甚者他是想在你的移動設(shè)備上裝些什么,用一個比較專業(yè)的詞叫中間人攻擊。

2015年315晚會關(guān)于wifi的新聞

曾遇到過IOS端的多款A(yù)PP更新時返回更新鏈接,當(dāng)我點擊更新時會跳轉(zhuǎn)到AppStore或者自己的APP發(fā)放平臺那里,如果這里沒有對返回數(shù)據(jù)進(jìn)行合法性校驗的話很容易招到中間人攻擊。這里拿58同城的IOS客戶端做一個例子,當(dāng)我打開APP時他會自動檢查軟件更新,如果存在新版本則立即返回更新提示,這里我修改返回鏈接為其他APP的下載鏈接,那么下載的應(yīng)用就是其他的APP。也可以修改為其他應(yīng)用的URL Scheme,例如支付寶的URL Scheme(alipass://),這樣我點擊更新時便直接跳轉(zhuǎn)到了支付寶,如果越獄了可能還會安裝一些惡意木馬。其實處理這類問題很簡單,數(shù)據(jù)包里加一個完整性的校驗,當(dāng)客戶端發(fā)現(xiàn)數(shù)據(jù)包被篡改時可自動注銷或提示用戶存在風(fēng)險。

58同城IOS客戶端更新可被劫持

可能有人會說了,我使用HTTPS協(xié)議不怕你們的所謂中間人??墒菍嶋H上真的是這樣么?這里的關(guān)鍵是如何讓用戶信任一個第三方的證書,現(xiàn)在大多的公共免費wifi連接后需要登錄web進(jìn)行驗證,驗證過程中需要輸入手機號和驗證碼然后點擊下一步。沒錯,我們可以在下一步的按鈕上做文章,釣魚wifi的名稱可以設(shè)置為“XXX銀行免費WIFI”,當(dāng)用戶連接后跳轉(zhuǎn)到手機認(rèn)證處,我們將下一步的按鈕的鏈接設(shè)置為下載證書的鏈接(例如:http://localhost:8888/FiddlerRoot.cer),只要用戶點擊下一步,證書就會自動下載,安裝證書則需要用戶再次點擊。為了能讓用戶更容易上當(dāng),完全可以在驗證手機號碼的頁面上寫到“為保證用戶的數(shù)據(jù)安全,使用我銀行的免費wifi時請先安裝證書,點擊下一步即可安裝”。可能在從事安全行業(yè)的人眼里我們是不會輕易信任任何證書的,但是使用wifi的人大多不懂安全,更不懂得什么是證書,如若用戶不小心連接了釣魚wifi,那么估計也有百分之八十的人會去信任這個非法的證書。而在IOS中,CA頒發(fā)的證書被標(biāo)識為可信,而自簽名的證書被標(biāo)識為不可信,可這在一個著急想蹭免費wifi的人眼里有什么區(qū)別么?

這是自簽名的證書IOS顯示不可信

解決方案:即使客戶端使用了較為嚴(yán)格的數(shù)據(jù)自我校驗體系,即使客戶端使用了HTTPS協(xié)議,那么也要為廣大的普通用戶考慮,不要讓壞人成為中間人來對我們的手機做壞事。呼吁廠商不要忽略中間人攻擊的漏洞。

0x04 小結(jié)

本來是想寫到0x005的,但是發(fā)現(xiàn)篇幅有點太長,希望下次有機會繼續(xù)寫吧。這里我們做一個簡單的小結(jié):1、數(shù)據(jù)請勿本地存儲,用后請刪或添加訪問限制;2、不要過分的信任某項技術(shù),安全要做到雙保險;3、誘騙一個用戶并不是很難。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容