스마트 컨트랙트 감사: 도구, 기술 및 취약점

### 스마트 컨트랙트 감사 및 취약점 탐지 이해하기
* 🔍 보안 공간을 복제하면 블록 난이도를 통해 채굴자가 조작할 수 있는 **불량 RNG와 같은 문제**를 포함해 각각 고유한 취약점을 가진 여러 컨트랙트를 살펴볼 수 있습니다.
* 💧 탈중앙화 금융(DeFi) 계약에서 유동성 풀을 오라클로 활용하는 것은 **자산 가격을 단일 거래소에 의존하는 것은 탈중앙화되지 않고 시장 조작으로 이어질 수 있으므로 위험**이 따릅니다.
* ⚙ 이러한 컨트랙트를 분석하기 위해 정적 분석 도구인 **Slither를 설치**하고 컨트랙트 폴더에서 실행하여 취약점을 식별하고 **Open Zeppelin 및 Chainlink와 같은 라이브러리에 필요한 리매핑**을 지정할 수 있습니다.
* 📊 감사 프로세스에는 **테스트를 실행하고, 문서를 읽고, Slither와 같은 도구**를 활용하여 잠재적인 문제를 감지하고, 영향력과 가능성에 따라 취약점을 분류하는 보고서에서 강조 표시할 수 있습니다.
* 🚨 재진입 취약점과 같이 Slither에서 확인된 영향력이 큰 문제는 해결하지 않으면 **심각한 보안 위험**을 초래할 수 있으므로 즉시 해결해야 합니다.
* 🛠 감사 프로세스는 반복적이기 때문에 개발자는 발견한 내용을 바탕으로 변경하고 추가 분석을 위해 다시 제출해야 하며, 감사자는 이 과정에서 **귀중한 인사이트와 권장 사항**을 제공합니다.
* 📚 개발자가 스마트 컨트랙트를 메인넷에 배포하기 전에 **재입력 및 오라클 조작과 같은 일반적인 취약점**을 이해하는 것은 스마트 컨트랙트의 보안을 보장하는 데 매우 중요합니다.
* 🔗 Ethernaut 게임과 보안에 초점을 맞춘 블로그와 같은 리소스를 통해 **스마트 컨트랙트 보안에 대한 이해**와 개발 과정에서 **철저한 감사의 중요성**을 더욱 높일 수 있습니다.

감사자는 배포 전에 스마트 컨트랙트를 꼼꼼하게 검토하여 재입력 및 오라클 조작과 같은 취약점을 식별해야 합니다.

What up, coder frogs? How to audit a smart contract, and can you spot the vulnerabilities before we do? This is a modified excerpt from that 32-hour monstrosity full stack Solidity free code camp video, which by the way you should 100% watch no matter your experience level. But in this video, we're going to go through what a smart contract audit is, what's the process that auditors take, and then give you a chance to spot the vulnerabilities in these contracts before we do. This is going to be an introductory video to auditing and security in your smart contracts, and anybody who wants to become an auditor eventually or deploy their code to a mainnet should 100% know all the points in this video. We'll be using Hardhat as our smart contract framework, but all the security tools that we're going to be showing you will work no matter what framework you're working with. So buckle up for security purposes, and let's get froggy. Now we have a link in the description that has both this GitHub repository and

the article that we're writing on this topic. If you want to follow along, feel free to git clone this topic as well. Well, an audit is going to be a security-focused code review, looking for issues with your code. So, for example, let's say we have some code that looks like this. Our code withdraws, goes and sends ether, and then updates the balances. This code is clearly vulnerable to a reentrancy attack here, and this is something that an auditor would catch. Since when we deploy our code, that code is immutable, and that code will always be there, it's really important to have these security reviews done before we deploy our code to a mainnet and before we go live. So, if you're going to deploy some crazy massive DeFi protocol, and you're going to have billions of dollars of people's money locked into your protocol, you probably want to make sure that the money is going to go to the correct places. So, audits are incredibly important for the life cycle of our projects, and we want people to peer review. We want people to review our code.

