Embed Size (px)
Citation preview
Test the Effectiveness of the Enhanced Mitigation
Experience Toolkit Using Well-known Attacks on
Well-known Binaries
Hoda [email protected]
June 1, 2014
1
Abstract
Nowadays internet becomes dark and scary zone which vulnerabil-ities and exploits are part of it that are inevitable. Infected systemsvia vulnerable software may result in loss of our privacy and data. AsWindows systems can easily be exploited, there are various exploits forattacking these systems.
So what is the solution? It is highly recommended to users toinstall the latest updates of the applications and also the security up-dates. But what happens when there is no update for that specificvulnerability or the users face with zero day attacks?
Microsoft designed a tool called Enhanced Mitigation ExperienceToolkit (EMET) to reduce the success of attacks from gaining access toWindows systems. This goal is achieved by applying several mitigationtechnologies to not allow the attacker to exploit vulnerabilities in apotentially vulnerable software. EMET forces the applications to applythese prevention techniques even if the applications don’t support themnatively. More than that, these technologies enables EMET to detectnew and unknown threats (zero-day attacks) as well as the old andwell-known ones.
Here in this project we investigated the effectiveness of EMETagainst well-known attacks in different software. Our result showedthat the EMET is indeed successful in preventing attacks in vulnera-ble software. The research questions and our scope are defined in thefirst section. In the second we focus on the EMET itself. Our approachand experimental setup is explained in section three. Our results aboutthe effectiveness of the EMET is shown in section fourth and the lastsection is the conclusion and the future work.
2
Contents
1 Introduction 41.1 Research Question . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Privacy and Security Considerations . . . . . . . . . . . . . . 5
2 EMET 62.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Mitigation Techniques . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Data Execution Prevention . . . . . . . . . . . . . . . 82.2.2 SEHOP . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 NullPage . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 HeapSpray . . . . . . . . . . . . . . . . . . . . . . . . 92.2.5 EAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.6 MandatoryASLR . . . . . . . . . . . . . . . . . . . . . 102.2.7 LoadLib . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.8 Memory Protection . . . . . . . . . . . . . . . . . . . . 112.2.9 Caller . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.10 SimExecFlow . . . . . . . . . . . . . . . . . . . . . . . 112.2.11 StackPivot . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 System and Application Mitigations . . . . . . . . . . . . . . 112.4 Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Approach and Experiment 133.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . 133.3 Vulnerable Software and Exploits . . . . . . . . . . . . . . . . 14
4 Findings/results 164.1 Successful EMET . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Unsuccessful EMET . . . . . . . . . . . . . . . . . . . . . . . 16
5 Conclusion and Future Work 19
Appendices 22
A Used exploits 22
3
1 Introduction
These days protection of computer systems is becoming a more and morecomplex problem. Through the internet cyber criminals can reach systemsfrom anywhere in the world, which leads to a constant and ongoing catand mouse game to keep the attackers out and the systems safe. As thesoftware systems are becoming more and more complex, they will alwayshave vulnerabilities for attackers to exploit.
A particularly difficult problem is how to protect your system againstzero-day exploits. The definition of a zero-day exploit is that it is a previ-ously unknown exploit of a vulnerability in an application. As it was pre-viously unknown, the developer has not had time to address the issue yet,therefor there is no patch or countermeasure available. Regular anti-virussoftware can not recognise the exploit with signature-based scans becausethe signature is not known. This gives attackers that do know about the vul-nerability the possibility to exploit it wherever they like. According to [1] azero-day to cyber criminals represents ”a free pass to any target they mightwish to attack, from Fortune 500 companies to millions of consumer PCsaround the world.” The average time it takes from the moment a zero-dayis discovered until the moment the vulnerability is made public is around10 months. These factors combined make zero-day exploits a very serioussecurity issue.
Another problem is that in some cases vulnerabilities are identified butsoftware is not patched. There can be a number of reasons for this. It canhappen that other software is dependant on the application but is not com-patible with the updated version. In this case software can not be updatedas it would break the system. Another situation that occurs is that themanufacturer of the software does not provide a patch. Either because thesoftware is old and it is no longer supported or because the manufacturerdoes not exist anymore. Sometimes it’s because of the third-party programsand libraries that systems get compromised. Their third party program-mers don’t care about the security implementations. Finally there can behome-brew software running that is not maintained anymore. With no-oneto maintain it, security issues can not be fixed. The scenarios describedabove happen a lot, especially in corporate environment where the softwareis critical for the business. Updating to a new version can be an expensiveand elaborate project that is not deemed worth the effort. The result is thatthere is a lot of vulnerable software out there that can pose a big risk to thesecurity of systems and networks.
As described above, there are a lot of challenges involved in keepingsystems safe in real-world environments.
In order to make an attempt to counter these issues, in October 2009Microsoft released the first version of EMET. The idea behind the applica-tion was to make it possible to use modern security mitigations to protect
4
any process on the system. [2] The program consisted of a number of miti-gations that could be turned on and off individually for each process. Oneof the key features was that the mitigations could work on any application,no matter how old, who developed it or in which language it was written.Even old, unsupported and homebrew applications could make use of themodern security mitigation techniques that the toolkit offered. Since 2009EMET has been developed further to include more mitigations. In April2014 the latest public version, version 4.1 update 1, was released [3]. Thisversion offers a wide range of mitigation techniques and claims to be able toprevent malicious code from running on the system.
1.1 Research Question
To find out what the impact of EMET can be in a real-world environment,this research will focus on two research questions, being:
1. What are the techniques employed by EMET to protect applicationsagainst being exploited?
2. What is the effectiveness of the different techniques used by EMETagainst well-known attacks on well-known vulnerable binaries?
In answering these questions a better insight will be gained on the impactEMET has on the security of a vulnerable system.
1.2 Scope
For this research the effectiveness of EMET 4.1 update 1 will be testedon Windows 7 Service Pack 1 and on Windows XP Service Pack 3. Allother platforms and versions of EMET are out of scope. In the researchwell-known attacks on well-known vulnerable binaries will be used. Theseexploits will be performed using the Metasploit framework.
1.3 Privacy and Security Considerations
For this research we have to consider the possible issues that can emergeconsidering privacy and security. The research will be conducted on virtualmachines that will be run in a controlled environment. They will be runon our own private server and will only be reachable from within the OS3network. This is necessary because the virtual machines will be vulnerableto attacks so in order to not compromise the security of the network we willneed to keep them strictly shielded from the outside. As for the privacyconsiderations; because all the work will be conducted in this controlled andseparated environment, privacy of third parties will not be compromised.
5
2 EMET
In the project the effectiveness of EMET will be researched. EMET is ananti-exploit toolkit for the Windows platform and is developed by Microsoft.EMET stands for Enhanced Mitigation Experience Toolkit [1]. It is designedto make it more difficult for an attacker to exploit vulnerable software. Itcan deploy various countermeasures against attacks based on for instancememory corruption, but it also includes numerous other countermeasuresagainst different kinds of exploits.
The idea is that EMET can use these security measures on every appli-cation out there, no matter who wrote it, how long ago or for what purpose.
Having installed EMET in our Windows System has a lot of benefitssuch as:
• It doesn’t need any source code of applications, hence it is very handywhen the source code is not accessible.
• It doesn’t need to recompile the software with special compiler flags
• It is highly configurable, we can allow mitigations applied on somespecified processes instead of all. This is very useful when a processis not compatible with a particular mitigation technology. Here, theuser can turn the mitigation off for that process.
• It improves the security of legacy applications, third party software,and business applications in order to raise the cost of attacks
• Ease of use via EMET’s graphical user interface
• Regular updates, EMET 5 will be released in the near future whileEMET 4.1 Update 1 was released just one month ago.
• It requires little overhead and CPU utilization
• It has advantages over anti-malware and anti-virus for detecting zero-day attacks
• It is free (you can download EMET from Microsoft site)
2.1 History
Now we take a quick look at the developments of EMET:
EMET 1.0.2 (2009-10-27)The initial EMET 1.0.2 was command-line based, and provided the fol-
lowing features:
• SEHOP (system and per process)
6
• DEP (system and per process)
• Null page allocation
• Heap spray allocation
EMET 2.0 (2010-09-02)The EMET 2.0 had the GUI and added the following mitigations:
• System ASLR and per-process MandatoryASLR
• Export Address Table Filtering (EAF)
• Minor bugs were fixed in version 2.0.0.3.
EMET 3.0 (2012-05-15)The EMET 3.0 was capable of enterprise wide deployment with protec-
tion profiles. It wrote to event log and showed tooltip when mitigationscaught exploits.
• Three Protection Profiles
• ADMX Files for Group Policy Management
• EMET Notifier (alert user when exploitations happen)
EMET 3.5 (2012-07-25)The EMET 3.5 added ROP mitigations from ROPGuard. The added
mitigations were:
• Caller check
• Execution flow simulation
• Stack pivot
• Special function checks for Memory Protections and LoadLibrary
• Bottom Up ASLR
EMET 4.0 (2013-04-18)The EMET 4.0 added an audit mode and the following mitigations:
• Deep Hooks
• Anti-detours
• Banned Functions
• Certificate pinning
7
EMET 4.1 (2013-11-12)Here is the features add in 4.1:
• Update to default protection profiles
• Improved event logging
• App-compat update/fixes
• Fix to allow shared remote desktops
EMET 5.0Now there is only technical preview available for this version. Here we
list its features which are added:
• Attack Surface Reduction
– Preventing unwanted third party modules from loading in appli-cations
• EAF+
– Adding KernelBase to protected functions
– Adding additional checks to existing protected exports
2.2 Mitigation Techniques
For this research version 4.1 update 1 of EMET is used. This version con-sists of numerous mitigation techniques including mandatory Address SpaceLayout Randomization (ASLR), Data Execution Prevention (DEP), Struc-tured Exception Handler Overwrite Protection (SEHOP), Export AddressTable Access Filtering (EAF), Heap Spray Protection, NULL page, andAnti-ROP [4].
In the following we explain each of these techniques separately [4] [5].
2.2.1 Data Execution Prevention
Data Execution Prevention (DEP) is a technique that prevents against at-tacks that execute malicious code entered somewhere in the memory. Itdoes this by marking certain pages in the memory as non-executable code.In EMET the heap and the stack are marked as non-executable. When theattacker tries to run code stored in these areas of the memory, it will notwork.
8
2.2.2 SEHOP
SEHOP performs Structured Exception Handling (SEH) chain validation toprevent SEH overwrite exploitation.
The purpose of the SEHOP mitigation is to prevent an attacker frombeing able to exploit SEH overwrite exploitation technique. Roughly 20%of the exploits in the Metasploit framework is using the SEH overwritetechnique.
SEHOP is checking the chains of all SEH structures existing on theprocess stack and especially the last one. The last one contains a handlerpointing to ntdll! except handler4. By overwriting a SEH structure, thenext SEH pointer is changed including some bytecode. Here, SEH handleris pointing to the POP POP RET in a non-SafeSEH module.
Figure 1: Valid SEH chain vs invalid SEH chain
Before calling any exception handlers by OS, EMET explores the ex-ception record chain. If the chain has been changed, EMET will stop theprocess.
2.2.3 NullPage
This mitigation will prevent Null pointer dereferencing. EMET will pre-allocate the NULL adress in memory. This mitigation technique is similarto the mitigation technique HeapSpray Allocation.
2.2.4 HeapSpray
Heap spraying is a technique for executing the arbitrary code. Code whichsprays the heap, puts a certain bytes at a specified location in the memoryof the target process and reserves blocks on the heap in order to fill thebytes with the correct values. The problem is that usually, on most archi-tectures and operating systems, the start address of the heap allocations ispredictable, so when running heap spray, it will be usually put in the samelocation.
EMET works by reserving memory pages at the most well-known heapspray addresses to block well-known attacks that fill a processs heap withcrafted content. The list can be configured from the registry.
9
Figure 2: Heap Spray
2.2.5 EAF
When malicious code wants to do something to the system, it will need tocall the Windows APIs. The locations of those APIs are stored in the ExportAddress Table (EAT). Normally malicious code will look in the EAT to findthe locations of interesting APIs that it might need to execute its payload.Export-Address-Table Access Filtering (EAF) can filter the access to thistable, so these lookups can be blocked. This prevents the malicious codefrom actually influencing the system.
2.2.6 MandatoryASLR
One of the techniques for confronting the ROP is Address Space LayoutRandomization. ASLR makes the addresses of loading modules includingthe base of executable and the positions of stack, heap and libraries ran-dom as many as possible to prevent an attacker to guess the locations atpredictable addresses. So all modules have to use a compile time flag toopt into this. Application opt-in by linking executable files with /DYNAM-ICBASE. /DYNAMICBASE modifies the header of an executable to changedynamically the application at load time.
Regardless of the flags compiled before, EMET forces modules to beloaded at randomized addresses. In this way the attacks relied on ROP willfail and the process will crash than being exploited.
BottumUpASLRThis technique randomized the base addresses of bottom-up allocations
such as heaps, stacks. It reserves a random number of 64K regions viaVirtualAlloc(). This will make future memory allocation less predictable.It provides entropy to images which have been randomized via mandatoryASLR.
10
2.2.7 LoadLib
Load library checks is a mitigation technique where EMET will look at thecalls to the LoadLibrary API. It will make sure that no libraries are loadedfrom a UNC path. When an application is allowed to load libraries fromlocations via a UNC path this option should not be activated.
2.2.8 Memory Protection
The MemProt rule checks memory protection functions like VirtualProtectin order to not allow making the stack area executable for shellcode.
2.2.9 Caller
The EMET Caller Check will check that when program is reaching a crit-ical function, it got there from a ”call” instruction and not from a ”ret”instruction. It prevents manipulation of the regular program flow.
2.2.10 SimExecFlow
EMET simulates execution forward from a critical function call. Simulatorforwards and follows the return addresses. The first return address is given(on the stack) and the subsequent return addresses are deduced by simulat-ing instructions that change the stack pointer. Each return address must bepreceded by a call instruction.
2.2.11 StackPivot
This technique checks to see if the stack has been pivoted, i.e. the stackpointer is in the thread’s upper and lower specified stack limit.
2.3 System and Application Mitigations
We can configure EMET via system or application mitigations [4].DEP, ASLR and SEHOP can be turned on at the system level. This will
impact the whole system. In the table 1 you can see the system mitigationscompatibility matrix in different Windows systems.
System Mitigation XP Vista Win 7 Win 8
DEP X X X XSEHOP - X X XASLR - X X X
Table 1: Compatibility matrix-System
The available settings in the EMET for system mitigation are:
11
• Disabled: disable the mitigation technology for the system and allapplications
• Application Opt In: the mitigation technique is enabled only for pro-cesses that explicitly opt-in to mitigation technique
• Application Opt Out: forces all applications to use the mitigationtechnology unless they are compiled to opt out of it
• Always on: the mitigation technique is enabled by default for all pro-cesses except those that explicitly opt out of mitigation technique.
The application mitigations compatibility matrix in different Windowssystems is shown in table 2.
Application Mitigation XP Vista Win 7 Win 8
DEP X X X XSEHOP X X X X
Mandatory ASLR - X X XNULL page X X X XHeap Spray X X X X
EAF X X X XBottom-up X X X X
Load library checks X X X XMemory protection checks X X X X
Simulate execution flow X X X XStack pivot X X X X
Table 2: Compatibility matrix-Application
All of the above techniques can be turned on for individual applications.In this way, the mitigation techniques will only impact the specified applica-tions. Besides that sometimes specific security mitigation technologies breaksome applications, here EMET enables us to turn the specified techniquesoff (or on) for each application.
2.4 Event Log
EMET events are logged in the Windows Event Log. The logs can be foundunder the Application logs with the EMET event source. When the EMETfinds an exploit in an application, it will stop the attack and a message willbe shown via a tooltip in the taskbar notification area.
12
Figure 3: EMET’s notification
3 Approach and Experiment
3.1 Approach
In order to be able to test the effectiveness of EMET, an experiment wasdesigned. The goal of the experiment is to show if EMET actually canprotect you from a hacker using an exploit to take control over your system.
In order to do this, first a number of working exploits for the systemneed to be found. To find the exploits Metasploit will be used. Metasploitis one of the best free, open source hacking penetration tools which is widelyused by security experts and pen-testing community. Its framework was de-signed such that exploitations can be done easily via known vulnerabilitiesin networks, operating systems and applications and also inspires new ex-ploits for new vulnerabilities. The free version of Metasploit is known as theMetasploit Community which we used during this project.
By following the guides on internet well-known attacks on different ap-plications can be found. When testing if the exploit works, it was markedas being successful i.e. it was possible to create a shell session on the victimsystem. Denial of service attacks are not seen as successful attacks and aretherefor not used in the next part of the experiment.
In this phase, the system will not be running EMET. When a number ofexploits have been found, tested, and shown to be working, EMET will beactivated on the target applications. The exploits found earlier will be testedwith EMET enabled. Now we can see exactly what the effect of EMET is onthe security of the system. The more exploits fail after turning on EMET,the better EMET succeeds in it’s goal to protect vulnerable applications.We repeated each exploits multiple times to be sure about the behavior ofEMET.
3.2 Experimental Setup
To be able to properly perform this test, two experimentation environmentswere set up, both running a different version of Windows.
• Windows 7 Home Premium SP1
• Windows XP Professional SP3
These experimentation machines are run as virtual machines. They areonly accessible from within the OS3 network. This is very important be-cause vulnerable software will be installed on the machines, and doing so
13
with an active internet connection will pose a risk of being attacked andcompromised.
On these systems a number of vulnerable applications were installed andthen exploited.
3.3 Vulnerable Software and Exploits
For attacking systems, we used some well-known attacks on well-known bi-naries. You can find these vulnerable software in the table 3. Most of theseexploits use social engineering to attract the victim to download and openthe crafted file. Another way is establishing a client/server connection be-tween the attackers host and the victim and then enticing the victim to clickon the link and exploit his system.
Note that these exploits were successful without EMET enabled. Theseexploits will be used to test the effectiveness of EMET.
14
Exploit Target Version Victim PC CVE-ID
VLC 1.1.8 XP SP3 CVE-2011-1574
Adobe PDF 8.1.2 XP SP3 CVE-2009-0658
Wireshark 1.2.5 XP SP3 CVE-2010-0304
Winamp 5.12 XP SP3 CVE-2006-0476
DVD X Player 5.5 Pro XP SP3 CVE-2007-3068
TFM MMPlayer 2.2 XP SP3 N/A
Fat Player 0.6b XP SP3 CVE-2009-4962
TugZip 3.5 XP SP3 CVE-2008-4779
MicroP 0.1.1.1600 XP SP3 N/A
Foxit Reader 4.1.1 XP SP3 N/A
Apple Quicktime 7.7 XP SP3 CVE-2012-0663
ERS Viewer 11 XP SP3 CVE-2013-0726
Orbital Viewer 1.04 XP SP3 CVE-2010-0688
JRE 7u7 XP SP3 CVE-2012-5076
Galan 0.2.1 XP SP3 N/A
Microsoft Word 2007 XP SP3 CVE-2012-0158
Adobe Reader 9.0 XP SP3 CVE-2009-0658
Mozilla Firefox 3.6.9 XP SP3 CVE-2010-3765
Internet Explorer 8 XP SP3 CVE-2011-1260
JRE 6u16 XP SP3 CVE-2009-3867
AudioCoder 0.8.18 Win 7 CVE: N/A
XAMPP 1.7.3 Win 7 CVE: N/A
Maxthon 3.1.7 Win 7 CVE: N/A
Internet Explorer 8 Win 7 CVE-2013-1347
Internet Explorer (2) 8 Win 7 CVE-2012-4969
Winamp 5.55 Win 7 CVE-2009-1831
JRE 7u15 Win 7 CVE-2013-1493
FotoSlate 4.0 build 146 Win 7 CVE-2011-2595
Winrar 4.20 Win 7 CVE: N/A
Table 3: Successful exploits
15
4 Findings/results
4.1 Successful EMET
Now after EMET installed, we repeated each exploits multiple times andmonitored the behavior of EMET. Table 4 shows which mitigation tech-niques in EMET stop the exploitations from penetrating to the WindowsSystems.
Vulnerable Software Mitigation Technology
VLC Caller
Adobe PDF SEHOP
Wireshark SEHOP
Winamp DEP
DVD X Player EAF
TFM MMPlayer SEHOP
Fat Player SEHOP
TugZip SEHOP
MicroP DEP
Mozilla Firefox Stack Pivot
Foxit Reader SEHOP
Apple QuickTime SEHOP
ERS Viewer DEP
Orbital Viewer SEHOP
JRE EAF
Galan DEP
Microsoft Word SEHOP
Adobe Reader DEP
Internet Explorer Heap Spray and DEP
AudioCoder DEP
Internet Explorer Heap Spray
Internet Explorer (2) StackPivot
Winamp No report
JRE Mandatory ASLR
FotoSlate No report
Table 4: Successful EMET
In all of these cases EMET stops malicious codes by killing the wholeprocess before the malicious code can do its damage.
4.2 Unsuccessful EMET
Among around 30 successful exploits done in Windows systems, just threeof them were not detected by EMET.
16
• XAMPP
• Maxthon
• WinRAR
Here we focus on the WinRAR and Maxthon applications to understandwhy the vulnerabilities cannot be prevented by mitigation techniques.
WinRARWinRAR is an application used for file archiver and data compression.
In this exploit, WinRAR file extension spoofing vulnerability is used whichenables attackers to hide malware. The mentioned vulnerability allows at-tackers to change the name of the file and extension to whatever they wantinside the file archive. This helps them to show a picture file or an mp3 orany other format instead of the malicious code.
If we use a hex editor to investigate a ZIP file, we will notice that Win-RAR tool adds some custom properties such as names. It has two names forfile. First name is the main name and the second one is the name which willbe shown at the GUI window. The attacker can change the second nameand extensions to tempt users.
Figure 4: Hex Editor opening archive file
Figure 5: After changing the name of file in hex editor
Abusing this feature, the attacker puts malware code in the archive filesand bypasses security measures in EMET.
Maxthon
17
Maxthon is a web browser for Windows users. This application is proneto cross context scripting vulnerabilities which affect about:history. An ar-bitrary JavaScript/HTML code can be injected through the visited websitesby using location.hash property. The code is rendered into the history page.
As the injection point is in the mx://res/ privileged browser zone, it canenable Maxthon to access native JavaScript privileged functions. Such ca-pability can be used to read and write from file system and execute arbitrarycode.
EMET is looking for a specific behavior. If the attacker can find an-other alternative behavior, bypasses are achievable. For example in CVE-2010-3971 the protection could be bypassed, due to disabling ASLR in DLLmscorie.dll in the Internet Explorer. Other ways of bypassing ASLR rely oninformation leakage, brute-force and using timing-side channels. There areother methods proposed by Bromium Labs for bypassing EMET [5]. Thisgroup suggested Microsoft to handle these weaknesses:
• Hook NtProtectVirtualMemory by default
• Create a new EAF protection scheme
• Check more than one CALL deep to detect if code was RETen into
• Expand the ROP mitigation to cover 64 bit code
Besides those, EMET may not be useful against kernel vulnerabilitiesand non-exploit attacks like Java sandbox escapes.
18
5 Conclusion and Future Work
In this research the focus was on two questions. The first question wasabout the way EMET tries to protect the system from being exploited. Asdescribed in chapter 2, EMET makes it possible for applications to make useof modern exploit mitigation techniques, no matter how old the applicationis or if it is still supported. This means that EMET targets especially theapplications that are at risk of being exploited. The nature of EMET alsogives it an advantage in protecting against zero-day exploits. Conventionalanti-virus solutions work with detection based on signatures of known mal-ware, but for zero-day exploits such signatures are not available. EMETuses its mitigation techniques to protect against the unwanted behaviour ofthe malware, not its signature. This different approach gives it an advantageover regular solutions
The second research question is about how effective this protection is inthe real world. Is this approach of system protection actually effective inpreventing the exploitation of the system? In the experiment conducted, vul-nerable software was installed on systems and then exploited. Then EMETwas installed to see if EMET would actually prevent the previously testedexploits. The results were impressive, as EMET was successful in preventingthe exploits in 25 out of 28 cases. This shows that EMET really does makethe system safer. It hardens the system and creates an extra layer in thedefence against exploits.
It should of course be noted that there are always possibilities for adetermined attacker to bypass EMET. In a targeted attack EMET can bebypassed so using EMET does certainly not guarantee a perfectly safe sys-tem. The results did show that EMET can be very effective in protect-ing Windows system from well-known exploitation in different applications.This good result, combined with the fact that EMET is freely available foranybody to use and that the installation and configuration of EMET is a5 minute job, make it a very useful application. In all environments wheresecurity is somewhat important, setting up EMET should be well worth theeffort.
As recommendations for future work there are a number of areas thatcould be explored.
First of all a new version of EMET, EMET 5.0 is currently in develop-ment. A technical preview of EMET 5.0 has been released in February 2014.This new version includes a number of improvements to the techniques al-ready in version 4.1, as well as new features. Testing the effectiveness of thisnew version compared to the current version could be interesting.
Another interesting subject could be research in beating the EMET sys-tem. If more people are using EMET, cyber criminals will try to find waysaround EMET. Are there exploits that employ countermeasures especiallyagainst EMET?
19
Finally it could also be interesting to investigate how EMET performswhen having to deal with current state of the art exploits. In this researchonly well-known attacks were used, but maybe EMET does not perform aswell against really new or more advanced exploitation techniques.
20
References
[1] L. Bilge and T. Dumitras, “Before we knew it: An empirical study ofzero-day attacks in the real world,” in Proceedings of the 2012 ACMConference on Computer and Communications Security, ser. CCS ’12.New York, NY, USA: ACM, 2012, pp. 833–844. [Online]. Available:http://doi.acm.org/10.1145/2382196.2382284
[2] S. L. Rose. (2011, Mar.) Whats emet and how can you benefit?(enhanced mitigation experience toolkit). [Online]. Available: http://blogs.windows.com/windows/b/springboard/archive/2011/03/04/what-s-emet-and-how-can-you-benefit-enhanced-mitigation-experience-toolkit.aspx
[3] Downloading emet. [Online]. Available: http://www.microsoft.com/en-us/download/details.aspx?id=41138
[4] Emet user’s guide. [Online]. Available: http://download.microsoft.com/download/7/A/A/7AA570E7-92DF-4C28-BE12-E72831797666/EMET%20User%27s%20Guide.pdf
[5] J. Demott. (2014, Feb.) Bypassing emet 4.1. [Online]. Available: http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf
21
Appendices
A Used exploits
ERS Viewer(CVE-2013-0726)This module exploits a buffer overflow vulnerability found in ERS Viewer
2011 (version 11.04). The vulnerability exists in the module ermapper u.dllwhere the function ERM convert to correct webpath handles user provideddata in a insecure way. It results in arbitrary code execution under the con-text of the user viewing a specially crafted .ers file. This module has beentested successfully with ERS Viewer 2011 (version 11.04) on Windows XPSP3 and Windows 7 SP1.
gAlan(CVE N/A)This module exploits a stack buffer overflow in gAlan 0.2.1 by creating
a specially crafted galan file.
Orbital Viewer(CVE-2010-0688)This module exploits a stack-based buffer overflow in David Manthey’s
Orbital Viewer. When processing .ORB files, data is read from file into afixed-size stack buffer using the fscanf function. Since no bounds checkingis done, a buffer overflow can occur. Attackers can execute arbitrary codeby convincing their victim to open an ORB file.
Real Player(CVE-2012-5691)This module exploits a stack based buffer overflow on RealPlayer ¡=15.0.6.14.
The vulnerability exists in the handling of real media files, due to the in-secure usage of the GetPrivateProfileString function to retrieve the URLproperty from an InternetShortcut section. This module generates a mali-cious rm file which must be opened with RealPlayer via drag and drop ordouble click methods. It has been tested successfully on Windows XP SP3with RealPlayer 15.0.5.109.
Java Applet(CVE-2012-5076)This module abuses the JAX-WS classes from a Java Applet to run arbi-
trary Java code outside of the sandbox as exploited in the wild in Novemberof 2012. The vulnerability affects Java version 7u7 and earlier.
Microsoft Word(CVE-2012-0158)This module exploits a stack buffer overflow in MSCOMCTL.OCX. It
uses a malicious RTF to embed the specially crafted MSComctlLib.ListViewCtrl.2Control as exploited in the wild on April 2012. This module targets Office2007 and Office 2010 targets. The DEP/ASLR bypass on Office 2010 is
22
done with the Ikazuchi ROP chain proposed by Abysssec. This chain uses”msgr3en.dll”, which will load after office got load, so the malicious file mustbe loaded through ”File / Open” to achieve exploitation.
QuickTime(CVE-2012-0663)This module exploits a vulnerability found in Apple QuickTime. When
handling a TeXML file, it is possible to trigger a stack-based buffer overflow,and then gain arbitrary code execution under the context of the user. Thisis due to the QuickTime3GPP.gtx component not handling certain Stylesubfields properly, storing user-supplied data on the stack, which results theoverflow.
Apple QuickTime(CVE-2012-3752)This module exploits a vulnerability found in Apple QuickTime. When
handling a TeXML file, it is possible to trigger a stack-based buffer over-flow, and then gain arbitrary code execution under the context of the user.This is due to the QuickTime3GPP.gtx component not handling certainStyle subfields properly, as the font-table field, which is used to trigger theoverflow in this module. Because of QuickTime restrictions when handlingfont-table fields, only 031-039 bytes can be used to overflow, so at the mo-ment DEP/ASLR bypass hasnt been provided. The module has been testedsuccessfully on IE6 and IE7 browsers (Windows XP and Vista).
Fat Player(CVE-2009-4962)This module exploits a buffer overflow in Fat Player 0.6b. When the
application is used to import a specially crafted wav file, a buffer overflowoccurs allowing arbitrary code execution.
TFM MMPlayer(CVE N/A)This module exploits a buffer overflow in MMPlayer 2.2 The vulnerabil-
ity is triggered when opening a malformed M3U/PPL file that contains anoverly long string, which results in overwriting a SEH record, thus allowingarbitrary code execution under the context of the user.
VLC(CVE-2011-1574)This module exploits an input validation error in libmod plugin as in-
cluded with VideoLAN VLC 1.1.8. All versions prior to version 1.1.9 areaffected. By creating a malicious S3M file, a remote attacker could executearbitrary code. Although other products that bundle libmodplug may bevulnerable, this module was only tested against VLC. NOTE: As of July1st, 2010, VLC now calls SetProcessDEPPoly to permanently enable NXsupport on machines that support it. As such, this module is capable ofbypassing DEP, but not ASLR.
23
MicroP(CVE N/A)This module exploits a vulnerability found in MicroP 0.1.1.1600. A
stack-based buffer overflow occurs when the content of a .mppl file getscopied onto the stack, which overwrites the lpFileName parameter of a Cre-ateFileA() function, and results arbitrary code execution under the contextof the user.
Wireshark(CVE-2010-0304)The LWRES dissector in Wireshark version 0.9.15 through 1.0.10 and
1.2.0 through 1.2.5 allows remote attackers to execute arbitrary code due toa stack-based buffer overflow. This bug found and reported by babi. Thisparticular exploit targets the dissect getaddrsbyname request function. Sev-eral other functions also contain potentially exploitable stack-based bufferoverflows. The Windows version (of 1.2.5 at least) is compiled with /GS,which prevents exploitation via the return address on the stack. Sending alarger string allows exploitation using the SEH bypass method. However,this packet will usually get fragmented, which may cause additional com-plications. NOTE: The vulnerable code is reached only when the packetdissection is rendered. If the packet is fragmented, all fragments must becaptured and reassembled to exploit this issue.
Winamp(CVE-2006-0476)This module exploits vulnerability in the Winamp media player. This
flaw is triggered when a audio file path is specified, inside a playlist, thatconsists of a UNC path with a long computer name. This module deliversthe playlist via the browser. This module has only been successfully testedon Winamp 5.11 and 5.12.
DVD X Player(CVE-2007-3068)This module exploits a stack-based buffer overflow on DVD X Player 5.5
Pro and Standard. By supplying a long string of data in a plf file (playlist),the MediaPlayerCtrl.dll component will attempt to extract a filename outof the string, and then copy it on the stack without any proper boundschecking, which casues a buffer overflow, and results arbitrary code execu-tion under the context of the user. This module has been designed to targetcommon Windows systems such as: Windows XP SP2/SP3, Windows Vista,and Windows 7.
TugZip(CVE-2008-4779)This module exploits stack-based buffer overflow vulnerability in the
latest version 3.5 of Tug Zip archiving utility. In order to trigger the vul-nerability, an attacker must convince someone to load a specially crafted zipfile with Tug Zip by double click or file open. By doing so, an attacker canexecute arbitrary code as the victim user.
24
Foxit Reader(CVE N/A)This module exploits a stack buffer overflow in Foxit PDF Reader prior
to version 4.2.0.0928. The vulnerability is triggered when opening a mal-formed PDF file that contains an overly long string in the Title field. Thisresults in overwriting a structured exception handler record. NOTE: Thisexploit does not use JavaScript.‘
Adobe Reader(CVE-2009-0658)This module exploits a heap-based pointer corruption flaw in Adobe
Reader 9.0.0 and earlier. This module relies upon javascript for the heapspray.
Mozilla Firefox(CVE-2010-3765)This module exploits a code execution vulnerability in Mozilla Firefox
caused by interleaved calls to document.write and appendChild. This mod-ule was written based on a live exploit found in the wild.
Internet Explorer (CVE-2011-1260)This module exploits a use-after-free vulnerability in Internet Explorer.
The vulnerability occurs when an invalid ¡object¿ tag exists and other ele-ments overlap/cover where the object tag should be when rendered (due totheir styles/positioning). The mshtml!CObjectElement is then freed frommemory because it is invalid. However, the mshtml!CDisplay object for thepage continues to keep a reference to the freed ¡object¿ and attempts tocall a function on it, leading to the use-after-free. Please note that for IE 8targets, JRE (Java Runtime Environment) is required to bypass DEP (DataExecution Prevention).
JRE (CVE-2009-3867)This module exploits a flaw in the getSoundbank function in the Sun
JVM. The payload is serialized and passed to the applet via PARAM tags. Itmust be a native payload. The effected Java versions are JDK and JRE 6 Up-date 16 and earlier, JDK and JRE 5.0 Update 21 and earlier, SDK and JRE1.4.223andearlier, andSDKandJRE1.3.126andearlier.NOTE : Althoughalloftheaboveversionsarereportedlyvulnerable, only1.6.0u11and1.6.0u16onWindowsXPSP3weretested.
AudioCoder( CVE: N/A )This module exploits a buffer overflow in AudioCoder 0.8.18. The vul-
nerability occurs when adding an .m3u, allowing arbitrary code executionwith the privileges of the user running AudioCoder. This module has beentested successfully on AudioCoder 0.8.18.5353 over Windows XP SP3 andWindows 7 SP1.
XAMPP ( CVE: N/A )
25
This module exploits weak WebDAV passwords on XAMPP servers. Ituses supplied credentials to upload a PHP payload and execute it.
Maxthon ( CVE: N/A )Cross Context Scripting (XCS) is possible in the Maxthon about:history
page. Injection in such privileged/trusted browser zone can be used to mod-ify configuration settings and execute arbitrary commands. Please note thismodule only works against specific versions of XCS. Currently, we’ve onlysuccessfully tested on Maxthon 3.1.7 build 600 up to 3.2.2 build 1000.
Internet Explorer 8 ( CVE-2013-1347 )This module exploits a vulnerability found in Microsoft Internet Ex-
plorer. A use-after-free condition occurs when a CGenericElement object isfreed, but a reference is kept on the Document and used again during ren-dering, an invalid memory that’s controllable is used, and allows arbitrarycode execution under the context of the user. Please note: This vulnerabil-ity has been exploited in the wild on 2013 May, in the compromise of theDepartment of Labor (DoL) Website.
Internet Explorer 8 ( CVE-2012-4969 )This module exploits a vulnerability found in Microsoft Internet Ex-
plorer (MSIE). When rendering an HTML page, the CMshtmlEd objectgets deleted in an unexpected manner, but the same memory is reused againlater in the CMshtmlEd::Exec() function, leading to a use-after-free condi-tion. Please note that this vulnerability has been exploited in the wild sinceSep 14 2012. Also note that presently, this module has some target depen-dencies for the ROP chain to be valid. For WinXP SP3 with IE8, msvcrtmust be present (as it is by default). For Vista or Win7 with IE8, or Win7with IE9, JRE 1.6.x or below must be installed (which is often the case).
Winamp ( CVE-2009-1831 )This module exploits a stack based buffer overflow in Winamp 5.55.
The flaw exists in the gen ff.dll and occurs while parsing a specially craftedMAKI file, where memmove is used with in a insecure way with user con-trolled data. To exploit the vulnerability the attacker must convince theattacker to install the generated mcvcore.maki file in the ”scripts” directoryof the default ”Bento” skin, or generate a new skin using the crafted mcv-core.maki file. The module has been tested successfully on Windows XPSP3 and Windows 7 SP1.
JRE ( CVE-2013-1493)This module abuses the Color Management classes from a Java Applet
to run arbitrary Java code outside of the sandbox as exploited in the wildin February and March of 2013. The vulnerability affects Java version 7u15
26
and earlier and 6u41 and earlier and has been tested successfully on Win-dows XP SP3 and Windows 7 SP1 systems. This exploit doesn’t bypassclick-to-play, so the user must accept the java warning in order to run themalicious applet.
FotoSlate ( CVE-2011-2595 )This module exploits a buffer overflow in ACDSee FotoSlate 4.0 Build
146 via a specially crafted id parameter in a String element. When viewinga malicious PLP file with the ACDSee FotoSlate product, a remote attackercould overflow a buffer and execute arbitrary code. This exploit has beentested on systems such as Windows XP SP3, Windows Vista, and Windows7.
Winrar ( CVE: N/A )This module abuses a filename spoofing vulnerability in WinRAR. The
vulnerability exists when opening ZIP files. The file names showed in Win-RAR when opening a ZIP file come from the central directory, but the filenames used to extract and open contents come from the Local File Header.This inconsistency allows to spoof file names when opening ZIP files withWinRAR, which can be abused to execute arbitrary code, as exploited inthe wild in March 2014
27
