Questions to answer
I have always been wondering if the people who run their own nodes have full awareness of what they are doing, do they copy-paste commands from some article they found, do they know what each argument does, do they have awareness of the power of their client RPC.
To answer those questions I made some research, and found a couple of ways to get IP addresses of nodes in the chain to pentest them
The first method was to run my own client using geth or any other and request the json-rpc for admin.peers to get peers around, I don’t need to run it on the mainnet, running on a private network will do the work, and I will keep receiving handshake requests from other peers
The second method is to use public information, I have found some resources the most helpful was ethernodes.
There are other ways to get better and more results like understanding the networking underlying the blockchain and making a custom tool that gathers nodes, or using the Ethereum beacon API, we will not use those in this research, but maybe someone will do in the future
Setting up geth client and scripts
I started my local geth client and checked the admin.peers, even though I am running my node on a private testnet but I am receiving handshake connections from remote nodes on different chains, I made a script that checks admin.peers every second and I got a lot of valid IP addresses of nodes, the purpose of that is to check if they have their json-rpc exposed to the public and to check if they have their accounts unlocked.
geth --datadir ethereum --networkid 1337 --port 30304 --http --http.api admin --http.corsdomain "*" --http.vhosts "*" --http.port 8555 --http.addr 127.0.0.1 --authrpc.addr 127.0.0.1the first test started on Jan-2 at 18:27:47 and stopped on Jan-2 at 22:03:02, this was just to demonstrate if I can get some interesting results.
Analyzing results
At that point, I scanned 1340 nodes from different chains, here are the results
each folder contains its json-rpc response, eth_mining missing an ip, probably a firewall blocked it or the node went down.
1107 of the total didn’t accept my requests whether for firewall, or it’s not exposed to the public, that’s a great sign, 82.6% of the nodes I scanned didn’t have any security issues with their nodes, but 18% did!
with 17 nodes from the mainnet 124 were from Taiko chain, and the rest are from different chains.
we had 80 enabled miners, and 197 miners disabled
The interesting part here is the personal_listAccounts, I found 276 wallets from 9 different nodes!!
9 nodes of that 18% had their wallets exposed, in the image above there are only 9 wallets shown, the rests are in one of the nodes
what a terrible thing to do, here I start digging deeper into that IP address, why it contains that much of addresses, and why it has a weird firewall, that blocks a request and allows it in the next minute.
First I checked if the wallets are locked or not, the first wallet is NOT!
That’s very interesting and weird, I had to investigate further, doing whois on the addresses revealed it belongs to <REDACTED>
<REDACTED> offers blockchain service for the infrastructure, maybe the node is for a customer? or it is theirs?
| later after publishing, I reported this to <REDACTED>, and they informed me that it is a customer asset.
I did a quick network scan for their network CIDR 174.xxx.xxx.xxx/17 using rustscan found 12 open ports, but only 7 of them had geth client actually, the node we found before is not included, probably because of the firewall
they all were running on the Ethereum mainnet, with 4 of them having the personal namespace disabled.
Now, with all of this analysis, we demonstrated that we can access a lot of nodes and almost do everything, but is really a critical issue? what are the implications?
First Yes it is a critical issue, we showed one of the nodes had its wallet unlocked, which means if it had balance any malicious user could steal it, and the owner won’t notice until it was too late, they can wait for users to unlock their locked wallets, they can automate this though, attackers can use them instead of paid services and make use of those free available nodes, they can also turn on/off the miners if this was allowed through json-rpc, they can use it like it’s their own client.
I have demonstrated enabling/disabling miner with my own geth to not interrupt others without permission.
What should we do?
when we run our clients on a public chain, users who run their own nodes must avoid enabling thepersonal namespace, or do not enable the RPC at all or keep it restricted to localhost at least
A better and recommended solution if you want to expose your RPC to the public but don’t want everyone
Extra Note
I did a scan for all active Ethereum nodes I found on ethernodes, 5431 active nodes at that time, and only 182 of them had their json-rpc exposed which is a good indicator for the mainnet nodes the 182 nodes, 37 of them had their account set but they were locked, another good indicator.
Conclusion
A lot of people tend to run their own clients on Ethereum without a proper understanding of what they are doing, in some cases, this will lead to bad consequences as we showed, and I haven’t seen this mentioned a lot, so I hope this article demonstrated enough consequences that will incentive users to have more awareness and follow best practices.
I might publish the script I used later on GitHub.
