January 2010 - Posts

Published: 2010-01-21,
Last Updated: 2010-01-21 20:21:55 UTC
by Chris Carboni (Version: 1)
1 comment(s)

Microsoft released the out of band security bulletin and patch it announced yesterday. MS10-002 is a cumulative patch for Internet Explorer. It fixes a total of 8 vulnerabilities. The "famous" vulnerability that triggered the release, CVE-2010-0249, is currently being exploited. According to the bulletin, none of the other vulnerabilities are currently being exploited and all had been disclosed to Microsoft directly without any prior public disclosure.

Given the number of ever improving exploits against CVE-2010-0249, and the publicly known use of these exploits, we recommend that you patch as soon as possible.

Advance Notification for Out-of-Band Bulletin Release

Today we issued our Advanced Notification Service (ANS) to advise customers that we will be releasing MS10-002 tomorrow, January 21st, 2010. We are planning to release the update as close to 10:00 a.m. PST (UTC -8) as possible.  This is a standard cumulative update, accelerated from our regularly scheduled February release, for Internet Explorer with an aggregate severity rating of Critical. It addresses the vulnerability related to recent attacks against Google and small subset of corporations, as well as several other vulnerabilities. Once applied, customers are protected against the known attacks that have been widely publicized. We recommend that customers install the update as soon as it is available.  For customers using automatic updates, this update will automatically be applied once it is released.

Today we also updated Security Advisory 979352 to include technical details addressing additional customer questions.

The updated Security Advisory includes guidance in relation to reports of proof of concept (POC) code that bypasses Data Execution Prevention (DEP) and additional information on the exploitability of, and mitigations and workarounds for, Microsoft products that use mshtml.dll.

Based on our comprehensive monitoring of the threat landscape, we continue to see only limited attacks. To date, the only successful attacks that we are aware of have been against Internet Explorer 6.

We continue to recommend that customers update to Internet Explorer 8 to benefit from the improved security protection it offers.

Additional Technical Details Related to Security Advisory 979352

Data Execution Prevention (DEP) Bypass

There is a report of a new exploit that bypasses Data Execution Prevention (DEP). We have analyzed the Proof-of-Concept (POC) exploit code and have found that Windows Vista and later versions of Windows offer more effective protections in blocking the exploit due to the improved security protection offered by Address Space Layout Randomization (ASLR).

On Windows XP, which does not benefit from the improved security protection provided by ASLR, attacks using the DEP bypass techniques are likely to be more effective.

The DEP bypass exploit is not, at this time, publicly available and we have not seen it used in attacks.

Additional details on the DEP bypass exploit are provided in a Security Research and Defense Blog published today.

Microsoft E-Mail Products That Render using mshtml.dll Protected by Default

There have been reports that supported versions of Outlook, Outlook Express and Windows Live Mail are affected by the vulnerability in Security Advisory 979352.

For customers using the default configuration of all supported versions of Outlook, Outlook Express and Windows Live Mail the risk of exploit using Outlook as an attack vector is low. We are unaware of active exploit against supported versions of Outlook, Outlook Express or Windows Live.

By default, Outlook, Outlook Express and Windows Live Mail open HTML e-mail messages in the Restricted sites zone, which helps mitigate attacks seeking to exploit this vulnerability by preventing Active Scripting and ActiveX controls from being used. Additionally, Outlook 2007 uses a different component to render HTML e-mail, removing the risk of the exploit.

If customers have modified their default configuration to not run in Restricted sites zone, their environments will be in a less secure, more vulnerable, state.

Other products may also use the HTML rendering engine for Internet Explorer and could expose this vulnerability.  Any successful attack would require bypassing the default security mechanisms used by each individual application. Therefore customers who use these default application configurations may have reduced risk from being exploited through additional vectors.

Office Applications with Active Scripting Enabled Potentially Vulnerable

We are also aware that the vulnerability can be exploited by including an ActiveX control in a Microsoft Access, Word, Excel, or PowerPoint file. Customers would have to open a malicious file to be at risk of exploitation.

