网络空间测绘核心技术之:协议识别(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的包结构,这样对方就会对应的返回挑战信息,里面带有完整的系统版本信息:

网络空间测绘核心技术之:协议识别(DCERPC篇)

看服务器的返回响应包:

网络空间测绘核心技术之:协议识别(DCERPC篇)

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


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

网络空间测绘核心技术之:协议识别(DCERPC篇)


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

网络空间测绘核心技术之:协议识别(DCERPC篇)

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

网络空间测绘核心技术之:协议识别(DCERPC篇)

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


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

网络空间测绘核心技术之:协议识别(DCERPC篇)

Goby来感受:网络空间测绘核心技术之:协议识别(DCERPC篇)



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

网络空间测绘核心技术之:协议识别(DCERPC篇)

做个小对比表,大家自行去确认:


NTLM信息提取
EPMapper提取
ServerAlive2
shodan -

-
censys
-
- -
zoomeye -
- -
quake
-
-
-
fofa


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

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

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



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

补充说明:

1)metasploit的bug与解决

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

网络空间测绘核心技术之:协议识别(DCERPC篇)

为了分析原因,去除干扰,咱们需要关闭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,或多或少都有一点,我知道对于大家来说已经属于仰望,但是对于我们做网络空间测绘而言,还是不够用。


版权归原作者所有,如若转载,请注明出处:https://www.ciocso.com/article/535.html

发表评论

登录后才能评论