【技术分享】Scapy Fuzz实现——S7协议从建连到“正常交流“(二)

【技术分享】Scapy Fuzz实现——S7协议从建连到“正常交流“(二)

2017-08-07 14:03:47

阅读：438次
点赞(0)
收藏
来源：安全客

【技术分享】Scapy Fuzz实现——S7协议从建连到“正常交流“(二)

作者：DropsAm4zing

【技术分享】Scapy Fuzz实现——S7协议从建连到“正常交流“(二)

作者：DropsAm4zing

预估稿费：300RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

传送门：http://bobao.360.cn/learning/detail/4120.html

上次酝酿了"三秒钟"，这次还是酝酿的久一点。这次继续上次的点和思路，把这个很low的小程序跑起来，先放一张运行截图做封面，自己总会认为我这个小屁孩这就是在班门弄斧，所以也就尽量的把自己的东西总结好，希望做好。

0x01 关于Set Communication

上次写到建立三次握手、S7协议握手数据包的重放，在文章的最后贴了自己写的建立连接的hello_plc()函数，其中通过Scapy发送数据并接收返回的响应数据包，Scapy接收到的数据格式是元组格式，我们只需要通过诸如“a[1][1]”这样的方式来访问取值，但还可能遇到问题，具体问题只能根据具体情况解决了。

0x02 数据格式

我们通过Wireshark可以看到，交互中的数据基本是“00 01 02 03 ……”这样的方式，如果我们通过TCP调试工具发送数据的当然是可以成功发送并接收数据，但是放到脚本里发送这样的格式会成功么？

答案很明显，肯定是会失败的，怎么搞?

姿势一：

hello='\x03\x00\x00\x16\x11\xe0\x00\x00\x00\x05\x00\xc1\x02\x01\x01\xc2\x02\x01\x01\xc0\x01\x0a' hello_respon="\x03\x00\x00\x16\x11\xd0\x00\x05\x00\x01\x00\xc0\x01\x0a\xc1\x02\x01\x01\xc2\x02\x01\x01" set_comm="\x03\x00\x00\x19\x02\xf0\x80\x32\x01\x00\x00\xcc\xc1\x00\x08\x00\x00\xf0\x00\x00\x01\x00\x01\x03\xc0"

上面的姿势可以通过脚本直接发送到设备并建立连接是没有问题的，需要你将“00 01 02 03 ……”通过处理变为上面的变量格式发送交互数据。

针对于建立连接过程，数据内容基本是固定的，所以直接转换格式固定发送即可，但是Fuzz测试的时候，可能需要准备专门的函数来转换格式发送，自认为比较麻烦，所以弃用。

姿势二：

测试的时候我们通过Wireshark来获取数据包的内容进行修改重放，所以我们看到的实际是十六进制的ASCII显示，我们需要转换到可直接传输的格式。

defstr2byte(data): base='0123456789ABCDEF' i=0 data=data.upper() result='' whilei<len(data): beg=data[i] end=data[i+1] i+=2 b1=base.find(beg) b2=base.find(end) ifb1==-1orb2==-1: returnNone result+=chr((b1<<4)+b2) returnresult

相比较上一种方法自觉比较简单粗暴，选用。为什么自己愿意选用这个方式，因为发送的数据遵循固定的报文格式，所以Fuzz可以针对一个特定部分或者几个特定部分进行，随机产生Fuzz数据后，直接拼接为原始数据，然后经过转换直接发送即可。

hello=010203040506070809Fuzz原始数据(假设此处为四位整数)0504030201 fuzz原始数据=random.randint(1000.9999) fuzz_data=str2byte(hello+fuzz原始数据)

上面对fuzz数据的产生过程做一个简单的解释，我们可以看到fuzz数据通过随机生成，通过拼接，再转换格式即可发送交互。实际情况是每个部分的数据进行拼接之后进行处理并发送。

0x03 模糊数据

那么模糊数据怎么产生并处理呢？

defrandom_String(n): random_string=(''.join(map(lambdaxx:(hex(ord(xx))[2:]),os.urandom(n)))) returnrandom_string

通过上面的函数产生指定长度的模糊数据，这里仍然存在问题，一些功能对应的数据报文是如“000a”这样的格式，而上面的函数只能生成如“a”、“2012”，不能生成前面为0的格式的数据(如“0001 001a”)，当时被坑惨了，然后一步步输出调试的时候才发现使这里除了问题。

zfill()函数: 这个函数解决了上面的问题，str.zfill(width)通过width指定字符串的长度，原字符串右对齐，在前面补0.

Protocol_ID='32' ROSCTR=ROSCTR_dict[random.randint(0,1)] Redundancy_Identification='0000' Protocol_Data_Unit_Reference=random_String(2).zfill(4) Parameter_Length='0008' Head_Data_Length=( hex( ((int(TPKT_Length,16))*2-14-36)/2 )[2:]).zfill(4) Header=Protocol_ID+ROSCTR+Redundancy_Identification+Protocol_Data_Unit_Reference +Parameter_Length+Head_Data_Length

上面这是一段自己定义的通过Wireshark识别之后，数据报对应的各个部分的数据内容，有些部分是固定的格式，那么暂时不做Fuzz，那些保留字段或者可变字段，进行随机生成处理。Wireshark内置了对S7协议的分析代码，可以下载源码进行查找分析。下面就来看看S7协议相关的一些点。

Wireshark已经针对数据中的每个部分做了解析，所以在学习了解S7协议的时候，Wireshark是必不可少的工具之一，通过Wireshark的解析，我们清楚的看到包括TPKT、COTP、S7 Communication这三个大的部分。大概结构如下:

TPKT包含了Version、Length和一个保留参数

COTP包含了Length、PDU类型和一个我不知道含义的参数(PS:为自己的无知捏一把冷汗)

S7 Communication包含了Header、Parameter、Data

我们的Fuzz目标针对于S7 Communication部分，前两部分的参数相对固定，我们一定要注意的是每部分中的“Length“对应的含义。

TPKT: 含有Length参数，表示整个数据的长度

COTP: 含有Length参数，表示COTP除Length参数之外的长度

Header: S7协议的Header部分，含有Parameter Length和Data Length参数，分别表示Parameter和Data的长度

Parameter: S7协议的Parameter部分，含有Parameter Length参数，表示这部分此参数之后的数据长度。

Data: S7协议的Data部分，含有Length参数，表示Data部分data的长度

0x03 运行日志

通过上一部分对数据格式的了解，Fuzz脚本已经可以实现出来，我们继续讨论完善，如何判断Fuzz数据是否对设备造成了影响(比如: 设备状态异常)？如何实时的保存造成设备异常的报文呢？

deffuzz_analysis(data): iflen(data[0])==0: fuzzlog.write("%s\n"%binascii.hexlify(data[1])) else: errorlog.write("%s\n"%binascii.hexlify((data[0][1][2].load)[-2:])) rst=TCP(sport=sport,dport=dport,flags='R',seq=data[2].ack) send(ip/rst)

我是通过上面的代码来处理的，发送Fuzz数据之后，判断返回的数据，并分别记录在不同的日志当中，判断数据的方法还是通过Scapy返回的数据格式，以元组的方式取值判断。

为什么要在记录日志之后发送一个RST数据包？

rst=TCP(sport=sport,dport=dport,flags='R',seq=data[2].ack)

在Fuzz数据发送之后，我无法判断发送的数据是否生效，所以自己用了最笨的办法，发送一个RST数据报，重置断开连接。下面的流程展示了整个脚本的运行过程和实现流程。