To prevent exploitation, we recommend that customers disable ActiveX Controls in Microsoft Office.

Detailed information on how to disable ActiveX Controls is included in the Security Advisory.

To be clear, applying the update for Internet Explorer addresses the issue across all products that may use mshtml.dll. Customers should install the update to be protected.

We continue to monitor the situation and will keep customers apprised of any changes to the situation or threat landscape through the Microsoft Security Response Center Blog.

Please join us Thursday, January 21 at 1:00 p.m. PST (UTC – 8) for a public webcast where we will present information on the bulletin and take customer questions. Registration information:

Date: Thursday Jan 21
Time: 1:00 p.m. PST (UTC -8)
Registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032440627

Thanks,

Jerry Bryant

*This posting is provided "AS IS" with no warranties, and confers no rights*

Anonymous comments are disabled
Published: 2010-01-21,
Last Updated: 2010-01-21 01:03:17 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Yesterday, we reported about a new Windows Kernel vulnerability [1] . The vulnerability affects all versions of Windows (NT 3.51 up to Windows 7) unless 16-bit application support is disabled. If exploited, the vulnerability will lead to privilege escalation.

Today, Microsoft released an official response in the form of a Security Advisory [2]. The advisory (KB Article 979682) states that Microsoft is investigating the report, and is not aware of any use of the vulnerability in current exploits.

According to Microsoft's list of vulnerable and non-vulnerable systems, 64 bit version of the Windows OS are not vulnerable, but 32 bit versions are. In part this is due to the fact that 64 bit versions of Windows do not include the vulnerable feature (16 bit compatibility).

The workaround outlined by Microsoft matches the workaround proposed in the advisory: Disable access to 16 bit applications. This should work well for the vast majority of systems. But be aware that there is a reason for this feature: Some old (very old) applications do require 16 bit support. This may in particular affect old custom software and support for odd hardware configurations. A standard office desktop should not require any 16 bit applications. As always: Test first.

The CVE number CVE-2010-0232 has been assigned to this issue [3].

[1] http://isc.sans.org/diary.html?storyid=8023
[2] http://www.microsoft.com/technet/security/advisory/979682.mspx
[3] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-0232 (not live yet as of this writing)

********************************************************************

Title: Microsoft Security Advisory Notification

Issued: January 20, 2010

********************************************************************

Security Advisories Updated or Released Today ==============================================

* Microsoft Security Advisory (979682)

- Title: Vulnerability in Windows Kernel Could Allow

Elevation of Privilege

- http://www.microsoft.com/technet/security/advisory/979682.mspx

- Revision Note: V1.0 (January 20, 2010): Advisory published.

* Microsoft Security Advisory (979352)

- Title: Vulnerability in Internet Explorer Could

Allow Remote Code Execution

- http://www.microsoft.com/technet/security/advisory/979352.mspx

- Revision Note: V1.2 (January 20, 2010): Revised Executive

Summary to reflect the changing nature of attacks attempting

to exploit the vulnerability. Clarified information in the

Mitigating Factors section for Data Execution Prevention

(DEP) and Microsoft Outlook, Outlook Express, and Windows

Mail. Clarified several Frequently Asked Questions to provide

further details about the vulnerability and ways to limit the

possibility of exploitation. Added "Enable or disable

ActiveX controls in Office 2007" and "Do not open unexpected

files" to the Workarounds section.

Reports of DEP being bypassed

Yesterday we heard reports of a commercially available exploit that bypasses DEP. This exploit was made available to a limited number of major security vendors (Antivirus, IDS, and IPS vendors) and government CERT agencies. We wanted to use this opportunity to give an overview of current customer risk related to this DEP bypass.

Real-world attacks so far still only effective against Internet Explorer 6

We have seen an increase in attacks attempting to exploit the vulnerability detailed in Security Advisory 979352. However, all attacks we have seen so far still target Internet Explorer 6 - this is also confirmed by the attack samples our Microsoft Active Protections Program (MAPP) partners have sent in.

