Khóa yếu của eMudhra cho phép giả mạo chứng chỉ tức thì và việc vá lỗi chậm chạp

Vào ngày 19 tháng 10 năm 2026, Cloudflare đã xác định một sự cố bảo mật nghiêm trọng liên quan đến eMudhra, một cơ quan cấp chứng chỉ (certificate authority) đã tạo ra tám khóa riêng trung gian với độ ngẫu nhiên (entropy) không đáng kể. Thay vì sử dụng các số phức tạp và khó đoán, eMudhra đã dùng những số nguyên đơn giản như 4, 56 và 237, cho phép bất kỳ ai cũng có thể tái tạo lại các khóa riêng từ các chứng chỉ công khai. Lỗ hổng chưa từng có này giúp tin tặc giả mạo các chứng chỉ TLS hợp lệ cho bất kỳ tên miền nào, qua đó vượt qua các biện pháp bảo vệ mã hóa tiêu chuẩn đối với các máy khách chưa được vá lỗi.

Chuyện gì đã xảy ra

Vấn đề cốt lõi bắt nguồn từ một sai lầm thảm khốc trong quy trình tạo khóa của eMudhra. Một cơ quan cấp chứng chỉ được tin cậy để chọn một số ngẫu nhiên khổng lồ làm nền tảng cho bảo mật mật mã của mình. Trong trường hợp này, eMudhra lại chọn các số có một hoặc hai chữ số. Vì những giá trị này quá nhỏ, kẻ tấn công có thể khôi phục khóa ký riêng gần như ngay lập tức chỉ bằng cách sử dụng chứng chỉ công khai. Điều này khác biệt hoàn toàn so với các vụ vi phạm CA trước đây, chẳng hạn như DigiNotar hay TrustWave, nơi các khóa bị đánh cắp là tài sản được bảo vệ và chỉ tiếp cận được bởi các nhóm đe dọa cụ thể. Ở đây, các khóa này về mặt toán học rất dễ suy ra bởi bất kỳ ai có công cụ cơ bản.

Cloudflare đã phản hồi ngay lập tức bằng cách vá các hệ thống tác động cao của mình, bao gồm các proxy Pingora, chỉ trong vòng vài giờ sau khi phát hiện. Họ đã sử dụng phân tích mã hỗ trợ bởi AI để xác định tất cả các hệ thống nội bộ tin tưởng vào các khóa yếu này, đồng thời gán các vé khắc phục dựa trên mức độ rủi ro. Để giám sát việc khai thác trong thực tế, Cloudflare đã thêm nhật ký để phát hiện các bắt tay (handshake) liên quan đến các khóa bị xâm phạm. Trong vòng một tuần, họ ghi nhận khoảng 22.000 lần thử bắt tay. Mặc dù phần lớn là các bài kiểm tra vô hại hoặc cấu hình tự ký, khoảng 160 lần thử liên quan đến các chứng chỉ giả mạo nêu tên các tên miền không liên quan, bao gồm cả các thiết bị IoT tiêu dùng. Các hành vi giả mạo này xuất hiện chỉ trong vài giờ sau khi lỗ hổng trở nên công khai, mặc dù không phát hiện thấy việc chặn đứng lưu lượng truy cập của Cloudflare thành công.

Để đánh giá mức độ dễ bị tổn thương trên toàn cầu, Cloudflare đã triển khai các kết nối thăm dò thông qua các trang thử thách của họ, kiểm tra xem trình duyệt của khách truy cập có chấp nhận các chứng chỉ được ký bởi các khóa yếu hay không. Dữ liệu tiết lộ sự chậm trễ đáng lo ngại trong việc áp dụng các bản vá. Trong khi các trình duyệt desktop hiện đại phần lớn đã được cập nhật, các hệ thống nhúng như Android WebView vẫn chấp nhận các chuỗi chứng chỉ bị xâm phạm với tỷ lệ 30–40%. Hơn nữa, hơn một nửa số cuộc thăm dò trên các mạng chính vẫn tin tưởng vào các chứng chỉ không hợp lệ, cho thấy một phần đáng kể của internet vẫn đang bị phơi bày trước các cuộc tấn công man-in-the-middle tiềm năng.

Chi tiết chính

• eMudhra đã sử dụng các số nguyên cực kỳ yếu (4, 56, 66, 115, 155, 156, 230, 237) cho tám khóa riêng trung gian.
• Khóa riêng có thể được khôi phục ngay lập tức từ các chứng chỉ công khai, cho phép giả mạo chứng chỉ không giới hạn.
• Cloudflare quan sát thấy khoảng 22.000 lần thử bắt tay sử dụng các khóa yếu trong vòng một tuần sau khi công bố.
• Các chứng chỉ giả mạo đã được tạo ra sớm nhất là vào ngày 20 tháng 10, chưa đầy một giờ sau khi Mozilla công bố báo cáo lỗi.
• Hơn 50 triệu cuộc thăm dò cho thấy nhiều trình duyệt nhúng và bot vẫn tin tưởng vào chuỗi chứng chỉ bị xâm phạm.
• eMudhra đã tuyên bố rút khỏi mảng kinh doanh CA công cộng nhưng chưa công bố script tạo khóa bị lỗi.

Bối cảnh

Các Cơ quan Cấp Chứng chỉ (CAs) là bên thứ ba được tin cậy, chịu trách nhiệm phát hành các chứng chỉ kỹ thuật số để xác minh danh tính của các trang web. Những chứng chỉ này dựa vào mật mã khóa công khai, trong đó khóa riêng ký dữ liệu và khóa công khai xác minh nó. Bảo mật của hệ thống này phụ thuộc hoàn toàn vào việc khóa riêng phải được giữ bí mật và được tạo ra với độ ngẫu nhiên cao, nghĩa là nó được chọn từ một tập hợp khổng lồ các số có thể. Nếu con số đó dễ đoán hoặc nhỏ, mối quan hệ toán học giữa khóa công khai và khóa riêng sẽ trở nên dễ dàng đảo ngược.

Trong sự cố này, việc thiếu độ ngẫu nhiên có nghĩa là "ổ khóa" bảo vệ mô hình tin cậy của internet thực chất đã bị bỏ ngỏ. Bất kỳ tác nhân nào cũng có thể tạo ra một chứng chỉ hợp lệ cho một tên miền mục tiêu, chẳng hạn như trang web ngân hàng hoặc cổng thông tin nội bộ của doanh nghiệp. Các máy khách không tuân thủ Certificate Transparency hoặc không kiểm tra danh sách thu hồi sẽ chấp nhận các chứng chỉ giả mạo này là hợp pháp, cho phép tin tặc giải mã và sửa đổi lưu lượng truy cập mà không kích hoạt cảnh báo trình duyệt.

Tại sao điều này quan trọng

Đối với các đội ngũ quản lý cơ sở hạ tầng tự chủ (self-hosted) hoặc dịch vụ nội bộ, sự cố này nhấn mạnh sự mong manh của niềm tin ngầm định vào các CA bên ngoài. Ngay cả khi tổ chức của bạn không trực tiếp sử dụng eMudhra, các thiết bị của nhân viên, ứng dụng di động và điểm cuối IoT của bạn vẫn có thể tin tưởng vào các chứng chỉ gốc hoặc trung gian bị xâm phạm. Nếu một kẻ tấn công giả mạo chứng chỉ cho tên miền nội bộ của bạn, các máy khách chưa được vá lỗi có thể kết nối với một máy chủ độc hại và tin rằng đó là dịch vụ hợp pháp của bạn. Rủi ro này đặc biệt nghiêm trọng đối với các hệ thống cũ, thiết bị nhúng và bot tự động không nhận được các bản cập nhật bảo mật thường xuyên.

Tỷ lệ vá lỗi chậm chạp giữa các trình duyệt nhúng và máy khách cấp độ mạng cho thấy các lỗ hổng trong chuỗi cung ứng tồn tại lâu sau khi được công bố. Các nhà lãnh đạo IT phải giả định rằng một phần người dùng của họ vẫn dễ bị tổn thương trước việc giả mạo chứng chỉ. Chỉ dựa vào các bản cập nhật trình duyệt là không đủ; các tổ chức cần giám sát chủ động để phát hiện việc sử dụng chứng chỉ bất thường và đảm bảo các dịch vụ của họ từ chối rõ ràng các thông tin đăng nhập yếu hoặc đã bị thu hồi. Sự kiện này nhấn mạnh nhu cầu về các kho lưu trữ tin cậy động có thể thu hồi nhanh chóng các tác nhân xấu, thay vì dựa vào các danh sách tĩnh mất nhiều tháng để lan truyền.

Bạn có thể làm gì

• Cập nhật tất cả các hệ điều hành, trình duyệt và phần mềm nhúng lên phiên bản mới nhất để đảm bảo các gốc yếu không còn được tin cậy.
• Cấu hình máy chủ để tuân thủ nghiêm ngặt certificate transparency và từ chối các chứng chỉ từ các CA bị xâm phạm đã biết.
• Giám sát nhật ký tìm kiếm các bắt tay TLS liên quan đến các khóa trung gian của eMudhra để phát hiện các nỗ lực chặn đứng tiềm năng.
• Kiểm toán các ứng dụng nội bộ và thiết bị IoT để xác nhận chúng không hardcode niềm tin vào các khóa eMudhra bị ảnh hưởng.
• Làm theo các hướng dẫn khắc phục do cộng đồng đóng góp, đặc biệt dành cho các nhà phát triển macOS có thể cần điều chỉnh kho lưu trữ tin cậy thủ công.
• Triển khai cảnh báo tự động cho các thay đổi chứng chỉ trên các tên miền quan trọng để nhanh chóng phát hiện các việc phát hành trái phép.