The result of tag: (6 results)

我的工控安全学习路线

by LauCyun Jun 13 14:06:53 3,435 views

一、概述

随着德国的“工业 4.0”、美国的“再工业化”风潮、“中国制造 2025”等国家战略的推出,以及云计算、大数据、人工智能、物联网等新一代信息技术与制造技术的加速融合,工业控制系统由从原始的封闭独立走向开放、由单机走向互联、由自动化走向智能化。在工业企业获得巨大发展动能的同时,也出现了大量安全隐患,伊朗核电站遭受“震网”病毒攻击事件、乌克兰电网遭受持续攻击事件和委内瑞拉大规模停电事件等更为我们敲响了警钟。

工业控制系统已成为国家关键基础设施的“中枢神经”,其安全关系到国家的战略安全、社会稳定。工业控制系统所面临的安全威胁是全世界面临的一个共同难题,工业设备的高危漏洞、后门、工业网络病毒、高级持续性威胁以及无线技术应用带来的风险,给工业控制系统的安全防护带来巨大挑战。

1.1 什么是工控安全

所谓工控即是工业控制,工业控制系统(ICS,Industrial Control System)是由各种自动化控制组件以及对实时数据进行采集、监测的过程控制组件,共同构成的确保工业基础设施自动化运行、过程控制与监控的业务流程管控系统。其核心组件包括数据采集与监控系统(SCADA)、分布式控制系统(DCS)、可编程逻辑控制器(PLC)、远程终端(RTU)、智能电子设备(IED)以及确保各组件通信的接口技术。

如图1所示,工业控制系统可简单划分为过程控制网络和现场控制网络两部分。过程控制网络中部署多种关键工业控制组件,通过 SCADA 服务器(MTU)与远程终端单元(RTU)组成远程传输链路。


图 1 典型工业控制系统结构(来源:计算机网络安全公众号)

过程控制网络向下与现场控制网络相连接。现场总线的控制和采集设备(PLC或RTU)一方面将现场设备状态传送到过程控制网络,另一方面还可以自行处理一些简单的逻辑程序,完成现场控制网络的大部分控制逻辑功能,如控制流量和温度、读取传感器数据等。

过程控制网络向上与企业信息网络相连接。在企业信息网络中,企业资源计划(ERP)服务器和制造执行系统(MES)服务器与工业控制系统紧密相连。

在企业信息网络中,邮件、Web、ERP 等业务都需要与互联网相连接,而 MES 需要与工业控制系统相连接,以获得生产过程的各种数据,并下达生产任务。各种病毒和木马就是利用这个通道进入企业信息系统,进而进入到工业控制系统中,这已经成为工业控制系统的主要安全威胁来源。随着信息技术的快速发展,工业控制系统中的无线连接、移动存储介质(U盘)、远程维护和升级等新兴技术和应用的广泛使用,为工业控制系统引入了更多的安全风险。

目前工业控制系统广泛的应用于我国电力、水利、污水处理、石油天然气、化工、交通运输、制药以及大型制造行业,其中超过 80% 的涉及国计民生的关键基础设施依靠工业控制系统来实现自动化作业,工业控制系统已是国家安全战略的重要组成部分。

1.2 工控安全与传统安全的区别

工业控制系统以“可用性”为第一安全需求,而传统安全以“机密性”为第一安全需求。在信息安全的三个属性(机密性、完整性、可用性)中,传统安全的优先顺序是机密性、完整性、可用性,而工业控制系统则是可用性、完整性、机密性。这一差异,导致工业控制系统中的信息安全产品,必须从软硬件设计上达到更高的可靠性,例如硬件要求无风扇设计(风扇平均无故障时间不到 3 年)。另外,导致传统信息安全产品的“故障关闭”原则如防火墙故障则断开内外网的网络连接,不适用于工业控制系统,工业控制系统的需求是防火墙故障时保证网络畅通。

为了进一步比较二者,总结如下表所示:


图 2 工控安全与传统安全的对比

1.3 工控安全特点

1.3.1 工业控制系统固有漏洞

各大厂商工控产品都或多或少存在着漏洞,工业领域存在着软、硬件的更新、升级、换代困难等问题。

工业控制系统协议在设计之初就缺乏安全性考虑,存在明文设计、缺乏认证、功能码滥用等安全威胁。

缺乏完善信息安全管理规定,存在U盘管理、误操作、恶意操作等安全威胁。

1.3.2 工业控制系统建设周期长

一般一个大型工业项目建设周期长达 5-10 年,一套工业系统建设调试到稳定需要的周期很长,无法频繁升级。

1.3.3 其他原因

两化融合使得工控系统而临着更多传统IT网络的威胁。

二、学习路线

上面介绍了工控安全的概念、与传统安全的区别和特点,那么接下来将讨论如何学习工控安全的问题。

工控安全是一个多学科,多技术,多领域的交叉门类。本身工控行业的基础专业是自动化专业,自动化专业就是一个多学科的交叉专业,它涉及计算机专业,电气电子专业、仪表专业、通信专业和信息专业等内容。工控网络涉及多个行业,如能源、交通、水利等。多技术包含控制技术、工艺技术、信息技术、网络技术、通信技术、存储技术等等。

作为初学者想开始学习时,却发现无从下手,因为工控安全涉及的知识面太广也太多了,为了广大初学者能够快速学习,特此整理本学习路线,而本学习路线仅展示了工控安全的冰山一角,还希望大家一起学习,一起交流,一起探讨,一起进步。

