CertiK: 웹3.0을 위한 코스모스 에코 보안의 해체, 별을 향한 여정

출처:CertiK

지난 주, CertiK 팀에서 발행한 코스모스 에코 보안 가이드가 웹3 미디어에 게재되었습니다. 메타 에라에 처음 게재된 후 수많은 미디어 매체에 의해 다시 게시되어 웹3.0 커뮤니티의 광범위한 관심을 받았습니다.

세계에서 가장 크고 잘 알려진 블록체인 생태계 중 하나인 코스모스는 블록체인 상호운용성을 개선하고 서로 다른 블록체인 간의 효율적인 상호운용성을 달성하는 데 초점을 맞추고 있습니다. 셀레스티아와 dYdX v4를 포함한 일련의 주요 프로젝트는 코스모스 SDK와 IBC 프로토콜을 기반으로 구축되었습니다.

코스모스 개발 컴포넌트가 더 많은 개발자들에게 선호됨에 따라 코스모스 생태계의 보안 이슈는 더 큰 영향을 미칠 수밖에 없습니다. 예를 들어, 이전에 발생한 코스모스 SDK의 드래곤프루트 취약점은 여러 주류 퍼블릭 체인의 정상적인 운영에 영향을 미쳤습니다. 코스모스 생태계의 기본 구성 요소의 탈중앙화 특성으로 인해 개발자는 다양한 기능 요구 사항에 따라 다른 구성 요소를 사용하거나 확장해야 하며, 그 결과 코스모스 생태계에서 보안 문제가 탈중앙화되고 다양해졌습니다. 따라서 개발자들이 코스모스 생태계 보안 현황과 대응 방안을 체계적으로 이해할 수 있도록 돕는 연구도 필요합니다.

인증팀은 코스모스 생태계를 구성하는 다양한 요소의 보안 시나리오를 독자가 이해하기 쉬운 카테고리로 분류하여 꼼꼼하게 분석한 '코스모스 생태계 보안 가이드'를 단독으로 발간했습니다. 이 보고서는 코스모스 생태계의 과거 주요 보안 취약점에 대한 분석뿐만 아니라 원인, 결과, 코드 위치 등을 기준으로 일반적인 보안 취약점을 분류하여 코스모스 생태계 개발자에게는 보안 가이드라인을 극대화하고, 보안 감사자에게는 코스모스 보안 문제를 학습하고 감사할 수 있는 색인화된 정보를 제공합니다.

써티케이 팀은 지속적인 연구와 마이닝을 통해 코스모스 및 전체 웹3.0 생태계의 보안을 개선하는 데 기여하고 있습니다. 저희는 정기적으로 모든 종류의 프로젝트 보안 보고서와 기술 연구를 제공할 예정이니 계속 지켜봐 주시기 바랍니다! 궁금한 점이 있으시면 언제든지 문의해 주세요.

다음은 코스모스 에코 보안 가이드 전문입니다.

코스모스 에코 보안 가이드

개요

코스모스는 오픈소스, 개방형, 확장성이 뛰어난 블록체인 크로스체인 네트워크이며, 세계에서 가장 잘 알려진 블록체인 생태계 중 하나입니다. 코스모스는 체인 간 상호 작용을 지원하기 위해 코멧BFT(구 텐더민트 팀)가 출시한 이기종 네트워크로, 여러 개의 독립적인 병렬 블록체인으로 구성되어 탈중앙화된 네트워크를 형성하며, 정보의 사일로 효과를 없애고 서로 다른 블록체인 간의 상호 운용성을 달성하는 것을 비전으로 삼고 있습니다. 현재 멀티체인 시대에서 크로스체인 상호 작용을 달성하는 것은 블록체인 업계에 시급한 과제가 되었습니다.

코스모스는 특정 업종에 초점을 맞춘 퍼블릭 체인에 특히 적합한 효율적인 크로스 체인 모델을 제공합니다. 코스모스는 모듈형 블록체인 인프라를 제공함으로써 다양한 애플리케이션 개발자들이 각자의 필요에 맞는 퍼블릭 체인을 선택해 사용할 수 있도록 지원합니다.

코스모스 생태계의 애플리케이션과 프로토콜은 IBC(블록체인 간 통신 프로토콜)로 연결되어 개별 블록체인 간 상호 작용을 가능하게 하고 자산과 데이터의 흐름을 자유롭게 합니다.
코스모스의 비전은 자율적이고 개발하기 쉬운 수많은 블록체인 간의 확장 및 상호작용 가능성을 제공하는 블록체인의 인터넷을 구축하는 것입니다. 확장 및 상호 작용의 가능성을 제공합니다.

서틱은 오랫동안 코스모스 생태계에 대한 관심과 연구를 지속해왔습니다. 코스모스 생태계 보안 이슈에 대한 충분한 경험을 축적해 왔으며, 이번 연구 보고서에서는 코스모스 SDK 보안, IBC 프로토콜 보안, CometBFT 보안 및 CosmWasm 보안의 네 가지 방향을 중심으로 코스모스 생태계 보안에 대한 탐색과 연구 결과를 소개합니다..

코스모스 생태계의 복잡성과 다양성, 그리고 보안 이슈의 다양성으로 인해 본 연구에서는 모든 유형의 보안 취약점을 다루지는 않으며, 코스모스 생태계에 더 큰 피해를 주는 대표적인 취약점만 살펴봅니다. 다른 보안 문제에 대한 자세한 내용은 CertiK 보안 엔지니어에게 문의하시기 바랍니다.

배경

• CometBFT: 크로스 체인 확장성의 초석

CometBFT는 다음과 같습니다. 혁신적인 합의 알고리즘으로, 두 가지 주요 구성 요소인 기본 합의 엔진(CometBFT Core)과 공통 애플리케이션 블록체인 인터페이스(ABCI)로 구성되어 있습니다. 합의 알고리즘은 하이브리드 PBFT+본드 지분 증명 합의를 사용하여 노드가 트랜잭션을 동기적으로 기록하도록 합니다. 인터체인 확장성의 핵심 구성 요소인 코멧BFT는 검증자 합의를 통해 인터체인 생태계의 보안, 탈중앙화, 무결성을 유지합니다.

• 코스모스 SDK: 모듈화 및 새로운 기능

코스모스 SDK는 개발자가 개발 프로세스를 가속화할 수 있도록 돕는 툴킷입니다.

코스모스 SDK는 모듈성과 플러그성을 제공하여 개발자의 개발 프로세스 가속화를 돕는 툴킷입니다. 코스모스 SDK를 통해 개발자는 코멧BFT 합의 알고리즘을 기반으로 블록체인 또는 기능 구성 요소를 직접 구축할 수 있어 편리한 개발이 가능하고 개발 주기를 단축할 수 있습니다. 이미 크로노스, 카바, 최근 출시된 dYdX V4 등 많은 블록체인 프로젝트에 채택되었습니다. 향후 개발 계획은 모듈화와 새로운 기능 도입에 초점을 맞춰 개발자들이 더 복잡한 모듈형 앱을 만들고 더 광범위하고 강력한 생태계를 조성할 수 있도록 할 것입니다.

• IBC 프로토콜: 향상된 상호 운용성 및 확장성

IBC 프로토콜(블록체인 간 통신)은 블록체인 간에 안전하고 탈중앙화된 허가 없는 데이터 전송을 가능하게 합니다. 블록체인 간 중앙화되고 허가 없는 데이터 전송. 코스모스는 독립적인 병렬 블록체인의 탈중앙화 네트워크이며 릴레이 기술을 사용하여 서로 다른 블록체인 간의 크로스체인을 가능하게 하므로, IBC는 프로젝트의 가장 핵심적인 부분입니다. 인터체인 재단은 현재 확장성과 가용성이라는 두 가지 주제에 집중하고 있습니다. 코스모스는 IBC의 확장성과 상호 운용성을 높여 블록체인, 앱, 스마트 컨트랙트 간의 원활한 상호작용을 가능하게 하는 생태계의 역량을 더욱 강화할 것입니다.

• 코스왐: 탈중앙화, 라이선스 없는 배포

