CertiK: 블록체인 탐색기가 DoS 공격으로부터 자신을 보호하는 방법은?
브라우저라고 하면 떠오르는 것은 다들 “바이두로 검색하면 알게 된다”, “서칭은 소구에서 시작된다”는 등의 문구일 것이다.
이처럼 누구나 아는 유명한 브라우저들은 인터넷의 얼굴이자, 인터넷 진입의 관문 역할을 해왔다.
하지만 오늘날 인터넷과 어깨를 나란히 하는 기술이라면 바로 급성장하고 있는 블록체인 기술이다.
인터넷이 삶을 바꾸고, 블록체인 기술은 인터넷을 바꾼다. 따라서 인터넷의 입구인 브라우저 역시 블록체인 기술과 무관할 수 없다. 이에 따라 등장한 것이 바로 블록체인 브라우저이며, 이는 익숙한 형태의 실용 제품으로 블록체인 사용자들에게 상당한 편의를 제공하고 있다.
블록체인 브라우저의 보안성은 어떨까?
블록체인 브라우저는 블록체인의 검색 엔진으로, 사용자는 이를 통해 블록체인상 특정 정보를 탐색할 수 있다.
예를 들어, Etherscan은 이더리움 블록체인 브라우저로, 사용자가 이더리움 상의 블록, 주소, 거래 내역 및 기타 활동 정보를 쉽게 확인할 수 있도록 한다. 즉, 블록체인 브라우저는 일종의 공식적인 블록체인 조회 사이트라고 볼 수 있다.
현재 대부분의 블록체인 애플리케이션이 보안 위협에 직면해 있는 상황에서, 블록체인 브라우저의 보안성은 어느 정도일까?
블록체인 브라우저 애플리케이션은 비교적 공격 가능한 지점이 적은 편이다. 그 이유는 다음과 같다:
사용자 인증이나 권한 부여 과정이 없어 개인정보 유출 가능성이 낮다;
Vue와 React 같은 웹 프레임워크의 보편화로 XSS(사이트 간 스크립팅) 취약점 발생 가능성이 감소했다;
그럼에도 불구하고, 블록체인 브라우저는 공격 대상이 되지 않을까?
혹은 공격받더라도 아무런 문제가 없을까?
정답은 ‘아니다’.
블록체인 브라우저의 공격 유형 분류
먼저 블록체인 브라우저가 어떤 유형의 공격에 노출될 수 있는지 살펴보자.
대부분의 블록체인 브라우저 기능은 백엔드 데이터베이스 또는 블록체인 노드로부터 데이터를 검색하거나 조회하는 데 집중되어 있다. 이런 검색 기능에는 일반적으로 두 가지 취약점이 존재할 수 있다:
SQL 인젝션;
DoS(서비스 거부 공격, Denial-of-service);
그러나 다양한 브라우저들을 조사한 결과, CertiK 기술팀은 SQL 인젝션 사례는 단 한 건만 발견했으며, 반면 50% 이상의 블록체인 브라우저가 DoS 공격에 취약한 상태였다.
DoS 공격이란 무엇인가?
쉽게 설명하자면, 어떤 백발노인이 자신의 튀김 치킨 가게보다 더 잘나가는 광대 아저이의 매장을 보며 질투를 느껴, 몇 명의 건달들을 고용하여 매장 앞에서 시비를 걸게 만든다고 하자. 건달들은 주문대 앞에서 떠들며 온갖 질문과 요구를 늘어놓고, 점원은 정신없이 혼란스럽고 두 시간 동안 주문을 받지만 결국 건달들이 원하는 게 무엇인지 모른 채이고, 배고픈 손님들은 기다리지 못하고 하나둘 떠나간다. 더욱이 만약 점원들의 성격마저 불같다면 외부 자극에 격분하여 난투극이 벌어져 매장은 아수라장이 될 수도 있다...
DoS(Denial of Service): 서비스 거부 공격으로, 합법적인 사용자에게 서비스를 제공하지 못하게 만드는 행위이다.
서버 환경에서는 클라이언트가 아무 노력 없이 HTTP 요청을 보낼 수 있지만, 서버는 그 요청을 처리하고 응답하기 위해 많은 리소스를 소모해야 한다는 사실이 존재한다. 애플리케이션 계층의 DoS 공격은 바로 이러한 특성을 이용하는 것이다.
일반적으로 DoS 공격과 방어는 자원 경쟁의 싸움과 비슷하며, 최종 결과는 누가 더 많은 자원을 보유하고 있느냐에 달려 있다. 하지만 백엔드 코드 구현에 결함이 있다면, 단일 요청만으로도 서버가 다운될 수 있다.
본문에서는 DoS 공격의 실제 사례, 영향, 그리고 애플리케이션을 보호하기 위한 제안사항을 소개한다.
DoS 공격 사례 분석
서버에 대한 DoS 공격 방법은 다양하다. 일반적으로 공격자는 다음을 목표로 한다:
모든 CPU 및 메모리 자원을 고갈시킨다;
모든 네트워크 연결을 점유한다;
다음은 실제로 DoS 공격에 취약한 서버들에 대한 사례 분석이다. 일부는 코드 구현 오류에서 비롯되었고, 일부는 설정 오류에서 기인하였다:
1. 자원 접근 API에 수량 제한 미흡
https://fake.sample.com/api/v1/blocks?limit=10
위 요청은 "limit" 파라미터 값만큼 블록 정보를 가져온다. limit가 10일 경우 최근 10개의 블록 정보를 반환한다. 작은 숫자일 경우 문제없이 작동한다.
그러나 백엔드는 "limit" 파라미터에 상한값을 설정하지 않았을 수 있다. CertiK 기술팀이 limit 값을 9999999로 설정하여 요청을 보내자, 오랜 처리 후 "504 gateway time-out" 오류가 발생했으며, 해당 요청 처리 중 다른 API들의 응답 시간이 크게 증가했다.
9999999는 해당 체인의 전체 블록 수를 이미 초과한 값이다.
백엔드가 체인의 모든 블록 데이터를 가져오려 시도했다고 가정할 때, 공격자가 높은 limit 값을 가진 수많은 요청을 보내면 서버는 정상 요청에 응답하지 못하거나 아예 다운될 수 있다.
2. 중첩된 GraphQL 쿼리
조사 중 CertiK 기술팀은 일부 블록체인 리소스가 GraphQL을 사용하는 것을 발견했다. GraphQL은 API용 쿼리 언어로, 전형적인 REST API가 여러 요청을 필요로 하는 것과 달리, 단일 요청으로 필요한 모든 데이터를 가져올 수 있다. GraphQL은 인기가 높지만, 보호 조치 없이 사용하면 보안 위험이 생길 수 있다.
테스트 도중, 한 브라우저가 서로 포함 관계에 있는 두 개의 GraphQL 타입을 정의하고 있어 매우 복잡한 중첩 쿼리를 생성할 수 있다는 점을 발견했다.
이러한 중첩 쿼리를 보내면 서버의 CPU 사용률이 급격히 상승할 수 있으며, 일반적으로 몇 개의 요청만으로도 CPU 사용률이 100%를 넘어서 정상 사용자의 요청을 처리하지 못하게 된다.
GraphQL 요청 처리 중인 서버의 CPU 사용률
아래 그림의 "dos_query"는 중첩된 GraphQL 쿼리의 예시를 보여준다:
악의적인 GraphQL 요청이 서버에 미치는 영향은 쿼리의 복잡성과 서버 성능에 따라 다르며, 서버가 오랜 시간을 들여 쿼리에 응답할 수도 있고, CPU 과부하로 인해 서버가 다운되기도 한다. GraphQL 보안에 대해 더 알고 싶다면 본문 하단의 참고 링크 1을 방문하시기 바란다.
3. 직접 노출된 Cosmos RPC API
https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1
위의 Cosmos API는 블록 1부터 시작해 100건의 송금 거래를 검색한다. 현재까지 Cosmos 메인넷에는 2,712,445개의 블록이 존재한다. CosmosHub에서 RPC API 노드를 공개한 경우, 이 요청을 처리할 수 있는 노드를 찾을 수 없었다. 해당 요청을 받은 서버는 잠시 후 "502 Bad Gateway" 오류를 반환하며 실패를 알렸다.
RPC 서버가 수초 안에 수백 건의 위와 같은 검색 요청을 받으면 모든 API 요청에 아래와 같은 오류를 반환하게 된다. 일부 노드는 오류 후 자동 복구되지만, 다른 노드는 재시작이 필요하다.
독자들이 위 문제를 더 잘 이해하고 효과를 시각화하기 위해, CertiK 기술팀은 완전히 동기화된 Cosmos 풀 노드를 구성하고, 위의 쿼리("https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1")로 공격을 수행했다.
Grafana CPU 사용률 패널
위 그래프는 세 단계로 나눌 수 있다:
노드가 시작되어 실행 중이며, 시스템 CPU 사용률은 35%
노드가 DoS 공격을 받으며 CPU 사용률이 97%까지 치솟음
노드 다운, Grafana에 새 데이터 전송 불가
이 그래프는 DoS 공격 하에서 서버가 수 분 안에 다운됨을 보여준다. 서버 다운 후 SSH 접속이 불가능해지자 운영자는 재시작이 불가피했다.
4. 결함 있는 요청 처리 핸들러
https://fake.sample.com/api/v1?feature=Always_time_out
CertiK 기술팀은 요청 후 계속 로딩되다가 시간 초과되는 API를 발견했다. 그러나 이 API에 여러 요청을 보내도 다른 API의 응답 시간에는 영향을 주지 않았다. 초기 추정으론 해당 API 핸들러가 CPU나 메모리를 거의 사용하지 않는 것으로 보인다. 해당 블록체인 브라우저는 오픈소스가 아니므로 API 코드 구현 정보를 얻을 수 없었으며, 이름만으로는 기능을 판단하기 어려웠다.
이 API를 공격해 서버를 다운시키긴 어렵겠지만, 공격자는 "계속 멈추고 시간 초과되는" 요청을 보내 네트워크 연결을 모두 점유함으로써 다른 사용자가 API에 접근하지 못하게 할 수 있다.
예를 들어, "sleep_to_handle_request" 함수는 CPU와 메모리는 적게 소모하지만 오랜 시간 동안 로딩되며 네트워크 연결을 점유하는 상황을 보여준다.
다른 세 사례처럼 서버가 완전히 다운되거나 장시간 복구가 필요한 것과 달리, 이 사례의 서버는 공격이 중단되면 즉시 정상으로 돌아간다.
DoS 공격의 영향
DoS 공격을 받은 취약한 서버는 정상적인 사용자 요청에 응답하지 못하게 된다. 일부 서버는 공격 종료 후 바로 또는 일정 시간 후에 복구되지만, 다른 서버는 완전히 다운되어 재시작이 필요하다.
블록체인 브라우저를 사용할 수 없게 되면 사용자들은 큰 불편을 겪게 된다. 체인 상의 활동 정보를 쉽게 확인할 수 없기 때문이다. 또한 Cosmos 기반 체인에서는 노드가 DoS 공격을 받을 경우, 연결된 블록체인 브라우저가 해당 노드로부터 데이터를 가져올 수 없을 뿐 아니라, 사용자가 API를 통해 토큰 전송이나 검증자에게 위임하는 작업도 수행할 수 없게 된다.
제안 사항
모든 애플리케이션은 DoS 공격의 위협에 노출되어 있으며, 완벽한 방어책은 존재하지 않는다. 그러나 공격 비용을 증가시켜 잠재적 공격자가 공격을 수행하기 어렵게 만들고, 블록체인 브라우저 애플리케이션의 취약점을 줄이는 방법은 있다.
이에 따라 CertiK 기술팀은 애플리케이션이 공격받을 확률을 최소화하기 위한 몇 가지 제안을 제시한다:
1. 속도 제한(Rate Limiting)
백엔드 API가 구현상 안전하더라도, 공격자는 수많은 요청을 보내 공격할 수 있다. 따라서 API는 반드시 속도 제한을 설정하여 악의적인 IP를 일시적 또는 영구적으로 차단해야 한다.
속도 제한은 근본적인 해결책은 아니지만 적용이 용이하며, DoS 공격에 대한 첫 번째 방어선이 될 수 있다.
2. 설계 및 구현 개선
좋은 설계와 코드 구현은 동일한 하드웨어 조건에서도 더 나은 성능을 발휘하며, 특히 데이터베이스 검색 및 데이터 처리 기능에서 두드러진다. 하지만 성능보다 먼저 코드에 오류가 없는지 확인해야 한다.
따라서 API를 프로덕션 환경에 배포하기 전 충분한 단위 테스트를 수행해 예상대로 작동하는지 확인하는 것이 중요하다.
3. 입력 검증 및 파라미터 제한
사용자가 제공하는 변수를 검증하고 제한하지 않으면 공격자가 API를 악용할 수 있다.
코드가 의도대로 작동함을 확인한 후에는, 비정상적인 입력을 통해 API를 악용하는 것을 방지해야 한다. 예를 들어 999만 개의 블록 데이터를 가져오거나 1000단계 중첩 GraphQL 쿼리를 처리하는 요청은 허용되지 않아야 한다.
따라서 모든 사용자 입력은 신뢰할 수 없는 것으로 간주하며, 서버는 입력 처리 전 반드시 검증을 수행해야 한다.
앞선 사례에서, GraphQL API는 최대 중첩 깊이를 설정해 반복 쿼리에 의한 DoS 공격을 효과적으로 방어할 수 있으며, 블록 데이터 조회 API는 최대 블록 수를 50과 같이 합리적인 수준으로 제한할 수 있다.
개발자는 코드 구현과 설계에 따라 가장 적합한 입력 검증 및 제한 방안을 마련해야 한다.
4. 노드 RPC 공개 금지
모든 API의 코드 구현이 개발자의 통제 하에 있는 것은 아니다.
예를 들어, Cosmos RPC API 코드를 수정하는 것은 권장되지 않는다. Cosmos SDK의 일부 검색 쿼리 성능이 좋지 않은데 어떻게 해야 할까?
해결책 중 하나는 Cosmos RPC API 주변에 래퍼 API 계층을 추가하고, 노드로부터 블록체인 데이터를 동기화하는 별도의 데이터베이스를 구성하는 것이다. 외부에 공개되는 래퍼 API가 사용자 요청을 받아 처리한 후, Cosmos RPC 또는 백엔드 DB에서 데이터를 조회한다. 이렇게 하면 사용자가 노드 RPC API에 직접 접근하는 것을 차단할 수 있으며, DB를 통해 노드가 검색 요청으로 붕괴되는 것도 방지할 수 있다. 또한 개발자는 원하는 방식으로 DB를 최적화할 수 있다.
Cosmos 포럼에서 사용자 "kwunyeung"은 Nginx나 Caddy 같은 HTTP 프록시를 사용해 RPC 포트를 보호하는 방법을 제안하기도 했다. 요지는 동일하다: RPC 포트는 공개되어서는 안 되며, 반드시 보호 조치가 필요하다는 점이다.
5. 권장 하드웨어 사양 준수
위의 모든 방어 장치를 적용하더라도, API 서버 또는 Tendermint(참고 링크 2 참조)와 같은 안정적인 노드 운영 시 하드웨어 최소 사양을 충족해야 한다. 일반 사용자의 웹사이트 접근 요청만으로도 서버가 과부하를 겪는다면, 관리자는 하드웨어 업그레이드를 고려해야 한다.
결론
DoS 공격은 블록체인 브라우저와 같은 애플리케이션을 다운시킬 수 있으며, 이는 대부분의 기업에게 치명적인 위협이 될 수 있다.
CertiK의 전문 보안 기술팀은 애플리케이션 취약점 평가, Solidity, Rust, Go 등 다양한 언어의 코드 감사, 이더리움, Cosmos, Substrate 플랫폼의 보안 유지 분야에서 풍부한 경험과 전문 지식을 보유하고 있다.
블록체인 브라우저, 지갑, 거래소, 스마트 계약, 심지
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
