漏洞挖掘—无线协议

Last updated 2 years ago

漏洞挖掘—无线协议

IOT模型一般分为感知层、传输层、应用层，本篇将探讨IOT漏洞研究中传输层的协议分析。当然由于研究角度不同也会出现四层、五层的分类模型，但从整体脆弱性作漏洞风险分析，无非是设备终端、管理软件(APP/Browser)、服务(云)平台三个端点，以及这三个点相互的数据传输。

三个端点通信的模块是接口，接口的连线就是通信协议，接口和连线都会有漏洞隐患，也是本文讨论的主题，web协议之前已经单做讨论，这里不再赘述，下面主要从“通用”协议、“专用”协议和“专有”协议三个方面作漏洞分析。由于笔者词穷，并没有想到好的标题表达自己的分类方式，而且也仅限个人想法并非权威，所以都打上引号。

一、“通用”协议

这里的“通用”协议指的是不仅在IOT上使用的一般网络协议，可以是有线也可以是无线。由于这些协议的研究手法比较通用，这里只作简单介绍。

SSH(Secure Shell)是大家最熟悉的远程管理协议之一，许多设备都提供了该接口。SSH最大的隐患当然是弱口令爆破攻击，下面几种协议亦然，当然，除了爆破认证绕过也是此类协议漏洞挖掘的重要方向。由于实现代码已经比较成熟，设备存在SSH漏洞案例不多，但也并非全然没有安全隐患，研究时可以作一些协议上的fuzz。

Telnet

Telnet被认为是SSH低配版，安全性也较低。研究者一般在漏洞利用中会打开telnetd服务获取shell，Telnet协议比较简单，可以利用或自己开发一些fuzz工具对设备进行测试。

FTP/SMB在设备中也比较常见，也有些溢出漏洞的案例，通过二进制危险函数审计或者借助fuzz工具一般很快可以定位。

SNMP

SNMP如果实现不当，有敏感信息泄露的隐患，甚至可以直接控制设备。比如前几年的某网关设备，由于代码中没有正确处理community认证，导致任意community均可以通过认证，直接使用snmpget命令发送 SNMP GET请求，并指定任意字符串作为community均可通过认证。

snmpget -v 1 -c public $IP iso.3.6.1.2.1.1.1.0
snmpget -v 1 -c '#Stringbleed' $IP iso.3.6.1.4.1.4491.2.4.1.1.6.1.1.0
snmpget -v 1 -c '#Stringbleed' $IP iso.3.6.1.4.1.4491.2.4.1.1.6.1.2.0

(SSL/Ipsec) VPN

边界和防护设备一般会提供VPN功能，尤其疫情期间，远程办公需求不断增加，在零信任还没普及落地前VPN仍是不二之选。有些厂商会将其集成到web中，方便使用的同时也带来不少安全隐患。比如某边界设备由于sslvpn功能实现不当造成登录等敏感信息泄漏问题。

import requests

r = requests.get('<https://sslvpn/dana-na/../dana/html5acc/guacamole/../../../../../../etc/passwd?/dana/html5acc/guacamole/>')

print r.content

对于这些协议除了上述专用测试工具以外，研究中还会使用到一些集成工具或fuzz框架，以sulley(不再更新)为代表，大致思路都差不多，比如boofuzz，kitty，或是比较新的Fuzzowski等，这些工具文末会作介绍。

二、 “专用”协议

所谓“专用”协议就是一般只在设备上采用，即之前章节提到的IOT无线电研究范畴。由于篇幅限制，下文重点介绍这些协议常见的攻击方式和漏洞点，对协议细节不再赘述。

2.1 WiFi

WIFI是一种标准，且PC上也广泛使用，但作为无线路由的重要功能点，设备wifi模块中也可能存在的一些协议漏洞。爆破和中间人攻击最为常见，此外还有其他协议漏洞点。

Krack

密钥重装攻击(Key Reinstallation Atacks，即Krack)，该攻击对加密安全构成理论性的威胁，某些条件下，可以恢复用户明文数据、实施重放攻击、或者会话劫持。

攻击者与station完成四次握手，但不转发四次握手的第四帧Msg4给AP。此时station认为四次握手完成，开始加密并发送数据，AP会重传Msg3，station收到重传的Msg3后重装会话密钥PTK，重置报文序号，重置密钥流，重新开始加密数据。

Kr00k

Kr00k是2020年2月份RSA大会上披露的一个漏洞CVE-2019-15126，由芯片驱动实现问题造成，主要影响Broadcom和Cypress网卡。

其核心漏洞点是在解除客户端关联后，其PTK会被置零，但是WiFi芯片会继续用置零的PTK发送缓冲中剩余的无线数据，攻击者收到这些数据后使用全零的PTK即可解密。

