교차 사슬 교량에서 낮은 수준의 사고가 많은 이유는 무엇입니까?

머리말

최근 자주 발생하는 교차 체인 보안 문제는 시장의 광범위한 관심을 끌었습니다.이 기사는 제품 디자인의 관점에서 시작하여 독자들에게 왜 이 트랙에 많은 제품 보안 문제가 있는지 설명하고자 합니다. 기사에서 지적한 문제가 모든 프로젝트에 존재하는 것은 아니라는 점을 선언해야 합니다. 대부분의 문제는 이미 적절한 대처 전략으로 설계되었습니다. 이 기사의 목적은 주로 더 많은 사람들이 이 트랙을 이해하기를 바라는 것입니다. .

기사의 작성 논리는 다음과 같습니다. 먼저 일반 교차 체인 브리지가 어떻게 설계되었는지 명확하게 설명하고 독자의 교차 체인 브리지에 대한 이해를 심화한 다음 이러한 교차 체인 브리지에서 발생할 수 있는 보안 문제를 요약합니다.

1: 끊임없이 변화하는 크로스체인 솔루션

이전 연구 보고서는 실제로 여러 유형의 정보 크로스 체인 솔루션을 모든 사람에게 설명했습니다 최종 프레젠테이션이 무엇이든 제품 디자인의 관점에서 볼 때 사이드 체인 (본문에서 넓은 의미의 사이드 체인) 말하기 롤업의 경우에도 사이드 체인, 해시 시간 잠금 및 공증의 세 가지 메커니즘으로 요약할 수 있습니다.

(1) 사이드 체인

세 가지 방식 중 사이드체인 방식은 다양한 롤업과 폴카닷 파라체인 등 보안성이 가장 높다. 보안은 메인 체인과 사이드 체인 간에 공유됩니다.

그러나 사이드체인 체계는 일반적으로 원래 체인과 대상 체인이 동형이어야 하므로 적용 가능한 시나리오가 훨씬 적습니다. 비탈릭이 크로스체인이 아닌 멀티체인에 동의하는 이유이기도 합니다. 크로스체인 솔루션은 보안을 공유할 수 없는 문제가 너무 많기 때문입니다.

(2) 해시 시간 잠금

이 솔루션은 가장 탈중앙화된 P2P 이종 교차 체인 솔루션이라고 주장하지만 비용이 높고 사용자 대기 시간이 너무 길어 현재 채택률이 높지 않습니다. 그리고 통화 교환을 위한 중간 노드 역할을 할 제3자가 여전히 필요한 경우 보안 및 분산 요구 사항을 충족하기 위해 소위 중간 합의 레이어가 필요합니다.

(3) 공증 기구

현재 가장 보편적으로 사용되는 이기종 크로스체인 브릿지 솔루션으로 시중의 대부분의 제품은 기본적으로 동일한 원산지이며 제품 디자인의 관점에서 거의 차이가 없습니다. 주요 차이점은 정보 확인 방법 및 단계, 공증인의 합의 알고리즘, 에스크로 지갑의 서명 알고리즘 등에 중점을 둘 수 있습니다. 사용자 경험과 안전 측면에서 큰 차이는 없습니다. 따라서 보안 관점에서 볼 때 직면한 보안 위험에는 많은 공통 기능이 있습니다.

이 기사는 공증 메커니즘의 교차 체인 브리지가 직면한 몇 가지 일반적인 보안 위험을 요약하고 분석하는 데 중점을 둘 것입니다.

2: 공증 메커니즘의 제품 논리 프로세스

공증 메커니즘이 직면한 다양한 위험을 이해하기 전에 제품 관점에서 이러한 유형의 솔루션의 설계 논리를 이해해야 합니다.

(1) 간략한 소개

이 솔루션은 디자인 철학의 관점에서 실제로 매우 간단합니다. 교차 체인 이기종 자산의 요구에 직면할 때 가장 직관적인 솔루션은 실제로 "매핑"입니다. 매핑이란 사용자 A가 이더리움에서 팬텀으로 ETH를 전송하는 것을 의미합니다. 자산을 물리적으로 양도하거나 Fantom에서 재발행할 필요가 없습니다(불가). 대신 사용자 A의 ETH를 이동할 수 없는 주소에 먼저 저장한 다음 이 주소에 저장된 사용자 A의 ETH 양에 따라 Fantom에서 해당 1:1 매핑된 자산을 발행합니다. 매핑된 자산은 원래 이더리움 체인에서 해당 ETH를 사용할 수 있는 권리를 나타냅니다. 1:1 앵커 덕분에 Fantom의 사용자들도 이 자산의 가치를 인식합니다.

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

(2) 디자인의 어려움

이것에 많은 문제가 있을 텐데, 가장 큰 문제는 다중서명 지갑의 관리인데, 이더리움에서 팬텀으로 넘어가는 ETH가 예치금이기 때문에 사용자 A가 크로스백을 원하면 코인을 인출하는 문제가 수반됩니다.

입출금의 탈 중앙화와 보안이 가장 큰 어려움이되었습니다.

1: 누가 돈을 관리할 것인가?

2: 누가 시작할 것인가?

3: 누가 트랜잭션을 모니터링합니까?

4: 실제로 송금하는 사용자가 있는지 확인하는 방법은 무엇입니까?

5: 사용자의 돈이 실제로 사용자가 인출하려는 돈인지 확인하는 방법은 무엇입니까?

6: 재생 공격을 방지하는 방법은 무엇입니까?

7: 실패한 거래를 다시 제출하는 방법은 무엇입니까?

8: 다중 서명 관리자가 악을 행하면 어떻게 됩니까?

9: 가동 중지 시간이 있으면 어떻게 해야 합니까?

감히 생각하지 못하고 생각하면 할수록 더 복잡하게 느껴진다. 크로스 체인 브리지 기술은 다중 서명을 포함할 뿐만 아니라 자산 발행, 크로스 체인 모니터링, 비동기 검증을 포함하며 독립적인 중간 합의 레이어(새로운 체인)를 발행해야 합니다.

따라서 사용자가 이해하기 어려운 부분을 더욱 단순화하기 위해 전체 크로스체인 프로세스를 입금과 출금의 두 부분으로 나누어 설명하겠습니다. 다음에 대해 자세히 알아보려면:

(3) 프로세스의 추가 개선

1: 입금 코인

우선 아래 그림에 그려진 과정은 신중한 논증 없이 저만의 추론한 설계안임을 선언합니다 그 목적은 설계 논리에서 발생할 수 있는 보안 문제를 탐색하는 것이며 확정된 계획으로 채택될 수 없습니다. 모든 헛소리.

그림에서 볼 수 있듯이 원래 체인에서 대상 체인으로의 입금 트랜잭션에는 원칙적으로 다음 단계가 포함됩니다.

(1) 사용자는 호스팅 주소로 충전

(2) 리스너가 트랜잭션을 모니터링한 후 BP(합의 노드는 다중 서명 관리자이기도 함)가 트랜잭션을 시작합니다.

(3) 계약은 BP 서명의 정확성을 확인합니다.

(4) 노드 내결함성 메커니즘이 있는지 여부

(5) 콜백이 없으면 매핑된 주소의 관계에 따라 대상 체인 주소를 충전합니다.

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

(7) Byzantium을 통과한 후 매핑 토큰을 대상 체인의 사용자 주소로 전송

이 과정은 일반적인 이기종 크로스체인을 논의하는 것을 목적으로 하므로 anyswap 및 기타 솔루션과 비교하여 사용자가 중간 합의 레이어에서 주소 관계를 바인딩할 수 있도록 하는 단계를 추가합니다. 이것은 주로 서로 다른 이기종 체인 트랜잭션에 정보를 첨부하는 방식이 다르기 때문입니다.

