Teku와 Besu, 이더리움(ETH) eMudhra 인증서 결함 패치 배포

Teku 26.10.3과 Besu 26.10.2

Teku 개발팀은 화요일 클라이언트 버전 26.10.3을 배포했고, Besu는 월요일 버전 26.10.2를 이어서 내놓았다. 두 업데이트 모두 인도 eMudhra와 연결된 인증서에 대한 신뢰를 Docker 이미지에서 제거했다. 변경 사항은 각각 공식 릴리스 노트인 Teku 26.10.3과 Besu 26.10.2에 기록돼 있다. 이번 수정은 가장 위험한 운영자 구성에서 공격자가 검증인 보상 일부를 자신이 지정한 주소로 조용히 보낼 수 있었던 경로를 막는다. 합의 규칙이 침해된 사례는 없었고, Teku 팀은 지금까지 악용 사례가 보고되지 않았다고 기록했다.

검증인은 예치금을 걸고 지분증명 방식의 체인을 보호하는 컴퓨터로, 블록을 제안하고 그 대가로 수수료를 받는다. 이 중 일부는 인터넷을 통해 외부 서비스와 통신하면서 디지털 인증서로 상대 서비스가 진짜인지 확인한다. 노출 지점은 프로토콜 자체가 아니라 바로 이 통신 설비에 있었다. 이더리움(ETH) 가격은 침해된 인증서와 무관했지만, 검증인이 벌어들이는 수수료와 보상은 영향받은 도구를 통해 흘러간다.

연구진은 10월 17일 토요일 eMudhra 중간 인증 기관 8곳의 개인 키가 무작위성이 부족한 상태로 생성됐다는 사실을 확인했다. 인증서는 공개 문서이기 때문에 인증서 자체에서 키를 재구성할 수 있었고, 키를 손에 넣은 사람은 패치되지 않은 소프트웨어가 진짜로 받아들이는 인증서를 위조할 수 있었다. 브라우저들이 먼저 움직여 이 인증서의 수락을 중단했다. eMudhra는 다음 날 인증서를 철회했고, 이후 인증서 사업에서 완전히 철수하겠다고 밝혔다. 결함을 처음 지적한 곳은 Teku 감사를 맡은 보안 파트너 Consensys Diligence다. 많은 운영자가 배포하는 미리 패키징된 빌드인 Docker 이미지가 양쪽 모두에서 영향받은 유통 채널이며, 더 넓은 Ethereum (ETH) 클라이언트 생태계는 검증인 도구를 자바 위에서 구동한다. 노출과 수정 모두의 방향을 결정한 세부 사항이다.

기본 메인넷 노드가 안전한 이유

두 클라이언트가 자바로 작성돼 있다는 점이 핵심이다. 자바는 기본 설정에서 인증서 폐기 여부를 확인하지 않는다. 그래서 Teku의 Docker 이미지는 브라우저들이 인증서를 버린 뒤에도 침해된 인증서를 계속 수락했고, 수정이 자바 업데이트만이 아니라 이미지 안에 담겨 나온 이유도 여기에 있다. Teku 팀이 릴리스와 함께 공개한 권고문은 공격 과정을 순서대로 설명한다. 검증인과 서비스 사이에 끼어든 공격자가 서비스를 사칭할 수 있고, 사칭에 속은 검증인이 수수료를 공격자 주소로 지급하는 블록을 제안할 수 있다. 가장 위험한 구성은 검증인의 키를 보관하는 별도 서비스인 외부 서명기다. 위조된 서명기가 보상 송금처를 바꾸는 서명을 넘겨줄 수 있기 때문이다.

자바 기본 설정의 이 공백이 대응 순서를 설명해 준다. 브라우저는 폐기 여부를 검사하므로 하루 안에 인증서를 차단했다. 자바 기반의 이더리움 도구는 그렇지 않았고, 클라이언트 팀들은 런타임 수준의 수리를 기다리는 대신 eMudhra를 신뢰 대상에서 뺀 Docker 이미지를 새로 만들었다. 대부분의 운영자에게 소식은 단순하다. 메인넷에서 기본 구성을 그대로 유지하며 운영하는 Teku 노드는 영향받지 않으며 별도 조치가 필요 없고, 지금까지 보상 탈취 사례도 없다. 조치 방법은 구성에 따라 갈린다. 미리 패키징된 Docker 이미지를 쓰는 운영자는 최신 Teku 또는 Besu 빌드를 받으면 된다. 소프트웨어를 자기 장비에 직접 설치해 운영하는 경우 일이 더 커진다. 이더리움 클라이언트를 업데이트해도 호스트의 자바 설치본은 손대지 않고, 새 이미지도 호스트 수준의 자바를 수리하지 않는다. 가장 어려운 처지는 여전히 자바 26을 쓰는 운영자다. 이 버전은 수명이 끝나 패치 빌드를 받을 수 없어, 자바 25로 옮기는 것이 유일한 길이다.

이번 사건은 프로토콜 이야기라기보다 운영 이야기로 읽힌다. 합의 계층은 버티지 않았다. 실제 노출을 안 집단도 좁다. 외부 서명기를 쓰거나, 기본값이 아닌 네트워크 경로를 두거나, 낡은 자바 설치본을 방치한 운영자들이다. 그래도 이더리움 노드 운영에 드는 관리 비용을 따지는 사람에게는 한 줄 항목이 된다. 클라이언트 주변의 런타임도 자체 주기에 맞춰 패치해야 하기 때문이다. 패치된 두 버전은 각 프로젝트의 저장소에 이미 올라와 있어 오늘 모든 운영자가 조치 경로에 접근할 수 있다. 두 릴리스가 나온 뒤로는 결함 심각성에 대한 독립적인 평가가 나오지 않았고, 당분간 클라이언트 팀들의 권고문이 유일한 공개 평가로 남는다.