코스왐(코스모스 웹어셈블리 )는 코스모스 생태계를 위해 설계된 웹어셈블리 기반 스마트 컨트랙트 프레임워크입니다. 개발자는 라이선스 요구 사항 없이 탈중앙화 애플리케이션을 배포할 수 있으며, 블록체인 개발자가 제품 개발 주기를 블록체인 개발과 분리하여 검증자 업그레이드 비용을 절감할 수 있습니다. 이 외에도 모듈형 아키텍처, 코스모스 SDK 통합, 크로스체인 통신 등이 특징입니다.

현재 코스모스 SDK, IBC 프로토콜은 비교적 성숙도가 높으며 현재 코스모스 생태계에서 가장 널리 사용되고 있습니다.

체인 개발자의 관점에서 볼 때, 코스모스 생태계에서 요구하는 대부분의 커스터마이징은 코스모스 SDK에 의존하여 수행할 수 있지만, 크로스 체인 운영 과정에서 일부 특수한 작업을 실현하거나 성능을 최적화하기 위해 체인 개발자는 자체 IBC 모듈을 커스터마이징하고, 소수의 체인은 자체 IBC 모듈을 커스터마이징하며, 이 외에도 소수의 체인은 자체 IBC 모듈을 커스터마이징할 것입니다. 또한 소수의 체인이 CometBFT Core와 같은 기본 엔진을 수정하고 커스터마이징할 것이지만, 지면 관계상 본 연구 보고서에서는 다루지 않습니다. 본 연구 보고서는 코스모스 SDK와 IBC 프로토콜의 기술적 포인트와 보안 문제를 분석하는 데 초점을 맞출 것입니다.

코스모스 SDK 보안 가이드

코스모스 SDK는 블록체인 애플리케이션과 탈중앙화 프로토콜을 구축하기 위한 강력하고 유연한 프레임워크입니다. 인터체인 재단에서 개발했으며, 상호 연결된 블록체인의 탈중앙화 네트워크인 코스모스 네트워크의 핵심 구성 요소입니다.

코스모스 SDK는 맞춤형 블록체인 애플리케이션 개발을 간소화하고 서로 다른 블록체인 간의 원활한 상호운용성을 구현하기 위해 설계되었으며, 다음과 같은 주요 특징을 가지고 있습니다: 모듈형 아키텍처, 커스터마이징 가능성, 코멧BFT 기반, IBC 통신 인터페이스 구현, 개발자 친화적.

.코스모스 SDK는 코멧BFT 코어 기반 합의 엔진을 활용하여 악의적인 공격으로부터 네트워크를 보호하고 사용자의 자산과 데이터를 보호함으로써 강력한 보안을 보장합니다. 또한 모듈화되어 있어 사용자가 맞춤형 모듈을 쉽게 설계할 수 있습니다. 이러한 장점에도 불구하고 개발자가 코스모스 SDK를 사용하여 자체 애플리케이션을 구현할 때 보안 취약점이 여전히 존재할 수 있습니다.

보안 감사 관점에서는 감사 목표를 철저히 하고 모든 보안 위험을 다각도로 고려해야 하지만, 보안 리서치 관점에서는 큰 영향을 미칠 수 있는 보안 취약점에 집중하여 단기간에 가장 큰 보안 위험을 최대한 피하고 통합 서비스 제공업체에 보다 효과적인 도움을 제공할 수 있어야 합니다. 이러한 관점에서 고위험, 고영향 취약점에 대한 취약점 모델을 분류하고 분석하는 것은 매우 필요하고 가치 있는 작업입니다.

코스모스 에코시스템의 ABCI 인터페이스 중 BeginBlock, EndBlock, CheckTx, DeliverTx의 네 가지 인터페이스에 집중합니다. 앞의 두 개는 단일 블록의 실행 로직과 직접 관련이 있고, 뒤의 두 개는 sdk.Msg(메시지 전송을 위한 코스모스 에코시스템의 기반이 되는 데이터 구조) 특정 처리와 관련이 있습니다.

코스모스 생태계의 다양한 애플리케이션 체인의 구현 로직은 코스모스 SDK의 모듈과 샘플을 따라갈 수 있으므로, 아래의 보안 취약점을 분석하고 이해할 때 코스모스 SDK의 모듈 런타임 흐름에 대한 기본 개념이 필요합니다.

코스모스 생태계에서 트랜잭션은 처음에 사용자 에이전트에서 생성된 다음 서명되어 블록체인 내 노드에 브로드캐스트됩니다. 노드는 서명, 발신자의 잔액, 거래 순서, 제공된 연료 등 다양한 거래 세부 정보를 검증하기 위해 CheckTx 방식을 사용합니다. 트랜잭션이 검증을 통과하면 메모리 풀에 추가되어 블록에 포함되기를 기다립니다. 또는 트랜잭션이 검증을 통과하지 못하면 사용자에게 오류 메시지가 전송되어 트랜잭션이 거부됩니다. 블록이 실행되는 동안 트랜잭션에 대한 추가 검사가 수행되며, 이는 일관성과 확실성을 보장하기 위해 DeliverTx 메서드를 통해 수행됩니다.

코스모스 SDK에서 트랜잭션의 라이프사이클은 다음과 같은 흐름으로 간략하게 설명할 수 있습니다.

1. 트랜잭션 생성: 트랜잭션은 클라이언트 측에서 다양한 도구, CLI를 사용하거나 프론트엔드에서 생성됩니다.

2. 메모리 풀에 추가: 트랜잭션은 메모리 풀에 추가되며, 노드는 유효성을 검사하기 위해 ABCI 메시지-CheckTx를 애플리케이션 레이어에 전송하고 그 결과 abci.ResponseCheckTx를 받습니다.CheckTx에서 트랜잭션은 바이트 형식에서 Tx 형식으로 디코딩된 다음, 메모리 풀의 ValidateBasic()이 Tx의 각 sdk.Msg에 대해 호출되어 초기 상태 비저장 유효성 검사를 수행합니다. 애플리케이션에 해당 anteHandler가 존재하면 먼저 내부 로직을 실행한 다음 runTx 함수를 호출하고, 이 함수는 결국 RunMsgs() 함수를 호출하여 sdk.Msg의 특정 내용을 처리합니다. CheckTx가 성공하면 메시지가 다음 블록의 후보로 로컬 메모리 풀에 추가되고 P2P를 통해 피어 피어 노드에 브로드캐스트됩니다.

3. 제안 블록에 포함된 내용: 각 라운드가 시작될 때마다 제안자는 최신 트랜잭션이 포함된 블록을 생성하고, 마지막으로 노드 간 합의를 담당하는 검증자가 블록 수락에 동의하거나 빈 블록에 투표합니다.

4. 상태 변경: DeliverTx는 CheckTx와 유사하게 블록의 트랜잭션을 반복하기 위해 호출되지만, Deliver 모드에서 runTx를 호출하고 상태 변경을 수행합니다.MsgServiceRouter는 트랜잭션의 여러 메시지를 다른 모듈로 라우팅하기 위해 호출됩니다. 로 라우팅한 다음 메시지 서버에서 각각의 해당 메시지를 실행합니다. 그런 다음 메시지를 실행한 후 검사를 실행하고 실패가 발생하면 상태를 복원합니다. 실행 중에 가스 미터는 연료(가스) 사용량을 추적하는 데 사용됩니다. 연료 오류(예: 연료 부족)가 발생하면 실행 실패 후와 동일한 결과로 상태가 되돌아갑니다.

5. 블록 제출: 노드가 충분한 검증자 투표를 받으면 블록체인에 추가할 새 블록을 제출하고 애플리케이션 레이어에서 상태 전환을 마무리합니다.

생태계에서의 코스모스 트랜잭션 라이프사이클 다이어그램

다음은 아래 취약점 트리거 경로를 분석할 때 쉽게 접근하고 이해할 수 있는 코스모스 SDK의 구체적인 실행 로직입니다.

ABCI에 초점을 맞춘 코스모스 SDK의 구체적인 실행 로직

일반적인 취약점 분류

