Various

Gong Da / Gondad Exploit Pack Add Flash CVE-2013-0634 Support

12

If you are working in computer security and still don’t have heard about the latest Adobe Flash 0days, aka CVE-2013-0633 and CVE-2013-0634, then you should change of job ! These vulnerabilities were found exploited in targeted attacks through spear phishing email messages targeting several industries including the aerospace one.

One of the e-email attached Word document was using the 2013 IEEE Aerospace Conference schedule, and another reported sample was related to online payroll system of ADP US company, to exploit CVE-2013-0633. I wrote a complete blog post regarding this campaign 2 weeks ago.

Adobe fixed the vulnerabilities in APSB13-04 the 7 February, but the vulnerabilities were not found massively exploited in Exploit Kits. Also there was a confusion,  by anti-virus vendors and security researchers, regarding CVE-2013-0633 and CVE-2013-0634 detection. But as mentioned in Adobe APSB13-04 CVE-2013-0633 was only exploited by been embedded in Word documents and CVE-2013-0634 was exploited through HTML web pages and by been embedded in Word documents.

So as nobody as seen CVE-2013-0633 working outside a Word document, I will suppose that the vulnerability I discovered exploited in Gong Da exploit kit is potentially a fork of CVE-2013-0633 or could be CVE-2013-0634. Colleagues, you are welcome for comments :)

Here is the new code in Gong Da exploit kit.

Capture d’écran 2013-02-25 à 23.29.30

If you take a look at the ActionScript of “myrF03.swf” (506fe8f82ea151959c5160bc40da25b5) you will see some similarities with CVE-2013-0633, like the “ByteArrayAsset” mentioned by MalwareMustDie, or the well-known “LadyBoyle” function.

Capture d’écran 2013-02-26 à 00.10.49

Capture d’écran 2013-02-26 à 00.11.03

This new version was discovered on “hxxp://www.jhtyhtrsgr.com/yymex/index.html” a web site how is actually still online.

Capture d’écran 2013-02-25 à 23.29.04

jhtyhtrsgr.com” is hosted on 69.197.61.29, in US and this domain name was created the 22 Feb 2013 with registration informations located in China and the following contact “jing yan (ttfu7ii777@126.com) - GuangMing yanjing“.

The “index.html” file containing JavaScript code obfuscated by “JSXX VIP JS Obfuscator“, but traditional traces if this obfuscator are no more available.

After de-obfuscation of the “index.html” file you can see that Gong Da Pack has involve to the following diagram.

Gong Da EK 1.4 - 2

Here under some information s regarding the different files:

  • vQSopE2.jpg (aka CVE-2011-3544) : 10/46 on VirusTotal.com
  • ulxzBc7.jpg (aka CVE-2012-0507) : 11/45 on VirusTotal.com
  • MQnA3.jpg (aka CVE-2012-1723) : 18/46 on VirusTotal.com
  • eATBNfg1.jpg (aka CVE-2012-4681) : 29/46 on VirusTotal.com
  • tkPfaMz7.jpg (aka CVE-2012-5076) : 14/46 on VirusTotal.com
  • iOiezo6.jpg (aka CVE-2013-0422): 19/46 on VirusTotal.com
  • YPVTz8.html (aka CVE-2012-1889): 14/46 on VirusTotal.com
  • vQSopE2.html (aka CVE-2012-1889): 12/46 on VirusTotal.com
  • myrFO3.swf (aka a fork of CVE-2013-0633 CVE-2013-0634): 8/46 on VirusTotal.com

Here under a demonstration video of CVE-2013-0633 CVE-2013-0634 without been embeded in a Word document.

Updates:

After investigation from @unixfreaxjp, it seem that the exploited vulnerability is CVE-2013-0634 and not CVE-2013-0633.

Facebook, Apple & Twitter Watering Hole Attack Additional Informations

34

Update: Some worrying information’s at the bottom of the post.