to make sure that everything looks good. Auditors also don't make sure that your code is bug-free. I'm leaving another link in the description to the Securium Substack. Securium is a great platform for learning more about audits and security in our smart contracts. They even have this audit techniques and tools 101, and one of the main things that they talk about as well is that audit is not a security guarantee of bug-free code. It is a best effort endeavor by trained security experts operating with reasonable constraints on time, understanding, expertise, and of course, decidability. And you can learn more about different audit types, audit scope, kind of all these differences in very specific audits, and the limitations. Feel free to pause the video and read this to learn some more. Getting an audit does not guarantee that your code is spotless. It is a best effort attempt. Like I said, audits are security-focused peer reviews for your code base. Now, when we send our code to audit though, we shouldn't just say, Hey, here's our code. Can you check to make sure it's

good. That's not going to give an auditor enough information they need to be able to very easily know what your code does, how to work with it, and what you're looking for because auditors aren't going to be kind of this fail-safe where if your code is terrible, they're going to catch everything. Auditors are human beings too; they can miss things as well. And when you do send your code to audit, you want to make sure you help out your auditors as much as possible. There's an amazing tweet thread from Tincho, who previously was an OpenZeppelin auditor, with a ton of tips and tricks for working with auditors. I highly recommend you pause the video, you click this link, and you read through his tweets because they are fantastic. OpenZeppelin has a readiness guide to try to help you make sure that you're even ready for an audit in the first place, and we've got a link to this readiness guide in the GitHub repository. The summary of them is to add comments to your code, use NatSpec, which we learned

about to document your functions. Document your functions. Document your functions. Test. Be ready to talk to your auditors and be prepared to give them plenty of time. They are literally pouring themselves over your code for weeks on end to make sure there's nothing wrong. If you rush your auditors, you're going to get a rushed audit, and they're going to miss things. If you want to, before we even start, jump into the contracts folder, because in here we have one, two, three, four, five different contracts with some vulnerability that an auditor should either catch or at least call out in their report. If you want to, maybe pause the video and see if you can spot the issues with these five contracts before we talk about them. Now, some of the names are dead giveaways, so maybe use those as a hint. So, let's talk about the auditing process. An auditing process is gonna look like this. First, they're gonna run your tests. That's the first step an auditor is always gonna take, and right there, they're going to find, Okay, do they have

enough code coverage is everything passing. What do the tests do? What is the optimal functionality? After an auditor runs tests, they're going to read specs or run your docs, and then they're going to run some fast tools like slither, linters, and static analysis, and that's going to be one of the first things we're going to talk about: slither and static analysis. So, static analysis is the process of just running some program to read over all your code and look for commonly known bugs. One of the most popular static analysis tools is going to be this tool called slither, and that's going to be one of the first things we're going to do here. So, let's go ahead and open up our VS Code now, and we'll make a new directory called hard hat security FCC. We'll CD into it, we'll do code period, and we'll open this up now. What I want you to do instead of starting a new folder and everything is we're going to get clone my hardhead security FCC. So, we'll do git.

clone our.securityfcc space and then put a period to clone it into this directory, and we'll get everything like this now in here. This comes with a couple of different contracts for us already that each have a different vulnerability. One of them is going to be bad RNG. This is a contract that picks a random winner of a raffle using block difficulty and message.sender. This isn't truly random as the miners can influence the block.difficulty, and people can cancel transactions, and there's a ton of different vulnerabilities with creating randomness in this way. We also have this liquid pool as an oracle in this contract. Here, we're using a liquidity pool as an oracle, and this is kind of some advanced DeFi stuff here. This is a minimalistic decentralized exchange example where people can buy and sell and swap different assets. Now, using this singular exchange to get the swap price is a terrible idea because this is a single protocol for a single price. The price from this protocol is a single centralized location, and we don't want to get our price from a single

centralized exchange. We want to get it from many exchanges. Getting the price of any asset from a single decentralized exchange is not decentralized. If somebody manipulates the market, doing some crazy advanced DeFi things, that will ruin the price of your assets. So, getting the price of your assets from a centralized location is a terrible idea. We have a metamorphic proxy here. The issue here is that it's initializable, and we don't guarantee that the contract has been initialized. We have a classic reentrancy issue here. And then we have a vault here where some password is stored on-chain, and we're crossing our fingers that nobody reads this password to unlock it. So, we're going to run some static analysis on these contracts, see if that static analysis can spot some of the bad things in here. To get started, we're going to use a tool, like I said, called Slither. This Slither tool was created by this Crytek team, aka the Trail of Bits team. Now, Trail of Bits is one of my absolute favorite auditors in the space, and I absolutely love all