취약점 분류를 이해하기 전에 취약점 위험도에 대한 기본적인 분류가 있어야 위험한 보안 허점을 더 잘 식별하고 잠재적인 보안 위험을 최대한 피할 수 있습니다.

위험의 정도와 영향의 범위를 고려하여 일반적으로 다음과 같은 위험을 초래할 수 있는 중요 및 주요 등급 보안 취약점에 중점을 둡니다.

1. 체인 중단

2. 자금 손실

3. 시스템 상태 또는 정상 작동에 미치는 영향

그리고 이러한 위험은 종종 다음과 같은 유형의 보안 취약점으로 인해 발생합니다:

1. 서비스 거부

2. 잘못된 상태 설정

3. 누락되거나 믿을 수 없는 인증

4. 고유성 문제

5. 합의 알고리즘 문제

6. 구현의 논리 구멍

7. 언어 기능

취약점 분석

코스모스 생태계의 모듈성으로 인해 모든 종류의 체인 구현에서 모듈 간 사용과 모듈 내 호출이 많이 발생합니다.

코스모스 생태계의 모듈성으로 인해 모듈 간 및 모듈 내 호출이 많기 때문에 취약점 트리거 경로와 취약점 트리거 위치 변수 제어 가능 경로가 일치하지 않으므로 취약점 트리거를 분석할 때 트리거 경로에만 집중할 것이 아니라 취약점 핵심 변수 제어 가능 경로에도 주의를 기울여야 취약점 모델의 정의를 더 잘 설명하는 데 도움이 될 수 있습니다.

• 체인 중단

체인 중단은 대부분 개별 블록 실행 문제로 인해 발생하지만, 코스모스 역사상 체인 중단으로 이어진 합의 보안 취약점도 있었습니다. 그러나 코스모스 역사상 체인을 자발적으로 중단시켜 문제를 해결해야 했던 합의 보안 취약점도 있었기 때문에 여기서는 체인을 중단시키는 합의형 보안 취약점의 영향에 대해 논의하고, 이 두 가지 유형의 문제를 각각 따로따로 이야기하겠습니다.

첫 번째 유형의 상황은 일반적으로 서비스 거부 유형의 취약점으로, 사용자가 영향을 받을 수 있는 부적절한 크래시 처리 및 루프 경계 통과로 인해 발생합니다. 이러한 유형의 취약점으로 인해 체인이 일시 정지되거나 작동 속도가 느려지는 등의 문제가 발생합니다.

이전 섹션에서 언급했듯이 코스모스 생태계의 핵심 인프라인 코스모스 SDK와 코멧BFT는 코스모스의 기본 체인뿐만 아니라 모든 종류의 애플리케이션 체인이 아키텍처를 기반으로 자체 로직을 구현하는 데 사용되므로 모두 코멧BFT의 ABCI 인터페이스 규칙을 따르며, 공격 표면의 초점은 ABCI 인터페이스에 맞춰져 있습니다. , 대부분의 체인 정지 보안 취약점은 블록 코드 실행에 직접적인 영향을 줄 수 있는 문제이기 때문에 기본적으로 경로를 추적할 수 있는 것은 BeginBlock과 EndBlock 인터페이스입니다.

두 번째 유형의 취약점은 합의에 영향을 미치는 취약점으로, 일반적으로 다양한 유형의 체인 구현과 관련이 있으며 현재 일부 로직 처리 검증, 시간 보정 및 무작위성 문제에서 흔히 발생하는 것으로 알려져 있습니다. 이러한 유형의 취약점은 본질적으로 블록체인의 탈중앙화 원칙에 영향을 미치며, 직관적으로는 큰 영향을 미치지 않는 것처럼 보이지만 악의적인 의도를 가진 누군가가 악의적으로 설계할 경우 심각한 보안 위험을 초래할 수 있습니다.

첫 번째 시나리오

• 사례 1: 슈퍼노바

취약점 발생 배경: 발행 배포 작업에서 주소 검증이 부족합니다. 코인 발행 배포 작업에서 주소 유효성 검사가 부족하면 작업 실패 및 자금 손실로 이어집니다. 채굴 모듈에서 각 토큰의 채굴은 담보 금액에 따라 달라집니다. 그런데 풀이 존재하지 않거나 컨트랙트 주소가 잘못 입력되면 발행 모듈에서 예기치 못한 상황이 발생하여 블록체인의 작동이 중단될 수 있습니다. 보상 풀 모듈에서는 풀 컨트랙트 주소가 확인되지 않습니다. 분배 작업이 실패하면 체인은 단순히 작동을 멈추게 됩니다.

취약점 위치: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/ keeper/keeper.go#L175

취약 코드 스니펫:

취약점 트리거 경로:

BeginBlocker (/x/mint/keeper/abci.go)   Keeper.DistributeMintedCoin    Keeper. Keeper.distributeLPIncentivePools    Keeper.distributeLPIncentivePools      Keeper. 
(/x/mint/keeper/keeper.go)

취약점 패치:
 https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0
패치는 풀인센티브의 메시지 처리 모듈(x/poolincentive /types/msgs.go)에 있으며, 민트 모듈이 아닙니다. 
MsgCreateCandidatePool을 처리하는 메시지(즉, 풀을 생성하는 메시지)에 주소 체크섬을 수행하는 것은 루트에서 잘못된 주소가 발생할 가능성을 제거하기 위한 시도입니다. 
사례 2: 코스모스 인터체인 보안 프로젝트
프로젝트 주소: https://github. com/cosmos/interchain-security
취약점 배경: 인증자는 동일한 블록에 여러 개의 AssignConsumerKey 메시지를 제출하여 프로비저닝 체인을 느리게 할 수 있습니다. x/ccv/provider/keeper/key_assignment.go에 정의된 AssignConsumerKey 함수를 사용하면 인증자는 승인된 소비자 체인에 다른 소비자 키를 할당할 수 있습니다. 이 작업을 수행하기 위해 consumerAddrsToPrune AddressList가 하나의 요소로 증가합니다. 이 주소 목록은 x/ccv/provider/keeper/relay.go의 엔드블로커에서 탐색되므로 공격자는 이를 사용하여 프로비저닝 체인을 느리게 할 수 있습니다. 이 공격을 수행하기 위해 악의적인 공격자는 여러 개의 AssignConsumerKey 메시지로 트랜잭션을 생성하고 이러한 트랜잭션을 공급자 체인으로 보낼 수 있습니다. consumerAddrsToPrune AddressList는 전송된 AssignConsumerKey 메시지와 동일한 베이스를 갖습니다. 결과적으로 엔드 블로커 실행에 예상보다 많은 시간과 리소스가 소요되어 공급자 체인이 느리게 실행되거나 심지어 중지될 수 있습니다. 
취약점 위치: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ ccv/provider/keeper/key_assignment.go#L378
취약 코드 스니펫:
취약점 트리거 경로:
msgServer.AssignConsumerKey    Keep Keeper.AssignConsumerKeyAppModule.EndBlock       핸들리딩VSC숙성패키지    핸들링 핸들VSC숙성패키지 & 핸들리딩VSC숙성패키지 & 핸들리딩VSC 숙성패키지   PruneKeyAssignments

사례 연구 3: 퀵실버 프로젝트 - 에어드롭 모듈
취약점 발생 배경: BeginBlocker와 EndBlocker는 모듈 개발자가 모듈에 구현할 수 있는 선택적 메서드입니다. 이 메서드는 각각 각 블록의 시작과 끝에서 트리거됩니다. BeginBlock 및 EndBlock 메서드에서 오류를 처리하기 위해 크래시를 사용하면 오류 발생 시 체인이 중지될 수 있으며, EndBlocker는 모듈에 충분한 토큰이 있는지 고려하지 않고 미완성 에어드랍을 청산하여 크래시 가능성을 유발하여 체인이 작동을 멈추게 할 수 있습니다. 
취약점 위치: https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d↪CF_200D↩ 60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15
취약점 코드 스니펫:
취약점 트리거 경로:
AppModule.EndBlock    Keeper .EndBlocker     Keeper.EndZoneDrop

취약점 패치: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/ keeper/abci.go#L16
패닉 처리 코드를 직접 제거하고 오류 로깅으로 대체했습니다. 
사례 4: 코스모스 인터체인 보안 프로젝트
프로젝트 주소: https://github.com/ 코스모스/인터체인 보안
취약점 배경: 공격자는 여러 개의 토큰을 공급자 체인의 보상 주소로 전송하여 서비스 거부 공격을 수행할 수 있습니다. 
소비자 체인의 엔드 블로커 실행 흐름에서 x/ccv/consumer/keeper/distribution.go에 정의된 SendRewardsToProvider 함수는 tstProviderAddr에 있는 모든 토큰의 잔액을 가져와서 공급자 체인으로 보냅니다. 이를 위해서는 보상 주소에서 찾은 모든 토큰을 반복하여 IBC를 통해 공급자 체인으로 하나씩 보내야 합니다. 누구나 보상 주소로 토큰을 보낼 수 있기 때문에 공격자는 토큰 팩토리 모듈이 있는 체인을 사용하는 등 다양한 액면가의 토큰을 대량으로 생성하고 전송하여 서비스 거부 공격을 시작할 수 있습니다. 그 결과, 엔드블로커 실행에 예상보다 많은 시간과 리소스가 소요되어 소비자 체인이 느리게 실행되거나 심지어 멈출 수도 있습니다. 
취약점 위치: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ ccv/consumer/keeper/distribution.go#L103
취약점 코드 스니펫:
취약점 트리거 경로:
< pre>AppModule.EndBlock    EndBlock  EndBlockRD EndBlockRD EndBlockRD  EndBlockRD                        ; 

두 번째 유형의 상황

이러한 유형의 합의 문제는 직관적으로 심각한 피해를 가져오지는 않을 수 있지만, 시스템 원칙의 전체 블록체인 본질에서 고려하거나 취약점을 살펴보기 위한 특정 시나리오에서 볼 때 다음과 같습니다. 그러나 이러한 취약점을 블록체인의 기본 원칙과 시스템의 관점에서 보거나 특정 시나리오의 관점에서 보면 이러한 취약점이 가져오는 영향과 피해가 반드시 다른 기존 취약점보다 적은 것은 아닙니다.

• 사례 1

취약점 배경: 코스모스 SDK 보안 권고 잭푸르트

코스모스 SDK의 x/authz 모듈에서 ValidateBasic 메서드의 비결정적 동작으로 인해 합의가 중단될 수 있습니다. x/authz 모듈의 MsgGrant 메시지 구조에는 부여된 사용자 정의 권한의 만료 시간이 포함된 Grant 필드가 포함되어 있습니다. Grant 구조의 유효성 검사 처리에서 블록 시간 정보 대신 해당 시간 정보를 노드의 현지 시간 정보와 비교하면 현지 시간이 비결정적이고 개별 노드의 타임스탬프가 다를 수 있기 때문에 합의 문제가 발생할 수 있습니다.

취약점 발표:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319

https. //forum.cosmos.network/t/cosmos-sdk-vulnerability-retrospective-security-advisory-jackfruit-october-12-2021/5349

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2

취약점 코드 스니펫:

취약점 패치:

https://github.com/cosmos/cosmos-sdk/compare/v0.44.1... .v0.44.2

이번 타임스탬프와 관련된 문제는 코스모스 SDK와 같은 기본 컴포넌트에서만 발생하는 것이 아니라 다양한 애플리케이션 체인에서 유사한 취약점이 발견되고 있습니다.

• 사례 2

취약점 배경: SuperNova, nova 프로젝트

프로젝트 주소: https://github.com/Carina-labs/nova/tree/v0.6.3

time.Now()를 사용하면 운영 체제의 타임스탬프를 반환합니다. 현지 시간은 주관적이므로 비결정적입니다. 개별 노드의 타임스탬프에 약간의 차이가 있을 수 있으므로 체인이 합의에 도달하지 못할 수도 있습니다. ICAControl 모듈에서 트랜잭션 전송 함수는 time.Now()를 사용하여 타임스탬프를 가져옵니다.

취약점 위치: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol /keeper/send_msgs.go#L14

취약점 코드 스니펫:

이미지 src="https://img.jinse.cn/7158705_image3.png">

취약점 패치:

로컬 타임스탬프의 사용을 block time.

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.. IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)) timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err =  k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp ))

• 사례 3

취약점 배경: 밴드체인 프로젝트의 Prophecy Machine 모듈

프로젝트 주소: https://github.com/bandprotocol/bandchain/

코드베이스의 주석에 따르면 Prophecy Machine 프로토콜 위반자에 대한 처벌을 활성화하기 위해 서약 전에 Prophecy Machine 모듈을 실행해야 합니다. 코드에서 이런 일이 발생하는 순서는 다음과 같습니다: SetOrderEndBlockers 함수에서, 서약 모듈은 술어 기계 모듈보다 먼저 실행됩니다. Pledge 모듈이 Predictor 모듈보다 먼저 실행되면, Predictor 모듈에서 수행한 검증에 따라 검증자를 처벌하는 등의 작업을 구현할 수 없게 됩니다.

취약점 위치: https://github.com/LeastAuthority/bandchain/blob/master/chain/app/app.go#L221-L225

취약점 코드 스니펫:

취약점별 구현과 취약점 코멘트가 완전히 뒤바뀌어 있으며, 예언 기계 모듈이 서약 모듈보다 앞에 와야 한다는 것을 알 수 있습니다.

• 사례 4

취약점 배경: 세이 코스모스 프로젝트의 접근 제어 모듈

프로젝트 주소: https://github.com/sei-protocol/sei-cosmos

다양한 코스모스 코드베이스의 여러 인스턴스에서, go map 반복은 모두 go 언어의 지도 유형을 사용하고 그 위에 반복했습니다. go 언어 맵의 반복은 비결정적이기 때문에 노드가 서로 다른 상태에 도달하게 되고, 이로 인해 합의 문제가 발생하여 체인의 실행이 중지될 수 있습니다. 이 문제를 처리하는 더 적절한 방법은 매핑된 키를 슬라이스로 정렬하고 정렬된 키에 대해 반복하는 것입니다. 이러한 유형의 문제는 보다 일반적이며 언어 기능으로 인해 발생하는 문제입니다.

x/accesscontrol/keeper/keeper.go의 BuildDependencyDag 구현에서 노드는 anteDepSet을 반복합니다. Go에서 매핑 반복의 비결정적 동작으로 인해. ValidateAccessOp은 두 가지 유형의 오류를 발생시킬 수 있으며, 이로 인해 합의가 실패할 수 있습니다.

취약점 위치: https://github.com/sei-protocol/sei-cosmos/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/ accesscontrol/keeper/keeper.go#L314C9-L314C9

취약 코드 스니펫:

이러한 경우를 기준으로 다음과 같은 경우가 발생할 수 있습니다. 체인이 수동적으로 동작을 멈추게 하는 취약점이 가장 큰 피해를 주는 경향이 있으며, 그 원인의 논리적 관계를 블록체인 내 개별 블록의 동작에 직접적인 영향을 미치는 실행 과정으로 거슬러 올라갈 수 있다는 것을 알 수 있습니다. 반면, 합의 보안 취약점은 체인이 취약점을 수정하기 위해 적극적으로 셧다운되는 경우가 많으며, 취약점의 원인을 블록체인 전체의 프로세스와 상태로 추적할 수 있습니다. 다음에 설명할 자금 손실 유형의 취약점과 달리, 자금 손실 유형의 취약점은 일반적으로 문제의 논리적 경로를 기반으로 특정 위험의 영향 정도를 판단하기보다는 자금의 소유자, 자금의 양, 자금의 영향 범위, 자금에 영향을 미치는 방식 등에 더 많은 관심을 기울입니다.

• 자금 손실

자금 손실 유형의 문제는 일반적으로 sdk.Msg 및 IBC 메시지의 논리적 처리에서 발견됩니다. 물론 체인의 실행을 중단시킬 수 있는 취약점도 존재하며, 구체적인 영향은 취약점에 따라 다르므로 여기서는 전자를 중심으로 살펴보기로 하겠습니다. 또한 IBC는 코스모스 생태계에서 매우 중요한 부분이기 때문에 IBC의 취약점도 일부 포함될 수밖에 없는데, IBC에 대한 구체적인 공격과 이에 대응하는 취약점은 다음 장에서 살펴보기로 하겠습니다.

자금 손실은 일반적으로 가스 소비, 자금이 잠겨서 인출할 수 없는 상황, 전송 중 자금 손실, 계산 로직 오류로 인한 자금 손실, 자금 ID 저장 시 고유성이 보장되지 않는 논리적인 상황에서 나타납니다.

여기서는 슈퍼노바 프로젝트를 예로 들어 이와 관련된 세 가지 취약점을 분석해 보겠습니다.

• 취약점 발생 배경: SuperNova 프로젝트

프로젝트 주소: https:// github.com/Carina-labs/nova

영역(구역)이 소수점 이하 18자리를 초과하는 경우 자금이 잠길 수 있습니다. 이 프로젝트의 코드에서는 구역의 소수점 이하 자릿수에 대한 상한선이 없으며, 18을 초과할 수 있습니다. 사용자가 자신의 지분 토큰을 청구하고자 할 때 ClaimSnMessage에서 ClaimShareToken이 사용되는데, 구역의 소수점이 18보다 크면 변환이 실패하고 시스템에서 자산을 인출할 수 없습니다. 따라서 영역 소수점을 제어하여 트랜잭션 실패를 직접 트리거할 수 있습니다.

취약점 위치: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

취약점 코드 스니펫:

취약점 트리거 경로:

msgServer.ClaimSnAsset    Keeper.ClaimShareToken   Keeper. Keeper.ConvertWAssetToSnAssetDecimal     Keeper.     정밀배수

• 취약성 컨텍스트: 슈퍼노바 프로젝트
  

프로젝트 주소: https://github.com/Carina-labs/nova/

이 지역의 고유성이 확인되지 않습니다. 등록된 지역에서는 각 지역마다 고유해야 하는 지역 ID를 사용하여 BaseDenom의 고유성을 확인하며, BaseDenom의 값이 잘못 설정된 경우 자금 손실이 발생할 수 있습니다. 이 프로젝트는 RegisterZone에서 기본 토큰을 설정하기 전에 모든 주요 영역에서 BaseDenom이 고유한지 확인하지 않았습니다. 그렇지 않으면 사용자가 동일한 이름의 BaseDenom을 포함하는 다른 악성 영역에 자금을 저장할 가능성이 있으며, 이로 인해 자금 손실이 발생할 수 있습니다.

익스플로잇 위치: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

익스플로잇 코드 스니펫:

취약점 패치: DenomDuplicateCheck 추가

위와 같이 체인 실행이 중단되는 경우 외에도 첫 번째 시나리오 중 하나는 크래시로 인한 발행 실패와 자금 손실입니다. 의 한 형태입니다.

• 취약점 발생 배경: 슈퍼노바 프로젝트

프로젝트 주소: https://github.com/Carina-labs/. nova/

상태 업데이트가 누락되었습니다. IcaWithdraw() 메서드에서 트랜잭션이 실패하고 버전 상태가 수정되지 않으면 WithdrawRecord에 액세스할 수 없게 되고 해당 자금이 인출되지 않습니다. 보다 일반적인 이해는 SendTx 이전에 상태가 설정되고 실패 후에도 상태가 수정되지 않아 자금 인출이 실패하고 다음에 다시 인출할 수 없다는 것입니다.

취약점 위치: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper /msg_server.go#L356

취약점 코드 스니펫:

이 부분의 사례를 바탕으로 자금과 관련된 연산 로직의 주요 구현 또는 다양한 유형의 메시지 처리에 따라, 물론 연산 발행과 관련된 BeginBlock의 프로세스 구현에서 첫 번째 유형의 상황과 같은 경우도 존재하며 이러한 연산이 실패하여 자금 손실로 이어지는 경우도 있음을 알 수 있습니다. 전반적으로 채굴 작업과 관련된 코드 모듈에 감사를 집중함으로써 이러한 취약점을 발견할 가능성을 크게 높일 수 있습니다.

• 시스템 상태 또는 정상 작동에 영향

이 유형의 문제는 범위가 더 넓으며, 방금 논의한 처음 두 가지 위험은 시스템 상태 또는 정상 작동에 영향을 미치는 취약성 유형의 하위 집합으로 간주할 수 있습니다. 취약점 유형의 하위 집합입니다. 또한, 보다 논리적 유형의 취약점의 위험이 더 큰 , 이러한 유형의 취약점은 프로젝트의 비즈니스 로직과 다양한 보안 위험에 따라 크게 달라지지만, 코스모스 SDK 구성 요소의 유사성과 특정 코드의 특성을 구현하는 모듈성으로 인해 종종 유사한 실수를 할 수 있으므로 다음 목록을 제공하고자 합니다. 일반적인 취약점 :

sdk.Msg 타입의 불완전한 변수 검사

프로젝트에서 sdk.Msg를 기반으로 다양한 파생 타입을 구현했기 때문에, Cosmos SDK가 기존 타입의 모든 요소를 감지하지 못해 일부 주요 내장 변수가 누락될 수 있습니다. 그러나 코스모스 SDK는 기존 타입의 모든 요소를 감지하지 못하여 일부 주요 임베디드 변수가 누락되어 보안 위험이 발생할 수 있습니다. 왼쪽;">취약점 배경: MsgCreatePeriodicVestingAccount.ValidateBasic 유효성 검사 메커니즘에 활성 상태와 같은 계정 상태에 대한 판단이 누락되어 있습니다. 공격자는 x/auth에 정의된 PeriodicVestingAccount를 사용하여 피해자의 계정을 입금은 가능하지만 인출은 불가능한 악성 어트리뷰션 계정으로 초기화할 수 있습니다. 사용자가 해당 계정에 자금을 입금하면 해당 자금은 영구적으로 잠기며 사용자가 인출할 수 없습니다.

취약점 패치:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https ://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0... .v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

익스플로잇 코드 스니펫:

이 외에도 코스모스-SDK 보안 권고 엘더플라워, 코스모스-SDK 보안권고 잭프루트(Jackfruit)는 실제로 ValidateBasic 체인의 문제이며, 전자는 ValidateBasic에 대한 호출이 직접 누락된 것이고, 후자는 타임스탬프 변수 체크섬에 대한 메시지 내부의 문제입니다. 이러한 문제는 애플리케이션 체인에서 훨씬 더 흔하게 발생하며, 이더민트, pstake-native, 퀵실버 등의 프로젝트에서도 메시지를 처리하는 데 사용되는 검증 조치에 유사한 보안 허점이 있습니다.

검증 유형 외에도 sdk.Msg의 처리 로직에는 대량의 가스 소비, 불합리한 크래시 처리 등을 포함하는 루프가 있으며, 이는 메시지 처리 체인의 복구 메커니즘으로 인해 체인 정지보다는 덜 위험하지만 여전히 시스템의 정상적인 작동에 영향을 미치거나 체인의 자금 손실로 이어질 수 있습니다. 체인의 자금 손실.

일반적인 취약점 유형

프로젝트 비즈니스에 특화된 보안 취약점 외에도 메시지를 보내기 전에 상태가 변경되는 경우 3의 자금 손실과 같은 몇 가지 일반적인 취약점 모델이 있으며, 이러한 유형의 취약점은 자금을 전송하기 전에 자체 상태를 변경하여 종종 재진입과 같은 문제를 일으키는 스마트 계약의 취약점과 매우 유사합니다. 이러한 유형의 취약점은 자금을 전송하기 전에 상태가 변경되어 종종 재입력 또는 레거시 오류 상태와 같은 문제를 일으키는 스마트 콘트랙트의 취약점과 매우 유사합니다. 이와 같이 상태 설정과 메시지 전송이 밀접하게 결합된 시나리오는 실제로 블록체인에서 매우 흔하며, 큰 위험을 초래하는 많은 취약점이 이러한 문제에서 비롯됩니다. 이 외에도 제로화 취약점, 가스 소비 우회, 취약한 버전 사용과 유사한 전산 보안 취약점도 있으며, 모두 시스템 상태 또는 시스템의 정상적인 작동에 영향을 미칠 수 있습니다.

