Ethereum: Teku và Besu sửa danh sách tin cậy, bản cài binary cần kiểm tra Java

Teku và Besu, hai ứng dụng máy khách nút Ethereum (ETH), đã sửa danh sách chứng chỉ tin cậy trong ảnh Docker sau sự cố tại tổ chức cấp chứng chỉ eMudhra. Người vận hành cài bằng tệp thực thi cần kiểm tra kho chứng chỉ của môi trường chạy Java riêng.

Nhóm Teku ngày 27 phát hành phiên bản 26.10.3 với bản sửa bảo mật và khuyến nghị người dùng cập nhật. Besu cũng thay đổi danh sách tin cậy trong phiên bản 26.10.2, nhưng bản sửa này chỉ áp dụng cho ảnh Docker.

Cả hai bản cập nhật đều gỡ bỏ mức độ tin cậy đối với emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 và AAA Certificate Services khỏi ảnh Docker. Nhóm Besu cho biết việc gỡ G1 là biện pháp phòng ngừa.

Động thái này diễn ra sau sự cố trong đó khóa riêng của một tổ chức cấp chứng chỉ trung gian do eMudhra tạo ra có thể được khôi phục từ chứng chỉ công khai. Chứng chỉ được tạo bằng khóa này có thể vẫn được một môi trường chạy Java chưa sửa lỗi chấp nhận như chứng chỉ hợp lệ.

Trong tuyên bố ngày 26, eMudhra cho biết lỗi tập lệnh đã tạo ra một tổ chức cấp chứng chỉ trung gian với khóa yếu. Công ty cho biết đã thu hồi tổ chức này trong vòng 14 giờ kể từ khi phát hiện sự cố; kết quả điều tra cho thấy hạ tầng của công ty và dữ liệu khách hàng không bị xâm nhập.

Trong hồ sơ sự cố của Mozilla, một người tham gia ghi rằng 107.107 chứng chỉ được ký bằng 6 khóa liên quan đã xuất hiện trong nhật ký e-Szignó, từ 18 giờ 40 ngày 20 đến 7 giờ 2 ngày 22 theo giờ Hàn Quốc. Trong số đó, 106.050 chứng chỉ là chứng chỉ thử nghiệm khái niệm dành cho một tên miền.

eMudhra cho biết họ không cấp chứng chỉ người dùng cuối được công khai tin cậy thông qua tổ chức cấp chứng chỉ trung gian gặp sự cố. Nhật ký Mozilla ghi nhận chứng chỉ do một bên khác ký bằng các khóa liên quan, nên hai nội dung này không thể được xem là cùng một số liệu. Việc chứng chỉ xuất hiện trong nhật ký cũng không đồng nghĩa chúng đã được dùng trong một cuộc tấn công thực tế.

Chứng chỉ được dùng để xác minh danh tính máy chủ đối tác trong kết nối HTTPS. Java mặc định không kiểm tra trạng thái thu hồi chứng chỉ; vì vậy, nếu tổ chức cấp chứng chỉ gốc liên quan vẫn còn trong kho tin cậy, việc thu hồi chứng chỉ có thể không đủ để chặn kết nối.

Nhóm Teku cho biết các nút mạng chính mặc định không bị ảnh hưởng nếu cấu hình không có địa chỉ HTTPS. Người vận hành nên kiểm tra các kết nối thực tế thay vì chỉ dựa vào tên ứng dụng máy khách để đánh giá rủi ro.

Rủi ro có thể phát sinh khi nút kết nối qua HTTPS với bên ký bên ngoài, nút beacon từ xa, ứng dụng máy khách thực thi hoặc bên dựng khối, đồng thời sử dụng môi trường chạy Java chưa được sửa lỗi. Trong trường hợp này, kẻ tấn công vẫn phải chặn được liên lạc để mạo danh máy chủ đối tác.

Giao tiếp ngang hàng (P2P) giữa các nút không dùng tổ chức cấp chứng chỉ không thuộc phạm vi sự cố. Do đó, phạm vi ảnh hưởng mà nhóm Teku nêu ra liên quan đến các kết nối HTTPS dựa vào việc xác thực chứng chỉ, chứ không phải mọi kết nối của nút.

Besu có một điểm cần kiểm tra riêng. Khi bật tùy chọn --rpc-http-tls-ca-clients-enabled, Besu chấp nhận chứng chỉ khách hàng được ký bởi tổ chức cấp chứng chỉ trong kho tin cậy Java mặc định. Nhóm Besu xếp cấu hình này vào mức rủi ro cao.

Với cấu hình đó, sự cố có thể phát sinh nếu kẻ tấn công truy cập được cổng RPC, ngay cả khi không chặn liên lạc. Ngược lại, các nút Besu dùng cấu hình mặc định không bị ảnh hưởng; nhóm Besu cho biết chưa có trường hợp khai thác thực tế nào được báo cáo.

Ảnh Docker có sẵn môi trường chạy Java riêng, nên sửa Java trên máy chủ không làm thay đổi môi trường bên trong vùng chứa. Bản nhị phân Teku và các gói Besu dạng tar hoặc zip sử dụng Java do người vận hành cài đặt. Vì vậy, cần kiểm tra cách cài đặt, kho chứng chỉ của môi trường đang chạy thực tế và cấu hình HTTPS/TLS.