@CetusProtocol의 해커 공격 보안 "리플레이" 보고서를 읽어보면 "흥미로운" 현상을 발견하실 수 있습니다. 기술적 세부 사항은 매우 투명하게 공개되어 있고, 비상 대응 방식도 교과서적인 수준이지만, 가장 중요한 반성적 질문인 "왜 해킹당했을까?"에 대해서는 회피적인 태도를 보입니다.
이 보고서는 `integer-mate` 라이브러리의 `checked_shlw` 함수의 검사 오류(≤2^192이어야 하지만 실제로는 ≤2^256)를 설명하는 데 많은 공간을 할애했으며, 이를 "의미적 오해"로 규정했습니다. 이런 서술은 기술적으로는 타당하지만, 마치 세터스 역시 이 기술적 결함의 무고한 희생자인 것처럼 교묘하게 외부 책임에 초점을 맞추고 있습니다.
질문은, `integer-mate`가 오픈 소스이자 널리 사용되는 수학 라이브러리인데, 왜 단 하나의 토큰으로 엄청난 유동성 공유를 얻을 수 있는 그런 터무니없는 실수를 저질렀는가입니다.
해커의 공격 경로를 분석하면, 해커가 완벽한 공격을 달성하기 위해서는 잘못된 오버플로 검사, 큰 이동 계산, 반올림 규칙, 경제적 합리성 검증 부족이라는 네 가지 조건을 동시에 충족해야 한다는 것을 알 수 있습니다.
Cetus는 모든 "트리거" 조건에서 "부주의"했습니다. 예를 들어, 사용자로부터 2^200과 같은 천문학적 숫자를 입력받고, 매우 위험한 대규모 변위 작업을 사용하고, 외부 라이브러리의 검사 메커니즘을 완전히 신뢰했습니다. 가장 치명적인 것은 시스템이 "하늘 높은 가격 주식에 토큰 1개"라는 터무니없는 결과를 계산했을 때, 어떠한 경제적 상식적 검토도 없이 바로 실행했다는 것입니다.
따라서 세투스가 실제로 반성해야 할 점은 다음과 같습니다.
1) 적절한 보안 테스트 없이 일반적인 외부 라이브러리를 사용하는 이유는 무엇입니까? `integer-mate` 라이브러리는 오픈 소스이고 인기가 많으며 널리 사용되고 있지만, Cetus는 이 라이브러리의 보안 경계를 완전히 이해하지 못한 채, 라이브러리에 장애가 발생할 경우 적합한 대체 솔루션이 있는지 등을 알지 못한 채 수억 달러 규모의 자산을 관리하는 데 이를 사용합니다. 분명히 Cetus는 공급망 보안 보호에 대한 가장 기본적인 인식이 부족합니다.
2) 천문학적 숫자를 경계를 설정하지 않고 입력하는 것이 허용되는 이유는 무엇입니까? DeFi 프로토콜은 분산화를 추구해야 하지만, 성숙한 금융 시스템이 더 개방적일수록 더 명확한 경계가 필요합니다.
공격자가 신중하게 구성한 천문학적 숫자의 입력을 시스템이 허용할 때, 해당 팀은 그러한 유동성 수요가 합리적인지 여부를 생각하지 못한 게 분명합니다. 세계 최대 규모의 헤지펀드조차도 그렇게 과장된 유동성 점유율을 필요로 하지 않을 것입니다. 분명히, Cetus 팀은 재정적 직관력을 갖춘 위험 관리 인재가 부족합니다.
3) 여러 차례의 보안 감사에도 불구하고 왜 문제를 미리 발견하지 못했을까요? 이 문장은 무심코 치명적인 인지적 오해를 드러냅니다. 프로젝트 당사자는 보안 책임을 보안 회사에 아웃소싱하고 감사를 책임 면제에 대한 황금 티켓으로 간주합니다. 하지만 현실은 잔인합니다. 보안 감사 엔지니어는 코드 버그를 찾는 데 능숙합니다. 환상적인 환율을 계산하는 시스템을 테스트할 때 뭔가 문제가 있을 거라고 누가 생각했을까요?
수학, 암호학, 경제학 전반에 걸친 이러한 경계 검증은 현대 DeFi 보안의 가장 큰 맹점입니다. 감사 회사는 "이것은 코드 논리 문제가 아니라 경제 모델의 설계 결함입니다"라고 말할 것입니다. 프로젝트 당사자는 "감사에서 아무런 문제도 발견되지 않았다"고 불평할 것이다. 그리고 사용자들은 자신의 돈이 사라졌다는 사실만 알고 있습니다!
결국 이는 DeFi 산업의 체계적인 보안 취약점을 드러냅니다. 순전히 기술적 배경을 가진 팀은 기본적인 "재정적 위험 감각"이 심각하게 부족합니다.
Cetus 보고서를 보면, 그 팀은 분명히 충분히 반성하지 못한 것 같습니다.
이번 해커 공격의 기술적 결함에만 집중하기보다는, Cetus를 시작으로 모든 DeFi팀이 순전히 기술적 사고의 한계를 바꾸고, "재무 엔지니어"의 보안 위험 인식을 진정으로 함양해야 한다고 생각합니다.
예를 들어: 기술 팀의 지식 사각지대를 메우기 위해 재무 위험 관리 전문가를 소개합니다. 코드 감사뿐만 아니라 필요한 경제 모델 감사도 살펴보는 다자간 감사 및 검토 메커니즘을 구현합니다. "재정적 감각"을 키우고, 다양한 공격 시나리오와 그에 따른 대응책을 시뮬레이션하고, 비정상적인 운영에 항상 민감하게 대처하는 것 등이 필요합니다.
이는 제가 이전에 보안 회사에서 일했던 경험을 떠올리게 합니다. 당시 업계 보안 리더인 @evilcos, @chiachih_wu, @yajinzhou, @mikelee205도 같은 의견을 공유했습니다.
업계가 성숙해짐에 따라 코드 수준의 기술적 버그는 점점 덜 흔해질 것이고, 경계가 불분명하고 책임이 모호한 비즈니스 로직 "인식 버그"가 가장 큰 과제가 될 것입니다.
감사 회사는 코드에 버그가 없는지만 보장할 수 있을 뿐, "논리적 경계"를 달성하려면 프로젝트 팀이 비즈니스의 특성을 더 깊이 이해하고 경계를 제어할 수 있는 능력이 필요합니다. (이전에 보안 감사 후에도 해커가 계속해서 공격하는 '비난 전가 사건'의 근본 원인은 여기에 있습니다)
DeFi의 미래는 강력한 코딩 기술과 비즈니스 로직에 대한 깊은 이해를 갖춘 팀에 달려 있습니다!
