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 smart contract runtime environment of this exploit was Stacks. This is a Bitcoin layer 2 solution that uses the Clarity smart contract language. Honestly, I couldn't follow this article. I also don't know how Stacks/Clarity works either. So, I had to ask a friend about how this exploit worked. So, take this with a grain of salt.

In most smart contract runtimes, you send funds alongside your call. In Stacks, the end user wallet specifies post conditions that determine what can be done, making this fail open instead of fail closed. In theory, if there is no post condition that disallows a contract taking all of your tokens, then it's legal to do.

In Solidity, there are two senders: tx.origin and msg.sender. One is used for the original executor of the transaction and the second is the most recent caller. This same concept exists in Clarity as well.

When making an external call to another contract, the AsContract command can override the tx.origin of the original caller. This is super important because this is what the post conditions are based around!

The post conditions can only be set by the original executor and NOT the smart contract. When the AsContract command is used, if the call is made to an untrusted contract then there are no post conditions restricting where the money can go for this! This lack of access control on the smart contract call is the reason for the bug. By becoming the contract, we can now drain all of the funds from it. Yikes!

The existence of AsContract is weird to me. I get there are situations where you want to act as the caller but it's such a security liability here. Again, not a great write up but an interesting vulnerability class none-the-less.