CVE-2019-0708漏洞影响面分析及采用多种规则的检测方法

概述

近期，随着CVE-2019-0708漏洞的公布，大多数安全社区都将该漏洞作为最优先处理的漏洞之一。提到漏洞修复，很难不联想到此前WannaCry和NotPetya产生的灾难性后果。并且根据之前的经验，我们非常清楚，用户往往不会立即修复漏洞，而是需要比较漫长的一段时间。因此，针对这一高危漏洞，我们有必要迅速制定该漏洞的检测规则。

关于CVE-2019-0708漏洞，有一个比较关键但非常重要的细节，该漏洞与远程桌面服务（Remote Desktop Services）有关，也就是在Windows上由Microsoft实现的远程桌面协议（RDP）。RDP协议本身是没有问题的，我必须要提到这一点，以避免再发生像WannaCry爆发期间我们看到的那些炒作。

“BlueKeep”的标签最初由Kevin Beaumount使用。我之所以选择这个标签，有两个原因：为了获得可供参考的信息，同时能够在Twitter上查找相关帖子，我们不能简单地使用CVE作为标签（除非删除其中的破折号）。BlueKeep这个标签只是让发推变得更加容易。

漏洞影响面分析

要建立检测理论，我们必须考虑两种威胁模型，分别是：

1. 蠕虫威胁，类似于WannaCry的场景。

2. APT攻击者，将漏洞作为更复杂的攻击中的一部分，就像永恒之蓝（EternalBlue）和SMB协议仅仅是NotPetya灾难性攻击中的一部分。

为了识别存在风险的资产，我们将参考由Dragon提供的下表：

CVE-2019-0708可以使用类似于WannaCry的大规模初始访问吗？我们迅速查看Shodan数据，发现网络上存在大量主机，暴露3389端口，并运行可能易受攻击的Windows版本。

搜索内容URL如下：

· https://www.shodan.io/search?query=port%3A3389+os%3A%22Windows+7+or+8%22

· https://www.shodan.io/search?query=port%3A3389+2003

· https://www.shodan.io/search?query=port%3A3389+2008

·https://www.shodan.io/search?query=port%3A3389+os%3A%22Windows+XP%22

总体来看，我们可以寻找在互联网上暴露RDP的238.5万台主机，但目前还无法验证这一结论的准确性。

搜索内容URL如下：https://www.shodan.io/search?query=Remote+Desktop+Protocol

引述2017年4月23日Dan Tentler的推文，“并非所有主机都是Windows，而且并非所有这些端口都是SMB”。我们将这句话放到今天也一样可以使用，“并非所有这230万台主机都是Windows，而且并非所有这些端口都是易受CVE-2019-0708影响的服务”。如果我们将此次的CVE-2019-0708与WannaCry的时间线进行对比，我们现在处于MS-17010已经发布的阶段，但永恒之蓝（EternalBlue）尚未出现，因此我们无法扫描到下一个DoublePulsar。直至这样的PoC出现之前，我们还不能完全确定事情的发展方向。然而，即使这一威胁到达了之前WannaCry的阶段，我们也可能还会有30天的时间来实施防御，当然，这一时间或许会更少。

尽管我们可以讨论这些稽查到的主机是否可以被攻击者真实利用，并且可以分析这些主机的补丁状态、网络分段等，但众所周知，许多公司仍然在运行易受攻击的Windows版本，并且修复周期对于这些系统来说可能更难。根据WannaCry的数据，我们看到有大约2.4万台以上潜在可利用的主机与14万台以上疑似影响的主机，DoublePulsar在事件发生前的3周被发布到互联网上。

在这个阶段，更大的风险是在组织内部利用CVE-2019-0708来迅速攻陷主机和进行横向移动。并且，由于漏洞利用PoC在本文撰写的时候尚未出现（网上有很多假冒的），因此我们将利用我们掌握的所有 工具 来构建漏洞利用前的检测方式。

考虑到上述情况，作为防御者，我们可以做的三件事是：

1. 部署主动检测方式；

2. 严格要求修复漏洞或缓解漏洞风险；

3. 参考受信任的研究人员的意见，跟踪该风险的后续发展。

为了具体解释这一点，我在这里引用Florian Roth的推文：

临场救火：Sigma规则

第一条规则，我们将其称为Sigma #1，由Sigma GitHub Repo的Markus Neis提供，该规则为横向移动技术T12010/远程服务漏洞利用 https://attack.mitre.org/techniques/T1210/ ：

