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
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.
In short, this means they are not prepared to deal with new attacks that are implemented in Wasm code.
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.