Guest Spotlight Article: Winning an Audit Competition in a Team

The following content has been kindly guest contributed by EgisSec, a team of security researchers (deth and nmirchev8) within the Hats Finance ecosystem, as part of the Security Researcher Content Contributor Programme.

Auditing in a team

Have you ever participated in a contest where speed is everything? You race against other researchers to find vulnerabilities, often sacrificing a deep dive for a quick win.

Hats Finance innovative reward mechanism incentivizes the fastest researchers, creating a pressure cooker environment. This can lead to focusing on easily identifiable vulnerabilities rather than taking the time to unearth more complex ones.

As an auditor, you’re faced with a dilemma: Do you rush to find basic vulnerabilities to secure a quick payout, or do you invest time in a deeper analysis for potentially more impactful findings? The latter option might be better for your skills.

But what if there was a way to avoid this trade-off?

This is how auditing in Egis Security feels like and that’s what allowed us to secure a first place in the recent Convergence contest.

A few months ago, we, nmirchev8 and deth, partnered up and created Egis Security.
What makes us such an effective team and what led us to winning the Convergence audit on Hats, which was one of our first contests as a team?

Our diverse auditing styles combine strengths to create a team with no weaknesses. With our complementary approach, our team is able to tackle any audit challenge.

When you work with a teammate you always have someone to bounce ideas with, someone that you can brainstorm with and someone who may be better in some areas. This gives us the potential to uncover a much wider range of vulnerabilities, compared to if we audited solo. Deth’s strengths are nmirchev8’s weaknesses and vice-versa, allowing us to become stronger as a team.

All this compounds into quickly uncovering vulnerabilities, which in Hats is vital. Egis Security manages to not only find issues that are low-hanging fruit, but also to quickly analyze the codebase and uncover the more complex/edge case vulnerabilities, which gives us an advantage in Hats competitions.

Now let’s examine our “multithreading” hacking approach:

deth’s thread

When I start auditing a codebase, the first thing I do is quickly go over all the important functions in a logical way. In Convergence’s case that would be: deposit logic -> reward logic -> withdraw logic. This very quickly gives me an understanding of what the protocol is trying to achieve and gives me the knowledge of what areas I should focus on.

I also prefer not to read any documentation, except if the protocol is very large and complex. I like this approach, because in my experience, documentation is almost always old or misleading and it showcases what the code is supposed to do, not what it actually does. Auditing this way is slower and confusing for beginners, so I don’t recommend it to newbies, but more experienced auditors should try it.

The documentation may lie, but the code never lies.

I also put a heavy emphasis on external integrations. This is one place where protocols are most likely to make mistakes. More complex external integrations almost always have some weird/edge case functionality, i.e pausing, whitelisting, distributing rewards in a novel way, etc. Almost always protocols don’t handle every edge case, which leads to vulnerabilities.

nmirchev8’s thread

My preferred approach to understanding a new Solidity codebase involves analyzing it as a state machine. This method prioritizes examining transition functions and their impact on state variables. By recursively tracing functions and their entry/exit states, I can gain a solid grasp of how the code manipulates data. This approach is particularly effective for identifying logic errors related to state variable manipulation and ensuring valid state transitions. However, it’s important to acknowledge that this method has limitations and may not uncover all types of vulnerabilities.

Convergence

As a newcomer to Hats Finance contests, I was impressed by the efficiency of the Arbitrum submission integration. The ease of tracking submissions streamlined the process, enabling me to dive right in and focus on the real challenge — cracking the code.

Convergence is a governance aggregator that optimizes yield

For this contest, the scope was a staking contract and an integration with Convex.

(More about convex: https://docs.convexfinance.com/convexfinance/general-information/why-convex)

I won’t go into details about the Convergence staking mechanism, because this would take a separate article.

For this specific bug, the issue resided in a complex function responsible for distributing staking rewards to users. The culprit was the utilization of an incorrect variable when referencing the length of an array of reward tokens (_cvxRewardsByCycle). This error could have potentially led to stakers losing their rewards under certain circumstances.

Seeing complex functions always gives me a “be careful” feeling in my gut and I started going slowly line by line and questioning each part.

The contract accumulates various ERC20 rewards for each cycle, storing them in the _cvxRewardsByCycle[cycle][erc20Id] state variable. However, the problematic code snippet mistakenly used the user’s last interaction cycle (nextClaimableCvx) to determine the array length for reward distribution. My mental alarm bells started ringing because there was no relation between those two components. From here I dived into finding an impact and 5 minutes later I had already submitted the issue on-chain through Hats platform.

Stay up to date with Egis Sec

Egis Sec Twitter: https://x.com/EgisSec

Egis Sec Website: https://www.egissec.com/

Deth Twitter: https://x.com/dethSCA

nmirchev8’s Twitter: https://x.com/nmirchev8