Cetus 보안 문제에서 얻는 교훈: DeFi 팀이 주의해야 할 점은?
글: Haotian
@CetusProtocol의 해킹 보안 '복기' 보고서를 읽고 나면, 한 가지 '흥미로운' 현상을 발견하게 될 것이다. 기술적 세부사항은 상당히 투명하게 공개되었고, 비상 대응도 교과서 수준이라 할 만하지만, 가장 중요한 '왜 해킹당했는가'라는 핵심 질문에 대해서는 회피하는 듯한 인상을 준다.
보고서는 `integer-mate` 라이브러리의 `checked_shlw` 함수 검사 오류(실제로는 ≤2^256이지만 ≤2^192여야 함)를 설명하며 이를 '의미상 오해'라고 정의한다. 이러한 설명은 기술적으로 성립할 수 있지만, 책임을 외부로 돌리는 방향으로 논점을 정교하게 유도하고 있으며, 마치 Cetus 또한 이 기술적 결함의 무고한 피해자인 것처럼 보이게 한다.
문제는, `integer-mate`가 오픈소스이며 널리 사용되는 수학 라이브러리임에도 불구하고, 왜 하필 Cetus에서 '1개의 토큰으로 천문학적인 유동성 지분을 얻는' 어이없는 오류가 발생했는가 하는 점이다.
해커의 공격 경로를 분석하면, 해커가 완벽한 공격을 수행하려면 네 가지 조건을 동시에 충족해야 한다는 것을 알 수 있다. 잘못된 오버플로우 검사, 극단적인 시프트 연산, 올림 규칙, 경제적 타당성 검증 부재.
Cetus는 바로 이 모든 '트리거' 조건에서 '부주의하게' 일관되게 실수했다. 예를 들어, 사용자가 2^200과 같은 천문학적인 숫자 입력을 허용하고, 매우 위험한 큰 폭의 시프트 연산을 채택하며, 외부 라이브러리의 검사 메커니즘을 무조건 신뢰하는 것뿐 아니라, 가장 치명적인 것은 시스템이 '1개의 토큰으로 천문학적인 지분을 교환'하는 어이없는 결과를 계산했을 때, 전혀 경제 상식에 기반한 검사를 거치지 않고 그대로 실행했다는 점이다.
따라서 Cetus가 진정으로 반성해야 할 핵심은 다음과 같다.
1) 왜 일반적인 외부 라이브러리를 사용하면서 제대로 된 보안 테스트를 하지 않았는가? `integer-mate` 라이브러리가 오픈소스이고 인기가 많으며 널리 사용된다는 점을 감안하더라도, Cetus는 수억 달러의 자산을 관리하는 데 있어 이 라이브러리의 보안 경계를 충분히 이해하지 못했으며, 라이브러리 기능이 실패했을 경우를 대비한 적절한 대체 방안이 있는지도 고려하지 않았다. 명백히 Cetus는 가장 기본적인 공급망 보안 방어 의식이 부족했다.
2) 왜 천문학적인 숫자 입력을 허용하면서도 경계를 설정하지 않았는가? DeFi 프로토콜이 탈중앙화를 추구해야 한다고는 하나, 성숙한 금융 시스템일수록 개방적이면서도 명확한 경계가 필요하다.
시스템이 공격자가 의도적으로 구성한 천문학적인 숫자 입력을 허용할 때, 팀은 과연 그러한 유동성 수요가 합리적인지를 생각해본 적이 있었는가? 전 세계 최대 헤지펀드라 하더라도, 이렇게 과도한 유동성 지분이 필요할 리 없다. 명백히 Cetus 팀에는 금융적 직관을 갖춘 리스크 관리 인력이 부족했다.
3) 여러 차례의 보안 감사를 받았음에도 불구하고 왜 미리 문제를 발견하지 못했는가? 이 말은 무의식 중에 치명적인 인식 오류를 드러내는데, 프로젝트팀이 보안 책임을 보안 업체에 외주로 맡기며 감사를 면책 통행증처럼 여겼다는 점이다. 그러나 현실은 가혹하다. 보안 감사 엔지니어는 코드 버그를 찾는 데 능숙하지만, 누가 시스템이 터무니없는 교환 비율을 계산할 때 문제가 생길 수 있다는 것을 사전에 테스트하겠는가?
수학, 암호학, 경제학의 경계를 넘나드는 이러한 검증은 바로 현대 DeFi 보안의 가장 큰 사각지대다. 감사 업체는 '이건 경제 모델 설계상의 결함이지 코드 로직의 문제는 아니다'라고 말할 것이고, 프로젝트팀은 '감사에서 문제를 발견하지 못했다'고 불평할 것이며, 사용자는 단지 자신의 돈이 사라졌다는 것만 알게 될 것이다!
보시다시피, 이것이 근본적으로 드러내는 것은 DeFi 산업의 구조적 보안 취약점이다. 순수 기술 배경의 팀들이 기본적인 '금융 리스크 감각'을 심각하게 결여하고 있다는 점이다.
Cetus의 이번 보고서를 보면, 팀이 아직 충분히 반성하지 못했다는 것이 분명하다.
이번 해킹 사건의 기술적 결함 자체보다 더 중요한 것은, Cetus를 시작으로 모든 DeFi 팀들이 순수 기술 중심 사고의 한계를 벗어나 진정한 '금융 엔지니어'로서의 보안 리스크 인식을 기르기 시작해야 한다는 점이다.
예를 들어, 금융 리스크 관리 전문가를 도입하여 기술 팀의 지식 격차를 메우고, 다중 감사 및 검토 메커니즘을 마련하여 코드 감사뿐 아니라 필수적인 경제 모델 감사도 반드시 수행하며, '금융적 감각'을 키워 다양한 공격 시나리오를 시뮬레이션하고 대응 방안을 마련하며 이상 조작에 항상 민감하게 반응하는 태도를 기르는 등의 노력이 필요하다.
이러한 점은 내가 이전에 보안 업계에서 경험했던 바이며, @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 등 업계의 보안 전문가들과의 대화에서도 공감대를 형성했던 부분이다.
산업이 점점 성숙해짐에 따라 코드 수준의 기술적 버그는 점차 줄어들겠지만, 경계가 불분명하고 책임이 모호한 비즈니스 로직의 '의식 버그'가 가장 큰 도전 과제가 될 것이다.
감사 업체는 코드에 버그가 없는 것까지만 보장할 수 있지만, '논리에 경계가 있는' 상태를 만들기 위해서는 프로젝트 팀이 비즈니스 본질에 대한 깊이 있는 이해와 경계 통제 능력을 가져야 한다. (이전 많은 보안 감사 후에도 여전히 해킹을 당한 '책임 전가 사건'의 근본 원인이 바로 여기에 있다.)
DeFi의 미래는 코드 기술이 뛰어나면서 동시에 비즈니스 로직을 깊이 이해하는 팀들에게 속해 있다!
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
Haotian | CryptoInsight