接下来,将重点介绍如何由浅入深、循序渐进的 Get 工控安全技能。

2.1 基础篇

正所谓万丈高楼平地起,所以基础的重要不言而喻。首先,无论是做工控安全还是程序员,都需要掌握的基本技能,那就是编程语言,建议从汇编、C/C++ 到 Python 的路线学习。

推荐书目:

  • 《汇编语言(第3版)》王爽·清华大学出版社
  • 《C Primer Plus(第6版)中文版》
  • 《Python编程:从入门到实践》
  • 《Python教程》廖雪峰·https://www.liaoxuefeng.com

除了,学习编程语言之外,还需要学习自动化相关知识,比如:自动化设备的基本原理、组成等。

推荐书目:

  • 《传感器与自动检测技术》
  • 《自动控制原理》
  • 《可编程逻辑控制器(PLC)》默里斯·机械工业出版社
  • 《工业控制网络》
  • 《信号与系统》

2.2 进阶篇

经过上面的基础学习,已经有了一定的知识储备,那接下来将学习自动化软件、协议解析两方面内容。

首先,介绍的是自动化软件,自动化软件分为编程软件、组态软件(SCADA 软件)、实时数据库等,具体可按照行业、厂家进行归类了解,深入了解后,再进行跨厂家、跨行业的深度学习。

至于,需要掌握到何程度,比如:会编写 S7 系列 PLC 梯形图、上载、下载等常用的操作。

计算机与计算机、人交流都涉及到协议,协议的重要就不言而喻,所以我们需要学习网络协议,网络协议分为基础协议和私有协议两大类。


图 3 OSI模型(来源:互联网)

基础协议主要涉及 TCP/IP 分层模型有关的内容,包括常见协议的工作原理和特点、缺陷、保护或替代措施等。学习 TCP/IP 方面的知识有很多原因,比如:要适当地实施防火墙过滤,安全管理员必须对于 TCP/IP 的IP层和 TCP/UDP 层有很深的理解、黑客经常使用 TCP/IP 堆栈中一部分区或来破坏网络安全等。

私有协议主要涉及应用层相关内容,常见的工业协议有 Modbus、S7、Ethernet/IP、DNP3、OMRON FINS、IEC104、OPC UA、OPC DA 等,需要学习、分析它的协议结构、工作原理和特点、缺陷、保护或替代措施等,为后续的漏洞挖掘做相应的铺垫。

推荐书目:

  • 《TCP/IP详解 卷1:协议》

既然我们是搞工控安全,那么下面的书籍很有必要读一读:

  • 《工业控制网络安全技术与实践》姚羽等·机械工业出版社
  • 《工业SCADA系统信息安全技术》饶志宏等·国防工业出版社
  • 《工业控制系统信息安全》肖建荣·电子工业出版社
  • 《工业控制系统安全等级保护方案与应用》蔡皖东·国防工业出版社
  • 《工业网络安全—智能电网,SCADA和其他工业控制系统等关键基础设施的网络安全》[美] Eric D.Knapp·国防工业出版社
  • 《智能电网安全:下一代电网安全》 托尼•弗里克·国防工业出版社

2.3 高手篇

经过以上阶段的学习,先想必对工控安全有一定的认识。本阶段主要学习的内容是固件分析和漏洞挖掘两部分。

2.3.1 固件分析

首先,固件逆向分析是在不对嵌入式系统进行实际运行的情况下,通过对固件文件进行逆向解析,分析固件中各代码模块的调用关系及代码内容,从而发现嵌入式系统中可能存在的漏洞及后门的一种技术手段。分析过程中,将会涉及到固件的识别和解压、固件的静态分析等技术。

固件的识别和解压,可以借用一些成熟的工具软件,如:Binwalk、BAT(Binary Analysis Toolkit)等。对二进制可执行文件进行反汇编分析,可以借用一些成熟的工具软件,如:IDA Pro、Capstone 等。

2.3.2 漏洞挖掘

最后,就是漏洞挖掘,也是最为高阶的学习内容,通过前面学习的基础基本就可进入此阶段了,综合利用上述内容对工业控制系统中的设备、软件、网络等内容进行渗透测试。

目前工控漏洞挖掘方法有很多种,常见的方法包括:基于工控协议的模糊测试漏洞挖掘方法、基于固件逆向分析的漏洞挖掘方法、基于工控软件 ActiveX 控件的漏洞挖掘方法、基于 VxWorks 操作系统的漏洞挖掘方法等,我们将会一一进行学习和研究。

三、如何加入?

3.1 加入条件

招收要求:

  • 热衷于信息安全,对信息安全有着不可磨灭的热情;
  • 对工控系统有一定的认知,熟悉或了解一种或多种工控协议 ModBus、S7、Ethernet/IP、DNP3、OMRON FINS、IEC104、OPC UA、OPC DA 等;
  • 熟悉主流的漏洞利用框架及扫描工具,懂得 Fuzz 技术;
  • 英语能力较强,对国外文章进行翻译复现;
  • 掌握至少一门编程语言,如 Python,Java、Lua 等,至少能上手写代码;
  • 人品良好,不将团队内部资料外泄;
  • 有分享精神,每周输出一篇短文章,每月输出一篇长文章(包含但不限于学习经验、学习笔记、总结知识、分析漏洞原理、靶机实验报告);
  • 执行力强,不推诿分内之事,能及时完成分配的任务;
  • 此未参加任何黑产、非法事项。

