Recently, the Slow Mist Security Team observed an attack of automated currency theft, in which the attacker exploited a flaw in the Ethereum Node Geth / Parity RPC API to maliciously invoke the eth _ send Transfer to steal tokens for up to two years. The value of the stolen and untransferred etheric currency alone was as high as $20 million, and there were 164 tokens, the total value of which was difficult to estimate (see below).
The Slow Mist Security Team synthesizes victim intelligence, Reddit information and honeypot log analysis. Backtracking attacks can be as follows: global scan 8545 port (HTTP JSON RPC API), 8546 port (WebSocket JSON RPC API) and other open Ethereum nodes, send eth _ getBlock ByNumber, eth _ accounts _ transfer the balance of the balance of the wallet to the attacker.
When it happens that a node user performs unlockaccount on his wallet, the duration is not required to enter the password again for the transaction signature, when the attacker's eth_sendtransaction call is executed correctly and the balance is entered into the attacker's wallet.
Note: Unlockaccount function describes the function will use the password to extract the private key from the local keystore and stored in memory, the function of the third parameter duration indicates the private key in memory after decryption time, default is 300 seconds; If set to 0, the memory is persisted until geth/parity exits. See：
https://github.com/ethereum/go-ethereum/wiki/Management-APIs#personal_unlockaccount
Attack Timeline We have a detailed analysis of the attacker's wallet address on Etherscan to get the following main attack timeline: 2016/02/14 03:59:14 pm for the first time in (), this day is Valentine's Day 2016/02/16 06:33:30 PM the second time in , a lapse of 2 days, the first line of guessing automatic attack 2016/05/19 07:46:33 pm First Out (transfers), at this time a total of 51 2016/07/20 06:35:57 PM the second out, at this time a total of 57 . 2017/05/11 06:34:35 PM shapeshift (well-known Exchange) in 7 pens, spanning 71 days 2017/06/10 02:39:53 AM out of the last, at this time altogether in about 207 2017/06/21 07:46:49
AM F2pool (well-known ore pool) in 36 pens, spanning 4 hours the tracking of this timeline can assist in analyzing the attacker's behavioral traces.
Impact situation through the slow fog security team's unique Mo-TSE (Mooz) system of around 4.2 billion IPv4 space for scanning detection, found exposed to the public network and open RPC API of the Ethernet square node has more than 10,000.These nodes have a high risk of being attacked by direct currency theft.
Defense recommendations change the default RPC API port, configuration methods such as:--rpcport 8377 or--wsport 8378 change RPC API listener address for intranet, configuration method such as:--rpcaddr 192.168.0.100 or--wsaddr
192.168.0.100 configuration iptables restricts access to RPC API ports, for example: Allow only 192.168.0.101 access to port 8545:iptables-A INPUT-s 192.168.0.101-p TCP-dport 8545-j ACCEPT iptables-A INPUT-p TCP-dport 8545-j DROP account information (keystore) Do not store on the node (because the account is not on the node, so there will not be any transfer of access keys)
Private key physical isolation (such as cold wallet, manual transcription) or high intensity encrypted storage and secure key security.
Further thinking through the tracking of this incident and the complete reappearance of the attacking tactics, we are increasingly aware that cyberspace follows the law of dark forests, which is referenced from" the three bodies ”: "The Universe is a dark forest, Every civilization is a hunter with a gun, prowling like a ghost in the forest, gently through the branches in the way, trying not to let the footsteps of a little voice, even breathing must be cautious, he must be careful, because the forest everywhere with him as a sneak hunter, if he found other life, can do only one thing, to kill the fire. ”
We carefully rehashed all the details of this two-year and now active attack, and if we were the attackers, we could easily take down tens, if not millions, of digital assets worldwide with a single scripted project.
We need to specifically mention the attacker's tactics, I do not know if you have not noticed that the first step of the attack is to call the eth _ getBlockByNumber to get the block height? The details of this call is: eth _ getBlockByNumber ("0x00", false), if the block height is not the latest, then the call will not be able to perform the last step of the attack, the balance is not necessary to complete a violent design of the attack.
Is this better?
We need to specifically mention the attacker's modus operandi, do not know if you have noticed, the first step of the attack why call the Eth_getblockbynumber to get the block height? The details of this call are: Eth_getblockbynumber ("0x00", false), if the block height is not the latest, then the call will be an error, the follow-up will not be necessary to carry out the wallet address, balance, such as query operations, because the balance is not accurate, And the last step of the transfer operation will not be completed. The design of this attack logic is a very violent aesthetic design for this attack scenario.
From the "attack timeline" mentioned above, we can see that the attackers were quite unusual. This lurking attack took place before the first well-known hacking event in Ethereum history, The DAO (2016 / 06 / 17), when Ethereum technology was officially recognized by the market. It is clear that the attackers were very early Ethereum technology researchers, and were well versed in optimizing the hacking process.
Further analysis of the RPC API-related module functionality revealed some potential security risks, such as: if the RPC API enabled the personal module, the account password can be blasted by the personal _ unlockAccount method, and if the blasting was successful, the account password can be unlocked + transferred at once. If the RPC API enabled the miner module, the address can be changed by using the Eminer _ wallet method.
In the full network probing of our MOOZ system, we find that the RPC API modules opened by these exposed Ethereum nodes are not the same. This provides a differential condition for more complex attacks. From a defensive analysis point of view, we also find that the logging mechanism of Geth, etc., is not perfect for recording the source IP(configuration-debug, forensics) of RPC API requests.
Although the robustness of the Ethereum has been tested, safety is the whole.Through this event we can see some safety flaws in the Ethereum ecology, some of which may be considered as a mechanism requiring user attention, but the threshold for safety for users is too high. High threshold security must be more likely to breed such large attacks. Finally, we hope that this article will bring more safety to this ecological disclosure.