Solidity 취약점 #5

 

• Transaction ordering dependence

Front Running, Race Condition이라고도 불린다.

이더리움 노드는 트랜잭션 풀에서 트랜잭션을 선택해서 블록을 생성한다.

채굴자가 작업 증명 알고리즘을 통해 해시 값을 찾고 해당 트랜잭션이 포함된 블록을 채굴해야만 트랜잭션은 유효한 것으로 간주된다.

이때 채굴자는 트랜잭션 풀에서 블록에 포함시킬 트랜잭션을 임의로 선택할 수 있다.

이때 공격자는 트랜잭션 풀에서 채굴자들이 푸는 문제에 대한 답, 논스 값을 포함하는 트랜잭션 정보를 얻을 수 있다.

 

 

contract FindThisHash{

    bytes32 constant public hash = 0x5b5b97fafd9855eec9b41f75d8f334abd24fd;

    constructor() public payable {}

    function solve(string solution) public{

        require(hash == sha3(solution));

        msg.sender.transfer(1000 ether);

    }

}

 

위의 예제에서 특정 해시값을 도출하는 solution을 찾으면 그 값을 찾은 사람은 1000이더를 받을 수 있는 컨트랙트이다.

공격자는 이 솔루션을 트랜잭션 풀에서 보고 더 높은 가스로 호출하면 같은 블록내에서 더 먼저 실행될 가능성이 높다.

또한 상태를 읽고, 쓰는 트랜잭션의 경우의 Ordering이 바뀔 때도 관련 취약점이 악용될수 있다.

 

• 문제 요인 및 해결

이 공격을 수행할 수 있는 사람은 사용자(gasprice를 수정)와 채굴자(블록에서 트랜잭션을 재정렬)이다.

 

첫 번째는 가스 가격에 상한을 둬서 gasprice를 높여서 트랜잭션 우선순위를 갖는 것을 방지한다. 이 경우 채굴자의 공격은 막을 수 없다.

두 번째 방법은 커밋-공개 방식을 사용하는 것이다. 트랜잭션을 보낼 때는 정보를 숨긴채 전송하고, 해당 트랜잭션이 블록에 포함되면 데이터를 표시하는 트랜잭션을 다시 전송하는 것이다. 이 방법은 채굴자와 사용자가 트랜잭션의 내용을 결정할 수 없기 때문에 방지할 수 있다.

 

 

• Security Failure

변수 값이 항상 블록체인에 게시되기 때문에 변수를 비공개로 선언한다고 해서 보안이 보장되지는 않는다. 누구나 게시된 값을 검사하고 가능한 후속 값을 유추할 수 있다. 암호화 기술을 사용하면 문제를 완화할 수 있다.

 

 

• Exception disorder

 

예외가 일어날수 있는 부분에 대해서 조건에 따라 처리하는 코드가 없다면 계약을 취약하게 만들수 있다

 

• 악의적인 라이브러리

외부 라이브러리의 사용에 있어서 공격자가 라이브러리를 공격해서 라이브러리 사용자가 공격당하거나, 서비스 장애가 일어날수 있는 ..

 

 

예시 추가

 

2018년 smart mesh라는 iot 기반 블록체인 플랫폼에 가해진 공격

Integer overflow활용

 

function transferProxy(address from, address to, uint value, uint fee){

    if(balance[from]<fee + value) revert();

 

    if(balance[to]+value<balance[to] || balance[msg.sender]+fee < balance[msg.sender]) revert();

 

    balance[to] += value;

    balance[msg.sender] += fee;

    balance[from] -= value +fee;

   

}

 

Balance에 대한 로직이 핵심 로직이다.

그전에 from,to에 대해서 value값 검증이 있다.

처음 if는 from이 가진 값이 fee+value보다 작으면 안된다는 것이고

 

두번째 if문은 금액을 받는 to에게 value가 더해져서 overflow가 일어나거나 sender에게 fee가 더해져서 overflow가 일어나는 경우를 보는 것이다.

 

하지만 첫 번째 if문에 대한 검증이 더 필요하다.

T0 = from != msg.sender이고

Balance[to] = balance[from] = 0이라고 하자.

만약에 value가 0x8fff….fff이고 fee가 0x700….01로 들어오면 더한 값이 0 이되어 첫번째 if문이 통과하게 된다.

 

그리고 balance[to]에는 엄청난 value가 들어가게 된다.