Browser Guard a Behavior-Based Solution To

5/13/2018 Browser Guard a Behavior-Based Solution To - slidepdf.com

http://slidepdf.com/reader/full/browser-guard-a-behavior-based-solution-to 1/8

IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 29, NO. 7, AUGUST 2011 1461

BrowserGuard: A Behavior-Based Solution toDrive-by-Download Attacks

Fu-Hau Hsu, Chang-Kuo Tso, Yi-Chun Yeh, Wei-Jen Wang, and Li-Han Chen

Abstract —Along with an increasing user population of variousweb applications, browser-based drive-by-download attacks soonbecome one of the most common security threats to the cybercommunity. A user using a vulnerable browser or browser plug-ins may become a victim of a drive-by-download attack rightafter visiting a vicious web site. The end result of such attacksis that an attacker can download and execute any code on thevictim’s host. This paper proposes a runtime, behavior-basedsolution, BrowserGuard, to protect a browser against drive-by-download attacks. BrowserGuard records the download scenarioof every file that is loaded into a host through a browser.Then based on the download scenario, BrowserGuard blocks

the execution of any file that is loaded into a host without theconsent of a browser user. Due to its behavior-based detectionnature, BrowserGuard does not need to analyze the source fileof any web page or the run-time states of any script code, suchas Javascript. BrowserGuard also does not need to maintain anyexploit code samples and does not need to query the reputationvalue of any web site. We utilize the standard BHO mechanism of Windows to implement BrowserGuard on IE 7.0. Experimentalresults show that BrowserGuard has low performance overhead(less than 2.5%) and no false positives and false negatives forthe web pages used in our experiments.

Index Terms—drive-by-download attack, heap spray, malware,Web browser, intrusion detection, system security.

I. INTRODUCTION

IN THIS PAPER we propose a behavior-based solution,

called BrowserGuard, against drive-by-download attacks

which are one of the most dangerous security threats nowa-

days. A drive-by-download attack utilizes the vulnerabilities

in a browser or browser plug-ins to download and execute

attack code in the address space of the browser without the

consent of the browser users. A drive-by-download attack

is launched through malicious web sites. When a user of a

vulnerable browser visits a malicious web site, the user’s host

will be compromised immediately. According to [1], more

than 1.3% query results provided by Google point to a webpage that performs drive-by-download attacks. Besides, Frei et

al. [2] observed that only 60% of Google users use the latest

version of their browsers. The above research results show

that there are many drive-by-download traps in the Internet

to prey on hosts that use vulnerable browsers or browser

plug-ins. Due to the potent destructive power of the drive-

by-download attacks, many promising solutions have been

Manuscript received 1 August 2010; revised 4 January and 21 February2011.

C.-K. Tso is with the Department of Computer Science and InformationEngineering, National Central University, Jhongli City, Taoyuan County,32001 ROC (e-mail: [email protected]).

F.-H. Hsu, Y.-C. Yeh, W.-J. Wang and L.-H. Chen are with National CentralUniversity.

Digital Object Identifier 10.1109/JSAC.2011.110811.

proposed. However, many of them are bothered by non-trivial

false positives, false negatives, or performance overhead.

This paper proposes a runtime, behavior-based solution,

BrowserGuard, to protect a browser against drive-by-download

attacks. BrowserGuard records the download scenario of every

file that is loaded into a host through a browser. Then based

on the download scenario, BrowserGuard blocks the execution

of any file that is loaded into a host without the consent of

a browser user. Due to its behavior-based detection nature,

BrowserGuard does not need to analyze the source file of any

web page or the run-time states of any script code, such asJavascript. BrowserGuard also does not need to maintain any

exploit code samples and does not need to query the reputation

value of any web site.We utilize the standard BHO mechanism (subsection II-B4)

of Windows to implement BrowserGuard on IE 7.0, which is

the most popular browser nowadays [3] and is the major target

of many drive-by-download attacks [4]. Experimental results

show that BrowserGuard has low performance overhead (less

than 2.5%) and negligible false positives and false negatives.

The remainder of this paper is organized as follows. Section

II discusses the attacking model of typical drive-by-download

attacks and the background knowledge of BrowserGuard.Section III illustrates the mechanism and implementation

details of BrowserGuard. Section IV includes our effectiveness

and performance evaluation. Section V discusses other related

research of this security problem. Section VI concludes this

paper.

II . BACKGROUND

In this section we discuss the details of drive-by-download

attacks, the APIs used by IE 7.0 to download a file, BHO, and

API hooking.

A. Drive-by-Download Attacks

A drive-by-download attack is launched through a web page

with crafted malicious content. The web server that hosts the

vicious web page may be owned by an attacker or may be

compromised by an attacker or may be a normal benign host

which allows other persons to put their content, such as an

advertisement, in the web pages of the host. To accomplish

a drive-by-download attack, a Malware Bootstrap Function

(MBF) must be injected into the address space of the attacked

browser first. Then the execution flow must be transferred

to the MBF through some vulnerability in the browser or a

plug-in in the browser. In turn, the MBF will download moremalware into the compromised host and execute the malware.

An MBF can be injected into the attacked browser either by a

0733-8716/11/$25.00 c 2011 IEEE



1462 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 29, NO. 7, AUGUST 2011

Javascript program or by a long string in some HTML tags in a

web page. The vulnerabilities utilized to transfer the execution

flow of a browser to an MBF can be divided into the following

three types.

