plc安全扫措及漏洞利用框架

一台西门子S7-1200 PLC的全扫CPU上，固件版本是措及4.4.0。它的漏洞利用443端口开着，Modbus TCP也开着，框架但默认密码没改。全扫用Shodan搜一下，措及全球至少有几千台这样的漏洞利用设备直接暴露在公网上，其中相当一部分属于水处理厂或能源站。框架这不是全扫什么科幻情节，而是措及我上周做安全测试时随手就能复现的场景。PLC的漏洞利用脆弱性从来不在计算能力上，而在它的框架设计哲学——它信任一切，包括攻击者。全扫

扫描一个PLC比扫描一台服务器要微妙得多。措及你不能拿Nmap的漏洞利用默认脚本集去乱撞，因为发送非预期的协议数据包可能让PLC直接进入STOP模式，导致现场停机。我见过一次测试，只是用modscan扫了一个污水处理站的PLC，结果它立刻抛出了“通信中断”故障，整条产线停了二十分钟。那是我第一次意识到，工业控制系统的安全测试，本质上是在走钢丝。

所以真正实用的扫描逻辑，第一步是识别，而不是探测。用EtherNet/IP的List Identity请求，或者S7comm的SZL读取，先拿到设备型号、固件版本、模块名称。这些请求是只读的，不会触发故障。拿到信息之后，再对照公开的漏洞库——比如西门子的CVE-2020-15782，那是个硬编码凭据问题，或者罗克韦尔的CVE-2021-22681，涉及路径遍历——判断这台设备有没有已知的软肋。这个过程讲究的是“轻触”，就像医生叩诊，力度大了病人会疼。

漏洞利用框架的构建，比扫描更讲究“对症下药”。PLC的协议栈是封闭的，你没法像Web应用那样塞个SQL注入payload进去。真正有效的利用方式大体分三类：

第一类是重放攻击。很多PLC的固件更新或远程启停功能没有时间戳和随机数校验，你只要抓一次合法的编程软件通信包，就能无限次重放。我实测过，用Wireshark抓取TIA Portal下载程序时的S7comm流量，然后脚本化重放，能直接把一个未设密码的S7-1500的RUN模式切换成STOP。整个过程不需要任何漏洞，纯粹是协议设计上没考虑抗重放。

第二类是固件降级。PLC的引导程序通常不校验固件签名，或者校验逻辑有版本回退漏洞。攻击者可以把一个带后门的旧版固件刷进去，再重启设备。这类攻击最隐蔽，因为PLC的Web界面和HMI上显示的固件版本可以伪造。你从外部看，设备一切正常，但内核已经被替换了。

第三类是利用PLC的“编程接口”做跳板。很多PLC自带FTP服务器或Web服务器，用于文件传输和诊断。这些服务经常用默认凭据或者空密码。攻进去之后，可以修改PLC的启动脚本，让它每次上电都从攻击者控制的TFTP服务器拉取恶意配置文件。这个思路不是我的原创，但我在一个模拟电力环境的测试床上验证过——从扫描到植入后门，全程不到十五分钟，期间PLC一直维持着正常输出，操作员完全无感。

说句实在话，目前市面上没有任何一款商业扫描器能真正做好PLC安全检测。它们要么太吵，容易触发故障，要么太浅，只做端口版本识别。真正好用的框架，比如基于Python的python-snap7配合Scapy自定义S7comm报文，或者用Modbus TCP的函数码0x2B做设备身份查询，都需要测试者自己拼装。这也是为什么工业安全领域的高手，往往对协议细节倒背如流，而不是靠工具集打天下。

最后提一嘴，别迷信“物理隔离”。我接触过不少工厂，OT网和IT网之间确实有防火墙，但维护人员为了方便远程调试，在防火墙上开了临时端口，忘了关。PLC安全的核心不是堵住所有洞，而是承认洞存在，然后假设攻击者已经站在了PLC面前——在这种情况下，你的设备还能扛住几次恶意指令？这个问题的答案，才是真正的安全基线。