The Hacker Mind Podcast: Hacking Ethereum Smart Contracts

How do you stop a half billion dollars in cryptocurrency from being stolen? You perform software testing and responsibly disclose it first, of course.

Yannis Smaragdakis, a researcher with Dedaub, found a major vulnerability in Ethereum smart contracts, arguably within the billion-dollar range, that would have made it one of the largest hacks ever—given that it was a theoretically unbounded threat -- had it not been mostly mitigated by the time it went public.  In this episode he steps us through how he discovered it and other vulnerabilities in Ethereum. 

The Hacker Mind is available on all podcast platforms.

[Heads Up: This transcription was autogenerated, so there may be errors.]

‍

Vamosi: Meter is a multi-blockchain company that allows you to trade across Ethereum to other public chains. There are a lot of public chains, and there are alot of cryptocurrencies. And, bridging across cryptocurrencies, that sometimes exposes a lot of vulnerabilities.

In early February Meter announced on Twitter that it had been exploited for around $4.4 million dollars. Exploited, not hacked, per se. Basically someone was able to leverage a vulnerability of Meter to mint a large amount of BNB -- a coin from Binance exchange-- and WETH -- which is wrapped Ethereum. By minting their own, they depleted Meter’s reserves for those currencies.  In other words, these cryptocurrencies were essentially stolen.

And Meter wasn’t the only company attacked.  In January there was the Wormhole network, a token bridge that allows users to trade multiple cryptocurrencies across the Ethereum and Solana blockchains, reported losses of $321 million US Dollars. And before, there was an attack at Qubit Finance, which also runs on the Binance Smart Chain. They were attacked for around $80 million US Dollars. All within the first two months of 2022.

These losses are huge. And they point to the inherent risk in any new financial vehicles. Again, this episode is not about whether or not to invest in cryptocurrency. Rather this episode talks specifically about how vulnerabilities that are coming to light within Ethereum Smart Contracts, among other cryptocurrencies.

 And in a moment we're going to learn about the greatest attack against Ethereum smart contracts, one that never happened. It never happened because a researcher found and responsibility reported it.

[music]

Welcome to The Hacker Mind, an original podcast from ForAllSecure.  I’m Robert Vamosi and in this episode I’m continuing my discussion of crypto--by which I mean cryptocurrencies -- by specifically the Phantom Function vulnerability in Smart Contracts, and how this vulnerability could have lead to the largest hack against cryptocurrencies had it not been found and fixed first. 

[music]

Vamosi: In a previous episode --episode 39 -- I talked with researcher Guido Vranken about fuzzing cryptographic libraries and also his work fuzzing cryptocurrencies. That episode provides some background and context for what I’m going to talk about here in episode 40. It’s not necessary for you to listen to that episode before this, but if you haven’t heard it, and if you’re new to cryptocurrency, you might want to check out episode 39 on fuzzing crypto first. 

At the end of January 2022, researchers disclosed they’d found vulnerability in a service built around Router Protocol. Just as the use of the word Crypto is confusing here -- is it cryptography or is it cryptocurrency? And same with smart contract -- it’s not really a contract, a program included in a blockchain. Here, to the use of the word router here is also not part of your internet gateway but simply a route to get from one currency, say Bitcoin, to another.  A router. 

Fortunately the company involved, Multichain, fixed the vulnerability so it can’t happen again.  But what’s kind of cool I my opinion about using blockchain is that the proof of concept used to demonstrate the vulnerability is still available within the blockchain.  Remember blockchains are immutable. That means the researcher can pull it out and demonstrate it. And that researcher is ….

Smaragdakis: Yanis Smaragdakis, and my professor and co-founder of Dedaub, which is a security company specializing especially in blockchain security, in Ethereum, smart contracts and blockchain smart contracts.

Vamosi:  Yannis has this company, Dedaub, that is focused on cryptocurrency vulnerabilities. And he’s been pretty successful in finding vulnerabilities.

Smaragdakis: I'm an academic by training, so I've been a professor for the past 22 years now. And we started this company DeDaub, to try to apply some of our program analysis tools to real world problems, and particularly in the blockchain space in smart contracts as the programs are called, that are deployed autonomously. On the blockchain. This is a fantastic domain for application of automatic tools and I can explain why in a second, but primarily we have d dub, applying static analysis technology over smart contracts over programs that run autonomously on the blockchain.

Vamosi: There are a lot of new words and terms being used here. So, with that in mind, let’s back up.  What is a blockchain?

Smaragdakis:  Blockchain is a distributed ledger, which means just like you have a ledger at your local county or, or town that keeps track of, say, real estate, assets, houses, plots of land, everything. The idea of the blockchain is that we can keep a ledger like that for all sorts of valuables. And the big unique feature of the blockchain is that nobody actually holds this ledger. It's not in a building. It's not in a computer somewhere. It's actually distributed among many, many people. In the particular case of the Ethereum blockchain. It's a little over 10,000 different participants in the network, I think, and they collaboratively build the next version of what this chain contains. Now with Bitcoin, especially people have heard a lot about what the blockchain is, how this works, how you can have a ledger, you can have a long list of transactions that no single person ever holds on their own, that we hold collaboratively. We all have copies and the copies are all consistent. 

Vamosi: So all of the cryptocurrencies are, at a fundamental level, blockchains.  And you can have blockchains for purposes other than currency. Whether it is bitcoin or ethereum. At the end of the day the cryptocurrencies are all block chains. It’s the code on top and the features within that code that makes them different. 

Smaragdakis:  all of these are blockchains. So Bitcoin is one blockchain. Ethereum is another blockchain that looks very much like Bitcoin. But it has added to Bitcoin smart contracts. It adds arbitrary program execution to Bitcoin, and it has very different technology, and especially in a few months, it's going to be entirely different technology underneath as a blockchain. 

Vamosi: So, for example, Ethereum has its own blockchain and Ethereum has its own features built into it, making it distinct from Bitcoin.

Smaragdakis:  So Ethereum and Bitcoin are completely separate blockchains but Ethereum because it's programmable because it allows you to deploy contracts. It has created a whole ecosystem where many, many other cryptocurrencies services financial services, banking like organizations, they operate on top of a theorem blockchain Okay, so it is a blockchain but because it's programmable, it's multifaceted and lots of functionalities being built on top of it.

Vamosi: So what, then, is the smart contract component?

Smaragdakis:  So let's start with let's start. Once they're back with smart contracts, smart contracts are basically problems. So when you hear smart contracts, that's a name for a particular class of computer programs. It's not contracts, it's much closer to arbitrary programs in any other setting, that is to the kind of contract that you sign at the notary or with a lawyer or whatever. So smart contracts are programs. They are programs that live autonomously on the blockchain. So the blockchain has this long list of transactions, it actually can include program deployment, smart contract deployment and smart contract execution. So I can just say my next transaction will be to deploy for everyone who's keeping this long list. of transactions to deploy the following code. And that code will now live in an address and anyone can call it and it can manage my money, it can manage my accounts, it can manage some logic that I want to put out in the world. So for instance, it can be well, something very simple, which is not actually realistic could be it's a betting shop. I'm going out there and I say I will write a contract and people can call it to place bets, and we'll find out who the winner is. And they will get money for various reasons that don't turn out to be realistic, but it's a good intuitive understanding of how a contract can be operating out there, making me some profit, and at the same time, it's handling money. Now, one of the major uses of contracts is to implement tokens to implement currency, or something that's like currency that reflects some other value. But the logic of how you print this currency, how you make money, or the logic of how you transfer it that's implemented inside the smart contract inside that computer program. 

Vamosi: So you have money, a cryptocurrency. How do you negotiate it with other cryptocurrency. That’s handled by these program, these smart contracts.

Smaragdakis: So for instance, again, not entirely accurate, but I could give a simplifying example, I could say I want to print some of my own Monopoly money, or the game I'm playing with my friends, but it is a real world game. So anyone who has this money, that real world convention will be that they're entitled to something from me. They're entitled to some services, whatever, some time on my podcast or something. I don't know what those services could be. Now, I may have computer code, I may have a smart contract that determines how new tokens get issued, and then what it means for someone to transfer their tokens to someone else, transfer their money of this particular kind that I'm printing to someone else, because they're their only two or three functions of money. You print it, you destroy it, and then you transfer it pretty much. Indirectly the transfer may also include an approval for someone else to spend your money, but primarily, money is printed and it gets transferred to someone and that someone can transfer it to someone else. If anything else needs to happen during that transfer that needs to be encoded in that computer program because the ledger that actually says that right now Yanis has this money or Rob has this money, that's the blockchain. So the program has to keep track of who has the money and who has transferred what to whom.

Vamosi: I should mention that one example of a non-currency use of digital ledger or blockchain is a NFT or non-fungible token. NFTs are immutable units of data stored on a blockchain that can be sold and traded, with all transactions visible to all parties.

Smaragdakis:  So and if these vast majority they are implemented as smart contracts on Ethereum, yes. Okay.

[music]

Vamosi: As we established, Ethereum is distinct from Bitcoin and several other cryptocurrencies. One of things that differentiates it is Solidity, an object-oriented programming language for writing smart contracts. Solidity programs -- smart contracts -- are intended to be run on the Ethereum Virtual Machine. Most cryptocurrencies run within virtual machines. So how do you go about finding vulnerabilities in Ethereum?