C1 misuse APIs [5]–[8]

C2 memory corruption errors [9]–[13]

C3 initialization errors [14]

Type C1 vulnerability is usually created by a browser plug-in, such as ActiveX Control, which erroneously exports a

flow-control function to its users. The flow-control function

allows its user to transfer the execution of a program into

any location specified by the user. Type C2 vulnerability is

usually generated by bugs in browser code or browser plug-ins.

The most famous one is buffer overflow bugs [9]–[12]. Even

though many secure solutions, such as ASLR, DEP, GS, and

so on, have been developed to solve the memory corruption

error problem, attackers continue designing new approaches,

such as heap sprays [15], to invalidate the protection. Type

C3 vulnerability is caused by some exception conditions that

a Javascript engine cannot handle correctly.

B. IE Components Regarding to File Download and File

Execution

BrowserGuard blocks drive-by-download attacks based on

the download and execution scenario of a file. There are

three components involved in the file download operation and

the file execution operation in IE. They are file download

component, file execution component, and event component.

The first two components consist of some Application Pro-

gramming Interfaces (API), which are responsible to file

download and file execution. The third component consists of various events of a browser. The following subsections give

detailed discussion about these components.

1) File Download Component: The following four reasons

cause an IE browser legally download a file to a local host.

First, when browsing a web page, in order to display the

web page on the Internet Explorer (IE) browser, IE needs to

download all the objects described in the web page, including

the source code of the web page, script files, Cascading Style

Sheets (CSS), and multimedia files, to local storage. Second,

when a browser user clicks a hyperlink to navigate another

web page, IE needs to download the html file. Third, when a

user clicks the download button in a download dialogue boxto download a file, IE downloads the file. (The dialogue box is

popped up due to a user’s clicking a URL which points to a file

that the browser cannot display on its window.) Fourth, when a

user clicks the hyperlink of an ASP/PHP/JSP file which creates

a new file or when a user puts the cursor over a hyperlink and

clicks the right button of a mouse to open a context menu and

download a file, IE downloads the related file. File download

caused by the above four reasons is accomplished by the file

download component. Files downloaded to a host due to one

of the above reasons are called benign files. Files downloaded

to a host through drive-by-download attacks (Subsection II-A)

are malware.Inside the file download component, IE follows the fol-

lowing steps to download a file. First, Internet Explorer

calls API InternetConnect to open a connection and

receive a handle. Second, using the above internet handle,

Internet Explorer calls API HttpOpenRequest to assign

a name to an object (file). Third, Internet Explorer calls API

InternetReadFile to download the file. Finally, Internet

Explorer calls API WriteFile to save the file into the

Temporary Internet Files directory.

Except the above execution path, there exists another

execution path used by IE to download a file. This ex-ecution path is used when an IE user manually down-

loads a file by clicking the right button of a mouse

or by clicking a hyperlink of a server-side page which

creates a new file. When this happens, IE calls API

DoFileDownload first to open a download window. Next,

it calls APIs InternetConnect, HttpOpenRequest,InternetReadFile, and WriteFile one by one. Finally

based on the directory specified by the user, IE uses APIWriteFile to save the downloaded file in the specified

directory.

2) File Execution Component: IE calls API

CreateProcessW to execute an executablefile. API CreateProcessW in turn calls API

CreateProcessInternalW to load the image of

the file. After the above operations, IE creates a new child

process.

3) Event Component: IE provides various events to indicate

the occurrence of different activities related to itself. Event

BeforeNavigate2 is one of them. When an object, such

as a window element or a frameset element in the DOM

architecture, is going to be browsed, BeforeNavigate2

will be issued to indicate this activity. The event component of

BrowserGuard allows BrowserGuard to more precisely decide

under what situation a file is downloaded.4) Browser Helper Object (BHO) and API Hooking: A

Microsoft BHO [16] is a DLL module that will be loaded

into the address space of an IE browser, called the host

browser of the BHO, when it starts up. The BHO keeps

staying in the address space of the host browser until the

browser finishes. Because a BHO is executed in the same

address space as its host browser, the BHO can perform any

operation that the host browser is allowed to do. The major

component of BrowserGuard is implemented in a BHO, called

BrowserGuard-BHO.

API hooking [17] is a technique that allows a programmer

to intercept function calls or messages or events passedbetween software functions. BrowserGuard uses Detours [18]

to implement API hooking. Detours replaces the first few

instructions of a target function with an unconditional jump to

a detour function provided by a user. The detour function then

transfers the execution flow of a process back to the original

target function.

III. IMPLEMENTATION

This section describes the design principle, design goals,

and implementation details of BrowserGuard. According to the

file download steps of a browser, BrowserGuard sets severalcheck points on a browser and the Windows kernel to detect

secret download and blocks the execution of downloaded

malware at runtime.



HSU et al.: BROWSERGUARD: A BEHAVIOR-BASED SOLUTION TO DRIVE-BY-DOWNLOAD ATTACKS 1463

IE

BrowserGuard-BHO

List Server

White-list

Blacklist

User Space

Kernel Space

BrowserGuard-Kernel Named Pipe

Fig. 1. Structure, major components, and major data structures of Browser-Guard.

A. Structure of BrowserGuard

As fig. 1 shows, BrowserGuard consists of a BrowserGuard-

BHO in every IE process, a BrowserGuard-Kernel in the

kernel space, and a list server process. Each host has only

one list server process. But the host may have several

