测试你的DFIR工具: Sysmon事件日志中的安全问题剖析

阅读量    36153 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

写在前面的话

作为一名站在网络安全防御端的研究人员,我需要不断地对各种安全监测框架进行测试和调整,然后再对重构的框架进行重新测试以确定安全防御思想是否正确。但是对于一名经验丰富的DFIR(数据取证与事件应急响应)从业人员来说,他们需要对类似安全工具所生成的检测结果进行交叉验证,并根据输出结果来进行下一步操作。在过去的九个月时间里,我花了大量的时间去研究新型的混淆技术和规避技术,而且在那一段时间里,我还花了很多时间去验证各种检测工具的检测效率和效果。在这篇文章中,我将跟大家分享我在Sysmon的事件日志系统中发现的一个安全漏洞,这个漏洞会影响相应的命令行参数以及至少两款不同的工具,攻击者还可以利用该漏洞查看目标主机中的Windows事件日志。
首先我要声明的是,从2014年第一代Sysmon版本发布之后,我就开始在我个人的测试实验室搭建中使用Sysmon了,所以我可以算是Sysmon的“脑残粉”了。Sysmon(System Monitor)是微软Sysinternals Suite的其中一个组件,由Mark Russinovich(@markrussinovich)主管开发。Sysmon驱动器会以应用服务的形式进行安装,并保持常驻性。网络安全检测人员可以利用Sysmon来监视和记录系统活动,而Sysmon不仅可以提供有关进程创建,网络链接和文件创建时间更改的详细信息,而且还可以将Windows主机中的事件情况记录在Microsoft-Windows-Sysmon/Operational事件日志中。Sysmon最近一次的更新日期为2018年1月5日,版本号为v7.01,并且支持二十二中不同的事件ID(Event ID),其中包括进程执行事件(EID 1 & 5)、网络连接事件(EID 3)、图像加载事件(EID 7)、命名管道事件(EID 17 & 18)、WMI事件(EID 19, 20 & 21)以及各种注册表事件等等。
在过去几年时间里,网上有很多关于使用Sysmon作为终端威胁分析的数据收集源的技术文章。除此之外,关于Sysmon的开源配置项目(例如@SwiftOnSecurity的sysmon-config项目- https://github.com/SwiftOnSecurity/sysmon-config)也越来越多,这样让更多的人开始使用Sysmon来进行数据收集和过滤了。而且微软近期还专门发布了一篇Sysinternals Sysmon可疑活动检测指南:https://blogs.technet.microsoft.com/motiba/2017/12/07/sysinternals-sysmon-suspicious-activity-guide/,感兴趣的同学可以阅读以了解更多详细信息。
接下来,我们一起进入今天的主题。

 

Sysmon安全分析

我们先看一看下面这个例子,这段代码会在环境变量envVar中设置一条命令,然后在一个子进程中执行这个环境变量中的代码内容:

cmd.exe /c "set envVar=echo TESTING&&cmd.exe /c %envVar%"

当我们在EventVwr.exe中查看这个Sysmon EID 1事件时,你就会发现其中的CommandLine参数已经被替换掉了,原来的%envVar%外面又多了一层百分号:


虽然我发现了这个问题,但我当时也没有太在意,直到我在日志中看到了使用随机命名环境变量(尤其是以整形数字开头的变量名称,如下面代码所示,使用1337直接替换掉了环境变量名envVar)的Payload信息时,这个情况才引起了我的注意:

cmd.exe /c "set 1337=echo TESTING&&cmd.exe /c %1337%"

接下来,我们可以在EventVwr.exe中查看这条命令的运行结果,这确实挺令人惊讶的:


这似乎是一个存在于Sysmon EID 1的CommandLine域中的溢出漏洞,因为我们在使用EventVwr.exe查看相关数据时,系统显示的是不正确的数据。
接下来,我就需要使用其他工具来验证这个数据源了,我直接选择了PowerShell以及它的Get-WinEvent脚本来查询这个Sysmon事件。结果证明,它返回的也是同样的错误值。
于是乎,我开始测试cmd.exe /c “echo %1”、cmd.exe /c “echo %2”和cmd.exe /c “echo %3”之类的语句,并看看系统显示的事件信息中是否同样会包含额外的值。实验结果表明,有些时候这些值会出现在其他的事件日志条目中,例如%2 —> ProcessGuid和%3 —> ProcessId等等,但有的时候这些值似乎显示的是一些随机的系统信息。
提醒大家一下,cmd.exe的命令行参数长度限制为8191个字符,于是我就想:Sysmon事件日志中的CommandLine域也会遵循这样的字符长度限制吗?
为了证实我的猜想,我使用cmd.exe的||操作符(跟&&的作用相反,如果操作符前面的命令返回值为FLASE,那么代码将会执行操作符后面的命令)执行了下列测试命令,所以我们可以直接在一条命令的后面接上一堆垃圾文本,而这些文本按理来说是不会得到执行的:

cmd.exe /c "echo PUT_EVIL_COMMANDS_HERE||%1"

从下面的图片中你可以看到EventVwr.exe和PowerShell的Get-WinEvent脚本所生成的不正确的CommandLine值:


所以说,“%1”(2个字符)这个由用户控制的输入值将会在事件日志中生成“Incorrect function.”(19个字符)错误信息。那么运行55个”%1”实例:

cmd.exe /c "echo PUT_EVIL_COMMANDS_HERE||%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1"

将会生成如下图所示的输出结果:


如果再加到50-85个”%1”实例的话,你将会从EventVwr.exe中的每一个Sysmon EID 1事件中看到一堆乱码,有的时候甚至还会显示其他事件日志源的完整日志信息(类似PowerShell EID 800事件):


在使用PowerShell的Get-WinEvent脚本查询这些事件时,我们得到了如下所示的事件错误信息:


我们所发现的漏洞可以在Windows 7到Windows 10的所有版本系统(以及PowerShell v2到v5)中成功复现。

 

可能的解决方案

但是,在接下来的验证测试过程中,我又发现了其他的工具可以对.evt/.evtx解析并正确显示出百分号+整形填充值。比如说,微软的Log Parser以及FireEye的Redline取证分析工具(这两款工具都是免费的!)都不会被Sysmon中CommandLine域的溢出问题所影响,并且能够显示出”%1”和”%1337”等字符的正确值。
那么重点是什么?很好,在这个漏洞的帮助下,如果网络管理员使用的是类似EventVwr.exe 或PowerShell的Get-WinEvent脚本来查询事件日志信息的话,攻击者就可以通过在命令中填充足够多的百分号+整形字符串,然后有效地在Sysmon EID 1中隐藏恶意进程执行事件了。
如果你是一名网络安全管理员的话,并且喜欢使用EventVwr.exe 或PowerShell的Get-WinEvent脚本来查询Sysmon EID 1事件,那么在系统出现异常时,你可能需要使用一款不受该漏洞影响的工具来处理这些异常事件了(友情提示:在PowerShell攻击场景下,try/catch语句也许是你的最佳选择)。当然了,你也可以通过官方支持的安全事件日志EID 4688来获取并分析进程命令行参数。
除此之外,建议大家对自己手头上现有的工具进行测试,以确保自己的工具没有受到这个漏洞的影响。

 

总结

如果你现在问我:“你仍然觉得Sysmon是一款非常优秀的工具吗?“我会毫不犹豫地点头!但如果你要问我:”我仍然会把Sysmon当作唯一的进程执行事件源吗?“我肯定不会,因为我可能会使用安全EID 4688或其他官方所支持的机制来实时捕获命令行参数。但是,如果我必须要使用Sysmon EID 1的话(直到这个漏洞被成功修复),我可能会选择使用其他的一些不受该漏洞影响的工具来解析Sysmon中包含在百分号内的字符,这样就可以确保我们所编写的检测规则不会被这个溢出漏洞所影响。
作为一名负责任的防御端研究人员,我们需要不断地进行测试、调整、验证和再验证,然后不断地打破我们原有的假设,这样才能不断地优化我们的安全检测机制,并更好地利用手上的工具来实现我们的目标。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多