The Eye of Horus, 이더리움 스마트 컨트랙트에 대한 공격 탐지 분석 프레임워크
본 내용은 The Eye of Horus: Spotting and Analyzing Attacks on Ethereum Smart Contracts [1] 논문에 대한 내용을 다루고 있다.
이더리움은 블록체인 상 튜링 완전한(turing-complete) 스마트 컨트랙트 개념을 도입함으로써 디지털 자산을 거래하는데에 큰 변혁을 일으켰다. 프로그램의 일종인 스마트 컨트랙트는 블록체인을 거쳐 실행 및 저장되며, 변조 방지(tamper-resistant) 특성으로 인해 한 번 배포되면 수정이 불가능하다.
지난 수 년간 이더리움이 꾸준히 성장해오는 동안 수많은 스마트 컨트랙트들이 배포되었고, 이 가운데 취약한 컨트랙트를 이용해 자금을 탈취하려는 시도들도 꾸준히 발생했다. 많은 사람들에게 잘 알려진 The DAO 해킹 사건이나 Parity wallet 해킹 사건 등으로 인해 상당한 자금이 해커에 의해 도난당하거나 이더리움 블록체인 네트워크 상에 영원히 동결되어 자산을 사용할 수 없는 사태가 벌어지기도 했다.
이러한 상황에 맞춰 스마트 컨트랙트 취약점을 찾기 위해 많은 연구가 이루어졌고 OYENTE, Vandal, VeriSmart, SODA 등 정적, 동적 분석을 이용한 다양한 취약점 탐지 툴들이 생겨났다. 하지만 논문에서는 대부분의 툴들이 스마트 컨트랙트의 바이트 코드 분석에만 초점을 맞추고 있으며, 각 컨트랙트 별 트랜잭션이나 행동들에 관해서는 잘 다루고 있지 않다고 주장하고 있다.
또한, 대부분은 이더리움 클라이언트를 수정해야 하거나, 길고 복잡한 공격 탐지 스크립트를 작성해야 한다는 것을 전제로 하는 경우가 있다고 하며, 공격 탐지 이후에 도난당한 자산에 대해서 직접적으로 추적하는 툴은 없다라고 표현하고 있다.
이 논문의 저자는 위와 같은 내용을 바탕으로 하여 Horus라는 이름의 공격 탐지 프레임워크를 제안하였다. 해당 프레임워크는 이전 블록체인 데이터로부터 스마트 컨트랙트 공격들을 자동으로 탐지하고 분석할 수 있는 기능을 가지고 있다. 또한, 이더리움 계정 간 도난당한 자산의 흐름을 추적하고 정량화 할 수 있는 수단도 제공하고 있다.
그렇다면 이 Horus에 대해 자세히 한 번 들여다보도록 하자.
The Horus Framework
Horus는 이더리움 스마트 컨트랙트에 대한 종적 연구(longitudinal study, 연속적 시간 간격으로 동일한 집단을 관찰하는 것 [2]) 수행 과정을 자동화하고 있다. 위에서 언급했던 것과 같이 이전의 기록을 통해 스마트 컨트랙트 공격을 탐지하고 분석할 수 있는 능력이 있으며, 이더리움 계정 간 도난당한 자산의 흐름을 추적하는 수단을 제공하고 있다. 이러한 기능 덕분에 공격자의 행동을 연구하는데에도 유용하게 쓰일 수 있다고 한다.
Horus의 아키텍처는 [그림 1]과 같이 EAT(Extract, Analysis and Tracing), 총 3개의 진행 과정으로 이루어져 있다.
각 과정에 대해 대해 간단히 기술해보자면,
- Extraction (추출): 이더리움 블록체인 네트워크부터 실행 관련 정보(execution related information)로 추출된 후 datalog fact로 저장된 트랜잭션 목록을 입력으로 받는다. (논문에서 해당 문장에 대한 정확한 의미를 파악하는데 장시간을 고민했지만 최종적으로는 다음과 같이 번역하였다.)
- Analysis (분석): Datalog relation및 query set을 입력으로 하여 추출된 datalog facts를 통해 공격에 대한 내용을 식별한다.
- Tracing (추적): 분석을 통해 얻은 공격자 계정 목록을 검색하여 해당 계정과 관련된 모든 트랜잭션(일반 트랜잭션, 내부 트랜잭션 및 토큰 전송) 기록을 가져온다. 이후 위의 계정으로 들어오고 나간 자산의 흐름을 포착한 그래프 데이터베이스가 생성되며, 해당 DB는 도난당한 자산에 대한 추적을 강화하기 위해 레이블링된 계정 목록을 추가로 이용해 보완할 수 있다.
라고 설명할 수 있으며, 각 단계에 대한 자세한 내용은 아래에 순서대로 설명하도록 하겠다.
Extraction
추출 단계에 있는 extractor의 역할은 이더리움 클라이언트에게 트랜잭션 리스트에 대한 실행 추적(execution trace)을 요청하고, 실행 의미(semantics of execution)를 반영하는 논리 릴레이션(logic relation)으로 변환한다. 여기서 실행 추적은 실행된 EVM(Ethereum Virtual Machine) instructions의 순서 리스트로 구성된다.
리스트의 각 레코드에는 실행된 opcode, 프로그램 카운터(program counter), 호출 스택 깊이(call stack depth) 그리고 현재 스택 값(current stack value)에 대한 정보가 포함된다. 하지만 실행 추적은 이전의 블록체인 데이터로부터 직접 얻을 수는 없고 컨트랙트 실행 중에만 기록될 수 있다. 다행히 Geth(Go based Ethereum client)는 debug_traceTransaction 및 debug_traceBlockByNumber 함수를 통해 디버그 기능을 제공하는데, 이를 이용하여 과거의 트랜잭션 기록에 대해 재실행(replay)함으로써 실행 추적에 대한 정보를 얻을 수 있다.
또한, 실행 추적은 Remote Procedure Call (RPC)*을 통해 요청되는데, 기존의 연구들은 RPC가 너무 느린 탓에 Geth를 수정하여 실행 추적 검색 과정의 속도를 높였다고 한다. 하지만 이렇게 되면 사용자가 Geth의 기본 버전을 사용할 수 없게 되고, 새로운 버전으로 업데이트 될 때 마다 수정 사항을 일일히 전달해야 하기 때문에 어려움이 따를 수 밖에 없다.
실제로 이 논문이 작성될 당시 수정된 버전의 Geth를 공개한 연구는 없었다고 하며, 이는 결과를 재현해내는 것을 비롯하여 향후 연구를 더 어렵게 만든다. 이러한 이유로 저자는 Geth를 수정하는 대신 RPC를 통한 실행 추적 검색 속도를 개선하는 방향으로 실험을 진행했다고 한다.
이 과정에서 Geth에서 제공하는 디버그 기능을 통해 얻은 실행 추적에는 분석과 무관한 정보들이 많이 있음을 확인할 수 있었다. [그림 1]의 캡션에서 확인할 수 있다시피 extractor와 tracer는 커스텀하게 구성할 수 있기 때문에 논문에서는 JavaScript로 작성된 자체 코드를 사용하였다. 이를 통해 실행 추적에 대한 정보에서 현재의 프로그램 카운터, 남은 가스(gas), instruction에 대한 가스 비용의 내용을 제거하고, 기존에 실행된 모든 instruction에 대한 스택 및 메모리의 전체 스냅샷을 반환하는 대신 실행된 instruction과 관련된 스택 요소(stack element) 그리고 메모리 조각(memory slice)만 반환하도록 했다. 이를 통해 실행 추적 정보의 크기를 줄이고 실행 속도를 향상시킬 수 있었다.
* Remote Procedure Call: 원격 제어를 위해 별도의 코딩을 하지 않아도 서로 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 해주는 프로세스 간 통신 기술이다. [4]
위에서 언급하고 있는 기존 연구에 대한 자세한 정보와 EVM의 구조적 특징에 대해서는 필자도 기본적인 내용만을 참고하였기 때문에 추가적인 내용이 궁금한 경우 원문을 참고하여 기존 연구에 대한 정보를 얻거나 이더리움 공식 홈페이지를 통해 EVM의 구조에 대해 자세히 조사해보면 좋을 것 같다.
Extractor를 통해 추출한 datalog facts 목록은 [리스트 1]과 같다. 위 내용은 실행 추적의 각 레코드에 대한 처리를 반복한 후 관련 정보를 인코딩하여 생성한 것이다. 대부분의 fact는 call 함수와 같은 로우 레벨(low level) EVM 연산과 관련되어 있고, 그 외에는 하이 레벨(high level) 연산으로 이루어져 있다.
예를 들어, erc20_transfer fact의 경우 ERC-20 토큰 이벤트인 Transfer를 가리키는데, 이는 토큰이 전송될 때마다 발생하는 함수이다. 여기서 contract는 토큰 컨트랙트 주소를 가리키며, from과 to는 발신자와 수신자를 각각 나타낸다.
[리스트 1]과 같은 내용은 extractor를 수정할 수 있다는 점에서 이 논문에서 제안한 것과 다른 연구에서도 쉽게 수정하고 확장할 수 있다는 점에 주목해야 한다. 이 논문에서는 기본 타입의 number와 symbol을 사용한 것뿐만 아니라 새로운 세 가지 타입을 정의하기도 했다.
- Address: 160 bits 값
- Opcode: EVM opcode의 집합
- Value: 256 bits 스택 값
Analysis
Horus의 두 번째 과정은 분석 단계이다. 이 단계에서는 datalog engine을 사용해서 주어진 datalog relation과 query 정보가 이전에 추출된 datalog facts와 일치하는지 여부를 분석한다. 이 때, datalog query는 스마트 컨트랙트의 취약점을 이용해 공격에 성공한 악의적인 트랜잭션들을 식별하게 된다.
논문에서는 Soufflé이라고 하는 정적 분석용 datalog engine 툴을 사용했으며, 이 툴은 datalog relation 및 query를 고도로 최적화된 C++ 실행 파일로 컴파일하여 사용한다고 한다.
수많은 스마트 컨트랙트 취약점이 있지만 이 글에서는 NCC Group이 선정한 Top 10 순위에 따라 재진입(reentrancy), 패리티 지갑 해킹(Parity wallet hacks), 정수 오버플로우(integer overflows), 처리되지 않은 예외처리(unhandled exceptions) 그리고 짧은 주소 공격(short address attack)에 대해서만 다룰 예정이며, 아래 [리스트]를 통해 공격 탐지에 대한 datalog query를 확인할 수 있다.
재진입 (Reentrancy)
재진입 문제는 하나의 컨트랙트가 다른 컨트랙트를 부를 때 이전의 컨트랙트의 상태가 완전히 처리되기도 전에 새로운 내용을 호출할 때 발생한다. Horus는 동일한 caller와 동일한 callee를 호출하는 것으로부터 발생하는 주기적 호출(cyclic call)을 식별하여 재진입 공격을 탐지한다.
[리스트 2]와 같이 두 개의 성공적인 call (result=1)이 동일한 트랜잭션 hash, caller, callee, id 그리고 branch를 공유하는지 확인하고, 두 번째 call이 가진 depth2가 첫 번째 call의 depth1보다 큰 지 확인한다. 이후에 두 개의 storage 연산이 첫 번째 call과 같은 depth를 갖는지, SLOAD 연산이 첫 번째 call 전에 발생하는지 그리고 SSTORE 연산이 두 번째 call 직후 발생하는지를 확인한다. 위의 모든 과정 중 조건이 일치하지 않으면 재진입 공격이 발생했다고 판단하게 된다.
아래의 나머지 문제들도 재진입 문제와 유사하게 datalog query를 분석함으로써 공격에 대한 부분을 탐지한다.
패리티 지갑 해킹 (Parity Wallet Hacks)
패리티 지갑 해킹 관련해서는 두 가지 사건[5]이 존재한다. 두 가지 모두 잘못된 접근 제어 구현(faulty access control implementation)으로 인해 공격자가 자신을 컨트랙트의 소유자로 설정하여 자금을 전송한다거나 컨트랙트를 파괴하는 등의 치명적인 행동을 취할 수 있었다.
(사건에 대한 자세한 내용은 생략하였지만) Horus는 첫 번째 패리티 해킹 사건에 대해 다음과 같은 탐지 방식을 사용했다.
두 transaction t_1과 t_2 모두 동일한 발신자와 수신자를 가지는지 보고, t_1의 input1 앞 4 bytes(ex. e46dcfeb)가 initWallet* 함수의 function signature의 내용과 일치하는지 확인한다. t_2 또한 input2 앞 4 bytes(ex. b61d27f6)가 execute 함수의 function signature 내용과 동일한지 확인한 다음 t_2의 일부인 call 함수가 있는지 그리고 t_2가 t_1 이후 실행되었는지, 마지막으로 코드 끝에 있는 조건에 부합하는 지 과정을 모두 확인함으로써 판단을 내린다고 한다.
* initWallet: 지갑이 생성되면 Wallet 컨트랙트를 배포하고, delegateCall을 통해 지갑을 초기화시키기 위한 기능 [6]
두 번째 패리티 해킹 사건에 대한 내용도 첫 번째와 유사한 방식으로 탐지했으며, 하나 다른 점이라면 t_2의 input2 앞 4 bytes(ex. cbf0b0c0)가 kill 함수의 function signature와 일치하는지 그리고 t_2가 selfdestruct 함수를 포함하고 있는 지를 확인했다는 점이다.
정수 오버플로우 (Integer Overflows)
Horus는 arithmetic 연산으로 유입되는(flows into) CALLDATALOAD 또는 CALLDATACOPY opcode에 대해 산술 결과가 EVM이 반환한 결과와 다른 경우에 대한 데이터를 확인함으로써 오버플로우를 탐지했다. 이후 산술 연산의 결과가 SSTORE storage 연산으로 유입된 후 erc20_transfer가 발생하는지 확인한다. 이 때, amount는 산술 연산에 사용된 두 개의 연산자 중 하나이다.
논문에서는 토큰 스마트 컨트랙트가 과거에 정수 오버플로우로 인해 빈번한 피해를 입었다는 것을 확인했기 때문에 ERC-20 토큰과 관련된 정수 오버플로우 문제에만 초점을 맞췄다고 한다.
처리되지 않은 예외사항 (Unhandled Exception)
스마트 컨트랙트에 의해 실행되는 내부 호출(inner call)은 언제든 실패할 수 있고, 기본적으로 호출이 실패하면 상태 변경(state change) 정보가 롤백된다.
원래는 개발자가 모든 호출에 대한 결과를 사전에 확인하고 적절한 예외처리를 수행해야 하는데 많은 사람들이 이러한 예외처리를 무시하거나 놓치는 경우가 생긴다. 예시로 송금과 관련된 코드에서 이러한 경우 문제가 발생하면 자금이 정당한 소유자에게 전달되지 않는 경우가 생길 수 있다.
Horus는 CALL이라는 opcode를 가진 호출이 0보다 큰 amount로 실패했는지 그리고 결과가 어떤 condition에서 사용되지 않았는지 확인함으로써 처리되지 않은 예외사항을 탐지한다.
짧은 주소 (Short Address)
분석 단계의 마지막 취약점인 짧은 주소 공격이다.
ERC-20의 transfer 및 transferFrom 함수는 전송할 대상에 대한 주소와 토큰의 개수를 적도록 하고 있다. 실행 과정 동안 EVM은 트랜잭션 인자(transaction argument)가 정확히 32 bytes로 인코딩되지 않으면 입력의 끝부분에 길이에 맞게 0을 추가한다. 이렇게 되면 전송될 토큰 개수 또한 의도치 않게 증가하게 되는 경우가 생길 수 있다.
공격자들은 이러한 사실을 이용하여 0으로 끝나는 주소를 생성하고 이 0을 생략한 채로 다른 사람이나 서비스를 속여 잘못된 형식의 주소를 포함한 후 전송 요청 기능을 호출할 가능성이 있다.
Horus는 이를 탐지하기 위해 transaction의 input 앞 4 bytes가 transfer의 function signature(ex. a9059cbb) 또는 transferFrom의 function signature(ex. 23b872dd)와 일치하는지 확인한다.
Transfer 함수에 대해서는 input 길이가 68보다 작은지 확인하는데, 예를 들어 4 bytes의 function signature, 32 bytes의 대상 주소 그리고 32 bytes의 amount가 포함될 수 있다.
TransferFrom 함수에 대해서는 input 길이가 100보다 작은지 확인하는데, 예를 들어 4 bytes의 function signature, 각 32 bytes의 from 주소와 to 주소 그리고 32 bytes의 amount가 포함될 수 있다.
그 다음 위의 내용을 바탕으로 erc20_transfer 함수가 실행되는지 확인하는 과정을 거치게 된다.
[리스트 7]의 길이를 구하는 과정에서 나누기 2를 하고 있는 이유는 16진법 형태를 바이트로 바꾸기 위함이다.
Tracing
지금까지 Horus의 Extraction과 Analysis 과정을 모두 살펴봤다. 사실상 Analysis 과정에서 취약점 파악의 대부분을 설명하고 있다고 생각하지만 논문에서는 Tracing 단계에 부가적인 기능을 추가하였다.
Horus의 마지막 과정인 Tracing 단계에서는 공격자 계정으로부터 레이블링된 계정(labeled account)에 이르는 이더리움 혹은 토큰과 같은 도난당한 자산들을 추적한다. 처음 설명했던 것과 같이 tracer 또한 커스텀하여 사용할 수 있으며, datalog 분석 과정을 통해 식별된 악의적 트랜잭션들로부터 발신 주소와 타임스탬프를 추출함으로써 추적이 시작된다. 이 때, 발신 주소는 공격자에 속한 계정으로 간주한다.
Horus의 tracer는 Etherscan의 API를 이용하여 각 발신 주소에 대한 일반 트랜잭션, 내부 트랜잭션 및 토큰 전송 기록을 검색하고 해당 내용을 Neo4j라고 하는 그래프 데이터베이스에 불러온다.
계정들은 꼭짓점들(vertices)로, 트랜잭션은 이들을 잇는 방향 그래프들(directed edges)로 인코딩 된다. 또, Horus는 계정의 타입을 공격자 계정, 레이블링 되지 않은 계정, 레이블링 된 계정 이렇게 세 가지로 구별했다.
모든 계정 유형은 주소를 가지고 있으며, 레이블링된 계정들은 카테고리(ex. exchange)와 레이블(ex. Kraken 1)을 포함하고 있다. 또한 각 트랜잭션 유형에는 트랜잭션 값, 해시 및 날짜가 들어있고, 토큰 트랜잭션에는 토큰 이름, 심볼 및 십진수 수(number of decimals)가 포함되어 있다.
논문에서는 204개의 카테고리에 속하는 5,437개의 라벨을 다운받았으며, 이에 속하는 트랜잭션들을 앞으로 불러오게 되면(loading transactions forwards)공격자가 훔친 자산을 어디로 보냈는지 알 수 있고, 트랜잭션을 뒤로 불러오면 (loading transactions backwards) 공격자가 어디에서 자금을 얻었는지 알 수 있다.
일반적으로 트랜잭션을 불러올 때 공격자의 계정에서 시작하며, 최대 홉(hop)* 수에 대한 동일한 트랜잭션의 일부인 인접 계정의 트랜잭션을 재귀적으로 불러온다. (이 부분 또한 번역에 어려움이 있었다.)
논문에서는 1,000개 이상의 트랜잭션을 가진 계정은 불러오지 않았는데, 이는 거래소나 도박과 관련된 스마트 컨트랙트에서 발생한 다량의 트랜잭션이 그래프 데이터베이스를 지나치게 부풀릴 것을 방지하기 위함이라고 한다. 또한, 트랜잭션을 뒤로 불러올 때는 공격 타임스탬프 이전에 발생한 트랜잭션만 불러오고, 트랜잭션을 앞으로 불러올 때는 공격 타임스탬프 이후에 발생한 트랜잭션만 불러온다.
모든 트랜잭션들을 불러온 이후에는 Neo4j의 자체 graph query 언어인 Cypher를 이용하여 그래프 데이터베이스를 query 하게 되고, 이를 통해 도난당한 자금의 흐름을 추적할 수 있게 된다.
* 홉(hop): 컴퓨터 네트워크에서 출발지와 목적지 사이에 위치한 경로의 한 부분 [9]
Evaluation & Validation
논문에서는 이더리움 ETL 프레임워크*를 사용하여 1,000만 번 째 블록까지 배포된 모든 스마트 컨트랙트에 대한 트랜잭션 목록을 검색했다. 이를 통해 총 697,373,206개의 트랜잭션과 3,362,876개의 컨트랙트를 수집했으며, 타임스탬프 범위는 2015년 8월 7일부터 2020년 5월 4일까지에 해당한다.
* 이더리움 ETL 프레임워크: 블록체인 데이터를 관계형 DB 또는 csv와 같은 포맷으로 변환해주는 프레임워크
위에서 수집한 컨트랙트 중 거래가 없거나 제대로 실행되지 않은 코드가 있는 트랜잭션의 경우를 비롯해 2016년에 발생한 DoS(denial-of-service) 공격에서 발생한 트랜잭션들은 모두 제외하였다.
모든 필터링 과정을 거친 이후 총 371,419,070개의 트랜잭션과 1,234,197개의 스마트 컨트랙트가 포함된 dataset을 가지게 되었다. Horus는 이를 통해 약 700GB에 달하는 datalog facts를 생성해 실험을 진행하였다.
그래서 Horus를 사용한 결과는 어떨까?
[표 1]의 내용과 같이 Horus를 이용하여 약 1,888개의 공격을 받은 컨트랙트와 8,095개의 악의적인 트랜잭션을 발견하였다. 이 중 46건의 재진입 공격, 600건의 패리티 지갑 해킹 공격, 125건의 정수 오버플로우 공격, 1,068건의 처리되지 않은 예외 공격 그리고 55건의 짧은 주소 공격을 확인했다.
패리티 지갑 공격의 경우 첫 번째 해킹 사건에 의해 다수의 피해를 입었고, 정수 오버플로우 공격의 경우 주로 언더플로우(Underflow) 문제가 다수를 차지하고 있었음을 확인할 수 있었다.
[표 1]에서의 용어 중 TP는 true positives*, FP는 false positives* 그리고 p는 정확도를 나타낸다. Horus를 이용한 공격 탐지 분석의 정확도는 약 99.54%에 달했다고 주장하고 있다.
* True positives: 실험 결과가 true이면서 동시에 실제 발생한 경우 (true)
* False positives: 실험 결과는 true이지만 실제 발생하지 않은 경우 (negative)논문에서 검증한 여러가지 예시를 들고 있는데 글이 너무 길어지는 것 같아 그 중 한 가지만 아주 간단하게 다루도록 하겠다. 위에서 존재했던 여러가지 취약점들에 대한 모든 검증이 궁금한 경우 논문을 참고해보면 좋을 것 같다.
이 중 재진입 공격에 대한 내용을 보자면, 취약점 분석 논문 중 SEREUM에서 총 16개의 취약 컨트랙트를 발견하였고, 그 중 14개는 false positives의 결과를 얻었다고 한다. True positives에 포함되는 내용은 The DAO 해킹 사건과 DSEthToken에 관한 내용이었고, Horus 또한 위의 두 가지만 TP로 발견할 수 있었다고 한다.
또, ÆGIS 라는 논문과 비교해봤을 때 결과로 보고한 7건 모두, 그리고 SODA가 발견한 26개의 컨트랙트 중 25개를 TP로써 발견했다고 한다. 나머지 1개는 재진입 공격에 취약한 문제는 아니었던 것으로 판단했다. 심지어 SODA가 보고한 5개의 false positives 중에서 3개를 TP로 발견하였고, 보고한 내용이 잘못되었음을 확인하기도 했다.
모든 내용을 통틀었을 때 기존에 스마트 컨트랙트에 대한 공격 또는 취약점 문제에 대해서는 Horus의 분석 기능을 통해 대부분 발견하였고, 잘못된 내용을 바로잡기도 했다.
아래의 [그림]들은 각각 캡션에 달아놓은 내용대로 실험을 진행하면서 얻은 결과를 시각화한 자료이다. 특히 [그림 3]에서 고점을 찍은 4개의 공격 중 앞의 3개는 The DAO와 Parity wallet 해킹 사건이 주를 이루고 있음을 보여주고, 마지막은 2020년 이후 발생한 유니스왑(Uniswap)과 Lendf.me 해킹을 다루고 있음을 확인할 수 있다.
나머지 자료 또한 Horus에서 분석한 내용이며, 실제로 Horus를 이용하여 유니스왑과 Lendf.me 해킹 사건에 대한 내용을 분석하는 과정을 거쳤고, 각각 525개와 46개의 트랜잭션으로부터 재진입 공격을 받았음을 탐지하였다고 한다. Lendf.me에 대해서는 19개의 트랜잭션을 통해 훔친 imBTC 토큰을 이용해서 다른 토큰들을 빌리는 행위를 감지하였다.
Conclusion
Horus 저자는 지난 수 년간 이더리움 스마트 컨트랙트 취약점 탐지에 대한 툴이 계속해서 제안돼왔지만 스마트 컨트랙트 보안에 대한 문제는 여전히 제기되고 있다고 주장하고 있다. 그래서 위와 같은 세 단계의 과정을 통해 컨트랙트 및 트랜잭션 분석을 진행하고, 스마트 컨트랙트에 대한 공격/취약성 탐지 및 공격자의 행동을 추적할 수 있는 방법을 제안하며 취약점과 공격 문제를 정확히 발견하고 처리하여 문제 발생의 감소를 희망하고 있다.
최근 스마트 컨트랙트 취약점 분석에 대해 관심이 생겨 해당 논문을 읽어보게 되었는데, 필자 또한 그렇고 아직 사용해 본 사람이 있는지는 모르겠지만 Github에 관련 코드를 공유하고 있으니 혹시라도 궁금한 일이 생긴다면(?) 들여다보는 것도 좋을 것 같다! 끝.
References
[1] Christof Ferreira Torres, et al. “The Eye of Horus: Spotting and Analyzing Attacks on Ethereum Smart Contracts”, arXiv:2101.06204 (2021) | https://arxiv.org/abs/2101.06204
[2] Meaning of ‘Longitudinal Study’ | https://welfare24.net:56715/ab-welfare_dic_v-2731
[3] Diagram of EVM | https://ethereum.org/en/developers/docs/evm/
[4] Meaning of ‘Remote Procedure Call’ | https://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C
[5] Parity Wallet Hacks | http://wiki.hash.kr/index.php/%ED%8C%A8%EB%A6%AC%ED%8B%B0_%EC%A7%80%EA%B0%91
[6] Function ‘initWallet’ | https://medium.com/haechi-audit-kr/parity-multisig-wallet-%EB%8F%99%EA%B2%B0%EA%B3%BC-eip999-4dc303cd8e27
[7] Label Word Cloud | https://etherscan.io/labelcloud
[8] Ethereum ETL | https://ethereum-etl.readthedocs.io/en/latest/
[9] Meaning of ‘Hop’ | https://ko.wikipedia.org/wiki/%ED%99%89_(%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)
[10] Precision and Recall | https://ko.wikipedia.org/wiki/%EC%A0%95%EB%B0%80%EB%8F%84%EC%99%80_%EC%9E%AC%ED%98%84%EC%9C%A8
