Flash player related vulnerabilities have been notorious in their susceptibility to a vast range of attacks over time. When performing an offensive engagement, whether it’s through consultancy, or through external responsible disclosure programs, it is highly recommended that analysis of any Shockwave Flash (SWF) file be performed. While many haven’t explored such an attack path, this is a widely known issue.
During my brief period as a bounty hunter, I had identified SWF related vulnerabilities, within a multiplex of organizations, as well as high profile government entities, including that of; Police agencies, NASA, NATO, Australian Signals Directorate, US Army, US Airforce, US Navy and more.
As opposed to deep diving into flash exploitation and the various attack vectors. This article will be focusing on a more generic overview, prior to presenting my own findings, as a reminder as to how Shockwave Flash (SWF) files can pose a threat, their capabilities and the potential attack path associated with the insecure variations being hosted and exposed to the public domain.
SWF files are created through ActionScript syntax, which, is very similar to JavaScript, as both conform to the ECMA-based syntax. Like any other language, failure to properly validate and sanitize user inputs, can leave the segment vulnerable to various attacks. Furthermore, ActionScript itself contains vulnerabilities associated with it, this includes methods rendered ‘unsafe’, such as, but not limited to:
externalInterface.call(); getURL(), loadVariables(), navigateToURL(), loadMovieVar(), loadMovieNum(),LoadVars.load, LoadVars.send, XML.load ( ‘url’ ), XML.sendAndLoad ( ‘url’ ), LoadVars.load ( ‘url’ ), LoadVars.send ( ‘url’ ), flash.external.ExternalInterface.call(_root.callback), externalInterface.addCallback, AddDLL, etc..