ycdxsb research / windows17 分钟 读完 (大约 2582 个字)  0次访问

Windows内核利用——从任意地址写到任意地址读写

Windows内核利用：使用GDI结构从任意地址写到任意地址读写利用技术的攻防演进

前言#

假设我们已经存在一个任意地址写任意值的内核漏洞，我们的最终目的是要实现提权。

这个时候我们就需要先回答这个问题：什么地址，写什么值可以让我们实现提权呢？

我们比较常用的方法是将exp进程的token地址替换为System进程的token地址，启动system cmd，因此这个问题也很好回答：

什么地址：exp进程的token地址

写什么值：System进程的token值

但是处于普通用户权限的exp进程并不能知道当前进程的token地址，也不知道System进程的token值，我们只有一个内核里的任意地址写任意值的漏洞。那什么东西可以让我们实现最终的提权呢？这就是本文的主要内容。

Windows对象#

Windows 中存在着 3 种类型的对象，分别为 user object、GDI object、Kernel object，一共有 40 多种对象

其中：

  • bitmap对象属于 GDI object，存在于换页会话池中

  • Accelerator table 对象属于 user object，存在于换页会话池中

  • 桌面堆对象属于 user object，存在于换页会话池中

  • Palette对象属于GDI object，存在于换页会话池中

存在于同一会话池中的对象，可以通过堆风水的技术使得攻击者可以稳定的分配到同一块内存空间，实现内核地址的泄露

BitMap RS1(v1607)前#

BitMap结构#

BitMap是Windows GDI的一个对象，存在于内核中，可以帮助我们实现从任意地址写到任意地址读写。

img

当新建一个BitMap对象时，会在内核中分配三个结构，分别是BaseObject,SURFObj和Pixel Data，其中SURFOBJ中的pvScan0指向Pixel Data，另外，用户态进程可以通过GetBitmapBits和SetBitmapBits来读写pvScan0指向的PixelData数据区 => 用户态进程可以操作内核数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
typedef struct _BASEOBJECT32 // 5 elements, 0x10 bytes (sizeof)
 {
	ULONG32 hHmgr;
	ULONG32 ulShareCount;
	WORD cExclusiveLock;
	WORD BaseFlags;
	ULONG32 Tid;
 }BASEOBJECT32, *PBASEOBJECT32; 
 
 typedef struct _BASEOBJECT64 // 0x18
 {
	ULONG64 hHmgr;
	ULONG32 ulShareCount;
	WORD cExclusiveLock;
	WORD BaseFlags;
	ULONG64 Tid;

	void operator=(const BASEOBJECT32 &base )
	{
		hHmgr = base.hHmgr;
		ulShareCount = base.ulShareCount;
		cExclusiveLock = base.cExclusiveLock;
		BaseFlags = base.cExclusiveLock;
		Tid = base.Tid;
	}

	bool operator==(const _BASEOBJECT64 &base )
	{
		return ((hHmgr == base.hHmgr) && (Tid == base.Tid));
	}

	void dump()
	{
		dprint("BASEOBJECT:\n");
		dprint("\thHmgr: %08lx\n", hHmgr);
		dprint("\tulShareCount: %08lx\n", ulShareCount);
		dprint("\tcExclusiveLock: %04lx\n", cExclusiveLock);
		dprint("\tBaseFlags: %04lx\n", BaseFlags);
		dprint("\tTid: %016I64x\n\n", Tid);
	}

 }BASEOBJECT64, *PBASEOBJECT64;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
typedef struct _SURFOBJ32 { pvScan0偏移0x20
	ULONG32 dhsurf;  // +4
	ULONG32  hsurf;  // +4
	ULONG32 dhpdev;  // +4
	ULONG32   hdev;  // +4
	SIZEL  sizlBitmap; // +8
        /*
        typedef struct tagSIZE
        {
            LONG        cx;
            LONG        cy;
        } SIZE, *PSIZE, *LPSIZE;

        typedef SIZE               SIZEL;
       */
	ULONG  cjBits;   // +4
	ULONG32  pvBits; // +4
	ULONG32  pvScan0; 
	LONG   lDelta;
	ULONG  iUniq;
	ULONG  iBitmapFormat;
	USHORT iType;
	USHORT fjBitmap;
} SURFOBJ32 ;