EVM 체인에서 트랜잭션을 처리하는 경우 이 단계가 필요하지 않으며 트랜잭션을 시작할 때 대상 체인의 주소를 첨부하기만 하면 됩니다.

주제로 돌아가서: 위의 프로세스에서 두 번째 단계부터 다양한 상황에서 다양한 논리 검증 문제와 처리 문제가 발생한다는 것을 알 수 있습니다.

주요 확인 논리에는 다음이 포함됩니다.

(1) 트랜잭션을 들은 후 자산 매핑을 시작하고 사용자 A의 대상 체인으로 전송하는 트랜잭션을 확인합니다.

(2) 대상 체인 거래 개시 및 거래 결과 검증

물론 내 프로세스에서 도출한 검증 로직 외에도 위조 화폐 충전 문제에 대한 검증은 물론 다른 토큰을 호출할 때 수행해야 하는 특수 처리 문제도 포함되어야 합니다. 앞으로 발생할 수 있는 잠재적인 안전 위험을 더 잘 요약하기 위해 코인을 인출하는 과정을 계속 이해해 봅시다.

2: 코인 출금

코인 인출에 의해 입증된 프로세스는 대상 체인 자산을 원래 체인 자산으로 다시 교환하는 논리입니다.현재 많은 토큰이 여러 체인 버전을 가지고 있다는 점에 유의하는 것이 중요합니다. 따라서 일부 브리지 프로젝트는 종종 자산 풀을 설정합니다. 충분한 자금 풀의 경우 사용자는 anyDAI와 같은 매핑된 자산의 존재를 느끼지 않고 대상 체인 버전의 토큰으로 직접 대체하지만 이는 전체 논리에 영향을 미치지 않습니다. 따라서 분석은 계속됩니다.

그림에서 볼 수 있듯이 대상 체인에서 원래 체인으로의 트랜잭션 흐름은 다음과 같습니다.

(1) 사용자가 트랜잭션을 시작합니다(동일한 양의 매핑된 자산을 대상 체인의 에스크로 지갑으로 전송).

(2) BP 신원을 확인하고 BP가 출금 요청을 시작합니다.

(3) 출금 권한 확인 및 서명

(4) Byzantium을 통과한 후 원래 체인에서 코인 출금 요청을 완료하고, 원래 체인의 커스터디 지갑에서 사용자 A에게 자금을 이체합니다.

(5) 중간에 노드 검증 오류나 다운타임이 발생하면 롤백 후 재시도 해야 함

위의 프로세스에서 볼 수 있듯이 여기에 관련된 주요 검증 논리는 다음과 같습니다.

(1) 개시 및 서명 권한 확인

(2) 문제 발생 후 내결함성 메커니즘

(4) 보안 위험

1: 디자인 로직의 보안 문제

교차 체인 브리지의 설계를 보다 자세히 이해한 후 교차 체인 브리지의 설계 논리에 많은 문제가 있음을 알 수 있습니다.요약하면 세 가지 주요 문제가 있습니다(관련 도난 사례는 다음에 표시됩니다. 질문 끝)

(1) 보증금

a) 코인 충전 계약의 권한에 허점이 있어 충전된 금액이 직접 이체됩니다. 이것은 거의 모든 계약 프로젝트에서 접하게 될 어리석은 질문입니다.

b) 위조 통화 충전 문제, 일부 프로젝트는 크로스 체인 토큰의 진위를 확인하지 않아 fakeTOKEN -> realTOKEN(anyswap)이 발생합니다. 솔직히 말해서 이것은 약간 어리석은 일입니다.

c) 위조 화폐 충전 문제, ETH와 같은 고유 자산은 ERC20 계약과 다르고 ETH의 부적절한 취급으로 인해 많은 공격이 발생하여 가짜 ETH -> realETH가 발생하므로 WETH와 같은 래핑된 자산이 인기가 있습니다. . (토르체인)

