소개
지난 3년간 DeFi 생태계에서 여러 보안 사고가 발생했습니다. 이러한 위협에 대응하기 위해 커뮤니티에서는 정적 코드 감사, 스마트 컨트랙트 스캐닝 도구, 동적 퍼징 등 코드 중심의 방법을 채택해 왔습니다. 이러한 방법들이 효과를 보이고 있지만, 코드 중심의 접근 방식만으로는 보안 문제를 해결하고 프로젝트 사용자의 자산을 보호하기 어렵다고 생각합니다. 예를 들어, 여러 유명 코드 감사 회사에서 감사를 받은 취약한 컨트랙트의 사례가 다수 존재합니다.
저희는 기존의 코드 중심 접근 방식 외에도, 위협에 대응하기 위한 보다 선제적인 위협 방지 솔루션이 필요하다고 생각합니다. 2021년 말경 내부적으로 이 아이디어를 검토하여 2022년 초에 IronDome이라는 시스템을 개발했습니다. 이후 BlockSec 내부에 시스템을 배포하여 운영해 왔습니다. 2022년에 IronDome은 여러 공격을 성공적으로 차단하고 500만 달러 이상의 사용자 자산을 보호했으며, 2022년 4월 Saddle Finance에 대한 익스플로잇을 방지하고 380만 달러를 구제한 사례도 포함됩니다.
이 블로그에서는 IronDome의 시스템 아키텍처와 성공 사례를 자세히 설명합니다. 또한 시스템의 한계와 위협 방지의 미래 방향에 대한 인사이트도 논의할 것입니다.
고수준 시스템 아키텍처
IronDome의 기본 아이디어는 이더리움의 펜딩 풀을 모니터링하고, 트랜잭션 사전 실행 시스템 Mopsus를 통해 공격 트랜잭션을 탐지하며, 취약한 자산을 안전한 계정으로 이동시키는 구제 트랜잭션을 자동으로 합성하고 FlashBot을 통해 공격 트랜잭션을 프론트런닝하여 공격을 차단하는 것입니다. 아래 그림은 해당 아키텍처를 보여줍니다.
멤풀 모니터링
IronDome은 커스터마이징된 Geth 클라이언트를 통해 메모리 풀의 펜딩 트랜잭션을 모니터링합니다. 핵심은 시스템이 트랜잭션을 신속하게 수신하고 최대한 많은 트랜잭션을 모니터링해야 한다는 점입니다.
공격 탐지
각 펜딩 트랜잭션은 공격 탐지 모듈로 전달됩니다. 이 트랜잭션들은 아직 체인에 올라가지 않은 상태이므로, 트랜잭션 사전 실행 엔진 Mopsus를 활용하여 이를 사전 실행하고, 트랜잭션의 런타임 상태와 결과를 기반으로 공격(악성) 트랜잭션을 탐지합니다.
구제 트랜잭션 합성
공격 트랜잭션이 탐지되면, IronDome은 구제 트랜잭션과 보조 컨트랙트를 자동으로 합성합니다. 구제 트랜잭션은 공격 트랜잭션과 유사한 방식으로 취약한 컨트랙트를 *"익스플로잇"*하지만, 수익을 공격자가 제어하는 계정이 아닌 안전한 계정(멀티시그 계정)으로 전송합니다. 예를 들어, 공격 컨트랙트와 유사한 보조 컨트랙트를 자동으로 배포하되 토큰 전송 주소를 안전한 계정으로 교체할 수 있습니다. 물론 일부 공격 트랜잭션에는 더 복잡한 접근 방식이 필요합니다.
구제 트랜잭션은 공격 트랜잭션보다 먼저 체인에 올라가야 합니다. 현재 시스템에서는 이를 위해 FlashBot을 활용하고 있습니다. 첫째, 다른 사람들이 구제 트랜잭션을 모니터링할 수 없도록 해야 합니다. 둘째, 구제 트랜잭션이 블록의 최상단에 위치할 수 있도록 몇 가지 전략을 사용할 수 있습니다.
대표적인 성공 사례
IronDome은 2022년 초에 배포되었습니다. 시스템은 여러 공격을 성공적으로 탐지하고 차단했습니다. 이 표는 일부 성공 사례를 요약하고 있습니다.
아래 타임라인은 2022년 4월 말 시스템이 Saddle Finance를 위해 380만 달러를 구제한 방법을 보여줍니다. 특히, 시스템은 공격 트랜잭션을 탐지하고 구제 트랜잭션을 자동으로 합성하는 전체 과정을 1초 이내에 완료했습니다. 구제된 모든 자금은 Saddle Finance에 반환되었습니다. 원본 해킹 트랜잭션과 구제 트랜잭션은 아래 링크에서 확인할 수 있습니다.
- 원본 해킹 트랜잭션: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
- 구제 트랜잭션: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3
윤리적 고려사항
저희는 시스템의 보안 윤리를 매우 중요하게 생각합니다. 시스템이 사용자 자산을 구제하기 위해 취약한 컨트랙트를 *"익스플로잇"*하는 방식을 취하지만, 이 행위에는 윤리적 문제가 없다고 생각합니다.
- 첫째, 저희 시스템은 취약한 컨트랙트를 능동적으로 익스플로잇하지 않습니다. 펜딩 공격 트랜잭션이 탐지될 때만 반응하여 유사한 트랜잭션을 자동으로 합성합니다(공격 트랜잭션을 차단하기 위해). 처음부터 공격 트랜잭션을 생성하지는 않습니다.
- 둘째, 피해를 입은 프로토콜과 적극적으로 소통하고 구제된 자금을 반환합니다.
한계점
IronDome이 효과를 보이고 있지만, 시스템에는 여전히 몇 가지 한계가 있습니다. 아래에서 이러한 한계점을 설명하고 선제적 위협 방지의 향후 방향을 논의하겠습니다.
- 첫째, 저희 시스템은 멤풀의 펜딩 트랜잭션을 모니터링합니다. 공격자가 FlashBot과 같은 프라이빗 트랜잭션 서비스를 활용할 경우, 공격 트랜잭션이 멤풀에 올라오지 않아 탐지할 수 없습니다. 이 문제를 해결하기 위해 프라이빗 트랜잭션 서비스 제공자와의 협력을 요청합니다(저희 시스템과 유사한 방식으로 악성 트랜잭션을 탐지하고 차단하기 위해). 또한, 시스템이 펜딩 툴에서 공격 트랜잭션을 차단하지 못하더라도 체인 상에서 공격 트랜잭션을 탐지하고 구제 트랜잭션을 전송하여 추가적인 공격 트랜잭션을 방지할 수 있습니다. 많은 경우 공격 트랜잭션이 두 개 이상 존재한다는 점을 참고하시기 바랍니다.
- 둘째, 보안은 끝없는 군비 경쟁입니다. 공격자들이 구제 트랜잭션 합성의 난이도를 높이는 사례를 발견했습니다. 예를 들어, 공격 트랜잭션을 여러 개로 분할하거나 수익 주소를 난독화할 수 있습니다. 이러한 문제들은 해결 가능하지만, 군비 경쟁은 멈추지 않을 것으로 생각합니다. 저희는 이러한 문제를 해결하기 위한 방안을 연구하고 있습니다.
- 셋째, 구제 트랜잭션을 공격 트랜잭션보다 먼저 체인에 올리는 방법은 여전히 해결해야 할 과제입니다. 일부 입찰 전략으로 구제 트랜잭션이 블록에 포함될 가능성을 높일 수 있지만, 100% 보장은 불가능합니다.
참고 자료 및 추가 읽기
[1] 블록체인 공격을 "차단 가능"하게 만드는 방법 | BlockSec 작성
[2] The Block: 스테이블코인 DEX Saddle Finance, 1,000만 달러 해킹 피해
[3] Lend 익스플로잇 사후 분석 — HomeCoin (mirror.xyz)
[5] FSWAP 트위터: "FSWAP 유동성 공격의 세부 사항" / Twitter
[6] https://forta.org/blog/blocksec-and-forta-work-to-secure-web3-beyond-audits/
[7] https://forta.org/blog/the-future-of-threat-prevention-in-web3/
