At Code4rena, our goal is to help reduce the number of vulnerabilities that make it to production in the web3 space. Most of the time, this is done through audit competitions where Wardens compete to find unique vulnerabilities in projects’ code. Another element of this mission is helping people understand common vulnerabilities so that at the point of developing a codebase they’re front of mind, and at the point of auditing they don’t slip through the cracks.
We sat down with Zhuo Zhang and Brian Zhang to talk about exactly that: the theory behind spotting vulnerabilities in web3 codebases. They co-authored a research paper titled “Demystifying Exploitable Bugs in Smart Contracts” which provides insight into exploitable bugs extracted from Code4rena competitions. The aim of this paper is to raise awareness about the significance of such bugs and help develop more sophisticated automatic semantical oracles to detect them. Let’s dive in.
Introduce yourselves!
Zhuo: Hello, my name is Zhuo Zhang, and I’m currently a fifth-year PhD student at Purdue University. I’ve been working as a white hat hacker since 2016, specializing in web2 security. My research interests lie in binary analysis or reverse engineering, which involves extracting high-level semantics from low-level assembly or byte codes. By doing so, I’ve been able to find vulnerabilities in closed-source programs and even obtained several zero-day bugs with CVE numbers assigned. This has been the main focus of my PhD research.
In early 2022, I began my journey into web3, starting with bug bounties and participating in auditing competitions, which ultimately led me to conduct research in this area. I’m excited about exploring this new and fascinating field further. As I approach the end of my PhD (by the end of 2024), I’m considering opportunities in academia and industry and keeping an open mind to any exciting prospects that come my way.
Brian: My name is Brian Zhang, and I am a high school student at William Henry Harrison High School in West Lafayette, Indiana.
Over the past year, I have had the privilege of participating in numerous audits on platforms such as Code4rena and Immunefi. These experiences have allowed me to develop a keen understanding of software security and sharpen my skills in finding smart contract vulnerabilities. Before that, I had been doing competitive programming for years and achieved the USACO Platinum status.
How did your journey into software security begin?
Zhuo: Great question! My journey into software security began when I was a sophomore in college in 2016. It all started with Capture the Flag (CTF) competitions, which are cybersecurity challenges designed to test participants’ security skills. I became intrigued by CTFs after seeing some of my friends participate and thinking it looked pretty cool. I asked them to take me along the next time they played, and from there, I had the opportunity to compete in various world-level CTF games, including the DEFCON final in Las Vegas. That’s how my journey into software security began!
Brian: My involvement with software security began through an outreach activity organized by PhD students at Purdue University. There, I was introduced to essential ideas behind cryptocurrency and blockchain technology. I was also introduced to competitive web3 auditing, which I found to be really interesting. My auditing experience began through the Ethernaut series, and I would eventually move on to real-world auditing like Code4rena competitions.
Zhuo, we saw that you’re a PhD student in software security. What made you decide to pursue this avenue as a career path?
Zhuo: Thanks for asking! As I mentioned earlier, I became interested in software security when I started participating in CTF competitions back in 2016 and spent a significant amount of time on them throughout my college life. It was at that time that I discovered my interest in software security. After graduation, I faced a tough decision between pursuing a career in industry or continuing my education through a PhD program. Ultimately, I wanted to push the boundaries of my knowledge and see how far I could go in the academic world as a researcher. That’s why I chose to become a PhD student in software security, and I’m grateful for the opportunity to explore this field further and contribute to its development.
And Brian, are you thinking along the same lines as Zhuo?
Brian: While I am still a high school student, my goal is to get a PhD. My current aim is to study software security in college since I really enjoy auditing web3 security and I also believe it will have a substantial impact on the future. Through my auditing experience, I acquired valuable practical skills that I would have difficulty obtaining elsewhere. There aren’t that many courses which will teach you how to set up package managers, nor teach you how to construct exploits to real-world vulnerabilities. It is also gratifying to know that I have contributed to the creation of safer online environments.
As is evident in your research paper, you’ve obviously got an in-depth understanding of web3 security. How, in your opinion, do web2 and web3 security differ from one another?
Zhuo: That is a good question, which is also one of the key questions we try to answer in our ICSE23 paper, which was written as an initiative for the ICSEconf. In my opinion, one of the most significant differences lies in how functional bugs are treated and their impact. In traditional software security, functional bugs are less of a concern because their impact is often implicit. Instead, the focus is on low-level memory corruption issues like stack/heap overflow and use after free.
However, in web3, functional bugs can have severe consequences, such as incorrect fund transfers when a smart contract yields an incorrect output. In fact, a large portion of severe vulnerabilities in web3 are caused by functional bugs. It is also worth noting that detecting functional bugs is not easy in both web2 and web3 security. It usually requires deriving high-level semantic oracles, which are currently lacking in existing web3 auditing tools. Therefore, developing such oracles could be one of the most promising directions for web3 security research.
Additionally, web2 security has been well-developed for several years, and many famous protection mechanisms are in place, such as Address Space Layout Randomization (ASLR) and Control Flow Integrity (CFI). However, similar protections are still in the early stages of development in web3. Runtime attack detection and protection may also be important for web3 security in the future.
How did you get into the web3 world, and what interests you most about the web3 security space?
Zhuo: I first got into the world of web3 through my friend Wen Xu, who founded a web3 security company (PwnedNoMore). He gathered a group of white hat hackers to discuss research directions in web3 security, which was my first exposure to the field. From there, I started doing bug bounties on Immunefi in my free time. After about half a month of exploring web3, I reported a critical bug and was awarded $3,000. Despite not having a huge amount of bounties, my journey started there.
What interests me most about web3 security is the opportunity to make a real impact. The high payouts are certainly attractive, but even more satisfying is knowing that my efforts are helping to secure users’ funds. For example, through C4, I reported several critical issues to ENS, which is one of the most important components in the Ethereum ecosystem. It’s rewarding to see that my work can have a significant impact on the security of such crucial systems.
Brian: As mentioned previously, I was introduced to the web3 world through an outreach activity organized by Purdue students. I also did a lot of self-studying by reading online blogs and tweets and working through the Ethernaut challenge series.
One thing that interests me the most about the web3 security space is the diversity of applications. There are a wide variety of smart contracts that are available to audit, so each competition is like opening a mystery box. Additionally, I really enjoy the feeling of finding an exploit (doesn’t everyone?), especially given the fact that it is never guaranteed that an exploit exists, finding one and having it be accepted is a fantastic sensation. I remember what I felt when I found my first exploit; it was on my birthday, and I was giddy enough to feel light-headed.
We saw you have over $100k in earnings from competitive web3 audits. What do you like about the competitive audit model? Is there anything you’d change?
Zhuo: I strongly believe that the competitive audit model is one of the most effective approaches to auditing smart contracts. With so many talented white hat hackers working together, there’s a greater chance of catching even the most elusive bugs. The competitive model also increases efficiency, which is essential in meeting the high demand for contract auditing. Additionally, the resulting reports are a valuable resource for the ecosystem, not only because they’re publicly available but also because they’re well-organized and easy to access.
In terms of changing the model, I think things are working well overall. If I had to make a suggestion, I would consider increasing the awarding pools! Just kidding. I know the amount in award pools is well-designed by C4 and good for me.
Seriously speaking, a potential improvement could be requiring wardens to provide a runnable script as proof of concept for high-severity bugs. This would make the judging process easier, as well as prevent malicious actors from intentionally flagging lower severity bugs as high. During our research, we found that quite a number of reports lacked runnable scripts and relied solely on descriptions as proof of concept. While descriptions are useful, they can be less effective in conveying the impact of the bug.
Brian: I am extremely satisfied with the current competitive model. First, it helps establish a time-bound that encourages auditors to work hard. Also, the frequency of competitions is great; casual auditors won’t feel that bad for missing a few contests (e.g., due to homework and college applications), whilst more dedicated auditors have a wide variety of contests to choose from. I also think one of the best parts of the model is providing access to successful bug reports. This is a huge part of our research paper, after all. The released bug reports help paint a picture of what security in smart contracts looks like: if there is a sudden popularity drop in a certain type of exploit, that may mean there exists some method or tool that can detect it. If not, then that type of exploit may be more likely to occur in the coming contests.
If I could change anything, I would probably push for the creation of a testing script to be submitted along with each exploit. This may likely prevent many submissions that do not work, saving time on the judging side. Additionally, judges will have an easier time ascertaining the validity of an exploit.
What’s the first thing you look for when searching for vulnerabilities in a smart contract? Do you have a usual process?
Zhuo: I typically follow the abstract models outlined in our ICSE23 paper when searching for vulnerabilities in a smart contract. For example, I’ll always check pricing and swap-related functions for price oracle manipulation bugs, as well as look for bugs that can be discovered by simple and general oracles like reentrancy.
Once I’ve exhausted all of the abstract models, I’ll spend a considerable amount of time understanding the business logic of the project at hand. Because functional bugs are critical in smart contract security, it’s important to have a deep understanding of the semantics of the project to know what’s right and what’s wrong. With this understanding, I can then develop high-level semantic oracles (in my mind) and identify operation paths that can break them.
Typically, in a 7-day contest, I allocate one day to try abstract models, at least four days to understand the project logic and manually derive oracles, and two days to break those oracles. I recognize that most of my time is spent on deriving oracles, which underscores the importance of developing automated tools for deriving oracles. That was the original motivation behind writing our ICSE23 paper — to share our findings with the community and ask for their help in developing such oracles.
However, I must admit that this process is more focused on finding high-severity bugs, which may hinder my ability to identify lower-severity issues.
Brian: Well, the first thing I do when searching for vulnerabilities is to understand the contract. This usually takes me a few days and is one of the most time-consuming parts of my audit. Then, I note down functionalities that would make it more vulnerable to a certain type of attack; for example, if there are states and state updates across multiple functions, I may focus more on Incomplete State Update exploits. Once I have finished analyzing the contract, I try to work out business logic that will make an exploit possible.
What’s next for you?
Zhuo: My current research focus has been switched to web3 security, and our group has several ongoing projects related to developing more efficient auditing tools and providing stronger protection for smart contracts. In the near future, my primary goal is to accelerate this research and make significant contributions to the field. Additionally, I plan to continue participating in C4 competitions in my free time, and I hope that my tools can help me earn more rewards (laughs).
Brian: Given the extensive amount of time that it takes me to analyze a contract, I have been working on abstraction and automation of certain types of exploits so I won’t have to waste time on them during actual competition. Applying for colleges has taken a huge chunk of my time, but now that applications are over, I am looking forward to participating in more C4 contests.
Finally, if you could give a tip to someone just starting out in web3 security, what would it be?
Zhuo: Well, if I had to give just one tip to someone starting out in web3 security, it would be to not miss out on the C4 competitions. That’s where the real action is happening, and you can gain valuable experience and learn from the best in the field. And if I’m allowed to give one more tip, it would be to check out our ICSE23 paper — not because we want more citations, but because we think it can provide some useful insights for anyone interested in web3 security. Plus, it’s a great way to impress your friends at parties (laughs).
Brian: One of the best tips in my opinion for starting out on web3 security is to read current exploits. Whilst I think C4 is one of the best resources, other sources work as well, from blogs to tweets to papers and more. Finally, I want to express my sincere gratitude to you and the entire team at C4 for allowing me the chance to share my experiences.
If you’re interested in reading their paper, visit this page.
You can find Zhuo on Twitter here, and Brian on Twitter here.