d) 서로 다른 토큰은 모두 ERC20 표준이지만 구체적인 구현 방법이 다르거나 추가 로직(리베이스, 폴백 등)이 있지만 개발자가 적응할 때 (WETH, PERI 등) 조사를 잘 하지 않았습니다. , OMT , WBNB, MATIC, AVAX) 등은 전송 완료 후 추가 작업을 수행하기 위해 발신자의 사용자 지정 대체 기능을 호출하므로 교차 체인 브리지 판단의 복잡성이 증가합니다(anyswap 2022.1.18).

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

a-chain 입금이 완료된 후 b-chain 자산이 계정에 도착하기 전에 교차 체인 브리지는 일반적으로 dpos를 사용하는 합의 메커니즘을 필요로 하는 독립적인 블록체인 시스템처럼 처리되며 다음은 모두 다음과 같이 가정됩니다. dpos를 사용하는 문제를 고려해야 하지만 모든 노드가 프로젝트 측에 속해 있고 애초에 중앙 집중화의 위험이 있다고 의심됩니다.

a) 코인 입금 메시지를 모니터링하기 위해 누가 가장 먼저 크로스 체인 처리 제안을 무작위로 시작합니까? 아니면 차례대로? 아니면 중간 합의 레이어에서 생성된 블록의 순서에 따라?

b) 여러 공증인이 예금의 정확성을 어떻게 확인합니까 데이터 소스가 모두 infura와 같은 데이터 제공자로부터 온 경우 infura는 단일 위험 지점입니다.가장 안전한 것은 비용이 많이 드는 자체 노드를 유지하는 것입니다.

c) 교차 체인 처리가 완료되었는지 확인하는 방법(b가 계정에 업로드됨) 처리가 완료되지 않은 몇 가지 상황이 있습니다.

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

ii.크로스 체인 브리지가 처리를 시작했지만 검증 및 합의에 실패했습니다.

iii.크로스 체인 브리지의 검증이 통과되었지만 b-chain에서 트랜잭션이 시작되지 않았습니다.

iv. b 체인에 트랜잭션이 있지만 실패합니다(자금 부족 또는 기타 상황).

(3) 다중 서명 검증 문제

문제가 자주 발생하는 가장 어려운 영역, 대부분 코드 논리 문제

a) 3/5 서명, 다중 서명 목록에 없는 서명을 무작위로 구성합니다. 또한 +1(체인스왑)입니다.

b) 명목상 다중 서명인 중앙 집중화 문제는 실제로 프로젝트 당사자의 손에 달려 있으며 이는 중앙 집중화의 큰 위험을 내포합니다.

c) 서명 확인 방법, 서로 다른 체인의 개발 모드가 다르기 때문에 필연적으로 개발자가 도킹할 때 누락될 수 있습니다. 웜홀 예: solana의 확인 서명 기능은 시스템 계약의 기능이며 시스템 계약은 정상적으로 호출되어야 합니다. , 시스템 컨트랙트의 주소는 코드에 하드 코딩되어야 합니다. 여기서 시스템 컨트랙트 주소를 매개 변수로 전달합니다. 해커가 통화를 인출할 때 그는 가짜 시스템 컨트랙트 주소를 전달하여 서명 검증을 우회하고 인출합니다. 원활하게 통화. .

(4) 환불

a) (2)-c에서 논의한 바와 같이 크로스체인 상태에 대한 많은 가능성이 있으며, 어떤 경우에도 사용자에게 환불 방법을 제공해야 합니다. , 그런 다음 대상 체인의 사용자에게 anyToken을 보낸 다음 소스 체인의 anyToken을 소각합니다.이 목적은 문제가 어디에 있든 사용자가 anyToken을 보유함으로써 자신의 자산을 나타낼 수 있다는 것입니다. 이 프로세스에는 3개의 체인(소스, 대상, 교차 체인 브리지)과 4개의 자산(소스 체인 및 대상 체인의 원본 토큰/anyToken)이 있으며 코드 논리 문제가 발생하기 쉽습니다.

