 Bonjour. Hello everyone. Thank you for coming to our presentation. Are we talking about smart contract vulnerabilities? Wait a minute. No? No, they're not moving. Uh, Space Park, maybe? No. This is not what we expected. Great. So I'm Sarah. I work at a company called Consensus. We do blockchain development. I work on Balance, which is our accounting and analytics project. And I also make games. My name is John. I go by Morillian online most of the time. I work for our smart contract auditing practice called Consensus Diligence. If you haven't heard of it, Consensus is probably the largest blockchain-only company in the world. And we'd be happy to talk to you more about it after our presentation. What this talk will be, we're going for kind of a storytelling meets vulnerability post-mortems vibe. So first, we'll be doing a quick intro to the Ethereum blockchain. For those of you who may not know, this may be repetitive for those who are familiar or were in Mark's talk yesterday. And then we're going to do a series of deep dives into various incidents. All right. So Ethereum basics. Let's get you started. And everything here will be like all the essentials you need to follow the talk. So first of all, Ethereum is a blockchain. It's a chain of blocks and we'll define that a little bit better in a minute. It has a touring complete virtual machine. That sounds dangerous. And it's a distributed state machine. Many blockchains you could think of as a distributed ledger. I like to think of this one as a distributed state machine. So a really fundamental object in Ethereum is that we have accounts and we have state. An account has four properties. It's a notes. Well, an account is an address. So each account is tied to an address just like with Bitcoin. But in each account you have a notes for replay protection. You have a balance. The balance is measured in Ether or ETH, which is the sort of native currency on the network. And then you have code. Code is in Ethereum virtual machine opcodes. And so that may or may not be in any given account. And then you also have that last property storage. So that's like the disk. It holds storage values. All right. So when you're interacting with the Ethereum blockchain, you do so by sending a transaction. And there are two main types of accounts. External accounts which map on to people or private key, public key pairs and contract accounts which contain code. And so consequently we have two major types of transactions. Simple ones like Alice sending some Ether to Bob and more complex transactions where Alice is calling a function X on contract Z. And contracts can do any number of things. They can do any arbitrary computation. So the first path here, this contract is dispensing some Ether to Bob. The second path, it's calling a function on another contract. And it can also create other contracts. Transactions result in state transitions. So they can update any of the state properties. So during this presentation, we're going to talk about traces at various points. They are also sometimes called message calls or internal transactions. You can think of these as a step in the execution of a transaction. So here contract C is calling contract D. This would result in a two-trace transaction. It can call another contract. Now we have three traces. And four, etc. This spiral out in possible complexity. And you may find yourself asking if we're all sharing the same decentralized unstoppable computer, how do we dodge the halting problem? How do we guarantee that this computation will ever finish? And the answer is gas. Gas. Gas is one of the more interesting and innovative aspects of this system. So every opcode in the EVM has a gas price. So here's a series of fairly vanilla opcodes. And then we've got these more exotic Ethereum-specific opcodes. So you can create a contract. You can call a contract. And they have significantly higher gas prices for reasons that we might get into. And then there's these super, super standard kind of push opcodes, which are actually free, I learned today. So every opcode has a gas rate, as you see here. So the gas column is the cost of that thing. So the way that this is essentially meant to meter the amount of computation that your contract is doing. And so you can provide a certain amount of gas when you create a transaction. And if that gas gets run out, then the transaction will be undone. And you pay for it and you lose all your gas, but no state change will actually occur. So this is essentially a spam prevention technique. Some more things about gas. Gas is sort of the unit. Gas price is how much you can actually pay a higher fee per unit computation. And then each block, so each sort of block, has a limited amount of gas that can be spent within it to contain how much computation will be done in any given block. And so blocks. Great. So there's a number of things in every block. There's the roots of three Merkle Patricia trees. The transaction route, the transaction receipt route, and the state route. And we identified transactions you're going to see throughout this presentation by their hashes. There's a couple other parameters at the bottom that we'll talk about. So the blocks in the blockchain are chained. So each block includes the hash of the previous block, all of the data in it. And thus they're chained together, building out a data structure that you can think of like an append only linked list. And in theory, because these are cryptographic hashes and they are irreversible, this makes the blockchain immutable. Here's another diagram of basically the same thing, showing how after the transactions are processed and the state transitions have been taken, we update the state route, but we don't have to copy over all the state. So we have this blockchain. It's being maintained by miners who you may have heard of. These miners are creating blocks. And they receive a payout for finding blocks. But how do we decide who gets to do that? And the answer which we won't go into in great depth is proof of work mining, which you may have heard about. The miners are searching for a nonce that when added to the block data and all of that is hashed, it results in a hash that is lower than the difficulty of the network. So the difficulty is just a number and the hash is just a number. We're looking for a hash such that x is lower than y. And the difficulty is automatically adjusted based on the available hash rate. And the goal here is to keep the blocks coming in constant dependable time. Okay, so if you've heard much about Ethereum at all in the past, you've probably heard about tokens. And so tokens are not, as you might think, like Ether, a sort of first class citizen on the blockchain. They're actually a program that people create to track balances. So this is the EIP, Ethereum Improvement Proposals, Standard Token Interface. You'll see it has these sort of like this metadata, like a name, the number of decimals that there are in values symbol, so like ETH, BTC to like a stock trading symbol, total supply, and then these functions for checking your balance or for transferring balances to other people. And this is one of many standards, and this is something really powerful that's happened over time. It's the creation of new standards in interfaces which enable us to codify and create a ton of interoperability between standard patterns such as tokens, collectible items, or also known as non-fungibles, or voting protocols, many, many things, and many more are coming over time, and this is over time increasingly creating a snowball effect of interoperability. And it's all public on the chain. That's what's really fun about this is, as we tell these stories, I'd encourage you to notice how often we actually return to the data, how often we go and look at the history, because it's all out there. The whole story is visible in a public ledger, and it's still unfolding right now, every 15 seconds, a new update to the adventure, if you will. Many of our slides will actually include an image from this site, EtherScan, it's a great, easy to use interface for reading and understanding the history of the blockchain, and from a security perspective, this is, I think, like a really exciting, brave new world. It's like the 90s all over again. I probably actually, yeah, it's 1995 again for blockchain security. There's code. Anybody can read the code. Anybody can read the data. You can poke it and see what happens, and there's real value attached to it. So my colleague Bernard recently wrote this paper, Smashing Ethereum Smart Contracts for Fun in Real Profit. You may catch the illusion to the seminal paper by ALF1 there. So that, I think, captures sort of the enthusiasm for the people in this, who've been in the space for a little while, start to feel for this. So that ends our 10 minutes. Now you know everything about Ethereum attempt. It's a blockchain. You can also think of it as a state machine. It has accounts. Accounts can be contracts. Contracts are made up of code, opcodes. They have gas prices. We send transactions. They go in blocks, and the blocks are mined. Any questions? So now we're going to get into our incident reports slash adventure section. Okay. No talk on Ethereum security. Can't ignore the doubt. This was a formative moment for the community. If it was a musical, it would be a rock opera. If it was a ride at an amusement park, somebody would end up dead. So to set the stage, the mood in early 2016, people were feeling good. The network had been running for a year. Things were going up and to the right. People are making money. I personally had not been paying a lot of attention, and so I sat out on that. But I'm happy for my friends. So generally, the community at the time was doing really good, feeling good, and feeling like it was time to push the limits of the technology. So enter the DAO. The DAO was a digital, decentralized, autonomous organization in a form of investor-directed venture capital fund. So more concretely, the DAO was a contract on the blockchain that encoded mechanisms and incentives so that people could coordinate permissionously so they could just come in and they could pool their funds. They could put Ether in. They would get tokens for this system. These tokens would give you a vote. Each token was worth one vote for the decisions that this investor investment fund would make. So people could submit proposals on how to spend the funds in this contract and you could vote on proposals. An important feature is that there was a split functionality so that you could actually propose to split off from the main DAO and say, I don't like the direction this is going. I think we should get out of here and you could propose that and people could decide to follow you into your child doubt. There was this idea at the time that I think is important to bring up, that a code could be like law, self-executing law. That's awesome. Thank you. I mean it. It didn't sound sincere. I think it sounds scary. I appreciate you backing me up. So, yeah, I mean, this was huge. People just lost it. FOMO, FOMO, FOMO. There were specific incentives to get in early. If you got in in the first week, you got like 20% more tokens than everybody else. So that had a pretty pumpy kind of dynamic to it. I think a lot of the really large holders got in on this thing. And then I don't know who nobody will admit to this, but people were running ads on Facebook. Probably like early investors who'd gotten a good sort of bonus. They were like, well, let's get more people in on this thing. They were running ads on Facebook. And so this was like $130 million, the largest crowdsale in history. So things are going awesome. But hang on, what's this? There was an announcement in the midst of this excitement. A new vulnerability pattern was described. It's not something in the way that Ethereum is built itself, but it was like a subtle design pattern that could easily be included in the design of a contract. So here it's called, oh, the face is in the way. It says race to empty is what you're missing there. But fortunately, it's all good guys. The creators of the DAO, they took a look. They said, ah, it's not in there. We're fine. Carry on. Up into the right, steady as she goes. Now, before I continue the saga, I'll diverge a little bit or digress to describe the re-entrancy vulnerability pattern itself. So here we have a victim contract. I'll just go through this quickly for you. So it's got a withdrawal function. Presumably you have a balance in here already. You ask to say, I want to withdraw this value, this how much of what I have in this contract. The contract says, OK, like I require that you have sufficient balance. Message.sender is the requester in this case. And so, yeah, you've got enough. You may withdraw. And it sends the value to the caller, message.sender. And then it reduces their balance by the value. Seems pretty good, right? But there's something quite subtle in here, which is that essentially we have sent the value before we actually reduce their balance. And this is going to get us in a lot of trouble. So here's in a simplified attacker pattern. There's an attack function and then this fallback function. And the fallback function is just if you send ether to something, you don't have to specify a function. It's going to call. That's what's going to call. It's the default. So we'll run through this quickly. I'm the attacker, or I will call the attacker contract. It's going to call to the victim. The victim is going to send the ether to me as requested. And as mentioned, that's going to trigger the fallback function. And then the fallback function calls the victim's withdraw function. And so those orange arrows are both pointing to the withdraw function. So we do it again. And as I mentioned, that underlying section, we're withdrawing before we've actually reduced the balance. So we go back in there and we say, OK, yeah, totally go right ahead. I'll just, here's your ether, man. But they've sent it out twice now. And you can keep doing this and just like until the only real upper bound on this is how much ether is actually in the contract. So you can pretty much take everybody else's balance and leave just enough and then, you know, and then escape from the whole call and walk away scot-free. And it all comes down like there's, I've seen several kind of get commit sort of things where people actually switch the order and ruined everything. Like it's just got to switch those lines and you're good or you're totally screwed. So right, the Dow saga thing. Where were we? OK. Yeah, right. So no worries. It's chill. We don't have a problem here. Just kidding, a hacker of more than $50 million dashes hopes in the virtual currency world. The Dow is hacked. It was in fact vulnerable and the flaw was the flaw that the team missed and so nonchalantly declared to be not an issue. It was quite, I was looking at it again the other day. It's quite subtle. It's really buried in there. So yeah. And so, you know, from euphoria and happy good times everybody. Everything just like, you know, tears. So in the midst of this, this trauma, a white hat group appears. And these guys are sort of like, I don't know, they're like the incident response ninjas and they appear just in time and they're like committed to the community and they emerge and they start hacking the hacker back because everything's public and they could just, they didn't even really need to understand. They just said, well, what did this person do? They sent this sort of thing. OK, we will replicate that. They used the same split functionality which the attacker was making use like creating these child dowes which was draining the contract. So the white hats were like, well, we'll create child dowes. And they were draining it off on the other side. There's all this kind of like shenanigans and wild chase ensuing on the chain. It was enthralling, hard to follow. I still don't understand what happened really to be honest with you. But so some sort of like, I don't know, zeitgeisty tweets from the time. This is Avsa. He's a pretty core member from the Ethereum Foundation. I repeat, there was an attack on the dowes. So we launched our white hat counter attack. More updates will follow. OK, rescue is on the way. A note from Stefan of the Dow team itself. A community team is currently coordinating a white hat attack on the dow in order to prevent further attacks. Nice. OK, sweet. We're going to be fine. Dow? Whoa, OK. Man, that was timing. But the dow is being securely drained. Do not panic. Ah, it's a dow zaster. It did not like people panic. Don't worry. And out of this... Nobody got anything done that week. I got some water. Yeah, nobody got anything done for a month. I was not with consensus at the time. Consensus systems, it's confusing, but I was not at the company at the time, but apparently no work got done. So then we heard from the hacker. This message came out. It was actually signed. I haven't checked it, but I think it was corresponding to their private keys from the actual hack. I have carefully examined the code of the dow and decided to participate after finding the feature where splitting is rewarded with additional ether. I have made use of this feature and have rightfully claimed three million sum ether. And would like to thank the dow for this reward. So remember Sarah said this code is law thing. Like the terms of service on the website actually said it doesn't matter what this says. Just read the code. The hacker read the code carefully, and they appreciated their reward for their hard work. Can anything be done? But wait, we're not going to just let them get away with this, are we? So we said that it's immutable. We can't really, there's nothing, no intervention that can be done. But if you think, if you really think differently about things, maybe there really was no hack. So a series of proposals were put forward to fork the network. And what this means is essentially updating the rules of the code of the system so that we could create a new transaction to recover the funds. And so this was a huge debate because it really was a fundamentally different approach. But nobody really, like this was not planned for. This is just something that didn't happen. It was like there was one blockchain and you don't really mess with things in that way. You don't want to go intervening kind of directly and picking something out and adjusting it. And I'm not going to get into the whole philosophy here. It's something that happened and we've moved on. But it was a very contentious and divisive discussion. So they updated the client. They got ready to put it live. They announced the block number at which point this would change. And everybody was so confident there was just going to be this one true chain that would carry on. But ultimately what happened with so much contention, we got this split and a whole new chain was born. It's up to you which one you think is the real one or the original, but Ethereum Classic emerged. And so not only the chain and the history but the community really divided, you can straddle them. You can partake in both. But there was this real philosophical divide that emerged and a very interesting sort of... And what is interesting about this is that it really caused us to... There are many, many interesting things, but it caused us to think entirely differently about blockchains. It was the first known use of this re-entrancy attack. There were tons of money lost. It really impacted people's wallets. And in the end, probably, even though the funds were recovered, I'm sure a lot of people lost a lot of money in some way or other. And we got the first significant split of an important blockchain, which has inspired many more since then. It's kind of standard practice. Thank you. I will pass it over to Sarah again. Great. So I'm going to talk to you about the DDoS, which was an event that took place from September 2016 to November 2016. And there were three distinct waves of this attack, followed by a cleanup process that was, in many ways, just another DDoS. So it was the first night of DevCon 2. And DevCon 2, if you don't know, is the largest developer conference for the Ethereum blockchain. All the core devs had flown to Shanghai, and the rumor is that they were out drinking together. When suddenly, guess, the most popular implementation of Ethereum started crashing. There was a memory leak. No one knew what was going on. This is the offending transaction that triggered the memory leak in Gaff. The other clients, Parity, the Rust implementation, and the C++1 were able to continue maintaining the network. The transaction payload, this is it. And when you translate that into Unicode, it says, fart knocked house. What does that mean? Go home. So there's speculation that the attacker was deliberately climbing this at a time when the core devs would be distracted. This may not have worked out the way they intended. Everyone was together in the same room, so they were able to mobilize really quickly. Only seven hours later, a patch called from Shanghai with Love was released, and Gaff was working again. And though there was a minor price drop, for a while it seemed like everything was going to be fine. It seemed like the total damage of the vulnerability was that DevCon 2 presentations were running 30 minutes late. Little did they know. It was far from over, just a day or two later. There was a second transaction, and you'll notice this is an example. There were many of these sent. This one has over a thousand traces, so that means there were over a thousand steps taken during the execution of this transaction. And what this transaction was doing was calling an opcode called XcodeSize over and over and over. What this opcode does is it returns the size of the code that is held at an address. So normally we would use it to tell if an address is a contract, whether that contract has been destroyed, et cetera, and involves fetching the code from disk on the client. It's an operation that on optical drives can take quite a while. So on average for these transactions, during this wave of the attack, XcodeSize was getting called 50,000 times per block, and it resulted in a two to three times slowdown in the rate of block creation. To put things in perspective, initially this opcode was priced at 20 gas, and once everything was recalibrated, it went up to 700. So over the course of DevCon, the core devs frantically released a series of patches, amongst other things, trying to optimize XcodeSize. The patches have names like Into the Woods, What else should we rewrite? Come at me, bro. So for a while, everyone again thought everything was going to be fine. This is a pattern. The attacker wasn't done. This is another example transaction, and you'll see this one has almost 2,000 traces, so almost 2,000 steps taken during its execution. And unlike some blockchains, Ethereum has state, as we know, it has world state, and this contains a bunch of things, contract code, storage used by contracts, and accounts. So what the attacker was doing here was creating almost 19 million empty accounts. It created and destroyed many contracts, taking advantage of some idiosyncrasies and oversights in the Ethereum protocol. It bloated the state tries such that it couldn't be held in cash, and made disk retrievals necessary, and they were slow. So the way the state bloat started out was innocuous enough. The attacker deploys a contract, that contract has a counter, it's initially set at zero, and it spawns another contract. The next thing it does is call a self-destruct function on the contract it just spawned. And normally, this function is used to refund any Ether held in the contract to its rightful owner. But here, the contract is passed counter as an arg, and it casts the counter to an address, and tries to refund that address with its balance, which is nothing. So it's basically creating an empty account. And you'd be forgiven now for thinking that this contract no longer exists. We just called it self-destruct opcode. But if we review the yellow paper, which is the technical reference paper for Ethereum, we will see that it says halt execution for later deletion. So what this means is that the contract is registered for deletion, but it won't actually be deleted until the transaction execution ends. We might call it self-destruct in a second. So it turns out we're actually back here. We're incrementing our counter. Our counter is now one. And we have still this address that we get, address zero, and it has nothing in it. What does it mean for an account to be empty? You can think of this as equivalent to a variable that is declared, but explicitly set to null. This would be in contrast to some programming languages where something that has never been declared would be undefined, like JavaScript. So contract C does the same thing all over again with counter one. It calls self-destruct again. Contract D still exists. It tries to refund account one with nothing. And contract C will do this over and over and over until it runs out of gas. And the attacker continues to send these transactions until the problem is patched. So eventually the community debates, they come together around a series of fixes. These fixes are that the self-destruct opcode will trigger an additional cost if it touches a newly created account. It adds a gas cost to the creation of a new account. And if an operation would result in an address having an empty balance that address is removed. And once these changes are included in the protocol, Core Devs deploy a series of contracts that replicate this counter-call behavior of the attack. They're poking each account in order starting from zero and prompting the protocol to notice that they're empty and delete them. Sadly, this slowed down the network as much as the DDoS itself. So this is a heat map of the number of traces per transaction on the Ethereum network. You'll notice that most transactions over the history are clustered near the top. This means they had only a small amount of traces. And the DDoS stands out on the extreme opposite side with thousands per transaction. This is another view of the same data. The large peaks in the front have a very small amount of traces. And there's these two bipolar lumps at the back and that's the DDoS and the state clearing operations. And this is actually still skewed because height here represents the number of transactions. If we adjust the height to be proportional to the number of traces actually being created, you'll see things are even more crazy. So the scope of the impact is that the total number of accounts was increased to around 20 million, which needed 10 gigabytes of disk space to store. And once state clearing was complete, the total number of accounts was brought back down to just under 100,000, which are only about one gigabyte of storage. In summary, the DDoS was not one event. It was a series of events. It revealed a bunch of bugs, some in the protocol itself, some in specific client implementations. There were no lost funds. But since the attacker was actually spending their own money in the form of gas to execute this attack, their motivations are quite unclear. This did result in price drops, so possibly this is an attempt at market manipulation. But both their identity and their motivation are unknown. In some ways, you might say they did us a favor by revealing these weaknesses in the protocol. Oh, man, did I leave a note on there? Oh, boy, that's embarrassing. The point of this is not so much rather the transaction, but the concept of... Okay, so I can skip this section, right? No. So this builds on what Sarah was talking about. We had this state-blowed attack. And as she just mentioned, we had to find some way, we had to clean it up. So I'm going to talk a little bit about the clean-up and some weird things that we discovered in that. And one theme that carries over also is just how weirdly ambitious this whole thing is. It's like really like hold my beer. I'm going to make a blockchain and hopefully... and it's going to work out. And not only did they write one blockchain client, but when it initially launched it was written in multiple implementations. And so there was a lot of talk about how each client would have to be bug-for-bug compatible with one another. If you have any disagreement, then you'll just have a fork. If the rules are different, if there's a state transition where in one case I get some ether and in another case Sarah gets some ether, that's a different state of the world. We disagree, we're going to diverge, that's a bad thing. Yeah, I discovered that. So one way that this is dealt with is with a reference specification which is known as the yellow paper. There's a lot of fancy hieroglyphics that nobody really can read, but there are some people who claim to be able to and then to also translate that into code. So that's been done many times over. I encourage you to give it a look through. It is actually quite fascinating if you skip over the equations. And so there was a recent update because as we update the network we need to update the specifications so that we can all stay in sync. And I happened to notice this appendix K which appeared in the last iteration and I always found it very strange, deletion of an account despite out of gas. So I looked into that for this talk. So as Sarah mentioned these empty accounts were created starting at zero going up through I don't know just until the attacker stopped spending gas to create these empty accounts which blow the state. So a contract was created by the cleanup crew which just went calling to all these empty contracts or accounts. So if it was touched as they called it, this empty account would be touched. The new rules would remove it from the network. We don't have to store that in our list anymore. Great. But there are some edge cases in here of course because it's super complex. So addresses 1, 2, 3, and 4 have to do what we call pre-compiles. So these are contracts but they're not contracts with bytecode in them. They're contracts that are written into the client. So if you make a call to address 1 the client will say I'm going to run this go module that will do ECDSA recover or SHA 3 or write MD. So when they went through and touched all these accounts, most of them were okay because they didn't have so the thing was the weird thing that nobody thought of is that yes these accounts have code but it's not stored in state. It's not on the blockchain so it doesn't look like it has code so it would normally be deleted except most of these happen to have a little bit of balance sitting in them. Somebody just had sent some ETH to them by accident or for the lulls but not 3. Wripe MD was deleted and so this is a bug you shouldn't be able to delete one of these contracts but the amazing thing about it is that everybody deleted it. Every single implementation made the wrong mistake. I spent too much time in this talk trying to find a gif where somebody makes a mistake and somebody else makes a mistake and like you land on your feet and it's fine. That's what happened. It's really awesome, I think. It's like the quintessential edge case because everybody implements it and so that's how appendix K was born. Summary consensus with bug for bug compatibility is hard, edge case is abound in this complex system and we got lucky. So I'm going to talk to you about a bug that is affectionately called the Polonix short address bug. Polonix if you don't know is a centralized exchange which means that it holds user funds it maintains off-chain order books and allows off-chain trading so this allows people to trade faster than block time. Consequently it's holding user funds in escrow and it has a series of really large wallets. The potential consequences of this bug were draining Polonix's entire supply of Golem token which is what John described earlier an EIP 20 token. Luckily the actual consequences were none. So here's the transaction screen cap from etherscan and the bug is down here it has to do with how we format contract args. So under normal circumstances they look like this we take the hash of the function signature we take the first four bytes of that and we use that to identify which function we're trying to call and then we just pass in the args. So in this case it's two simple static args an address and unsigned 256 bit int we've had these all to a length of 32 bytes and we get one long string which is 72 bytes long. But this one was called with 79735 in the address field and this is not a long enough string. So left all this empty space that the EVM was expecting to parse. What does it do when it encounters this? It fills it in with zeros. So that meant that this contract thought that this user was trying to send a value of and this number is in hex but you would say it as 33 Vigintillion. Now luckily that is a very large number it's more than the total supply of Golem token that ever existed so it quickly hit a check and couldn't be executed. But there are at least 35 other transactions that have similar formatting errors turns out Polonix was just not validating user input at all. So this one is also from Polonix. Four days after this bug was disclosed but it did not drain any wallets either that we know of. So this is a quick one to summarize a peripheral to Ethereum itself basically equivalent to calling functions with invalid args minimal damage. This one's pretty fun so I'll get right into it. XSS and Ether Delta the story of how one hacker stole thousands of code injection attack. So Ether Delta is a DEX decentralized exchange and so this is it's sort of like Coinbase or Polonix or these exchanges that you know but it's encoded in a contract and so it has these sort of typical exchange like functions like you can deposit withdraw check your balance submit in order or trade and there's this pretty front end that you can use to what's interesting about this is this is just a static HTML.js page that is talking to the blockchain it's reading data from there and it will facilitate you signing and sending transactions so in this case we're using a browser extension metamask made by our friends who are also part of consensus and so the private keys are in this sandboxed browser extension this popup will let you approve or not approve signing a transaction but there's also this option with Ether Delta to keep your keys in the web app which we'll see causes issues so we have this token if we're an attacker we could create a token and it has these metadata values and then we then the attack plays out as so so we launch this token with those metadata values this attacker had given a sort of an extra function called rename they submitted this value to rename the token with this weird name which is a lot of javascript and within that javascript it's finding a key pushing that key to an array and then sending it to a server and then it's gonna steal everything in your account so you just you have this token and you make people think it's a great token that they might want to trade they look it up on Ether Delta and you make profit and so the amusing thing here is that a few days later after pulling this off once their token was blacklisted they updated the name on the token again to this alert call pwned I don't like that spelling but that's how they spelled it so in summary sanitize your inputs even if you're reading them from the blockchain sanitize your inputs do you think I should do this one still or so alright front running into it so front running is when a broker enters a trade with foreknowledge of a transaction this is a classic stock exchange issue it's very bad so if you know that a trade is coming to influence the price of inequity you can get your trade in first and get economic gain this is a prohibited practice it's really bad but on the blockchain it's fair game so this is a great visualization of the blockchain it's from a site called ether viewer dot live and so we see it's actually kind of backwards to the left is the head and there's a new block is being created by minors as we go and the minors are when you broadcast the transaction it just goes out into the world into this mempool so you say I just I want to trade some tokens I want to buy some token XYZ for one ETH and it goes in there and then somebody can read and say oh somebody wants to purchase this token for this price I'm going to buy it first and then I'm going to sell it to them first even so you could actually like create one transaction and then another buy it and buy it and immediately turn around and sell it back to that person at a higher price quick and easy profit low risk so something I learned recently is that there's this F7F3 who dominates the front running game all around the world so I don't know how they're doing it I've had people actually like talk to me like who is this guy how are they doing it is it you it's not me it's not me they have nodes all over the world their devops game clearly is on point because they're always beating people out and getting in on the front running before everyone else not only that they have diversified their revenue streams so they're not only getting their orders in before other people but they're also finding the fat finger orders the people who instead of paying ten paid a hundred offered to pay a hundred for some item and so they're seeing that order and saying well that's a that's a nice one and then getting their corresponding purchasing so I there are actually like comments in ether scan on these accounts what we got here great bought lost some money on this too by missing one digit in order so so he caught that he's like oh you messed up my profit either Delta scammer finds historically signed orders invisible on the order book and depletes the ETH sell me your bot yeah it's I don't know I never expected this I this was like a kind of hypothetical front running hack situation and it was I didn't realize that people were actually making millions of dollars a year off this so I find it quite a fascinating emergent behavior on to parody last deep dive of the day and has to do with parody which you may remember is one of the most popular ads in the world and it's the one written in rust so everything starts in July 2017 and at this time you know things have been calm for a while it had been some time since the Dow and the DDoS so everyone was getting comfortable but of course it can't last security alert goes out this is from parody's founder the severity is critical and it turns out to be a vulnerability with parody's official multi-sig wallet and a multi-sig if you don't know our wallets that are often used to store funds more securely because supposedly at least they need the signatures of multiple owners in order to transact so we see the attacker calling a function called init wallet and in the owner's they're passing in their own address so the first thing to know about how this happened is that parody uses a child parent library contract so it has this child but most of the actual code that is getting executed lives in this parent library and the attack starts off with the attacker calling a nameless function and the vulnerable child the fallback function and in this case that function passes whatever it was called with on to the parent via a delegate call and a delegate call is a special kind of call that will execute the parent's code but on the child's state so the attacker calls init wallet that's where things go wrong because init wallet updates the owner's array and the coding error here is really simple it's just a missing keyword init wallet should have been marked as internal so only the library should have been able to call its own init wallet function and the attacker is able to overwrite the owner's library with their own address withdraw all the funds so the attacker gets to work really quickly within three hours they've managed to deal 30 million and at the same time a white hat group springs into action possibly the same white hat group that mobilized for the DAO they scan the chain for vulnerable wallets they're able to find many and they also rescue 85 million parity urges its users to migrate to a new wallet contract and everything was great nevermind at first no one realized what this meant or that it was serious parity's github repo a github user claims to have deleted the parent library contract and if you read the initial comments like no one knows what this means I think the first comment is like no you didn't so to my knowledge the identity of ghost who was originally named devops199 is still unknown they may not have known what they're doing this says I accidentally killed it but nevertheless the library was gone and just to review what's at stake here these are the top 10 wallets that use this library and they are holding about 52 million in dollars or just over 500,000 ether so in some ways this is similar to this is a more simple vulnerability than the previous one ghost was able to claim the wallet and then destroy the claim the library and then destroy it so if you remember left pad which is a well known incident in the Node.js community a popular dependency was deleted it caused a bunch of things across the internet to stop building this is basically left pad for cryptocurrency but because blockchains are immutable once left pad is deleted it's gone forever which means that all the funds that are held in any of these child wallets are frozen the code that would allow those funds to be withdrawn doesn't exist or are the funds frozen so an EIP is an Ethereum improvement proposal this one was recently put forth by the parody devs and it was to restore the contract code of the wallet library contract with a patched version the contract was accidentally self-destructed and renders a significant amount of ether inaccessible and no one really knows what to do about this yet the debate rages the community is very distracted from its pressing technical problems people have been worrying about the possibility of another contentious hard work well a recent unofficial poll on Etherchain tipped towards no don't execute EIP 999 the future here is still somewhat uncertain and it's an ongoing debate so to summarize parody had two related vulnerabilities it's possible that the second one was a result of the haste which the first one was fixed it was a significant theft and an even more significant amount of frozen funds and it reveals a weakness in the child library pattern so some might say that this is just the kind of thing that someone had to learn the hard way in conclusion it's been a wild ride if the idea of working on an unstoppable distributed computing platform that has money as a primitive excites you come talk to us we're hiring and if you want to get in touch this is how thank you so much for listening to us all and thank you to NorthSec for organizing