 Hey everyone, my name is Martin. Thank you for having me today. I will be talking about the seven phases of a smart contract hacking In this talk my my idea is not not to jump and dive into technical parts of what it means to hack a smart contracts but actually I want to give a little bit of perspective and Try to talk about the bigger picture of what does it actually mean to hack a smart contracts? so if you're up and tested if you are not a back hunter a Perhaps working in application security or or other realms of information security. You can jump into the Ethidium ecosystem and start helping us secure the entire platform. So a little bit of background about myself. I'm Martin I'm a security researcher open sapling one of the leading companies in a smart contract audits in ethidium I'm a systems engineer. I'm doing a master's degree in cybersecurity and cyber defense at the University of Buenos Aires And I used to work as a pentester mainly on application security infrastructure mobile applications web applications at a big four and Then I jumped into being a security researcher here open sapling Well, let's say again that you are a pentester. You might be a back hunter a white hat hacker and Perhaps working other realms of information security But you're interested in blockchains in smart contracts You have heard about them because to be honest, we have hit the headlines a couple of times There has been many hacks in the latest months Around smart contracts in ethidium so as you see many hacks and In my opinion, we need more and more security experts to jump into the field and to help us secure the entire ecosystem So this talk is mainly aimed at you And the question is if you can hack a smart contract, right? If what knowledge do you have already that can help you out here? In the smart contract world and that you can start applying today to start hacking smart contracts And well the answer is yes that you do have some knowledge Because you do know which are the seven faces, let's say of a typical security engagement I'm gonna say seven. I don't mean to be strict with these faces that we'll be talking about It's just a way of organizing the talk But perhaps when you do back hunting some faces you might skip them or you might do others But the idea is to outline our work as security auditors or back hunters or what hackers in these seven faces So we can have a common language So to talk about this well These are the seven faces that I have That we will be talking about first is scoping the reconnaissance identification of vulnerabilities Exploiting these vulnerabilities that we have found What does it actually mean to do post Exploitation is in the smart contract world and we will be asking ourselves if whether that's an actual thing or not And then we'll be briefly covering reporting fixes and retest So you might be already familiar with these faces The idea of today is to see how these faces apply in the smart contract world And where we can start drawing some parallels between these faces and the ones that you are used to to apply So let's get started Let's talk about scoping If you come from the let's say application security world or maybe doing pen testing for infrastructure Exposed on the internet. You might be familiar with the fact that you have IP addresses, right? You When you are scoping your work, you will be given an IP addresses that will help you understand the systems that you that you are about to audit or assess In the Ethereum case, we also have addresses in this case. We have Ethereum addresses. I know they are not the same I know there are many differences between them by the idea is to start drawing as I said before some parallels between the worlds So we can think about these addresses as ways of allocating like not allocating but Locating resources, let's say in the first case on a network and in the other case on the blockchain When you are working in smart contracts, you will not only have a one Ethereum address But you can have many Ethereum addresses that are related to each other And you may not even have Ethereum addresses, but actually you can have domain names, right? As in the classic world, you have the DNS that will help you resolve from read human readable Names to actual IP addresses in Ethereum We have the Ethereum nice service which will help you translate Human readable domain names like John Doe.ith to Ethereum addresses such as Wonder But sometimes most times actually you won't have perhaps you won't have an Ethereum address or many addresses You may be you might only have Solidity source code and Solidity is the smart contract language that we use Nowadays there might be others but today is the smart contract language that is high-level and that can help you code smart contracts in an easy way, let's say so You might be given a Repository with these files or you can actually find that source code in Ethereum scan Which is the main explorer for the Ethereum blockchain and at this point the Engagement will become something like a white box engagement, right? You will have access to the source code, but there are ways as we will see later So actually deploy these contracts and to start poking around with them last living program So there are two ways perhaps of of approaching the the assessment So if you want to go to ether scan you can find the verify source source code there This is for instance the source code for die one of the main stable coins in the Ethereum ecosystem And you can go to its address and retrieve the source code there But if you don't have the code you can actually decompile the evm bytecode and try to Read it in a more in a more like a nicer way using evm, right? So this is a decompiler for Solidity code and will help you Understand what's what's behind this is sometimes difficult to parse evm bytecode and will give you a more readable way to understand it and So again, you might have the source codes But if you don't and you only have an Ethereum address you can use this the compiler that can help you out Well, once we are done with this scoping phase we move on to the second one which is reconnaissance in reconnaissance We basically once want to understand what's in there, right? so we might be given as I said before a list of files and We are not only talking about one two three But many many and several files that you might be given and sometimes the names of these files don't even Make much sense at the beginning, right? So you we see here like files names flap flip flop and there is not so self-explanatory to be honest so We need to start looking deeper into the files and to actually understand what they are doing But when we look when we look deeper into the files, we will see Solidity code, right? This is what actually actual Solidity looks like And just a brief example for those that are not familiar with it It looks like another object oriented language at the beginning the six the syntax is similar as you go deeper and deeper into Solidity You might start seeing Several differences with our languages, but again the first look of Solidity looks like another object oriented language But if you go to actual files to actual Solidity files today being used in Ethereum You will see that sometimes developers Are not that clear with their intentions of the code and you will see that functions Have weird names and variable names are not that clear and you cannot make much sense out of The things that you already in the code, right? So it might be a bit disorganized or repetitive or the function nice might not be the best as we see in these cases But luckily there are tools and there are things that we can start doing in this reconnaissance phase that we can help us Get more familiar with the code understand what it's trying to do So in this case what we want is a we want to understand the architecture the interactions between the contracts We want to see where the contracts expose functions because we need to use the mass entry point for attacks We need to see the inheritance chains of this contract and many other things, right? But I want to make a special point on the intention we as Let's say auditors or backhunters looking at the Ethereum smart contracts We need to understand the intention of the code right intention is not usually the same as Implementation so we need to find the differences between intention and implementation and actually start digging bugs in that in that sense So a special attention to the intention of the code and not only what it's actually doing, but what is what it intends to do? For these three last points for the roles of the system the integration points and intention the work in reconnaissance becomes a bit of a Manual work and reading documentation ring the code we input requests Perhaps talking to developers From those things we can start understanding these points, right? But for the others there are tools that can actually help us In a really nice way as we are about to see so if you want to see Some things about inheritance chains. For example, you can use ether scan. We can use Surya Slither, which are tools That can help us print This kind of theorems of inheritance and can help us understand how do contracts relate to each other in a codebase It's a slither that is ecstatic analyzer can also help us See which are the exposed functions of a contract so we can see where it has many public functions Which are these public functions how they To which contracts do I belong and if there are private functions so in those contracts related to the spread to these public functions So it's easier can help us explore this There are also ID plugins such as in visual studio code You have the soliti auditor plug-in which is super useful and as you see here in the give it can help you track for instance Function calls and starting from a public function call You can go all the way down to the private calls and see Whether in this way you can track different bugs in the code And another thing that is super useful that I at least myself and useful Are diagrams so these diagrams are things that you can actually draw yourself put you better yourself and Can help you out really to find Several bugs in the code. So give it a shot try it out Please don't go so crazy on it. But again can help you Understand the relationships between different contracts and functions and dynamics of the system So that's about it with reconnaissance. We have seen tools. We have seen Manual things that you can use And now let's get on to One of the most interesting parts I guess which is vulnerability identification So this is one of the main objectives of our assessment is to actually find vulnerabilities in the code And if you're a beginner with it, uh, I wouldn't recommend you to start trying to hack Smart contracts in crazy new ways. I would suggest that you start with the basics So you might read the master team ethereum book. You can read online databases of known attacks We have the swc registry which classifies vulnerabilities and With different test cases, uh, of course, not all vulnerabilities nor all witnesses in smart contracts But the most common ones, uh, are there and you can go ahead and read them And start learning which are the basics of smart contact security But if you like learning with as playing, uh, like learning by doing you can Play the ethanol by open sampling, which is a kind of a capture the flag challenge A set of challenges actually And it's super fun and can help you understand how to hack smart contracts and learn about security in that way One thing that also, uh, always, uh, surfaces when we talk about vulnerability identification in smart contracts Is this difference between automated and manual work, right? I think this also happens in, for instance, application security where where you may have like scanners that can help you out Identify vulnerabilities in an application But all Also people or pentesters hackers tend to also do some manual work So I guess it's always, uh, about Complimenting the automated manual work. You shouldn't lean fully lean towards one on another But doing both automated and manual Work to to find out these vulnerabilities And so in the automated, uh realm We find many tools that can help us out in Ethereum For smart contracts in Solidity or perhaps you don't even need for some of these tools the the source code You can only have the even ebm bytecode. We have a sleet there mantic or a key Nami three various olpacala and many more Uh, I won't dive deeper into this the the program analysis world is Extremely interesting and it's a whole world on its own. The idea of this talk is just to briefly Uh, present them Uh, and to also mention that of course the automated tools we while they are good They might have bugs, right? They might not always work as expected They might produce false positive and they may not even find The most critical bugs. Uh, so last year we Ended up publishing a post when we found a critical vulnerability in the maker. Now contracts Uh, and we realized that many of the tools weren't capable of finding that that type of bag And the forum post became really interesting with when the The authors of these tools Jumped in and started explaining the improvements that they were applying in the tools to actually find the bag And I think that right now many of these tools are already capable of finding the This bag that we found at maker So the automated tool world is is always moving forward and coming up with new ways of finding vulnerabilities. That's super cool But also we do manual work, right in this case we focus on the business logic and the intention of the code And this actually means that uh, at least in it at least in my experience Most of the most critical bugs that I have found in smart contracts come actually from business logic Uh, and not from let's say solely common patterns So by understanding the business logic of the contracts, you can actually start Uh, highlighting these differences between implementation and intention and start coming up with different attack vectors to break the contract Uh, special care should be paid to sensitive functions. And when I mean when I say sensitive I mean Functions that may have convoluted and mixed logic functions that uh, let's say handle decimals Arrive signatures, which are usually not so straightforward to do in Insolidity so usually developers need to come and come with different hacks to to implement. Let's say handling decimals So, uh, there might be bugs there dangerous math and Functions making external calls to untrusted contracts is also something that we should be paying attention to and uh users of assembly or low level calls in Solidity is usually Uh, a good source of vulnerabilities that I have seen In my years doing doing smart contracts So again, some of these Are really important things that we should be paying attention to when we are assessing Smart contracts in a manual way But there are more right so we can also pay attention to the interactions with external dependencies And in this case, let's say other protocols price order calls decentralized exchanges are points of interaction that Sometimes can trigger different dynamics different functionalities or unexpected things in the in the system that we are trying to break Uh, another thing to to pay attention to is the impact of these dynamics of novel dynamics extreme I'm expected ones that Perhaps the developers didn't take into account with when they were developing the system and we Should be paying attention to so for instance Flash loans have been the big new thing recently in defying ethereum and with with the introduction of flash loans. We have found that Many projects ended up having problems in their dynamics and their incentives just because flash loans were available to everyone in the ecosystem Having a clocked network is also something to take into account when we are analyzing smart contracts. What happened if The network is highly congested and transactions cannot go through What happens if the price of heat goes down? by half And how would this project that i'm analyzing would react to that And another cool thing going on right now in ethereum is front running back running and transaction ordering So there are lots of bots right now in my net Playing with front running and back running and these are things really interesting things that we should also take into account If we are trying to find vulnerabilities, right? How would the project the contract we are seeing reacts to these kind of things? well once we have a Found vulnerabilities is time for us to exploit them right another fun part of being of doing security research is Actually exploit the things that we found To do exploiting what we want is actually first to have an reproducible attack vector and that means Have some way of sharing with the clients sharing with The bug bounty report that we are how to submit that we have a reproducible attack vector And we are proving actually that there is a vulnerability and that can be exploited and there is a certain scenario right And we also need to understand the impact that this Actually exploiting this would have in the system And for the impact to be honest, we usually also need to see Or to actually to understand How would the system Work and how would the system react to our exploit and what is the actual impact in the business logic of the system, right? So we need some knowledge Business logic related knowledge to the system that we are we are assessing To do exploiting my recommendation is to also try your exploits in a local testing environment You shouldn't do that at main net, of course So you can first spin up a local node. You can do that with ganache or with geth Geth allows you to have a development mode. So Your test will run faster and with ganache. There is a cool feature that you can do is to actually fork main net and So you can Point ganache to a Let's say a full node fork main net into your local environment And actually run your exploits as if they were to be run on main net But you will be like Causing no damage to any project out there To interact with nodes, you can use if you are Hacking on javascript. You can use web 3.js or ethers But I think that web 3 is also available for python and if you are wanting to do bigger things That perhaps It would be too difficult to only to only do with web 3.js or ethers You can use bidler or travel which are kind of frameworks or Tax tax runners that can help you Do more crazy and bigger things with your exploits These are the ones that I personally use and the ones I recommend But of course there might be others out in the space that can help you out too If you want to see some exploit examples actually using some of the tools that I just mentioned We have published in the open sapling github repository An exploit for the uniswap vulnerability that was found by another auditing company by consensus deletions last year And that we ended up publishing A proof of concept Exploit on how that vulnerability would come exploited for some kind of tokens in uniswap pools And the exploit is readily available there and it's public and for you to See and run it in your local machines. Interestingly this exploit was actually I don't know if this particular exploit but the vulnerability was later exploited in the wild in some real uniswap pools I have also published myself some Exploits example in my github repository And in February this year, for example, we also at open sapling publish A way to backdoor nosy safe wallets one of the most most popular wallets in the space during deployment And we in this post that I keep leaving you the link there in this post We are actually publishing the proof of concept exploit on how to Backdoor nosy safe wallets during deployment But also we have the possibility to to reproduce real exploits in Ethereum So you can see here a transaction an execution trace of a transaction that actually Stole More than 24 k usdc last week on approaching in Ethereum on main net. This is real And we there this the attack not only was made up of a single transaction, but many transactions and cost a lot of fund losses In this project So you can actually see these transactions because transactions are public in Ethereum. You can see The interactions between the contracts and you can even go ahead and reproduce these real exploits on your local environments So that is something something pretty cool Well, moving on after exploiting we can begin talking about post exploit exploitation, right? So The big question here that I I've been asking myself myself when preparing this talk if this is if this is even a thing, right? so In the application security world, perhaps you might be thinking of like pivoting open in a shell moving to our systems Champing around the network, but perhaps in this in the smart contract world that is not possible or that is It is not that easy to draw draw a parallel between the smart contract and our walls so Again, we shouldn't think of having a shell here But perhaps we can start thinking about when thinking about posted exploitation. We can Try to extend or elevate access to the smart contracts We can cost for the consequences in our components or even even In other protocols by going beyond beyond the exploited system that we are assessing, right? So in that sense, there might be some parallels between In this post exploitation phase, sorry So, uh, let's go to an example to see to better see what I mean by post exploitation hero So let's see a compromise oracle case In this case, we have a let's imagine a platform that is selling collectibles is selling these kitties And you pay it and it will give you away some kitties depending on how much if you have paid But this platform actually uses the price in In each of these kitties But uses a price oracle to fetch the price in it, right? The price oracle is basically another set of contracts where the price in each of these kitties is registered by someone and But in this case if you Can end up finding a vulnerability in the price oracle and you can compromise the price oracle You can actually compromise The system that is relying on the right because you can set for instance the price in each of these collectibles to zero You can send a transaction to buy all kitties and you can steal away all kitties in this platform And that is not also true for a single platform that relies on this oracle, but it's also true for all A platforms that are actually relying on this price oracle This is an actual problem that I think that we have nowadays in ethereum The more pro projects that are relying on a single oracle or just a small number of oracles The greater the incentives the economic incentives to attack a price oracle to compromise it and to Basically pound every single project depending on it So this is basically what I mean with post exploitation We can compromise an oracle and by doing that we can move on to other projects and execute attacks in in in them as well moving on We have these Last phases which is about reporting doing fixes doing retests and I believe that There are many many many similarities with the With our information security realms. So I don't think I should dive deeper into this Um, of course we do reporting of course we review the fixes for our clients. Of course, we do retest to make sure they They haven't reintroduced the vulnerability and have actually fixed the things the things that we have reported So we do all of that. That is basically the same But one thing that we should be highlighting here is that in the ethereum world Most if not all but most Uh security reports are public. There is something that you don't see in other words, right? There is something that for instance me working as a pen tester for banks in my previous job I wouldn't have even imagined that I could at some point make public a report, right? But in the ethereum world that is true. You can do that. Of course agreeing that with the client But um, I think everyone is encouraged to actually public their security reports because in that way we can all Improve the ecosystem. We cannot learn about the best security practices with which things might not be the best for Sometimes of projects and also to have the perspective of other security auditors in the space and Yeah, learn from from each other and and make everything In the open and as transparent as possible So we have public security reports and you can go to for instance our blog at open sepuline And many other companies as well are publishing their reports and you can read them and learn tons about Smart contract hacking and security and research just by reading those public security reports So that is something that I wanted to highlight because I think it's super valuable in the space Um, well and to end this talk Uh, I I wanted to leave you with a little surprise, right? I don't think Today I I have covered many things Like technical on the technical side just because I wanted to as I told you at the beginning I wanted to give you like the bigger picture of what does it mean to hack smart contracts and how do we structure our engagements? um But if you actually want to look at code and run some exploits and try to break smart contracts I think you might find this super Useful and entertaining It's time for you to start hacking smart contracts So you can start applying all these learnings from these phases that I have been telling you about You can go to my github repository. It's already public and you can start hacking a set of smart contracts That is based on a governance system using flash loans and token snapshots all things and features super popular nowadays in the fee space and here you have An example on how that can be severely broken and you can be the one attacking it and breaking it. So please have fun with it and Hope hope to get some feedback on that if you if you happen to play it So, thank you very much. You can contact me on Telegram on twitter on github and all these platforms and you can find me as tinge abate And you can learn more about information security related to smart contracts in our forum in our blog at openseparim and yeah, happy to Happy to help you out with anything related to this and yeah, please Ping me if you find this interesting. So thank you