Smaragdakis: Yes, so, so, here's why the Ethereum blockchain is an ideal playground for a program analysis researcher. We have all sorts of problems, hundreds of 1000s of different programs, all these smart contracts that are deployed out there. I can look at them I have their binary code. Most of the time I have their source code. I have all their past executions, all their back inputs and internal processing and output is encoded on the blockchain and their current state, like what is on their heap, so to speak, which is called storage in here. That current state that every time I call this contract, we will consult like who has this balance is going to be there. So you have this computer that you can completely crack open and inspect. It runs more than half a million different programs, actually many millions but there are copies of more than half a million original code bases that are deployed by many, many 1000s of people, and they handle real money. So it's an ideal application for program analysis because I can go in and I have everything I may need to do program analysis. I have the code I have the input data, I have the state and at the same time, I have lots of people who really care that this thing runs correctly, because it handles real money. So I can get pretty deep results. And those results will be actionable they will be they will have real world impact right away. So that's what attracts program analysis researchers to the blockchain.

Vamosi:   In episode 39 we focused on fuzzing. Here, Yannis uses program analysis which includes static analysis.

Smaragdakis: Yes, well, nothing, no good analysis is entirely static. I mean, there cannot be an analysis, good analysis of problems that just looks at the code. You always need to take into account what you see in the code together with the current state. So the code may be perfectly fine under some assumptions about what's the current state of the computation, but under different assumptions, it could be entirely not fine. So, in practice, good program analysis needs to combine something static, static meaning from the code understanding from the code that I can understand without checking what happens when you run the program, and something dynamic, some information that says this is the current state.

 Vamosi: And so it's through this program analysis that you found the Phantom function.

Smaragdakis:  So Well, yes and no. So this is why we found this major vulnerability recently, and it was originally flagged by static analysis, but I don't want to claim that static analysis really found the essence of the problem. Eight had just given us a bunch of warnings, and just randomly inspected these warnings. I had the realization that there could be a really, really sneaky bug in some code that people have not really expressed before. There could be a new attack vector that people have not really thought very much about. But I cannot really say that it was a static analysis that found it, although I wouldn't have inspected the code if it wasn't flagged by the static analysis, especially for this particular nobility. I cannot really say it was found by our static analysis.

Vamosi: So the Phantom Function vulnerabilities are subtle. They rely on token and its implicit use of permits. In other words, you can allow certain transactions to proceed without being notified each and every time they are called.

Smaragdakis:  Yes. So this so this one, our ability, the attack vector rather, the essence of it is the following. You have tokens, in the standard of cryptocurrencies that are implemented as programs on top of Ethereum you have two ways to approve someone to spend your money. You can either say I allow Rob to spend $200 From my balance, and that's that traditional approved way. Or you can say, I will sign an off-chain off the blockchain permission, that with my cryptographic signature, anyone who takes us can know that I signed this particular authorization and my authorization could say, I allow Rob to spend this much money by this time. That's the typical pattern. allow someone to spend this month by that time. 

Vamosi: So when this is working properly, it works. But what happens when it doesn’t work. When, for example, it is not expressly defined as a yes or no?

Smaragdakis: So most tokens include most kinds of cryptocurrencies that support the standard interface for default defining derivative cryptocurrencies or Ethereum. Support the first kind of approval, just a straightforward approval, but many of the more advanced cryptocurrencies support both the vulnerability and the attack vector that we discovered goes like this. There is a class of cryptocurrencies of tokens of problems of smart contracts on Ethereum. That even though they're not designed to accept those off chain signatures, those permissions when they are given such a permission, they just silently ignore it. And this sounds a little strange, like why would they silently ignore it? And this has to do with the semantics of the solidity language that's used for expressing smart contracts and as it happens, solidity, especially in older versions, encourages the use of what's called the fallback function, which is a function that will catch any function invocation that is not masked.  

Vamosi: The solidity fallback function is executed if none of the other functions match the function identifier or no data was provided with the function call. Only one unnamed function can be assigned to a contract and it is executed whenever the contract receives plain Ether without any data

Smaragdakis: So if I, if I call a function on a problem, and I have not defined that function but I have defined the fallback function, the execution will go to the fallback function, that's the one that's going to end up being called. Now, for various legacy reasons, many major currencies defined a fallback function and in this way, even though they didn't support permits, they didn't support accepting those off chain signatures. When they would get them. What would get executed was the code of that fallback function, and that code would just silently not do anything, but also not complain that it got these permissions that it didn't know what to do about. So that's effectively taking a call that should be a message not found method not found to call, revert the transaction and turning it, turning it silently into an hour, just not doing anything, which normally would not be a problem. The problem is when you have functionality that expects those permissions to authorize someone else to be spending your money, like I signed that Rob can spend my money. And at the same time, I'm using the traditional way of doing approvals, and I have given that program approval to spend my money because I expect that it doesn't spend my money only when I call it. 

Vamosi: In other words, it appears as though the program is operating as it was supposed to, except in this case it can be misused.

Smaragdakis:  Now suddenly, I can call the program through the entry point that say,s well, check the permission. Yanis has given me authorization to spend his money. Look at the permission I go through that code that checks the permission certificate that supposedly I have signed off chain, it doesn't do anything. It doesn't complain that the token, the actual cryptocurrency, does not support permission certificates. Okay, fine. And then it goes and tries to transfer money from Yanis to the contract. But Yanis has actually happened to authorize the contract in the past, because they have called it because they have used the other path the approved path they have interacted with a contract they know that when I call it it's safe to say contract, you are allowed to spend my money.

