Firefox Under Fire: Anatomy of latest 0-day attack

On the August 6th, the Mozilla Foundation released a security update for the Firefox web browser that fixes the CVE-2015-4495 vulnerability in Firefox’s embedded PDF viewer, PDF.js. This vulnerability allows attackers to bypass the same-origin policy and execute JavaScript remotely that will be interpreted in the local file context. This, in turn, allows attackers to read and write files on local machine as well as upload them to a remote server. The exploit for this vulnerability is being actively used in the wild, so Firefox users are advised to update to the latest version (39.0.3 at the time of writing) immediately.

In this blog we provide an analysis of two versions of the script and share details about the associated attacks against Windows, Linux and OS X systems.

According to ESET’s LiveGrid® telemetry, the server at the IP address 185.86.77.48, which was hosting the malicious script, has been up since July 27, 2015. Also we can find corroboration on one of the compromised forums:

image1

Operatives from the Department on Combating Cybercrime of the Ministry of Internal Affairs of Ukraine, who responded promptly to our notification, have also confirmed that the malicious exfiltration server, hosted in Ukraine, has been online since July 27, 2015.

According to our monitoring of the threat, the server became inactive on August 8, 2015.

 

The script

The script used is not obfuscated and easy to analyze. Nevertheless, the code shows that the attackers had good knowledge of Firefox internals.

The malicious script creates an IFRAME with an empty PDF blob. When Firefox is about to open the PDF blob with the internal PDF viewer (PDF.js), new code is injected into the IFRAME (Figure 2). When this code executes, a new sandboxContext property is created within wrappedJSObject. A JavaScript function is written to the sandboxContext property. This function will later be invoked by subsequent code. Together, these steps lead to the successful bypass of the same-origin policy.

Code that creates sandboxContext property

The exploit is very reliable and works smoothly. However, it may display a warning which can catch the attention of tech-savvy users.

The warning message showed on compromised site

After successful exploitation of the bug, execution passes to the exfiltration part of code. The script supports both the Linux and Windows platforms. On Windows it searches for configuration files belonging to popular FTP clients (such as FileZilla, SmartFTP and others), SVN client, instant messaging clients (Psi+ and Pidgin), and the Amazon S3 client.

The list of collected files on Windows at the first stage of attack

These configuration files may contain saved login and password details.

On the Linux systems, the script sends following files to the remote server:

  • /etc/passwd
  • /etc/hosts
  • /etc/hostname
  • /etc/issue

It also parses the /etc/passwd file in the order to get the home directories (homedir) of users on the system. The script then searches files by mask in the home directories collected, and it avoids searching in the home directories of standard system users (such as daemon, bin, sys, sync and so forth).

The list of collected files on Linux at stage 1 of attack

It collects and uploads such files as:

  • history (bash, MySQL, PostgreSQL)
  • SSH related configuration files and authorization keys
  • Configuration files for remote access software – Remmina
  • FileZilla configuration files
  • PSI+ configuration
  • text files with possible credentials and shell scripts

As is evident here, the purpose of the first version of the malicious script was to gather data used mostly by webmasters and site administrators. This allowed attackers to move on to compromising more websites.

 

The second version

The day after Mozilla released the patch for Firefox the attackers decided to go “all-in”: they registered two new domains and improved their script.

The two new malicious domains were maxcdnn[.]com (93.115.38.136) and acintcdn[.]net (185.86.77.48). The second IP address is the same one as used in the first version. Attackers selected these names because the domains look as if they belong to a content delivery network (CDN).

The improved script on the Windows platform not only collects configuration files for applications; it also collects text files containing almost all combinations of words of possible value to attackers (such as password, accounts, bitcoins, credit cards, exploits, certificates, and so on):

List of files collected on Windows during the second attack stage

The attackers improved the Linux script by adding new files to collect and also developed code that works on the Mac OS X operating system:

List of files collected on Macs during the second stage of an attack

Some Russian-speaking commentators misattributed this code to the Duqu malware, because some variables in the code have the text “dq” in them.

 

A copycat attack

Since the bug is easy to exploit and a working copy of the script is available to cybercriminals, different attackers have started to use it. We have seen that various groups quickly adopted the exploit and started to serve it, mostly on adult sites from google-user-cache[.]com (108.61.205.41)

This malicious script does all the same things as the original script, but it collects different files:

The list of collected files used in copycat attack

 

Conclusion

