크로스 체인 브릿지가 왜 사고 다발 지역이 되었나요?

원문 제목：《크로스체인 브릿지 사고가 이렇게 많은 이유는?》

원문 저자：0xScope 팀

서론

최근 빈발하는 크로스체인 보안 문제는 시장의 광범위한 관심을 끌고 있으며, 본문은 제품 설계의 관점에서 독자에게 이 분야의 제품 보안 문제가 왜 이렇게 많은지 설명하고자 합니다. 명시해야 할 것은, 본문에서 지적하는 문제는 모든 프로젝트에 존재하는 것은 아니며, 대부분의 문제는 설계 시 이미 관련 대응 전략이 마련되어 있습니다. 본문의 목적은 더 많은 사람들이 이 분야의 복잡성을 이해할 수 있도록 하는 것입니다.

본문의 작성 논리는 다음과 같습니다: 먼저 일반적인 크로스체인 브릿지가 어떻게 설계되는지 명확히 설명하여 독자의 이해를 돕고, 이후 이러한 크로스체인 브릿지가 직면할 수 있는 보안 문제를 요약합니다.

1: 변하지 않는 본질의 크로스체인 솔루션

이전의 연구 보고서에서는 여러 가지 다른 유형의 정보 크로스체인 솔루션을 설명한 바 있습니다. 최종적인 표현이 어떻든, 제품 설계의 관점에서 볼 때, 사이드체인(광의의 사이드체인, 본문에서 롤업도 사이드체인으로 분류됨), 해시 타임 락, 공증인 이 세 가지 메커니즘만이 존재합니다.

(1) 사이드체인

이 세 가지 솔루션 중 사이드체인 솔루션의 보안성이 가장 높습니다. 예를 들어 다양한 롤업과 폴카닷의 평행 체인입니다. 메인 체인과 사이드체인 간에 보안성을 공유합니다.

하지만 사이드체인 솔루션은 일반적으로 원체인과 목표체인이 동형이어야 하므로 적용 가능한 장면이 훨씬 적습니다. 이것이 바로 비탈릭이 다중 체인을 지지하지만 크로스체인을 인정하지 않는 이유입니다. 보안성을 공유할 수 없는 크로스체인 솔루션은 문제점이 너무 많습니다.

(2) 해시 타임 락

이 솔루션은 점대점에서 가장 탈중앙화된 이종 크로스체인 솔루션으로 알려져 있지만, 비용이 높고 사용자 대기 시간이 길어 현재 채택률이 높지 않습니다. 또한 여전히 제3자가 환전 중간 노드 역할을 해야 할 경우, 보안성과 탈중앙화 요구를 충족하기 위해 소위 중간 합의 계층이 필요합니다.

(3) 공증인 메커니즘

현재 가장 많이 사용되는 이종 크로스체인 브릿지 솔루션으로, 시장의 대부분 제품은 기본적으로 동일한 출처를 가지고 있습니다. 제품 설계의 관점에서 거의 차이가 없습니다. 주요 차이는 정보 검증 방식, 공증인의 합의 알고리즘, 관리 지갑의 서명 알고리즘 등에 집중됩니다. 사용 경험과 보안성의 차이도 크지 않습니다. 따라서 보안의 관점에서 보면, 직면하는 보안 위험도 많은 공통점을 가지고 있습니다.

본문은 공증인 메커니즘의 크로스체인 브릿지가 직면하는 몇 가지 공통적인 보안 위험을 요약하고 분석하는 데 중점을 두겠습니다.

2: 공증인 메커니즘의 제품 논리 흐름

공증인 메커니즘이 직면하는 다양한 위험을 이해하기 전에, 이 유형의 솔루션이 제품 관점에서 어떤 설계 논리를 가지고 있는지 먼저 이해해야 합니다.

(1) 간략 설명

이 솔루션은 설계 철학의 관점에서 매우 간단합니다. 이종 자산의 크로스체인 요구에 직관적으로 가장 적합한 솔루션은 "매핑"입니다. 매핑의 의미는 사용자 A가 이더리움에서 팬텀으로 ETH를 이동할 때, 자산을 실제로 이동시키거나 팬텀에서 재발행할 필요가 없다는 것입니다(이것도 불가능합니다). 대신 사용자 A의 ETH를 이동할 수 없는 주소에 저장한 후, 이 주소에 있는 사용자 A의 ETH 수량에 따라 팬텀에서 1:1 매핑 자산을 발행합니다. 매핑 자산은 이더리움 원체인에서의 ETH 사용권을 나타냅니다. 1:1의 고정으로 인해 팬텀의 사용자도 이 자산의 가치를 인정합니다.

가장 단순화된 크로스체인 프로세스

(2) 설계의 난점

여기에는 많은 문제가 존재하며, 그 중 가장 큰 문제는 다중 서명 지갑 관리 문제입니다. 왜냐하면 ETH가 이더리움에서 팬텀으로 이동하는 것은 충전이고, 만약 사용자 A가 다시 돌아가고 싶다면 출금 문제에 관련됩니다.

충전과 출금의 탈중앙화 및 보안성이 최대의 난점이 됩니다.

1: 누가 돈을 관리하나요?

2: 누가 시작하나요?

3: 누가 거래를 모니터링하나요?

4: 어떻게 사용자가 실제로 돈을 보냈는지 확인하나요?

5: 어떻게 사용자의 돈이 실제로 사용자가 출금하고 싶어하는 것인지 확인하나요?

6: 어떻게 재전송 공격을 방지하나요?

7: 실패한 거래는 어떻게 다시 제출하나요?

8: 다중 서명 관리자가 악의적으로 행동하면 어떻게 하나요?

9: 다운타임이 발생하면 어떻게 하나요?

생각하기도 두렵고, 생각할수록 복잡하게 느껴집니다. 크로스체인 브릿지 기술은 단순히 다중 서명뿐만 아니라 자산 발행, 크로스체인 모니터링, 비동기 검증, 심지어 독립적인 중간 합의 계층(새로운 체인)을 발행해야 합니다.

따라서 사용자 이해의 난이도를 더욱 간소화하기 위해, 전체 크로스체인 프로세스를 충전과 출금 두 부분으로 나누어 설명하겠습니다. 이를 통해 여러분이 더 잘 이해할 수 있도록 돕겠습니다:

(3) 프로세스의 추가 세분화

1: 충전

먼저 명시하자면, 아래 그림의 프로세스는 제가 추론한 설계안일 뿐이며, 세심한 검증을 거치지 않았습니다. 이는 설계 논리에서 발생할 수 있는 보안 문제를 탐구하기 위한 것이며, 성형된 솔루션으로 채택할 수 없습니다. 전부 허튼소리입니다.

그림에서 보듯이, 원체인에서 목표체인으로의 충전 거래는 원칙적으로 다음 단계를 포함합니다:

(1) 사용자가 관리 주소로 충전합니다.

(2) 리스너가 이 거래를 감지한 후 BP(합의 노드이자 다중 서명 관리자)가 거래를 시작합니다.

(3) 계약이 BP 서명의 정확성을 검증합니다.

(4) 노드 오류 수정 메커니즘이 있는지 확인합니다.

(5) 없다면 되돌리고, 있다면 매핑 주소의 관계에 따라 목표 체인 주소로 충전합니다.

(6) BP가 이 충전 거래를 확인합니다.

(7) 비잔틴 합의를 통해 매핑 토큰을 사용자에게 목표 체인 주소로 전송합니다.

특히 주의해야 할 점은, 이 프로세스는 일반적인 이종 크로스체인에 대한 논의를 목적으로 하므로 anyswap 등의 솔루션에 비해 중간 합의 계층에서 사용자가 주소 관계를 바인딩하는 단계를 추가했습니다. 이는 서로 다른 이종 체인 거래에 부가된 정보의 방식이 다르기 때문에 통일된 처리를 위해 사용자가 매핑 관계를 미리 바인딩하도록 한 것입니다.

모두 EVM 체인 거래를 처리하는 경우에는 이 단계를 필요로 하지 않으며, 거래를 시작할 때 목표 체인 주소를 함께 첨부하면 됩니다.

본론으로 돌아가서: 위의 프로세스에서 볼 수 있듯이, 두 번째 단계부터 다양한 논리 검증 문제와 다양한 상황에서의 처리 문제가 발생합니다.

주요 검증 논리는 다음과 같습니다:

(1) 거래를 감지한 후 자산 매핑 및 사용자 A의 목표 체인 거래에 대한 검증

(2) 목표 체인 거래의 시작 및 거래 결과 검증

물론 제가 그린 프로세스의 검증 논리 외에도 가짜 자산 충전 문제의 검증 및 다양한 토큰 호출 시 필요한 특별 처리 문제도 포함되어야 합니다.

이후 발생할 수 있는 보안 위험을 더 잘 요약하기 위해, 출금 프로세스를 이해해 보겠습니다.

2: 출금

출금에서 보여주는 프로세스는 목표 체인 매핑 자산을 원체인 자산으로 교환하는 논리입니다. 특히 주의해야 할 점은 현재 많은 토큰이 여러 체인 버전을 발견했다는 것입니다. 즉, 많은 토큰이 여러 체인에서 원주 토큰을 가지고 있습니다. 따라서 일부 브릿지 프로젝트는 자산 풀을 설정하는 경우가 많습니다. 자금 풀이 충분한 경우, 사용자는 anyDAI와 같은 매핑 자산의 존재를 느끼지 못하고, 직접 목표 체인 버전의 토큰으로 교환됩니다. 하지만 이는 전체 논리에 영향을 미치지 않습니다. 따라서 분석을 계속하겠습니다:

그림에서 보듯이, 목표 체인에서 원체인으로 출금하는 거래 프로세스는 다음과 같습니다:

(1) 사용자가 거래를 시작합니다(동일량의 매핑 자산을 목표 체인 관리 지갑으로 전송).

(2) BP 신원을 검증하고, 특정 BP가 출금 요청을 시작합니다.

(3) 출금 권한 및 서명을 확인합니다.

(4) 비잔틴 합의를 통해 원체인에서 출금을 완료하고, 원체인의 관리 지갑에서 사용자 A에게 돈을 전송합니다.

(5) 이 과정에서 노드 검증 오류나 다운타임 등의 문제가 발생하면 롤백하여 다시 시작해야 합니다.

위의 프로세스에서 볼 수 있듯이, 여기에는 주요 검증 논리가 포함됩니다:

(1) 시작 및 서명 권한의 검증

(2) 문제 발생 시의 오류 수정 메커니즘

(4) 보안 위험

1: 설계 논리상의 보안 문제

크로스체인 브릿지의 설계를 자세히 이해한 후, 우리는 설계 논리에서 크로스체인 브릿지가 직면하는 도전이 매우 많다는 것을 알 수 있습니다. 주요 문제는 세 가지 측면으로 요약할 수 있습니다(관련된 도난 사례는 문제 끝에 주석으로 달았습니다).

(1) 충전

a) 충전 계약 권한 취약점으로 인해 충전된 돈이 직접 전송되는 문제입니다. 이는 거의 모든 계약 프로젝트가 직면하는 어리석은 문제입니다.

b) 가짜 자산 충전 문제로, 일부 프로젝트가 크로스체인 토큰의 진위를 검증하지 않아 fakeTOKEN -> realTOKEN(anyswap) 문제가 발생합니다. 솔직히 이 또한 다소 어리석습니다.

c) 가짜 자산 충전 문제로, ETH와 같은 원주 자산은 ERC20 계약과 다르며, 많은 공격이 ETH에 대한 특별한 처리가 부적절하여 발생합니다. 이는 fakeETH -> realETH 문제로 이어지며, WETH와 같은 래핑 자산이 유행하는 이유이기도 합니다(Thorchain).

d) 서로 다른 토큰이 모두 ERC20 표준이지만, 구체적인 구현 방식이 다르거나 추가적인 논리가 있을 수 있습니다(rebase, fallback 등). 개발자가 적절한 조사를 하지 않고 적응할 경우, (WETH, PERI, OMT, WBNB, MATIC, AVAX 등) 전송 완료 후 sender가 정의한 fallback 함수를 호출하여 추가 작업을 수행하게 되어 크로스체인 브릿지 판단의 복잡성을 증가시킵니다(anyswap 2022.1.18).

