스마트 계약 보안 분석 도구 상업화의 기회가 왔나요?

저자: Ray Xiao, Sally Gu, IOSG Ventures

서문:

9월 말 Paradigm이 블록체인 보안 프로젝트 Blowfish의 투자 유치를 완료했다고 발표하면서 스마트 계약 보안 분석 분야에 대한 관심이 다시 한번 집중되었습니다. 사실 Paradigm 팀은 그 이전부터 스마트 계약 보안 테스트 방향에서 많은 실천을 해왔으며, 올해 3월 Paradigm CTO Georgios는 그들이 개발한 Foundry 스마트 계약 테스트 도구 세트를 발표했습니다(이 팀은 Runtime Verification 팀도 중요한 기여자입니다). 현재 블록체인 보안 분석은 더 세분화된 방향으로 발전하고 있습니다.

최근 몇 달간의 자금 조달 추세와 시장 반응을 보면, 1차 시장 자본은 현재 보안 정보의 시의성, 위험 커버리지, 기술적으로 경량화된 보안 모니터링 및 방화벽 분야에 강한 관심을 보이고 있습니다(이는 과거 대부분의 자본이 감사 분야에 투자된 것과는 크게 다릅니다).

CertiK와 SlowMist의 관련 보고서에 따르면, 2022년 1분기와 2분기 동안 보안 공격 문제로 인해 암호 자산 손실이 20억 달러에 달했습니다. 2분기에는 단일 플래시 론 공격으로 인해 총 3억 달러의 자산 손실이 발생했습니다. 이번 달은 역사상 해커 활동이 가장 활발한 달이 되었으며, 2주 만에 DeFi 프로토콜을 대상으로 한 공격이 12회를 초과하고, 도난 금액은 7억 달러를 초과했습니다.

출처: https://twitter.com/chainalysis/status/1580312145451180032?s=20\&t=QfqOMqMKjHd3EtX_0O-QjA

우리가 체인 상의 스마트 계약을 개발>> 배포>> 블록체인 네트워크에서 실행으로 보는 완전한 생애 주기로 간주한다면, 스마트 계약에 대한 보안 분석은 계약 배포 전(블록체인 네트워크가 공식적으로 가동되기 전)의 분석과 계약 배포 후의 분석으로 나눌 수 있습니다. 이는 대략적으로 테스트, 감사, 모니터링의 세 가지 주요 카테고리를 포함하며, 각 카테고리 아래에는 다양한 유형의 분석 방법과 해당 도구가 있습니다(아래 그림 참조). PS: 스마트 계약의 감사 범위는 계약 배포 전부터 배포 후(계약 업그레이드 감사)까지 포함됩니다.

1. 스마트 계약 배포 전의 보안 분석: 테스트 + 감사

1.1 테스트 (Testing)

계약 테스트는 개발자와 감사자가 가장 많은 노력을 기울여야 하는 작업으로, 이는 전통적인 개발자와는 다릅니다. 블록체인의 불변성 특성 때문에, 스마트 계약이 EVM 가상 머신에 배포되면 변경하기 어려워지므로, 보안 분석 및 보안 취약점 보완 작업은 대부분 "사전 분석"에 소요됩니다. 즉, 스마트 계약 배포 전의 보안 테스트에 많은 노력을 기울여야 합니다.

정식 감사 전에 계약 개발자/감사자는 계약 코드에 대해 일부 기본 테스트를 수행해야 하며, 초기 테스트의 커버리지가 높을수록 간단한 버그가 정식 감사 단계에 들어가는 것을 방지할 수 있습니다(일반적으로 스마트 계약의 85%-90% 코드가 테스트 커버리지를 갖는 것이 합리적인 수준이며, 핵심 모듈에 대한 커버리지는 95% 이상이어야 합니다).

일반적인 기본 테스트에는 단위 테스트(단일 함수 테스트에 집중)와 통합 테스트(각 부분 코드가 조합되어 정상적으로 작동하는지 확인)가 포함됩니다. 이 단계에서 일반적으로 사용되는 도구는 Hardhat, Truffle test framework 등이 있으며, 일반적인 테스트 내용에는 상태 확인, 이벤트 트리거, 거래 리셋, 함수 계산, 완전 기능 테스트가 포함됩니다.

출처: https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d

1.2 감사 (Auditing)

"테스트는 프로그램의 결함을 효과적으로 발견할 수 있지만, 프로그램에 결함이 없다는 것을 증명할 수는 없다."------ Edsger Wybe Dijkstra(컴퓨터 과학자, 1972년 튜링상 수상자)

Ethereum 공식 문서의 정의에 따르면, 감사는 스마트 계약의 각 줄 소스 코드의 세부 사항을 평가하고, 공격자의 사고 방식을 통해 스마트 계약 내의 가능한 공격 벡터를 도출하여 잠재적인 결함, 보안 취약점 및 불량 개발 관행을 발견하는 과정입니다. 감사 단계는 대략적으로 정적 분석, 동적 분석(퍼징 테스트, 기호 실행), 수동 분석, 형식 검증을 포함합니다. Dijkstra가 말한 것처럼, 단순히 테스트에만 의존해서는 프로그램에 결함이 없다고 완전히 믿을 수 없으며, 감사와 형식 검증은 프로그램에 결함이 없다는 목표에 더 가까워지기 위해 필요합니다.

금전적 비용

스마트 계약 보안 회사 Hacken의 데이터에 따르면, 스마트 계약 감사 서비스의 산업 평균 비용은 5000달러에서 30000달러 사이입니다(중소형 프로젝트). 대형 프로젝트의 경우 비용이 50만 달러에 이를 수도 있습니다. 스마트 계약 감사의 비용은 코드 복잡성과 합의된 작업 범위에 직접적으로 의존합니다. 가격에 영향을 미치는 다른 요인으로는 긴급성, 스마트 계약의 크기(코드 행 수), 완료 과정에 필요한 엔지니어링 시간 수, 프로젝트 관련 문서의 가용성 등이 있습니다.

시간 비용

초기 감사는 평균 2일에서 14일이 소요되며, 이는 프로젝트의 복잡성, 스마트 계약 규모 및 긴급성에 따라 달라집니다. 대형 프로젝트나 프로토콜의 경우 초기 감사가 최대 1개월까지 소요될 수 있습니다. 초기 감사가 완료되면 고객은 어떤 수정 사항을 도입해야 하는지에 대한 제안을 받게 됩니다.

인력 비용

IOSG가 블록체인 형식 검증 분야의 선도 프로젝트인 Runtime Verification의 피드백에 따르면, 감사의 인력 비용은 프로토콜의 복잡성에 따라 달라집니다. 대부분의 경험이 풍부한 업계 전문가와 학문적 경험을 가진 주요 보안 감사 회사는 암호 고객 프로젝트의 비즈니스 논리와 토큰 경제를 이해하는 데 큰 어려움이 없으며, 일반적으로 두 명의 전문 엔지니어가 약 1~2주 정도면 초기 단계를 완료할 수 있습니다.

그러나 이후 단계는 고객의 구체적인 요구 사항에 따라 달라집니다. 일부 고객은 감사 프로젝트의 기본 비즈니스 논리만 수동으로 감사하기를 원하며(코드를 검토하고 요구되는 비즈니스 논리에 부합하는지 수동으로 검토), 이는 가장 저렴한 서비스입니다. 일부 고객은 비즈니스 논리와 토큰 경제를 모델링한 후 수학적 증명을 수동으로 수행하여 특정 중요한 결과가 성립하는지 확인하기를 원합니다. 예를 들어 안전성, 활성화, 일관성 등이 있습니다. MakerDAO, 이더리움 재단과 같은 대형 고객은 코드에 대한 형식 검증을 더 원합니다.

형식 검증에 대해 추가로 설명하자면, 형식 검증은 수학적 방법을 사용하여 프로그램의 정확성을 검증하는 것입니다. 즉, 프로그램의 구현이 프로그래머의 의도와 일치함을 증명하여 프로젝트 시스템이 버그가 없음을 입증하는 것입니다. 다시 말해, 형식 검증은 보다 포괄적인 "테스트"와 같으며, 이론적으로 모든 가능한 입력과 상태를 포함합니다. 이는 테스트로는 불가능한 것입니다(아래 그림의 예시처럼 전송 계약에서 오버플로우 버그가 있을 경우, 테스트를 통해서는 테스트자가 극단적으로 큰 값을 입력해야 발견할 수 있지만, 형식 검증자는 "토큰의 총량 = 모든 주소의 잔액 합계"라는 수학적 논리를 통해 오버플로우 버그를 찾아낼 수 있습니다).

실제 규모화된 사용 측면에서 형식 검증은 전통적인 테스트 솔루션에 비해 상대적으로 느립니다. 대부분의 암호 프로젝트는 스마트 계약 감사를 완료한 후 충분하다고 생각하며, 비용 투자와 잠재적 이익 측면에서 소형 프로젝트에는 필수품이 아닙니다(또는 프로그램이 버그가 없다는 것을 증명하는 비용이 여전히 높기 때문입니다). 핵심 원인은 형식 검증이 전문적인 형식 인력이 참여해야 하기 때문입니다. 프로젝트 코드에 대한 형식적 규범(formal specification)을 만드는 것은 매우 복잡한 작업이며, 계약 코드의 속성을 포함하고 다양한 상황에서 계약의 행동 방식을 정의해야 하므로 전문 인력이 필요합니다. (관심 있는 독자는 우리가 이전에 쓴 "왜 우리는 Runtime Verification에 투자했는가"를 참조하시기 바랍니다: https://mp.weixin.qq.com/s/VWVgn4k9k0XqbM-O7-TVXg)

스마트 계약 감사는 여전히 노동 집약적인 산업이며, 인재에 대한 기술 요구가 높습니다. 현재 시장에는 10여 개의 인기 있는 감사 도구가 있으며(대부분 주요 보안 감사 회사나 학술 연구자들이 개발한 것), 이러한 감사 도구의 개발 목적은 일반적인 취약점을 발견하는 것입니다. 예를 들어: 거래 순서 의존성, 난수, 타임스탬프, 호출 스택 깊이, 재진입, 위험한 위임 호출 등이 있습니다. 따라서 이러한 도구에만 의존하여 감사 작업을 완료하는 것은 어렵고, 비즈니스 논리와 관련된 많은 취약점을 놓칠 수 있습니다. 일반적으로 스마트 계약 감사는 자동화 도구와 수동 코드 검토를 결합한 방식으로 수행되며, 고객의 스마트 계약 비즈니스 논리 및 토큰 모델에 따라 사례별로 수동 검토가 필요합니다.

스마트 계약 보안 분석 및 감사는 종종 프로그램의 정확성을 검증하는 과정입니다. 즉, 프로그램의 구현이 프로그래머의 의도와 일치하는지 확인하는 것입니다. 프로그램의 버그는 실제로 프로그램의 구현과 프로그래머의 의도 간의 차이에서 발생합니다. 우리가 이전에 Runtime Verification에 투자한 내용을 공유하면서 언급한 형식 의미론은 개발자의 개발 의도(즉, "의미")와 구현(즉, 프로그래밍 언어의 "구문")이 정확하게 일치하도록 하는 언어 프레임워크로, 버그 발생을 줄이는 데 기여합니다.

스마트 계약 보안 감사 분야에서는 현재 시장에 도구가 많고 대부분 오픈 소스이지만, 실제로 성공적으로 상업화된 것은 극히 드뭅니다. 이 근본적인 원인에 대해서는 후에 분석할 예정이며, 현재는 여전히 보안 서비스 제공업체의 자동화 도구와 각 코드의 수동 검토 또는 모델링에 의존하고 있어, 기본적으로 자동화 감사 도구를 직접 판매하여 규모화된 상업 수익을 얻는 것은 불가능합니다.

PS: 최근 우리가 투자한 Hexens의 피드백에 따르면, 초기에는 Slither와 MythX와 같은 일부 정적 분석 테스트가 그들이 자주 사용하는 오픈 소스 도구이며, 결과가 그들을 매우 만족시키지는 못했다고 합니다. 더 높은 수준의 테스트를 위해 그들은 주로 Echidna, Forge + 내장 퍼저를 사용합니다.

2. 스마트 계약 배포 후의 보안 분석 ------ 모니터링 (Monitoring)

현재 10가지 가장 일반적인 블록체인 네트워크 보안 공격 중 Scam의 발생 빈도가 가장 높으며, 사용자에게 직접적인 자산 손실을 초래합니다. Peckshield의 데이터에 따르면, 2021년 암호화폐는 각종 사기로 인해 체인 상에서 120억 달러의 경제적 손실을 입었으며, 이는 해커의 직접 공격으로 인한 손실보다 6.7배 높습니다.

일반적인 Scam 공격:

• 피싱(일반적인 피싱 기법은 이메일/웹사이트를 통해 사용자에게 비밀번호 재설정/계정 복구를 요청하는 것입니다. 사용자가 이러한 가짜 웹사이트에 로그인하면 개인 키가 도난당합니다.)

  사례: Alice가 특정 거래소에 로그인한 후 MetaMask 지갑을 연결하고, 지갑 오류로 인해 복구를 위해 시드 문구를 입력하라는 팝업을 받습니다. 복구 후 지갑 내 자산이 모두 도난당합니다.

• 사칭/위장(자칭 특정 dapps/기관의 직원이나 대표인 사람이 이메일, 전화 또는 소셜 미디어를 통해 사용자에게 연락합니다. 그들은 가짜 무료 민팅/에어드랍 웹사이트를 통해 사용자로부터 자금을 훔칩니다. 또는 사칭 행위를 통해 피해자로 하여금 자금이나 민감한 데이터를 추출하도록 조작합니다.)

  사례: 우크라이나 정부가 암호화폐 기부를 받고 NFT 에어드랍을 발표하자, 사칭자가 우크라이나 정부를 가장하여 가짜 토큰 에어드랍을 통해 사기를 칩니다.

• Discord 관리자 신원 탈취(공격자는 커뮤니티에서 신뢰받는 관리자의 봇을 제어하여 가짜 공지, 사기 링크를 게시하거나 피해자로 하여금 암호화폐나 NFT를 포기하도록 속입니다.)

  사례: 해커가 Bored Ape Yacht Club과 같은 블루칩 NFT의 Discord 공식 서버를 제어하여 회원들에게 잘못된 링크를 대량으로 전송하고, 사용자가 클릭하면 자산이 되돌릴 수 없이 도난당합니다.

• BGP 탈취(실제로 제어할 수 없는 IP 접두사를 소유하고 있다고 거짓 주장하고 이를 인터넷 BGP 라우터의 라우팅 테이블에 추가함으로써, 공격자는 해당 IP 주소의 트래픽을 탈취할 수 있습니다. 이 경우 사용자가 로그인하려고 시도하면 공격자가 설정한 함정 주소로 리디렉션됩니다.)

  사례: Celer가 BGP 탈취 공격을 당해 32명의 사용자와 23.5만 달러의 손실을 입었습니다(2022.08).

• 코드 백도어 및 함정(공격자는 정상 프로그램에 숨겨진 특수 기능을 가진 악성 코드의 일부를 삽입하여 파일을 파괴하거나 삭제하고, 비밀번호를 전송하며, 키보드를 기록하고 DDoS 공격을 수행하는 등의 특수 기능을 가진 백도어 프로그램을 통해 사용자 개인 정보를 훔칩니다.)

  사례: Bob이 특정 웹사이트에서 NFT를 민팅한 후 이틀 후 사라진 것을 발견했습니다. 공격자가 NFT 코드에 특정 특성을 삽입하여 다른 사람이 NFT 거래를 승인하거나 다른 사람의 NFT를 파괴할 수 있게 했습니다.

• 프론트엔드 악성 코드(공격자는 거래소와 같은 웹사이트의 프론트엔드에 악성 코드를 삽입하여 사용자 브라우저의 탭 관리 시스템을 통해 이 악성 코드가 잘못된 승인을 생성하게 하여 사용자의 자산이 공격자의 주소로 전송되도록 합니다.)

  사례: KyberSwap이 해커가 삽입한 프론트엔드 악성 코드로 인해 256만 달러의 손실을 입었습니다(2022.09).

일반적인 도구:

스마트 계약 보안 감사에 비해 모니터링 및 방화벽 서비스는 더 방대하고 세밀한 비즈니스 내용을 포함합니다.

계약 배포 전 및 계약 배포 후 업그레이드된 스마트 계약 코드의 보안 감사는 종종 다양한 테스트(정적 분석, 동적 분석)를 통해 일련의 값을 입력하여 계약의 출력 값 및 상태가 정상적으로 작동하는지 확인합니다. 예를 들어, 일반적인 체인 상 전송 논리에 대해(아래 그림 참조), 일반적인 테스트 담당자는 transfer zero ether, transfer all the ether, transfer slightly more than all the ether, transfer the largest possible amount of ether, transfer an account's value to itself 등의 작업을 수행하여 계약이 프로그래머가 예상한 대로 작동하는지 확인합니다.

Focus는 사건 중 보안 분석의 모니터/방화벽 서비스에서 처리해야 할 문제는 더 복잡합니다. 현재 이와 같은 프로젝트가 제공하는 보안 서비스는 가능한 한 많은 문제 있는 체인 상 자산 계약, 최신 사기 행위의 주소 계약 피싱 웹사이트 등을 포함하는 폭넓은 접근을 더 중시하고 있으며, 이는 계약 감사의 보안 서비스보다 더 경량화되어 있습니다. 코드의 정확성을 검사하는 것 외에도 다양한 사기 및 피싱 관련 공격과 같은 보안 위험이 포함됩니다. 이러한 취약점을 모니터링하기 위해서는 계약 분석 능력 외에도 의심스러운 주소, 의심스러운 계약 논리, 의심스러운 자산 목록 등의 데이터 위험 데이터베이스를 지속적으로 업데이트해야 합니다.

최근 업계 종사자와의 대화를 통해 다양한 모니터 서비스의 위치가 각기 다르다는 것을 발견했습니다. 예를 들어 GoPlus는 프로젝트 측에 데이터 API 서비스를 제공하는 데 더 중점을 두고 있으며, 심지어 일부 프론트엔드 방화벽에 대해서도 마찬가지입니다. Harpie와 Blowfish는 사용자가 거래 행위를 수행하거나 권한 부여를 완료하기 전에 이 거래를 시뮬레이션하여 문제를 발견하고 사용자가 안전 위험이 있는 거래를 방지하도록 합니다. Tenderly는 개발자의 요구에 더 중점을 두어 스마트 계약 개발자에게 실행 모니터링 등의 서비스를 제공합니다. 물론 현재 이 분야는 비교적 새롭고, Opensea와 같은 대형 거래 플랫폼이 일부 프로젝트와 실질적인 상업적 협력을 진행하고 있지만, 우리는 미래의 상업화 경로가 여전히 불확실하며, 동종 경쟁이 상당할 것이라고 생각합니다(코드 감사 기술의 진입 장벽이 상대적으로 낮기 때문에).

3. 스마트 계약 보안 분석 도구의 상업적 발전 기회와 도전 과제

1) 현재 업계의 많은 사람들은 모니터링 및 방화벽과 보안 감사 간의 상업적 경계가 여전히 모호하다고 생각합니다(현재 두 서비스 모두 2B 서비스에 해당하며, 고객의 대부분은 다양한 암호 프로젝트입니다). 이론적으로 블록체인 보안 분야에서 다년간 깊이 있는 전문 보안 감사 회사가 직접 모니터링 서비스를 제공하고, 심지어 B2C, 2C화된 최종 사용자에게 직접 수익을 창출하는 제품이 상업적 발전 논리에 더 부합합니다. 그러나 모니터링 분야는 이제 막 시작되었고, 요금 모델과 수익 모델이 명확하지 않습니다(현재는 2B 서비스 수수료 또는 프로젝트의 거래 수수료 분배를 통해 수익을 얻고 있습니다). 만약 시장이 회복된다면 보안 감사 시장은 여전히 공급 > 수요 상태로, 주문을 처리할 수 없는 상황이 발생할 수 있으며, 이로 인해 새롭게 등장한 모니터/방화벽 전문 회사에 좋은 기회를 제공할 수 있습니다.

