스마트 컨트랙트는 탈중앙화 서비스(Dapp)를 구축하거나, 토큰, 게임 아이템 등의 디지털 자산을 만들 수 있는 훌륭한 도구입니다. 스마트 컨트랙트로 만들어지는 디지털 자산의 가치는 적게는 몇 십억 원 수준에서 많게는 몇 조원 수준에 이르기도 합니다. 실제로 이더리움, 트론 등의 플랫폼에서 스마트 컨트랙트를 통해 발행된 테더(Tether)라는 토큰의 시가총액은 현재 약 5조 3천억 원입니다.
이렇듯 스마트 컨트랙트를 통해 만들어지는 디지털 자산의 가치는 상당히 크다고 볼 수 있는데요, 만약 스마트 컨트랙트가 잘못 짜이게 된다면 어떤 일이 발생할까요? 막대한 가치를 지닌 디지털 자산이 해커의 손에 넘어가거나 아예 사라져 버리는 일 등이 생길 수 있습니다.
위와 같은 피해를 예방하기 위해 HAECHI AUDIT은 스마트 컨트랙트 보안감사 서비스를 제공하고 있습니다. 이번 글에서 스마트 컨트랙트 보안감사란 무엇이며 어떻게 진행되는지, 그리고 왜 중요한지에 대해 살펴보도록 하겠습니다.
스마트 컨트랙트 보안감사란?
스마트 컨트랙트 보안감사란 스마트 컨트랙트 코드에 존재하는 보안 취약점을 검출하고, 코드가 의도대로 잘 작성되었는지를 분석하는 것입니다.
보안 취약점이 존재하는 스마트 컨트랙트는 해커의 공격으로 인해 자산을 탈취당할 수 있고, 구현 의도와 다르게 코드가 작성된다면 원하는 기능이 작동하지 않거나 잘못 작동될 수 있기 때문입니다.
그렇다면 스마트 컨트랙트 보안감사는 왜 필요한 것일까요?
스마트 컨트랙트 보안감사, 왜 필요할까?
스마트 컨트랙트는 한 번 배포되면 수정이 불가능합니다.
일반 소프트웨어의 경우 코드를 배포한 다음에 오류가 발견되면 이를 수정해 다시 배포하는 것이 가능하지만, 스마트 컨트랙트는 한 번 배포된 후 블록체인에 기록되면 코드를 변경할 수 없습니다. 코드를 수정하려면 새로운 스마트 컨트랙트를 다시 작성하고 배포하여야 합니다.
특히 토큰 스마트 컨트랙트의 경우, 처음 배포한 스마트 컨트랙트에 문제가 생겨 다른 스마트 컨트랙트를 배포하려면 기존 토큰 소유자들에게 일일이 새로운 토큰을 전송해주어야 하기 때문에 꽤 큰 비용을 초래합니다.
사실 스마트 컨트랙트를 재배포하는데 들어가는 비용은 해킹으로 발생하는 피해 금액에 비하면 상대적으로 적은 수준입니다. 2016년 발생한 TheDAO 해킹 사건에서 해커는 스마트 컨트랙트의 결함을 발견해 총 243만 이더리움을 인출하였고, 피해금액은 그 당시 가치로 약 750억 원가량이었습니다. 해커가 스마트 컨트랙트의 결함을 찾아낼 수 있었던 이유는 스마트 컨트랙트가 모두에게 공개되는 코드이기 때문입니다. 스마트 컨트랙트는 특정 주체에 의해 운영되지 않고 누구나 볼 수 있고, 작동할 수 있도록 공개되어 있습니다. 따라서 스마트 컨트랙트에 결함이 존재한다면 언제든지 해커의 표적이 될 수 있고, 막대한 피해를 입을 수 있습니다.
위와 같은 이유로 스마트 컨트랙트를 통해 디지털 자산을 만들거나, 이를 활용한 탈중앙화 서비스를 만들 예정이라면 반드시 스마트 컨트랙트 보안감사가 필요합니다. 다음으로는 실제로 스마트 컨트랙트에 결함이 있어 발생한 대표적인 스마트 컨트랙트 해킹 사례를 통해 스마트 컨트랙트 보안감사의 필요성에 대해 알아보도록 하겠습니다.
대표적인 스마트 컨트랙트 해킹 사례 — TheDAO 해킹
현재까지 이더리움에서 발생한 스마트 컨트랙트 해킹 사례들 중 가장 대표적으로 알려진 것은 바로 TheDAO 해킹입니다.
아마 이더리움 혹은 블록체인에 대해 관심이 많은 분이라면 TheDAO에 대해 한 번쯤은 들어보셨을 거라 생각되는데요, 이번에는 TheDAO 해킹 사건이 발생한 배경에 대해 설명드리도록 하겠습니다.
https://www.coininsider.com/what-happened-to-the-dao/
2016년 4월에 오픈한 TheDAO는 이더리움의 스마트 컨트랙트를 통해 진행된 대표적인 크라우드 펀딩 사례입니다.
TheDAO는 탈중앙화 된 자율 조직(Decentralized Autonomous Organization)으로 초국경 투자 조직입니다. 일종의 벤처 캐피털(Venture Capital)이라고 볼 수 있지만, 가장 큰 차이점은 대표자의 부재입니다. TheDAO에서는 주주들이 모든 투자 및 정책에 대해 결정하게 되어 있었고, 주주가 되기 위해서는 다음과 같은 과정을 거쳐야 했습니다. 1) 주주가 되고 싶은 A는 Ether(이더리움)를 TheDAO로 보낸다, 2) 주주가 될 수 있는 DAO Token을 받는다.
즉, TheDAO의 주주가 되기 위해서는 Ether와 DAO Token을 교환하는 과정이 존재했습니다.
그렇다면 탈중앙화 된 자율 조직에서 어떻게 크라우드 펀딩이 진행될 수 있었을까요?
방식은 비교적 간단합니다. Ether를 TheDAO로 보내면, DAO Token을 돌려주었습니다. 이러한 작동들 모두 스마트 컨트랙트로 작성되어 있어, 다음과 같이 작동하게 됩니다.
1. The DAO의 입금 로직1.투자자로부터 “Ether” 수량 A를 받는다.
2. 투자자에게 수량 A에 해당하는 금액만큼 DAO Token 수량을 계산한다.
3. 투자자의 DAO Token 수량을 늘린다.
다행히도 DAO Token을 발행하는 것에는 문제가 없었습니다.
그런데 TheDAO는 크라우드 펀딩 이후에 투자를 철회하고 싶은 투자자를 위해 다음과 같은 함수를 제공했습니다.
The DAO의 출금 로직1.투자자로부터 “Ether” 수량 A를 받는다.
2. 투자자에게 수량 A에 해당하는 금액만큼 Ether를 보낸다.
3. 투자자의 DAO Token 수량을 줄인다.
여기서 문제가 발생합니다.
바로 두 번째 라인인 “투자자에게 A에 해당하는 만큼 Ether를 보낸다”에서 문제가 발생한 것인데요. 만약 환불하는 대상이 Contract라면 Ether를 수령하는 동시에, 새로운 로직을 추가할 수 있게 됩니다.
1.공격 계약의 Ether 입금 로직
- 공격 계약의 “TheDAO의 출금 로직” 실행2. 공격 계약의 TheDAO 출금 로직
- TheDAO 계약의 “출금 로직” 실행
실제로 해커는 위 두 개의 함수를 가지고 있는 공격 스마트 컨트랙트를 배포하였습니다. 해당 함수를 통해 TheDAO 출금 함수를 실행하면 다음과 같이 작동하게 됩니다.
1. 공격 계약의 TheDAO 출금 로직
2. TheDAO 계약의 “‘출금 로직” 실행
(1). 투자자로부터 “DAO Token” 수량 A를 받는다.
(2). 투자자로부터 A에 해당하는 만큼 Ether를 보낸다.3. 공격 계약의 Ether 입금 로직
4. 공격 계약의 TheDAO 출금 로직
…(반복)
투자자의 DAO Token의 수량이 감소하기 전에 Ether를 지속적으로 전송하도록 할 수 있던 것입니다. 이런 방식으로 TheDAO의 잔고는 계속 줄어들었습니다. 결국 TheDAO 해킹 이후에는 많은 양의 Ether가 도난당했고, 해킹된 내용을 그대로 반영한 이더리움 클래식(Ethereum Classic)과 해킹된 내용 이전으로 상황을 되돌리는 이더리움(Ethereum) 진영으로 나뉘게 되었습니다.
스마트 컨트랙트 보안 감사의 필요성
앞서 살펴본 TheDAO 해킹 사건이 발생하게 된 것도 아마 “출금 로직”만 보았을 때는 작동이 잘 될 것으로 보였기 때문일 것입니다. 실제로 다른 로직이 끼어들지 않는다면 말입니다. 이러한 문제 상황은 단순히 코드를 테스트하는 것으로 감지하는 것이 어렵습니다. 더군다나, 이미 배포된 코드에 담겨있는 Ether이기 때문에 누구나 접근할 수 있어 언제든지 해커의 표적이 될 수 있습니다.
따라서 스마트 컨트랙트가 배포되기 이전에 이러한 사태를 막는 것이 중요합니다. 이미 스마트 컨트랙트가 배포되고, 사용자들에게 전달된 이후에는 돌이킬 수 없기 때문에 보안 감사는 필수적인 요소입니다.
TheDAO 해킹 사건 또한 스마트 컨트랙트 보안감사를 받았다면 피할 수 있는 사고였을 텐데요, 그렇다면 이러한 스마트 컨트랙트 보안감사는 어떻게 이루어지는 것일까요?
스마트 컨트랙트 보안감사 진행 과정
이번에는 실제로 스마트 컨트랙트 보안 감사가 진행되는 과정에 대해 알아보도록 하겠습니다. HAECHI AUDIT과 같이 스마트 컨트랙트 보안감사를 전문적으로 제공하는 기업에서는 이 과정을 통해 이미 배포되었거나, 배포 이전의 스마트 컨트랙트에 대한 보안 취약점을 분석합니다.
1. 명세 확인
이 단계에서는 스마트 컨트랙트가 구현하고자 하는 로직에 대한 정보를 받습니다. 예를 들어 백서나 백서 발행 이후 개정된 내용들에 대해 정보를 수집하는 과정을 가집니다. 이러한 작업을 통해 명세를 구체화하고, 스마트 컨트랙트가 명세에 맞게 구현되었는지 확인하기 위한 준비를 합니다.
2. 테스트 코드 작성
명세가 확인되었다면, 고객사로 부터 전달된 스마트 컨트랙트에 대한 테스트 코드를 작성합니다. 모든 예외 상황과 라이브러리들이 올바르게 작동하는지 검증하며, 필요로 하는 조건들을 달리하여도 예외 상황을 일으키지 않는지에 대해 검사하는 작업입니다.
이는 앞서 본 TheDAO의 케이스에서, 각각의 로직들이 명세에 따라 구현되었는지 확인하는 과정이 됩니다. 또한 명세를 통해 유추할 수 있는 사용자들의 악의적인 패턴들을 분석하는 시나리오 테스팅까지 해당 과정에서 수행됩니다.
일반적으로 이 과정에서 대부분의 버그와 보안 취약점이 검출되며, 수정 제안 사항들을 찾아내게 됩니다.
3. 정적 분석
테스트 코드가 작성되었고 모든 코드의 예외 상황을 점검했을 때, 정적 분석을 수행합니다. 코드에는 취약점을 가지는 구현 패턴이 존재할 수 있으며, 테스트 코드로 검출되지 않는다는 특성을 가지고 있습니다.
앞서 본 TheDAO의 해킹 사례에서 공격자가 스마트 컨트랙트인 경우에 새로운 로직이 중간에 끼어들 수 있다는 점은 테스트 코드로 검출되기 어렵습니다. 이러한 구현 패턴은 보안 감사 도구를 통해서 검증하는 것이 훨씬 정확합니다.
이 과정에서 다수의 도구를 이용하게 되며, 보편적으로 알려진 취약점들을 발견하게 됩니다. 대부분 알려진 스마트 컨트랙트 코드의 취약점들은 Smart Contract Weakness Classification(이하 SWC)라는 이름으로 잘 정리되어 있습니다. 이 중에서 분석되어야 하는 SWC 항목에 대해 검증하게 됩니다. HAECHI AUDIT 에서는 다음과 같은 SWC 항목에 대해 정적 분석 도구를 활용하여 검사합니다.
이러한 과정 속에서도 도구로 발견하지 못하는 취약점이 존재하는데 훈련된 전문 감사원이 SWC를 기반하여 해당 취약점이 있는지 분석합니다.
4. 코드 디자인 리뷰 및 가스 최적화 분석
보안 취약점 분석이 끝나면 스마트 컨트랙트의 아키텍처에 대한 종합적인 분석이 진행됩니다. 예를 들어 상속 구조나 변수가 불필요하게 사용되었을 경우, 이를 해결할 수 있는 방법을 보고서 내용에 추가합니다. 또한 시뮬레이션을 통해 해당 스마트 컨트랙트가 메인넷에서 실행될 때 얼마나 많은 가스를 소모하는지 분석하고 이를 최적화할 수 있는 방안에 대해서도 제안합니다.
5. 보고서 발행
보안감사 대상 코드에서 취약점과 버그가 발견된 경우, 문제가 되는 코드 영역을 보안 이슈 레벨에 따라 분류하고 수정 방안에 대해 제안하는 내용을 보고서에 담습니다.
테스트 코드가 모든 예외 상황에 대해 검사를 마쳤다는 내용과 정적 분석을 통해 감지해야 하는 알려진 이슈들에 대한 통과 여부를 체크리스트로 표시합니다. 해당 내용이 담긴 1차 보고서는 고객사에게 전달됩니다.