The recent Firefox attacks are an example of active in-the-wild exploitation of a serious software vulnerability. The exploit shows that the malware-writers had a deep knowledge of Firefox internals. It is also an interesting one, since in most cases, exploits are used as an infection vector for other data-stealing trojans. In this instance, however, that was not necessary, because the malicious script alone was able to steal sensitive files from victims’ systems.

Additionally, the exploit started to be reused by other malware operators shortly after its discovery. This is common practice in the malware world.

ESET detects the malicious scripts as JS/Exploit.CVE-2015-4495. We also urge Firefox users to update their browser to the patched version (39.0.3). The internal Firefox PDF reader can also be disabled by changing the pdfjs.disabled setting to true.

 

Indicators of Compromise

A partial list of compromised servers:

hxxp://www.akipress.org/

hxxp://www.tazabek.kg/

hxxp://www.super.kg/

hxxp://www.rusmmg.ru/

hxxp://forum.cs-cart.com/

hxxp://www.searchengines.ru/

hxxp://forum.nag.ru/

Servers used in attack:

maxcdnn[.]com (93.115.38.136)

acintcdn[.]net (185.86.77.48)

google-user-cache[.]com (108.61.205.41)

Hashes (MD5):

0A19CC67A471A352D76ACDA6327BC179547A7A25

2B1A220D523E46335823E7274093B5D44F262049

19BA06ADF175E2798F17A57FD38A855C83AAE03B

3EC8733AB8EAAEBD01E5379936F7181BCE4886B3

 
 

Credit:  Anton Cherepanov

Major Android Bug is a Privacy Disaster (CVE-2014-6041)

 

On the night of September 7, 2014, Joe Vennix of Rapid7’s Metasploit Products team wrote, “I did not believe this at first, but after some testing it seems true: in AOSP browser before Android 4.4, you can load javascript into any arbitrary frame or window […]” and provided a Metasploit module to exploit this condition. After some of the usual testing and confirmation of the vulnerability, this module is available in all versions of Metasploit.

 

The vulnerability that Joe didn’t believe is CVE-2014-6041, and was disclosed on September 1, 2014 by Rafay Baloch on his blog, Rafay Hacking Articles. By malforming a javascript: URL handler with a prepended null byte, an attacker can avoid the Android Open Source Platform (AOSP) Browser’s Same-Origin Policy (SOP) browser security control.

 

What this means is, any arbitrary website (say, one controlled by a spammer or a spy) can peek into the contents of any other web page. Imagine you went to an attackers site while you had your webmail open in another window — the attacker could scrape your e-mail data and see what your browser sees. Worse, he could snag a copy of your session cookie and hijack your session completely, and read and write webmail on your behalf.

 

This is a privacy disaster. The Same-Origin Policy is the cornerstone of web privacy, and is a critical set of components for web browser security. Oh, and it gets worse.

 

When this vulnerability was announced by Balcoh, it was met with… total silence. There has been no acknowledgement of the bug from Google, as far as we can tell. There’s no listing of this bug on CVEDetail’s readout of Android issues, and no chatter (we could find) in the Android security community about this bug.

 

Research and testing is still ongoing to plumb the depths of this issue. We’d like to pin down exactly when the bug was fixed, and to determine just how widespread this vector really is. After all, pre-4.4 builds of Android account for about 75% of the total Android ecosystem today.

 

More importantly, 4.2 (Jellybean) and prior phones account for nearly 100% of off-the-shelf, lower-end prepaid phones from major manufacturers and carriers. They still ship the unsupported AOSP browser. These are the kinds of phones that account for a huge chunk of total market share, and yet are still vulnerable to this bug and the WebView addJavascriptInterface vulnerability.

 

While the AOSP browser has “been killed off” by Google, it is wildly popular, even on modern devices used by sophisticated users who prefer the stock browser over Google Chrome, Firefox, Dolphin, or other browsers. A quick search for “AOSP browser” turns up page after page of instructions and HOWTOs on re-installing this defunct, unsupported-by-Google software. Among the top pages, I could find absolutely no mention of security concerns in reinstalling the original stock browser.

 

Later this week, I’ll have a demo of the bug all videoed up that’s sufficiently shocking. I’d really like to continue the conversation about security for mid- to low-end devices that people trust with the details of their lives. I hope this Metasploit module (which is available today in all versions of Metasploit) spurs along the conversation on what we can do to ensure that the users of normal, off-the-shelf, brand-new phones aren’t so vulnerable to privacy violations.

 

 

CREDIT:  Tod Beardsley