以前總是在這里看到各位大牛分享其安全滲透經驗,而今我也很榮幸的收到了烏云的約稿,興奮之情難以言表。由于IOS是一種閉源的操作系統,源碼恐怕也只有幾個人見過,其安全性究竟如何我們不得而知,突然想起一段話:恐懼來源于我們的無知。好在國內早有大牛團隊—盤古團隊總是走在世界的前沿給我們帶來最新鮮的IOS安全詳解,感謝沙梓社和吳航的《IOS應用逆向工程》讓我對IOS逆向充滿興趣,感謝念茜的博客將我領入了IOS安全之門。
為了能讓文章具有原創性,如下我將結合我接觸過的APP進行幾個簡單方面的詳細解釋。
本地存儲的敏感數據:首先我們需要一個越獄手機,還需要iTools工具來幫助我們。其實過程很簡單,用iTools連接你的iPhone,通過共享文件打開某一APP,里邊的結構一目了然。其中Document目錄:目錄存儲用戶數據或其他應該定期備份的信息。AppName.app目錄:這是應用程序的程序包目錄,包括應用程序本身,在AppStore上下載的APP是需要脫殼的才能將程序用IDA反編譯的。Library目錄:這個目錄下有兩個子目錄Caches和Preference,Caches目錄存儲應用程序專用的支持文件,保存應用程序再次啟動過程中需要的信息,而Preference目錄包含程序的偏好設置。
招商銀行IOS客戶端目錄結構
那么哪些文件是可能透露敏感信息的呢?以plist、db、xml、log、txt為后綴的文件需要重點監控,例如中國銀聯的銀聯手機支付APP將用戶名和密碼居然以明文的方式存儲在了unionpay.db的文件中;蘇寧的某款理財APP同樣的也是將手機號碼和密碼存儲在了以plist為后綴的文件中;當然也見過xml和log文件中存有敏感信息的APP。還有各種的txt或其他文檔,光大銀行的某款APP里的111.txt文件中就記錄了交易明細、轉賬匯款、手機任意轉等多種操作的URL,這給滲透測試人員大大的方便。還有更奇葩的是見過某銀行APP中的某文件中記錄著“這個項目TMD難做了!”
銀聯支付IOS客戶端用戶名和密碼明文存儲
光大銀行IOS客戶端存在方便滲透測試的文件
還有一些敏感數據是需要一些腳本來處理的,例如Cookie.Binarycookies文件、keychain文件等。例如浦發銀行的某款APP和團貸網的APP就是將自己的cookie信息存儲于本地的Cookie.binarycookies中的,可以使用cookies-binarycookies-reader腳本讀取里邊的詳細內容;keychain文件中存儲了ios系統及第三方應用的一些信息,keychain數據庫是hacker們最關注的數據源頭之一,我們可以使用Keychain-Dumper導出keychain的值。
團貸網IOS客戶端存有cookie信息
這里同時再介紹幾款較為給力的軟件:ikeymonitor、introspy、iFile,其中ikeymonitor軟件是可以監控你的鍵盤的,如果銀行使用了自定義鍵盤可以使用該軟件來測試其是否起到了保護作用;introspy可以追蹤分析應用程序,念茜在其微博里就記錄了如何使用該軟件查看支付寶APP采取了什么加密措施,你的手勢密碼是什么,銀行卡是什么都記錄在案,甚至記錄了哪些信息存儲在了什么文件中,親測好用;iFile可以在手機上直接查看某款APP的目錄結構,也可以直接打開db文件,非常好用。
網絡上的敏感信息泄露:其實這一點本想放到下一節來說的,但是好多APP都有這個問題還是拿到這里來說吧。這里不是拿HTTP說事,而是說一種設計方式的缺陷。曾見過多款APP是這樣設計的:每當我在APP上進行一次操作時APP會發數據包給服務端,其中每次發數據包時為了校驗身份都會把用戶名和密碼以明文的方式發出。這是一種什么樣的概念呢,我在公共場所連接wifi,使用某APP五分鐘,我的明文密碼就在網絡上明文傳輸了十幾次(因為每次操作都要校驗身份)。還有一種情況,蘇寧某產品因為涉及資金安全所以有手勢密碼的功能,盡管使用的是HTTPS協議,但是只要我未注銷我的賬戶再次打開APP時,APP跳轉到了輸入手勢密碼的頁面,你的用戶名和密碼已經通過數據包發往了服務端,這樣手勢密碼就形同虛設。詳情見:WooYun-2015-119249。
蘇寧某IOS客戶端校驗手勢密碼時存在的問題
解決方案:數據盡量不要本地存儲或者用后即刪,可能要考慮用戶體驗有些敏感數據一定要存儲于本地,那么請將數據進行加密,數據庫要添加訪問限制。前幾天銀聯忽略了我提交的賬戶密碼明文存儲的漏洞,其實這是不應該的,因為移動設備和PC畢竟不一樣,移動設備容易丟失,如果不幸的話可能你的錢也會一起丟失的。在給銀行做安全審計的時候,其實這些都算是中危漏洞的,因為銀行要保證資金在最糟糕的情況下也是安全的。對于網絡上敏感數據的應對策略,客戶端和服務端最好用加密后的數據進行身份的校驗,就在我截稿的前三天,蘇寧的IOS開發小伙伴微信加我為好友說道:由于身份校驗的接口較老,所以無法處理加密后的用戶名和密碼,但是他們已經向上級申請提高身份校驗接口的安全性了。
可能很多人看了這個標題都想說一句:“這不是廢話么,如果HTTP安全的話那還要HTTPS有何用?”其實我并不是說哪個協議更安全,而是想說設計者不要過分的依賴于某種技術而放松對其他問題的警惕性,下面我將分別拿真實案例說一下。
雖然使用了HTTP卻依然很安全:這里拿華夏銀行來說吧,他的APP使用了HTTP協議,我使用Fiddler成功的攔截到了數據包,但是我卻發現無從下手。APP發出的數據和服務端發出的數據洋洋灑灑的很長最關鍵的是加鹽加密的,我們不知道哪段是你的用戶名,我們不知道哪段是你的轉款金額,我們不知道錢要轉給誰。我隨意更改一個字母,數據包自己的完整性校驗都過不去。那好,我轉款時重放數據包,會不會有源源不斷的錢轉到我的錢包里呢?APP設置了時間戳,我們能想到的地方基本上都無法攻破,曾經見過最坑的APP:無論是發出的還是返回的數據從始至終均是密文,除非逆向否則你毫無思路。當然這的確暴漏了一些問題的關鍵:即在這層面紗的掩護下很有可能存在越權的情況,如果逆向分析得到關鍵的key,那么后果不堪設想。
華夏銀行某IOS客戶端使用HTTP協議
華住酒店的IOS客戶端返回數據的可識別度極低
即使使用了HTTPS但很危險:終于可以講關于HTTPS的一些奇葩經歷了。有很多APP包括銀行在內的,盡管使用的是HTTPS協議但其漏洞卻多的可怕,究其原因是其過分的相信了某一技術。先從今年的四月份Freebuf轉載的一篇文章說起:《流行iOS網絡通信庫AFNetworking曝SSL漏洞,影響銀聯、中國銀行、交通銀行在內的2.5萬個iOS應用》,看到這篇文章我首先做的是看看哪些銀行中槍了,然后就是判斷其危險性。漏洞為:如果APP使用了AFNETworking框架的2.5.3之前的版本,攻擊者就可以使用任何可信的證書機構(CA)發布的SSL證書解密和加密數據;在此之前還有一個漏洞是:攻擊者可以使用自簽名的證書截聽iOS應用與服務器之間的加密的敏感數據。
有人會問那這意味著什么?很簡單你的APP信任任何證書,如果你在星巴克連接上了wifi,而又信任了不該信任的證書,那么你在網上的行為早被一覽無余。其實說了這么多我一直沒有說到重點:好多使用了HTTPS協議的銀行IOS客戶端其數據都是明文,因為他認為HTTPS足夠安全,所以在設計的時候根本就沒想到如果數據包在中途被改了怎么辦?這樣假設某APP的數據在傳輸過程中轉賬金額被篡改了,而自己卻渾然不知,因為發出的數據沒有完整性校驗,本想轉出10塊結果卻轉出了100塊。(此段是從受害者的角度出發的)
上海某銀行的理財客戶端使用了AFNetworking通信庫
這里可能又有人會說,沒事我們的APP沒有使用AFNetworing通信庫,我們的APP只信任自己的證書。但是做安全的都應該聽說過hook技術,沒錯這里我們可以hook IOS相關的API,以此來繞過APP校驗證書合法性的過程,這樣APP就可以信任任何證書,我們一樣可以正常抓到包,這給滲透或者惡意者極大的便利。這里舉個例子:某電商的理財產品,雖然其APP只信任自己的證書,但是仍然可以通過hook一些關鍵函數來繞過證書的校驗過程,在對通信數據的審計過程中發現,存在越權可泄露任意用戶的姓名、銀行卡號和手機號。由于返回的數據也都是明文未做加密處理,我們甚至可以通過修改幾個關鍵參數繞過安全問題,達到重置支付密碼的目的。(此段是從惡意者角度出發的) 這里我不放截圖了因為廠商還沒有修復,請參考蘇寧易付寶錢包IOS客戶端存在賬戶越權可泄漏任意用戶姓名/銀行卡號/手機號等;中國銀聯某移產品設計不當可繞過密保問題重置任意用戶密碼,另外推薦深度好文。
So,不是HTTPS不安全,而是工程師過分的信任了某項技術的安全性而忽略了潛在的危險,在這里提醒開發者參數校驗要放到服務端來做,安全要做到雙保險。還有就是要警惕一些開源的開發庫,盡管這些開源開發庫給我帶來了諸多便利,但是他也是一顆定時炸彈。
解決方案:只使用HTTP協議的采用HTTPS,采用HTTPS協議的工程師學習學習只使用HTTP協議的小伙伴的安全方案,通信數據要做到讓人看了就煩的地步。總之安全要做到雙保險。如果有機會,希望以后可以詳細的講一下繞過認證的幾種方法。
這里可能和上面的內容有些重復,不過這的重點是如何釣魚。在烏云上看到好多廠商對PC端的中間人攻擊漏洞采取了積極處理,而移動端的卻總是被忽略,在這里我想為移動端討些說法。隨著時代的變遷wifi已經變得越來越普及了,當然如果你是土豪一直用流量那么我無話可說,但是畢竟土豪總是少數人么,今年的315就現場演示了一把什么是黑wifi。所謂黑wifi并不只是在你和服務器之間有一雙眼在偷偷的看著你在干什么,更有甚者他是想在你的移動設備上裝些什么,用一個比較專業的詞叫中間人攻擊。
2015年315晚會關于wifi的新聞
曾遇到過IOS端的多款APP更新時返回更新鏈接,當我點擊更新時會跳轉到AppStore或者自己的APP發放平臺那里,如果這里沒有對返回數據進行合法性校驗的話很容易招到中間人攻擊。這里拿58同城的IOS客戶端做一個例子,當我打開APP時他會自動檢查軟件更新,如果存在新版本則立即返回更新提示,這里我修改返回鏈接為其他APP的下載鏈接,那么下載的應用就是其他的APP。也可以修改為其他應用的URL Scheme,例如支付寶的URL Scheme(alipass://),這樣我點擊更新時便直接跳轉到了支付寶,如果越獄了可能還會安裝一些惡意木馬。其實處理這類問題很簡單,數據包里加一個完整性的校驗,當客戶端發現數據包被篡改時可自動注銷或提示用戶存在風險。
58同城IOS客戶端更新可被劫持
可能有人會說了,我使用HTTPS協議不怕你們的所謂中間人。可是實際上真的是這樣么?這里的關鍵是如何讓用戶信任一個第三方的證書,現在大多的公共免費wifi連接后需要登錄web進行驗證,驗證過程中需要輸入手機號和驗證碼然后點擊下一步。沒錯,我們可以在下一步的按鈕上做文章,釣魚wifi的名稱可以設置為“XXX銀行免費WIFI”,當用戶連接后跳轉到手機認證處,我們將下一步的按鈕的鏈接設置為下載證書的鏈接(例如:http://localhost:8888/FiddlerRoot.cer),只要用戶點擊下一步,證書就會自動下載,安裝證書則需要用戶再次點擊。為了能讓用戶更容易上當,完全可以在驗證手機號碼的頁面上寫到“為保證用戶的數據安全,使用我銀行的免費wifi時請先安裝證書,點擊下一步即可安裝”。可能在從事安全行業的人眼里我們是不會輕易信任任何證書的,但是使用wifi的人大多不懂安全,更不懂得什么是證書,如若用戶不小心連接了釣魚wifi,那么估計也有百分之八十的人會去信任這個非法的證書。而在IOS中,CA頒發的證書被標識為可信,而自簽名的證書被標識為不可信,可這在一個著急想蹭免費wifi的人眼里有什么區別么?
這是自簽名的證書IOS顯示不可信
解決方案:即使客戶端使用了較為嚴格的數據自我校驗體系,即使客戶端使用了HTTPS協議,那么也要為廣大的普通用戶考慮,不要讓壞人成為中間人來對我們的手機做壞事。呼吁廠商不要忽略中間人攻擊的漏洞。
本來是想寫到0x005的,但是發現篇幅有點太長,希望下次有機會繼續寫吧。這里我們做一個簡單的小結:1、數據請勿本地存儲,用后請刪或添加訪問限制;2、不要過分的信任某項技術,安全要做到雙保險;3、誘騙一個用戶并不是很難。