[00:01.570 --> 00:07.150] Hey everyone, my name is Martin, thank you for having me. Today I will be talking about the [00:07.150 --> 00:15.810] seven phases of smart contract hacking. In this talk my idea is not to jump and dive into technical [00:15.810 --> 00:21.610] parts of what it means to hack smart contracts, but actually I want to give a little bit of [00:21.610 --> 00:27.370] perspective and try to talk about the bigger picture of what does it actually mean to hack [00:27.370 --> 00:34.910] smart contracts. So if you're a pentester, if you're a bug hunter, perhaps working in application [00:34.910 --> 00:43.250] security or other realms of information security, you can jump into the Ethereum ecosystem and start [00:43.250 --> 00:49.690] helping us secure the entire platform. So a little bit of background about myself, I'm Martin, [00:50.370 --> 00:55.430] I'm a security researcher at Open Zeppelin, one of the leading companies in smart contract audits [00:55.430 --> 01:00.570] in Ethereum. I'm a systems engineer, I'm doing a master's degree in cyber security and cyber [01:00.570 --> 01:05.850] defense at the University of Buenos Aires, and I used to work as a pentester mainly on application [01:05.850 --> 01:13.250] security, infrastructure, mobile applications, web applications at a big four. And then I jumped [01:13.250 --> 01:18.670] into being a security researcher here at Open Zeppelin. Well let's say again that you're a [01:18.670 --> 01:25.350] pentester, you might be a bug hunter, a white hat hacker, perhaps working in other realms of [01:25.350 --> 01:31.610] information security, but you're interested in blockchains and smart contracts, you have heard [01:31.610 --> 01:38.650] about them, because to be honest we have hit the headlines a couple of times. There has been many [01:38.650 --> 01:48.530] hacks in the latest months around smart contracts in Ethereum. So as you see, many hacks and in my [01:48.530 --> 01:53.230] opinion we need more and more security experts to jump into the field and to help us secure the [01:53.230 --> 01:59.910] entire ecosystem. So this talk is mainly aimed at you. And the question is if you can hack a [01:59.910 --> 02:05.310] smart contract, right? What knowledge do you have already that can help you out here [02:05.310 --> 02:12.570] in the smart contract world and that you can start applying today to start hacking smart contracts? [02:12.570 --> 02:17.110] And well the answer is yes, that you do have some knowledge, because you do know which are [02:17.110 --> 02:22.670] the seven phases, let's say, of a typical security engagement. And when I say seven, [02:22.670 --> 02:27.630] I don't mean to be strict with these phases that we will be talking about. It's just a way of [02:27.630 --> 02:34.110] organizing the talk, but perhaps when you do bug hunting, some phases you might skip them or you [02:34.110 --> 02:40.790] might do others, but the idea is to outline our work as security auditors or bug hunters or white [02:40.790 --> 02:48.530] hackers in these seven phases, so we can have a common language to talk about this. [02:49.310 --> 02:55.290] Well, these are the seven phases that I have, that we will be talking about. First, [02:55.290 --> 03:00.090] scoping, then reconnaissance, identification of vulnerabilities, exploiting these vulnerabilities [03:00.090 --> 03:06.550] that we have found. What does it actually mean to do post-exploitation in the smart contract world? [03:06.550 --> 03:10.610] And we'll be asking ourselves whether that's an actual thing or not. [03:10.690 --> 03:16.750] And then we'll be briefly covering reporting fixes and retests. So you might be already familiar with [03:16.750 --> 03:22.090] these phases. The idea of today is to see how these phases apply in the smart contract world [03:22.630 --> 03:26.370] and whether we can start drawing some parallels between these phases [03:27.110 --> 03:35.050] and the ones that you are used to applying. So let's get started. Let's talk about scoping. [03:36.110 --> 03:41.270] If you come from the, let's say, application security world or maybe doing pen testing for [03:41.270 --> 03:47.570] infrastructure exposed on the internet, you might be familiar with the fact that you have IP [03:47.570 --> 03:55.530] addresses, right? When you are scoping your work, you will be given IP addresses that will help you [03:55.530 --> 04:03.210] understand the systems that you are about to audit or to assess. In the Ethereum case, [04:03.210 --> 04:07.910] we also have addresses. In this case, we have Ethereum addresses. I know they are not the same. [04:07.910 --> 04:12.930] I know there are many differences between them, but the idea is to start drawing, as I said before, [04:12.930 --> 04:24.370] some parallels between the worlds. So we can think of these addresses as ways of allocating resources, [04:24.370 --> 04:27.810] let's say, in the first case on a network and in the other case on the blockchain. [04:29.290 --> 04:34.590] When you are working on smart contracts, you will not only have one Ethereum address, but you can [04:34.590 --> 04:39.010] have many Ethereum addresses that are related to each other. And you may not even have Ethereum [04:39.010 --> 04:45.010] addresses, but actually you can have domain names, right? As in the classic world, you have the DNS [04:45.010 --> 04:51.770] that will help you resolve from human readable names to actual IP addresses. In Ethereum, we [04:51.770 --> 04:57.670] have the Ethereum nice service, which will help you translate human readable domain names like [04:57.670 --> 05:06.130] johndoe.eth to Ethereum addresses, such as the one there. But sometimes, most times actually, [05:06.130 --> 05:12.110] you won't have... perhaps you won't have an Ethereum address or many addresses. You might [05:12.610 --> 05:17.130] only have Solidity source code. And Solidity is the smart contract language that we use [05:17.130 --> 05:21.430] nowadays. There might be others, but Solidity is the smart contract language [05:21.430 --> 05:29.510] that is high level and that can help you code smart contracts in an easy way, let's say. So [05:31.090 --> 05:38.730] you might be given a repository with these files or you can actually find that source [05:38.730 --> 05:44.150] code in Etherscan, which is the main explorer for the Ethereum blockchain. And at this point, [05:44.910 --> 05:49.450] engagement will become something like a white box engagement, right? You will have access to [05:49.450 --> 05:55.070] the source code, but there are ways, as we will see later, to actually deploy these contracts [05:55.070 --> 06:01.650] and to start poking around with them as a living program. So there are two ways, perhaps, of [06:02.410 --> 06:10.290] approaching the assessment. So if you want to go to Etherscan, you can find the verified source [06:10.290 --> 06:15.810] code there. This is, for instance, the source code for DAI, one of the main stable coins in [06:15.810 --> 06:20.830] the Ethereum ecosystem. And you can go to its address and retrieve the source code there. [06:20.830 --> 06:28.730] But if you don't have the code, you can actually decompile the EVM bytecode and try to [06:29.990 --> 06:38.110] read it in a nicer way using EVM, right? So this is a decompiler for Solidity code [06:38.110 --> 06:47.550] and will help you understand what's behind this sometimes difficult to parse EVM bytecode [06:47.550 --> 06:54.270] and will give you a more readable way to understand it. So again, you might have the [06:54.270 --> 06:58.790] source code, but if you don't and you only have an Ethereum address, you can use this decompiler [06:58.790 --> 07:05.690] that can help you out. Well, once we are done with this scoping phase, we move on to the second one, [07:05.690 --> 07:11.590] which is reconnaissance. In reconnaissance, we basically want to understand what's in there, [07:11.590 --> 07:19.770] right? So we might be given, as I said before, a list of files. And we are not only talking about [07:19.770 --> 07:24.930] one, two, three, but many, many and several files that you might be given. And sometimes the names [07:24.930 --> 07:31.010] of these files don't even make much sense at the beginning, right? So we see here like files [07:31.010 --> 07:37.070] named flap, flip, flop. And that is not so self-explanatory, to be honest. [07:37.170 --> 07:43.830] So we need to start looking deeper into the files and to actually understand what they are doing. [07:43.830 --> 07:48.910] But when we look deeper into the files, we will see Solidity code, right? This is what [07:48.910 --> 07:55.530] actual Solidity looks like. Just a brief example for those that are not familiar with it. [07:55.530 --> 08:02.630] It looks like another object-oriented language. At the beginning, the syntax is similar. As you [08:02.630 --> 08:09.050] go deeper and deeper into Solidity, you might start seeing several differences with other languages. [08:09.050 --> 08:15.190] But again, the first look of Solidity looks like another object-oriented language. [08:16.130 --> 08:21.510] But if you go to actual files, to actual Solidity files today being used in Ethereum, [08:21.510 --> 08:28.110] you will see that sometimes developers are not that clear with their intentions of the code, [08:28.110 --> 08:33.190] and you will see that functions have weird names, some variable names are not that clear, [08:33.190 --> 08:38.670] and you cannot make much sense out of the things that you are reading in the code, right? So [08:38.670 --> 08:44.270] it might be a bit disorganized or repetitive, or the function names might not be the best, [08:44.270 --> 08:50.110] as we see in these cases. But luckily, there are tools and there are things that we can start doing [08:50.110 --> 08:55.850] in this reconnaissance phase that can help us get more familiar with the code and understand [08:55.850 --> 09:01.830] what it's trying to do. So in this case, what we want is, we want to understand the architecture, [09:01.830 --> 09:07.970] the interactions between the contracts, we want to see where the contracts expose functions, [09:07.970 --> 09:12.130] because we need to use them as entry points for attacks, we need to see the inheritance [09:12.130 --> 09:17.790] chains of this contract, and many other things, right? But I want to make a special point on [09:17.790 --> 09:26.430] intention. We as, let's say, auditors or bug hunters looking at Ethereum smart contracts, [09:26.430 --> 09:31.550] we need to understand the intention of the code, right? Intention is not usually the same as [09:32.110 --> 09:36.650] implementation, so we need to find the differences between intention and implementation, [09:36.650 --> 09:45.030] and actually start digging bugs in that sense. So special attention to the intention of the code, [09:45.030 --> 09:52.450] not only what it's actually doing, but what it intends to do. For these three last points, [09:52.450 --> 09:58.550] for the roles of a system, the integration points, and intention, the work in reconnaissance becomes [09:58.810 --> 10:05.490] a bit of a manual work, and reading documentation, reading the code, reading pull requests, perhaps [10:05.490 --> 10:11.670] talking to developers, from those things we can start understanding these points, right? But for [10:11.670 --> 10:17.450] the others, there are tools that can actually help us in a really nice way, as we are about to see. [10:17.590 --> 10:23.310] So if you want to see some things about inheritance chains, for example, you can use [10:23.310 --> 10:31.270] EtherScan, we can use Surya, Slyther, which are tools that can help us print these kind [10:31.270 --> 10:36.810] of diagrams of inheritance, and can help us understand how do contracts relate to each other [10:36.810 --> 10:44.470] in a code base. Slyther, that is a static analyzer, can also help us see which are the [10:44.470 --> 10:51.210] exposed functions of a contract, so we can see whether it has many public functions, which are [10:51.210 --> 10:57.730] these public functions, to which contracts do they belong, and if there are private functions [10:57.730 --> 11:04.750] in those contracts related to these public functions. So Slyther can help us explore this. [11:05.610 --> 11:11.510] There are also IDE plugins, such as in Visual Studio Code you have the Solidity Auditor plugin, [11:11.510 --> 11:17.590] which is super useful, and as you see here in the GIF, it can help you track, for instance, [11:17.590 --> 11:24.210] function calls. Starting from a public function call, you can go all the way down to the private [11:24.210 --> 11:30.790] calls, and see whether in this way you can track different bugs in the code. [11:31.410 --> 11:36.310] And another thing that is super useful, that I at least myself find useful, [11:36.310 --> 11:41.170] are diagrams. So these diagrams are things that you can actually draw yourself, [11:41.170 --> 11:48.430] put together yourself, and can help you out really to find several bugs in the code. So [11:48.430 --> 11:54.310] give it a shot, try it out, please don't go so crazy on it, but again can help you [11:54.310 --> 12:00.090] understand the relationships between different contracts and functions and dynamics of the system. [12:02.090 --> 12:08.530] So that's about it with reconnaissance. We have seen tools, we have seen manual things that you [12:08.530 --> 12:15.550] can use, and now let's get on to one of the most interesting parts, I guess, which is [12:15.550 --> 12:21.490] vulnerability identification. So this is one of the main objectives of our assessment, is to [12:21.490 --> 12:26.770] actually find vulnerabilities in the code. And if you're a beginner with it, I wouldn't recommend [12:26.770 --> 12:34.730] you to start trying to hack smart contracts in crazy new ways. I would suggest that you start [12:34.730 --> 12:41.730] with the basics. So you might read the Mastering Ethereum book, you can read online databases of [12:41.730 --> 12:48.510] known attacks, we have the SWC registry which classifies vulnerabilities and with different [12:48.510 --> 12:53.650] test cases. Of course not all vulnerabilities, not all weaknesses in smart contracts, but the [12:53.650 --> 13:00.210] most common ones are there, and you can go ahead and read them and start learning which are the [13:00.210 --> 13:08.390] basics of smart contract security. But if you like learning as playing, like learning by doing, [13:08.390 --> 13:15.250] you can play the Ethernode by OpenZeppelin, which is a kind of a capture the flag challenge, a set of [13:15.250 --> 13:21.030] challenges actually, and it's super fun and can help you understand how to hack smart contracts [13:21.030 --> 13:29.150] and learn about security in that way. One thing that also always surfaces when we talk about [13:29.150 --> 13:33.950] vulnerability identification in smart contracts is this difference between automated and manual [13:33.950 --> 13:38.910] work, right? I think this also happens in, for instance, application security, where you [13:38.910 --> 13:46.330] might have scanners that can help you out identify vulnerabilities in an application, [13:47.040 --> 13:55.150] but also people or pen testers, hackers, tend to also do some manual work. So I guess it's always [13:55.150 --> 14:02.010] about complementing the automated and manual work. You shouldn't fully lean towards one or another, [14:02.010 --> 14:09.490] but doing both automated and manual work to find out these vulnerabilities. [14:10.510 --> 14:16.530] So in the automated realm, we find many tools that can help us out in Ethereum [14:17.170 --> 14:21.770] for smart contracts insolidity, or perhaps you don't even need for some of these tools, [14:21.770 --> 14:26.570] the source code, you can only have the EVM bytecode. We have Slyther, Manticore, [14:26.570 --> 14:32.430] Keyedna, Mithril, Veris, Solpacale, and many more. I won't dive deeper into this. The program [14:32.430 --> 14:38.510] analysis world is extremely interesting and it's a whole world on its own. The idea of this talk [14:38.510 --> 14:46.090] is just to briefly present them. And to also mention that, of course, the automated tools, [14:46.090 --> 14:51.890] while they are good, they might have bugs, right? They might not always work as expected, [14:51.890 --> 14:57.350] they might produce false positives, and they might not even find the most critical bugs. [14:57.750 --> 15:03.330] So last year, we ended up publishing a post when we found a critical vulnerability in the [15:03.330 --> 15:10.490] MakerDAO contracts. And we realized that many of the tools weren't capable of finding that type of [15:10.490 --> 15:18.450] bug. And the forum post became really interesting when the authors of these tools jumped in and [15:18.450 --> 15:23.250] started explaining the improvements that they were applying in the tools to actually find the bug. [15:23.250 --> 15:29.710] And I think that right now, many of these tools are already capable of finding this bug that we [15:29.710 --> 15:37.170] found at MakerDAO. So the automated tool world is always moving forward and coming up with new [15:37.170 --> 15:42.770] ways of finding vulnerabilities, and that's super cool. But also, we do manual work, right? In this [15:42.770 --> 15:48.170] case, we focus on the business logic and the intention of the code. And this actually means [15:48.170 --> 15:56.690] that, at least in my experience, most of the most critical bugs that I have found in smart contracts [15:56.690 --> 16:04.510] come actually from business logic and not from, let's say, solidity common patterns. So by [16:04.510 --> 16:09.650] understanding the business logic of the contracts, you can actually start highlighting these differences [16:09.650 --> 16:15.030] between implementation and intention and start coming up with different attack vectors to break [16:15.030 --> 16:22.110] the contract. Special care should be paid to sensitive functions. And when I say [16:22.110 --> 16:29.050] sensitive, I mean functions that may have convoluted and mixed logic, functions that, [16:29.050 --> 16:35.710] let's say, handle decimals, arise signatures, which are usually not so straightforward to do [16:35.710 --> 16:42.770] in solidity. So usually developers need to come up with different hacks to implement, [16:42.770 --> 16:48.570] let's say, handling decimals. So there might be bugs there. Dangerous math, [16:50.050 --> 16:55.170] functions making external calls to untrusted contracts is also something that we should be [16:55.170 --> 17:02.110] paying attention to. And uses of assembly or low-level calls in solidity is usually [17:03.370 --> 17:10.090] a good source of vulnerabilities that I have seen in my years doing smart contract audits. [17:10.090 --> 17:15.070] So again, some of these are really important things that we should be paying attention to [17:15.070 --> 17:21.070] when we are assessing smart contracts in a manual way. But there are more, right? So we can [17:21.070 --> 17:25.610] also pay attention to the interactions with external dependencies. And in this case, [17:25.610 --> 17:31.490] let's say, other protocols, price oracles, decentralized exchanges, are points of [17:31.490 --> 17:38.910] interaction that sometimes can trigger different dynamics, different functionalities or unexpected [17:38.910 --> 17:48.810] things in the system that we are trying to break. Another thing to pay attention to is the impact [17:48.810 --> 17:56.210] of these dynamics, of novel dynamics, extreme unexpected ones, that perhaps the developers [17:56.210 --> 18:02.550] didn't take into account when they were developing the system and we should be paying attention to. [18:02.550 --> 18:08.610] So for instance, flash loans have been the big new thing recently in DeFi and Ethereum. [18:08.610 --> 18:15.590] With the introduction of flash loans, we have found that many projects ended up having problems [18:15.590 --> 18:20.750] in their dynamics, in their incentives, just because flash loans were available to everyone [18:20.750 --> 18:26.610] in the ecosystem. Having a clogged network is also something to take into account when we are [18:26.610 --> 18:32.630] analyzing smart contracts. What happens if the network is highly congested and transactions [18:32.630 --> 18:42.230] cannot go through? What happens if the price of ETH goes down by half and how would this project [18:42.230 --> 18:47.350] that I'm analyzing would react to that? Another cool thing going on right now in Ethereum is [18:47.350 --> 18:51.850] front-running, back-running and transaction ordering. So there are lots of bots right now [18:51.850 --> 18:58.510] in mainnet playing with front-running and back-running and these are things, really interesting [18:58.510 --> 19:03.090] things, that we should also take into account if we are trying to find vulnerabilities. How would [19:03.090 --> 19:11.400] the project, the contract we are seeing, react to these kind of things? Well, once we have [19:12.880 --> 19:19.380] found vulnerabilities, it's time for us to exploit them. Another fun part of doing [19:19.380 --> 19:25.680] security research is actually exploit the things that we found. To do exploiting, what we want is [19:25.680 --> 19:33.460] first to have a reproducible attack vector and that means to have some way of sharing with [19:33.460 --> 19:39.440] the client, sharing with the bug bounty report that we are about to submit, that we have a reproducible [19:39.440 --> 19:43.840] attack vector and we are proving actually that there is a vulnerability and that can be exploited [19:43.840 --> 19:50.560] under a certain scenario. And we also need to understand the impact that actually [19:50.560 --> 19:57.680] exploiting this would have in the system. And for the impact, to be honest, we usually also need to [19:57.680 --> 20:06.140] see or to actually to understand how would the system work and how the system reacts to our [20:06.140 --> 20:10.640] exploit and what is the actual impact in the business logic of the system. So we need some [20:11.200 --> 20:16.700] knowledge, business logic related knowledge, to the system that we are assessing. [20:18.460 --> 20:24.180] To do exploiting, my recommendation is to also try your exploits in a local testing environment. You [20:24.180 --> 20:30.180] shouldn't do that at mainnet, of course. So you can first spin up a local node. You can do that with [20:30.180 --> 20:37.800] ganache or with geth. Geth allows you to have a development mode so your test will run faster. [20:37.800 --> 20:41.920] And with ganache, there is a cool feature that you can do is to actually fork mainnet. [20:41.920 --> 20:51.800] And so you can point ganache to a, let's say, a full node, fork mainnet into your local environment [20:51.800 --> 20:57.960] and actually run your exploits as if they were to be run on mainnet, but you will be like [20:58.640 --> 21:04.520] causing no damage to any project out there. To interact with nodes, you can use, if you are [21:05.100 --> 21:11.180] hacking on javascript, you can use web3js or ethers, but I think that web3 is also available [21:11.180 --> 21:18.760] for python. And if you are wanting to do bigger things that perhaps it would be too difficult to [21:19.420 --> 21:25.160] only do with web3js or with ethers, you can use biddler or truffle, which are kind of frameworks [21:25.160 --> 21:34.120] or task runners that can help you do more crazy and bigger things with your exploits. [21:34.720 --> 21:39.120] These are the ones that I personally use and the ones I recommend. But of course, [21:39.120 --> 21:43.600] there might be others out in the space that can help you out too. If you want to see some [21:43.600 --> 21:48.860] exploit examples actually using some of the tools that I just mentioned, we have published in the [21:48.860 --> 21:57.020] OpenSampling GitHub repository an exploit for the Uniswap vulnerability that was found by another [21:57.020 --> 22:01.820] auditing company, by Consensus Intelligence, last year, and that we ended up publishing [22:03.240 --> 22:08.200] a proof-of-concept exploit on how that vulnerability can be exploited for some kind [22:08.200 --> 22:14.600] of tokens in Uniswap pools. And the exploit is readily available there and is public and for you [22:14.600 --> 22:21.040] to see and run it in your local machines. Interestingly, this exploit was actually, [22:21.610 --> 22:26.420] I don't know if this particular exploit, but the vulnerability was later exploited in the wild in [22:26.420 --> 22:34.720] some real Uniswap pools. I have also published myself some exploits examples in my GitHub [22:34.720 --> 22:41.120] repository. And in February this year, for example, we also at OpenSampling published [22:41.740 --> 22:46.540] a way to backdoor non-c-safe wallets, one of the most popular wallets in the space, [22:46.540 --> 22:53.020] during deployment. And in this post, I'm leaving you the link there, in this post we are [22:53.020 --> 23:01.780] actually publishing the proof-of-concept exploit on how to backdoor non-c-safe wallets during deployment. [23:02.700 --> 23:09.680] But also we have the possibility to reproduce real exploits in Ethereum. So you can see here [23:09.840 --> 23:18.600] a transaction, an execution trace of a transaction that actually stole more than 24k USDC [23:18.600 --> 23:25.880] last week on a project in Ethereum. On mainnet this is real and the attack not only [23:25.880 --> 23:33.080] was made up of this single transaction but many transactions and caused a lot of fund losses [23:33.820 --> 23:38.780] in this project. So you can actually see these transactions because transactions are public in [23:38.780 --> 23:44.900] Ethereum. You can see the interactions between the contracts and you can even go ahead and [23:44.900 --> 23:50.440] reproduce these real exploits on your local environments. So that is something pretty cool. [23:51.660 --> 23:58.180] Well, moving on, after exploiting we can begin talking about post-exploitation, right? So [23:59.180 --> 24:05.720] the big question here that I've been asking myself when preparing this talk is if this is [24:05.720 --> 24:11.400] even a thing, right? So in the application security world perhaps you might be [24:11.400 --> 24:19.920] thinking of pivoting, opening a shell, moving to other systems, jumping around the network, [24:19.920 --> 24:26.480] but perhaps in the smart contract world that is not possible or it is not that easy to [24:26.480 --> 24:32.840] draw a parallel between the smart contract and other worlds. So again, we shouldn't think of [24:32.840 --> 24:40.800] having a shell here but perhaps we can start thinking about, when thinking about post-exploitation, [24:40.800 --> 24:47.720] we can try to extend or elevate access to the smart contracts. We can cause further [24:47.720 --> 24:53.940] consequences in our components or even in other protocols by going beyond the [24:53.940 --> 24:58.980] exploited system that we are assessing, right? So in that sense there might be some parallels between [25:00.940 --> 25:09.580] in this post-exploitation phase. So let's go to an example to better see what I mean by [25:09.580 --> 25:17.200] post-exploitation here. So let's see a compromised oracle case. In this case, let's imagine [25:17.400 --> 25:21.980] a platform that is selling collectibles, is selling these kitties and you pay ETH and it [25:21.980 --> 25:28.040] will give you away some kitties depending on how much ETH you have paid. But this platform actually [25:28.040 --> 25:37.900] uses the price in ETH of these kitties but uses a price oracle to fetch the price in ETH, right? [25:37.900 --> 25:42.860] The price oracle is basically another set of contracts where the price in ETH of these kitties [25:42.860 --> 25:52.920] is registered by someone. But in this case, if you can end up finding a vulnerability in the [25:52.920 --> 25:58.160] price oracle and you can compromise the price oracle, you can actually compromise the system [25:58.160 --> 26:02.440] that is relying on that oracle, right? Because you can set, for instance, the price in ETH of [26:02.440 --> 26:07.520] this collectible to zero, you can send a transaction to buy all kitties and you can steal away all [26:07.520 --> 26:13.080] kitties in this platform. And that is not also true for a single platform that relies on this [26:13.080 --> 26:19.080] oracle, but it's also true for all platforms that are actually relying on this price oracle. This is [26:19.080 --> 26:24.100] an actual problem that I think that we have nowadays in Ethereum. The more projects that [26:24.100 --> 26:30.740] are relying on a single oracle or just a small number of oracles, the greater the incentives, [26:30.740 --> 26:36.600] the economic incentives to attack a price oracle, to compromise it and to basically pound every [26:36.600 --> 26:42.360] single project depending on it. So this is basically what I mean with post exploitation. [26:42.360 --> 26:48.420] We can compromise an oracle and by doing that we can move on to other projects and execute attacks [26:48.420 --> 27:00.650] in them as well. Moving on, we have this last phases which is about reporting, doing fixes, [27:00.650 --> 27:09.130] retests and I believe that there are many similarities with other information security [27:09.130 --> 27:15.950] realms. So I don't think I should dive deeper into this. Of course we do reporting, of course [27:15.950 --> 27:23.390] we review the fixes for our clients, of course we do retests to make sure they haven't reintroduced [27:23.390 --> 27:28.810] the vulnerability and have actually fixed the things that we have reported. So we do all of [27:28.810 --> 27:33.530] that, that is basically the same. But one thing that we should be highlighting here is that in [27:33.530 --> 27:41.770] the Ethereum world most, if not all, but most security reports are public. That is something [27:41.770 --> 27:46.390] that you don't see in other worlds. That is something that, for instance, me working as a [27:46.390 --> 27:53.570] pen tester for banks in my previous job, I wouldn't have even imagined that I could at some point make [27:53.570 --> 27:58.950] public a report, right? But in the Ethereum world that is true, you can do that, of course agreeing [27:58.950 --> 28:04.850] that with the client, but I think everyone is encouraged to actually public their security [28:04.850 --> 28:10.570] reports because in that way we can all improve the ecosystem, we can all learn about the best [28:10.570 --> 28:17.690] security practices, which things might not be the best for some types of projects, and also to have [28:17.690 --> 28:25.470] perspectives of other security auditors in the space and learn from each other and [28:26.090 --> 28:32.610] make everything in the open and as transparent as possible. So we have public security reports and [28:32.610 --> 28:38.950] you can go to, for instance, our blog at OpenZeppelin and many other companies as well are publishing [28:38.950 --> 28:44.210] their reports and you can read them and learn tons about smart contract hacking and security [28:44.210 --> 28:49.030] and research just by reading those public security reports. So that is something that I [28:49.030 --> 28:56.670] wanted to highlight because I think it's super valuable in the space. Well, and to end this talk [28:58.130 --> 29:04.430] I wanted to leave you with a little surprise, right? I don't think today I have covered many [29:04.430 --> 29:10.930] things on the technical side just because I wanted to, as I told you at the beginning, [29:10.930 --> 29:15.730] I wanted to give you the bigger picture of what does it mean to hack smart contracts and how do [29:15.730 --> 29:23.010] we structure our engagements. But if you actually want to look at code and run some exploits and [29:23.010 --> 29:31.130] try to break smart contracts, I think you might find this super useful and entertaining. It's time [29:31.130 --> 29:35.250] for you to start hacking smart contracts so you can start applying all these learnings from these [29:35.250 --> 29:40.590] phases that I have been telling you about. You can go to my github repository, it's already public, [29:40.590 --> 29:47.110] and you can start hacking a set of smart contracts that is based on a governance system [29:47.110 --> 29:53.770] using flash loans and token snapshots, all things and features super popular nowadays in the FIFA [29:53.770 --> 30:01.170] space. And here you have an example on how that can be severely broken and you can be the one [30:01.170 --> 30:08.270] attacking it and breaking it. So please have fun with it and hope to get some feedback on that if [30:08.270 --> 30:16.610] you happen to play it. So thank you very much, you can contact me on telegram, on twitter, [30:16.610 --> 30:23.070] on github and all these platforms. You can find me as Tim Chavate and you can learn more about [30:23.070 --> 30:28.810] information security related to smart contracts in our forum, in our blog at Open Zeppelin. [30:29.670 --> 30:36.090] I'm happy to help you out with anything related to this and please [30:36.990 --> 30:41.430] ping me if you find this interesting. So thank you!