BEC, SMT 토큰 무한생성?

Henry Kang
Hexlant
Published in
7 min readApr 26, 2018

25일 오전 11시 10분 경 Huobi에 모든 통화 입금이 중지되는 사태가 발생했습니다.

후오비프로 공지사항

Etherscan에 아래 txid 값을 확인 하면 다음과 같은 트랜잭션 기록을 확인 할 수 있습니다.

0x0775e55c402281e8ff24cf37d6f2079bf2a768cf7254593287b5f8a0f621fb83

Huobi 지갑 주소로 입금된 1경개의 SMT 토큰

SMT의 경우 총 31억개의 토큰을 발행 하였는데, Huobi의 ERC 지갑으로 약 1경 개가 입금 되었으며, 이를 출금한 이력도 있습니다.

이와 같은 문제가 왜 나왔는지 SMT 와 BEC 의 Contract Code를 확인해 보겠습니다.

Contract Code Check

- SMT

해커는 SMT 토큰팀에서 만든 Contract Code에 있는 transferProxy 함수를 사용하였습니다.

SMT Contract Code

line 206 — 보내는 사람(_from) 의 잔액이 보내려는 수량보다 많이 남는지 check

line 210 — 보내는 사람(_from)의 서명 인증

line 212 — 받는 사람(_to) 의 value check

line 215 ~ 222 — token transfer

SMT 의 transferProxy 함수는 위의 line 206, 210, 212 의 조건을 통과하면 토큰전송이 적용됩니다.

해커는 위의 세 조건을 통과 한 후 약 65,133,050,195,990,400,000,000,000,000,000,000,000,000,000,000,000,000,000,000.891004451135422463 개를 만들어 내는데 성공했습니다.

여기서 중요한 부분은 check 에 계산 되는 _value 와 _feeSmt 입니다. 이 두개의 값을 더하는 과정에서 조건을 가볍게 넘어가게 되고 이를 통해 transfer 를 실행하게 되기 때문이죠.

이 두 변수(_value, feeSmt)는 자료형이 uint256 으로 이 데이터는 0 ~ 2²⁵⁶-1의 값을 담을 수 있습니다.

쉽게 설명하기 위해 unit256 의 max value 가 256 이라고 가정하면 이 변수에 257 이 담기는 순간 overflow 가 발생해 이 데이터는 0을 가리키게 됩니다.

해커는 이 _value 에 256의 값을 넣었고, _feeSmt 에 1의 값을 줌으로 써 if 문을 넘겨 65,133,050,195,990,400,000,000,000,000,000,000,000,000,000,000,000,000,000,000.891004451135422463 개의 토큰을 만든 것입니다.

- BEC

BEC Contract Code

line 258 — 수신받을 주소의 갯수가 0~20 사이인지 check

line 259 — 보내려는 개수(_value) 가 0개 이상이고 보내는 사람(msg.sender)이 보유한 토큰 수량이 보내고자 하는 토큰의 총량보다 많아야 한다

line 261 ~ 266 — token transfer

BEC 의 batchTransfer 함수는 위의line 258, 259 의 조건을 통과하면 실제 토큰 전송이 이루어지게 됩니다

위의 SMT 사례와 마찬가지로 unit256 의 max value 가 256 이라고 가정하면 line 257에서의 amount값이 257이 되도록 _receivers개수와 _value값을 넘기면 line 259의 check를 통과하게 되어 token을 transfer 하게 됩니다.

이를 어떻게 예방 할수 있을까?

이는 간단하게 위의 예에서 볼수 있듯이 overflow, underflow 를 예방하면 해결 되는 문제입니다. max value 가 256이라면 사칙연산에 의해 생긴 결과값이 256을 넘는 순간 error 를 발생시켜 더 진행되지 않게 하면 됩니다.

이는 이미 OpenZepplin 에서 개발 된 SafeMath라는 library 를 통해 아주 간단하게 해결 할 수 있습니다.

SafeMath를 왜 써야 하는지는 Alex Park 님의 아래 포스팅 (‘18.02.19 작성) 에서 더 자세하게 확인해 볼 수 있습니다.

Alex Park님 posting 중 일부

이더리움의 문제?

위 문제가 이더리움의 문제라고 말할 수 있을까요?

이더리움은 모두가 알다시피 Platform을 지향하는 블럭체인입니다. 다양한 Dapp이 이더리움 위에서 실행될수 있게 해주는것을 기반으로 하는 블럭체인 네트워크입니다. 쉽게 설명하면 이더리움은 블록체인계에서 Android 같은 포지션을 맡는다고 볼 수 있습니다.

Android 위에는 현재 수많은 Application 이 실행되고 있습니다. 누군가가 Banking Application 을 개발 하였고, 이 Banking Application 에서 OverFlow 가 발생으로 인하여 돈을 무한으로 찍어낸다고 해서 이를 Android 책임으로 몰고 갈 수 있을까요?

Contract Code는 한번 배포하면 수정이 불가능 하다는 점에서 예외처리에 대한 개발과, 다양한 상황에서 문제는 없는지 검증작업이 매우 중요합니다

이러한 문제를 해결하기 위해 Hexlant는 ICO에 대한 기술 검증을 진행하고 있습니다. 특히 Contract Code에 대해 Code Review/Audit을 진행하고, 다양한 상황에 있어서 발생 할 수 있는 부분에 대해 Testcase를 작성하여, 자동화된 테스트로 빠르게 문제를 분석하고 있습니다.

맺음말

“코인의 95%는 사라질것이다" — JTBC 토론 중 코빗 전 김진화 대표

볼록체인 시장은 많은 사람들의 관심속에 계속 커지고 있는 시장입니다.

현재까지 발행된 암호화폐 중에는 BEC, SMT와 같이 개발이나 검증이 미흡한 토큰이 존재합니다. 지금과 같은 사태를 예방하기 위해선 암호화폐를 개발하는 개발자의 능력이나 경력도 중요하지만, 무엇보다 투자자 스스로도 해당 암호화폐에 대해 보다 철저한 검증과 자료검토가 필요하다고 할 수 있습니다.

참고자료

SMT Contract Code

BEC Contract Code

Alex Park Posting

--

--