이더리움 노드 보안 수정…바이너리 설치는 자바 점검

이더리움(ETH) 노드 클라이언트 Teku와 Besu가 eMudhra 인증기관 사고에 대응해 Docker 이미지의 신뢰 목록을 수정했다. 실행 파일로 설치한 운영자는 별도 자바 런타임의 인증서 저장소를 확인해야 한다.

Teku 팀은 27일 보안 수정을 담은 26.10.3을 권장 업데이트로 배포했다(Teku 릴리스 공지). Besu도 26.10.2에서 관련 신뢰 목록을 바꿨으며, 이 수정은 Docker 이미지에만 적용된다(Besu 릴리스 공지).

두 업데이트는 Docker 이미지에서 emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2, AAA Certificate Services에 대한 신뢰를 제거했다. Besu 팀은 G1 제거가 예방 조치라고 설명했다.

이번 조치는 eMudhra가 만든 중간 인증기관의 개인키가 공개 인증서에서 복구될 수 있었던 사고에 따른 것이다. 해당 키로 만든 인증서는 문제가 남아 있는 자바 런타임에서 정상 인증서처럼 받아들여질 수 있다.

eMudhra는 26일 성명에서 스크립트 오류로 약한 키를 가진 중간 인증기관이 만들어졌다고 밝혔다. 회사는 문제를 확인한 뒤 14시간 안에 해당 인증기관을 폐기했으며, 조사 결과 자사 인프라와 고객 데이터는 침해되지 않았다고 설명했다(eMudhra 성명).

모질라(Mozilla)의 사고 기록에서 한 참여자는 한국시간 기준 20일 오후 6시 40분부터 22일 오전 7시 2분까지 문제의 키 6개로 서명된 인증서 10만7107건이 e-Szignó 로그에 기록됐다고 적었다. 이 가운데 10만6050건은 단일 도메인용 개념증명 인증서였다(모질라 사고 기록).

eMudhra는 자사가 문제의 중간 인증기관으로 공개 신뢰 최종 사용자 인증서를 발급하지 않았다고 밝혔다. 모질라 기록은 다른 주체가 문제의 키로 서명한 인증서를 담고 있어 두 내용은 같은 집계로 볼 수 없으며, 로그에 기록된 인증서가 실제 공격에 쓰였다는 뜻도 아니다.

인증서는 HTTPS 연결에서 상대 서버의 신원을 확인하는 데 쓰인다. 자바는 기본적으로 인증서 폐기 상태를 확인하지 않으므로, 신뢰 저장소에 관련 루트 인증기관이 남아 있으면 폐기만으로 연결이 차단되지 않을 수 있다(Besu 사고 안내).

Teku 팀은 설정에 HTTPS 주소를 넣지 않은 기본 메인넷 노드는 영향을 받지 않는다고 안내했다. 노드 클라이언트 이름만으로 위험 여부를 판단하기보다 실제 연결 설정을 확인해야 한다.

외부 서명자, 원격 비콘 노드, 실행 클라이언트, 빌더 등에 HTTPS로 연결하면서 수정되지 않은 자바 런타임을 사용하면 위험이 생길 수 있다. 이 경우에도 공격자가 통신을 가로챌 수 있어야 상대 서버를 사칭할 수 있다(Teku 보안 공지).

인증기관을 사용하지 않는 노드 간 P2P 통신은 이번 문제의 대상이 아니다. 따라서 Teku 팀이 안내한 영향 범위는 모든 노드 연결이 아니라 인증서 신뢰에 의존하는 HTTPS 연결이다.

Besu에는 별도 점검 지점이 있다. --rpc-http-tls-ca-clients-enabled를 켜면 자바 기본 신뢰 저장소의 인증기관이 서명한 클라이언트 인증서를 받아들이며, Besu 팀은 이 설정을 높은 위험으로 분류했다.

이 설정에서는 공격자가 통신을 가로채지 않아도 RPC 포트에 접근할 수 있으면 문제가 생길 수 있다. 반면 기본 설정의 Besu 노드는 영향을 받지 않으며, Besu 팀은 실제 악용 사례가 보고되지 않았다고 밝혔다.

Docker 이미지는 자체 자바 런타임을 포함하므로 호스트 컴퓨터의 자바를 수정해도 컨테이너 내부 런타임은 바뀌지 않는다. Teku 바이너리와 Besu tar·zip 배포판은 운영자가 설치한 자바를 사용하므로, 운영자는 설치 방식과 실제 실행 중인 런타임의 인증서 저장소, HTTPS·TLS 설정을 각각 확인해야 한다.