Lỗi TLS trong GoAhead âm thầm chấp nhận chứng chỉ đã thu hồi và làm suy yếu mã hóa

EmbedThis đã phát hành GoAhead phiên bản 6.1.1 vào ngày 12 tháng 10 năm 2026 để khắc phục các lỗi bảo mật nghiêm trọng trong máy chủ web nhúng được sử dụng rộng rãi của họ. Bản cập nhật này sửa chữa các vấn đề cho phép chứng chỉ khách hàng đã thu hồi vượt qua xác thực và làm suy yếu mã hóa trong một số bản build TLS, ảnh hưởng đến potentially hàng trăm triệu thiết bị IoT.

Chuyện gì đã xảy ra

Lỗ hổng chính, được xác định là CVE-2026-115881 với mức độ nghiêm trọng do nhà cung cấp đánh giá là 9.1, ảnh hưởng đến các bản build GoAhead sử dụng backend OpenSSL với tính năng mutual TLS (TLS hai chiều) được bật. Trong các cấu hình này, máy chủ tải danh sách thu hồi chứng chỉ khi khởi động nhưng không thực thi nó. Do đó, các khách hàng trình bày chứng chỉ đã bị thu hồi, chẳng hạn như từ các thiết bị bị đánh cắp hoặc ngừng hoạt động, sẽ được chấp nhận ngầm định là hợp lệ. Lỗi này tồn tại trong các phiên bản từ 3.4.5 đến 6.1.0 khi các cài đặt do người vận hành cấu hình bao gồm gói chứng chỉ cơ quan cấp tin cậy (trusted CA), kiểm tra issuer và danh sách thu hồi.

Nhà nghiên cứu Sébastien Féry từ FoxIO đã công bố vấn đề này cùng với hai sự cố liên quan đến TLS khác vào ngày 26 tháng 10 năm 2026. Mặc dù bản vá đã được cung cấp cho các nhà sản xuất thiết bị vào ngày 2 tháng 8 năm 2026, việc công khai thông tin diễn ra sau đó vào tháng 10. EmbedThis tuyên bố rằng chưa có báo cáo về việc khai thác tích cực, mặc dù thời điểm phát hành phối hợp cho thấy không có cuộc tấn công nào đang diễn ra vào thời điểm công bố.

Hai lỗ hổng bổ sung cũng được khắc phục trong cùng bản phát hành. Một lỗ hổng ảnh hưởng đến các bản build sử dụng phiên bản LibreSSL cũ hơn (3.2.x và 3.3.2–3.3.6), cho phép các chuỗi chứng chỉ vượt quá giới hạn mười chứng chỉ bỏ qua bước xác thực khi tắt tính năng kiểm tra issuer. Lỗ hổng còn lại tác động đến các bản build Mbed TLS (phiên bản từ 4.0.2 đến 6.1.0), nơi một lỗi lập trình khiến máy chủ gửi một giá trị Diffie-Hellman dài một byte thay vì giá trị 2048-bit như dự kiến. Điểm yếu này cho phép các bên quan sát thụ động giải mã các phiên nếu phía khách hàng chấp nhận trao đổi khóa bị sai lệch.

Cơ chế hoạt động

Lỗi OpenSSL bắt nguồn từ một lỗi logic, nơi danh sách thu hồi được nạp vào bộ nhớ nhưng không bao giờ được tham chiếu tích cực trong quá trình bắt tay (handshake). Máy chủ không báo cáo lỗi nào khi khởi động, tạo cảm giác an toàn giả cho người vận hành. Khi một khách hàng trình bày chứng chỉ, máy chủ xác minh chữ ký của nó dựa trên cơ quan cấp tin cậy nhưng bỏ qua bước kiểm tra xem số sê-ri của chứng chỉ cụ thể đó có xuất hiện trong danh sách thu hồi hay không. Điều này cho phép bất kỳ chứng chỉ nào được ký bởi một cơ quan cấp tin cậy đều được cấp quyền truy cập, bất kể trạng thái thu hồi của nó.

Vấn đề với Mbed TLS liên quan đến một lỗi đánh máy trong đoạn mã xử lý trao đổi khóa Diffie-Hellman trường hữu hạn. Thay vì truyền một giá trị công khai mạnh mẽ 2048-bit, máy chủ chỉ gửi một byte duy nhất. Các khách hàng phổ biến như trình duyệt hiện đại, Java và Go từ chối giá trị nhỏ này và hủy kết nối. Tuy nhiên, các khách hàng nhúng hoặc tùy chỉnh thiếu kiểm tra kích thước tối thiểu có thể chấp nhận nó, thiết lập một khóa phiên yếu mà kẻ nghe lén dễ dàng tính toán được. Lỗ hổng này không ảnh hưởng đến các phiên TLS 1.3 hoặc ECDHE.

