Auscert-2k10 - Slide 1


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Auscert-2k10 - Slide 1

  1. 1. A History of Microsoft Exploit Mitigations Benjamin Mossé
  2. 2. Overview  Definition and scope  Introduction to binary exploitation  Exploit mitigation mechanisms  Vulnerability context  Miscellaneous  Conclusion
  3. 3. Definition & Scope  Exploit mitigation: “a feature of the operating system which enhance the difficulty of exploiting a vulnerability”.  Presentation of the current exploit mitigations and discussion of the impact those technologies have on several fields of IT security.  Windows-based systems only.  High level oriented presentation.
  4. 4. Intended audience  Not experts in exploitation  You would like to get some insights on how exploit mitigation technologies work and what are their limitations.  You work for an organization who still runs Internet Explorer 6; you’re thinking of migrating all your workstations to IE8 and would like to get a high level or semi-technical explanation of why from a security standpoint that’s a good idea.  Try to answer the “Is my Windows secure?” question
  5. 5. Part i – Introduction to binary exploitation
  6. 6. Introduction to exploitation  Understand how memory works  Understand the fundamentals of exploitation  Understand some of the basics of how our applications work at the system-level (assembly)
  7. 7. Normal control flow of an application Function 1 Function 2 Function 3
  8. 8. In Memory Region 3Region 2Region 1 Function 1 Function 2 Function 3 Function 4 Function 5 Function 6 Memory is divided in regions.
  9. 9. Memory regions  Each region has:  A start address  Access control properties: read, write, execute  Within each applications we also find the following regions:  The stack – to story static data  The heap – to store dynamic data
  10. 10. Concept of exploiting a memory corruption vulnerability Function 1 Function 2 Function 3 shellcodeFunction 2 has a fault which allows attackers to modify the control flow of the application. Function 2 will jump into the attackers Shellcode instead of Function 3.
  11. 11. A few word about the shellcode  The shellcode is a small piece of code used as a payload in the exploitation of a software vulnerability  It is also stored in a memory region (often the stack or the heap)  Hence if the region the shellcode is in is not executable, the shellcode won’t work
  12. 12. Exploiting a vulnerability: 3 requirements Working exploit Control the application’s flow Crash Shellcode
  13. 13. Part ii – Exploit mitigation technologies
  14. 14. Exploit mitigation mechanisms  Introduction  An overview at the history  Analyzing specific mechanisms  /GS cookie  SafeSEH  SEHOP  DEP  ASLR
  15. 15. Introduction  Applications compiled with Visual Studio (Microsoft’s compiler)  A certain number of flags need to be on:  /DYNAMICBASE  /GS  /NXCOMPAT  /SAFESEH
  16. 16. Exploit mitigations  Two (2) main categories of mitigations  The ones that try to stop common know exploitation patterns:  DEP  ASLR  SafeSEH  The ones that try to detect a memory corruption fault:  /GS cookie  Heap protections  SEHOP
  17. 17. /GS cookie Buffer Stack cookie Return address Buffer overflow Before using the return address the application detects if the stack cookie (random generated value) has been modified. If it has, the application will terminate itself.
  18. 18. SEH Overwrite attack Buffer Stack cookie Return address SEH pointer One popular technique to bypass /GS was to overwrite the ‘SEH pointer’ located a the return address in memory. Then attackers would crash the application, resultin that pointer being used by the exception handler. Hence then taking control of the application flow. Buffer overflow
  19. 19. SafeSEH  Exploit mitigation against the SEH overwrite attack.  Verifies the SEH pointer before using it.  The memory address cannot point to a memory region protected by SafeSEH.  This method relies on the principle that every memory regions have been set with that protection. Hence if only one region is not protected, the mitigation becomes ineffective. Important note: for the SEH overwrite attack to work, attackers must generate a crash in the application. This is often done by trying to write data past the stack region.
  20. 20. Structured Exception Handler Overwrite Protection (SEHOP) Buffer Stack cookie Return address SEH pointer Random value Buffer overflow 1. Anti-exploitation mechanism introduced in windows Vista to prevent SEH overwrite attacks similar to the stack cookie 2. Set by default in Win 7 3. Checks that the random value located after the SEH pointer has not been modified before using the pointer.
  21. 21. Data Execution Prevention (DEP) Stack (read / write) Region 2 (R / X) Region 1 (R / X) Function A Function B Shellcode Function C i. Attackers have to find a location where to store their shellcode. ii. The known memory regions they use have been marked Non-Executable iii. Hence, their shellcode cannot be executed by the application anymore
  22. 22. Address Space Layout Randomization (ASLR)  Memory regions always start at a different address  Makes it harder to determine memory locations:  Where is my shellcode?  Hence the shellcode itself cannot use fixed memory addresses.
  23. 23. Timeline Image taken from the paper ‘Bypassing Browser Memory Protections’
  24. 24. Part iii – Vulnerability Context
  25. 25. The properties of a vulnerability  The context in which a particular vulnerability is found.  That specific context may allow attackers to develop a working exploit which bypasses all exploit mitigations implemented on the operating system.  “The exploit works because the 7 moons are aligned”
  26. 26. Properties of a vulnerability Vulnerability ASLR DEP SafeSEHSEHOP /GS The vulnerability may be in a context where the exploit mitigations are either ineffective to prevent its exploitation or circumvented in certain scenario.
  27. 27. Example: the ANI vulnerability  First public exploitable vulnerability on Windows Vista  Discovered by Alex Sotirov  Vulnerable function not protected by /GS  ASLR’s entropy too small, hence could be brute forced  DEP not yet implemented in Internet Explorer 7 at the time Vulnerability /GS ASLR DEP SafeSEH
  28. 28. Implications?  There will always be exploitable vulnerabilities.  Exploit mitigation mechanisms have an impact on how we search for vulnerabilities.  Old scoping method: find all inputs of an application and test them while hoping one will not be protected enough.  New scoping method: find all sections of an application which are not correctly protected by anti- exploitation mechanisms and try to find a bug in them.  No public technologies to perform that type of scoping yet
  29. 29. Implications?  Before Windows Vista, we could generate reliable exploits using automated tools because of the lack of certain anti-exploitation technologies by default.  Since Windows Vista, exploitation becomes vulnerability specific, hence automatically generating exploits is a lot harder.  Static source code analysis tools also need to be able to take into account anti-exploitation mechanisms.  Exploit mitigations also impact on bug fixing prioritization.  Hence the importance of knowing which sections of an application is less likely to be effectively protected or not.
  30. 30. Contexts or attack patterns that allow to bypass anti-exploitation mechanisms  Bypassing DEP:  Inject shellcode is Executable memory regions  Return into libc / returned oriented programming  Disable DEP manually on the system  NtProtectVirtualMemory()  Bypassing ASLR  Brute force  Memory spraying  Memory leaks  Requires a bug which leaks information about the memory layout (i.e. a memory address)
  31. 31. Contexts or attack patterns that allow to bypass anti-exploitation mechanisms  Bypassing SEHOP  Re-create a valid fake SEH chain (not applicable with the latest version of SEHOP in Windows 7)  Need to defeat ASLR first to perform that technique  Bypassing GS  Find instances of variables in the code that are not protected by GS  Use the SEH pointer overwrite technique  Need to bypass SafeSEH (and SEHOP)
  32. 32. The future of exploitation?  Applications known to offer contexts to bypass memory protections  Browsers and their plugins (i.e. Flash, Acrobat)  Applications known not to be protected by all memory protections  Kernel mode applications  Operating systems not as protected as Windows  Macintosh?  Mobiles?  Other kind of devices not protected with mitigations:  Routers, switches.
  33. 33. Part iv – Miscellaneous
  34. 34. Lifetime of an attack pattern: /GS & SEH Overwrite  /GS: Introduced in 2003  Bypass: overwrite the SEH handler.  Safe SEH: Introduced in Windows XP SP2 (August 24th, 2004)  Bypass: overwrite the SEH handler with a pointer to a module not protected by Safe SEH  SEHOP: Introduced in Windows Vista SP1 and Win Server 2008 but disabled by default  Safe SEH bypass technique still effective by default  SEHOP: Enhanced and enabled by default in Windows 7 (October 22e, 2009)  No bypass seen so far. The solution seems effective.
  35. 35. Lifetime of an attack pattern: /GS & SEH Overwrite  Techniques to bypass the mitigations were introduced in 2003.  An effective solution to prevent those attack patterns was deployed and enabled by default in 2009.  The SEHOP deployed in Win 7 has not been bypassed yet.  For about 6 years attackers were able to use that attack pattern to successfully exploit vulnerabilities.  And they still are millions of systems running older version of Windows. Those systems are still not protected.
  36. 36. Lifetime of an attack pattern: return oriented programming (ROP)  1997: Solar Designer published the first ret2libc exploit  Since numerous papers and tools have been published on the subject.  Used to bypass DEP.  We are un 2010 and no bulletproof exploit mitigations have been implemented against this known attack pattern.  Attackers need to defeat ASLR to apply that technique.  Lots of research has been done on ROP lately. As a result, we can probably assume we will see many more exploit using that technique in the near future.  Automated tools to generate part of the exploit etc.
  37. 37. Lifetime of an attack pattern: conclusion  Between the date researchers discover a new attack pattern which bypasses one or several exploit mitigations and the date a protection is implemented, attackers have several years to successfully compromise systems using the method.  Hence, maybe, the need for an independent security company to develop exploit mitigation tools is still relevant today?
  38. 38. Enhanced Mitigation Evaluation Toolkit (EMET)  Command line utility to deploy mitigations on applications that have been written before the mitigations were available or when the source code is not available.  XP, Vista, Windows 7, Windows Server 2003+  Supported mitigations:  DEP  SEHOP  Null page allocation  Heap spray allocation
  39. 39. Shellcode isn’t necessary a shell Authentication Submit banking form Verify amount of money Transfer money
  40. 40. Part vi – Conclusion
  41. 41. Conclusion  Exploitation on the Windows platform is considerably harder but memory corruption vulnerabilities are not yet dead.  How do we efficiently identify portions of code that provide an exploitable context?  Is there new yet unknown vulnerability classes which are not protected by anti-exploitation technologies?  The community is focused on researching how to bypass memory protections; maybe it would be good to be reactive and research on how to improve them.
  42. 42. Conclusion  It is going to be interesting to see Microsoft’s future mitigations against the latest exploitation techniques:  Researchers will probably come up with new exploitation methods  What will be the limitations of those new mitigations? Will we be able to turn them to our advantage and come up with new exploitation techniques? (i.e. see the latest research on the IE8 XSS filter)  Will exploitation mitigations ever reach a level of maturity where we can state that memory corruption vulnerabilities are over?
  43. 43. Question?
  44. 44. References  The ANI bug video: - Alex Sotirov  EMET: ouncing-the-release-of-the-enhanced-mitigation- evaluation-toolkit.aspx  Paper ‘Bypassing Browser Memory Protections’: - Mark Dowd, Alex Sotirov  Bypassing SEHOP:  There’s a party at ring0 and you’re invited:
  45. 45. Part v – Web related stuff The following content was presented at OWASP. Excluded from Auscert.
  46. 46. Reflected Cross-site scripting (XSS)  IIS6 XSS Filter + IE8 XSS Filter = END of reflected cross-site scripting vulnerabilities  Context of exploitation:  DOM Based XSS  Through know techniques.  Through browser bugs.  Reflected but injecting directly into javascript code  Ineffective against stored XSS
  47. 47. PHP Magic quotes  Attack mitigation against SQL injections that automatically escapes all inputted data  Contexts allowing bypass:  Injecting into an integer field  SELECT * FROM blah WHERE id = $id  Attacker can successfully exploit the vulnerability in this context by converting any needed string to hexadecimal  http://blah/page.php?id=-1 UNION SELECT LOAD_FILE(0x1234456) INTO OUTFILE(0x0432432435435)  Possible mitigation: develop a patch for MySQL to prevent the use of hexadecimal strings and by default forbid many of the casting methods
  48. 48. Stopping automated tools  Anti-spidering technology  Easy to create and implement  Would stop many automated scanners out there  Randomizing 404 responses  Do not return HTTP 404  Randomize the size and number of lines the page returns  Would stop many file and directory scanning tools  Both methods aren’t bullet proof but they do exactly what exploit mitigations do: stop known attack patterns.
  49. 49. Normalizing traffic  Http Parameter Pollution (HPP):  Search.jsp?q=Britney spears&q=Hackers kick ass  Implement scrubbing methods at the language engine level or at the http server level.  End of HPP  Prevent against HTTP header manipulation
  50. 50. Frameworks  Tomcat + Java + Spring + Hibernate  Default mitigations:  No stored or reflected cross-site scripting: all outputted data is escaped by default.  No SQL injection: use of prepared statements by default. Also easy to pick up any mistakes with some greps on the code.  Security classes and functions (i.e. authentication) provided by the framework.  Java is a language with strong types: cannot insert a string in an integer like with PHP.  Weaknesses:  Access-control bypasses / insecure object references  Know vulnerability in the MVC  Malicious file upload  No anti-scanning mitigations  Insecure configuration
  51. 51. Hardened by default  Malicious file upload vulnerability:  By default disable any methods and functions that may allow an application to execute commands on the server.  Getting popular in PHP (aka hardening php.ini)  Not as popular with Java which is well known to provide *features* allowing to upload *modules*:  Tomcat manager  Websphere
  52. 52. Web: conclusion  Web exploitation can be as context-dependant as binary exploitation  Web anti-exploitation mechanisms are not as mature as binary anti-exploitation  Too many technologies (web servers, database servers) and languages