Tuesday, November 30, 2010

cve-2010-4091 exploited ? – 0.2 – Adobe Reader 9.3.0

Starting from the malwaretracker sample (see my previous posts) seem that edx and ecx are set to some interesting values:

overwritten

Thursday, November 25, 2010

cve-2010-4091 exploited ? – 0.1

Trying to reversing the shell code contained within the PDF that seem exploit CVE-2010-4091, in according with the sample reported by MalwareTracker, it’s been founded the following URL:

http://212.117.168.89/ad/fi_16.php

image

From Robtex:

image

The URL above at this time is down or not more available. Did really exploited for retrieve malware from womens-puzzle.com ? :) .  Many Thanks to binjo for his support and tools.  For the PDF check my previous post: http://extraexploit.blogspot.com/2010/11/cve-2010-4091-exploited.html 

All this things continues to be weird and funny! (WOMENS-PUZZLE.COM :-) ).  IMPORTANT: The PDF reported is not sure that exploit, really, the CVE-2010-4091

Friday, November 19, 2010

cve-2010-4091 exploited ?

November 24,  2010 – Update:

Looking for other  exploiting attempts I found a Malwaretracker sample where the PDF seem spread via URL that contains:  filepdf.php@v=zday

image

The following analysis report the objects used within this PDF (that is different from the fulldisclosure PDF):

http://www.malwaretracker.com/pdfsearch.php?hash=0398e68507882a38a26a341058c94653&submit=Search


November 22 , 2010 – update:

Some interesting (and useful) notes about the original full disclosure PDF PoC published on full disclosure mailing list:

Who’s looking for eggs in your PDF?
http://labs.m86security.com/2010/11/whos-looking-for-eggs-in-your-pdf/

November 19, 2010:

This is my latest result. Seem that with a crafted PDF as explained by Haifei Li in his paper (see previous posts for reference), the code flow looks like could be hijacked. At least I have this impression from the debugger response as you can see in this screen shot:

exploited

feedback and suggestion are welcome. Some notes: this is only an attempt to try to understand better this issue.  My mistakes in this stage are very likely.

Thursday, November 11, 2010

cve-2010-4091 – printSeps - exploitation attempts

November 26, 2010 – update:
This is a very useful  presentation (from Immunity Sec) where is possible get some methods for approach the reversing of  Java script engine in Adobe Reader context:

Attacking Embedded Languages
http://www.immunitysec.com/downloads/ID_reCON_2008.odp

November 16, 2010 – update:
In previous post I didn’t report where is the place in the AcroRD32.dll where the memory corruption is triggered (as result of the use after free bug).  The following screen shot is the leak screen shot:

image

At first view, the AcroRd32.dll offset 0094450, seem a zone involved with Acro Heap Manager, so this could confirm some of my doubts for the question like “where to play whit this bug ?”. So, IMHO, this bug is due from the double handling mechanism of the heap. In other words what the OS heap management has previously freed may be that the Adobe Heap Manager try to free again with the result as show.  I hope to release a more detailed analysis as soon as possible.


