MQTT安全性研究

admin 2023年12月23日11:26:45评论28 views字数 3858阅读12分51秒阅读模式
## 引言

标题说研究,确实是很虚了,背景其实就是因为自己在对公司资产做渗透测试的时候,用扫描器发现了一个MQTT匿名登录的弱口令问题,对MQTT渗透测试的思路做了些搜索和整合。

总结下来,MQTT的渗透思路大概如下:

MQTT安全性研究

## MQTT介绍

那么什么是MQTT呢?MQTT (Message Queueing Telemetry Transport,消息队列遥测传输)是IBM公司在1999年设计的一套协议,它设计的背景和目的主要涉及到物联网(IoT)和传感器网络中的通信需求。具有以下几个特点:

1. 低带宽、不稳定网络环境:MQTT的设计考虑到设备可能在低带宽、高延迟或不稳定的网络环境中运行,因此它的设计目标之一是在这样的条件下能够高效地传输数据。

2. 轻量级:MQTT协议被设计为轻量级协议,旨在减少网络流量和系统资源的消耗。这使得它非常适合于资源受限的设备,如传感器、嵌入式系统等。

3. 发布/订阅模式(Pub/Sub):MQTT采用了发布/订阅模式,使得不同设备之间可以通过发布消息和订阅感兴趣的消息主题进行通信。这种模式使得设备之间的通信更为灵活和解耦。

4. 可靠性和实时性:MQTT提供不同级别的服务质量(QoS),允许根据需求选择消息传输的可靠性。这个特性使得在物联网环境中能够根据具体场景选择适合的消息传输质量。

5. 可扩展性:MQTT的设计允许在不同网络层级上进行扩展和应用,从局域网到云端的连接,都可以使用相同的协议进行通信。

https://blog.csdn.net/q7w8e9r4/article/details/132296955

### 几个渗透之前要理解的概念:

端口及服务
TCP端口8883和1883分别保留用于MQTT TLS和非TLS通信。

MQTT安全性研究

角色

先看下面三种角色的概念:

  • Publisher(发布者):发布者是消息的发送方。它连接到MQTT代理服务器,并将消息发布到指定的主题上。发布者发送PUBLISH消息,其中包含要发布的消息内容和指定的主题。
  • Subscriber(订阅者):代理服务器是消息的中转站。它接收发布者发送的消息,并根据订阅者的订阅情况将消息分发给对应的订阅者。代理服务器负责管理主题和订阅关系、处理连接和认证等操作。
  • Broker(代理):订阅者是消息的接收方。它连接到MQTT代理服务器,并订阅感兴趣的主题。订阅者发送SUBSCRIBE消息,指定要订阅的主题。当有新的消息发布到订阅者已订阅的主题上时,代理服务器将消息发送给对应的订阅者。

字太多,不爱看,可以直接看下图:

MQTT安全性研究

发布者将【消息和主题】发布给代理,订阅者可通过主题订阅相关消息。

主题及规则

  • Topic(主题):
可以把它理解为一类消息的标签,订阅者可以通过主题订阅一类消息。

他的写法类似于系统的文件目录的结构,如/area/department/device。父子主题关系举例,如area是department的父主题。

  • Topic Filter(主题过滤器):可以理解为主题的正则
  • +:匹配一个特定主题级别的任何项目,如/a/+/c/d 匹配的/a/b/c/d,或者匹配/a/x/c/d。
  • #:匹配特定主题级别及其所有子主题级别中的任何项目。/a/b/#匹配/a/b/目录下的所有主题。
  • $SYS主题:`$SYS`主题是一个特殊的主题层级,用于发布与MQTT代理(broker)相关的系统级别信息。

    $SYS/broker/version:发布MQTT代理的版本信息。$SYS/broker/uptime:发布代理运行时间的信息,例如运行时间的持续秒数。$SYS/broker/clients/connected:发布当前连接到代理的客户端数量。$SYS/broker/clients/disconnected:发布已断开连接的客户端数量。$SYS/broker/messages/received:发布代理接收到的消息数量。$SYS/broker/messages/sent:发布代理发送的消息数量。$SYS/broker/bytes/received:发布代理接收的字节数量。$SYS/broker/bytes/sent:发布代理发送的字节数量。$SYS/broker/heap/current:发布代理当前使用的堆内存大小。$SYS/broker/heap/maximum:发布代理可使用的最大堆内存大小。

QoS

QoS(Quality of Service):主要有三个级别,0,1,2;

QoS 级别0 - 最多一次传递 - 这是一种不可靠的消息传递机制,接收者不会发送任何确认,这意味着如果消息丢失,它就丢失了。
QoS 级别1 - 至少一次传递 - 这确保消息至少被接收一次。接收者应该对 PUBLISH 数据包发送 PUBACK 数据包作为响应。