browsers executing simultaneously; hence, there may existmultiple BrowserGuard-BHOs in a host at the same time.

A BrowserGuard-BHO communicates with the list server

process through a named pipe. Multiple BrowserGuard-BHOs

can communicate with the list server process simultaneously.

The list server process contains two lists, a white-list and

a blacklist. The white-list records the URLs of benign files

(Subsection II-B1) and the hash vales of benign executable

files. The blacklist records the hash values of detected ma-

licious files. Downloading benign files to a host due to the

first three reasons discussed in Subsection II-B1 will trigger

the system to issue event BeforeNavigate2, which in

turn will trigger the execution of the BrowserGuard-BHOfunction, before_navigate, to record the URLs from

which benign files are downloaded (Subsection II-B1). Be-

sides, BrowserGuard also utilizes BrowserGuard-BHO to hook

detour functions (Subsection II-B4) to functions in the file

download component and functions in the file execution com-

ponent. The hooked target functions in the file download com-

ponent contain DoFileDownload, InternetReadFile,

and WriteFile. The hooked function in the file execution

component is CreateProcessInternalW.

BrowserGuard-Kernel is a kernel component of Browser-

Guard. BrowserGuard-Kernel enforces the following two tasks

to prevent the execution of malware and illegal modifi-cations of a white-list and blacklist. First, BrowserGuard-

Kernel ensures that the execution of a program is issued

by CreateProcessInternalW which has been hooked

by BrowserGuard. Second, BrowserGuard-Kernel denies a

request to modify a white-list, if the request is not is-

sued through the code in function before_navigate or

DoFileDownload of BrowserGuard.

B. Work fl ow of BrowserGuard

BrowserGuard blocks drive-by-download attacks by deny-

ing the execution of malware (subsection II-B1). Browser-Guard provides its protection to a host through a two-phase

mechanism and a kernel component. In the first phase, namely

the filtration phase, BrowserGuard distinguishes malicious

files from benign ones based on the situations under which

the files are downloaded to a local host. In the second phase,

namely the prohibition phase, BrowserGuard denies the re-

quest to execute malicious files. The kernel component blocks

attempts to bypass BrowserGuard. This and next subsections

describe the techniques.

1) Filtration Phase: To be able to distinguish malicious

files from benign ones, BrowserGuard needs to know thesituation under which a file is downloaded to a local host.

With the information, BrowserGuard can deduce whether a

downloaded file is a benign one or malicious one. In order to

collect the required information, BrowserGuard installs several

check points to monitor the behavior of a browser.

The check point before_navigate is a BrowserGuard-

BHO function that is bound to event BeforeNavigate2, so

that the function is invoked whenever a BeforeNavigate2

event is issued. When before_navigate is called, it

records the URL of the related file in the white-list of

the list server process. As discussed in the previous sub-

section, a benign file download that is not triggered byclicking the hyperlink of an ASP/PHP/JSP file which cre-

ates a new file or by clicking the right mouse button

will always result in the BeforeNavigate2 event. Even

though clicking right mouse button does not trigger eventBeforeNavigate2, this file download request makes IE

to invoke DoFileDownload to perform the download.

DoFileDownload also contains the URL of the file that

is going to be downloaded to a local host. Figure 2 shows

the major functions, data structures, and operations involved

in the filtration phase.

While a user is surfing the WWW, a browser needs to

download various files. All these files are placed in a di-rectory called Temporary Internet Files and they

cannot be directly executed without the admission of the

browser user. On a BrowserGuard-protected browser, normal

file download triggers the execution of DoFileDownload

or before_navigate. Both functions connect to the list

server process of a host to record URLs in the white-list of

the process. The URLs are the URLs of the files that are

going to be downloaded to the host. The real download is

performed by API InternetReadFile, which in turn calls

API WriteFile to store the downloaded file.

The detour functions of InternetReadFile checks

whether the URL of the file that this function is asked todownload is within the white-list. If the URL is within the

white-list, the file is downloaded as usual; but if the URL is not

within the white-list and the first two bytes of the file is “MZ”,

after the file is downloaded to the local host, BrowserGuard

calculates the hash value of the file and adds the hash value

to the black list. “MZ” is the first two bytes of a PE format

file which is the most common format of Windows executable

files. Instead of using the filename extension to find executable

files, BrowserGuard uses “MZ” to find executable files. This

can prevent an attacker from naming an executable file with a

non-executable filename extension first and then changing its

filename extension back to an executable filename extensionbefore executing the file.

The hash value is calculated based on the first 512 bytes of

a file. BrowserGuard uses the hash value of a file to represent




BeforeNavigate2DoFileDownloadInternetConnect

HttpOpenRequest

InternetReadFile

WriteFile

URL

URL

URL

hash

hash

EventFile DownloadNormal download Download via context menu

BlackList White-list

Add to white-list

(URL or hash value)

Check white-list

(URL of hash value)

Add to blacklist

Possible route to

save a file

List Servers

Named Pipe

Internet Explorer

Fig. 2. Functions, data structures, and operations involved in the filtrationphase.

the file in the blacklist. Hence, BrowserGuard does not need

to compare every byte of two files to determine whether these

two files have the same content. This step can accelerate the

processing time of the prohibition phase and save storage

space.Except adding the hash value of a malicious file into the

blacklist, the detour function of InternetReadFile also

adds the hash value of a benign executable file into the white-

list. The hash values in the white-list are then used by the

detour function of WriteFile. WriteFile is used to write

