This is an electronic reprint of the original article. This reprint may differ from the original in pagination and typographic detail. Bui, Thanh; Rao, Siddharth; Antikainen, Markku; Aura, Tuomas Pitfalls of open architecture Published in: Proceedings of the 12th European Workshop on Systems Security, EuroSec 2019 DOI: 10.1145/3301417.3312495 Published: 25/03/2019 Document Version Early version, also known as pre-print Please cite the original version: Bui, T., Rao, S., Antikainen, M., & Aura, T. (2019). Pitfalls of open architecture: How friends can exploit your cryptocurrency wallet. In Proceedings of the 12th European Workshop on Systems Security, EuroSec 2019 (pp. 6). [3] ACM. https://doi.org/10.1145/3301417.3312495 This material is protected by copyright and other intellectual property rights, and duplication or sale of all or part of any of the repository collections is not permitted, except that material may be duplicated by you for your research use or educational purposes in electronic or print form. You must obtain permission for any other use. Electronic or print copies may not be offered, whether for sale or otherwise to anyone who is not an authorised user. Powered by TCPDF (www.tcpdf.org) Pitfalls of open architecture: How friends can exploit your cryptocurrency wallet Submitted to EuroSec’19 ABSTRACT stolen from wallets by exploiting the remotely-accessible RPC in- Many cryptocurrency wallet applications on desktop provide an terface where authentication has not been properly configured [55]. open remote procedure call (RPC) interface that other blockchain- The primary solution for protecting the RPC interface against such based applications can use to access their functionality. This paper attacks has been to block remote access to the interface so that studies the security of the RPC interface in several cryptocurrency only local processes on the computer can access it. Furthermore, wallets. We find that, in many cases, a malicious process running the wallet applications usually require password authentication on the computer regardless of its privileges can impersonate the when accessing the RPC interface. However, while these security communication endpoints of the RPC channel and, effectively, steal mechanisms may help against remote attacks, their effectiveness the funds in the wallet. The attacks are closely related to server against local threats has not been considered. and client impersonation on computer networks but occur inside This paper studies the security of the RPC interface of the wallet the computer. The malicious process may be created by another applications in the presence of a local attacker. Our main contribu- authenticated but unprivileged user on the same computer or even tion is to show vulnerabilities in popular cryptocurrency wallets, by the guest user. The main contribution of this paper is to raise which allow nonprivileged processes that belong to other users on awareness among wallet developers about the need to protect local the same computer to exploit their RPC channel and steal the wal- RPC channels with the same prudence as network connections. We let content. We also show that the currently used authentication also hope that it will discourage users to run security-critical appli- mechanisms on the channel are not effective and discuss potential cations like cryptocurrency wallets on shared systems or computers mitigation techniques. with guest account enabled. The rest of the paper is organized as follows: Section 2 describes the background information on cryptocurrency wallet applications CCS CONCEPTS and our threat model. Section 3 shows our attacks to the RPC inter- face of various wallet applications, and Section 4 presents mitigation • Security and privacy → Authentication; Software security engi- solutions to the attacks. We have reported all the vulnerabilities neering. that we found to the corresponding vendors and received responses from Parity [21] and Bitcoin Core [5] teams. We include these re- KEYWORDS sponses in Section 5. Section 6 reviews the related prior research Cryptocurrencies, Remote Procedure Call (RPC), Impersonation and Section 7 concludes the paper. 1 INTRODUCTION 2 BACKGROUND This section describes how a typical cryptocurrency wallet applica- Bitcoin [45] and other cryptocurrencies have become remarkably tion works as well as explaining our threat model. popular in the last decade. In cryptocurrencies, transactions happen between public keys and are communicated as signed messages in an open peer-to-peer (P2P) network. The transactions are col- 2.1 Cryptocurrency wallets lected into blocks, which are appended into a structure, called the Most cryptocurrencies have one “official” wallet applications and blockchain. The global consistency of the blockchain is guaranteed several recommended third-party applications. A wallet application with a consensus mechanism, such as proof-of-work [45], proof-of- typically provides a command-line or graphical user interface for stake [35], or a Byzantine fault-tolerant (BFT) variant [52]. the users to manage their cryptocurrency accounts. Each account Users access a cryptocurrency with a wallet, which manages the is basically a private/public key-pair that is used for transactions private/public key-pairs that are used for transactions and allows and usually encrypted with a password. (Note that in some places the user to store, send and receive the cryptocurrency. There are “wallet” is used to refer to such key pair. We chose to use “account” various types of cryptocurrency wallets: online, mobile, desktop, instead to easy differentiation between key pairs and wallet appli- paper, and hardware wallets, each of which has its own pros and cations.) The user must enter the password to unlock the account cons [32]. This paper focuses solely on desktop wallet applications. before it can be used. For simplicity, in the rest of the paper, we will use wallet applications Most wallet applications provide a remote procedure call (RPC) to refer to desktop wallet applications. interface with a JSON-RPC over HTTP server [40] that runs on a Desktop wallet applications often provide a remote procedure call specific port number on the localhost. Other applications can con- (RPC) interface, through which other applications can access the nect to the RPC server as clients to access the wallet’s functionality, wallet’s functionality either locally or remotely. While this open such as querying account balance or making transactions. Examples interface enables easy development of other blockchain-based ap- of such RPC client applications include web-browser extensions plications, it increases the attack surface of the wallet. In fact, there [17], third-party wallet applications that do not want to implement have been reports on attacks where cryptocurrencies have been the cryptocurrency protocol by themselves [4], and cryptocurrency EuroSec’19, March 2019, Dresden, Germany Alice's login session Alice's login session Alice's login session RPC client Wallet app RPC client Wallet app RPC client Wallet app 8332 8332 8332 8332 Evil process Evil process Mallory's login session Mallory's login session (a) Normal operation (b) Server impersonation (c) Client impersonation Figure 1: Attacks on the RPC channel of a wallet application by a nonprivileged user exchange web platforms [3, 22]. While the number of RPC client 3.1 Case 1: Wallets with no authentication applications is still fairly low, the availability of open RPC interfaces Ethereum [56] has two official command-line wallets: Go-Ethereum and client libraries indicate that the wallet developers expect the (Geth) [14] and CPP [9], out of which only the former supports the ecosystem of such add-on software to grow in the future. RPC interface. If the user enables the RPC interface, Geth runs the RPC server on port 8545 of the localhost by default so that only 2.2 Threat model local clients can access it. Geth does not require any authentication In this paper, we consider threats on multi-user computers that have mechanism on its RPC interface, and it does not support TLS. If the processes belonging to two or more users running at the same time. user wants to access the interface over TLS, he/she must configure The attacker is a logged-in user who tries to steal cryptocurrency a TLS proxy on the same host, which relays requests to the RPC from the wallet of another logged-in user of the same computer. interface. The only security mechanism that Geth provides is allow- The attacker does this by impersonating the communication end- ing the user to configure cross-origin resource sharing (CORS) [41] points of the wallet’s RPC channel, as illustrated in Figure 1. Unlike to authorize specific web pages that are open in the user’s browser malware that runs with the victim’s privileges or as administrator, to access the wallet. the attacker here is nonprivileged, and we do not assume that he Attacks. Since there is no authentication between the RPC client can perform any kind of privilege escalation. and the RPC server, a malicious nonprivileged process can imper- To exploit the RPC channel, the attacker needs to run a process sonate the client by simply connecting to the server. CORS is clearly in the background when the victim is using the computer. On Linux not an effective mitigation solution here because the attacker can and macOS, the attacker only needs to log in, run the process, and set the Origin header of its HTTP requests to anything. While an leave it running when he logs out, e.g. with the nohup command. On account could be encrypted with a password, Geth allows the user Windows, user processes are killed at the end of the login session, to unlock the account when starting it. This allows the malicious and thus the attacker needs to do fast user switching [43] to leave client to access the account without knowing the password and, his session in the background. The attacker can also remotely run for example, sends the victim’s funds to the attacker’s account.