While we have not seen real-world attacks for any other platform, we have seen researchers poking at other platforms and have seen the following:

  • Private proof-of-concept code exploiting IE7 on Windows XP for arbitrary code execution
  • Private proof-of-concept code exploiting IE7 on Windows Vista without DEP enabled for code execution within the Protected Mode sandbox. We are not aware of any proof-of-concept code exploiting Windows Vista with DEP enabled.
  • Commercial, limited distribution proof-of-concept code exploiting IE8 on Windows XP with DEP enabled for arbitrary code execution.

State-of-the-art of attacker research on various platforms

Here’s the current state-of-the-art on each platform:

  Windows XP Windows Vista Windows 7
IE 6 Public exploit code consistently reliable for arbitrary code execution N/A N/A
IE 7 Private proof-of-concept is likely consistently reliable for arbitrary code execution Private proof-of-concept is likely consistently reliable for limited code execution within the Protected Mode sandbox. N/A
IE 8 In our testing, the commercially-available, limited distribution exploit results in code execution about one in three attempts. For two in three attempts, it results in an Internet Explorer crash. No known proof-of-concept code. Current exploits modified for use on Windows Vista would likely be effective for limited code execution within the Protected Mode sandbox on less than 1% (1/256 + 1/255 + 1/254) of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows Vista. No known proof-of-concept code. Current exploits modified for use on Windows 7 would likely be effectively for limited code execution within the Protected Mode sandbox on less than 1% (1/256 + 1/255 + 1/254) of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows 7.

Other mitigations (besides DEP)

We have discussed DEP at length in this blog. As you can see in the table above, two other mitigations help prevent or limit the impact of attacks on later platforms.

  • Internet Explorer Protected Mode limits the impact of Windows Vista and Windows 7 exploits. Attackers who are able to successfully exploit Internet Explorer on those platforms are stuck in a “sandbox”, potentially able to read data but unable to install programs or change system configuration.
  • Address Space Layout Randomization (ASLR) makes exploiting vulnerabilities more difficult by relocating normally-predictable code locations pseudo-randomly in memory. ASLR re-bases DLL’s to random locations in memory, making ret2libc type attacks unreliable. Due to ASLR we believe exploits for Internet Explorer 8 on Windows Vista or Windows 7 could result in limited code execution for less than 1% of attempts.

Out-of-band update coming tomorrow

We’ll be releasing a comprehensive, well-tested security update tomorrow morning PST to address this vulnerability. In the meantime, we hope this information helps you assess risk and protect your environment.

Acknowledgements

Thanks Matt Miller and John Lambert for help with the ASLR arithmetic and other feedback. 

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Published: 2010-01-20,
Last Updated: 2010-01-20 22:03:06 UTC
by Lenny Zeltser (Version: 2)
0 comment(s)

Microsoft posted "an advance notification of one out-of-band security bulletin that Microsoft is intending to release on January 21, 2010. The bulletin will be for Internet Explorer to address limited attacks against customers of Internet Explorer 6, as well as fixes for vulnerabilities rated Critical that are not currently under active attack."

For details, see:

http://www.microsoft.com/technet/security/bulletin/ms10-jan.mspx

Update:

Microsoft also posted a comprehensive overview of the exploits that target this vulnerability. See:

http://blogs.technet.com/srd/archive/2010/01/20/reports-of-dep-being-bypassed.aspx

-- Lenny

Lenny Zeltser - Security Consulting

********************************************************************

Title: Microsoft Security Advisory Notification

Issued: January 20, 2010

********************************************************************

 

Security Advisory Updated Today

