Web3 공격 표면: 침투 테스트 개요

이 시리즈의 처음 세 개의 글에서는 암호화폐 기관이 왜 블록체인 침투 테스트를 필요로 하는지(Part 1), 이 분야가 무엇을 검증하는지(Part 2), 그리고 기관 차원의 참여를 어떻게 안전하게 준비하고 진행할 수 있는지(Part 3)를 다루었습니다.

이 글에서는 web3 기관을 대상으로 한 침투 테스트와 관련된 공격 표면을 개괄적으로 살펴보며, 특히 필요한 커버리지가 전통적인 침투 테스트 표면을 넘어 어떻게 확장되는지에 특별히 주목합니다 [1]. 구체적으로, 먼저 web3 기관을 위한 4개 구성요소 모델을 정의하고, 각 구성요소의 책임, 대표 사례, 주요 공격 표면을 함께 제시합니다. 이 모델을 바탕으로, 서명 의도, 승인 및 서명 워크플로우, 자금 로직, 온체인 런타임 동작에서 상속된 애플리케이션 및 인프라 노출과 web3 고유의 검증 지점을 연결하는 다섯 가지 공격 표면 영역을 살펴봅니다.

web3 기관의 구성요소

중앙화 거래소, 결제 제공업체, DeFi 프로젝트를 포함한 web3 기관들은 기존의 애플리케이션 및 인프라 환경을 오프체인에서 온체인으로 이어지는 자금 처리 체인과 연결합니다 [2]. 이들은 전통적인 침투 테스트 표면을 유지하면서도, 거래 의도, 서명 권한, 자금 회계, 온체인 실행과 관련된 추가적인 검증 지점을 도입합니다. 이러한 표면들이 어떻게 상호작용하는지, 그리고 어떤 조건이 가치로 이어지는 경로를 형성할 수 있는지를 파악하려면 web3 보안에 대한 전문적인 판단이 필요합니다.

이렇게 확장된 공격 표면을 체계적으로 살펴보기 위해, 이 섹션에서는 애플리케이션(Application), 인가 및 서명(Authorization and Signing), 블록체인 상호작용(Blockchain Interaction), **인프라(Infrastructure)**라는 4개 구성요소 모델을 정의합니다. 각 구성요소에 대해 해당 구성요소의 책임을 설명하고, 대표적인 구현 사례를 제시하며, 주요 공격 표면을 요약합니다. 서로 다른 web3 기관들은 이러한 구성요소들을 다양한 방식으로 결합하거나 외주화할 수 있다는 점에 유의해야 합니다.

구성요소 1: 애플리케이션(Application)

애플리케이션 구성요소는 정의된 비즈니스 및 인가 로직에 따라 사용자 또는 내부 운영자로부터의 요청을 처리하고, 인가된 의도를 자산 이체나 복구 작업과 같은 의도된 비즈니스 행위로 변환합니다. web3 기관에서 흔히 볼 수 있는 대표 사례로는 웹 및 모바일 애플리케이션, 브라우저 확장 프로그램, 백엔드 API 등이 있습니다.

일반적인 테스트 유형.

• 웹 애플리케이션 침투 테스트

• 모바일 애플리케이션 침투 테스트

• 브라우저 확장 프로그램 침투 테스트

• API 침투 테스트

애플리케이션 구성요소는 신원 및 세션 관리, 인가 및 격리, 비즈니스 워크플로우 및 상태 전이 무결성과 같은 전통적인 공격 표면을 상속받습니다. web3 기관에서는 이 단계에서 준비된 비즈니스 행위 또는 거래 의도가 이후 인가 및 서명 구성요소를 통해 승인되고, 블록체인 상호작용 구성요소를 통해 실행될 수 있습니다. 따라서 이러한 통제의 실패는 서비스 중단으로 이어지거나 직접적인 자산 손실로 확산될 수 있습니다.

구성요소 2: 인가 및 서명(Authorization and Signing)

인가 및 서명 구성요소는 애플리케이션 구성요소에서 준비된 거래 요청을 받아 온체인 제출에 필요한 암호화 서명을 생성합니다. 일부 구현에서는 서명을 생성하기 전에 서명 시스템 내에서 추가로 정책 또는 승인 검사를 수행하기도 합니다. web3 기관에서 흔히 볼 수 있는 대표 사례로는 지갑 및 서명 시스템 또는 서비스가 있습니다.

일반적인 테스트 유형.

• 신원 및 권한 있는 접근 테스트

• 서명 및 승인 워크플로우 테스트

인가 및 서명 구성요소가 상속받는 전통적인 공격 표면에는 권한 있는 신원 및 접근 관리, API 인가 및 직무 분리, 승인, 복구, 관리 워크플로우 무결성이 포함됩니다. web3 기관에서는 유효한 서명이 되돌릴 수 없는 상태 변경이나 자산 이체를 직접 승인할 수 있기 때문에, 이 구성요소의 실패가 특히 심각한 결과를 초래할 수 있습니다. 온체인 제출 이전의 최종 암호화 인가 단계로서, 인가 및 서명 구성요소는 사용되는 모든 곳에서 핵심적인 보증 우선순위로 다루어져야 합니다.

구성요소 3: 블록체인 상호작용(Blockchain Interaction)

블록체인 상호작용 구성요소는 사용자 또는 내부 운영자가 인가한 거래를 제출하고, 그 실행 상태를 확인하며, 그 결과로 발생하는 온체인 상태를 추적합니다. web3 기관에서 흔히 볼 수 있는 대표 사례로는 노드 또는 RPC 게이트웨이, 인덱서, 릴레이어가 있습니다.

일반적인 테스트 유형.

• API 및 RPC 침투 테스트

• 거래 제출 및 릴레이어 남용 테스트

블록체인 상호작용은 web3 운영에 특화된 역할을 수행하지만, 이 구성요소에 대한 침투 테스트는 상속받은 공격 표면인 서비스 자격 증명 및 엔드포인트 보안, RPC 및 API 인가, 메시지 및 이벤트 처리 무결성의 적대적 악용 가능성에 초점을 맞춥니다. 예를 들어 RPC 또는 릴레이어 동작이 악용될 수 있는지, 거래 제출이 조작될 수 있는지, 체인 이벤트가 잘못 해석될 수 있는지 등을 살펴봅니다. 맞춤형 또는 자체 호스팅 블록체인 노드를 운영하는 기관의 경우, 노드 및 클러스터의 정확성과 대규모 RPC 복원력—동기화, 거래 전파, 장애 조치, 가용성—은 침투 테스트가 아니라 Blockchain Security Testing에서 다루는 보완적인 관심사입니다 [2].

구성요소 4: 인프라(Infrastructure)

인프라 구성요소는 나머지 세 구성요소를 지원하거나 영향을 미치는 기관 고유의 인프라 및 운영 시스템을 포괄합니다. web3 기관에서 흔히 볼 수 있는 대표 사례로는 클라우드 플랫폼, 네트워크 인프라, IAM 및 비밀 관리 시스템, 소스 관리 및 CI/CD 시스템, 모니터링 플랫폼이 있습니다.

일반적인 테스트 유형.

• 외부 및 내부 네트워크 침투 테스트

• 클라우드 인프라 침투 테스트

• CI/CD 및 소프트웨어 공급망 테스트

인프라는 주로 네트워크 및 서비스 노출, 신원, 권한, 비밀 관리, 소프트웨어 배포 및 공급망 무결성과 같은 전통적인 공격 표면을 상속받습니다. 인프라는 일반적으로 자금 처리 행위를 직접 수행하지 않지만, 인프라의 실패나 침해는 상당한 자산 손실로 이어질 수 있습니다. Part 1에서 다룬 Bybit 및 TrustWallet 사건은 소프트웨어 배포 및 유통 채널의 침해가 어떻게 자금 처리 체인으로 확산될 수 있는지를 보여줍니다 [1].

web3 공격 표면

4개 구성요소 모델은 web3 기관에 대한 침투 테스트가 전통적인 애플리케이션 및 인프라 공격 표면의 상당 부분을 그대로 유지한다는 것을 보여줍니다. 차이는 자금 처리라는 맥락에 있습니다. 즉, 약점이 여러 구성요소에 걸쳐 확산되어 거래 의도, 서명, 자금 상태, 온체인 실행에 영향을 미칠 수 있다는 것입니다. 따라서 이러한 경로를 파악하고 적절한 검증 지점을 선정하려면 web3 보안에 대한 전문적인 판단이 필요합니다.

이러한 커버리지를 구조화하기 위해, 이 섹션에서는 Part 2에서 소개한 자금 처리 체인과 테스트 범위를 바탕으로 도출된 다섯 가지 주요 공격 표면 영역으로 web3 공격 표면을 분류합니다 [2]:

• 운영 환경 및 자동화 운영

• 웹 및 dApp 프론트엔드, 인가, 서명 의도

• 서명, 승인, 출금 인가 체인

• 자금 비즈니스 로직

• 온체인 거래 및 배포된 컨트랙트

운영 환경 및 자동화 운영

운영 환경은 자금 처리 체인의 모든 단계를 지원합니다. 전통적인 인프라, 신원, 소프트웨어 배포 관련 침투 지점이 자금을 직접 이동시키지는 않을 수 있지만, 애플리케이션의 동작을 변경하거나, 인가 및 서명에 도달하거나, 블록체인 상호작용에 영향을 미칠 수 있습니다. 따라서 블록체인 침투 테스트는 인프라 취약점을 고립된 종단점으로 취급하는 대신, 해당 침투 지점이 자금 처리 체인에 미칠 수 있는 도달 가능한 영향을 평가합니다 [2].

테스트 초점. 테스터는 접근, 배포, 비밀 정보, 운영 통제가 자금 처리 행위로 연결될 수 있는지를 검증합니다. 시나리오는 노출된 서비스, 침해된 신원, 워크로드 자격 증명, 빌드 토큰, 종속성, 또는 벤더 통합에서 시작하여, IAM, 세분화, 비밀 처리, 변경 통제, 서비스 인가가 추가적인 확산을 막을 수 있는지 평가할 수 있습니다. 그 결과로 나온 증거는 운영 침투 지점을 해당 지점이 영향을 미칠 수 있는 구성요소 및 가치 이동 행위와 연결해야 합니다.

상세 분석 [3]에서는 운영 환경의 침해가 배포 및 운영 통제를 통해 자금 처리 구성요소로 어떻게 확산될 수 있는지를 살펴봅니다.

웹 및 dApp 프론트엔드, 인가, 서명 의도

웹 및 dApp 프론트엔드는 사용자와 운영자가 자금 처리 행위를 시작하고 검토하며, 그 행위가 승인되는 인가 및 서명 흐름에 참여하는 주요 상호작용 계층입니다. 이러한 위치 때문에 프론트엔드는 피싱 및 프론트엔드 탈취의 매력적인 표적이 됩니다. 인터페이스를 장악하면 거래 요청이 지갑이나 서명 시스템에 도달하기 전에 그 맥락이나 내용을 조작할 수 있기 때문입니다 [1].

테스트 초점. 테스터는 사용자 또는 운영자에게 표시되는 거래가 최종적으로 인가되는 행위와 다를 수 있는지를 검증합니다. 이 평가는 애플리케이션 인증 및 인가에서부터 거래 구성, 지갑 표시, 서명, 제출에 이르기까지 요청을 추적하며, 세션 상태, 지갑 권한, 시뮬레이션, 체인 컨텍스트, 컨트랙트 컨텍스트, 또는 표시 로직이 의미를 변경할 수 있는지를 고려합니다. 증거는 표시된 행위, 실제 페이로드, 결과 서명, 제출된 동작을 보존해야 합니다.

상세 분석 [4]에서는 거래 의도가 애플리케이션 표시에서부터 지갑 인가를 거쳐 서명 또는 제출된 결과에 이르기까지 어떻게 추적되는지 살펴보며, 특히 행위의 의미가 달라질 수 있는 지점에 초점을 맞춥니다.

서명, 승인, 출금 인가 체인

서명은 종종 자금을 이동시키는 행위이지만, 암호화적 유효성만으로는 올바른 비즈니스 권한이 성립되지 않습니다. 보안 결과는 누가 요청을 시작했는지, 어떤 정책이 적용되었는지, 승인자가 무엇을 검토했는지, 그리고 페이로드가 변경되지 않고 유지되었는지에도 달려 있습니다. 이 통제 체인의 약점은 정당한 서명자가 의도하지 않은 행위를 인가하게 만들 수 있습니다 [2].

테스트 초점. 테스터는 신원, 역할, 정책 검사, 승인 단계가 우회되거나 결합될 수 있는지를 검증합니다. 시나리오는 하나의 신원이 행위를 시작하고 승인할 수 있는지, 목적지 또는 한도 변경이 독립적인 검토 없이 유효해지는지, 정책이 서명자 수준에서 강제되는지 아니면 인터페이스에서만 강제되는지, 또는 페이로드가 승인 이후 변경될 수 있는지를 평가할 수 있습니다. 증거는 테스트된 순서, 우회된 통제, 그리고 이로 인해 가능해진 미인가 행위를 문서화해야 합니다.

상세 분석 [5]에서는 기관의 승인 및 서명 워크플로우가 거래 시작부터 서명, 출금 실행에 이르기까지 비즈니스 권한을 보존하는지를 살펴봅니다.

자금 비즈니스 로직

수탁형 기관은 잔액, 채무, 그리고 가치의 방출 가능 여부를 판단하기 위해 오프체인 상태에 의존합니다. 따라서 서명 키나 스마트 컨트랙트가 침해되지 않았더라도, 의도하지 않은 입금 처리나 상태 전이가 직접적인 금전적 손실로 이어질 수 있습니다. 테스트는 개별 API가 구현된 대로 동작하는지 여부뿐만 아니라 경제적 불변량과 대사(reconciliation) 경로도 고려해야 합니다 [2].

테스트 초점. 테스터는 잔액, 한도, 대사, 출금 규칙, 상태 전이가 의도하지 않은 조건을 받아들이는지를 검증합니다. 시나리오는 입금이 예상된 가치 없이 처리되는지, 하나의 이벤트가 여러 건의 입금 처리를 발생시키는지, 정밀도 또는 동시성 문제가 잔액을 변경하는지, 또는 유효하지 않은 상태가 출금 가능해지는지를 검토할 수 있습니다. 증거는 단순한 기술적 결함뿐만 아니라 결과로 나타난 상태 전이와 재현 가능한 비즈니스 영향 경로를 포착해야 합니다.

상세 분석 [6]에서는 기관 워크플로우 전반에서 의도하지 않은 오프체인 자금 상태가 어떻게 생성, 확산, 출금 가능한 가치로 전환될 수 있는지를 살펴봅니다.

온체인 거래 및 배포된 컨트랙트

온체인 인계 지점은 오프체인 의도가 공개적인 런타임 동작으로 전환되는 곳입니다. 거래는 되돌릴 수 없을 수 있으며, 배포된 컨트랙트는 공개적으로 호출 가능하고 기관의 직접적인 통제 밖에 있는 시스템과 조합될 수 있습니다. 따라서 이 평가는 의도된 행위, 제출된 거래, 관찰된 실행, 기관이 해석한 상태 간의 관계를 보존해야 합니다 [2].

