The Honeytrap (A Story about a Migrator behind Timelock)
An analysis on the HoneySwap.fi rugpull
On Feb 28 at around 3AM UTC, HoneySwap.fi, another one of the latest Goose clones executed a rug pull. Transferred all of the staked funds to their own pockets.
This one caught a lot of people off guard because on first glance, it seemed everything was under timelock protection, including the migrator function that was added back in. Many in the community was left confused as to how they managed to bypass timelock protection to execute this rugpull.
So as always, let’s take a dive into what really happened.
Background Story
HoneySwap.fi forked from the Goose MasterChefV2 contract, an upgraded version of the original Goose MasterChef with added re-entrancy protection that was recommended by the CertiK audit, which seems extra safe.
But then on top of that, they re-introduced the migrator code that existed in the original PancakeSwap/SushiSwap MasterChef, an abomination that has wrecked havoc way too many times in the recent weeks.
Interestingly, they did not actually use the migrate function to execute the final rugpull, atleast, not directly.
They told everyone that the migrator was not here for rugpull, and assured everyone that the fact that it is protected by timelock is proof of that.
Any prudent user would check and indeed be able to see that the setMigrator function is behind timelock, and the current migrator is indeed empty. However, this was just a smoke screen and they have already covered their tracks in this scam.
The Method
When we analyze the decompiled attack contracts used to pull off the final rugpull, we can see that the “transfer” function was called on the attack contract for every pool, which then simply called the basic 3rd party token transfer and moved funds from the MasterChef to the dev.
If you know some basic solidity, you will know that this 3rd party token transfer requires an “Approval”, a signed allowance that gives a specific 3rd party the permission to transfer the tokens.
So we know that MasterChef must have given approval to this attack contract some how. Here is where the migrator comes into play. All this happened before everything was released to the public, and the devs covered their tracks afterwards.
The Rundown
- Deploy MasterChef
- Set Migrator to Attack Contract
- Call migrate function on each pool, even without any tokens already staked, this call still grants an infinite amount of allowance to the current migrator, which is the Attack Contract.
- Set Migrator back to 0x0000000 (this covers up their tracks that something fishy already happened)
- Transfer MasterChef ownership to Timelock
At this point, to an outsider’s eyes, everything looks normal and protected by Timelock. Little do they know, the backdoor is already wide open and the fruit is just waiting to be picked.
All that is left for the dev to do is to wait until the TVL is juicy enough for the picking. The Attacker Contract has infinite allowance to the funds staked into MasterChef and can access all the funds anytime. The rest is history.
WHAT ABOUT ZOMBIE FARM?
Zombie Farm is trying to create a cleaner environment for people to yield farm. We have removed the Migrator backdoor. We cannot migrate the assets therefore your assets will be safe with us.
We stress this over and over again, if you see the migrator function, it is a HUGE red flag. Even if it is behind a timelock.
Join Zombie Farm on Telegram: https://t.me/zombieFarm
Follow Zombie Farm on Twitter: https://twitter.com/ZombieFarm_en
Website: https://zombie-farm.com/
Finally also a shoutout to the guys at the group DEFI Audit & Research that asked us to help look into this rugpull case: https://t.me/defidyor
