How to secure Ethereum JSON RPC from Vulnerabilities

How to secure Ethereum JSON RPC from Vulnerabilities

·

4 min read

Blockchain technology has emerged like a revolution in the world of Internet and is now finding abundant use-cases in major industries like finance, insurance, gaming, asset management, digital records, and a lot more.

**## Introduction to Ethereum JSON RPC – **

It is an interaction protocol between various Ethereum nodes. This communication protocol uses HTTPS or web sockets to send low-level commands.

With the possibility of interacting with the Ethereum nodes using JSON/RPC nodes remotely, the system has grown to be more vulnerable than ever. It can lead to hacking of your account. Hackers are always looking for insecure nodes.

**## Various vulnerabilities faced while connecting to Ethereum node remotely **

  • Unsafe deserialization in ois.readObject in mine/Ethash.java and decode.readObject in cyrpto/ECKey.java. When a new block is mined, arbitrary OS commands can run on the server.

  • A smart contract code can cause out-of-bounds read which can result in the execution of out-of-bound writing, thereby resulting in remote code execution. A hacker can use this as an opportunity to create/send a malicious smart contract

  • Improper Authorization Vulnerability: A JSON request can directly be used to access the restricted functionality which can cause authorization bypass.

  • Especially crafted smart contracts can cause out-of-bounds read leading to a denial of service (DoS) attack or memory disclosure.

  • An exploitable unhandled exception vulnerability exists which can result in denial of service.

info1-ethereum.png

**## Securing Ethereum Nodes – **

Ethereum facilitates interaction with its interface using JSON/RPC remotely. Securing Ethereum nodes is essential because hackers are always running automatic scanners that are looking for unprotected nodes to steal the ETH, therefore an incorrect Ethereum node can lead to accounts becoming easily prone to hacking.

Ethereum platform, as a representation of Blockchain 2.0, implements a new computing standard running on top of blockchains known as the Decentralized Applications (DApps). The prolific applications of DApps distinctly introduces many security vulnerabilities.

**### 1. Restricting interface on which geth nodes listen **

Using the ‘-rpcaddr geth’ command, a restriction can be placed on HTTP-RPC must listen. Running geth with -rpcaddr 0.0.0.0 is highly insecure as anyone can access the HTTP_RPC remotely. It is advised to use -rpcaddr 127.0.0.1 or private network IP to make it more foolproof.

Server IPs can be checked by the command

ifconfig|grep netmask|awk ‘{print $2}’

**### 2. Restricting remote Ethereum node access using SSH/Tunneling for development purposes **

For development purposes, you SSH tunneling if you must access a remote Ethereum node that will listen to the loopback address. SSH tunneling can be set up in the ~/.ssh/config file. Tunnel from local port 8545 to server port 8545.

  • Host ethereum-testnet #This can be used to specify nicknames or abbreviations for hosts

  • User ec2-user # ethereum server remote ssh user

  • Hostname 1.1.1.1 # Server IP address

  • IdentityFile ~/.ssh/testnet-private-key.pem # path to ssh key on your local machine

  • LocalForward 8545 localhost:8545 # tunnel command

The above code will help in communicating to the Ethereum node as if it’s running on your local port 8545.

**### 3. Restricting remote Ethereum node access using SSH/Tunneling for production purposes **

If you are running your geth node in a production environment then deploy it in a custom vpc in the cloud like AWS/Azure/GCP. You can build a virtual network in the cloud through the security group, NACL, and subnet. They will help in customizing the network flow.

**-Use nginx as a reverse proxy and turn HTTP basic auth on ** Set basic nginx authentication so that you can enable basic authentication in which username & password will be used for authentication.

**## Making RPC requests over WebSocket **

Like HTTP, you can also secure WebSocket endpoint with authorization also by incorporating the following section in your configuration –

location ^~/ws{
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Nginx-Proxy true;
proxy_pass http://127.0.0.1:8546/;

**## Steps to generate basic HTTP Auth basic credentials – **

Command: htpasswd -c <path-to-store-password-file> <username>

You will be asked to enter your password two times for verification. After successful execution of the command, the password will be stored in the file created at the given location

In addition to setting up authentication, close the 8545 port in your server firewall so that it can be accessed through the nginx configured path. Below is the code using abc.com/rpc as the HTTPS path.

server {
listen 80;
listen [::]:80;
server_name abc.com;
listen 443 ssl;
ssl on;
ssl_certificate{cert_path_for_abc.com}/fullchain.pem;
ssl_certificate_key{cert_path_for_abc.com}/privkey.pem;
include etc/letsencrypt/options-ssl-nginx.conf; #if certificate is issued from letsencrypt
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; #if certificate is issued from letsencrypt:80;
}

**## Conclusion: **

With the ease of accessing the Ethereum node, the vulnerabilities of the system also increase. These vulnerabilities can be exploited by attackers and hackers. To safeguard your system, certain checks must be implemented based on the environment you are working in. Here is where you can choose and trust Zeeve as your steadfast service provider. Zeeve can help you with seamless performance and make your remote connection more secure by limiting the interaction of remotely connected nodes and keeping a restriction on the intermediate interface.