深入分析XINJE PLC Program Tool中的代码执行漏洞
2022-5-25 11:50:0 Author: www.4hou.com(查看原文) 阅读量:13 收藏

内容提要

Team82在工程设计工作站XINJE PLC Program Tool中发现了两个漏洞。

3.5.1版本受到这些漏洞的影响,其他版本也可能受到影响。

Team82于2020年8月开始着手披露工作。一年多后,XINJE终于在2021年9月承认了我们披露的漏洞。

当时XINJE拒绝与Team82合作,并要求我们停止与他们沟通。

在今天披露有限的细节之前,我们将协调披露政策的期限从90天延长到9个月,以帮助资产所有者遴选缓解措施。

攻击者能够利用一个精心制作的项目文件来触发这些漏洞。

可以将任意数量的项目文件写入一个项目文件以获得代码执行。

工程设计工作站是最关键的运营技术 (OT) 资产之一。工程师使用这些平台在工业控制系统的普渡模型较低级别配置和维护各种控制系统应用程序和设备。如果攻击者能够访问和使用工程工作站,那么,他们就可以将其作为攻击媒介来进一步破坏工业流程,进而可能危及公共安全或中断关键服务。

Team82在审查v3.5.1版本的XINJE PLC Program Tool的安全性的时候,发现了两个安全漏洞,分别为CVE-2021-34605和CVE-2021-34606)。不过,Team82仅对 v3.5.版本系列进行了测试,但我们相信,其他版本也可能存在相同的漏洞。

这些漏洞可以通过精心设计的项目文件触发。攻击者可以利用这些漏洞将任意数量的项目文件写入PLC并获得代码执行权限。

Team82今天披露了有关这些漏洞的有限信息,在尝试与公司代表联系一年未果后,这些漏洞的详细信息已经于2021年8月末私下披露,因为供应商既不接受我们分享技术信息,也拒绝了让我们参与漏洞修复与响应的请求。最后,2021年9月8日,XINJE代表要求Team82停止沟通。Team82则将其协调披露政策的期限从90天延长至9个月后,决定披露有限的漏洞细节,以帮助资产所有者遴选缓解措施。

关于PLC Program Tool 

XINJE的PLC Program Tool是一个工程设计工作站程序,可以在OT环境中与XINJE生产的PLC进行通信。据XINJE称,这些设备不仅在中国销售,而且还在欧洲、北美、东南亚和其他地区的一些市场上销售,涉及能源、制造业和工程等行业。

从安全的角度来看,只要获得对安装有工程设计工作站程序的机器的访问权限,攻击者就能接管PLC和其他高度敏感的OT设备,并造成不良后果。因此,攻击者可以利用这些程序中的漏洞作为完全控制OT网络的最后一步。

 1.png

以工程工作站为目标的攻击者可以感染较低级别的设备,如PLC、传感器或泵。

恶意项目文件是这类漏洞的重心

Team82对与项目文件相关的安全漏洞特别感兴趣。

项目文件通常是包含OLE文件、SQLite数据库、专有格式的二进制文件、文本文件和工程工作站内创建的目录的归档文件格式。这些程序被工程师用来监控、配置可编程逻辑控制器(PLC)和其他控制系统,并与之进行通信。

项目文件中包含的程序逻辑不仅负责管理ICS设备以及监督流程,同时还可能包含网络配置数据,甚至完整的OT网络布局。对于以工业网络为目标的攻击活动,尤其是国家级的入侵活动,项目文件的武器化就是这些活动的核心之所在。

当通过工程设计工作站程序打开一个项目文件时,该程序将迅速与相关设备进行通信。另外,OT工程师有时可以通过PLC上传项目文件,但这需要运行网络发现工具来确定PLC的网络地址(不是所有的PLC都支持这个程序),或者手动输入相关的网络参数。因此,许多公司会选择使用项目文件,因为每个文件可以包括一个或多个PLC的配置。

当工程设计工作站程序打开由攻击者精心构造的项目文件时,可能会触发漏洞。在这种情况下,攻击者可以将用于存储文件的网络共享中的合法文件替换成一个特制的文件,从而触发程序中的漏洞。我们在XINJE的PLC Program Tool中就发现了这样的漏洞:在打开一个精心构造的项目文件时,攻击者可以在易受攻击的端点上运行任意代码。

研究环境设置是关键的第一步

作为我们工作的一部分,我们经常收到研究专有协议的请求,以便最大限度地提高客户观察其网络流量的能力。有时,我们必须支持仍在生产现场发挥关键作用的旧设备,而在其他时候,我们甚至会偶然发现小型OT供应商制造的设备。

有次,我们从一个客户那里收到了分析由XINJE制造的设备所使用的协议的请求,这就属于后者。