加分项:

  • 具备攻防能力者优先;
  • 具备设备漏洞挖掘能力者优先;
  • 掌握国内 DCS 相关协议者优先。

3.2 你能得到

加入我们有什么好处呢?

  • 拥有一群志同道合的朋友;
  • 个人技术提升、团队归属感、职业发展;
  • 获得各大公开课、沙龙的参与演讲机会;
  • 在日后工作中可多出一份项目经验;
  • 获得许多团队的内部资料(学习资料、测试环境(PLC、DCS、RTU等)等)及内部福利;
  • 参与论文、团队安全系列图书的撰写。

3.3 加入方式

我是 Ms08067 实验室工控安全小组的 laucyun,如果您想加入我们,一起成长、学习,并且符合以上条件。

请将个人简介发送至 liu#laucyun.com(替换#为@即可),抄送 8946723#qq.com(替换#为@即可),邮件标题为 “[加入申请]-工控安全-xxx”,并包含如下内容:

  • 个人基本情况介绍;
  • 研究方向;
  • 相关技能;
  • 原创文章、研究成果、项目经历等。

...

Tags Read More


工业环境常见勒索病毒的解密工具汇总

by LauCyun May 29 00:36:00 2,234 views

本文转载于https://github.com/jiansiting/Decryption-Tools/,感谢团队成员@剑思庭的分享。

最近应急服务的时候,总是在工控用户方碰上各种勒索病毒,感染工控系统的计算机,以下为日常搜集的勒索病毒解密工具的汇总。

参考链接

...

Tags Read More


2018年工业信息安全技能大赛(东北赛区)解题报告——梯形图运算

by LauCyun Aug 07,2018 10:11:15 11,648 views

前面,《2018年工业信息安全技能大赛(东北赛区)解题报告——工业网络数据分析》介绍了工业控制网络流量部分的解题思路,而本文将介绍梯形图运算部分的解题思路。

0x01 梯形图运算1(200分)

1 赛题描述

赛题如图1所示,附件下载:question_1531222405_8edje2o39d3d.zip


图1 赛题7

启动M0.01DB1.DBD8的运算结果,结果为十六进制结果。

2 解题思路

该题目为工业领域常见的梯形图分析,属于应用编程类的题目,可以使用针对的工控编程软件将其打开进行分析。本题是由西门子STEP7-Micro/Win编写的梯形图算法,有条件的同学可以直接使用STEP7-Micro/Win软件进行分析,没有的同学也不要灰心,请看下面的分析过程。

本题目一并给出了程序的源文件及程序截图,我们可以直接看截图并分析,如图2所示:


图2 程序段1-3

上图2中的内容由三段程序组成,我们一次来分析;

2.1 程序段1分析

本段程序只是一个简单的自锁程序,当M0.01时,Q0.0的输出为1,并且由于Q0.0的输出变成自己的输出,则Q0.0一直保持1的输出。

所以,通过第一段程序,我们知道一旦有M0.01,则Q0.0会一直保持输出。

2.2 程序段2分析

接下来在分析第二段程序的内容:

首先这段程序使用了S_PEXT处理模块,S_PEXT模块是扩展定时器模块,当输入S1时,Q的输出会在TV时间段内保持1的输出,当TV的计时时间到,A的输出就是变为0

所以,在Q0.0保持输出的时间内,Q0.1会产生一个1秒的方波,即Q0.1会维持一个1S内输出为1的状态。

2.3 程序段3分析

首先这段程序使用了MOVE处理模块,MOVE是一个赋值运算器,但输入信号EN1时,MOVE模块会将IN的输入值赋值给OUT指定的存储单元。

所以,此时根据前两段的输出结果,此时DB1.DBD0会被赋值为5.045000e+001

2.4 程度段4分析

程序段如下图3所示:


图3 程序段4-5

首先这段程序继续使用了MOVE处理模块。

所以,在前三段的运行结果上,程序段4的运行结果为DB1.DBD4的值为4.000000e+001

2.5 程序段5分析

首先这段程序使用了MUL_R处理模块,MUL_R处理模块是一个浮点数运算模块,其将IN1IN2的值相乘之后,将值赋值给OUT

所以,在前4段运行结果的基础上,程序段5的运行结果为50.45x40 = 2018,最后将2018换成十六进制为0x07E2

0x02 梯形图运算2(300分)

1 赛题描述

赛题如图4所示,附件下载:question_1531222212_aQiWuoVymW2TtMOY.zip


图4 赛题6

启动M10.01tag_10的运算结果,结果为十六进制结果。

2 解题思路

同样,本题也是梯形图分析,我们可以直接看截图并分析,如图5所示:


图5 程序段1

2.1 程序段1分析

在这里使用到一个TON延时定时器,该定时器为当输入IN1时,定时器开始工作,并大于定时时间pt时,Q输出为1。当IN输入为0时,定时器停止工作并清零。

所以,这段程序是当M10.01时,M10.1会产生一个时间为1秒的方波。并且%MW100的数值为5

2.2 程序段2分析

接下来在分析第二部图型图内容,如图6所示:


图6 程序段2-3

