1. technology and computing
2. computer security
3. antivirus and malware

Hacking The World With Flash:
Analyzing Vulnerabilities in Flash and the Risk of Exploitation
OWASP 29/2008
Paul Craig
Security-Assessment.com
© 2007 Security-Assessment.com

Who Am I?
 Paul Craig, Principal Security Consultant - Security-Assessment.com
 Author, hacker, active security researcher.

My Role
 Application Penetration Tester
 “I break the crack-headed ideas of developers..”

Comments, Questions, Feedback?
 Email: [email protected]
© 2007 Security-Assessment.com
Overview
 “Wow, Macromedia/Adobe Flash is everywhere on the internet!”
 YouTube, FaceBook, MySpace, CNN, Ebay, etc
 I Wonder, do internet users implicitly trust Flash content?
 The Litmus Test: My Wife, Kim.
 If I sent you a link to funnygame.exe, would you run it? “Nope.”
 How about funnygame.swf “I would probably open that”
 Flash is considered harmless, “It’s a funny game or joke”
 My Question:
 What are the incurred risks of running Flash content?
 How easily can Flash be used as an attack vector?
 Probability of getting pwned through a malicious SWF??
© 2007 Security-Assessment.com
Who Why How What of Flash
 Everything you wanted to know about Flash:
 Originally developed by Macromedia in early 2000’s.
 Macromedia was purchased by Adobe in 2005 ($3.4 billion!)
 Flash logic is developed in ActionScript
 Originally based on ECMAScript/JavaScript.
 ActionScript API is segregated into two streams.
 Web Flash Content:
 ActionScript executed by a browser plug-in/ActiveX control.
 Reduced functionality API, no access no host functionality.
 Standalone Flash:
 Compiled PE executables with embedded ActionScript player
 .SWF played from local flash player.
 Larger more complete API, access to host functionality.
© 2007 Security-Assessment.com
Who Why How What of Flash
 ActionScript was developed from a feature in Flash 4, 7 years ago.
 Flash 4 ‘Actions’ (Macros) expanded into ActionScript v1 in Flash 5.
 JavaScript like language with simple functionality.
 Un-enforced variable type system.
 Simple API for graphical manipulation.
 Prototype-oriented programming (No class support).
 Only 60% of API documented.
 ActionScript v2, 2003-2006
 Flash is being used for complex applications!
 Developers demanded more functionality.
 Compile-time type checking implemented, strict variable typing.
 Object-oriented programming support.
 Flash begins to appear ‘everywhere’
© 2007 Security-Assessment.com
Who Why How What of Flash
 ActionScript v3, 2006-Today
 Compile-time and runtime type validation
 Support for packages, namespaces and regular expressions.
 JIT compilation for new Flash Virtual Machine (AMV2)
 Binary sockets (Connect to a port, send/retrieve data)
 10% of API is still undocumented!
 ActionScript has matured into a flexible/powerful language.
 Supported by 850 million internet connected desktops.
 Cross-platform (Windows, OSX, Linux, HP-UX, PPC)
 “I would probably open that”
 “I probally shouldn’t, aye”
© 2007 Security-Assessment.com
Who Why How What of Flash
 Flash is a Powerful Attack Vector.
 850 million devices which support a language (ActionScript)
 Language first developed by Macromedia, and now Adobe.
 Vast history of Adobe/Macromedia security issues.
 Adobe Acrobat exploit anyone?
 ActionScript is complex.
 Grown immensely, very quickly.
 Quickly implemented features tend to contain bugs, exploits.
 Do Adobe follow a decent secure coding methodology?
 Adobe make apps like Photoshop do they take internet security
seriously?
 Flash Plug-in is Critical Browser Infrastructure.
 One zero day in Flash, 850 million exploitable devices.