the tools that this team puts out. They put out open-source security tools for any of us to use, such as Slither. Now, to get started with Slither, we actually need to install Python first. So, you can also run it with Docker, but I'm going to show you how to work with Python first. So, if you haven't worked with Python before, you can come to python.org downloads and download Python right from the website. You'll know you've done it right, and you can run python3 --version like this, or if you have an older version of Python, you can run python version. Once you install Python, you should also have this tool called pip3 installed, and you can check by running pip3 version or pip --version. Now, we also want to install this solc-select package just in case we're using weird versions of Solidity. To install solc-select, we run pip3 install solc-select like that, and then we can do solc-select use, and then we can choose a version of Solidity for Slither to work with.

once you have those tools, you can just run pip3 install slither analyzer like so, and you can install slither into your Python environment. I'm not going to run it because I already have. You can also learn how to do this all with Docker. We'll learn how to do this with Docker in a little bit. Now in our package.json, we actually have command script in our package.json for running slither. You'll know you've installed slither correctly if you can run slither --help, and you get an output like this. Now we can use slither to run it on our contracts folder by running this big command here. So we'll say slither, and we want to run it on ./contracts. We would need to tell it that it has some sulk remappings, and every time it sees Open Zeppelin, it should use node module Open Zeppelin, and every time it sees Chainlink, it should use node modules Chainlink. And I'm just going to read from our package.json, and we're excluding a couple of functions that it

runs and excluding build or ignore, but don't worry too much about that. We can actually just run that by first running yarn to install all of our packages, and after we've installed all of our packages, we can run yarn slither, or you can copy-paste that slither command and run it directly. Now, we'll get this massive output that looks like this, with some red and some green. Let's go through what's actually happening here. The way that we can read slither, it'll list out a number of lines that have an issue and then a reference to that issue, and each one of these is separated by a new line, so that's a section, that's exception, etc. So, if we get a red here, that means that there is a high-impact issue that we definitely should address, and it even comes with a reference link that we can copy-paste and put into our browser and see what the issue is and more information from the slither tool about what that issue is and how to correct it. We can see it catches our metamorphic.

contract issue. It says the metamorphic contract is never initialized. It is used here in metamorphic.kill. The reason that this is a massive issue, if we go to our metamorphic contract.sol, is that if we deploy this contract, somebody else could initialize this code, become the owner, and then automatically kill it before we even have a chance. This is actually something that has happened in the past and has caused a ton of issues. So, if we see red in the terminal, this means, Hey, massive issue. We should absolutely check it out. Now, there's going to be a ton of green in here. These are detectors that are probably low impact and they're probably okay. And in fact, we can see it's even just calling out some opens up on stuff here saying, Hey, we see some in-line assembly. Inline assembly is kind of scary, maybe don't use that. So, you can think of green as kind of a warning that there's a low likelihood that this will impact anything, but you might want to check it out. We get this different versions of solidity used, which is just

saying hey, there's a couple of different versions of Solidity that might be something you want to keep in mind. Maybe you should use the same versions of Solidity we have. This allows old versions, and this is actually why throughout this whole course we've been using 0.8.7, because 0.8.4 and 0.8.7 are considered more stable versions of Solidity. So, if you're using versions outside of there, Slither will say, Hey, maybe you want to work with a different version. We have some flags in here about maybe, Hey, you should make a variable constant because it never changes, which is great. Uses literal with too many digits, saying, Hey, this is kind of hard to read. Maybe you screwed up some of the zeros. Loud old versions, and What's this reentrancy in Etherstore.withdraw? So, just by running this Slither tool, we can catch a reentrancy vulnerability in one of our contracts, which is fantastic. So, running this static analysis caught at least two huge vulnerabilities in our metamorphic contract.

