Author Archives: Christopher Boyd

Researchers go hunting for Netflix’s Bandersnatch

A new research paper from the Indian Institute of Technology Madras explains how popular Netflix interactive show Bandersnatch could fall victim to a side-channel attack.

In 2016, Netflix began adding TLS (Transport Layer Security) to their video content to ensure strangers couldn’t eavesdrop on viewer habits. Essentially, now the videos on Netflix are hidden away behind HTTPS—encrypted and compressed.

Previously, Netflix had run into some optimisation issues when trialling the new security boost, but they got there in the end—which is great for subscribers. However, this new research illustrates that even with such measures in place, snoopers can still make accurate observations about their targets.

What is Bandersnatch?

Bandersnatch is a 2018 film on Netflix that is part of the science fiction series Black Mirror, an anthology about the ways technology can have unforeseen consequences. Bandersnatch gives viewers a choose-your-own-adventure-style experience, allowing for various options to perform task X or Y. Not all of them are important, but you’ll never quite be sure what will steer you to one of 10 endings.

Charlie Brooker, the brains behind Bandersnatch and Black Mirror, was entirely aware of the new, incredibly popular wave of full motion video (FMV) games on platforms such as Steam [1], [2], [3]. Familiarity with Scott Adams text adventures and the choose your own adventure books of the ’70s and ’80s would also be a given.

No surprise, then, that Bandersnatch—essentially an interactive FMV game as a movie—became a smash hit. Also notable, continuing the video game link: It was built using Twine, a common method for piecing together interactive fiction in gaming circles.

What’s the problem?

Researchers figured out a way to determine which options were selected in any given play-through across multiple network environments. Browsers, networks, operating systems, connection type, and more were changed for 100 people during testing.

Bandersnatch offers two choices at multiple places throughout the story. There’s a 10-second window to make that choice. If nothing is selected, it defaults to one of the options and continues on.

Under the hood, Bandersnatch is divided into multiple pieces, like a flowchart. Larger, overarching slices of script go about their business, while within those slices are smaller fragments where storyline can potentially branch out.

This is where we take a quick commercial break and introduce ourselves to JSON.

Who is JSON?

He won’t be joining us. However, JavaScript Object Notation will.

Put simply, JSON is an easily-readable method of sending data between servers and web applications. In fact, it more closely resembles a notepad file than a pile of obscure code.

In Bandersnatch, there are a set of answers considered to be the default flow of the story. That data is prefetched, allowing users who choose the default or do nothing to stream continuously.

When a viewer reaches the point in the story where they must make a choice, a JSON file is triggered from the browser to let the Netflix server know. Do nothing in the 10-second window? Under the hood, the prefetched data continues to stream, and viewers continue their journey with the default storyline.

If the viewer chooses the other, non-default option, however, then the prefetched data is abandoned and a second, different type of JSON file is sent out requesting the alternate story path.

What we have here is a tale of two JSONs.

Although the traffic between the Netflix browser and its servers is encrypted, researchers in this latest study were able to decipher which choices its participants made 96 percent of the time by determining the number and type of JSON files sent.

Should we be worried?

This may not be a particularly big problem for Netflix viewers, yet. However, if threat actors could intercept and follow user choices using a similar side channel, they could build reasonable behavioral profiles of their victims.

For instance, viewers of Bandersnatch are asked questions like “Frosties or sugar-puffs?”, “Visit therapist or follow Colin?”, and “Throw tea over computer or shout at dad?”. The choices made could potentially reveal benign information, such as food and music preferences, or more sensitive intel, such as a penchant for violence or political leanings.

Just as we can’t second guess everyone’s threat model (even for Netflix viewers), we also shouldn’t dismiss this. There are plenty of dangerous ways monitoring along these lines could be abused, whether the data is SSL or not. Additionally, this is something most of us going about our business probably haven’t accounted for, much less know what to do about it.

What we do know is that it’s important that content providers—such as gaming studios or streaming services—affected by this research account for it, and look at ways of obfuscating data still further.

Afterall, a world where your supposedly private choices are actually parseable feels very much like a Black Mirror episode waiting to happen.

The post Researchers go hunting for Netflix’s Bandersnatch appeared first on Malwarebytes Labs.

Mozilla launches Firefox Send for private file sharing

Mozilla look to reclaim some ground from the all-powerful Chrome with a new way to send and receive files securely from inside the browser. Firefox Send first emerged in 2017, promising an easy way to send documents without fuss. The training wheels have now come off and Send is ready to go primetime. Will it catch on with the masses, or will only a small, niche group use it to play document tennis?

How does it work?

Firefox Send allows for files up to 1GB to be sent to others via any web browser (2.5GB if you sign in with a Firefox account). The files are encrypted after a key is generated, at which point a URL is created containing said key. You send this URL to the recipient, who is able to then download and access the file securely. Mozilla can’t access the key, as the JavaScript code powering things only runs locally.

Before sending, a number of security settings come into play. You can set the link expiration to include number of downloads, from one to 200, or number of days the link is live (up to seven). Passwords are also available for additional security.