==============================================

 

 * Microsoft Security Advisory (979352)

  - Title: Vulnerability in Internet Explorer Could

    Allow Remote Code Execution

  - http://www.microsoft.com/technet/security/advisory/979352.mspx

  - Revision Note: V1.2 (January 20, 2010): Revised Executive

    Summary to reflect the changing nature of attacks attempting

    to exploit the vulnerability. Clarified information in the

    Mitigating Factors section for Data Execution Prevention

    (DEP) and Microsoft Outlook, Outlook Express, and Windows

    Mail. Clarified several Frequently Asked Questions to provide

    further details about the vulnerability and ways to limit the

    possibility of exploitation. Added " Enable or disable

    ActiveX controls in Office 2007" and " Do not open unexpected

    files" to the Workarounds section.   

********************************************************************

Microsoft Security Bulletin Advance Notification for January 2010

Issued: January 20, 2010

********************************************************************

This is an advance notification of one out-of-band security bulletin that Microsoft is intending to release on January 21, 2010.

The full version of the Microsoft Security Bulletin Advance Notification for January 2010 can be found at http://www.microsoft.com/technet/security/bulletin/ms10-jan.mspx.

This bulletin advance notification will be replaced with the January bulletin summary on January 21, 2010. The revised bulletin summary will include the out-of-band security bulletin, as well as the security bulletins already released on January 12, 2010.

For more information about the bulletin advance notification service, see http://www.microsoft.com/technet/security/Bulletin/advance.mspx.

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications on http://www.microsoft.com/technet/security/bulletin/notify.mspx.

Microsoft will host a webcast to address customer questions on the out-of-band bulletin on January 21, 2010, at 1:00 PM Pacific Time (US & Canada). Register for the Security Bulletin Webcast at http://www.microsoft.com/technet/security/bulletin/summary.mspx.

Microsoft also provides information to help customers prioritize monthly security updates with any non-security, high-priority updates that are being released on the same day as the monthly security updates. Please see the section, Other Information.

This advance notification provides a number as the bulletin identifier, because the official Microsoft Security Bulletin numbers are not issued until release. The bulletin summary that replaces this advance notification will have the proper Microsoft Security Bulletin numbers (in the MSyy-xxx format) as the bulletin identifier. The security bulletins for this month are as follows, in order of severity:

Critical Security Bulletins

===========================

IE Bulletin

- Affected Software:

- Internet Explorer 5.01 Service Pack 4 when installed on

Microsoft Windows 2000 Service Pack 4

- Internet Explorer 6 Service Pack 1 when installed on

Microsoft Windows 2000 Service Pack 4

- Internet Explorer 6 for

Windows XP Service Pack 2 and

Windows XP Service Pack 3

- Internet Explorer 6 for

Windows XP Professional x64 Edition Service Pack 2

- Internet Explorer 6 for

Windows Server 2003 Service Pack 2

- Internet Explorer 6 for

Windows Server 2003 x64 Edition Service Pack 2

- Internet Explorer 6 for

Windows Server 2003 with SP2 for Itanium-based Systems

- Internet Explorer 7 for

Windows XP Service Pack 2 and

Windows XP Service Pack 3

- Internet Explorer 7 for

Windows XP Professional x64 Edition Service Pack 2

- Internet Explorer 7 for

Windows Server 2003 Service Pack 2

- Internet Explorer 7 for

Windows Server 2003 x64 Edition Service Pack 2

- Internet Explorer 7 for

Windows Server 2003 with SP2 for Itanium-based Systems

- Internet Explorer 7 in

Windows Vista,

Windows Vista Service Pack 1, and

Windows Vista Service Pack 2

- Internet Explorer 7 in

Windows Vista x64 Edition,

Windows Vista x64 Edition Service Pack 1, and

Windows Vista x64 Edition Service Pack 2

- Internet Explorer 7 in

Windows Server 2008 for 32-bit Systems and

Windows Server 2008 for 32-bit Systems Service Pack 2

(Windows Server 2008 Server Core installation not affected)

- Internet Explorer 7 in

Windows Server 2008 for x64-based Systems and

Windows Server 2008 for x64-based Systems Service Pack 2

(Windows Server 2008 Server Core installation not affected)

- Internet Explorer 7 in

Windows Server 2008 for Itanium-based Systems and

