Microsoft Patch Tuesday April 2010 Pre-Release

Published: 2010-04-08
Last Updated: 2010-04-08 23:41:28 UTC
by Guy Bruneau (Version: 1)
0 comment(s)

Microsoft announced earlier today that they will be releasing a total of 11 bulletins (5 critical, 5 important, 1 moderate). If exploited, eight of the bulletins could allow for remote code execution. More details available here.


Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org

0 comment(s)

Fyodor nmap author would like your help on two things.

Published: 2010-04-08
Last Updated: 2010-04-08 19:38:31 UTC
by donald smith (Version: 1)
0 comment(s)

First the Nmap Project was once again accepted for the Google
Summer of Code program, so he will have full time coding help this
summer!  SoC previously brought them the Nmap Scripting Engine, Zenmap,
Ncat, 2nd generation OS detection, and great developers such as David
Fifield, Doug Hoyte, and Patrick Donnelly.  But one of their biggest
challenges is getting the word out.  They won't get great applicants if
they don't know about the program.  So if you know any college/grad
students (or are one) who might be interested, please point them to ASAP.  They gain valuable experience writing code
used by millions of people and even earn a $5,000 stipend!  But the
application deadline is THIS FRIDAY at NOON U.S. Pacific Time (that is
19:00 UTC).  Our project ideas are listed at

He is also pleased to announce the 2010 Nmap/Sectools Survey! He
previously ran this survey in 2000, 2003, and 2006, and it helped
guide Nmap development as well as sharing our collective wisdom
through  He had 3,243 responses in 2006 and is
trying to reach 5,000 this year.  And this year he has upped the ante
by offering prizes!  So please take this quick survey, and in return
they will build you a better Nmap and a new and improved Sectools.Org:

0 comment(s)

Continuing ISC / SANS Network Outage

Published: 2010-04-08
Last Updated: 2010-04-08 18:44:03 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

We are still having connectivity issues at one of our hosting locations. Most of the ISC site is now working ok. is just showing the ISC page for now (working on this).

E-Mail is still a problem, and reports are currently not processed. But the contact form should be working. Reports will be processed once we get back online.


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

0 comment(s)

JavaScript obfuscation in PDF: Sky is the limit

Published: 2010-04-08
Last Updated: 2010-04-08 05:49:50 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

I know that most of you are probably already sick of malicious PDF documents, but one of our readers, Will Thomson, sent a really interesting malicious PDF document that used some more advanced obfuscation techniques that I wanted to share with everyone. So, let's get to work.

The PDF document Will sent contains a JavaScript section that gets called immediately after opening the document. This is today really standard. The JavaScript section is relatively short and we can see that it uses the app.doc.getAnnots() (line 17) call to get Annotations, from the code excerpt below:

Main JS

When called like this, the app.doc.getAnnots() call will return an array of objects that will contain all annotations. This is important to remember.

Now, in line 4 you can see that the num variable is set to 1 which will cause the sum variable (line 18) to contain the second annotation's subject field (array members start with 0). This will then be deobfuscated with a loop at line 27 and finally at line 39 the second JavaScript layer gets called with an eval() call.

This second JavaScript layer at first sight looks familiar – the huge "blob" of obfuscated data is passed as an argument to the function called iXM__8f_ITb, which is then deobfuscated. One trap is immediately visible – the author used the arguments.callee() call to prevent us from modifying the deobfuscation function but this can normally be easily evaded by redefining the eval() call. However, if this is done, and the function is called it will only print out some meaningless numbers! Yet, the PDF is malicious when tested on a vulnerable Acrobat Reader so something else must be going on here.

Take a look at the code below, which I tidied a bit for you so you can read it easier:

Second layer JS

Especially important are lines 6-13. So, what do the attackers do here:

  • First the variable n_AXr11_7Wdj is assigned value 0,
  • Then, on line 8, the existence of the app object is tested. This object is created by Acrobat Reader so if you run this outside (for example, with SpiderMonkey or another JavaScript interpreter) this call will fail since the object will not exist. We can create that object easily, but we are still not done,
  • On line 10, the h__l_S_1__f variable will contain pr[n_AXr11_7Wdj].subject. Since n_AXr11_7Wdj is 0, this equals to pr[0].subject. Remember what the pr array is? It contains annotations. In other words, this will use the first annotation.

If all this passed correctly, the contents of first annotation are used as the deobfuscation key – if any part fails, the deobfuscation function will simply just print some numbers. Clever indeed! The final JavaScript layer just exploits the old Collab.collectEmailInfo vulnerability.

Why are the attackers going to this length with obfuscation you might ask? Well, the obvious answer is to make detection (and analysis) more difficult. And it indeed looks as they were successful with this since when I uploaded the document to VirusTotal (VT) only 6 out of 39 AV programs detected it as malicious, with most of big names missing it. Wepawet, another great service for analyzing malicious JavaScript/PDF/Flash files by UCSB (Wepawet) handled the file better and managed to analyze it correctly – kudos to the UCSB team.

While there has been a lot of words and warnings about how patching Adobe Reader installations is important, I would like to stress this out again as attackers are clearly not sleeping.


0 comment(s)


Diary Archives