2022년, Klaytn의 노드 운영 보안 취약점은 무엇이었을까요?
요약
본 글은 작년 8월경, ChainLight이 발견한 Klaytn의 Debug Namespace 취약점에 관한 리포트입니다. 현재 본문에 언급된 취약점은 패치 완료된 상태이며, Klaytn이 아닌 다른 블록체인에서도 충분히 발생할 수 있는 문제이기 때문에 리포트 공개가 적절하다고 판단해 사례를 공유합니다.
2022년 08월경 Klaytn의 debug API 노출 상태 식별
대부분의 Klaytn Public JSON-RPC 엔드포인트는 Debug namespace를 지원하도록 설정된 상태입니다. 이는 스마트 컨트랙트 개발자의 편의를 위한 것으로 추정되며, Geth fork 또는 EVM 호환 노드에서의 Debug API는 보안상 문제가 발생할 수 있기 때문에 외부에 노출해서는 안 됩니다. 실제로 Geth 공식 문서에서도 eth, net, web3 외의 Namespace 지원은 Attack surface 증가를 이유로 추천하지 않습니다.
Namespace란, 객체 지향 언어에서 유용하게 사용되며 데이터 명칭 간의 충돌을 방지하기 위해 명명하는 공간을 의미하며 명칭 공간이라고도 합니다. 본문에서 사용된 의미는 RPC(원격 프로시저 호출)에서 호출 가능한 메서드(Method)를 카테고리별로 묶는 개념으로서 Namespace를 사용했으니 참고하시길 바랍니다.
작년 8월경, Klaytn 노드에는 보안적으로 취약한 Debug API가 다수 노출되어 Denial of Service(서비스 거부 공격), Remote Code Execution(원격 코드 실행 공격) 등 심각한 피해로 이어질 수 있는 상태였습니다.
curl -H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0",
"method":"debug_printBlock","params":["latest"],"id":1}' \
https://public-node-api.klaytnapi.com/v1/cypress | jqDebug API 취약점
지난 2022년 8월경, 확인된 Klaytn 노드의 Debug API 취약점은 아래와 같으며 취약한 API는 추가로 존재할 수 있습니다.
1. debug_write{Block,Mem,Mutex} Profile API를 이용한 임의 파일 덮어쓰기
공격자는 원하는 경로에 profiling 결과 파일을 쓸 수 있으며 이미 있는 파일의 경우 덮어쓰게 됩니다. 이를 통해, 로컬에 저장된 State DB 등 중요 파일을 손상시킬 수 있고 이를 복구하기 위해 재동기화하는 과정은 상당한 시간이 소요될 수 있습니다. Root 권한(최상위 권한)으로 노드를 가동하고 있을 경우 libc와 같은 주요 시스템 파일을 손상시켜 해당 서버를 마비시킬 수 있습니다.(참고: https://github.com/klaytn/klaytn/blob/eb48bd747fa2afeee9fddd
1200a3f85b8d2c17ad/api/debug/api.go#L315-L324)
일반적으로, 블록체인에서 노드를 구동할 때 Root 권한(최상위 권한)으로 노드를 구동하는 것은 최상위 권한으로만 접근 가능한 리소스에 접근하는 목적이 아닌 이상 권장되는 사항이 아닙니다. 블록체인에서 노드를 구동하는 주체들은 모두 동등한 권한을 지녀야 하는데, 최상위 권한으로 노드를 실행하게 되면 네트워크의 보안, 시스템 상의 문제가 생길 소지가 있습니다. 따라서 일반적으로 최상위 권한으로 노드를 실행하는 것은 제한하는 것이 권장됩니다. Klaytn의 공식 문서에서 배포하는 패키지 설정에는 CN 노드 실행이 루트 권한으로 요구되니 참고바랍니다.
2. debug_traceTransaction API의 JavaScript-based trace 기능을 이용한 RCE(Remote Code Execution)
RCE는 Remote Code Execution의 약자로, 원격으로 코드 실행을 하는 것을 의미합니다. 즉, 악의적인 공격자가 원격으로 특정 명령어를 실행시켜 시스템을 제어하거나, 중요한 정보를 탈취하거나 하는 등의 악의적인 행동을 할 수 있는 것을 의미하며 이는 심각한 보안 문제에 속합니다.
debug_traceTransaction API에는 trace를 할 때, 임의의 JS 코드를 전달 받아 실행하는 기능이 있는데 이것은 Duktape JS 엔진의 go binding인 olebedev/go-duktape을 이용해서 구현됩니다. 이러한 코드 실행 기능을 노출하는 것 자체가 보안 위협을 크게 상승시키지만, 더 큰 문제는 go-duktape는 개발이 중단된 상태로 의존성이 있는 Duktape에 대해 v2.5를 사용한 채로 멈춰있었다는 점입니다. 참고로 Duktape는 현재 v3.0이 릴리즈된 상태입니다. Duktape v2.5에는, 상위 버전에서 수정된 다수의 Memory safety issue가 존재하며, 이 취약점들을 이용해서 노드 충돌을 발생시킬 수 있는 것을 확인했고 RCE Exploit도 가능합니다.(https://github.com/klaytn/klaytn/blob/dev/node/cn/tracers/
tracer.go)
취약점이 일으킬 수 있는 영향
파일 덮어쓰기로 State DB가 손상되는 경우 해당 노드는 체인 정보를 정상적으로 제공할 수 없으며 손상된 데이터를 삭제하고 처음부터 다시 동기화해야 합니다. DApp Frontend, Wallet, Bridge, CEX 등 해당 Public RPC에 의존하는 서비스들은 가용성 문제가 발생할 수 있습니다.
공격자가 RCE를 시도하고 실패하는 경우 높은 확률로 충돌이 발생하며 그 경우 해당 노드의 사용자들에게 발생하는 가용성 문제는 1번의 시나리오가 일으킬 수 있는 영향과 유사합니다.
RCE를 성공하는 경우, 해당 노드의 모든 입출력은 공격자에 의해 감시 및 조작이 가능하며 Bridge 또는 CEX에서 참조하는 노드의 경우 실제로 발생하지 않은 입금 이벤트를 반환하여 자금 탈취 등이 가능해집니다.
권고 사항
단기적으로는, Debug Namespace를 비활성화합니다. 특히, 늦게 적용하는 노드가 공격당하지 않도록 모든 노드 운영자가 동시간에 Debug Namespace를 비활성화해야 합니다. 장기적으로는 보안 위험을 노출하지 않는 것으로 확인된 기능만 지원하도록 코드를 수정합니다.
필요한 기능만 새로운 네임스페이스로 분리하거나 나머지 API는 명시적으로 설정한 경우에만 활성화하고 실행 시 경고 메시지를 띄워야 합니다.(예: tracetx namespace 추가; 트랜잭션에 대한 디버그 기능을 노드 자체에 대한 디버그 namespace에서 분리, 또는 — enable-unsafe-debug-api flag 추가)기본 설정 파일이나 공식 문서에 Debug Namespace를 허용하는 내용이 있으면 제거하고 위험성에 대한 경고를 추가해야 합니다.
잘못 설정되어 있는 Public RPC 서버들은 이미 장악당한 것으로 간주하고 이에 맞는 침해 사고 대응 절차를 진행해야 합니다.(로그 파일 등 증거 수집, Credential 교체, OS 재설치 또는 인스턴스 재생성)
패치 사항
해당 취약점은 Klaytn Github에서 Debug Namespace 중 안전한 API들만 공개하는 방식으로 패치가 되었습니다.
결론
블록체인에서는 작은 취약점조차도 심각한 결과를 초래할 수 있기 때문에, 보안은 매우 중요한 요소입니다. 따라서 개발 커뮤니티나 재단은 블록체인에 대한 잠재적인 공격을 방지하기 위해 보안 결함을 식별하고 패치를 적용하기 전에 사전 조치를 취해야 하며, 코드의 취약점에 대해 확인하고 최신 보안 업데이트를 적용하여 안전성을 확보하는 노력을 기울여야 합니다. 그렇지 않으면 자금 손실, 데이터 손상, 서비스 이용 불가 등 유저와 서비스에 심각한 결과를 초래할 수 있습니다.
참고 자료
✨ We are ChainLight!
ChainLight 팀은 풍부한 실전 경험과 깊은 기술 이해를 바탕으로 새롭고 효과적인 블록체인 보안 기술을 연구합니다. 연구 결과를 바탕으로 Web3 생태계의 각종 보안 위험 요소와 취약점을 사전 파악하여 제거하는 혁신적인 보안 감사 서비스를 제공합니다. 보안 감사 이후에도 온체인 데이터 모니터링 및 취약점 탐지 자동화 서비스를 이용한 지속적인 디지털 자산 위험 관리 솔루션을 제공합니다.
ChainLight 팀은 사용자들이 탈중앙화 서비스를 안전하게 활용할 수 있도록 Web3 생태계 위협으로부터의 보호에 힘쓰고 있습니다.
ChainLight의 더 다양한 정보를 보고 싶으시다면? 👉 Twitter 계정도 방문해 주세요.
🌐 Website: chainlight.io | 📩 TG: @chainlight | 📧 chainlight@theori.io
Originally published at https://blog.theori.io on May 18, 2023.
