7

Has anyone encountered the following scenario on Ropsten:

  1. You create an account in Geth, and proceed to transfer some ETH to yourself via a faucet.
  2. You unlock the account and proceed to start compiling and running contracts.
  3. Suddenly you find that all your ETHs are gone, transferred to 0x6Ef57BE1168628A2bD6c5788322A41265084408a.

This happened to me and a group of participants during a workshop where in a matter of seconds, all our ETH were stolen.

If you look at the transaction that has happened on this account in Etherscan, it runs in spurts, having small, and sometimes rather considerable amount of ETH transferred to itself.

Wanted to find out if this is something explainable. I realized that the same address 0x6Ef57BE1168628A2bD6c5788322A41265084408a is also found on Rinkeby.

Improve this question
8
  • Wanted to mentioned that as this was merely a trial, none of us secured our Geth instance. This was the command that ran the instance: geth --testnet --syncmode "light" --rpc --rpcapi db,eth,net,web3,personal,admin --cache=1024 --rpcport 8545 --rpcaddr 0.0.0.0 --rpccorsdomain "*
    – Jackson Ng
    Apr 7, 2018 at 6:56
  • What websites did you visit while the account was unlocked? With those RPC settings, any website you visited could take the funds.
    – user19510
    Apr 7, 2018 at 7:04
  • Just etherscan. All of us punched our account ID into etherscan to monitor our transactions. I know that the RPC settings were unsecure, but I am interested to learn about how a script can be written to trawl the blockchain for unsecure geth to steal ETH from and how it did so.
    – Jackson Ng
    Apr 7, 2018 at 7:07
  • It seems unlikely Etherscan would be the culprit. For any other website, it's just a few lines of code: new Web3('http://localhost:8545') and then a call to web3.eth.getAccounts to find the accounts and then web3.eth.sendTransaction to send ether.
    – user19510
    Apr 7, 2018 at 7:09
  • It also doesn't have to be a website... software on your computer or perhaps anyone else's in the workshop could do the same thing. There's nothing particularly difficult about doing it.
    – user19510
    Apr 7, 2018 at 7:11

1 Answer 1

Reset to default
3

I've encountered exactly the same situation on a private network when leaving an account unlocked on a node with a public IP address to see what happened - all funds were transferred to the same address you've posted within seconds of the account being funded - I was amazed at how quickly the vulnerability was found, but not surprised that it was taken advantage of!

Smarx's comments indicate the fix to lock access down to your local machine: --rpcaddr 127.0.0.1 and removing the --rpccorsdomain "*" tag will keep things locked down nicely.

If you wanted to broaden your access point to enable web3 queries (such as hosting a DApp frontend on a server) and assuming you want to keep a local node(s) running and not use a service like infura.io there are a few possible workarounds:

  1. use Nginx (or similar) as a reverse proxy to keep that access point open but limit it to authorised parties only. This isn't wildly different from the infura.io approach and the security will be as good as you make it, depending on the authentication methods applied. Set up Nginx to forward requests to your geth RPC port, and configure geth to only accept local requests with --rpcaddr 127.0.0.1
  2. web3.js 1.0 allows you to sign transactions remotely so you can keep a node online with no accounts and just use it to propagate those signed transactions directly, with no external access to your accounts possible via the HTTP-RPC interface. This doesn't stop anyone from using your node to read the state and potentially hit it with a DDOS attack
  3. (very risky, far less secure and not something I'd recommend) - keep your funded node accounts locked and enable the personal tag in your RPC configuration, then send web3.personal.unlockAccount(eth.accounts[0], "<password>") and web3.personal.lockAccount(eth.accounts[0]) instructions immediately before and after any transaction lines in your code. Whilst preventing your funds from easily being taken from an unlocked account, enabling the personal tag brings its own risks as you're leaving a door open to a number of different attacks here
Improve this answer
5
  • you said "Whilst preventing your funds from easily being taken from an unlocked account, enabling the personal tag brings its own risks as you're leaving a door open to a number of different attacks here". can you provide information about what are those different attacks? Unlocking and locking are what mist does, no? Also by default geth uses -rpcaddr 127.0.0.1 isnt this enough to be sure that all the request are local? I am curious
    – Jaime
    Apr 7, 2018 at 11:28
  • With personal enabled on a publicly-available IP address you're leaving a door open to brute-force attacks on your account passwords as a malicious party has free reign to keep trying to unlock your account for as long as they like. They could also create any number of new accounts on your node and spam the network with signed zero-value transactions from those accounts among other possibilities. I'm not 100% clear on how Mist works with account unlocking - I think it may sign transactions locally and then only send the signed transaction to the node but I could be wrong
    – TC8
    Apr 7, 2018 at 12:01
  • Mostly correct, except if you specify --rpccorsdomain "*", in which case any website you visit can (in javascript) perform a JSON request to localhost on the RPC port and initiate transactions etc... by specifying a wildcard CORS domain in the response you are telling the browser this is fine and that you approve of such actions.
    – norganna
    Apr 8, 2018 at 0:57
  • I did some trial of my own. I specific --rpcaddr 0.0.0.0 and --rpccorsdomain "<a specific IP address>". My ETH were still stolen. From this, I gathered that the ETH thief script was not written to steal via a cross site script. Is this a correct deduction?
    – Jackson Ng
    Apr 8, 2018 at 13:41
  • If your node is down or your rpc cors domain filter is up and running then the hacker theoretically would not be able to take any money out... however maybe he was smart enough to leave a script running on your node or something.
    – Andy B.
    Apr 11, 2018 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.