[Ethereum] Smart Contract 보안 취약점

이더리움 보안 가이드라인

- Minimalism : 꼭 필요한 기능들만 가진 contract을 제작하자.
- Code reuse : 코드를 작성할 때 library를 찾아서 써라.
- Code quality : 제작된 contract은 항상 블록체인에 올라가 있다. 따라서 처음 만들 때 제대로 만들어서 사용하자.
- Readability : 가독성이 좋도록 작성하자.
- Test coverage : 다양한 형태의 input 값을 테스트 해보자.

 

 

대표적인 취약점

1) Reentrancy 공격

: fallback() 함수를 이용한 취약점이다. 사용자가 외부 공격자의 contract 코드를 사용했을 때, 호출한 함수가 존재하지 않는다면 공격자 contract의 fallback() 함수가 동작된다. 그럼 이때, fallback 함수 안에 악의적인 코드를 넣어 얻어걸릴 수 있는 취약점이다.

(해결방안) - transfer 함수 사용

            - 외부 call이 필요할 시에는 내부 state를 미리 다 변화시키기

            - 뮤 택스를 사용

 

2) Overflow와 Underflow

: 자료형을 사용할 때 지정된 범위를 넘어서면 언더 플로 혹은 오버플로가 발생한다. 값을 넘겨줄 때 발생할 수 있다.

(해결방안) - 직접 대입 X

             - assert() 함수로 확인하는 작업 추가

             - 안전한 library를 사용

 

3) Unexpected Ether

: 공격자가 A라는 account가 만들어지는 것과 account의 address를 추측할 수 있다면, 발생할 수 있는 취약점이다. 해당 계정이 생성되기 전에 해당 address로 이더를 전송하면 none-zero ether balance를 가진 account가 생성된다. 이러한 계정은 이더 게임에서 악용될 수도 있다. 

(해결방안) - this.balance를 직접 사용 X

 

4) Delegate Call

: 사용자가 외부 contract을 사용할 경우, 호출한 contract의 context는 본인의 context 기반이 아니라 호출한 context 기반으로 코드가 동작된다. library를 사용할 때 발생할 수도 있으며, 호출한 쪽의 state 기반으로 동작되기 때문에 원래와는 다른 용도로 동작될 수 있다.

(해결방안) - library keyword를 사용 >> 무조건 외부 state를 가져와서 사용할 수 있도록 함.

 

5) Default Visbilities

: 함수 키워드를 사용하지 않을 때 발생하는 취약점이다. 함수 키워드를 작성하지 않으면 기본적으로 public으로 지정된다. 따라서 제작자의 실수로 코드가 유출될 수도 있고, 공격자들은 디렉트로 함수로 접근할 수 있게 된다.

(해결방안) - 함수 키워드 반드시 작성

 

6) Entropy Illusion

: 난수 생성에 대한 취약점이다. 이더리움에는 난수를 생성할 수 있는 소스가 존재하지 않는다. 따라서 다양한 난수 생성과 관련한 접근이 존재했는데, 그중 하나의 예시로 미래에 생성되는 값을 가져와서 쓰고 현재 참여한 시점에서 나중의 값을 예측할 수 없기 때문에 해당 값을 난수로 사용할 수 있다는 아이디어이다. 하지만 마이닝을 통해 혹은 아예 결과를 예측할 수 없을 것이라고 단정 짓기는 어렵기 때문에 취약점이 발생할 수도 있다.

 

7) Vulnerability

: 외부 contract을 호출할 때 발생할 수 있는 문제점으로, 사용자는 호출한 contract이 본인이 사용하려는 conrract인지 확인하지 않기 때문에 다른 address가 들어가게 될 경우를 알 수 없다.

(해결방안) - 내부 distance로 작성하여 사용

            - 외부 함수 호출 코드는 public으로 작성 // 다른 사람이 이걸 쓸 때 취약하다고 판단되면 알아서 안 쓰겠지.. 마인드

 

8) Unchecked Call Return value

: call 함수나 send 함수를 사용할 때 리턴 값을 제대로 확인하지 않아 발생하는 취약점이다. 앞서 이더리움에서는 문제가 생기면 자동으로 reboot 되는 개념을 설명한 적이 있다. 따라서 해당 리턴 값을 잘 확인하지 않는 경우가 생기는데, send 함수의 예로, gas price가 부족하여 정보를 다 불러오지 못하게 되면 contract은 이를 return false로 반환한 뒤에 다음 코드를 실행시킨다. 즉, 정상작동이라는 의미이다.

(해결방안) - transfer() 함수 사용

             - return value 체크

             - withdrawal 패턴 사용

 

9) Race Condition / Front Running

: 사용자에 따라 gasprice가 높은 transaction을 먼저 받아들일 수 있다. 따라서 정답을 알아맞히는 게임에서 A가 정답을 보냈는데 B가 이를 베껴 똑같이 관리자에게 보내게 되면 관리자는 gasprice가 높은 B를 먼저 보게 된다. 

(해결방안) 두 페이지를 나눠서 제공한다. 즉 제일 처음 transaction은 데이터를 숨겨서 보내고, 확인 시에 정답 데이터를 transaction 할 수 있도록 함. (hash 함수에서와 동일)