Interview with samczsun
If you keep up with Ethereum security-related postings, you’ve no doubt heard of @samczsun: security researcher and white hat extraordinaire. Last year, he discovered significant vulnerabilities in the 0x v2 Exchange and the Livepeer protocol. Within the Ethereum security community, he’s known for being an unusually prolific finder-of-bugs. Just in the last week, he found a critical vulnerability in the Curve.fi Curve contract as well as a bug in the ENS Registry contract.
Last week, I had the opportunity to pick his brain and find out how he does what he does:
Do you work mostly on Ethereum?
There’s more for me to do in Ethereum.
The rest of the security field is so developed, it’s definitely a bit easier to find stuff in Ethereum since there’s not a lot of coverage.
How much time do you spend on Ethereum-related work per week?
That really fluctuates. These days, activity has kind of died down. Mid-2017 there was like a new project every week so there was a lot of material to go through… it’s just a lot more quiet nowadays. So, usually a couple hours in a week, sometimes double digits if I feel like I’m onto something, but that’s really pushing it.
Does having public bytecode contribute to a more secure ecosystem?
Not being able to obfuscate your code makes it easier to find bugs, and having the general attitude that “you should present your source code” also makes it easier.
It means you get to eliminate a lot of the easy stuff like integer overflow right away because people are constantly searching for it. So any bugs you find are more of the “subtle” variety.
I think in general it makes things better. There was a bug found in Windows 10 that allowed attackers to spoof certificates by passing in custom eliptic curve parameters (ref). If the source code was public, someone would have found it years back. Since it wasn’t, it took the NSA (with their much larger budget) to find it.
Do you use any tools to assist your search?
I think in the grand scheme of things tooling is important. Outside of Ethereum, it is very important.
Within Ethereum, it’s fortunate that contracts can only get so large before the EVM won’t support it. As such, I haven’t found the need to rely on tooling yet. I think it’s also because I don’t need to look through 100% of the code, whereas during an audit - you have to.
As an auditor, you really have to pay attention to everything - maintain state on everything, whereas I can kinda breeze through until I’m no longer interested.
How do you find potential targets?
If someone mentions a project to me directly or in a group chat, I’ll keep it in mind.
Occasionally I browse the ethereum subreddit.
And if a project announces “we just launched!” - I’m like, “cool, let’s see if you’re completely broken!”
When I’m bored and/or procrastinating, I’ll flip through transactions on Etherscan - like, “This looks like an interesting target that it’s going to, I wonder…”
That’s kinda how I found the 0x bug in the first place.
You found the 0x bug looking through transactions on Etherscan?
It was their Wrapped Ether contract, which stored a bunch of ETH. I was like, “This looks like a critical piece of infrastructure.” And then I traced that to 0x.
Basically, “this is active” and “this is holding money,” so this must be important.
But the Wrapped Ether contract didn’t have anything to do with the contract that contained the bug!
Right, it’s kinda like a search algorithm - like how you can visualize it branching out. So you start at the Wrapped Ether contract and find that, “Oh, nothing’s broken here, but if you were the owner, you could withdraw a lot of money.”
So, who’s the owner? Oh, it’s these asset proxies (for example). And these asset proxies are pretty simple, but they allow this exchange to call into it - and what does this exchange do? And at that point, I was like, “Oh - this is 0x!”
It’s interesting - through this process of asynchronously picking up things to look at, you end up visiting the same contracts a lot of times. So by the time I really looked into 0x, I had already gone through it 2 or 3 times. I guess n-th time’s the charm.
Do bug bounties entice you to look at code?
Bug bounties are nice. I’ve come to accept that they’re not a guarantee, and even if they have one it’s not going to be as dazzling as 0x.
Because of that I think sometimes I might adjust how much time I spend looking at something. Just, knowing that there might not be (from a purely monetary point of view) a great return on this time investment.
As someone who has participated in a lot of bug bounties, would you say that they work well, or could they be done better?
It works. It’s definitely appreciated if a bug bounty exists. Not sure what could be done to make it more effective.
The target market for a bug bounty is so small that I’m not really sure what you could do to optimize for the people that are interested.
Any advice for projects looking to post a bug bounty? What information are you interested in?
In terms of useful information, scope is definitely good to know. Whether the project is live or not, links to the contracts on Etherscan. Hopefully you’ve verified your contracts on Etherscan, otherwise I have to assume that you haven’t changed your code on GitHub since deployment.
Other than that, some way to contact you would be great.
The payment or bounty is also good to know. If you say “up to $X,” I’m assuming that you’ll consider the higher end of that range for critical vulnerabilities.
Sometimes projects will say, “Thanks so much for finding this, we’re aware that it’s really severe but we just don’t have the funding to match what we’d like to provide.” And in that case it’s totally reasonable, but just make sure to mention that.
Realistically, how well a bounty is funded is going to be a consideration for these things. The alternative is that someone finds it in the wild and doesn’t want to go through the bounty system.
Yeah. I think in general, you should look at what other projects are offering and scale your bounty proportionally to theirs, according to how much is at risk.
That’s where I think 0x did a really good job. They recognized that with the amount of money at risk, they wanted to offer a suitably high compensation in exchange so that you’re incentivized not to go “do the bad thing” instead.
If you offer only $1,000 - $5,000 for a bug that nets $1,000,000 - $5,000,000, some people might decide it’s worth exploiting that bug themselves or even selling it to someone for more than the bounty.
Let’s talk about Livepeer - how did you find that? It’s a large codebase, did you go through all of it?
I skimmed through all of it.
I think I saw one of their blog posts on /r/ethereum, maybe one of their weekly calls or something. I thought, “That’s an interesting project.” They posted about it, so at the very least it was brought to my attention.
Where did you start?
My approach for Ethereum contracts (I don’t recommend doing this in general) is I either start from where the money flows out (because realistically, that’s what you care about), or I start from some of the more core functions (where something could be catastrophic if it didn’t do what was expected).
In both cases, start from there, work your way out, ask “What preconditions do I need to meet in order to reach that point of code.” Like, where the money flows out - “How do I make it to this part that transfers Ether to me?”
With utility functions, “This thing’s broken: where is it used, and how can I manipulate the inputs so that I get a result that the developers weren’t expecting?”
Which part in Livepeer caught your eye?
In Livepeer, I see the “slashing” part and that’s like… impactful to people. At the time I didn’t think an attacker necessarily made a profit from slashing (it turns out they do), but it’s impactful, so what causes it? What preconditions do I need to meet in order to slash someone?
And then it turns out, one of the preconditions didn’t exist - the precondition that your inputs had to be unique.
I originally got to know samczsun as the mysterious hacker crushing every challenge I laid out in an old CTF series I ran in 2018. When I first reached out to him, I assumed he was associated with one of the other Ethereum security firms. As it turns out, he’s completely independent - just some curious, talented security nerd.
If you’re interested in learning more, here’s a list of all his (public) Ethereum-related findings to date:
- July, 2019:
- 0x V2 Exchange: (0x disclosure | 0x post-mortem | Diligence post-mortem | Sam’s writeup)
- Livepeer stake slashing: (Livepeer disclosure | Livepeer post-mortem | Sam’s writeup)
- September, 2019:
- DDEX and bZx exchange price manipulation: (DDEX disclosure | bZx disclosure | Sam’s writeup)
- October, 2019:
- Cheeze Wizards: Unpasteurized
- January, 2020:
- Curve Finance vulnerability
- ENS Registry contracts
Thanks to @samczsun for participating!
Thinking about smart contract security? We can provide training, ongoing advice, and smart contract auditing. Contact us.