Adobe 0-day in the wild - again

Published: 2009-12-15
Last Updated: 2009-12-16 20:15:36 UTC
by Johannes Ullrich (Version: 3)
10 comment(s)

Update2:  : It looks like Adobe will not be releasing an update to resolve this issue until Jan 12!  Find their full advisory with the release date here ==> http://www.adobe.com/support/security/advisories/apsa09-07.html

Handler on Duty: Rob VandenBrink

------------------------------------------------

Update1:  One of the samples that we had access shows the following behavior that could help you to identify infections in your network/system:

The exploit has the executable included: AdobeUpdate.exe - Size 9.356k (hash 069175846447506b3811632535395bc3 ).

This executable will download another file called ab.exe (and save it as winver32.exe on C:windows folder). You may also check your logs for the website hxxp://foruminspace.com . This file is hosted there.

The current sample has the following specs: Size 386,016k and hash 686738eb5bb8027c524303751117e8a9 .

-------------------------------------------------

Handler on Duty: Pedro Bueno (pbueno //&&// isc. sans. org)

Twitter: twitter.com/besecure

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

It's not ground hog day, but it surely feels like it. The Shadowserver Foundation [1] is reporting about spotting another Adobe 0-day in the wild

Adobe acknowledged the issue in a PSIRT post [2].

The quick summary: The is currently no patch available and commonly used anti-virus products appear to be mostly missing it. The bug requires JavaScript. Turning off JavaScript support appears to be your best defense. I could recommend that you don't open any malicious PDFs. But it would probably be as useful to go and hide in a cave until all Adobe bugs got fixed.

Please let us know if you find any malicious PDFs like this, and let the Adobe PSIRT know as well.

[1] http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20091214

[2] http://blogs.adobe.com/psirt/2009/12/new_adobe_reader_and_acrobat_v.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: 0day adobe pdf
10 comment(s)

Comments

partial analysis of the sploit:

http://extraexploit.blogspot.com/search/label/CVE-2009-4324

Ben K

Dec 15th 2009
1 decade ago

Registry keys to disable javascript:

http://insecureweb.com/javascript/secure-yourselffrom-the-recent-pdf-exploits-by-disabling-javascript/

CE

Dec 15th 2009
1 decade ago

I've always loved how Adobe claims that Reader's scripting is enabled by default, due to claims that "enterprise customers require it".

In hindsight after working yet another policy to kill scripting, I've decided that it can't be that these "enterprise customers" are concerned about scripting being default-disabled on THEIR machines, because they could simply apply a policy to turn it back on, etc. No, they must want scripting enabled on the giant pile of machines they don't own, and have no authority over. You know, the machines YOU own.

That strikes me as downright unethical by Adobe, and a flat out offensive abuse of our time, forcing us to repeatedly mitigate it. It's no different than spam - we absorb the cost of a feature we explicitly do not want, so that some strange "enterprise customer" can send Gramma a PDF laced with arbitrary executables.

/sigh

Steven

Dec 15th 2009
1 decade ago

Adobe Flash? Adobe Photoshop? Adobe Shockwave?
A no! Adobe Reader and Acrobat!

Why not just name the affected app in the title, in stead of using only "Adobe" every time?

Kender

Dec 15th 2009
1 decade ago

It's also important to note that the filename ab.exe is a valid Apache file (Apache Benchmark). Not sure what, if any impact there would be to blocking this entirely, but a bit of caution for those who may be using Apache. Winver32.exe has no valid use that I can find, so block away...

Lee

Dec 15th 2009
1 decade ago

Interestingly ab.exe (md5=686738eb5bb8027c524303751117e8a9)has an attached, albeit invalid, digital signature supposedly issued to Microsoft by "Root Agency" (also included), valid from 2009-06-09 2040-01-01. Both certificates use the md5RSH algorithm.

The "Root Agency" root certificate's serial number is "06 37 6c 00 aa 00 64 8a 11 cf b8 d4 aa 5c 35 f4". A little googling shows that the perps may have used info from http://www.grimes.demon.co.uk/workshops/secWSThirteen.htm for creating their malware.

Bitwiper

Dec 15th 2009
1 decade ago

I agree with Kender, the overuse of the term Adobe is annoying. They do have more that one product...

---

"I could recommend that you don't open any malicious PDFs. But it would probably be as useful to go and hide in a cave until all Adobe bugs got fixed."

LOL!

joeblow

Dec 15th 2009
1 decade ago

This is now is the latest trunk of Metasploit, just thought you'd wanna know. Check HDM's Twitter feed.

xyberpix

Dec 16th 2009
1 decade ago

Nothing to worry about. It doesn't execute code in Acrobat 9.2, Acrobat 9.2 have DEP enabled by default and you'll get online Data Execution Prevention dialog, shell code never gets executed. Older versions of Acrobat 9.2 is not important. Because they was already vulnerable to other exploits, like recent U3D exploit. So only important version is 9.2 and this exploit doesn't work on 9.2 because of DEP. So simply, don't worry.

JavaGuru

Dec 16th 2009
1 decade ago

You are partially correct about DEP: With a default XP/Vista/7 install and Acrobat 9.2 DEP will be enabled when the application loads, which can prevent attacks like this. This happens because the OS is set to OptIn mode and the program is compiled with the DEP flag. The far more serious risk comes from Acrobat being invoked as a browser plugin in a drive-by attack. When running as a browser plugin, DEP status is based off if the invoking application (browser) has DEP enabled. In IE7, the DEP flag is not compiled in the binary and you are vulnerable to this. IE8 is a little better, where its binary is compiled with the flag. HOWEVER, if there is a single plugin running in that browser session that does not have the flag, it will be disabled.

So you should be worried. The only surefire way to mitigate against this is to change to OptOut mode which takes a good bit of application compatibility testing.

Infractal

Dec 16th 2009
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives