Smart Contract Security Audit: An Auditor's Interrogation

Let’s go - 0xheading:

Starting all the way from a blockchain engineer’s to an auditor’s internship, half a year later grabbing a junior smart contract auditor position, here at BlockApex, I decided to set out with my current auditing skills in an open market to test the waters. 

One thing happened. It came as a blow.

“Ethereum is a developer’s blockchain, built by developers, for developers.” 

Mastering Ethereum: Building Smart Contracts and DApps 

- Andreas Antonopoulos

My story starts here - Introduction:

As soon as I got into blockchain from the conventional software development universe of the web2, I found myself into a crosshair of what they at paradigm.xyz term as the Dark Forest. Indeed, exploring the details of EVM and Solidity as a programming language introduced me to sensitive traits and precise characteristics of the blockchain which I would like to call a pure child of Computer Science. 

All the while, it was a constant effort to try and connect the dots with DeFi after learning through different concepts. It still amazes me what many things one can learn and achieve within this fast and growing world of web3 and that too in such a short period of six months. 

How I find auditing - Essence of Audit:

Smart Contract Auditing and Security Review is an uncharted territory where a great landscape needs discovery. But switching into audit even from an expert developer background does not guarantee a potentially successful security researcher’s career. Auditing requires a solid approach to security mindset and for an individual’s Sherlock skills to outperform each time. I confess that even time after time I went through the cycle of audits for various DeFi projects, I would find myself restricted in terms of a comprehensive story building and a proper reconnaissance phasing by looking at the smart contract codes or the documentations.

Whereas, I’d often find my mentor make up stories for some protocol we were auditing in pairs and come to some exploitable hack not just by following the coding/ logical errors but supplying it with a dense knowledge of DeFi and hence, pertaining to the scenario at hand. 

How do I get better at this - Learning Path:

I bear witness to the magic of composable knowledge that auditing demands. It is a constant association and context-switching where one combines the knowledge of economics, finance, blockchain technology and the rational thinking of actors.

Intrinsically, smart contracts being a software program inspire one to get their hands dirty with the building blocks of this ecosystem through a technical roadmap. The fundamentals are composed of getting a deeper understanding of the EVM (Ethereum Virtual Machine) and the working of a public blockchain at lower scientific levels.

Securing this piece of software from most kinds of privacy exploits and monetary attacks starts as a fun ride where you grab the Solidity concepts through courses, blogs, youtube channels and the best one; Documentations. Developing the sophistication of security recommendations and the common vulnerabilities is another great journey where the story building develops through making small exploits here and there, reading upon some famous relevant tweets/ hack analyses, and popular researcher’s works to catch up.

I find auditing as a smooth switch from a development background. One can start right away by solving and attempting challenges/CTFs or the best option in my opinion is Secureum. Secureum encourages such an approach and provides a complete glossary of security based learning and guide to different paths of smart contract audit. Another golden egg is an audit report, loads of insight, information and knowledge captured in just 10-20 pages of publication where a diverse audience is expected.

Interviews can go down - Hope Not Out:

I was set up to meet a really cool person for the auditor’s position interview at one of the top-tier firms in smart contract security who was a web3 security researcher and had a cyber security background. After talking for around more than 1 and a half hours, it was really exciting for me to get to experience the different concepts through a proper auditor’s lens and how things were supposed to be seen in perspective. 

The first question which any auditing interview concerns is mostly regarding what is your preferred audit process? Answers could be subjective, but I like to follow the industry standard as in this ‘Solcurity Standard’ article by Rari-Capital along with the Consensys’ best practices set of guidelines which pave a path for a thorough audit process. 

Summary of my personal process which is kind of mixed up with the one that my senior auditor exercises (and I learned it from him) would be as follows;

• Make up an understanding of the protocol without looking the code first
  • Start with docs, whitepaper/ yellowpaper, github readme, anything that describes what the protocol plans to accomplish.
• Get a bird's eye view

Moving up with some generalized questions such as;