QoS 级别2 - 确保精准一次传递 - 当消息的丢失或重复不可接受时使用。这是一个包含四个步骤的过程。

举几个场景帮助一下理解:

QoS 0:适用于丢失数据不会对系统造成什么影响的场景;
QoS 1:适用于可靠性较高的场景,但是重复发送不会有影响的场景,比如开阀门的指令,重复开几次,没有影响。
QoS 2:绝对可靠,消息不允许重复,如金融交易系统、控制系统的关键指令等等。

## 渗透测试

渗透测试这块其实看了一下午的姿势利用,大概总结已经如开篇那张图所示了。

MQTT安全性研究

工具介绍

图形化工具:mqttfx,测试过程中比较方便的工具;

脚本类工具:mqtt-pwn,这个很奇怪,安装一直没有成功过。不过我们可以根据 mqtt-pwn 中的漏洞利用手法来分析他的实现原理,这一点我们会在漏洞利用这个标题下做补充。

漏洞利用

可以写个脚本,筛选下方便匿名登录的机器
import paho.mqtt.client as mqtt

# 定义回调函数,用于处理连接成功和消息接收def on_connect(client, userdata, flags, rc):    print("Connected with result code "+str(rc))    # 订阅感兴趣的主题    client.subscribe("topic/interest")

def on_message(client, userdata, msg):    print(f"Received message: {msg.payload.decode()} on topic {msg.topic}")

# 实例化 MQTT 客户端client = mqtt.Client()

# 设置连接回调函数client.on_connect = on_connect# 设置消息接收回调函数client.on_message = on_message

# 连接 MQTT 代理client.connect("mqtt.example.com", 1883, 60)

# 在连接成功后会触发 on_connect 回调函数,然后会开始监听消息# 在接收到消息时会触发 on_message 回调函数

# 保持客户端持续运行,处理消息client.loop_forever()

mqttfx使用

配置ip及端口信息:

MQTT安全性研究

我们这里订阅所有主题,可以订阅到所有内容:

MQTT安全性研究

同样我们也可以作为pulisher发布消息:

MQTT安全性研究

mqtt-pwn
前面讲到了基于图形化工具 mqttfx 匿名(或实名)连接 mqtt broker,订阅主题和发布主题的方法。
剩下的 mqtt 的利用手法我们通过 mqtt-pwn 作补充,mqtt 的文档:
` https://mqtt-pwn.readthedocs.io/en/latest/`
我们直接来看 mqtt 的 plugins 部分:
  • 暴力破解:这一块不必多说,基于用户名、密码字典对 mqtt 服务进行连接尝试的方法。
  • 命令&控制:这个模块通过创建一种类似僵尸网络的网络,使客户端不直接与 broker 通信,而是和一个开放的代理通信。(纯翻译了模块描述,因为原理没看懂)
  • 连接到 broker:同样的,这个模块是对 broker 的连接,图形化界面也可以做到;
  • 信息收集:这一块是通过一些$SYS 主题的订阅,获取系统的相关信息,这一块我们前面也有讲到过;
  • ownTracker(GPS 跟踪):通过发布一个特定格式的 message 来获取安卓或 ios 上一个开源项目的定位。
  • 枚举:这个模块是通过一些 topics filter 的语法和字典结合使用,枚举出更全的 topics。
  • Sonoff exp: 这个模块是对一款专注于控制开关系统的攻击,去 jd 上搜了下,没想到还真的很多

MQTT安全性研究

以上就是 mqtt-pwn 对 mqtt 攻击方式的一些补充。
这个链接里有一些其它的攻击手法的补充,感兴趣的可以看看:https://blog.csdn.net/We8__/article/details/128441857

## MQTT安全实践

  1. 使用TLS协议。

  2. 不要使用客户端ID进行身份验证或主题访问控制。

  3. 使用随机生成的客户端ID。

  4. 不要向客户端公开$SYS/主题。如果需要,使用基于身份验证的访问控制。

  5. 不要信任设备发布的消息,根据数据的使用情况过滤已知攻击。

  6. 不要在设备固件中硬编码凭据。

  7. 设备(客户端)应仅对所需主题具有可见性或访问权限。

  8. 记录所有活动。

  9. 如果没有必要的话,最好将消息记录在`$SYS`/主题上,而不是发布到这些主题并使其可供订阅。例如,Mosquitto服务器有一个配置选项,可以在本地记录而不是发布消息到任何$SYS/主题。

  10. 启用并使用云服务提供商(AWS、Azure等)的安全通知,用于监测MQTT基础架构中的异常行为或潜在攻击,例如多次身份验证失败等异常行为。

MQTT安全性研究

原文始发于微信公众号(东方隐侠安全实验室):MQTT安全性研究

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年12月23日11:26:45
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   MQTT安全性研究http://cn-sec.com/archives/2230415.html

发表评论

匿名网友 填写信息