Scapy-TCP-fuzz v0.3

1 0x01 Bug

之前呢只是用scapy来单纯的实现tcp握手+s7的简单fuzz,当然只是自己觉得这个方法是可行的,写了两个吧,一个是单纯的用socket的,另一个是scapy,然后我现在发现我的脚本跑着跑着就会出一些小问题,看报错的话问题还是出在握手的时候发生了什么不可预知的错误?

2 0x02 think

我猜测可能是这样的,因为从抓包来看的话,设备对于伪造的数据包返回的RST包并没有想象中的那么快,所以在第二轮的发包过程中,接收到了第一轮返回的RST包,所以在这过程中会收到很多keep-alive的数据包,当发包的速度快于回应的速度的时候,积累到一定程度,达到连接上限,然后下一次的连接就自然的失败并且报错了,当然,这只是我猜测的一种情况.

3 0x03 Solution

• 预想的解决办法:

结合socket和scapy来同时实现这个fuzz的功能,通过socket来建立连接,而通过scapy来负责伪造发包等功能,这样是否会相对稳定,感觉在一定程度上控制了重连的频率,关于日志记录,还在想一个更好的方式来记录异常信息,但是更想要通过能实时的解析数据包是最好的选择.

4 0x04 Do it.

两天后.

这两天又折腾了另一个版本的fuzz脚本,之前想要通过socket连接,然后获取端口后在利用scapy进行测试,但是尝试了一下之后发现好像有点儿不是很方便,或者说两者的区别没有太明显?

在上个版本的基础上升级了一下(姑且就当我的折腾是版本的升级吧),在代码中直接添加了scapy的sniff模块来过滤目标IP的数据包,在发送伪造的数据包的下一句执行监听,监听两个数据包即结束监听.

为什么监听两个,当时的设想是可以监听到一个ack和一个rest数据包,但实际代码执行的过程中并没有收到预想中的数据包(sniff到的应该是两个重传包,重传的是设备返回的error code的数据包),所以,同样是有价值的,判断sniff到的两个数据包,可判断伪造数据包的返回状态,丢弃还是记录.

• 需要考虑的一个问题: iptables -A OUTPUT -p tcp –tcp-flags RST RST -j DROP 配置丢掉所有的RST包,那么收到RST包之的时候,谁先对其进行处理,是iptables还是wireshark?那么scapy是怎么样的?

5 0x05 Some supplement

• 通过analysis来粗略的判断返回结果,并决定是否被记录.

• sniffer功能没有想象中的快速,也就是返回ack的速度比执行发送之后执行下一条命令的时间要迅速.因为sniff到两个重传包就是最好的例子,当然不排除代码实现很渣导致这个原因.

• 预想中的sniffer应该是单独的一个功能,通过多进程实现?不断发包的同时实时处理接收到返回信息,以此来判断是否需要重连或者继续发包.

• 我还想把脚本执行过程中的那些正常情况下命令行的回显都隐藏起来,显得简洁,有报错的时候抛出异常就可以.

5.1 Project Source Code:

https://github.com/yizhimanpadewoniu/FuzzScapy

6 0x06 About blog

• 添加了评论功能,虽然我觉得这个功能目前来说确实是很扯淡的.