0x00 序

以前總是在這裡看到各位大牛分享其安全滲透經驗，而今我也很榮幸的收到了烏雲的約稿，興奮之情難以言表。由於IOS是一種閉源的作業系統，原始碼恐怕也只有幾個人見過，其安全性究竟如何我們不得而知，突然想起一段話：恐懼來源於我們的無知。好在國內早有大牛團隊—盤古團隊總是走在世界的前沿給我們帶來最新鮮的IOS安全詳解，感謝沙梓社和吳航的《IOS應用逆向工程》讓我對IOS逆向充滿興趣，感謝念茜的部落格將我領入了IOS安全之門。

為了能讓文章具有原創性，如下我將結合我接觸過的APP進行幾個簡單方面的詳細解釋。

0x01 敏感資訊洩露之不定時炸彈

本地儲存的敏感資料：首先我們需要一個越獄手機，還需要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

團貸網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開發小夥伴微信加我為好友說道：由於身份校驗的介面較老，所以無法處理加密後的使用者名稱和密碼，但是他們已經向上級申請提高身份校驗介面的安全性了。

0x02 HTTP or HTTPS更安全？

可能很多人看了這個標題都想說一句：“這不是廢話麼，如果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協議的小夥伴的安全方案，通訊資料要做到讓人看了就煩的地步。總之安全要做到雙保險。如果有機會，希望以後可以詳細的講一下繞過認證的幾種方法。

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

這裡可能和上面的內容有些重複，不過這的重點是如何釣魚。在烏雲上看到好多廠商對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協議，那麼也要為廣大的普通使用者考慮，不要讓壞人成為中間人來對我們的手機做壞事。呼籲廠商不要忽略中間人攻擊的漏洞。

0x04 小結

本來是想寫到0x005的，但是發現篇幅有點太長，希望下次有機會繼續寫吧。這裡我們做一個簡單的小結：1、資料請勿本地儲存，用後請刪或新增訪問限制；2、不要過分的信任某項技術，安全要做到雙保險；3、誘騙一個使用者並不是很難。