安全黑客
当前位置:安全黑客文章资讯安全资讯安全新闻
日期:2019-01-03 20:28:00  来源:本站整理

Windows内核扩展机制研究[安全新闻]

赞助商链接



  本文“Windows内核扩展机制研究[安全新闻]”是由安全黑客为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:

一、前言
最近我需要写一个内核模式驱动,这种工作通常会让许多人恼怒不堪,无法从容处理(转述自Douglas Adams)。
与我之前写过的代码一样,这个驱动也存在几个主要的bug,会导致一些有趣的副作用。具体而言,该驱动会阻止其他驱动正确加载,导致系统崩溃。
事实证明,许多驱动会默认自己的初始化例程(DriverEntry)始终能够成功执行,当意外情况发生时并不具备相应的处置办法。j00ru在几年前的一篇博客中讨论了其中一些案例,并且其中许多案例仍可以在当前的Windows版本中找到关联线索。然而,这些bug驱动并不是我遇到的那个问题,并且j00ru对这些bug驱动的分析也比我更加全面。我关注的是其中一个驱动,进一步分析后,我开始研究“windows kernel host extensions”(Windows内核宿主扩展)机制。
 
二、初步分析
我们的目标是Bam.sys(Background Activity Moderator),这是Windows 10 1709(RS3)版新引入的一个驱动。当该驱动的DriverEntry中途失败时,系统会出现崩溃,相关调用栈情况如下所示:

从崩溃转储信息中,我们可知Bam.sys注册了一个进程创建回调函数,并且在卸载前忘记取消注册该回调。因此,当进程被创建/终止时,系统会尝试调用该回调函数,结果就碰到无效指针,发生崩溃。

这里有趣的并不是系统崩溃这件事,而是Bam.sys注册该回调的过程。通常情况下,驱动会通过nt!PsSetCreateProcessNotifyRoutine(Ex)来注册进程创建回调函数,将回调函数加入nt!PspCreateProcessNotifyRoutine数组中。然后,当进程被创建或者终止时,nt!PspCallProcessNotifyRoutines会遍历该数组,调用已注册的所有回调。然而,如果我们在WindDbg中运行!wdbgark.wa_systemcb /type process命令(参考wdbgark),会看到数组中并不存在Bam.sys所使用的回调。

相反,Bam.sys使用了另一种机制来注册回调函数。

如果我们去分析nt!PspCallProcessNotifyRoutines,就会看到其中显式引用了名为nt!PspBamExtensionHost的一些变量(Dam.sys驱动中也存在另一个类似变量)。通过这种“extension host”机制,nt!PspCallProcessNotifyRoutines就可以得到一张“extension table”(扩展表),然后调用extension table中的第一个函数,也就是bam!BampCreateProcessCallback。
 
三、扩展机制分析
如果我们在IDA中打开Bam.sys,很容易就能找到bam!BampCreateProcessCallback,进一步搜索相关的交叉引用(xref)。幸运的是,这里只有一处交叉引用,位于bam!BampRegisterKernelExtension中:

正如我们猜想的那样,驱动并没有通过正常的回调注册机制来注册Bam!BampCreateProcessCallback,实际上该函数存放在名为Bam!BampKernelCalloutTable的一张函数表中,该表随后会与其他一些参数传递给未公开的nt!ExRegisterExtension函数(稍后我们再讨论这些参数)。
我尝试搜索相关文档或者线索,想知道这个函数具体负责的工作,或者澄清这究竟是什么扩展,但找到的线索寥寥无几。我找到最有用的一个资源就是公开泄露的ntosifs.h头文件,头文件中包含nt!ExRegisterExtension的原型以及_EX_EXTENSION_REGISTRATION_1结构的布局信息。
ntosifs.h中关于nt!ExRegisterExtension原型以及_EX_EXTENSION_REGISTRATION_1结构的内容如下:
NTKERNELAPI NTSTATUS ExRegisterExtension (
    _Outptr_ PEX_EXTENSION *Extension,
    _In_ ULONG RegistrationVersion,
    _In_ PVOID RegistrationInfo
);
typedef struct _EX_EXTENSION_REGISTRATION_1 {
    USHORT ExtensionId;
    USHORT ExtensionVersion;
    USHORT FunctionCount;
    VOID *FunctionTable;
    PVOID *HostInterface;
    PVOID DriverObject;
} EX_EXTENSION_REGISTRATION_1, *PEX_EXTENSION_REGISTRATION_1;
经过一番逆向分析后,我发现PVOID RegistrationInfo这个输入参数实际上为PEX_EXTENSION_REGISTRATION_1类型。
nt!ExRegisterExtension的伪代码请参考附录B,这里给出该函数的主要工作流程,如下所示:
1、nt!ExRegisterExtension提取RegistrationInfo结构中ExtensionId和ExtensionVersion成员的值,然后通过nt!ExpFindHost函数(参考附录B)使用这些值来查找nt!ExpHostList中与之匹配的host;
2、然后,该函数验证RegistrationInfo->FunctionCount所提供的函数数量是否与host结构中设置的预期数量值相匹配。函数还会确保host的FunctionTable字段尚未被初始化。从这点来看,该检查机制意味着一个内核扩展无法多次注册;
3、如果一切正常,那么host的FunctionTable就会指向RegistrationInfo中的FunctionTable;
4、此外,RegistrationInfo->HostInterface会指向host结构中的一些数据。这一点比较有趣,后面我们会回头讨论这些数据;

[1] [2] [3] [4] [5]  下一页


  以上是“Windows内核扩展机制研究[安全新闻]”的内容,如果你对以上该文章内容感兴趣,你可以看看安全黑客为您推荐以下文章:
  • Windows 0 day任意数据覆写文件漏洞
  • 渗透技巧——Windows中net session的利用
  • Windows内核扩展机制研究
  • Windows10 v1703基于桌面堆泄露的内核提权技术
  • 渗透基础——Windows下计划任务的使用
  • CVE-2018-8611 Windows kernel事务管理器0 day漏洞分析
  • 从DirectX到Windows内核——几个CVE漏洞浅析
  • 如何借助COM对Windows受保护进程进行代码注入(第二部分)
  • 如何借助COM对Windows受保护进程进行代码注入
  • 渗透技巧——Windows系统文件执行记录的获取与清除
  • Windows VBScript引擎远程执行代码漏洞 之CVE-2018-8373分析与复现
  • Windows Notification Facility (WNF)组件的详细介绍
  • 本文地址: 与您的QQ/BBS好友分享!

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    免责条款 - 广告合作 - 下载声明 - 欢迎投稿 - 友情连接 - 网站地图 -
    Copyright © 2012-2013 www.110hack.com. All Rights Reserved .