a file into storage, such as a disk. Thus, when an executable

fi

le is written to a disk by WriteFile, its detour functionqueries the white-list to check whether the hash value of this

file is logged by InternetReadFile. If the hash value of

the file is not in the white-list, the file must be transformed

from another non-executable file after the non-executable file

is downloaded to the local host. For example, an attacker

may disguise a malware file as an image file first. After

the disguised file is downloaded to an attacked host by an

MBF, the MBF transforms the file into an executable file

and executes it. Because benign files are not supposed to be

handled in this way, executable files created on a disk using the

above methods are deemed as non-benign files (i.e. malicious

fi

les). WriteFile saves the hash values of thesefi

les intothe blacklist.2) Prohibition Phase: Inside an IE browser,

CreateProcessInternalW is used to execute an

executable file stored on a disk. BrowserGuard hooks this

API to ensure that the API will not execute malware.

BrowserGuard calculates the hash value of the executable

file first. Then BrowserGuard checks whether the white-list

and blacklist contain the same hash value. If the blacklist

does not contain the hash value but the white-list contains

the hash value, API CreateProcessInternalW runs the

executable file. Otherwise, it blocks the execution of the file.

C. Prevention of Checkpoint-Bypassing

Various checkpoints installed by BrowserGuard are the

critical instructions used to detect downloaded malware and

prevent the execution of the downloaded malware. If an

attacker can bypass these checkpoints, she/he can successfully

accomplish a drive-by-download attack on a BrowserGuard-

protected browser. BrowserGuard utilizes various approaches

to ensure that, if the download and execution of a program

do not follow the normal path and does not pass the pre-

defined checkpoints, BrowserGuard can detect it and block

the execution.1) Protecting the Checkpoints in DoFileDownload and

before_navigate: This subsection describes the ap-

proaches that BrowserGuard uses to prevent attackers from

adding URLs to the white-list by directly calling API

DoFileDownload and before_navigate from an MBF

or executing copied versions of these APIs in an MBF.

DoFileDownload and before_navigate connect to

the list server process in a host to record URLs in the white-

list of the process. Inside the kernel, BrowserGuard-Kernel

ensures only instructions inside functions DoFileDownload

and before_navigate can add a URL to the white-list. In

a BrowserGuard-protected browser, the URLs are transmittedfrom an IE process to a list server process. Thus, kernel

functions need to be used to accomplish this work. Hence,

by recording the return addresses used to return to API

DoFileDownload or before_navigate from the kernel

after the kernel transmits a URL from an IE process to the

white-list of a list server process, BrowserGuard-Kernel can

infer the addresses of the legal user space instructions that

can initialize the transmission. Thus, BrowserGuard can deny

any request to transmit a URL to the white-list of a list server

process if the request is not issued through instructions insideDoFileDownload and before_navigate.

Besides, even if an MBF directly calls DoFileDownloador before_navigate to add URLs of malware to the

white-list, BrowserGuard still can detect the behavior due to

the following reason: When the above behavior occurs, the ex-

ecution flow still needs to return to the MBF because the MBF

has to download and execute the malware or the execution flow

finally needs to transfer to CreateProcessInternalW

which is the only legal API inside a BrowserGuard-protected

browser to create a new process (subsection III-C2). On a

Windows system, due to DEP, the stack segment and data

segments of a process are not executable. Hence, an MBF can

only be stored in the heap segment of a process. As a result,

by checking whether the stack return addresses contain a heapaddress or the address of CreateProcessInternalW

when DoFileDownload or before_navigate is exe-

cuted, BrowserGuard can prevent these two APIs from being

directly called by an MBF.

2) Protecting the Checkpoint in

CreateProcessInternalW : To avoid that an MBF

bypasses the check point inside the detour function hooked

to CreateProcessInternalW by directly jumping to

the sixth byte of this function, BrowserGuard utilizes a

new software interrupt, BGSetFlag, to solve the problem.

BGSetFlag is an element of BrowserGuard-Kernel.

Because BGSetFlag is a software interrupt, after a threadinvokes this software interrupt in the user address space,

the thread switches from user mode into kernel mode and

the system will store the address (a return address) of the




instruction right after the calling instruction in the kernel

mode stack of the thread. For a process, the first execution

of BGSetFlag results in the recording of the above return

address, called anchor address of the process, and the setting

of the BG_CHECKED flag. Every subsequent execution of

BGSetFlag compares the return address stored in the kernel

mode stack of the process with the anchor address first. If

these two addresses are the same, the BG_CHECKED flagwill be set; otherwise, the flag is cleaned. Inside the kernel

address space, the native API in charge of the creation of a

new process checks the BG_CHECKED flag first. Only when

the flag is set, the API creates a new process and then cleans

the flag. Otherwise, it aborts the process creation request.

BrowserGuard adds an invocation statement of BGSetFlag

in the detour function of CreateProcessInternalW

to make sure that the detour function is executed when a

process creates a new process. Except BrowserGuard-Kernel,

the detour function of CreateProcessInternalW is

another place where BrowserGuard blocks the execution

of malware downloaded by a drive-by-download attack.The above approach is also used to prevent attackers from

bypassing the detour function of InternetReadFile.

IV. EVALUATION

In this section, we discuss the results of various experiments

that were made to evaluate the effectiveness and ef ficiency

of BrowserGuard. What follows are the specifications of the

hosts, operating systems, and browsers used in our experi-

