记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

深入分析施耐德工控软件代码执行漏洞

2020-09-22 15:16

译文声明

本文是翻译文章,原作者 Soroush Dalili
原文地址:https://www.thezdi.com/blog/2020/9/9/performing-sql-backflips-to-achieve-code-execution-on-schneider-electrics-ecostruxure-operator-terminal-expert-at-pwn2own-miami-2020
译文仅作参考,具体内容表达请见原文

简介

在本文中,我们将为读者详细介绍Claroty Research团队的Amir Preminger和Sharon Brizinov是如何组合利用两个漏洞,来触发施耐德工控软件EcoStruxure Operator Terminal Expert的代码执行漏洞,从而在首届举办的Pwn2Own迈阿密大赛上赢得了2.5万美元奖金。这里所述的漏洞存在于施耐德电气公司的EcoStruxure Operator Terminal Expert软件的V3.1.100.267(SP 1)和之前版本(以前称为Vijeo XD)中。

实际上,攻击者只要引诱受害者打开(双击)EcoStruxure Operator Terminal Expert软件的项目文件,就能够利用默认配置发动相应的漏洞。这时,将触发应用程序上下文中的代码执行漏洞。总的来说,要想成功利用这个代码执行漏洞,需要组合利用下文描述的两个已知的漏洞。在本文中,我们先按照漏洞被发现的顺序来描述其详细信息,然后,给出组合运用这些漏洞并实现命令执行攻击所需的具体步骤。下面,我们先给出相应的演示视频的地址:https://youtu.be/SAmhljE9ZlE。

漏洞详情

EcoStruxure Control Terminal Expert是一个软件环境,用于设计人机界面(HMI)设备的图形用户界面。这些用户界面用于控制工业部署中可编程逻辑控制器 (PLC) 的操作。


图1 使用EcoStruxure Control Terminal Expert设计水流控制

在这里,所有的项目信息,包括各种设置和图形组件的信息,都会被保存到一个后缀为.VXDZ的EcoStruxure Control Terminal Expert项目文件中。实际上,.VXDZ项目文件就是一个存放各种文件的压缩目录,这些文件包含了程序还原项目所需的全部信息,以便工程师在以后可以继续工作。项目文件主要包括以下几种文件类型:

  • .db:SQLite3数据库文件,包括各种项目配置和设置。
  • .inf/.dat:JSON文件,用于存储数据和设置。例如,每个屏幕及其图形组件都是用JSON表示的。


图2 项目目录

当工程师打开项目文件时,压缩后的目录会被解压到一个临时目录下,路径如下所示:

C:\users\USER\AppData\Local\EcoStruxure\Temp\Schneider\CURRENT_VERSION_FULL\GUID\ProjectFiles

为了便于后面进行参考,我们将路径中与环境有关的组件用红色进行了相应的标记。另外,橙色显示的是GUID,它是在每次打开一个项目时随机生成的,即使这个项目之前已经打开过,亦是如此。这意味着这个路径无法提前预测,因为它取决于当前登录的用户、当前具体的版本名以及一次性随机生成的GUID。例如,下面就是我们打开一个项目文件时生成的一个有效的路径:

C:\Users\Administrator\AppData\Local\EcoStruxure\Temp \Schneider\Imagine3.1ServicePack\A1A98F0B-9487-41B3-84A2-2195ECAA11F5\ProjectFiles

此外,由于所使用的.NET zip库能够防止路径遍历企图,因此,只能提取随机生成的目录。

高级功能

与任何安全研究一样,我们需要尽量熟悉目标产品,并寻找那些可能没有被厂商深入检查过的复杂/先进功能。在把玩一阵EcoStruxure Control Terminal Expert后,我们发现了一个名为“Drivers”的功能。由于HMI是智能屏幕,呈现的数据是从工厂内的现场控制器收集的,所以必须具备查询功能,才能从PLC中获取数据。为了达到这个目的,施耐德提供了这样一种机制,即在项目中添加一个特定厂商的驱动程序,该驱动程序能够查询PLC以获取所需数据。我们知道,PLC有许多不同的型号,并且每个PLC都是通过自己的协议进行通信的。正因为如此,施耐德提供了许多的驱动程序,工程师可以根据他们需要集成的PLC自行选用。


