One push too far / part 3
As we saw in part 1 and part 2 of this article series, we can use malicious notifications to gain persistent access to users’ browsers (either through a malicious website, or via an XSS notification hijack). In this article I’d like to discuss another risk of the notification mechanism – a notification-based botnet.
No S**T, Sherlock
When you think about it, it’s a rather direct result of the definition of web push notifications. The mechanism gives you access to many browsers and allows you to operate on these browsers. While you can’t exactly execute OS commands on all of these ‘bots’, launching a DDoS is quite straight forward.
Consider the following Service Worker code:
self.addEventListener(‘push’, function(event) { event.waitUntil( getEndpoint() .then(function(endpoint) { return fetch(“https:/-www.victim -dot- com”, { method: ‘POST’, // body:JSON.stringify(‘[“very very long”,”data!!!]’) }); }) .then(function(response) { return response.text(); });});
Pretty self-explanatory, all we do here is consume the ‘push’ event, and then send a POST to our victim (Obviously our request body will be bigger in a real attack scenario).
Now, we just need to get enough users to register to our notification service. When we’re ready to launch the DDoS, we send requests to our ‘CNC’ (Google/Mozilla), which send the commands to the bots (browsers), which then attack the victim:
Invisibility cloak?
You might have noticed that our service worker does not prompt an actual notification, meaning the activity is meant to be ‘invisible’ to the end-user. However, sending invisible push notifications is not always possible:
In Chrome, invisible notifications are not really allowed, unless the end-user is correctly focused on the application tab. In any other instance sending an ‘invisible’ notification in Chrome will result in a warning notification displayed to the user stating that there was a background operation:
There are some workarounds (especially with the new Budget API), however, in all of them you’re limited to a small number of silent pushes. Invisible or not, the DDoS POST message will still be sent.
In Firefox, invisible push notifications ARE allowed, with some sort of rate limitation (i.e. after enough invisible notifications, the website might be blocked). I was rather surprised by this behavior, I even considered it a bug, but it turns out to be a feature ?
The following clip demonstrates a silent push in Firefox:
Piecing this all together, I think the botnet operator can choose between two ‘working modes’: either stay in “Caution mode”, i.e. only use Firefox and/or currently connected Chrome users for launching the attack (thus keeping most clients unaware of the traffic generated from their browser); or go for an “all out” mode – using all bots and risking the exposure of the botnet.
How to take the botnet down?
The interesting thing about this concept is the botnet’s resilience. Unlike a traditional botnet, a notification-based botnet does not have a CNC server that can be taken down. Commands are sent to the bot via Google/Mozilla. Taking down the botnet can only be done by the service provider itself (for example by invalidating the public key), but detecting the abuse is not trivial (I haven’t experimented with a large-scale notification-based botnet so I cannot testify to how fast it will be detected, if at all).
Final thoughts
Having spent some time with push notifications, I still don’t understand why an end user would actually want to allow this feature on any website, it’s simply annoying and intrusive (but maybe that’s just because I’m too and cranky). Anyhow, from the attacker’s point of view, it seems there is a lot to play with and more research can probably lead to more attack vectors.
Zohar Shachar, tech lead