Tóm tắt ngắn
- Teku 26.10.3 và Besu 26.10.2 loại bỏ niềm tin đối với các gốc chứng chỉ liên quan đến eMudhra sau khi các khóa trung gian bị xâm phạm làm lộ một số cấu hình trình xác thực dựa trên HTTPS vào nguy cơ giả mạo.
- Các nút mạng chính Teku mặc định không bị ảnh hưởng và chưa có báo cáo nào về việc bị khai thác, trong khi rủi ro phụ thuộc vào các validator kết nối đến các dịch vụ bên ngoài qua HTTPS.
- Người dùng Docker nên cập nhật các hình ảnh client, trong khi các người vận hành độc lập phải vá Java riêng biệt; người dùng Java 26 cần chuyển đổi sang các bản build Java 25 được hỗ trợ.
Teku và Besu đã phát hành các bản cập nhật bảo mật sau khi các khóa của cơ quan cấp chứng chỉ eMudhra bị xâm phạm khiến cấu hình nút mạng Ethereum bị phơi bày trước các kết nối HTTPS giả mạo. Các ghi chú phát hành của Teku khuyến nghị sử dụng phiên bản 26.10.3, loại bỏ niềm tin đối với bốn gốc chứng chỉ bị ảnh hưởng từ các hình ảnh Docker, trong khi Besu đã phát hành phiên bản 26.10.2. Các bản cập nhật này giải quyết vấn đề niềm tin chứng chỉ ở lớp phân phối phần mềm, chứ không phải do lỗ hổng trong các quy tắc đồng thuận của Ethereum. Các nút mạng chính mặc định của Teku không bị ảnh hưởng, làm cho sự cố này khác biệt với các lỗ hổng trong giao thức Ethereum.
Các khóa chứng chỉ bị xâm phạm tạo ra nguy cơ giả mạo
Các nhà nghiên cứu phát hiện rằng các khóa riêng của tám cơ quan cấp chứng chỉ trung gian eMudhra có thể được khôi phục do chúng được tạo ra với độ ngẫu nhiên không đủ. Mặc dù các chứng chỉ đã bị thu hồi, nhưng Java không kiểm tra việc thu hồi theo mặc định, khiến các môi trường chạy có thể chấp nhận các chứng chỉ giả mạo. Do đó, một kẻ tấn công nằm giữa một nút mạng và dịch vụ HTTPS có thể giả mạo điểm cuối đó trong các cấu hình dễ bị tổn thương. Sự việc này củng cố lý do tại sao sự đa dạng của client Ethereum và an ninh vận hành vượt ra ngoài mã đồng thuận.
Các kịch bản rủi ro cao nhất liên quan đến việc các validator kết nối với các dịch vụ bên ngoài qua HTTPS. Một điểm cuối giả mạo có thể thao túng thông tin xây dựng khối, chuyển hướng người nhận phí hoặc lấy chữ ký thông qua một bên ký bên ngoài giả mạo. Teku cho biết một kẻ tấn công có thể khiến client validator sử dụng remote beacon node đề xuất một khối trả phí cho địa chỉ của kẻ tấn công. Mức độ rủi ro phụ thuộc vào vị trí mạng và cấu hình dịch vụ từ xa, không chỉ đơn thuần là việc chạy Teku hoặc Besu. Chưa có báo cáo nào về việc khai thác lỗ hổng này.
Teku 26.10.3 loại bỏ sự tin tưởng đối với emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 và AAA Certificate Services trong các hình ảnh Docker. Bản cập nhật của Besu áp dụng cách tiếp cận tương tự. Các nhà vận hành chạy tệp nhị phân trực tiếp phải cập nhật Java riêng biệt vì các bản nâng cấp client không thay thế kho chứng chỉ của runtime máy chủ. Do đó, các bản triển khai Docker và độc lập yêu cầu các đường dẫn khắc phục khác nhau. Sự phân biệt này quan trọng sau khi Ethereum validator infrastructure incidents cho thấy các phụ thuộc ngoài giao thức có thể ảnh hưởng đến hoạt động staking.
Java 26 tạo ra sự phức tạp vì đã hết hạn hỗ trợ và sẽ không nhận được bản vá cần thiết, nghĩa là các nhà vận hành bị ảnh hưởng cần chuyển sang Java 25. Mạng peer-to-peer của ethereum không được bật vì không phụ thuộc vào các cơ quan cấp chứng chỉ này. Các bản sửa lỗi giảm thiểu rủi ro từ kho tin cậy của bên thứ ba mà không khắc phục lỗ hổng đang hoạt động trên mạng chính hay thay đổi giao thức ethereum. Sự cố này tiếp nối các nỗ lực bảo mật khác, bao gồm sửa lỗi định tuyến nạp Glamsterdam, nhấn mạnh rằng sự an toàn của validator phụ thuộc vào mã giao thức và cơ sở hạ tầng hỗ trợ.