Home Ankr aBNBc Token Exploit
Post
Cancel

Ankr aBNBc Token Exploit


Overview

On 1st December 2022 Ankr’s BNB liquid staking token (aBNBc) was compromised and resulted in the hacker minting 60 trillion aBNBc which when compared to the liquidity resulted in an actul value of $5 million dollars.

Addresses/Transactions:

Attacker: 0xf3a465c9fa6663ff50794c698f600faa4b05c777

Malicious Contract: 0xb2cb9e5311610c48aeed89e44549542362692808257f706accdc75f051ac7303

Schnoodle Proxy: 0xcbc5ff4a6c9a66274f9bde424777c3dc862ab576e282fbea3c9c2609ca3e282b

Transaction: 0xe367d05e7ff37eb6d0b7d763495f218740c979348d7a3b6d8e72d3b947c86e33

(Compromised) Ankr deployer address: 0x2ffc59d32a524611bb891cab759112a51f9e33c0


The Attack

The attack in itself was not complex involving some clever abuse of the Ankr tokens via a exploit rather it was classed as a simple social engeneering attack with the malicious actor managing to aquire the secret private key specifically the deployer private key enabling the attacker to essetially control the upgrade procedure and inject a custom contract with the ability to mint infinite tokens with zzero validation of the caller addres opening this fucntion to the general public resulting in random addresses minting tokens out of thin air.

With the recent updates released by Ankr it has been disclosed it wasent even a typical social eng. attack rather it seems like a disgruntuled ex employee with access and knowledge of the upgrading process was able to compromise the system and steal the private key.

The important thing to note here is this whole incident could have been avoided if the developers had taken heed of the advice given by the peckshield team which pointed out the consequences of having a single key controlling large amounts of authorisation making it a single point of faliure, but the said issue was marked as confirmed by Ankr which was clearly far from the truth.

this is the report by peckshield

Coming to why the attacker did what he did? It would be more surprising if someone had not done it!!! This attack is perfect example of complete neglegence on the part of developers, management, the administration and company policies in general.

The attacker being an ex employee who is we could say with sufficient conviction not a big fan of the company saw the perfect opportunity of his positoin and inside knowledge of the company procedures and supposedly restricted information which should have been in the first place not known to someone who has been removed from the credit list of the comapny, with the result in the attacker completely compromising the system.

Presented with such a scenerio it is hard to imagine some one not taking advantage of the situation. Anyone with knowledge of the codebase would have been aware of the fact that the protocol used single private key for validation rather than a multisig one. This issue was highlighted in the audit reports too which also would have been publicly accessible. Thus when the attacker got this information and odds are that he also knew the company had not resolved the issue (with the attackre being an insider essentially) all this was enough catalyst to set the attacker in motion.


Coming to how such things can be prevented we analyse risk management from two aspects…….

risk management platform for protocols

A risk management platform for such protocols would have to include preventive measures to tackle attacks and full comprmise of the system.

Firstly It should keep track of al the audit issues highlighted in the various audits the protocol has undergone.

These issues have to be verified that they have been addresesd to and have been rectified or otherwise been taken note of and not simply been marked as confirmed etc.

This would be a publicly acessebile framework where the protocol users can clearly see the issues along with the proof of their confirmation in the case such proof is required to verify said claims. Thus ensuring companies dont take audits lightly.

Another preventive method would be to avoid single points of faliure, the whole point of making an application on block chain is to make use of its dcentralised framework if after that the the entire control rests with a few central figures it is undermining the entire idea of a dex and a huge security flaw. Thus ensuring te use of multisig wallets for verifying important admin fucntion/ sensetive data.

Ideally the majority of control should lie with protocol investers with ability to perform governance rather then the developers themselves.

Another important prevention technique is strict access control of important and critical information and peridocally reviewing security policies and building robust access control software that invovles minimum manual oversight with good reliability and usability.

Coming to metrics…

Each transaction should be monitored via bots and limit must be set for the amount of money that can be deposited or withdrawn in a single transaction from the pool, this makes more sense when a particular exchange has been in use for a long time and has significant liquidity and users where if an atacker was to compromise the security they should not be able to drain the entirety of the funds in a single transaction.

At the very least if no limit is set a system should be set in place to notify/warn the important / necessary people in the organization on the account a huge transaction has taken place involving the dex. this would enable the leadership to become aware of potential hacks in the system.

Keeping analytics regardingb the user base is another important metric. This includes transaction information such as other defi platforms from where incoming transaction orginate or the destination of outgoing transactions. This would allow to monitor those platforms for potetial hacks which could have a residual effect on your platform.


risk management platform for investors

Information describing risks associated with Trading

The basic step towards risk management is to have a solid trading plan and the platform should have resources/information that help traders understand the risk of impulsive trading.


limiting risk per trade

The platform should have ways to track and identify new users and their level of experience to be able to impose certain trade restrictions on them initially so that they dont end up risking too much and or getting scammed.


Impermanant loss

The platform should analyse and evaluate the ip loss for each open position and warn the user if it exceeds a certain pre defined limit.


Limit use of exessive leverage

As you are spending borrowed money not your own money it is easy to get carried away and allthough rewards wouls prfit a lot the risk of loosing out is large.


Measuring unique addresses growth rate

On any platform a positive growth in the number of unique addresees signifies the reach and popularity as well as the trust people have on a certain project, this helps in bringing prospective new users and increases trust in the system.


Transaction monitoring

Alerting users on influx of a lare amount of liquidity or rapid withdrawals which can be indictive of some hack or malicious actions.


Keeping track of the M-cap (price-scale ratio)

measures what a company is worth on the open market and the market’s perception of its future prospects. Thus, market capitalization is a simple, yet effective measure of how valuable a particular company or an industry is.


Keeping track of inflation rate

it is important to look at the token’s increase in supply and inflation rate. Tokens with a tendency to demonstrate high inflation rates in the past may be best to avoid.


This post is licensed under CC BY 4.0 by the author.