As reported by Ars Technica, the 15th February, Facebook was victim of a watering hole attack, involving a “popular mobile developer Web forum“. The attack was using a Java 0day that has been urgently patched, in Oracle Java CPU of first February, by version 7 update 11 and version 6 update 39.

Ars Technica also pointed that the attack had occur during the same timeframe as the hack that exposed cryptographically hashed passwords at Twitter. Also Twitter was encouraging, the first February, users to disable Java in their browsers. 250 000 user accounts was compromised during the Twitter breach.

Four days after the news on Facebook, the 19 February, Reuters also mentioned Apple as a victim of the Oracle Java 0day. The same ”popular mobile developer Web forum” was mentioned, but with the precision that this website is a “popular iPhone mobile developer Web forum”. People briefed on the case said that hundreds of companies were affected by this Java 0day, including defense contractors.

Another interesting fact is that Apple had blacklist Java Web plug-in, a second time in a month, the 31 January, through an update to Xprotect, the Mac OS X “anti-malware” system. Surely a reaction the breach reported in the press 19 days later.

Today, Ars Technica released the name of the “popular iPhone mobile developer Web forum”, aka www.iphonedevsdk.com. Now we can gather some information’s related to this watering hole attack.

On urlQuery we can find an interesting submission, the 23 January, who reveal that some Java code was involved during the visit of the web site.

deployJavaPlugin

On JSUNPACK we can find another interesting submission, the 22 January, related to the www.iphonedevsdk.com. This submission reveals another website who is min.liveanalytics.org with URL “min.liveanalytics.org/cache.js?1358893681579“. The “cache.js” JavaScript was no more present at this date.

liveanalytics.org domain name was created the 8 December October 2012, through Public Domain Registry registrar. All contact information’s are hidden behind PrivacyProtect.org. Privacy Protection ensures that private information of domain owners are not published by replacing all the publicly visible contact details with alternate contact information.

But going back on the first urlQuery submission, we can see that www.iphonedevsdk.com website was doing three requests to min.liveanalytics.org website.

First call was to “/cache.js?1358897354865” JavaScript with a date of “Tue, 22 Jan 2013 23:21:31 GMT“. “1358897354865” return the number of milliseconds since 1970/01/01.

min-liveanalytics-org-cache-js

Second call was to “/jquery.js?ummrznjf” JavaScript with the same date.

jmin-liveanalytics-org-query-js

Third call was to “empty.htm” with additional parameters who are “empty.htm?id=0&ts=X&n=fp&s=Y“. In the following screenshot you will se that X value of ts variable return the number of milliseconds since 1970/01/01. Also in the following screenshot you will see a base64-encoded string:

[code]eyJicm93c2VyIjoiRmlyZWZveCIsInVhIjoiTW96aWxsYSU1Qy81LjAlMjAlMjhXaW5kb3dzJTNCJTIwVSUzQiUyMFdpbmRvd3MlMjBOVCUyMDYuMSUzQiUyMGVuLVVTJTNCJTIwcnYlM0ExLjkuMi4xMyUyOSUyMEdlY2tvJTVDLzIwMTAxMjAzJTIwRmlyZWZveCU1Qy8zLjYuMTMiLCJwcm9kdWN0IjoiR2Vja28iLCJwbHVnaW5zIjp7Ik1vemlsbGElMjBEZWZhdWx0JTIwUGx1Zy1pbiI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxLjAuMC4xNSJ9LCJTaG9ja3dhdmUlMjBGbGFzaCI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxMC4wLjQ1LjIifSwiSmF2YSUyOFRNJTI5JTIwUGxhdGZvcm0lMjBTRSUyMDYlMjBVMjYiOnsiaW5zdGFsbGVkIjp0cnVlLCJ2ZXJzaW9uIjoiNi4wLjI2MC4zIn0sIkphdmElMjBEZXBsb3ltZW50JTIwVG9vbGtpdCUyMDYuMC4yNjAuMyI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiI2LjAuMjYwLjMifSwiQWRvYmUlMjBBY3JvYmF0Ijp7Imluc3RhbGxlZCI6dHJ1ZSwidmVyc2lvbiI6IjguMC4wLjQ1NiJ9LCJNaWNyb3NvZnQlQUUlMjBEUk0iOnsiaW5zdGFsbGVkIjp0cnVlLCJ2ZXJzaW9uIjoiOS4wLjAuNDUwMyJ9LCJXaW5kb3dzJTIwTWVkaWElMjBQbGF5ZXIlMjBQbHVnLWluJTIwRHluYW1pYyUyMExpbmslMjBMaWJyYXJ5Ijp7Imluc3RhbGxlZCI6dHJ1ZSwidmVyc2lvbiI6IjMuMC4yLjYyOSJ9LCJhY3JvYmF0Ijp7Imluc3RhbGxlZCI6ZmFsc2UsInZlcnNpb24iOm51bGx9LCJmbGFzaCI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxMC4wLjQ1LjIifSwic2hvY2t3YXZlIjp7Imluc3RhbGxlZCI6ZmFsc2UsInZlcnNpb24iOm51bGx9LCJTaWx2ZXJsaWdodCUyMFBsdWctSW4iOnsiaW5zdGFsbGVkIjpmYWxzZSwidmVyc2lvbiI6bnVsbH0sIndtcCI6eyJpbnN0YWxsZWQiOmZhbHNlLCJ2ZXJzaW9uIjpudWxsfSwicmVhbCI6eyJpbnN0YWxsZWQiOmZhbHNlLCJ2ZXJzaW9uIjpudWxsfSwiamF2YSI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxLjYuMF8yNiJ9fX0=[/code]

Decoded this value is quiet interesting:

[code]{"browser":"Firefox","ua":"Mozilla%5C/5.0%20%28Windows%3B%20U%3B%20Windows%20NT%206.1%3B%20en-US%3B%20rv%3A1.9.2.13%29%20Gecko%5C/20101203%20Firefox%5C/3.6.13","product":"Gecko","plugins":{"Mozilla%20Default%20Plug-in":{"installed":true,"version":"1.0.0.15"},"Shockwave%20Flash":{"installed":true,"version":"10.0.45.2"},"Java%28TM%29%20Platform%20SE%206%20U26":{"installed":true,"version":"6.0.260.3"},"Java%20Deployment%20Toolkit%206.0.260.3":{"installed":true,"version":"6.0.260.3"},"Adobe%20Acrobat":{"installed":true,"version":"8.0.0.456"},"Microsoft%AE%20DRM":{"installed":true,"version":"9.0.0.4503"},"Windows%20Media%20Player%20Plug-in%20Dynamic%20Link%20Library":{"installed":true,"version":"3.0.2.629"},"acrobat":{"installed":false,"version":null},"flash":{"installed":true,"version":"10.0.45.2"},"shockwave":{"installed":false,"version":null},"Silverlight%20Plug-In":{"installed":false,"version":null},"wmp":{"installed":false,"version":null},"real":{"installed":false,"version":null},"java":{"installed":true,"version":"1.6.0_26"}}}[/code]

min-liveanalytics-org-empty-htm

These kinds of behaviors make me think to a statistic backend like Jsbug, but I don’t have enough information’s to validate my doubts.

By doing some additional researches on urlQuery, regarding min.liveanalytics.org, we can find a submission dating from the 23 January with one screenshot. And by doing also additional researches on urlQuery, regarding www.iphonedevsdk.com, we can observe that min.liveanalytics.org was down the 24 January.

down

Now let try other occurrences for www.iphonedevsdk.com or min.liveanalytics.org in search engines & search engines caches. No luck, Google and his cache are not revealing any information’s, same for Bing and other popular search engines. But WayBack Machine is providing a cached version of www.iphonedevsdk.com for the 15 January, and, and you got it Google Chrome is presenting a nice warning screen regarding min.liveanalytics.org  ;)

Capture d’écran 2013-02-20 à 02.47.11

