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!

Redacted Cartel Custom Approval Logic Bugfix Review- 877

ImmunefiPosted 3 Years Ago
  • ERC20 is a standard used for different tokens in Ethereum. OpenZepplin has a battle tested implementation of this to ensure that nobody has to rewritten these basic but security sensitive functionality.
  • The implementation of transferFrom allows users to get money from other users. Of course this requires the approval of the user whose funds is being taken away. This is common in the real world, with situations like bills from comcast and things.
  • Within this function, the funds are first transferred to the sender of the request. Although this sounds strange, this is the proper pattern to prevent reentrancy attacks. transfer will ensure that the operation is allowed.
  • Next, it calls the approve function to subtract the amount of tokens from the current transfer of allowed tokens. For instance, if I'm allowed to take 5 apples total but only take 2, I still have 3 apples I can take. This is the logic that the code is trying to do for the tokens.
  • Here is where the problem comes in: instead of allowing the recipient of the data, it allows the msg.sender or the CALLER of the request. This malicious user was never allowed to access these tokens, which creates a major problem.
  • In order to exploit this, the attacker needs to send a request to transferFrom to send 0 tokens. This is because we need the call to succeed in order to change the approval on our account. Once the approval has been made, we can transfer tokens from their account.
  • The fix was to remove this contract entirely and use the OpenZeppelin implementation instead. Don't roll your own crypto(currency)!
  • Overall, I really enjoyed the bug. It was extremely subtle and easy to miss. I'm surprised that transferFrom for 0 ETH still worked, even when our user was not authorized to do this. Interesting!