2020-01-11 23:12:49 Author: bbs.pediy.com(查看原文) 阅读量:196 收藏
-
-
-
[讨论][原创]迅雷有必要搞这样的流氓行为吗？
- 3天前 1165
-
最近我们的系统拦截到操作系统刚启动services.exe的时候，检测到该系统进程中执行未知shellcode加载dll的事件，对shellcode进行简单分析后，发现通过LdrLoadDll函数加载了一个迅雷的dll文件
shellcode加载的dll文件路径：C:\Program Files (x86)\Common Files\Thunder Network\xlguard\xlsvc001.dll
shellcode反汇编，如下图：
由于被加载DLL是迅雷的，所以这事和迅雷有莫大的关系！ 可是网上缺搜不到和xlsvc001.dll这个文件相关的任何资料，关注点转移到存放这个dll的目录名称xlguard
原来早在两年前迅雷就已经被人关注到xlguard这关键词了，简单看了一下该文只是说逆向该驱动发现会在卸载驱动和关机时，再把迅雷的XLServicePlatform服务通过注册表，设置为开机自动启动
具体细节，参考卡饭链接：https://bbs.kafan.cn/thread-2072871-1-1.html
使用IDA看了一下xlguard.sys文件，发现它利用内核强大权限，监控主流操作系统上所有DLL加载事件
并在事件回调函数中且判断如果是services.exe进程加载dll事件
首先修改services.exe进程EPROCESS结构的签名级别为0 == Unchecked
关于保护进程的签名级别可以参考：《 Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers 》 http://www.alex-ionescu.com/?p=146
以及其看雪其它人对《迅雷在win10x64上的services进程注入》的分析 https://bbs.pediy.com/thread-250446.htm
然后在services进程中申请可执行内存，拷贝驱动中硬编码的shellcode模板，并替换掉模板中共4处需要动态替换的地址：
0x11111111、0x22222222、0x33333333、0x44444444
驱动中的shellcode模板如下，与我们在services进程中拦截到的shellcode一致：
unsigned char ida_chars[] =
{
0x48, 0x89, 0x5C, 0x24, 0x08, 0x48, 0x89, 0x6C, 0x24, 0x10,
0x48, 0x89, 0x74, 0x24, 0x18, 0x48, 0x89, 0x7C, 0x24, 0x20,
0x41, 0x54, 0x48, 0x83, 0xEC, 0x20, 0x83, 0x3D, 0x11, 0x11,
0x11, 0x11, 0x00, 0x48, 0x8B, 0x2D, 0x22, 0x22, 0x22, 0x22,
0x49, 0x8B, 0xD9, 0x4D, 0x8B, 0xE0, 0x48, 0x8B, 0xFA, 0x48,
0x8B, 0xF1, 0x75, 0x13, 0x4C, 0x8D, 0x05, 0x33, 0x33, 0x33,
0x33, 0xC7, 0x05, 0x44, 0x44, 0x44, 0x44, 0x01, 0x00, 0x00,
0x00, 0xFF, 0xD5, 0x4C, 0x8B, 0xCB, 0x4D, 0x8B, 0xC4, 0x48,
0x8B, 0xD7, 0x48, 0x8B, 0xCE, 0x48, 0x8B, 0xC5, 0x48, 0x8B,
0x5C, 0x24, 0x30, 0x48, 0x8B, 0x6C, 0x24, 0x38, 0x48, 0x8B,
0x74, 0x24, 0x40, 0x48, 0x8B, 0x7C, 0x24, 0x48, 0x48, 0x83,
0xC4, 0x20, 0x41, 0x5C, 0x48, 0xFF, 0xE0
};随后查看被注入的xlsvc001.dll到底想搞什么事情！ 首先第一个函数初始化一些需要用到的函数到全局变量
然后通过读取services.exe自身特征，找到guid为{367abb81-9844-35f1-ad32-98f038001003}的字符，搜索时注意大小端排序，使用16进制编辑器可对services.exe二进制文件搜索 81bb7a36
定位到guid以后，加固定偏移，可以得到这个com对象的接口虚表，最终这个函数返回虚表地址。拿到虚表地址以后，对虚表中的0x10和0x1C偏移位置的接口函数地址进行替换
那么问题来了，这个guid代表哪个com对象？ 被替换的接口是什么？ 替换的目的是什么？
通过github搜索相关guid找到了这个guid是关于svcctl对象的，这个对象中的0x10和0x1C号函数正是OpenServiceA和OpenServiceW
相关地址： https://github.com/mauropalumbo75/bro-2.6.1/blob/29fe549f512c032c14124d962c4e80018059a7ea/scripts/base/protocols/dce-rpc/consts.bro#L649
看雪上已经有相关Hook劫持RPC函数的文章： https://bbs.pediy.com/thread-251158-1.htm
那么迅雷为什么要劫持这两个函数呢？
通过劫持这两个函数，发现如果是打开XLServicePlatform服务，再通过I_RpcBindingInqLocalClientPID获取请求的客户端进程ID-》再获取进程名称
如果是thunder.exe、lserviceplatform.exe就可以打开该服务
如果是mmc.exe、msconfig.exe、svchost.exe、taskhost.exe、taskmgr.exe，则返回5 拒绝访问
MSDN ROpenServiceA文档: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-scmr/ddd7c91f-e4fb-446e-9053-0b6308c640eb
我通过任务管理器，找到迅雷的XLServicePlatform服务，尝试停止该服务，果然提示拒绝访问！！
通过这种方式劫持rpc服务请求确实挺有意思！
如有侵权请联系:admin#unsafe.sh