Sponsored By

Attack Code 'MarioNet' Is Pulling Strings in Your Web Browser

JavaScript APIs have stretched the boundaries of what is run in the browser to enable feature-rich web applications. But this comes at a price...

Larry Loeb

February 28, 2019

3 Min Read

Modern browsers are really small but powerful operating systems that execute web applications. They run implicitly trusted script code which is confined inside of the browser.

JavaScript APIs have stretched the boundaries of what is run in the browser to enable feature-rich web applications. But this comes at a price.

A web publisher is considered as a trusted source by the browser, and so can run JavaScript code on the user side without any real restriction. Thus far, the code only executes while the browser is in contact with a web page.

But some researchers from FORTH in Greece have shown a way in their research to turn this on its head. In their paper presented this week at the Network and Distributed Systems Security (NDSS) Symposium in San Diego, "Master of Web Puppets: Abusing Web Browsers for Persistent and Stealthy Computation," they show how a framework they call MarioNet (a play on marionette, get it?) could let attackers persistently and stealthily hijack a browser and control its actions.

While this is similar in concept to the PuppetNet of 2007, it varies greatly in the details. More importantly, the attack code will continue to run when the triggering website is left or the tab that resolved it has been closed.

The secret sauce here is an API called Service Worker. Designed to free the rendering of the web page from an underlying computational task, it can operate in a page's background even when the page is not being rendered.

To do this, the Service Worker SyncManager interface is abused in an attack to keep the service worker alive.

The service workers can be controlled from a website that was not the originating one, thus a "command and control" operation is possible. So, attackers could put the attack originating code on some high-traffic websites for only a short period of time, which would get them a lot of service workers, and then remove the attack code. They could still continue to control the infected browsers from another site. Instant bot.

The user would be totally unaware that this is happening, since no interaction is required for this.

However to gain persistence across browser reboots, attackers need the Web Push API. This would require the attacker to obtain user permission.

Now since these are newer HTML5 APIs, they are present in modern browsers. In fact, the only browsers currently safe from this attack are IE (desktop), Opera Mini (mobile), and Blackberry (mobile). The researchers laid out the kinds of criminal activity this approach could enable. They mention DDoS attacks, cryptocurrency mining, distributed password cracking and malicious or illegal data hosting as prime examples of what could be done under MarioNet.

To mitigate this attack, they also suggest putting some form of limitation on service workers so that they just do not run unimpeded. Other defenses could be browser-based or host-based.

In short, the paper should cause a re-evaluation with a security viewpoint of unrestricted JavaScript code use within a browser.

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Read more about:

Security Now

About the Author(s)

Larry Loeb

Blogger, Informationweek

Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He has written a book on the Secure Electronic Transaction Internet protocol. His latest book has the commercially obligatory title of Hack Proofing XML. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. His first Mac had 128 KB of memory, which was a big step up from his first 1130, which had 4 KB, as did his first 1401. You can e-mail him at [email protected].

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights