Google researcher calls for Flash flush
10,000 sites need scrubbing (or more)
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
A Google researcher is advising that security professionals rewrite code associated with Adobe Flash content two weeks after warning that buggy files can be exploited by attackers to gain complete control over transactions on websites belonging to banks, government agencies and other trusted organizations.
The security bug resides in SWF files created by most of the most common programs for generating the ubiquitous Flash applets that animate sites across the web. Vulnerable content opens websites up to cross-site scripting (XSS) exploits that allow an attacker to perform any action available to a user of the targeted website. Criminals could use it to pilfer a users' account details or perform withdrawals on behalf of a customer.
Adobe, Autodemo, TechSmith and InfoSoft have updated their content generation products so they no longer produce buggy SWF files, according to this post from Rich Cannings, a senior information security engineer at Google who helped discover the vulnerability. He advised security professionals to remove vulnerable SWF files from websites and regenerate them following the manufacturers' advice.
Cannings recommended security pros take other steps. They include serving automatically generated SWF files from numbered IP addresses or from domains that are separate from trusted sites that contain sensitive cookies or other credentials that could be used in phishing attacks. Or security people may opt to move or remove all third-party generated SWF files entirely, he said.
"If there's an issue on a bank, the impact of an XSS is pretty large," said Cannings. In other words, it's a huge amount of work, but well worth it for trusted sites that want to remain that way.
Security pros and Flash authors may also want to use Stafano Di Paola's SWFIntruder to check for vulnerabilities in their content.
When we first reported the Flash vulnerability two weeks ago, some Reg readers complained the article didn't detail exactly how the vulnerability worked. Now that patches are available, Cannings is willing to say a bit more.
Flash files produced by Adobe DreamWeaver contain a "skinName" parameter that can be exploited to force victims to load arbitrary URLs that include the "asfunction" protocol handler. SWF files generated with Adobe Acrobat Connect don't properly validate the "baseurl" parameter, allowing script injection. Content produced by TechSmith Camtasia contain a "csPreloader" parameter that loads an arbitrary flash file.
The vulnerability is documented in the book Hacking Exposed Web 2.0: Web 2.0 Security Secrets and Solutions, which is hitting store shelves now. In addition to Cannings, it was written by Himanshu Dwivedi, Zane Lackey, Chris Clark and Alex Stamos of iSEC Partners. It is published by The McGraw-Hill Companies.
The buggy Flash files are known to be contained on tens of thousands of websites, many belonging to banks, government agencies and major corporations, according to the authors, who relied on Google searches for their estimate. The actual number of sites could be in the hundreds of thousands because vulnerable files don't always turn up in web searches, they said. ®
COMMENTS
Stop using flash.
There are sites like CNET.com that are so full of Flash based ads that the page is impossible to read. They have full motion videos with sound that load automatically, and if you want to scroll anywhere you have to manually turn them off first.
These guys wouldn't dream of having imbedded MIDI files playing tunes and animated GIF files everywhere, like some Geocities template page about cute kittens from deepest cyburbia.
They do it with Flash and that's somehow more sophisticated.
I use Firefox and Flashblock and don't visit CNET very often.
Bugs IN the file?
Aren't the Flash files themselves the bugs?
Let me see if I can explain
I think you avoid flash fullstop. :)
It seems to work this way:
Site bankinc.compromised has a flash applet on the site which is vulnerable.
You visit the bank and start a logged in session, which is controlled by a cookie only bankinc.compromised can access.
You get bored and go off to evil.comdom which whilst displaying a number of interesting pictures is also trying to load flash objects in the background from various sites with an ill crafted skinName paramater in them. This will allow
code to be injected and hence control the flash applet running on your browser which comes from bankinc.compromise.
They get lucky and the code they inject requests all the cookies on the bank site you are still logged in to the bank. And the bank cookies are now available via the compromised flash. The code also communicates those cookies back to evil.condom thru your browser.
Once evil.condom operator has your cookie, they could hijack your bank session.
It is a cross site attack and they could do more beyond just taking the cookies, but the cookies are the obvious one, and you would hope they checked the IP did not change mid session. Theoretically if the flash was on the make payments page they could automate a payment with it.
Who inserts code where? bad guy calls flash from bank using a skinName param which allow arbitrary to code to run in the bank's flash.
What exactly will I have to do to expose myself to danger? Allow flash to run and use a trusted site that has flash anywhere on the domain.
Is the trick ... ? No - bad site calls the bank flash - like you embed a site in a site, or snaffle an image.
Where is the injection, is javascript to blame? No, javascript is not to blame the flash html object is if you must blame something - but really it is flash.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
