-
-
[原创]用户模式APC蓝屏分析报告
-
发表于: 2009-1-13 17:17
-
关键词：APC，蓝屏，QueueUserAPC，ZwQueueApcThread，漏洞
曾在看雪上看到一篇 【囧】Ring3下把Windows XP SP2 弄蓝了…… 的帖子。
出于好奇，改了段QueueUserAPC的Delphi的代码（见该贴的5楼），结果SP3下也蓝屏了：
也许是太简单了，苦等不见高手回复。正好在学漏洞分析这门课，就拿这个问题来练手了
。
最后分析发现，其实这个蓝屏原因很简单——QueueUserAPC的调用上范了初级错误，APC插csrss后执行出错，导致csrss被OS中止掉了。
虽然简单，不过重要的是分析过程，所以在这里记录一下。分析中难免有错，高手飘过...
-------------------------------------------------------------------------------------------------
由于出问题的API是QueueUserAPC，于是尝试着用OllyDbg跟入检查原因。可以看到，QueueUserAPC实际是通过调用ntdll!ZwQueueApcThread实现的。不过ZwQueueApcThread没办法进一步跟进去：
SYSENTER之后进入Ring0，OD是拿它没办法的。
好在实际测试发现，并不是SYSENTER进入后就马上蓝屏，也就是说出问题的地方并不是ntdll.KiFastSystemCall中。
由于不会SoftICE，所以没法进一步跟踪，看来只能从DUMP文件入手。
在“启动和故障恢复”选项卡中，选择核心内存转储方式（图2），然后运行引起蓝屏的程序，让Windows输出蓝屏时的内存DUMP：
这样，蓝屏后就会将高端内存输出到C:\WINDOWS\MEMORY.DMP中。用WinDBG打开DMP文件，!analyze -v进行分析（详细分析方法见二楼），发现该蓝屏的产生是系统关键进程CSRSS被意外终止所导致的。据此可以初步断定，由于ZwQueueApcThread插入APC队列使csrss.exe被终止，而不是最早插入APC的SYSTEM和SMSS.EXE这两个进程。
看来不了解APC的原理是无法继续分析了，我们先来看看什么是APC。APC即异步过程调用，是（Asynchronous Procedure Call）的缩写。这里直接引用《谈谈对APC的一点理解》中的原话：
简单来说，APC通过 Alertable I/O 提供更有效的异步通知形式，当IO请求完成后，一旦线程进入可告警状态（Alertable），我们在APC队列中设置的回调函数将会执行，此时我们将获得目标线程的控制权直至返回。
APC在Windows系统中应用相当广泛，实际上TerminateThread就是利用APC实现的。使用TerminateThread可以在任何时候结束指定线程。查阅微软支持库Q254956（http://support.microsoft.com/kb/254956/en-us/）可知，调用TerminateThread会在目标进程中产生一个APC队列，然后强制所有线程进入等待状态，用于执行APC队列中的ExitThread函数，从而结束目标进程。这是一种典型的APC应用，由于使用APC来执行退出进程操作，这就导致了被TerminateThread结束的线程不能回到自身的清理函数中，这也是APC的一个特性。[/url]
APC方式执行的回调函数，实际上是中断目标进程转入指定回调程序执行。这样的好处在于不会有新的线程产生，而且可以控制目标线程的执行流程。返回目标进程领空也比较简单，由于APC调用前已经把返回地址压入堆栈中，只需适时的执行一条ret指令便可以返回，而无需像挂钩子函数或者远程线程中，执行繁琐的清理操作。
这么一来就清楚了。一旦我们劫持csrss.exe中的某个线程，让他去执行一些非法操作，于是csrss.exe就壮烈牺牲了。
有人说了，将CallBack地址赋值LoadLibraryA也会引起蓝屏？首先我要说的是，表1中那段APC代码实际是错的，光调用一个QueueUserAPC函数就错了两个参数，也正是因为写得有问题才引起的目标程序访问违规：
由Delphi的调用规范可知，参数1（@LoadLibraryA）是取LoadLibraryA的地址。然而，这里取得的并非LoadLibraryA的真正地址，而是一个JMP指令（不清楚的可以用OD跟踪一下程序中的API调用）。正确方法应该是通过GetProcAddress取得LoadLibraryA函数入口，这样才能继续。当然，参数3（DWORD(pStrDll)）是另一个错误所在，将pStrDll这个DLL名字指针强制转成DWORD型是没有错误，问题在于这个pStrDll所指内容是在本地进程中的，要是在其他进程里访问这个地址，内容肯定不一样。
是不是很熟悉，QueueUserAPC这个API调用其实和CreateRemoteThread很像，只不过其根本不同在于CreateRemoteThread要创建新的线程用于执行我们的目标代码，而QueueUserAPC不用。
-------------------------------------------------------------------------------------------------
另外说说网上一些关于APC注入的误区。APC注入参数1不一定非要是LoadLibraryA，其他API也是可行的（网上教程都用LoadLibrary是因为载入DLL实现起来比较简单而且通用）。APC的可以帮助我们执行指定位置的任意代码，只要把QueueUserAPC参数1的指针指向要执行的ShellCode，然后等待系统处理这个用户模式APC就行了。
当然，搬网上某些APC注入教程的原话，“有时你等得花儿都谢了APC还没有执行”。确实如此，只有当目标线程调用了SleepEx、WaitForSingleObjectEx、WaitForMultipleObjectsEx等API时，用户模式APC才能执行，这也是大多数线程插入APC后没有反应的原因。就目前来看，公认的方法是通过暴力注入explorer.exe的所有线程来达到目标效果。实际explorer中，通常都会有这样两个线程等着你去插入：
这两个进程可以通过Sysinternals的Process Explorer的线程列表进行查看，他们会不断的进入Alertable等待状态，所以可以顺利执行ShellCode。
曾在看雪上看到一篇 【囧】Ring3下把Windows XP SP2 弄蓝了…… 的帖子。
出于好奇，改了段QueueUserAPC的Delphi的代码（见该贴的5楼），结果SP3下也蓝屏了：
也许是太简单了，苦等不见高手回复。正好在学漏洞分析这门课，就拿这个问题来练手了
。最后分析发现，其实这个蓝屏原因很简单——QueueUserAPC的调用上范了初级错误，APC插csrss后执行出错，导致csrss被OS中止掉了。
虽然简单，不过重要的是分析过程，所以在这里记录一下。分析中难免有错，高手飘过...
-------------------------------------------------------------------------------------------------
由于出问题的API是QueueUserAPC，于是尝试着用OllyDbg跟入检查原因。可以看到，QueueUserAPC实际是通过调用ntdll!ZwQueueApcThread实现的。不过ZwQueueApcThread没办法进一步跟进去：
7C92E23D > B8 B4000000 MOV EAX,0B4 ; ZwQueueApcThread 7C92E242 BA 0003FE7F MOV EDX,7FFE0300 7C92E247 FF12 CALL DWORD PTR DS:[EDX] ; ntdll.KiFastSystemCall 7C92E249 C2 1400 RETN 14 SS: 0012FF30 7C834174 返回到 kernel32.7C834174 来自 ntdll.ZwQueueApcThread 7C92EB8B > 8BD4 MOV EDX,ESP ; ntdll.KiFastSystemCall 7C92EB8D 0F34 SYSENTER
SYSENTER之后进入Ring0，OD是拿它没办法的。
好在实际测试发现，并不是SYSENTER进入后就马上蓝屏，也就是说出问题的地方并不是ntdll.KiFastSystemCall中。
由于不会SoftICE，所以没法进一步跟踪，看来只能从DUMP文件入手。
在“启动和故障恢复”选项卡中，选择核心内存转储方式（图2），然后运行引起蓝屏的程序，让Windows输出蓝屏时的内存DUMP：
这样，蓝屏后就会将高端内存输出到C:\WINDOWS\MEMORY.DMP中。用WinDBG打开DMP文件，!analyze -v进行分析（详细分析方法见二楼），发现该蓝屏的产生是系统关键进程CSRSS被意外终止所导致的。据此可以初步断定，由于ZwQueueApcThread插入APC队列使csrss.exe被终止，而不是最早插入APC的SYSTEM和SMSS.EXE这两个进程。
看来不了解APC的原理是无法继续分析了，我们先来看看什么是APC。APC即异步过程调用，是（Asynchronous Procedure Call）的缩写。这里直接引用《谈谈对APC的一点理解》中的原话：
1) APCs允许用户程序和系统元件在一个进程的地址空间内某个线程的上下文中执行代码。
2) I/O管理器使用APCs来完成一个线程发起的异步的I/O操作。
3) 使用APC可以得到或者设置一个线程的上下文和挂起线程的执行。
在NT中，有两种类型的APCs：用户模式和内核模式。……用户模式的APCs需要目标线程处在Alertable等待状态才能被成功的调度执行。对于用户模式下，可以调用SleepEx, WaitForSingleObjectEx等API使目标线程处于Alertable等待状态，从而让用户模式APCs执行。当一个用户模式APC被投递到一个线程，调用上面的等待函数，如果返回等待状态STATUS_USER_APC，在返回用户模式时，内核转去控制APC例程，当APC例程完成后，再继续线程的执行。
简单来说，APC通过 Alertable I/O 提供更有效的异步通知形式，当IO请求完成后，一旦线程进入可告警状态（Alertable），我们在APC队列中设置的回调函数将会执行，此时我们将获得目标线程的控制权直至返回。
APC在Windows系统中应用相当广泛，实际上TerminateThread就是利用APC实现的。使用TerminateThread可以在任何时候结束指定线程。查阅微软支持库Q254956（http://support.microsoft.com/kb/254956/en-us/）可知，调用TerminateThread会在目标进程中产生一个APC队列，然后强制所有线程进入等待状态，用于执行APC队列中的ExitThread函数，从而结束目标进程。这是一种典型的APC应用，由于使用APC来执行退出进程操作，这就导致了被TerminateThread结束的线程不能回到自身的清理函数中，这也是APC的一个特性。[/url]
APC方式执行的回调函数，实际上是中断目标进程转入指定回调程序执行。这样的好处在于不会有新的线程产生，而且可以控制目标线程的执行流程。返回目标进程领空也比较简单，由于APC调用前已经把返回地址压入堆栈中，只需适时的执行一条ret指令便可以返回，而无需像挂钩子函数或者远程线程中，执行繁琐的清理操作。
这么一来就清楚了。一旦我们劫持csrss.exe中的某个线程，让他去执行一些非法操作，于是csrss.exe就壮烈牺牲了。
有人说了，将CallBack地址赋值LoadLibraryA也会引起蓝屏？首先我要说的是，表1中那段APC代码实际是错的，光调用一个QueueUserAPC函数就错了两个参数，也正是因为写得有问题才引起的目标程序访问违规：
完整代码点这里
pStrDll := PAnsiChar(dllName);
QueueUserAPC(@LoadLibraryA, hThread, DWORD(pStrDll));
由Delphi的调用规范可知，参数1（@LoadLibraryA）是取LoadLibraryA的地址。然而，这里取得的并非LoadLibraryA的真正地址，而是一个JMP指令（不清楚的可以用OD跟踪一下程序中的API调用）。正确方法应该是通过GetProcAddress取得LoadLibraryA函数入口，这样才能继续。当然，参数3（DWORD(pStrDll)）是另一个错误所在，将pStrDll这个DLL名字指针强制转成DWORD型是没有错误，问题在于这个pStrDll所指内容是在本地进程中的，要是在其他进程里访问这个地址，内容肯定不一样。
是不是很熟悉，QueueUserAPC这个API调用其实和CreateRemoteThread很像，只不过其根本不同在于CreateRemoteThread要创建新的线程用于执行我们的目标代码，而QueueUserAPC不用。
-------------------------------------------------------------------------------------------------
另外说说网上一些关于APC注入的误区。APC注入参数1不一定非要是LoadLibraryA，其他API也是可行的（网上教程都用LoadLibrary是因为载入DLL实现起来比较简单而且通用）。APC的可以帮助我们执行指定位置的任意代码，只要把QueueUserAPC参数1的指针指向要执行的ShellCode，然后等待系统处理这个用户模式APC就行了。
当然，搬网上某些APC注入教程的原话，“有时你等得花儿都谢了APC还没有执行”。确实如此，只有当目标线程调用了SleepEx、WaitForSingleObjectEx、WaitForMultipleObjectsEx等API时，用户模式APC才能执行，这也是大多数线程插入APC后没有反应的原因。就目前来看，公认的方法是通过暴力注入explorer.exe的所有线程来达到目标效果。实际explorer中，通常都会有这样两个线程等着你去插入：
ntdll!RtlQueueWorkItem+0x2b5 ntdll!RtlDowncaseUnicodeString+0x75
这两个进程可以通过Sysinternals的Process Explorer的线程列表进行查看，他们会不断的进入Alertable等待状态，所以可以顺利执行ShellCode。
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
这是注入CSRSS并且LoadLibraryA一个显示对话框的DLL引起的蓝屏截图，相关代码见此楼附件：
 同样的使用WinDbg分析，可以得到如下信息：
