— written by Park DoYeon / reviewed by Blockchain Valley Research Team

고팍스는 투자자들의 시장에 대한 올바른 이해와 투자를 돕기 위하여 가상자산 시장을 분석한 다양한 보고서를 게재하고 있습니다. 본 보고서의 게재는 블록체인 밸리와의 ‘가상자산인재 양성 및 콘텐츠 협업을 위한 산학협력 업무협약(MOU)’의 일환으로 진행됩니다.

TL;DR

• Pwnable (시스템해킹), Web Hacking, Crypto (암호학) 등 대부분의 해킹 분야에서는 자주 나오는 bug case를 정리한 자료가 항상 있었지만 블록체인 보안 분야에서는 이를 정리한 자료가 현저히 부족한 실정이다.
• 그래서 필자는 블록체인 보안 취약점 리서치를 위해 OpenZeppelin에서 만든 Ethernaut이라는 Wargame 사이트의 모든 문제를 풀었다. Ethernaut을 다 풀고도 여러 solidity Framework 의 이해를 위하여 반복적인 풀이를 진행했으며, 모든 문제를 대상으로 작성된 write-up 코드가 첨부된 GitHub Repository를 생성하였다. 풀이에 대하여 참고가 필요한 사람들은 방문하면 좋을 것 같다.

GitHub - parkttule/Ethernaut-all-solve-p6rkdoye0n

Contribute to parkttule/Ethernaut-all-solve-p6rkdoye0n development by creating an account on GitHub.

GitHubparkttule

• Smart Contract의 보안 취약점을 연구해본 사람은 알겠지만, 대부분의 Real World Attack Vector는 Logical bug로 터지는 취약점이 많다. 하지만 이런 유형의 취약점은 Smart Contract 마다 너무 다른 형태의 vector 형식으로 나타나게 되기 때문에 이번 글에서는 Ethernaut에서 풀었던 Logical Bug를 제외한 주요한 Attack Vector 들을 소개할 것이다.

목차

1. 서론
2. 본론 (Attack Vector)

2–1. Block Timestamp Manipulation

2–2. Integer Overflow / Underflow

2–3. Denial-of-Service (DoS)

2–4. Reentrancy Atttack

2–5. Storage Collision

2–6. Insufficient Validation

3. 결론

서론

하나의 transaction이 confirm 되고 블록으로 네트워크에 올라가게 되면 삭제가 불가능 하기 때문에 블록체인에서 보안은 정말 중요한 문제다. 그렇기에 이미 Audit을 받은 여러 Smart Contract도 지속적인 보안 개선을 위해 자신들의 서비스의 취약점에 대한 Bug bounty를 immunfi나 Hackerone과 같은 플랫폼을 통해 요청한다.

해커들은 취약점을 공부하고 리서치 하기 위해 해킹 문제 사이트인 Wargame을 풀며 여러 지식들을 습득한다. 블록체인 취약점을 공부하기 위한 사이트는 Ethernaut (Openzeppelin), Damn Vulnerable DeFi, Paradigm ctf, dreamhack 등이 있다.

해당 글은 Ethernaut 문제의 Write-up을 제공하는 것이 아닌, Smart Contract의 보안 취약점을 탐구하기 위한 학술적 목적의 글이라는 것을 일러둔다.

1. Block Timestamp Manipulation

Block Timestamp Manipulation 취약점은 Smart Contract의 논리가 블록의 Timestamp를 의존할 때 발생하는 취약점이다.

블록체인에서 각 Block에는 Block이 채굴된 시간을 나타내는 Timstamp가 있다. 이 Timstamp는 거래의 순서와 실행을 결정하므로 Smart Contract가 제대로 작동하는 데 매우 중요하다. Block Timestamp Manipulation은 Smart Contract의 이점을 얻거나 취약점을 악용하기 위해 Block의 Timstamp 를 변경하는 행위를 의미한다.

Example of Vulnerable Code

아래는 Block Timestamp Manipulation Attack Vector가 존재하는 Smart Contract 코드이다.

해당 Roulette contract 내부에 존재하는 spin 함수의 동작 방식은 다음과 같다 .

• spin 함수는 1 ether에 해당하는 금액을 받았는지 확인을 한다.
• block.timestamp의 모듈러 연산을 통한 임의의 난수를 생성한다.
• 해당 값이 0에 수렴하게 되면, 제출한 금액의 두 배에 해당하는 값을 호출자에게 송금한다.

하지만 이와 같은 설계는 Block Timestamp Manipulation 공격에 취약하며, block.timestamp의 값을 조작하게 된다면 공격자는 spin 함수에서 항상 승리할 수 있을 것이다.

아래는 Block Timestamp Manipulation attack vector를 활용한 Exploit 코드이다.

해당 Exploit 코드를 실행하면 난수를 임의로 설정했음에도 block.timstamp의 값이 조작되어 지속적으로 승리할 수 있었다.

Real-World Case

• Lottery SmartBillions Exploit (2017) : 2017년 10월 4일 SmartBillions는 자신들의 Smart Contract 보안 위험성을 ICO가 시작되기 전에 제거하고자 해커톤을 개최하였다. 이때 공격자는 Lottery contract에서 Block Timestamp Manipulation Attack Vector를 사용하여 400 ETH($120,000) 를 Drain 하였다.

Mitigation

• Avoiding Block Timestamps: Smart Contract를 작성할 때 기본적으로 block.timstamp의 값 사용을 피해야 한다.
• Using External Oracle: 난수를 사용해야 한다면 Smart Contract 내부에서 생성하는 것이 아닌, 외부에서 생성 후 오라클을 활용하여 데이터를 가져오는 방식으로 전환해야 한다.
• Following 15 Second Rule: “The Yellow Paper” 에서는 각 block.timstamp 값이 Parent Block의 block.timstamp 보다 커야 한다고 주장한다. 이더리움 프로토콜인 Geth와 Parity는 모두 미래 15초 이상의 Timestamp를 가진 Block을 거부한다.

• 만약 시간에 따라 변하는 이벤트의 시간 척도가 15초 내외로 변할 수 있고 무결성을 유지할 수 있다면, block.timestamp 를 사용하는 것이 안전하다.

2. Integer Overflow / Underflow

Integer Overflow / Underflow 취약점은 산술 연산이 비트 수로 저장할 수 있는 범위를 초과해서 생성하려고 할 때 발생한다. solidity에서는 대부분 부호 없는 정수 형 (ex. uint256, uint160, uint..) 데이터를 사용하여 산술을 진행하게 된다.

만약 산술 연산 중, 음수 값으로 변하게 된다면 Unsigned int 형식에 맞게 큰 값의 데이터로 바뀌게 된다 (Underflow), 반대로 비트 수로 표현할 수 있는 값의 max value로 값이 변하게 된다면 0부터 시작하여 작은 값의 데이터로 바뀌게 된다 (Overflow).

Example of Vulnerable Code

아래는 Integer Overflow / Underflow Attack Vector가 존재하는 Smart Contract 코드이다.

해당 Bank contract에는 다음과 같은 3가지 함수가 존재한다.

• deposit: 보낸 금액 만큼의 값을 balances mapping에 기록한다.
• withdraw: Parameter로 전달한 값 만큼 기존 balances mapping에 존재하는지 확인 후, 존재한다면 balances mapping에서 요청한 값 만큼을 감소 시키고 사용자에게 Parameter로 전달한 값 만큼의 금액을 송금한다.
• balanceOf: Parameter로 전달한 주소의 잔액을 확인한다.

하지만 withdraw 함수 내부에 Integer Underflow Attack Vector가 존재하여서 입금을 하지 않고 1을 parameter로 전달하고 withdraw 함수를 호출하게 된다면 Integer Underflow가 발생한다.

아래는 Integer Underflow attack vector를 trigger 시킨 Exploit 코드이다.

해당 코드를 실행하게 된다면 Mapping 값을 uint256의 Max value인 115792089237316195423570985008687907853269984665640564039457584007913129639935 ((2^256)–1) 로 변경되는 underflow가 발생한다.

Real-World Case

• BeautyChain (BEC) Token Attack (2018): 공격자는 batchTransfer 함수 내부에 존재하는 Overflow 취약점을 악용하여 BEC 토큰의 비정상적인 변동을 일으켰다. 해커는 많은 양의 BEC 토큰을 Drain 하였고, 이는 급격한 시장의 가격 폭락으로 이어졌다.

Mitigation

• Using solidity version 0.8.0 or higher: solidity에서는 버전 0.8.0 이상부터 자체 컴파일러에서 자체적으로 Integer Overflow와 Integer Underflow에 대하여 검사하도록 설계하였다. 그래서 0.8.0 버전 이상에서는 위와 같은 코드를 사용해도 취약점이 trigger 되지 않는다.
• Using SafeMath Library: solidity 0.8.0 미만 버전에서 사용했던 방식이다. 모든 산술 연산을 OpenZeppelin에서 만든 SafeMath Library를 사용하거나, 자체적으로 overflow와 underflow를 checking 하는 Library를 만드는 것이다.

Real world에서는 사실 대부분의 Smart Contract가 solidity 0.8.0 버전을 사용하고 있어서 해당 취약점을 간과하고 Bug hunting을 하는 researcher가 많지만, 이는 잘못된 판단이다.

0.8.0 버전에서도 Integer Overflow나 Underflow가 trigger 되는 여러 케이스들이 존재한다.

대표적으로 unchecked 함수의 사용이다. 해당 함수는 gas fee optimization을 위하여 만들어진 함수이고, Real world에서 나름 빈도 수가 높게 출현하고는 한다. 해당 함수 내부에 만약 Attack Vector가 존재한다면 trigger 시킬 수 있으니 주의 깊게 보기 바란다.

3. Denial-of-Service (DoS)

Denial-of-Service (DoS) 취약점은 Smart Contract의 기능을 손상 시킬 수 있는 취약점이다. 해당 취약점은 Web3 생태계 뿐 아니라 웹 사이트, 게임, 네트워크 등등 여러 방면에서 여전히 많은 빈도의 공격이 이어지고 있다.

Differences (DoS attacks in the Web3 ecosystem) vs (general DoS attacks)

한편, Web3 생태계에서 발생할 수 있는 DoS 공격과 우리가 알던 일반적인 DoS 공격은 차이가 존재한다.

우리가 기존에 알고 있던 DoS 공격은 반복적인 Request을 하거나 SYN flooding과 같은 여러 번의 TCP connection 지연으로 network의 traffic을 과부화 시켜 서비스의 기능을 손상 시키는 형태의 공격이었다.

하지만 블록체인은 기본적으로 이러한 DoS 공격에 예방하기 위해 하나의 request(Transaction, Block)에 대하여 증명 방식을 통해 증명 된 Block 만이 confirm 되도록 설계하였다.

그래서 Web3 생태계에서의 DoS 공격은 Smart Contract logic에 기반을 두고 trigger 시킨다.

Example of Vulnerable Code

아래는 Denial-of-service (DoS) 취약점이 존재하는 유명한 “KingOfEther” 코드이다.

KingOfEther contract에 존재하는 claimThrone 함수의 동작 방식은 다음과 같다.

• 해당 함수와 함께 Ether를 송금하게 되면 전역변수인 balance 값보다 큰지 비교 연산한다.
• king에게 balance에 해당하는 값 만큼을 송금해준다.
• 그리고 함수 호출자를 king으로, 보낸 금액을 balance로 설정하게 된다.

하지만 해당 코드에서는 전달 받은 함수 호출자의 contract가 Ether를 받지 않거나, fallback 함수로 무한 루프를 걸어서 Denial-of-service (DoS) 취약점을 trigger 시킬 수 있다.

다음은 해당 공격 시나리오를 반영한 Exploit 코드이다.

Attack Transaction을 분석해보면 Attacker contract 내부에 fallback 함수가 구현이 되지 않아 Ether를 보낼 때마다 revert를 발생하였다. 이렇게 된다면Transaction 자체를 confirm 시키지 못하게 되며 DoS 공격이 trigger 된다.

DoS 공격이 trigger 된 KingOfEther contract는 더 이상 기능을 못하게 되므로 시스템 운영에 큰 타격을 받게 된다.

아래와 같이 무한 루프를 걸어주는 방법도 있다.

gas limit를 300000000으로 걸고 Exploit 코드를 실행시켜준다면 OutOfGas 라는 메세지와 함께 gas 고갈을 시켰다는 내용을 알 수 있다.

Mitigation

• Sufficient Validation within a loop: Gas Exhaustion Attack에 대해서 설명을 생략하긴 했지만 만약 사용자에게 동적 배열을 Parameter로 받고 반복문 안에서 돌리게 된다면 Gas Exhaustion Attack이 가능하게 된다. 그러므로 반복문을 돌리기 전에는 충분한 검증을 한 후에 돌려야 한다.
• Gas Limit Consideration: 가스 한도에 대한 유의가 항상 필요하다. 루프나 복잡한 계산으로 인하여 가스 소비량이 높아질 수 있다. 가스 사용량을 optimization 하려면 가능할 때마다 라이브러리와 미리 계산된 값을 사용해야 한다.
• Use of Modifiers: 특정 함수 기능에 대한 액세스를 제한하려면 modifier를 사용해야 한다. 이를 통해 승인되지 않은 사용자가 잠재적으로 DoS 공격으로 이어질 수 있는 함수를 호출하는 것을 방지할 수 있다.
• Gas Price Estimation: 함수 호출 시 필요한 가스 가격을 추정하는 메커니즘을 구현한다. 이는 불필요한 Delay 없이 Transaction이 처리되도록 보장한다.

Real World Bug hunting을 할 때 가장 많이 보이는 case이므로, 해당 vector에 대해서는 주의 깊게 secure coding을 할 필요가 있다.

4. Reentrancy Atttack

Reentrancy Attack 이란 Smart Contract의 함수 호출 중 다시 내부 함수로 진입하며 일어나는 취약점이다.

해당 공격은 gas의 limitation이 없는 call 함수와 CA의 내부 함수가 호출 될 때 일어나는 fallback 함수들의 chaining으로 발생한다. 해당 공격은 Drain 까지 할 수 있는 취약점으로, 등록되어 있는 cvss가 Critical로 분류되는 파급력이 강한 취약점이다.

Example of Vulnerable Code

해당 Smart Contract는 간단한 Vault contract이며, 구성 요소는 다음과 같다.

• deposit : 해당 함수를 호출한 EOA mapping 값에 함수 호출과 함께 보낸 Etther 만큼 잔액을 더해준다.
• withdraw : 해당 함수를 호출하면 호출한 EOA에 충분한 잔액이 있는지 확인을 해주고 충분하다면 EOA에 call 함수를 통해서 요청한 값만큼 출금해준다. 호출이 끝난 이후 잔액을 출금한 값만큼 차감해준다.

얼핏 보면 아무런 취약점이 없는 코드 같지만 해당 Smart contract 코드에는 Reentrancy Attack attack vector가 존재한다.

call 함수로 call data에 CA 함수의 Signature value가 아닌, 빈 바이트 상태로 CA의 함수를 호출하거나 Ether를 보내게 되면 CA는 CA 내부에 있는 receive 함수와 fallback 함수로 call 함수 실행 도중 Transaction flow를 옮길 수 있다.

이를 다이어그램으로 나타내면 다음과 같다.

처음으로 withdraw 함수를 호출하면 Vault contract 내부에 있는 call 함수가 Hacker의 CA로 요청이 갈 것이고, 그렇다면 Hacker CA 내부에 존재하는 receive 함수로 withdraw 함수를 재 호출하며 Transaction flow를 control 할 수 있게 된다. 계속해서 반복하면 최종적으로 Vault에 있는 모든 자금을 Drain 할 수 있게 된다.

아래는 위의 공격 시나리오를 반영한 Exploit 코드이다.

Exploit 코드를 실행하면 재 진입을 지속적으로 하는 Attack Transaction을 볼 수 있다.

해당 공격으로 최종적으로 Vault contract에 존재하는 모든 자금을 Drain 할 수 있다.

Real-World Case

• Grim Finance Exploit (2021): 공격자는 Flashloan 으로 빌린 자금을 베이스로 Reentrancy Attack 을 사용하여 유동성이 확보된 토큰의 양을 재진입 단계마다 증가 시키며 최종적으로 Flashloan을 상환하고 $30M규모의 자금을 Drain 하였다.

Mitigation

• Using noreentrant modifier: Real World에서 가장 많이 사용하고 있는 방법이다. modifier가 실행될 때 전역변수로 정의 되어 있는 reentrant state value를 컨트롤 하며 Reentrancy Attack 공격을 방어한다.
• Adjusting the Order of Call Functions: Real World에서 사실 단일 Reentrancy Attack을 막기 위하여 modifier를 설치한 경우여도 Reentrancy Attack이 가능한 여러 케이스들이 존재한다 (여기서는 다루지 않는다). 그래서 가장 좋은 방법은 Reentrancy Attack vector가 존재하여도 공격의 이점을 얻을 수 없도록 Reentrancy Attack vector (callback 함수를 trigger 시키는 함수) 를 함수 마지막에 배치 시키는 것이다. 그렇다면 Reentrancy Attack을 trigger 시켜도 공격에 대한 이점을 가져가지 못하게 된다.

5. Storage Collision

Storage Collision이란 두 개 이상의 contract에서 서로 다른 Storage layout을 사용할 때 delegatecall을 호출할 때 Storage Slot이 충돌하여 발생하는 취약점이다.

해당 취약점은 예상치 못한 동작, 자금의 Drain, proxy admin 조작 등의 여러가지 부정적 피해를 안겨줄 수 있다.

아래는 Storage Collision 취약점이 존재하는 코드이다.

Example of Vulnerable Code

해당 코드는 Proxy contract의 로직을 구현하였다. Token contract의 logic을 execution 함수로 사용하여 Storage Token contract에 맞는 storage slot에 데이터를 저장하도록 설계 되어있다.

함수의 종류가 많으므로 함수에 대한 설명은 생략하도록 하겠다.

하지만 Proxy Contract 내부에 잘못된 Storage slot에 admin의 주소가 존재한다. 이는 Token contract 내부에 존재하는 totalbalance 변수와 같은 Storage slot에 존재하여 Storage Collision 취약점이 발생한다.

totalbalance의 값은 deposit 함수와 withdraw 함수가 호출될 때 값이 설정된다. 그렇다면 deposit 함수에 Parameter를 전달할 때 아래와 같은 방식으로 전달하면 admin의 주소를 마음대로 조작할 수 있게 된다.

uint256(uint160(hacker)) - uint256(uint160(IProxy(address(target)).admin()));

Storage Collision 취약점으로 admin을 조작하고 logic에 해당하는 주소를 악성 contract로 변경을 해주면 Proxy contract에 존재하는 모든 자금을 Drain 할 수 있게 된다.

아래는 위와 같은 공격 시나리오를 반영한 Exploit 코드이다.

Storage Collision을 이용하여 admin 주소를 성공적으로 바꿀 수 있었고, 아래와 같은 악성 contract로 logic을 변경하여 최종 Drain을 시도 하였다.

contract Helper {
function exploit(address _hacker) external {
_hacker.call{ value: address(this).balance }("");
}
}

Real-World Case

• Audius Governance Exploit(2022): 2022년 7월 24일, Audius의 Governance, Stacking, delegation bug로 인해 $1,8M 상당의 $AUDIO 토큰을 공격자의 지갑으로 전송하라는 Governance Proposal이 통과되었다. Storage Collision 취약점을 사용한 공격자는 성공적으로 자산을 자신의 지갑으로 이체하였다.

Mitigation

• Using unstructured storage: _implementation Proxy의 첫 번째 Storage slot에 주소를 저장하는 대신 pseudo random slot을 선택한다. 이 슬롯은 충분히 무작위이므로 동일한 slot에서 변수를 선언하는 논리 계약의 확률은 무시할 수 있다.

아래는 EIP-1967 사용하는 방식의 pseudo random slot logic의 예시이다.

bytes32 private constant implementationPosition = bytes32(uint256(
keccak256('eip1967.proxy.implementation')) - 1
));

6. Insufficient Validation

Insufficient Validation은 Smart Contract에서 불충분한 검증을 했을 때 발생하는 logical bug의 한 종류이다.

필자는 사실 이번 글에서 Logical bug에 대한 내용은 다룬다고 하지는 않았지만, Real World에서 research 를 진행할 때 항상 주의 깊게 보는 attack vector 라서 “External Call Function Endpoints”에 관련된 내용을 공유해보고자 한다.

External Call Function Endpoints

기본적으로 Insufficient Validation 취약점은 함수 Parameter로 address나 Contract를 받고 External Call Function Endpoints 로 외부 호출을 진행했을 때 발생한다.

함수에 대한 Parameter가 address나 Contract일 때, 함수를 분석할 때는 위와 같은 External Call Function Endpoints 들을 중심적으로 분석하면 수월하게Insufficient Validation vector를 trigger 시킬 수 있다.

아래는 Insufficient Validation 취약점이 존재하는 코드다.

Example of Vulnerable Code

Vault contract는 “MTN” Token contract를 생성하고 Token을 관리하는 Smart Contract 이다. Vault contract의 구성 요소는 다음과 같다.

• deposit : Parameter로 token의 address를 받고 송금한 금액 만큼 MTN 토큰을 minting 해준다.
• withdraw : Parameter로 token의 address와 출금하고자 하는 양의 값을 받고 잔액의 유무를 검사 한 다음에 호출자에게 요청한 금액만큼 잔액을 송금해준다.

하지만 해당 contract는 Insufficient Validation의 취약점이 존재하며, token address를 Parameter로 전달할 때 악성 contract로 전달하게 된다면 Transaction flow를 control 할 수 있을 것이다.

다음은 해당 공격 시나리오를 반영한 Exploit 코드이다.

해당 코드를 실행해주면 다음과 같이 Vault contract에 존재하는 모든 자금을 Drain 할 수 있다.

Real-World Case

• OlympusDao Exploit (2022): 2022년 10월 21일, OlympusDao 에서 관리하는 BondFixedExpiryTeller contract가 공격자에게 악용되어 $292K (30500 OHM) 에 해당하는 금액을 도난 당했다. 해당 공격은 redeem function 내부에 input에 대한 어떠한 validation도 적용 시키지 않아서 발생한 공격이었다.

Mitigation

• Sufficient Validation: 해당 취약점은 대부분 input에 대한 적절한 검증이 부족해서 발생한 취약점이다. 최대한 많은 케이스들을 고려하여 except 상황을 잘 handling 할 수 있도록 하는 것이 중요하다.

결론

immunefi나 HackerOne과 같은 Bug bounty 플랫폼에서 Bug hunting을 해보거나 Real world에서 Audit을 해보면 기본적으로 Offensive Security 관점으로 취약점을 trigger 시키고 PoC (Proof-of-Concept)를 작성 해야 한다.

OpenZeppelin에서 만든 Ethernaut은 Smart Contract에서 발생하는 보안 취약점들을 공부하고 연구할 수 있도록 다양한 edge case 에서 Smart Contract를 해킹할 수 있는 환경을 제공해주었고, 이는 Smart Contract Auditor, Bug Hunter로 성장하고자 하는 많은 사람들에게 도움을 주었다.

Ethernaut은 해당 글에서 미처 다루지 못한 취약점들과 여러 경험을 제공하고 있으니 Smart Contract Auditor나 Bug Hunter로 성장하고 싶으신 분들은 꼭 풀어보길 권장한다.

또한, 이번 글에서 사용한 Vulnerable Code와 PoC 코드들은 해당 GitHub repository에 올려두었으니 방문해보기 바란다.

Reference

• https://ethernaut.openzeppelin.com/
• https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#unstructured-storage-proxies
• https://medium.com/chainlight/en-audius-variant-scanner-scanning-storage-collisions-between-ethereum-contracts-4d2d64b77566
• https://medium.com/coinmonks/smart-contract-security-block-timestamp-manipulation-baec1b95c921
• https://medium.com/@xoredtwice/defi-vulnerabilities-fd6b5ffd449a
• https://medium.com/@solidity101/100daysofsolidity-073-understanding-denial-of-service-attacks-in-solidity-smart-contracts-a790de3d0943
• https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/timestamp-dependence/

Blockchain Valley — Korea University-based Blockchain Research & Development Academy

disclaimer: 본 보고서는 단순한 정보 제공을 위해 외부에서 기고한 문서이며, 특정 가상자산에 대한 추천을 하는 것이 아닙니다. 해당 내용을 바탕으로 투자 결정을 하지 마십시오. 본 리서치는 학술적 연구 및 정보 제공을 목적으로 작성되었으며, 이 보고서에 포함된 어떠한 내용도 투자 조언이 아니며 투자 조언으로 해석되어서도 안됩니다.