typedef struct _SURFOBJ64 { pvScan0偏移0x38
	ULONG64  dhsurf; // +8
	ULONG64  hsurf;  // +8
	ULONG64  dhpdev; // +8
	ULONG64  hdev;   // +8
	SIZEL  sizlBitmap; // +8
	ULONG64  cjBits; // +8
	ULONG64  pvBits; // +8
	ULONG64  pvScan0;
	LONG32  lDelta;
	ULONG32  iUniq;
	ULONG32  iBitmapFormat;
	USHORT  iType;
	USHORT  fjBitmap;

	void operator=(const SURFOBJ32 &surf )
	{
		dhsurf = surf.dhsurf;
		hsurf = surf.hsurf;
		dhpdev = surf.dhpdev;
		hdev = surf.hdev;
		sizlBitmap = surf.sizlBitmap;
		cjBits = surf.cjBits;
		pvBits = surf.pvBits;
		pvScan0 = surf.pvScan0;
		lDelta = surf.lDelta;
		iUniq = surf.iUniq;
		iBitmapFormat = surf.iBitmapFormat;
		iType = surf.iType;
		fjBitmap = surf.fjBitmap;
	}

} SURFOBJ64;

泄露内核信息#

CreateBitmap 创建 Bitmap 对象后，会返回对应的资源句柄，该句柄的低16位是数组的访问下标

1
UINT index = hBitmap & 0xFFFF;

通过下标可以找到对应的GDI对象

1
2
3
4
5
6
7
8
9
10
11
struct _GDI_CELL GdiSharedHandleTable[0x8fff];

struct _GDI_CELL
{
    IntPtr pKernelAddress;
    UInt16 wProcessId;
    UInt16 wCount;
    UInt16 wUpper;
    UInt16 wType;
    IntPtr pUserAddress;
}

GdiSharedHandleTable可以在用户态通过TEB->PEB->GdiSharedHandleTable获取到。
GDI_CELL结构在32位下大小为0x10，64位下为0x18。它的第一个指针 pKernelAddress 指向了 BASEOBJECT 的第一个字节

由于SURFACE OBJ结构体的偏移固定，可以泄露pvScan0的内核信息，过程如下：

pvScan0 = *(PDWORD32)pKernelAddress + (x86:0x10,x64:0x18) + (x86:0x20,x64:0x38)

此时，我们可以在用户态找到内核态的PvScan0地址

单次任意地址写 -> 单次任意地址读写#

当我们有了一个任意地址写任意值的能力时，我们可以通过以下流程使用BITMAP进行利用

  1. 新建BITMAP结构
  2. 用户态获取位于内核中的pvScan0地址
  3. 任意地址写漏洞改写 pvScan0 的值为我们想要读写的地址
  4. 使用GetBitMapBits和SetBitMapBits读写任意值

但是上面的流程好像只比原来的漏洞多了一个读的能力，当漏洞只能触发一次时，一次读写根本不能满足我们想要达到的目的

单次任意地址写 ->任意次任意地址读写#

img

通过两个BitMap的Manager + Worker模式，实现任意次任意地址读写，完全控制内核

  1. 用户态新建Manager和Worker两个BitMap
  2. 使用任意地址写覆盖Manager的pvScan0为Worker的pvScan0地址
  3. 在用户态，操作Manager，可以替换Worker的pvScan0地址，再通过Worker来读写任意内存
  4. 通过任意地址读获取System进程的token
  5. 通过任意地址写替换当前进程token

Accelerator Table RS1(v1607)#

在RS1中，微软将pKernelAddress指向了异常地址，阻止了BitMap方式的pvScan0地址泄露

