JSGuard Addon IEEE paper

Browser JS Guard: Detects and Defends against Malicious JavaScript Injection based Drive by Download Attacks Ravi Kishore K, Mallesh M, Jyostna G and P R L Eswari

Samavedam Satyanadha Sarma

Centre for Development of Advanced Computing, Hyderabad Email: {ravikishorek,malleshm,gjyostna,prleswari}@cdac.in http://www.cdachyd.in

CERT-IN, DIT, New Delhi Email: [email protected] http://www.cert-in.org.in

whether they are trusted or untrusted sites. Attackers are taking this as an advantage and tricking the users to download malicious software. This is one of the easy channels for an attacker, as he can enter into the user‘s end system without exploiting any vulnerability. It is also possible for attacker to exploit browser vulnerabilities and download malicious code into end system when user visits compromised websites, knowingly or unknowingly. One such type of popular attack is Drive by Download attack [16], [17].

Abstract—In the recent times, most of the systems connected to Internet are getting infected with the malware and some of these systems are becoming zombies for the attacker. When user knowingly or unknowingly visits a malware website, his system gets infected. Attackers do this by exploiting the vulnerabilities in the web browser and acquire control over the underlying operating system. Once attacker compromises the users web browser, he can instruct the browser to visit the attackers website by using number of redirections. During the process, users web browser downloads the malware without the intervention of the user. Once the malware is downloaded, it would be placed in the file system and responds as per the instructions of the attacker. These types of attacks are known as Drive by Download attacks. Now-a-days, Drive by Download is the major channel for delivering the Malware. In this paper, Browser JS Guard an extension to the browser is presented for detecting and defending against Drive by Download attacks via HTML tags and JavaScript.

In this attack, initially the attacker compromises a legitimate web server and inserts a script in web application. When user accesses the web site that was compromised by the attacker, web server sends the injected script along with the requested page. This script is either an exploit script or it imports exploit from a central server which is controlled by the attacker and this import is either a direct inclusion of the resources from the remote server or through a number of redirections the browser is instructed to follow. A redirection starts from one web server to the other that actually plays part of hop points. After following a number of redirections the users request reaches the central exploit server. The central exploit server sends the exploit script depending on the fingerprint of the user end system. Fingerprinting is done by using the User-Agent field present in the HTTP request coming from the user‘s web browser. Fingerprinting includes web browser type and underlying operating system along with version details. Imported exploit script is used to exploit the vulnerability present either in the browser/ browser plug-in/ webpage. This exploit instructs the browser to visit the malware distribution site. This is, actually, when the Drive by Download starts. Malware executables are downloaded and user‘s end system automatically installs and executes the malicious code.

Keywords—Malware, HTML tags, DOM Change Methods, JavaScript Functions, Web Browser, Web Browser Extensions, Drive by Download Attacks.

I.

I NTRODUCTION

With the increasing usage of Internet, the attacking channels are flagging towards the usage of web browsers and web applications widely. Browsers have evolved from static document renderers to todays sophisticated execution platforms for web applications. Browsers are very much susceptible to attacks through exploitable vulnerabilities. Attacker uses browser/ browser plug-in/ webpage as vehicles to infect end system without directly connecting to them. Attacks are launching through memory, web content, web markup or scripting language level exploits. In a typical XSS attack, due to the vulnerability in validating the input, attacker can inject malicious JavaScript code as a comment in the blog or reply to a post. This injection leads to the execution of malicious JavaScript code with the privileges of web application. This injection affects the users who visit these websites. This makes attacker get unauthorized access to data stored at users end system without their knowledge.

II.

In the earlier days attackers used vulnerabilities in the operating system configuration or installed applications for exploitation. With the advent of web, attackers have changed their target to web browser and its plug-ins. Some of the current day attacks such as XSS (Cross Site Scripting) and CSRF (Cross Site Request Forgery) does not require exploiting the vulnerabilities in the client‘s browser or system. In these

Now-a-days, it became very easy for any user to download and install the required software from web without checking 978-1-4799-2259-14/$31.00©2014

BACKGROUND

92

Fig. 1: Drive by Download attack scenario - Exploit code resides on Target server

Fig. 2: Drive by Download attack scenario Exploit code resides on Attacker Server

attacks, malicious code is injected into the webpage and attacker tricks the client to visit the infected webpage for getting access to user‘s web browser. Through this Drive by Download attack is carried out.

web browser runs the exploit code received from the attacker‘s server. Detailed analysis on mechanisms used by JavaScript injection attacks is carried out and the result is shown in Figure 3. From the analysis, it is understood that Hidden iframe and JS Obfuscation are the main mechanisms for initializing the attack. Sample obfuscated codes found in various attacks are presented below.

In some scenarios, Drive by Download attack is initiated from a genuine web server. Attacker initially injects the malicious code into the web server and then tricks the user to visit the web page in which the malicious code is injected. This injected malicious code typically written in JavaScript language redirects browser requests and downloads exploit code. Injected malicious code allows execution of downloaded exploit code by exploiting vulnerabilities in web browser.

