Wavethrough – Stealing data from remote sites through (fake) wav files

Jake Archibald discovered a really nice browser bug (which is fixed by now) by which he was able to steal data from remote sites by loading it in as a (fake) wav file.

The exploit works as follows:

  1. Make a request to evil-script, using a Content-Range header to suggest there’s more data to be loaded afterwards.
  2. Have evil-script return a valid WAV PCM header block, but also have it return a Redirect response header to the cross-origin (!) location you want to read out.
  3. Since a Content-Range header was used, the browser will make a second request to fetch the rest of the data.
    • A browser susceptible to this exploit will actually make the request to the remote location defined in the Redirect header.
    • Good browsers will stop here, throwing a CORS error.
  4. Store the returned data in an <audio> element.
  5. Play back the audio fragment, and meanwhile read out its data using a ScriptProcessorNode.

Not all browsers were affected by this bug: in Firefox you could only get the length of the returned content, and it was only in Edge that Jake was able to read out the actual contents of the generated wav file. Here’s a video of Edge (warning: as it’s raw data you’ll only hear glitches and stuff … you might want to turn down the volume):

Nice find Jake!

A shame the process of reporting this bug with the Edge team didn’t go that smooth though (details in Jake’s post). I’m confident the Edge team will adjust / already have adjusted a few things internally to prevent this obstacle course from happening again.

Jake Archibald: “I discovered a browser bug” →

Other neat hacks that recently made rounds was this one, using the W3C Ambient Light Sensor API and this one using mix-blend-mode. Always fun to see smart people find a way to abuse a new technology that seems safe at first 🙂

Side-channel attacking browsers through CSS3 features

Ruslan Habalov and Dario Weißer found a way to read contents from an iframe, using CSS3:

Accessing the DOM of an iframe that includes a cross-origin resource is forbidden by default. However, the content of the iframe was displayed in the same context as the rest of the site so we wanted to verify if there is side-channel potential that might allow us to leak state information through the interaction of browser features with the iframed content. With this in mind, we went ahead and tested various CSS features like transparency, rotation and mix-blend-mode on top of the cross-origin iframe.

By doing so, we discovered a bug that allowed side-channel attacking the CSS feature mix-blend-mode.

The bug was disclosed properly and has already been fixed.

Side-channel attacking browsers through CSS3 features →

Another neat hack that recently made rounds was this one, using the W3C Ambient Light Sensor API. Always fun to see smart people find a way to abuse a new technology that seems safe at first 🙂

Stealing your browser history with the W3C Ambient Light Sensor API

A few years ago window.getComputedStyle and the like where adjusted to return the default color of links, instead of the actual color on screen.

Security and privacy were the driving factors behind that decision: by styling :visited links with a different color than their non-visited counterparts, a hacker could easily determine which sites a user has visited by simply checking the color of each link.

// @ref https://dbaron.org/mozilla/visited-privacy
var links = document.links;
for (var i = 0; i < links.length; ++i) {
    var link = links[i];
    if (getComputedStyle(link, "").color == "rgb(0, 0, 128)") {
        // we know link.href has not been visited
    } else {
        // we know link.href has been visited
    }
}

With that hole now plugged for quite some time, Lukasz Olejnik turned towards the Ambient Light Sensor API to perform a likewise hack:

Since a website can apply different styles to visited and unvisited links, but cannot detect how the links are displayed to the user, we use the sensor to identify its true color:

  1. Set link styles: visited (white), unvisited (black).
  2. Calibrate: display a white background, then follow with a black background to identify the light levels in the user’s environment; this is also possible, but more difficult, if sensor readings fluctuate significantly.
  3. Iterate through a list of links, one by one, displaying each of them in turn as a large rectangle which fills the entire screen. Visited links will show up as white, unvisited as black.
  4. Log the light levels in response to displaying each link, identifying its color. Since we calibrated the screen in step #2, we know which color each reading represents.

At the end the attacker obtains a list of links for which the screen was white and knows that the user had previously visited the given pages.

Using the same technique it's also possible read out QR codes.

Stealing sensitive browser data with the W3C Ambient Light Sensor API →

WordPress < 3.6.1 PHP Object Injection

WordPress 3.6.1 contains a PHP Object Injection Vulnerability Fix, detected by one of my former students. He also made an extensive writeup about it:

Let’s recap: maybe_serialized(‘i:1;<funkycharacterhere>’) is inserted to the database. As WordPress does not see this as a serialized string (because it doesn’t end in ; or }), this will result in i:1;. When inserted, MySQL doesn’t know how to store it properly, and removes the <funkycharacterhere>. Later on, when the value i:1; is retrieved, it will be unserialized as it now has ; as last character which will make is_serialized() return true. Boom. Vulnerability.

WordPress < 3.6.1 PHP Object Injection →

Major Samsung Galaxy TouchWiz exploit hard resets a device by just visiting a website

A phone dialer code can hard reset a Galaxy S2, S3, and a bunch of minor devices that use Samsung’s TouchWiz overlay. The idea is that the operator could enter it on the keypad manually to hard reset all of the data. However, it was discovered last month that an SMS could carry the number and reset the device (video above). Now, it seems some folks have tried embedding the call function in a web frame with those numbers. They were able to reset the Samsung Galaxy devices just by having the device visit a website.

It’s as easy as including this in your website:

<frame src="tel:*2767*3855%23" />

Samsung is already working on the issue.

Major Samsung Galaxy TouchWiz exploit hard resets a device by just visiting a website →

(via )

iOS in-app proxy

We received some disturbing tips today that a Russian developer has published a method of obtaining in-app purchases from iOS apps for free. The “in-app proxy” method does not require a jailbreak, can be completed by novices in three steps using just an iOS device, and allows users to install in-app content for free. The hack also works on all devices running iOS 3.0 to 6.0.

Only works if the developer of the app doesn’t verify the store receipt after “purchasing”

Apple’s in-app purchasing process circumvented by Russian hacker →
iOS Developer Library: Verifying Store Receipts →