可以想到的两个想法：

  1. 寻找其它方法来泄露 bitmap GDI 对象的地址
  2. 寻找 bitmap 的替代方案

泄露内核地址#

由于堆风水技术的存在，如果我们可以让BitMap分配到一个我们已知地址的空间，那么我们还是能泄露出pvScan0的地址，实现任意次的任意地址读写

  • bitmap对象属于 GDI object，存在于换页会话池中

  • Accelerator table 对象属于 user object，存在于换页会话池中

如果可以泄露Accelerator table的地址，再让BitMap分配到释放的Accelerator table的那块内存，就可以泄露pvScan0地址

泄露Accelerator table内核地址的结构体如下：

user32.dll 模块中有一个全局变量叫做 gSharedInfo，结构如下：

1
2
3
4
5
6
7
8
9
10
typedef struct _SHAREDINFO {
	PSERVERINFO psi;
	PUSER_HANDLE_ENTRY aheList;
	ULONG HeEntrySize;
	ULONG_PTR pDispInfo;
	ULONG_PTR ulSharedDelts;
	ULONG_PTR awmControl;
	ULONG_PTR DefWindowMsgs;
	ULONG_PTR DefWindowSpecMsgs;
} SHAREDINFO, * PSHAREDINFO;

其中第二个变量aheList指向一张结构为 USER_HANDLE_ENTRY 的表，如下：

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct _USER_HANDLE_ENTRY {
	void* pKernel;
	union
	{
		PVOID pi;
		PVOID pti;
		PVOID ppi;
	};
	BYTE type;
	BYTE flags;
	WORD generation;
} USER_HANDLE_ENTRY, * PUSER_HANDLE_ENTRY;

这里的pKernel指向对应的User Object在内核中的位置

堆风水#

  1. 调整构造函数，使得创建的Accelerator Table对象和BitMap对象大小一致
  2. 使用Accelerator Table占位
  3. 释放Accelerator Table并分配BitMap，实现内存复用
  4. 根据偏移，计算出pvScan0内核地址
1
pvScan0 = *(PDWORD32)pKernel + (x86:0x10,x64:0x18) + (x86:0x20,x64:0x38)

lpszMenuName RS2(v1703)#

在RS2中，Windows再次将pKernel指向异常地址，阻止了Accelerator Table + 堆风水泄露pvScan0的方式

lpszMenuName关联一个windows窗口对象, 其在内核当中对应结构体对象为tagWND

tagCLS对应于windows窗口类，其中一个对象是lpszManuName

如果可以泄露lpszManuName地址，就可以通过设置wndclass.lpszMenuName控制对应内存的大小

img

tagWND对应一个桌面堆. 内核的桌面堆会映射到用户态去.。

泄露内核地址#

  • bitmap对象属于 GDI object，存在于换页会话池中

  • 桌面堆对象属于 user object，存在于换页会话池中

使用桌面堆对象和堆风水泄露BitMap对象的pvScan0的内核地址。

桌面堆会在用户态和内核态各保存一份，我们通过下面的方式泄露桌面堆的内核地址

img

指向用户模式版本的指针被存在TEB.Win32ClientInfo+0x28的位置，ulClientDelta即是内核地址减去用户地址

img

img

首先在用户态找到函数HMValidateHandle的地址

