대문 보안 수업 03｜Gate & GoPlus: 감사 보고서를 어떻게 읽고 컨트랙트 취약점을 점검할 것인가

보안은 정적인 상태가 아니라 하나의 증명서가 아니다. 올해 해킹당한 프로젝트들 중 상당수는 감사를 받은 곳이었고, 그중 일부는 여러 번 감사를 받았다. 이는 감사에 가치가 없다는 뜻이 아니라, 감사가 답할 수 있는 질문의 범위가 대부분 사람들이 생각하는 것보다 훨씬 좁다는 뜻일 뿐이다.

감사 보고서는 특정 날짜에 특정 팀이 검토한 특정 버전을 기술한 것이다. 그러나 컨트랙트는 업그레이드되고, 권한은 변경되며, 프로젝트가 의존하는 오라클과 크로스체인 브릿지는 바뀌고, 새로운 공격 기법은 매주 등장한다. 보고서가 전달되는 그 순간부터 그것은 만료되기 시작한다. 더 골치 아픈 것은 몇 년 전에 배포되어 당시 감사를 순조롭게 통과한 구형 컨트랙트들이 지금 다시 대량으로 스캔되고 있다는 점이다. 수년간 운영된 컨트랙트의 심층 취약점이 십수 분 만에 발견될 수 있다.

이것은 Gate가 특별 기획한 《대문 보안 수업》의 세 번째 편이다. 우리는 Web3 보안 서비스 제공업체인 GoPlus Security와 Gate 보안팀을 초청해, 보안 서비스 제공업체와 거래 플랫폼이라는 두 가지 관점에서 감사와 취약점 점검에 대해 이야기해 본다. 왜 감사를 받은 프로젝트에서 여전히 사고가 발생하는지, 보고서는 어떻게 읽어야 하는지, 플랫폼은 상장 전후에 각각 어떤 점검을 하는지, 그리고 일반 사용자가 서명 전에 어떻게 스스로 점검할 수 있는지에 대해서다.

게스트 소개

GoPlus 파트너 Adam: Adam은 GoPlus 파트너이자 보안 연구원 책임자다.

GoPlus Security는 Web3와 AI를 위한 최초의 탈중앙화 보안 레이어를 구축하고 있으며, 블록체인과 최첨단 인공지능 보안 솔루션을 활용해 사용자에게 지능적이고 효율적이며 탈중앙화된 보안 제품과 서비스를 제공한다. 2022년 이후 GoPlus는 지수적 성장을 이루어 일일 API 호출량이 3,000만 건에 달하며, 사용자를 위해 약 1,000억 달러에 가까운 잠재적 손실을 예방했다.

Gate 보안팀: Gate 보안 부서는 플랫폼 계정, 거래 및 자산 보안 체계 구축을 담당하며, 동시에 사용자의 비정상 계정 이의 제기와 협조 요청을 장기적으로 처리하고 있다.

Gate는 2013년에 설립되어 업계 최초로 100% 준비금 증명을 도입한 거래 플랫폼이며, 현재 전 세계 6,000만 명 이상의 사용자에게 서비스를 제공하고 있다. 보안은 이 사업이 성립할 수 있는 전제이며, 우리는 《대문 보안 수업》을 통해 이러한 실제 위험 이면의 공통 메커니즘을 명확히 전달하고자 한다.

Q1. 왜 많은 프로젝트가 감사를 통과한 후에도 여전히 해킹당하고 권한 남용이 발생하는가?

GoPlus 파트너 Adam: "일회성 감사"는 "항상 안전"을 의미하지 않는다. 전통적인 컨트랙트 감사 서비스는 현재 네 가지 구조적 실효성을 갖는다:

1) 스냅샷식 점검. 감사는 본질적으로 감사 엔지니어가 특정 시점에 수행하는 반자동 점검으로, 효과는 도구 품질, 개인 역량, 업무 상태에 의존한다. 그러나 컨트랙트 코드는 업그레이드되고, 관리 권한은 변경되며, 파라미터 설정은 조정된다. 일회성 감사 보고서는 전달되는 그 순간부터 "만료"된다.

2) 미래를 예측할 수 없음. 새로운 취약점 유형과 새로운 공격 기법이 끊임없이 등장하며, 과거 감사는 미래의 위험을 포괄할 수 없다.

3) 외부 의존성 통제 불능. 프로젝트는 일반적으로 오라클, 크로스체인 브릿지, 제3자 프로토콜에 의존하며, 이러한 의존 항목의 위험 변화는 전통적 감사 범위에 포함되지 않는다.

4) 구형 컨트랙트의 집중적 폭로. 수년 전에 배포되어 당시 "감사를 받은" 컨트랙트가 자동화 도구에 의해 대량으로 취약점이 다시 발굴되고 있다. 예를 들어 Balancer, Yearn과 같이 정식 출시 후 수년간 발견되지 않은 심층 취약점이 그렇다.

권한 남용의 경우, 그것은 컨트랙트 코드 자체보다 운영 단계에서 더 많이 발생한다. 원인으로는 Owner 권한 과대(임의 발행, 블랙리스트 등재, 거래 일시정지 가능), 관리자 개인키 유출, 멀티시그 관리 부실, 악의적 제안 및 거버넌스 공격 등이 있다. 이들은 모두 운영 단계에서 쉽게 발생하는 보안 문제다. 감사 보고서에 권한 위험이 명시되어 있더라도, 이후 누가 이를 감시할 것인가? 운영이 안전하고 합리적인지는 답할 수 없다.

컨트랙트 감사 후 상장은 보안 작업의 시작일 뿐 종착점이 아니다. 프로젝트에 필요한 것은 컨트랙트 전체 생애주기를 포괄하는 지속적 보안이며, 일회성 감사 보고서가 아니다.

Gate 보안팀: 감사는 코드가 무엇을 할 수 있는지 사용자에게 알려줄 수 있지만, 프로젝트 측이 무엇을 할 계획인지는 알려줄 수 없다.

이것이 우리가 상장 심사를 하면서 가장 깊이 느낀 점이다. 많은 사고의 근원은 프로젝트 측의 의도에 있다. 하나의 컨트랙트는 기술적으로 완전히 규정을 준수할 수 있고, 소유자 권한 설계도 정상 범위 내에 있을 수 있지만, 프로젝트 측은 여전히 특정 시점에 이러한 권한을 사용할 수 있다. 거래 규칙 변경, 블랙리스트 개설, 토큰 추가 발행 등이다. 이러한 행동은 코드 수준에서 모두 합법적이며, 감사 보고서도 취약점으로 표시하지 않는다. 왜냐하면 그것들은 원래 설계의 일부이기 때문이다.

따라서 기술 감사 외에 또 하나의 제약 층이 필요하다. Gate의 방식은 상장 단계에서 엄격한 프로젝트 심사와 검토를 수행하고, 동시에 프로젝트 측과 불악의 선언을 체결하며, 이행 상황을 감독하는 것이다. 이 층이 해결해야 할 것은 바로 감사가 해결할 수 없는 부분이다. 코드에 취약점이 없다고 해서 그 팀이 사용자에게 피해를 주는 선택을 하지 않는다는 뜻은 아니다.

이미 상장된 프로젝트에 대해서는 정기적인 보안 감사를 수행하며, 동시에 온체인 이벤트 모니터링으로 컨트랙트 상태를 추적한다. 사용자도 언제든지 특정 컨트랙트의 현재 위험 항목을 조회할 수 있다.

Q2. 일회성 감사가 항상 안전을 의미하지 않는다면, 프로젝트 측과 업계 전체는 어떻게 조정해야 하는가?

Gate 보안팀: 암호화폐 업계에는 하나의 구조적 특징이 있다. 상당 부분의 비즈니스, 특히 DeFi는 운영 방식이 모듈형 금융에 가깝다. 각종 플랫폼은 공유 컴포넌트로 구축된다. 컨트랙트, 소프트웨어 라이브러리, 지갑, 가격 오라클, 크로스체인 브릿지, 연결 서비스 제공업체, 웹 인터페이스, 그리고 업데이트를 푸시하는 시스템이다.

따라서 자신의 컨트랙트가 안전한지 외에도, 의존하는 모든环节이 여전히 신뢰할 수 있는지 물어야 한다. 업스트림의 특정 컴포넌트에 장애가 발생하면 손실은 체인을 따라 하류로 전파된다. 중대한 공격들을 돌아보면, 문제는 종종 프로토콜 로직보다 더 이른 단계에서 발생한다. 공급업체, 개발 도구, 소프트웨어가 사용자에게 도달하는 방식, 또는 사용자가 이체를 승인하는 프로세스다.

GoPlus 파트너 Adam: 해커가 자동화 도구를 이용해 효율적으로 취약점을 발굴하는 공격 패러다임은 이미 형성되어 빠르게 확산되고 있다. 공격은 "전문가의 수작업 연구"에서 "컨베이어 벨트"로 변했다. 업계의 사고가 여전히 "출시 전에 감사 회사를 찾아 보고서 한 부를 받는 것"에 머물거나, 위험을 발견한 후에야 보안 회사를 찾아 "사후 약방문"을 하는 것이라면, 그것은 활과 화살로 기관총에 맞서는 것과 같다. 똑같이 효율적인 도구로 공격에 맞서는 것만이 유일하게 효과적인 경로다.

업계 차원의 조정 방향은 "일회성 감사" 또는 "문제 발생 후 전문가 찾기"에서 "전 생애주기 지속 보안"으로 업그레이드하는 것이다. GoPlus DeepScan의 "컨트랙트 보안 3종 세트"를 예로 들면, 이것은 실현 가능한 폐쇄 루프다:

출시 전, Token 보안 자가 점검: 몇 분 만에 빠르게 자기 점검 - 허니팟/미끼풀, 악의적 추가 발행(Mint), 블랙리스트, 비정상 거래세, Owner 권한 등 백도어 위험;

출시 시, AI 컨트랙트 감사: 소스 코드, 권한 관리 및 비즈니스 로직을 심층 분석하고, 구문 계층과 비즈니스 로직 계층의 취약점을 스캔하며, 구조화된 감사 보고서 전달;

출시 후, 지속적 보안 모니터링 및 정기 점검: 신규 취약점 정보, 공격 이벤트 및 외부 의존성(오라클, 크로스체인 브릿지, 제3자 프로토콜) 위험을 실시간 추적하고, 프로젝트가 영향을 받았는지 지속적으로 판단하며, 상시 경고. 정기적으로 컨트랙트에 대한 보안 점검과 지속적 감사 수행.

Q3. 최근 2년간 취약점 발굴 방식에 어떤 변화가 있었는가? 동일한 자산을 온체인에 두는 것과 거래소에 두는 것의 보안 모델은 어떻게 다른가?

GoPlus 파트너 Adam: 솔직히 말하면, 단기적으로 현재 공격 측의 취약점 발굴 방식은 더 다양해졌다. 이유는 세 가지다:

1) 자동화 도구가 취약점 발굴 문턱을 크게 낮췄다. 과거 최고급 보안 연구원이 수 주간 해야 했던 작업을 이제 공격 컨베이어 벨트가 몇 분 만에 완료할 수 있다;

2) 온체인에는 "당시 감사를 받은" 구형 컨트랙트가 대량으로 축적되어 있어, 공격자에게는 매장량이 거대한 "금광"이다;

3) 공격은 단방향 현금화로, "하나"의 취약점만 찾으면 충분하다. 반면 방어자는 "모든" 취약점을 지켜야 한다.

해커가 이 돈을 빼가는 데 몇 분이 걸렸고, 방어자가 동일한 취약점을 찾아내는 데도 사실 몇 분이면 충분하다. 차이는 단지 프로젝트 측이 해커보다 먼저 도구를 올바르게 사용했는지 여부에 있다.

더 핵심적인 것은 방어자가 공격자에게 없는 세 가지 구조적 우위를 갖는다는 점이다:

1) 선수 우위: 방어자는 출시 전과 운영 중에 무한히 재검사할 수 있지만, 공격자는 방어자가 재검사를 하지 않았기를赌할 수밖에 없다;

2) 비용 우위: AI 감사는 건당 또는 연간 패키지로 과금되며, 비용이 상시적이고 전면적인 운영이 가능할 정도로 낮다;

3) 지식 복리: 보안 지식 베이스는 매 새로운 공격 이벤트와 함께 지속적으로 진화하며, 방어 시스템은 사용할수록 강해진다.

온체인과 오프체인 두 모드에서 "누가 당신의 자산을 보호하는가"와 "당신이 직면한 위험 유형"은 완전히 다르다.

온체인 자가 보관: 보안 = 개인키 보안 + 컨트랙트 보안. 당신이 유일한 보안 책임자다. 개인키 분실/도난 시 "고객센터"에 이의 제기할 곳이 없다. 모든 상호작용은 온체인 위험(승인 취약점, 피싱 서명, 미끼풀)을 수반한다. 장점은 자산이 어떤 플랫폼 신용에도 의존하지 않는다는 것이다.

거래소 보관: 보안 = 플랫폼 보안 + 계정 보안. 개인키는 플랫폼이 관리하며(콜드/핫월렛 분리, 멀티시그, 리스크 관리), 이는 "기술적 보안"을 거래소에 아웃소싱하는 것과 같다. 그러나 거래소 계정 보안(비밀번호, 2FA, 피싱, API Key 등)도 잘 보호해야 하며, 동시에 플랫폼 신용이 보장된 거래소를 선택하는 데 반드시 주의해야 한다.

종합하면, 온체인은 "개인키 보호 + 자기 운영 위험", 거래소는 "플랫폼 신용 + 보안 인프라 위험"이다. 전자는 당신의 Web3 보안 의식을 시험하고, 후자는 거래소 플랫폼 인프라와 당신의 계정 보안 습관을 시험한다.

Q4. 거래 플랫폼으로서 Gate는 보안 측면에서 어떤 개선을 했는가?

Gate 보안팀: 먼저 우리는 이미 상장된 프로젝트에 대해 정기적인 보안 감사를 수행하며, 동시에 온체인 이벤트 모니터링을 통해 컨트랙트 상태를 지속적으로 추적한다. 컨트랙트가 업그레이드되었는지, 권한이 변경되었는지, 비정상적인 대규모 작업이 발생했는지는 지속적으로 확인해야 한다. 왜냐하면 상장 시의 점검 결론도 Adam이 말한 감사 보고서와 마찬가지로 유효기간이 있기 때문이다. 사용자도 언제든지 특정 컨트랙트의 현재 위험 항목을 조회할 수 있다.

다음은 플랫폼 자체에 대해 말하자면, Gate의 보안 취약점 바운티 프로그램은 항상 열려 있으며, 전 세계 보안 연구