首先这段程序使用CTU处理模块,CTU模块是只加计数器,当输入CU有一个上升沿的时候,就会对CV的输出进行加1处理。当CV的数据达到PV的上限的时候,CV就不再进行计算处理,并且此时Q的输出为1,其他时间Q的输出都为0

所以,程序段2的内容就是%MW110M10.1的脉冲下进行累加1处理,当大于%MW100的时候不在进行运算处理,而此时的%MW110的输出结果为5

2.3 程序段3分析

首先,这段程序使用了MUL处理模块,MUL是一个乘法运算器,但输入信号EN1时,IN1IN2进行乘法运算,并将结果输出到%MW120中。

所以,本段程序的内容就是当M10.11时,并且%MW110中的数据大于或者等于%MW100时,对%MW110中的数据与100相乘并赋值给%MW120中。

此时根据前两段的输出结果,这里的输出结果%MW120的结果为500

2.4 程度段4分析


图7 程序段4

首先,这段程序使用了SWAP处理模块和OR处理模块,SWAP处理模块时将IN的数据的高低字节进行交互,如0x1234的交换结果为0x3412OR处理模块时对IN1的数据与IN2的数据进行OR(与操作)。如0x0012 OR 0x1200的处理结果就是0x1212

所以,本段程序的分析结果就是对%MW120的数据进行高低字节交换后赋值给%MW130。当程序段2中的计数器计算完之后,将%MW130%MW120的数据进行OR操作,并叫最终结果输出到%MW140中,这个就是我们要寻找的结果。

根据程序段3的结果,此时%MW120的数值为500,转换成十六进制是0x01F4,而%MW130的结果为0xF401,在经过OR操作后,%MW140的最终结果就是0xF401 OR 0x01F4运算结束后的结果为0xF5F5

...

Tags Read More


2018年工业信息安全技能大赛(东北赛区)解题报告——工业网络数据分析

by LauCyun Jul 20,2018 00:57:17 28,074 views

当前,随着中国制造2025战略深入推进,工业控制系统从单机走向互联、从封闭走向开放、从自动化走向智能化,安全漏洞和隐患不断涌现、安全事件频繁发生。我国面临的工业信息安全形势日益严峻。

图1 2018年工业信息安全技能大赛(东北赛区)开幕式

2018年工业信息安全技能大赛(东北赛区)分为漏洞挖掘赛和夺旗赛,其夺旗赛大概可分为工业网络数据分析工控固件逆向工控安全分析三个部分。

本文将介绍工业控制网络流量部分的解题思路,当然本文的思路不一定是最好的。仅仅作为抛砖,欢迎大家下载赛题来玩!

0x01 电力工控数据分析1(200分)

1 赛题描述

赛题如图2所示,附件下载:question_1531222544_JYvFGmLP49PFC0R2.pcap


图2 赛题

2 解题思路

考虑到题目是了解MMS规约,发现数据中隐藏的Flag,所以可以先排除非MMS协议的数据包。

用wireshark打开数据包并选择MMS协议进行过滤,如图3所示:


图3 过滤后MMS协议的数据包

经过MMS协议过滤后,共有1838个MMS协议的数据包,发现共有四个PDU(协议数据单元),分别是:Initiate-RequestPDU (启动-请求PDU)Initiate-ResponsePDU (启动-应答PDU)Confirmed-RequestPDU (确认-请求PDU)Confirmed-ResponsePDU (确认-应答PDU),所以把分析的重点放在Confirmed-RequestPDUConfirmed-ResponsePDU中。

通过分析数据包得知MMS协议的规约中Confirmed-RequestPDUConfirmed-ResponsePDU的结构,如下:

  • Confirmed-RequestPDU包含invokeIDlistOfModifiersconfirmedServiceRequestRequest-detail四个部分组成;
  • Confirmed-ResponsePDU包含invokeIDconfirmedServiceResponseResponse-detail三个部分组成。

接下来,先分析一下数据包中的MMS服务,编写脚本提取出数据包中所用的MMS服务并统计,脚本代码如下:

import pyshark

def get_service():
    try:
        captures = pyshark.FileCapture("question_1531222544_JYvFGmLP49PFC0R2.pcap")
        confirmed_services_request = {}
        confirmed_services_response = {}
        for capture in captures:
            for pkt in capture:
                if pkt.layer_name == "mms":
                    if hasattr(pkt, "confirmedservicerequest"):
                        service = pkt.confirmedservicerequest
                        if service in confirmed_services_request:
                            confirmed_services_request[service] += 1
                        else:
                            confirmed_services_request[service] = 1
                    if hasattr(pkt, "confirmedserviceresponse"):
                        service = pkt.confirmedserviceresponse
                        if service in confirmed_services_response:
                            confirmed_services_response[service] += 1
                        else:
                            confirmed_services_response[service] = 1
        # print
        print(confirmed_services_request)
        print(confirmed_services_response)
    except Exception as e:
        print(e)


if __name__ == '__main__':
    get_service()

脚本运行结果如下:

{'77': 4, '4': 17, '12': 26, '6': 211, '72': 72, '1': 351, '73': 44, '74': 9, '5': 32}
{'77': 4, '4': 17, '12': 26, '6': 211, '72': 72, '1': 351, '73': 44, '74': 9, '5': 32}

