STRLCPY/0days-in-the-wild

CVE-2021-1732: add RCA
jq0904 committed with Maddie Stone 3 years ago

e84aa5e5

1 parent 77f5f367

Total 1 files

■ ■ ■ ■ ■ ■

0day-RCAs/2021/CVE-2021-1732.md

1	+
2	+	# CVE-2021-1732: Windows win32k flag setting out of sync in xxCreateWindowEx
3	+	Quan Jin, DBappSecurity
4	+
5	+	## The Basics
6	+
7	+	Disclosure or Patch Date: 10 February 2021
8	+
9	+	Product: Microsoft Windows
10	+
11	+	Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1732
12	+
13	+	Affected Versions: For Windows 10 20H2 x64, [KB4598242](https://support.microsoft.com/en-us/topic/january-12-2021-kb4598242-os-builds-19041-746-and-19042-746-ab18a1a1-d572-598f-4d86-7137aad34056) and previous
14	+
15	+	First Patched Version: For Windows 10 20H2 x64, [KB4601319](https://support.microsoft.com/en-us/topic/february-9-2021-kb4601319-os-builds-19041-804-and-19042-804-87fc8417-4a81-0ebb-5baa-40cfab2fbfde)
16	+
17	+	Issue/Bug Report: N/A
18	+
19	+	Patch CL: N/A
20	+
21	+	Bug-Introducing CL: N/A
22	+
23	+	Reporter(s): JinQuan, MaDongZe, TuXiaoYi, and LiHao of DBAPPSecurity Co., Ltd
24	+
25	+	## The Code
26	+
27	+	Proof-of-concept: https://github.com/KaLendsi/CVE-2021-1732-Exploit
28	+
29	+	Exploit sample: N/A
30	+
31	+	Did you have access to the exploit sample when doing the analysis? Yes
32	+
33	+	## The Vulnerability
34	+
35	+	Bug class: Flag setting out of sync
36	+
37	+	Vulnerability details:
38	+
39	+	The bug is caused by xxxClientAllocWindowClassExtraBytes callback in win32kfull!xxxCreateWindowEx. The callback causes the setting of tagWND.WndExtra and its corresponding flag to be out of sync.
40	+
41	+	When xxxCreateWindowEx creating a window that has WndExtra area, it will call xxxClientAllocWindowClassExtraBytes to trigger a callback, the callback will return to user mode to allocate WndExtra area. In the custom callback function, the attacker could call NtUserConsoleControl and pass in the handle of current window, this will change tagWND.WndExtra to an offset, and setting a corresponding flag to indicate that tagWND.WndExtra now is an offset. After that, the attacker could call NtCallbackReturn in the callback and return an arbitrary value. When the callback ends and return to kernel mode, the return value will overwrite the tagWND.WndExtra, but the corresponding flag is not cleared. After that, the unchecked offset value is directly used by kernel code for heap memory addressing, causing out-of-bounds access.
42	+
43	+	Patch analysis: N/A
44	+
45	+	Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:
46	+
47	+	This type of vulnerability can be discovered by carefully auditing the possible changes in the flag before and after the callback function, especially carefully audit those API functions that can be called to change the kernel structure flag during the callback process.
48	+
49	+	(Historical/present/future) context of bug:
50	+
51	+	DBappSecurity found this bug exploited as an independent component.
52	+
53	+	The exploit was discovered by DBappSecurity in December 2020. The initial exploit was designed to attack Windows 1909 x64. It’s possible that the attackers decided to use this exploit to achieve privilege escalation on a windows 10 1909 x64 machine.
54	+
55	+	## The Exploit
56	+
57	+	The details about the exploitation method were posted by DBappSecurity in their post "[WINDOWS KERNEL ZERO-DAY EXPLOIT (CVE-2021-1732) IS USED BY BITTER APT IN TARGETED ATTACK](https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/)".
58	+
59	+	Exploit strategy (or strategies):
60	+
61	+	1. The origin exploit mainly creates three windows: window 0, window 1 and window 2.
62	+	2. The exploit calls NtUserConsoleControl to change the flag of window 0 to offset, and leaks an offset of window 0 via HMValidateHandle.
63	+	3. In the callback, the exploit calls NtUserConsoleControl again to change the flag of window 2 to offset, and triggers the bug to overwrite the tagWND.WndExtra of window 2 to the leak offset of window 0.
64	+	4. When the callback ends, window 2 obtains the primitive to operate the kernel tagWND of window 0.
65	+
66	+	Exploit flow:
67	+
68	+	1. The HMValidateHandle function is used to leak the offset of tagWND.
69	+	2. The exploit calls SetWindowLongW to set cbWndExtra of of window 0 to 0xfffffff, this gives window 0 the OOB read/write primitives.
70	+	3. The exploit then uses the OOB write primitive of window 0 to modify the style of window 1(dwStyle\|=WS_CHILD), after that, the exploit replaces the origin spmenu of window 2 with a fake spmenu.
71	+	4. The arbitrary read primitive is achieved by fake spmenu works with GetMenuBarInfo.
72	+	5. The arbitrary write primitive is achieved via window 0 and window 1, works with SetWindowLongPtrA.
73	+	6. After achieving the arbitrary read/write primitives, the exploit leaks a kernel address from the origin spmemu, then searches through it to find the EPROCESS of current process.
74	+	7. Finally, the exploit traversals ActiveProcessLinks to get the token of SYSTEM EPROCESS and the token area address of current EPROCESS, and swaps the current process Token value with SYSTEM Token. This is a known technique that has been documented in many places such as [here](https://improsec.com/tech-blog/windows-kernel-shellcode-on-windows-10-part-1).
75	+
76	+	Known cases of the same exploit flow:
77	+
78	+	- Many windows kernel exploits will use HMValidateHandle to leak kernel address.
79	+
80	+	- Most win32k exploits will use SetWindowLong* functions to achieve arbitrary read/write primitives.
81	+	- Most windows kernel exploits will swap the current process token with SYSTEM token.
82	+
83	+	Part of an exploit chain? No
84	+
85	+	## The Next Steps
86	+
87	+	### Variant analysis
88	+
89	+	Areas/approach for variant analysis (and why): The variant of this bug can be discovered by carefully auditing the possible changes in the flag before and after the callback function. Especially carefully audit those API functions that can be called to change the kernel structure flag during the callback process.
90	+
91	+	Found variants: N/A
92	+
93	+	### Structural improvements
94	+
95	+	Ideas to kill the bug class: Carefully auditing the possible changes in the flag before and after the win32k callback function
96	+
97	+	Ideas to mitigate the exploit flow: N/A
98	+
99	+	Other potential improvements: N/A
100	+
101	+	### 0-day detection methods
102	+
103	+	1. Check whether the token of current process is replaced with SYSTEM token at the right time.
104	+	2. Check whether a call to HmValidateHandle is from an address out of user32.dll, there is [a demo of this method](https://theevilbit.github.io/posts/a_simple_protection_against_hmvalidatehandle_technique/).
105	+
106	+	## Other References
107	+
108	+	- February 2021: "[WINDOWS KERNEL ZERO-DAY EXPLOIT (CVE-2021-1732) IS USED BY BITTER APT IN TARGETED ATTACK](https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/)" by DBappSecurity
109	+
110	+

CVE-2021-1732: add RCA