Sample 1: Obfuscated Code:

If successful, the attack will be able to execute arbitrary code with the privileges of the user. During this process it uses Redirections (to other malicious websites), Fingerprinting and Obfuscations. Drive by Download attack is explained in detail with the following scenarios.

De Obfuscated Code: document.write(’’);

In the first scenario, attacker prepares the attack using a genuine web server. Attacker injects into the target web server, PHP code as well as web content to redirect the user to PHP code through iframe tag. Web browser accesses the injected web page when connected to the target web server. After accessing the injected web page from the server, web browser gets redirected to PHP page. This redirection is possible through iframe tag. Now the web server sends the attack code or payload to the web browser if it is vulnerable. Target browser runs the exploit script received from the target web server as it is from the same origin. This is one scenario for Drive by Download attack, where the exploit code also resides in the target web server as shown in Figure 1.

Sample 2: Obfuscated Code:

De Obfuscated Code: (function() { var pzt = document.createElement(’iframe’); pzt.src = ’http://www.betterbailbonds.net/ VLNSec01/cnt.php’; pzt.style.position = ’absolute’; pzt.style.border = ’0’; pzt.style.height = ’1px’; pzt.style.width = ’1px’; pzt.style.left = ’1px’; pzt.style.top = ’1px’;

In second scenario exploit code resides on attacker server as shown in Figure 2. In this scenario, attacker injects the content into target web server. Injected content refers to a script residing in attacker‘s web server. Target browser fetches the injected web page from the target web server. Whenever browser renders the fetched web page, client browser is being redirected to a script on attacker‘s web server which is referred by using Script src tag. Attacker‘s web server delivers the exploit code to the target browser if it is vulnerable. Target

if (!document.getElementById(’pzt’)) {

93

var os=PluginDetect.OS;} ... (some bytes skipped). try{ var adobe=PluginDetect.getVersion("AdobeReader");} ... (some bytes skipped).

The JavaScript code uses a publicly available JavaScript library to collect information about browser plugins. Once it has collected the information it makes a POST request to the server indicating whether the victim has Java and Adobe Acrobat Reader installed in the system. The server redirects the browser to a server that makes another redirection very likely depending on the plugins detected on the victim. The server has returned HTML code that is embedding some Flash content in the browser as well as a new iframe and encoded JavaScript content with String.fromCharCode() function.

Fig. 3: Mechanisms used by JavaScript Injection Attacks

The exploit code in this exploit is matching with the Exploit Kit known as Magnitude/Popads.

document.write(’’); document.getElementById(’pzt’).appendChild( pzt); } })();

III.

R ELATED W ORK

If the obfuscated code of the Sample code is de-obfuscated then it is leading to a hidden iframe which redirects the user to an evil URL.

WANG has done some good work in this area. In his approach he is extracting the features of malicious javascript statically[1].

Consider an example of a website compromised in the recent times. “PHP.net” has been compromised and it is being redirected to an exploit kit as per the sources and this attack is a form of Drive by Download attack [19].

In inline code analyzer, authors discussed inline code analysis for malicious JavaScript elements. The elements include string functions and HTML tags[2]. In Browser guard, authors discussed about the file download scenario and depending on the scenario, blocking the execution of any file that is automatically downloaded without any knowledge of the user. This tool is developed for IE browser only[3].

In this attack, the attackers built a connection to inject a malicious iframe in the PHP.net website that was redirecting to an Exploit Kit. It seems that as reported by Google the JavaScript file www.php.net/userprefs.js had some injected obfuscated content at the end of the file. Part of injected obfuscated code is as shown below

Various types of hidden iframe injections into the web page are well explained by Bin Liang [4].

(function(Anv){var LUI="M\xaa\xb0\xa9\xf5n-\x92\xe0\ xb5S\xc7\x81,\x0b\x0f\x1e\x15\xb0\xa6BL\x16\x7f %\x0aCDkFDt{bszH2qEdpNFX\x173\x18@Y\x7fZ}\x1bk\ x08%\x05*:7{bedFmˆHi\x0a%\x0f\x20N’KDnBSIww’ z8fol;pxoo:\x0a%\x00n]nA˜ C o l ..(some bytes skipped)).

JStill captures some essential characteristics of obfuscated malicious code by function invocation based analysis. It also leverages the combination of static analysis and lightweight runtime inspection so that it not only detects, but also prevents the execution of the obfuscated malicious JavaScript code in browsers [5].

De-obfuscated content for the above obfuscated JavaScript code is shown below

An integrated approach of using honey client with the abnormal visibility recognition detection is chosen in this approach for increasing the malicious website detection rate and speed. This integrated approach consists of Spidering, HTML Parser, JavaScript Engine, Honey client and abnormal visibility detector [6].