Theresa Welchy: Master of web puppets: abusing web browsers for persistent and stealthy computation

Master of web puppets: abusing web browsers for persistent and stealthy computation Papadopoulus et al., NDSS’19

You’ve probably heard about crypto-currency mining and the like in hijacked browsers.

From a security perspective, a fundamental problem of web applications is that by default their publisher is considered as trusted, and thus allowed to run JavaScript code (even from third parties) on the user side without any restrictions… On the positive side JavaScript execution so far has been constrained chronologically to the lifetime of the browser window or tab that rendered the compromised or malicious website.

Not any more! This paper shows how modern browsers with support for Service Workers can be stealthily connected into a botnet, with a connection that persists until the user closes the browser completely: “in contrast to previous approaches for browser hijacking, a key feature of MarioNet is that it remains operational even after the user browses away from the malicious webpage.”

MarioNet building blocks: Service Workers and WebRTC

Service Workers are non-blocking modules that reside in the user’s browser. Once registered they can run in the background without requiring the user to continue browsing on the originating site. In addition, service workers have the ability to intercept and handle network requests (for e.g., caching and pre-loading purposes). No user permission is required to register and maintain a service worker.

When the user browses away from a website, the service worker of that website is typically paused by the browser; it is then restarted and reactivated once the parent domain is visited again. However, it is possible for the publisher of a website to keep its service worker alive by implementing periodic synchronization.

If the user permits the publishing site to send push notifications, then it is even possible to have the service worker restart when the browser is restarted.

![][TABLE1]

Browser extensions are not permitted to use HTML5 APIs such as the Service Workers API and Push API, and hence cannot interact with or see deployed service workers in any way (e.g., modify their code, monitor their outgoing traffic etc.). Thus no extension-based mechanism or blocker (save turning off JavaScript completely) can offer protection.

Once browsers have been hijacked, the Web Real-Time Communication (WebRTC) API is also very useful for implementing peer-to-peer communication between browsers.

Key features of MarioNet

MarioNet aims to establish an in-browser botnet that requires only that the user visit a target website (e.g. one owned by the attacker, or one that the attacker has compromised) one time in order to takeover the browser. The design has the following goals:

Isolation: operation is independent of any browsing session thread or process (so that more heavyweight computation can be done with less chance of detection)
Persistence: operation is completely detached from any ephemeral browsing session, so that the browser remains under the attackers control for periods of time much longer than a website visit
Evasiveness: operations should be performed in a stealthy manner to evade detection and maintain the infection for as long as possible.There are three main components to the system, as shown in the figure below.

The user simply needs to visit one time a page under the attackers control, hosted on a website. This page installs a service worker (the Servant) when loaded in the browser, and uses background sync registrations to keep the Servant always alive.

As part of its initialization, the Servant establishes a communication channel with its remote command and control server (Puppeteer) and requests the initial set of tasks.

The Puppeteer can send tasks to Servants at any time over the established communications channels. One easy way to package them is as JavaScript scripts that the servant simply evals. Because extensions cannot see service workers, the connection between a Servant and the Puppeteer is hidden from all extensions. The connection is also TLS-encrypted such that it cannot be eavesdropped outside of the browser either.

The only request that reveals the existence of the service worker is the initial GET request at the time of the user’s first website visit, when the service worker gets initially registered.

To further evade detection, the Servant monitors the device’s current status (CPU utilisation, battery, etc.) and can throttle or pause execution of the malicious workload to minimise risk of detection.

If the user allows the distributor to send push notifications (more likely perhaps when the servant is distributed via a compromised site the user trusts), then MarioNet can send asynchronous notifications and updates to its service workers to re-activate them after browser restarts.

MarioNet use cases

MarioNet can conduct a subset of DDoS attacks by instructing Servants to connect to a specific Internet host. There is no low-level networking access, but HTTP request methods and the HTTP body can of course be controlled. If the victim site has enabled WebSockets then this is another attack vector.

UsingXMLHttpRequest.send(), jQuery’s ajax() and WebSocket’s send() methods, we can continually send a flood of messages to a targeted host.

MarioNet can be used for cryptocurrency mining, where it is much more efficient than current Web Worker based approaches since it can continue mining even once the user has left the initial site.

MarioNet can instruct Servants to assist in distributed password cracking. “A major advantage of MarioNet is that it can be agnostic to the hashing function used, since the function code is transferred from the Puppeteer and executed from the MarioNet nodes through eval().”

A network of MarioNet nodes can form a content distribution network (presumably for content of an unsavoury nature) using WebRTC. The authors implemented a WebTorrent proof-of-concept for this idea. In a similar manner, WebRTC can be used to construct obfuscating relay proxies.

Another classic use case would be click fraud, where MarioNet is used to surf targeted websites, stream online videos to increase views, manipulate online polls, and so on. The Puppeteer would simply need to periodically send a list of online links to visit…

Defenses?

MarioNet works across a wide range of modern desktop and mobile browsers, although in the evaluation Service Worker performance on Safari was found to be very poor (presumably Apple will improve this over time?).

The prime defence against MarioNet would require a mechanism to restrict or disable service workers. Since many sites now depend on them this has the potential to degrade user experience for legitimate use cases. Forbidding service workers to use eval and friends would make it more difficult for the Puppeteer. A same-origin policy for service worker network requests would also help in the case of a compromised distribution site. Users could also be required to explicitly give permission for a service worker to be installed by a site (currently user consent is only needed for Push notifications).

Network traffic monitors may be able to pick up message exchange patterns, in environments where these are deployed and appropriately configured.

Beyond never accepting push notification requests, and periodically restarting your browser, it seems there’s not much more you can do as an end user to protect against this class of attacks.

Essentially, our work demonstrates that the trust model of web, which considers web publishers as trusted and allows them to execute code on the client-side without any restrictions is ﬂawed and needs reconsideration. Furthermore, this work aims to increase the awareness regarding the powerful capabilities that modern browser APIs provide to attackers, and to initiate a serious discussion about implementing restrictions while offering such capabilities that can be easily abused.