吾爱破解 - LCG - LSG |安卓破解|病毒分析|www.52pojie.cn

 找回密码
 注册[Register]

QQ登录

只需一步,快速开始

查看: 4915|回复: 9
收起左侧

[转载] 分析及防护:Win10执行流保护绕过问题

[复制链接]
楚轩 发表于 2015-8-11 21:59
使用论坛附件上传样本压缩包时必须使用压缩密码保护,压缩密码:52pojie,否则会导致论坛被杀毒软件等误报,论坛有权随时删除相关附件和帖子!
病毒分析分区附件样本、网址谨慎下载点击,可能对计算机产生破坏,仅供安全人员在法律允许范围内研究,禁止非法用途!
禁止求非法渗透测试、非法网络攻击、获取隐私等违法内容,即使对方是非法内容,也应向警方求助!
本帖最后由 楚轩 于 2015-8-18 09:56 编辑

Black Hat USA 2015正在进行,在微软安全响应中心公布的最新贡献榜单中,绿盟科技安全研究员张云海位列第6位,绿盟科技安全团队(NSFST)位列28位,绿盟科技安全团队(NSFST)常年致力于发现并解决计算机以及网络系统中存在的各种安全缺陷。这篇《Windows 10执行流保护绕过问题及修复》是团队在此次大会上分享的主要内容

0x00 Content
执行流保护(CFG)CFG原理绕过问题 CustomHeap::Heap对象绕过CFG问题修复 HeapPageAllocator::ProtectPages函数修复机制 0x01 内容摘要

Black Hat USA 2015正在进行,在微软安全响应中心公布的最新贡献榜单中,绿盟科技安全研究员张云海位列第6位,绿盟科技安全团队(NSFST)位列28位,绿盟科技安全团队(NSFST)常年致力于发现并解决计算机以及网络系统中存在的各种安全缺陷。这篇《Windows 10执行流保护绕过问题及修复》是团队在此次大会上分享的主要内容。

1. 1月22日,微软发布Windows 10技术预览版,Build号9926;2. 2月,绿盟科技安全团队(NSFST)展开对其安全机制的研究,发现并与微软一起解决了CFG绕过问题;3. 3月,微软发布补丁修复了CFG绕过问题;4. 7月21日,在绿盟科技Techworld技术大会上分享了此次研究成果;5. 8月7日,在Black Hat US 2015上进行演讲并发布分析文章。

绿盟科技安全团队NSFST一直努力发现及修复计算机以及网络系统中存在的各种安全缺陷,如果您需要了解更多信息,请联系:

绿盟科技微博http://weibo.com/nsfocus绿盟科技微信号搜索公众号绿盟科技0x02 执行流保护(CFG)

攻击者常常溢出覆盖或者直接篡改寄存器EIP的值,篡改间接调用的地址,进而控制了程序的执行流程。执行流保护(CFG,Control Flow Guard)是微软从Windows 8.1 update 3及Windows 10技术预览版开始,默认启用的一项缓解技术。这项技术通过在间接跳转前插入校验代码,检查目标地址的有效性,进而可以阻止执行流跳转到预期之外的地点,最终及时并有效的进行异常处理,避免引发相关的安全问题。

这种思想及技术在业界有了较为成熟的应用,此次Windows 10将其引入,以便提高其安全性。但是绿盟科技安全团队(NSFST)在分析CFG的实现机制过程中,发现了CFG存在全面绕过的方法,随即向微软提报,并在随后的一段时间内,配合微软修复了这个问题。

0x03 CFG原理

在编译启用了CFG的模块时,编译器会分析出该模块中所有间接函数调用可达的目标地址,并将这一信息保存在Guard CF Function Table中。

:006> dds jscript9!\_load\_config\_used + 48 l562b21048 62f043fc jscript9!\_\_guard\_check\_icall\_fptr Guard CF Check Function Pointer62b2104c 00000000 Reserved62b21050 62b2105c jscript9!\_\_guard\_fids\_table Guard CF Function Table62b21054 00001d54 Guard CF Function Count62b21058 00003500 Guard Flags

同时,编译器还会在所有间接函数调用之前插入一段校验代码,以确保调用的目标地址是预期中的地址。这是未启用CFG的情况:

jscript9!Js::JavascriptOperators::HasItem+0x15:66ee9558 8b03 mov eax,dword ptr [ebx]66ee955a 8bcb mov ecx,ebx66ee955c 56 push esi66ee955d ff507c call dword ptr [eax+7Ch]66ee9560 85c0 test eax,eax66ee9562 750b jne jscript9!Js::JavascriptOperators::HasItem+0x2c (66ee956f)

这是启用CFG的情况:

ript9!Js::JavascriptOperators::HasItem+0x1b:62c31e13 8b03 mov eax,dword ptr [ebx]62c31e15 8bfc mov edi,esp62c31e17 52 push edx62c31e18 8b707c mov esi,dword ptr [eax+7Ch]62c31e1b 8bce mov ecx,esi62c31e1d ff15fc43f062 call dword ptr [jscript9!\_\_guard\_check\_icall\_fptr (62f043fc)]62c31e23 8bcb mov ecx,ebx62c31e25 ffd6 call esi62c31e27 3bfc cmp edi,esp62c31e29 0f8514400c00 jne jscript9!Js::JavascriptOperators::HasItem+0x33 (62cf5e43)

操作系统在创建支持CFG的进程时,将CFG Bitmap映射到其地址空间中,并将其基址保存在ntdll!LdrSystemDllInitBlock+0x60中。

CFG Bitmap是记录了所有有效的间接函数调用目标地址的位图,出于效率方面的考虑,平均每1位对应8个地址(偶数位对应1个0x10对齐的地址,奇数位对应剩下的15个非0x10对齐的地址)。

提取目标地址对应位的过程如下: * 取目标地址的高24位作为索引i; * 将CFG Bitmap当作32位整数的数组,用索引i取出一个32位整数bits; * 取目标地址的第4至8位作为偏移量n; * 如果目标地址不是0x10对齐的,则设置n的最低位; * 取32位整数bits的第n位即为目标地址的对应位。

操作系统在加载支持CFG的模块时,根据其Guard CF Function Table来更新CFG Bitmap中该模块所对应的位。同时,将函数指针\_guard\_check\_icall\_fptr初始化为指向ntdll!LdrpValIDAteUserCallTarget。

ntdll!LdrpValidateUserCallTarget从CFG Bitmap中取出目标地址所对应的位,根据该位是否设置来判断目标地址是否有效。若目标地址有效,则该函数返回进而执行间接函数调用;否则,该函数将抛出异常而终止当前进程。

ll!LdrpValidateUserCallTarget:774bd970 8b1570e15377 mov edx,dword ptr [ntdll!LdrSystemDllInitBlock+0x60 (7753e170)]774bd976 8bc1 mov eax,ecx774bd978 c1e808 shr eax,8774bd97b 8b1482 mov edx,dword ptr [edx+eax\*4]774bd97e 8bc1 mov eax,ecx774bd980 c1e803 shr eax,3774bd983 f6c10f test cl,0Fh774bd986 7506 jne ntdll!LdrpValidateUserCallTargetBitMapRet+0x1 (774bd98e)ntdll!LdrpValidateUserCallTargetBitMapCheck+0xd:774bd988 0fa3c2 bt edx,eax774bd98b 730a jae ntdll!LdrpValidateUserCallTargetBitMapRet+0xa (774bd997)ntdll!LdrpValidateUserCallTargetBitMapRet:774bd98d c3 retntdll!LdrpValidateUserCallTargetBitMapRet+0x1:774bd98e 83c801 or eax,1774bd991 0fa3c2 bt edx,eax774bd994 7301 jae ntdll!LdrpValidateUserCallTargetBitMapRet+0xa (774bd997)ntdll!LdrpValidateUserCallTargetBitMapRet+0x9:774bd996 c3 ret0x04 绕过问题

通过上面的原理分析,我们发现CFG的实现中存在一个隐患,校验函数ntdll!LdrpValidateUserCallTarget是通过函数指针\_guard\_check\_icall\_fptr来调用的。

如果我们修改\_guard\_check\_icall\_fptr,将其指向一个合适的函数,就可以使任意目标地址通过校验,从而全面的绕过CFG。通常情况下,\_guard\_check\_icall\_fptr是只读的:

06> x jscript9!___guard_check_icall_fptr62f043fc          jscript9!__guard_check_icall_fptr = <no type information>0:006> !address 62f043fcUsage:                  ImageBase Address:           62f04000End Address:            62f06000Region Size:            00002000State:                  00001000    MEM_COMMITProtect:                00000002    PAGE_READONLYType:                   01000000    MEM_IMAGEAllocation Base:        62b20000Allocation Protect:     00000080    (null)Image Path:             C:\Windows\System32\jscript9.dllModule Name:            jscript9Loaded Image Name:      C:\Windows\System32\jscript9.dllMapped Image Name:

但如果利用jscript9中的CustomHeap::Heap对象将其变成可读写的,那么就会出现问题了。

0x05 CustomHeap::Heap对象

CustomHeap::Heap是jscript9中用于管理私有堆的类,其结构如下:

stomHeap::Heap+0x000  HeapPageAllocator           :    PageAllocator+0x060  HeapArenaAllocator          :    Ptr32 ArenaAllocator+0x064  PartialPageBuckets          :    [7] DListBase<CustomHeap::Page>+0x09c  FullPageBuckets             :    [7] DListBase<CustomHeap::Page> +0x0d4  LargeObjects                :    DListBase<CustomHeap::Page>+0x0dc  DecommittedBuckets          :    DListBase<CustomHeap::Page>+0x0e4  DecommittedLargeObjects     :    DListBase<CustomHeap::Page>+0x0ec  CriticalSection             :    LPCRITICAL_SECTION

当CustomHeap::Heap对象析构时,其析构函数会调用CustomHeap::Heap::FreeAll来释放所有分配的内存。

__thiscall CustomHeap::Heap::~Heap(CustomHeap::Heap *this){  CustomHeap::Heap *v1; // esi@1  v1 = this;  CustomHeap::Heap::FreeAll(this);  DeleteCriticalSection((LPCRITICAL_SECTION)((char *)v1 + 0xEC));  \'eh vector destructor iterator\'((int)((char *)v1 + 0x9C), 8u, 7, sub_10010390);  \'eh vector destructor iterator\'((int)((char *)v1 + 0x64), 8u, 7, sub_10010390);  return PageAllocator::~PageAllocator(v1);}

CustomHeap::Heap::FreeAll 为每个Bucket对象调用CustomHeap::Heap::FreeBucket。

d __thiscall CustomHeap::Heap::FreeAll(CustomHeap::Heap *this){  CustomHeap::Heap *v1; // esi@1  signed int v2; // ebx@1  int v3; // edi@1  int v4; // ecx@2  v1 = this;  v2 = 7;  v3 = (int)((char *)this + 0x9C);  do  {    CustomHeap::Heap::FreeBucket(v1, v3 - 0x38, (int)this);    CustomHeap::Heap::FreeBucket(v1, v3, v4);    v3 += 8;    --v2;  }  while ( v2 );  CustomHeap::Heap::FreeLargeObject<1>(this);  CustomHeap::Heap::FreeDecommittedBuckets(v1);  CustomHeap::Heap::FreeDecommittedLargeObjects(v1);}

CustomHeap::Heap::FreeBucket 遍历Bucket的双向链表,为每个节点的CustomHeap::Page 对象调用CustomHeap::Heap::EnsurePageReadWrite<1,4>。

__thiscall CustomHeap::Heap::FreeBucket(PageAllocator *this, int a2, int a3){  PageAllocator *v3; // edi@1  int result; // eax@2  int v5; // esi@3  int v6; // [sp+8h] [bp-8h]@1  int v7; // [sp+Ch] [bp-4h]@1  v3 = this;  v6 = a2;  v7 = a2;  while ( 1 )  {    result = SListBase<Bucket<AddPropertyCacheBucket>,FakeCount>::Iterator::Next(&v6);    if ( !(_BYTE)result )      break;    v5 = v7 + 8;    CustomHeap::Heap::EnsurePageReadWrite<1,4>(v7 + 8);    PageAllocator::ReleasePages(v3, *(void **)(v5 + 0xc), 1u, *(struct PageSegment **)(v5 + 4));    DListBase<CustomHeap::Page>::EditingIterator::RemoveCurrent<ArenaAllocator>(*((ArenaAllocator **)v3 + 0x18));  }  return result;}

CustomHeap::Heap::EnsurePageReadWrite<1,4> 用以下参数调用VirtualProtect:

lpAddress: CustomHeap::Page 对象的成员变量addressdwSize: 0x1000

flNewProtect: PAGE_READWRITE

RD __stdcall CustomHeap::Heap::EnsurePageReadWrite<1,4>(int a1) { DWORD result; // eax@3 DWORD flOldProtect; // [sp+4h] [bp-4h]@3 if ( (_BYTE *)(a1 + 1) || *(_BYTE *)a1 ) { result = 0; } else { flOldProtect = 0; VirtualProtect((LPVOID *)(a1 + 0xC), 0x1000u, 4u, &flOldProtect); result = flOldProtect; *(_BYTE *)(a1 + 1) = 1; } return result; }

将内存页面标记为PAGE_READWRITE, 这正是出现问题的关键地方。

0x06 绕过CFG

通过修改CustomHeap::Heap对象,我们可以将一个只读页面变成可读写的,从而可以改写函数指针\_guard\_check\_icall\_fptr的值。观察ntdll!LdrpValidateUserCallTarget在目标地址有效时执行的指令:

mov     eax,ecxshr     eax,8mov     edx,dword ptr [edx+eax*4]mov     eax,ecxshr     eax,3test    cl,0Fhjne     ntdll!LdrpValidateUserCallTargetBitMapRet+0x1 (774bd98e)bt      edx,eaxjae     ntdll!LdrpValidateUserCallTargetBitMapRet+0xa (774bd997)ret

从调用者的角度来看,上述指令与单条ret指令之间并没有本质区别。因此,将函数指针\_guard\_check\_icall\_fptr改写为指向ret指令,就可以使任意的目标地址通过校验,从而全面的绕过CFG。

0x07 问题修复

绿盟科技安全团队(NSFST)发现这一问题后,立即向微软报告了相关情况。微软很快修复了这一问题,并在2015年3月发布了相关的补丁。在该补丁中,微软引入了一个新的函数HeapPageAllocator::ProtectPages。

0x08 HeapPageAllocator::ProtectPages函数
__thiscall HeapPageAllocator::ProtectPages(HeapPageAllocator *this, LPCVOID lpAddress, unsigned int a3, struct Segment *a4, DWORD flNewProtect, unsigned __int32 *a6, unsigned __int32 a7){  unsigned __int32 v7; // ebx@1  unsigned int v8; // edx@2  int result; // eax@7  struct _MEMORY_BASIC_INFORMATION Buffer; // [sp+Ch] [bp-20h]@4  DWORD flOldProtect; // [sp+28h] [bp-4h]@7  v7 = (unsigned __int32)this;  if ( (unsigned __int16)lpAddress & 0xFFF    || (v8 = *((_DWORD *)a4 + 2), (unsigned int)lpAddress < v8)    || (unsigned int)((char *)lpAddress - v8) > (*((_DWORD *)a4 + 3) - a3) << 12    || !VirtualQuery(lpAddress, &Buffer, 0x1Cu)    || Buffer.RegionSize < a3 << 12    || a7 != Buffer.Protect )  {    CustomHeap_BadPageState_fatal_error(v7);    result = 0;  }  else  {    *a6 = Buffer.Protect;    result = VirtualProtect((LPVOID)lpAddress, a3 << 12, flNewProtect, &flOldProtect);  }  return result;}

这个函数是VirtualProtect的一个封装,在调用VirtualProtect之前对参数进行校验,如下:

检查lpAddress是否是0x1000对齐的;检查lpAddress是否大于Segment的基址;检查lpAddress加上dwSize是否小于Segment的基址加上Segment的大小;检查dwSize是否小于Region的大小;检查目标内存的访问权限是否等于指定的(通过参数)访问权限;

任何一个检查项未通过,都会调用CustomHeap_BadPageState_fatal_error抛出异常而终止进程。

0x09 修复机制

CustomHeap::Heap::EnsurePageReadWrite<1,4>改为调用HeapPageAllocator::ProtectPages而不再直接调用VirtualProtect。

unsigned __int32 __thiscall CustomHeap::Heap::EnsurePageReadWrite<1,4>(HeapPageAllocator *this, int a2)2  {3    unsigned __int32 result; // eax@24    unsigned __int32 v3; // [sp+4h] [bp-4h]@55  6    if ( *(_BYTE *)(a2 + 1) || *(_BYTE *)a2 )7    {8      result = 0;9    }10    else11    {12      v3 = 0;13      HeapPageAllocator::ProtectPages(this, *(LPCVOID *)(a2 + 12), 1u, *(struct Segment **)(a2 + 4), 4u, &v3, 0x10u);14      result = v3;15      *(_BYTE *)(a2 + 1) = 1;16    }17    return result;18  }

这里参数中指定的访问权限是PAGE_EXECUTE,从而防止了利用CustomHeap::Heap将只读内存页面变成可读写内存页面。


发帖前要善用论坛搜索功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。

5598869 发表于 2015-8-11 22:07
说的什么啊!!!!!!!
云在青霄水在瓶 发表于 2015-8-12 00:34
wuftszg 发表于 2015-8-12 11:35
常黑屏 发表于 2015-8-15 12:28
看看哦,呵呵
willJ 发表于 2015-8-18 09:47
建议整理下格式再发吧,看原作者文章听好看的

http://blog.nsfocus.net/win10-cfg-bypass/
xiaomi1991 发表于 2016-4-8 10:53
支持楼主 学习了
xiaomi1991 发表于 2016-4-8 10:55
支持楼主 学习了
Conc0rd 发表于 2016-4-30 00:29
支持,学习了。
chen4321 发表于 2016-4-30 08:13
完全没看懂的赶脚,话说virtual不是工作在ring-1下吗,超级权限
您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则 警告:本版块禁止灌水或回复与主题无关内容,违者重罚!

快速回复 收藏帖子 返回列表 搜索

RSS订阅|小黑屋|处罚记录|联系我们|吾爱破解 - LCG - LSG ( 京ICP备16042023号 | 京公网安备 11010502030087号 )

GMT+8, 2024-3-29 13:30

Powered by Discuz!

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表