SpyProxy SpyProxy Execution-based Detection of MaliciousWeb Content Execution-based Detection of MaliciousWeb Content Hongjin, Lee

Paper Information TitleTitle –SpyProxy: Execution-based Detection of MaliciousWeb Content AuthorsAuthors –Alexander Moshchuk, Tanya Bragin, Damien Deville, Steven D. Gribble, and Henry M. Levy Department of Computer Science & Engineering PublishedPublished –16th USENIX Security Symposium (USENIX 2007)16th USENIX Security Symposium

Outline… 1. Introduction 2. Architecture and Implementation 3. Performance Optimizations 4. Evaluation 5. Conclusions

1. Introduction 1.1 Background Early Web pages contained simple, passive content Modern Web pages increasingly active containing embedded code ActiveX components, JavaScript, or Flash  leads to new security threats (Drive-by-download) install malware on the user’s PC

Introduction 1.2 Execution-based Approach Observing the side-effects of the execution Advantage can detect threats that have not been seen previously (e.g., zero-day attacks). -Because it is based on behavior rather than signatures Zero-day Attack - a computer threat that tries to exploit unknown, undisclosed or unpatched computer application vulnerabilitiescomputer application

Introduction 1.3 SpyProxy1.3 SpyProxy Goal To demonstrate the potential for execution-based tools that protect users from malicious content To do this designed, prototyped, and evaluated SpyProxy a new anti-malware service  SpyProxy implemented as an extended Web proxy SpyProxy intercepts users'Web requests, downloads content on their behalf valuates its safety before returning it to the users (If the content is unsafe, the proxy blocks it, shielding users from the threat)

2. Architecture and implementation 2.1 SpyProxy Key Techniques First Technique executes Web content on-the-fly in a disposable virtual machine, identifying and blocking malware before it reaches the user's browser. In contrast, many existing tools attempt to remove malware after it is already installed. Second Technique monitors the executing Web content by looking for suspicious “trigger” events (such as registry writes or process creation) that indicate potentially malicious activity  based on behavior rather than signatures

Architecture and implementation 2.2 Design Goals 1. Safety SpyProxy should protect clients from harm by preventing malicious content from reaching client browsers. 2. Responsiveness The use of SpyProxy should not impair the interactive feel and responsiveness of the user’s browsing experience. 3. Transparency The existence and operation of SpyProxy should be relatively invisible and compatible with existing content-delivery infrastructure (both browsers and servers).

Architecture and implementation 2.3 Proxy-based Architecture Key components the client browser, SpyProxy, and remote Web servers When the client browser issues a new request to a Web server  The request first flows through SpyProxy (where it is checked for safety)

Architecture and implementation Figure.1 Key Component

Architecture and implementation (a) A client browser requests a Web page; The proxy front end intercepts the request, retrieves the root page, and statically analyzes it for safety.

Architecture and implementation (b) If the root page cannot be declared safe statically, the front end forwards the URL to a VM worker. A browser in the VM downloads and renders the page content. All HTTP transfers flow through the proxy front end and a Squid cache.

Architecture and implementation (c) If the page is safe, the VM notifies the front end, and the page content is released to the client browser from the Squid cache. Note that if the page has been cached and was previously determined to be safe, the front end forwards it directly to the client.

3. Performance Optimizations 3.1 Caching the Result of Page Checks Web Proxy Cache To reduce Web traffic and improve response times Hit rates as high as 50% VM-based approach incurs the overhead for repeated visits to the same page ∴ First Optimization is caching the result of the security check

Performance Optimizations 3.2 Prefetching Content to the Client Problem in the unoptimized system The Web client will not receive any content until the entire Web page has been downloaded, rendered, and checked by SpyProxy The network between the client and the proxy remains idle when the page is being checked The client has a low-bandwidth network connection, or if the Web page contains large objects, this idle time represents a wasted opportunity to begin the long process of downloading content to the client

Performance Optimizations Solution(Prefetching Content)Solution(Prefetching Content) SpyProxy contains additional components and protocols that overlap several of the steps shown in Figure 1 A new client-side component acts as a SpyProxy agent The client-side agent both prefetches content from SpyProxy and releases it to the client browser once SpyProxy informs it that the Web page is safe ∴ This improves performance by transmitting content to the client in parallel with checking the Web page in SpyProxy - Because we do not give anyWeb page content to the browser before the full page has been checked, this optimization does not erode security

Performance Optimizations 3.3 The Staged Release of Content Problems about Prefetching Content Optimizations Although prefetching allows content to be spooled to the client while SpyProxy is performing its security check, the user’s browser cannot begin rendering any of that content until the full Web page has been rendered and checked in the VM worker  degrades responsiveness The client browser cannot take advantage of its performance optimizations that render content well before the full page has arrived

Performance Optimizations Staged Release OptimizationStaged Release Optimization Goal To present content considered safe for rendering to the client browser in pieces; As soon as the proxy believes that a slice of content (e.g., an object or portion of an HTML page) is safe Simultaneously releases and begins transmitting that content to the client

Performance Optimizations Figure.2

Performance Optimizations Figures 2(a) (b). Only part of the main Web page has been downloaded and rendered by the VM browser.

Performance Optimizations Figure 2(c). all of the first embedded object has been rendered by the VM, which causes that object and some of the mainWeb page content (shown in black) to be released and transmitted to the client browser More of the main Web page and the second embedded object is downloaded and rendered in Figure 2(d)

Performance Optimizations Figures 2(e)(f). The full Web page is released

4. Evaluation 4.1 Performance of the Unoptimized System  The unoptimized SpyProxy implementation added less than three seconds to the total page download time

Evaluation 4.2 Performance Optimizations Prefetching Latency improvements gained by the prefetching optimization in the broadband environment.  Prefetching alone did not yield significant benefits.

Evaluation Staged Release4.2.2 Staged Release Latency improvements from staged release in the broadband environment.  Staged release significantly improved the latency until rendering starts

Evaluation Caching4.2.3 Caching Shows The latency improvements gained when the security cache optimization is enabled and the Web page hits in the cache Security cache hit

Evaluation 4.3 Effectiveness at Blocking Malicious Code4.3 Effectiveness at Blocking Malicious Code The effectiveness of SpyProxy at detecting and blocking malicious Web content.  SpyProxy was successful at detecting and blocking 100% of the malicious Web pages we visited

5. Conclusions 1. SpyProxy successfully detected and blocked all of the threats it faced, including threats not identified by other detectors 2. The SpyProxy prototype adds only 600 milliseconds of latency to the start of page rendering—an amount that is negligible in the context of browsing over a broadband connection 3. Our prototype integrates easily into the network and its existence is transparent to users