图3 驱动程序是帮助HMI与所需控制设备(PLC)进行通信的组件。每个供应商及其特定设备(生态系统、协议栈等)都会提供许多不同的驱动程序。

有关特定项目文件使用的驱动程序的所有信息都位于一个名为DriverConfig.db的SQLite3数据库文件中,我们可以在项目目录中找到这个文件。我们在项目中添加了一个新的驱动程序,并检查了DriverConfig.db文件,发现其中有三个数据表:

  • Driver_X:空表。
  • Driver_X_Configuration_X:关于驱动程序的详细信息,如设置和元数据。这其中包括将要加载的驱动程序/模块名称。


图4 DriverConfig.db的内容

  • Driver_X_Equipment_X:关于HMI将与之通信的PLC的详细信息。其中,会包括与PLC相关的信息,如IP地址、型号、协议等。

其中,X代表驱动索引,由于我们只添加了一个驱动,所以在我们的例子中X为0。

通过.NET反射器,我们研究了相关的中间语言(IL)代码。我们发现,ModuleName字段实际上就是驱动程序DLL,它将从预定义的目录中进行加载,并处理HMI和PLC之间的通信。例如,如果我们有一个Rockwell Automation公司的PLC,我们就需要加载Rockwell公司相应的驱动程序——它通过EtherNet/IP+CIP协议与PLC进行通信。具体这里来说,需要加载驱动程序RockwellEIP.dll。为此,我们可以在该项目中的SQLite3数据库文件DriverConfig.db中的Driver_0_Configuation_0表的ModuleName列(字段)中加以指定。


图5 打开DriverConfig.db数据库的SQLite3查看器。ModuleName字段是驱动DLL的名称,它将被加载并处理HMI和PLC之间的通信。

Bug No. 1:通过路径遍历以获取DLL加载原语

为了更好地理解如何从DriverConfig.db数据库中提取信息,我们钻进了一个“兔子洞”:DriverConfig.db的连接。我们可以看到,这里的代码会查询并提取Driver_x_configuration_0表中的所有属性。然后,它将一个新的Driver对象实例化,并根据表中找到的相应值设置ModuleName字段。最后,它使用 ModuleName字段指定的路径加载相应的驱动程序DLL文件。

由于数据库(包括ModuleName字段)在我们的掌控之下,我们可以提供一个带有一些 ../../../字符的自定义ModuleName,以便从包含合法驱动程序的应用程序定义目录中导航出来。换句话说,我们能够从系统中加载任意DLL。


图6 我们将ModuleName字段改为../../../../claroty.dll,并使用procmon来监控系统。

然而,我们的攻击要想成功,必须满足下面两个条件:

  1. 如果一个名为driver.xml的文件没有出现在将要加载的DLL旁边,那么该DLL将不会被加载。
  2. 加载的DLL必须位于同名的目录中。

例如,如果我们将ModuleName改为Claroty,软件将进入预定义的驱动程序目录C:\Program Files\Schneider Electric\EcoStruxure Operator Terminal Expert 3.1 Service Pack\Drivers\Drivers,并寻找名为Claroty的目录,然后在该目录中搜索Claroty.dll和Driver.xml。如果这两个文件都找到了,就会加载里面的DLL,在本例中就是C:\Program Files\Schneider Electric\EcoStruxure Operator Terminal Expert 3.1 Service Pack\Drivers\Drivers\Claroty\Claroty.dll。

我们通过目录遍历实现了加载任意DLL的原语,这真是太棒了。但是,现在面临的问题是,我们如何才能提供自己的DLL,并使其运行呢?

好吧,在一定程度上说,我们还需要一个具有“任意文件写入”功能的原语。回想一下,我们的项目文件实际上就是一个包含文件和目录的压缩容器。也就是说,我们可以添加我们的文件和目录,然后再重新打包项目文件。当软件打开项目文件并提取所有文件时,我们添加的文件也会和其他文件一起被提取出来(并保存到临时目录中)。现在唯一的问题是:我们如何才能提前知道我们的文件会被解压到哪里,这样我们就可以在DriverConfig.db数据库下的ModuleName属性中设置相应的路径了。