Vamosi: how might a malicious actor take advantage of this?

Smaragdakis:  So it's actually very easy. This attack vector is very easy. It's just sneaky because nobody expects this to be there. As the malicious actor, all I have to do is say, call that program function, the contract function that allows me to spend Rob's money. And what I want you to do is to take Rob's money and not give it to me directly. Just keep it in the contract. And that program path should revert. Whenever it's not given proper permission from you. The program paths should not go through but for some kinds of cryptocurrencies it just silently went through with no objection and he did not do anything. So I as an attacker come in and I say, look, Rob has signed the certificate that says that you are allowed to transfer Rob's money to the contract. On behalf of me though, because I'm the color of the contract, texted permission and said, Okay, well, let me share let me make sure that Rob has given this permission. That particular permit call ends up being a no-op for that particular cryptocurrency so it doesn't do anything it just silently ignores without failing. And the program after that does not know that. The permission is not because of the certificate, but it's because Rob in the past, has given the contract permission to do something with his money. Because Rob did useful work with that contract. And now it just goes and uses this past approval and moves the money into the contract. And now the money got deposited into the contract as if it's meant for me, the attacker and on the next transaction, I can go and withdraw it.

[Music]

Vamosi: Maybe we need to  understand the fallback function more. Are these put there by a malicious actor or these are just precedent; these are things that happened in the past and therefore no action is taken.

Smaragdakis:  Now the fallback function is just something that exists in the code of the contract for many contracts, and it's just a catch all function. It's what will be called if nothing else can be called. And in this particular case, you have a program that represents a currency as a token. And it does not support the permit functionality. So what happens instead is that the fallback functionalities get called now for 99% of contracts out there, the fallback functionality just says I didn't find a matching method, reverted transaction. But for some very important kinds of cryptocurrencies that fallback functionality, it will silently not fail if it gets called. So if I submit a certificate, there is no certificate approval function. It will go into the fallback which is the default function for the contract, and it will not fail.

Vamosi: There are other currencies built on Ethereum. Can you give examples of a few that might be relevant here.

Smaragdakis:  So in the most relevant for this particular vulnerability that we're discussing now, is is just what's called the rap, ether, or with and that's their rap version of the native cryptocurrency of Ethereum, which is ether. So it's a technicality that you have the native cryptocurrency of the blockchain, the one that's being used when you want to interact with the blockchain, the one that's being used when you participate in growing the team, but then you need to treat that as a derivative token as well as a token, just like any other of the hundreds or 1000s of tokens that run on Ethereum. So in order to have a unified functionality like a bank, very often you need to treat all tokens the same through the same API. And that's the need that the Web Token addresses. It also makes the native cryptocurrency ether make it look like a derivative token. A token that has a smart contract in order for its logic to execute. So that's the one that had the major vulnerability that we identified.

Vamosi: Not only is the fallback function important here, but so is its use of permits. In particular, what’s been permitted in the past can be exploited through the fallback function.

Smaragdakis:  So the permit function is, is a modern way and very convenient way to get approvals for someone else. To spend your money to give approval for someone else to spend your money. So advanced functionality that deals with tokens on Ethereum is likely to use permit and permit again, doesn't do anything special. It just says I have this kind of token in my hands. And someone passes me a certificate. And I will ask the token, might this certificate mean that this person has approved that other person to spend their money? And if the token says yes, well, go ahead and try what you are going to do next. And the idea is that the token doesn't just say yes, the token also internally says, Oh, yes, that certificate tells me that Rob has authorized Yanis to spend their money. I will keep a note of that authorization. So the next action of any color will be Oh, now that I submitted the certificate. Now I will do the actual movement of money because the contract knows about that permission. 

Vamosi: That’s how it is supposed to work. But it doesn’t always work that way. 

Smaragdakis:  In this particular case, the first step, the permit ended up being a no up. It did nothing but it did not fail. Crucially, it did not fail. It silently succeeded without doing anything. The second step should fail. Because now that there's no permission in there, why is Yannis allowed to spend Rob's money, but the attack vector actually took advantage of past permissions? That Rob had given not to Uranus specifically, but to the contract itself to take Rob's money and temporary investment. So that attack takes advantage of the first safeguard, being a node and the second part which should not normally work, without the first part does work, because there's a different path that gives a different kind of authorization for spending someone's money.

 Vamosi: So, we said earlier this was subtle. And just looking at the code doesn’t necessarily reveal the flaw. That said, what can developers in the Ethereum community learn from this?

