CertiK: Has your client been stolen? This article restores the beginning and end of the Axion Network attack incident

特邀专栏作者

2020-11-03 11:23 (UTC+8)

This article is about 2660 words, reading the full article takes about 4 minutes

Vulnerabilities in the Axion Network resulted in the accidental minting of nearly 80 billion AXNs. This incident has nothing to do with the audit completed by CertiK.

AI Summary

Expand

Vulnerabilities in the Axion Network resulted in the accidental minting of nearly 80 billion AXNs. This incident has nothing to do with the audit completed by CertiK.

The price of the Axion Network token, AXN, plummeted 100% just hours after it went live on Nov. 2. This price crash revealed its vulnerabilities, and the following is a complete analysis of the incident by the CertiK security audit team.

At around 7:00 pm Beijing time on November 2, 2020➀, hackers managed to mint about 80 billion AXN tokens by using the unstake function of the Axion Staking contract.

The hacker then exchanged the AXN tokens for Ethereum on the Uniswap exchange, and repeated the process until the Ether for the ETH-AXN trading pair in Uniswap was exhausted, and the price of the AXN token dropped to 0.

Within minutes of the attack, the CertiK security audit team was informed of the attack and immediately launched an investigation.

The CertiK security audit team believes that the attack is most likely caused by an internal operation that injects malicious code into the OpenZeppelin dependencies that the project depends on when deploying the code.

Maliciously exploited smart contract functions are not within the scope of the CertiK audit.

secondary title

premeditated attack

The hackers used the anonymous funds➂ obtained from tornado.cash➁ the day before to launch the attack, indicating that this was a premeditated attack.

It may be to save some funds in case the attack fails. After receiving the funds, the hacker account immediately transferred 2.1 ether coins through tornado.cash.

secondary title

attack preparation

At 4:00 p.m. Beijing time ➄, the hacker first calls the stake function with a quantity of 0 and a continuous mortgage time of 1 day as parameters to create an "empty" mortgage in the mortgage contract of Axion Network.

This creates a Session entry for the hacker with a session ID of 6, a quantity of 0, and a stock price of 0.

Anticipating that the attack would be successful, the hackers have since pre-authorized unlimited AXN to the Uniswap exchange.

They then approved Axion's NativeSwap contract for the amount of funds to be converted into AXN tokens.

The hacker called the deposit function of the NativeSwap contract at about 5:00 pm Beijing time➅, but the hacker did not call the withdraw function of the contract to obtain the AXN it exchanged, which is clearly visible in the swapTokenBalanceOf function of the NativeSwap contract.

secondary title

attack execution

The transactions mentioned above are just smoke bombs for hackers to cover the real unstake attack.

Since the sessionDataOf mapping was not changed by the transaction made by the hacker, it can be concluded that this is a multi-address attack.

In order to find the possible reasons for the impact of sessionDataOf mapping, the CertiK security audit team reviewed the contract source code shared by the project party and CertiK in the GitHub code repository.

secondary title

attack vector

After analyzing the source code of the deployed Staking contract, the CertiK security audit team found a code injection in the deployed source code of the Staking contract ➆ lines 665-671, which occurred in the modified OpenZeppelin library. AccessControl smart contract.

The checkRole function in the link is not part of the implementation of OpenZeppelin v3.0.1, which is listed as a dependency in the project's GitHub code repository.

In the checkRole function, the following assembly modules exist:

This function allows a specific address to write to the contract arbitrarily through the underlying call according to the parameters passed in. An annotated assembly module looks like this:

in conclusion

The code involved in this attack was intentionally added before the contract was deployed.

This incident has nothing to do with the audit completed by CertiK, and the person responsible for this attack should be the relevant personnel involved in the deployment of the Axion Network contract.

Here, CertiK also particularly emphasizes that in order to ensure the validity of the audit report and guarantee the security of the project, the audit report should include the addresses of the deployed smart contracts. The code of the contract pointed to by the address should be the same as the audited source code. Therefore, please do not follow up blindly without doing any background checks just because you see that the project is "audited".

CertiK Security Oracle, as a security detection tool that can interact in real time on the chain, it can effectively ensure and verify that the deployed smart contract matches the audited version.

It can retrieve a set of security scores from the decentralized security operator network, obtain a secure and reliable source code for network evaluation, and everyone can verify the security of the contract by using the oracle machine.

Reference link: