start	end	text
1570	7150	Hey everyone, my name is Martin, thank you for having me. Today I will be talking about the
7150	15810	seven phases of smart contract hacking. In this talk my idea is not to jump and dive into technical
15810	21610	parts of what it means to hack smart contracts, but actually I want to give a little bit of
21610	27370	perspective and try to talk about the bigger picture of what does it actually mean to hack
27370	34910	smart contracts. So if you're a pentester, if you're a bug hunter, perhaps working in application
34910	43250	security or other realms of information security, you can jump into the Ethereum ecosystem and start
43250	49690	helping us secure the entire platform. So a little bit of background about myself, I'm Martin,
50370	55430	I'm a security researcher at Open Zeppelin, one of the leading companies in smart contract audits
55430	60570	in Ethereum. I'm a systems engineer, I'm doing a master's degree in cyber security and cyber
60570	65850	defense at the University of Buenos Aires, and I used to work as a pentester mainly on application
65850	73250	security, infrastructure, mobile applications, web applications at a big four. And then I jumped
73250	78670	into being a security researcher here at Open Zeppelin. Well let's say again that you're a
78670	85350	pentester, you might be a bug hunter, a white hat hacker, perhaps working in other realms of
85350	91610	information security, but you're interested in blockchains and smart contracts, you have heard
91610	98650	about them, because to be honest we have hit the headlines a couple of times. There has been many
98650	108530	hacks in the latest months around smart contracts in Ethereum. So as you see, many hacks and in my
108530	113230	opinion we need more and more security experts to jump into the field and to help us secure the
113230	119910	entire ecosystem. So this talk is mainly aimed at you. And the question is if you can hack a
119910	125310	smart contract, right? What knowledge do you have already that can help you out here
125310	132570	in the smart contract world and that you can start applying today to start hacking smart contracts?
132570	137110	And well the answer is yes, that you do have some knowledge, because you do know which are
137110	142670	the seven phases, let's say, of a typical security engagement. And when I say seven,
142670	147630	I don't mean to be strict with these phases that we will be talking about. It's just a way of
147630	154110	organizing the talk, but perhaps when you do bug hunting, some phases you might skip them or you
154110	160790	might do others, but the idea is to outline our work as security auditors or bug hunters or white
160790	168530	hackers in these seven phases, so we can have a common language to talk about this.
169310	175290	Well, these are the seven phases that I have, that we will be talking about. First,
175290	180090	scoping, then reconnaissance, identification of vulnerabilities, exploiting these vulnerabilities
180090	186550	that we have found. What does it actually mean to do post-exploitation in the smart contract world?
186550	190610	And we'll be asking ourselves whether that's an actual thing or not.
190690	196750	And then we'll be briefly covering reporting fixes and retests. So you might be already familiar with
196750	202090	these phases. The idea of today is to see how these phases apply in the smart contract world
202630	206370	and whether we can start drawing some parallels between these phases
207110	215050	and the ones that you are used to applying. So let's get started. Let's talk about scoping.
216110	221270	If you come from the, let's say, application security world or maybe doing pen testing for
221270	227570	infrastructure exposed on the internet, you might be familiar with the fact that you have IP
227570	235530	addresses, right? When you are scoping your work, you will be given IP addresses that will help you
235530	243210	understand the systems that you are about to audit or to assess. In the Ethereum case,
243210	247910	we also have addresses. In this case, we have Ethereum addresses. I know they are not the same.
247910	252930	I know there are many differences between them, but the idea is to start drawing, as I said before,
252930	264370	some parallels between the worlds. So we can think of these addresses as ways of allocating resources,
264370	267810	let's say, in the first case on a network and in the other case on the blockchain.
269290	274590	When you are working on smart contracts, you will not only have one Ethereum address, but you can
274590	279010	have many Ethereum addresses that are related to each other. And you may not even have Ethereum
279010	285010	addresses, but actually you can have domain names, right? As in the classic world, you have the DNS
285010	291770	that will help you resolve from human readable names to actual IP addresses. In Ethereum, we
291770	297670	have the Ethereum nice service, which will help you translate human readable domain names like
297670	306130	johndoe.eth to Ethereum addresses, such as the one there. But sometimes, most times actually,
306130	312110	you won't have... perhaps you won't have an Ethereum address or many addresses. You might
312610	317130	only have Solidity source code. And Solidity is the smart contract language that we use
317130	321430	nowadays. There might be others, but Solidity is the smart contract language
321430	329510	that is high level and that can help you code smart contracts in an easy way, let's say. So
331090	338730	you might be given a repository with these files or you can actually find that source
338730	344150	code in Etherscan, which is the main explorer for the Ethereum blockchain. And at this point,
344910	349450	engagement will become something like a white box engagement, right? You will have access to
349450	355070	the source code, but there are ways, as we will see later, to actually deploy these contracts
355070	361650	and to start poking around with them as a living program. So there are two ways, perhaps, of
362410	370290	approaching the assessment. So if you want to go to Etherscan, you can find the verified source
370290	375810	code there. This is, for instance, the source code for DAI, one of the main stable coins in
375810	380830	the Ethereum ecosystem. And you can go to its address and retrieve the source code there.
380830	388730	But if you don't have the code, you can actually decompile the EVM bytecode and try to
389990	398110	read it in a nicer way using EVM, right? So this is a decompiler for Solidity code
398110	407550	and will help you understand what's behind this sometimes difficult to parse EVM bytecode
407550	414270	and will give you a more readable way to understand it. So again, you might have the
414270	418790	source code, but if you don't and you only have an Ethereum address, you can use this decompiler
418790	425690	that can help you out. Well, once we are done with this scoping phase, we move on to the second one,
425690	431590	which is reconnaissance. In reconnaissance, we basically want to understand what's in there,
431590	439770	right? So we might be given, as I said before, a list of files. And we are not only talking about
439770	444930	one, two, three, but many, many and several files that you might be given. And sometimes the names
444930	451010	of these files don't even make much sense at the beginning, right? So we see here like files
451010	457070	named flap, flip, flop. And that is not so self-explanatory, to be honest.
457170	463830	So we need to start looking deeper into the files and to actually understand what they are doing.
463830	468910	But when we look deeper into the files, we will see Solidity code, right? This is what
468910	475530	actual Solidity looks like. Just a brief example for those that are not familiar with it.
475530	482630	It looks like another object-oriented language. At the beginning, the syntax is similar. As you
482630	489050	go deeper and deeper into Solidity, you might start seeing several differences with other languages.
489050	495190	But again, the first look of Solidity looks like another object-oriented language.
496130	501510	But if you go to actual files, to actual Solidity files today being used in Ethereum,
501510	508110	you will see that sometimes developers are not that clear with their intentions of the code,
508110	513190	and you will see that functions have weird names, some variable names are not that clear,
513190	518670	and you cannot make much sense out of the things that you are reading in the code, right? So
518670	524270	it might be a bit disorganized or repetitive, or the function names might not be the best,
524270	530110	as we see in these cases. But luckily, there are tools and there are things that we can start doing
530110	535850	in this reconnaissance phase that can help us get more familiar with the code and understand
535850	541830	what it's trying to do. So in this case, what we want is, we want to understand the architecture,
541830	547970	the interactions between the contracts, we want to see where the contracts expose functions,
547970	552130	because we need to use them as entry points for attacks, we need to see the inheritance
552130	557790	chains of this contract, and many other things, right? But I want to make a special point on
557790	566430	intention. We as, let's say, auditors or bug hunters looking at Ethereum smart contracts,
566430	571550	we need to understand the intention of the code, right? Intention is not usually the same as
572110	576650	implementation, so we need to find the differences between intention and implementation,
576650	585030	and actually start digging bugs in that sense. So special attention to the intention of the code,
585030	592450	not only what it's actually doing, but what it intends to do. For these three last points,
592450	598550	for the roles of a system, the integration points, and intention, the work in reconnaissance becomes
598810	605490	a bit of a manual work, and reading documentation, reading the code, reading pull requests, perhaps
605490	611670	talking to developers, from those things we can start understanding these points, right? But for
611670	617450	the others, there are tools that can actually help us in a really nice way, as we are about to see.
617590	623310	So if you want to see some things about inheritance chains, for example, you can use
623310	631270	EtherScan, we can use Surya, Slyther, which are tools that can help us print these kind
631270	636810	of diagrams of inheritance, and can help us understand how do contracts relate to each other
636810	644470	in a code base. Slyther, that is a static analyzer, can also help us see which are the
644470	651210	exposed functions of a contract, so we can see whether it has many public functions, which are
651210	657730	these public functions, to which contracts do they belong, and if there are private functions
657730	664750	in those contracts related to these public functions. So Slyther can help us explore this.
665610	671510	There are also IDE plugins, such as in Visual Studio Code you have the Solidity Auditor plugin,
671510	677590	which is super useful, and as you see here in the GIF, it can help you track, for instance,
677590	684210	function calls. Starting from a public function call, you can go all the way down to the private
684210	690790	calls, and see whether in this way you can track different bugs in the code.
691410	696310	And another thing that is super useful, that I at least myself find useful,
696310	701170	are diagrams. So these diagrams are things that you can actually draw yourself,
701170	708430	put together yourself, and can help you out really to find several bugs in the code. So
708430	714310	give it a shot, try it out, please don't go so crazy on it, but again can help you
714310	720090	understand the relationships between different contracts and functions and dynamics of the system.
722090	728530	So that's about it with reconnaissance. We have seen tools, we have seen manual things that you
728530	735550	can use, and now let's get on to one of the most interesting parts, I guess, which is
735550	741490	vulnerability identification. So this is one of the main objectives of our assessment, is to
741490	746770	actually find vulnerabilities in the code. And if you're a beginner with it, I wouldn't recommend
746770	754730	you to start trying to hack smart contracts in crazy new ways. I would suggest that you start
754730	761730	with the basics. So you might read the Mastering Ethereum book, you can read online databases of
761730	768510	known attacks, we have the SWC registry which classifies vulnerabilities and with different
768510	773650	test cases. Of course not all vulnerabilities, not all weaknesses in smart contracts, but the
773650	780210	most common ones are there, and you can go ahead and read them and start learning which are the
780210	788390	basics of smart contract security. But if you like learning as playing, like learning by doing,
788390	795250	you can play the Ethernode by OpenZeppelin, which is a kind of a capture the flag challenge, a set of
795250	801030	challenges actually, and it's super fun and can help you understand how to hack smart contracts
801030	809150	and learn about security in that way. One thing that also always surfaces when we talk about
809150	813950	vulnerability identification in smart contracts is this difference between automated and manual
813950	818910	work, right? I think this also happens in, for instance, application security, where you
818910	826330	might have scanners that can help you out identify vulnerabilities in an application,
827040	835150	but also people or pen testers, hackers, tend to also do some manual work. So I guess it's always
835150	842010	about complementing the automated and manual work. You shouldn't fully lean towards one or another,
842010	849490	but doing both automated and manual work to find out these vulnerabilities.
850510	856530	So in the automated realm, we find many tools that can help us out in Ethereum
857170	861770	for smart contracts insolidity, or perhaps you don't even need for some of these tools,
861770	866570	the source code, you can only have the EVM bytecode. We have Slyther, Manticore,
866570	872430	Keyedna, Mithril, Veris, Solpacale, and many more. I won't dive deeper into this. The program
872430	878510	analysis world is extremely interesting and it's a whole world on its own. The idea of this talk
878510	886090	is just to briefly present them. And to also mention that, of course, the automated tools,
886090	891890	while they are good, they might have bugs, right? They might not always work as expected,
891890	897350	they might produce false positives, and they might not even find the most critical bugs.
897750	903330	So last year, we ended up publishing a post when we found a critical vulnerability in the
903330	910490	MakerDAO contracts. And we realized that many of the tools weren't capable of finding that type of
910490	918450	bug. And the forum post became really interesting when the authors of these tools jumped in and
918450	923250	started explaining the improvements that they were applying in the tools to actually find the bug.
923250	929710	And I think that right now, many of these tools are already capable of finding this bug that we
929710	937170	found at MakerDAO. So the automated tool world is always moving forward and coming up with new
937170	942770	ways of finding vulnerabilities, and that's super cool. But also, we do manual work, right? In this
942770	948170	case, we focus on the business logic and the intention of the code. And this actually means
948170	956690	that, at least in my experience, most of the most critical bugs that I have found in smart contracts
956690	964510	come actually from business logic and not from, let's say, solidity common patterns. So by
964510	969650	understanding the business logic of the contracts, you can actually start highlighting these differences
969650	975030	between implementation and intention and start coming up with different attack vectors to break
975030	982110	the contract. Special care should be paid to sensitive functions. And when I say
982110	989050	sensitive, I mean functions that may have convoluted and mixed logic, functions that,
989050	995710	let's say, handle decimals, arise signatures, which are usually not so straightforward to do
995710	1002770	in solidity. So usually developers need to come up with different hacks to implement,
1002770	1008570	let's say, handling decimals. So there might be bugs there. Dangerous math,
1010050	1015170	functions making external calls to untrusted contracts is also something that we should be
1015170	1022110	paying attention to. And uses of assembly or low-level calls in solidity is usually
1023370	1030090	a good source of vulnerabilities that I have seen in my years doing smart contract audits.
1030090	1035070	So again, some of these are really important things that we should be paying attention to
1035070	1041070	when we are assessing smart contracts in a manual way. But there are more, right? So we can
1041070	1045610	also pay attention to the interactions with external dependencies. And in this case,
1045610	1051490	let's say, other protocols, price oracles, decentralized exchanges, are points of
1051490	1058910	interaction that sometimes can trigger different dynamics, different functionalities or unexpected
1058910	1068810	things in the system that we are trying to break. Another thing to pay attention to is the impact
1068810	1076210	of these dynamics, of novel dynamics, extreme unexpected ones, that perhaps the developers
1076210	1082550	didn't take into account when they were developing the system and we should be paying attention to.
1082550	1088610	So for instance, flash loans have been the big new thing recently in DeFi and Ethereum.
1088610	1095590	With the introduction of flash loans, we have found that many projects ended up having problems
1095590	1100750	in their dynamics, in their incentives, just because flash loans were available to everyone
1100750	1106610	in the ecosystem. Having a clogged network is also something to take into account when we are
1106610	1112630	analyzing smart contracts. What happens if the network is highly congested and transactions
1112630	1122230	cannot go through? What happens if the price of ETH goes down by half and how would this project
1122230	1127350	that I'm analyzing would react to that? Another cool thing going on right now in Ethereum is
1127350	1131850	front-running, back-running and transaction ordering. So there are lots of bots right now
1131850	1138510	in mainnet playing with front-running and back-running and these are things, really interesting
1138510	1143090	things, that we should also take into account if we are trying to find vulnerabilities. How would
1143090	1151400	the project, the contract we are seeing, react to these kind of things? Well, once we have
1152880	1159380	found vulnerabilities, it's time for us to exploit them. Another fun part of doing
1159380	1165680	security research is actually exploit the things that we found. To do exploiting, what we want is
1165680	1173460	first to have a reproducible attack vector and that means to have some way of sharing with
1173460	1179440	the client, sharing with the bug bounty report that we are about to submit, that we have a reproducible
1179440	1183840	attack vector and we are proving actually that there is a vulnerability and that can be exploited
1183840	1190560	under a certain scenario. And we also need to understand the impact that actually
1190560	1197680	exploiting this would have in the system. And for the impact, to be honest, we usually also need to
1197680	1206140	see or to actually to understand how would the system work and how the system reacts to our
1206140	1210640	exploit and what is the actual impact in the business logic of the system. So we need some
1211200	1216700	knowledge, business logic related knowledge, to the system that we are assessing.
1218460	1224180	To do exploiting, my recommendation is to also try your exploits in a local testing environment. You
1224180	1230180	shouldn't do that at mainnet, of course. So you can first spin up a local node. You can do that with
1230180	1237800	ganache or with geth. Geth allows you to have a development mode so your test will run faster.
1237800	1241920	And with ganache, there is a cool feature that you can do is to actually fork mainnet.
1241920	1251800	And so you can point ganache to a, let's say, a full node, fork mainnet into your local environment
1251800	1257960	and actually run your exploits as if they were to be run on mainnet, but you will be like
1258640	1264520	causing no damage to any project out there. To interact with nodes, you can use, if you are
1265100	1271180	hacking on javascript, you can use web3js or ethers, but I think that web3 is also available
1271180	1278760	for python. And if you are wanting to do bigger things that perhaps it would be too difficult to
1279420	1285160	only do with web3js or with ethers, you can use biddler or truffle, which are kind of frameworks
1285160	1294120	or task runners that can help you do more crazy and bigger things with your exploits.
1294720	1299120	These are the ones that I personally use and the ones I recommend. But of course,
1299120	1303600	there might be others out in the space that can help you out too. If you want to see some
1303600	1308860	exploit examples actually using some of the tools that I just mentioned, we have published in the
1308860	1317020	OpenSampling GitHub repository an exploit for the Uniswap vulnerability that was found by another
1317020	1321820	auditing company, by Consensus Intelligence, last year, and that we ended up publishing
1323240	1328200	a proof-of-concept exploit on how that vulnerability can be exploited for some kind
1328200	1334600	of tokens in Uniswap pools. And the exploit is readily available there and is public and for you
1334600	1341040	to see and run it in your local machines. Interestingly, this exploit was actually,
1341610	1346420	I don't know if this particular exploit, but the vulnerability was later exploited in the wild in
1346420	1354720	some real Uniswap pools. I have also published myself some exploits examples in my GitHub
1354720	1361120	repository. And in February this year, for example, we also at OpenSampling published
1361740	1366540	a way to backdoor non-c-safe wallets, one of the most popular wallets in the space,
1366540	1373020	during deployment. And in this post, I'm leaving you the link there, in this post we are
1373020	1381780	actually publishing the proof-of-concept exploit on how to backdoor non-c-safe wallets during deployment.
1382700	1389680	But also we have the possibility to reproduce real exploits in Ethereum. So you can see here
1389840	1398600	a transaction, an execution trace of a transaction that actually stole more than 24k USDC
1398600	1405880	last week on a project in Ethereum. On mainnet this is real and the attack not only
1405880	1413080	was made up of this single transaction but many transactions and caused a lot of fund losses
1413820	1418780	in this project. So you can actually see these transactions because transactions are public in
1418780	1424900	Ethereum. You can see the interactions between the contracts and you can even go ahead and
1424900	1430440	reproduce these real exploits on your local environments. So that is something pretty cool.
1431660	1438180	Well, moving on, after exploiting we can begin talking about post-exploitation, right? So
1439180	1445720	the big question here that I've been asking myself when preparing this talk is if this is
1445720	1451400	even a thing, right? So in the application security world perhaps you might be
1451400	1459920	thinking of pivoting, opening a shell, moving to other systems, jumping around the network,
1459920	1466480	but perhaps in the smart contract world that is not possible or it is not that easy to
1466480	1472840	draw a parallel between the smart contract and other worlds. So again, we shouldn't think of
1472840	1480800	having a shell here but perhaps we can start thinking about, when thinking about post-exploitation,
1480800	1487720	we can try to extend or elevate access to the smart contracts. We can cause further
1487720	1493940	consequences in our components or even in other protocols by going beyond the
1493940	1498980	exploited system that we are assessing, right? So in that sense there might be some parallels between
1500940	1509580	in this post-exploitation phase. So let's go to an example to better see what I mean by
1509580	1517200	post-exploitation here. So let's see a compromised oracle case. In this case, let's imagine
1517400	1521980	a platform that is selling collectibles, is selling these kitties and you pay ETH and it
1521980	1528040	will give you away some kitties depending on how much ETH you have paid. But this platform actually
1528040	1537900	uses the price in ETH of these kitties but uses a price oracle to fetch the price in ETH, right?
1537900	1542860	The price oracle is basically another set of contracts where the price in ETH of these kitties
1542860	1552920	is registered by someone. But in this case, if you can end up finding a vulnerability in the
1552920	1558160	price oracle and you can compromise the price oracle, you can actually compromise the system
1558160	1562440	that is relying on that oracle, right? Because you can set, for instance, the price in ETH of
1562440	1567520	this collectible to zero, you can send a transaction to buy all kitties and you can steal away all
1567520	1573080	kitties in this platform. And that is not also true for a single platform that relies on this
1573080	1579080	oracle, but it's also true for all platforms that are actually relying on this price oracle. This is
1579080	1584100	an actual problem that I think that we have nowadays in Ethereum. The more projects that
1584100	1590740	are relying on a single oracle or just a small number of oracles, the greater the incentives,
1590740	1596600	the economic incentives to attack a price oracle, to compromise it and to basically pound every
1596600	1602360	single project depending on it. So this is basically what I mean with post exploitation.
1602360	1608420	We can compromise an oracle and by doing that we can move on to other projects and execute attacks
1608420	1620650	in them as well. Moving on, we have this last phases which is about reporting, doing fixes,
1620650	1629130	retests and I believe that there are many similarities with other information security
1629130	1635950	realms. So I don't think I should dive deeper into this. Of course we do reporting, of course
1635950	1643390	we review the fixes for our clients, of course we do retests to make sure they haven't reintroduced
1643390	1648810	the vulnerability and have actually fixed the things that we have reported. So we do all of
1648810	1653530	that, that is basically the same. But one thing that we should be highlighting here is that in
1653530	1661770	the Ethereum world most, if not all, but most security reports are public. That is something
1661770	1666390	that you don't see in other worlds. That is something that, for instance, me working as a
1666390	1673570	pen tester for banks in my previous job, I wouldn't have even imagined that I could at some point make
1673570	1678950	public a report, right? But in the Ethereum world that is true, you can do that, of course agreeing
1678950	1684850	that with the client, but I think everyone is encouraged to actually public their security
1684850	1690570	reports because in that way we can all improve the ecosystem, we can all learn about the best
1690570	1697690	security practices, which things might not be the best for some types of projects, and also to have
1697690	1705470	perspectives of other security auditors in the space and learn from each other and
1706090	1712610	make everything in the open and as transparent as possible. So we have public security reports and
1712610	1718950	you can go to, for instance, our blog at OpenZeppelin and many other companies as well are publishing
1718950	1724210	their reports and you can read them and learn tons about smart contract hacking and security
1724210	1729030	and research just by reading those public security reports. So that is something that I
1729030	1736670	wanted to highlight because I think it's super valuable in the space. Well, and to end this talk
1738130	1744430	I wanted to leave you with a little surprise, right? I don't think today I have covered many
1744430	1750930	things on the technical side just because I wanted to, as I told you at the beginning,
1750930	1755730	I wanted to give you the bigger picture of what does it mean to hack smart contracts and how do
1755730	1763010	we structure our engagements. But if you actually want to look at code and run some exploits and
1763010	1771130	try to break smart contracts, I think you might find this super useful and entertaining. It's time
1771130	1775250	for you to start hacking smart contracts so you can start applying all these learnings from these
1775250	1780590	phases that I have been telling you about. You can go to my github repository, it's already public,
1780590	1787110	and you can start hacking a set of smart contracts that is based on a governance system
1787110	1793770	using flash loans and token snapshots, all things and features super popular nowadays in the FIFA
1793770	1801170	space. And here you have an example on how that can be severely broken and you can be the one
1801170	1808270	attacking it and breaking it. So please have fun with it and hope to get some feedback on that if
1808270	1816610	you happen to play it. So thank you very much, you can contact me on telegram, on twitter,
1816610	1823070	on github and all these platforms. You can find me as Tim Chavate and you can learn more about
1823070	1828810	information security related to smart contracts in our forum, in our blog at Open Zeppelin.
1829670	1836090	I'm happy to help you out with anything related to this and please
1836990	1841430	ping me if you find this interesting. So thank you!