Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The SUSHI token is a governance token with voting power. The SUSHI holders can delegate their votes to other users to gang vote on proposals as well. This entity is known as the representative.

The protocol had some design flaws in it. The function _moveDelegates is executed during the voting delegation process to give the votes to a representative. Although the voting power is moved to the representative, the delegator's tokens are NOT. So, they can transfer the tokens to another user who can now vote or delegate further these further. This is known as a sybil or double spend attack.

The second vulnerability is a logic flaw in changing representatives. During the redelegation process, the previous delegates voting tokens are subtracted from and the new delegates tokens are added to. However, the previous delegate token amount subtracts with the current token amount instead of the previous. This means that we can subtract votes from a representative by simply delegating, buying SUSHI and changing representatives.

The previous vulnerability can also cause a denial of service (DoS). A user may want to redelegate their funds to another. However, since the current SUSHI token count is used instead of the previous one, the arithmetic can underflow.

Interestingly, these are known bugs by the SUSHI team. In the contract code, there is a comment saying to NOT use this token for security reasons. I'm sure when people assumed the code worked fine though. Why wouldn't they just patch the bugs then? So weird. Overall, impactful and simple logic bugs.