Master of Web Puppets: Abusing Web Browsers for Persistent and Stealthy Computation

In the last Network and Distributed System Security Symposium (NDSS’2019), we presented an attack that allows a remote malicious entity to control a visitor’s browser and abuse its resources for unwanted computation or harmful operations, such as cryptocurrency mining, password-cracking, and DDoS. The attack relied solely on already available HTML5 APIs, without requiring the installation of any additional software. Most of the web browsers were affected, including Google Chrome, Mozilla, Firefox, etc. Our technical paper first published online last September (online here), and by then several browser vendors have already included fixes [1], [2], that restrict the execution of JavaScript shortly after (~1 min) the user navigates away from the website.

Attack Overview

The attack is launched in three main steps, as illustrated in the Figure below. First, (step 1) the user visits the website (i.e., the Distributor) to get content that they are interested in. The Distributor delivers the JavaScript code of the Servant along with the rest of the webpage’s resources. During webpage rendering (step 2), the Servant is deployed in the user’s browser. As part of its initialization, the Servant establishes a communication channel with its remote command and control server (Pupeteer) and requests the initial set of tasks (step 3). The Pupeteer, maintained by the attacker, responds with the malicious script (e.g., DDoS, password cracking, cryptocurrency mining) the Servant has to execute.

After victims get compromised, the attacker can instrument them to perform a diverse set of attacks in users’ web browsers, which can be categorized in three models, as shown in the Figure below: (a) force victims to visit to a selected server or URL, for DDoS attack or fake ad-impressions, (b) enable victims to request computations, such as cryptocurrency mining or password cracking, and (c) deploy illegal services, such as illicit file hosting or hidden/anonymized communications. More technical details can be found in our paper.

Current Status

The issue was made public by many browser vendors in November 2018, which were dealing with it internally at the same time we were working on our MarioNet prototype [1 ], [2]. The first fixes have started being released since the end of July, and were mainly restricting the number of events (such as fetch, push, sync, etc.) that a Service Worker can receive. These events were used by our attack model to keep the Service Worker alive. Currently, the expected behavior for a Service Worker is to get only one event and then gets terminated soon after that. That means that the Service Worker can stay alive only for about one minute after the user navigates away from the website, significantly limiting the lifetime of an infected user.

Conditions of Use | Privacy Policy