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!

This article dives into finding exploitable smart contract vulnerabilities. In particular, it tries to find methodologies for vulnerability classes that are missed by static and dynamic analysis tools. Several classes, such as integer overflows and reeentrancy, can be detected with analysis, while others cannot.

The paper uses vulnerabilities from Code4rena and real world exploits. It compares the bugs that were discovered between the two locations, making a distinction on difficulty from these two. Unfortunately, there are only are handful of bugs on the real world exploit-side though.

They group the bugs that cannot be found by automated analysis into a several categories, with clear and defined ways to identify them. First, they talk about Price Oracle Manipulation. When operating an AMM or using money, a price must be generated for this. If this is done insecurely, then the price of an asset can be manipulated somehow. For finding this vulnerability, the author mentions looking at how prices are generated and see if any of the variables in the algorithm can be changed quickly.

The next one is privilege escalation, a sequence of events to bypass access controls. In the example contract, there is a proposal vote that forces action to be in separate blocks (vote and end). The passing of a proposal is calculated based upon the amount of votingToken given to the contract. Although the vote function is the only way to send tokens directly, a user can manipulate the funds in a single block by taking out a flash loan, transfer the funds to the contract, end the proposal then claim all of the locked funds.

For finding these bugs, the author talks about critical access controls checks being violated by internal or external calls to this contract. The difficultly in identifying this bug was that it requires domain specific knowledge in order to understand the implications.

The final bug class with a good example is atomic violations. In the world of Ethereum, this means demanding that state variables cannot be accessed by other flows while they are on-going. An example of this is a lottery system which tries to force lottery number picking to be different than submitting. However, a bug in the contract allows a user to look in the mempool (by frontrunning) to see if a number has been placed. If this is true, then they can place the correct number. Looking for proper use of booleans and lock variables is how to find these bugs.

The author also mentions a few other bug classes:

• Erroneous Accounting: Complex math operations going wrong. This can be a bad yield percentage, inflation, infinite burn and weird numerical issues.
• ID Uniqueness: Orders and NFT IDs should be unique in order to ensure the owner can act on it. If IDs can be duplicated in some way, a major problem can occur, similar to access control violations.
• Inconsistent State Updates: Many variables are correlated with each other for a user, such as credit limit being proportional to a user collateral. If some state is updated but another is not, major problems occur.

To me, a lot of these violations can be solved with three questions: what are the threats for this contract, what are the security controls to prevent these threats and how can these controls be violated? The authors of this post used this knowledge to find 100K worth of bugs. They found two oracle manipulations, two erroneous accounting bugs, four privilege escalation bugs, two atomicity violations, one of both bad state updates and ID uniqueness and three contract implementation specific bugs. Pretty awesome paper with good thoughts on discovery!