工控CTF中常见题型介绍(上) | 您所在的位置:网站首页 › udp传输的最大值 › 工控CTF中常见题型介绍(上) |
前言 去年参加了几场工控CTF比赛,基本都在坐牢。闲暇之余对工控CTF中常见的题型进行学习。 赛事介绍工控CTF题目主要以流量分析、无线电分析、组态分析、梯形图等方向为主,偶尔有逆向分析、日志分析等相关分析题目。相关赛事较少,赛事主办方以政府为主,常见的有每年的ICSC/IISC国赛及其各省的选拔赛/省赛。线下赛有工业网络渗透实战、工业应急响应等赛制,主要考察渗透和运维能力。 工控协议分析常见的工控协议有:Modbus、MMS、MQTT、COTP、IEC104、IEC61850、S7COMM、OMRON等。由于工控技术起步较早但是统一的协议规范制定较晚,所以许多工业设备都有自己的协议。题目考点主要以工控流量和恶意流量为主,主要考察Wireshark使用和找规律,部分难度较高的题目主要考察协议定义和特征。 ModbusModbus协议是工控领域最常见的协议之一,也算是工控CTF中最常见题型。 Modbus/RTU 从机地址1B+功能码1B+数据字段xB+CRC值2B 最大长度256B,所以数据字段最大长度252BModbus/ASCII 由Modbus/RTU衍生,采用`0123456789ABCDEF`表示原本的从机地址、功能码、数据字段,并添加开始结束标记,所以长度翻倍 开始标记`:`1B+从机地址2B+功能码2B+数据字段xB+LRC值2B+结束标记`\r\n`2B 最大长度513B,因为数据字段在RTU中是最大252B,所以在ASCII中最大504BModbus/TCP 不再需要从机地址,改用UnitID;不再需要CRC/LRC,因为TCP自带校验 传输标识符2B+协议标识符2B+长度2B+从机ID 1B+功能码1B+数据字段xB题目中最常见的是Modbus/TCP协议,主要原因是抓包方便。Modbus常见功能码: 1:读线圈 2:读离散输入 3:读保持 4:读输入 5:写单个线圈 6:写单个保持 15:写多个线圈 16:写多个保持 IISC河南省赛2022初赛《HNGK-Modbus协议分析》题目要求:分析文件找出flag 首先依次筛选常见功能码,筛选到功能码为3的返回包:可以选择筛选返回包中的来源ip地址,来筛选出response包 ((modbus) && (modbus.func_code == 3)) && (ip.src == 192.168.161.2)因为功能码显示read,所以判断看返回包,发现有报错的数据包。通过筛选byte count字段,筛选出有数据的响应包 (((modbus) && (modbus.func_code == 3)) && (ip.src == 192.168.161.2)) && (modbus.byte_cnt)查看响应包数据,发现响应包每条会增加一些字符 将值复制出来 #=$@%&$=!!%!!$! "=$&$!""#!"@$@!'% $$#但是发现复制的值中间有欠缺,所以复制hex16进制,然后找过字符的开头和结尾进行去除,然后转码 0023003d0024004000250026002400260023003d00210021002500210021001f0024001f002100200022003d0024002600240021002200220023001f0021001e00220040002400400021002700250020002400240023以下步骤目的是为了将00去除第一步:将hex转换
MMS主要有2种类型: initiate(可以理解为握手) initiate-RequestPDU initiate-ResponsePDUconfirmed(可以理解为交互) confirmed-RequestPDU confirmed-ResponsePDU通常情况为: 1轮initiate 即发送1个initiate-RequestPDU,接收1个initiate-ResponsePDUn轮confirmed,直到会话主动关闭或被动断开 即confirmed-RequestPDU和confirmed-ResponsePDU交替发送和接收交互时的指令称为confirmedService 对象操作 read (4) write (5) getVariableAccessAttributes (6) getNamedVariableListAttributes (12)文件操作 fileOpen (72) fileRead (73) fileClose (74) fileDirectory (77) IISC河南省赛2022复赛《HNGK-MMS》题目要求:分析文件找出flag 根据题目名称过滤出MMS数据包,发现前两个包为请求握手,观察第三个包发现read为4 过滤read不是4的包,发现没有。证明全是4 (mms) && (mms.confirmedServiceRequest != 4)然后再找其他数据段发现itemId数据不一样,仔细观察都是LLN0开头 过滤LLN0开头的数据 选中过滤器 (mms) && mms.itemId contains "LLN0"然后过滤一下非FFNO的数据,发现三条数据 (mms) && mms.itemId &&!(mms.itemId contains "LLN0")通过观察比较发现数据疑似ascii码,因为ascii码中f为66、l为6citemId: LLN666i5250356j4249itemId: LLN616732557968356jitemId: LLAy7sxCA9wSYrVLCbr 将字符串中的字母部分转换,构建为666c为flag的fl开头 所以使用正则先将字母提取出来,然后进行减法,让i变为c发现减6变成c 然后使用merge合并,转成hex发现得到flRP5mBIag2Uyh5m 观察发现应该为2个字节换了下一段flRP5mBIag2Uyh5m 拼接后flag为: 子协议 IEC 101(任务相关) IEC 102(电量相关) IEC 103(保护相关) IEC 104(101的网络版) IEC ASDU(基于101/104的应用服务数据单元传输)主要技巧 筛选`iec60870_asdu` 关注IOA的值 可尝试用type进行分类 IISC河南省赛2022复赛《HNGK-IEC协议分析》过滤协议发现有错误的数据包,并且随便点数据包,发现分组不同说明建立了很多不同的连接 过滤分组为0的数据包,这样得到的为同一个连接的数据包,数据也是连贯的 iec60870_asdu && tcp.stream == 0然后筛选有IOA Value值的数据 再去筛选TypeId: M_ME_TD_1 (34)发现对应的ioa的值,无规则,并且右下角数据包过多 继续筛选除去TypeId: M_ME_TD_1 (34)后的包,发现TypeId: M_ME_TD_1 (9)也有100多数据包,然后除去34和9,之后发现只剩18条数据 (((iec60870_asdu && tcp.stream == 0) && (iec60870_asdu.normval)) && !(iec60870_asdu.typeid == 34)&& !(iec60870_asdu.typeid == 9))将值提取,base64解码后发现为乱码 Mzhx3ZKtTOTJ0VadnNYdVSnlUUBNQf== 分析发现两个字节组成一个数据,猜测为颠倒数据(两字节一数据有可能为颠倒的) 调换位置获取flag mZhx3ZKtTOTJ0VadnNYdVSnlUUBNQf==ZmxhZ3tKOTJTV0daNndYSVlnUUNBfQ==flag{J92SWGZ6wXIYgQCA} MQTT主要数据交互的消息类型为PUBLISH 筛选mqtt.msgtype == 3 服务端有若干个主题(topic)可供客户端订阅 客户端订阅后可以收到来自服务端关于这个主题的消息(message) 一个主题可以持续产生消息 ICSC济南站2020《工业物联网智能网关数据分析》首先查看协议占比,大致判断为mqtt的题目1、筛选mqtt.msgtype == 3的时候有数据 (mqtt) && (mqtt.msgtype == 3)
放入010粘粘hex,然后保存为rar,解压发现文件损坏 COTP可以理解为基于TCP的工控TCP COTP主要有五种类型: CR Connect Request (0x0e) CC Connect Confirm (0x0d) DT Data (0x0f) UD User Data (0x04) ED Expedited Data (0x01)CR和CC只在建立连接时由双方发送,发起方发送CR,被动方发送CC,后续数据主要走DT 因为协议类似于TCP,较为底层,所以没有其他比较有用的协议字段可供解题 ICSC济南站2020《COTP》题目:找到黑客流量,flag为后90字节的16进制1、过滤cotp流量,发现第一个流量包没有请求握手流量,反而直接是数据传输 2、过滤掉分组0,查看其他分组cotp && tcp.stream != 0发现是一个完整的请求 S7基于COTP 主要有3种类型(ROSCTR) Job (1) - Ack_Data (3) / Ack (2)10种功能(Function) Setup communication (0xf0) Read Var (0x04) Write Var (0x05) 下载 Request download (0x1a) Download block (0x1b) Download ended (0x1c) 上传 Start upload (0x1d) Upload (0x1e) End upload (0x1f) PI-Service (0x28) Userdata (7)6种功能组(Function group) Mode-transition (0) Programmer commands (1) Block functions (3) CPU functions (4) Security (5) Time functions (7) ICSC湖州站2020《工控协议数据分析》题目:通过协议分析获取flag1、查看协议占比发现该题考察点为s7comm,然后通过筛选发现read中data没有flag的痕迹 Command CODE比较多,关注点主要在读写,如: Memory Area Read (0x0101) Memory Area Write (0x0102) Multiple Memory Area Read (0x0104) Memory Area Transfer (0x0105) Parameter Area Read (0x0201) Parameter Area Write (0x0202) Data Link Table Read (0x0220) Data Link Table Write (0x0221) Program Area Read (0x0306) Program Area Write (0x0307) ICSC线上2021《Fins协议通讯》打开压缩包发现key 基于各类数据传输协议的数据传输功能,实现的数据传输都可以称为隧道。如:基于TCP的隧道、基于UDP的隧道、基于ICMP的隧道。 CISC兰州站2021《DNS》1、通过大致翻阅,发现查询了奇怪的域名
某行业特有的一些通信协议,比较少见。 ICSC济南站2020《司机的身份》题目要求:找到卡车司机的身份信息下载文件附件t808_info,为交通运输行业标准和流量包
本篇因freebuf存在图片数量限制,本篇只是总结了工控ctf中协议分析相关题目的解题方法。对于工控ctf中逆向分析、组态分析、梯形图相关题目放到下一章节进行讲解。 |
CopyRight 2018-2019 实验室设备网 版权所有 |