ments. All browsers used in our experiments are IE 7.0 and are

executed in a guest machine. The guest machine is executed

on a host machine through VMware. The web server used in

our tests is installed in a remote Linux machine.

• local client machine:

– guest machine: (OS: Windows XP SP2 (32bit),

Browser: IE 7.0)

– VMware 7.0.1 (Memory: 1024 MB)

– host machine (OS: Windows 7 (32bit), CPU: Intel

Core2Duo CPU P8600 2.4 GHz, Memory: 3 GB)

• remote server machine: (OS: Ubuntu 10.04, Web Server:

Apache 2)

A. Effectiveness

To evaluate the effectiveness of BrowserGuard, we made

various tests to evaluate the false positives and false negatives

created by BrowserGuard.

To test the false positives of BrowserGuard, we chose the

top 500 ranking websites from Alexa [19] and visited them

using an IE browser with BrowserGuard. Because surfing these

websites did not make BrowserGuard to issue any drive-by-

download attack alert and these websites were not reported by

Google as malicious websites, the number of false positives

of BrowserGuard for these websites is zero.

In order to evaluate the false negatives of BrowserGuard,

we used Metasploit framework [20] to generate 10 maliciousweb pages based on the 9 exploits for IE 7.0 listed in Table

I. We installed these 10 malicious web pages in a remote

server machine. All these web pages contain both shellcode

and exploit code used to launch drive-by-download attacks;

hence, these web pages compromised our test machines im-

mediately after we use an ordinary IE 7.0 to view these web

pages. However, when using a browser with BrowserGuard

to visit these pages, even though the related malware were

still downloaded to the local host, all of them were blocked

when the shellcode tried to execute them. Hence, the number

of false negatives of BrowserGuard for these malicious webpages is zero.

Among the 10 malicious web pages, number 5 is a special

one because it stores malware in a file with JPEG image

file header first. After the disguised file is downloaded to

the local host, the file is transformed back to an executable

file. But BrowserGuard still thwarted the attack of number

5 web page. Hence, no matter how attackers encrypt the

malware. BrowserGuard still can detect the malware before

it is executed.Table II shows comparisons of the detection accuracy be-

tween BrowserGuard and other similar work [21]–[24]. Some

work does not provide complete data; hence, in Table IIwe use N/A to represent the unavailable data. IMC [24] is

a signature-based solution; hence, if the database does not

contain the signatures for a vulnerability, the false negative

rate will increase to 48%. Besides, [25] proposed an approach

to bypass Nozzle’s detection recently. Hence, the figure shows

that BrowserGuard is an accurate solution.

B. Performance Overhead

Static code analysis shows that the performance overhead

imposed by BrowserGuard is mainly caused by the following

operations. First, when an object is going to be navigated,

BrowserGuard makes some memory access to enlist the URLof the object to the white-list. Second, BrowserGuard needs to

read the header of a downloaded file to check whether the first

two bytes of the file are “MZ”. Third, BrowserGuard needs to

execute extra code to handle event reception and API hooking.To evaluate the performance overhead introduced by

BrowserGuard, we measured the time period between the time

when a browser issues a request to view a web page and the

time when the browser finish the download of the web page

with or without BrowserGuard. We chose 5 web pages from

Alexa Top Sites to make our measurements. For each web

site, we tested the time to finish the above operations 2000

times to collect the statistics. The extra time introduced byBrowserGuard is almost fixed; hence, when a user visits a web

page, the performance overhead imposed by BrowserGuard is

determined by the original time needed to download the web

page. The original download time is affected by many factors,

such as the workload of a web site, the size of a web page,

the computation power of a web site, the transmission time of

a web page, and so on. To reduce the influence of the above

factors, we mirror all tested web pages in a separate local

server. Hence, the whole testing environment is built in a local

network so that we can make sure that the measured data is

under minimized affection of network transmitting velocity.

Overall, the worst case performance overhead in our tests is2.5%. Table III lists the results.

Figure 3 shows comparisons of performance overhead be-

tween BrowserGuard and other similar work. Some work does




TABLE IRESULTS OF FALSE NEGATIVE TESTS . I N THIS TABLE MS B MEANS MICROSOFT SECURITY BULLETIN

Number MSB CVE-ID Description Result

1 MS06-014 2006-0003 RDS.Dataspace ActiveX Control Vulnerability Blocked2 MS06-055 2006-4868 VML Fill Method Buffer Overflow Blocked

3 MS06-067 2006-4777 Daxctle.ocx Keyframe Function Heap Overflow Blocked4 MS07-017 2007-0038 ANI LoadAniIcon Function Buffer Overflow Blocked5 MS07-017 2007-0038 The Malicious Executable is encoded in a jpg file. Blocked

6 MS08-078 2008-4844 Data Binding Memory Corruption Blocked7 MS09-002 2009-0075 CFunctionPointer Uninitialized Memory Corruption Blocked8 MS09-072 2009-3672 getElementsByTagName Memory Corruption Blocked9 MS10-002 2010-0249 HTML Object Memory Corruption Blocked

10 MS10-018 2010-0806 DHTML Behaviors Use-after-free Blocked

TABLE IICOMPARISONS OF THE DETECTION ACCURACY BETWEEN

BROWSERGUARD AND OTHER SIMILAR WORK

False Positive Rate False Negative Rate

BrowserGuard 0% 0%Nozzle 50% Threshold 0% 0%

BuBBle N/A 0%JSAND 10.9% 0.2%