테스트 초점. 테스터는 기관의 온체인 상호작용이 적대적인 런타임 조건 하에서 어떻게 동작하는지를 검증합니다. 시나리오는 거래 필드가 구성, 서명, 제출 과정에서 변경될 수 있는지를 검토할 수 있습니다. 또한 RPC 또는 릴레이어 동작이 행위에 영향을 미치는지, 체인 이벤트가 올바르게 해석되는지, 배포된 권한, 업그레이드, 또는 프로토콜 조합이 예상 결과를 변경하는지도 평가할 수 있습니다. 증거는 제출된 거래, 관련 체인 컨텍스트, 관찰된 런타임 결과를 보존해야 합니다.

이 영역에서 침투 테스트는 적대적 런타임 상호작용과 거래 수준의 증거에 계속 초점을 맞춥니다. 코드 수준의 컨트랙트 보증은 Code Audit의 영역으로 남아 있으며, 노드 또는 클러스터의 정확성과 대규모 RPC 복원력은 Blockchain Security Testing의 영역으로 남아 있습니다 [2].

결론

블록체인 침투 테스트는 기존 평가에서 살펴보는 전통적인 애플리케이션 및 인프라 공격 표면을 그대로 유지합니다. 이를 구별 짓는 것은 이러한 진입 지점을 넘어 기관의 자금 처리 체인 전반에 걸쳐 약점을 추적해야 할 필요성이며, 이 체인에서는 요청 처리, 인가, 소프트웨어 배포, 인프라의 실패가 암호화 서명, 자금 상태, 온체인 실행에 영향을 미칠 수 있습니다.

이러한 관계를 명확히 하기 위해, 이 글에서는 4개 구성요소 모델을 사용합니다: 애플리케이션은 비즈니스 행위를 준비하고, 인가 및 서명은 서명을 생성하며, 블록체인 상호작용은 거래를 제출하고 결과를 해석하며, 인프라는 나머지 구성요소들을 지원하거나 영향을 미칩니다. 또한 다섯 가지 공격 표면 영역은 web3 보안에 대한 전문적인 판단이 가장 중요한 지점, 특히 거래 의도, 서명 권한, 자금 로직, 온체인 런타임 동작 사이의 경계를 짚어줍니다.

이어지는 네 편의 후속 가이드는 이 개요를 확장하여 애플리케이션 인가 및 서명 의도, 클라우드 및 CI/CD 보안, 트레저리 통제, 거래소 원장 로직에 대한 전문적인 분석을 다룰 예정입니다. 온체인 거래 및 배포된 컨트랙트는 이 개요에서 계속 다룹니다.

BlockSec은 구성요소, 소유자, 자금 흐름, 신뢰 경계를 매핑하고, 공격자 관점을 선택하며, 안전한 증거를 정의하고, 중요한 잠재적 경로를 검증함으로써 기관이 4개 구성요소 모델과 다섯 가지 공격 표면 영역을 테스트 가능한 범위로 전환하도록 돕습니다. 다음 참여를 위한 공격 표면 범위를 설정하려면 스코핑 미팅을 요청하세요. 더 자세한 정보는 요청 시 제공됩니다.

이 시리즈의 다음 글도 곧 게시될 예정입니다:

• Part 5: Authorization and Signing Security: Web, dApps, and
• Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
• Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
• Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

Blockchain Penetration Testing 필러 페이지에서는 참여 수준의 전체 개요를 제공합니다.

참고 문헌

처음 등장한 순서대로 번호가 매겨져 있습니다.

1. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
2. BlockSec, What Is Blockchain Penetration Testing? Definitions and Boundaries.
3. BlockSec, 곧 게시 예정.
4. BlockSec, 곧 게시 예정.
5. BlockSec, 곧 게시 예정.
6. BlockSec, 곧 게시 예정.