It is confirming us that this website was hosting some malware and that www.iphonedevsdk.com was including JavaScript calls to min.liveanalytics.org the 15 January, date of the Wayback Machine capture. If you take a look at the source code of cached version of www.iphonedevsdk.com you can see this, a nice JavaScript inclusion.

Capture d’écran 2013-02-20 à 00.28.33

So we have a timeline associated with this domain:

  • Domain name was registered the 8 December October with hidden information’s
  • WayBack Machine cached version of 7 December is not infected.
  • WayBack Machine report us that the website was infected the 15 January
  • urlQuery & JSUNPACK report us that the website was up the 22/23 January
  • urlQuery report us that the website was down the 24 January

Another interesting timeline is the Oracle Java patch and life cycle:

  • 11 December 2012: Oracle release, through a CPU, Java SE 7 Update 10 who introduced the levels of security for applet execution.
  • 13 January 2013: Oracle release an alert and update, Java SE 7 Update 11, for a Java 0day able to bypass the security manager.
  • 1 February 2013: Oracle release, through an out-of-band CPU, Java SE 7 Update 13, in order to fix a 0day exploited in the wild.

As you can see, Java SE 7 Update 10, released the 11 December, has introduce the levels of security (“Medium” by default) and bunch of pop-ups, who are warning you about the trust of an applet. Java SE 7 Update 11, released the 13 January, has force the level of security from “Medium” to “High“. With the “High” setting, the user is always prompted before any unsigned Java applet or Java Web Start application is run.

What I can suppose regarding these timelines:

  1. First, the victims of this watering hole campaign didn’t have potentially updated to the latest version.
  2. Second, the victims of this watering hole campaign did have potentially update to JSE 7U11, but have not change the default security level from “Medium” to “High“, despite all the history in Java 0days and advises of security experts.
  3. Third, the victims, have potentially detect the attack when JSE 7U13 was out, because the “High” security level shown them some unusual applet execution on the ”popular iPhone mobile developer Web forum”.

Was this campaign a highly targeted attack? I don’t think so, why because Oracle Java has a long history of 0days, and serious companies like Twitter, Facebook and Apple should have disable Java Web Start application for non trusted applets since a while.

Updates

F-Secure has provide in a blog post 2 other domain names involved in the Facebook, Apple and Twitter compromise, this domain name are:

  • cloudbox-storage.com
  • digitalinsight-ltd.com

By investigating on these domain names, I found some worrying information’s. If these information’s are confirmed then the story is complete different and could have a bigger impact.

digitalinsight-ltd.com” domain name was registered the 2012-03-22. By doing some Google dorks we can find these informations:

A post on Fedoraforum.org, dating from 2012-07-14 mentioning this domain name… and a user of the forum wonder why a JavaScript inclusion is done to this domain.

fedora-forum

If you take a look on Wayback Machine, you can find a cached version from 2012-07-12, that makes your Google Chrome screaming….

fedora-forum-alert

And what can we find in the source code of the FedoraForum webpage!!!!! A similar JavaScript inclusion as for www.iphonedevsdk.com also calling a “cache.js” script….

fedora-forum-source-code

We can also found a JSUNPACK submission, dating from 2012-10-22 with same source code….

And we can find some French guys complaining on a forum regarding a JavaScript inclusion to the same domain and script…. the 2012-09-29

A Deeper Look In CVE-2012-4792 Watering Hole Campaigns – Alljap Chapter

9

This post is a small part of an in-depth analysis of the watering hole campaign of December involving an Internet Explorer 0day.  Jindrich Kubec and my self are working hard in order to synthesize all these information’s in order to provide you a high level overview.

As I mentioned to threatpost.com, the 14th January, additional web sites were discovered hosting Internet Explorer CVE-2012-4792 exploit. One of the additional web site was “All Jap auto parts” (www.alljap.net), an importer of second-hand japanese engines and car parts located in Brisbane, Queensland, Australia.

StopMalvertising published an analysis I recommend to you for additional information’s.