Windows Server 2008 for Itanium-based Systems Service Pack 2

- Internet Explorer 8 for

Windows XP Service Pack 2 and

Windows XP Service Pack 3

- Internet Explorer 8 for

Windows XP Professional x64 Edition Service Pack 2

- Internet Explorer 8 for

Windows Server 2003 Service Pack 2

- Internet Explorer 8 for

Windows Server 2003 x64 Edition Service Pack 2

- Internet Explorer 8 in

Windows Vista,

Windows Vista Service Pack 1, and

Windows Vista Service Pack 2

- Internet Explorer 8 in

Windows Vista x64 Edition,

Windows Vista x64 Edition Service Pack 1, and

Windows Vista x64 Edition Service Pack 2

- Internet Explorer 8 in

Windows Server 2008 for 32-bit Systems and

Windows Server 2008 for 32-bit Systems Service Pack 2

(Windows Server 2008 Server Core installation not affected)

- Internet Explorer 8 in

Windows Server 2008 for x64-based Systems and

Windows Server 2008 for x64-based Systems Service Pack 2

(Windows Server 2008 Server Core installation not affected)

- Internet Explorer 8 in

Windows Server 2008 for Itanium-based Systems and

Windows Server 2008 for Itanium-based Systems Service Pack 2

- Internet Explorer 8 in

Windows 7 for 32-bit Systems

- Internet Explorer 8 in

Windows 7 for x64-based Systems

- Internet Explorer 8 in

Windows Server 2008 R2 for x64-based Systems

(Windows Server 2008 Server Core installation not affected)

- Internet Explorer 8 in

Windows Server 2008 R2 for Itanium-based Systems

- Impact: Remote Code Execution

- Version Number: 1.0

0-day vulnerability in Internet Explorer 6, 7 and 8

Published: 2010-01-14,
Last Updated: 2010-01-14 22:19:56 UTC
by Bojan Zdrnja (Version: 1)

1 comment(s)

Microsoft just published an advisory about a critical security vulnerability in all versions of Internet Explorer (apart from 5 – but no one has that around anymore, right?).

While all versions of Internet Explorer are affected, the risk for everyone running Internet Explorer 8 is lower since it has DEP (Data Execution Prevention) enabled by default. DEP makes exploitation of this vulnerability more difficult so as a temporary workaround you might want to enable it for older IEs (keep in mind that it might break some add-ons).

Microsoft says that so far they only saw exploits against Internet Explorer 6. In a related post (here) McAfee said that this vulnerability was (one of those) used to compromise Google. So, it appears that it was maybe even a cocktail of 0-day exploits used (IE + Adobe).

********************************************************************

Title: Microsoft Security Advisory Notification

Issued: January 14, 2010

********************************************************************

Security Advisory Released Today

==============================================

* Microsoft Security Advisory (979352)

- Title: Vulnerability in Internet Explorer Could

Allow Remote Code Execution

- http://www.microsoft.com/technet/security/advisory/979352.mspx

- Revision Note: Advisory published.

Secure USB Flaw Exposed

Published: 2010-01-06,
Last Updated: 2010-01-06 18:44:38 UTC
by Guy Bruneau (Version: 1)

0 comment(s) Facebookacebook witter

Several ISC readers have written in regarding a security flaw recently exposed on USB flash drive. The issue of the attack is with a software bug in the password verification mechanism. This affects Kingston, SanDisk and Verbatim.

Vendor Information

SanDisk Update Information: http://www.sandisk.com/business-solutions/enterprise/technical-support/security-bulletin-december-2009
Verbatim Update Information: http://www.verbatim.com/security/security-update.cfm
Kingston Recall Information: http://www.kingston.com/driveupdate/

Binsservicesonline Scam Spreading on Facebook and SEO Poisoning

Date:01.05.2010

Threat Type: Malicious Web Site / Malicious Code