Chi tiết chính

• CVE-2026-115881: Được đánh giá 9.1, ảnh hưởng đến các bản build OpenSSL từ 3.4.5–6.1.0 với mutual TLS và danh sách thu hồi được cấu hình; chứng chỉ đã thu hồi được chấp nhận.
• CVE-2026-115884: Được đánh giá 7.4, ảnh hưởng đến các bản build LibreSSL 3.2.x và 3.3.2–3.3.6; cho phép các chuỗi chứng chỉ quá dài khi tắt kiểm tra issuer.
• Lỗi Mbed TLS: Được đánh giá 5.9, ảnh hưởng đến các phiên bản từ 4.0.2–6.1.0; gửi các giá trị Diffie-Hellman 1-byte, cho phép giải mã phiên bởi các bên quan sát thụ động.
• Khả năng khắc phục: GoAhead 6.1.1 giải quyết tất cả các vấn đề; chủ sở hữu thiết bị phải chờ các nhà sản xuất tung ra các bản cập nhật firmware chứa phiên bản này.
• Bản vá bổ sung: Phiên bản 6.1.1 cũng vá một lỗi bỏ qua đăng nhập, cho phép truy cập bằng bất kỳ mật khẩu nào nếu tên người dùng đã biết và được lưu trữ dưới định dạng Blowfish.
• Phát hiện: FoxIO cung cấp các dấu vết công cụ JA4Scan để xác định các backend GoAhead, mặc dù điều này chỉ xác định loại bản build chứ không phải lỗ hổng đã được xác nhận chắc chắn.

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

Đối với các kỹ sư quản lý hạ tầng IoT, sự cố này làm nổi bật tính mờ ám của chuỗi cung ứng phần mềm nhúng. GoAhead chạy trên các router, máy in và bộ điều khiển công nghiệp từ các nhà cung cấp lớn như HP, Siemens và D-Link. Vì backend TLS và các cài đặt được biên dịch vào firmware, chủ sở hữu thiết bị không thể xác định mức độ rủi ro của mình nếu không kiểm tra sâu hoặc xác nhận từ nhà cung cấp. Khoảng cách giữa việc phát hành bản vá cho các nhà sản xuất vào tháng 8 và công khai thông tin vào tháng 10 nhấn mạnh chu kỳ vá chậm chạp điển hình của các thiết bị nhúng, khiến hệ thống dễ bị tổn thương trong thời gian dài.

Sự thất bại âm thầm của việc kiểm tra thu hồi đặc biệt nguy hiểm cho các môi trường dựa vào mutual TLS để xác thực thiết bị. Người vận hành cấu hình rõ ràng các danh sách thu hồi để quản lý bảo mật vòng đời thiết bị bị đánh lừa tin rằng các biện pháp kiểm soát của họ đang hoạt động. Điều này làm xói mòn niềm tin vào các cơ chế xác thực dựa trên chứng chỉ, vốn thường là tuyến phòng thủ chính cho các thiết bị headless (không giao diện người dùng truyền thống). Sự hiện diện của một lỗi bỏ qua đăng nhập trong cùng bản phát hành càng làm tăng thêm rủi ro, cho thấy nhiều lớp phòng thủ có thể bị xâm phạm đồng thời.

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

• Xác định các thiết bị chạy GoAhead trong môi trường của bạn và liên hệ với nhà sản xuất để xác nhận xem họ đã tung ra firmware dựa trên phiên bản 6.1.1 hay chưa.
• Nếu bạn kiểm soát quy trình xây dựng firmware, hãy nâng cấp lên GoAhead 6.1.1 ngay lập tức và xây dựng lại các image của bạn.
• Đối với các bản build Mbed TLS, hãy tắt các suite DHE trường hữu hạn hoặc chuyển sang backend OpenSSL như một biện pháp giảm nhẹ tạm thời trước khi cập nhật.
• Đối với các bản build LibreSSL, hãy bật kiểm tra issuer với một gói CA tin cậy hoặc nâng cấp lên LibreSSL 4.x nếu có thể.
• Sau khi nâng cấp, hãy kết thúc tất cả các phiên đang hoạt động, khởi động lại máy chủ và xoay vòng (rotate) bất kỳ mật khẩu nào được lưu trữ dưới định dạng Blowfish.
• Sử dụng các công cụ như JA4Scan để lấy dấu vết (fingerprint) các instance GoAhead và xác định backend TLS nào chúng đang sử dụng, giúp ưu tiên hóa nỗ lực khắc phục.