Smaragdakis: The developer community in Ethereum should know this attack vector because they use permit a lot. And they need to be sure that they have taken into account that even though for 99% of tokens out there, the permit will behave just as you expect or it will fail completely. Or if you give it the right signature. It will keep track of that permission inside the token for one out of 100 tokens, and this one turns out to be the most important one, which is ether, but in rapt form, for the most important token in the theorem ecosystem. You have permission not to do what you might expect, if you call it with any kind of signature. Of course, it will do nothing; it will not register permissions because the code of the token has not foreseen any such functionality, but at the same time, it will not reject the transaction. It will not say Oh, this is an invalid signature, it will just happily go through and do nothing. And if the rest of your logic is not behaving correctly, with respect to that do nothing, then you have a problem.

Vamosi:  So Yannis and his team found this vulnerability. They did reach out to Ethereum for normal vulnerability disclosure, but they also lucked out by knowing someone at one of the affected companies that used smart contracts.

Smaragdakis:  There's a company that runs some smart contracts, and they are the ones that had this vulnerability. That vulnerability actually happened to also exist in five or six other code bases. But the code base of that particular company is the one that had major exposure to this bug. So I mean, I can go through with it with the rest of your question. The disclosure procedure perhaps,  So what really happens with vulnerability disclosures in Ethereum, and this, this now is a habit for us because we've had eight or nine vulnerability disclosures in publicly deploying code in the past year, but this is obviously the most major one of all. So what happens typically, in this case, is that you try to get a synchronous contact with the people with the implementers or with the company behind the vulnerable protocol. Now, most of the time, we go through some disclosure service that also runs bug bounty programs. So they have an excellent contact list of most everyone who deploys contract contracts in Ethereum. In this particular case, although we did go through that service, we actually knew someone who knew someone. We had a former co author of a research paper, who works for a company that develops the Phantom blockchain and the Phantom blockchain was a major customer of the vulnerable company.  So within a few hours, they put us in touch with the CEO and we had a channel on telegram and we told them their WhatsApp what the vulnerability is.

Vamosi: So you just mentioned the Phantom blockchain. Does that have something to do with the name that you assigned to this?

Smaragdakis:  Yeah, well, it's phantom with an F. But it was a good fit. So part of why we like the name was also this match because phantom would have been a major victim of this vulnerability, but not directly, I should say. Okay,

Vamosi: Given the relative newness of cryptocurrency, I’m wondering about the maturity of the industry. I mean, are they able to ingest vulnerabilities that are reported to them?

Smaragdakis:  I think one, perhaps interesting aspect is the process of disclosing a vulnerability and how people react to that. Because that's, that's kind of interesting, that kind of disbelief that comes with that, and the denial, initially and how their vulnerabilities are demonstrated. The other perhaps is, so if someone has the ability to steal anonymously, a billion dollars, why don't they do it? Why do you disclose the vulnerability instead of exploiting it? The third, maybe, I don't know if that's good or not. Some mention that this vulnerability that we discussed is arguably the largest ever crypto vulnerability and that means a lot because there have been a lot of crypto vulnerabilities in the past, including some very major ones. Of course, it wasn't exploited, but it could very well have been right. I can exploit it right now by going back to the state of the blockchain in two weeks. ago. To demonstrate that this was completely exploitable. We just chose not to exploit it. So I think these are kind of interesting points that may be you might want to include something about them. And then I don't know if it's good to kind of include some kind of defensive points because technical people have very polarized views about cryptocurrencies these days. And I don't know it's I don't know if I should be defensive about that or not. But I think there's a knee jerk reaction to all of that. We shouldn't talk to it at all. Why is this interesting? Why is this good? Just abolish it, or something? 

Vamosi:  This is somewhat surprising. It would seem that even a great developer can acknowledge that all software has vulnerabilities. 

Smaragdakis: Yes, I think first of all, there's a natural element of denial, everyone went and faced a scenario where their code is claimed to be vulnerable. Their first reaction will be no, yes, that's not true. I've thought of what they'll tell you. Secondly, because of a pretty high number of low quality warnings, most development groups do get such warnings. Not I don't want to say every week but certainly one a month. So they get a lot of false positives reported by people who have not really reproduced their claim vulnerability vulnerabilities. So it's not completely unreasonable for the developers or for an organization, especially if it's not the developers. It's the CEO to say, oh, yeah, we've seen this bug report before. Now. Now it's not valid. You cannot really exploit that we've gone through that. And that's very often the first reaction. That's very often the first reaction. And even with proof of concept code, it could take a couple of hours until people really understand the essence, especially of a new attack vector and to agree, and we had to go through that twice. In this particular vulnerability disclosure with a multi chain for each instance of the vulnerability we had to explain. No, this is actually real, because we would get objections to the form. No, no, our other code prevents that. No, it doesn't. Because of this, or that, just run the proof of concept we sent you and you will see. So we have to overcome some initial negative reactions, and it's also a pretty awkward thing. To try to convince people that you are qualified and be a benevolent, white hat hacker. So that kind of awkwardness is what we are often trying to get away from by having an intermediary by having a service that's well known. For instance, in unify the bug bounty service, the best known smart contract bug bounty service, and to have them contact the victims, have them contact the vulnerable service and say, Hey, we have some pretty trustworthy white hat hackers here, and they report this vulnerability and our engineers confirm that it's very likely real. So can we get on a channel and discuss this? 

