#btc
Khóa riêng của 8 cơ quan cấp chứng chỉ trung gian yếu đến mức có thể tính trực tiếp từ chứng chỉ công khai
Trình duyệt đã đưa loạt chứng chỉ này vào danh sách đen, nhưng một số client Ethereum vẫn tiếp tục tin cậy chúng
📣 盘面异动群里喊
Ngày 17 tháng 10, các nhà nghiên cứu bảo mật phát hiện lỗ hổng số ngẫu nhiên này ở cơ quan cấp chứng chỉ eMudhra của Ấn Độ
Vấn đề nằm ở bước tạo khóa: tính ngẫu nhiên không đủ, khiến khóa riêng có thể suy ra từ một phần giá trị công khai
Ai có được 8 khóa riêng này đều có thể ký một chứng chỉ mà phần mềm chưa được vá sẽ coi là hợp lệ
Các nhà cung cấp trình duyệt ra tay trước. Một ngày sau, eMudhra thu hồi loạt chứng chỉ trung gian này và tuyên bố rút khỏi lĩnh vực kinh doanh chứng chỉ
Rắc rối thực sự nằm ở Java
Java mặc định không kiểm tra chứng chỉ đã bị thu hồi hay chưa
Vì vậy, các Docker image dựng sẵn của Teku vẫn tin cậy những chứng chỉ này sau khi trình duyệt đưa chúng vào danh sách đen
Teku phát hành phiên bản mới vào thứ Ba, Besu phát hành phiên bản mới vào thứ Hai; cả hai đều loại eMudhra khỏi danh sách tin cậy 🔐
Lộ trình tấn công không phức tạp
Một nút có thể chen vào giữa validator và dịch vụ mà nó kết nối có thể giả mạo dịch vụ đó
Validator bị lừa có thể đề xuất một khối và chuyển phí giao dịch đến địa chỉ của kẻ tấn công
Đáng lo hơn là dịch vụ ký bên ngoài giả mạo: nó nắm quyền ký để thay đổi địa chỉ nhận phần thưởng 💥
Teku xếp trường hợp này vào mức rủi ro cao nhất
Cần nói rõ rằng các nút Teku trên mainnet dùng cấu hình mặc định không bị ảnh hưởng và không cần thực hiện bất kỳ thao tác nào
Hiện chưa có báo cáo nào về việc lỗ hổng bị khai thác trên thực tế. Vấn đề được Consensys Diligence phát hiện đầu tiên
Nhưng những người tự chạy client trực tiếp sẽ có việc phải làm
Chỉ nâng cấp phần mềm Ethereum là chưa đủ; danh sách tin cậy của Java sẽ không tự thay đổi theo
Docker image mới cũng không thể sửa Java trên máy chủ
Những người vẫn dùng Java 26 còn gặp rắc rối hơn: phiên bản đó đã ngừng được hỗ trợ, không có bản vá; lựa chọn duy nhất là nâng cấp lên Java 25 ⚠️
Theo tôi, sự cố lần này không phơi bày vấn đề ở lớp đồng thuận của Ethereum, mà là bộ hạ tầng Internet cũ kỹ hơn hai mươi năm nằm bên dưới
Cơ quan cấp chứng chỉ, số ngẫu nhiên, hành vi mặc định của Java
Chỉ cần một mắt xích lỏng lẻo, dù blockchain có vững đến đâu, người ta vẫn có thể lách qua từ bên cạnh 🦖
Người nắm giữ tiền mã hóa thông thường không cần lo lắng về tin này
Còn với người staking và tự vận hành nút, đây là lời nhắc nhở: rốt cuộc ai đang duy trì danh sách tin cậy của bạn?
Giá hiện tại: ETH khoảng 2309 USD, giảm 2% trong một ngày; BTC khoảng 79830 USD, giảm 1,41% trong một ngày
Thị trường đang giảm. Những bản vá hạ tầng kiểu này sẽ không được phản ánh vào giá trong ngắn hạn, nhưng sớm muộn gì cũng sẽ
Cùng thảo luận ở phần bình luận: quanh bạn có ai tự chạy nút không? Lần gần nhất họ cập nhật Java là khi nào?
Mỗi ngày, tôi giúp bạn theo dõi các điểm nóng về bảo mật tiền mã hóa — không chỉ cập nhật tin tức mà còn giúp bạn hiểu logic và cơ hội đằng sau 👀🚀
Khóa riêng của 8 cơ quan cấp chứng chỉ trung gian yếu đến mức có thể tính trực tiếp từ chứng chỉ công khai
Trình duyệt đã đưa loạt chứng chỉ này vào danh sách đen, nhưng một số client Ethereum vẫn tiếp tục tin cậy chúng
📣 盘面异动群里喊
Ngày 17 tháng 10, các nhà nghiên cứu bảo mật phát hiện lỗ hổng số ngẫu nhiên này ở cơ quan cấp chứng chỉ eMudhra của Ấn Độ
Vấn đề nằm ở bước tạo khóa: tính ngẫu nhiên không đủ, khiến khóa riêng có thể suy ra từ một phần giá trị công khai
Ai có được 8 khóa riêng này đều có thể ký một chứng chỉ mà phần mềm chưa được vá sẽ coi là hợp lệ
Các nhà cung cấp trình duyệt ra tay trước. Một ngày sau, eMudhra thu hồi loạt chứng chỉ trung gian này và tuyên bố rút khỏi lĩnh vực kinh doanh chứng chỉ
Rắc rối thực sự nằm ở Java
Java mặc định không kiểm tra chứng chỉ đã bị thu hồi hay chưa
Vì vậy, các Docker image dựng sẵn của Teku vẫn tin cậy những chứng chỉ này sau khi trình duyệt đưa chúng vào danh sách đen
Teku phát hành phiên bản mới vào thứ Ba, Besu phát hành phiên bản mới vào thứ Hai; cả hai đều loại eMudhra khỏi danh sách tin cậy 🔐
Lộ trình tấn công không phức tạp
Một nút có thể chen vào giữa validator và dịch vụ mà nó kết nối có thể giả mạo dịch vụ đó
Validator bị lừa có thể đề xuất một khối và chuyển phí giao dịch đến địa chỉ của kẻ tấn công
Đáng lo hơn là dịch vụ ký bên ngoài giả mạo: nó nắm quyền ký để thay đổi địa chỉ nhận phần thưởng 💥
Teku xếp trường hợp này vào mức rủi ro cao nhất
Cần nói rõ rằng các nút Teku trên mainnet dùng cấu hình mặc định không bị ảnh hưởng và không cần thực hiện bất kỳ thao tác nào
Hiện chưa có báo cáo nào về việc lỗ hổng bị khai thác trên thực tế. Vấn đề được Consensys Diligence phát hiện đầu tiên
Nhưng những người tự chạy client trực tiếp sẽ có việc phải làm
Chỉ nâng cấp phần mềm Ethereum là chưa đủ; danh sách tin cậy của Java sẽ không tự thay đổi theo
Docker image mới cũng không thể sửa Java trên máy chủ
Những người vẫn dùng Java 26 còn gặp rắc rối hơn: phiên bản đó đã ngừng được hỗ trợ, không có bản vá; lựa chọn duy nhất là nâng cấp lên Java 25 ⚠️
Theo tôi, sự cố lần này không phơi bày vấn đề ở lớp đồng thuận của Ethereum, mà là bộ hạ tầng Internet cũ kỹ hơn hai mươi năm nằm bên dưới
Cơ quan cấp chứng chỉ, số ngẫu nhiên, hành vi mặc định của Java
Chỉ cần một mắt xích lỏng lẻo, dù blockchain có vững đến đâu, người ta vẫn có thể lách qua từ bên cạnh 🦖
Người nắm giữ tiền mã hóa thông thường không cần lo lắng về tin này
Còn với người staking và tự vận hành nút, đây là lời nhắc nhở: rốt cuộc ai đang duy trì danh sách tin cậy của bạn?
Giá hiện tại: ETH khoảng 2309 USD, giảm 2% trong một ngày; BTC khoảng 79830 USD, giảm 1,41% trong một ngày
Thị trường đang giảm. Những bản vá hạ tầng kiểu này sẽ không được phản ánh vào giá trong ngắn hạn, nhưng sớm muộn gì cũng sẽ
Cùng thảo luận ở phần bình luận: quanh bạn có ai tự chạy nút không? Lần gần nhất họ cập nhật Java là khi nào?
Mỗi ngày, tôi giúp bạn theo dõi các điểm nóng về bảo mật tiền mã hóa — không chỉ cập nhật tin tức mà còn giúp bạn hiểu logic và cơ hội đằng sau 👀🚀