Let's talk about the two 0-day fixes in May.
On July 15, May 12, 2015, Beijing time, Microsoft pushed the patch on July 15, May, including security updates for multiple components such as IE, Windows kernel, Windows kernel driver, and Office. Two 0-day vulnerabilities fixed this month
Windows Kernel security features vulnerability fixed in MS15-052: CVE-2015-1674
Windows Kernel Mode Driver Privilege Escalation Vulnerability fixed in MS15-051: CVE-2015-1701 also caught our attention. After confirmation, CVE-2015-1674 was a kernel KASLR bypass vulnerability discovered by the author in 2014, and CVE-2015-1701 was found in the Operation RussianDoll (Russian doll action) report released by Fireeye in April 18 this year, the zero-day Kernel Vulnerability used in attacks against extremely specific targets initiated by the Russian APT28 hacker group for permission escalation. When Microsoft releases patches, hfiref0x, a hacker from the Russian security community kernelmode.info, also published a complete attack code for CVE-2015-1701 vulnerabilities on his Github. In this Blog, I will talk about the principles, details, repair methods, and peripheral information of these three 0-day vulnerabilities that have been fixed this month.
0x01 CVE-2015-1674/MS15-052
Vulnerability Information
MS15-052 is Microsoft's Security Update for CNG. sys, designed to fix CVE-2015-1674 vulnerabilities. The vulnerability is the same as the vulnerability http://weibo.com/1648808737/BpGpHhEyD/CVE-2015-0010 introduced on a microblog (MS05-010) released by Microsoft in last October when Windows 10 first preview (9860, microsoft did not completely fix the legacy security vulnerability when fixing the CVE-2015-0010.
After Windows 10 was released, I tested two KASLR bypass vulnerabilities on it, one is a problem that j00ru published on NoSuchCon 2013 that uses kernel KiTrap01 to handle debugging exceptions and detects kernel address bypassing KASLR, the other is a CNG found by the author in reverse Windows 2014 kernel in 8.1. the undisclosed KASLR bypass vulnerability in sys was not fixed in the Windows 9860 pre-release.
Due to CNG. sys devices (\ Device \ CNG) are one of the few devices in the system that have configured the all application packages dacl, allowing highly isolated AppContainer to be accessible at will, in addition, this problem affects both x86 and x64 systems (the KASLR of j00ru can only be used for x86 systems), so the latter is more practical. This vulnerability is one of the kernel vulnerabilities/defects in 360 Vulcan Team that are reserved for Pwn2Own competitions, moreover, Microsoft has always been ambiguous about the KASLR Bypass Type Vulnerability (the KASLR of j00ru has been bypassed until the latest version 10074 of Windows 10 has not been repaired). Therefore, I have not reported this vulnerability to Microsoft, in this patch, CVE-2015-1674 is the vulnerability mentioned here.
It may be because this vulnerability affects the PEM (enhanced protection mode, mainly using AppContainer for protection) in IE and Spartan. Microsoft decided to fix this vulnerability in the new version of Windows 10. We can see that, in Windows 10 January 2015 released in 9926, Microsoft has quietly completely fixed this vulnerability. In the patch period in February, Microsoft was also affected by Windows 8/8. 1/Server 2012/Server 2012 R2 pushed the MS05-010 to try to fix this problem.
But it is interesting that, in the MS05-010, although Microsoft gave the vulnerability CVE-2015-0010 number, but the problem is not completely fixed, this vulnerability was eventually used by lokihardt from South Korea on Pwn2Own 2015, breaking the Windows kernel. It is also because of Pwn2Own 2015, Microsoft once again released MS15-052 security updates, for the vulnerability for a new number: CVE-2015-1674. The reality of this "new" vulnerability and CVE-2015-0010 is almost exactly the same problem, belonging to the CVE-2015-0010 is not completely fixed and legacy issues that are hard to understand, in Windows 10 9926, CVE-2015-0010 and CVE-2015-1674 problems are fixed at one time, have to say that Microsoft seems to be developing Windows 10 in the Process of patch repair and management has been neglected and chaotic, this causes the current problem.
Some details of this vulnerability have been made public on ZDI's official website: http://www.zerodayinitiative.com/advisories/ZDI-15-189/, due to cng. there are not many attacks in sys. experienced security researchers can easily find details of this vulnerability based on this information. Therefore, I will introduce the details of this vulnerability directly.
Vulnerability details
This vulnerability exists in the device control processing code of cng. sys. CNG. SYS is Microsoft's next-generation kernel cryptography driver. It provides many cryptographic interfaces through Device Control and function output, just like many Windows Kernel drivers, the device control processing incorporates the control functions that are simultaneously open to other kernel drivers and user mode programs. This is often the source of many kernel security vulnerabilities. I mentioned on ISC 2014 about Kernel protection of 360 XP license a 3.0 that once affected Windows systems, so far, KASLR bypasses in many important third-party control interfaces are still affected, and similar problems exist.
CNG. the special feature of sys is that, after creating a Device (\ Device \ CNG), it will use ObSetSecurityObjectByPointer to set a special Security Descriptor for the Device, this security descriptor allows all application packages users to fully control the device. If you have a little understanding of Microsoft's AppContainer/EPM mechanism, you can know that the device that has configured this permission, even if the rendering process is in IE or Spartan isolation protection mode, it can also be accessed directly. The purpose of this setting is to allow all processes to access its related interfaces. Therefore, in the IRP_MJ_CREATE process of the driver, arbitrary access is also allowed, no check, that is, CNG. related interfaces in SYS, even processes protected by IE/Spartan or enhanced protection mode, can be accessed at will.
In the CNG. multiple Control codes are provided to external drivers, such as 0x39024,0x39040,0x39044,0x39048, 0x39064, etc, these Device Control codes will return to the caller a series of function interface addresses implemented inside the CNG, including FIPSSHA, FIPS3Des, HMAC MD5, FIPS GenRandom, SSL encryption and decryption, Key management, and BCrypto interfaces, in this way, the external driver can directly call the interfaces of these functions to perform related cryptographic operations, without the need to implement these interfaces on its own.
The problem here is that the interface set for these dedicated external kernel mode drivers does not check whether the IRP source is in kernel mode. Therefore, the user-Mode Program directly uses the DeviceIoControl function, you can call the control codes of these devices to obtain the interfaces of these functions. Of course, user-mode programs cannot directly use these interfaces, but they work with CNG. the Image Layout of SYS allows the user-Mode Program to obtain the CNG. this completely bypasses the KASLR Kernel Mode address randomization technology of Microsoft Kernel.
In Microsoft's MS05-010, The 0x39024 interface is processed and repaired (CVE-2015-0010), and right below the fix code line, the 0x39040/0x39044/0x39048/0 x x39064 and Other interfaces were ignored in the patch in. Lokihardt players who used this vulnerability to participate in Pwn2Own on June 18, March saw the patch, and they certainly laughed at it :)
It was not until this month that Microsoft's MS15-052 officially fixed 0x39040 ~ 0x39064 series interface problems, and rename this unrepaired vulnerability as a CVE-2015-1674.
Here we will introduce some background knowledge: Before Microsoft Windows 8.1 operating system, Microsoft did not pay attention to the local KASLR issue, although it started from Windows NT, microsoft's kernel module is a random address (especially after high entropy random numbers are used in x64 system + Windows 8 or above), but it is limited to making remote kernel vulnerabilities more difficult. This is mainly because any process with any permissions can use NtQuerySystemInformation and SystemModuleInformation to obtain the base address of the kernel and kernel drivers and modules, and can directly ignore KASLR.
In Windows 8.1, the situation has changed. Microsoft uses kernel vulnerabilities to penetrate the sandbox in the IE protection mode and enhanced protection mode, introduced the KASLR easing mechanism for local programs. Alex Ionescu analyzed this mechanism on his BLOG:
(Http://www.alex-ionescu.com /? P = 82). In Windows 8.1, if a process runs below the low integrity level (protection mode or enhanced protection mode ), then, SystemModuleInformation and other methods to obtain the base address of the kernel module will be blocked. In this way, even if an attacker triggers a kernel vulnerability in the protection mode or enhanced protection mode, the kernel base address cannot be obtained, it is also difficult to make further use.
This security vulnerability of CNG opens the door for attackers to bypass KASLR in this easing mode, because it is a vulnerability that can be used in both protection mode and enhanced protection mode, at the same time, it can be called stably on both x64 and x86 systems. After obtaining the key data addresses related to cng, If attackers have a vulnerability that writes arbitrary addresses in the kernel, they can directly overwrite the data stored in CNG. the list of functions in the SYS data segment. When other kernel-mode drivers are called, they directly obtain the right to execute the kernel code.
Vulnerability fix
It is relatively easy to fix this vulnerability. In the IRP_MJ_DEVICE_CONTROL code, check the Irp-> RequestMode for control codes such as 0x39024 and 0x39040, you can distinguish between kernel-mode drivers and user-mode calls to avoid vulnerabilities. Such a simple vulnerability is ignored by Microsoft's patch repair department for almost parallel code. It takes two times to completely fix it in half a year. It is a tragedy.
0x02 CVE-2015-1701/MS15-051
Vulnerability Information
CVE-2015-1701 is Fireeye's April 18 this year report "Operation RussianDoll: Adobe & Windows Zero-Day Exploits Likely Leveraged by Russia's APT28 in Highly-Targeted Attack" (https://www.fireeye.com/blog/threat-research/2015/04/probable_apt28_useo.html) the Windows kernel privilege escalation vulnerability mentioned in is used in combination with the Adobe Flash Vulnerability for attacks. Since the vulnerability was not fixed in April, therefore, the vulnerability information on the Fireeye official website is also unknown.
In this month's patch day, Microsoft fixed this privilege escalation vulnerability through the MS15-051 patch, and in the patch release almost at the same time, on its github, hfiref0x, a hacker at the kernelmode.info forum in Russia, announced the complete attack code (https://github.com/hfiref0x/CVE-2015-1701) exploiting the vulnerability, which seems to imply a close relationship with Russia.
This vulnerability is similar to the CVE-2014-4113 vulnerability exposed in last October, is Windows Kernel Driver win32k. the Kernel Window object flag caused by a timing problem in the window creation process of sys is disordered, resulting in arbitrary kernel code execution. Microsoft has fixed this problem since the Windows 8 operating system, however, this vulnerability remains in the Windows XP/2003/Vista/Windows 7/Server 2008/Server 2008 R2 operating system.
Another Microsoft error appears to be that the vulnerability's impact on Windows 7/Windows 2008 R2, as mentioned in the MS15-051 patch announcement (https://technet.microsoft.com/en-us/library/security/MS15-051), is: None, however, this vulnerability affects Windows 7 and Server 2008 R2. The attack code on Github is targeted at Windows 7.
Vulnerability details
By analyzing the attack code, we can know that this vulnerability is used to drive win32k in kernel mode. window Creation function in sys: occurs in xxxcreatejavaswex. This function is a complex function used to create Kernel Window objects in the GDI kernel. It is passed through user32 in user mode! CreateWindow (Ex)-> ntusercreateappswex can finally call this kernel function. After analyzing a series of parameters, xxxCreateWindows will use HMAllocateObject to allocate a window-type win32 object and fill it with some parameters, such as the Class Object of the window. Using Hex-rays Decompiler, we can see that there is a logic process like this on the operating systems that did not fix vulnerabilities before Windows 8:
if ( pcls->spicn && !pcls->spicnSm ){ xxxCreateClassSmIcon(pcls);}pwnd->hModule = hMoudle;pwnd->lpfnWndProc = MapClientNeuterToClientPfn(pcls, 0, bansi);
Here, xxxCreateClassSmIcon aims to create a small Icon cache for the icons in the window class. Next, the system uses MapClientNeuterToClientPfn to set WindowProc for the window class.
It seems that there is no problem here, but when we look at the implementation of xxxCreateClassSmIcon, we will find that this xxxCreateClassSmIcon is implemented through xxxClientCopyImage-> KeUserModeCallback, that is to say, this call is ultimately implemented in combination with the user mode callback.
Readers who are familiar with Window management may know that KeUserModeCallback actually calls the corresponding function placed in PEB-> KernelCallbackTable to implement the function, these functions are implemented in the user mode. For example, user32 will be called in the end! _ XxxClientCopyImage function.
Kernel Mode Callback is a set of user mode-kernel mode interactive Callback mechanism dedicated to win32k. It is also designed to improve performance in the window Kernel system. Due to the existence of this mechanism, user-mode programs may hook the system's kernel callback function to implement logical processes that control and interrupt kernel execution, leading to many security vulnerabilities, including the history of CVE-2013-3167 vulnerabilities are caused by this mechanism.
Tarjei Mandt, the Norman Threat Research Team (now Security company Azimuth Security, he has also published a topic "Kernel Attacks through User-Mode Callbacks" on Blackhat 2011 to analyze the security vulnerabilities caused by this call back mechanism ), this article describes multiple security vulnerabilities caused by this mechanism. If you are interested, you can take a closer look.
Let's continue to explain this vulnerability. We know from the analysis just now that we have linked user32! \__ XxxClientCopyImage function, we can implement the xxxCreateClassSmIcon position in the above Code, that is, to interrupt the xxxcreateappswex process before the system fills pwn-> lpfnWndProc, and execute the operation we want. So how can we use this? In the hfiref0x code, we can see that after the function is hooked, the Code only performs one operation:
SetWindowLongPtr (GetFirstThreadHWND (), GWLP_WNDPROC, (LONG_PTR) & DefWindowProc );
SetWindowLongPtr is a function used to set window-related data and attributes. Here, the GWLP_WNDPROC function index (index) is used to subclass the window (subclass)/unsubclass ), you can use subclass to replace the call process of the window with your own function to take over some processing of the window, or set it to DefWindowProc to subclass and cancel the process.
GetFirestThreadHWND is a technique used to obtain the currently created window handle, because xxxcreatejavaswex is being interrupted during the kernel process and only uses the user-mode code and xxxCreateClassSmIcon information, we cannot know the currently created window object/handle.
However, we know that in the Win32k kernel, all Kernel Window information is mapped to a memory address in user mode, through user32! GSharedInfo we can get its address (a read-only ing of the kernel mode window information list), and we just said that the Kernel Window object has been created through HMAllocateObject during our interruption, then it can be retrieved in gSharedInfo. This is not a fresh trick, and similar techniques are used in some of the past vulnerability attack code, such as the CVE-2013-1300 Exploit used by MWR Labs in Pwn2Own2013.
Here we can see that the Code uses SetWindowLongPtr to replace WindowProc in the window being created by the current thread with DefWindowProc, And then it seems that the kernel code execution capability is achieved. Why? Let's take a closer look at the implementation of SetWindowLongPtr-> NtUserSetWindowLongPtr to get a solution. By analyzing the implementation of the kernel, we can know that NtUserSetWindowLongPtr-> xxxSetWindowLongPtr, when index (GWLP_WNDPROC (-4 ))
ptr = MapClientToServerPfn(dwData);if ( ptr ){ ClrWF(pwn, WFANSIPROC); SetWF(pwn, WFSERVERSIDEPROC); pwn->lpfnWndProc =ptr;
The logic here is to check whether GWLP_WNDPROC is a de-subclass operation (unsubclass). If yes, it is considered that it should be set as the kernel to take over the window process, set the Server Side Proc flag for the window. This flag indicates that the window procedure function will be called in kernel mode.
Here, MapClientToServerPfn checks whether the WindowProc (the SetWindowLongPtr parameter dwData) set for the current window is a preset function in apfnClientA/W in gpsi (PCSERVERINFO, that is, the pre-prepared processing functions for various windows in user32, such as ScrollBarWndProcW, MenuWndProcW, and ButtonWndProcW. Of course, DefWindowProcW is also included here.
If verification is performed by these preset window procedures, set the window flag to run window procedure functions in kernel mode, modify the window procedure function to the kernel processing function in gpsi> aStoCidPfn, such as xxxSBWndProc, xxxDefWindowProc, xxxMenuWindowProc, and so on.
It seems that there is no problem here, because in kernel mode, WindowProc (win32k! XxxDefWindowProc ).
However, from the logic sequence of xxxcreateappswex we mentioned above, we will find that this will cause a serious problem: xxxcreateappswex:
Xxxcreatejavaswex call HMAllocateObject to create a window object
Call xxxCreateClassSmIcon-> xxxClientCopyImage
XxxClientCopyImage is interrupted. The user mode function calls SetWindowLongPtr to set WindowProc for the window currently being created.
WindowProc is user32! DefWindowProc, which is considered as de-subclass by xxxSetWindowData, sets the window process to run in kernel mode and sets WindowProc as the kernel function win32k! XxxDefWindowProc
Return from xxxCreateClassSmIcon, continue to call MapClientNeuterToClientPfn to convert the default WindowProc of the current window function (that is, the user mode controllable function), and then set WindowProc of the window object to the user's own window object
As we can see, this interruption happens just before xxxCreateWindowProc sets WindowProc for the window, so xxxSetWindowData modifies the WindowProc of the window to xxxDefWindowProc, which is invalid, the WindowProc of the window is also changed to the WindowProc set by the user mode application. At this time, the flag of the window has been set to the WindowProc that needs to be executed in kernel mode, then, when the xxxSendMessage and other functions send messages to this window, they will directly jump in kernel mode and call the functions in user mode for processing, this directly causes code execution in kernel mode.
The above is the general principle of this vulnerability. That is to say, the xxxcreatejavaswex process is interrupted before WindowProc is set for the window, and the system is deemed to be de-subclass through SetWindowLongPtr, and set the window to run in kernel mode. When xxxcreatejavaswex is returned, the de-subclass function is overwritten when the window procedure function is set, but the kernel mode execution mark of the window function is not removed, this causes arbitrary code execution in kernel mode.
The Exploit code obtains the tokens of the system process and overwrites the tokens of the system process to improve the permissions.
Vulnerability fix
On Windows 8 and later operating systems, Microsoft has modified the timing logic of this item. First, modify WindowProc of the window and then call xxxCreateClassSmIcon. In this way, xxxCreateClassSmIcon is deprecated even if it is interrupted, the final window processing function will also be win32k! This vulnerability does not exist because xxxDefWindowProc is not modified to user mode functions.
In this month's patch, this vulnerability is also fixed for Windows 2003/Vista/7/Server 2008/Server 2008 R2.
In Windows 8 or later operating systems, if the CPU supports SMEP (IvyBridge or above), this kernel mode directly calls the user mode function and is blocked, however, attackers may also hide the payload in the kernel address space to bypass this interception. For Microsoft XP operating system without official patches, 360 XP license a from v2.0 provides win32k kernel function to take over the processing, for this type of vulnerability in CVE-2015-1701 without upgrading, you can directly immune.
