XZ Utils压缩库后门、CrowdStrike更新导致Windows蓝屏、黎巴嫩数千个传呼机爆炸等热点安全事件再一次敲响了供应链安全的警钟。近年来，工控系统供应链攻击频发， Codesys Runtime内核作为全球超过500多家工控厂商的共同组件，引入了公共威胁和难以及时修复的漏洞。近年来，我们在Codesys Runtime内核中发现了10多个漏洞，这些漏洞正在严重威胁工控系统的安全性。
一起来回顾下高剑在SDC2024 上发表的议题演讲：《工控系统供应链攻击大揭秘》
高剑，和利时信安院安全研究员
*以下为速记全文
各位领导，各位嘉宾，大家早上好。很荣幸站在这个舞台和大家一起分享关于工控安全的议题，我今天要分享的议题是《工控系统供应链攻击大揭秘》。在开始前先做一个自我介绍，我是高剑，现在就职于宁波和利时信息安全研究院，工作经历有近10年的工控厂商，再加上4年安全厂商（绿盟科技格物实验室安全研究员）的经验，研究方向是工控系统及设备漏洞挖掘分析，工控业务场景风险评估与系统安全测试，截至目前已经获得了50多个CVE编号，前几年也参加了国际和国内的一些安全顶会，包括Blackhat、HITB、HITCON、ICS conference等，也是看雪峰会的老人了，在SDC2020年讲了关于工控安全的议题。入选了西门子、施耐德等国际知名工控厂商名人堂。
今天的议题我准备从以下几个方面进行一个阐述。首先讲一下背景概述，接下来讲述Codesys V2和V3的内核的安全研究，包括一些研究方法和结果展示，然后我们会做一个攻击展示。后边两个部分基于现状，会提出一些安全建议。从长远来看，工业大脑应该怎么设计会更安全，我也会提出一些建议。
接下来我们就进入第一部分，什么是供应链攻击？供应链攻击是使用第三方的组件，或者说服务来渗透目标系统、设备或网络。供应链攻击不是直接针对目标，它攻击的是目标所依赖的第三方组件，这个也是我们护网或者红蓝对抗时候的思路。目标单位打不进去，我们打它边缘的东西，打它供应链上的一些东西。依赖项有很多，包括第三方供应商提供的硬件程序、固件、软件代码或服务。
从2020年开始，供应链攻击的事件慢慢进入公众视野，2021年的log4j核弹级漏洞。今年尤其是供应链事件爆发的年份，前半年的xz后门植入，到7月份，微软所依赖安全软件crowdstrike做升级时候出现缺陷导致全球很多行业都受到了影响。再到9月份，让我们看到了现代战争中对供应链的利用，达到了定点清除的目的。恶意攻击者对BP机和对讲机设备进行改装供应链植入，然后进行特定代码的触发爆炸，达到定点清除的目的。这是我们日常所能看到的一些供应链攻击的安全事件报道，工业控制系统是比较封闭的系统，它存不存在供应链攻击的潜在风险呢，今天这个议题带大家逐一剖析。
首先我们先看一下工控系统中的供应链，给大家普及一下控制系统包含普度模型5个层级，从最上边的是ERP到MES，它类似于我们的IT系统里边的调度管理之类，使用的最多的是Html、QT这些第三方组件。Level 2是监控层级，用的最多的工业主机是windows操作系统，还有一些移动的监视设备用的安卓系统，触摸屏用的是WINCE操作系统。再到Level 2和Level 1之间，做通讯的时候，采用的协议有OPC UA、Modbus、MQTT等。在Level 1控制层包含了控制器，它是工业大脑，包括了PLC、RTU、DPU等等，控制器层级有一个整体解决方案的提供的厂商，比如Codesys、Infoteam等。到Level 0层级，也就是传感器和执行器。Level 1和Level 0之间是通过各种工业以太网或者工业总线进行通讯。
接下来看一下工业控制系统供应链的安全现状，我总结了4点：
第一点尤为重要，基础组件漏洞多。刚才看到工控系统中包含的组件非常多，使用的基础组件多了，出现漏洞的概率也就大了。比如广泛流行的OPP UA组件，从2017年到现在已经暴露出来了很多漏洞，影响了现场数以万计的产品，严重威胁了现场应用。
第二个是欠缺对第三方依赖项的审查机制。工控厂商做产品开发的时候，直接从第三方购买源码方案或者开源代码直接使用，没有对其进行安全审查。产品售卖之初监管机构对应用于关基领域的产品和软件没有强制要求，做全方位的供应链漏洞或者威胁审查。
第三个就是工业产品的供应渠道易遭劫持。类似于BP机爆炸事件一样，工控行业的特点所决定的，一般项目有总包有分包有分分包，在这么长的链条里边，难以避免引入风险。
第四个是工业升级过程不安全。工业系统中使用了很多工业软件，它们会定期的去升级，在升级过程中会引入恶意代码或者劫持升级过程等风险。这样来看整个工控系统中的供应链是存在威胁的，而且是威胁比较大，只不过工业控制系统比较封闭，现阶段都比较关注工控业务的可用性、稳定性，在安全方面的关注比较少。
这么多的供应链里边，我们最关注的是工业大脑，是最接近于被控设备的控制器。经过我们的调研目前全球工业控制器，使用最多的第三方解决方案--Codesys。从2020年起Codesys解决方案支持国产的CPU，包括瑞芯微、龙芯、飞腾，操作系统上支持32所的Reworks还有龙芯的操作系统。
科普一下Codesys方案包含两部分，一个是Development system，Develop system类似于VS的IDE，电气工程师拿IDE软件去做编程，把代码调试好之后编译下装到PLC里边去。控制器上运行着runtime system，也就是内核系统，左边这个图就呈现了对应框架。采用这个方案设计出来的工业控制器，在流程行业、离散行业都有应用，在离散行业应用尤其广泛，像纺织机械、工业机器人、印染包装灌装机等等。
接下来看一下控制器在全球的分布，在Codesys官网上面可以看到全球约有600家控制系统生产厂商和10000家的设备制造厂商都是Codesys的用户，尤其是在德国、美国应用的比较广泛，ABB、施耐德、倍福、奥普图等等。经过在FOFA的探测，发现了美国、德国暴露的特征端口非常多，这样也就说明了，只要把Codesys研究透了，是不是就类似于工控界的安卓？
讲到这里大家会产生疑问，如此规模的大厂应该挺重视安全的，你说的应该不存在。
接下来我就回答最容易困惑的4个问题，如此大厂肯定会重视安全，你说的供应链攻击是不存在的，我给大家对比IT和OT领域安全通告的不同。微软、谷歌每个月固定时间会发很多通告，但是在OT领域，西门子、施耐德、罗克韦尔做的比较好。Codesys也做得比较好,但是发公告的频率一年也就十几份公告。
第二个就是合作厂商肯定会看安全通告，肯定知道自己产品有问题的，这也就是工控行业的一个特点，现在还是只关注于业务，安全是稍微有点关注，也没有那么大的重视程度。
第三个新售卖的产品当然是最新的内核版本，不可能给用户卖有漏洞的版本，这确实是一个问题，我们分析了两款最新售卖或最新PLC的固件，这些设备的Codesys内核还是2017年、2018年的Codesys内核，存在很多漏洞。
第四个就是漏洞扫出来之后，终端用户及时打补丁，升固件不就行了，没你说那么严重。首先漏扫能不能扫出来是一回事儿，即使扫出来之后，客户愿不愿意打补丁？打补丁后对原有的工作业务有无影响？这些问题都需要解决。
接下来分析Codesys解决方案的攻击面。内核就是运行于工业控制器内的runtime。攻击面包含工程文件解析、shell命令恶意利用、第三个就是私有通讯协议、第四个是自定义的算法库，自定义的一些算法库去执行恶意操作，如果你的语言开放程度比较多的话，编写恶意的自定义算法库读取内存数据等。接下来就是固件升级、还有总线的滥用和伪造。这些都是攻击面，我们今天关注点是私有通讯协议，为什么关注这一点？因为工业控制器部署到现场之后，该攻击面一直存在且很好攻击，只要IP可达就行。
接下来我们就看 Codesys V2的通讯协议，先给大家普及一下 Codesys的解决方案，分为Codesys V2和Codesys V3，类似于我们的Python2和Python3。V2版本属于早期版本，现在工业现场服役的控制器比较多，因为工业场景工业控制系统服役的年份较长，一般都到15~20年，短则也7~10年。V3版本属于流行版本，现阶段的国内外大量控制器均在使用这个版本。我们先看现场大量使用的 V2版本。
V2版本私有通讯协议是2000年左右设计的时候，工业场景里边要求实时性和可靠性，所以它用短的报文结构传输有效的信息。首先是报文头，接下来一个长度域，长度域分为大端小端、接下来是功能码，最后是一个数据部分payload，我们为了研究方便写了对应的插件，对通讯协议做解析。这边就是功能码的列举，比如说login服务，logout服务，还有start stop的服务。
接下来我们用研究协议最通用最高效的方法--模糊测试技术去看V2协议里到底存在哪些漏洞。我们采用了基于变异的一个模糊测试技术，为什么使用基于变异的技术，因为更高效，待会大家可以看到我演示视频，几秒钟就可以挖掘出漏洞。如下是一个测试框架，首先是管理单元，接下来就是crash log单元、monitor单元、变异单元、检测单元，最后是一个通讯单元。测试对象是某国际知名品牌PLC，测试环境中包括电源控制单元，根据它的一个反馈指令，我们去控制 PLC的启动和重新上电。为什么要这么做？加入电源模块的作用是当PLC进入故障模式后要执行重启操作，以便于进行下一轮的fuzzing测试。
接下来讲几个重要的关注点，第一个样本的生成，丰富的样本会覆盖更多的路径，会找到更多的漏洞。可以从IDE上对控制器的专有指令或专有服务码执行操作，比如说stop、断点调试或者强制变量等，通过wireshark抓取后进行fuzzing文件制作。为了尽可能多的覆盖Codesys V2协议的功能码，我们也是做了逆向工程工作，从PLC硬件里边提取固件、分析固件。
接下来讲变异策略和异常监测，为了达到更全面的覆盖，把功能码列表纳入变异策略，每隔一定时时间，在功能码列表的随机抽取。变异目标是payload域。变异算法参考AFL、Radamsa，还有定制化的一些算法边界值、特殊值替换等。每次从语料库里边选取若干样本，送入变异引擎，变异后的报文和特定的报文组合成一个序列，发送至目标。异常监测是怎么做的呢？可以根据测试目标的特点去做，或者根据硬件的故障指示灯亮红灯或者红灯闪烁去做异常监测。
如右图所示是我们在实验室做了一个Demo，目标是某国际知名厂商的PLC模块，可以看一下Fuzzing测试的效果，几秒的时间就挖掘出了漏洞。
有没有一个通用的方法，更高效的挖掘漏洞呢？Fuzzing测试工业控制器的缺点是即使用了自动化的方法，硬件重启的时候会耗费一定的时间，而且会比较难做异常监测；环境搭建也有一定的门槛；发现漏洞后，复现和分析工作比较难。基于这些缺点，有没有其他替换的解决方案，在Codesys的解决方案里边携带一个模拟器，模拟器的私有通讯协议和提取固件PLC的协议栈经过对比之后，非常相似。这样的话就可以利用模拟仿真软件搭建基于Fuzzing测试环境。先构建一个测试框架，搭建自动化测试框架，然后再启动测试程序，监控进程，如果异常后直接启动。
Codesys V3对比V2版本有很多改进，比如组件化的结构，支持模块化组件化，现场总线的协议也更加丰富。
接下来是通讯协议，V2协议是简单报文结构，V3是一个复杂的层级报文的结构关系。下面看一下这个层级报文，首先是块驱动层，接下来数据报文层，然后通道层，最后是服务层。针对V3协议，我们编写了解析插件，这样的话分析起来就会更加清晰。
接下来讲一下V3协议的授权流程，V3协议有一个复杂的授权流程，当把这一系列授权流程走下来之后，才能够进入到核心服务分支。要做Fuzzing测试就需要构建一个重放攻击的框架，只有把流程走通后，再把RUN/STOP操作替换成目标的畸形报文，这样就构建出来一个模测试的环境。V3协议模糊测试的思路和刚才讲的V2一样，在硬件PLC上先不做Fuzzing测试，先把要研究的PLC硬件所对应的V3内核版本调研清楚之后，在它的对应版本的模拟器上做Fuzzing测试，再去在PLC硬件上面验证PoC，这样的话效率就提高了，门槛也就降低了。
由于V3协议报文结构复杂，这里着重讲的样本的制作， V3报文的结构是层级式的报文结构，可以结合基于生成和基于变异这种两种思路去做研究。在服务层server以上，把它报文结构拎清楚，采用基于生成的思路。然后在它服务往下的域里，使用基于变异的思路。这样结合起来之后，效率会更加的高。
基于这个思路，我们也是做了一个Demo，直接进行Fuzzing的演示Demo，目标对象是2024年9月23号Codesys发布的V3 Win模拟器。
利用刚才的思路，我们要研究的工业控制器是某国际厂商的控制器，把控制器里边使用的V3的内核调研清楚后，在对应的模拟器上去做Fuzzing测试，挖掘出来漏洞之后拿PoC适配到PLC上。可以看到初始态工业控制器是正常的，RUN指示灯正常，当执行PoC之后，控制器就挂掉了，挂掉意味着什么？不是办公电脑直接宕机你手一按重启就行，如果这个设备在煤矿井下，你需要抵达设备所在位置，给PLC断电上电才能让它恢复。
接下来说一下我们在Codesys内核的研究成果，我们从2021年开始，针对V2/V3内核进行了一系列的研究，把漏洞提交给了国家相关单位，同时上报给了Codesys公司，收到了多个致谢。
接下来我们看一下Codesys供应链的攻击流程及模型。第一步是搜索扫描一些端口，比如1740、1743、11740、11743，还有1200、1201端口，通过扫描到之后，枚举设备使用的内核是什么版本，有没有对应的漏洞。恶意攻击者的目的是扰乱还是要长期潜伏下来，进行定点的一个攻击。扰乱的话，简单的执行拒绝服务攻击，就可以扰乱生产过程。如果是长期控制，就要做一些深入的研究，比如说控制逻辑上传上来之后，进行控制点的对应修改，控制逻辑的修改，或者说是还可以执行更高级别的一个攻击，把工业控制系统当成真正的一个武器系统。
讲到这里，大家会不会有一个疑问，你说的Codesys解决方案有没有一个通用的攻击手段，通用的 RCE攻击手段，这个是有的。不论是6131-3标准中的何种语言， 在编译型的PLC都会编译成机器码，并通过通讯协议下装到PLC特定区域里，这样就可以设计恶意的机器码插入到编译后的机器码片段，或者劫持某个控制流把它写入到PLC中，然后在PLC中调用，当运行PLC的时候就可以执行。恶意代码的功能是什么就看恶意组织的攻击目的了，可以添加后门账号等。本质问题是编译后的本地机器码，可以不受限制的在设备上运行。
我们做了一个Demo，采用了Codesys V3内核的PLC。按照刚才的思路编译了恶意payload写入了PLC，效果是创建一个监听端口，外连一个NC进行远控，这个只是一个简单demo。现代化工业攻击的场景，可以把PLC当做一个C2服务器，直接套上TLS协议逃避审计并且让它反弹一个shell，在PLC里边实现一个DNS，一套C2服务器就做好了。
基于上面所讲的威胁是存在的，我们怎么做好防护措施？作为业主来讲，也就是使用的这些设备的工厂或者企业，需要将受影响的产品放置于防火墙安全设备之后做好纵深防御策略。当需要远程访问时候，采用VPN网络，用向日葵或其他远控软件也是会有一些问题的。第三个就是关注受影响产品的安全补丁。第四个就是尽量减少受影响设备端口的暴露，把这些端口就加到防火墙安全策略里边。第五个就是尽量给受影响的控制器设置用户名和密码，把攻击难度提高。第六、七个是针对现阶使用Codesys内核的工控厂商，他们要积极去修复，发布修复的补丁版本，或者和Codesys供应商达成一个更好的合作方案，能定期更新安全补丁，最起码在最新售卖的控制器里边采用最新最安全的版本。
站在长远安全的角度来讲，我们希望构建自主可控的生态环境。从硬件层面关键电子元器件自主可控、RTOS及实时总线自主可控、PLC Runtime自主可控、编程软件环境包括SCADA也全都自主可控。最起码出了问题之后自己可以修改。
我们和利时信安院也做了安全控制器，融合了安全可信和国密技术应用，将可信计算融入到工业控制器里，做静态启动的验证。当PLC运行起来之后，只要有恶意进程起来之后，就立马通过实时动态的可信验证，识别到恶意程序并且杀掉恶意程序同时上报至安全中心，这样的话整个环节都安全后，相信应用到关基领域的控制系统上会使我国的关键基础设施变得更加安全。
接下来做一个总结，首先从供应链攻击事件入手，引出了工控系统是否存在供应链攻击风险，经过讲解它确实是存在该项风险。然后以广泛使用的Codesys内核为研究对象，进行了相关的研究。从通讯协议出发，深入研究V2和V3内核私有协议漏洞挖掘的方法。接下来我们展现了漏洞对现场运行PLC的影响，还有通用类远程代码执行攻击demo和思路。最后就目前的工业领域广泛使用的Codesys解决方案的现状提出了建议。从长远来看，我们建议构建自主可控的生态环境，使用安全可信工业控制器，以抵御大规模的供应链攻击。
峰会议题PPT及回放视频已上传至【看雪课程】：https://www.kanxue.com/book-leaflet-195.htm
【已购票的参会人员可免费获取】：我方已通过短信将“兑换码”发至手机，按提示兑换即可~