November 11, 2010
In my previous post (http://extraexploit.blogspot.com/2010/11/full-disclosure-xplpdf-adober-reader-94.html)  it’s been followed  the timeline and what is called exposure time for this bug that seem have a bit strange history. After my initial analysis,  only few details has been released about. But after play a bit with this flaw I can confirm once of the latest and most clear comments fromVUPEN via Twitter:

exploiting the PDF printSeps was complicated. It involves allocating/freeing chained blocks before triggering the flaw

After this tweet I started to looking for more informations about. So IMHO a good support for “allocating/freeing before trigger” the flaw may be get from” heaplib” as well documented in

http://www.blackhat.com/presentations/bh-europe-07/Sotirov/Presentation/bh-eu-07-sotirov-apr19.pdf

Is possible fitting the heaplib.js for Adobe Reader and insert inside a crafted PDF for obtaining the heap handling ? For this goal code be usefull play with what is called Acro Managing Pool. A very interesting reference is from a Fortinet researcher:

http://www.fortiguard.com/papers/Adobe_Readers_Custom_Memory_Management_a_Heap_of_Trouble.pdf

The heaplib.js for Internet Explorer is here:
https://www.metasploit.com/redmine/projects/framework/repository/entry/lib/rex/exploitation/heaplib.js.b64

Anyway what I could say from my experience with this flaw is that the PDF posted on full disclosure seem leaks of something and using a debugger may lead you on the wrong way sometimes. Are only ideas which could be wrong as well right. Feedback are welcome.

Thursday, November 4, 2010

full disclosure xpl.pdf Adober Reader 9.4 poc - printSeps() - cve-2010-4091


November 26,2010 – Update:

Thank you, Mario, but our printSeps() is in another castle !
http://esec-lab.sogeti.com/dotclear/index.php?post/2010/11/26/Thank-you-Mario-but-our-printSeps%28%29-is-in-another-castle

November 22, 2010 – Update:

Who’s looking for eggs in your PDF?  (reported also in  cve-2010-4091 exploited ?)
http://labs.m86security.com/2010/11/whos-looking-for-eggs-in-your-pdf/

November 16, 2010 – Update:

Security updates available for Adobe Reader and Acrobat – ABSP10-28
http://www.adobe.com/support/security/bulletins/apsb10-28.html

November 9, 2010 – Update:

Adobe  PSIRT released - CVE-2010-4091
http://blogs.adobe.com/psirt/2010/11

US-CERT response:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4091

November 8, 2010 – Update 2:

VUPEN confirms the "remote code execution"
http://www.vupen.com/english/advisories/2010/2890
http://www.vupen.com/english/zerodays

November 8, 2010 – Update 1:

Some screenshots of my brief analysis for this bug.  The vtable where is referenced the PrintSeps() method:




 
 
 
 
 
 
 
 
 
 
 
 
 
the location where the Javascript code is being processed:
jscriptprocessed
 
Where Adobe Reader 9.4 crash after PrintSeps is processed:

















November 5, 2010 – Update:

emerging threats Snort sign

 http://permalink.gmane.org/gmane.comp.security.ids.snort.emerging-sigs/7437

eEye report as remote code execution

http://www.eeye.com/Resources/Security-Center/Research/Zero-Day-Tracker/2010/20101104

Adobe response:

http://blogs.adobe.com/psirt/2010/11/potential-issue-in-adobe-reader.html

November 4, 2010:
The vulnerable method seem: printSeps():

 
more info:

The original xpl.pdf is retrived via
http://seclists.org/fulldisclosure/2010/Nov/23

Xanda
http://twitter.xanda.org/

fuzzyd00r
http://fuzzyd00r.blogspot.com/2010/04/adobe-acrobat-javascript.html

PasteBIN
http://pastebin.com/h9GVyJhQ

Wednesday, November 3, 2010

CVE-2010-3962 - yet another Internet Explorer RCE

Update - November, 12 2010:
Amnesty International Hong Kong Website Injected With Latest Internet Explorer 0-day
http://community.websense.com/blogs/securitylabs/archive/2010/11/10/Amnesty-International-Hong-Kong-Website-Injected-With-Latest-Internet-Explorer-0_2D00_day-.aspx


Update - November, 5 2010:
CVE-2010-3962 - BindShell proof of concept:
http://www.offensive-security.com/0day/ie-0day.txt

Metasploit Module
https://www.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/windows/browser/ms10_xxx_ie_css_clip.rb

More on the IE 0-day - Hupigon Joins The Party
http://blog.fireeye.com/research/2010/11/ie-0-day-hupigon-joins-the-party.html



Update - November, 4 2010:
the memory corruption proof of concept is (place the following code as is within a HTML file):





(From: http://twitter.com/yuange1975/status/29593742541)

Microsoft Internet Explorer CSS "clip" Attribute Memory Corruption
http://www.vupen.com/english/advisories/2010/2880


November, 3 2010:
New IE 0-Day used in Targeted Attacks
http://www.symantec.com/connect/blogs/new-ie-0-day-used-targeted-attacks

The issue seem related to a "use after free" bug when are parsed some CSS tags sequence.
Once of the implicated malware seem a Backdoor.Pirpi variant.

Other links:
Incidents.org
http://isc.sans.edu/diary.html?storyid=9874

Microsoft Security Advisory 2458511 (workaround included)
http://www.microsoft.com/technet/security/advisory/2458511.mspx