我们的第一步是建立一个实验室设置;这通常需要购买设备,并将其连接到相关的工程设计工作站程序。在某些情况下,即使是购买设备也很困难,因为我们需要的确切型号可能已经断货了。

随着时间的推移,我们发现,竟然可以通过eBay买到各种型号的OT设备。在许多情况下,一旦工厂停止生产某型号的OT设备,旧的二手设备就会出现在eBay上,不仅容易买到,还是包邮到家那种。当然,XINJE提供的设备也不例外,各种型号的XINJE产品基本都可以通过eBay买到。

Ebay上的XINJE工业设备清单:

1.png

一旦购买了PLC,下一步就是把它和其他众多的OT设备一起安装到我们的实验室中,并将其连接到负责配置的工程设计工作站程序上。

1.png

 在实验室环境中运行的XINJE PLC

联合运用两个漏洞实现恶意文件的加载

一旦我们搭建好了实验环境,并研究好设备所使用的不同协议,接下来要做的事情,就是按照客户的要求在其中寻找安全漏洞。

检查这些安全问题可以帮助用户立即改善他们的安全状况。同时,负责任地将这些漏洞报告给供应商,不仅可以帮助修复这些漏洞,还能提高整个OT空间的安全性。

在XINJE的案例中,我们决定把重点放在名为XINJE PLC Program Tool的工程设计工作站程序上。如前所述,在这种情况下,项目文件的漏洞是特别值得关注的。通常情况下,在搜索项目文件的漏洞时,首先要调查工程设计工作站程序所使用的项目文件的具体结构。对于XINJE PLC Program Tool来说,相关文件是*.xdp文件。

1.png

XINJE PLC项目文件是由.xdp类型的文件组成的。

不难发现,这些项目文件都是些压缩文件,具体如下面的魔法字节PK/x03/x04所示:

1.png

并且,它们几乎可以被所有的归档工具(如7z)提取。更有趣的是,当程序打开一个项目文件时,它会立即将其解压缩到位于其安装目录下的一个临时目录中:

1.png

XDPPro.exe将多个文件写入C:\Program Files\XINJE\XDPPro\tmp目录中

这种行为表明,该程序认为自己是以管理员权限运行的。这一点,再加上提取的文件是一个zip文件,立即让人怀疑是否可以利用zip slip漏洞(一个任意的文件覆盖漏洞)来获得任意的写入权限。

很快,我们确实发现了一个zip slip漏洞(CVE-2021-34605),它可以授予攻击者该程序的所有权限,包括任意写入特权;在大多数情况下,这些权限都是管理员才具有的权限。

下一个问题是:如何从任意文件写入实现代码执行。由于代码在项目文件加载后立即执行是最合理的选择,所以,我们可以检查程序在打开项目文件后,会执行哪些操作:

1.png

XDPPro.exe试图从C:\Program Files\XINJE\XDPPro加载DNSAPI.dll,但没有找该动态库,并返回至C:\Windows\System32目录

有趣的是,它将通过LoadLibrary从其本地目录来加载.dll文件。当LoadLibrary没有找到相应的动态库时,它会再次回到C:\Windows\System32目录,并在此搜索库文件。这里是我们发现第二个漏洞,即CVE-2021-34606的地方;这是一个典型的DLL劫持漏洞。

为了创建一个行之有效的exploit,我们需要联合使用这两个漏洞:

一旦精心构造的恶意项目文件被XINJE PLC Program Tool打开,就会触发zip slip漏洞,这时,会将一个.dll文件写入Program Files的program目录中。之后,在加载新项目的过程中,这个DLL也会一同被加载,而不是加载真正的DLL(它位于Windows\System32)。

一旦攻击者的DLL被加载,恶意代码就会在其DLLMain进程或在程序导入的某个函数中执行,这样,攻击者就在OT网络中成功获得一个立足点。

1.png

Team82的PoC演示效果

小结

尽管近年来OT界对网络安全的认识一直在稳步提高,但许多工程设计工作站程序中仍然存在许多易受攻击的安全漏洞。

并且,并非所有的供应商都已经意识到,工程文件能够成为攻击者手中的武器,成为控制关键OT资源的手段;对于大多数OT人员来说,情况也是如此。

此外,许多供应商在协调漏洞的披露的方面,仍然有许多工作要做。因此,披露过程会浪费许多不必要的时间,因为这些信息往往要经过没有安全知识的销售和/或技术支持团队,才能到达负责开发受影响产品的团队。

对于新捷来说,这是一次具有挑战性的漏洞披露,幸好这并非大多数OT供应商的常态。

本文翻译自:https://claroty.com/2022/05/11/blog-research-from-project-file-to-code-execution-exploiting-vulnerabilities-in-xinje-plc-program-tool/如若转载,请注明原文地址


文章来源: https://www.4hou.com/posts/QgZM
如有侵权请联系:admin#unsafe.sh