It’s not for everyone

The process isn’t 100 percent anonymous, as per the Send privacy page:

IP addresses: We receive IP addresses of downloaders and uploaders as part of our standard server logs. These are retained for 90 days, and for that period, may be connected to activity of a file’s download URL. Although we develop our services in ways that minimize identification, you should know that it may be possible to correlate the IP address of a Send user to the IP address of other Mozilla services with accounts; and if there is a match, this could identify the account email address.

Of course, there may be even less anonymity if you use the service while signed into a FireFox account to make use of the greater send allowance of 2.5GB.

As a result, this might not be something you wish to use if absolute anonymity is your primary concern.

Who is likely to make use of this?

Send is for situations where you need to get an important file to someone but:

  1. The recipient isn’t massively tech-savvy. If you’re dealing with applications involving a drip feed of documents over time, this can get messy. Eventually, the person at the other end will have had enough of multiple AES-256 encrypted zip files hosted on Box where the password never seems to work, or they don’t have the right zip tool to extract the file. Send will simplify that process.
  2. The person at the other end is tech-savvy. However, they’re not necessarily aware that sending bank details or passport photos in plaintext emails is a bad idea.

A Mozilla project manager mentioned issues involving Visa-related documents in the cloud, and this is definitely where a service like Send can flourish. Multiple uploads over time usually ends up in a game of “hunt the files.” Did you delete everything? Maybe you should leave some of it online in case a problem arises? Are the files really gone if you delete them all, or is it as simple as flipping a “Whoops, didn’t mean it” switch and watching them all come back?

These are real-world, practical problems that people run into on a daily basis. The duct tape, multiple service/program approach works up to a point—and then it doesn’t. Firefox Send is perhaps a bit niche, but there’s nothing wrong with that. Not everyone is a fan of leaving important documents scattered across Google Drive or Dropbox, and this is a handy alternative. We’ll have to see what impact this product has long-term, but having more privacy options available is never a bad thing.

The post Mozilla launches Firefox Send for private file sharing appeared first on Malwarebytes Labs.

Spectre, Google, and the Universal Read Gadget

Spectre, a seemingly never ending menace to processors, is back in the limelight once again thanks to the Universal Read Gadget. First seen at the start of 2018, Spectre emerged alongside Meltdown as a major potential threat to people’s system security.

Meltdown and Spectre

Meltdown targeted Intel processors and required a malicious process running on the system to interact with it. Spectre could be launched from browsers via a script. As these threats were targeting hardware flaws in the CPU, they were difficult to address and required BIOS updates and some other things to ensure a safe online experience. As per our original blog:

The core issue stems from a design flaw that allows attackers access to memory contents from any device, be it desktop, smart phone, or cloud server, exposing passwords and other sensitive data. The flaw in question is tied to what is called speculative execution, which happens when a processor guesses the next operations to perform based on previously cached iterations.

The Meltdown variant only impacts Intel CPUs, whereas the second set of Spectre variants impacts all vendors of CPUs with support of speculative execution. This includes most CPUs produced during the last 15 years from Intel, AMD, ARM, and IBM.

This is not a great situation for everyone to suddenly find themselves in. Manufacturers were caught on the backfoot and customers rightly demanded a solution.

If this is the part where you’re thinking, “What caused this again?” then you’re in luck.

Speculative patching woes

The issues came from something called “speculative execution.” As we said in this follow up blog about patching difficulties:

Speculative execution is an effective optimization technique used by most modern processors to determine where code is likely to go next. Hence, when it encounters a conditional branch instruction, the processor makes a guess for which branch might be executed based on the previous branches’ processing history. It then speculatively executes instructions until the original condition is known to be true or false. If the latter, the pending instructions are abandoned, and the processor reloads its state based on what it determines to be the correct execution path.

The issue with this behaviour and the way it’s currently implemented in numerous chips is that when the processor makes a wrong guess, it has already speculatively executed a few instructions. These are saved in cache, even if they are from the invalid branch. Spectre and Meltdown take advantage of this situation by comparing the loading time of two variables, determining if one has been loaded during the speculative execution, and deducing its value.

Four variants existed across Spectre and Meltdown, with Intel, IBM, ARM, and AMD being snagged by Spectre and “just” Intel being caught up by Meltdown.

The vulnerabilities impacting CPUs (central processing units) made it a tricky thing to fix. Software alterations could cause performance snags, and hardware fixes could be even more complicated. A working group was formed to try and thrash out the incredibly complicated details of how this issue would be tackled.

In January 2018, researchers stressed the only real way to solve Spectre was redesigning computer hardware from the ground up. This is no easy task. Replace everything, or suffer the possible performance hit from any software fixes. Fairly complex patching nightmares abound, with operating systems, pre/post Skylake CPUs, and more needing tweaks or wholesale changes.

Additional complications

It wasn’t long before scams started capitalising on the rush to patch. Now people suddenly had to deal with unrelated fakes, malware, and phishes on top of actual Meltdown/Spectre threats.

