> For the complete documentation index, see [llms.txt](https://wokough.gitbook.io/iot-firmware-aio/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wokough.gitbook.io/iot-firmware-aio/wiki/lou-dong-wa-jue-app-ying-yong.md).

# 漏洞挖掘—APP应用

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

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

### 一、APP角色

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

![](/files/CDNTMIZehVml4gFKCfaY)

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

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

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

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

### 二、APP本地数据泄漏

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

![](/files/Bxmt7gE1SR6zpMU2ErSM)

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

* 数据库信息泄漏

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

![](/files/W0De9XDEL4abkLTeKIjm)

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

![](/files/ZOZIhSXn2ikpzmOVbwwz)

* 调试信息泄漏

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

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

![](/files/br8mXOfMrzQb446oAa9z)

![](/files/wAhNWok8ORdwBlqI4ioL)

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

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

* 通信未加密

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

* 认证逻辑错误

![](/files/na9bllMwvogeDPj7pI0c)

一些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测试的一些设备：

![](/files/sW3ZAOIuTymkhYbVb4mP)

### 五、APP加固

![](/files/kUJqlsL1BZxDsemDRsAG)

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

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

#### 5.1 静态反逆向

* 代码混淆

代码混淆是通过对源代码压缩、混淆、优化和预检等操作，提高代码阅读的难度。

![](/files/Z4Oa65AR2khltg2xcovj)

* 程序加壳

程序加壳是对原始App中的dex文件加密，并外包一层壳，将App核心代码隐藏。

![](/files/6m9lpMGRgSZGp8lfSCax)

#### 5.2 动态反调试

* 代码抽取

代码抽取是对dex文件中所有类及方法函数内容抽取、加密和隐藏，单独加密后存放在apk中特定文件内。

![](/files/gAm6jJrBesEQRQdZ5tCI)

* DVMP虚拟机

DVMP(dex virtual machine protect)使用全新的指令“语言”替代原有Andriod虚拟机的指令集，在程序类、方法保护上更近一部，实现指令集层面保护。

![](/files/zaIwXObtMTMzFt7nUPoB)

由于本篇主题侧重漏洞研究，所以并没有阐述加固细节和相关工具使用，下文介绍研究一般流程和相关工具。

### 六、流程和工具

#### 6.1 流程

漏洞研究方法基本类似，无非逆向、审计、调试、抓包分析和Fuzz等，从APP角度亦然，一般从数据、认证、交互和通信几个方面寻找漏洞点。

* (1) 逆向分析获得APP代码，梳理APP大致功能，此时可以对APP做一些常规测试；
* (2) 抓取通信数据，看是否加密，认证过程是否有完备，找回重置功能是否有逻辑问题，模拟APP通信数据与设备(云)交互，通过重放找寻一些通信中的缺陷；
* (3) 利用测试工具或APP端Fuzz变异数据，寻找设备端的一些内存破坏漏洞。、

#### 6.2 反混淆

![](/files/0l3VoCq1LwXQz57zHRFv)

上文简介了加固方法，回到研究者角度，自然需要和这些保护机制作对抗，实际上破解保护已经成为APP逆向的主要任务，可以借助JEB、Jadx等工具，这里就不详细展开。

JEB反混淆效果

![](/files/UN2sIWkPOW6A5imQXMSt)

Jadx反混淆效果

![](/files/ZmUZqSjtpiRXGPZL5DjN)

### 七、工具

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会是一个很好的切入点。