# 漏洞挖掘—APP应用 APP应用比浏览器有更好的交互体验，比PC端应用更加便捷，作为IOT设备控制手段愈发流行。APP为IOT生态提供了丰富的接口和灵活的交互，许多传统设备厂商也逐步从web管理投入APP应用的怀抱。与此同时，更多接口带来更多风险，代码重新实现也带来更多漏洞隐患。 手机也是智能设备，当然也属IOT网络重要环节，但由于手机(APP)安全已自成体系且资料全面，所以不作为本文侧重点。本篇旨在从APP在IOT网络中所处角色出发，阐述可能存在的漏洞点，并给出一些加固建议，最后梳理研究大致流程，推荐几款研究工具。 ### 一、APP角色 首先来看移动APP在IOT网络的中可能承担的角色， 这是一个比较简单的模型，其中设备、APP和云端服务组成一个三角，APP的角色有： ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2F4lRy88E0dBFzz2yAa9qp%2Fimage.png?alt=media\&token=52a9eee1-16f4-4586-9a52-a9966862c275) * 和设备通信，控制设备行为、向设备读写数据和升级操作等。 * 和服务端通信，与云端同步(读写)数据、指令和获取升级等操作。 从APP在网络中的位置出发，可以预见从其出发可能找到的漏洞点，即 * (1) APP本身存在漏洞，比如本地数据读写等； * (2) APP与设备(云端)通信漏洞，比如弱加密，甚至未加密，认证逻辑等； * (3) APP与设备通信触发设备漏洞，比如越权，内存破坏，拒绝服务等。 其中(2)和(3)的主要区别在于，(2)是APP和设备双向漏洞，即通信和协议问题，(3)可能只有设备存在漏洞，而APP作为一个漏洞发掘的突破口，两者的研究方法有所差异，下文将逐一介绍。 ### 二、APP本地数据泄漏 从APP安装运行环境出发，其与本地接口的交互和对本地数据的读写是重要的漏洞挖掘点。 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FY0sETiYygHktflBZAjWz%2Fimage.png?alt=media\&token=eefcfc8e-48eb-456d-b03d-57cf3aafc80d) 有些APP会存储一些诸如用户名、认证token等个人敏感信息，以便后续调用，如果这些信息未加密存储则有信息暴露风险；有些APP还会存储设备日志和调试未加密信息，这些信息往往成为漏洞挖掘的重要依据。比如在某智能门锁APP中就存在此类数据泄露问题： * 数据库信息泄漏 该门锁Andriod APP在`/data/data/com.belwith.hickorysmart/databases`目录下存储SQLite的未加密数据信息，这些都是用户远程控制门锁设备的关键信息，在退出重启APP后，这些信息任然存在： ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FCqqWyHB3cFum831xGAw0%2Fimage.png?alt=media\&token=2ef07667-fc77-4fc2-a040-a24ccd9e7750) 在该门锁iOS APP中同样存在类似问题，目录`/private/var/mobile/Containers/Data/Application/3CAC91D1-872C-4F96-9460-A93F770AC42D/Library/Caches/com.belwith.HickorySmart`下存在未加密远程开锁信息： ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2Fp1RMd6EP9lH66fFDuwW1%2Fimage.png?alt=media\&token=0e027f85-1bdd-4b27-a4e4-50d7ef4a0165) * 调试信息泄漏 该门锁Andriod APP在`HickorySmartLog/Logs/SRDeviceLog.txt`的调试日志中明文存储所有以蓝牙方式进行的联网的API服务和门锁连接记录。该日志文件存于SD卡中，无需高权限就可任意访问： 通过该日志内容果然发现了API访问控制漏洞，即可用其它用户身份来控制门锁，和之前特斯拉“串车”事件类似。 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2Fsokjbtq7mGKY36Oaq7Jf%2Fimage.png?alt=media\&token=1a8cf369-c20c-49f6-9bb5-dcd919dc6509) ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2F6El2reB8Q9edN44ZlbUU%2Fimage.png?alt=media\&token=cbf9dbce-b982-427f-bbff-8cd993ad6b86) ### 三、APP与设备(云)通信问题 通信问题比较常规，也容易发现，一般就是加密认证存在缺陷。 * 通信未加密 IOT设备的运算性能普遍不高，一些厂商为性能和成本考虑在通信中使用弱加密甚至直接明文通信，造成了很大的安全隐患。 * 认证逻辑错误 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2Fo3rRJXglbjAePIeylDl0%2Fimage.png?alt=media\&token=06756920-ec56-424a-a1da-c9d05f26700c) 一些APP存在认证逻辑缺陷或采用弱身份认证时，攻击者极易获取其认证信息，截取通话内容，可伪造终端同服务端对话，或伪造服务端同终端/移动端通信。同时，缺乏防爆破手段和找回(重置)密码等存在缺陷的问题也时常出现。 ### 四、从APP发现设备端漏洞 APP是设备的控制手段和重要接口，通过澄清通信协议可模拟APP与设备交互，发现一些其他接口无法挖掘的漏洞。 #### 4.1 鉴权逻辑错误或越权访问 比如某智能门铃，通过抓包发现APP与设备采用HTTP明文通信，首先未加密就有安全隐患，这里还存在鉴权问题。 通过设备序列号直接获取设备信息，不需要之前的cookie： * request ``` [[[[ GET /device_check/EKDB_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ]]]] HTTP/1.1 Host: api.gdxp.com:8100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close Upgrade-Insecure-Requests: 1 ``` * response ``` HTTP/1.1 200 OK Server: nginx Date: Tue, 10 Nov 2020 16:12:12 GMT Content-Type: text/html; charset=UTF-8 Connection: close Vary: Accept-Encoding X-Powered-By: PHP/7.2.6 Set-Cookie: PHPSESSID=xxxxxxxxxxxxxxxxx; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Content-Length: 497 {"resultCode":0,"msg":"","content":{"cmd_servers":[{"ip":" xxxxxxxx ","port":8888,"udp_port":25050}],"udp_servers":[{"ip":" xxxxxxxx ","port":25050}],"oss_setting":{"ossFromId":1,"endpoint":"http:\\/\\/oss-eu-west-1.aliyuncs.com","bucket":"britain"},"local_time":"2020-11-10 16:12:12","current_time":1605024732,"sleep_interval":15,"is_test":0,"p2p_servers":[{"ip":" xxxxxxxx ","port":17051}],"push_servers":["http:\\/\\/ xxxxxxxx :58720"],"stun_servers":[{"ip":"xxxxxxxx","port":17051}]}} ``` 无需认证直接可以更新门铃声音： * request ``` POST /app_update_property HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 66 Host: api.gdxp.com:8100 device_sn=EKDB_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&ring_volume=72 ``` * response ``` HTTP/1.1 200 OK {"resultCode":0,"msg":"","content":[]} ``` 无需认证直接查看图像： `http://britain.oss-eu-west-1.aliyuncs.com/EKDB_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/2020xxxxxxxxxx.jpg` #### 4.2 升级机制存在缺陷 有些设备需要通过APP升级，比如APP联网下载固件，再通过蓝牙等协议传输给设备。如果APP未对升级包安全校验就会存在固件被篡改的风险。 #### 4.3 设备内存破坏漏洞 通过APP端的数据构造和变异可以挖掘一些设备内存破坏漏洞，在NDSS 2018的一篇论文 [IOTFUZZER: Discovering Memory Corruptions in IoT Through App-based Fuzzing](http://web.cse.ohio-state.edu/~lin.3021/file/NDSS18b.pdf)中，几位作者提出了一种新的名为IOTFuzzer模糊测试框架，就是从APP的角度出发，以寻找IOT设备中的内存破坏漏洞，可惜的是IOTFuzzer并没有开源，笔者至今也未找到相关工具。 论文作者通过fuzz APP测试的一些设备： ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FnyyYp2JwJq3yOlnR0BGQ%2Fimage.png?alt=media\&token=e9750db5-4267-412b-b00c-dd1ba7308b4d) ### 五、APP加固 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FjIFFmuF80bCHTem6Vt0Z%2Fimage.png?alt=media\&token=dd9b5399-aa7b-42c0-ba06-6785cccaabd4) 从开发源头开始每个环节都把好安全是治标又治本的方法，在代码编写时应注意数据存储、防注入、防逻辑漏洞、通信加密等问题。奈何理想很丰满，现实很骨感。虽然安全开发慢慢提上日程，但代码bug在所难免，所以从防“讨厌”的安全研究者出发，为提高门槛，对APP做一些混淆加密。加固的思路一般是静态反逆向，动态反调试。 由于IOS App Store有严格的审查机制，有时代码混淆无法通过，所以下面以Andriod为例，对加固作简单介绍。 #### 5.1 静态反逆向 * 代码混淆 代码混淆是通过对源代码压缩、混淆、优化和预检等操作，提高代码阅读的难度。 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2F58xYgX6E0t0vYxiBIafn%2Fimage.png?alt=media\&token=235ebd5f-5540-4fc9-98ca-f30bbb88dfc4) * 程序加壳 程序加壳是对原始App中的dex文件加密，并外包一层壳，将App核心代码隐藏。 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FPHAkjqo71XcL8jhgGI1t%2Fimage.png?alt=media\&token=68eb462b-dad9-4d0d-98b9-d1d79fdcee85) #### 5.2 动态反调试 * 代码抽取 代码抽取是对dex文件中所有类及方法函数内容抽取、加密和隐藏，单独加密后存放在apk中特定文件内。 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FftGdy76fj2eGRhTqi7zp%2Fimage.png?alt=media\&token=abb5587a-4226-4fce-9723-9e44281620e9) * DVMP虚拟机 DVMP(dex virtual machine protect)使用全新的指令“语言”替代原有Andriod虚拟机的指令集，在程序类、方法保护上更近一部，实现指令集层面保护。 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FoyEUF6oCSEWZmjmhHLNd%2Fimage.png?alt=media\&token=e27830b7-6d14-4a79-a6fa-8e8d83b1d1b0) 由于本篇主题侧重漏洞研究，所以并没有阐述加固细节和相关工具使用，下文介绍研究一般流程和相关工具。 ### 六、流程和工具 #### 6.1 流程 漏洞研究方法基本类似，无非逆向、审计、调试、抓包分析和Fuzz等，从APP角度亦然，一般从数据、认证、交互和通信几个方面寻找漏洞点。 * (1) 逆向分析获得APP代码，梳理APP大致功能，此时可以对APP做一些常规测试； * (2) 抓取通信数据，看是否加密，认证过程是否有完备，找回重置功能是否有逻辑问题，模拟APP通信数据与设备(云)交互，通过重放找寻一些通信中的缺陷； * (3) 利用测试工具或APP端Fuzz变异数据，寻找设备端的一些内存破坏漏洞。、 #### 6.2 反混淆 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FUmbjFQbB39HotyO8vqli%2Fimage.png?alt=media\&token=ecff771a-1361-4fac-b200-b63136c6be81) 上文简介了加固方法，回到研究者角度，自然需要和这些保护机制作对抗，实际上破解保护已经成为APP逆向的主要任务，可以借助JEB、Jadx等工具，这里就不详细展开。 JEB反混淆效果 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FGfiny5vViEqnL4hfutxj%2Fimage.png?alt=media\&token=9ee9f8d6-22ea-4697-95fc-7b2f4575557b) Jadx反混淆效果 ![](https://1174461437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlLEV5Rrf0TFHD0Ld3R7q%2Fuploads%2FPleDx8YTqnNfA5BAhtJ3%2Fimage.png?alt=media\&token=5faf6213-4008-4773-98d6-7c97ba719f50) ### 七、工具 IDA、Ghdria和JEB之类的常规工具就不提了，下面给出一些常用工具。 * [frida](https://github.com/frida/frida) frida是一个轻量级别的hook框架和代码插桩工具，Andriod和iOS研究必备。 * honggfuzz Google fuzz框架，之前介绍过，在二进制和协议测试都很有效。 * [FART](https://github.com/hanbinglengyue/FART) Andriod ART环境下基于主动调用的自动化脱壳方案 * [deoptfuscator](https://github.com/Gyoonus/deoptfuscator) Andriod反混淆工具 * [passionfruit](https://github.com/chaitin/passionfruit) 基于frida开发，逆向必备，可以很容易看到第三方应用的各类信息。 * [AndroidShell](https://github.com/longtaoge/AndroidShell) Android加壳工具，当外壳运行的时侯，把真正的程序解密出来，动态加载到系统中。 ### 八、总结 本文是IOT漏洞研究系列的最后一篇，主要从APP应用角度分析一些IOT网络中可能存在的漏洞风险，由于侧重设备，对于一些常见的APP漏洞点，比如Andriod webview等并没有涉及。如果之前是(移动)软件漏洞研究人员，不太熟悉IOT硬件固件，从化归思维出发，设备APP会是一个很好的切入点。