(2) 크로스체인 메시지 전송

a 체인에서 충전 완료 후 b 체인 자산이 도착하기 전, 크로스체인 브릿지의 처리는 독립적인 블록체인 시스템처럼 작동합니다. 즉, 합의 메커니즘이 필요하며, 일반적으로 dpos를 사용합니다. 아래는 dpos를 가정했을 때 고려해야 할 문제입니다. 하지만 모든 노드가 프로젝트 측의 것이라면, 중앙화 위험이 존재합니다.

a) 충전 메시지 모니터링, 누가 첫 번째로 크로스체인 처리 제안을 시작하나요? 무작위? 아니면 순환? 아니면 중간 합의 계층의 블록 생성 순서에 따라?

b) 여러 공증인이 충전의 정확성을 어떻게 검증하나요? 데이터 소스가 infura와 같은 데이터 제공업체에서 온다면 infura는 단일 지점 위험이 됩니다. 가장 안전한 방법은 각자가 노드를 유지하는 것이지만, 이는 비용이 막대합니다.

c) 크로스체인 처리가 완료되었는지 어떻게 확인하나요(b에서 도착했는지)? 처리되지 않은 경우는 여러 가지 상황이 있습니다:

i. 크로스체인 브릿지가 처리를 시작하지 않았습니다.

ii. 크로스체인 브릿지가 처리를 시작했지만 검증 및 합의가 통과하지 않았습니다.

iii. 크로스체인 브릿지가 검증을 통과했지만 b 체인에서 거래를 시작하지 않았습니다.

iv. b 체인에서 거래가 있었지만 실패했습니다(자금 부족 또는 기타 상황).

(3) 다중 서명 검증 문제

문제가 자주 발생하는 주요 지역으로, 대부분 코드 논리 문제입니다.

a) 3/5 서명, 제가 임의로 다중 서명 목록에 없는 서명을 구성해도 +1로 간주됩니다(chainswap).

b) 중앙화 문제로, 명목상으로는 다중 서명이지만 실제로는 프로젝트 측이 통제하고 있어 큰 중앙화 위험이 존재합니다.

c) 서명 검증 방법으로, 서로 다른 체인에서의 개발 모델이 다르기 때문에 개발자가 연결할 때 누락이 발생할 수 있습니다. wormhole 사례: 솔라나의 검증 서명 함수는 시스템 계약의 함수로, 정상적으로는 시스템 계약을 호출해야 하며, 시스템 계약의 주소는 코드에 고정되어 있어야 합니다. 그러나 이들은 시스템 계약 주소를 매개변수로 전달하여 해커가 출금할 때 가짜 시스템 계약 주소를 전달하여 검증을 우회하고 원활하게 자산을 출금하게 되었습니다.

(4) 환불

a) (2)-c에서 논의한 것처럼, 크로스체인 상태에는 여러 가지 가능성이 있으며, 어떤 경우에도 사용자에게 환불 방법을 제공해야 합니다. 예를 들어, anyswap은 충전 시 원체인에서 사용자에게 anyToken을 먼저 발송한 후 목표 체인에서 사용자에게 anyToken을 발송하고, 원체인의 anyToken을 소각합니다. 이러한 목적은 문제가 어디에 있든 사용자가 anyToken을 보유함으로써 자신의 자산을 보유하고 있음을 나타내는 것입니다. 이 과정에서 3개의 체인(원, 목표, 크로스체인 브릿지)과 4개의 자산(원체인 및 목표 체인上的 원래 토큰/anyToken)이 존재하여 코드 논리 문제 발생이 매우 용이합니다.

b) Thorchain은 2021.7.23에 발생한 취약점으로, 해커가 코드 논리 문제를 이용해 대규모 가짜 충전을 구성하여 크로스체인 브릿지가 처리할 수 없게 되어 환불 논리로 들어가 해커가 대규모 환불을 받게 되었습니다.

2: 기타 보안 위험

