Private blockchain testnet attack via RPC: Dappros experience

Report: Dappros Platform Ethereum Testnet attack via RPC

Dappros Platform testnet has been subject to a hacking attempt in June 2019. We would like to share more information here for the benefit of those projects and private blockchains who are opening their testnets to the public via RPC.

It should be noted that none of Dappros customers accounts or data have been affected and no real transfer of Ether has taken place. It is most likely we’ve been targeted by an automated scanner who is aiming to transfer funds from Ethereum blockchains’ coinbase accounts, widely scanning the internet for any Ethereum RPC endpoints.

The attack was first observed on 12th June 2019. This attack continued till 13th June 2019. During the above days, the attacker was able to “transfer” the Ether from the “Coinbase account” to the malicious address. It was observed that the attacker used the following address for the attack: 0xcB31Bea86c3becC1F62652bC8b211fe1bd7f8aEd.

After some searching, we were able to find this account on the Etherscan explorer. This account exists on the Ethereum mainnet. We were also able to observe that this account had transfers form multiple accounts.

Although the values were small but, if we take a cumulative sum of all the values then it is significant in terms of the value in USD. We were also able to find out some of the research papers that also highlighted the above account as a malicious account. The research paper we’re talking about is this: https://arxiv.org/pdf/1904.01981.pdf.

About the paper:

The mentioned paper is about a technique of creating a honeypot on the ethereum mainnet. The honey pot works similar to an ethereum mainnet full node. The authors of the paper have conducted an experiment where an ethereum full node with a coinbase account is created. The coinbase account has some funds stored in the account so that it can attract the attackers. The honeypot also consists of a backend and a frontend. The backend is connected to the ethereum full node and forwards requests from the frontend to the backend. The backend is designed such that the attacker request is parsed and the details about the attacker are stored in the database. The backend then creates a fake response to deceive the attacker into believing that the attacker is penetrating the system successfully.

A note about the Dappros testnet:

The Dappros testnet is a private network. The node is connected to the application via the RPC connection. This is a simple web application that is used to transfer ethers and tokens on the Dappros testnet. The RPC port that is exposed to all the applications to connect is port 8545 and the web socket port is 8546. So the application uses these two ports to connect to the Dappros testnet.

How was the attacker penetrating the system?

The attacker was able to connect to the remote node on the Dappros testnet via RPC port that was exposed to connect to the external application. This way the attacker was able to directly connect with the remote node on the Dappros testnet bypassing the application backend. The attacker may have used the port-scanning technique to connect to the remote node via an exposed port. The port numbers that were used to connect to the remote node were 8545 and 8546. These port numbers are standard port numbers that are commonly used as RPC and WebSocket ports, so there is a possibility that the attacker targeted these ports without even using port scanning.

How did the attacker transfer Ether?

Once the attacker was connected to the remote node, they were able to transfer the Ether from the coinbase account to their own account. Now to do that the attacker needs the passphrase of the coinbase account or the account needs to be unlocked. The attacker can launch a bot attack on the node by executing the sendTransaction() function after every other second. When the coinbase owner unlocks the account even for a second or two, the ethers will be transferred from its wallet to the attacker’s wallet. The other way to get access to the coinbase account is by its passphrase. There is a good possibility that the attacker will be able to crack a weak passphrase within a short timeframe.

What went wrong?

The attacker was able to exploit the network because the architecture itself was not secure. The architecture of the Dappros Platform Development Testnet at the time allowed all the external applications to connect to the Ethereum node via RPC. By default, the Ethereum RPC doesn’t have any authentication methods, unlike Bitcoin. It was not a good decision to expose the RPC port to all the IP addresses. This architecture can be made secure by a number of ways some of the ways are discussed in this post: https://medium.com/coinmonks/securing-your-ethereum-nodes-from-hackers-8b7d5bac8986
This post explores the idea of using a UFW firewall in order to create a whitelist. However, there is no mention of any method to add IP addresses into this whitelist. A method based on a KYC verification can be used to add the IP address of the application owner can be used to add new entries to the whitelist. All the IP addresses other than the specified IP addresses are not allowed to connect with the remote testnet node.

The other thing that the attacker was able to exploit was the coinbase account. The account was unlocked by the attacker and the “Ethers” have been transferred to the attacker’s account. In this case, the attacker used a bot attack to execute the function sendTransaction() on the remote node and send the Ethers to a malicious account. The code in the application backend used the function personal.unlockAccount() this function is used to unlock an account present in the Keystore folder. In the application backend, this function is used to unlock the coinbase account for a period of 2 seconds only. But as the attacker executes the script after every second, the ethers are transferred from the coinbase account to the attacker’s account. To overcome this instead of using personal.Unlockaccount() sendRawTransaction() can be used. However, sendRawTransaction() requires the private key of the account holder to sign the transaction.

Conclusion:

The main objective of the blog post is to share our experience and create awareness among developers so that such security flaws can be avoided. It was estimated in the above-mentioned paper that the amount of stolen ether is estimated to be around 4,193.58 Ethers which is equivalent to $583,956.23.

Dappros Platform did not suffer as result of the attack as only Development testnet was exposed. In any case, neither Development nor Production blockchains of Dappros Platform hold any real Ethers. We have learned however of potential vulnerability and have adjusted our architecture to protect against attacks of this type in future.

In addition to changes already implemented we continue to work with our partners and advisers to introduce better security safeguards and systems improving the cybersecurity situation around private enterprise blockchains that get exposed to the world. Last year we have brought together a number of cybersecurity companies and experts, an initiative announced in our blog post in September 2018: https://www.dappros.com/201809/addressing-cyber-security-within-blockchain-systems/

Comment from Taras Filatov, Dappros CEO:

It is interesting to note that the possibility of RPC vulnerability has actually been highlighted by one of our partners – Nanitor team has raised that issue in our discussion in September 2018 and this was covered in a presentation by Dalitso Phiri during “Future technologies” event we have hosted in Qatar in January this year: https://www.dappros.com/201901/event-future-technologies-blockchain-use-cases-doha-qatar/. Happy to work with experts in the area and will make sure to leverage their experience to make Dappros Platform and our customers’ private blockchains more secure.

Previous ArticleNext Article

Leave a Reply

Your email address will not be published. Required fields are marked *