© 2007 Security-Assessment.com
Exploits in Flash
 Golden Rules of Security:
 #1 – Software Developers Always Make Mistakes.
 #2 – Mistakes Get Exploited.
 #3 – Developers tend to make the SAME mistake more than once.
 #4 – See #1
 A History of Flash Exploits (2001-2008)
 Look for common trends in Flash exploits over the last 7 years.
 Predict the future of Flash security, what will 2008 bring?
 Likelihood of malicious Flash content.
 Find new vulnerabilities in Flash.
 Same bug, different section of Flash.
© 2007 Security-Assessment.com
Exploits in Flash
 2002: First Major Flash Security Advisory’s
 Standalone Macromedia Flash Player 5.0 allows remote attackers
to save arbitrary files and programs via a .SWF file containing the
undocumented "save" FSCommand. (CVE-2002-0476)
 Standalone Macromedia Flash Player 5.0 before 5,0,30,2 allows
remote attackers to execute arbitrary programs via a .SWF file
containing the "exec" FSCommand. (CVE-2002-0477)
 Undocumented API functionality to write, or execute a file.
 FSCommand("exec","rundll\tuser.exe,exitwindows");
 FSCommand("save",“C:\\filename.txt")
 FSCommand function only present in the standalone player API.
 Web browser unaffected.
© 2007 Security-Assessment.com
Exploits in Flash
 Flash ActiveX v6.0.23 Parameter Stack Overflow (CVE-2002-0605)
 Long ‘movie’ tag parameter.
<param name=movie value=“AAAAAAAAAAAAAAAAAAAA....">
 Heap Overflow in malformed ‘length’ SWF header. (CVE-2002-0846)
 SWF header contains a ‘length’ value of the .SWF file.
 Define length shorter than the .SWF file, Malloc() overflow.
 User supplied value un-validated and used directly in memory
allocation!
 Multiple overflows Through Malformed SWF Headers (CVE-20021382)
 Three SWF header values vulnerable to memory corruption.
 Same bug, different variable, three months later.
 Flash appears to rely on user supplied values for memory length
calculations.
© 2007 Security-Assessment.com
Exploits in Flash
 Bypass Same Domain Policy (CVE-2002-1467)
 Read arbitrary files from disk using Flash.
 Flash security prohibits .SWF content from one site, accessing
content from another.
 Flash will follow a 302 HTTP redirect to file://
 "file://" base in a web document
 Flash Denial of Service (CVE-2002-1625)
 Flash Player 6 never terminates a connection to a remote
website when using.
 loadMovie()
 loadSound ()
 First Flash DOS tool. loadMovie(“http://www.blah.com”) Loop.
 Dumb mistakes…
© 2007 Security-Assessment.com
Exploits in Flash
 2003: First Flash Cross-Site Scripting Bug
 XSS vulnerability in Macromedia Flash ad user tracking capability
 Allows remote attackers to insert arbitrary Javascript via the
ClickTAG field.
 ClickTAG used to notify a website prior to Flash execution.
 http://www.example.com/victim.swf?clickTag=http://adnetwork.com/tracking?ex
ample.com
 http://www.example.com/victim.swf?clickTag=javascript:alert('aaa');
 Flash developers appear to be unaware of Cross Site Scripting
 Basic XSS attack vector, nothing fancy here..
 Quick pre-release code analysis would have found this.
 Or a secure coding methodology…
© 2007 Security-Assessment.com
Exploits in Flash
 Flash v6 ActiveX Malformed SWF Header (CVE-2005-2628)
 Malformed SWF header with a modified frame type identifier.
 Flash still fails to validate SWF file format.
 Now 3 years after original .SWF file format bug found.
 Multiple unspecified vulnerabilities in Adobe Flash Player 8.0.22.0
(CVE-2006-0024)
 ‘Remote attackers able to execute arbitrary code via a specially
crafted SWF file.’.. And again..
 Stack overflow in Adobe Flash Player 8.0.24.0 and earlier (CVE2006-3311)
 Execute arbitrary code via a long, dynamically created string in a
SWF movie.
 Stack overflow in the ActionScript 2 API.
© 2007 Security-Assessment.com
Exploits in Flash
 Malformed SWF File in Flash 8.0.24 (CVE-2006-3587)
 Malformed .SWF file causes memory access violations.
 More malformed flash..
 Malformed SWF file vulnerability in Flash 8.0.24.0 (CVE-2006-3588)
 Allows remote attackers to cause a browser crash via a
malformed, compressed .SWF file.
 Flash ActiveX Flash8b.ocx Browse Crash
 Long string in the Flash8b.AllowScriptAccess method.
 Second Flash ActiveX method to contain a stack overflow.
© 2007 Security-Assessment.com
Exploits in Flash
 CRLF injection vulnerability in Flash Player 9.0.16(CVE-2006-5330)
 Remote attackers can modify HTTP headers of client requests
and conduct HTTP Request Splitting attacks via CRLF injection in
ActionScript functions.
 XML.addRequestHeader(“aa%0D%0AFoo: bar”) ; Adds header Foo: bar
 XML.contentType(“aa%0D%0AFoo: bar”); Adds header Foo: bar
 Flash does not validate user supplied content for CRLF.
 Flash does not have any special character blacklist
 Special chars and binary data are often accepted.
 Malformed SWF File (CVE-2007-0071) Adobe Flash Player 9.0.115.0
 Allows remote attackers to execute arbitrary code via unknown
vectors related to "input validation errors.“
 Another SWF with a modified header value.
© 2007 Security-Assessment.com
Exploits in Flash
 Insufficient Input Validation Allows CSRF (CVE-2007-3457)
 Flash insufficiently validates HTTP Referrer headers for CRLF.
(AGAIN!)
 Allow remote attackers to conduct a CSRF attack via a crafted
SWF file.
 2nd CRLF bug, 2nd HTTP Referrer bug!
 Flash Player 9.0.48 HTTP Request Splitting Attack (CVE-2007-6245)
 Remote attackers can modify HTTP headers for client requests
and conduct HTTP Request Splitting attacks.
 3rd CRLF bug, 3rd Header bug.
 Flash Player Malformed SWF File (CVE-2007-6019)
 Improper object instantiation allows remote code execution.
 Modified DeclareFunction2 ActionScript tag.
 Access an object before it was properly instantiated.
© 2007 Security-Assessment.com
Exploits in Flash
 Multiple Cross Site Scripting Vulnerabilities in Flash ActiveX 9
 Remote attackers can inject arbitrary web script or HTML via:
 navigateToURL(), asFunction()
 NavigateToURL, takes two arguments, URL, browser frame.
 NavigateToURL accepts javascript: URI’s and arbitrary browser
frames.
 JavaScript executes in security context of named frame!
 Should execute in the security context of the page that
embedded the SWF!
 Evil.swf advert located on myadverts.co.nz is served on
mybank.co.nz
 JavaScript within evil.swf can execute in the context of
MyBank.co.nz
 All your money is belong to me?
© 2007 Security-Assessment.com
Exploits in Flash
 Interaction Error Between Adobe Flash and UPnP Services (CVE2008-1654)
 Flash can be used to send SOAP XML requests to arbitrary
addresses, including internal addresses. 
 How about reconfiguring your modem, using SOAP over unauthenticated UPnP functionality?
 Example: http://www.gnucitizen.org/blog/hacking-the-interwebs/
 “Exploiting the BT Home Hub with Flash”
 Reconfiguring the BT Home hub primary DNS server remotely
through the Flash player, over UPnP.
 2Wire Modem DDOS Virus
 Reconfigure modem to send 10,000 ‘test’ pings to www.cnn.com
 Flash lacks cohesive security ‘zones’ and network sandboxing.
© 2007 Security-Assessment.com
Exploits in Flash
 Mark Dowd – Weaponised Flash NULL Pointer Attack.
 25 page paper on exploiting Flash (worth reading, if your into it)
 http://documents.iss.net/whitepapers/IBM_XForce_WP_final.pdf
 ‘The Inhuman Flash Exploit’
 Un-validated user supplied value used as memory allocation size.
 NULL pointer returned when allocation size is greater than 2gig.
 Returned value + user supplied offset used in memory write.
 Append malicious ActionScript byte code to valid Flash byte
code.
 Bypass internal Flash verifier.
 Native code execution inside the ActionScript VM.
 Internet Explorer, FireFox, Vista, XP = owned.
© 2007 Security-Assessment.com
Statistical Analysis of Flash
 Brief Highlights of Flash Security Advisories.
 Too many advisories to detail each one.
 54 advisories since 2001
 2003-2006 ActionScript 2
 2006-Today ActionScript 3
 More Functionality = More Exploits
© 2007 Security-Assessment.com
Statistical Analysis of Flash
 Most Common Bugs?
 File Format Validation
= Malformed Flash Files
 Browser Input Validation = XSS, CSRF, etc
 ActionScript API
= Native Flash Functionality
 SandBox Violation
= Escaping The Flash SandBox
© 2007 Security-Assessment.com
Statistical Analysis of Flash
 How Many Of Those Bugs Can Be Used To Execute Code?
 48% of Flash vulnerabilities have been exploited to gain code
execution!
 Weaponised Flash exploits not uncommon.
 Flash is not compiled with ASLR /DYNAMICBASE support.
© 2007 Security-Assessment.com
Exploits In Flash
 Common trends:
 Flash has poor SWF file format validation.
 User supplied values frequently used in memory calculations.
 Majority of vulnerabilities stem from file format validation bugs.
 Malicious Flash is most likely to be ‘malformed’.
 Adobe/Macromedia have a poor Security Development LifeCycle.
 Flash contains basic vulnerabilities, XSS, CRLF, Stack Overflows
 Vulnerabilities repeat themselves, often! Adobe do not learn.
 ActionScript API is being used natively as an attack vector.
 Flash security sandbox has been escaped three times!
 Flash ActiveX plug-in has the most issues.
 Flash security flaws have increased drastically.
 Almost half of vulnerabilities allow code execution!
© 2007 Security-Assessment.com
Exploits In Flash
 Flash ActiveX Plug-in has the most issues.
 Twice as many as the FireFox plugin.
 Flash Security Flaws have Increased Drastically.
 Almost half of vulnerabilities allow code execution!
 New method of native Flash VM code execution (Mark Dowd’s)
 2008?
 ActionScript 4 is likely 2 years away (Based on past history)
 Flash will grow, more functionality, bigger API.
 Competing with Silverlight (Microsoft’s Flash)
 Expect more Flash bugs.
© 2007 Security-Assessment.com
Exploits In Flash
 Possible Exploitation Scenario.
 Evil Hacker finds .SWF file format validation bug.
 Stack overflow, code execution.
 The Exploit:
 Legitimate Flash ‘advert’ created with exploit code.
 Exploit only triggered if(date > two weeks time)
 Evil Hacker buys $250 of advertising for malicious SWF file.
 You:
 Monday morning, you visit xyznews.co.nz, Flash anner adverts.
 Today is > two weeks since campaign launched.
 Exploit code is served from Flash advert, remote code exec.
 Everything looks normal, nothing crashes, but your owned.
 Case of the Monday’s?
© 2007 Security-Assessment.com
Exploits In Flash
 Recommendations:
 Keep Flash up to date, updates fix critical bugs.
 Disable Flash on critical systems.
 Implement browser virtualisation.
 Risk mitigation.
 FireFox/IE inside VMWare.
 Be weary of arbitrary Flash content.
 Flash Virus/Worm is just a matter of time.
© 2007 Security-Assessment.com