At the end of March 2018, ESET experts discovered an unusual malicious PDF file. Upon closer inspection, it turned out that the sample uses two previously unknown vulnerabilities: the remote code execution vulnerability (RCE) in Adobe Reader and the privilege elevation vulnerability (LPE) in Microsoft Windows.
The combination of two 0-days is quite dangerous because it opens up the ability of an attacker to execute arbitrary code on the target system with maximum privileges and minimal user participation. ART groups often use similar combinations of tools — for example, in
the Sednit campaign last year.
Having detected a malicious PDF, ESET experts contacted the Microsoft Security Response Center, Windows Defender ATP and the Adobe Product Security Incident Response Team to close the vulnerabilities.
')
Patches and recommendations of Adobe and Microsoft are available at the following links:
•
APSB18-09•
CVE-2018-8120The following products are subject to vulnerabilities:
• Acrobat DC (2018.011.20038 and earlier versions)
• Acrobat Reader DC (2018.011.20038 and earlier versions)
• Acrobat 2017 (011.30079 and earlier versions)
• Acrobat Reader DC 2017 (2017.011.30079 and earlier versions)
• Acrobat DC (Classic 2015) (2015.006.30417 and earlier)
• Acrobat Reader DC (Classic 2015) (2015.006.30417 and earlier)
• Windows 7 for 32-bit Systems Service Pack 1
• Windows 7 for x64-based Systems Service Pack 1
• Windows Server 2008 for 32-bit Systems Service Pack 2
• Windows Server 2008 for Itanium-Based Systems Service Pack 2
• Windows Server 2008 for x64-based Systems Service Pack 2
• Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1
• Windows Server 2008 R2 for x64-based Systems Service Pack 1
Next is a technical description of the malware sample and vulnerabilities.
Introduction
PDF files are often used to deliver malware to the target computer. To execute malicious code, an attacker has to search for and use vulnerabilities in PDF viewing software. One of the most popular similar programs is Adobe Reader.
The Adobe Reader introduced the technology of isolated execution, better known as the sandbox - Protected Mode. Its detailed description is published on the Adobe blog (
part 1 ,
part 2 ,
part 3 ,
part 4 ). Sandbox complicates the implementation of the attack: even if the malicious code is executed, an attacker will have to bypass the sandbox protection in order to compromise a computer running Adobe Reader. Typically, vulnerabilities in the operating system itself are used to bypass the sandbox.
A rare case where attackers managed to find vulnerabilities and write exploits for both Adobe Reader and the operating system.
CVE-2018-4990 - RCE Vulnerability in Adobe Reader
JavaScript is embedded in the malicious PDF to control the exploitation process. The code is executed after opening the PDF file.
At the beginning of the exploitation process, JavaScript code manipulates a
Button1
object. The object contains a specially crafted JPEG2000 image that triggers a double vulnerability.
Figure 1. JavaScript that manipulates a Button object.JavaScript uses the heap-spraying technique to break internal data structures. After these manipulations, the attackers reach the main goal - access to the memory with read and write permissions.
Figure 2. JavaScript code used to read and write memory.Using two primitives, attackers find the memory address of the plugin
EScript.api
, which is the Adobe JavaScript engine. Using ROP gadgets from this module, malicious JavaScript establishes the ROP chain, which will lead to the execution of native shellcode.
Figure 3. Malicious JavaScript that sets the ROP chain.As a final step, the shellcode initializes the PE file embedded in the PDF and passes it the execution.
CVE-2018-8120 - privilege elevation in Microsoft Windows
After exploiting the Adobe Reader vulnerability, an attacker needs to get rid of the sandbox. This is the task of the second exploit.
At the core of this previously unknown vulnerability is the
win32k
Windows kernel component component of the
NtUserSetImeInfoEx
component of the Windows
win32k
. In particular,
SetImeInfoEx
, the
NtUserSetImeInfoEx
routine, does not check the data pointer, allowing dereferencing a null (NULL) pointer.
Figure 4. Disassembled function SetImeInfoEx.As you can see in Figure 4, the
SetImeInfoEx
function expects a pointer to the initialized WINDOWSTATION object as the first argument.
SpklList
can be zero if the attacker creates a new WS object and assigns it to the current process in user mode. Thus, mapping a zero page and setting a pointer to an offset (offset) 0x2C allows attackers to use the vulnerability to write to an arbitrary address in kernel space. It is worth noting that, starting with Windows 8, the user process cannot convert zero page data.
Since the attackers have an arbitrary writing primitive, they can use different techniques. But in our case, the attackers choose the technique described by
Ivanlef0u , as well as
Mateusz "j00ru" Jurczyk and Gynvael Coldwin . They set the call gateway to Ring 0, overwriting the global descriptor table (GDT). To do this, attackers obtain the address of the original GDT using the SGDT assembly instructions, create their own table and then rewrite the original using the mentioned vulnerability.
The exploit then uses the
CALL FAR
command to invoke the privilege level.
Figure 5. Disassembled CALL FAR command.When code is executed in kernel mode, the exploit replaces the current process token with the system token.
findings
ESET specialists discovered a malicious PDF when it was uploaded to a public repository of malicious samples. The sample does not contain the final payload, which may indicate that it was detected in the early stages of development. Despite this, the authors demonstrated high qualifications in the field of searching for vulnerabilities and writing exploits.
Compromise Indicators (IoC)
Detection by ESET products:JS / Exploit.Pdfka.QNV trojan
Win32 / Exploit.CVE-2018-8120.A trojan
SHA-1:C82CFEAD292EECA601D3CF82C8C5340CB579D1C6
0D3F335CCCA4575593054446F5F219EBA6CD93FE