IMC 0% 48%(0%)

TABLE IIIPERFORMANCE OVERHEAD INTRODUCED BY BROWSERGUARD

Mirrored web site BrowserGuard W/O BrowserGuard Overheadavg.(sec) avg.(sec)

news.yahoo.com 4.933 4.891 0.9%w3.org 0.867 0.857 1.2%

youtube.com 1.227 1.211 1.3%imdb.com 1.520 1.483 2.5%

facebook.com 1.538 1.527 0.7%

not provide complete data; hence, in Fig. 3 we use N/A tomean the unavailable data. Figure 3 shows that BrowserGuard

has low performance overhead.

V. RELATED WOR K

In this section, we discuss related work in the literature.

Many drive-by-download attacks are triggered by vulnerable

ActiveX controls. Microsoft uses Kill-Bit [26] to mitigate this

problem. However, Kill-Bit does not patch any executable.

Instead, it just blocks the use of certain known vulnerable

ActiveX Controls. If a particular ActiveX Control is marked as

unsafe through Kill-Bit, the ActiveX Control will never be in-voked by any application. However, attackers can utilize non-

ActiveX-Control vulnerabilities to launch a drive-by-download

attack and not all vulnerabilities of all ActiveX controls are

unveiled.

Many drive-by-download attacks use heap sprays [15] to

accomplish the attacks. Nozzle [21] detects heap spray at-

tacks based on the observation that shellcode used in a heap

spray attack is usually prepended with a long NOP sled.

Experimental results showed that Nozzle has small number

of false positives and false negatives. However, if an attacker

writes NOP sleds and shellcode into a heap string after Nozzle

finishes its examination, Nozzle is not able to detect the attack.Besides, elaborately created attack strings still can bypass

Nozzle’s detection. Manuel Egele et al. [27] utilize library

libemb to emulate x86 instructions to detect shellcode stored

0

5

10

15

20

25

30

35

40

45

50

B r o w

s e r G u a r d

N o z z l e 5 %

S a m p l e R

a t e

N o z z l e 2 5 %

S a m p l e R

a t e

B u B

B l e

J S A N D

I M C

O v e r h e a d F a

c t o r s o f P a g e L o a d T i m e ( % )

1.32

6.4

45

4.82

N/A 1.5

Fig. 3. Comparisons of performance overhead between BrowserGuard andother similar work

in a Javascript variable. However, this solution introduces non-

trivial performance overhead and elaborately created attack

strings still can bypass their detection.

HSP [28] controls the number and location of int 80 instruc-

tions in a process and hides the whereabouts of the only legal

int 80 instruction; hence, HSP makes it dif ficult for attackers

to issue a system call, let alone a heap spray attack. HSP

is a compiler-based solution; hence, current version of HSP

cannot provide protection for static linked libraries. However,

very few if not none browsers use static linked libraries.

L. Lu et al. [29] adopt similar philosophy of blocking

the execution of suspicious executable files as BrowserGuarddoes. By sandboxing all downloaded objects in a secure zone,

their work, Blade, prohibits supervised process from operating

unauthorized files in the secure zone. Blade captures user

behaviors, such as clicking a mouse button on a download-

related popup window, to mark user-consent downloaded files

as authorized. Blade has zero error rate. However, it may pose

performance issues to non-browser processes due to the special

secure zone design that once a user tries to manipulate a file,

OS should check whether this file is in the secure zone.

Gadaleta et al. [23] defeat heap sprays by randomly insert-

ing interrupt instructions inside every Javascript string variable

before storing it in the heap and reverting the modified stringto the original string before using it. If the execution flow

is redirected to the shellcode stored in a Javascript string

variable, it cannot be successfully executed.




Another popular defense mechanism against drive-by-

download attacks is the browser reputation system. In this

system, before displaying a web page on a browser, the

browser automatically connects to a remote database to check

the reputation of the web page first. Only web pages with

good reputation can display on the browser. Various antivirus

vendors, such as Norton SafeWeb [30], McAFee SiteAdvisor

[31], and Trend Micro TrendProtect [32], adopted this ap-proach to deal with drive-by-download attacks. However, the

browser reputation system has no guarantee that all websites

are under their monitor. Besides, they have non-trivial false-

positives and it takes a while to update out-of-date or wrong

data in the database or to add new data to the database.

Some solutions, such as Provos et al. [1], Moshchuk et al.

[33], Capture-HPC [34], and HoneyMonkey [35], use high-

interaction honey browsers to visit web sites and monitor the

behavior of these web sites in the underlying operating system

to detect malicious web pages. The behavior includes creation

of files or new processes and creation or modification of

Registry. Cova et al. [22] utilize machine learning and anomalydetection in an emulation environment to automatically detect

and analyze malicious Javascript code in malicious web pages.

Their solution, JSAND, can simulate the presence of any

ActiveX controls or plug-ins required by a web page. Dewald

et al. [36] log critical actions triggered by the execution of

Javascript code in a web page. Then utilizing heuristics on

the logs, their solution, ADSandbox, decides whether the web

page is malicious. Basically these solutions are not integrated

into a browser; hence, they are not able to provide real

time protection to browsers. Moreover, these solutions cannot

detect malicious web content when the honey browser does

not have the vulnerability that is used by the exploits in themalicious page. Furthermore, it is a challenging work for them

to examine all web pages.

C. Song et al. [24] detect drive-by-download attacks by

matching the inter-module communication events with pre-

