Blockchain Security Science: How Counterfeit Attacks Steal Your Digital Assets

As more and more people participate in the blockchain industry, the new vitality of the industry, as well as the lack of relevant knowledge and lack of security awareness, gives attackers more opportunities.

In the face of frequent security incidents, Slow Fog introduced the blockchain security entry notes series to introduce the blockchain security related terms to let the novices adapt to the block network crisis security world!

Short Address Attack Short Address Attack

Short Address Attack is an attack form for ERC20 smart contracts on Ethereum, using the auto-completion mechanism for input bytecode in EVM.

In general, for the call to the transfer function in the ERC20 contract, the number of bytes of the input byte is 136 bytes. When the transfer function in ERC20 is called for ERC20 Token transfer, if the attacker provides one or more zeros after the address, the attacker can save the zero after the address and provide a missing address.

When transferring the address, for example, the A Token of the transfer 100, and then the address entered is the missing address provided by the attacker. At this time, the encoded input data is 134 bytes, which is 2 words less than the normal data. Section, in this case, the EVM will make up 136 bytes for the missing byte bits at the end of the encoded data, so that the 0 that was originally missing in the address segment is filled by the 0 of the data segment, and When the address segment is filled with 0, the data segment will be 0 less, and the missing 0 of the data segment is automatically filled by the EVM. This is like the data segment is moved to the address segment to fill the missing byte segment of the address segment, and then the byte segment missing from the data segment is EVM is padded with 0.

In this case, the transfer amount will change from 100 to 100 * 16 to the nth power, and n is the number of 0s whose addresses are missing. In this way, an attacker can attack an exchange or wallet and steal assets from the exchange and wallet.

The Slow Mist Security Team recommends that exchanges and wallets perform strict checks on transfer addresses when handling transfers to prevent short address attacks. For details, please refer to: Forgotten Atlantis: Ethereum Short Address Attack

Counterfeit currency attack Fake Token Attack

Fake Token Attack is a token created by using the universal creation template when creating an official token. The identification of each token is only identified by a specific tag. For example, the EOS official token is identified as "eosio." Token "contract, the identification mark of TRC10 of the wave field is tokenid, and the ERC20 of Ethereum uses the contract address as the identification mark.

Then there will be a problem. If the payee does not strictly check the Token-specific tags when collecting the Tokens, the attack will occur. Take EOS as an example, because the EOS official Token uses a contract. Issue a Token named EOS, and mark the EOS itself as the "eosio.token" distribution account. If the logo is not verified when accepting the transfer, the attacker can use another account to issue an EOS. Token, recharge the counter money on the exchange or wallet in exchange for real tokens.

On April 11, 2019, the wave field Dapp TronBank stole about 170 million BTTs (worth about 850,000 yuan) within 1 hour. Monitoring showed that the hacker created a counterfeit currency called BTTx to initiate an "invest" function to the contract, and the contract did not determine whether the sender's token id was consistent with the BTT real currency id 1002000. Therefore, hackers get the return on investment and recommended rewards of the real money BTT, which quickly shorts the pool of funds.

In this regard, when dealing with transfers, exchanges and wallets must strictly check various tokens of various tokens to prevent counterfeit currency attacks.

Integer Overflow Attack Integer Overflow Attack

The storage of data is an important part of the blockchain. However, each data type itself has a boundary. For example, a variable of type uint8 in Ethereum can only store data of 0 to 255 size. If it exceeds the limit, it will not be saved.

So what if you want to put a number that exceeds the size of the data type? For example, if 256 is stored in the data type of uint8, the data will be displayed as 1, instead of other values, and no error will be reported, because uint8 itself can store an 8-bit binary number, the maximum value is 11111111, if this time is added 1 This binary number becomes 100000001, and because of the data boundary, only the last 8 bits, that is, 00000001, can be obtained, and the size of the number becomes 1. This is called overflow.

There is a subordinate, underflow means a uint8 data with a value of 0. If you decrement it by 1 at this time, the result will become the maximum value that the data type can store plus 1 minus the subtracted number. In this case it is 255, which is the maximum value that the data type can store.

Then, if the above two situations occur in the smart contract, the malicious user manipulates his own account to send more tokens than the balance of his own account through the underflow operation. If the balance is not checked in the contract, the balance of the malicious user The underflow will become an oversized value. At this time, if the attacker sells these tokens in large quantities, it can instantly destroy the value system of the entire token.

The Slow Fog Security team recommends that all smart contract developers rigorously verify data boundaries to prevent plastic overflow attacks when operating on data in smart contracts. For details, please refer to: BEC Smart Contract Unlimited Currency Vulnerability Analysis and Early Warning .

Conditional competition attack

There are many ways to attack a Race Condition attack, but the essence of the core is nothing more than a competition for the state modification of a certain condition. The reentry vulnerability introduced in the previous period is also a kind of conditional competition, which is aimed at the condition of user balance. To compete, as long as the user's balance is not zero, the user can always withdraw the money from the smart contract. An example of conditional competition introduced this time is the recent denial of service vulnerability in the famous Edgeware lockout contract. For details, refer to the Denial of Service Vulnerability for Edgeware Locks .

The essence of this vulnerability problem is to compete for this condition of the balance of the newly created lock contract. The attacker can monitor the lock request on all chains, calculate the address of the lock contract in advance, and then transfer the contract address, causing the lock to fail.

Before the official fix, to prevent this kind of attack, you can only use your higher handling fee than the attacker to pack your own lock transactions, thus competing with the attacker to avoid attacks. Finally, the official repair program does not impose a mandatory equality check on the balance of the lock contract, but adopts a form of greater than or equal to avoid the attack.

The slow fog security team recommends that developers of smart contracts should fully consider the risk of conditional competition based on actual conditions when they modify certain states in smart contracts to prevent conditional competition attacks.

Series review:

Blockchain Security Getting Started Notes (3) | Slow Mist Science

Blockchain Security Getting Started Notes (4) | Slow Mist Science

Blockchain Security Getting Started Notes (5) | Slow Mist Science

Blockchain Security Getting Started Notes (6) | Slow Mist Science

Blockchain Security Getting Started Notes (7) | Slow Mist Science