可见这个BSOD是由于内存访问违规引起的。由于win32k.sys中的这条指令，读取了0xf0006c74的内容，而0xf0006c74不再内存中，于是引起了蓝屏。 0008:bf838c27 8b7108 mov esi,dword ptr [ecx+8] ; ds:0023:f0006c74=???????? 回想这个蓝屏发生的原因，由于LoadLibrary了一个cmdShell到csrss.exe的第二个线程中，结果就出现了这个蓝屏。查看蓝屏前的堆栈，可以看到这样三行： 0055fa34 7c801d6e 7ffdcc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e 0055fa48 7c801da4 016e0000 00000000 00000000 KERNEL32!LoadLibraryExA+0x1f 0055fa64 7c8341cc 016e0000 0055fac0 00000000 KERNEL32!LoadLibraryA+0x94 这说明了LoadLibraryA确实被执行了。也就是说如果我们写一段ShellCode到CSRSS中，就可以利用CSRSS的权限作我们想做的事情。至于注入CSRSS所需要的权限，例如管理员、SeDebugPrivilege等，参见其他注入教程中关于OpenThread和OpenProcess的部分。 --------------------------------------------------------------------------------------- 附件 APC_src.rar 说明： \APC注入_D2009\AnyAPC_Boom.rar 里面是APC注入的主程序，用法见源码目录下的readme.txt \注射用DLL\多线程cmdshell\s32.dll 改成32.dll丢到Windows安装目录中，注入后监听3820端口，可以Telnet试 相关的程序源码都在里面，自己看吧。另外，建议先扫一遍毒再运行
|
|
|
|
|
|
我那句“这也说明了利用APC可以执行任意地址的代码，而不是固定的在某个位置崩溃。”是复制出来的
，放这里确实点歧义 。WinDbg不熟，不过这两个蓝屏大致还是知道原因： 第一个蓝屏说的 关键进程 就是CSRSS，因为插入了错误的APC回调地址到CSRSS中，导致CSRSS.exe执行非法操作被终止。（这个道理很简单，比如在CSRSS中创建一个远程线程，开始地址随便设个不能正确执行的地方，一样会引发这种蓝屏） 第二个蓝屏是向CSRSS中LoadLibraryA一个命令行Shell的DLL引发的（可以看堆栈中我加粗的三行，说明LoadLibrary执行过了），虽然不知道为什么会蓝，不过肯定不是0Day。这个代码我整理一下稍后上传，今天下午有点事出去了。 不知道这两点我说的对不？ 关于第二个蓝屏，carsh dump分析中可以看到： |
|
|
|
|
|
临界进程/线程没接触过，我内核这块只能算是触及了点皮毛。
csrss是ring3，不过当csrss被结束时，依然会蓝屏（也就是第一种蓝屏——关键进程被结束）。 这是今天早上对csrss的第二个线程插入APC引发蓝屏的dump分析，回调地址随便设的一个0x80008000，参数设的是0x0F0F0F0F。
这个蓝屏的原因没说错吧，CSRSS因为执行插入的APC回调地址0x80008000的全零地址，访问违规被OS给结束掉了。 对于第二个蓝屏，也就是我发这个报告的原因了。到底是什么引起的，不知道您能不能详细分析一下 为方便测试，传了一个测试包上来，具体见压缩包里的测试说明。 |
|
|
|
|
|
很认真的分析文章 学习
|
|
|
你说的对。
第二个蓝屏我用的DLL好像不是cmdShell，刚才又试了一下，csrss中cmdShell也能加载成功。 根据2楼那个dump的堆栈情况看，应该是压缩包testdll目录下的那个MessageBox的，我再去仔细看看原因。 果然是MessageBox！换了个DLL，这次就不再是关键进程结束了    蓝屏和二楼相同： 
那个r32.dll和源码见附件，就MessageBox然后ExitThread而已。
|
|
|
深刻的讨论，坐着学习
|
|
|
总有一些发垃圾评论的，看着就恶心！
 学习，学习，学习你做个什么声啊！ |
|
|
|
|
|
我觉得是因为CSRSS的线程不属于桌面，这里硬要显示个对话框才蓝掉的。先看堆栈：
STACK_TEXT: 加粗的 win32k!NtUserGetDCEx+0x2c 说明了0x804e006b前面的一个Call跳到了NtUserGetDCEx。接着看蓝色部分0xbf838c27，这就是出错位置，所以转到了nt!KiTrap0E进行错误处理。所以大致可以确定是在 NtUserGetDCEx 里出的问题。 看到一篇叫“A Story of Unchecked Assumptions in the Windows Kernel”的文章，里面的第28页说了个有趣的特性： All threads are part of a desktop Except CSRSS-owned threads 简单讲就是除了CSRSS的线程外都是桌面的一部分，CSRSS不会调用NtUserGetThreadState或者NtUserGetDCEx所以不会有问题 所以只要有线程在CSRSS里访问NtUserGetDCEx就挂了，第二个蓝屏估计是这个原因。 另外该文章的作者也提出了这种代码，我想效果应该差不多。 hCsrss = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwCsrssId); CreateRemoteThread(hCsrss, NULL, 0, NtUserGetThreadState, 15, 0, NULL); 看来老外早就在做这方面的研究了啊 
|
|
|
|
|
|
|