1
2
3
4
5
6
7
8
9
10
kd> u user32!IsMenu
USER32!IsMenu:
00007fff`17d489e0 4883ec28        sub     rsp,28h
00007fff`17d489e4 b202            mov     dl,2
00007fff`17d489e6 e805380000      call    USER32!HMValidateHandle (00007fff`17d4c1f0)
00007fff`17d489eb 33c9            xor     ecx,ecx
00007fff`17d489ed 4885c0          test    rax,rax
00007fff`17d489f0 0f95c1          setne   cl
00007fff`17d489f3 8bc1            mov     eax,ecx
00007fff`17d489f5 4883c428        add     rsp,28h

在用户态调用HmValidateHandle，可以返回一个用户桌面堆中的tagWND对象指针

img

具体泄露过程如下：

  1. 从User32.dll中的IsMenu函数中找到HMValidateHandle函数的指针：pIsMenu --> pHMValidateHandle
  2. 通过调用HMValidateHandle函数找到用户桌面堆中的tagWND指针：pWnd = HMValidateHandle(hWnd,1)
  3. 获取内核桌面堆地址：pSelf=pWnd+0x20，获取内核tagCLS地址：kernelTagCLS=pWnd+0xa8，这里的pSelf其实是Kernel中的tagWND地址
  4. 内核桌面堆和用户桌面堆的地址偏移：ulClientDelta=pSelf-pWnd
  5. 获取用户态TagCLS:userTagCLS=kernelTagCLS-ulClientDelta
  6. lpszMenuName位于userTagCLS0x90偏移处(该处指向paged pool中的lpszMenuName成员)

堆风水#

  1. 调整构造函数，使得创建的桌面堆对象的lpszMenuName和BitMap对象大小一致
  2. 使用桌面堆对象占位
  3. 释放桌面堆对象并分配BitMap，实现内存复用
  4. 根据偏移，计算出pvScan0内核地址
1
pvScan0 = *(PDWORD32)pKernel + (x86:0x10,x64:0x18) + (x86:0x20,x64:0x38)

Palette RS3 (v1709)#

在RS3中，微软彻底解决了BitMap的问题，把Bitmap header与Bitmap data分离，无法通过Bitmap header取得pvscan0指针的内核地址

Palette结构#

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
typedef struct _PALETTE64
{
    BASEOBJECT64      BaseObject;    // 0x00
    FLONG           flPal;         // 0x18
    ULONG32           cEntries;      // 0x1C
    ULONG32           ulTime;        // 0x20 
    HDC             hdcHead;       // 0x24
    ULONG64        hSelected;     // 0x28, 
    ULONG64           cRefhpal;      // 0x30
    ULONG64          cRefRegular;   // 0x34
    ULONG64      ptransFore;    // 0x3c
    ULONG64      ptransCurrent; // 0x44
    ULONG64      ptransOld;     // 0x4C
    ULONG32           unk_038;       // 0x38
    ULONG64         pfnGetNearest; // 0x3c
    ULONG64   pfnGetMatch;   // 0x40
    ULONG64           ulRGBTime;     // 0x44
    ULONG64       pRGBXlate;     // 0x48
    PALETTEENTRY    *pFirstColor;  // 0x80
    struct _PALETTE *ppalThis;     // 0x88
    PALETTEENTRY    apalColors[3]; // 0x90
}
1
2
3
4
5
6
7
class PALETTEENTRY(Structure):
 _fields_ = [
  ("peRed", BYTE),
  ("peGreen", BYTE),
  ("peBlue", BYTE),
  ("peFlags", BYTE)
 ]

0x90处是一个4字节的数组apalColors，相当于BitMap里的pixel data，pFirstColor是一个指针，指向apalColors，相当于BitMap里的pvScan0。

  • pvScan0 -> pFirstColor

  • pixelData -> apalColors

img

泄露内核地址#

使用桌面堆风水泄露Pallete结构中的pFirstColor的内核地址

#

喜欢这篇文章？打赏一下作者吧

评论

关注我

链接

归档

订阅更新

邮件订阅，更新早知道

分类

最新文章

标签

AI2
CTF48
CVE4
Fuzz1
FuzzingBook1
HEVD5
NLP1
PyQt512
ROP Emporium2
Toddler's Bottle21
Web1
automatic analyse10
binary analyse1
codeql5
crypto7
fuzz3
life2
linux kernel2
machine learning1
mobile security1
others1
paper18
pentest3
pwn24
pwnable.kr21
re5
research20
security18
security situation awareness2
stack overflow3
tools2
windows8
work1
writeup5
数据库11
×