defined vulnerability signatures. However, its signature-based

property makes it dif ficult to detect zero-day attacks.

V I. CONCLUSION

Drive-by-download attacks are one of the most severe

security threats to computer and network systems nowadays.

In this paper, we present BrowserGuard, a runtime, behavior-based solution to drive-by-download attacks. BrowserGuard

analyzes the download scenario of every downloaded object.

Based on the download scenario, BrowserGuard blocks the

execution of any executable file that is downloaded to the host

machine without the consent of a user. This light-weighted

technique introduces less than 2.5% performance overhead

because no simulation or static web page analysis is required.

BrowserGuard also does not need to maintain any attack

string signatures or web site reputation. Experimental results

show that BrowserGuard has no false negative to past exploit

samples and no false positive to top 500 rated websites.

Currently, BrowserGuard is implemented on Windows InternetExplorer 7.0 because most exploits in the wild targeting this

version of IE. Although BrowserGuard only supports IE 7.0

on a Windows system, we believe the defense model of

BrowserGuard can serve as a guide to develop similar tools

for other browsers.

ACKNOWLEDGMENT

Our work is funded by National Science Committee of

Taiwan (ROC), and the numbers of the Projects are NSC 99-

2220-E-008-001 and NSC 99-2219-E-008-001.

REFERENCES

[1] N. Provos, P. Mavrommatis, M. A. Rajab, and F. Monrose, “All youriFRAMEs point to us,” in Proc. 17th conference on USENIX securitysymposium. USENIX Association, 2008, pp. 1–15.

[2] S. Frei, T. Dubendorfer, G. Ollmann, and M. May, “Understanding theweb browser threat: examination of vulnerable online web browser pop-ulations and the “insecurity iceberg”,” ETH, Eidgenossische TechnischeHochschule Zurich, Communication Systems Group, Tech. Rep., 2008.

[3] “NetApplications Company News (December 1, 2008).” [Online].Available: http://www.netapplications.com/newsarticle.aspx?nid=45

[4] “National Vulnerability Database.” [Online]. Available: http://nvd.nist.gov/

[5] M. Egele, E. Kirda, and C. Kruegel, “Mitigating drive-by downloadattacks: challenges and open problems, open research problems,” in

INetSec 2009. Open Research Problems in Network Security, 2009.[6] “Microsoft Of fice Snapshot Viewer ActiveX vulnerability.”

[Online]. Available: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2463

[7] “Microsoft Security Bulletin MS06-014 - Vulnerability in the MicrosoftData Access Components (MDAC) Function Could Allow CodeExecution.” [Online]. Available: http://www.microsoft.com/technet/security/Bulletin/MS06-014.mspx

[8] “Sina dloader class activex control ‘downloadandinstall’ methodarbitrary file download vulnerability.” [Online]. Available: http://www.securityfocus.com/bid/30223/info

[9] C. Cowan, C. Pu, D. Maier, H. Hintony, J. Walpole, P. Bakke, S. Beattie,A. Grier, P. Wagle, and Q. Zhang, “Stackguard: automatic adaptivedetection and prevention of buffer-overflow attacks,” in Proc. 7thconference on USENIX Security Symposium - Volume 7 . USENIXAssociation, 1998, pp. 5–5.

[10] Aleph One, Smashing the Stack For Fun and Pro fit . Phrack Magazine,1996.

[11] L.-H. Chen, F.-H. Hsu, C.-H. Huang, C.-W. Ou, C.-J. Lin, and S.-C.Liu, “A robust kernel-based solution to control-hijacking buffer overflowattacks,” Journal of Information Science and Engineering, vol. 27, no. 3,2011.

[12] T.-C. Chiueh and F.-H. Hsu, “RAD: a compile-time solution to bufferoverflow attacks,” in Proc. 21st International Conference on Distributed

Computing Systems, 2001, pp. 409–417.[13] J. Xu, P. Ning, C. Kil, Y. Zhai, and C. Bookholt, “Automatic diagnosis

and response to memory corruption vulnerabilities,” in Proc. 12th ACM

conference on Computer and communications security, ser. CCS ’05.ACM, 2005, pp. 223–234.

[14] “Microsoft Internet Explorer “window()” Arbitrary Code ExecutionVulnerability.” [Online]. Available: http://secunia.com/advisories/15546/

[15] A. Sotirov, “Heap feng shui in JavaScript,” BlackHat Europe, 2007.

[16] D. Esposito, “Browser Helper Objects: The Browser the Way YouWant It.” [Online]. Available: http://msdn.microsoft.com/en-us/library/bb250436(VS.85).aspx

[17] I. Ivanov, “API hooking revealed.” [Online]. Available: http://www.codeproject.com/KB/system/hooksys.aspx

[18] “Detours.” [Online]. Available: http://research.microsoft.com/en-us/projects/detours/

[19] “Alexa Internet.” [Online]. Available: http://www.alexa.com[20] “Metasploit.” [Online]. Available: http://www.metasploit.com[21] P. Ratanaworabhan, B. Livshits, and B. Zorn, “NOZZLE: a defense

against heap-spraying code injection attacks,” in Proc. 18th conferenceon USENIX security symposium. USENIX Association, 2009, pp. 169–186.

[22] M. Cova, C. Kruegel, and G. Vigna, “Detection and analysis of drive-by-download attacks and malicious javascript code,” in Proc. 19thinternational conference on World wide web, ser. WWW ’10. ACM,

