ScaleBit 심층 선정: 블록체인 생태계 내 보안 취약점과 공격 면을 분석한 한 편의 글 및 공격 표면 목록
블록체인 기술은 탈중앙화, 보안 및 신뢰 메커니즘 측면에서 큰 가능성을 보여주고 있지만, 그 생태계 내에는 여전히 다양한 보안 리스크가 잠재해 있습니다. L1/L2 간 크로스체인 통신의 다양한 취약점(예: 블록 롤백 미고려, 거래 실패 처리 부실, 경량 클라이언트 검증 결함)부터 Cosmos 앱 체인의 모듈 순서, 난수 사용, 거래 롤백 문제, 그리고 비트코인 확장 생태계 내 스크립트 구성, UTXO 처리, 롤백 등으로 인한 위험까지, 모두 블록체인 애플리케이션에 심각한 도전을 안겨줍니다. 또한 스마트 계약이나 일반 프로그래밍 언어에서 흔히 발생하는 정수 오버플로우, 무한 루프, 경쟁 조건, 예외 충돌 등의 오류는 시스템 가용성과 보안에 막대한 위협이 됩니다.
또한 P2P 네트워크 아키텍처의 취약성(Sybil 공격, Eclipse 공격)과 DoS 공격 역시 블록체인 시스템의 효율성과 신뢰성을 저해하며, 암호학적 취약점(안전하지 않은 해시 알고리즘, 약한 서명 알고리즘, 안전하지 않은 난수 생성 등)은 데이터 기밀성과 무결성에 위협을 가합니다. 장부 단계에서 트랜잭션 메모리풀, 고아 블록, 머클 트리 처리의 부실은 체인상 데이터 불일치나 자산 리스크를 유발할 수 있습니다. 마지막으로, 경제 모델 및 거버넌스 메커니즘 설계가 미흡할 경우 네트워크 인센티브 불균형 또는 분열을 초래하여 공격자가 이를 악용해 시스템 안정성을 훼손할 수 있습니다.
위와 같은 리스크들을 종합적으로 살펴보면, 지속적으로 진화하는 블록체인 생태계 내에서 보안성과 지속 가능한 발전을 보장하기 위해서는 깊이 있는 이해와 철저한 예방 조치가 필수적입니다. 2024년 말, ScaleBit의 모기업 BitsLab은 『2024 신생 생태 공개 블록체인 전반적 관찰 및 보안 연구 보고서』를 발표했습니다. 이 보고서는 현재 존재하는 다양한 보안 취약점과 공격 표면을 상세히 분석하며 실용적인 내용을 담고 있습니다. 본문은 해당 보고서 일부를 발췌하여 블록체인 생태계 내 핵심 보안 취약점 유형에 집중적으로 조명하고자 하며, 독자들이 사전에 대비하고 업계의 안전하고 건강한 발전을 함께 추진할 수 있도록 도움을 주고자 합니다.
보고서 원문 보기: https://bitslab.xyz/reports-page
1) 보안 취약점 유형 목록
1.1 L2/L1 크로스체인 통신 취약점
크로스체인 통신은 블록체인 생태계의 상호운용성을 높이는 중요한 수단이지만, 구현 과정에서 많은 보안 위험이 존재합니다. 다음은 주요 관심 사항들입니다:
L2가 L1의 블록 롤백을 고려하지 않음
L1 거래를 전송하거나 L1 체인 데이터를 가져올 때 이러한 상황을 고려하지 않으면 자산 손실이 발생할 수 있습니다.
L2가 L1로 전송된 거래의 성공 여부를 검사하지 않음
네트워크, 가스비 등의 문제로 인해 전송된 거래가 실패할 수 있습니다. 이러한 상황을 고려하지 않으면 프로젝트나 사용자의 자산 손실로 이어질 수 있습니다.
체인 상 이벤트 위조
크로스체인 브릿지가 체인 상 이벤트를 모니터링할 때, 해당 이벤트가 특정 컨트랙트 주소에서 발생했는지를 검증하지 않으면 다른 컨트랙트가 이벤트를 위조할 수 있습니다.
동일한 거래에 여러 개의 체인 상 이벤트 포함
하나의 거래는 여러 개의 이벤트를 포함할 수 있으며, 이를 고려하지 않을 경우 프로젝트나 사용자 자산 손실이 발생할 수 있습니다.
경량 클라이언트 검증 취약점
1. PoW 체인이 자체 채굴 공격을 고려하지 않음
2. 공식 권장 알고리즘을 채택하지 않음
중간자 공격
L2/L1 크로스체인 통신에서 메시지 전달 메커니즘은 매우 중요하며, 전달 중 메시지의 무결성과 기밀성을 보장해야 합니다. 서로 다른 체인 사이의 메시지 전달은 변조되거나 도청될 위험이 있으므로 정보 보안을 위해 암호화 수단을 사용해야 합니다. 또한 체인 간 메시지 전달 시 부인 불가능성을 보장하는 것도 중요하여 악의적인 변조를 방지해야 합니다.
지연 및 최종성 문제
크로스체인 통신은 종종 지연 및 최종성 문제에 직면합니다. 서로 다른 체인의 합의 메커니즘과 확인 시간이 다르기 때문에 크로스체인 거래의 확인 시간이 일치하지 않아 상태 업데이트 지연이 발생하며, 이는 잠재적인 보안 리스크를 증가시킵니다. 크로스체인 프로토콜 설계 시 최종성의 정의를 명확히 하고 거래 상태의 일관성을 보장하여 확인 지연으로 인한 이중 지불 공격이나 상태 불일치 문제를 방지해야 합니다.
1.2 Cosmos 앱 체인 취약점
Cosmos는 블록체인 상호운용성에 중심을 둔 생태계로서, IBC(크로스체인 커뮤니케이션 프로토콜)를 통해 서로 다른 블록체인이 연결될 수 있게 합니다. 그러나 Cosmos 앱 체인의 구현 과정에서도 몇 가지 취약점과 보안 위험이 존재할 수 있습니다. 다음은 주요 관심 사항들입니다:
BeginBlocker 및 EndBlocker 충돌 취약점
BeginBlocker와 EndBlocker는 모듈 개발자가 자신의 모듈에서 선택적으로 구현할 수 있는 메서드입니다. 각 블록의 시작과 끝에서 트리거됩니다. BeginBlock 및 EndBlock 메서드에서 오류 처리를 위해 충돌(crash)을 사용하면 오류 발생 시 체인이 작동 중단될 수 있습니다.
로컬 시간 부정확한 사용
다른 노드들의 로컬 시간은 차이가 있을 수 있으므로, 합의 생성 시 이를 고려하지 않으면 합의 문제를 일으킬 수 있습니다.
참고 자료:
출처
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
난수 부정확한 사용
다른 노드들이 생성하는 난수가 다를 수 있으므로, 합의 생성 시 이를 고려하지 않으면 합의 문제가 발생할 수 있습니다.
Map 반복 기능의 부정확한 사용
Go 언어의 map 반복은 비결정적이므로, 합의 생성 시 이를 고려하지 않으면 합의 문제가 발생할 수 있습니다. 아래는 예시 코드입니다:
모듈 순서 부적절로 인한 문제
Cosmos 앱 체인은 여러 모듈로 구성되어 있으며, 특정 이벤트 처리 시 모듈 간 순서가 존재합니다. 순서 설정이 부적절하면 보안 문제가 발생할 수 있습니다.
거래 실패 시 데이터 롤백 미처리
Cosmos 앱 체인에서 거래 실행이 실패하더라도 설계상 결함으로 인해 데이터 상태가 거래 이전 상태로 되돌아가지 않으면 체인상 데이터 불일치가 발생할 수 있습니다. 이는 사용자 신뢰를 해칠 뿐 아니라 자금 손실도 초래할 수 있습니다. 따라서 스마트 계약이 실패한 거래를 적절히 처리하여 상태 일관성과 신뢰성을 보장하고, 필요 시 자동 롤백 메커니즘을 구현해야 합니다.
오류 상태 검증
Cosmos 앱 체인의 상태 검증 로직은 매우 엄격해야 합니다. 상태 검증이 부정확하면 불법 거래가 승인되어 체인 보안에 영향을 줄 수 있습니다. 개발자는 상태 전이 로직을 신중하게 설계하고 포괄적인 테스트를 수행하여 오류 상태 검증으로 인한 취약점을 방지해야 합니다.
크로스체인 메시지 전달 보안
Cosmos의 IBC 메커니즘은 서로 다른 앱 체인 간 메시지 전달을 가능하게 하지만, 이는 잠재적인 보안 리스크도 동반합니다. 예를 들어 크로스체인 메시지가 전달 중 변조되면 잘못된 상태 업데이트나 공격자가 해당 메시지를 악용한 악의적 조작이 발생할 수 있습니다. 메시지의 무결성과 진위성을 보장하기 위해 암호화 및 서명 메커니즘을 적용하여 전달 중 변조를 방지해야 합니다.
컨트랙트 업그레이드 및 버전 관리 문제
Cosmos 앱 체인의 컨트랙트는 사용 중 업그레이드가 필요할 수 있으나, 부적절한 업그레이드는 이전 컨트랙트 상태의 호환성 문제나 보안 취약점을 초래할 수 있습니다. 개발자는 명확한 컨트랙트 업그레이드 전략을 수립하여 버전 관리 및 마이그레이션 계획을 포함시키고, 업그레이드 과정에서 체인 정상 작동에 영향을 주지 않도록 해야 합니다.
경제 모델 및 인센티브 메커니즘
Cosmos 생태계의 경제 모델 설계는 체인의 보안성과 안정성에 직접적인 영향을 미칩니다. 인센티브 메커니즘이 부적절하게 설정되면 참여자 행동의 불균형이나 악의적 행위, 경제 공격이 발생할 수 있습니다. 경제 모델을 포괄적으로 평가하여 인센티브 메커니즘이 네트워크 보안성과 건강성을 효과적으로 유지할 수 있도록 해야 합니다.
거버넌스 메커니즘의 취약점
Cosmos 앱 체인의 거버넌스 메커니즘은 보유자가 체인 결정에 참여할 수 있게 하지만, 거버넌스 메커니즘이 부적절하게 설계되면 거버넌스 공격이나 중앙집권화 문제가 발생할 수 있습니다. 거버넌스 메커니즘의 공정성과 투명성을 보장하여少数가 체인 의사결정 과정을 조작하는 것을 방지해야 합니다.
1.3 비트코인 확장 생태계 취약점
비트코인 스크립트 구성 취약점
비트코인 스크립트는 대부분 실시간 생성되어 비트코인에 배포되며, 스크립트 내용은 사용자가 제공한 데이터를 포함합니다. 스크립트 구성이 안전하지 않으면 자산 손실이 발생할 수 있습니다.
파생 자산 미고려로 인한 취약점
흔한 비트코인 파생 자산으로 인스크립션과 룬이 있습니다. L2가 사용자 자산을 조작할 때 원생 BTC만 고려하고 파생 자산을 고려하지 않으면 사용자 자산 손실이 발생할 수 있습니다.
UTXO 금액 계산 오류 취약점
1. 거래 수수료 계산 실수
2. 거스름돈 금액 계산 실수
예를 들어 아래 코드에서는 거스름돈 출력 계산에 조건이 포함되어 있습니다. 즉, 거스름돈 금액이 546사토시 이상일 경우에만 거스름돈 출력을 추가합니다. 이 값은 전통적인 P2PKH 거래의 더스트 제한(dust limit)에 해당합니다. 그러나 서로 다른 주소 유형의 더스트 제한은 다릅니다. 특히 Taproot 주소의 경우 더스트 제한이 330사토시입니다.
이 하드코딩된 값은 Taproot 주소의 낮은 더스트 제한을 고려하지 않아 Taproot 주소 관련 거래에서 소액 자산 손실을 초래할 수 있습니다. 다양한 주소 유형의 더스트 제한에 대한 자세한 정보는 Bitcoin Core 소스 코드와 BitcoinTalk 포럼 토론에서 확인할 수 있습니다.
https://bitcointalk.org/index.php?topic=5453107.msg62262343#msg62262343
UTXO가 "op_return" 포함 여부 미검사
"op_return"을 포함한 UTXO는 사용할 수 없습니다.
SPV 검증 취약점
1. 블록 헤더 타임스탬프 미검증
2. 블록 헤더 작업 증명 미검증
롤백 상황 미고려
비트코인은 PoW 기반으로 자주 블록 재구성이 발생합니다. 비트코인 거래를 전송하거나 비트코인 체인 데이터를 가져올 때 이러한 상황을 고려하지 않으면 자산 손실이 발생할 수 있습니다.
비트코인 거래 성공 여부 미확인
비트코인 거래가 전송된 후 반드시 채굴자가 패키징할 것이라는 보장은 없습니다. 따라서 거래가 체인에 성공적으로 올라갔는지 확인해야 합니다. 또한 제3자가 더 높은 거래 수수료를 가진 거래를 생성하여 L2가 전송한 거래가 오랫동안 거래 메모리풀에 머물며 패키징되지 못하게 할 수 있습니다.
절대 시간 잠금과 상대 시간 잠금 혼동 취약점
비트코인 스크립트를 구성할 때 두 종류의 시간을 혼동하면 심각한 경우 자산 손실이 발생할 수 있습니다.
해시 시간 잠금 계약(HTLC)의 시간 설정 부적절
흔한 사례는 다음과 같습니다:
1. 시간 설정이 너무 큼
2. 시간 설정이 너무 작음
3. L1과 L2의 시간 동기화 실패
1.4 프로그래밍 언어 일반 취약점 유형
1.4.1 정수 오버플로우
정수 오버플로우는 값이 해당 타입이 표현할 수 있는 범위를 초과할 때 발생하여 값이 순환하거나 논리 오류를 일으켜 프로그램 데이터의 정확성에 영향을 줍니다. Rust는 디버그 모드에서 오버플로우를 자동으로 감지하며, Go는 수동으로 범위 검사를 추가해야 합니다.
1.4.2 무한 루프
무한 루프란 프로그램이 특정 조건에서 무한 반복에 들어가 시스템 자원을 소모하여 프로그램이 멈추거나 응답하지 않는 현상을 말합니다. 이를 방지하려면 적절한 루프 종료 조건을 설정하고, Rust의 타임아웃 메커니즘 또는 Go의 context 패키지를 사용하여 장시간 실행되는 루프를 제어해야 합니다.
1.4.3 무한 재귀 호출
무한 재귀 호출이란 재귀 함수에 종료 조건이 없어 스택 오버플로우를 일으키고 충돌을 유발하는 것을 말합니다. 재귀에 명확한 기본 조건을 두고 필요에 따라 재귀 깊이를 제한하면 이를 효과적으로 방지할 수 있습니다.
Rust는 디버그 정보에서 스택 오버플로우 오류를 아래와 같이 출력합니다:
1.4.4 경쟁 조건
여러 스레드가 공유 자원에 동기화 없이 접근할 경우 데이터 경쟁이 발생하여 데이터 불일치를 초래합니다. Rust는 소유권 메커니즘과 스레드 안전 라이브러리를 통해 경쟁 조건을 방지하며, Go는 channel과 sync 패키지를 통해 동시성을 지원합니다.
다음은 안전하지 않은 Rust(Unsafe Rust) 예시로, 두 스레드가 동시에 동일한 공유 변수에 접근하고 수정하여 정의되지 않은 동작을 유발합니다. 이 코드는 동기화 메커니즘 없이 공유 자원을 보호하지 않아 데이터 경쟁을 일으킵니다:
Safe Rust는 데이터 경쟁을 방지하지만, 논리적 경쟁은 여전히 발생할 수 있습니다. 논리적 경쟁 조건(Race Condition)이란 특정 실행 순서에서 예기치 않은 동작을 하는 코드를 의미하며, 이는 논리적 경쟁입니다. 예를 들어 다음 시나리오에서:
1. 시간에 민감한 작업: 두 스레드 간 작업 순서가 최종 논리 결과에 영향을 줄 수 있습니다. 예:
a. 한 스레드가 어떤 조건이 성립하는지 확인하는 동안 다른 스레드가 그 조건을 변경합니다. Rust에서는 Arc<Mutex<T>>와 같은 동기화 메커니즘을 통해 접근 순서를 조정할 수 있지만, 논리적 경쟁 조건 자체는 방지할 수 없습니다.
2. 더블 체크 잠금(Double-Checked Locking): 여러 스레드가 공유 자원 초기화를 시도하면서 모두 자원이 초기화되지 않았다고 판단하면 논리적 오류가 발생할 수 있습니다. 이 경우 데이터 경쟁은 발생하지 않지만 예기치 않은 논리적 오류가 발생할 수 있습니다.
3. 부적절한 잠금 순서: 여러 잠금을 사용할 때 스레드가 일관되지 않은 순서로 잠금을 획득하면 교착 상태(deadlock)가 발생할 수 있습니다. Rust의 타입 시스템은 이러한 유형의 교착 상태 경쟁 조건을 방지하지 못합니다.
다음은 Safe Rust의 조건 경쟁 취약점 시연입니다. 이 예시에서:
● 두 스레드가 각각 공유 변수 data에 1씩 더합니다. 각 스레드는 data를 잠근 후 값을 증가시킵니다.
● 연산이 단계별로 완료되기 때문에, 데이터가 Mutex로 보호되고 있더라도 스레드 1과 스레드 2의 실행 순서가 최종 출력 결과에 영향을 줍니다. 이론적으로 최종 값은 2가 되어야 하지만, 특정 스레드의 출력 순서는 고정되지 않을 수 있습니다.
1.4.5 예외 충돌
예외 충돌은 처리되지 않은 오류로 인해 프로그램이 예기치 않게 종료되는 현상입니다. Go는 defer/panic/recover를 사용하여 예외를 포착하며, Rust는 Result와 Option 타입 시스템을 사용하여 더욱 견고한 오류 처리를 제공합니다.
다음은 panic을 포착하지 않아 프로그램이 충돌하는 예시입니다:
1.4.6 나누기 0 취약점
나누기 0 취약점은 프로그램이 나눗셈 연산 시 분모가 0일 경우 발생하며, 예외나 충돌을 유발할 수 있습니다. 나눗셈 전 분모 값을 점검하여 0 연산을 방지하고 프로그램 안정성을 보장하는 것이 좋습니다.
1.4.7 형변환
형변환 오류는 안전하지 않거나 호환되지 않는 변환으로 인해 예측할 수 없는 동작을 일으킵니다. Go와 Rust는 변환 시 타입 불일치를 알리며, Rust는 형변환에서 더 엄격하여 “as” 연산자를 명시적으로 사용해야 합니다.
다음 예시 코드에서 사용자는 amount만큼의 토큰 유동성을 추가하고 시스템이 유동성 수량을 기록합니다. 만약 amount = (u128::MAX << 64) | 1이라면 실제로는 1의 토큰만 지불했지만, 유동성 잔액은 340282366920938463444927863358058659841로 기록됩니다.
1.4.8 배열 범위 초과
배열 범위 초과란 배열의 유효하지 않은 인덱스 위치에 접근하여 메모리 접근 오류나 프로그램 충돌을 일으키는 현상입니다.
다음 예시 코드는 배열 범위 초과로 인한 프로그램 충돌을 보여줍니다:
1.5 p2p 네트워크 취약점
P2P(피어 투 피어) 네트워크는 블록체인 시스템에서 분산 노드 간 직접 연결 및 통신을 위한 것입니다. P2P 네트워크는 탈중앙화 시스템에 네트워크 기반을 제공하지만, 일련의 보안 취약점과 공격 리스크에도 직면합니다.
보안 측면에서 p2p 네트워크는 두 가지로 나눌 수 있습니다. 하나는 퍼블릭 네트워크로, L1에서 주로 사용됩니다. 다른 하나는 퍼미션 기반 네트워크로, L2에서 많이 사용됩니다.
퍼블릭 p2p 네트워크에서 많은 취약점 공격은 Sybil 공격을 기반으로 합니다. 퍼미션 기반 네트워크에서는 모든 노드가 신뢰할 수 있다고 가정할 수 없으며, 보안 관점에서 최소한 하나의 악의적 노드가 존재한다고 가정해야 합니다.
P2p 네트워크의 일반적인 취약점 유형은 다음과 같습니다:
1. 이형 공격(Heterogeneous Attack) 취약점:
이형 공격은 주소 풀 오염이라고도 하며, 동일한 유형의 체인 노드를 서로 침입하고 오염시키는 공격 방식입니다. 주된 원인은 동일한 유형의 체인 시스템이 통신 프로토콜에서 비동일 유형 노드를 식별하지 못한다는 것입니다.
이더리움 일부 동일 유형 체인에서 유사한 취약점이 발생한 바 있습니다. 이더리움 동일 유형 체인(즉, 이더리움 P2P discv4 노드 발견 프로토콜을 사용하는 공개 체인, 이더리움, 이더리움 클래식 포함)은 호환 가능한 핸드셰이크 프로토콜을 사용하여 노드가 동일 체인에 속하는지 여부를 구분할 수 없어 주소 풀이 서로 오염되고, 노드 통신 성능이 저하되며 결국 노드가 차단되는 현상이 발생합니다.
공격 과정은 다음 그림과 같습니다:
2. 신뢰 모델 메커니즘 부족
각 노드에 평판 점수를 부여하고 노드의 과거 행동에 따라 신뢰도를 조정합니다. 예를 들어 노드가 자주 무효 데이터를 보내면 평판을 낮춥니다. 높은 평판의 노드는 더 신뢰받으며, 낮은 평판의 노드는 제한을 받습니다.
3. 노드 수 제한 메커니즘 부족
새 노드 생성 속도나 각 IP의 연결 수를 제한하여 짧은 시간 내에 대량의 가짜 노드를 생성하는 것을 방지합니다.
4. 노드 발견 알고리즘 문제
노드 발견 및 선택 알고리즘은 P2P 네트워크에서 새로운 노드를 찾고 연결을 설정하는 역할을 합니다. 알고리즘 설계가 부적절할 경우, 예를 들어 거리 알고리즘이 균형을 이루지 못하면 네트워크 토폴로지 불균형이 발생하여 일부 노드가 과부하될 수 있습니다. 알고리즘의 균형성과 예측 불가능성을 보장하여 노드 분포의 보안성과 네트워크의 공격 저항력을 높여야 합니다.
다음 이미지는 네트워크 토폴로지 불균형의 극단적 사례를 보여줍니다:
5. 취약한 노드 선택 메커니즘
노드가 취약한 노드 선택 메커니즘을 사용하면 연결된 모든 다른 노드가 악의적 노드일 수 있어 Eclipse Attack이 발생할 수 있습니다. 다음은 일반적인 노드 선택 보안 메커니즘입니다:
무작위 노드 선택: 노드 연결 대상을 무작위화하여 공격자가 노드 연결 구조를 쉽게 제어하지 못하게 합니다.
국소 연결 전략: 노드가 물리적으로 또는 네트워크 토폴로지상 가까운 노드와 우선적으로 연결하도록 하여 공격자가 전체 네트워크에 침투하기 어렵게 만듭니다.
6. 신원 인증 부재
퍼미션 기반 p2p 네트워크에서는 노드의 신원을 검증해야 합니다.
7. 라우팅 테이블 정기 업데이트 메커니즘 부족
노드가 반환하는 데이터가 불법일 경우 라우팅 테이블에서 해당 기록 삭제를 고려해야 합니다.
노드는 정기적으로 라우팅 테이블에서 장기간 비활성 상태인 노드를 제거하고 새로운 노드로 교체하여 라우팅 테이블 실패로 인한 네트워크 고립을 방지해야 합니다.
8. 중간자 공격(MitM) 취약점
p2p 데이터 전송 중 데이터 무결성을 유지해야 합니다. 사용하는 암호화 알고리즘이 부적절하거나 결함이 있을 경우 데이터가 변조될 수 있습니다.
1.6 DoS 취약점
DoS(서비스 거부) 취약점은 시스템 자원을 고갈시켜 정상 사용자의 접근을 방해합니다. 주요 유형은 다음과 같습니다:
1. 메모리 고갈 공격
대량의 메모리 요구를 이용해 시스템을 무력화하며, 자원 상한선을 설정하여 방어하는 것이 좋습니다.
비교적 흔한 메모리 고갈 공격은 “zip 폭탄”입니다. zip 폭탄의 기본 원리는 매우 큰 0(또는 다른 값)으로 구성된 파일을 생성한 후 zip 파일로 압축하는 것입니다. 동일 내용 파일의 압축률이 매우 높기 때문에 생성된 zip 파일은 매우 작습니다. 공격 대상이 zip 파일을 해제하면 해제된 파일 저장을 위해 많은 메모리를 소비하게 되어 메모리가 빠르게 고갈되고 OOM으로 인해 충돌하게 됩니다.
다른 압축 알고리즘도 동일한 문제가 발생할 수 있습니다. 아래는 1GB 크기의 0으로 구성된 파일을 압축했을 때 일반 알고리즘의 압축률 목록입니다:
2. 디스크 고갈 공격: 쓸모없는 데이터를 써서 저장 공간을 가득 채우며, 디스크 할당량 관리로 자원 부족을 방지합니다.
디스크 고갈 공격의 일반적인 사례는 다음과 같습니다:
1. zip 폭탄. 공격 방법은 위의 “메모리 고갈 공격”과 동일하며, 다만 대상 프로그램이 zip을 메모리가 아닌 디스크에 해제한다는 점이 다릅니다.
2. 무료 또는 저비용으로 대량 데이터를 디스크에 쓰면 디스크 데이터가 고갈될 수 있습니다.
3. 커널 핸들 고갈 공격: 대량의 자원 요청으로 핸들이 고갈되는 현상으로, 핸들 할당을 제어하고 이상 징후를 모니터링하는 것이 좋습니다.
이 공격의 대략적인 원리는 공격자가 취약점을 통해 대상 노드의 커널 핸들이 고갈되거나 거의 고갈되게 하여 정상적인 서비스 요청에 응답하지 못하게 만드는 것입니다.
흔한 공격 중 하나는 “Socket 압력 공격”입니다. 대상 노드가 연결 수와 동시 접속 수를 제한하지 않으면 공격자가 대량의 연결 요청을 보내고 유지하여 시스템 Socket 자원을 고갈시킬 수 있습니다.
4. 지속적 메모리 누수: 메모리가 정상적으로 해제되지 않아 자원 고갈로 이어지며, 메모리 사용을 정기적으로 점검하여 문제 악화를 방지해야 합니다.
일반적으로 메모리 누수는 보안 취약점으로 간주되지 않습니다. 그러나 공격자가 대상 노드의 메모리 누수를 의도적으로 유발하고 이를 반복할 수 있다면, 시간이 지남에 따라 대상 노드 프로그램이 메모리 부족으로 충돌하게 될 수 있습니다.
1.7 암호학적 취약점
암호학적 취약점은 데이터 기밀성과 무결성을 파괴하여 시스템에 잠재적 보안 위협을 초래합니다. 주요 암호학적 취약점 유형은 다음과 같습니다:
이미 안전하지 않다고 입증된 해시 알고리즘 사용
해시 알고리즘은 데이터의 고유 식별자를 생성하여 무결성을 보장합니다. MD5 및 SHA-1과 같은 일반적인 해시 알고리즘은 충돌 위험이 있음이 입증되어 악의적 공격자에 의해 악용될 수 있습니다. 따라서 더 안전한 SHA-256 또는 SHA-3 등의 현대적 해시 알고리즘을 사용하고 알고리즘을 지속적으로 업데이트하여 해킹되기 쉬운 오래된 알고리즘으로 인한 데이터 무결성 리스크를 피해야 합니다.
안전하지 않은 커스텀 해시 알고리즘 사용
일부 프로젝트는 자체 정의 해시 알고리즘을 사용하는데, 일반적으로 이러한 알고리즘은 공개된 유명 알고리즘보다 안전하지 않습니다.
예를 들어 우리는 감사 과정에서 다음과 같은 커스텀 해시 알고리즘을 마주친 바 있습니다:
`hashCode` 함수는 암호화 해시 함수가 아니며 충돌이极易ly 발생합니다. 단순한 비트 연산과 덧셈만 수행합니다. 게다가 이 함수의 입력 길이와 출력 길이는 명확하고 예측 가능한 패턴을 따르므로 쉽게 역설계되고 해킹될 수 있습니다. 이러한 약한 해시 메커니즘으로 인해 공격자는 동일한 `CONST_KEY_HASH` 값을 갖는 키를 쉽게 생성하여 API 인증 프로세스의 보안을 위협할 수 있습니다.
다음은 이러한 약한 해시 취약점을 활용하는 개념 증명(PoC) 코드입니다:
안전하지 않은 사용으로 인한 해시 충돌
흔한 사례는 HASH(A+B+C)=HASH(D+E)의 경우로, A+B+C=D+E 때문인데, 'A+B+C'와 'D+E'는 완전히 동일하지만 A, B, C, D, E는 각각 다릅니다.
안전하지 않은 디지털 서명 알고리즘 사용
디지털 서명 알고리즘은 데이터의 진위성과 출처를 검증하여 데이터 변조를 방지합니다. 초기 서명 알고리즘인 DSA와 RSA는 양자 컴퓨팅 위협 하에서 무효화될 수 있습니다. ECDSA 또는 EdDSA와 같은 현대적 서명 알고리즘을 사용하면 더 강력한 보안을 제공하여 데이터의 합법성과 위조 방지 능력을 보호할 수 있습니다. 특히 분산 시스템과 스마트 계약에서는 서명 알고리즘의 신뢰성이 매우 중요합니다.
안전하지 않은 암호화 알고리즘 사용
암호화 알고리즘의 강도는 데이터 기밀성에 직접적인 영향을 미치며, 약한 암호화 알고리즘(예: DES)은 공격자에 의해 쉽게 해독될 수 있습니다. AES-256과 같은 더 높은 비트 수의 대칭 암호화 알고리즘을 사용하고, 통신 중 TLS와 같은 종단 간 암호화를 구현하여 데이터 전송 보안을 보장하고 도청이나 변조를 방지하는 것이 좋습니다. 또한 키 관리가 철저히 이루어져 키 유출을 방지해야 합니다.
안전하지 않은 난수 생성 알고리즘 사용
난수 생성기는 많은 암호학적 작업의 기반이며, 특히 키, IV(초기화 벡터), 비대칭 암호화의 중요한 매개변수 생성 시 예측 불가능성을 보장하는 것이 중요합니다. 다음은 일반적인 보안 문제들입니다:
1. 안전하지 않은 난수 생성 알고리즘으로 인해 난수가 예측되거나 조작될 수 있음;
2. 퍼블릭 체인 상 난수 알고리즘은 기본적으로 난수 예측 리스크가 존재하며, 정보가 모두 공개되어 있기 때문에 난수를 예측할 수 있습니다.
3. 안전하지 않은 난수 생성 알고리즘으로 인해 난수의 무작위성이 매우 낮아져 일부 취약점이나 문제(예: 채굴자 블록 생성) 발생 확률이 증가할 수 있음.
안전하지 않은 난수 시드 사용
난수 시드가 유출되거나 무차별 대입 공격으로 유출되어 난수 예측이 가능해짐;
암호학적 사이드채널 공격
사이드채널 공격은 시스템의 물리적 특징(예: 전력 소비, 실행 시간, 캐시 등)을 모니터링하여 민감한 정보를 추출합니다. 이 공격은 알고리즘 자체의 보안을 우회하며, 특히 하드웨어 장치 및 임베디드 시스템에서 더 흔합니다. 방어 수단으로는 알고리즘 구현을 최적화하여 실행 시간과 전력 소비를 일정하게 유지하고 유출 가능한 특징을 줄이는 것입니다. 또한 마스킹 및 혼동 기술을 통해 사이드채널 정보 유출 가능성을 낮출 수 있습니다.
서명 연장성(Signature Malleability)
서명 연장성이란, 서명 내용을 변경하지 않고 기존의 유효한 서명으로부터 또 다른 다른 유효한 서명을 도출해낼 수 있는 특성을 말합니다. 이 특성으로 인해 발생하는 주요 리스크는 거래 연장성으로, 악의적 사용자가 다른 서명 변형을 이용하여 거래 재생을 할 수 있다는 점입니다. 재생된 거래는 서명이 다르기 때문에 해시값도 다르며, 거래 확인 과정에서 사용자가 거래 상태를 혼동하게 만들고 이중 지불을 실현할 수 있습니다.
1.8 장부 보안 취약점
거래 메모리풀 취약점
1. 거래 재생 가능
2. 실패한 거래에 대해 수수료 미공제
블록 해시 충돌 취약점
블록 구성 방식에 문제가 있을 경우 충돌이 발생할 수 있습니다.
고아 블록 처리 로직 취약점
고아 블록은 직접 폐기할 수 있지만, 캐시할 경우 높이, 시간 등의 제한 조건을 추가해야 합니다.
머클 트리 해시 충돌 취약점
머클 트리 리프 노드의 구성 방식에 문제가 있을 경우 충돌이 발생할 수 있습니다.
거래 금액 처리 문제
거래 금액 처리 시 상하한 오버플로우, 타입 불일치, 정밀도 오차, 음수 발생, 외부 조건 변화로 인한 예기치 않은 값 발생
거래 수수료 처리 문제
거래 수수료 처리 시 상하한 오버플로우, 타입 불일치, 정밀도 오차, 음수 발생, 외부 조건 변화로 인한 예기치 않은 값 발생
블록 및 거래 검증 시간 과민
다른 노드의 시간이 오차를 가지므로 시간 검증이 지나치게 민감하면 쉽게 블록 포크를 유발할 수 있습니다.
거래 서명 권한 로직 문제
주로 다음 두 가지를 포함합니다:
1. 신원 위조 우회
2. 권한 검사 오류
1.9 경제 모델 취약점
경제 모델은 블록체인 및 분산 시스템에서 중요한 역할을 하며, 네트워크의 인센티브 메커니즘, 거버넌스 구조, 전반적 지속 가능성에 영향을 미칩니다. 주요 관심 사항은 다음과 같습니다:
Cosmos 앱 체인의 경제 모델(예: UniChain)
Cosmos의 앱 체인은 블록체인 상호운용성과 확장성을 핵심으로 하는 경제 모델을 채택하고 있습니다. UniChain을 예로 들면, 해당 경제 모델 설계는 체인상 토큰 유통 및 사용뿐만 아니라 다양한 애플리케이션 시나리오의 수요도 고려합니다. Cosmos SDK를 활용함으로써 UniChain은 앱 특화 블록체인을 생성하고 크로스체인 커뮤니케이션을 실현하여 서로 다른 체인 간 자원 공유 및 가치 흐름을 촉진할 수 있습니다. 경제 모델은 토큰 발행량, 인플레이션율, 거래 수수료 구조, 체인상 거버넌스 메커니즘 등을 주목하여 생태계의 안정과 번영을 보장해야 합니다.
인센티브 메커니즘의 합리성
인센티브 메커니즘은 경제 모델의 핵심 요소로, 사용자와 노드의 참여도에 직접적인 영향을 미칩니다. 합리적인 인센티브 메커니즘은 채굴자, 검증자, 개발자, 사용자 등 모든 참여자가 공정한 보상을 받을 수 있도록 해야 합니다. 인센티브 구조의 지속 가능성을 평가하여 악의적 행위와 중앙집권화 추세를 효과적으로 방지해야 합니다. 또한 인센티브 메커니즘은 시장 변화에 적응하여 네트워크 성숙과 사용자 수요 변화에 따라 조정되어야 합니다. 예를 들어 적절한 보상 및 처벌 메커니즘이 있는지, 단기 및 장기 인센티브를 어떻게 균형 있게 조율하는지 등은 심층적으로 분석해야 할 문제입니다.
네트워크 경제학의 지속 가능성
경제 모델은 네트워크의 장기적 지속 가능성도 고려해야 하며, 생태계 내 각 당사자의 경제 인센티브, 가치 창출 및 그 분배 관리에 주목해야 합니다. 경제 불균형이나 자원 낭비가 존재하는지 평가하여 모든 참여자가 네트워크 내에서 합리적인 가치를 얻을 수 있도록 해야 합니다. 또한 시장 변동성과 사용자 행동 변화와 같은 네트워크 안정성에 영향을 줄 수 있는 외부 요인을 분석해야 합니다.
시장 피드백 메커니즘
경제 모델이 사용자 수요와 시장 역학에 따라 조정될 수 있도록 효과적인 시장 피드백 메커니즘을 구축해야 합니다. 정기적인 데이터 분석과 사용자 피드백을 통해 잠재적 문제를 신속히 식별하고 수정하여 경제 모델의 유연성과 적응성을 보장할 수 있습니다.
거버넌스 구조의 영향
경제 모델 설계는 거버넌스 구조와 결합되어야 하며, 사용자가 거버넌스 과정에서 경제적 의사결정에 참여할 수 있도록 하여 커뮤니티의 참여감과 소속감을 강화해야 합니다. 합리적인 거버넌스 메커니즘은 경제 모델의 자가 치유 및 지속적 최적화를 촉진하여 네트워크 전반의 건강도를 높일 수 있습니다.
블록체인 생태계 내 존재하는 다양한 보안 취약점 유형을 깊이 이해한 후, 다음 단계는 이러한 취약점이 악용될 수 있는 구체적인 공격 표면을 탐색하는 것입니다. 공격 표면이란 잠재적 공격자가 시스템에 침입하고 경로를 이용할 수 있는 부분을 의미하며, 이러한 공격 표면을 식별하고 분석함으로써 리스크를 더욱 효과적으로 평가하고 적절한 방어 전략을 수립할 수 있습니다. 따라서 취약점 유형과 공격 표면 간의 관계를 포괄적으로 이해하는 것은 견고한 블록체인 보안 방어선을 구축하는 데 매우 중요합니다. 다음은 현재 블록체인 생태계에서 흔한 공격 표면을 상세히 나열하여 독자들이 위협의 구체적 실현 방식을 더 잘 이해할 수 있도록 도와줄 것입니다.
2. 공격 표면 목록
다음은 일반적인 공격 표면 목록입니다:
4.1 가상 머신
공격 표면: 가상 머신은 스마트 계약을 실행하고 바이트코드를 처리하며, 일반적으로 복잡한 로직을 많이 포함하고 있어 재진입 공격, 정수 오버플로우, 메모리 오버플로우 등의 잠재적 리스크가 있습니다. 또한 계산 소모가 많은 스마트 계약은 DoS 공격을 유발하여 자원 고갈을 초래할 수 있습니다. 또한 스마트 계약의 바이트코드에 감사되지 않은 취약점이 포함되어 있으면 임의 코드 실행 및 권한 상승 등의 리스크를 초래할 수 있습니다.
4.2 P2P 노드 발견 및 데이터 동기화 모듈
공격 표면: P2P 노드의 발견 및 동기화 기능이 부적절하게 설계된 경우, 시빌 공격(Sybil Attack)에 쉽게 노출되어 대량의 가짜 노드를 위조하여 네트워크를 장악하고 네트워크 성능 저하 또는 무효화를 유발할 수 있습니다. 노드 데이터 동기화 과정에서의 라우팅 테이블 오염은 노드 간 연결 품질에 영향을 미쳐 일부 노드를 사용할 수 없게 만들 수 있습니다. 또한 데이터 패킷에 위조되거나 악의적인 데이터가 포함되어 노드가 잘못된 정보를 수신하여 동기화 및 합의에 영향을 줄 수 있습니다.
4.3 블록 파싱 모듈
공격 표면: 블록 파싱은 대량의 데이터 처리를 포함하며, 파싱 코드에 오버플로우나 오류 처리 부재가 있을 경우 악의적인 블록 공격으로 인해 서비스 충돌 또는 서비스 거부(DoS)가 발생할 수 있습니다. 또한 부정확한 블록 형식 검사는 네트워크를 통해 전송된 블록이 변조되었음에도 불구하고 인식하지 못하게 하여 전망 일관성에 영향을 줄 수 있습니다.
4.4 거래 파싱 모듈
공격 표면: 거래 파싱은 거래 구조 및 서명을 검증하는 과정을 포함하며, 위조된 거래 형식, 악의적인 데이터 또는 이상한 서명 처리가 부적절할 경우 허위 거래가 승인되어 시스템 자원을 소모할 수 있습니다. 또한 거래 파싱에 경계 오버플로우 문제가 있을 경우 메모리 주입 공격을 실행하는 데 악용될 수 있습니다.
4.5 거래 메모리풀
공격 표면: 메모리풀은 거래가 체인에 올라가기 전의 임시 저장 공간으로, 대량의 무효 거래 또는 악의적 거래를 삽입하여 메모리 사용 공격을 유발하고 노드가 정상 요청에 응답하지 못하게 할 수 있습니다. 또한 악의적 공격자는 거래 메모리풀에 중복되거나 고빈도 거래를 삽입하여 자원 고갈 및 DoS 리스크를 더욱 가중시킬 수 있습니다.
4.6 합의 프로토콜 모듈
공격 표면: 합의 메커니즘이 부적절하게 설계되거나 조작될 경우 이중 지불 공격, 이기적 채굴, 51% 공격 등의 문제가 발생할 수 있습니다. 공격자는 계산 능력의 절반 이상을 장악하여 악의적인 포크를 실행하고 거래 기록의 합법성에 영향을 줄 수 있습니다. 또한 일부 합의 메커니즘은 고지연 또는 분할 네트워크 환경에서 명확한 오류 허용 메커니즘이 부족하여 무효화될 수 있습니다.
4.7 RPC 인터페이스
공격 표면: RPC 인터페이스는 외부와 블록체인 노드 간 상호작용의 경로로, 접근 권한 구성이 부적절할 경우 무단 접근 및
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@scalebit_