and in our reentrancy contract, it didn't catch the issues in vault outsole liquidity pool or bad rng though, which is why we don't only want to rely on slither because it's not going to catch everything, but it will catch a lot of major vulnerabilities. So, that's how we can use slither, at least from a minimalistic point, to get started. So, great, we just learned how to work with slither. That's one of the first tools that are really fantastic in our audit process, and that's going to be considered a fast tool for static analysis. Running tests, linters, etc., are also types of static analysis. After we run a tool like that, we enter some manual analysis where we walk through the code ourselves manually. And it's in this manual review, though, that we might want to say, Oh, um, probably shouldn't get the swap price from a single dex because that could be oracle manipulated attack, or we might go, Uh, this randomness method that you have isn't that random. Auditors will

literally pour over every single line of a smart contract to make sure it's doing exactly what we want it to be doing. And maybe we do it in tangent with running some slower tools like Echidna, Manticore, and other symbolic execution tools. Symbolic execution is where we simulate executing transactions on the blockchain, and one of these symbolic execution tools that we're going to work with is this Echidna tool. Again, this is a Trail of Bits tool for doing something called fuzz testing. Now, in programming, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. In a lot of our code, oftentimes, we're going to get people interacting with them in ways that we will never think about. So, we want to be able to provide random data and random information to our test to see if something weird happens that we weren't expecting. So, we can actually build our own fuzz tests in our Hardhat projects and run these fuzz tests. I've

actually created a sample fuzz test. We write our fuzz tests in Solidity, actually, as opposed to writing our tests in JavaScript. So, let's say, for example, we've built this vault contract, and we think that at first glance, Hey, nobody should ever be able to know the password, and no one should ever be able to unlock this contract, which obviously we know is ridiculous because we know that anybody can read anything in a storage variable. So, we know that this should fail, but it might be hard to write a test to catch that this actually would fail. A good approach to testing this would be to just send a ton of random bytes32 objects to this unlock function to see if we can unlock it. We can write a fuzz test to do exactly that. So, in my vault fuzz test.soul, we're importing vault.soul, and so we're saying vault fuzz test is vault, and we have a password of 123 asd 123. And now we have a function called echidna test find password where it's gonna send a ton of random data into vault to try to

make s locked equal false so we just say s locked equals true here, and our fuzz test will try to make s-locked equals false. Now we could install just echidna, but at this point, it's a good idea to bring up our the security toolbox from trail of bits. So trailer bits has a package called the eth security toolbox, which has all their security tools in one single container: echidna, etherno, manticore, slither, rattle, and not so smart contracts. It has all these in the same exact package. Now to work with this toolbox, we're going to need docker installed, so we're going to do a little bit of installation here, and again, sometimes this can be the hardest part of the course, it's just installing these packages. So we've left a link to docs.docker.com/getdocker to install docker. To actually work with these tools, you're just going to come, you're going to click whichever one of these is appropriate for you to install docker. Once we have docker installed, we can run the e-security toolbox by pulling it.

down from the docker equivalent of github, and we're going to use a whole bunch of docker commands that I'm not going to explain here because this isn't a docker course. If you're looking to get into the security stuff, I would definitely recommend reading up on all these commands afterwards, and we're going to leave a ton of links for you to learn more. In the package.json associated with this lesson, we even have the command to get set up right in here, so we can just run yarn toolbox, which will run our docker command like this. So I'm just going to run yarn toolbox, and if you get something like this saying cannot connect to the docker daemon, is the docker daemon running? Because I need to have my docker daemon running. Since I installed docker desktop, I need to have my docker engine started and running for it to actually be working again to work with this. There's a lot of docker setup and configuration that needs to happen, which I'm going to leave a ton of instructions on how to

get started with Docker. Once we have Docker set up, now we can run Yarn toolbox, which will stick us into a new shell to work with any of these tools that Trailer Bits has out of the box. Now our vault fuzz test comes with a config as well. This is in a YAML file with all our arguments for running Echidna. So it has a test limit, which is how many different runs we should do, a time delay, block delay, and then of course some remappings in here. This Docker shell will already have these security tools already installed, like Echidna test. So we'll run an Echidna test on src/contracts/test/fuzzing/vault_fuzz_test.sol --contract will be vault_fuzz_test --config will be src/contracts/test/buzzing/config.yaml. And we'll go ahead and we'll hit enter here, and it'll say analyze and contract, and will give us an output that looks like this. What it's saying is it found a use case where it could make s-locked.