2.2 RFID

RFID(Radio Frequency Identification)，即射频识别，是自动识别技术的一种，生活中的各种智能卡和RFID技术关系密切。说到RFID，一般都会提起现在应用广泛的NFC(Near Field Communication)近场通信，NFC可以看作是RFID的子集，物理层、协议层遵循RFID标准，只是应用层协议不同。

RFID涉及的通信基础较多，以下是RFID常用的几种攻击方式。

嗅探攻击

伪造数据越权读写

存储数据篡改

攻击中间件和后端系统

除此之外还有其他的一些攻击手段，比如频率干扰等，这里不再一一列举。

2.3 Bluetooth

蓝牙是IOT设备中常用的传输方式，现在的智能家庭网除了使用WIFI，蓝牙传输也是重要手段。蓝牙这个名称十分有趣，来自十世纪一位丹麦国王Harald Blatand，Blatand在英文里可以被解释为Bluetooth，因为国王喜欢吃蓝梅，牙龈每天都是蓝色的而得名。由于蓝牙(BLE)实现功耗逐步降低，包括手机在内的许多设备都默认打开，进一步增加了安全隐患。

BleedingBit

BleedingBit由Armis的安全研究人员发现，漏洞存在于德州仪器生产的BLE芯片中，影响Cisco、Meraki、Aruba等多家公司设备。BleedingBit包括BleedingBit RCE(CVE-2018-16986)和BleedingBit OAD RCE(CVE-2018-7080)两个漏洞。

BleedingBit RCE

首先发送正常广播信息，这些信息被接收并存储到目标设备中；继续发送恶意数据包，数据包特定头信息置位改变，从而触发漏洞。

BleedingBit OAD RCE

利用自己修改过的固件覆盖原先的系统，从而控制目标设备。

BIAS

BIAS(Bluetooth Impersonation AttackS)，即蓝牙冒充攻击。Bluetooth BR/EDR中被发现了一些严重的安全漏洞，包括缺乏强制相互身份认证、角色转化过度轻松、认证过程降级等。攻击者利用该漏洞可以打破标准适配设备的蓝牙安全机制，最后可以在安全连接建立后仿冒已配对设备发送数据。从本质上说，BIAS攻击是利用了蓝牙设备如何处理长期连接的漏洞。

2.4 zigbee

ZigBee是比较新的无线通信技术，适用于短距离设备之间数据传输。Zigbee与蓝牙相比能建立更大的网络，功耗比起wifi相对要低不少，所以经常在家庭、工厂等应用场景使用。

ZigBee协议分为物理层、MAC层、网络称和应用层4层:

提供3个等级的安全模式：

非安全模式：不采取任何安全服务，容易被窃听；
访问控制模式：通过ACL限制非法节点；
安全模式：采用AES 128位加密通信。

Zigbee常见攻击方式：

数据窃听

当ZigBee使用非安全模式，也就是其默认安全策略时，对传输数据将不作加密，所以可以通过嗅探窃听到传输数据。

密钥攻击

在密钥传输过程中，可能会以明文形式传输密钥，因此有被窃取密钥的风险。

目前针对ZigBee的攻击，主要还是窃听和密钥安全方向，比较流行的研究工具有KillerBee，可实现抓包、分析和发包等功能。虽然ZigBee没有WiFi、蓝牙那样流行，但其安全问题仍不容忽视。

2.5 MQTT

MQTT(Message Queuing Telemetry Transport，消息队列遥测传输协议)是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议轻量、简单、开放和易于实现的，这些特点使它广泛使用于卫星链路通信传感器、医疗设备、智能家居、及一些小型化设备中。

MQTT可能存在的攻击点：

使用匿名访问规则则，可能导致信息泄漏或者被恶意攻击者发起恶意指令；
数据未开启加密，可能导致中间人攻击或泄漏用户名/密码；
弱口令问题，传统的安全隐患；
订阅端明文配置导致泄漏用户名/密码；
服务端软件缺陷，或者订阅端或服务端解析漏洞。

MQTT比较流行的安全测试工具有mqtt-pwn，集成扫描、爆破和利用等多种功能。

2.6 LoRaWAN

大家可能对loRaWAN协议相对陌生，LoRaWAN是一个开放标准，它定义了基于LoRa芯片的LPWAN技术的通信协议。LoraWAN相对于NB-IoT、蜂窝更加灵活，同时更节省成本，在智能城市、智能建筑、智能机场、智能工厂等适用场景潜力巨大。

新的协议实现必然伴随新的安全风险，LoRaWAN母公司在Github上开源的LoRaMac-Node项目被爆出存在漏洞(CVE-2020-11068)，该项目用于实现LoRaWAN节点协议栈，漏洞影响在4.4.2-rc.1至4.4.4之前版本。

