网络空间测绘核心技术之：协议识别（DCERPC篇）

我一直觉得技术无止境，别人能明确告诉你的每一个单点都不难，难的在于你自己根本找不到这些单点技术，尤其是你完全不知道还有多少个单点技术。所以在技术领域会有一种类似于上学时候的情景，越是学霸的越说好多点不懂，越是学渣的看过两天书确能感觉自己无所不知。在技术层面，我跟同事们讲的很多的是“大家首先是没有发现问题的能力，形成了认为做得很不错的错觉；其次是但凡有一点难度，就连解决问题的能力都没有了，会的都会，不会的都不会”。

所以我写这一系列的文章，一方面当然是给行业输出一点贡献，告诉大家还有很多技术点大家可以做但是还没有做，另一方面，也是想告诉一些同行们“做Demo容易，做满足实用需求的集大成者非常难”。我花一个月完成了最初fofa的上线，但是，接下来的几年时间，我们整个公司都在查漏补缺，我们的目标是“识别所有应该识别的协议，收集所有世界上存在的软硬件指纹规则，录入所有能够被利用的网络类漏洞exp”，在任何场合，只要有超出我们知识体系的内容，我们没有任何借口，马上补齐，哪怕是挨骂，我们也立正站好。

我经常想，在这个世界上最难做起来的是信誉，有了信誉做什么都能成。但是现今社会，最容易做得恰恰也是信誉。因为大多数人没有远大的目标，大家为了生计奔波，为了短时间内物质的回报想要走一些捷径，魑魅魍魉光怪陆离，充斥着各行各业，大家把小聪明当做高人一等的智慧，愿意把时间放在吹嘘而不是脚踏实地做技术沉淀，他们的小算盘是：行业一天一个样，乘机把这个风口的钱赚了，再等下一个风口来，世界从来不缺风口。逻辑是对的，我相信他们也能赚钱，但是，这不就是典型的投机主义吗？这不就是典型的劣币驱逐良币吗？至于口碑什么的，信誉什么的，他们一概不加理睬。两个畸形价值观不绝于耳，既有懂王式的“我不尴尬，尴尬的就是你们”，也有世俗化的“一个有足够多金钱的人，就是本事，就能够指鹿为马”。

所以有时候你什么都不用做，但凡你比别人沉得住气，守得住底线，哪怕什么都不干，在其他人眼里也是“佼佼者”了。不是因为你有多优秀，而是都靠行业衬托。

上次写了rdp这个使用量非常广泛的基础网络协议，我看到有些已经把技术做了补齐，还有一些平台依然一身傲气打死不加。不管怎么样，技术沉淀的量变肯定会在某个时间爆发形成肉眼可见的质变的，所以，咱们再等等，等到大家都从狂欢的过程中稍微安静下来的时候，就都有分辨能力了。

今天我们写一写dcerpc这个协议，这是一个另一个非常非常基础的Windows系统的通信协议，它比rdp协议更普遍，默认开启。由于内容丰富，接口众多，早期的安全人员基于它写了很多蠕虫病毒，一度让微软和运营商非常头疼。dcerpc的默认端口是135，上面承载了包含wmi，有认证就有ntlmssp，还有epmapper等一系列丰富的系统信息，甚至还能获取网卡IP地址列表。

用人话说就是，可以：

- 获取操作系统版本信息

- 获取系统的IP地址列表（是的，你没看错，包含ipv6地址）

- 获取系统的软件服务信息

- 获取系统服务开放的动态端口

- 获取系统的芯片架构（32位/64位）

- 账号的暴力破解（wmi）

好了，我说了这么多，大家会说这些技术应该比较基础，很多其他工具应该都能做到吧？这里特别有意思，我把结论先写出来：目前没有任何一个工具或者平台能够完成全面且准确的信息提取，无论是nmap，metasploit，zmap，还是shodan，censys，zomeye，quake等所有公网平台。网络空间测绘平台或者产品一般是基于两种逻辑：要么是基于nmap/zmap做集成，要么是自己写协议深入识别。事实上，nmap的一个script的小bug导致识别不了，metasploit的那个模块最接近，但是也是一个字节的问题导致dump不了接口，zmap压根就没实现。所以我经常说，不要老迷信国外技术，哪怕是nmap这样的集大成者很多细节功能也欠缺的比较多，我们可以借鉴参考学习，同时也要现在巨人的肩膀上看的更远。