b) Thorchain의 취약점은 2021년 7월 23일에 공개되었습니다.해커는 코드 논리 문제를 사용하여 엄청난 양의 가짜 충전을 구성했습니다.크로스 체인 브리지가 이를 처리하지 못하여 환불 로직에 들어가 해커가 막대한 환불하다.

2: 기타 보안 위험

하지만 논리적인 과정을 통해 보여질 수 있는 문제는 비즈니스 로직 문제일 뿐 전부는 아니다.

보안 관점에서 세 가지 다른 위험도 고려해야 합니다.

(1) 시스템 리스크

예를 들어 원래 체인의 입금이 초기에 성공적이었다가 다시 롤백되는 것이 큰 문제입니다 V God이 솔라나에서 이더리움으로 자산을 이전하는 것에 대해 논의했습니다 크로스체인이 완료된 후 솔라나가 롤백합니다 , 그리고 사용자의 자산은 두 배가 될 것입니다.

그러나 이더리움과 보안을 공유하는 롤업과 같은 레이어 2에는 이러한 문제가 없습니다.

(2) 프런트 엔드 위험

a) oxdao.fi 0xdao.fi oxdai.fi 등과 같은 위조된 URL

b) Xss 공격 즉, 크로스 사이트 스크립팅 공격은 www 와 같은 코드 인젝션 공격으로 xss를 방지하기 위해 주의를 기울여야 하며, 이 코드는 페이지에서 실행되어 사용자가 해커의 서명을 인증하도록 합니다. 거래이므로 출처를 알 수 없는 링크를 열지 마십시오.

c) Cors 사이트 간 서비스 공격 엄격한 동일 출처 정책에 따라 브라우저는 이 사이트의 콘텐츠만 로드 할 수 있습니다. . Finance 도메인 이름이지만 현재 대부분의 프로젝트는 교차 사이트 호출을 허용합니다. 즉, xxxx 프런트 엔드는 quickswap 인터페이스를 호출할 수 있고 그 반대의 경우도 마찬가지이므로 개발에 편리함을 제공하지만 위험도 수반합니다.

내가 xxxx.finance를 방문하여 일부 민감한 데이터를 브라우저 캐시에 저장한 다음 악성 웹사이트를 방문하면 xxxx의 동일 출처 정책이 제한되지 않으면 이 악성 웹사이트는 xxxx의 캐시에 저장된 데이터를 자유롭게 얻을 수 있습니다. .

(3) 추가 기능의 위험성

일부 크로스체인 브릿지 프로젝트는 자산 크로스체인을 제공할 뿐만 아니라 크로스체인 계약 호출도 제공하여 추가적인 복잡성을 가져옵니다.

공격자는 a체인에 b체인에 x 컨트랙트 호출을 개시하고 크로스체인 브릿지는 x컨트랙트와 상관없이 직접 호출하는데 의외로 x컨트랙트는 크로스체인 브릿지의 다중서명 컨트랙트이다. b체인에서 다중서명 계정을 공격자 자신의 주소로 변경하는 것으로, 실행 성공 후 해커는 b체인(폴리네트워크)에서 크로스체인 브릿지의 자금을 자유롭게 통제할 수 있다.

셋: 결론

1: 이 보고서의 목적은 사용자가 크로스체인 브릿지의 보안 위험을 더 명확하게 이해하도록 돕는 것이며, 크로스체인 브릿지가 얼마나 취약한 공격을 받는지에 대한 악의적인 렌더링이 아닙니다.

2: 공증 메커니즘의 크로스 체인 브리지 솔루션은 적어도 현재로서는 최고의 경험, 가장 넓은 적용 범위 및 가장 낮은 비용을 가진 솔루션입니다. 그리고 어떤 제품이든 상흔에서 성숙으로 가는 과정을 거치게 되며, 블록체인 제품에 대한 공격은 종종 "논리적 문제"입니다. 이러한 질문은 시간과 경험이 쌓이면 나아질 수밖에 없습니다.