2023년의 상당 기간은 DeFi 프로토콜에게 약세장이었음에도 불구하고, 프로토콜 취약점으로 인한 심각한 해킹 피해는 계속되고 있습니다. 특히 Euler Finance 해킹에서 약 2억 달러에 달하는 막대한 손실이 발생했습니다. 한편, 컴파일러로 인한 취약점이나 널리 사용되는 표준 간의 비호환성과 같은 새로운 유형의 DeFi 보안 사고가 등장했습니다. 이러한 위협에 대응하기 위해 커뮤니티는 모니터링 및 위협 인텔리전스를 포함한 다양한 해결책을 제안했습니다. 일부 조치는 효과적인 것으로 입증되었지만, 이러한 노력들은 임기응변식에 불과하다고 생각합니다. 커뮤니티에는 여전히 DeFi 프로토콜을 보호하는 데 도움이 되는 체계적인 접근 방식과 지침이 부족합니다.
이 블로그에서는 먼저 대표적인 사례를 통해 DeFi 프로토콜 보안의 새로운 트렌드를 소개하고, 현재의 해결책과 그 한계를 설명합니다. 마지막으로 DeFi 프로토콜 보안을 강화하는 방법에 대한 BlockSec의 관점을 제안합니다.
0x0. DeFi 프로토콜 보안의 새로운 트렌드
트렌드-I: 신뢰받는 프로토콜들이 공격받다
2023년에는 Curve, Balancer, KyberSwap 등 잘 확립되고 신뢰받는 프로토콜들이 침해를 당했습니다. 아래 표는 이러한 신뢰받는 프로토콜들의 출시 날짜와 공격받은 시점을 보여줍니다. 악용된 취약점은 프로토콜 초기 출시 이후 업데이트 과정에서 도입되었을 수 있다는 점을 유의해야 합니다. 따라서 표에 제시된 기간은 대략적인 수치이며, 관련된 기간에 대한 전반적인 개념을 제공하기 위한 것입니다.
위의 사례들 외에도, Aave V2는 11월에 커뮤니티로부터 취약점 보고를 받은 후 긴급 일시 중단되었습니다. 프로토콜이 실제로 공격받지는 않았지만, 신뢰받는 프로토콜에 대한 보안 우려를 불러일으켰습니다.
이러한 프로토콜들은 여러 차례의 감사를 거쳤으며, 내부적으로도 다양한 보안 조치가 구현되어 있습니다. 아래 표는 각 프로토콜의 감사 기관을 나열합니다. 감사 기관은 프로토콜 내 일부 스마트 컨트랙트에 대해서만 감사를 수행했을 수 있다는 점을 유의해야 합니다. 표에 언급된 감사 기관이 반드시 취약한 스마트 컨트랙트를 감사한 기관과 일치하지 않을 수 있습니다. 이 표의 목적은 해당 프로토콜들이 보안에 상당한 자원을 투자했음을 보여주기 위한 것입니다.
| 프로토콜 | 감사 기관 | 링크 |
|---|---|---|
| kyberSwap | ChainSecurity, Sherlock, Hacken | 감사 - KyberSwap 문서 |
| Curve | TrailOfBits, MixBytes, Quantstamp, ChainSecurity | 감사 - Curve 문서 |
| Balancer | OpenZeppelin, TrailOfBits, Certora, ABDK | 보안 | Balancer |
다행히도 피해자들은 각 프로토콜이 시행한 계획을 통해 손실을 보상받았습니다. 예를 들어, Kyber Network는 KyberSwap 재무를 통해 피해 사용자들에게 보상할 계획을 발표했습니다. 마찬가지로, Curve 커뮤니티는 LP들의 금전적 손실을 보전하기 위한 제안에 찬성 투표를 했습니다. 이러한 조치들은 상당한 비용이 수반되지만, DeFi 커뮤니티의 신뢰를 회복하기 위한 발걸음입니다.
트렌드-II: 새로운 유형의 공격 벡터가 등장하다
컴파일러 버그와 호환되지 않는 서드파티 라이브러리와 관련된 공격 벡터가 DeFi 분야에서 실제로 등장했습니다. 예를 들어, Curve 보안 사고의 근본적인 원인은 특정 버전의 Vyper 컴파일러 내부 버그로 확인되었습니다. 또한 일부 프로토콜은 thirdweb과 같은 인기 있는 서드파티 개발 라이브러리에 구현될 때, 널리 채택된 두 표준인 ERC2771과 Multicall의 비호환성으로 인한 공격을 받았습니다. 이러한 복잡한 기술적 과제는 새롭고 예측하지 못한 취약점으로부터 보호하기 위해 철저한 보안 관행과 지속적인 보안 조치의 발전이 얼마나 중요한지를 강조합니다.
컴파일러 버그
1983년, Ken Thompson은 튜링상 수상 강연에서 "신뢰를 신뢰하는 것에 대한 성찰"이라는 제목의 연설을 했습니다. 이 연설에서 그는 C 컴파일러를 수정하여 프로그램에 백도어를 삽입하는 방법을 설명했으며, 이는 예상치 못한 결과를 초래할 수 있습니다. 연설에서 전달된 아이디어는 커뮤니티에서 큰 호응을 얻었습니다. 그러나 실제로 악의적인 컴파일러 사례는 드뭅니다(잘 알려진 XcodeGhost 보안 사고를 제외하고). 악의적인 컴파일러에서 악의적이지는 않지만 예상치 못한 컴파일러 동작으로 보안 모델을 완화하더라도, 심각한 금전적 손실을 일으킨 공개적인 사례는 여전히 드뭅니다.
Vyper 컴파일러 버그로 인한 Curve 보안 사고는 약 7천만 달러의 손실을 초래한 공개적으로 알려진 사례입니다(일부는 반환되었으며 실제 손실은 약 2,300만 달러). Vyper 컴파일러 버전 0.2.15, 0.2.16, 0.3.0에는 재진입 방지 기능을 무효화하는 버그가 있습니다. 이는 컴파일러가 올바른 바이트코드를 생성했다면 발생하지 않았을 재진입 공격을 공격자가 활용할 수 있음을 의미합니다 — 개발자가 재진입을 방지하는 코드를 추가했음에도 불구하고.
공격 Tx: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c
공통 표준의 비호환성
DeFi 컴포저빌리티는 서로 다른 스마트 컨트랙트와 표준을 연결하여 강력한 애플리케이션을 만들 수 있게 합니다. 그러나 이는 잠재적인 호환성 문제를 야기할 수 있습니다. 예를 들어, 각 스마트 컨트랙트가 개별적으로는 원활하게 작동하더라도 인기 있는 표준들을 결합하면 새로운 보안 취약점이 발생할 수 있습니다.
이러한 비호환성 문제의 한 예로 ERC-2771과 Multicall 표준이 있습니다. ERC-2771은 신뢰할 수 있는 포워더를 통해 메타 트랜잭션을 수신하기 위한 인터페이스를 정의하고, Multicall은 단일 트랜잭션 내에서 여러 함수 호출을 일괄 처리하는 메커니즘입니다. 문제는 신뢰할 수 있는 포워더로부터 전달된 호출이 calldata에서 실제 호출 주소를 가져올 때 발생하며, 이는 공격자에 의해 조작될 수 있습니다. 각 표준은 단독으로는 완벽하게 작동하지만, 함께 사용하면 특정 가정을 깨뜨리고 예상치 못한 문제를 초래할 수 있습니다. 자세한 내용은 OpenZeppelin의 블로그 포스트를 참조하세요.
ERC-2771과 Multicall 표준은 모두 OpenZeppelin 및 thirdweb과 같은 인기 있는 개발 라이브러리에 구현되어 있습니다. 개발자들은 종종 이러한 잘 알려진 코드베이스를 신뢰하고 코드 감사에서 제외할 수 있습니다. 이러한 관행은 프로토콜 자체에 취약점이 없더라도 새로운 보안 허점을 도입할 수 있습니다.
트렌드-III: 기존 취약점이 새로운 보안 위협을 가져오다
정밀도 손실은 계산 과정에서 정밀도와 정확도가 감소하는 현상으로, 일반적으로 결과값이 예상보다 소수점 이하 자릿수가 적을 때 발생합니다. 정적 분석기는 정밀도 손실 문제를 쉽게 감지할 수 있지만, 그 존재 자체가 반드시 보안 취약점을 의미하지는 않습니다. 정밀도 손실이 심각한 결과를 초래할 수 있을 때만 취약점으로 간주됩니다. 그러나 정밀도 손실의 영향을 평가하는 것은 종종 어려우며, 프로토콜의 의미론과 코드의 특정 맥락에 대한 깊은 이해가 필요합니다.
Compound v2 및 Aave v2와 같은 주요 프로토콜을 포크한 프로토콜들을 대상으로 한 여러 공격이 있었으며, 이들은 알려진 정밀도 문제에 취약할 수 있습니다. 구체적으로, Compound v2의 포크인 Hundred Finance와 Channels Finance 사고는 부적절하게 초기화된 마켓과 정밀도 손실 문제에서 비롯되었습니다. 이러한 문제로 인해 공격자들은 반올림 오류로 인해 적은 수의 토큰으로 담보를 상환할 수 있었습니다.
공격 Tx: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d
0x1. 현재의 해결책
신뢰받는 DeFi 프로토콜들이 보안 조치에 상당한 투자를 하고 여러 차례의 보안 감사를 받은 것은 사실입니다. 그럼에도 불구하고, 이러한 프로토콜들이 관리하는 방대한 사용자 자산을 고려할 때, 프로토콜 보안의 중요성을 강조하는 것은 완전히 정당합니다. 코드 감사 외에도 위협 모니터링과 같은 추가적인 해결책이 제안되고 있습니다. 이러한 해결책의 현재 상태와 한계를 살펴보겠습니다.
코드 감사
여기서 정의하는 코드 감사는 DeFi 프로토콜의 보안 평가에서 매우 중요한 프로세스로, 일반적으로 프로토콜이 출시되기 전에 수행됩니다. 수동 코드 검토, 정적 분석, 동적 퍼즈 테스팅, 형식 검증 등 다양한 기술을 포함합니다. 또한 이 프로세스는 하나(또는 소수)의 감사 회사에서 수행하거나 커뮤니티 주도 방식으로 진행할 수 있습니다. 그러나 코드 감사에는 반드시 인정해야 할 한계가 있습니다.
-
첫째, 코드 감사는 주로 프로토콜이 배포되기 전에 이루어집니다. 프로토콜이 출시된 후에는 감사 프로세스가 일반적으로 종료되며, 초기 코드 감사로는 지속적인 보안을 평가할 수 없습니다. 이는 출시 후 발생하는 취약점이나 문제가 초기 코드 감사에서 감지되지 않을 수 있음을 의미합니다.
-
둘째, 코드 감사는 복잡한 상호작용과 특정 상태가 필요한 미묘한 취약점을 식별하는 데 어려움을 겪는 경우가 많습니다. DeFi 프로토콜의 컴포저빌리티는 유연성과 통합을 촉진하는 기능이지만, 프로그램 공간을 크게 확장하여 인간 검토자와 정적 분석기에게 심각한 과제를 제시합니다. 이들은 전체 프로그램 상태를 탐색하는 데 어려움을 겪습니다. 동적 퍼즈 테스팅이 도움이 될 수 있지만, 트랜잭션 및 상태 의존성에 의해 제한됩니다. 실패를 감지할 수 있는 DeFi 프로토콜 인식 퍼징 오라클의 부재는 업계와 학계 모두에서 미해결 연구 과제로 남아 있는 중요한 공백입니다.
-
셋째, 자격을 갖춘 코드 감사자의 부족은 제한된 인재 풀로 인해 빠르게 해결될 수 없습니다. 코드 감사는 사이버 보안, 금융, 수학에 대한 지식이 필요한 학제간 작업입니다. 현재 이 전문 분야의 교육을 제공하는 대학은 소수에 불과하여, 고품질 코드 감사의 높은 비용과 긴 대기 시간이 발생합니다. 결과적으로 프로토콜은 비즈니스 일정을 맞추기 위해 코드 감사 없이 출시될 수 있습니다.
-
넷째, 사용자가 코드 감사의 품질을 평가하기 어렵습니다. 사용자들은 프로토콜에 자산을 예치하기 때문에 프로토콜 보안에 가장 큰 이해관계를 가지고 있지만, 대부분은 코드 감사의 철저함을 평가할 능력이 없습니다. 이는 단순히 외관상의 목적으로만 수행되는 감사로 이어질 수 있으며, 궁극적으로 프로토콜과 사용자 자산의 보안을 저해할 수 있습니다.
결론적으로, 코드 감사는 프로토콜 보안에 있어 귀중한 도구이지만, 내재적인 한계로 인해 유일한 보안 솔루션이 될 수 없습니다.
위협 모니터링
위협 모니터링의 기본 아이디어는 의심스러운 활동을 모니터링하고 감지하는 것입니다. 이는 보안을 향상시키지만, 효과적이기 위해서는 다음과 같은 우려 사항을 해결해야 합니다.
-
첫째, 위협 모니터링 시스템의 정확도가 중요합니다. 거짓 양성과 거짓 음성을 모두 최소화하는 균형을 맞춰야 합니다. 높은 거짓 양성률은 거짓 경보를 유발하여 사용자나 보안팀이 경고에 둔감해져 실제 위협을 간과할 수 있습니다.
-
둘째, 현재 위협 모니터링 시스템은 의심스러운 트랜잭션을 감지한 후 조치를 취하기 위해 수동 확인이 필요한 경우가 많습니다. 이는 앞서 언급한 높은 거짓 양성률 문제 때문입니다. 수동 개입의 반응적 특성은 블록체인과 DeFi 프로토콜의 빠른 환경에서 공격이 수동 대응이 이루어지기 전에 자원을 빠르게 고갈시킬 수 있기 때문에 문제가 됩니다. 따라서 위협 모니터링 시스템이 공격을 예방하거나 완화하기 위한 적시의 자동 조치를 제공할 수 없다면 그 가치는 크게 감소합니다.
-
또한, 위협 모니터링은 지속적이어야 하며 새로운 위협이 등장함에 따라 적응할 수 있어야 합니다.
0x2. BlockSec의 관점
우리는 프로토콜 보안이 프로토콜의 생명주기에서 여러 단계에 걸친 다층적 방어가 필요하다고 생각합니다. 여기에는 고품질 코드 감사, 출시 전 보안 테스팅, 공격 탐지 및 차단, 출시 후 보안 사고 대응이 포함됩니다. 또한 커뮤니티에서 간과되어 온 몇 가지 관점을 강조하고자 합니다.
-
첫째, 작은 코드나 구성 업그레이드에도 철저한 보안 테스팅이 필요하다고 생각합니다. 이러한 테스팅은 허구의 사용자 데이터 상태가 아닌 프로토콜의 실제 상태에서 수행되어야 합니다. 앞서 논의한 바와 같이, 복잡한 프로토콜의 취약점을 찾는 데 프로토콜 상태가 매우 중요합니다.
-
둘째, 수동 개입이 아닌 공격에 대한 자동화된 대응 시스템이 필요합니다. 이를 위해서는 매우 낮은 거짓 양성률과 거의 0에 가까운 거짓 음성률을 가진 정확하고 신속한 공격 탐지 시스템이 필요합니다. 예를 들어, 자동화된 대응이 배포된다면 수백만 달러 규모의 사용자 자산을 보호할 수 있습니다.
-
셋째, 적절한 보안 사고 대응 절차를 수립하고 포괄적인 보안 서비스를 제공할 수 있는 보안 파트너가 필요합니다. 예를 들어, 익스플로잇이 발생했을 때 파트너는 워룸 구성 과정을 지원하고, 취해야 할 조치를 권고하며, 보안 패치 검토 및 감사를 돕고, 자금 흐름을 추적하는 등의 역할을 할 수 있습니다. yearn finance 문서는 익스플로잇 처리 방법에 대한 좋은 자료입니다.
BlockSec이 제공하는 풀스택 보안 서비스
위의 인사이트를 바탕으로, BlockSec은 프로토콜에 풀스택 보안 서비스를 제공합니다.
- 고품질 코드 감사 서비스. BlockSec은 DeFi 프로토콜에 철저한 코드 감사 서비스를 제공합니다. 창의적인 학술 연구를 기반으로 한 정적 분석 도구, 동적 퍼징, 차등 테스팅 프레임워크를 활용하여 프로토콜과 기반 EVM 실행 엔진 모두를 아우르는 코드 감사를 수행합니다. 또한 정적 분석 도구 HookScan은 Uniswap V4 훅의 취약점을 감지하기 위해 Uniswap Lab의 지원을 받았습니다.
- Phalcon: 공격 탐지 및 차단 시스템. 20건 이상의 공격을 차단하고 약 1,400만 달러를 구출한 검증된 기술로, BlockSec Phalcon은 프로토콜이 공격 컨트랙트와 트랜잭션을 능동적으로 모니터링할 수 있도록 지원합니다(해커가 공격 트랜잭션을 실행하기 전에도). 99.99%에 가까운 정밀한 공격 탐지 엔진과 사용자 맞춤형 정책으로 거짓 양성과 거짓 음성의 균형을 맞추며 자동화된 방어 메커니즘을 구현합니다.
- 보안 사고 대응. BlockSec은 DeFi 해킹에서 공격의 근본 원인과 취약점을 가장 빠르게(혹은 최초로) 파악하는 보안 업체입니다. 프로토콜의 보안 패치 검토(Telcoin), 화이트햇 자금 구출 [예: AnySwap, TransitSwap, Paraspace, Loot], 해킹 자금 흐름 추적, Hopeland 공격자 신원 파악 등을 지원합니다.
0x3. 결론
2023년에는 DeFi 프로토콜 보안에 새로운 트렌드가 나타났으며, 많은 신뢰받는 프로토콜들이 공격을 받았습니다. 기술적으로 프로토콜 보안을 보장하는 것은 복잡하고 지속적인 과제임을 알고 있습니다. 단순히 코드 감사나 모니터링 시스템을 도입하는 것만으로는 더 이상 충분하지 않습니다. 이러한 요소들을 결합하고 프로토콜의 전체 생명주기에 걸쳐 작동하는 풀스택 솔루션이 필요합니다.
결론적으로, 최첨단 감사 기술, 자동화된 공격 방어 도구, 신속한 사고 관리를 결합한 BlockSec의 총체적인 DeFi 프로토콜 보안 접근 방식은 2024년 DeFi 분야에서 진화하는 위협에 맞서 보안 조치를 강화하고 사용자 자산을 보호하고자 하는 프로토콜의 선도적인 파트너로 자리매김합니다.
