back

검색

다시 300억원 규모 공격받은 디파이…해결책은 있다?

암호화폐, 디파이, 디포스, 가상화폐

디파이(Defi, 탈중앙화 금융) 플랫폼 디포스에서 약 300억 원 규모의 자금 손실 사태가 4월 19일(한국시간) 일어났다. 이는 디포스 보유 BTC·ETH 자산의 99%에 달하는 수치다. 디파이 취약점을 노린 사건 중 가장 큰 피해규모에 해당된다. 한편 디파이 업계는 지난 2월에도 유동성 취약점을 노린 공격자로부터 약 7억원의 자금을 손실한 바 있다. #유니스왑? imBTC? lendf.me? 이번 탈취 사건은 탈중앙 암호화폐 교환 서비스 유니스왑(Uniswap)의 Imbtc풀 코드 취약점을 이용해 발생했다. 유니스왑은 지난 2월 또 다른 디파이 프로젝트 bZx의 유동성 취약점을 공격할 때도 이용된 서비스다. 당시에는 공격자가 플래시 론(Flash Loan)이라는 초단기 대출을 이용해 유니스왑에서 급등한 wBTC(BTC를 이더리움 체인으로 본뜬 것)를 판매하고, 그 이더리움을 다시 빌려 bZx의 마진 거래소 펄크럼(Fulcrum)에 고의적 레버리지를 거는 방식을 반복하여 시세차익을 얻어냈다. 그와 달리 이번에는 공격자가 유니스왑의 유동성 풀 중 하나인 imBTC의 코드 취약점을 노리는 식으로 자금을 탈취했다. imBTC는 아임토큰 측이 제공하는 일반 유동성 풀이다. 디파이 시스템은 이러한 방식으로 누구든지 유동성 풀을 만들어낼 수 있다. imBTC풀은 많은 유동성 풀 중 하나일 뿐이다. 문제는 디파이 플랫폼 서비스 디포스(dForce)가 운영하는 탈중앙 대출 프로토콜 lendf.me도 2020년들어 imBTC풀을 오픈했다는 점이다. 암호화폐 분석 업체 팩쉴드(Peckshield)에 따르면 유니스왑의 imBTC풀 공격 피해액은 약 2억 7000만원에 불과하다. 큰 피해는 lendf.me 채널에서 왔음을 알 수 있다. 현재까지 lendf.me 서비스가 공격 받음으로써 발생한 피해규모는 약 300억원에 달한다. #bZx 사태와는 조금 다르다…오히려 DAO사태와 유사하다 공격자가 디파이 서비스 취약점을 이용했다는 점에서 이번 사건은 bZx와 같은 측면이 있다. 하지만, 공격방식은 달랐다. bZx 사태가 플래시 론이라는 디파이 특유의 서비스와 낮은 유동성을 노린 ‘제도 취약 공격’이었다면, 이번에는 코드 결함을 통해 리엔트런시(Reentrancy) 공격을 시도한 ‘기술 취약 공격’에 가깝다. 리엔트런시 공격이란 하나의 거래를 요청한 후 그 거래가 끝나기도 전에 다시 새로운 거래를 시도하는 방법을 의미한다. 공격자가 해당 방법을 성공적으로 진행하면 이중 처리가 가능하게 된다. 이렇게 되면 잔고가 10만원일 때 10만원 인출이 끝나기 전에 다시 10만원 인출을 해도 그 거래가 그냥 통과되는 오류가 발생한다. 그리고 이 패턴을 무한으로 반복하면 피해액수는 그만큼 커지게 된다. 옛 이더리움 클래식의 하드포크를 촉발한 2016년 더 다오(THE DAO) 사태도 리엔트런시 공격을 활용한 공격자가 자금을 탈취해 발생한 사건이다. 당시 공격자는 재귀호출 버그(Recursive Call Vulnerability)를 이용한 무한환불 공격으로 약 360만 이더리움(ETH)을 탈취했다. 특정 스마트 콘트랙트의 splitDAO(이더리움 환불 명령 함수)가 재귀호출에 취약하다는 사실을 해커가 파악했기 때문이다. 이를 통해 보상이 갱신되기 전 DAO 토큰을 인출해 이 작업이 무한 반복되도록 설정했다. 이번 디포스 사태도 imBTC의 이더리움의 표준 프로토콜 중 하나인 ERC-777상의 스마트 콘트랙트 코드 취약점을 노려 발생했다. 해당 ERC-777 코드 내에 있는 공급(Supply)함수가 제대로 작동되지 않아 인출(Withdraw) 잔고에 영향을 끼친다는 것을 공격자가 파악하고 리엔트런시 공격을 감행한 것이다. 결과적으로 imBTC의 토큰 결함과 lendf.me의 콘트랙트 결함 문제가 겹치면서 디포스 사태가 터진 것이라고 볼 수 있다. #또 당했다…그러나 이번에도 해결책은 존재한다 bZx 사건이 가시기도 전에 더 큰 액수의 도난을 당했다는 점에서 이번 일은 분명 디파이 업계에 뼈아픈 일이다. 그러나 이에 대한 해결책이 없는 것은 아니다. 이에 대해 그로우파이(GrowFi) 모종우 공동창업자는 “디파이 프로젝트의 취약점 중 하나는 콘트랙트 결함 가능성이다. 이 결함을 해결하기 위해선 프로토콜의 변화가 있을 경우, 수시로 콘트랙트 보안 업체에 코드 오딧(Code Audit, 일종의 결함 검사)를 받아야 한다”며 검증 작업을 철저히 하면 문제 발생 가능성을 크게 낮출 수 있다고 내다봤다. 또한 그는 “문제가 발생한 부분의 lendf.me 콘트랙트를 보면 시작 및 정지 기능이 없는 것을 확인할 수 있다. 디파이 대출 서비스를 설계하는 과정에서 해당 부분에 대한 장치만 마련해도 지금과 같은 돌발 상황을 최소화할 수 있다”고 덧붙였다. 곧, 콘트랙트 설계 과정에서 기본적인 위험성 방지 장치만 추가해도 리스크를 줄일 수 있다는 이야기다. 박상혁 기자 park.sanghyuk@joongang.co.kr

조인디 logo
j o i n
d

Article Title

  • J loading image
  • O loading image
  • I loading image
  • N loading image
  • D loading image

RE:CENT