secondary title
1. Brief description of the event
On June 18, 2020 (the time mentioned in this article is UTC time), the smart contract Bancor Network on Ethereum was exposed to have serious loopholes. The vulnerability was first discovered by the Bancor Network team and the white hat, and immediately transferred funds that were at risk of being stolen, involving more than 500,000 US dollars.
0x923cab01e6a4639664aa64b76396eec0ea7d3a5f
0x8dfeb86c7c962577ded19ab2050ac78654fea9f7
0x5f58058c0ec971492166763c8c22632b583f667f
In this incident, the contract addresses with vulnerabilities mainly include the following three:
At 3:06:48 on June 18, 2020, the Bancor Network team used this vulnerability to transfer user funds that were at risk of being stolen. As of 6:56 on June 18, 2020, the Bancor Network team had transferred a total of approximately $409,656.
0x052ede4c2a04670be329db369c4563283391a3ea
0x1ad1099487b11879e6116ca1ceee486d1efa7b00
Two other public email addresses:
At the same time, this vulnerability was also used to transfer user funds, transferring funds of $131,889 and $2346 respectively.
image description
Figure 1
The Bancor Network team has also responded to this incident,
see details
（https://blog.bancor.network/），
And deployed a new Bancor Network contract at 2020-06-17 21:35:53 UTC time, the contract address is
0x2f9ec37d6ccfff1cab21733bdadede11c823ccb0
secondary title
2. Principle analysis
image description
Figure II
image description
Figure three
image description
Figure four
Figure four
The above is the analysis of the principle of the vulnerability in this incident. The principle of the vulnerability is very simple. It is because the calling authority of the function is set incorrectly, and the function that should only be called by the contract itself is set to be called by anyone. When the Bancor Network has the users authorization limit, anyone can transfer the users funds as an agent of the Bancor Network by calling the safeTransferFrom function.
For this vulnerability, there are two points worthy of our in-depth analysis:
1. Why does the safeTransferFrom function of the Bancor Network contract set the permission to public.
image description
Figure five
Since it is only called in the handleSourceToken function, it is obviously not necessary to set it as a public permission, and according to the business, the main function of Bancor Network is for token exchange, and it does not require the user to actively call safeTransferFrom, so there is no need to set safetransferFrom Set to public permission. So we compared several other functions in the contract, and these functions are all set to public permissions. As shown below:
image description
Therefore, for the first question, we speculate that setting these functions as public permissions may be due to the negligence of contract developers. At present (2020-06-19), the contract newly deployed by the Bancor Network team also verified this speculation. According to the code on the chain, the new contract officially deployed has changed all relevant function permissions (although other functions have nothing to do with this event). The specific code is shown in the figure below:
image description
For the second question, we tracked the addresses where the funds were transferred after the vulnerability broke out, and found that when these addresses authorized the amount of Bancor Network, they often exceeded the number of tokens that needed to be exchanged, and after the exchange was completed, they were not recovered. amount. As shown below:
image description
Figure eight
To sum up, we speculate that the user may have authorized all tokens to the Bancor Network contract at one time for the convenience of using them at any time. It may also be that the front end of Bancor Network sets a default value for the authorized amount. However, there is a huge risk in this behavior. Once a vulnerability breaks out in the smart contract, the funds are easily stolen by attackers. When analyzing the subsequent new Bancor Network contract, it was found that the Bancor Network team and users seemed to be aware of the huge risk of this problem and made corresponding security protections. Figures 9 and 10 below show the user’s authorization for the new contract. Comparing the two online transactions, it is not difficult to see that the time interval between the two authorizations is very short. When the user successfully redeems the tokens, the remaining authorization will be withdrawn.
Figure 9
secondary title
3. Conclusion
3. Conclusion
