# Bancor smart contracts vulnerability: It’s not over

## The flaw

The security bug was originated in the contract’s function safeTransferFrom (ironically named at hindsight):

The function’s flaw is the unauthenticated call to transferFrom. This is ERC20’s interface function to enable a certain spender (Bancor’s contract in this context) to transfer funds on behalf of the actual owner of the token (i.e. the user interacting with Bancor’s exchange). Because this function is public, anyone can call this function with a destination address to his choice.

## The architectural flaw

This vulnerability in safeTransferFrom could have gone irrelevant, as the success of such a function call is dependent on a preceding transaction where the owner of the tokens approves that the smart contract can transfer a certain amount of tokens on his behalf.
Unfortunately, Bancor Wallet and other external wallets that interact with this contract adopted a common anti-pattern where the requested amount to approve is infinite. This is exactly what we at Zengo have warned about in our recent baDAPProve research:

…in most DApps users actually grant access to ALL of their holdings in that token… attackers can abuse these highly excessive privileges to steal ALL of the DApp’s users holdings (in the approved tokens) without any further user consent.

Bancor has acknowledged this issue in their blog post:

In addition, infinite approval was removed from bancor.network in favor of the exact amount required for conversions.

## It’s not over

As of the time of this writing, 24 hours after the reported time of the vulnerability detection, we’ve found over 160 addresses that are still with a positive allowance to the buggy contracts, many of which of infinite amounts. As was also explained in our post, until users revoke the excessive permissions they have given to the flawed Bancor contract, these addresses are still vulnerable. Meaning, when these addresses receive funds in the allowed tokens, a hacker can still exploit that same vulnerability and steal these assets.

Bancor may monitor these addresses to “self hack” them in the same protective manner as they did before, but it would be a race against attackers trying to do the same to steal users’ funds.

## Conclusions

This case shows that security vulnerabilities which concern to smart contracts seldom remain in the realms of theory.

At ZenGo we do not allow Dapps to have such excessive access to our customers’ funds while still maintaining delightful user experience. We encourage other wallets and Dapps to follow adapt such cautionary steps.