Evil Contract exploit

Basics

• An evil contract exploit lets a contract think certain aspects have changed, which open the door for exploits. For instance with users who give protocols “infinite approval” for spending its tokens.

Examples

• From Rekt (1-3-2021):

"In what is known as an “evil contract” exploit, the attacker made the Furucombo proxy contract think that Aave V2 had a new implementation.

The new implementation was, of course, malicious, and had the ability to transfer all approved tokens to addresses controlled by the attacker, as users had approved the Furucombo contracts to use their tokens on their behalf.

Summary:

1. FC proxy made caller-specified delegatecalls to trusted handlers, letting its storage be modified
2. a handler made caller-specified delegatecalls to an address read from storage
3. the handler exposed a function for setting that address

What have we learnt:

1. a "trust list" is useful but not a guarantee
2. developers should audit how a delegatecallee's functions can affect the caller's storage
3. consider restricting functions or parameters of callees
4. be wary of user-supplied inputs

It wasn’t just individuals who lost out, even Cream Finance suffered a loss, as the attacker “borrowed” directly from their treasury."