Websense Security Labs™ ThreatSeeker™ Network has discovered several spam messages on Facebook that trick the user into visiting BINSSERVICESONLINE(dot)INFO. When the link in the message is clicked, the Web site redirects the user to an online scam site similar to the one we published in the blog Google Scam Kits in mid-December. The use of Facebook to distribute links that lead to Google scam kits is fairly new, and is sure to trick some users into buying the kits.

A lot of users have apparently received this message, as it quickly became a popular search string on Google. As we've seen in the past, there are criminal groups monitoring the popular search terms on Google and other search engines to start their own malicious attacks, so it didn't take long until we started seeing Google search results for BINSSERVICESONLINE leading to rogue AV products.

Note that the two attacks are done by separate groups of criminals. One group started the spam attacks on Facebook and another started manipulating Google results.

We can see many messages spreading in Facebook, for example:

BINSSERVICESONLINE.INFO redirects to the following scam site:



Google search results for BINSSERVICESONLINE:

The Google Trend showing the hot CTR for BINSSERVICESONLINE:

Report of Java Object Serialization exploit in use in web drive-by attacks

Published: 2010-01-05,
Last Updated: 2010-01-05 17:54:55 UTC
by Toby Kohlenberg (Version: 1)

0 comment(s) Facebookacebook witter

We've had a report (thanks Tom!) of a java applet exploiting CVE-2008-5353 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353) as part of a web drive-by attack. While PoC has been around for a long time for this, this is the first time I've heard of it being used in the wild for a general attack. If anyone else has seen this, we'd be interested to hear about it.

The applet is already being detected by some A/V packages according to VirusTotal: https://www.virustotal.com/analisis/d4f5bcc9acecb2f53a78313fc073563de9fc4f7045dd8123a23a08f926a3974d-1262270360

As we get more details on what it does, we'll update this entry with it.

Sophisticated, targeted malicious PDF documents exploiting CVE-2009-4324

Published: 2010-01-04,
Last Updated: 2010-01-04 06:29:59 UTC
by Bojan Zdrnja (Version: 1)

0 comment(s) Facebookacebook witter

Couple of days ago one of our readers, Ric, submitted a suspicious PDF document to us. As you know, malicious PDF documents are not rare these days, especially when the exploit for a yet unpatched vulnerability is wide spread.

Quick analysis of the document confirmed that it is exploiting this vulnerability (CVE-2009-4324 – the doc.media.newPlayer vulnerability). This can be easily seen in the included JavaScript in the PDF document, despite horrible detection (only 6 out of 40 AV vendors detected this when I initially submitted it here).

After extracting the included JavaScript code, the shellcode that it uses looked quite a bit different than what we can usually see in such exploits: this shellcode was only 38 bytes long! Initially I even thought that it does not work, but after studying it a little bit, I found that this particular PDF document has some very interesting, sophisticated characteristics.

The exploit for this vulnerability is similar to most other exploits: it uses heap spraying in order to redirect the execution to shellcode. The NOP sled in this case actually consists of SBB AL,0x1C and SBB AL,0x0C instructions which do nothing (SBB is Subtract with borrow, from the register AL, so it keeps subtracting two values until it reaches the shellcode). The 38 bytes shellcode can be seen below:

Shellcode
Now comes the interesting part. This is an egg-hunting shellcode: it starts at the memory address ((0x02020200 OR 0xFF) + 0x01) = 0x02020300) and compares content of every 4 bytes with 0x58905090. You can see that initially the attacker moves 0x5890508F into the EAX register, which then gets increased by one – this was probably done to evade detection.

This pattern (0x58905090) corresponds to instructions POP EAX, NOP, PUSH EAX, NOP. Now, once this pattern has been identified in memory, the egg-hunting shellcode passes execution to this, second stage shellcode.

What is interesting about this approach is that the second stage shellcode is included as a different object in the PDF document. While the object is marked as a color object and its contents are inflated, it looks as if it is corrupted: it does not contain any inflated streams. You can see the object and the deflation error printed by pdf-parser, an excellent tool by Didier Stevens whom I wish to thank for useful discussion while I was analyzing this malicious PDF document:

$ pdf-parser.py --object 3 --raw --filter Requset.pdf

obj 3 0
Type:
Referencing:
Contains stream
<</BitsPerComponent 8/ColorSpace/DeviceRGB/Filter/FlateDecode/Height 90/Length 13136/Subtype/Image/Width 60>>
<<
   /BitsPerComponent 8
   /ColorSpace /DeviceRGB
   /Filter /FlateDecode
   /Height 90
   /Length 13136
   /Subtype /Image
   /Width 60
>>
FlateDecode decompress failed
The fact that the decompression fails does not matter – Adobe Reader will open the whole document (mmap it) into memory, including this "corrupted" object so the first stage shellcode will be able to find it and pass execution to it!

The advantage for the attacker is obvious: first, he can modify this object (what the exploit actually does) without having to modify the first stage shellcode. Additionally, this will make automatic analysis impossible for any tool that will use a JavaScript interpreter on the included JavaScript code (such as Wepawet) – the first phase shellcode will work only if the document is loaded in the memory. Sneaky, but that was not all!

The second stage shellcode does something interesting as well. It parses the document name from the command line arguments and opens the PDF document directly. The reason for this is that the PDF document carries two embedded binaries! The first binary (SUCHOST.EXE, b0eeca383a7477ee689ec807b775ebbb) contains a PoisonIvy client which tries to connect to the host cecon.flower-show.org which was down when I analyzed the document. Luckily, this binary has a bit better (but still not good, some major AV vendors missing it!) detection on VT (here). This binary is embedded in the PDF document – we can see it at offset 0x0e65c:

$ hexdump -C -v ../Requset.pdf |less
00000000  25 50 44 46 2d 31 2e 36  0d 25 e2 e3 cf d3 0d 0a  |%PDF-1.6.%......|
00000010  32 34 20 30 20 6f 62 6a  0d 3c 3c 2f 4c 69 6e 65  |24 0 obj.<</Line|
00000020  61 72 69 7a 65 64 20 31  2f 4c 20 39 34 37 32 33  |arized 1/L 94723|
00000030  32 2f 4f 20 32 36 2f 45  20 31 37 38 31 2f 4e 20  |2/O 26/E 1781/N |
...
0000e650  b4 b4 b3 88 8f a0 a0 c0  ca c3 88 8f c8 df 00 00  |................|
0000e660  84 00 00 00 87 00 00 00  7a 7a 00 00 c5 00 00 00  |........zz......|
0000e670  00 00 00 00 c5 00 00 00  00 84 00 00 8b 9a 31 8c  |..............1.|
The binary is XORed with value of 0x85 so the first two highlighted bytes are actually MZ, which is where the executable starts.

The second binary (temp.exe, 980e40cacbc9f898bc08cb453fa2d6bb) was even more surprising. This binary drops a benign PDF document on the machine, called baby.pdf. This PDF document is then opened with Adobe Reader – it just shows a table and, according to the metadata in the document, has been built from an Excel document. This was done by the attackers to make the victim believe as if nothing happened, because the original exploit will crash Adobe Reader and this might make the victim suspicious about what happened.

Additionally, the PDF document contains everything it needs to fully exploit the victim's machine – it does not have to download anything off the net.

Lessons learned

Not only was this a very interesting example of a malicious PDF document carrying a sophisticated "war head", but it also showed the length attackers are willing to go to in order to make their malware as hard to detect as possible, not only for the AV vendors, but also for victims.

Since this exploit has not been patched yet, I would like to urge you all to, at least, disable JavaScript in your Adobe Reader applications. We are getting more reports about PDF documents exploiting this vulnerability, and it certainly appears that the attackers are willing to customize them to get as many victims to open them as possible. Also keep in mind that such malicious PDF documents can go to a great length when used in targeted attacks – the fake PDF that gets opened can easily fool any user into thinking it was just a mistakenly sent document.

If we are to judge the new year by sophistication the attackers started using, it does not look too good.