Smart Contract Security Newsletter #41

Shayan Eskandari

Published in

ConsenSys Diligence

4 min readJul 4, 2020

[This newsletter is also translated to Korean by Richard Kim.]

(This newsletter was sent out on July 2nd, Sign up to receive them on the first day)

This is the last week for Gitcoin CLR matching, Please check out two of our Public Goods Projects:

Do you consider yourself a smart contract hacker? Or do you know someone that might be? Good news, ConsenSys Diligence is hiring.

Distilled News

Balancer Pool issue

We previously covered issues caused by flash loans (bZx hack and security implications of flash loans), now combined with non-standard ERC20 deflationary tokens, the plot has thickened. Last week, two different attacks on two Balancer pools resulted in $500K profit for the attackers. It seems that the issue was previously reported by Hex Capital to Balancer’s bug bounty in May 2020.

Balancer called this attack vector an “expected behaviour”, as the Pool owners must verify the legitimacy and compatibility of the bounded tokens.

The main issue is that the smart contracts interacting with ERC20 tokens, expect the tokens to behave as specified in the EIP, however, that is not the case with deflationary tokens, which subtract a fee on each transfer, such as STA and STONK. This is similar to yield farming tokens which airdrop interest to token holders, such as COMP.

Balancer will begin adding transfer fee tokens to the UI blacklist similarly to what they have done for no bool transfer tokens. They also decided to take further action on blocking these tokens and reimburse everyone who lost funds in this attack.

Bancor Network hack

This was a pretty unfortunate and straightforward attack. In short, anyone could force Bancor’s exchange to call `transferFrom()` on any ERC20 token, with any from address, and to any address.

This means that if a user had approved the exchange with an infinite allowance of some token, which is fairly common practice when using a smart-contract based exchange, they could be a victim of this attack.

There’s a good writeup from 1inchExchange here. Our fascination with Front-running was certainly piqued by this excerpt:

Apparently, the Bancor Team or some white hackers discovered this issue before anyone could begin draining user wallets and made attempts to rescue user funds by withdrawing them from user wallets.
Subsequently, two automatic front-runners joined in, helping the Bancor Team to withdraw funds from user wallets. We discovered contact information of all the front-runners and we believe they potentially agree to return the stolen funds since their automatic software is not able to distinguish an arbitrage opportunity from hacking.

Attack Nets — Ethereum Notes

For the Attack Nets, we propose that client teams and EF run the majority of nodes/validators to provide a stable testground for attackers. This is in contrast to the multi-client testnet which has the goal of being controlled largely by the community.

The primary goal is to incentivize/observe a range of attacks in a production setting (clients and consensus), find and patch security holes prior to mainnet launch, and provide a clean and stable environment for those that actually want to attack.

Research Papers

ETHBMC: A Bounded Model Checker for Smart Contracts
Remote Side-Channel Attacks on Anonymous Transactions
Stablecoins 2.0: Economic Foundations and Risk-based Models
Counting Down Thunder: Timing Attacks on Privacy in Payment Channel Networks
Minerva: The curse of ECDSA nonces — Systematic analysis of lattice attacks on noisy leakage of bit-length of ECDSA nonces
Ethainter: A Smart Contract Security Analyzer for Composite Vulnerabilities [Video]