When I discovered this infected web, I noticed initially that the files were time stamped (HTTP Last-Modified entity-header) at the following dates:

  • deployJava.js : Fri, 14 Dec 2012 15:47:42 GMT
  • index.html : Fri, 14 Dec 2012 15:49:58 GMT
  • news.html : Fri, 14 Dec 2012 15:50:42 GMT
  • robots.txt : Fri, 14 Dec 2012 15:50:57 GMT
  • today.swf : Fri, 14 Dec 2012 15:51:08 GMT
  • xsainfo.jpg : Fri, 14 Dec 2012 15:56:44 GMT

index.html” file was supporting chinese simplified (zh-cn), taiwanese mandarin (zh-tw), japanese (ja), american english (en-us) and russian (ru). “girl” and “boy” patterns were present. And “hello” text was hidden.

CFR.org version of “index.html”, I discovered in Google cache and dating from the 7 December, was only supporting chinese simplified (zh-cn), taiwanese mandarin (zh-tw) and american english (en-us). “girl” and “boy” patterns were also present and “hello” text was not hidden.

CFR.org version, reported by FireEye, of around the 20 December, was supporting chinese simplified (zh-cn), taiwanese mandarin (zh-tw), japanese (ja), american english (en-us), russian (ru) and korean (ko). “girl” and “boy” patterns were no more present and replace by “ms-help:” technique to bypass ASLR on Windows 7. Also “hello” text was hidden.

By only analyzing these samples, from CFR.org and All jap auto part, we can observe that the attackers have changed tactics multiple times during this campaign.

By analyzing all the samples of other infected web sites (around 40 infected web sites samples), I observed that the All jap auto part was not used in the watering hole campaign. No high value legit websites where including, by iframe or by JavaScript inclusion, this website.

By doing some further analysis, regarding All jap auto part, I observed initially that hosted phpmyfaq and wwwboard tools were not updated since a long time. And after some Google dorks, I found two PHP backdoors and the Apache logs (from 13 November to beginning February) who were freely accessible from Internet. We will name the first backdoor BK1 and the second BK2 for further references in this blog post.

Having free access to the logs, was an unique opportunity to find additional evidences, regarding the attackers and the differences in the samples and patterns.

I first researched, in the logs, accesses to the backdoors. BK1 was not present in the logs, but BK2 was accessed the 7 December by IP 112.175.234.199. The IP is located in South Korea and is associated to FlyVPN.com VPN mirror. User agent associated to this IP is Internet Explorer 8 under Windows XP.

112.175.234.199 – - [07/Dec/2012 00:31:22 +0000] “GET /BK2.php HTTP/1.1″ 200 371 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727)”

By searching additional references to this IP, we can observe a first access to CVE-2012-4792 exploit the 7 December with a different user agent, Firefox 12 under Windows XP.

112.175.234.199 – - [07/Dec/2012 01:18:59 +0000] “GET /wwwboard/news/index.html HTTP/1.1″ 200 5776 “http://www.gbn.com/” “Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0″

We can directly observe that the HTTP referer was Global Business Network (www.gbn.com) and that All jap auto part was also involved in a watering hole campaign. Description of GBN:

GBN helps organizations adapt and grow in an increasingly uncertain and volatile world. Using our leading-edge tools and expertise—scenario planning, experiential learning, networks of experts and visionaries—we enable our clients to address their most critical challenges and gain the insight, confidence, and capabilities they need to shape the future.

We can also confirm, like CFR.org, that the exploit was present on All jap auto part since minimum the 7 December.

By doing a complete log analysis we can observe the following time line and information’s.

[table "3" not found /]

This IP has directly access to BK2, no other web pages visits. You can observe that some PHP mail code (mail.php) was put in place in order to send spear phishing email targeted to Taiwanese people’s (tw.htm). Bunch of operations have been done through BK2. Also you can observe that they test the exploit with Firefox 12.

[table "5" not found /]

