안녕하세요, 저는 알고리마에서 연구한 결과를 공유하고자 합니다. 먼저 코드 재사용의 위험성을 알아보고 실제 구현된 코드에 대해서 설명하려고 합니다.
Copy and Paste
코드의 재사용은 단기간 내 개발 시간과 비용을 절약할 수 있기 때문에 일반적으로 널리 사용되고 있습니다. 그러나 이러한 소스 코드의 재사용은 코드 내 잠재된 결함이나 보안 약점을 그대로 복사하여 사용하는 위험을 지니고 있어 프로그램의 다양한 문제의 원인이 되기도 합니다.
다 알지만.. 그래도 복 붙
블록체인 프로젝트는 보통 오픈소스로 진행됩니다. 그렇기 때문에 코드를 많이 차용하곤 하는데요, 문제는 안전하지 않은 코드라는 것입니다. IBM 보고서(Zeus:Analyzing Safety of Smart Contracts )에 따르면 2만 2400개 스마트 계약 코드 가운데 94.6%가 보안에 취약하다고 합니다. 즉 오픈된 소스 코드를 그대로 가져다 쓰면 취약점이 그대로 노출되는 안타까운 결과를 만들어 내는 셈입니다.
코드 재사용에 대한 경각심을 줄 수 있는 방법이 없을까??
저희 알고리마는 안전한 개발환경을 제공하는 데 앞장서고자 개발자 분들이 안전하게 이더리움 환경에서 개발할 수 있도록 실제 이더스캔에 공개된 소스를 분석하기 시작했습니다.
제한된 쓰기 취약점(Restrict Write)
2017년 Parity Multisig Bug로 인해 $30M 피해가 발생한 사건이 있었는데요, 이러한 사고 케이스를 restricted write로 정의하였습니다(Securify: Practical Security Analysis of Smart Contracts). 앞선 사례처럼 자신에게 부여된 권한을 넘어 스마트 계약 코드를 악용하는 공격 기법은 많은 언론 보도와 대응 방안이 알려졌는데요, 이와 비슷한 취약한 코드는 최근까지도 재사용 되고 있었습니다.
코드분석
저희 알고리마 팀은 700여개 오픈된 스마트 계약 코드를 분석하였고 ZXX, MXX, DXX 총 3개의 토큰이 아래와 같은 취약한 코드를 사용하고 있었습니다.
취약점 발생원인
취약한 코드를 살펴보면 increaseAllowance 함수는 자신 (msg.sender)의 allowance( _approvals)를 원하는 만큼 증가시킨 후, transferFrom 함수를 호출해서 토큰을 자신에게 전송할수 있습니다. _approvals[spender][msg.sender]는 스마트 계약 조건으로 msg.sender 가 spender 로부터 이체할수 있는 토큰의 양을 나타냅니다.
해당 스마트 계약의 취약점은
_approvals의 인덱스msg.sender와spender의 순서가 바뀌었기 때문에 발생한 문제인데요, 악의적인 사용자는 이점을 이용해 타인 소유의 토큰을 자기 자신의 계좌로 보내 소유자에게 큰 피해를 입힐수 있는 치명적인 공격을 할 수 있습니다.
그래도 다시한번
한번 잘못 만들어진 코드는 재사용이 됨에 따라 최초 토큰뿐만 아니라 이후에 만들어지는 토큰까지도 같은 취약점에 노출되는 위험한 상황을 초래하게 됩니다. 특히 이번 RW 취약점은 기존 보안 툴에서 찾지 못한 버그였기 때문에 코드를 복붙하기 전 보안 원칙을 고려하는 것이 얼마나 중요한지를 다시 한번 생각해보게 됩니다.
저희 알고리마는 이번 분석을 통해 코드 재사용이 지금까지도 많은 위험에 노출되어 있는지를 다시 한번 확인할 수 있는 기회였습니다. 블록체인 개발자라면 Solidity Security Considerations 을 한 번 읽어 보시고 보다 주의를 기울이심이 어떨까 합니다.