유일성 문제

블록체인에는 수많은 조회-읽기-저장 작업이 포함되므로 특정 기능 구현에서 명명 고유성은 매우 중요합니다. 예를 들어, 앞선 자금 손실 사례에서 고유성 문제는 키와 같은 중요한 요소를 나타내는 일부 문자열 또는 바이트 배열 유형 변수 외에도 각 명명 끝에 "/"가 존재하는 등 접두사 구성에 약간의 위험이 있는 경우 사소한 부주의로 인해 문자열의 명명이 다른 의미로 위조될 수 있으며 이는 일련의 자금 손실 및 합의 오류와 같은 문제가 발생할 수 있습니다.

언어 기능의 문제

이러한 유형의 문제는 좀 더 광범위하지만 특징적이어서 발견하기 쉬운데, 예를 들어 골랑의 맵 반복 문제, 러스트의 일부 패닉 메커니즘 등이 있습니다. 해당 언어를 사용하기 전에 언어 기능 자체가 위험을 초래할 수 있는 지점을 나열해 두는 것을 권장합니다. 해당 언어를 사용하기 전에 해당 위험을 초래할 수 있는 포인트를 나열한 다음, 해당 언어를 사용하거나 감사할 때 개별적으로 주의를 기울여 이러한 오류를 최대한 방지하는 것이 좋습니다.

요약

코스모스 생태계의 근본적인 보안 문제를 살펴본 결과, 이러한 문제가 코스모스 생태계에만 적용되는 것이 아니라 다른 생태계에도 적용될 수 있는 취약점 모델이 많다는 것을 어렵지 않게 발견할 수 있었습니다. 권고사항 및 요약:

인프라 취약점에 집중: CometBFT와 Cosmos SDK의 핵심 구성 요소도 취약할 수 있으므로 보안을 위해 정기적으로 업데이트하고 유지 관리해야 합니다.

서드파티 라이브러리의 적시 검토: 코스모스 개발자는 애플리케이션의 기능을 확장하기 위해 타사 라이브러리를 사용하는 경우가 많습니다. 그러나 이러한 라이브러리에는 잠재적인 취약점이 있을 수 있으므로 위험을 완화하기 위해 검토하고 업데이트해야 합니다.

악성 노드 공격 주의: 코스모스 생태계에서 합의 노드는 네트워크의 핵심 구성 요소입니다. 노드의 비잔틴 장애 허용 알고리즘은 공격을 받을 수 있으므로 노드를 보호하여 나쁜 행동을 방지해야 합니다.

물리적 보안에 주의: 무단 접근과 잠재적 공격을 방지하기 위해 코스모스 노드를 실행하는 하드웨어와 서버에 물리적 보안 조치가 필요합니다.

코드 검토 필요: 코스모스 SDK와 CometBFT 에코시스템의 개방적인 특성으로 인해 개발자와 검토자는 핵심 코드와 사용자 지정 모듈에서 작성된 코드를 검토하여 잠재적인 보안 문제를 식별하고 수정해야 합니다.

생태계 도구를 주의 깊게 살펴보세요: 코스모스 생태계에는 보안을 위해 보안 검토와 정기적인 업데이트가 필요한 여러 도구와 애플리케이션이 포함되어 있습니다.

IBC 프로토콜 보안 가이드

이 모듈은 코스모스에서 매우 중요한 부분인 IBC 프로토콜(블록체인 간 통신 프로토콜)과 관련된 보안 이슈에 초점을 맞춥니다. IBC는 이기종 블록체인이 신뢰할 수 있고, 질서정연하며, 신뢰를 최소화하는 방식으로 모든 데이터를 전송할 수 있도록 하는 프로토콜입니다. 모든 데이터를 위한 프로토콜입니다.

비트코인 도입 이후 블록체인 분야는 폭발적인 성장을 거듭했습니다. 수많은 새로운 네트워크가 생겨났고, 각 네트워크는 고유한 가치 제안, 합의 메커니즘, 이념, 구성원과 존재 이유를 가지고 있습니다. IBC가 도입되기 전에는 이러한 블록체인의 대부분이 서로 소통할 수 없는 폐쇄된 컨테이너 안에 존재하는 것처럼 독립적으로 운영되었지만, 이러한 폐쇄적인 모델은 근본적으로 지속 불가능합니다.

블록체인을 인구가 증가하고 상거래가 활발하며 농업에 특화된 국가가 있는 반면 축산업에 뛰어난 국가가 있는 개별 국가로 생각한다면, 각자의 강점을 살려 상호 이익을 위해 거래하고 협력하려는 것은 당연한 일입니다. IBC는 오늘날의 대규모 블록체인 네트워크에 내재된 확장성 문제의 제약을 받지 않고 서로 다른 블록체인이 상호 운용하고, 가치를 전송하고, 자산과 서비스를 교환하고, 연결을 구축할 수 있는 무한한 가능성의 신세계를 열어준다고 해도 과언이 아닙니다.

그렇다면 IBC는 어떻게 이러한 요구를 충족하고 중요한 역할을 할 수 있을까요? 근본적인 이유는 다음과 같습니다.

1. 신뢰가 필요 없음

2. 이기종 블록체인 지원

3. 애플리케이션 레이어에서 커스터마이징 가능

4. 입증되고 성숙함

IBC 프로토콜은 라이트 클라이언트와 리피터의 조합에 기반합니다. 클라이언트)와 리피터. IBC를 통해 통신하는 체인 A와 체인 B는 서로의 원장에 대한 라이트 클라이언트를 가지고 있습니다. 체인 A는 제3자를 신뢰할 필요가 없으며, 블록 헤더를 확인하는 것만으로 체인 B의 상태에 대한 합의에 도달할 수 있습니다. IBC를 통해 상호작용하는 체인(특히 모듈)은 서로에게 직접 메시지를 전송하지 않습니다. 대신, 체인 A는 패킷의 일부 메시지를 자신의 상태와 동기화합니다. 그러면 리피터가 이 패킷을 검사하여 대상 체인으로 전송합니다.

요약하면, IBC 프로토콜은 두 가지 계층, 즉 IBC TAO와 IBC APP로 나눌 수 있습니다.

IBC TAO: 패킷의 전송, 인증, 순서에 대한 표준, 즉 인프라 계층을 정의합니다. ICS에서는 코어, 클라이언트, 리피터 클래스로 구성됩니다.

IBC APP: 전송 계층을 통과하는 패킷에 대한 애플리케이션 핸들러를 정의하는 표준으로, 동질화된 토큰 전송(ICS-20), 비동질화된 토큰 전송(ICS-721), 체인 간 계정(ICS-27)을 포함하며 ICS의 애플리케이션 카테고리에서 찾아볼 수 있습니다.

IBC 차트(코스모스 개발자 포털의 코스모스 개발자 포털)

IBC 프로토콜은 코스모스가 블록체인 인터넷 비전을 고수하는 근간입니다. 이러한 의미에서 IBC의 설계 선택은 TCP/IP 사양의 영향을 받았습니다. TCP/IP가 컴퓨터 통신에 대한 표준을 설정하는 방식과 유사하게, IBC는 블록체인이 통신할 수 있도록 구현할 수 있는 일련의 일반적인 추상화를 지정합니다.TCP/IP는 네트워크를 통해 전달되는 패킷의 내용에 제한을 두지 않으며, IBC 역시 마찬가지입니다. 또한, HTTP와 SMTP와 같은 애플리케이션 프로토콜이 TCP/IP에 구축되는 방식과 유사하게, 동종 자산/비동종 자산 전송 또는 크로스체인 스마트 콘트랙트 호출과 같은 애플리케이션 인스턴스는 IBC 프로토콜을 기본 계층으로 사용합니다.

