Breaking New Ground: WebAssembly’s Rising Role in Web Development and Its Security Concerns

11/19/2019
G DATA Blog

Getting to Know WebAssembly

Web applications development is continuously accelerating—from simple pages that use HTML/CSS/JavaScript, to the use of plugins like Flash and Java applets, to server–side tools that create programs over the Internet instead of installing them locally on users’ desktops or mobile devices. The driving force for these developments is the need to provide more information and services that can be easily accessed by the end users.

One of the most popular and important components in developing these apps is JavaScript (JS), due to its functionality in creating dynamic/interactive web pages and cross-platform support across web browsers. However, websites and applications with complex JS code suffer from optimization problems and slow execution. Several technologies were developed to address these issues such as Portable Native Client (PNaCl) by Google and asm.js by Mozilla, which can convert low-level codes into programs that run very fast within the browser. Despite addressing the performance issues, these solutions still struggle to execute in a way that developers want their applications to perform. These efforts gave way to the creation of a new tool for web applications development called WebAssembly (Wasm).

How WASM works

WebAssembly is an open standard low-level assembly language and binary format that executes at near-native speeds, compiled from languages like C/C++. It is designed to help web apps coded with JS in executing more efficiently. Wasm has capabilities not limited to the following:

  • Portable — able to run in different browsers and platforms
  • Compact — files are already in bytecode and directly executed by the browser
  • Fast execution — less time spent parsing and optimizing
  • Support — can compile old programs coded in C/C++ that previously required dependencies

Several tools can be used to compile C/C++ code into Wasm such as Emscripten, a compiler toolchain that runs in operating systems like Linux and Windows.

Emscripten outputs three files: 1) the Wasm file that is the compiled C/C++ code; 2) the JavaScript file used to instantiate and call the Wasm file; 3) and the HTML page that loads the JS and Wasm files into a web browser. The Wasm, JS, and HTML files form the web application that is rendered in the browser.

Converting the code using Emscripten would result in a Wasm bytecode as show in the image below. It should be noted that the first few hex bytes of the file indicating it as Wasm is 0x00 0x61 0x73 0x6D (“ asm”).

The image below is the loaded web page of the string “Hello, world!” initially written in C and converted to Wasm. Emscripten also automatically generates a basic HTML layout that correctly outputs the printf command of C upon loading in the browser. Even though Wasm is relatively new, web developers are keen to try out this tool for their applications. Various companies and entities are already adapting this new technology for the web.

Industry Adaption and Acceptance

All modern browsers support WebAssembly, although some browsers such as MS Edge Mobile and Extended Support Release of Firefox disable support for Wasm by default. Momentum is slowly gaining for industry acceptance and support as developers are implementing Wasm in their web applications.

Video games are known for being high-load applications that have heavy CPU and graphics memory usage. Early demonstrations of Wasm therefore focused on video games since Wasm is designed for efficiency and a minimal memory footprint. Two examples are the D3Wasm project and Unity. D3Wasm is a port of the id Tech 4 engine into Wasm, which can render the game “Doom 3”. Users are now able to play the game in any web browser that supports WebGL, showing that it is possible to load large programs with Wasm. In August 2018, the video game engine Unity switched their default target web format from asm.js to Wasm. They noted that Wasm is more efficient compared with asm.js in terms of smaller code size, memory efficiency during load time, and faster performance. 

WebAssembly’s capabilities in image processing was recently demonstrated on Ebay’s online version of their bar code scanner. Users assumed that the old version of the application did not work properly because the processing time of the scanner was too slow. The new online scanner utilized both Wasm and JS and was found to be 50 times more efficient than the JS-only version of the application.
AutoCAD also created a version of their desktop software for the web that targets portability. Their initial development was built on the now-deprecated Adobe Flash, later switching to HTML5/JS. They were able to port their C++ code base into Wasm, some of which are 30 years old. The result is an application that can be accessed by the registered users over the web.
Lastly, Google Earth is the most recent and significant web application that uses Wasm. Like the above examples, the code base of Google Earth is in C++ and was ported using Emscripten. While the previous version of Google Earth was compiled in Native Client (NaCl) that only runs in Chrome, the newer version can be accessed by all major browsers that support Wasm. Currently the development of Wasm is a work in progress to adapt to newer Wasm-related technologies.

With more companies integrating WebAssembly in their applications due to its versatility and advantages which can complement and work alongside JavaScript, the future for this technology is optimistic. But much like JS and other web application tools, Wasm will also gain attention from cybercriminals and malware authors. Therefore, we also need to focus on Wasm’s security and its possible use in malware by cybercriminals.

Security Concerns

WebAssembly’s security architecture was designed in response to the shortcomings of previous technologies such as JavaScript and Flash. It runs in an isolated/sandboxed environment within the browser. When an application written in WebAssembly is executed, it cannot directly access or modify the functions or variables that are not yet called. Any calls needed by the application must be verified by the browser’s engine/environment before it gives access to the called instruction or memory allocation.
However, Wasm can still be used for malicious activities. An example would be a file collected by G DATA that was found to be compiled into Wasm. Based on the modules from its header the file was used for Cryptonight mining, an algorithm for cryptocurrency mining such as Monero and Electroneum.

Although Cryptonight is not malicious by itself, malware authors are compiling it into Wasm instead of JS and injecting them in websites to illicitly mine cryptocurrencies from users’ browsers by hijacking the CPU to use its processing power. This makes sense as JS is commonly used in crytpomining, the malware authors in this situation optimize their attack by leveraging Wasm to increase their mining efficiency as cryptomining requires large computing power.

According to research presented at Blackhat USA 2018, possible vulnerabilities that can use WebAssembly include cross-site scripting (XSS), where the function definitions in Emscripten calls JS to execute malicious code. If such vulnerabilities would exist in Wasm, then drive-by downloads that can be executed outside the browser environment are possible leading to malicious behavior like invoking PowerShell or process injection although no recent proof-of-concept are available yet to leverage these exploits in WebAssembly. 

Is WebAssembly Future Friendly?

With its many possibilities, WebAssembly could be either a friend or a foe. It adds overwhelming advantages to applications development but can provide new avenues for vulnerabilities that may lead to exploits and malware attacks. However, adaption of Wasm for malicious activity is not yet imminent as development is still ongoing with continuous improvements in its security standards and general implementation in web browsers. The future of Wasm is anticipated, but we must prepare for any emerging threats that may surface.

While developers are responsible for the security of Wasm as compiled modules are the most probable targets, end-users must also constantly update their browsers and plugins. Users can download browser extensions such as NoScript, a software that blocks dynamic web content, to stop any Wasm files from loading as it currently uses Javascript as the glue code to execute on a web page. The maximum privacy and security settings for browsers can be enabled for a safer web surfing. It is also best to be on the lookout for suspicious activities on the web.

Sample IOC

  • SHA256: 3f5961a80d3aa7cb06520fd8e89558170936a1a4a3fe16e9fc84c379518c0759
  • Malware type: Cryptonight Wasm
  • Detection: Application.BitCoinMiner.ZV

G DATA Security Lab
Virus-Analyst Team