通过运行上面的脚本,发现数据包中使用到了9个服务,分别是1 (getNameList)4 (read)5 (write)6 (getVariableAccessAttributes)12 (getNamedVariableListAttributes)72 (fileOpen)73 (fileRead)74 (fileClose)77 (fileDirectory)

ConfirmedServiceRequestConfirmedServiceResponse的服务类型,可以参考GBT16720.2-2005 工业自动化系统 制造报文规范 第2部分 协议规范.pdf

接下来就是对服务一个一个的分析,按照服务的出现次数从小到大来分析,先分析77 (fileDirectory)服务的数据包,惊奇的发现数据包第1764个比数据包第266个多一个flag.txt文件,而且文件最后一次修改时间为2018-06-14 11:19:00 (UTC),如图4所示:


图4 获取文件目录的确认应答

可以猜测这个flag.txt文件就是我们所需要的flag信息,接着过滤出与flag.txt文件相关的数据包,如图5所示:


图5 过滤后与flag.txt相关的数据包

从图5中发现数据包中存在读取flag.txt的请求,编写脚本找出flag.txt的文件内容,脚本代码如下:

import pyshark

def flag():
    try:
        captures = pyshark.FileCapture("question_1531222544_JYvFGmLP49PFC0R2.pcap")
        flag_frsm = False
        flag_frsm_id = None
        flag_read = False
        for capture in captures:
            for pkt in capture:
                if pkt.layer_name == "mms":
                    # file open
                    if hasattr(pkt, "confirmedservicerequest") and int(pkt.confirmedservicerequest) == 72:
                        if hasattr(pkt, "filename_item"):
                            filename_items = pkt.filename_item.fields
                            for f in filename_items:
                                file_name = str(f.get_default_value())
                                if file_name == "flag.txt":
                                    flag_frsm = True
                    if hasattr(pkt, "confirmedserviceresponse") and int(pkt.confirmedserviceresponse) == 72 and flag_frsm:
                        # print(pkt.field_names)
                        if hasattr(pkt, "frsmid"):
                            flag_frsm_id = pkt.frsmid
                        flag_frsm = False
                    # file read
                    if hasattr(pkt, "confirmedservicerequest") and int(pkt.confirmedservicerequest) == 73 and flag_frsm_id:
                        if hasattr(pkt, "fileread"):
                            if str(pkt.fileread) == str(flag_frsm_id):
                                flag_read = True
                        flag_frsm_id = None
                    if hasattr(pkt, "confirmedserviceresponse") and int(pkt.confirmedserviceresponse) == 73 and flag_read:
                        if hasattr(pkt, "filedata"):
                            data = str(pkt.filedata).replace(":", "")
                            print(hex_to_ascii(data))
                        flag_read = False
    except Exception as e:
        print(e)


def hex_to_ascii(data):
    data = data.decode("hex")
    flags = []
    for d in data:
        _ord = ord(d)
        if (_ord > 0) and (_ord < 128):
            flags.append(chr(_ord))
    return ''.join(flags)


if __name__ == '__main__':
    flag()

脚本运行结果如下:

61850@102

所以,61850@102就是需要寻找的Flagwink

0x02 工业协议数据分析(300分)

1 赛题描述

赛题如图6所示,附件下载:question_1531222648_ctf03.pcap


图6 赛题

2 解题思路

用wireshark打开下载到的数据包后可以发现数据包中有大量的数据混杂在一起,考虑到题目是工业协议数据分析,因此可以初步排除非工控的协议,留到最后分析。

经过逐步排除后可以发现,数据包中相关的工控流量有Modbus/TCP协议(端口是TCP 502)和西门子S7comm协议(端口是TCP 102),如图7所示:


图7 数据包中的工控流量

接下来只需要进一步分析Modbus/TCP协议及西门子S7comm协议的数据包即可。

Ok,先来分析西门子S7comm协议吧,从数据包中可以发现,西门子S7comm协议中的PDU类型有Job和Ack_Data两种,所以分析起来更加简单了,编写脚本解析出数据包中使用到的西门子S7comm协议的功能码,脚本代码如下:

import pyshark

def get_func_s7():
    try:
        captures = pyshark.FileCapture("question_1531222648_ctf03.pcap")
        func_codes = {}
        for c in captures:
            for pkt in c:
                if pkt.layer_name == "s7comm":
                    if hasattr(pkt, "param_func"):
                        func_code = pkt.param_func
                        if func_code in func_codes:
                            func_codes[func_code] += 1
                        else:
                            func_codes[func_code] = 1
        print(func_codes)
    except Exception as e:
        print(e)

if __name__ == '__main__':
    get_func_s7()

脚本执行后,数据包中所使用的西门子S7comm协议的功能码有0xf0 (Setup communication)(出现2次)和0x04 (Read Var)(出现6196次),但是进一步分析后,发现大量的0x04 (Read Var)都是对DB 1.DBX 4.0进行的读取行为,而且数据(数据是00000000020037000000000c000000002c41)没有变化。因此也可以大致排除西门子S7comm协议中存在Flag的可能。

下一步需要分析的就是Modbus/TCP协议了,同样编写脚本解析出数据包中使用到的Modbus/TCP协议的功能码,脚本代码如下:

import pyshark

def get_func_mb():
    try:
        captures = pyshark.FileCapture("question_1531222648_ctf03.pcap")
        func_codes = {}
        for c in captures:
            for pkt in c:
                if pkt.layer_name == "modbus":
                    func_code = int(pkt.func_code)
                    if func_code in func_codes:
                        func_codes[func_code] += 1
                    else:
                        func_codes[func_code] = 1
        print(func_codes)
    except Exception as e:
        print(e)

