反正技术长文也没什么人看,图片全没了,换编辑器了,摆烂了,看原文吧🐶
执行摘要
-
Team82 正在发布我们对 Unitronics 集成 PLC/HMI 的研究细节,该研究始于去年秋天披露的多起关键基础设施攻击之后,特别是针对美国和以色列的水处理设施。
-
据称 与伊朗有关的 CyberAv3ngers对此次袭击负责。
-
我们开发了两种工具,现免费提供。这些工具可用于从 Unitronics 集成 HMI/PLC 中提取取证信息。
-
第一个工具
PCOM2TCP
允许用户将串行 PCOM 消息转换为 TCP PCOM 消息,反之亦然。PCOM 是 Unitronics 的专有通信协议。 -
第二个功能称为
PCOMClient
,它使用户能够连接到他们的 Unitronics Vision/Samba 系列 PLC,对其进行查询,并从 PLC 中提取取证信息。 -
本博客描述了我们的研究设置、我们解压专有 PCOM 协议的过程,以及促使我们开发这两种工具从设备中提取信息的必要性。
-
作为这项研究的一部分,我们发现了两个新的漏洞CVE-2024-38434和CVE-2024-38435。Unitronics 建议所有用户升级到 v9.9.1
介绍
去年 11 月针对 Unitronics 集成 HMI/PLC 的攻击表明,与伊朗有关的 CyberAv3ngers 等 APT 行为者仍然意图引起人们对关键基础设施网络安全的恐慌和恐惧,并希望通过传播宣传来获取政治利益。
此次攻击针对的是以色列和美国水处理设施中的设备,并展示了该组织对这些以色列制造的 HMI/PLC 的访问权限。虽然水处理和水质没有受到影响,但该组织确实破坏了 Unitronics 设备,并留下一条消息,威胁以色列制造的其他类似技术。
CyberAv3ngers 利用了 Unitronics Vision 和 Samba 系列产品当时没有 PCOM 密码保护这一事实。攻击者可以使用 Unitronics VisiLogic 工程工作站软件远程连接和控制设备,将恶意项目下载到 PLC 中,从而破坏 PLC。
被毁坏的 Unitronics 集成 HMI/PLC。(来源:Unitronics)。
由于攻击影响了全球数百台设备,我们决定研究和开发一种工具,让用户能够从 Unitronics Vision/Samba HMI/PLC 中提取取证信息。从我们的工具(我们今天在 GitHub 页面上免费提供的两种工具之一)中提取的信息可用于识别访问这些设备的攻击者,此外还可以从设备中提取关键信息,以帮助在攻击期间保存取证信息。
开发我们的工具需要我们研究和了解 Vision/Samba HMI/PLC 使用的专有 PCOM 通信协议。PCOM 协议的唯一现存文档是由一组研究 Unitronics 设备的研究人员创建的(《SCADA 协议的全面安全分析:从 OSINT 到缓解措施》,Luis Rosa 等人,2019 年)。
我们开发的第一个工具名为 PCOM2TCP,它使用户能够将串行 PCOM 消息转换为 TCP PCOM 消息,反之亦然。第二个工具名为 PCOMClient,它使用户能够连接到他们的 Unitronics Vision/Samba 系列 PLC,对其进行查询,并从 PLC 中提取取证信息。
没有以太网端口,没问题
了解 PCOM 协议以及可以从 Unitronics 设备中提取哪些工件的第一步是购买一台。有了物理设备,我们就可以连接并与之通信。所以我们买了一台设备,把它运到我们的办公室,然后耐心等待开始我们的研究。然而,当它终于到达时,我们发现我们搞砸了:我们的设备没有以太网端口。默认情况下,Unitronics Vision 系列设备不附带以太网连接,只有串行连接;以太网卡单独出售。这意味着我们无法连接到我们的设备。
Unitronics Vision 570 PLC 端口。
为了解决这个问题,我们必须阅读 Unitronics 文档以了解RJ11连接器的引脚排列。为了让 PLC 使用串行通信,Unitronics 使用 RJ11 连接器实现了串行端口,并以RS232作为通信标准。我们的目标是创建一条定制电缆,连接 Vision PLC 和我们的笔记本电脑(使用笔记本电脑上的 DB9 连接器)。从 Unitronics 文档中,我们发现 RJ11 端口具有以下布局:
Unitronics RJ11 端口引脚排列(RS232 标准)
考虑到这个引脚排列,我们的目标是采用 RJ11 电缆并对其进行修改,使其另一端具有 DB9(公头)连接,这样我们就可以使用 RJ11 端连接到 PLC,并使用 DB9 连接连接到我们的笔记本电脑。我们再次在网上查找有关 DB9 引脚排列的文档,如下所示:
DB9 M 引脚排列。
观察了两个引脚排列后,我们要做的就是将 RX 引脚连接到 TX 引脚,反之亦然,以及连接地线,如下所示:
将 RX 连接到 TX、将 TX 连接到 RX、将地连接到地。
通过创建这条定制电缆,我们能够创建一个功能齐全的设置,将 Unitronics V570 连接到我们的实验室笔记本电脑。
我们的设置,将 PLC 连接到我们的笔记本电脑。
这样,我们就能够使用 Unitronics 的 VisiLogic 工程工作站 (EWS) 连接到我们的 PLC。我们从 Unitronics 网站下载了 EWS,安装了它,并将其连接到我们的 PLC。
使用 VisiLogic 连接到我们的 PLC。
接下来,我们的目标是在 PLC 和我们的 EWS 之间创建一个中间人 (MiTM) 设置。这意味着我们可以窃听这两个端点之间的所有流量,以及修改我们选择的任何数据包。但是,由于我们使用了自定义电缆而不是以太网扩展卡,因此我们的 EWS 和 PLC 通过串行连接进行通信。通常这没有问题,因为 Wireshark 提供了嗅探串行通信的功能。然而,在这种特殊情况下,这是不可能的,因为 EWS 在 Windows 上以独占模式打开了串行端口,这意味着没有其他进程可以打开此端口。因此,Wireshark 无法连接并嗅探此端口。这促使我们开发了第一个工具PCOM2TCP
来绕过此限制。
我们无法嗅探 EWS 和 Vision 设备之间的流量,因为 EWS 以独占模式打开串行端口。
PCOM2TCP 工具说明
PCOM 通信协议允许 Visilogic EWS 使用两种连接方法之一连接到 PLC:串行或以太网。为此,Unitronics 以串行或 TCP 版本(使用 TCP/20256)实现了 PCOM 协议。在这两种情况下,都存在基本 PCOM 层,唯一的区别是在 TCP 连接中,基本 PCOM 数据包与 PCOM/TCP 层封装在一起。
这给了我们一个想法:如果我们无法使用串行连接创建 MiTM 设置,也许我们可以创建一个 Python 工具,将 PCOM 串行消息转换为 PCOM/TCP 数据包。这样,我们的 EWS 将使用 TCP/IP 而不是串行连接到我们的 Python 脚本,我们将数据包转换为串行 PCOM 并将其发送到 PLC。然后,我们可以使用 Wireshark 嗅探和监控流量(搜索 TCP/IP TCP 流),并修改 Python 脚本中的某些数据包。
我们的设置使用 PCOM2TCP,允许我们进行 MiTM 并嗅探 EWS 和 PLC 之间的流量。
PCOM 流量:PCOM 串行到 TCP
这对我们的研究来说是一个巨大的里程碑,因为它让我们最终开始调试并尝试解析 PCOM 流量。
了解 PCOM 通信协议基础知识
PCOM 协议的核心是由 EWS 发送的请求和 PLC 发送的响应组成。为了区分不同的命令/程序,PCOM 实现了一组广泛的功能代码(操作码),每个代码都有自己的功能和参数。这样,使用不同的操作码,EWS 就可以调用 PLC 中的不同请求和程序。
除了不同的功能代码(操作码)之外,Unitronics 还在 PCOM 协议中实现了两种不同的协议:PCOM ASCII 和 PCOM Binary。这两种协议实现了不同的操作码,这意味着为了完全理解 PCOM 协议,必须研究这两种实现。让我们分析一下:
首先,让我们看一下 PCOM 二进制请求/响应。在此协议中,每个数据包必须以魔术/硬编码字节序列(即字符串)开头/_OPLC
,后跟 ID、一些保留参数和操作码本身。二进制 PCOM 消息的完整结构可在此处看到:
PCOM二进制消息结构。
为了检查某条消息是请求还是响应,必须检查操作码的最高有效位 (MSB);如果它是 0,那么该消息就是请求,如果它是 1,那么该消息就是响应。
检查操作码 MSB 来确定请求或响应。
查看 PCOM ASCII 消息格式时,我们看到以下结构:
PCOM ASCII 格式。
与 PCOM Binary 不同,在 PCOM Binary 中,为了判断一条消息是请求还是响应,您必须检查命令操作码(在本例中为),而在 PCOM ASCII 中,请求和响应具有不同的魔法。如果是请求,则使用- Command Code
魔法,如果消息是响应,则使用魔法。/``/a
了解了 PCOM 协议的基础知识之后,我们开始构建基本的 PCOM 客户端,并在此过程中研究和发现未知的操作码。
PCOMClient:Unitronics 取证客户端
我们研究的下一步是实现一个功能齐全的 PCOM 客户端,这样我们就可以在它的基础上构建我们选择的任何功能代码/进程。这使我们能够测试不同的操作码、调试应用程序并尝试理解未记录的操作码。
我们的客户端允许用户连接到他们的 Unitronics PLC,提取其确切的版本、名称和类型,以及读取/写入其原始内存。除了所有基本功能外,我们还添加了一个用于添加新发现的操作码的界面。
在幕后,为了与 PLC 通信,Unitronics 实现了数十种不同的功能代码,每种代码都调用 PLC 内的不同功能。例如,为了请求 PLC 重播其名称,需要使用功能代码发送 PCOM 二进制请求0x0C
。一些操作码已经被之前研究过 Unitronics PCOM 协议的研究人员研究和记录(《SCADA 协议的全面安全分析:从 OSINT 到缓解措施》,Luis Rosa 等人,2019 年)。
为了构建我们的客户端,我们必须研究和了解 Unitronics 实现的不同功能代码。这个过程主要使用逆向工程以及对我们设法捕获的 Wireshark 数据包的协议分析来完成。
另一个有趣的操作码是0x42
,它允许用户重置Upload Password
机制。从 Unitronics 的用户手册中,我们发现操作员可以设置密码来保护他们的项目。操作员可以使用此密码锁定项目并阻止其他人阅读。我们发现此操作码可以以某种方式用于重置Upload Password
,并将此问题报告给 Unitronics,其编号为CVE-2024-38434。这是我们在研究中发现并向供应商披露的两个漏洞之一。
以下是 PCOM 协议中已知功能码的列表(重要提示:我们为每个操作码提供的描述只是我们对操作码的解释):
功能代码(请求/响应) | 描述 |
---|---|
0x01 / 0x81 | 读取内存 |
0x02 / 0x82 | 检查密码 |
0x0C / 0x8C | 获取 PLC 名称 |
0x10 / 0x90 | 查找资源 |
0x16 / 0x96 | 将资源索引转换为地址* |
0x1A / 0x9A | 刷新内存缓冲区 |
0x41 / 0xC1 | 写内存 |
0x42 / 0xC2 | 重置上传密码(CVE-2024-38434) |
0x4D / 0xCD | 读操作数 |
0xFF | 错误 |
ID(ASCII) | 获取 PLC ID |
UG(ASCII) | 获取 PLC 单元 ID |
GF(ASCII) | 获取 PLC 版本 |
提取取证证据
在对 Unitronics VIsion 系列生态系统以及 PCOM 通信协议有了相当深入的了解之后,我们回到了最初的目标:从受攻击的 PLC 中提取取证证据。经过进一步挖掘,我们发现了两种允许提取取证证据的方法,我们相信这两种方法可以用来更好地了解攻击,并包含有关设备和在设备上进行的操作的敏感信息。
VisiLogic 项目文件
我们发现的第一个证据来源是 VisiLogic 项目文件。每当工程师使用 VisiLogic(Unitronics EWS)连接到 Vision PLC 时,他们首先要构建一个项目。然后,使用这个项目,工程师可以设置 PLC、其操作、功能以及其 HMI 屏幕。使用这个项目,工程师可以完全控制 Vision PLC。
Unitronics VisiLogic 项目展示了 PLC 的功能。(来源:Unitronics)。
在后台,为了保存所有这些配置以及功能代码,EWS 将所有这些数据都存储在一个 zip 文件中,其中包含一个 Access DB 数据库(在 PLC 的内存中,此文件以使用硬编码密码的加密格式存储)。通过解析这个数据库(使用我们的 Access DB python 解析器)并在特定表中搜索特定字段,可以提取大量有关用户计算机和设置的有趣数据和取证信息,包括创建项目的完整路径(通常包含计算机的用户名)、攻击者的键盘布局(过去用于识别攻击者,即Mandiant 用于识别 APT-1)、与 PLC 的所有连接的完整日志等等。
项目的完整路径,保存在ProjectTable表中。
项目创建日期,保存在 ProjectTable 表中。
安装在计算机上的键盘布局,保存在 tblKeyboards 表中。
虽然项目文件包含大量取证信息,但文件本身并不总是存储在 PLC 上。在 Unitronics 生态系统中,将项目下载到 PLC 时,可以选择是否“刻录”项目文件。在 Unitronics 生态系统中,“项目刻录”是下载过程中的一项设置,它决定是否将项目文件下载到 PLC 并稍后可供上传。本质上,如果将项目下载到 PLC 而不进行刻录,用户将无法执行上传过程并在稍后从 PLC 中检索项目。创建此机制是为了让工程师“保护”他们的项目,并防止有权访问 PLC 本身的人简单地上传项目并访问项目。
Unitronics 实施的另一种保护机制允许工程师保护他们的项目,即设置“上传密码”,将执行上传程序的能力锁定为仅对知道所设置密码的人。虽然我们确实设法找到了绕过此密码的方法(绕过密码要求并允许我们在不知道密码的情况下上传项目),但如果项目没有被刻录,就无法从 PLC 读取任何内容。所有这些都已添加到我们的自定义 PCOM 客户端中。
在 Unitronics 攻击案例中,攻击者在执行下载程序时没有刻录项目。这意味着我们无法获得攻击者的项目,但是我们的工具仍然能够访问下载到 PLC 的旧项目(在攻击者覆盖之前),前提是该项目已被刻录。
PLC 工件:签名日志
在项目文件陷入困境后,我们继续在 PLC 内存本身上寻找取证证据。这时我们发现了 PLC 上存储的一个名为“签名日志”的工件。此日志包含用户与 PLC 执行的所有交互的列表。
提取此日志是一个漫长而繁琐的过程,但我们确实设法将其实现到我们的系统中PCOMClient
。使用我们的客户端,任何人都可以从他们的 PLC 中提取签名日志。
从受攻击的 PLC 中提取的签名日志。
在签名日志中,我们可以找到很多非常有趣的取证信息,包括连接到 PLC 的确切日期、下载到 PLC 的项目的完整路径、连接到 PLC 的计算机的用户名,以及有关计算机的信息,包括其操作系统、键盘布局等。
从签名日志中提取的攻击者使用的项目路径。
从签名日志中提取的攻击者使用的用户名。
从签名日志中提取的攻击者使用的连接日期。
从签名日志中提取的攻击者使用的键盘布局。
从签名日志中提取的攻击者使用的连接信息。
以下是可从 Unitronics Vision 系列 PLC 中提取的大部分取证证据的列表:
取证证据 | 位于签名表内 | 位于项目文件内 |
---|---|---|
项目路径 | 是的 | 是的 |
电脑用户名 | 是的 | 否(可能在路径中) |
项目创建日期 | 不 | 是的 |
PLC 连接日期 | 是的 | 是的 |
电脑键盘 | 是的 | 是的 |
PLC 连接字符串 | 是的 | 是的 |
项目图片 | 不 | 是的 |
项目功能 | 不 | 是的 |
总结
Team82 对 Unitronics 集成 HMI/PLC 的广泛研究始于去年年底披露的针对众多水处理设施和其他关键基础设施的攻击事件。一个与伊朗有关的组织利用这些设备上的弱身份验证来访问和破坏它们。
虽然没有发现对水质造成的影响,但这些攻击确实达到了该组织的目的,即传播混乱并让人们对这些地区关键基础设施的网络安全产生恐惧。
这促使我们更深入地研究这些事件和所涉及的 Unitronics 控制系统。直接针对工业控制系统的攻击仍然相对罕见,因此当出现此类问题时,我们的团队希望了解原因并提供解决方案,以打造更安全的生态系统。
当我们研究 Unitronics 为设备和网络之间的通信而开发的专有 PCOM 协议时,很明显我们必须开发自己的工具,不仅要了解协议的内部工作原理,而且还要帮助在未来发生攻击时提取取证信息。
今天,我们免费提供这两种工具。PCOM2TCP 使用户能够将串行 PCOM 消息转换为 TCP PCOM 消息,反之亦然。第二个工具称为 PCOMClient,使用户能够连接到他们的 Unitronics Vision/Samba 系列 PLC,对其进行查询,并从 PLC 中提取取证信息。
您可以提取的信息为了解攻击者在设备上的行为提供了宝贵的线索,包括连接日期、键盘布局、文件系统路径等等。我们敦促用户下载每一个并了解它们的分析和取证能力。
原文链接:
https://claroty.com/team82/research/from-exploits-to-forensics-unraveling-the-unitronics-attack
原文始发于微信公众号(独眼情报):从漏洞利用到取证:揭秘 Unitronics 攻击事件
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论