Better to wait than to swing and miss.
We heard about Furucombo but our hands were tied - small teams can’t always ship on time, especially when the hackers work weekends. If you’re a DeFi detective with skills to share, then reach out and tell us about your experience - we might have a spot for you here at rekt.news.
A hacker hit back with a counter attack, broke Furucombo and knocked out $14 million from various wallets who had given the app “infinite approval”.
Infinite approval means unlimited trust - something which we know we shouldn’t do in DeFi.
“Don’t trust, verify”, but who has time or the cash for gas to approve set amounts each time they transact?
People who used Furucombo had to give some amount of approval, but it seems too many gave too much, and they received a harsh lesson in return.
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.
Kurt Barry provided an analysis:
One of the fund stealing transactions was sent to the Furucombo proxy, specifying the AAVE v2 Lending Pool proxy as the "handler" for the first and only action.
You can see the execution trace below, as shown on ethtx.info. Notice the nested delegatecalls.
Handlers must be approved in a registry; at the time of the transaction (but not at present), this proxy was a valid handler.
The FC proxy delegatecalls the AAVE v2 proxy, which then reads out the implementation address from a special storage slot, but as this is a delegatecall, it reads from the storage of the FC proxy, and the extracted address is the hacker's exploit contract.
If we look at the hacker's previous transaction:
We see that the hacker used their malicious contract to make the FC proxy delegatecall to the AAVE v2 proxy, invoking the initialize function, setting the implementation slot.
Once the delegatecall executed the hacker's code in the FC proxy's context, it was all over. The victim had approved the FC proxy to move their stETH, and the exploit code sent it all to the hacker.
Rinse and repeat for the rest.
- FC proxy made caller-specified delegatecalls to trusted handlers, letting its storage be modified
- a handler made caller-specified delegatecalls to an address read from storage
- the handler exposed a function for setting that address
What have we learnt:
- a "trust list" is useful but not a guarantee
- developers should audit how a delegatecallee's functions can affect the caller's storage
- consider restricting functions or parameters of callees
- 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.
Igor Igamberdiev gave a list of the assets which were stolen.
- 3,9k stETH
- 2.4M USDC
- 649k USDT
- 257k DAI
- 26 aWBTC
- 270 aWETH
- 296 aETH
- 2.3k aAAVE
- 4 WBTC
- 90k CRV
- 43k LINK
- 7.3k cETH
- 17.2M cUSDC
- 69 cWBTC
- 142.2M BAO
- 38.6k PERP
- 30.4k COMBO
- 75k PAID
- 225k UNIDX
- 342 GRO
- 19k NDX
We spoke to DeFi enthusiast Limzero (@pleyuh) after we found out he was one of the worst affected.
How did the situation play out for you?
How did you realise Furucombo was being attacked and when did you take action?
I checked one of my addresses I had used furucombo from and noticed the transfer of my aAAVE and some aETH.
I got scared because I had some active loans and didn't want to have my deposits liquidated. I found out that my health factor had dropped to 1.15, so i repaid the loans fast.
What i noticed is that the attacker drained all my aAAVE but only 1/3 of my aETH. I suspect that the low HF blocked them from transferring more funds out. I might have been lucky having active loans.
After I repaid the loans to protect the deposits, I revoked all token permissions I had given from that address.
That was an action I was postponing for weeks (for when fees would be lower). Apparently it was a costly delay.
I noticed the transfer of my funds by the hacker 90m after the hack had taken place.
Was it a big loss for you?
How did it feel psychologically, do you feel more cautious or less confident about using DeFi after the attack?
It was a big loss in absolute numbers but nothing my portfolio couldn't survive.
I got very scared for a couple of minutes as I was afraid that all my aTokens could have gotten liquidated, when I saw my health factor above 1.1 I felt relief.
I treat the whole experience as an expensive security lesson- having infinite allowances on from an address with large amounts was a very silly mistake by my side. All things considered, that was an ape tax I had to pay eventually. It's the first smart contract hack / exploit that affects me after so many years in the space. I feel lucky that more serious situations haven't touched me yet.
Actually the first exploit after the COVER exploit but I forgot about that :P
I do not feel less confident about using DeFi. These kinds of risks were known.
I have taken measures to increase my cyber security though.
What can you tell us about these measures?
I'd rather not say sorry.
It's part of the measures 😋
What steps would you recommend our readers take to improve their security?
- use hardware wallets
- avoid windows
- web 3 dedicated machine for contract interactions
- unique passwords or password managers + VPN
- low social media profile
- use multiple addresses to spread risk
- fresh addresses for new farms
- revoke approvals from frequently used addresses
I am not a security expert by any means. These are standard guidelines suggested by more knowledgeable people in crypto.
- read REKT xD
rekt: Any final message for our readers?
"Please don't hack me again"
Also, unless you feel very confident about your security, consider keeping a small fraction of your holdings on top tier CEXes like Kraken, Coinbase, Gemini, Binance in case your personal wallets get hacked.
That's all from me.
Thanks for talking to us.
Thank you! I hope we never talk again lol.
A simple attack with a simple fix - don’t use “infinite approve” unless you have unlimited trust. Individual approvals are no small expense, but don’t cut costs when it comes to security.
Never drop your guard, hackers are always looking for an opening, and these attacks occur much more regularly than you might expect.
There’s no referee inside this ring; you are responsible for your own safety, but once you learn the ropes, the prize money is worth the risk.
REKT serves as a public platform for anonymous authors, we take no responsibility for the views or content hosted on REKT.
Donate (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C
REKT is not responsible or liable in any manner for any Content posted on our Website or in connection with our Services, whether posted or caused by ANON Author of our Website, or by REKT. Although we provide rules for Anon Author conduct and postings, we do not control and are not responsible for what Anon Author post, transmit or share on our Website or Services, and are not responsible for any offensive, inappropriate, obscene, unlawful or otherwise objectionable content you may encounter on our Website or Services. REKT is not responsible for the conduct, whether online or offline, of any user of our Website or Services.
You might also like...
The US government payment system “Fedwire” got rekt yesterday, preventing them from processing some of the $3 trillion dollars that is supposed to go through their system each day. Decentralise the central bank. Give us a CBDC and we'll decide if we use it or not.
The dark arts of DeFi remain the most profitable. ~$37.5M gone in a tale of fake magic, confusion and accusation. The victim has singled out their attacker.
Sometimes armour is not enough. A protocol that offered protection has stabbed its users in the back. Armor is not to be trusted. The team decided to throw away their reputation and put their greed on public display when they refused to pay one of their policyholders after last week's Yearn arb attack.