[Music]

Vamosi:  Let’s look at the Phantom Function attack in more detail. It turns out that there were several layers to the attack.

Smaragdakis:  It's not good, the blockchain contains immutable programs. The blockchain is a data structure, that once you deploy a program, you cannot really change it unless the logic of the program says Oh, and by the way, I will disable myself when this message comes in. If you don't have that, there is no fixing the vulnerability, there is mitigation. Any way you can and this depends on the situation. Now in this particular case, there was one attack vector, two vulnerabilities, four threats. What do I mean by that? It's the same attack vector with the permit function that I described before. There were at least two major vulnerable services. So the same code existed in two places, two very different pieces of functionality. And you needed different attacks for the two. So the code that actually performed the proof of concept attack was very different in one case, versus the other and the total was four different threats. And I'm distinguishing the four different threats because some of them can be mitigated and some of them, in principle, are very hard to mitigate. 

Vamosi: A vulnerability in a codebase isn’t always exploitable. Yeah, it’s a flaw, but it would require other things to exploit it. And sometimes you do see vulnerabilities chained together -- an exploit chain. What’s cool, as I mentioned before, about the blockchain is that it captures the flaw and even after they are fixed, you can still go back in time and see the flaw and understand how the threat worked.

Smaragdakis: So let me explain the threats. So, threat number one, there was about 500 million of exposed funds that we could steal right then and there. It's an actual transaction. I can show it to you now because on the blockchain, you can always go back in time and show it two weeks ago. Let's pretend we are in the state of the blockchain as of two weeks ago. And let's run the proof of concept transaction to show that I can steal half a billion dollars directly. So that's the first thread. Very majorly everyone understands that. The second thread was the same code that existed in different block chains and we were not even sure about the exposure there. Because those are more minor blockchains but still, they handle significant money. Still, this was a smaller threat. It turned out a few days later, we determined that this was about a 40 million threat, roughly. 

Vamosi: So these vulnerabilities could have affected millions of dollars in cryptocurrency. The next vulnerability, however, was the big one.

Smaragdakis: The third and very major vulnerability was the following. One of the victims, not the vulnerable code, but one of those accounts that trusted the vulnerable code, and that would have been a victim not only had over 300 million in that account that we could steal, but it was also an escrow account. That held some money that had moved to different blockchains. So the money had moved to different blockchains and it was escrowed. So that it could not be used during the time that the money lived in a different blockchain. This means that the vulnerability had theoretically infinite impact. I could take a billion dollars, say I want to move this to that other chain. And when I see that it actually got moved to that other team. I steal it from here, and I also have it in that other team. I just turned my billion dollars into 2 billion and at the same time, of course, I wouldn't just steal my money. I would also steal half a billion from everyone else in there. So we are talking about a major exposure not just of about half a billion dollars, but also a vector that allowed doubling money. And of course, you cannot double money indefinitely. But you can certainly do it at the level that it does not completely destroy the ecosystem. There's still some trust in this money. So it's unclear to say how much money you can steal that way, but it's still significant. 

Vamosi: I want to note that when we talk about multiplying effects of some of these cryptocurrency vulnerabilities, we're still talking about a finite amount of currency. We're not creating money out of nothing. As with stock, there’s a certain number of shares availability and if more and more people claim ownership of those shares, the value of each share dilutes or drops until the stock is worth nothing. That can happen with cryptocurrency.

Smaragdakis:  Well, in the hole in the whole blockchain creating money out of nothing walks a very fine line with creating money out of something. It's a very fine line that separates creating money out of nothing versus creating money out of something. So there could be an infinite multiplier obviously not. Anything that could be an infinite multiplier will erode trust so quickly, that the coal currency that's vulnerable will lose value right away in real world terms? But in terms of accounting? Could there be vulnerabilities that allow you to multiply some kind of money by infinity? Absolutely. Absolutely. So what will happen if someone takes advantage of this vulnerability? Well, that currency goes to zero, its value goes to zero. Nobody accepts to trade it for any other currency. So it's the collapse of that particular currency. Every time a vulnerability of this kind is discovered, some attacker can multiply their money ad infinitum.

Vamosi: The important thing here is that the vulnerability was disclosed before someone took advantage of it, before the value of the affected currencies could collapse.

Smaragdakis: The other blockchain that we're talking about has a valuation right now between five and 6 billion. So if I were to still another half a billion, probably it would not collapse right away from that theft. Most of the money there would still be good. So that's the third major effect, the third major threat. 

Vamosi: The fourth threat, then, is one for the future, where the account has no funds now but may someday. And that’s when the Phantom Function could wipe out those funds. At the time of disclosure, close to 5000 different accounts had given infinite approval for WETH to the vulnerable contracts (on Ethereum). Fortunately that number has since diminished. 