This IP has directly access to BK2, no other web pages visits, and manipulate the content of CVE-2012-4792 0day. The IP is located in South Korea with only a pptp VPN open port. You can also observe usage of a file named “demo.txt”.

[table "4" not found /]

This IP has directly access to the BK2, no other web pages visits, manipulate the content of CVE-2012-4792 0day and do some test from GBN.com. The IP is located in Taiwan with only a pptp VPN open port.

[table "6" not found /]

This IP has directly access to the BK2, no other web pages visits, manipulate the content of CVE-2012-4792 0day. The IP is located in Hong-Kong with only a pptp VPN open port.

[table "7" not found /]

This IP has directly access to the BK2, no other web pages visits, manipulate the content of CVE-2012-4792 0day. The IP is located in South Korea with only a pptp VPN open port.

[table "8" not found /]

This IP has directly access to the BK2, no other web pages visits, manipulate the content of CVE-2012-4792 0day and do some test from GBN.com. The IP is located in South Korea.

As you can see the attackers have use massively VPN connexions in order to connect themselves to BK2. If you compare the “Last-Modified” HTTP headers of the samples, you can see that they are corresponding to the last three different IPs manipulations.

As we have the complete Apache logs, I was also able to analyze the attack surface of the watering hole campaign through GBN.

My first analysis was to see all successful hits to “index.html” file from 7 December to 17 December, without any segregation. By clicking on the following link you will access to a Google Fusion Table providing all associated information’s.

alljap-all-hits

You can find also the TOP 10 of countries how have hit the exploit.

[table "9" not found /]

My second analysis was to see all potential successful exploitation targeting “MSIE 8.0“, from 7 December to 17 December. By clicking on the following link you will access to a Google Fusion Table providing all associated information’s.

alljap-msie8-hits

You can find also the TOP 10 of countries how have hit the exploit.

[table "10" not found /]

You can see that the potential success rate, compared to the visitors of GBN is very low. The fact to use a 0day only capable to target MSIE 8.0 was clearly a limiting point.

As explained at the beginning of the blog post, the post is only a small part of that has been analyzed. Jindrich Kubec and me will provide you additional information’s soon.

New Adobe PDF Reader 0day and Acrobat Found Exploited in the Wild

3

FireEye team has report a new Adobe Reader and Acrobat zero day exploited in the wild. This new 0day allow exploitation of the latest Adobe PDF Reader 9.5.3, 10.1.5, and 11.0.1 with sandbox bypass. In the information’s provided on FireEye blog post, it seem that two DLLs are dropped by the malicious PDF and that fake error message appears.

Adobe has acknowledge a potential vulnerability in his latest PDF Reader through a post on PSIRT (Product Security Incident Response Team) blog.

In the screenshot provided by FireEye, who don’t provide a lot of details, we can see a call to a “/index.php” page, which will potentially mean that the PDF 0day is streamed from the PHP file. Also we can observe that the involved user agent is MSIE 7 (aka Internet Explorer 7) under windows NT 5.1 (aka Windows XP).

According to a post on threatpost.com:

Attackers are using malicious PDFs posing as an application for an international travel visa to exploit a zero-day vulnerability in Adobe Reader and Acrobat.

Happy 0day Hunting

Despite the lack of information’s, after some researches yesterday night, I found the following file “Visaform Turkey.pdf” (f3b9663a01a73c5eca9d6b2a0519049e).

And through other researches, we found at 10pm the supposed C&C server aka “http://bolsilloner.es/index.php“.

Visaform Turkey.pdf” was submitted on VirusTotal the 2013-02-11 and was recognized as ”HEUR:Exploit.Script.Generic” at this time. This file was also submitted on malware tracker the 2013-02-12 and you can find some interesting information in this submission. Also the same file was submitted the 2013-02-13 to Wepawet. C&C server was submitted to jsunpack the 2013-02-13 without any associate outputs.

Adobe Security Advisory APSA13-02