2) 스마트 계약 감사의 자동화 도구는 현재 시장에 이미 많이 있으며, 일반적으로 10여 가지가 대부분 오픈 소스입니다. 이 방향에서 도구를 판매하여 수익을 얻는 상업 모델은 아직 성공적으로 운영되지 않고 있으며, 그 핵심 원인은 다음과 같습니다:

• 해커와 보안 방어자의 대결 관계는 무기 경쟁이며 공격은 항상 움직이는 목표입니다. 따라서 보안 도구는 출시되면 해커가 이를 우회하려고 시도하고 새로운 공격 형태를 개발합니다. 따라서 보안 도구는 지속적으로 업데이트하여 공격 문턱을 높여야 합니다.
• 대부분의 도구는 사용 문턱이 높아 전문 보안 분석 도구를 사용할 수 있는 사람이 적어 시장 규모를 제한합니다(비록 Runtime Verification이 일반 개발자 사용을 위해 Firefly를 제공하고 ConsenSys Diligence도 MythX를 제공하고 있지만).
• 보안 분석 도구는 주로 일반적인 취약점만을 커버할 수 있으며, 프로토콜 비즈니스 논리의 경제 모델에 따라 고객은 주관적으로 감사 팀이 수동으로 제공하는 맞춤형 서비스를 더 선호합니다.