漏洞发生在入网流程中，接收数据时发生溢出，可对正在入网的设备造成危害。

对于LoRaWAN的研究除了从上面的源码角度，针对特定设备还可以利用直接从数据分析，协议fuzz等手段。比如可利用LoRa Craft一些脚本作数据解析。

>>> import binascii
>>> from layers.loraphy import *

>>> pkt = "18 31 10 40 ad 15 00 60 00 00 00 03 ca fe ff ff ff ff ff ff ff ff ff 6e 5a d7 0d 59 2e"

>>> l_pkt = LoRa(binascii.unhexlify(pkt.replace(" ", ""))
... )
>>> l_pkt.show()
###[ LoRa ]###
  Preamble  = 0x1
  PHDR      = 0x8311
  PHDR_CRC  = 0x0
  MType     = Unconfirmed Data Up
  RFU       = 0
  Major     = 0
  \\DevAddr   \\
   |###[ DevAddrElem ]###
   |  NwkID     = 0xad
   |  NwkAddr   = 0x600015
  \\FCtrl     \\
   |###[ FCtrl_UpLink ]###
   |  ADR       = 0
   |  ADRACKReq = 0
   |  ACK       = 0
   |  ClassB    = 0
   |  FOptsLen  = 0
  FCnt      = 0
  FPort     = 3
  DataPayload= '\\xca\\xfe\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff'
  MIC       = 0x6e5ad70d
  CRC       = 0x592e

2.7 UPnP

通用即插即用(Universal Plug and Play，简称UPnP)是由“通用即插即用论坛”(UPnP™ Forum)推广的一套网络协议。UPnP和上述协议不在一个层面，这里之所以单列出来是由于UPnP俨然成为危险协议，简单搜索如下所示：

可以看到UPnP漏洞问题层出不穷，笔者之前也有一篇文章对UPnP栈溢出漏洞作过分析。UPnP很多实现漏洞都出在SSDP(Simple Service Discovery Protocol)协议阶段，该协议通过UDP 1900端口提供网络内发现设备的机制。

除了溢出漏洞，可能还会存在注入(就是这么神奇，不然怎么称得上危险协议)，比如某路由器，攻击者可以在 SSDP M-SEARCH discover 包的Search Target域来实现命令注入。

三、 “专有”协议

“专有”协议是指只在某些或一类设备上使用的协议，一般由厂家自己实现，便于管理设备或设备间通信。此类协议较多，下文列举几个有代表性的抛砖引玉。由于下一篇会着重介绍APP内容，通过APP端研究协议漏洞在这里不再赘述。

3.1 TDDP

TDDP是基于UDP，用于调试的简单协议，该协议由TP-Link开发使用，在载荷中使用不同的消息类型来完成请求。

这种私有管理协议是我们探究的重点，因为往往越少使用到或者比较新的协议，实现代码出现漏洞的概率很大。从某使用该协议的设备看出该协议使用UDP 1040端口: 通过二进制审计发现一个内存拷贝函数，导致了一个溢出漏洞。

3.2 Modbus

Modbus是工业电子设备之间相当常用的连接协议，一般使用UDP502端口，是工控专有协议。因其协议简单而得到广泛使用，不同厂商设备协议实现可能不完全相同，但都是官方标准的变体。协议实现有差别，代码自然有出入，上文也提到，一旦一个标准出现很多实现代码，那漏洞几乎不可避免。

Modbus/TCP OPC Server 3.0.2之前存在堆溢出漏洞，可造成DOS或RCE，对于工控设备来说，DOS已经是致命的。

# POC 关键代码

#!/usr/bin/python

import sys
import socket

port=502

resp="\\x00\\x00"+"\\x00\\x00"+"\\x02\\x01"+"\\x00"+"\\x03"+"\\x02"+"\\x00\\x00" # break @ 40832c, dump edi, keep hitting f9 and watch (debug)

sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
sock.bind(("",port))
sock.listen(1)
conn,addr=sock.accept()

req=conn.recv(32)
conn.send(resp)
conn.close()

此类工控协议实现代码的安全性相对较弱，一般漏洞研究方法是协议fuzz，随着工控安全重要性提上日程，此类协议测试工具也是越来越多，除了传统的peach，boofuzz，还有针对性较强的smod框架等。

3.3 CLI (command line interface)

CLI是人与设备的交互接口，简单来说就是订制(限制)功能的shell，一般需要手动配置的设备，例如交换机、路由器、防火墙和一些专用设备会提供该接口。CLI一方面方便配置，另一方面也是避免提供高权限shell(RTOS可能没有shell)，所以一般会运行在低权限下。对于CLI的漏洞研究，我们要可以考虑：