[西门子] 星期五实验室 | 漫谈工控协议安全-S7Comm

[复制链接]
查看89736 | 回复0 | 2024-3-25 11:57:18 | 显示全部楼层 |阅读模式


本文旨在分享工控协议安全问题的思想,并不着重于协议的详细解析,有以下几点原因:1、分析协议各个字段的内容十分繁复,各个功能码、子功能码下对应的协议结构不尽相同,最终文章会变成长达几十页的手册。2、工控协议基本都是私有协议,或在公开的协议上实现的私有化,并不能保证对其字段含义解析得完全正确,且很多协议字段对安全研究毫无意义。3、目前已经有很多工控协议结构的分析文章,Wireshark也已经支持大部分协议。虽然知识零碎,但足以认识协议整体结构。

前言

本篇漫谈,我们来讲一下S7Comm协议。它是西门子在1993年推出的私有协议,应用于S7-300/400系列及200系列PLC(各系列协议略有不同),监听于102端口。

它在OSI七层模型中是实现了应用层、表示层和会话层的协议。实际上更为准确的说,S7Comm建立在传输层的COTP协议(RFC905)之上,作为其Payload进行传输。自S7Comm推出起,TCP/IP已被广泛应用,为了能让协议适配TCP/IP,S7Comm采用在TCP之上模拟COTP服务,并用TPKT(RFC1006)来作为过渡,封装COTP。此处的TCP已经和我们熟知的TCP有些不同,它没有确认机制,被称为ISO-on-TCP协议(RFC1006)。当然,脱离TCP/IP的架构,S7Comm也是完全可以通信的,理论上它是属于COTP的载荷,只不过要使用特殊接口/设备。

总结来说,S7Comm以太网传输时模型如下:
OSI layerProtocol
Application LayerS7 communiation
Presentation LayerS7 communiation
Session LayerS7 communiation
Transport LayerISO-on-TCP+ TPKT + COTP
Network LayerIP
Date Link LayerEtherent
Physical LayerEtherent

目前关于S7Comm的文章都将TPKT划归会话层,将COTP划归表示层,这是不对的。仔细想想会发现这样划分,它们各自都没有达到OSI对该层协议规定的作用。

协议简介

下面简单介绍与S7Comm相关协议。同文首所述,不会把精力放在协议字段解析上。

TPKT

TPKT被作为COTP和TCP之间的过渡,用于在TCP之上模拟COTP协议。



COTP

它是一种可靠传输协议,和TCP相似,已经随着时代演进逐渐淡出人们视野。小端序,不定长,协议第二个字段为功能码,总共四个:

    CR: 0x0e,Connect Request,表示连接请求。

    CC: 0x0d,Connect Confirm,表示连接确认。

    DT: 0x0f,Data,表示数据传输,其后承载S7Comm。

    DR: 0x08,Disconnect Request,表示断开请求。一般用不上,而是发送TCP FIN。


你会发现数据包中存在dst/src reference字段,在发送CR/CC为功能码的数据包时,还会出现src-tsap、dst-tsap、tpdu-size这些参数字段。其中,xxx-tsap用来指定CPU机架和槽位,tpdu-size表示最大tpdu长度。类似于TCP的端口,COTP采用reference+tsap来达到多路复用效果。
TPDU: Transport Protocol Data Unit,传输协议数据单元,简单理解为COTP的载荷,在该上下文中即是S7Comm。TASP: Transport Service Access Point,类比为TCP中的端口即可。



S7CommS7Comm是极其繁复的协议,但我们可以抛开无用的东西,关注于关键字段。它大体上分为三部分:

    Header: 包含功能码等基本信息。

    Parameter: 功能码的参数,所以根据功能码不同,也随之不同。

    Data: (可选)若需要传输数据时存在。




Header中有几个关键参数:
•ROSCTR / PDU Type: 即功能码,常用功能码如下

    0x01: Job,即由主设备(上位机)发送的作业请求,用于完成建立通讯(Set Communication)、读/写寄存器(Read/Write Var)、读/写块(即读/写工程,Read/Write Block)、启/停PLC等常见任务。

    0x02: ACK,acknowledgement without additional field,类似TCP的ACK。

    0x03: Ack_Data,acknowledgement with additional field,一般用于响应Job请求。

    0x07: Userdata,协议扩展,参数字段包含请求/响应ID(用于编程/调试,读取SZL,安全功能,时间设置,循环数据...)。
•PDUR: Protocol Data Unit Reference,用于标识会话。请求方仅接收相同PDUR的响应包,来达到会话控制的目的。

通讯流程

S7Comm通讯前需要建立连接,流程如下图:



简单总结,S7Comm通讯需要先握手三次,先后分别是TCP、COTP、S7Comm。随后才开始发送S7Comm的功能包。通常来说,S7Comm的控制指令只需要进行单次通讯,并没有什么需要注意的地方,但多次通讯就涉及到上文所述的PDUR修正,比如Write Block通讯流程下:



当作为上位机时,处理PLC发送来的请求需要注意修正PDUR,否则PLC将拒收并断开TCP连接。例如上图处理Downlaod Block时,就需要将响应包的PDUR改为和请求包一致。

