Lessons Learned From Auditing Large Codebases, Georgi Ivanov | ETHSofia

[Music] Hello everyone. My name is Gorgi Ivanov. Some of you may know me as Given. It's so nice to see that the crowd for security research is getting larger every year at ET Sophia. Before joining the ranks of uh web three, I worked as a software engineer for 12 years mostly in stratfi organizations.

My last position was as a team lead for a crypto custodian where we served institutional clients. I'm happy to say that for two years, for the last two years, I've been working as an independent security researcher in the web 3 space. Before we start, I will have to warn you that this talk is a little bit more technical than the ones in this track. So, be prepared. Uh today we're going to talk about the topic Today we're going to talk about the topic that new security researchers might find challenging namely auditing large code bases.

Often the biggest constraint is time. You might enter a contest late or for example it happens that your client doesn't have enough budget to do the full duration of an audit. So my hope is that after the end of this talk you will have some items to put in your auditing toolbox for your next security audit. Okay, [Music] let's start by loosely defining what is a small code base. There is no concrete definition, but I would say that it's no more than a thousand lines of code.

It has zero or one integrations with another protocol. It also has at most two or three more complex functions for you to to look into. The docs might take like 30 to 40 minutes uh to read through. All in all, a small code base is one that we can easily fit in our mind. So as a person who has previous experience in software development, the usual approach is sequential.

We start by reading the docs. Then we pass through the code a couple of times. Then we try to find simple bugs and at the end we try to find more complex ones and try to do the exploits themselves. The issue is that this sequential approach can fall apart when we go into a large codebase and time is a constraint. In a large codebase, we can have multiple integrations which drastically increases the time to learn.

The docs might take like a day. There are thousands of lines of code and a lot of complex functions. So if we try the sequential approach that's normal, it is possible that 50% of the audit has passed. and we are still learning and we haven't found any bugs yet. So the first tactic I would suggest is breaking the codebase into verticals.

One vertical is one business flow or two. Let's say you have deposit and redeem. It makes sense to be in a vertical. They are kind of the opposite. So you pick one vertical, you look through the docs, then you read through the vertical only.

Try to find simple bugs and then if possible you you might try to find more complex ones. If you try this approach, it is possible that um at the end you will be left with a lot of questions. Actually, if you do this right, that's exactly what is going to happen. You will have a lot of questions. So, please write them down and we'll use them later as you go with this in this way.

What's happening is that we are taking one large scope and we are breaking it down into smaller ones. we will do uh iterations of learning and then trying to find some new bugs, right? And not try to do everything all at once, which might become counterproductive at some point. The best auditors that I know take this approach to an extreme. They omit reading the docs part.

they go straight into the code, read the code a couple of times, try to find simple bugs, then trying to find find complex ones. Okay? And as you go, you will start to notice, okay, there are some adjacent flows. Once you have finished with one, continue with the other. Tactic number two is something that I call derived by changed by diagram.

This is the part where it becomes a little bit technical. So we'll see some code. The best way to explain it is just to show a simple example. We have an equation total amount equals stake minus slashing. This doesn't come from a protocol.

It's just for an example. Right? So every variable in this equation can be modeled as being changed by something or being derived by something else. Let's see how this work for how this works for this equation. Staked the staked variable is changed by stake and withdraw functions.

The slashing is derived by slashed plus pending slash. So just on level one we can see some interactions and certain questions pop into our mind. For example, stake and withdraw seem like are touching the same state. Meaning they're probably the opposite. Maybe withdraw has to undo what staking has done minus fees and plus some profit.

So we have to check how these two functions interact. The slashing variable is derived by slash and pending slash. So the questions that pop into my mind first are is slashed and pending slash actually the same token? Are they the same scale? Because they might be different decimals.

Right? So even on level one there are certain questions that pop into our minds. Where this diagram starts to become really useful is once we go one level deeper all the terms from level one are also changed by or derived by something else. So withdraw and uh stake are influenced by are determined by this um uh amount this formula amount multiplied by by virtual stake factor. So immediately we think about okay how can I influence virtual stake factor and probably increase the stake amount or increase the withdrawal amount right same goes for how pending slash is derived the slash factor function might be influenced by some certain setting or whatn not where this type of diagram The DC diagram is very useful from my experience is wherever we have complex functions and wherever these functions are influenced by certain settings.

So it will be um this type of diagram will um it will pop up some certain information about uh this this formula the main formula that we're working on right and this is a very simple example in the real world it looks a bit like a mind map it will be something like this right and when when you go levels and levels deeper into it, you will start hitting public functions meaning okay these functions are actually callable. So, so it is very obvious how we can affect the equation that we are examining right now and eventually how can we like break it apart. That's that's the main thing that we do as auditors. We we want to break all this Okay, so tactic number three, focusing on the right bugs. This is especially important when you are started starting an audit in a new technology.

Imagine I noticed that some of you here are auditors. Imagine that you're starting your first Cosmos SDK. So fir first Cosmos SDK audit. So you learn about this great thing called the ABCI which allows Cosmos modules to speak to the to the consensus layer. So it brings a lot of complexity into the system and it's something new and shiny and we don't have this in the EVM.

So your first instinct might be okay uh let me go and see how this works how this works and all of a sudden you have spent like two or three four five days only on this part of the code. There are other parts of the Cosmos SDK like the interchain block communication protocol where it's a multi-chain tokens can go from one chain chain to another NFTTS can be transferred so very complex right and um time consuming to learn so here what's important is that we prioritize our time what are the parts of the protocol that will yield us most of the bugs. And here is a uh nice exercise for all of the auditors that can uh do do it at home. You can go back into all of your previous contests, contests and audits and try to categorize all of your bugs. I have placed all of this is these are my results.

I have placed all of them in three categories. So business logic, integration and crosschain. It's very obvious that the business logic bugs are the multitude of the uh the found issues in an audit. So in business logic I include rounding errors, I include accounting, I include protocol mechanics, um access control. So it doesn't matter what you audit on.

These are the parts of the code or or the Yeah, exactly the code that you need to focus on first. I'm not saying that the IBC doesn't contain any bugs. It probably does. Probably does. But you have to prioritize and start with the thing that that's most important.

In this diagram, the integration is 90% and there I include year C20 token standards and integration with other protocols and crosschain bugs are only 4%. Even though crosschain bugs are very interesting, very devastating when they happen, they don't pop up as often. It's just the the nature of u the protocols that I have holded at least. Okay. So if you enjoyed this talk, you like the topics and you would like to participate in discussions similar to this one.

I am organizing a weekly meeting for auditing professionals. You can find me on X, drop me a message and I can tell you how you can participate. We share various bugs, findings, we discuss um we discuss hacks, exploits and everything related to the auditing profession.

Thank you. [Applause] Heat. [Music]