Alongside the previously mentioned scams, fake websites started to pop up, too. Typically they claimed to be an official government portals, or plain old download sites offering up a fix. They might also make use of SSL, because displaying a padlock is now a common trick of phishers. That’s a false sense of security—just because there’s a padlock, doesn’t mean it’s a safe site. All it means is the data on it is encrypted. Beyond that, you’re on your own.

The site in our example offered up a zipfile. Contained within was SmokeLoader, well known for attempting to grab additional malicious downloads.

SmokeLoader

Click to enlarge

Eventually, the furore died down and people slowly forgot about Spectre. It’d pop up again in occasional news articles, but for the most part, people treated it as out of sight, out of mind.

Which brings us to last week’s news.

Spectre: What happened now?

What happened now is a reiteration of the “it’s not safe yet” message. The threat is mostly the same, and a lot of people may not need to worry about this. However, as The Register notes, the problem hasn’t gone away and some developers will need to keep it in mind.

Google has released a paper titled, unsurprisingly enough, “Spectre is here to stay: An analysis of side-channels and speculative execution.”

The Google paper

First thing’s first: It’s complicated, and you can read the full paper [PDF] here.

There’s a lot of moving parts to this, and frankly nobody should be expected to understand everything in it unless they’re working in or around this in some capacity. Some of this has already been mentioned, but it’s already about 700 words or so ago so a short recap may be handy:

  1. Side channels are bad. Your computer may be doing a bunch of secure tasks, keeping your data safe. All those bits and pieces of hardware, however, are doing all sorts of things to make those secure processes happen. Side channel attacks come at the otherwise secure data from another angle, in the realm of the mechanical. Sound, power consumption, timing between events, electromagnetic leaks, cameras, and more. All of these provide a means for a clever attacker to exploit this leaky side channel and grab data you’d rather they didn’t.
  2. They do this in Spectre’s case by exploiting speculative execution. Modern processors are big fans of speculative execution, given they make use of it extensively. It helps improve performance, by making guesses about what programs will do next and then abandoning if it turns out that doesn’t happen after all. Conversely, the retained paths are deployed and everything gets a nice speed boost. Those future potential possibilities is where Spectre comes in.
  3. As the paper says, “computations that should never have happened…allow for information to be leaked” via Spectre. It allows the attacker to inject “dangerously speculative behaviour” into trusted code, or untrusted code typically subjected to safety checks. Both are done through triggering “ordinarily impossible computations” through specific manipulations of the processor’s shared micro-architectural states.

Everything is a bit speed versus security, and security lost out. The manufacturers realised too late that the speed/security tradeoff came with a hefty security price the moment Spectre arrived on the scene. Thinking bad actors couldn’t tamper with with speculative executions—or worse, not considering this in the first place—has turned out to be a bit of a disaster.

The paper goes on to list that Intel, ARM, AMD, MIPS, IBM, and Oracle have all reported being affected. It’s also clear that:

Our paper shows these leaks are not only design flaws, but are in fact foundational, at the very base of theoretical computation.

This isn’t great. Nor is the fact that they estimate it’s probably more widely distributed than any security flaw in history, affecting “billions of CPUs in production across all device classes.”

Spectre: no exorcism due

The research paper asserts that Spectre is going to be around for a long time. Software-based techniques to ward off the threat will never quite remove the issue. They may ward off the threat but add a performance cost, with more layers of defence potentially making things too much of a drag to consider them beneficial.

The fixes end up being a mixed bag of trade-offs and performance hits, and Spectre is so variable and evasive that it quickly becomes impossible to pin down a 100 percent satisfactory solution. At this point, Google’s “Universal Read Gadget” wades in and makes everything worse.

What is the Universal Read Gadget?

A way to read data without permission that is for all intents and purposes unstoppable. When multiple vulnerabilities in current languages run on the CPU, it allows construction of said read gadget and that’s the real meat of Google’s research. Nobody is going to ditch speculative execution anytime soon, and nobody is going to magically come up with a way to solve the side channel issue, much less something like a Universal Read Gadget.

As the paper states,

We now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations…as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels.

On the other hand, it’s clear we shouldn’t start panicking. It sounds bad, and it is bad, but it’s unlikely anyone is exploiting you using these techniques. Of course, unlikely doesn’t mean unfeasible, and this is why hardware and software organisations continue to wrestle with this particular genie.

The research paper stresses that the URG is very difficult to pull off.

The universal read gadget is not necessarily a straightforward construction. It requires detailed knowledge of the μ-architectural characteristics of the CPU and knowledge of the language implementation, whether that be a static compiler or a virtual machine. Additionally, the gadget might have particularly unusual performance and concurrency characteristics

Numerous scenarios will require different approaches, and it lists multiple instances where the gadget will potentially fail. In short, nobody is going to come along and Universal Read Gadget your computer. For now, much of this is at the theoretical stage. That doesn’t mean tech giants are becoming complacent however, and hardware and software organisations have a long road ahead to finally lay this spectre to rest.

The post Spectre, Google, and the Universal Read Gadget appeared first on Malwarebytes Labs.