equal false, and the use case was one, two, three, asd, one, two, three. So when what seemed like almost seconds, it found the password to unlock our contract. And this is why running a fuzz tester can be so powerful. We thought our contract was secure, but it immediately found the password, which means anybody else could immediately find the password. And this would be an indicator that what we're doing there is not a good setup. So we'll hit ctrl c to escape and to leave our docker setup here. We'll just write exit. Now again, I'm going to leave a ton of links to work with echidna and work with this fuzz tester in the GitHub repo associated with this lesson so that you can go ahead and learn more. Now if you take anything away from this whole section, it should be this right here. The two most common attacks are reentrancy and oracle manipulation. So if you're not going to be an auditor and you just want to deploy things to mainnet, always, always before you deploy anything, the absolute minimum that you should be doing is always running

slither and then looking manually for oracle manipulation and reentrancy attacks. So please keep these in mind before you deploy anything to mainnet with any type of security guarantees. Okay, great. So we've learned about the fast tools. We've learned about some of the slow tools. We didn't look into Mantacore or MythX, but these are also tools that you can use. Mantacore is going to be another tool from the TrailerBits team. Mythics is actually a smart contract security service from the ConsenSys team. You basically send a bot that they have running in the cloud your contracts, and it'll do some automated process to check for security vulnerabilities. This is a paid service, but if you're going to be deploying a protocol that's worth millions of dollars, spending a few thousand dollars to make sure it actually does what it says is going to do correctly is definitely something that you want to invest in. After you run through this whole process, you, the smart contract developers, and the audits should discuss their findings, and if

there's any issues. Repeat the steps, repeat all these steps again after changes are made, so this audit process and making sure your contracts are secure is a long process. And then afterwards, an auditor will finally write you a report with all security vulnerabilities and everything that they found in your contracts. Typically, you'll organize reports in a chart that'll look something like this. You'll label issues that have a high chance of happening and have a high impact as critical, things that have a high impact but a low likelihood as medium, and etc. I'm also going to leave some examples of audits that have been done in the past so that you can take a look at them and you can see what a full audit looks like on certain code. We'll be looking at Open Zeppelin, Sigma Prime, and Trail of Bits because these are three of what I think are some of the best auditors in the space. Now in the GitHub repo, we also have a ton of other tools that you can use: MythX, Mythril, Ethersplay, and Consensus Security Tools.

If you want to learn more about security in auditing, I highly recommend that after this course, you play the Ethernaut game and Damn Vulnerable DeFi. These are two games that will teach you a ton about security and will test the chops and will test everything that you've learned in this course. There's also a couple of security-focused blogs that I really like. One of them in particular is rect.news. They keep a running list of some of the largest hacks that have ever happened in the space and then retrospectives on why those actually happened, and they usually make it very entertaining as well. We have some articles in here as well. One of the best places to look at is this known attacks section where they talk about reentrancy, oracle manipulation, front-running, and a ton of other attacks that you should absolutely be aware of when writing your smart contracts. We're not going to go over them here because they do a great job in these resources explaining them. You should also check out this article because I helped write it, so definitely.

check that out, and then we've got a list to even more sections. Security is something that is always going to be on your mind, and there's always going to be new tools to help with security, and there's always going to be new things to think about. So even though we went through this very quickly, I 100% want you to pause this video and work with and try out some of the tools we tried here, and then maybe even try coming up with your own vulnerabilities as well. We've got a lot more content like this coming out, so please like, subscribe, tell your friends to subscribe, and let me know what you want to see next in the comment section. And definitely tell your friends to subscribe, because at 100,000 subscribers, we're gonna do something crazy. We have one thing that we're definitely already gonna do, but let me know if you want to see something else crazy for our 100,000 subscriber celebration. Take care, everybody, and we'll see you next time. [Music] [Music]

