{"id":7123,"date":"2017-03-27T07:03:35","date_gmt":"2017-03-27T15:03:35","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/03\/27\/news-914\/"},"modified":"2017-03-27T07:03:35","modified_gmt":"2017-03-27T15:03:35","slug":"news-914","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/03\/27\/news-914\/","title":{"rendered":"Detecting and mitigating elevation-of-privilege exploit for CVE-2017-0005"},"content":{"rendered":"

Credit to Author: msft-mmpc| Date: Mon, 27 Mar 2017 15:00:01 +0000<\/strong><\/p>\n

On March 14, 2017, Microsoft released security bulletin MS17-013<\/a> to address CVE-2017-0005, a vulnerability in the Windows Win32k<\/em> component that could potentially allow elevation of privileges.\u00a0A report from\u00a0a trusted partner identified\u00a0a zero-day exploit for this vulnerability. The exploit targeted\u00a0older versions of Windows and allowed\u00a0attackers to elevate process privileges on these platforms.<\/p>\n

In this article, we walk through the technical details of the exploit and assess the performance of tactical mitigations in Windows 10 Anniversary Update\u2014released in August, 2016\u2014as well as strategic mitigations like Supervisor Mode Execution Prevention (SMEP) and virtualization-based security (VBS). We also show how upcoming Creators Update enhancements<\/a> to Windows Defender Advanced Threat Protection (Windows Defender ATP<\/a>) can detect attacker elevation-of-privilege (EoP) activity, including EoP activities associated with the exploit.<\/p>\n

Zero-day elevation-of-privilege exploit<\/h2>\n

Upon review of its code, we found that this zero-day EoP exploit targets computers running Windows 7 and Windows 8. The exploit has been created so that it avoids executing on newer platforms.<\/p>\n

The exploit package unfolds in four stages:<\/p>\n

 <\/p>\n

\"Execution<\/p>\n

Figure <\/em>1<\/em>.<\/em> Execution stages of the exploit package and corresponding functionality<\/em><\/p>\n

 <\/p>\n

Stages 1 and 2 – Decryptor and API resolver<\/h3>\n

To protect the main exploit code, attackers have encrypted the initial stage PE file using AES-256 algorithm. To load code for the next stage, a password must be passed as a parameter to the main entry function. Using the CryptHashData<\/a><\/em> API, the password is used as a key to decrypt the loader for the next stage.<\/p>\n

Stage 2 acts as an intermediate stage where API resolution is performed. API resolution routines in this stage resemble how shellcode or position-independent code works.<\/p>\n

The following code shows part of the GetProcAddress<\/a><\/em> API resolution routine. This code appears to obfuscate the succeeding payload and stifle analysis.<\/p>\n

 <\/p>\n

\"Locating<\/p>\n

Figure <\/em>2<\/em>.<\/em> Locating kernel32!GetProcAddress location using EAT traverse<\/em><\/p>\n

 <\/p>\n

Stage 3 – Avoiding newer platforms<\/h3>\n

In stage 3, the exploit package performs environmental checks, specifically to identify the operating system platform and version number. The attacker ensures that the exploit code runs on vulnerable systems that have fewer built-in mitigations, particularly Windows 7 and Windows 8 devices.<\/p>\n

 <\/p>\n

\"Code<\/p>\n

Figure <\/em>3<\/em>. Code that performs environmental checks<\/em><\/p>\n

 <\/p>\n

Analysis of the exploit code reveals targeting of systems running specific versions of Windows:<\/p>\n