하지만 논리 프로세스에서 보여줄 수 있는 문제는 비즈니스 논리상의 문제일 뿐이며, 전부는 아닙니다.

보안의 관점에서 우리는 세 가지 추가 위험을 고려해야 합니다:

(1) 시스템적 위험

예를 들어 원체인의 충전이 처음에 성공했지만 나중에 롤백되면 이는 큰 문제입니다. 비탈릭이 논의한 바와 같이, 자산이 솔라나에서 이더리움으로 이동한 후 크로스체인이 완료된 후 솔라나가 롤백되면 사용자의 자산이 두 배가 되며, 이에 대한 해결책이 없습니다.

그러나 이더리움과 보안을 공유하는 레이어2인 롤업과 같은 경우에는 이러한 문제가 발생하지 않습니다.

(2) 프론트엔드 위험

a) 위조된 URL, 예를 들어 oxdao.fi, 0xdao.fi, oxdai.fi 등

b) XSS 공격, 즉 교차 사이트 스크립트 공격으로, 코드 주입 공격입니다. 예를 들어 www.xxxx.finance/?params=hackerscode12345, 비록 URL이 실제 공식 사이트이지만, URL에 해커의 코드가 포함되어 있습니다. 만약 프론트엔드 개발자가 XSS 방지를 주의하지 않았다면, 이 코드가 페이지에서 실행되어 사용자가 해커의 송금 거래에 대한 서명을 허가하게 됩니다. 따라서 출처가 불분명한 링크는 열지 말아야 합니다.

c) CORS 교차 사이트 서비스 공격으로, 엄격한 동일 출처 정책에서 브라우저는 본 사이트에서 로드된 콘텐츠만 허용합니다. 즉 www.xxxx.finance 사이트에서 표시되는 모든 콘텐츠와 호출된 인터페이스는 xxxx.finance 도메인에서 와야 합니다. 그러나 현재 대부분의 프로젝트는 교차 사이트 호출을 허용하고 있습니다. 즉 xxxx 프론트엔드가 quickswap의 인터페이스를 호출할 수 있으며, 그 반대도 마찬가지입니다. 이는 개발에 편리함을 제공하지만 위험도 동반합니다:

예를 들어 제가 xxxx.finance에 접속하여 브라우저 캐시에 민감한 데이터를 저장한 후 악성 URL에 접속하면, xxxx의 동일 출처 정책이 제한되지 않았다면 이 악성 URL이 xxxx에 존재하는 캐시 데이터를 자유롭게 가져갈 수 있습니다.

(3) 추가 기능의 위험
일부 크로스체인 브릿지 프로젝트는 자산 크로스체인 외에도 크로스체인 계약 호출을 제공하여 추가적인 복잡성을 초래합니다.

공격자가 a 체인에서 b 체인의 x 계약에 대한 호출을 시작하면, 크로스체인 브릿지는 x 계약이 무엇인지 상관없이 직접 호출하게 됩니다. 예상치 못하게 x 계약이 크로스체인 브릿지의 b 체인 다중 서명 계약이라면, 이 호출은 다중 서명 계좌를 공격자의 주소로 변경하게 됩니다. 실행이 성공하면 해커는 크로스체인 브릿지의 b 체인 자금을 자유롭게 조작할 수 있게 됩니다(폴리 네트워크).

3: 결론

1: 본 보고서의 목적은 사용자가 크로스체인 브릿지의 보안 위험을 보다 명확히 이해하는 데 도움을 주는 것이며, 크로스체인 브릿지가 얼마나 쉽게 공격받을 수 있는지를 악의적으로 부각시키려는 것이 아닙니다.

2: 공증인 메커니즘의 크로스체인 브릿지 솔루션은 현재로서는 사용자 경험이 가장 좋고, 적용 범위가 가장 넓으며, 비용이 가장 낮은 솔루션입니다. 그리고 모든 제품은 상처투성이에서 성숙해지는 과정을 겪게 되며, 블록체인 제품이 겪는 공격은 종종 "논리 문제"입니다. 이러한 문제는 시간이 지남에 따라 경험이 쌓이면서 점점 더 나아질 것입니다.