以制作动作游戏闻名世界的Capcom最近曝出乌龙事件。在Capcom出品的《街头霸王5》一次更新中，它内置了一个用来防止玩家作弊的驱动程序Capcom.sys，然而这个反作弊驱动却闯了大祸，刚发布不久就被曝光其实是一个高度危险的后门，它可以帮助任意程序获得系统内核权限，当然也会被木马病毒轻易利用，比如绕过沙箱、破坏杀毒软件、HIPS等防护产品，完全瓦解系统安全体系。
Capcom中文名为卡普空株式会社，代表性游戏有《生化危机》、《街头霸王》、《鬼泣》等，可以说很多70后、80后玩家都是玩着Capcom的游戏长大的。然而此次《街头霸王5》的后门事件却让Capcom陷入窘境，为此专门致歉并发布了升级补丁。这里我们建议相关游戏用户尽快升级补丁，同时提醒各大安全厂商注意，尽快针对存在后门的Capcom.sys版本进行防御。根据测试，目前国内外仍有大量杀毒软件可以被恶意程序利用Capcom后门轻松击溃。
以下我们将对Capcom.sys进行深入分析，揭秘该驱动后门对系统安全造成的巨大隐患。
0x1 逆向分析Capcom.sys
Capcom.sys所做的就是关闭操作系统的安全机制并提升自己游戏为管理员权限，目的在于能够对系统上所有的文件进行操作。它预留了接口让应用层的程序(游戏)调用，来实现一些更高级、更自由的操作，比如防止游戏内存修改，验证正版用户等。接下来我们开始逆向分析 Capcom.sys，看看此神奇的驱动到底做了什么。。。
最关键的函数有如下5个：
1：关闭SMEP(Supervisor Mode Execution Protection)
那么啥是SMEP呢？SMEP全称是Supervisor Mode Execution Protection。监管模式执行保护。存在与CR4中的第20位处。
SMEP的引入是Intel考虑到系统安全而新增的机制。我们知道CPU提供了环权限的机制，也就是我们平常所说的ring0，ring3。当然还有ring1和ring2(甚至ring-1)。只不过windows操作系统只使用了2个环(ring0和ring3)。环的产生意味着权限的产生。不同环的权限等极也是不同的，环的数字越小，则权限越高。SMEP的存在就是为了防止不同环访问不同权限的页面而产生的。
在未开启SMEP前，Supervisor Mode(ring0-2)所对应的page entry属性可以是user或者Supervisor，也就是说page entry.u/s可以为0，也可以为1。User mode(ring-3)所对应的page entry属性只能是user(page entry.u/s=0)。
在开启SMEP后，Supervisor Mode(ring0-2)所对应的page entry.u/s只能为0。这也就意味着Supervisor Mode(ring0-2)将无法访问User mode(ring3)的页面。
Capcom.sys正是利用了这点，关闭了SMEP，使得ring0的模式可以访问ring3的代码，这里所指的ring3的代码也就是合法的shellcode了。不过这比shellcode更生猛，因为Capcom.sys可以直接访问ring3的函数。
2：开启SMEP(Supervisor Mode Execution Protection)
3.驱动的IOCtl通信函数（只取关键部分）
我们可以知道，当控制码为0xAA012044时，代表的是32位模式，当控制码为0xAA013044时，代表的是64位模式。此驱动样本为64位，所以我们着重研究64位的控制码0xAA013044即可。
4.漏洞利用函数
我们可以知道，所被调用的函数类型大致为void(*)(PVOID(*)(PUNICODE_STRING))。即该函数的第一个参数为MmGetSystemRoutineAddress的地址。
在这里有一个非常关键的地方，条件判断的第一句话，这里猜想是Capcom为了防止此驱动滥用而设置的暗桩。所以我们构造shellcode的时候需要特别注意。
5.解密Device Name函数
// 解密设备名
// PWCHAR Funk(PWCHAR in_device_name,PWCHAR out_device_name)
_WORD *__fastcall deobfuscatetion_device_name_sub_103AC(_WORD *in_device_name, char *out_device_name)
{
_WORD *v2; // r8@1
signed __int64 v3; // rcx@1
__int16 v4; // ax@2
__int16 v5; // di@3
__int16 *v6; // rdx@3
signed __int16 v7; // r9@3
unsigned into v8; // er10@4
signed __int16 v9; // ax@5
unsigned __int16 v10; // cx@5
_WORD *v11; // rdi@16
signed __int64 v12; // rcx@16
bool v13; // zf@18
__int64 v14; // rcx@19
__int16 v15; // ax@20
__int16 v17[36]; // [sp+0h] [bp-48h]@1
v2 = in_device_name;
v3 = (char *)v17 - out_device_name;
do
{
v4 = *(_WORD *)out_device_name;
*(_WORD *)&out_device_name[v3] = *(_WORD *)out_device_name;
out_device_name += 2;
}
while ( v4 );
v5 = 0;
v6 = v17;
v7 = 21845;
if ( v17[0] )
{
while ( 1 )
{
v7 = v5 + 4 * v7;
v8 = (unsigned into)(unsigned __int16)*v6 >> 6;
if ( v8 - 1 > 2 )
break;
v9 = 0;
v10 = (((unsigned __int8)v7 ^ (unsigned __int8)*v6) - (_BYTE)v5 - (_BYTE)v8) & 0x3F;
if ( v10 >= 0xAu )
{
if ( v10 >= 0x24u )
goto LABEL_10;
v9 = v10 + 55;
}
else
{
v9 = v10 + 48;
}
if ( v10 >= 0x24u )
{
LABEL_10:
if ( v10 < 0x3Eu )
v9 = v10 + 61;
}
if ( v10 == 62 )
v9 = 46;
if ( v9 )
{
*v6 = v9;
++v6;
++v5;
if ( *v6 )
continue;
}
break;
}
}
v11 = v2;
v12 = -1i64;
do
{
if ( !v12 )
break;
v13 = *v11 == 0;
++v11;
--v12;
}
while ( !v13 );
v14 = 0i64;
do
{
v15 = v17[v14];
++v14;
v11[v14 - 2] = v15;
}
while ( v15 );
return v2;
}这里看的有点辣眼睛，但是我们不需要理他。因为我们可以直接使用WinObj来得知他创建的设备符号链接名为：Htsysm72FB。有了此符号链接名，我们可以使用CreateFile函数来打开它的驱动设备并且发送控制码来利用了。。
至此，逆向分析到此结束，我们来总结一下：Capcom.sys初衷只是为Capcom自家人提供的一种反作弊的插件，从他的设备名字符串混淆与调用暗桩可以看出，他并不想让别人使用它，但是这并没有什么用。从软件安全角度上去看，此sys没有加壳是被利用的最致命因素之一。攻击者只需要绕过暗桩，即可调用它的驱动。
0x2 利用前的准备工作
基于之前的分析，我们知道了设备名称的符号连接为Htsysm72FB，根据微软的定义。我们需要在他前面加上file:///\.。然后使用CreateFile函数来打开他的设备。
接着开始准备shellcode。
第一行，前8个字节是为了绕过暗桩而加入的，前8个字节需要填写利用函数的入口地址(也就是第二行)。
第二行，实现的是CALL $+8处 等价于push第三行(利用函数的地址) && Rip=第四行(POP RAX)
第三行，为我们需要填写的利用函数地址。
最后一行，跳向我们的利用函数地址处。
在该模板内填写相应的内容即可。
最后，开始向Capcom.sys发送控制码来利用此驱动。值得注意的是0xAA013044为64位模式，0xAA012044为32位模式。需要传递的shellcode为之前的模板+8处，以此来绕过暗桩。
0x3 基于Capcom.sys实现无签名加载驱动
无签名加载驱动的话题已经很老套了。
具体分析请参考j00ru的“A quick insight into the Driver Signature Enforcement“这篇文章
以及MJ0011的这篇pdf
http://www.powerofcommunity.net/poc2012/mj0011.pdf
结合两位大牛的文章，我们知道在WIN7上，可以通过修改nt!g_CiEnabled为0来绕过，目的是让操作系统以为你在WINPE模式中。在WIN8及以上此验证转移到了ci!g_CiOptions上。现在我们在WIN10 14393上做这个实验，验证同样在ci!g_CiOptions。但是不同与WIN8的是，WIN10 已经把ci!g_CiOptions加入到了PatchGuard的豪华套餐中。倘若修改不还原或者修改时机恰巧撞遇PatchGuard的检测。那么一瞬间你将进入蓝屏的节奏…关于PatchGuard，读者可自行搜索相关内容，这里不再展述。
1.寻找ci!g_CiOptions(WindowsSystem32CI.dll)
可以发现，该变量存在于CipInitialize 函数中，但是此函数未导出，不过庆幸的是。CI.dll给我们导出了CiInitialize函数，改函数最后会调用CipInitialize。
那么我们的思路很简单，首先获取导出函数地址CiInitialize，根据它找到CipInitialize函数，最后根据CipInitialize找到g_CiOptions，然后修改为8即可(由于在WIN10 14393版本上进入测试签名模式时，该值为8)。当然得先保存一份之前的数值，便于还原。
2.注意要点
a.IRQL(中断请求等极)
还记得sys的调用函数吗，它的形式如下：
关闭中断->调用Ring3利用函数->开启中断。
我们注意到，再执行我们的利用函数的过程中，中断始终是处于关闭的状态，也就是说我们的IRQL(中断请求等极)一直处于Dispatch级别，而大多数内核函数调用的要求是IRQL==PASSIVE_LEVEL。这就会造成概率性蓝屏。所以我们必须在我们的利用函数头尾处加入_enable和_disable，来手动的配合它的流程，这样我们就可以避免IRQL的问题了。
b.禁用KeStackAttachProcess(CR3切换)
由于该函数会切换CR3(页目录表基址)。并且最终返回到当前进程的CR3。而我们当前是在Ring0模式。所以显示会发生奇妙的蓝屏。。。
c.利用函数尽量简短
因为在WIN10 14393版本上，经过测试SMEP已被加入PatchGuard豪华套餐中。所以需要尽快的将SMEP恢复，这也就意味着我们的利用函数需要尽量的简短。当然了，时运不济的话，可能就在那一瞬间就被检测到了。
d.配合动态PatchGuard
一般而言，做到以上3点，加载/卸载驱动1-5次之间的蓝屏几率是很小的。但是如果需要完美的话，那就要动态的干PatchGuard了。我们知道，在WIN7以及WIN8已经有牛实现了动态干PatchGuard并已放出，但是在WIN10上目前并没有公开放出源代码。不过国内已经有研究者实现了这一攻击效果。
0x4 题外话
对于在微软新签名机制(具体请使用搜索引擎搜索)下有签名的朋友来说，这并没有什么用。但是如果被坏人利用了，那就比较尴尬了。因为此驱动有合法签名，大多数杀毒软件还没有对其拦截，而当坏人进入内核后，那就可以想干啥就干啥了。
0x5 对各大安全厂商的建议
由于Capcom公司目前已经道歉，并承诺不再使用此类手段的情况来看。安全厂商完全可以把该Capcom.sys列入黑名单中，以此彻底绝杀针对该后门的一切利用。
发表评论
您还未登录，请先登录。
登录