看zwell怎么带我解决方程式poc的bug

由于工作上的需要，我用到python的次数越来越多了。

这天，zwell看到我刚回公司，就让我继续poc的转化与录入。

而刚好，一些客户没有从勒索病毒“永恒之蓝”的阴影中走出来。我要将MS17010的漏洞poc录进fofa里面。

在同事们的建议下，我决定将巡风的POC转化回ruby。

在t00ls有哥们说我本末倒置了~巡风的POC就是从MSF的EXP转的，而MSF的exp是ruby写的，囧。

其实不是我不想用MSF的shellcode，而是刚学习ruby，暂时没有这个能力读懂框架的代码，二来巡风的也是将MS17010的exp整合的很好。看一下其他的python版本的poc都是要分版本的，要么就是调用方程式黑客武器的那个xml和exe文件实现的。

这里贴出巡风的脚本，有点长，看官们抱歉,用力一滑就下去了~

#-*- coding: UTF-8 -*- import binascii import socket fofaquery = 'protocol=smb&& banner="windows"' def get_tree_connect_request(ip, tree_id): ipc = "005c5c" + binascii.hexlify(ip) + "5c49504324003f3f3f3f3f00" ipc_len_hex = hex(len(ipc) / 2).replace("0x", "") smb = "ff534d4275000000001801280000000000000000000000000000729c"+ binascii.hexlify( tree_id) + "c4e104ff00000000000100" + ipc_len_hex + "00" + ipc tree = "000000" + hex(len(smb) / 2).replace("0x", "") + smb tree_connect_request =binascii.unhexlify(tree) return tree_connect_request def check(ip, port, timeout): negotiate_protocol_request =binascii.unhexlify( "00000054ff534d4272000000001801280000000000000000000000000000729c0000c4e1003100024c414e4d414e312e3000024c4d312e325830303200024e54204c414e4d414e20312e3000024e54204c4d20302e313200") session_setup_request =binascii.unhexlify( "0000008fff534d4273000000001801280000000000000000000000000000729c0000c4e10cff000000dfff0200010000000000310000000000d400008054004e544c4d5353500001000000050208a2010001002000000010001000210000002e3431426c7441314e505974624955473057696e646f7773203230303020323139350057696e646f7773203230303020352e3000") try: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) s.connect((str(ip), int(port))) s.send(negotiate_protocol_request) s.recv(1024) s.send(session_setup_request) data = s.recv(1024) user_id = data[32:34] session_setup_request_2 =binascii.unhexlify( "00000150ff534d4273000000001801280000000000000000000000000000729c"+ binascii.hexlify( user_id) + "c4e10cff000000dfff0200010000000000f200000000005cd0008015014e544c4d53535000030000001800180040000000780078005800000002000200d000000000000000d200000020002000d200000000000000f2000000050208a2ec893eacfc70bba9afefe94ef78908d37597e0202fd6177c0dfa65ed233b731faf86b02110137dc50101000000000000004724eed7b8d2017597e0202fd6177c0000000002000a0056004b002d005000430001000a0056004b002d005000430004000a0056004b002d005000430003000a0056004b002d00500043000700080036494bf1d7b8d20100000000000000002e003400310042006c007400410031004e005000590074006200490055004700300057696e646f7773203230303020323139350057696e646f7773203230303020352e3000") s.send(session_setup_request_2) s.recv(1024) session_setup_request_3 =binascii.unhexlify( "00000063ff534d4273000000001801200000000000000000000000000000729c0000c4e10dff000000dfff02000100000000000000000000000000400000002600002e0057696e646f7773203230303020323139350057696e646f7773203230303020352e3000") s.send(session_setup_request_3) data = s.recv(1024) tree_id = data[32:34] smb = get_tree_connect_request(ip, tree_id) s.send(smb) s.recv(1024) poc = binascii.unhexlify( "0000004aff534d422500000000180128000000000000000000000000"+ binascii.hexlify( user_id) + "729c" + binascii.hexlify( tree_id) + "c4e11000000000ffffffff0000000000000000000000004a0000004a0002002300000007005c504950455c00") s.send(poc) data = s.recv(1024) if "\x05\x02\x00\xc0" in data: return True return False s.close() except Exception,e: #print str(e) return False def verify(hostinfo): ip,port= hostinfo.split(":") result = check(ip,port,5) return result if __name__ == '__main__': print verify("10.10.10.230:445")