2010, pp. 281–290.[23] F. Gadaleta, Y. Younan, and W. Joosen, “Bubble: A javascript engine

level countermeasure against heap-spraying attacks,” in Engineering

Secure Software and Systems, ser. Lecture Notes in Computer Science,vol. 5965. Springer, 2010, pp. 1–17.




[24] C. Song, J. Zhuge, X. Han, and Z. Ye, “Preventing drive-by downloadvia inter-module communication monitoring,” in Proc. 5th ACM Sym-

posium on Information, Computer and Communications Security, ser.ASIACCS ’10. ACM, 2010, pp. 124–134.

[25] Y. Ding, T. Wei, T. Wang, Z. Liang, and W. Zou, “Heap taichi: exploitingmemory allocation granularity in heap-spraying attacks,” in Proc. 26th

Annual Computer Security Applications Conference, ser. ACSAC ’10.ACM, 2010, pp. 327–336.

[26] “Microsoft Security Research & Defense.” [Online]. Avail-

able: http://blogs.technet.com/srd/archive/2008/02/06/The-Kill 2D00Bit-FAQ 3A00 -Part-1-of-3.aspx[27] M. Egele, P. Wurzinger, C. Kruegel, and E. Kirda, “Defending browsers

against drive-by downloads: Mitigating heap-spraying code injection at-tacks,” in Proc. 6th International Conference on Detection of Intrusions

and Malware, and Vulnerability Assessment , ser. DIMVA ’09. Springer-Verlag, 2009, pp. 88–106.

[28] F.-H. Hsu, C.-H. Huang, C.-H. Hsu, C.-W. Ou, L.-H. Chen, and P.-C.Chiu, “HSP: A solution against heap sprays,” Journal of Systems and

Softwware, vol. 83, pp. 2227–2236, 2010.[29] L. Lu, V. Yegneswaran, P. Porras, and W. Lee, “BLADE: an attack-

agnostic approach for preventing drive-by malware infections,” in Proc.

17th ACM conference on Computer and communications security, ser.CCS ’10. ACM, 2010, pp. 440–450.

[30] “Norton safe web.” [Online]. Available: http://safeweb.norton.com/[31] “McAFee SiteAdvisor.” [Online]. Available: http://safeweb.norton.com/

[32] “Trend Micro’s TrendProtect.” [Online]. Available: http://www.trendsecure.com/portal/en-US/tools/security tools/trendprotect[33] A. Moshchuk, T. Bragin, D. Deville, S. D. Gribble, and H. M. Levy,

“Spyproxy: execution-based detection of malicious web content,” inProc. 16th conference on USENIX Security Symposium. USENIXAssociation, 2007, pp. 3:1–3:16.

[34] “The Honeynet Project. Capture-HPC.” [Online]. Available: https://projects.honeynet.org/capture-hpc

[35] Y.-M. Wang, D. Becker, and X. Jiang, “Automated web patrol withstrider honeymonkeys: Finding web sites that exploit browser vulnerabil-ities,” in Proc. Symposium on Network and Distributed System Security,2006.

[36] A. Dewald, T. Holz, and F. C. Freiling, “Adsandbox: sandboxing javascript to fight malicious websites,” in Proc. 2010 ACM Symposium

on Applied Computing, ser. SAC ’10. ACM, 2010, pp. 1859–1864.

Fu-Hau Hsu received his Ph.D. degree in thedepartment of computer science from Stony BrookUniversity, New York, USA in 2004. He is an assis-tant professor at National Central University and hashad an appointment in the Department of ComputerScience and Information Engineering since August2005. He is af filiated with the Advanced DefenseLab and the Wireless and Multimedia Lab.

Chang-Kuo Tso is a Ph.D. student in the Depart-ment of Computer Science and Information Engi-neering of National Central University. He receivedhis M.S. degree in computer science and informa-tion engineering from National Central University,Taoyuan, Taiwan, in 2009. His researches are secu-rity issues about OS design, mobile devices, espe-cially Windows Mobile and Android, and networksecurity.

Yi-Chun Yeh received the B.S degree in computerscience and engineering from Tatung University, in2007, and the M.S degree in computer science andinformation engineering from National Central Uni-versity, in 2009. He is currently working toward thePh.D. degree in Department of Computer Scienceand Information Engineering, National Central Uni-versity with Prof. Fu-Hau Hsu. His research interestsinclude malware technology, firmware development,operating system and mobile security.

Wei-Jen Wang is an Assistant Professor of Com-puter Science and Information Engineering at Na-tional Central University, Taiwan. He received hisB.S. degree and M.S. degree in computer informa-tion science from National Chiao Tung University,Taiwan, in 1997 and 1999, respectively. He receivedhis Ph.D. in computer science from RensselaerPolytechnic Institute in 2006. His research inter-ests include concurrent programming models andlanguages, cloud/grid/Internet computing, distributegarbage collection, and data hiding.

Li-Han Chen is a Ph.D. student in the Departmentof Computer Science and Information Engineeringof National Central University. He received his M.S.

degree in computer science and information engi-neering from National Central University, Taoyuan,Taiwan, in 2008, and his B.S. degree in chemicalengineering from National Tsing Hua University.His research areas include mobile security, operatingsystem, and network security.

Date post:	16-Jul-2015
Category:	Documents
Upload:	shanoop-pattanath
View:	92 times
Download:	0 times

Browser Guard a Behavior-Based Solution To

Documents