Security Vulnerability Report: Remote Code Execution in Status Desktop Client

Summary

A bug in Status Desktop Alpha allows for remote code execution (RCE).  Status desktop is built on the react-native-desktop repository, which runs a JavaScript engine server for code execution.  A vulnerability was disclosed through our HackerOne campaign that allows anyone on the local network to bind to this server and run arbitrary code on the client’s device.  This was patched to only bind to localhost and new versions of Desktop have been released.  Long term solutions are underway to properly sandbox the application from outside communications.

All desktop clients are subject to this vulnerability and will need to upgrade immediately to a version >= 0.12.2 which are available at https://status.im/get/.  Mobile Status clients are not affected.  

*Status Desktop is still in Alpha and alpha software may contain vulnerabilities. We recommend that you do not import a key that has significant value. Code changes are regular and the expected users are developers.

Products affected

• All Status Desktop versions, before 0.12.2.
• Status Mobile is unaffected.

Am I affected?

If you downloaded and used Status Desktop in a version before 0.12.2, yes.  You can find out your current version by going to Profile, then About.

The attacker is required to bind to your machine via port 5000. If not running a personal firewall on your device, this can be accomplished on a local network, or through a specially crafted malicious website.

Mitigation

Download latest versions of desktop at https://status.im/get/

If an attacker has used this vulnerability against you, they are able to run arbitrary code on the device with the same user privileges as the user running the Status Desktop client.  Note that Status Desktop needs to be running.  This means they would have access to your encrypted keystore file.  The attacker would then need to decrypt this keystore file, which is possible if your password is weak.  

It is recommended that if you feel it is possible that someone has had the opportunity and motive to use this against you, then you should create a new account with a newly downloaded client.

It is also recommended that you run virus and malware scanning software, as an exploited device would have the ability to install malicious software on the exploited device.

Description

Excerpt from HackerOne disclosure:

The Status_im desktop application starts an application "ubuntu-server" in the background. This is a node application that opens a socket and executes whatever code is sent to it.

This code is running through the "vm" module, but as the node documentation states "The vm module provides APIs for compiling and running code within V8 Virtual Machine contexts. The vm module is not a security mechanism. Do not use it to run untrusted code. The term "sandbox" is used throughout these docs simply to refer to a separate context, and does not confer any security guarantees." This can be "bypassed" by grabbing the passed in objects constructor and bouncing up to the function constructor which will give us the "global" scope. From there we can grab "process", get the "mainModule" and require in child process to execute any shell commands.

This means if we can talk to this service we can execute code. This can be done directly if we are on the same network, or we can trigger the issue by having the user view a malicious website over an extended period of time.

The immediate vulnerability has been addressed by rejecting all connections outside the device.  The longer term solution is to implement a proper sandbox around the Status Desktop client by migrating from the “vm” package to the “vm2” package. This way, connections cannot enter or leave without proper whitelisting or acknowledgement.

Takeaways

This dependency was inherited from Canonical when we forked it to create the desktop client.  It is clear that new dependencies, especially when containing communication connections, need to be more thoroughly audited.  

In the process of releasing a hotfix for this, we identified various inefficiencies in the process of going from pull request to cut release, which is now being audited and improved.  An organizational process that includes assumptions has a higher chance of failure or being drawn out longer than it needs to be.  This can (and will be) improved by infrastructure automation, proper process for listing requirements, and ownership of said requirements.

A quality bug bounty program can help supplement an organization's security practices. Every organization will have weaknesses, and incentivizing others to find and responsibly disclose vulnerabilities can drastically improve the security coverage of an organization.

The Desktop client is Alpha software, and is expected to have bugs as it has not been thoroughly audited.  It also has copy for warning the user that this is the case.  In our opinion, disclosures like this are exactly the reason to run and publish Alpha software, as well as include them in bounty programs.  

See the full post-mortem here: https://notes.status.im/-1H2rIhcTkGRiG2w8RsbEQ

Help us make more secure software

This particular vulnerability was brought to our attention by the community.  Big shout out and thank you to HackerOne hacker @mattaustin for a wonderfully comprehensive disclosure and prompt, detailed answers to questions afterwards.  Additional thanks to the HackerOne triage team for validating and working with us throughout this process.  

We always encourage and appreciate feedback so that we can improve both the Status organization and software we produce.  If you have questions/comments/concerns, please email security@status.im or talk with us on Status in the #status-security channel.