2019 SDC 议题回顾 | 工业集散控制系统的脆弱性分析
作为工控系统种类之一,集散控制系统(DCS)多用于控制关键基础措施,分布在石油、化工、冶金、水泥、水系统中,是工艺操作人员的“大脑”。其重要性更是不言而喻。
上世纪70年代中期,出现了以微处理器为基础的分散式控制系统,经过30多年的发展,DCS已经综合了计算机、通信、显示和控制等4C技术,在功能日益健全的同时也面临着越来越多的安全风险。
下面就让我们来回顾看雪2019安全开发者峰会上《工业集散控制系统的脆弱性分析》的精彩内容。
编辑按
crownless:在工业生产进入信息化、数字化时代后,其安全问题越来越受到人们的重视。如果系统被入侵,不仅可能造成生产被迫停止,甚至还可能产生爆炸等事故。工控安全在技术上难度较低,但反而很脆弱。这就要求我们投入更多的资源在工控安全上。
嘉宾介绍
剑思庭,复旦大学软件工程硕士,暗影安全团队工控安全高级研究员,中国自动化协会常任理事,Kcon 2018讲师,开发Ethernet/IP协议设备嗅探工具。
大会上讲师为大家介绍了工业集散系统架构、工业网拓扑以及脆弱性分析,为大家打开了风控领域的新视野。
演讲具体内容
以下为速记全文:
大家好!我现在就职于工业自动化厂商侧,来负责工控渗透及防御工作,也承担了暗影安全、破晓安全和米斯特安全的工控研究。
接下来我给大家分享的题目是“工业集散系统的脆弱性分析”。
在工控系统里有很多种类,除了PLC还有一个大种类是DCS工业集散控制系统,它和PLC在架构和应用上的区别,这种领域里存在哪些脆弱性而带来系统不稳定的状态呢?接下来和大家简单分享。
用户方使用一套这样DCS的系统,用户通过非授权的USB的使用,这个USB的使用是由业主供应商带过来的,不慎把它的上位机感染了wannacry变种,造成了它的上位机蓝屏,用户找到我们团队帮助它解决病毒的问题。
通过这个引发了什么事情?我们做完HMI的防护后,让我们帮助检查除此之外工业控制网络DCS系统有没有相应脆弱性,基于此就产生了今天的这个议题。
大家看到的结构就是我们经常会碰到的DCS的标准架构,下一侧灰颜色的地方就是所谓控制器,在DCS里它叫“单元控制器”,它是控制什么?它是控制化工、石油以及水行业里的阀门和传感器。
自动化设计的初衷是代替手动制造,不需要人为参与工业生产,它就是干这个的,它有不同种类的控制器。再往上一层,通过以太网的形式是它的监控系统。
大家可以看到那个控制器是一个盒子一样的东西,它通过信号线连接了外侧的传感器和执行器,作为总控室操作人员,如何能够第一时间知道现场状态,通过什么样的交互界面呢?将通过上面这一层,我们叫监控系统。
再往上一层就是所谓的管理系统,在管理系统里会提取你监控的信息以及管理信息,综合起来再去分析你的生产状况。下面那层只是纯监控、监视和控制,上面那层会有分析。这是标准的DCS系统。
它和PLC工控系统有什么区别?PLC是以下面灰颜色控制器为主,上面的监控软件和下面的控制器可以是两个不同的厂商、可以是两个不同的软件,甚至可以是一个PLC上面挂一个开发的应用软件,但是DCS里永远不会出现这样的情况,DCS都是一个厂商,而且走的协议也是私有协议。
我们测试的主要是红框这个地方,这个地方是安全仪表系统,比如我假设一个场景,因为大家可能都不是在做制造业的,很难在脑中复现这个画面。
举个例子,大家都开车,车里的汽油是怎么产生的?由三大油厂商把地下石油提炼出来,经过练化、裂解才变成我们使用的石油,过程中它会经过高度加温,经过离心高速旋转,但是这两项行为是很危险的。
红颜色的系统是什么意思?比如它设定一个温度超高比如1200度如何,如果罐里液体少于10%又如何,离心超快达到几万转又如何,它为了保证安全性会设立这个控制器,一旦超出设立指标马上停止,以确保设备安全和人的安全。
这是传统信息安全和工业安全的本质区别,传统信息其他更多保护的是知识资产、信息资产,但是工控安全不是这样的,信息资产也很多,但是更重要的是人和设备。
我们曾经出现过一件事情,大家都知道锅炉,北方冬季取暖都用到暖器,暖器是由供热公司送过来的,它有一个专门产生蒸气的锅炉把蒸气送过来,如果水在锅炉液位超低的话,再烧就会炸了,这个控制器就是确保水不能烧干了。
就像大家在家里烧水一样。在锅炉系统里,一旦水烧干了,锅炉就会被炸掉,因为里面的热气没有办法被释放出来。这个控制器就是确保设备和人身的安全。
这个场景有几部分组成?有2台思科2960二层交换机组成它的网络结构,另外有两台DCS控制器,另外有两台server里面运行server2003,还有4台client,XPSP3的,为什么我把这侧面标灰了,是因为我们要去打补丁和安全防护的,客户让我们测试的里面不包括这两台设备,另外,我们使用1台kali机器。
这个图就是网络架构,中间两台是2960交换机,下面2台是冗余控制器,上面两台是server是2003,还有4台client。每台机器上都有两条线,一个黄的,一个绿的,它是保证单网络不要出现中断的情况,双网下来。
但是它为了保证网络冗余性,它不仅仅保证双网,还保证了如果交换机坏掉也不影响使用。这里它就构成了STP,生成数的这样一个环境。
仔细去看,会发现这里是有环的,如何确保没有环,这是DCS厂商自己解决在通讯上的问题,既保证链路是冗余的,又要保证不要形成环路。就像一个小区一样,路由很多,怎么确保不要打转呢,这由厂商去解决。
每台计算机后面的接口都是这样的,一块网卡上有两个口。厂商把它做成了桥接模式,传统来讲这应该是2个不同的网段,但把它做成了同一网段,这种模式下它就形成了环。
如何破解这个环路,不让它对环路形成干扰?厂商自己开发了二层的容错以太网协议,这个协议10年前就开发出来了,是非常优秀的以太网冗余的协议。
左侧图是把两口的网卡协议层时加了自己的驱动软件,把它做成了桥接,桥接这个模式时又屏蔽了STP可形成环的检测,这是它做得很高明的地方。同时,它在这里面开通路由功能。
再往上是协议层,它要跑自己的工业协议,这里面跑的什么协议从后面可以看到。这张图是一个基于二层高可靠性的网络,另外的图片是每一个节点状态是不是正常的,到任何一个节点都有4条链路可以走,任何一条链路坏掉都没有影响,但同时它只走了1条链路。
大家可以看下面的图,虽然它有4条,最后会把2条堵上,哪条最优是它自己做计算的。
我们团队接到渗透任务这个时候首先看到的是2960交换机,首先去看能不能找到和2960以及这个厂商相关的信息。我们找到了这个厂商的配置文件,标红的地方是什么意思?它不让你在DCS网络里形成环,并启用MSTP协议,保证只有单链的通讯,同时又可以实现多路径的冗余。
在此基础上,STP有什么特点?它是为破解环路而设计的一个网络。STP有一种没有使用的状态,第二种是转发的状态,第三种是把这个关口关闭掉,为了防止形成环路,还有一种是在学习,还有一种是在监听,这5个状态是在循环的,交换机的这个端口的状态是这样的循环。
每一个状态的切换都需要5-15秒,这5-15秒之间是不做任何数据转发的,也就是说数据是中断的。另外一个图,当形成三角、形成环路时,它会把端口阻塞掉,虽然外形很像环性,但其实它是line形。
我们采用什么工具去做这个破坏性实验?我们尝试一下,如果我们对这个STP做攻击会有什么结果。我们采用了一个工具,这个工具是专门攻击工业以太网二层协议的工具,大家使kali 2007版以前的都有这个工具。
我们当时选择了BPDU连续发送,什么意思?在刚才看到的3台交换机里形成环网时,永远有一个管理者来决定哪个端口是关闭的、哪个端口是开放的。怎么选择这个管理者?就是我想如果、地址最低的那个设备视为管理者。
我们就模仿了一下,如果我们对这个交换机发大量mac地址肯定有地址比你低,会不会造成它的链路震荡?这个视频是我们做的,DCS系统上位机,可以看到攻击状态,它输入用户名和密码,输入进去之后我们选择在线监控图,这张图是客户在线的生产状态,我切到这个系统里,针对那台2960 mac地址做一次hack,目标mac一定是交换机的我想如果、不是端口mac,因为它是二层的,端口上没有mac。
我们先发一个BPDU一次震荡,告诉它会产生震荡,这时它开始学习了,然后我们发个连续让它震荡不停,mac地址在狂发送。这时我们切换到平台上,这时画面还是有的,但是数据已经不刷新了,画面为什么还有?它有一个和自己控制器重连的时间,这个重连时间有3次里面定义的时间,现在看来所有的都还是可以的。
这时数据已经不刷新了,我们再想回到界面时发现它已经报错了,“timeout”控制器已经全部断开连接了。这是我们的一个演示,造成DCS上位系统和它的控制器连接断开了。
DCS有个最大的不同,一旦上位机断开,下面的控制器设备自动进入保护状态,不会自己持续,间接把控制器做成了hold的状态,所有端口都会保持上一时间的状态,不再做任何变化。
另外,当我们发现这个之后,尝试想看到控制器跑了什么协议,我们采取了什么办法?大家有没有人知道CVE-2018-0171,是一个安全团队发现思科的漏洞,也就是说在4786端口上如果发一个畸形数据包时会把交换机打死,甚至会拿到root权限。
我们之所以用这个CVE打这个交换机,是想做个端口镜像,把上位机到控制器的流量引出来。因为交换机不像集线器,它不是全端口转发,你根本看不到它们俩的流量。
这段是我们的攻击代码,最下面的一个是发送了,在tv1和tv2那两个地方如果装了特殊字符就会引起2960交换机直接死机了。当时我们是想能够获得root,但是没有成功,很不幸直接把交换机打死了。
而且客户当时只给我们1天时间,没有办法再修改代码去找到错误的地方获取root。我们采取了另外一个比较粗暴的方式,就是Mac泛洪,2960交换机的mac地址表大概是4K,我们测试只要超过了4K多之后,它就会变成一个hub。
因为它自己找不到那些需要做转发的端口,因为mac地址表,哪个端口对应哪个,会把原来真实mac地址冲掉了,里面都是虚假的,交换机发现没有了对应mac怎么办?做广播。做广播时我们可以抓到上位机到控制器的清晰流量。
下面它跑了一个Modbus-TCP,这是工业以太网里一个非常常见的工业协议,但是它不仅仅跑了这个Modbus-TCP,还同时跑了一个组播协议,224的组播段上把通信服务跑在组播上,把数据跑在tcp这个协议上,这是它的设计方法,我们也是通过mac泛洪的方式抓到这个流量。
Modbus-TCP端口是502,有哪些家会采用Modbus-TCP?市面上国产的DCS系统都具备这个接口,而且这个协议有先天性不足。
但是为什么很多人要使用这个Modbus-TCP?因为Modbus-TCP是工业以太网的协议,在工业环境里还没有谈及安全时,只谈功能、只谈业务时它已经产生了,它是第一代的工业以太网协议,所以它更关注的是怎么实现业务,却没有考虑安全。
这是它的报文,它是一个7层协议,最下面有一个Modbus-TCP的站地址,这个站地址不是TCP的地址,它认为TCP里的节点从0开始,也就是说站里有多少个设备,它就有多少地址。后面有一个功能码,发进去这个数据流到底要做什么,是被这个功能码定义的。
另外还有地址,后面就是数据,但它这里面没有校验,校验那两个地方是空的,因为它用了TCP的校验,在协议里没加校验。Code码有1、2、3、4、5、6等很多种,最多有16个code,是里有读、写、批量读、批量写。但是这里面它没有对身份验证,所以做重放也好,任意接入也好,对它来讲都是有效的,这是Modbus-TCP自身存在的协议上的一个缺陷。
我们针对协议上的缺陷写了这段代码,目标地址是10.1.1.35,端口是502。我们对地址“000”做一次hack,行为是让它产生一次“01”的跳变,这个跳变在我们信息安全的人看来只是一次数值的变化,没有什么意义。
但是在工业领域里不是这样的,如果这个位置对应的是你的一个24v的蒸气阀门,这个蒸气阀门是关闭的,你让它产生一次跳变时,它就会开一次再关一次,例如40吨的蒸气瞬间会在管道里涌出来,也就是说附近以内的人沾上就死掉了,是看不见的那种蒸气,可能是一层白烟,过去的时候身体连原形都没有,这是我们曾经在现场出现一次事故,程序写错了把40吨蒸气打开了,现场维修的工程师连衣服都没有剩下。
整个代码就是这样的,前面那几个字符都是标准固定的,后面是计算协议的字长,然后放哪个功能码,功能码放的是“1”。如何去写数据?最后那个地方是ff,那个ff就是致1。000是致0。中间做了个延时,经过这样一个跳变之后就实现了标志位的0到1的跳变。我给客户做了这样一个展示。
这个视频就是介绍这段程序的执行,另外,大家可以看到那一侧,是一个模拟的现场控制器,大家眼睛可以关注第一位的那个“0”,一旦这个程序执行之后就会产生这样一个跳变。
这个代码其实非常简单,就是我们要去做地址唯一的off,位置在哪?就是地址为“1”的这个地方。大家可以看一下那个地方,它变1了,又变0了,仅仅是这样一个动作,你可以对一个位,也可以对所有的位,让计算器里所有的状态跑的不是它原来程序所要的状态,这都是可以的。
我们讲了这么多,最关键的PPT是这一页,面对这样的问题,我们怎么去防护它?
第一,交换机一定要增加端口的安全策略。就像现在工业用户的交换机端口不是敞开就是默认的状态,这是不可以的。如果不用一定把这个断口堵掉,这样可以确保端口的安全。
第二,增加工业防火墙的隔离。因为协议本身并不安全,怎么确保是非法攻击呢?通过过滤防火墙确保原mac以及攻击向量踢出去。同时,网络里一定要监控主机。
第三,用户侧原来在计算机上没有安装防火墙,也没有安装杀软。这次我们帮助用户安装了杀软,开了防火墙,并做了基线安全,同时装了白名单的防护,因此防止其他恶意把木马传上来去做执行。整体在这方面的防护。
非常感谢大家,这是我的个人信息,有二维码、邮箱和三个团队:暗影、破晓和米斯特,如果大家有对公共安全感兴趣的可以跟我进行私下交流。
工控安全在技术上没有什么难点,但反而很脆弱。但是国家之所以把基础设施安全提到这样的高度,因为它是由人员、设备和资产三部分共同组成的安全等级,不是简简单单的信息丢失,可能造成设备的损伤、人员的伤亡。
注意:点击文末原文链接,即可查看本议题完整演讲PPT。其他议题演讲PPT,经过讲师同意后会陆续放出,请大家持续关注看雪论坛及看雪学院公众号!
2、2019 SDC 议题回顾 | 新威胁对策:TSCM 技术反窃密
3、2019 SDC 议题回顾 | 安全研究视角看macOS平台EDR安全能力建设
4、2019 SDC 议题回顾 | Android容器和虚拟化
5、2019 SDC 议题回顾 | 基于云数据的司法取证技术
6、2019 SDC 议题回顾 | Android漏洞检测沙箱的设计与实现
7、2019 SDC 议题回顾 | 是谁推开我的“窗”:iOS App接口安全分析
公众号ID:ikanxue
官方微博:看雪安全
商务合作:wsc@kanxue.com
↙点击“阅读原文”,查看演讲PPT