if __name__ == '__main__':
    get_func_mb()

脚本执行后,数据包中所使用的Modbus/TCP协议的功能码有1 (Read coils)(出现3220次)、2 (Read Discrete Inputs)(出现3220次)、3 (Read Holding Registers)(出现3220次)、4 (Read Input Registers)(出现3220次)和16 (Write Multiple Registers)(出现228次)。而功能码中的1 (Read coils)2 (Read Discrete Inputs)3 (Read Holding Registers)4 (Read Input Registers)的请求都出现过3220次,且请求的各个寄存器数值一直在不停的变化,看起来比较像正常的工业数据。

所以,接下来编写脚本对16 (Write Multiple Registers)功能码相关的数据包进行分析,脚本代码如下:

import pyshark

def find_flag():
    try:
        cap = pyshark.FileCapture("question_1531222648_ctf03.pcap")
        idx = 1
        for c in cap:
            for pkt in c:
                if pkt.layer_name == "modbus":
                    func_code = int(pkt.func_code)
                    if func_code == 16:
                        payload = str(c["TCP"].payload).replace(":", "")
                        print(hex_to_ascii(payload))
                        print("{0} ###########################################".format(idx))
            idx += 1
    except Exception as e:
        print(e)

def hex_to_ascii(payload):
    data = payload.decode("hex")
    flags = []
    for d in data:
        _ord = ord(d)
        if (_ord > 0) and (_ord < 128):
            flags.append(chr(_ord))
    return ''.join(flags)

if __name__ == '__main__':
    find_flag()

脚本执行后,发现第11779个数据包比较异常,先看一下它的TCP Payload是926d6f64627573494353736563757269747957696e?E K(如图8所示):


图8 隐藏Flag的数据包

可以大胆的猜测6d6f64627573494353736563757269747957696e就是我们需要的Flag,将其16进制字符串转成ASCII字符串后得到modbusICSsecurityWin,所以modbusICSsecurityWin就是需要寻找的Flagwink

0x03 Modbus协议分析1(200分)

1 赛题描述

赛题如图9所示,附件下载:question_1531222756_modbus1.pcap


图9 赛题

2 解题思路

考虑到题目是Modbus协议数据分析,因此可以初步排除非Modbus的协议。

先分析一下数据包中所有使用到的Modbus/TCP协议功能码,同样编写脚本对其进行分析,脚本代码如下:

import pyshark

def get_func_mb():
    try:
        captures = pyshark.FileCapture("question_1531222756_modbus1.pcap")
        func_codes = {}
        for c in captures:
            for pkt in c:
                if pkt.layer_name == "modbus":
                    func_code = pkt.func_code
                    if func_code in func_codes:
                        func_codes[func_code] += 1
                    else:
                        func_codes[func_code] = 1
        print(func_codes)
    except Exception as e:
        print(e)

if __name__ == '__main__':
    get_func_mb()

脚本执行后,数据包中所使用的Modbus/TCP协议的功能码有1 (Read coils)(出现702次)、2 (Read Discrete Inputs)(出现702次)、3 (Read Holding Registers)(出现702次)、4 (Read Input Registers)(出现702次)和16 (Write Multiple Registers)(出现2次)。而功能码中的1 (Read coils)2 (Read Discrete Inputs)3 (Read Holding Registers)4 (Read Input Registers)的请求都出现过702次,且请求的各个寄存器数值一直在不停的变化,看起来比较像正常的工业数据。

16 (Write Multiple Registers)请求只出现了2次,因此比较可疑。 数据包中的16 (Write Multiple Registers)写入到25个连续的寄存器中(如图10所示),我们所需要的flag信息就可能藏在这里。


图10 隐藏Flag的数据包

所以,TheModbusProtocolIsFunny!就是需要寻找的Flagfrown

0x04 S7comm协议分析1(200分)

1 赛题描述

赛题如图11所示,附件下载:question_1531222894_065xYFFV1c3lR5sj.pcapng


图11 赛题

2 解题思路

考虑到题目是S7comm协议数据分析,因此可以初步排除非S7comm的协议。

如下图12所示,可以看到该流量中存在大量的重传现象,因此一种可能是网络中存在中间人攻击,传输的流量可能被截取篡改,而篡改的数据包中就很有可能存在需要的Flag。


图12 数据重传现象

此时可以将过滤后的数据包使用wireshark导出(s7.pcapng)后用scapy工具进行辅助分析是否存在中间人改包及定位数据包位置。

import scapy.all as scapy
from scapy.layers.inet import TCP

if __name__ == '__main__':
    try:
        captures = scapy.rdpcap("s7.pcapng")
        for i in range(len(captures) - 1):
            pkt1 = captures[i]
            pkt2 = captures[i + 1]
            # 只检测push的TCP数据包
            if pkt1[TCP].flags == 0x18 and pkt2[TCP].flags == 0x18:
                # 判断ack和seq重复的数据包
                if pkt1[TCP].seq == pkt2[TCP].seq and pkt1[TCP].ack == pkt2[TCP].ack:
                    if pkt1.load != pkt2.load:
                        print("Find target: packet number: %s" % i + 1)
    except Exception as e:
        print(e)