在一小时内，类似的规则（Sigma #2）由Roman Ranskyi在SOC Prime TDM上发布，并提供给社区免费使用，该检测逻辑已经扩展到T1036/Masquerading https://attack.mitre.org/techniques/T1036/ 和T1046/网络服务扫描 https://attack.mitre.org/techniques/T1046/。

基本上，我们已经有了一个TLP:WHITE和TLP:GREEN，并且赶在了漏洞利用之前。但是，这就足以全面地发现攻击行为吗？

更进一步：机器学习

接下来，我们探讨机器学习如何能为我们提供一些检测方面的优势，同时也考虑如何为Elastic栈创建解决方案。

理论：

在限定的时间窗口内，某一主机发起大量RDP连接，并且其中单一的目标IP地址过多，可以证明疑似使用RDP协议作为传播方式，进行蠕虫的横向移动和传播。在该过程中，可能使用与CVE-2019-0708漏洞相关的RDS漏洞。

（1）描述

我们可以借助该方法识别源IP地址，这些IP地址可能是RDP蠕虫传播端点，也可能是跨网段或通过RDP/T1076进行的横向移动。

（2）影响

该方案是作为远程桌面服务（RDS）远程代码执行漏洞（CVE-2019-0708）自动主动检测方式的一部分二条功能的，但尚未发现此类RDP蠕虫，预计蠕虫会利用这一漏洞，并借助RDP跨内部LAN实现横向移动。一旦在野外观察到RDP蠕虫的行为后，我们可以通过分析RDP蠕虫行为的其他信息，来调整策略，从而产生更加有效的检测结果。

（3）用例类型

基本攻击行为（Elementary Attack Behavior）：该用例检测与基本攻击行为相关的异常。其中，每个被检测到的异常都会被分配一个归一化的异常分数，并使用数据中对异常具有统计影响的其他字段值进行注释。具有共同统计影响因素的基本攻击行为通常与常见的攻击进程相关。

（4）用例数据源

Netflow事件，ECS格式的类似数据的VPC流日志，其中包含内部LAN段内Windows主机之间的RDP连接日志。

（5）用例方案

用途：RDP连接

模型：源IP地址中每个目标IP地址的唯一计数

检测：特殊源IP地址中存在大量目标IP地址

比较：所有（最高已登记的）源IP地址的流量

分类依据：无

排除项：无

持续时间：对Netflow事件进行持续分析，大概持续两周或更长的时间

相关方案：无

结果：发现的主机可能是漏洞扫描主机、跳转主机或受漏洞影响的主机（作为RDP蠕虫传播的来源）。

输入内容和备选影响者：

必填字段描述示例

Source.ip（RDP会话源IP） 10.10.1.1

Destination.ip（RDP会话目的IP） 10.10.1.124

Destination.port（TCP端口，用于检测RDP连接） 3389

（6）示例Elasticsearch索引模式

ecs-netflow*

（7）示例Elasticsearch查询

