1581, 15/80 ȸ¿ø°¡ÀÔ  ·Î±×ÀΠ 
   err0r2
   http://javaphile.org
   ÇãÁ¢ÇÑ °¨È¸ - VI

http://www.hackerschool.org/HS_Boards/zboard.php?id=Free_Lectures&no=1199 [º¹»ç]


¿À´ÃÀº ±×³É ´Ì~¿ì~½º Çϳª¸¸ ±×³É ÆÛ¿À±â·Î Çß´Ù.

Ãâó:

  http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219


When PDFs Attack - Acrobat [Reader] 0-Day On the Loose

The Shadowserver Foundation has recently become aware of a very severe vulnerability in Adobe Acrobat affecting versions 8.x and 9 that is currently on the loose in the wild and being actively exploited. We are aware of several different variations of this attack, however, we were provided with a sample last week in which we were permitted to analyze and detail in this post. We want to make it clear that we did not discover this vulnerability and are only posting this information to make sure others are aware and can adequately protect themselves. All of our testing was done on Adobe Acrobat Reader 8.1.0, 8.1.1, 8.1.2, 8.1.3 (latest release of 8), and 9.0.0 (latest release of 9). We have not confirmed via testing that the exploit actually works on Adobe Acrobat (non-Reader) but believe that it will also affect it as well.

Right now we believe these files are only being used in a smaller set of targeted attacks. However, these types of attacks are frequently the most damaging and it is only a matter of time before this exploit ends up in every exploit pack on the Internet. As a result we are also not going to provide any specific details on how the exploit works despite the fact that information is known. We know several of the details on the internals thanks to a good friend of mine -- Matt Richard. He took a look at the file for us last week and provided the following:

The malicious PDF's in the wild exploit a vulnerability in a non-JavaScript function call. However, they do use some JavaScript to implement a heap spray for successful code execution. The malicious PDF's in the wild contain JavaScript that is used to fill the heap with shellcode. Since this exploit relies on both JavaScript and non-JavaScript components there are some potential reliability issues which has led to confusion over which platforms are affected.

Testing of the exploit with XP SP3 using Adobe Reader 8.1.1, 8.1.2, 8.1.3 and 9.0.0 shows that the vulnerability results in code execution on all of them. There may be cases where Adobe Reader crashes without code execution, especially on systems with more physical memory and faster processors. This is likely due to the race condition needed to populate the heap before certain data structures are parsed by Reader.

The exploit can be effectively mitigated by disabling JavaScript. In this scenario Adobe will still crash but the required heap spray will not occur and code execution is not possible. There may be a method for populating the heap with the necessary shellcode without JavaScript, however if such a technique exists I am not aware of it. As a general rule I like the idea of both disabling JavaScript in Adobe Reader and also flagging PDF documents containing JavaScript at perimeter devices.

In Matt and I's testing, we found that disabling JavaScript would definitely prevent the malware from being installed on the system. However, it would still result in the crash of the application. We would HIGHLY recommend that you DISABLE JAVASCRIPT in your Adobe Acrobat [Reader] products. You have the choice of small loss in functionality and a crash versus your systems being compromised and all your data being stolen. It should be an easy choice.

Disabling JavaScript is easy. This is how it can be done in Acrobat Reader:

Click: Edit -> Preferences -> JavaScript and uncheck Enable Acrobat JavaScript

We believe Adobe is aware of this issue and actively working to address it. However, we felt it was necessary to release this information to let people know how to mitigate against the attacks as they can be devastating. Right now multiple Antivirus companies detect this threat. We will update this post as we have more information that we can share on this.

A special thanks to the kind source that provided the file to us last week for analysis.

---

It has been pointed out to us that Symantec may have been protecting against this since February 12, 2009. We have not had it confirmed but believe they detect it as Trojan.Pidief.E which has a write-up here.
We have also been informed Trend Micro currently detects this threat as "TROJ_PIDIEF.IN".

=>Posted February 19, 2009, at 03:03 PM by Steven Adair

¹¹ ±×Àú ±×·¸´Ù´Â°Í...½Ã¸¸ÅÃèØ :Bloodhound.PDF.6

http://www.symantec.com/en/th/enterprise/security_response/writeup.jsp?docid=2009-021215-2608-99

ÇÊ¿äÇÏ½Ã¸é ¿¬¶ôÇϽñæ...

  Hit : 13882     Date : 2009/02/20 02:16



    
1301   bufffer over flow [BOF] test     ÇØÄ¿ Hades
10/24 39034
1300   c[1]     gohuns123
05/25 7686
1299   C ¾ð¤· ¤Ã goto(x,y)[4]     hackerÅ×µð
12/31 5926
1298   C ¾ð¾î óÀ½ ½ÃÀÛÇϽô ºÐµéÀ» À§ÇÑ °­ÁÂ[12]     kevin0960
04/17 9235
1297   C ¾ð¾î óÀ½ ½ÃÀÛÇϽô ºÐµéÀ» À§ÇÑ °­Á - 2     kevin0960
04/22 7153
1296   C ¾ð¾î Æ÷ÀÎÅÍ°¡ ¾î·Á¿ì½Ã´Ù°í¿ä[2]     smile_mut
04/27 6502
1295   C ¾ð¾î °­ÀÇ ¿äÀϱ¸Çϱâ C¾ð¾î ÇÁ·ÎÁ§Æ®[1]     kordokrip
06/21 39479
1294   C ¾ð¾î °øºÎÇϽôºРÂü°í ÀÚ·á[6]     ROK.AF
03/02 9913
1293   c ¾ð¾î º¸¾È ÄÚµù °¡À̵å ÀÔ´Ï´Ù.     oldlove7
12/11 9865
1292   C ¾ð¾î ½±°Ô ¹è¿ì´Â °÷ ¹ß°ß[11]     lsykoh2
01/17 6934
1291   C++ if else ÀÀ¿ë [2]     festal
09/24 8121
1290   c++ °­ÁÂ[7]     jhon55
08/12 12291
1289   C++¿¡¼­ Wave formatex ±¸Á¶Ã¼¸¦ ÀÌ¿ëÇÏ¿© »ç¿îµå ÆÄÀÏ Ãâ·Â ½Ã°£ ¾ò´Â ¹æ¹ý     kordokrip
06/21 6981
1288   ÇãÁ¢ ÆÁ Setuid ½±°Ô ã±â -_-;[3]     ttongfly
09/10 15002
1287   ÇãÁ¢ÇÑ °¨È¸ - I     err0r2
02/11 7904
1286   ÇãÁ¢ÇÑ °¨È¸ - II     err0r2
02/12 7999
1285   ÇãÁ¢ÇÑ °¨È¸ - III     err0r2
02/13 7673
1284   ÇãÁ¢ÇÑ °¨È¸ - IV[2]     err0r2
02/15 7045
1283   ÇãÁ¢ÇÑ °¨È¸ - V[2]     err0r2
02/19 7291
  ÇãÁ¢ÇÑ °¨È¸ - VI     err0r2
02/20 13881
[1]..[11][12][13][14] 15 [16][17][18][19][20]..[80]

Copyright 1999-2024 Zeroboard / skin by Hackerschool.org / Secure Patch by Hackerschool.org