下面,我们来总结一下:我们可以利用目录遍历漏洞来跳出正常的驱动程序的目录,同时,我们也可以在我们的项目文件被提取的时候,把一些文件和目录保存到硬盘上。但是,这些文件会被提取到一个随机的临时目录,我们无法提前预知,因为GUID每次都是随机生成的。

Bug No. 2:未进行严格安全过滤导致敏感数据信息泄露

我们对这些问题思考了很久,后来终于想到了一个解决方案。这个解决方案来自于一个意想不到的领域:SQLite的魔术!我们使用SQL pragma和SQL views数据库功能实时生成提取目录的完整路径。因此,我们可以让Terminal Expert软件直接找到我们的恶意DLL。我们之所以能够做到这一点,是因为Terminal Expert软件加载了我们所控制的项目文件中提供的数据库,并在没有对数据进行适当安全过滤的情况下查询表格。

什么是PRAGMA?

PRAGMA语句是一个依赖于具体实现的SQL扩展。它可以用来修改SQLite库的操作,或者查询SQLite库的内部(非表)数据。例如,pragma database_list命令将返回当前连接数据库的列表。

而SELECT file FROM pragma_database_list命令则会产生当前加载数据库的完整路径。


图7 显示当前加载的数据库的完整路径

这意味着我们可以在实时加载数据库之后生成数据库的完整路径。同样,这也是在将数据库保存到新建的、具有随机路径的临时目录之后完成的。现在,我们只需要一种方法来获取该查询的结果,并将其插入到软件即将查询的ModuleName属性中即可。

什么是视图?

为了达到上述目的,我们使用了数据库的一个不太常用的功能:视图。在数据库中,视图是一个存储查询的结果集。换句话说,视图就像一个动态创建的表,它是在客户端查询时实时生成的。当客户端查询视图时,数据库会查询为视图定义的实际表,并根据视图的设置对生成的数据进行重组,最后将完整的结果反馈给客户端——整个过程对客户端而言是透明的。从客户端的角度来看,似乎正在查询数据库中找到的常规表。


图8 数据库视图和我们实时影响查询的抽象方案

在我们的案例中,客户端是EcoStruxure Operator Terminal Expert软件,它查询驱动程序数据库以获取ModuleName属性,从而可以加载驱动程序DLL。我们的计划是在数据库被提取到临时位置后,实时修改ModuleName属性,最终让ModuleName保存我们数据库的实际路径。

1+2=RCE:组合两个漏洞,实现代码执行攻击

在项目文件中,我们需要准备一个名为ClarotyModule的目录,其中含有如下所示的两个文件:

  • Driver.xml
  • ClarotyModule.dll

我们将按照以下步骤准备DriverConfig.db:

  1. 我们将原来的Driver_0_Configuration_0表重命名为Driver_0_Configuration_0_ORIG。
  2. 我们将创建一个名为Driver_0_Configuration_0的VIEW表。

当客户端查询“原来的”表Driver_0_Configuration_0时,实际上会查询我们新建的VIEW表。在查询到ModuleName字段后,我们将VIEW表的内部处理设置为返回SELECT file FROM pragma_database_list的结果,并对其进行必要的修改,以构成正确的目录遍历语法。通过这种方式,我们可以在文件夹结构中向上、向下导航,直到抵达当前的临时目录中,也就是我们的payload DLL所在的位置。


图9 精心构造一个驱动数据库,使其实时包含我们DLL的路径。

最后,我们把所有的部分重新打包成一个VXDZ项目文件。当受害者双击该文件时,我们的DLL将被加载,之后,我们的代码也将被执行。


图10 POC运行时,会打开项目文件,并执行相应的代码

小结

在本文中,我们为读者详细介绍了如何利用EcoStruxure Operator Terminal Expert读取给定项目文件的方式,通过执行一些SQL backflips操作,诱导软件加载我们提供的DLL,从而在打开项目文件时发动任意代码执行攻击。施耐德电气公司已经修复了这些漏洞,并将其分配了相应的编号:CVE-2020-7494与CVE-2020-7496。


知识来源: xz.aliyun.com/t/8282

阅读:23821 | 评论:0 | 标签:漏洞 工控 执行

想收藏或者和大家分享这篇好文章→复制链接地址

“深入分析施耐德工控软件代码执行漏洞”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

❤人人都能成为掌握黑客技术的英雄❤

ADS

标签云