通过辅助分析后,并没有在数据包中发现被篡改的数据,因此可以排除中间人改包的这个可能。怀疑造成数据包显示大量重放的原因可能与端口镜像配置有关。

接下来就是进一步分析S7comm协议的数据包,但是数据包中没有S7comm协议相关的数据包,有的是COTP协议相关的数据包,所以接下来就是分析COTP协议,先统计一下cotp协议的PDU类型,编写脚本如下:

import pyshark

if __name__ == '__main__':
    try:
        captures = pyshark.FileCapture("s7.pcapng")
        pdu_types = {}
        for c in captures:
            for pkt in c:
                if pkt.layer_name == "cotp":
                    if hasattr(pkt, "type"):
                        type = pkt.type
                        if type in pdu_types:
                            pdu_types[type] += 1
                        else:
                            pdu_types[type] = 1
        print(pdu_types)
    except Exception as e:
        print(e)

脚本执行后,数据包中所使用的COTP协议的PDU类型有0x0e (CR Connect Request,连接请求)(出现12次)、0x0d (CC Connect Confirm,连接确认)(出现8次)和0x0f (DT Data,数据传输)(出现3696次)。从统计的结果来看,一共有12次连接请求,但是只有8次连接确认,所以推测有的连接存在非法信息,这可能就是所需要的Flag。

COTP(ISO 8073/X.224 COTP Connection-Oriented Transport Protocol)是OSI 7层协议定义的位于TCP之上的协议。COTP以“Packet”为基本单位来传输数据,这样接收方会得到与发送方具有相同边界的数据。

COTP协议分为两种形态,分别是COTP连接包(COTP Connection Packet)和COTP功能包(COTP Fuction Packet)。

用wireshark过滤后,如图13所示:


图13 PDU类型是0x0e和0x0d的相关数据包

发现第19933、19938、19946、41010个数据包只进行了连接请求,没有得到192.168.1.13的连接确认,而且19933、19938、19946的src-ref都是0x0001,先重点分析这3个数据包,果然在第19946个数据包中发现了猫腻,如图14所示:


图14 隐藏Flag的数据包

通过对比分析其他16个数据包,可以确定NESSUS就是需要的Flaglaugh

0x05 参考

...

Tags Read More


超过8800个工业物联网云中心暴露于公网——DTU数据中心态势感知报告

by LauCyun Jun 05,2017 16:38:40 6,823 views

国内工业物联网发展迅速,无线数据采集与传输是工业物联网数据通信中重要的采集方式和组网方式,DTU在无线数据采集所涉及到的供热、燃气、气象等市政重点工业领域应用及其广泛。最近我们对国内暴露在互联网的DTU数据中心(DSC)进行了全网扫描,并对已发现的DTU中心站进行了深入的行业应用和用户所属单位分析。

 

一、关键词定义

DTU:数据终端单元(Data Transfer unit)。

DSC:数据服务中心(Data Service Center),即DTU中心站,DTU通过无线GPRS/CDMA网络将数据上传至中心站监听的某个端口。

DDP:DTU和数据服务中心(DSC)之间的通讯协议。

 

二、应用场景

在工业现场中,存在许多现场是有线无法到达的场景,DTU无线数据终端基于GPRS/CDMA数据通信网络,可专门用于将串口数据转换为IP数据或将IP数据转换为串口数据,并通过无线通信网络进行传输,目前广泛应用在电力、环保监测、车载、水利、金融、路灯监控、热力管网、煤矿、油田等行业。

 

三、DTU数据中心指纹特征分析

DTU与DSC中心站通信可使用TCP/UDP方式,DTU会根据配置主动连接DSC中心站IP和开放的数据服务端口进行数据上传。

通信端口

根据厂家和应用的不同,DSC开放的数据上传端口也不尽相同,我们根据厂商官方提供的一些解决方案和文档,搜集了一些知名厂商的默认端口,具体如下:

厂商 默认端口
宏电DTU 5002
深证汉科泰 5003
厦门才茂通信科技 5001
济南有人物联网 5007
聚英电子 5004
拓普瑞GPRS DTU 5000
TLINK 5006
厦门锐谷通信 8002
蓝斯通信 10000
鑫芯物联 2009
四信科技 5020
山东力创 3030

DDP协议(DTU DSC Protocol)是DTU与DSC之间的通讯协议,DDP是一种厂商定义的私有公开性质的通信协议,用于数据的传输和DTU管理,对于DDP协议厂商一般会提供协议文档和SDK开发包,用户可以通过组态软件或开发包,将数据中心集成到自己的平台软件中,国内的组态王、三维力控、昆仑通态、紫金桥等著名组态软件公司也均可以对接DTU实现数据采集。

协议介绍

以DTU市场占有量较高的宏电公司的DTU为例,宏电DDP协议官方提供了通信协议文档和数据中心SDK样例可供用户进行二次开发和集成。

宏电DDP协议数据帧格式
起始标志 包类型 包长度 DTU 身份识别 数据 结束标志
(1B) (1B) (2B) (11B) (0-1024B) (1B)
0x7B         0x7B
宏电DDP协议DTU请求功能类型
包类型  包类型描述  传输类型
0x01 终端请求注册 GPRS
0x02 终端请求注销 GPRS
0x03 查询某一DTU IP 地址 GPRS
0x04 无效命令或协议包(一般在查询或设置指令时使用) GPRS
0x05 DSC接收到用户数据的应答包 GPRS
0x09 DSC发送给 的用户数据包 GPRS
0x0B DTU查询参数的应答包 GPRS
0x0D DTU设置参数的应答包 GPRS/SMS
0x0E DTU提取日志的应答包 GPRS
0x0F 远程升级的回应包 GPRS/SMS