我根据其思路，将其转化为ruby的poc在foeye中使用。

Fofa的框架远比其他的框架简单…

可是发现运行的时候~

卡在这边，百思不得骑姐？？？

加了begin和rescue..end也没有爆出什么异常。

按Ctrl+c发现连接被重置， excuse me？shellcode完全和python的一模一样啊。

检查了几遍程序发现没有语法问题，也没有逻辑问题。

可是之前没有出现这个问题啊，扫描的时候能扫出没有补丁的还有关闭445端口的，但是扫到有漏洞的时候总是卡死在一个界面。

龙大侠说，小伙子啊，你这样不给力啊T T。

心怀不惩的我去吃饭，老板将最后一口饭吃下去之后，抿了下嘴巴，说半小时搞不定来找我。

…..

半小时后，我真的去找他了。

下面是他表演的时刻，文笔有限，尽量还原当时的情景。

首先，我将环境给他看了下，他说肯定是你shellcode哪些字符出问题。

我：不可能啊，都是复制粘贴进去的。

他：你能保证你发的包出去就是对的？

我：…

他：来，环境搞好。

我汹汹打开虚拟机

多么精致的2003R2啊，可惜我就是没有把poc弄好。

首先 确认ip

用python的脚本检测一发， 既然巡风发了，那么肯定是没有问题的了。

用python检测只是为了确定这个系统存在漏洞，可以验证poc。

提示true，说明存在漏洞。（值得一提的一点是发送错误的payload会让之后正确的payload也利用失败，这个时候请重启）

那么这时候我们开启wireshark抓包再次利用一下。

设定如下：

将抓取到python发送的数据包保存为230_ok.pcapng

用ruby发包，抓取ruby发送的数据包保存为230_ruby.pcapng

其中ruby爆出的异常是这个，也就是第四次发送数据包的时候出错，那么也就是在第三次接收数据包的时候，第四次发送的时候出问题。

按照出异常的经验，一般是前面那个。

然后我分析了第三次数据包，发包和收包都要分析。

这个漏洞是基于445端口的SMB服务。所以我们分析的时候肯定看SMB这个写的包了。

第三次发包也是这个，果不其然。

右边是ruby的包，左边是python的包。右边变红了，这个比股票变绿了可怕。

复制出数据包的Hex值发现明显不对。相同的poc为何发送的数据包不一样呢？

难道是ruby的Hex解码和python的Hex解码有差异？

Zwell很笃定的告诉我这个是不可能的…

后面发现是ruby和python语言特性的差异害苦了我。

Zwell怀疑是：ython中的切片和ruby中的字符串截取不一样。

打开ruby的调试环境，irb

定义一个变量a=’10086’

a[2..4]做一个切片，我们从中可以看出a在内存的位置是从0算起的，2~4就是‘086’，共三位。

再看看python

运行的结果是08，python的切片是最后一位属于界定位，不包含在内。

所以将ruby中的切片改为：[32:33]就行了。

Ok，还有一个小坑就是，

在 ruby中会自动对字符识别做转换，在python中不会，所以ruby在对比的时候就会报错，解决的方法就是加一个编码转化。

然后放一下扫描的图片。

总结下，要使用一门语言还是要学习深入一点~

而ruby我都没学过(/ □ \)没办法，硬着头皮上了~重要的还是细心，一步步解决问题明显很迷人~~

打个小广告，欢迎体验fofa~~ 一群老司机在群里等你~~