Smaragdakis: And the fourth threat was that many 1000s of accounts had given approvals to the vulnerable code. To spend their money. And that's not a direct threat, because we're talking about accounts that right now, do not have money that can be stolen through this attack, but in the future, whenever they might get money that can be stolen via this attack.

[Music]  

Vamosi: Like most software, cryptocurrencies need to be updated, unfortunately the mechanism for alerting customers is not solid, particularly if you don’t check in irregularly.  

Smaragdakis: Someone can be watching the blockchain and stealing right away. So that fourth vector is nearly impossible to mitigate, without really going out into the world and telling 1000s of different account holders in some way or another whatever real world channel you can go and no longer trust this vulnerable contract for this kind of money. So the three first threats were mitigated pretty successfully. I mean, I would say over 99 and a half percent successfully within a week or 10 days. And the fourth thread is still ongoing to this day, although by now it's significantly smaller. Right now. It's a little over 2000 accounts with approvals and most of them are not very active accounts. So now slowly, we can start saying that even the fourth threat is mostly mitigated, but the fourth kind of threat is always extremely messy. You have to go out in the world and tell people you are vulnerable. You haven't done anything wrong, but you have trusted some vulnerable code. Now go and revoke that trust, because anyone can steal your money. And right now you don't have money of that particularly stealable time, but it's a very popular time. So at any point, they could arrive in your account, you could do an exchange, or you could bring some money in and suddenly this money can be stolen. 

Vamosi: So how does Ethereum, for example, push out the fact that people need to revoke the permissions? 

Smaragdakis:  So the primary way to get the word out is indeed to go to the media to go on Twitter and announce that? Because the Ethereum blockchain has one explorer service, which is ether scan, and everyone who wants to watch the activity of their accounts will go on ether scan. Another very effective way to communicate with anonymous holders of those accounts. We don't know who they are, in most cases, it is to put a banner on the account on ether scan and say this account is vulnerable to this kind of attack. Please go and do that. And indeed the company multi chain did that for I think, over 2000 accounts. They put banners on ether scan with the collaboration of ether scan people they put banners of this kind to warn through that. But also, you contact people in the real world. You get the word out that there's a vulnerability if you've ever interacted with a service, go and do that. And of course, they also did it and actually did it even before the public announcement. They did it through their own UI to their own web app through their own mobile app, or whatever their UI said to every returning user, go and revoke your permissions. But the problem is not the returning users. The problem is that people who interacted with this service six months ago, and they don't don't even remember anymore that they interacted with the service, but their account is still vulnerable.

[music]

Vamosi: Phantom Function was, perhaps, the most public of the vulnerabilities, but Yannis and his team has found other vulnerabilities in Cryptocurrency.

Smaragdakis:  So there were quite a few interesting vulnerabilities that we disclosed in the past year. The DefFi server one was our first about a little over a year ago. It was very interesting, but mostly because of highly technical elements, that in order to get to the vulnerable point you need to repay some loans from the victim. So the code had the bond but in order to exploit that bond, you have to get a loan and repay the victims loans. And only after that, you could get all of that collateral of the loan of the victim. So you could pay off say a $2 million loan and get that 5 million. So that was the interesting part there in that vulnerability. I think in terms of other interesting vulnerabilities, something that I can explain in sound bites

Vamosi:  like common weaknesses that are occurring you know, use after free type things. Anything that you're discovering.

Smaragdakis: Okay. So the best known attack vector in Ethereum smart contracts is what's called reentrancy. Which, in the middle of a transaction, you call out to code and the code calls back into you and if you are not in a consistent state when the code calls back into you, what could happen is that you end up with all sorts of logical errors. For instance, if I'm in the middle of giving back some money to clients, and I want to do accounting of that money, I go on to say, Rob got his $10 but I don't actually write on my balance sheet that Rob got these $10 before I call Rob, to receive this $10. Then in the middle of that call, Rob can come back and say, Hey, give me the $10 that you owe me. And if I don't update and say, Hey, I'm giving this money to rob, before I go back to give it Rob can call a third time and say, give me the $10 that you owe me. And that's with this reentrancy attack vector. One can get multiples of their money assuming that that contract logic supports something like that. So this was the oldest best known vulnerability in Ethereum. That was, it became popular with a DAO hack back in 2016. So that's what most people think about when they think of vulnerabilities in Ethereum. 

Vamosi: Let’s talk about that for a minute. The ethereum network is a network of computers all running the ethereum blockchain. A DAO is a Decentralized Autonomous Organization. eliminating the need for documents and people in governing, creating a structure with decentralized control. In 2016, the DAO was subjected to an attack exploiting a combination of vulnerabilities, including the one concerning recursive calls, that resulted in the transfer of 3.6 million Ether - around a third of the 11.5 million Ether that had been committed to The DAO - valued at the time at around $50M.  Researcher said: “this was actually not a flaw or exploit in the DAO contract itself: technically the Ethereum Virtual Machine (EVM) was operating as intended, but Solidity was introducing security flaws into contracts that were not only missed by the community, but missed by the designers of the language themselves.”

