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

UPDATE 2019-04-14: An author update has been published for this paper which details that with current browser versions, ServiceWorkers can only stay alive for about a minute after the user navigates away from the site. This mitigates the main risk detailed in the paper of long running botnet membership. With thanks to Alex Russell (@slightylate) for highlighting this to me. 

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.

MarioNet-Table-1.jpeg

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 flawed 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.

9 thoughts on “Master of web puppets: abusing web browsers for persistent and stealthy computation

  1. Service Workers don’t seem to be limited to one minute if the site can trick you into allowing notifications, which many do. I don’t think that’s the answer.

  2. Look for yourself how big them Service Worker folders could explode!
    Mine were over 400MB! :(
    For an Opera Browser profile backup much too big.
    After DIY cleansing they got 60% off size AND Opera Browser also got 40% smaller in RAM and faster in reaction and data transfer over Internet, subjectively :)

    Here is my workaround against the Service Worker “Overload”.
    Please amplify and correct :)

    1. Possibility:
    File Explorer:
    C:\Users\Your Profilename\AppData\Roaming\Opera Software\Opera Stable\Service Worker
    There folders:
    CacheStorage (biggest?)
    ScriptCache
    Database
    To sort files for size i use the XYplorer.

    Here you could always watch the
    index.txt
    to see which site (mis)uses your HD space.
    So i discovered plus 100MB eg from nytimes.com, where i didnt go for years.
    Deleted at once. But this is too time-consuming for evey folder.

    2. Poss.:
    Simplier with the address bar:
    opera:serviceworker-internals
    Here you can manualy click unregister per Domain.
    I cleaned all up but important folders like Googlemail, Opera, etc.
    Success: More than 200 MB so of 60% shrunked my Service Worker folder! :D
    But this won’t be permanent i’m afraid.

    3.Poss:
    Opera developer tools :
    CTRL+Shift+I, Application, Service Worker, Service workers from other origins.
    I did not use this.

    4. Poss.:
    Deactivation of Service Worker in the Opera Browser per Addon uMatrix:
    Click on the 3 points points on top of each other to the right of On/Off: Forbid Webworker.

    5. Poss.:
    opera://flags
    Search for “service worker”.
    Enable/Disable:
    – Service worker on UI thread
    – Prefetch request properties are updated to be privacy-preserving
    Could be permanent, but this seams to be too unspecific und risky for many sites who do profit from that.

    Conclusion:
    Options 2 an 4:
    opera:serviceworker-internals
    Addon uMatrix
    They seem to be a good team: First delete non important and then block this permantly by an addon.
    But you got to look regularly in your Opera Profile folder “service Worker”, otherwise it would blow up too much.

    And the problem stays that you can not simply get rid off this data waste. :(
    Not to talk of probably important security risks.

    Yes, for website performance or while staying offline the Service Worker might be useful and necessary, but i never read something positive about it.
    Who has got sources? :)
    thx

Leave a Reply to Mark Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.