星期五实验室 | 漫谈工控协议安全-S7Comm

本文旨在分享工控协议安全问题的思想，并不着重于协议的详细解析，有以下几点原因：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 layer	Protocol
Application Layer	S7 communiation
Presentation Layer	S7 communiation
Session Layer	S7 communiation
Transport Layer	ISO-on-TCP+ TPKT + COTP
Network Layer	IP
Date Link Layer	Etherent
Physical Layer	Etherent

目前关于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

关注获得更多资讯