协议安全分析

经过上文简单的讲述,已对S7Comm协议整体有了初步了解。下面,我们从多个角度来看待这个协议的安全问题。

认证方案

作为一个应用层协议,最后服务的对象就是一个应用程序(Application),在S7Comm的场景下,这个应用程序就是S7-300/400系列PLC。身份验证准确上来讲,理应由应用程序(PLC)实现,它本身不能称为协议问题,但既然S7Comm是和S7 PLC绑定的私有协议,也可以宽泛的把它作为漏洞的一部分。通过上文学习了解到,上位机和PLC建立通讯以后,接收上位机请求并处理,并不存在验证请求来自可信对象,这就是S7-300/400系列PLC(甚至可以说目前大部分PLC)最严重的问题所在。

例如,把PLC比作Web服务器,上位机比作Web浏览器,通过浏览器访问Web服务器后,管理员操作(上传下载/开关机)按钮直接显示在了网页上,直接点击执行即可,这就毫无安全性可言。恶意攻击者通过自己的上位机软件即可控制PLC,甚至不需要上位机软件,直接发送/重放流量即可,这就是工控安全的由来和亟待解决的重大问题。

2011年Blackhat上的一篇WP[1]成为了工控安全的开端,时至今日,解析协议后组包攻击的手段层出不穷,由于缺乏身份认证,工控领域黑客已经完全接管了S7-300。

完整性保保护

互联网早期时代,中间人攻击屡见不鲜,正是因为当年协议缺乏完整性保护,随后出现了数字签名等相关技术。回看S7Comm,同样缺乏完整性保护,所以流量被劫持后修改传输数据,若改动长度再修正一下length,即可被PLC或上位机认可。有没有真实的案例呢?当年震网病毒(Stuxnet)想必部分读者还有印象,核电站设施超负荷运作/宕机为什么没有被工程师站检测到呢?是因为中间人攻击修改Read SZL/Var/Block传输至上位机的数据显示为正常状态。可见,完整性保护也是一大痛点。

加密方案

S7Comm作为不公开的私有协议,当年的工程师可能认为这已经对协议进行了加密,难以分析。实践证明,对S7Comm协议的研究已经让它和公开协议没有区别,形同明文传输。工程师们犯了密码学的一个认知错误:私有实现的加密算法(比喻可能不太恰当)并不能像理论验证安全的公开加密算法一样保证安全。公开的数据交换大大降低了黑客的研究成本,所以S7CommPlus的快速更迭也赶不上被攻破的速度。并且随着工业互联网的推进,流量传输在互联网上将会带来数据泄漏等等安全隐患。为什么Web应用推荐采用HTTPS作加密和完整性保护?这都是有历史经验的,而工控协议远远落后于时代。

后记
S7Comm协议诞生于上世纪90年代,过去这么多年,西门子设备已经占领了工控行业半壁江山,加之工控设备更替缓慢,遗留下来的隐患设备数不胜数,它们正运行在各国、各行各业的生产线上。变革是工控行业时代发展的需求,而工控安全出现正是为了解决这些生根已久的隐患。
参考•S7comm·Wiki·Wireshark: https://gitlab.com/wireshark/wireshark/-/wikis/S7comm•COTP·Wiki·Wireshark: https://gitlab.com/wireshark/wireshark/-/wikis/COTP•TPKT·Wiki·Wireshark: https://gitlab.com/wireshark/wireshark/-/wikis/TPKT•IsoProtocolFamily·Wiki·Wireshark: https://gitlab.com/wireshark/wireshark/-/wikis/IsoProtocolFamily•[MS-RDPBCGR] Client X.224 Connection Request PDU: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/e78db616-689f-4b8a-8a99-525f7a433ee2?redirectedfrom=MSDN
[1] WP: https://media.blackhat.com/bh-us-11/Beresford/BH_US11_Beresford_S7_PLCs_WP.pdf

推荐阅读
•Exploiting Siemens Simatic S7 PLCs WP: https://media.blackhat.com/bh-us-11/Beresford/BH_US11_Beresford_S7_PLCs_WP.pdf•Exploiting Siemens Simatic S7 PLCs PPT: https://media.blackhat.com/bh-us-11/Beresford/BH_US11_Beresford_S7_PLCs_Slides.pdf•Internet-facing PLCs - A New Back Orifice WP: https://www.blackhat.com/docs/us-15/materials/us-15-Klick-Internet-Facing-PLCs-A-New-Back-Orifice-wp.pdf•Internet-facing PLCs - A New Back Orifice PPT: https://www.blackhat.com/docs/us-15/materials/us-15-Klick-Internet-Facing-PLCs-A-New-Back-Orifice.pdf•西门子S7COMM协议READ SZL解析: http://blog.nsfocus.net/s7comm-readszl-0427/













工业互联网安全

工业互联网创新型企业

坚持以客户实际需求出发

用数据赋能未来工业

www.bolean.com.cn

扫描二维码

或手动搜索bolean-tech

关注获得更多资讯

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?注册哦

x
您需要登录后才可以回帖 登录 | 注册哦

本版积分规则