我们分别就这几个效果对应的技术进行说明。

一）默认情况下dcerpc的ping包并不会启动认证流程，当然你可以手动直接带上ntlmssp的包结构，这样对方就会对应的返回挑战信息，里面带有完整的系统版本信息：

看服务器的返回响应包：

在rdp中也是如此，windows在很多接口中只要带有认证属性，基本上都是通过ntlm来进行的，这种情况下都能够利用，往往就给出了大量的系统信息。

二）通过无需认证的epmapper接口，我们可以dump出来所有注册到rpc的程序服务，每一个uuid都能够准确的对应上可执行文件或者服务名称，比如sqlserver等等，这个非常有用。另外对于绑定了TCP端口的高端随机端口，也能返回，省去了全端口扫描的效率问题。

三）通过一个无需授权的接口OXIDResolver接口，调用ServerAlive2（opnum为5），能够得到目标系统网卡的所有IP地址，这个就太有用了。

看看服务器的返回，丰富的宝矿，我甚至认为这绝对算得上是一个信息泄漏的漏洞了。

四）关于wmi的接口认证对应的暴力破解，在我没用go语言写出一个完整的协议实现情况下，我暂时不进行深入说明了。

最后，大家可以通过fofa和goby来完整感受一下完整的实现效果：https://fofa.so/result?qbase64=cHJvdG9jb2w9ZGNlcnBjICYmIHBvcnQ9MTM1

Goby来感受：

鉴于大家对于我提及其他的平台比较敏感，大家可以自行到其他的大网测绘系统或者内网测绘系统看一看，对比对比感受一下。我一直说shodan做的比较稳，就在于他们确实是踏踏实实做了一些细节的，虽然shodan只实现了epmapper的部分，但是相比其他平台只有一对二进制内容（还有大量误报数据），shodan绝对属于稳稳的老大哥。

做个小对比表，大家自行去确认：

由于之前出现大量的蠕虫都是通过smb和rpc接口来进行，所以国内的运营商为了安（sheng）全（shi），大部分地方直接把139/445这两个罪魁祸首进行了端口流量阻断，顺带把135端口也搞掉了。所以国内的很多网络默认从公网是扫描不到的，但是国外还是非常好用的。即便是公网不好用，在内网绝对是信息采集的一个大杀器。未来还有多少是可以挖掘的呢？咱们拭目以待。

最后还是那句话：未来如果有可能，我会引导技术使用方明确把这一点写到招标参数里面去，或者形成标准规范的要求。就是要逼着大家做基础技术研究 ；）

如果大家有兴趣做全球最好的技术研究，愿意沉下心来做技术突破，愿意接受最高难度的挑战，敢于进入无人区做别人没有做过的创新，有种你就加入我们，fofa团队和goby团队随便你挑，来联系我吧！

============ 性感的分割线 =============

补充说明：

1）metasploit的bug与解决

直接扫描的话它的模块做不了epmapper的dump：

为了分析原因，去除干扰，咱们需要关闭fake_bind_multi的设置：

set DCERPC::fake_bind_multi false

可以看到填写的数据为一堆0，在Endpoint Mapper接口中0对应的opnum为insert，导致了报错，明显是作者偷了懒，没有做深入分析。lookuo的opnnum为2。

把 res = dcerpc.call(0, NDR.long(0) * 128)

改成：

res = dcerpc.call(0x02, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00" \

"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" \

"\x00\x00\x00\x00\xf4\x01\x00\x00"

就能看到返回了。

2）nmap的bug

nmap本来就有一个script，名为msrpc-enum是来做epmapper的dump效果的，然而它对135无效，我估计也是作者在后来的改动情况下改出了错误。或者作者也把135跟139/335的smb接口没有梳理的很清楚。基于nmap封装的那些系统，你们稍微留点意，这个懒偷不得。

3）其实还有其他很多工具都实现了一部分功能，比如最近泄漏的canvas，还有impacket，以及rpcdump，或多或少都有一点，我知道对于大家来说已经属于仰望，但是对于我们做网络空间测绘而言，还是不够用。