Teku và Besu đã cập nhật các hình ảnh Docker của riêng mình sau sự kiện eMudhra, do khóa chứng chỉ yếu gây rủi ro cho phần mềm kết nối với các dịch vụ bên ngoài, bao gồm cả một số triển khai người xác thực Ethereum.
- Teku 26.10.3 và Besu 26.10.2 đã loại bỏ độ tin cậy của chứng chỉ bị ảnh hưởng trong hình ảnh Docker do sự kiện eMudhra.
- Teku cho biết, các nút mạng chính mặc định không bị ảnh hưởng, mức độ phơi bày thực tế phụ thuộc vào kết nối HTTPS và thời gian chạy Java mà người vận hành sử dụng.
- Các rủi ro được tiết lộ liên quan đến các dịch vụ và người xác thực bị giả mạo, không có báo cáo nào về việc bị khai thác trong thông báo của Teku.
Đối với người vận hành, vấn đề trực tiếp nhất hiện nay là: khi kết nối với các dịch vụ khác, phần mềm của họ có chấp nhận chứng chỉ giả mạo hay không. Câu trả lời phụ thuộc vào kết nối được sử dụng và phiên bản Java cài đặt, do đó việc cập nhật client không có nghĩa là mọi người xác minh đều đối mặt với cùng một mức độ rủi ro.
Cập nhật hình ảnh Docker của Teku và Besu
Các nhóm khách hàng Ethereum đã phát hành bản cập nhật để sửa lỗi chứng chỉ bắt nguồn từ ngoài chuỗi khối. Các thay đổi liên quan đến cách phần mềm xác định liệu dịch vụ từ xa có phải là thật hay không.
Teku 26.10.3 và Besu 26.10.2 đã gỡ bỏ sự tin tưởng đối với gốc chứng chỉ bị ảnh hưởng từ hình ảnh Docker của chúng. Bản phát hành này xuất phát từ việc phát hiện khóa yếu liên quan đến cơ quan cấp chứng chỉ eMudhra.
Đối với những người vận hành người xác minh, vấn đề nằm ở việc kẻ tấn công giả mạo dịch vụ mà phần mềm kết nối. Tùy theo vai trò của dịch vụ, phản hồi giả mạo có thể làm xáo trộn trách nhiệm hoặc ảnh hưởng đến hướng thanh toán phí khối.
Tuy nhiên, điều này không có nghĩa là mọi người xác thực Ethereum đều đang đối mặt với rủi ro. Thông báo bảo mật của Teku cho biết các nút mạng chính mặc định không bị ảnh hưởng và hiện chưa có báo cáo nào về việc bị khai thác.
Sự khác biệt nằm ở cách cài đặt. Những người vận hành sử dụng dịch vụ HTTPS bên ngoài cần kiểm tra các kết nối mà có thể không tồn tại trong các bản triển khai hoàn toàn cục bộ.
Các bản cập nhật này áp dụng cho môi trường cài đặt cụ thể. Hình ảnh Docker sau khi vá chứa các thay đổi runtime được đóng gói trong container, trong khi phần mềm cài đặt từ tệp lưu trữ có thể sử dụng Java do người vận hành cung cấp thêm.
Sự kiện này ảnh hưởng đến cơ sở hạ tầng xung quanh người xác thực, trong khi quy tắc đồng thuận của Ethereum không thay đổi.
Tại sao vấn đề chứng chỉ lại trở thành rủi ro bảo mật?
Chứng chỉ giúp phần mềm xác định xem nó có đang kết nối đến dịch vụ mong muốn hay không. Các tổ chức phát hành chứng chỉ đáng tin cậy sẽ xác nhận danh tính tương ứng với chứng chỉ máy chủ.
Cơ chế này rất phổ biến trên các trang web HTTPS và cũng áp dụng được cho các ứng dụng không giao tiếp thông qua trình duyệt. Các dịch vụ nền cũng có thể phụ thuộc vào các xác thực danh tính này.
Cơ quan cấp chứng chỉ có thể sử dụng chứng chỉ trung gian dưới chứng chỉ gốc được tin cậy. Khóa riêng liên quan đến các chứng chỉ trung gian này phải được giữ an toàn, vì chúng có thể được sử dụng để cấp thêm nhiều chứng chỉ.
Trong sự kiện này, vấn đề không chỉ là ai đó đã nhận được thông tin đăng nhập thông thường của máy chủ. Khóa trung gian bị ảnh hưởng có thể được khôi phục từ các thông tin đã được công khai.
Nhóm bảo mật Go cho biết lỗ hổng này cho phép khôi phục khóa riêng ở mức vi giây. Báo cáo cũng nêu rằng kẻ tấn công sau đó có thể tạo chứng chỉ cho các miền mà họ không kiểm soát.
Nếu một ứng dụng dễ bị tấn công cho rằng chứng chỉ này cuối cùng vẫn có thể truy ngược về một tổ chức mà nó tin cậy, thì nó có thể chấp nhận chứng chỉ đó. Như vậy, việc giả mạo danh tính có thể vượt qua các kiểm tra vốn được thiết kế để từ chối những kẻ mạo danh.
Tuy nhiên, kẻ tấn công vẫn cần một cách nào đó để chặn hoặc chuyển hướng kết nối của nạn nhân. Khóa yếu không tự động khiến chúng xuất hiện giữa mỗi người dùng và mỗi máy chủ.
Điều kiện này thu hẹp cách thức cuộc tấn công có thể xảy ra, nhưng không làm cho việc vô hiệu hóa chứng chỉ trở nên vô hại. Chỉ cần phần mềm coi kẻ giả mạo là điểm cuối thực sự, việc chặn mạng sẽ trở nên nguy hiểm hơn.
Nghiên cứu của Kudelski Security đã xem xét các cấp độ chứng chỉ bị ảnh hưởng. Vấn đề nằm ở chỗ, phần mềm có thể chấp nhận các chứng chỉ được ký bởi khóa mà kẻ tấn công có thể tái tạo.
eMudhra gán các khóa yếu cho lỗi xử lý
Bản tuyên bố sự kiện của eMudhra cho biết, một nhà nghiên cứu đã báo cáo 8 khóa trung gian yếu vào ngày 17 tháng 10. Công ty đã thu hồi 8 khóa này vào ngày hôm sau.
Công ty cho biết các chứng chỉ trung gian này được tạo ra trong một nghi lễ khóa vào ngày 30 tháng 4 năm 2025. Theo công ty, các bước wrap và unwrap có lỗi đã tạo ra các bản sao yếu bên ngoài khóa mạnh ban đầu.
Công ty cho biết đã sử dụng mô-đun bảo mật phần cứng được chứng nhận. Họ giải thích rằng sự cố là do một bước trong quy trình phụ, chứ không phải do thiếu thiết bị này.
Công ty cũng cho biết, trong số đó, 7 chứng chỉ trung gian chưa bao giờ được sử dụng trong môi trường sản xuất, và chứng chỉ còn lại cũng chưa từng được cấp. Công ty khẳng định sự cố này không dẫn đến việc cơ sở hạ tầng bị xâm nhập hay rò rỉ dữ liệu.
These statements explain eMudhra's description of its internal operations. However, software vendors must still address another possibility: other parties may exploit recoverable keys.
Hệ thống chứng nhận không thể chỉ dựa vào cam kết của bên vận hành ban đầu rằng họ sẽ không cấp thêm bất kỳ nội dung nào. Một khi người khác cũng có thể tái tạo khóa chữ ký đó, sự đảm bảo này sẽ không còn kiểm soát được tất cả các chứng nhận có thể được tạo ra.
Do đó, các biện pháp phản ứng đã vượt ra ngoài công ty tạo ra khóa. Các nhà sản xuất trình duyệt, nhà cung cấp hệ điều hành và các nhóm ngôn ngữ lập trình đều cần xem xét phần mềm của người dùng sẽ chấp nhận gì.
Các bản sửa đổi này sẽ được truyền đến người dùng thông qua các bản cập nhật khác nhau. Trình duyệt có thể nhận danh sách chặn, trong khi một ứng dụng Java độc lập khác có thể vẫn tiếp tục sử dụng bộ chứng chỉ đáng tin cậy cũ.
Khóa yếu và ứng dụng chấp nhận khóa đó là hai phần khác nhau của cùng một vấn đề. Việc thu hồi chứng chỉ giải quyết vấn đề ở cấp độ hồ sơ tổ chức, trong khi client vẫn cần một cách đáng tin cậy để nhận diện các đường dẫn tin cậy bị ảnh hưởng mà chúng nên từ chối.
Các dịch vụ bên ngoài mang đến những rủi ro khác nhau cho người xác thực
Các nút Ethereum được tạo thành từ các phần mềm đảm nhận các vai trò khác nhau. Tài liệu khách hàng Ethereum phân biệt giữa khách hàng thực thi và khách hàng đồng thuận:前者 xử lý thực thi giao dịch và trạng thái,后者 tuân theo đồng thuận chứng minh cổ phần.
Phần mềm người xác thực đã bổ sung trách nhiệm đề xuất khối và chứng minh cho chuỗi. Người vận hành có thể chạy các thành phần này tại địa phương hoặc kết nối một phần thông qua dịch vụ bên ngoài.
Teku là khách hàng đồng thuận, Besu là khách hàng thực thi. Cả hai đều sử dụng Java, đây cũng là lý do tại sao độ tin cậy chứng chỉ khi chạy liên quan đến phiên bản của chúng.
Các dịch vụ ngoài máy cục bộ sẽ thêm một lớp xác thực danh tính cho arrangement này. Phần mềm cần xác minh rằng điểm cuối phản hồi yêu cầu chính là nhà cung cấp mong đợi.
Ví dụ, người vận hành có thể sử dụng dịch vụ ký từ xa thay vì giữ thao tác ký trong cùng một tiến trình. Một số người có thể phụ thuộc vào các điểm cuối bên ngoài để cung cấp dữ liệu hoặc dịch vụ xây dựng khối.
Mức độ thiệt hại mà kẻ giả mạo có thể gây ra phụ thuộc vào việc dịch vụ đó được phép thực hiện những gì. Dịch vụ chỉ tiếp nhận dữ liệu giám sát có rủi ro khác với dịch vụ tham gia vào quyết định ký.
Đường dẫn mạng cũng quan trọng không kém. Việc kết nối thông qua cơ sở hạ tầng công cộng có cơ hội bị chặn khác với các thành phần chỉ nằm trên cùng một máy chủ hoặc trong mạng riêng được kiểm soát chặt chẽ.
Mạng riêng không thể ngăn chặn hoàn toàn mọi sự cố, nhưng nó có thể giảm cơ hội kẻ tấn công chiếm được vị trí cần thiết để gây nhiễu lưu lượng.
Do đó, chỉ dựa vào tên client không thể xác định liệu có bị phơi bày hay không. Cùng một phần mềm có thể được triển khai trong các môi trường sử dụng các điểm cuối, kho tin cậy và kiểm soát truy cập khác nhau.
Câu hỏi thực sự cần được trả lời là: Kết nối nào đã vượt qua đường dẫn bị ảnh hưởng để chấp nhận chứng chỉ. Một khi xác định được điều này, người vận hành có thể đánh giá mức độ quyền hạn mà dịch vụ bị giả mạo nên có trong hoạt động của người xác thực.
Tại sao hình ảnh Docker và cài đặt qua tệp nén lại khác nhau?
Hình ảnh Docker sẽ đóng gói ứng dụng cùng với môi trường cần thiết để chạy nó, có thể bao gồm Java Runtime và các chứng chỉ mà Runtime này tin tưởng.
Cập nhật Java trên máy chủ sẽ không tự động thay thế Java trong hình ảnh hiện có. Container vẫn có thể tiếp tục sử dụng các tệp được đóng gói bên trong nó.
Đây là lý do tại sao bản ghi chú phát hành của client đặc biệt đề cập đến các thay đổi Docker. Tài liệu của Teku cho biết, hình ảnh nền Eclipse Temurin của họ lúc đó chưa bao gồm việc gỡ bỏ liên quan, do đó hình ảnh client đã được chỉnh sửa trực tiếp.
Bản phát hành của Besu cũng cho biết việc gỡ bỏ chứng chỉ áp dụng cho hình ảnh Docker và yêu cầu rõ ràng người dùng cài đặt tự cung cấp kiểm tra phiên bản Java do họ cung cấp.
Việc lưu trữ cài đặt sẽ giao trách nhiệm này cho người vận hành. Client Ethereum có thể đã được cập nhật, nhưng runtime riêng lẻ của nó vẫn có thể chứa kho chứng chỉ cũ.
Ngược lại, trong quá trình bảo trì, cũng sẽ xuất hiện sự khác biệt tương tự. Việc thay thế runtime của máy chủ sẽ ảnh hưởng đến các tiến trình sử dụng runtime đó, nhưng không ảnh hưởng đến cài đặt khác sử dụng đường dẫn Java khác.
Sự kiện của Oracle khuyến nghị người dùng cập nhật runtime bị ảnh hưởng hoặc làm theo các giải pháp thay thế được cung cấp trong tài liệu của nó. Nó cũng yêu cầu khởi động lại các phiên bản đang chạy và xem xét từng cài đặt độc lập riêng biệt.
Điều này làm cho các tiến trình đang chạy quan trọng hơn so với các bản cập nhật đã tải về. Máy chủ có thể chứa các tệp đã được vá, nhưng các tiến trình cũ vẫn sẽ tiếp tục chạy cho đến khi được thay thế hoặc khởi động lại.
Bộ lưu trữ chứng chỉ tùy chỉnh đã thêm một biến thể khác. Một tổ chức có thể sử dụng kho chứng chỉ do chính họ duy trì cho các dịch vụ của mình, thay vì chỉ sử dụng kho chứng chỉ do Java cung cấp mặc định.
Nhiệm vụ thực tế là xác định khách hàng thực sự đã sử dụng gì. Cách cài đặt, vị trí chạy và cấu hình tin cậy cùng nhau quyết định liệu bản vá đã phát hành có đã đến kết nối cần nó hay không.
Sự khác biệt trong việc kiểm tra thu hồi giữa các ứng dụng
Việc thu hồi có nghĩa là chứng chỉ không còn được chấp nhận. Nhưng điều này không đảm bảo rằng mỗi ứng dụng đều kiểm tra thông tin thu hồi mới nhất trước khi thiết lập kết nối.
Các ứng dụng khác nhau có cách lấy thông tin này khác nhau. Một số truy vấn dịch vụ trực tuyến, một số sử dụng danh sách chặn do nhà cung cấp cung cấp, và một số chủ yếu dựa vào kho chứng chỉ địa phương.
Phản hồi từ nhóm Go giải thích lý do tại sao nhà cung cấp runtime có thể cần can thiệp trực tiếp. Nhóm đã khởi động bản phát hành khẩn cấp về bảo mật vào ngày 19 tháng 10 và cho biết đã cung cấp phiên bản vá sau khoảng 7,5 giờ kể từ khi nhận được thông báo.
Hành động này đã chặn các con đường chứng chỉ bị ảnh hưởng liên quan đến các ứng dụng sử dụng hành vi xác thực Go tương ứng. Người dùng Java cần được bảo vệ thông qua cài đặt runtime và niềm tin của riêng họ.
Teku thông báo rằng Java mặc định không kiểm tra việc thu hồi. Đây cũng là lý do tại sao, ngay cả khi eMudhra đã thu hồi các chứng chỉ trung gian này, việc loại bỏ niềm tin tại địa phương vẫn là cần thiết.
Việc loại bỏ chứng chỉ gốc và chặn chứng chỉ trung gian cũng có thể tác động ở các cấp độ khác nhau.前者 từ chối một con đường bị xâm phạm cụ thể, trong khi后者 có thể từ chối toàn bộ chuỗi chứng chỉ dẫn đến chứng chỉ gốc đã bị loại bỏ.
Việc triển khai đúng thuộc về nhà cung cấp và tổ chức duy trì ứng dụng. Việc tạm thời vô hiệu hóa xác thực danh tính chỉ loại bỏ lớp bảo vệ, chứ không giải quyết vấn đề tin tưởng.
Các dịch vụ hợp pháp cũng có thể cần điều chỉnh. Nếu chứng chỉ của chúng phụ thuộc vào con đường mà khách hàng hiện từ chối, thì bên cung cấp dịch vụ phải cung cấp giải pháp thay thế có thể chấp nhận được, thay vì mong đợi người dùng khôi phục niềm tin không an toàn.
Điều này cũng giải thích tại sao một sự cố chứng chỉ có thể kéo dài nhiều ngày. Việc phát hiện có thể xảy ra ngay lập tức, nhưng việc bảo vệ sẽ được triển khai dần thông qua các quy trình phát hành và duy trì khác nhau của trình duyệt, ứng dụng đóng gói và cơ sở hạ tầng riêng.
Đối với người vận hành người xác minh, kết quả quan trọng là các kết nối liên quan đã bị từ chối đối với các danh tính không đáng tin cậy hay chưa. Các thông báo revocation ở các nơi khác trong hệ sinh thái phần mềm không chứng minh được tiến trình nút của họ đã đạt được kết quả này.
Phần thưởng vàstaking của người xác thực có bị phơi bày theo cùng một cách không?
Việc stakes của người xác minh, trách nhiệm ký tên và thanh toán phí có liên quan đến nhau, nhưng chúng bị chi phối bởi các cơ chế khác nhau. Vấn đề ảnh hưởng đến một trong số này không nên tự động được mô tả là sự kiểm soát đối với tất cả những nội dung này.
Tài liệu hướng dẫn staking Ethereum: Người xác minh nhận phần thưởng khi thực hiện đầy đủ trách nhiệm và bị phạt khi offline hoặc có hành vi sai trái có thể chứng minh được. Quyền ký và quyền rút tiền đóng vai trò khác nhau trong hệ thống.
Khóa chứng nhận thuộc về hệ thống xác thực dùng để kết nối. Nó không phải là khóa ký riêng của người xác thực và không tiết lộ trực tiếp thông tin xác thực để rút ETH đã đặt cọc.
Tuy nhiên, dịch vụ bị giả mạo vẫn có thể ảnh hưởng đến hành vi của người xác minh. Mức độ ảnh hưởng phụ thuộc vào việc dịch vụ đó xử lý những yêu cầu hoặc phản hồi nào, cũng như còn giữ lại những kiểm tra bổ sung nào.
Khối đề xuất bao gồm người nhận phí cho các giao dịch liên quan. Nếu một con đường nào đó có thể thay đổi đề xuất hoặc cấu hình, thì có thể gây ra hậu quả mà không cần kiểm soát toàn bộ khoản đặt cọc.
Dịch vụ chữ ký cũng đặt ra một bộ câu hỏi khác do nó tham gia vào việc xác thực hành vi của người xác thực. Các biện pháp bảo vệ của chính nó, bao gồm giới hạn yêu cầu và các biện pháp phòng ngừa chữ ký xung đột, sẽ ảnh hưởng đến mức độ mà kẻ tấn công có thể làm được.
Việc bỏ sót trách nhiệm do gián đoạn dịch vụ cũng là một hệ quả có thể xảy ra. Ngay cả khi không chuyển được bất kỳ khoản thanh toán nào, kẻ tấn công chỉ cần ngăn chặn phản hồi chính xác cũng có thể giảm phần thưởng.
Hậu quả tài chính của các kết quả này là không giống nhau. Việc bỏ lỡ cơ hội đề xuất khối, hình phạt offline thông thường và hình phạt slashing không thể được xem là tương đương.
Mô tả thông báo khách hàng nêu ra các hậu quả có thể xảy ra trong điều kiện bị ảnh hưởng, nhưng không chứng minh rằng mỗi nhà vận hành đều gặp phải những hậu quả này, cũng không chứng minh rằng có một lượng ETH tương ứng đã bị đánh cắp.
Đối với những người dùng dịch vụ staking, điều thực sự quan trọng là việc triển khai thực tế của dịch vụ đó. Số lượng ETH được quản lý không cho thấy người vận hành đã sử dụng những dịch vụ hoặc kho chứng chỉ nào.
Các người xác thực cũng phụ thuộc vào phần mềm ngoài Ethereum
Các quy tắc của mạng Ethereum chỉ là một phần trong những yếu tố mà người vận hành phụ thuộc vào. Phần cứng, thời gian chạy, dịch vụ lưu trữ, cấu hình và các dịch vụ bên ngoài đều ảnh hưởng đến việc validator có thể thực hiện đúng trách nhiệm hay không.
Cơ quan cấp chứng chỉ nằm ngoài giao thức Ethereum, nhưng khi phần mềm người xác thực phụ thuộc vào nó để nhận diện dịch vụ, sự cố của nó sẽ trở nên liên quan. Chỉ riêng điều này đã đủ để đưa một vấn đề bảo mật internet phổ biến vào cơ sở hạ tầng staking.
Sự đa dạng của client vẫn có giá trị vì các triển khai khác nhau có thể giảm sự phụ thuộc vào một kho mã duy nhất. Nhưng điều này không có nghĩa là mỗi thành phần phụ thuộc đều là độc lập.
Hai client có thể sử dụng cùng một runtime ngôn ngữ lập trình. Các nhà vận hành khác nhau cũng có thể sử dụng cùng một nhà cung cấp lưu trữ, dịch vụ ký hoặc hạ tầng xây dựng khối.
Các thành phần chia sẻ này sẽ tạo ra bề mặt phơi bày chung khi phần mềm Ethereum khác nhau. Do đó, để hiểu rõ tình hình triển khai, không thể chỉ xem xét số lượng thương hiệu client.
Việc thuê ngoài cũng mang lại những sự đánh đổi. Dịch vụ ký chuyên dụng có thể cải thiện cách bảo vệ khóa, nhưng cũng làm cho kết nối xác thực với dịch vụ đó trở nên quan trọng hơn.
Việc chạy tại địa phương cũng có những yêu cầu bảo trì riêng. Đặt các thành phần trên cùng một máy chủ có thể giảm một phần tiếp xúc mạng, nhưng người vận hành vẫn cần quản lý cập nhật phần mềm và quyền truy cập vào máy đó.
Sự kiện này không tự động đưa ra một kiến trúc an toàn nhất trong mọi trường hợp. Nó cho thấy cần phải hiểu và duy trì trách nhiệm của từng kết nối xung quanh.
Sự khác biệt này cũng rất quan trọng đối với người dùng ETH thông thường. Việc vá chứng chỉ trong cơ sở hạ tầng nút không có nghĩa là mọi ví đều phải chuyển tiền, cũng không có nghĩa là số dư tài khoản Ethereum đã thay đổi.
Các hành động liên quan thuộc về người vận hành phần mềm bị ảnh hưởng. Họ mới có khả năng xác định các runtime, endpoint và cài đặt niềm tin liên quan, sau đó áp dụng hướng dẫn từ nhà cung cấp vào các hệ thống đang thiết lập các kết nối này.
Người vận hành cần áp dụng và kiểm tra bản cập nhật
Các bản phát hành này cung cấp cho người vận hành phương pháp loại bỏ các đường dẫn tin cậy bị ảnh hưởng từ các hình ảnh Docker được hỗ trợ. Người dùng lưu trữ cần xử lý các môi trường chạy riêng lẻ theo hướng dẫn của nhà cung cấp Java tương ứng.
Phiên bản vá sẵn sàng chỉ là bước đầu tiên. Môi trường đã được cập nhật còn cần được chạy thực tế và đảm bảo cấu hình cũng như các dịch vụ hoạt động như mong đợi.
Đối với nhà cung cấp dịch vụ, sự gián đoạn do chứng chỉ mới bị từ chối gây ra có thể yêu cầu thay đổi chứng chỉ tại điểm cuối. Khi khôi phục dịch vụ, cần duy trì xác thực danh tính thay vì bỏ qua nó.
Các tiết lộ tiếp theo có thể làm rõ thêm các tác động. Người vận hành có thể xác định được các cấu hình đã chấp nhận chuỗi chứng chỉ bị ảnh hưởng, hoặc báo cáo các sự kiện liên quan đến các dịch vụ cụ thể.
Hiện tại, báo cáo thông báo của Teku chưa bị khai thác và đã phân biệt rõ giữa việc sử dụng mạng chính mặc định và các kết nối bên ngoài bị ảnh hưởng. Đây là cơ sở rõ ràng nhất để mô tả bề mặt bị phơi bày hiện tại của Ethereum.
Các bên vận hành bị ảnh hưởng có lý do để cập nhật. Mọi tổn thất tài chính đều phụ thuộc vào việc kẻ tấn công đã giả mạo dịch vụ nào, có chặn lưu lượng hay không, cũng như người xác thực cho phép dịch vụ đó thực hiện những hành động gì.
Cần chú ý những gì
- Cập nhật khách hàng: Theo dõi các bản phát hành của Teku và Besu và xác nhận đã chạy phiên bản đã được vá.
- Chứng chỉ Java: Xem hướng dẫn của nhà cung cấp về runtime Java và thư viện chứng chỉ được sử dụng cho từng cài đặt.
- Liên kết bên ngoài: Kiểm tra các liên kết HTTPS trỏ đến các dịch vụ ký tên từ xa, dữ liệu và xây dựng khối.
- Thông báo bảo mật: Lưu ý các xác nhận về cuộc tấn công hoặc thông tin bổ sung từ đội ngũ khách hàng và nhà cung cấp Java.
Frequently Asked Questions
Sự kiện eMudhra là gì?
Sự cố này liên quan đến khóa riêng yếu gắn với chứng chỉ trung gian của Cơ quan cấp chứng chỉ eMudhra. Các nhà nghiên cứu phát hiện rằng các khóa này có thể được khôi phục từ thông tin công khai, cho phép người khác tạo chứng chỉ cho các miền mà họ không kiểm soát. Phần mềm tin tưởng vào chuỗi chứng chỉ bị ảnh hưởng có thể chấp nhận danh tính giả mạo này. Tuy nhiên, kẻ tấn công vẫn cần một cách nào đó để chặn hoặc chuyển hướng kết nối để giả mạo dịch vụ mục tiêu.
Consensus của Ethereum có thất bại không?
Không. Vấn đề trong báo cáo liên quan đến cách phần mềm kiểm tra danh tính của các dịch vụ bên ngoài, chứ không phải các quy tắc đồng thuận của Ethereum trên blockchain. Cập nhật client thay đổi niềm tin vào chứng chỉ trong môi trường phần mềm bị ảnh hưởng. Một số triển khai người xác thực vẫn có thể đối mặt với rủi ro vận hành nếu dịch vụ bên ngoài bị giả mạo. Khả năng này phụ thuộc vào kết nối và vai trò của dịch vụ, và không có nghĩa là các quy tắc đồng thuận của Ethereum bị phá vỡ.
Which clients have been updated?
Teku 26.10.3 và Besu 26.10.2 đã cập nhật hình ảnh Docker của chúng để loại bỏ các chứng chỉ đáng ngờ. Teku là client đồng thuận, Besu là client thực thi, cả hai đều sử dụng Java. Cách cài đặt rất quan trọng vì thay đổi này áp dụng cho môi trường được cung cấp trong các hình ảnh này. Những người vận hành cài đặt client qua tệp lưu trữ và tự cung cấp runtime Java cần xem hướng dẫn riêng cho runtime đó.
Will all validators be affected?
Không. Thông báo từ Teku cho biết các nút mạng chính mặc định không bị ảnh hưởng. Mức độ rủi ro phụ thuộc vào việc một triển khai cụ thể có thực hiện kết nối HTTPS bên ngoài liên quan hay không, cũng như việc kiểm tra chứng chỉ của nó có chấp nhận đường dẫn tin cậy bị ảnh hưởng hay không. Các nhà vận hành khác nhau có thể chạy cùng một client trên các dịch vụ, phiên bản Java và thư viện chứng chỉ khác nhau. Do đó, tên client hoặc số ETH được stakes không thể cho biết một validator cụ thể nào có bị phơi nhiễm hay không.
Docker update có thể ghi đè tất cả các phương pháp cài đặt không?
Không. Hình ảnh Docker sau khi vá sẽ cập nhật môi trường được đóng gói trong hình ảnh đó, nhưng việc cài đặt qua tệp lưu trữ có thể sử dụng Java do người vận hành cung cấp riêng. Các container hoặc dịch vụ khác cũng có thể có runtime riêng của chúng. Người vận hành cần xác định quy trình đang chạy sử dụng phương pháp cài đặt nào và tuân theo hướng dẫn của nhà cung cấp. Các tệp đã vá trên máy chủ không thể bảo vệ các quy trình vẫn đang chạy trong môi trường cũ.
Đã xác nhận bị khai thác chưa?
Tại thời điểm được nêu trong bài viết này, thông báo từ Teku không báo cáo bất kỳ sự lợi dụng nào. Các tiết lộ liên quan mô tả một điểm yếu và các hậu quả tiềm ẩn, chứ không chứng minh rằng kẻ tấn công đã sử dụng nó để thực hiện vai trò xác minh. Sự khác biệt này rất quan trọng khi thảo luận về tổn thất. Việc tồn tại một con đường có thể giả mạo dịch vụ không đồng nghĩa với việc trách nhiệm ký được thao túng, thanh toán phí bị chuyển hướng hoặc ETH thế chấp bị đánh cắp.
Will validator deposits be automatically exposed?
Không. Khóa ký chứng chỉ khác với khóa ký người xác thực và cũng khác với chứng chỉ kiểm soát việc rút tiền. Việc khôi phục khóa chứng chỉ bị ảnh hưởng sẽ không tự động tiết lộ khóa cần thiết để rút ETH đã đặt cọc. Dịch vụ bị giả mạo vẫn có thể gây rối loạn trách nhiệm hoặc ảnh hưởng đến thông tin mà người xác thực sử dụng, tùy thuộc vào cách triển khai. Cần đánh giá các hệ quả có thể xảy ra đối với dịch vụ này, thay vì coi đó là quyền truy cập tự động vào toàn bộ khoản tiền gửi.
Người vận hành nên làm gì?
Người vận hành nên tuân theo các bản phát hành liên quan của Teku hoặc Besu, cùng với hướng dẫn của phiên bản Java của họ. Cần xác định runtime và kho chứng chỉ được sử dụng bởi từng tiến trình bị ảnh hưởng, bao gồm cả các thành phần được cung cấp trong container. Sau khi áp dụng bản cập nhật được đề xuất, cần xác nhận rằng dịch vụ đã cập nhật đang chạy và các kết nối cần thiết vẫn hoạt động bình thường. Việc vô hiệu hóa kiểm tra chứng chỉ để khôi phục kết nối bị lỗi sẽ loại bỏ các biện pháp bảo vệ mà các kiểm tra này nên cung cấp.