Cosmos 생태계 보안 가이드: Cosmos 생태계의 다양한 구성 요소별 보안 시나리오 분석
글: CertiK
전 세계 최대이자 가장 유명한 블록체인 생태계 중 하나인 Cosmos는 블록체인 간 상호운용성을 향상시키고 다양한 블록체인이 효율적으로 연결될 수 있도록 하는 것에 집중하고 있습니다. Celestia, dYdX v4 등 주요 프로젝트들이 Cosmos SDK와 IBC 프로토콜을 기반으로 구축되었습니다.
Cosmos 개발 구성 요소들이 점점 더 많은 개발자들에게 선호됨에 따라, Cosmos 생태계의 보안 문제 또한 더욱 광범위한 영향을 미칠 것으로 예상됩니다. 예를 들어 이전 Cosmos SDK의 Dragonfruit 취약점은 다수의 주요 공개 블록체인의 정상 작동에 영향을 미쳤습니다. Cosmos 생태계의 기본 구성 요소들이 분산되어 있기 때문에, 개발자들은 기능 요구 사항에 따라 다른 구성 요소들을 사용하거나 확장해야 하며, 이로 인해 Cosmos 생태계 내 보안 문제 역시 분산되고 다양한 특성을 가지게 됩니다. 따라서 개발자들이 Cosmos 생태계의 보안 현황과 대응 방안을 체계적으로 이해할 수 있도록 돕는 연구가 매우 중요합니다.
CertiK 팀이 독점적으로 발표한 『Cosmos 생태계 보안 가이드』는 독자가 쉽게 이해할 수 있는 분류를 통해 Cosmos 생태계 각 구성 요소의 보안 시나리오를 세심하게 분석하였습니다. 본 보고서는 Cosmos 생태계에서 발생했던 주요 보안 취약점 분석뿐만 아니라, 일반적인 보안 취약점을 원인, 효과, 코드 위치 등을 기준으로 분류하여 Cosmos 생태계 개발자들에게 최대한의 보안 지침을 제공하며, 보안 감사 담당자들에게는 Cosmos 보안 문제를 학습하고 감사하는 데 필요한 자료를 제공합니다.
CertiK 팀은 지속적인 연구와 탐색을 통해 Cosmos 및 전체 Web3 생태계의 보안 강화를 지원해 왔습니다. 앞으로도 다양한 프로젝트의 보안 보고서와 기술 연구를 정기적으로 제공할 예정이니, 지속적인 관심 부탁드립니다! 궁금한 사항이 있으시면 언제든지 문의해 주세요.
다음은 『Cosmos 생태계 보안 가이드』 전문입니다👇.
개요
Cosmos는 오픈소스이며, 개방적이고 고도로 확장 가능한 블록체인 크로스체인 네트워크로, 세계에서 가장 유명한 블록체인 생태계 중 하나입니다. Cosmos는 CometBFT(구 Tendermint 팀)가 개발한 크로스체인 상호작용을 지원하는 이종 네트워크로서, 여러 개의 독립적이고 병렬적으로 운영되는 블록체인들로 구성된 탈중앙화 네트워크입니다. 그 목표는 정보의 고립 상태를 해소하고 서로 다른 블록체인 간 상호운용성을 실현하는 것이며, 현재 다중 체인 시대에서 크로스체인 상호작용을 가능하게 하는 것은 블록체인 산업의 절박한 요구사항입니다.
Cosmos는 특정 수직 분야에 특화된 공개 블록체인에 특히 적합한 효율적인 크로스체인 모델을 제공합니다. 모듈화된 블록체인 인프라를 제공함으로써, Cosmos는 애플리케이션 개발자들에게 편의를 제공하여 자신의 요구에 맞는 공개 블록체인을 선택하고 활용할 수 있게 합니다.
Cosmos 생태계 내 애플리케이션과 프로토콜은 IBC(Inter-Blockchain Communication Protocol, 블록체인 간 통신 프로토콜)을 통해 연결되며, 이를 통해 각각의 독립된 블록체인 사이에서 크로스체인 상호작용이 이루어지고, 자산과 데이터가 자유롭게 흐를 수 있습니다. Cosmos의 비전은 블록체인 인터넷을 구축하여, 수많은 자율적이며 개발이 용이한 블록체인들이 확장성과 상호작용을 할 수 있도록 하는 것입니다.
지난 긴 시간 동안 CertiK은 Cosmos 생태계에 대해 충분한 관심과 연구를 지속해 왔습니다. 우리는 Cosmos 생태계 보안 문제에 대한 풍부한 경험을 쌓았으며, 본 연구 보고서에서는 Cosmos 생태계 보안에 대한 탐색과 연구 성과를 소개합니다. 주로 Cosmos SDK 보안, IBC 프로토콜 보안, CometBFT 보안, CosmWasm 보안이라는 네 가지 방향에 초점을 맞출 것이며, 논의 대상은 Cosmos 기초 구성 요소에서부터 Cosmos 기반 체인 또는 애플리케이션 체인까지 확장됩니다. 유사한 문제들을 분석하고 확장함으로써, 하향식 접근법을 통해 독자들에게 체인 자체와 관련된 주요 보안 포인트들을 제시하겠습니다.
Cosmos 생태계의 복잡하고 다양한 특성으로 인해 존재하는 보안 문제들도 다양성을 띠고 있습니다. 따라서 본 연구 보고서는 모든 보안 취약 유형을 포괄하지는 않으며, 보다 전형적인 특징을 가지고 있으며 Cosmos 생태계 체인에 더 큰 위험을 초래할 수 있는 취약점들만을 다룹니다. 다른 보안 문제들에 관해 더 자세히 알고 싶으시다면, CertiK 보안 엔지니어에게 연락하셔서 논의하시기 바랍니다.
배경
-
CometBFT: 크로스체인 확장성의 기반
CometBFT는 혁신적인 합의 알고리즘로, 저수준 합의 엔진(CometBFT Core)과 일반적인 애플리케이션 블록체인 인터페이스(ABCI)라는 두 가지 주요 구성 요소를 포함합니다. 해당 합의 알고리즘은 PBFT+Bonded PoS 하이브리드 합의 방식을 채택하여 노드들이 거래 내역을 동기화하여 기록하도록 보장합니다. Interchain 확장성의 핵심 구성 요소로서, CometBFT는 검증자의 합의를 통해 Interchain 생태계의 보안성, 탈중앙화, 무결성을 유지합니다.
-
Cosmos SDK: 모듈화와 신규 기능
Cosmos SDK는 개발자들이 개발 속도를 가속화할 수 있도록 도와주는 도구 패키지입니다. 모듈화 및 플러그인 가능한 특성을 제공하며, Cosmos SDK를 활용하면 개발자들은 CometBFT 합의 알고리즘을 기반으로 자신만의 블록체인이나 기능 모듈을 구축하여 개발을 간편하게 하고 개발 주기를 단축할 수 있습니다. 이미 Cronos, Kava, 최근 출시된 dYdX V4 등 다수의 블록체인 프로젝트에서 채택되었습니다. 향후 계획은 모듈화 및 신규 기능 도입에 중점을 두어 개발자들이 더욱 복잡하고 모듈화된 애플리케이션을 만들 수 있도록 하여, 더 광범위하고 강력한 생태계를 조성하는 것입니다.
-
IBC 프로토콜: 상호운용성 및 확장성 강화
IBC 프로토콜(Inter-Blockchain Communication Protocol, 블록체인 간 통신 프로토콜)은 블록체인 간 안전하고 탈중앙화되며 무허가 방식의 데이터 전송을 가능하게 함. Cosmos는 여러 개의 독립적이고 병렬적으로 작동하는 블록체인들로 구성된 탈중앙화 네트워크이며, 리레이 기술을 이용해 서로 다른 블록체인 간 크로스체인을 실현하기 때문에, IBC는 사실상 이 프로젝트의 핵심이라 할 수 있습니다. Interchain 재단은 현재 두 가지 주제에 집중하고 있습니다: 확장성과 가용성. IBC의 확장성과 상호운용성을 향상시킴으로써, Cosmos는 생태계의 수용력을 더욱 증대시켜 블록체인, 애플리케이션, 스마트 계약 간 원활한 상호작용을 가능하게 할 것입니다.
-
CosmWasm: 탈중앙화, 무허가 배포의 잠재력 해제
CosmWasm(Cosmos WebAssembly)는 WebAssembly 기반의 스마트 계약 프레임워크로, Cosmos 생태계를 위해 특별히 설계되었습니다. 개발자들이 무허가 조건에서도 탈중앙화 애플리케이션을 배포할 수 있도록 하며, 동시에 블록체인 개발자들이 제품 개발 주기를 블록체인 개발과 분리할 수 있도록 하여 검증자 업그레이드 비용을 줄일 수 있습니다. 게다가 모듈화 아키텍처, Cosmos SDK 통합, 크로스체인 통신 등의 특징도 갖추고 있습니다.
현재까지 Cosmos SDK와 IBC 프로토콜은 상대적으로 성숙하며, 현재 Cosmos 생태계에서 가장 널리 사용되고 있음.
체인 개발자의 관점에서 보면, 현재 Cosmos 상의 생태체인이 필요로 하는 대부분의 맞춤형 기능은 Cosmos SDK를 통해 달성할 수 있습니다. 다만 크로스체인 작업 중 특정 작업을 수행하거나 성능 최적화 등을 목적으로 각 체인 개발자들이 자신들의 IBC 모듈을 커스터마이징하기도 합니다. 이 밖에도 소수의 체인들은 CometBFT Core 등의 저수준 엔진을 수정·커스터마이징하기도 하지만, 본 연구 보고서의 분량 제한상 여기서는 다루지 않겠습니다. 본 보고서는 주로 Cosmos SDK와 IBC 프로토콜이라는 두 가지 기술 요소와 보안 문제를 심층적으로 분석합니다.
Cosmos SDK 보안 가이드
Cosmos SDK는 블록체인 애플리케이션과 탈중앙화 프로토콜을 구축하기 위한 강력하고 유연한 프레임워크입니다. Interchain 재단이 개발하였으며, 탈중앙화된 블록체인 간 네트워크인 Cosmos 네트워크의 핵심 구성 요소입니다.
Cosmos SDK는 맞춤형 블록체인 애플리케이션의 개발을 단순화하고 서로 다른 블록체인 간 원활한 상호운용성을 실현하기 위해 설계되었습니다. Cosmos SDK의 주요 특징은 다음과 같습니다: 모듈화 아키텍처, 맞춤화 가능성, CometBFT 기반, IBC 인터페이스 구현, 개발자 친화성. Cosmos SDK는 CometBFT Core 저수준 합의 엔진을 활용하여 강력한 보안을 보장하고, 악의적인 공격으로부터 네트워크를 보호하며 사용자의 자산과 데이터를 보호합니다. 또한 모듈화 특성 덕분에 사용자가 쉽게 맞춤형 모듈을 설계할 수 있습니다. 이러한 장점이 있음에도 불구하고, 개발자가 Cosmos SDK를 사용해 자신의 애플리케이션을 구현할 때 여전히 보안 취약점이 발생할 수 있습니다.
보안 감사 관점에서 보면, 감사 대상에 대해 면밀히 살펴보고 모든 각도의 보안 위험을 충분히 고려해야 합니다. 그러나 보안 연구 관점에서는 보다 큰 영향을 미치는 보안 취약점을 더 중점적으로 파악하는 것이 중요하며, 짧은 시간 안에 최대한의 보안 위험을 피하고 통합 서비스 제공업체에게 더 효과적인 도움을 줄 수 있어야 합니다. 이러한 맥락에서, 위험성이 높고 영향 범위가 큰 취약점들을 분류하고 그 취약 모델을 분석하는 일은 매우 필수적이며 가치 있는 일입니다.
전체 Cosmos 생태계를 관통하는 ABCI 인터페이스에서, 우리는 BeginBlock, EndBlock, CheckTx, DeliverTx 이 네 가지 인터페이스에 주목합니다. 전자는 직접적으로 단일 블록의 실행 로직과 관련되며, 후자는 sdk.Msg(Cosmos 생태계에서 메시지를 전달하는 기본 데이터 구조)의 구체적인 처리와 관련됩니다.
Cosmos 생태계 상의 다양한 애플리케이션 체인들의 구현 로직은 모두 Cosmos SDK 내 모듈과 샘플과 유사하게 구성되기 때문에, 아래에 설명하는 보안 취약점을 이해하고 분석할 때는 Cosmos SDK의 모듈 실행 프로세스에 대한 기본 개념이 필요합니다.
Cosmos 생태계에서 거래는 처음에 사용자 에이전트에서 생성되며, 이후 서명되어 블록체인 내 노드로 방송됩니다. 노드는 CheckTx 메서드를 활용하여 서명, 발신자의 잔액, 거래 순번, 제공된 가스(gas) 등의 다양한 거래 세부 사항을 검증합니다. 거래가 검증을 통과하면 메모리 풀(mempool)에 추가되어 블록에 포함될 때를 기다립니다. 반대로 거래가 검증을 통과하지 못하면 사용자에게 오류 메시지가 전송되어 거래가 거부됩니다. 블록 실행 중에는 거래에 대한 추가 검사를 수행하며, 이는 DeliverTx 메서드를 통해 이루어져 일관성과 결정성을 보장합니다.
Cosmos SDK에서 거래의 생명주기는 다음과 같은 간략한 프로세스로 설명할 수 있음:
1. 거래 생성: 거래는 다양한 도구, CLI 또는 프론트엔드를 사용하여 클라이언트에서 생성됩니다.
2. 메모리 풀에 추가: 거래는 메모리 풀에 추가되며, 이때 노드는 응용 프로그램 계층으로 ABCI 메시지 -CheckTx를 보내 유효성을 확인하고 abci.ResponseCheckTx 결과를 수신합니다. CheckTx에서는 바이트 형식의 거래가 Tx 형식으로 디코딩된 후, 각 sdk.Msg에 대해 ValidateBasic()이 호출되어 초기의 상태 없는 유효성 검사를 수행합니다. 응용 프로그램에 anteHandler가 존재하는 경우 먼저 내부 로직을 실행한 후 runTx 함수를 호출하며, 결국 RunMsgs() 함수를 호출하여 sdk.Msg의 구체적인 내용을 처리합니다. CheckTx가 성공하면 메시지는 다음 블록 후보로 로컬 메모리 풀에 추가되며 P2P를 통해 피어 노드에 방송됩니다.
3. 제안된 블록에 포함: 매 라운드 시작 시 제안자가 최신 거래를 포함한 블록을 생성하며, 마지막으로 전체 노드가 합의 검증자로서 해당 블록을 수락하거나 공백 블록에 투표합니다.
4. 상태 변경: DeliverTx가 호출되어 블록 내 거래를 반복 처리하며, CheckTx와 유사하지만 Deliver 모드에서 runTx를 호출하고 상태 변경을 수행합니다. MsgServiceRouter가 호출되어 거래 내 다양한 메시지를 다른 모듈로 라우팅한 후 각 메시지에 해당하는 Msg Server에서 실행합니다. 이후 메시지 실행 후 검사를 수행하며, 실패가 발생하면 상태를 롤백합니다. 실행 과정에서 가스 미터기가 사용되어 얼마나 많은 가스를 사용했는지 추적합니다. 가스 오류(예: 가스 부족)가 발생하면 실행 실패 후와 동일한 결과가 되며, 상태 변경은 롤백됩니다.
5. 블록 커밋: 노드가 충분한 검증자 투표를 수신하면 새로운 블록을 블록체인에 추가하여 커밋하고, 결국 애플리케이션 계층의 상태 전환이 확정됩니다.
Cosmos 생태계에서의 거래 생명주기도
아래는 Cosmos SDK의 구체적인 실행 로직으로, 이후 취약점 트리거 경로를 분석할 때 참고하시기 바랍니다:
Cosmos SDK 주요 ABCI의 구체적인 실행 로직
일반적인 취약점 분류
취약점 분류를 이해하기 전에, 취약점의 위험 수준에 대한 기본적인 구분이 필요합니다. 이를 통해 위험성이 큰 보안 취약점을 더 잘 식별하고 잠재적인 보안 위험을 최대한 회피할 수 있습니다.
위험 수준과 영향 범위를 고려할 때, 주로 Critical 및 Major 등급의 보안 취약점에 주목하며, 일반적으로 다음의 위험을 초래할 수 있습니다:
1. 체인 중단
2. 자금 손실
3. 시스템 상태 또는 정상 작동에 영향
이러한 위험의 원인은 일반적으로 다음과 같은 유형의 보안 취약점에서 비롯됩니다:
1. 서비스 거부
2. 잘못된 상태 설정
3. 검증 누락 또는 부적절한 검증
4. 고유성 문제
5. 합의 알고리즘 문제
6. 구현상의 논리적 결함
7. 언어 특성 문제
취약점 분석
Cosmos 생태계의 모듈화 특성으로 인해 다양한 체인 구현에서 모듈 간 상호 사용 및 모듈 내 상호 호출 사례가 많으며, 이로 인해 취약점 트리거 경로와 취약점 트리거 위치 변수의 제어 경로가 일치하지 않는 경우가 발생합니다. 취약점의 구체적인 원인을 분석할 때 트리거 경로만을 주목할 것이 아니라, 취약점 핵심 변수의 제어 경로에도 주목해야 하며, 이를 통해 취약점 모델을 더 잘 정의하고 분류할 수 있습니다.
체인 중단
체인 중단의 주요 원인은 대부분 단일 블록 실행 과정에서 발생하는 문제이지만, Cosmos의 역사적 발전 과정에서 합의 보안 취약점으로 인해 체인을 수동으로 중단하고 수정해야 했던 사례도 있었습니다. 따라서 본 항목에서는 합의에 영향을 주는 유형의 보안 취약점도 체인 중단 효과에 포함하여 논의하겠습니다. 두 가지 유형의 문제를 나누어 설명하겠습니다.
첫 번째 유형은 일반적으로 서비스 거부(Denial of Service) 유형의 취약점으로, 주된 원인은 부적절한 충돌 처리와 사용자가 영향을 줄 수 있는 순회 작업의 반복 경계입니다. 이러한 취약점은 체인의 일시 정지 또는 실행 속도 저하 등의 결과를 초래합니다.
앞서 언급했듯이 Cosmos SDK와 CometBFT는 Cosmos 생태계의 핵심 인프라로서, Cosmos의 기반 체인뿐만 아니라 다양한 애플리케이션 체인들도 이들의 아키텍처를 기반으로 각자의 로직을 구현합니다. 따라서 모두 CometBFT의 ABCI 인터페이스 규칙을 따르며, 주요 공격 표면도 ABCI 인터페이스에 집중됩니다. 체인 중단을 초래할 수 있는 보안 취약점은 대부분 블록 코드 실행에 직접적인 영향을 미치는 문제이며, 그 발생 경로는 기본적으로 BeginBlock과 EndBlock 두 인터페이스로 거슬러 올라갑니다.
두 번째 유형은 합의에 영향을 주는 취약점으로, 일반적으로 다양한 체인의 구현과 관련이 있습니다. 알려진 대표적인 사례로는 논리 처리 검증, 시간 조정, 무작위성 문제 등이 있습니다. 이러한 취약점은 본질적으로 블록체인의 탈중앙화 원칙에 영향을 미치며, 직관적으로는 큰 영향이 없어 보일 수 있지만, 악의적인 의도로 설계된다면 상당한 보안 위험을 초래할 수 있습니다.
첫 번째 유형
-
사례 1: SuperNova 프로젝트
취약점 배경: 주조 분배 작업에서 주소 검증이 누락되어 작업 실패 및 자금 유출이 발생함. 주조 모듈에서 토큰 주조는 항상 담보 금액에 따라 결정됩니다. 그러나 풀이 존재하지 않거나 계약 주소 입력이 잘못된 경우, 주조 모듈은 예기치 못한 상황에 직면하여 블록체인 작동 중단을 초래할 수 있습니다. 보상 풀 모듈에서는 풀 계약 주소에 대한 검증이 없습니다. 만약 분배 작업이 실패하면 체인은 즉시 작동을 중단합니다.
취약점 위치: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/keeper/keeper.go#L175
취약점 코드 조각:
취약점 트리거 경로:
BeginBlocker (/x/mint/keeper/abci.go)
Keeper.DistributeMintedCoin
Keeper.distributeLPIncentivePools
PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)
패치:
https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0
패치는 mint 모듈이 아닌 poolincentive의 메시지 처리 모듈(x/poolincentive/types/msgs.go)에 위치합니다.
MsgCreateCandidatePool(즉, 풀 생성) 처리 시 메시지에 주소 검증을 추가하여 잘못된 주소의 가능성을 근본적으로 차단했습니다.
-
사례 2: Cosmos Interchain Security 프로젝트
프로젝트 주소: https://github.com/cosmos/interchain-security
취약점 배경: 검증자는 동일한 블록 내에서 여러 AssignConsumerKey 메시지를 제출함으로써 제공 체인의 속도를 늦출 수 있음. x/ccv/provider/keeper/key_assignment.go에 정의된 AssignConsumerKey 함수를 통해 검증자는 승인된 소비 체인에 대해 서로 다른 consumerKey를 할당할 수 있음. 이를 수행하기 위해 consumerAddrsToPrune AddressList에 요소가 추가됨. x/ccv/provider/keeper/relay.go의 EndBlocker에서 이 AddressList를 순회하기 때문에, 공격자는 이를 악용하여 제공 체인의 속도를 늦출 수 있음. 이 공격을 수행하기 위해 악의 행위자는 여러 AssignConsumerKey 메시지를 포함한 거래를 생성하고 제공 체인에 전송할 수 있음. consumerAddrsToPrune AddressList의 기수가 전송된 AssignConsumerKey 메시지 수와 동일해짐. 따라서 EndBlocker의 실행은 예상보다 더 많은 시간과 리소스를 소모하여 제공 체인의 작동 속도가 느려지거나 중단될 수 있음.
취약점 위치: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378
취약점 코드 조각:
취약점 트리거 경로:
msgServer.AssignConsumerKey
Keeper.AssignConsumerKey
AppModule.EndBlock
EndBlockCIS
HandleLeadingVSCMaturedPackets
HandleVSCMaturedPacket
PruneKeyAssignments
-
사례 3: Quicksilver 프로젝트 - Airdrop 모듈
취약점 배경: BeginBlocker와 EndBlocker는 모듈 개발자가 자신의 모듈에서 선택적으로 구현할 수 있는 메서드입니다. 각각 블록의 시작과 끝에서 트리거됩니다. BeginBlock과 EndBlock 메서드에서 오류 처리를 위해 충돌(crash)을 사용하는 것은 오류 발생 시 체인 중단을 초래할 수 있습니다. EndBlocker가 미완료된 에어드랍을 정산할 때 모듈에 충분한 토큰이 있는지 여부를 고려하지 않아 충돌이 발생할 수 있으며, 이로 인해 체인이 중단됩니다.
취약점 위치: https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d60f4047e2f2f403d67701b030e/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
panic 처리 코드를 제거하고 오류 로그 기록으로 교체했습니다.
-
사례 4: Cosmos Interchain Security 프로젝트
프로젝트 주소: https://github.com/cosmos/interchain-security
취약점 배경: 공격자는 제공 체인의 보상 주소로 여러 토큰을 보내 DoS 공격을 수행할 수 있음.
소비 체인의 EndBlocker 실행 프로세스에서, x/ccv/consumer/keeper/distribution.go에 정의된 SendRewardsToProvider 함수는 tstProviderAddr의 모든 토큰 잔액을 가져와 제공 체인으로 전송함. 이를 위해서는 보상 주소에 있는 모든 토큰을 순회하고 IBC를 통해 하나씩 제공 체인으로 전송해야 함. 누구나 보상 주소로 토큰을 보낼 수 있기 때문에, 공격자는 토큰 팩토리 모듈을 사용하는 체인을 통해 다양한 denom의 대량 토큰을 생성하고 전송함으로써 DoS 공격을 수행할 수 있음. 따라서 EndBlocker의 실행은 예상보다 더 많은 시간과 리소스를 소모하여 소비 체인의 작동 속도가 느려지거나 중단될 수 있음.
취약점 위치: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103
취약점 코드 조각:
취약점 트리거 경로:
AppModule.EndBlock
EndBlock
EndBlockRD
SendRewardsToProvider
두 번째 유형
이러한 합의 문제는 직관적으로 심각한 피해를 초래하지 않을 수도 있지만, 블록체인의 본질적인 원칙과 체계를 고려하거나 구체적인 시나리오를 바라보면, 그로 인한 영향과 피해가 다른 일반적인 취약점보다 결코 작지 않습니다. 또한 이러한 취약점들은 공통점도 가지고 있습니다.
-
사례 1
취약점 배경: Cosmos SDK Security Advisory Jackfruit
Cosmos SDK의 x/authz 모듈에서 ValidateBasic 메서드의 비결정적 행동은 합의 중단을 초래하기 쉬움. x/authz 모듈의 MsgGrant 메시지 구조는 Grant 필드를 포함하며, 이는 사용자 정의 권한 부여의 만료 시간을 포함합니다. Grant 구조의 ValidateBasic() 검증 처리 과정에서 노드의 로컬 시간 정보가 아닌 블록 시간 정보와 비교하는데, 로컬 시간은 비결정적이므로 각 노드의 타임스탬프에 차이가 발생할 수 있으며, 이로 인해 합의 문제가 발생합니다.
취약점 공지:
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
타임스탬프와 같은 문제는 Cosmos 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
취약점 코드 조각:
패치:
로컬 타임스탬프 사용을 블록 시간 사용으로 변경함.
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
취약점 배경: BandChain 프로젝트의 오라클 모듈
프로젝트 주소: https://github.com/bandprotocol/bandchain/
코드베이스의 주석에 따르면, 오라클 모듈은 처벌 조치를 위해 담보 전에 실행되어야 함. 코드에서 나타나는 순서는 SetOrderEndBlockers 함수에서 담보 모듈이 오라클 모듈보다 먼저 실행되는 것임. 만약 담보 모듈이 오라클 모듈보다 먼저 실행되면, 오라클 모듈에서 수행된 검증을 기
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
CertiK
