漏洞挖掘—APP应用

Last updated 2 years ago

漏洞挖掘—APP应用

APP应用比浏览器有更好的交互体验，比PC端应用更加便捷，作为IOT设备控制手段愈发流行。APP为IOT生态提供了丰富的接口和灵活的交互，许多传统设备厂商也逐步从web管理投入APP应用的怀抱。与此同时，更多接口带来更多风险，代码重新实现也带来更多漏洞隐患。

手机也是智能设备，当然也属IOT网络重要环节，但由于手机(APP)安全已自成体系且资料全面，所以不作为本文侧重点。本篇旨在从APP在IOT网络中所处角色出发，阐述可能存在的漏洞点，并给出一些加固建议，最后梳理研究大致流程，推荐几款研究工具。

一、APP角色

首先来看移动APP在IOT网络的中可能承担的角色，这是一个比较简单的模型，其中设备、APP和云端服务组成一个三角，APP的角色有：

和设备通信，控制设备行为、向设备读写数据和升级操作等。
和服务端通信，与云端同步(读写)数据、指令和获取升级等操作。

从APP在网络中的位置出发，可以预见从其出发可能找到的漏洞点，即

(1) APP本身存在漏洞，比如本地数据读写等；
(2) APP与设备(云端)通信漏洞，比如弱加密，甚至未加密，认证逻辑等；
(3) APP与设备通信触发设备漏洞，比如越权，内存破坏，拒绝服务等。

其中(2)和(3)的主要区别在于，(2)是APP和设备双向漏洞，即通信和协议问题，(3)可能只有设备存在漏洞，而APP作为一个漏洞发掘的突破口，两者的研究方法有所差异，下文将逐一介绍。

二、APP本地数据泄漏

从APP安装运行环境出发，其与本地接口的交互和对本地数据的读写是重要的漏洞挖掘点。

有些APP会存储一些诸如用户名、认证token等个人敏感信息，以便后续调用，如果这些信息未加密存储则有信息暴露风险；有些APP还会存储设备日志和调试未加密信息，这些信息往往成为漏洞挖掘的重要依据。比如在某智能门锁APP中就存在此类数据泄露问题：

数据库信息泄漏

该门锁Andriod APP在/data/data/com.belwith.hickorysmart/databases目录下存储SQLite的未加密数据信息，这些都是用户远程控制门锁设备的关键信息，在退出重启APP后，这些信息任然存在：

在该门锁iOS APP中同样存在类似问题，目录/private/var/mobile/Containers/Data/Application/3CAC91D1-872C-4F96-9460-A93F770AC42D/Library/Caches/com.belwith.HickorySmart下存在未加密远程开锁信息：

调试信息泄漏

该门锁Andriod APP在HickorySmartLog/Logs/SRDeviceLog.txt的调试日志中明文存储所有以蓝牙方式进行的联网的API服务和门锁连接记录。该日志文件存于SD卡中，无需高权限就可任意访问：

通过该日志内容果然发现了API访问控制漏洞，即可用其它用户身份来控制门锁，和之前特斯拉“串车”事件类似。

三、APP与设备(云)通信问题

通信问题比较常规，也容易发现，一般就是加密认证存在缺陷。

通信未加密

IOT设备的运算性能普遍不高，一些厂商为性能和成本考虑在通信中使用弱加密甚至直接明文通信，造成了很大的安全隐患。

认证逻辑错误

一些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中，几位作者提出了一种新的名为IOTFuzzer模糊测试框架，就是从APP的角度出发，以寻找IOT设备中的内存破坏漏洞，可惜的是IOTFuzzer并没有开源，笔者至今也未找到相关工具。

论文作者通过fuzz APP测试的一些设备：

五、APP加固

从开发源头开始每个环节都把好安全是治标又治本的方法，在代码编写时应注意数据存储、防注入、防逻辑漏洞、通信加密等问题。奈何理想很丰满，现实很骨感。虽然安全开发慢慢提上日程，但代码bug在所难免，所以从防“讨厌”的安全研究者出发，为提高门槛，对APP做一些混淆加密。加固的思路一般是静态反逆向，动态反调试。

由于IOS App Store有严格的审查机制，有时代码混淆无法通过，所以下面以Andriod为例，对加固作简单介绍。