In response to blockchain security issues, the Beosin (Chengdu Lianan) team will analyze and serialize the security vulnerabilities of smart contracts every week, hoping to help programmers write more secure and firm contracts to prevent problems before they happen.
Recap
Recap
In the last book, EOS games have been repeatedly attacked, and random number loopholes have been banned repeatedly.
Topics of this issue
Topics of this issue
DApp counterfeit currency is misleading, transfer function detection omissions are sloppy
Speaking of domestic movies that are more popular this year, Chow Yun-fats Wu Shuang must have a place. The manufacturing technology of counterfeit US dollar bills in the movie is amazing, and it also deduces a cruel banknote-level deception.
secondary title
Paving the way for basic knowledge
Architecture of EOS Smart Contract
The EOS smart contract is composed of a series of actions, each action represents a contract clause to implement the specific rules in the clause. Executing an EOS smart contract is divided into three parts: making, deploying, and invoking.
Among them, in the step of deploying the smart contract, each EOS smart contract must implement an apply() function, which is used to map the action request to a specific processing function. The specific implementation details are encapsulated in the EOSIO_ABI macro. This design allows developers to only focus on the development of business logic, without having to pay attention to the underlying technology, which simplifies development. Example of apply function:
Fake EOS transfer attack
Historical events:
The well-known EOSBet lost about 42,000 EOS on September 12, which started an upsurge of hackers using fake EOS tokens to attack, followed by eoswindice and the decentralized exchange newdex, which were all reduced to hackers.
Attack analysis:
The common token on the EOS chain is EOS token, which is generated by the eosio.token contract deployed by EOSIO, but the eosio.token code is open source, any eos account can deploy the eosio.token contract by itself, and issue the abbreviated name It is the token of EOS, as shown in the figure, we can see a large number of worthless fake EOS:
How to identify the authenticity of EOS? Money detector? Of course not, the full name of the token will be displayed on the eosflare browser. There is a difference between the full name of the real EOS and the fake EOS:
It can be seen from the picture that one is EOS and there is no other explanation behind it, and the other is the fake EOS (refundwallet) of refundwallet.
In the browser, we can see the transaction details to judge whether the EOS token used for the transaction is true or false, so what if it is placed in the smart contract?
For example, the case contract:
void transfer(const account_name& from,
const account_name& to,
const asset& quantity,
const string& memo)`
This is a function used to receive a callback. When a fake EOS is passed, the function has no way to distinguish the authenticity. If the EOS is not detected in advance in the apply, it will cause the contract to receive the fake EOS and execute the normal business logic. If the malicious account deploys the contract to issue an EOS token, it can realize empty-handed white wolf and exchange fake banknotes for real money.
Bug fixes:
In order to verify that the issuer of EOS is eosio, it is necessary to add code == eosio.token in apply() for judgment.
secondary title
Variant 1: Direct call attack on the transfer function
Vulnerability analysis:
After adding relevant judgments according to the above-mentioned vulnerability repair methods, many project parties let out a sigh of relief, but the vulnerability code that caused the EOSBet incident was not so easily fixed. Because, when using the above-mentioned apply to detect the code call, there is another bypass situation, if the detection condition is only:
if( code == self || code==N(eosio.token) ||action == N(onerror))
Then this detection condition only handles two detections: the call of the function’s own action and the call of the action from eosio.token. The caller of the transfer action without verification must be eosio.token or its own contract.
This will lead to the transfer under the contract account can be called directly.
For example, user A originally called eosio.token to transfer 1 EOS to user B, and then eosio.token sent a trasfer receipt to call the transfer function of contract B to execute the business logic. Now, the transfer function of contract B can be directly called, and from is specified in it. Correct parameters such as to, value, etc., directly execute the business logic of the B contract without transferring money. Therefore, the attacker who attacked EOSBet completely bypassed the eosio.token->transfer function, directly called eosbetdice11->transfer with the correct parameters, and executed the business logic of the contract without transferring EOS to the contract.
Bug fixes:
The defense method for this type of attack is to detect the action and code at the same time, that is, when
secondary title
if (code == N(eosio.token) && action == N(transfer))
{ }
Variant 2 EOS fake receipt attack
Historical events:
After the incident on September 14, EOSBet also issued an official statement mentioning the importance they attach to code security.
But just one month later, on October 15, EOSBet was hacked again, losing nearly 140,000 EOS.
Vulnerability analysis:
The reason for the vulnerability is that there is a lack of to judgment in the transfer function of the smart contract processing logic: if the to judgment is missing, the contract cannot judge whether it is itself that received the transfer, and may continue to execute the logic function without receiving the transfer. Suppose an attacker Have two accounts AB, c is the game contract account, the attacker can call eosio.token through account A to transfer EOS to account B, then deploy the contract in account A or B, and call require_recipient(N(XXXXXX) again in the callback transfer ); Send the transfer notification to the game contract C account, so that the verification of code==N(eosio.token)action==transfer can be bypassed and the corresponding business logic can be executed.
Bug fixes:
void transfer(const account_name& from,
const account_name& to,
const asset& quantity,
const string& memo) {
secondary title
return;
}
Code security is black and white
After a series of security incidents and code repairs, the game official under attack finally solved a seemingly unbelievable loophole. It can be seen that blockchain security is an extremely rigorous and worthy technology, and the bumps and bumps in the past two years have made it a very heavy topic. There is a line in Wu Shuang, People who only see black and white will always be losers. This sentence is not applicable in the blockchain field. If you dont believe me, watch the ending of the protagonist of the movie.
Quote:
Quote:
[3]: Shock! EOSBet has been attacked again. The loss was as high as 5 million. Is this the attack method?；
