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

时间：2023-05-06 17:15:02 | 来源：网站运营

时间：2023-05-06 17:15:02 来源：网站运营

网络空间测绘技术之：协议识别（RDP篇）：今年网络空间测绘技术得到了很大的发展，不论大厂小厂都进到了这个领域，宣称自己也有这方面的技术积累和储备。于是身边的领导朋友又开启了“担忧模式”：你们这是不是没有技术壁垒啊？怎么是个公司都宣称有这门技术，连一些独立的个人都如雨后春笋般出来，开发了一套一套的类似平台，连界面都如出一辙，好像一点难度都没有。

这事啊确实怪我们，我们没有承担起相应的责任，没有说清楚关键点和难点在哪里，以及为什么要覆盖这些关键点，后续会用到什么核心的场景。所以不只是跟随者不知道技术pk点在哪里，连商用客户也无法区分出来，导致全天下觉得网络空间测绘技术就是端口扫描和元数据采集，再用一个搜索框一个结果展示页面，就是合格的产品。后来的招标参数一律被引导到端口数协议数ip数以及指纹规则数，当然这些还是很有价值的，但是很多情况真实的技术就被掩盖在了这些单纯的数据下面，导致真正到技术pk的时候，我们丢掉了主要的阵地。就好比选一台车，看的不是强劲的发动机（引擎），而是一个跑车般酷炫的外壳。

我们很长一段时间聚焦在做一个发动机，早期没人关注嘛，所以我用了一个月时间单枪匹马写了一个框架作为Demo上线，得到了大家（更多是的白帽黑客而非企业用户）的反馈，但是接着的五年时间里我们不断地打磨，因为我们发现要深扎下去的点越来越多，可以改进的技术也越来越多，每一个点我们对比了所有大家觉得最好用的工具和产品，都发现好像都只是很粗浅的实现了一小部分，点到为止，大量的新的技术并没有能够很好的融入进去。

就拿协议识别举例，目标IP开放了一个端口，如何识别它对应的协议是什么？协议识别的目的是什么？应该有什么样的流程？如何评价好坏？很多产品用内嵌了nmap来完成这个工作，殊不知nmap带来的坑太多了，他是一个非常重量级的集大成者，涉及的知识点非常多，对应的script和配置项组合是个非常大的数据量，你如果不知道这些细节（至今我不敢自称nmap专家），那么很多内容你就丢弃掉了，识别的效果其实非常差。

网络空间测绘就是绘制“网络攻防地图”，说白了也就是一个情报系统，情报系统最重要的目标就是为决策提供详细且准确的依据。所以衡量协议识别好坏的方法主要有如下几个方面：

一）能否针对一个IP开放的端口进行完整的协议识别，尽可能不要有遗漏。因为很多情况下目标系统可能只开放了很少的业务必须的最小化端口，一个准确的协议识别能够作为非常有效的目标动作的决策依据，比如，那是一个工业互联网的协议。所以，能够识别的协议越多越好，“是否某种协议”是一种简单且有效的初步情报。80不一定是http协议，有可能是ssh协议，这种情况在fofa平台能够看到大量的案例，所以传统简单通过端口号的方法极其不准确。这里牵涉到一个很大的问题：到底有多少种网络协议？

二）能否针对一个协议提取更多的数据内容，为上层的指纹规则提供高价值。用更技术化的语言就是：能否提供更多属性字段（fields）。属性字段有哪些？比如操作系统，软件信息，版本信息，元数据描述信息，硬件架构，中间件信息，网络信息等一系列的深入内容。拿http举例，一个uri对应一个head一个body，head可以分解成server，x-powered-by等属性字段，可以提取各种中间件信息，body字段可以提取title等信息，如果是https还可以提取证书cert信息（内含common name等高价值信息）。但是有一种情况是非常常见的，就是默认的首页uri返回一个404错误信息或者价值信息特别少，但是当你切换到一个预置包含大量价值信息的uri接口时，比如axis的系统信息页，你就知道我在说什么，全是宝库。类似的，一个二进制协议，你发一个/x01代表hello，通过返回的解析确实能够准确的判断协议种类，但是没有更多的信息，如果你改成/x02它可能就是对应info，吐出来大量信息。

三）能否用最少量的数据发包，完成跨版本兼容性，将误报率和漏报率都控制在一个很小的比例。通常一个协议都会有不同的版本，之间可能存在着不兼容，v1和v2的数据格式截然不同。这时候你发了一种版本的request包，那么其他版本的包就没有响应，导致了大批量的漏报。另外你如果只是通过简单的关键字来识别，必然会存在大批量的误报。如果漏报率误报率高于10%，我觉得这个协议识别就没有太大价值了，因为后续还要提供给指纹库来做上层的业务分析，极大地影响真实的使用场景。

情报越全面越详细（广度和深度），基于此给出的决策就越准确；反之亦然，你的情报源都是片面的或者错误百出的，你怎么可能给出正确的决策呢？网络安全跟行军作战是类似的，咱们可以想象一下，在古代帝王准备御驾亲征，一个大臣说能打，因为民心所向，对方奸淫掳掠十恶不赦，出兵必胜；另一个大臣说不能打，因为苛捐杂税民不聊生，洪旱灾害导致哀鸿遍野，同时粮草不足天寒地冻，出兵必败。你是君王，试问你听谁的？多少君王被那些自以为是的拍脑袋的情报坑死。当臣子的做不好情报收集，就不要瞎给决策建议。




