CertiK analyzes the incident with Axion Network and the subsequent drop in prices

189
SHARES
1.5k
VIEWS
ADVERTISEMENT

Related articles


On November 2nd, the Axion Network launched its new token called AXN. The project touted the asset as a new investment vehicle, claiming it was the most profitable blockchain of its kind to date. During preliminary preparation for AXN’s Airdrop, five separate teams allegedly examined the token’s code. Industry insiders like CertiK and Hacken were among those who conducted the audits.

However, a few hours after the log’s Freeclaim event, it became clear that something had gone wrong. An unauthorized actor unexpectedly coined AXN 79 billion and dumped it on the market. The price slumped more than 99% and earned the attackers a cool 1,300 ETH – valued at an estimated $ 500,000 at the time of publication.

In the hours that followed, the team behind the Axion project encouraged participants to stay away from trading or interacting with the asset, stating over the platform’s official Telegram channel:

“Don’t buy AXN now, don’t interact with the dashboard.”

The Axion network Twitter account continued to post updates including:

Despite these assurances, CertiK is stepping forward to provide the community with a clearer explanation of what they believe went wrong and insights into how similar attacks could be prevented in the future. Cointelegraph emailed “Jack Durden” who was described to us as CEO of the Axion Network but did not receive an immediate response. No team members are listed in the project whitepaper or website, and the name “Jack Durden” is given to the invisible narrator from the film Fight Club.

Note that the rest of this article is reproduced word for word as a public service with permission from CertiK to help educate readers of the audit team’s understanding of what happened. Cointelegraph has not reviewed the code and therefore the views listed below are only those of CertiK.

CertiK employees report on the Axion price drop

On November 2, 2020 at around 11:00 a.m. + UTC, a hacker managed to mint around 80 billion AXN tokens using the unstake function of the Axion staking contract.

The hacker then placed the tokens on the AXN Uniswap exchange for ether and repeated this process until the Uniswap exchange was empty and the token price was driven to 0.

We were notified of the incident within minutes of the attack and our security analysts immediately began assessing the situation.

We have concluded that the attack was likely designed from the inside and, at the time the code was deployed, it was injecting malicious code by modifying code from OpenZeppelin dependencies.

The function that was exploited was not part of the audit we conducted as it was added after the Axion code was merged with the OpenZeppelin code by “collapsing” and inserted into the OpenZeppelin code prior to deployment.

planning

The hacker used anonymous funds obtained from tornado.cash the day before the hack, which indicated a temporary attack. Presumably to save money in case the attack fails, 2.1 ethers were put into circulation immediately after receiving the money in tornado.cash.

To complete the attack setup, the hacker bought around 700,000 HEX2T tokens from the Uniswap exchange. However, these resources were ultimately not part of the attack and acted as a smoke screen in relation to the evolution of the attack.

To install

The hacker started his attack by creating an “empty” deployment for the Axion network deployment contract by calling the deployment function with a deployment of 0 and a deployment duration of 1 day at around 09:00 + UTC. This created a session entry for the attacker with a value of 0 and a clearance value of 0 with session ID 6.

The attacker then approved an unlimited amount of AXN for the Uniswap exchange before the attack was successful. As a result, they approved Axion’s NativeSwap contract for the amount of funds they wanted to convert into AXN tokens.

You called up the deposit function of the NativeSwap contract at around 10:00 a.m. + UTC. However, the hacker never called the reverse function of the contract to claim his exchanged AXN, as can be seen in the swapTokenBalanceOf function of the NativeSwap contract. After that, they made another failed deposit function call before launching the attack.

execution

These transactions were just a smoke screen for the actual execution of the unstake attack. Since the transactions performed by the attacker did not change the sessionDataOf mapping, we concluded that it was a multi-address attack.

We examined the source code of the contracts in the GitHub repository that was shared with us to identify a bug that would result in the sessionDataOf mapping being compromised.

We could not find any assignments to him or his members outside of the investment functions, which led us to question whether the provision of the contracts was carried out properly.

Attack vector

After analyzing the source code of the staking contract provided, we identified a code injection in the AccessControl OpenZeppelin library between L665-L671 of the staking contract source code provided. The associated checkRole function is not part of the OpenZeppelin v3.0.1 implementation, which was listed as a dependency in the project’s GitHub repository.

The following assembly block exists within the checkRole function:

This special function enables a specific address to do any writing in the contract based on the input variables, which it supplements via low-level calls. Commented the assembly block would look like this:

this function was injected during use Since it is not present in the OpenZeppelin AccessControl implementation, the members of the Axion network who were involved in providing the token acted maliciously.

Conclusion

The attack used code that was intentionally inserted before the log was deployed. This incident is not related to the audits carried out by CertiK and the party responsible for the attack was someone who appeared to be involved in delivering the Axion Network contracts.

As an additional security level, test reports should be standardized in order to include provided intelligent contract addresses whose source code is identical to the checked one.

The security oracle acts as an on-chain relayer for security information and performs security reviews, including reviewing the deployed smart contracts to match against the reviewed versions.