1 / 25

Preventing Adobe Flash Exploitation

Preventing Adobe Flash Exploitation. Blitzableiter - a signature-less protection tool. Black Hat 2010 Felix 'FX' Lindner, Head of Recurity Labs. Motivation.

alphonse-meller
Télécharger la présentation

Preventing Adobe Flash Exploitation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Preventing Adobe Flash Exploitation Blitzableiter - a signature-less protection tool Black Hat 2010 Felix 'FX' Lindner, Head of Recurity Labs

  2. Motivation • Results from a project initiated in 2008 by the German Federal Office for Information Security showed Adobe Flash to be the weakest Rich Internet Application technology • Adobe Flash runtime unfixable (at least for a third party) • Traditional detection mechanisms (AV/IDS) fail • The constant surfacing of new attacks against Flash requires a defense approach that doesn’t depend on attack signatures • We didn’t want to build yet another AV • The goal still is to be done with it at some point in time, once and for all

  3. Agenda • Overview of Flash Attack Surface • Flash Infrastructure • Blitzableiter Implementation • Conclusion

  4. Agenda • Overview of Flash Attack Surface • About SWF • Flash Victims • Native Security Functionality of Adobe Flash • Flash Malware v.s. Anti-Virus • Flash Infrastructure • Blitzableiter Implementation • Conclusion

  5. About SWF • Flash files (SWF) is a container format for • Vector graphics data (shapes, morphing, gradients) • Pixel graphics formats (various JPEG, lossless bitmaps) • Fonts and text • Sound data (ADPCM, MP3, Nellymoser, Speex) • Video data (H.263, Screen Video, Screen Video V2, On2 Truemotion VP6) • Virtual machine byte code for the ActionScript Virtual Machines (AVM) • All data structures from file format version 3 until the current version 10 are still supported • The parser is completely written in unmanaged languages (C/C++)

  6. Flash Victims • End users • Flash player can be triggered by any web page • Direct code execution, DNS rebinding, CSRF… • 97% of web browsers report Flash installed • Site owners and Advertisement networks • Forced to accept pre-compiled content • Flash can change behavior after it’s accepted, or pull additional code from remote server • Some news sites like NYTimes.com, etc

  7. Flash Victims • End users • Flash player can be triggered by any web page • Direct code execution, DNS rebinding, CSRF… • 97% of web browsers report Flash installed • Site owners and Advertisement networks • Forced to accept pre-compiled content • Flash can change behavior after it’s accepted, or pull additional code from remote server • Some news sites like NYTimes.com, etc • Unfortunately, Flash Player is the problem!!!

  8. Native Security Functionality of Adobe Flash • Very limited settings within the Flash Player configuration page, using an actual Flash file • Camera and microphone access, local storage limits, hardware video acceleration, “older security system”, DRM licenses • Much more useful settings can only be made in mms.cfg, a local user specific configuration • AutoUpdateDisable, AllowUserLocalTrust, LocalFileLegacyAction, LegacyDomainMatching, ThirdPartyStorage, FileDownloadDisable, FileUploadDisable • There is no proof of origin for Flash files (i.e. no digital signatures)

  9. Flash Malware v.s. Anti-Virus • Flash malware is not very well detected by AV. • AV. software failed to detect when malware is uncompressed • Table. 1: Flash malware detection rate generated by Virustotal.com

  10. Agenda • Overview of Flash Attack Surface • Flash Infrastructure • SWF File Structure • ActionScript Virtual Machine • AVM 1 Weakness • Blitzableiter Implementation • Conclusion

  11. SWF File Structure • SWF can be compressed by zlib • Elements are called “Tags”, 91 tag types defined currently, split into two categories • Definition tag • Control tag • Fig. 1: File structure of SWF

  12. Tag examples Fig. 3: Example of control tag Fig. 2: Example of definition tag

  13. ActionScript Virtual Machine • Two stack virtual machines: AVM1 and AVM2, contained in Flash Player • AVM1 • Start from Flash 3 • Destine for ActionScript 1 and ActionScript 2 • 80% Flash files using AVM1, including YouTube • AVM2 • Introduced in Flash 9 • Destine for ActionScript 3 • ActionScript 3 is based on ECMA-262

  14. AVM 1 Weakness • Branch target are signed 16-bit offsets from current code block • Can jump into the middle of other instructions • Can jump outside the code block (e.g. into image) • Cannot have large “if” statements • Length filed is parsed even for instructions with defined argument sizes • Argument arrays contain their own length fields after the instruction length filed

  15. AVM 1 Weakness (cont.) • Order of code execution is non-deterministic • Depends on tag order and tag type • Depends on references to other Flash files • Depends on the condition set to execute • Depends on the visibility of the object (i.e. z-axis)

  16. Agenda • Overview of Flash Attack Surface • Flash Infrastructure • Blitzableiter Implementation • About Blitzableiter • Blitzableiter Flow • Conclusion

  17. About Blitzableiter • Written in C# with .NET CLR 2.0 • Binary executable or Firefox plugin in NoScript • OpenSource under GPL 3

  18. Blitzableiter Flow • Parse the original SWF file • Discard original SWF file • Verify inter-tag consistency and AVM byte code • Create a new “normalized” SWF file for the final consumer (e.g. the Flash Player)

  19. Blitzableiter Flow (cont.) Original SWF file Blizableiter New parsed SWF in memory Parser All type-length-value data structures are allocated in individual memory streams with space it declared Parser ensure that all content is used Parser only accepts well-documented SWF data structures, and it’s version-dependent

  20. Blitzableiter Flow (cont.) Original SWF file Blizableiter New parsed SWF in memory AVM1 Byte Code Verification & Modification Is the instruction legal in the declared SWF version? Is the declared instruction length correct and completely used? Does the instruction has exact number of argument specified? Does the code flow remain within the code block? Do all branches, try/catch/finally and all function declaration target addresses point to the beginning of an instruction? Do all instructions belong to one and only one function? For undetermined arguments, add some byte codes such that arguments are verified in runtime before the API is called. Verified SWF in memory

  21. Blitzableiter Flow (cont.) Original SWF file Blizableiter New parsed SWF in memory Flash Player Normalized SWF file if successful Verified SWF in memory It Works

  22. Agenda • Overview of Flash Attack Surface • Flash Infrastructure • Blitzableiter Implementation • Conclusion • Challenges • Conclusion

  23. Challenges • Some third party and proprietary formats without specification published would be filtered out • Some Flash obfuscation software used to protect intellectual property of Flash code result in AVM byte code that fails verification • AVM 2 • Capable of Just-In-Time compilation • Allows dynamic loading of additional byte code and emit in run time

  24. Conclusion • The looseness of Flash Player allows many malformed SWF files be executed • It’s signature-free protections using file normalization with managed language • For arguments cannot be determined, add run time verification • Attacker cannot guess structures and offsets after normalization

  25. The End

More Related