Adobe PSIRT has release a security advisory APSA13-02 regarding two vulnerabilities CVE-2013-0640 (base CVSS score of 9.3) and CVE-2013-0641 (base CVSS score of 9.3) in Adobe Reader and Acrobat XI (11.0.01 and earlier), X (10.1.5 and earlier) and 9.5.3 and earlier for Windows and Macintosh. Also this security advisory confirm the exploitation of these vulnerabilities in targeted attacks through spear phishing campaign. Adobe is working on the issue and will provide updated versions asap. Affected softwares are:

  • Adobe Reader XI (11.0.01 and earlier) for Windows and Macintosh
  • Adobe Reader X (10.1.5 and earlier) for Windows and Macintosh
  • Adobe Reader 9.5.3 and earlier 9.x versions for Windows, Macintosh and Linux
  • Adobe Acrobat XI (11.0.01 and earlier) for Windows and Macintosh
  • Adobe Acrobat X (10.1.5 and earlier) for Windows and Macintosh
  • Adobe Acrobat 9.5.3 and earlier 9.x versions for Windows and Macintosh

Regarding Adobe security advisory, the vendor recommend, for users of Adobe Reader XI and Acrobat XI for Windows, as workaround to enable “Protected View“. To enable this setting, choose the “Files from potentially unsafe locations” option under the Edit > Preferences > Security (Enhanced) menu. The problem is that despite “Protected Mode” is activated, and as discussed on Twitter with @artem_i_baranov, and also mentioned by Ars Technica, “Protected View” is off when using the default version.

adobe-reader-protected-view

According to the documentation of “Protected View“:

When Protected View in enabled, PDFs are displayed in a restricted environment called a sandbox.

So it means, that by default sandbox is deactivated during display of PDFs.

Also Mac OS X users, and Linux users are not protected by this workaround who is only available for Windows.

Vendors Informations

FireEye has release new details regarding the payload used by the vulnerabilities. Also they point the fact on the high usage of Italian in the JavaScript embedded in the malicious PDF file.

Sophos has release a screenshot of the “Visaform Turkey.pdf” file and additional informations.

Visaform Turkey.pdf“ Sample Analysis

Based on the poor sample we found on malware tracker (please re-enable the download functionality !), we started to analyse it.

First interesting information: It could be that the “Protected Mode” could be bypassed via pdf properties. After some researches it doesn’t seem linked.

trusted-mode-false

Second interesting information: The date in the document appear to be f****ng old !!!! (2012-11-08).

date-of-creation

Third sHOGG function is used to decrypt a bunch of variables in the code.

sHOGG-function

By using this function on certain variables, we can confirm that the following Adobe Readers were targeted:

  • 10.0.1.434
  • 10.1.0.534
  • 10.1.2.45
  • 10.1.3.23
  • 10.1.4.38
  • 10.1.4.38ARA
  • 10.1.5.33
  • 11.0.0.379
  • 11.0.1.36
  • 9.5.0.270
  • 9.5.2.0
  • 9.5.3.305

oTHERWISE-pRENDENDO

Also some special cases, for some specific languages and only with Reader 9.502 or 10.104, are forced.

languages-special-cases

I also can confirm that the code is heavily obfuscated with bunch of variable and functions names in Italian, like “dIAVOLO”, “bENEDETTO”, “sENTIRSI”, “aPPARENZA”, “fISAMENTE”, “pRESUNSI”, “cOCOLLE”, “sCHIUMA”, “pENITENZA”, etc.

esperanza

Regarding different sources, files dropped by the PDF:

  • L2P.T” (3a2547af14b5621f43481a70f32ccef3). Analysis on VirusTotal.
  • LangBar32.dll” (97777F269AE807891DAC4B388C66A952). Analysis on VirusTotal.
  • Visaform Turkey.pdf” (F475A43D374334197099ADA17720EB00). Analysis on VirusTotal.
  • D.T” (CB33E97F46A219804DDB373FF982D694). Analysis on VirusTotal.

As @binjo has released the code of Adobe Javascript, I also release my studies on it.

I will keep you in touch, in this post, if I have any additional information’s.

Go to Top