Active Members Fi8sVrs Posted January 27, 2013 Active Members Report Posted January 27, 2013 (edited) ==================================================Attacking the Windows 7/8 Address Space RandomizationCopyright © 2013 Kingcope"Was nicht passt wird passend gemacht" (English: "If it don't fit, use a bigger hammer.") German phrase==================================================Synopsis - What this text is all about==================================================The following text is what looks like an attempt to circumvent windows 7 andwindows 8 memory protections in order to execute arbritrary assembly code.The presented methods are in particular useful for client-side attacks as usedfor example in browser exploits.The topic that is discussed is a very complex one. At the time I started theresearch I thought the idea behind the attack will be applied to real-worldscenarios quick and easy. I had to be convinced by the opposite.The research was done without knowing much about the real internals of the windows memory space protection but rather using brute force, trial & failurein order to achieve what will be presented in the upcoming text. Be warned -the methods to attack the protection mechanisms hereby presented are notfailsafe and can be improved. Tough in many cases it is possible tocompletely bypass Windows 7 and especially Windows 8 ASLR by using thetechniques.Target Software==================================================The used operating systems are Windows 7 and Windows 8, the included PoC coderuns on 32 Bits platforms and exploits Internet Explorer 8. All can be appliedto Internet Explorer 9 with modifications to the PoC code. For Internet Explorer 10 the memory protection bypass is included anddemonstrated in the PoC. Executing code through return oriented programmingis left as an excercise to the reader.The PoC makes use of the following vulnerability and therefore for testing thePoC the patch must not be installed.MS12-063 Microsoft Internet Explorer execCommand Use-After-Free VulnerabilityThis vulnerability is identified as CVE-2012-4969.It might be possible to use the very same method to exploit other browsersas other browsers give similar opportunities to the exploit writer. I don't wantto sound crazy but even other Operating Systems might be affected by this, yetunconfirmed.Current ways to exploit browsers==================================================Today alot of attention is brought to client side exploits especially insideweb browsers. Normally the exploitation is done through the old known methodof spraying the heap. This is done by populating the heap with nopsleds andactual shellcode. By filling the heap in this way a heap overrun can be usedto rewrite the instruction pointer of the processor to a known heap addresswhere the shellcode resides quite deterministic.In order to bypass protections like Data Execution Prevention a ROP chain isbuilt. There are exploits that install a stack pivot in the first place inorder to exploit a heap overrun as it would be a stack based buffer overrunusing a "return into code" technique. The mentioned modern ways to exploitheap corruptions are documented very well. When it comes to Windows 7 and Windows 8 exploitation the exploit writerwill face the obstacle of randomized memory space. There remains the simplequestion where do I jump to when having control over the instruction pointer?It might by possible to leak memory directly from the web browser and use thisinformation to gain information about the correct offsets and executable codesections. This requires knowledge about a memory leak bug tough and thereforeis not used alot. Another option is to use old DLLs that do not have theirimage bases randomized, for example older Java versions are known to have un-randomized image bases. This option requires the use of third-party softwarethat has to be installed.This text will present a new way to deal with the 'where do i jump whenI have code execution' problem.Introduction to Windows memory randomization==================================================Windows 7 and Windows 8 have a special security relevant protection programmedin. The so called A.S.L.R or '[A]ddress pace [L]ayout [R]andomization' that does nothing more than randomize every piece of memory, say its offsets.For example the program image is randomized, the DLLs the program uses arerandomized too. There is not a single piece of memory from what one could sayafter a reboot the data in the memory space will be at the same place as beforethe reboot. The addresses even change when a program is restarted.ActiveX and other useful features==================================================Web browser exploits have many advantages to other kinds of exploits.For example JavaScript code can be executed inside the webbrowser. This is alsothe tool that heap spraying makes use of.Let us have a look at what happens if we load an ActiveX object dynamicallywhen a web page loads. The ActiveX object we will load is the Windows Media Player control. This can either be done using JavaScript or plain HTML code.At the point the ActiveX object is loaded Windows will internally load theDLLs into memory space if they previously where not inside the programsmemory space. The offset of loading the DLLs in memory space is completely random. At least it should be. Let us now see how we can manage to put a DLLinto memory space at a fixed address by loading an ActiveX object at runtime.Exhausting memory space and squeezing DLLs into memory==================================================The nuts and bolts of what is presented here is the idea that DLLs are loadedinto memory space if there is memory available, and if there is no memory oronly small amounts of memory available then the DLL will be put into theremaining memory hole. This sounds simple. And it works, we can load a DLLinto a remaining memory hole. First of all the exploit writer has to codea javascript routine that does fill memory until the memory boundary is hitand a javascript exception is raised. When the memory is filled up the installedjavascript exception handler will execute javascript code that frees smallchunks of memory in several steps, each step the javascript code will try toload an ActiveX object. The result is that the DLL (sometimes there are severalDLLs loaded for an ActiveX object) will be loaded at a predictable address.This means that now the exploit writer has a predictable address to jump to andthe 'where do i jump when I have code execution' problem is solved.One problem the method has is that Windows will become unresponsive at the timememory is exhausted but will resume normal operation after the DLL is loadedat a fixed address and the memory is freed using the javascript code.Summary of exploitation stages: * Fill the heap with random bytes until all memory is used up. During the heap filling stage Windows might become unresponsive and will relax soon afterwards·* Free small heap blocks one by one and try adding a DLL (for example by using a new ActiveX Object that is loadable without a warning by Internet Explorer) This DLL (and the DLLs that are loaded from it) will be squeezed into the remaining memory region (the space that was freed by us through JavaScript). This address is fixed and predictable for us to jump to * Free the remaining memory blocks which were allocated before * Spray the heap using the well known method * Finally trigger the heap corruption and jump to this fixed DLL base to execute our code in a ROP manner. To say it abstract the exploit writer has to be especially careful about thetiming in the JavaScript code and about the memory the exploit routinesthemselves take up.ROP chain and the LoadLibrary API==================================================At the time we have loaded the DLL at a predictable address it is possible touse a ROP chain in order to execute shellcode. The PoC code goes a much simplerpath. It will use a short ROP chain and call the LoadLibrary API that iscontained in the Windows Media Player DLLs. This way another DLL can be fetchedfrom a WebDAV share and loaded into the Internet Explorer memory space in orderto fully execute arbritrary code.Windows 8 singularity==================================================Testcases have shown that Windows 8 behaves more vulnerable to the method thanWindows 7. In Windows 8 the DLL will be loaded at the very low address 0x10000and more reliable than in Windows 7. Windows 7 is much more persistant inloading the DLL at a fixed memory address. The testcases for Windows 7 haveshown that the DLL will be loaded at the predictable address at least 7 out of10 times of loading the exploit.The PoC codes==================================================There are two different PoCs, one for Windows 7 and one for Windows 8.The Windows 8 code is a slightly modified version of the Windows 7 code.Please note that Windows Defender detects the Win8 PoC as being an exploit andblocks execution. The parts which are detectable by windows defender arenot needed for the A.S.L.R. attack to work. Please disable Windows Defenderif you test the Windows 8 PoC for now.The Windows 7 PoC is successful if it loads gdiplus.dll at the predictablefixed offset 0x7F7F0000. If you are lucky and have set up the exploitappropriately the payload will be executed, which is currently a MessageBox thatpops up.The Windows 8 PoC is successful if it loads gdiplus.dll at the predictablefixed offset 0x10000.Please note that wmp.dll (Windows Media Player DLL) and gdiplus.dll should notbe in the Internet Explorer address space prior to executing the PoC for it to succeed.As a final note, the PoC does not depend on the ActiveX control that is added itcan be changed with some effort to load a different DLL.Here are the mappings I tested when the PoC succeeds:Windows 7 32-Bit Service Pack 0 & Service Pack 1 across reboots:Address Size Owner Section Contains Type Access 7F7F0000 00001000 gdiplus PE header Imag R RWE7F7F1000 0016B000 gdiplus .text code,imports Imag R RWE7F95C000 00008000 gdiplus .data data Imag R RWE7F964000 00001000 gdiplus Shared Imag R RWE7F965000 00012000 gdiplus .rsrc resources Imag R RWE7F977000 00009000 gdiplus .reloc relocations Imag R RWEWindows 8 32-Bit across reboots:Address Size Owner Section Contains Type Access 00010000 00001000 gdiplus PE header Imag R RWE00011000 00142000 gdiplus .text code,exports Imag R RWE00153000 00002000 gdiplus .data Imag R RWE00155000 00003000 gdiplus .idata imports Imag R RWE00158000 00012000 gdiplus .rsrc resources Imag R RWE0016A000 00009000 gdiplus .reloc relocations Imag R RWEEnjoy!This archive has a whitepaper that discusses research and methods used to circumvent Microsoft Windows 7 and 8 memory protections in order to execute arbitrary assembly code. Proof of concepts are also provided.Downloadhttp://packetstormsecurity.com/files/119835/Attacking-The-Windows-7-8-Address-Space-Randomization.html Edited January 27, 2013 by Fi8sVrs Quote
