Decentralized exchange vulnerabilities

Last month, losses as a result of hacker attacks on the crypto community increased to $1.019 billion (24.10), surpassing the past few months (excluding the Terra Luna incident)

Looking closer, we can see that the top exploits were conducted on DEX (Decentralized Exchange) platforms, accounting for nearly 15% of total losses in October alone.

With that in mind, let's delve into three cases in the world of DEX exploitation and try to answer these questions:

What are the main causes of DEX vulnerabilities?

How can we avoid this in the future?

Banana swap

On August 28, the $DDC token exchange, Banana Exchange , was attacked. The attacker successfully manipulated the coin price, breaking the internal logic of price calculation, and as a result, exchanged 23 $DDC for 110.105 $BUSD.

The vulnerability was simple enough, but the impact had huge profit potential:

The attack started with a transaction of 26 $DDC in the attacker's account

A search was then initiated for the victim's wallet to find a wallet that contained a large amount of tokens.

[Exploitation] When a suitable account was found, the attacker called handleDeductFeewho performed a deduction of almost all chips from the victim's balance

To finalize the price manipulation, the function syncwas called to update the value/price of $DDC

As a result, the balance of $DDC in the pool was reduced to 0.0003 $DDCs, after the value/price was updated, the price of $USD corresponding to $DDC increased significantly, and a large amount of $USD can be exchanged through a small amount of $DDC. The hacker used 23 $DDC to exchange it for 104,600 USD.

So how was it possible for an attacker to manipulate the victim's account balance? How was the handleDeductFeefunction running?

Let's take a look at the code:

function handleDeductFee (ActionType actionType, uint256 feeAmount, address from, address user) external override {

distributeFee(actionType, feeAmount, from, user);

}

// deduct the config fee and transfer to handle fee address which config.

// parameter from

function distributeFee (ActionType actionType, uint feeAmount, address from, address user) internal {

_balances [from] = _balances[from].sub(feeAmount);

...

}

Here we have an outer function with controllable arguments that calls an inner function passing the same arguments as parameters which performs a deduction using those arguments immediately.

The attacker passed the victim's address as the fromparameter and the feeAmountwas slightly less than the result of balanceOfthis address.

That's it! Not a single validation on the received data. No complex theory behind it.

Cyber ​​Security 101: Never trust user-controlled data.

More information can be found on Beosin Alert's Twitter post here .

Next, we will review a more complex protocol. But as we have already witnessed, losing one line of code can break the whole system.

Public transport exchange

Transit Exchange is a multi-chain DEX aggregator platform running on Ethereum and Binance chains. On October 1, the platform was the victim of an attack that removed nearly $29 million in assets from the wallets of protocol users.

Swap with Transit Swap involves going through some contracts that route and link different swappers and enforce permission management. Each of the contracts calls the other passing its parameters as arguments to the next, each of them uses the parameters to process some logic and perform actions.

A simplified version of the data flow looks something like this:

As I mentioned earlier, each of the contracts calls the next passing the arguments as parameters, so why is this so critical?

“The main reason for this attack is that the Transit Swap protocol does not strictly validate the data passed by the user during the token exchange, which results in an arbitrary external call.” – Analysis by SlowMist

None of the contracts properly validated the data used to effect the transaction. As a result, the attacker successfully manipulated the entire chain, passing in specifically crafted data for each step of the transaction.

This is yet another case of data validation with a large-scale vulnerability. Let's fast forward to one of the biggest losses of this year:

Maiar Exchange – Elrond Network

The third most profitable DEX attack of all time was carried out on Maiar DES . Hackers exploited a recently deployed vulnerable function on the mainnet. They successfully emptied the protocol's reserves, stealing $113 million in assets.

The exploit started with a function executeOnDestByCallerthat allowed Contract A to perform actions on Contract C through proxy B. Contract A will call a function within B that allows B to perform actions on C on behalf of Contract A.

To illustrate this, we'll illustrate Contracts A, B, and C. Contract A calls foothat are inside B. foocalls executeOnDestByCallerthat allow B to perform barContract C's function as A's imposter.

In practice, Contract B can perform all functions on behalf of A if A makes the first call to B. This idea already seems a little suspect.

To create an exploit using this function, you have to figure out how to get the victim to call the contract, and then you can do whatever you want with that contract using the external functions it provides, such as transferFrom.

Luckily for hackers, Elrond has a concept called Callbacks . By using these callbacks one can pass a malicious function as a callback to the victim who will have no option but to execute the callback and the rest is history.

If you'd like to dive deeper, see Elrond's Official Report and The Collapse of Arda's Assault .

So there was no vulnerability in the code, but a logical flaw. The public encountered several security issues with this feature after deployment, but the patch and fix could only be delivered a week later, thereby exposing all contracts to a potential vulnerability for an entire week.

Answering the questions

Knowing what we know now, we can address these questions.

The incidents discussed share a common cause: smart contract vulnerability. We're all familiar with the terms vulnerabilities and exploits in other scenarios, so what makes it different in the smart contract scenario?

Open Source – As we all know, the 'D' in DEX stands for Decentralized, which means the product is driven by the users and makes the code accessible to the world. This makes vulnerabilities easier to find.

Difficult to update – The cost of finding and updating a vulnerability is much higher than with an off-chain application. As contracts are loaded up the chain, fixing a vulnerability means loading a new copy of the contract and redirecting all addresses from the old one to the new one if no proxy contracts are in use.

So we don't get a second chance. We must ensure that the contract is bug free and secure before uploading it to the network.

Pre-upload security audits and constant monitoring of security threats are crucial measures in the world of decentralized applications.

Conclusion

These examples only cover a portion of the vulnerabilities and issues found in smart contracts. As the development of Web 3 progresses, more complex algorithms will be introduced into the world, algorithms that can play a major role in the next exploit and cause loss of funds.

Analyzing previous exploits and mitigating, auditing and verifying the code can avoid financial downfalls and make a big difference to the future of decentralized applications.

At Cyphershield Tech, we check every line of code while having a deep understanding of the architecture. In addition to common attacks and best practices, it's also important to understand your own business logic and the idea behind each feature.

An auditor's mission is to understand the code, its purpose, and what bad actors would do to take advantage of the contract's logic. The auditor uses automated tools and manual testing to perform a quality smart contract audit.