以前总是在这里看到各位大牛分享其安全渗透经验，而今我也很荣幸的收到了乌云的约稿，兴奋之情难以言表。由于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、诱骗一个用户并不是很难。