Smaragdakis: But it's arbitrary code. So there can be any kind of attack vector. Most of them are not low level. It's not Use After Free vulnerabilities. It's not a buffer overrun. It's mostly vulnerabilities that may have to do with subtle semantics of the language such as we enter and see subtle semantics. Of different API's or financial manipulation. Something that's very, very popular is anytime you interact with a financial service, and they ask other contracts on the blockchain, how much is $1 right now compared to say, euros well it's on the blockchain, so I can perhaps still to that price, by making the other contract that keeps track of the price of the dollar, giving it enough information to be convinced that right now the dollar is very cheap. If I can do this kind of manipulation, and can confuse what's called the pricing oracle of the first contract, then there could be a benefit to doing that. So that's another common kind of attack next. You second prize on the blockchain. The blockchain does not have knowledge of the real world. It tries to estimate the knowledge of the real world based on its past transactions and the state that it has accumulated. And if you can affect that state in some way, and give the contract wrong pricing information you can take advantage of that, in all sorts of ways. get loans for disproportionate amounts, get back disproportionate amounts from investments, or from exchanges, all sorts of things.

Vamosi: So we’ve discussed the vulnerabilities. Yannis has some best practices to follow to avoid making this.

Smaragdakis: So the standard practice in smart contracts is to employ specialized auditing services that look into your code and try to find vulnerabilities before the code is actually deployed. And that's excellent practice. It's very stringent requirements for high maturity protocols. And auditors are highly specialized, and they will not find all vulnerabilities but it's significantly harder to find vulnerabilities in audited code relative to non audited code, no matter how expert the programmers are, because all of us have our blind spots. In fact, our very first major vulnerability that we discovered last year in defy savor the service you mentioned earlier, the programmers of that service are x auditors. They are people who are highly experts in security on Ethereum. They used to do auditing for at least a couple of years, they had a pretty good auditing. Service. So they felt pretty confident that they are aware of all security considerations when they are writing code, so their code is likely safe. At the same time, it's very, very good to have some other eyeballs, look at your code, go over your code. Even if you are an expert. It's a completely different standpoint, and often it finds a lot of issues that could lead to high value vulnerabilities. So that's one practice. The other practice is a coding practice. When deploying a contract, it's good to put in some defensive mechanisms to make the contract possible or upgradable. To put in, in the Mcode logic, some safety valve that in case something goes wrong, allows you to take over. Now the problem there is that this goes very much against the philosophy of the blockchain. Those contracts are autonomous agents. They're supposed to be programs that operate and live on their own without anyone's authorization. If I'm interacting with them, I just look at the code. I don't need to know who runs it. Whoever deployed it originally should have no special permissions. And by creating upgradability functionality or possibility functionality, I'm I'm implicitly giving permissions to some owner. And that's kind of bad philosophically, for many of those protocols, many of those services. So there's a very fine line between having some form of control for safety. And at the same time, allowing the contract to operate autonomously and most decentralized protocols, most protocols that run over the blockchain these days, try to balance these two, and some go completely on one side or the other.

VAMOSI: Given his research, how does Yannis feel about cryptocurrency for his own use?

Smaragdakis: I feel fairly confident given the standard issues. That one I mean, in any kind of investment or money holding the degree of confidence once one has, and we're talking here about entirely security aspects, right, not valuation or anything else. In terms of security. I would not feel as confident as in traditional finance yet, but I would feel almost as confident especially with good practices of differentiation, and good InfoSec practices about how I'm managing my keys or managing my machine etc. So I would feel reasonably confident. I will say something that's kind of juicy, but not perhaps the best thing to say. We have lost more money as a company from traditional finance fraud than from blockchain from we have lost a couple of 1000 when a virus on one machine, went into our online, online money transfer account, and issued some transfers to some Russian sounding name in the Netherlands, we complained within 20 minutes it's been a couple of months. We've never gotten that back through the regular banking system with a full police report. And with immediate contact of both sides of the bank transfer. We may get that eventually, but we haven't. Of course, it's a small sum. It's a money transfer system, the one that we use to pay employees, but we've lost more money in banking that I would normally consider fairly safe. As a consumer, I would consider that we would be at least reimbursed for that. But still, that was a heavier loss for us than dealing on the blockchain dealing sums of money on the blockchain with good security practices. 

I’d like to thank my guest, Yannis Smaragdakis for talking about his research. 

To ardent supports of cryptography, this isn’t an attack on cryptocurrencies to poke holes in the code, to find and report vulnerabilities. Rather it’s an attempt to strengthen it. All currencies to some degree function on the basis of trust. And if we keep hearing about millions of dollars in cryptocurrencies gone missing because of poor coding practices or more often poor configuration and auditing of the code, then these currencies will be bankrupt. Rather, let’s keep researching and keep finding and fixing these vulnerabilities.

‍