BlackHatEU : Defending the Poor
By Felix FX Lindner (Twitter: @41414141, fx@recurity-lab.com)
Image from http://de.wikipedia.org/wiki/Blitzableiter
Felix’s talk is about defending against Flash based web application exploits
This talk is about a tool he developed called “Blitzableiter” (Lightning rod) can be found at http://blitzableiter.recurity.com/. Felix is very much looking for feedback.
Felix has been playing offense for quite some time, but is now playing defense, which he said turns out to be harder then offense.
The motivation for Felix’ work comes form the German government agency BSI who found out that Adobe Flash is way behind the security curve in comparison to other technology.
Rich internet Applications platforms are very persistent:
Over 90% of the broswers have Flash, about 50% have SilverLight or Moonlight and about 75% has Java.
“The problem with Flash is that it won’t go away”, FX said. In an deal world Flash code runs into a sandbox that shields the code from your operating system. “If this worked, I wouldn’t be standing here”.
One of the problems of Flash is that there is no support for “proof or origin”. You cannot digitally sign a Flash file and only execute Flash files from certain authors.
Flash has quite a number of security vulnerabilities in itself, but it also a useful vehicle to deploy other attacks, as Dan Kaminsky showed with his DNS rebinding attack. But there are far more examples like browser redirection, clickjacking, UPNP snd CSRF attacks, etc.
There are three general Flash malware classes:
1. Downloaders – Download malware onto the user PC
2. Binary Exploits – Targeting the Flash player directly
3. Web Attack Vehicle – Using Flash to launch non-flash attacks
Flash Malware is poorly detected by Anti-Virus. 40-70% detection on VirusTotal.com. Oddly enough detection rates drop when the Flash is decompressed, so it seems that detection is based on pattern detection in the compressed files, which can very easily be evaded.
Flash file format is complex and its interpretation may vary depending on the version of the specification. Currently version 3 to version 10 of the file format is supported and in active use.
There is actually not one, but two Flash virtual machines.80%-90% of the Flash objects on the Internet use the older AVM1. The AVM’s have to deal with the challenge of taking into account the file version of the Flash object to “correctly” interpret the code passed to it.
About the defense approach
The defense approach wanted to protect against two scenarios:
• Malformed files
• Well formed malicious files that abuse the API
Binding the player or rewriting the player is not an option. So they have chosen a different approach. Normalization of the Flash file handed to the player.
The tool called “Blitzableiter” which means lightning rod and turns “Malicious Lightning into harmless Flash”
Blitzableiter is a Flash parser written in C# that normalizes Flash before feeding in to the Flash player.
At the obvious cost of some memory and CPU cycles Blitzableiter parses and validates the code Flash code and removes any undocumented and known malicious constructions from a Flash file.
Blitzableiter also prevents API abuse, but it is virtually impossible to do up-front anlysis of what a Flash file does before passing it to the Flash player. In stead Blitzableiter adds code to API calls made from the flash to enforce basic security principles like “same origin policy”.
The tool is currently not free of problems, e.g. running the tool in a browser is still not recommended because graphical computations are very expensive.
Every talk of FX about this subject is accompanied by a development release.
Please try the tool and report back issues.