指纹构造

通过构造符合DDP协议的DTU“注册”请求发送到DSC中心站,可以作为识别中心站的一种手段,如果目标应用的端口运行有中心站服务将会返回符合DDP协议标准的数据包。

 

四、安全隐患分析

DTU与DSC中心站之间通信使用的DDP协议构造简单,通信时一般使用DTU中插入的SIM卡的11位手机号码作为“身份识别”的手段,DTU主动链接DSC中心站开放的TCP/UDP端口上传数据,并且以明文方式传输,从目前DTU无线数据远传的通信模型上来看,最易受攻击的攻击面主要在DSC中心站上。

根据我们的本地分析与测试,暴露在互联网的DTU中心站易受到如下攻击:

终端伪造风险

根据DTU与DSC中心站的通信协议,攻击者可以构造任意手机号码(11个字节的DTU身份识别标识)的“注册”请求,如果用户的应用逻辑上没有判断该手机号码是否可信,该设备将可以被注册到DSC中心站。

数据伪造风险

攻击者可以构造任意手机号码(11个字节的DTU身份识别标识)的“注册”请求,并在同一时间或一段时间内发送大量“注册”登录请求到DSC中心站,对于未做身份标识验证和判断的DSC中心站应用将会消耗大量系统资源,甚至导致中心站的采集应用崩溃,所有DTU设备无法链接至DSC中心站,使数据采集中断。

终端枚举风险

DTU与DSC中心站之间使用11位手机号码作为“身份识别”,攻击者如果知道DTU终端的11位手机号码,即可以伪造对应的终端进行数据上传或将终端请求注销,如果确定了该应用场景或准确的地市区,针对终端号码的枚举或爆破将会缩小到较小的尝试范围。

 

五、DTU数据中心联网分布

鉴于DSC中心站各家应用开放端口不一致的情况,我们对国内3亿IP超过160个常用于发布DDP服务的端口进行了识别扫描,其中发现运行有DDP协议服务的主机超过了8800个,具体分布如下:

广东 1998
香港 1052
浙江 710
上海 676
北京 631
广西 556
江苏 500
山东 427
福建 251
河北 212
天津 208
四川 171
湖北 164
辽宁 144
安徽 125
河南 119
云南 99
新疆 88
中国 84
甘肃 81
湖南 80
陕西 73
黑龙江 71
吉林 66
江西 58
山西 57
重庆 48
内蒙古 41
贵州 41
青海 22
西藏 17
海南 17
宁夏 9
总计 8896

发布DDP服务最多的前30个端口:

排行 端口 暴露数量
1 5060 1302
2 9999 1248
3 5002 802
4 60000 575
5 55555 547
6 50123 537
7 51960 418
8 65000 392
9 61697 385
10 2000 296
11 3000 234
12 8000 204
13 6000 108
14 1025 92
15 5001 88
16 6004 87
17 33333 81
18 10001 76
19 5000 75
20 60001 69
21 5007 67
22 5003 61
23 5005 61
24 8001 60
25 4000 56
26 6002 45
27 7001 41
28 7000 40
29 5004 39
30 8888 32

 

六、联网企业与应用分析

根据对扫描到的数据,我们通过IP开放服务、IP位置,分析验证了运行公网的DSC中心站所属的企业和单位,具体行业分布如下,我们目前已经准确验证了超过300家公司和单位的DDP服务暴露情况。

 

七、解决方案与应对策略

在本次针对DSC数据中心站的安全分析的过程中,像终端使用GPRS/CDMA直接经过互联网与中心站的固定/动态IP进行通信,这种快捷、廉价的组网应用广泛,目前虽然没有出现专门针对此类系统公开的攻击事件,但根据我们的判断,对于DDP协议这种ICS协议暴露将缩短攻击者发现重要工业控制系统入口的时间,随着DDP服务的开放易导致该IP目标成为针对性的被攻击对象,我们建议使用此类组网的用户,尤其应该做好边界入口的安全防护、应用服务(Web、Telnet、SSH)的安全加固、主机安全配置。

依据工信部《工业控制系统信息安全防护指南》以及相关国家标准,给出如下具体应对建议:

身份认证

我们建议在互联网开放DDP服务的用户,应检查除DDP服务以外,如Telnet、SSH、Web服务等服务配置的安全性,避免使用默认口令或弱口令,合理分类设置账户权限,以最小特权原则分配账户权限,对于关键系统和平台的访问采用多因素认证。

远程访问安全

我们推荐有条件的用户在中心与终端之间使用电信运营商提供的APN专网进行组网,DTU的SIM卡开通专用APN接入,使用APN专线后所有终端及数据中心分配的IP地址均为电信运营商的内网IP地址,通过APN专网终端与数据中心的数据通信无需通过公网进行传输,专网实现了端到端加密,避免了中心在互联网开放网络端口。

 

点击下载本报告的PDF版本 【PDF下载】,本文转载于灯塔实验室

(全文完)

...

Tags Read More