Share on Facebook Tweet on Twitter Share on LinkedIn Share by email
Spectator: Detection and Containment of JavaScript Worms

Overview

Recent popularity of interactive AJAX-based Web 2.0 applications has given rise to a new breed of security threats: JavaScript worms. We propose Spectator, the first automatic detection and containment solution for JavaScript worms. Spectator is a proxy that performs distributed data tainting by observing and tagging the traffic between the browser and the Web application. When a piece of data propagates "too far", a potential worm is reported. To prevent worm propagation, subsequent upload attempts performed by the same worm are blocked. Spectator is able to detect fast and slow moving, monomorphic and polymorphic worms with a low rate of false positives. In addition to our detection and containment solution, we propose a range of deployment models for Spectator, ranging from simple intranet-wide deployments to a scalable load-balancing scheme appropriate for large Web sites.

Architecture

The goal of Spectator is to protect Web site users from the adverse effects of worm propagation after the server has failed to discover or patch a vulnerability in a timely manner. The essence of the Spectator approach is to tag or mark HTTP requests and responses so that copying of the content across a range of pages in a worm-like manner can be detected. Note that JavaScript worms are radically different from “regular” worms in that they are centralized: they typically affect a single Web site or a small group of sites. Spectator consists of an HTTP proxy inspecting the traffic between the user’s browser and a Web server in order to detect malicious patterns of JavaScript code propagation. Our tagging scheme is a form of distributed tainting: whenever content that contains HTML is uploaded to the server, Spectator modifies it to attach a tag invisible to the end-user. The tag is preserved on the server and is contained in the HTML downloaded by subsequent requests. Spectator injects client-side support so that tags are reliably propagated on the client side and cannot be removed by worms aware of our tagging scheme. Client-side support relies on HTTP-only cookies and does not require specialized plug-ins or browser modifications, thus removing the barrier to client-side adoption.

Worm detection at the Spectator proxy works by looking for long propagation chains. Our detection algorithm is designed to scale to propagation graphs consisting of thousands of nodes with minimal overhead on every request. Whenever a long propagation chain is detected, Spectator disallows further uploads that are caused by that chain, thereby containing further worm propagation. The Spectator detection algorithm is designed to detect propagation activity that affects multiple users.

With every HTML upload, we also record the IP address of the user issuing the request. Worm detection relies on sufficiently many users adopting Spectator. However, since Spectator relies on no additional client-side support, it can be deployed almost instantaneously to a multitude of users.

Tracking Details

To make the discussion above more concrete, a diagram of Spectator’s architecture is shown above. Whenever a user attempts to download a page containing Spectator tags previously injected there by Spectator, the following steps are taken, as shown in the figure:

  1. The tagged page is retrieved from the server.
  2. The Spectator proxy examines the page. If the page contains tags, a new session ID is created and associated with the list of tags in the page. The tags are stripped from the page and are never seen by the browser or any malicious content executing therein.
  3. The modified page augmented with the session ID stored in a cookie (referred to below as “Spectator cookie”) is passed to the browser.

Whenever an upload containing HTML is observed, the following steps are taken:

  1. A user issues an HTTP request containing HTML and a new tag is created for that upload. If a Spectator cookie is found on the client, it is automatically sent to Spectator by the browser.
  2. If the request has a valid session ID contained in a Spectator cookie attached to the request, the list of tags it corresponds to is looked up and, for every tag, causality links are added to the propagation graph. The request is not propagated further if the Spectator detection algorithm decides that the request is part of worm propagation.
  3. Finally, the request augmented with the newly created tag is uploaded and stored at the server.

 

Documents: