AMA with Riley Holterhus Recap

On the 14th of December 2022, Unbound Finance hosted an Ask Me Anything (AMA) session with independent security researcher Riley Holterhus. He is a well-known figure in the world of Web 3 security, having previously worked with Paradigm, SpearBitDao and code4rena. Riley has a reputation for discovering security vulnerabilities and helping organizations recover stolen funds. He is also the first to conduct an audit for the Unbound V2 smart contracts.

During the AMA, Riley discussed the results of his recent Unbound V2 security audit and Web 3 security. Below is a recap of the insightful AMA.

Q1) Riley, please introduce yourself, and tell us about your background and journey as a blockchain security auditor.

Hi everyone; I am Riley Holterhus. I have been in the smart contract security space for over a year. I got into space last October after hearing about an exploit that happened on a protocol. I instantly started to learn about the different opportunities that exist in the space and started working with Code Arena. It is a website where you can participate in decentralised audits and get paid based on the severity of bugs you find. Then I started to explore unified bug bounty hunting. Then I started doing independent audits and eventually worked at Paradigm in their security team. And then since then begin, in September started working more independently again. So I’ve done more independent auditing, which is where I am today.

Q2) Blockchain as a technology is known to be inherently secure, then what makes it so vulnerable?

There are two different aspects that people could be talking about when they refer to blockchain security. So one aspect is the actual blockchain itself. So, for example, back in September, we all know that Ethereum transitioned from PoW to PoS. And these are different senses mechanisms that have their security guarantees. These are things that are inherent to the blockchain itself. But at the same time, code lives on the blockchain. The problem is that there could be bugs in that code itself, and the blockchain’s security guarantees will help you with those bugs.

Bugs in the smart contract code itself are what the problem is. And because the space is new and Solidity as a programming language is relatively new, and the whole space is less than ten years old. That’s one aspect of why there are so many problems and whether problems happened in the past.

Q3) What is your approach to security Audits in web3?

There are lots of good tools that people use. The one that I like to use or just like that general class of approach is fuzzing, where you can provide the functions that would cause it to break and automatically go through different inputs and try to see if it would break. This function is the most automated tool that I use.

Other than that, I’m still traditional; I look at it like I like to just look through the code manually and try to find bugs that way. I still primarily rely on that because although there are lots of new tools and new things, I don’t think anyone expects them to catch everything. It’s still important to look through the code and use code that deeply. The automated tools are really good, like the first step. Tools help find very low-hanging fruit that is easy to catch. Even though they’re low hanging, they could cause problems if they weren’t caught at all. I mostly like to do auto-manual stuff, but different things like fuzzing and other promising areas are the formal verification area of research.

Q4) What kind of vulnerabilities/ attacks are most common in dapps?

One of the common bugs back in the day was re-entrancy. You can re-enter the contract, and maybe the state wasn’t updated so you can exploit that. This was a big problem, leading Ethereum to transition from the classic mainnet to the mainnet. There was a reentrancy bug in the DAO.

Oracle attacks primarily using flash loans. It is easier to manipulate the price of an asset in DeFi in spot trades. Exotic bugs can’t be classified into one category. But re-entrancy and flash loans are essential.

Q5) Can you share some findings you are proud of in your auditing journey so far?

I was once working with a protocol trying to find bugs with them & found an interesting bug I didn’t realise there was. It was a bug where users had to collateralise a position, and every user had a debt. Eventually, that debt was reduced over time because of the yield they got in the position; ultimately, they were supposed to have credit. But the problem was that their credit was always set to the like to the difference. So, if they made $10 of credit since the last time the function was called, instead of adding 10 to the credit, it would just set their credit to 10, which is an issue. I was surprised that no one had caught it before because it was a fork of a much bigger protocol. So the reason I was pretty proud of this one is that I was able to submit the bug to like 45 different forks of this protocol and also able to use it in a Code Arena contest that still hadn’t realised that there was this bug.

Then I realised that this smart contract security space is relatively new because I came in and realised that this problem and I was still relatively new. There are a lot of opportunities to find these things. The other time I found a bug in the most prominent name protocol. It was a bug where someone could steal money from their periphery system. But the bug was simple. It was just you create a promotion, and then you don’t actually pay it, and then you get all your money back times two. And obviously, like it’s such a big problem, but it wasn’t super technical.

Q6) You recently completed the Unbound V2 smart contracts security audit. What are your thoughts?

It was fun to look through the Unbound contracts. All the bugs have been fixed, so to the best of my knowledge, there aren’t any bugs.

There was a common vulnerability that had happened before that Unbound was aware of. It’s related to the LP token pricing. The naive solution for doing this is to use the arithmetic mean of the token prices of the LP position. So, if your LP position is between ETH and USDC, it makes sense to take the amount of USDC and the amount of ETH in the pool and then take your proportion of that. Then someone can just manually send one token to your protocol and cause it to revert.

Some protocols might think this is never an issue because you can’t possibly send ETH to some contracts that don’t have a payable function or like receive function. But there are other ways to get around this way; you can, like, manually send ether smart contracts, and it’s even easier if you just.

Another issue is to ensure that the yield farming rewards allocation is fair. So if someone deposits some collateral and that collateral is used in a yield farm.

It should always be the case that they get their proportion of the rewards. So if you deposit like $1000 and then you eventually acquire like $100 worth of rewards, and then someone else like afterwards rewards someone else deposits, they should never get access to those $100 of rewards that you generated alone with your collateral. And there was a slight change in the code that needed to be made for that to happen.

But now, obviously, the Unbound V2 code has that modified. So the rewards should be fairer.

Q7) What are the to-dos in Do Your Own Research to avoid risks in DeFi?

Firstly, many protocols don’t even do audits at all, and I think that’s a pretty big red flag. Another thing is whether or not the protocol had a bug bounty. I think it’s a pretty good signal of if they care about security.

The second thing to check is how much centralization the protocol has or if they have plans to move away from that centralization. No protocol should be extremely central or centralised in that it can take everyone’s money, which has been a problem before. People usually call them rug pulls, where someone can easily just take all the tokens from the particle for their own and never give them back. That’s a bad thing.

Another thing, I guess, is related to the audit point if the protocol is a fork of another protocol. I think it’s almost as if like the security guarantees of the other protocol are inherited. So keeping in mind which fork each protocol is of each other might be something to keep in mind just to ensure that if a bug happens in the protocol, then that protocol fork or downstream is another protocol. Keep in mind that there could be bugs in both of them. Those are some DYOR things I would keep in mind when interacting with DeFi protocols.

Q8) In terms of security, how does Web 3 differ from Web 2?

Starting by one thing is that this space is very new, which is one part of why Web 3 security is so different. There are more people expect in bugs because Solidity has only been around for six years, which is not very long. As a result, people are still getting used to these new programming paradigms.

One other thing I would say that is different from Web 2 security is that if there’s a bug in the code, it’s a lot less likely to steal money directly. Another thing is that Web 3 has a lower barrier to entry where anyone can have their private key and then send transactions on the blockchain, which is relatively easy. But this barrier to entry also benefits hackers as well. So if you’re a hacker, you can make a new address, fund it with tornado cash and steal the money. You can send it back through tornado cash. So it’s easy to like lose the trail if you do. Getting away with the crime will be more challenging if you steal the money.

And one other thing is in Web 3, it’s more expected that the code is open-sourced and that you can read it. For instance, on Etherscan, they can verify smart contracts. So in Web 3, it’s a lot easier to get access to the source code to see if there are bugs in particular not working; you might need access to the source code in absolute, like decompiling yourself.

And one final thing is that in Web 3, even if you find a bug before any person finds it, it’s not even obvious to fix it. One of the problems in Web 3 is the code is expected to be immutable. So if you find a bug only way to fix the bug is to exploit it yourself, known as White hat hacking. It is kind of a crazy concept, but it started where we are, and that’s another difference between Web 3 and Web 2.

Q9) Community audits are getting popular nowadays. What are your thoughts on it? Would you recommend projects to go for community audits?

I think community audits are really good, but they have pros and cons.

Well, first of all, my anecdote is there were a couple of times was a community audit went head to head with other auditing firms and most of the time, I think all the time, and I’m mostly just talking about Code Arena. That’s the main community audit platform.

But usually, the community audit incentives have been much more significant. One example in thinking of his Open Sea had a contest where $1,000,000 was rewarded for a high-severity bug.

And although several other auditing companies have already looked at the Seaport code, some high severity bug was identified. So this is one anecdote on how a Community audit can be better just because the incentives are aligned differently.

But that being said, I think one con to the Community approach is that the review for the mitigations that are found, the medications for the bug that are found in the contest or not reviewed very closely; this sort of the nature of competition works. There’s a week period where people look for bugs, and then you can’t fix the bugs as they are submitting them because everyone should have a chance to submit them throughout the entire week.

So as a result, sometimes the protocol has gone through a Coat Arena on it, and they find lots of bugs, which is great. But they make some mitigations to the protocol, and as a result, there could be new bugs that are introduced that have yet to be like that for the audit.

And this is usually addressed in a traditional security audit, where they look through the mitigations and ensure that everything is implemented correctly. That’s the biggest con to the approach, and I used to keep this in mind and look through some of the Code Arena reports and see if any of the bugs were incorrect. To ensure that their mitigation was implemented correctly and more than once, the protocol has to do more high-severity findings in the mitigations review than in the original review.

About Unbound Finance
Unbound Finance is a novel, non-custodial lending platform driven towards enabling newer and better opportunities of yield to improve the overall capital efficiency of the DeFi ecosystem. The platform enables Defi users to borrow over-collateralized synthetic asset loans in the form of UND stablecoin by collateralizing liquidity pool tokens (LP tokens) and concentrated liquidity positions of next-gen AMMs such as Uniswap v3. Through synthetic assets like UND stablecoin, Unbound aims to unlock the liquidity available in DeFi DEXs and to enable the easy flow of this liquidity from one chain to another without actually removing it.

The key highlights of the protocol are as follows:

• Interest-free borrowing: Unbound does not charge any interest on the borrowed UND.
• Perpetual borrowing: At Unbound, borrowers have unlimited maturities. Users can unlock the underlying collateral at any time by simply paying off the outstanding debt.
• Stablecoin UND: UND is the first flagship product of the Unbound protocol. It is a decentralized, cross-chain stablecoin designed to be native to the AMM space.
• Factory Smart Contracts: Unbound uses liquidity lock contracts that are permissionless and support EVM-based AMMs like Uniswap, Balancer, Curve, SushiSwap and the like.
• Collateralizing concentrated liquidity positions: Unbound is one of the first protocols that allows concentrated liquidity positions to be used as collateral for borrowing synthetic crypto assets such as UND stablecoin.

Stay Tuned

Website | Twitter | Unbound V2 Whitepaper | V2 Testnet | Telegram | Medium |Telegram Announcement Channel | Lens