How to Audit a Smart Contract | Can you find the Solidity Security Vulnerabilities?

Patrick Collins

스마트 계약 감사하기: 단계별 가이드

스마트 컨트랙트 감사는 배포 전에 취약점을 식별하는 데 매우 중요합니다.

이 과정에는 정적 및 동적 분석을 위해 하드햇, 에키드나, 슬리더와 같은 도구를 사용합니다.

퍼즈 테스트와 수동 코드 검토도 잠재적인 문제를 포착하고 코드 보안을 보장하기 위한 감사 프로세스의 필수 단계입니다.

코드 분석 및 감사에 Slither 사용

Slither는 코드의 정적 분석에 사용되는 도구로, 그 결과를 통해 영향력이 큰 문제를 식별하는 데 도움을 줍니다.

감사 프로세스에는 테스트 실행, 문서 읽기, 버그 감지를 위한 Slither와 같은 도구 사용 등이 포함됩니다.

서두르면 문제를 놓칠 수 있으므로 감사자가 코드를 철저히 검토할 수 있도록 충분한 시간을 주는 것이 중요합니다.

변형 컨트랙트는 초기화되지 않기 때문에 원래 소유자가 기회를 갖기도 전에 다른 사람이 소유권을 가져가서 죽일 수 있는 위험이 있습니다.

슬리더 도구의 분석 결과, 재진입 가능성과 다른 솔리디티 버전 사용 등 몇 가지 취약점이 발견되었습니다.

이 동영상은 스마트 컨트랙트에서 보안의 중요성을 강조하며 시청자가 도구를 살펴보고 스스로 취약점을 찾아내도록 독려합니다.

블록체인 개발에서 보안 감사의 중요성

퍼즈 테스트 프로세스에서는 s_locked 변수를 false로 설정하는 것이 중요합니다.

트레일 오브 비츠의 Eth 보안 툴박스는 Echidna와 Slither를 포함한 포괄적인 보안 도구 패키지를 제공하며, 설치를 위해 Docker가 필요합니다.

코드를 메인넷에 배포하기 전에 철저한 보안 감사를 수행하는 것은 취약점을 식별하고 프로젝트의 성공을 보장하는 데 필수적입니다.

보안 감사를 위한 Docker 설정하기

설정에는 Docker 명령이 사용되며, package.

json은 실행 명령을 제공합니다.

제대로 작동하려면 Docker 데몬을 실행하는 것이 중요합니다.

감사자는 코드를 검토하는 데 중요한 역할을 하지만 감사자의 작업이 버그 없는 코드를 보장하는 것은 아니며, 최선을 다해 검토하는 것입니다.

도커는 트레일러 비츠의 보안 도구에 대한 액세스를 제공하는 얀 툴박스를 실행하도록 설정되어 있습니다.

볼트 퍼즈 테스트는 Docker 셸에 이미 설치되어 있는 Echidna를 실행하기 위한 YAML 파일로 구성됩니다.

또 다른 보안 도구인 Slither는 Python 설치와 솔리디티 버전 관리를 위한 solc-select 패키지가 필요합니다.

강의가 끝난 후 Ethernaut 게임과 Damn Vulnerable DeFi를 플레이하며 실전 보안 학습을 해보는 것을 추천합니다.

news는 주요 해킹과 알려진 공격에 대한 통찰력 있는 블로그를 제공하므로 유용한 리소스입니다.

솔리디티의 퍼즈 테스트는 볼트 컨트랙트 예시에서 취약점을 효과적으로 식별할 수 있습니다.

취약한 스마트 컨트랙트 분석하기

복제된 보안 공간에는 무작위 당첨자 선정을 위한 불량 RNG와 자산 스와핑을 위한 중앙화된 오라클로 사용되는 유동성 풀 등 다양한 취약점이 있는 컨트랙트가 포함되어 있습니다.

가격 결정에 단일 탈중앙화 거래소를 사용하는 것은 중앙 집중식 장애 지점을 발생시킨다는 비판을 받고 있습니다.

분석은 트레일 오브 비트 팀이 개발한 도구인 슬리더를 사용해 계약의 취약점을 파악하고 해결할 것입니다.