• What is a bytecode? Collection of opcodes (hexadecimal digits) - mini commands used inside the limited storage of the “EVM” to manage operations
• How do you look at the opcodes? Translation of a high level program to machine level - lowest platform to check for stuff/ manipulate things
• What's your perspective of understanding the compiled version of code that runs on top of the EVM? Solidity is a sensitive contract oriented HLL - needs delicate touch and close look for optimum results - a code can always be optimized with ingenious ways - best is to think in terms of bytecode - translation of Solidity to bytecode and what difference a simple typo in a function name can create to the final bytecode, refer to the Pinball CTF by samczsun, guy literally made a game to mess with the compiler and the contract creation code, so there’s always one thing that could be bested.

A further session was switched into more code focused and best practices formatting where we wandered off towards some factual questions e.g.;

• How do you get a private variable’s data? Though the internal accessibility modifier remains hidden, private is readable and could be accessed using the low level eth call (eth.getStorageAt()) or using tools like cast/ slither-read-storage. 
• What to do if you don't want to use safemath in ^0.8 versions of Solidity? Use unchecked. Why would you do that? To save gas as the checking for obviously safe numbers will be a redundant op, hence let it go unchecked!
• What’s the difference between msg.sender and tx.origin? The tx.origin address will always be an EOA - msg.sender is the immediate preceding caller could be EOA, could be smart contract.
• How is using tx.origin risky? create an attack contract, originate the call/tx from that contract - social engineering to influence users to make a call from authorized addresses - take control into the attack contract, hence the check for tx.origin to be authorized would be true at the start but plays into the adversary hands then.
  AVOID. USING. TX.ORIGIN.
• What are some potential vulnerabilities in forks? Modification brings unwanted attack vectors/ backdoor opportunities - bots copy and clone the forks and overlook the solidity version updates before changing functionality hence the mods break.
• What are breaking changes of solidity versions? E.g. version 0.8 contains the builtin overflow underflow checks
• Define reentrancy? a function makes an external call to an untrusted contract containing the “expected function” which makes a recursive call back to the original function in an attempt to drain funds, attack protocol, rob assets. 
• What could be a better solution to prevent reentrancy? The checks-effects-interactions pattern is a really good way and a recommended industry practice while making external calls.

When you attempt a Capture-The-Flag CTF challenge, the goal is to extract sheer ingenuity of an exploit. This way you get an exposure to the unimaginable attack vectors observed in the solution of the challenge. 

Consider the example of a challenge named King Of Ether. Although winning this challenge by becoming the king is a feat, what if you are asked to stay as the king of that contract, persistently? Answer which I learnt that day was something like this; create a fallback in your version of contract that reverts the tx required to become the next king whenever it receives funds to be redeemed for your contract. These ingenious solutions open up a world of possibilities and perspectives for an auditor to let their mind go berserk.

Which one of the following is your favorite CTF to play around?

(forever incomplete) List of Solidity CTFs:

• Ethernaut, 
• Damn Vulnerable DeFi, 
• Not So Smart Contracts, 
• Paradigm CTF, 
• Capture the Ether, 
• Ether Hack, 
• Cipher Shastra, 
• DeFi Hack, 
• Gatcha Lab, 
• Pinball Challenge

What is my most favorite DeFi hack, technically, ever happened? 

Honestly speaking, I don't know the answer to this yet.
When I read about a hack in a researcher’s tweet, some news reporting handle or any article, I deep dive into the technical perspectives of the motivation behind the devs code writing. My question raised is how as an auditor (had this attack not happened then) would I get to it, prove/verify the severity and report the issue/bug? This cycle keeps on repeating and takes me from one audit report to another, introducing the minor details of how auditors actually come to the understanding of hacks and how in the first place report them as vulnerability within the code. 

This, to me, is like a superpower and leaves me in awe of the beauty of story building, slowly and gradually making up my mind to think and construct in the same patterns and ways to exploit the code during the audit.

On my way - In the end:

If you (a web2 developer) think you have a good imagination and can quickly understand what is going on in the mind of the person across from you, either be a dev or a fellow auditor, then search for Secureum now and start learning auditing. You will be amazed at how easily the resources are available and the number of opportunities present to you on the way. After that, it's just code4rena and you (You’re welcome ;-)).