팀은 또한 시장에서 인증된 감사 회사가 더 깊이 있는 맞춤형 감사 서비스를 제공하고 도장을 찍어주기를 원합니다. 따라서 모니터링 서비스를 제공하는 것은 전문 보안 팀이 규모화된 제품으로 진입할 수 있는 좋은 기회가 될 것입니다.

3) DeFi 프로젝트, DAO 또는 개인을 위한 보험 사업은 다음 블루오션이 될 수 있습니다. 현재 시장에서 해커가 개인 키를 직접 탈취하는 등의 공격 방법에 대한 효과적인 방어 또는 해결책이 없기 때문에, 위험 회피 및 자산 보호를 목적으로 하는 보험 사업은 미래에 더 많은 인기를 끌 가능성이 높습니다.

물론 암호 자산 자체의 복잡성과 규제 측면의 여러 불확실성을 고려할 때, 인수자는 종종 더 큰 위험을 감수해야 하므로 이 문제를 해결하기 전까지 보험 산업의 발전은 예측 가능한 한계에 직면할 것입니다. 전체 암호 자산 규모의 증가와 더 많은 전통 기관 사용자의 진입에 따라 보험 사업이 다음 주기가 도래하기 전에 더 많은 제도적 개선을 이룰 수 있기를 기대합니다.

참고 문헌:

https://www.paradigm.xyz/2022/03/foundry-02

https://www.coindesk.com/business/2022/09/30/paradigm-leads-118m-funding-round-into-web3-firewall-blowfish/

https://ethereum.org/en/developers/docs/smart-contracts/testing/

https://docs.openzeppelin.com/learn/writing-automated-tests

https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297

https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d