현재 IBC 프로토콜의 주요 문제점은 채널 전송 및 패킷 처리에 관한 문제이며, 물론 검증 증거가 부족하고 프로세스의 다른 측면이 상대적으로 큰 문제로 나타난 것은 아니지만 이러한 문제는 상대적으로 작으며, 이 기사에서는 IBC 프로토콜의 일반적인 문제에 중점을 둡니다. IBC 프로토콜의 모듈식 설계로 인해 IBC 애플리케이션 개발자는 클라이언트, 연결 및 증명 검증의 기본 세부 사항에 집중할 필요가 없습니다. 그러나, 개발자는 IBCModule 인터페이스와 해당 키퍼 처리 메서드 등을 구현해야 합니다. 따라서, 패킷을 수신하고 처리하기 위한 IBCModule 인터페이스의 코드 경로(onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket 등) 코드 경로입니다.

공통 취약점 분류

코스모스 생태계에서 IBC 프로토콜은 연결 허브 역할을 하며, 취약점 유형 측면에서 IBC 프로토콜 관련 취약점이 더 많고, 취약점이 발생하는 위치가 더 복잡합니다. IBC 프로토콜의 구현은 코스모스-SDK, 코멧BFT 및 기타 모듈과 밀접한 관련이 있기 때문에 아래에서 코스모스 생태계의 다른 모듈의 일부 구현을 언급하는 것은 불가피합니다. 또한, 현재 코스모스 생태계에서는 ibc-go 문서에 설명된 대로 IBC가 사용되므로 주요 언어는 Golang입니다.

이 글에서는 지면 제약으로 인해 IBC 프로토콜의 다양한 측면과 구성 요소를 자세히 분석하지 않고 일부 기존 보안 취약점의 분류에 대해서만 설명합니다. 보다 상세하고 포괄적인 분석을 원하시면 언제든지 CertiK 보안 엔지니어에게 문의해 주시기 바랍니다.

일반적인 취약점 :

1. 네이밍 취약점

① 문자열 처리 취약점

② 바이트코드 처리 취약점

2. 전송 프로세스 취약점

① 패킷 시퀀스 취약점

② 패킷 타임아웃 취약점

2. 취약점

③ 패킷 인증 취약점

④ 기타 패킷 취약점

3. 로직 취약점

① 상태 업데이트 취약점

② 투표 합의 및 기타 취약점

③ 기타 로직 취약점

4. 가스 소비 취약점

기존 IBC 기존 IBC 프로토콜은 보안을 감사하고 분석하는 측면에서 웹2.0 프로토콜의 감사 프로세스와 유사점이 많습니다. 이번에는 프로토콜 개발, 구현 및 애플리케이션 확장이라는 전체 프로세스의 관점에서 IBC 프로토콜의 보안 이슈와 잠재적 위험성을 분석해 보겠습니다. 프로토콜 개발은 종종 소수의 사람과 조직에 의해 이루어지며, 모든 종류의 블록체인 조직은 프로토콜의 구현과 확장을 중심으로 더 많은 작업을 수행하므로, 이 백서에서는 이 두 가지의 보안에 초점을 맞출 것입니다. 이는 프로토콜의 다양한 유형의 보안 문제를 해당 링크와 모듈로 더 잘 나눌 수 있는 IBC 프로토콜의 광범위한 보안 위험에 대한 고려에서 비롯된 것입니다.

취약점 분석

• IBC 프로토콜의 구성

• 사례 1: ICS-07 프로토콜, 논리 취약점

취약점 배경: 잘못된 언번들링 데드라인 사용

코드에 다음과 같은 검사가 존재합니다:

