Research: More worries with Wasm

In many web browsers, the WebAssembly programming language is taking over execution tasks that were once exclusively the domain of JavaScript. Now Wasm is used increasingly for malicious purposes, new research shows.

Wasm (the WebAssembly code) has gained significant traction on websites over the past three years. Before WebAssembly, developers were stuck with JavaScript. They didn’t have another choice that could deliver both speed and performance in the same package.

The problem with JavaScript is that it wasn’t designed to be the controller of  CPU-intensive tasks and ran into performance problems when it was forced to.

Wasm, on the other hand, benefits from how it formats data, which enables it to speed up execution. This advantage allows for speeds similar to that of a compiled language like C.

The major browser makers have agreed on WebAssembly as a format. It now runs on most modern browsers.

However, there’s a catch, and it’s not trivial.

According to a recent publication by German researchers from Technical University Braunschweig, they discovered that more than half of the Wasm modules they found in the wild and inspected are malicious and used for nefarious purposes.  

In their research paper, New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild, the team led by Marius Musch document what they found when they examined the prevalence of WebAssembly modules on Alexa Top 1 Million websites.

Source: TU Braunschweig

The TU Braunschweig researchers didn’t just check if Wasm was used on those sites. They took the measuring a step further.

Wasm More Prevalent

Looking at the time each site took to run the Wasm modules, they were able to also measure the extent of Wasm usage compared to the time spent on executing JavaScript code.

The researchers discovered that 1 out of 600 sites was using WebAssembly and that “one-third of these even spend more than 75 % of the time executing WebAssembly in comparison to time spent in JavaScript code.”

While that’s an interesting bit of information with mostly academic value, the real surprises result from the most labor-intensive part of the investigation.

The Price of WASM Prevalence

The researchers manually categorized each unique sample they had collected. This allowed them to identify several distinct use cases for Wasm that have found traction and, therefore, widespread adoption on the web.

What they saw wasn’t pretty. Cryptominers (especially those mining Monero) was an obvious malware classification category that was applicable for 32 % of all the unique code samples.

The researchers found that in 26 % of all of the sites that ran a miner, what they called “a significant fraction” of those Wasm-based miners were instantiated by third-party code (such as a “poisoned” library used in Wasm.)

The second of their categories covered the broad field of obfuscation, which amounted to 6 % of the unique samples. Modules in this category mask code so that its real purpose becomes unintelligible. Obfuscation helps hide malicious purposes, such as code targeting specific local network resources that should be off-limits from within a site visitor’s browser.

Malicious mining Wasm was found on more than half of the total sites analyzed by the researchers. Of the 506 sites with more than 50 % WebAssembly usage, 497 sites were found to draft their visitors’ browsers for cryptocurrency mining.

Wasm Whopper in the Wild

That number becomes the real Wasm whopper in the TU Braunschweig paper once we consider the off-campus  implications here.

Standard defenses against browser cryptojacking all predate WebAssembly. To function, they rely on parsing or inspecting JavaScript code to detect attacks.

In short, this means they are not prepared to deal with new attacks that are implemented in Wasm code.

The researchers make it clear in their report that the days of these defense methods may be numbered. Many are specifically designed to work with the peculiarities of JavaScript.

Old Tools No Match for Wasm Exploits

The fundamental differences between the two languages would require, they write, a “non-trivial amount of work” to modify these existing approaches to function in the stack-based virtual machine running the WebAssembly code.

I’ve written about WebAssembly exploits previously on this blog, in November 2018. Three points that I think bear mentioning in this context:

• Cryptominers were a problem even then, and Coinhive boasted of the performance boost owed to the use of WebAssembly.
• WebAssembly had several heap buffer overflow problems in certain versions. This can be a vulnerability that allows malware to get its hooks into the language’s code.
• Last but not least, any problem present in the high-level language (like a faulty library) from which the Wasm is compiled also becomes a buried problem in the resulting WebAssembly code.

Add to that the findings of the TU Braunschweig research project, and we’re in for more worrisome news on the Wasm front. The paper’s conclusion reads like a warning.

Wasm & the Browser: New Code. Old Worries.

WebAssembly, the researchers emphasize, has opened the door for entirely new obfuscation techniques that were not possible before.

Such a development would render existing analysis systems and defensive mechanisms useless, because Wasm enables their circumvention.

With traditional point solutions, such as antivirus tools or URL filtering, being already way behind the exploit curve anyway, that means that regular browsers - which process web-borne code on the local machine (including now the latest and greatest Wasm exploits)  - will be even less secure in the future.