“query”: {“term”: {“destination.port”: {“value”: 3389",”boost”: 1}}}

（8）机器学习分析/检测工具配置

Detector：source.ip中的high_distinct_count（destination.ip）

Bucketspan：15m

Influencer：source.ip

最后，我们查看Elastic栈中的ML结果。

在单个度量视图中，确实找到了我们想要寻找的目标。由此可以得出结论，我们拥有的数据集越好，异常值的检测就越准确。

Anomaly Explorer有助于分析类似蠕虫行为的正常RDP连接，或者非常勤奋工作的管理员的行为，这些正常的RDP连接行为常常属于误报。

使用ArcSight相关引擎

在这个阶段，我们已经明确定义了检测逻辑，我们看看是否可以将其应用于许多公司仍在用作主要SIEM工具的技术上。关于即将到来的威胁，我们可以尝试解决几项任务：

1. 自动识别风险资产；

2. 跟踪上述资产的异常RDP活动；

3. 尝试通过利用Sigma和基于行为的规则来检测横向移动。

任务 #1：依赖ArcSight中的几个功能

通过利用任何能提供CEF输出的漏洞扫描程序填充的资产和网络模型，可以列出易受CVE-2019-0708影响的资产列表。此外，Qualys、Nessus甚至nmap都可以解决这一问题。

如果我们没有扫描器，那么怎么办呢？我们可以在资产和网络模型的基础上，对Windows XP、Windows 7、Windows 2003、Windows 2008资产进行过滤，或者对与新版本Windows不同的那些系统版本生成的Windows事件ID进行跟踪，来找到可能存在漏洞的主机。

任务 #2：作为机器学习的替代方案，我们可以制定一个规则，根据分类选择防火墙和Netflow事件，并将RDP源和目标IP存储到活动列表。这样一来，我们就可以找到与潜在/已确认的易受攻击资产的第一个链接。此外，我们可以构建趋势图，以分析RDP连接，并通过连接数量检测流量的峰值。

任务 #3：将Sigma规则 #1从查询移植到实时关联，这样即可覆盖横向移动T1210的检测。为了实现这一点，我将Sigma #1源复制到Uncoder.io中，以生成ArcSight查询。使用ArcSight查询的一个好处是，如果我们掌握一些语言知识，就可以轻松地将代码转换为实时关联规则的过滤器。

将多种方式组合融入SOC中

对于ArcSight，上面的内容部分绑定在一个仪表盘中，在正常的阿情况下，仪表盘应该保持为空。如果需要让事件滚动到主SOC通道，我们需要添加一个轻量级规则，以接收“相关事件详细信息”的相关警报。

对于基于Elastic的SOC，我们添加了一个简单的Kibana仪表盘。在其中，显示了RDP峰值和机器学习的视觉化展示，用于根据网络流量查找异常值，以及显示有关Sigma规则触发器、受影响主机的详细信息。

如果我们已经使用SOC Prime仪表盘进行管理，那么可以借助MITRE ATT&CK的探索技术，发现攻击者所使用的策略、技术、攻击受影响用户、受影响计算机，同时能够观察到攻击的时间轴，并可以管理观察者、通过SOC Workflow应用程序转到Sigma规则和案例。上述所有这一切，都没有离开Kibana界面。

使用Elastic、ArcSight还是Sigma？

如果我们只使用ATT&CK作为基线，那么Elastic就是最为领先的技术。Elastic栈的主要优点是能够将机器学习与基于Sigma的现代威胁稽查结合起来。需要注意的是，在使用Sigma规则进行实时关联查询时需要重新考虑，并且ArcSight不支持Masquerading/T1036。

但是，值得注意的是，在实际上，我们更容易对ArcSight进行设置，并利用漏洞扫描程序中的数据进行跨设备关联。一旦与检测规则包中的所有其他日志源相结合，该检测方式可以有效用于许多组织之中。

如果我们从检测开发的速度和成本的角度来考虑，那么Sigma显然会胜出。只要我们的SIEM或EDR支持Sigma，或者管理员具有来自所有主机（包括Windows XP、Windows 7、Windows 2003和Windows 2008）的Sysmon日志，那么这将是最佳的方案。另外，单一规则与更大的检测包相比，其优势在于我们的假设，即：真正的攻击将利用RDP进行横向移动。在威胁检测方面，没有任何一种方案能适用于所有场景。哪种方法的优势更大，只能在实际的漏洞利用被发现之后才能得出结论，在此之前，我们唯一能做的就是建立检测规则，而最可能使用的就是Sigma规则。最后，我们根据已知和未知的规则，并运用机器学习的方式，构建了主动检测内容，就如同Anton Chuvakin博士在最近的帖子（https://blogs.gartner.com/anton-chuvakin/2019/04/30/rule-based-detection/）中所描述的那样。

预防措施与修复方案

我们应该借鉴之前WannaCry的经验，假如用户提前对SMB漏洞进行了修复，那么WannaCry的影响就不会如此严重。如果无法实现修复，那么就应该部署检测方式，进行备份，并缓解风险。

MITRE ATT&CK检测规则

Sigma #1（Markus Neis）

https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_susp_rdp.yml

关键词：横向移动；T1210；日志源：Microsoft Sysmon

Sigma #2（Roman Ranskyi）

https://tdm.socprime.com/tdm/info/2159/

关键词：横向移动；逃避防御；发现；T1210；T1036；T1046；日志源：Microsoft Sysmon

ArcSight .ARB规则包

https://tdm.socprime.com/tdm/info/2160/

关键词：横向移动；T1210；T1046；T1076；日志源：防火墙；Netflow；漏洞扫描程序；MS Active Directory日志；Sysmon

Elastic栈规则包

https://tdm.socprime.com/tdm/info/2160/

关键词：横向移动；逃避防御；发现；T1210；T1036；T1046；T1076；日志源：Netflow；MS Active Directory日志；Sysmon

SOC Workflow APP社区版

https://github.com/socprime/soc_workflow_app_ce