if  currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod {

에 따르면 Tendermint 보안 모델에 따르면 t 시점에 블록(헤더)의 NextValidators에 있는 유효성 검사기는 t+TrustingPeriod까지 올바르게 실행되어야 하며, 그 이후에는 다르게 동작할 수 있습니다. 그러나 여기서 검사하는 것은 TrustingPeriod가 아닌 UnbondingPeriod에 대한 것으로, 만약 consState의 지속 시간이 TrustingPeriod와 UnbondingPeriod 사이에 있으면 다음과 같습니다. 가 되어 부정 행위를 구성하는 충돌하는 헤더 중 하나를 검증하는 데 사용되는 기준선으로 해당 헤더를 받아들입니다. 이 기간 동안 consState.NextValidators의 유효성 검사기는 더 이상 신뢰할 수 있는 것으로 간주되지 않으며, 적대적인 전 유효성 검사기는 아무런 위험 없이 클라이언트를 종료할 수 있습니다.

프로젝트 주소: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007- 텐더민트-클라이언트

취약점 위치: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/ spec/ics-007-tendermint-client#misbehaviour-predicate

https://github.com/cosmos/cosmos-sdk/blob/ 6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

익스플로잇 코드 스니펫:

img src="https://img.jinse.cn/7158715_image3.png">

프로토콜 정의 함수

코드 구현

• IBC 프로토콜 구현

IBC 프로토콜 구현 링크는 목록의 상단과 하단 모두에서 역할을 하기 때문에 문제가 되는 곳입니다. 프로토콜 사양의 모호함을 피하는 것도 중요하지만, 프로토콜의 후속 사용 및 확장을 위해 보다 기본적이고 편리한 인터페이스를 제공하는 것도 중요합니다. 따라서 IBC 프로토콜 구현의 주요 문제점은 다음과 같이 분류됩니다.

1. 프로토콜 구현의 모호성 및 불규칙성

2. 프로토콜 설정의 오류

• 프로토콜 구현의 모호성 및 불규칙성

  프로토콜 구현의 모호성 및 불규칙성

  프로토콜 구현의 모호성 및 불규칙성

  . 모호성 및 불규칙성 문제

• 사례 1: ICS-20 프로토콜, 명명 취약점

취약점 배경: 호스팅 주소 충돌 GetEscrowAddress()는 20바이트 SHA256(포트 ID + 채널 ID)으로 잘립니다. 이 접근 방식에는 세 가지 문제가 있습니다.

1. 포트와 채널 사이에 도메인이 분리되어 있지 않으며, 문자열 연결을 사용하면 포트와 채널의 도메인이 분리되지 않습니다. 예를 들어 포트/채널 조합("전송", "채널") 및 ("트랜스", " 페채널")은 동일한 관리 주소, 즉 잘린 SHA256("전송 채널")을 제공합니다. 특정 라이브러리 지원 모듈이 포트 및 채널 ID를 선택할 수 있는 경우 취약점이 발생할 수 있습니다.

2. 모듈 계정 주소 간의 충돌. 임의의 영숫자 문자열이 포스트이미지 크기가 160비트인 SHA-256의 프리이미지에 사용됩니다. 이렇게 작은 포스트 이미지와 빠른 해시 함수의 조합으로 보안이 80비트로 줄어들어 생일 공격이 가능해집니다. 이는 서로 다른 두 호스팅 계정 주소 간의 충돌을 찾는 데 약 2^80번의 추측이 필요하다는 것을 의미하며, 2018년 텐더민트에서 수행한 SHA256 절단 공격에 대한 자세한 비용 분석에 따르면 이 공격은 비용 측면에서 실현 가능하며, 충돌을 찾는다는 것은 서로 다른 두 호스팅 계정이 동일한 계정 주소에 매핑된다는 것을 의미합니다. 이는 호스팅 계정에서 자금을 탈취할 위험으로 이어질 수 있으며, 자세한 내용은 ICS20 GetEscrowAddress 사전 이미지 도메인이 공개 키와 겹침T:BUG.

3.모듈형 계정 주소와 비모듈형 계정 주소 간의 충돌

에서 확인할 수 있습니다. strong>. 공개 계정 주소는 Ed25519 공개 키의 20바이트 SHA-256과 동일한 방식으로 구성됩니다. 특정 공개 주소에 대한 충돌 공격을 방지하는 데는 160비트의 보안으로도 충분하지만, 생일 공격에 대한 보안은 다시 80비트에 불과합니다. 이 상황은 반쪽 생일 공격 모델과 유사하며, 한 주소는 빠른 SHA-256으로 생성하고 다른 주소는 상대적으로 느린 Ed25519 공개 키 계산으로 생성합니다. 이 시나리오는 더 안전하지만 에스크로 및 공개 계정에 대한 공격 가능성이 여전히 높습니다.

프로젝트 주소: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020- 대체 가능한 토큰 전송

취약점 위치: https://github.com/cosmos/cosmos-sdk/blob/ 6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https:// github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

익스플로잇 코드 스니펫:

• 프로토콜 설정 오류 문제

• 사례 1: IBC 보안 권고 드래곤베리, 전송 프로세스 취약점

취약점 배경: IBC는 애플리케이션 패킷을 처리할 때 패킷의 구조를 사용합니다. 타임아웃 메커니즘, 동기 및 비동기 확인 메커니즘 및 해당 증명 검증 프로세스에 따라 패킷은 두 가지 실행 프로세스로 나뉩니다.

1. 정상 사례: 타임아웃 내 성공

2. 타임아웃 사례: 타임아웃 실패

IBC 애플리케이션 패킷 전송 흐름도

1. 시간 초과가 발생하면 전송이 실패하고 IBC 프로토콜이 환불 프로세스를 시작합니다. IBC에는 사용자가 구성할 수 있는 시간 초과 메커니즘이 있다는 점에 유의해야 합니다. ICS-23(IBC)에서 발생한 드래곤베리 취약점은 사용자가 인증 프로세스에서 비존재 증명(즉, 패킷 미수신 증명)을 위조하여 보안 검사를 우회하여 "그럴듯한" IBC 시간 초과 조건으로 IBC 프로토콜을 스푸핑함으로써 리피터가 잘못된 시간 초과 조건으로 패킷을 전송하도록 만들 수 있다는 사실에 그 뿌리를 두고 있습니다. 이로 인해 리피터가 잘못된 인증서가 포함된 타임아웃 패킷을 전송하게 되고 ICS-20 이중 지출 문제로 확대될 수 있으며, 취약점의 구체적인 트리거 흐름은 아래 그림에서 확인할 수 있습니다.

드래곤베리 취약점 개략도

프로젝트 주소: https:// github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel 

취약점 위치: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/ timeout.go#L117C28-L117C54

취약 코드 스니펫:

• 사례 2: IBC 보안 권고 허클베리, 전송 프로세스 취약점

  >

취약점 배경: UnreceivedPackets는 쿼리에 포함된 각 시퀀스 번호에 해당하는 패킷 영수증만 조회하여 응답을 구성합니다. 정렬된 채널은 패킷 영수증 대신 nextSequenceRecv를 사용하기 때문에 이는 정렬되지 않은 채널에만 적용됩니다. 따라서 정렬된 채널에서는 GetPacketReceipt을 통해 시퀀스 번호를 쿼리해도 해당 채널에 포함된 영수증을 찾을 수 없습니다.

ICS-20 FT는 대부분 정렬되지 않은 채널에서 전송하고 리피터가 트리거링 시간 초과 패킷을 결정하기 위해 이 grpc 엔드포인트에 의존하지 않기 때문에 이 문제의 심각성은 덜 심각합니다. 그러나 대상 체인에 많은 수의 패킷이 있고 IBC 전송을 위해 구성된 정렬된 채널이 있고 grpc 응답의 페이징이 없는 경우, 이로 인해 성능 저하 또는 서빙 노드의 충돌이 발생할 위험이 있습니다. 구체적인 트리거링 프로세스는 다음 그림에서 확인할 수 있습니다.

허클베리 취약점 개략적인 순서도

프로젝트 주소: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

취약점 위치: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-

channel/keeper/grpc_query.go#L408

익스플로잇 코드 스니펫:

• IBC 프로토콜의 사용 및 확장

• 사례 1: 스트라이드 에어드롭 취약점, 로직 취약점

취약점 배경:TryUpdateAirdropClaim이 함수는 IBC 패킷의 발신자 주소를 senderStrideAddress라는 스트라이드 주소로 변환하고 패킷 메타데이터에서 airdropId와 새 에어드롭 주소를 추출합니다. 그런 다음 updateAirdropAddress를 호출하여 senderStrideAddress와 클레임 레코드를 업데이트합니다. 클레임 레코드가 업데이트되면 newStrideAddress가 에어드랍을 청구할 수 있게 됩니다. 그러나 여기서 업데이트 함수는 요청에 대한 발신자의 주소가 비어 있는지 여부만 확인하며, newStrideAddress는 확인하지 않습니다. ibc는 단독 머신 연결로 IBC 지원 체인을 구현할 수 있기 때문에 다른 계정 주소를 드롭 주소로 업데이트할 경우 보안상 위험성이 있습니다.

프로젝트 주소: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/ 자동 조종 장치

취약점 위치: https://github.com/Stride-Labs/stride/blob/ 3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/ 3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

익스플로잇 코드 스니펫:

• Case 2: 중성자 IBC 모듈 취약점, 가스 소비 취약점

취약점 배경: IBC 이벤트의 승인/타임아웃에 대한 스마트 컨트랙트 지불이 충분히 검증되지 않았으며, 이는 악의적인 스마트 컨트랙트에 의해 악용될 수 있는 OnAcknowledgementPacket 및 온타임아웃 패킷의 처리 중 온타임아웃패킷 메시지의 악의적인 스마트 컨트랙트에 의해 악용되어 에러아웃오브가스 크래시를 유발합니다. 이러한 크래시는 아웃오브가스 리커버리 실행으로 복구되지 않으며, 이는 트랜잭션이 블록에 포함되지 않고 IBC 리피터가 반복적으로 메시지를 제출하게 되어 궁극적으로 리피터 자금 손실과 네트워크에서 버려지는 패킷이 너무 많아지는 피해를 초래할 수 있음을 의미합니다.

프로젝트 주소: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

취약점 위치:

https://github.com/neutron-org/neutron/blob/ 64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

취약점 코드 스니펫:

요약

위와 같이 IBC 프로토콜의 보안 문제에 대해 연구하고 분석한 결과, IBC 프로토콜의 보안 문제는 광범위한 분포와 다양한 문제를 가지고 있지만, 주요 문제는 여전히 IBC 프로토콜 확장의 구현과 사용에 있다는 것을 어렵지 않게 발견할 수 있습니다. 주요 문제는 IBC 프로토콜의 구현과 사용의 확장입니다. IBC의 경우 IBM의 소프트웨어에서 사용되는 프로토콜을 그대로 사용할 수는 없지만, IBM의 소프트웨어에서 사용되는 프로토콜을 그대로 사용할 수 있고, IBM의 소프트웨어에서 사용되는 프로토콜을 그대로 사용할 수 있는 것은 가능합니다.

위에서 언급한 IBC 체인의 보안 이슈 외에도 IBC 미들웨어와 같은 다른 보안 이슈도 등장하고 있으며, 향후에는 IBC 모듈의 보안 이슈가 코스모스 생태계의 보안에 중요한 부분이 될 것으로 생각됩니다.

요약

코스모스 생태계의 보안을 탐구하고 연구하는 과정에서 복잡한 감사, 요약 및 분류 작업을 거쳤으며, 풍부한 실무 경험을 통해 코스모스 생태계에서 가장 중요한 코스모스 SDK와 IBC 프로토콜에 대한 보안 이슈를 탐구했습니다. 일반적인 감사에 대한 많은 교훈을 얻었습니다.

이 보고서는 크로스 체인 상호 작용을 지원하는 이기종 네트워크를 다룰 때 직면하는 문제를 강조합니다. 구성 요소의 복잡성과 탈중앙화로 인해 이러한 구성 요소에 대한 보안 감사를 수행하는 것은 기존 보안 경험을 통해 내재된 일부 보안 위험을 해결해야 할 뿐만 아니라 새로운 보안 시나리오에 직면하여 새로운 보안 문제를 분석해야 하는 등 똑같이 어려운 과제입니다. 또한 끊임없이 새로운 보안 시나리오에 직면하고 새로운 보안 문제를 분석해야 합니다.

그럼에도 불구하고 이 보고서에 요약된 것과 같은 일반적인 시나리오와 보안 이슈를 통해 이기종 코스모스 생태계의 전반적인 보안을 점진적으로 개선할 수 있다고 믿습니다.