说了那么多的理论，我们来聊点实际的案例，一个特别典型的协议叫做RDP（remote desktop protocol）。之所以我会认为比较典型基于如下几个特征：一）使用量巨大，在网络运维过程中跟SSH同等重要，属于Windows系统最小化端口也必然会开启的范畴，作为基础协议大家在做网络管理的时候必须支持；二）协议相对比较复杂，涉及到多个协议的组合，tpkt，tls，ntlmssp等，这里面可深可浅，非常能够区分出来不同网络空间测绘平台技术功底的深浅，如果只开了一个rdp协议，我们能获取到哪些有价值的信息；三）大家对RDP协议的叫法不像http那么习以为常，比如nmap将其命名为ms-wbt-server，大家很容易将协议与产品混为一谈，这就导致了大量的奇葩现象产生，能够反映出大家的一些基础认知差异。

有必要申明一下，为了说明情况，我们会分别从其他一些很不错的平台拿出一些案例，可能会引发一些不适，我只想就技术讨论技术，如果引起了不必要的误会，还请谅解。我们先来看不同平台对于rdp协议解析的不同，我们会从如下g两个方面进行对比：一）协议的解析深入度；二）准确率（漏报和误报）；




zoomeye协议名称叫ms-wbt-server，在发送了一个tkpt包以后，仅仅获取了返回的原始数据作为banner进行了存储，并没有对其进行解析以及深入交互：

一些误报也是比较明显的，比如http协议也被标记为了ms-wbt-server：

如果做过协议深入分析的朋友可能知道，rdp除了最早期的RDP标志位以外，其他的版本默认都会走tls，默认情况下，Windows自带的远程桌面服务里面自动生成的证书，名称对应的就是主机名，新的知识点有没有get?

quake平台很诡异，rdp协议分为了rdp和ms-wbt-server，同时也存在一些初级的误报：

quake进一步提取了tls信息，如上面所说，里面的issuer默认会对应系统的主机名，bingo。

shodan是行业第一个完成了证书提取和截图的平台，也是创新性的完成了图片文本识别平台。恰恰是这种创新，让后来的跟随者简单copy了一下，带到坑里去了。确实某些情况下能够根据文本粗略的判断操作系统信息，这种方式虽然有用，但是及其低效且错误百出。

比如如果截图失败还能获取操作系统信息吗？可以看到提取的文本为空。




其实还有一个知识点大部分人没有掌握，而很早在nmap中就进行了实现：就是在进行tls连接后会进行ntlmssp的挑战响应，能够非常准确的提取出来主机名和操作系统的版本。我们通过Goby的一个界面来感受一下效果：

在协议识别过程中，在协议解析方面不能偷懒，在协议流程学习方面也不能偷懒，实话说，这已经比看二进制的漏洞调试容易太多了，尽管如此大家还是沉不下心来。




我们可以整理一个对别表：

再整理一个rdp协议不同的类型影响的效果，不是每一个实现都能截图，如果强制开启了CredSSP，那么截图就失效了；另外如果只启用了PROTOCOL_RDP，那么暴力破解就无效了，这也是为什么hydra和medusa等大量不兼容的问题：

几个遗留问题的集中解答：

一）协议名称到底叫rdp还是ms-wbt-server？

我个人的看法是叫做rdp合理得多，比如rdp协议是一种网络协议，实现这个协议的服务器和客户端产品都不相同，微软实现的第一版本早期只有它自己，所以我们叫Micorsoft Windows Based Terminal (WBT)还说的过去，但是加上Server就不对了，这明显是一种产品的实现，尤其是后来有了各种linux上面实现的开源版本，你还叫ms-wbt-server明显不合理，人家可以是freerdp-server啊。所以由于历史的原因，未必当时的命名就是合理的，我们需要对其进行改进。对于既有rdp还有ms-wbt-server的平台，我只能说太不用心了，要么是复制了别人的数据，要么是重复堆叠（拼数据量还是不用心）。

协议是协议，产品是产品，厂商是厂商，这些需要做好区分。

二）协议识别要支持多少种才算完善？

大家很容易盲目地去追求数量而不是质量，无论是以前的漏洞数还是现在的指纹规则数。wireshark加上nmap一起可以支持几千种协议规则，但是实例上意义不大。说的再直白一点，咱们自己局域网的协议识别全了么？一个网络设备放在那，眼跟前的设备你都识别不了，谈什么识别所有。

举个例子，我们内部把协议分为ABC三类协议，A类协议属于你必须发一个正确的request包，服务器才会返回response，比如rdp协议；B类协议就是主动response，不需要你请求的，比如ssh协议；C类协议就是你需要你发request，但是哪怕格式不对也会返回错误信息的response，比如http协议。对于一个开放了非标准端口的A类协议，你如何确认是哪一个？你是准备几百个协议挨个遍历吗？如果考虑网络等待超时，一个端口的协议识别一次需要几分钟？

这个问题是个选择问题，可能未来会有一个算法来证明最有效的方案，但是现在还没有。我们的协议引擎已经能够自动化高效率的用少量包筛选出B类协议和C类协议，但是对于A类，会用最top的几个去做尝试，没法全遍历。




最后，我想说，行业还是要做好技术沉淀的，不是老是商务模式致胜，客户关系致胜，以及PPT致胜，我希望在技术上大家应该都能达到一些基础的要求才能宣称具备了网络空间测绘的能力。所以未来如果有可能，我会引导技术使用方明确把这一点写到招标参数里面去，或者形成标准规范的要求。可以想象到，大家看完这篇文章会沉下心来至少把这个协议的技术做好（不然测试无法正偏离啊），也算我们对行业做了些许贡献，有效区分一下混水摸鱼的主。大家沉下来踏踏实实做个五年，我相信行业就能更好的引导到技术突破上来，形成良性竞争的局面。