Ba lỗ hổng TLS trong GoAhead: Hàng trăm triệu thiết bị IoT, công nghiệp và quân sự có nguy cơ bị ảnh hưởng

Máy chủ web nhúng GoAhead là một thành phần quen thuộc nhưng ít được chú ý trong thế giới an ninh mạng. Nó được cài trên hàng trăm triệu thiết bị IoT, tường lửa, thiết bị OT và thậm chí cả hệ thống quân sự của những tên tuổi lớn như Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin và Boeing.

Một báo cáo mới đây đã chỉ ra ba lỗ hổng TLS độc lập trong cách GoAhead tích hợp với các thư viện mã hóa khác nhau. Điều đáng lo là mức độ phơi nhiễm phụ thuộc vào backend TLS và cấu hình xác thực được đóng gói sẵn trong từng thiết bị — nghĩa là rất nhiều hệ thống đang chạy ngoài kia có thể đang mang lỗi mà chủ sở hữu không hề biết.

Ba lỗ hổng, ba mức độ nguy hiểm

Ba lỗ hổng TLS trong GoAhead và mức độ nghiêm trọng

Báo cáo phân loại ba vấn đề theo mức độ nghiêm trọng:

• Backend tương thích OpenSSL — Nghiêm trọng, CVSS 9.1 (GOAHEAD-SA-2026-0006): CRL được nạp nhưng không được thực thi, khiến chứng chỉ máy khách đã bị thu hồi vẫn được chấp nhận một cách âm thầm.
• Bộ xác thực cũ của LibreSSL — Cao, CVSS 7.4 (GOAHEAD-SA-2026-0004): Chuỗi chứng chỉ máy khách vượt quá độ sâu cho phép vẫn được chấp nhận khi bắt buộc có chứng chỉ máy khách nhưng tắt kiểm tra nhà phát hành.
• Mbed TLS — Trung bình, CVSS 5.9 (GOAHEAD-SA-2026-0005): Một lỗi đánh máy về độ dài bộ đệm làm modulus DH 2048-bit bị rút gọn xuống còn một byte, khiến các phiên TLS 1.2 DHE_RSA có thể bị giải mã.

Lỗi thứ nhất: CRL được nạp nhưng không bao giờ được kiểm tra

Backend OpenSSL của GoAhead nạp danh sách thu hồi chứng chỉ (CRL) đã cấu hình vào kho chứng chỉ, nhưng không bao giờ bật tính năng kiểm tra thu hồi. OpenSSL yêu cầu cờ X509_V_FLAG_CRL_CHECK để kích hoạt việc kiểm tra CRL — chỉ nạp file vào kho là chưa đủ.

Hậu quả là hàm check_revocation() trả về thành công trước khi kiểm tra trạng thái thu hồi. Chứng chỉ máy khách đã bị thu hồi vẫn có thể hoàn tất bắt tay mTLS, ngay cả khi đã bật xác thực nhà phát hành. Trong thử nghiệm trên GoAhead 6.1.0 với OpenSSL 3.6.2, một chứng chỉ máy khách do CA ký nhưng đã bị thu hồi vẫn vượt qua toàn bộ quá trình xác thực với mã lỗi 0 xuyên suốt chuỗi.

Đáng chú ý là X509_STORE_load_locations() vẫn trả về thành công, nên quá trình khởi động không hề đưa ra cảnh báo nào rằng việc thực thi CRL đang không hoạt động.

Phiên bản bị ảnh hưởng: GoAhead 3.4.5 đến 6.1.0 dùng backend tương thích OpenSSL có cấu hình CRL. Bản vá nằm ở 6.1.1, nơi CRL được kiểm tra ngay sau khi nạp.

Lỗi thứ hai: Lỗi đánh máy biến DH 2048-bit thành 1 byte

Đây có lẽ là lỗi "ngớ ngẩn" nhất nhưng lại gây hậu quả nghiêm trọng. Backend Mbed TLS của GoAhead cấu hình nhóm DH 2048-bit theo RFC 3526 thông qua hàm mbedtls_ssl_conf_dh_param_bin(). Tuy nhiên, độ dài modulus truyền vào hàm này lại lấy nhầm từ bộ đệm của generator.

Lỗi đánh máy khiến modulus DH bị rút gọn

Cụ thể, đoạn mã dùng sizeof(dhm_g) cho cả hai tham số, dù dhm_g chỉ dài một byte. Đáng lẽ độ dài của dhm_p phải là sizeof(dhm_p), tức 256 byte. Kết quả là mbed TLS chỉ đọc byte đầu tiên của dhm_p — giá trị 0xFF (255) — và bỏ đi 255 byte còn lại.

Trong bản tin ServerKeyExchange, tham số DH xuất hiện dưới dạng 00 01 ff, tương ứng một tham số chỉ dài một byte với giá trị 255. Điều này khiến chỉ còn tám giá trị khóa chia sẻ khả dĩ: 01, 02, 04, 08, 10, 20, 40 và 80 (hex). Kẻ nghe lén chỉ cần thử từng giá trị để tìm ra khóa đúng.

Trong bản PoC đính kèm, tác giả đã tái tạo được khóa chia sẻ chỉ sau năm lần thử, khớp với khóa của máy khách — đồng nghĩa toàn bộ phiên HTTP có thể bị giải mã hoàn toàn ngoại tuyến từ dữ liệu bắt được.

Điều kiện khai thác là máy khách phải chấp nhận tham số DH hỏng. Máy khách OpenSSL tiêu chuẩn sẽ từ chối với lỗi "modulus too small", nhưng các máy khách dễ dãi — đặc biệt là các triển khai nhúng tự viết, không kiểm tra kích thước tối thiểu — có thể hoàn tất phiên và bị giải mã.

Lỗi đánh máy này xuất hiện từ năm 2018, khi chuyển sang API tham số nhị phân, và vẫn tồn tại qua đợt tái cấu trúc TLS hồi tháng 4/2024. Mbed TLS 4.x đã loại bỏ các bộ mã TLS_DHE_*, nên không bị ảnh hưởng.

Lỗi thứ ba: Giới hạn độ sâu chuỗi bị vượt qua

GoAhead 6.1.0 đặt giới hạn độ sâu chuỗi là 10 bằng SSL_CTX_set_verify_depth(). Bộ xác thực cũ của LibreSSL 3.2.x và 3.3.2–3.3.6, vốn được dùng mặc định để xác thực peer, có một vòng lặp xây dựng chuỗi kèm chú thích FIXME — chính điều này đã thu hút sự chú ý của nhóm nghiên cứu.

Sơ đồ kiểm tra độ sâu chuỗi chứng chỉ

Vòng lặp này dừng xây dựng chuỗi mà không ghi nhận lỗi độ sâu. Thay vào đó, lỗi đến tay GoAhead dưới dạng lỗi 20 — UNABLE_TO_GET_ISSUER_CERT_LOCALLY — và bị bỏ qua khi tắt kiểm tra nhà phát hành (VERIFY_ISSUER=0). Lỗi 22, tức CERT_CHAIN_TOO_LONG, mới bị từ chối.

Trong thử nghiệm trên GoAhead 6.1.0 liên kết với LibreSSL 3.3.6, một chuỗi 17 chứng chỉ với CA tự ký do kẻ tấn công kiểm soát đã hoàn tất bắt tay, và tài nguyên phía sau yêu cầu chứng chỉ máy khách trả về HTTP 200. Cùng mã nguồn đó biên dịch với LibreSSL 4.3.1 lại nhận lỗi 22 tại độ sâu 10 và từ chối chuỗi.

Khuyến nghị cho người dùng và nhà phát triển

Với các doanh nghiệp vận hành thiết bị nhúng, đặc biệt trong môi trường OT hoặc hạ tầng quan trọng, đây là thời điểm nên rà soát lại toàn bộ hệ thống có dùng GoAhead:

• Nâng cấp lên GoAhead 6.1.1 trở lên — bản này đã vá cả ba lỗi.
• Tắt các bộ mã DHE trường hữu hạn hoặc chuyển sang backend OpenSSL để tránh lỗi rút gọn modulus DH.
• Bật VERIFY_ISSUER=1 cùng bộ CA tin cậy, hoặc dùng OpenSSL / LibreSSL 4.x thay cho bộ xác thực cũ.
• Kiểm tra log JA4S để phát hiện các phiên TLS đáng ngờ, ví dụ chữ ký t120100_009f_1ca028f07214, vốn chỉ ra việc sử dụng các bộ mã dễ bị ảnh hưởng.

Công cụ JA4Scan do FoxIO phát triển có thể giúp quét chủ động các máy chủ công khai trong hệ thống để tìm ra các backend bị ảnh hưởng thông qua dấu vân tay TLS.

Dấu vân tay JA4Scan-TLS tương ứng với từng backend

Góc nhìn cho thị trường Việt Nam

Tại Việt Nam, GoAhead xuất hiện phổ biến trong các thiết bị định tuyến, camera IP, thiết bị mạng doanh nghiệp và hệ thống giám sát công nghiệp — nhiều trong số đó là thiết bị nhập khẩu hoặc OEM với firmware đóng, ít được cập nhật định kỳ. Các đơn vị vận hành hạ tầng mạng, nhà máy thông minh và hệ thống giám sát giao thông nên đưa vấn đề này vào kế hoạch đánh giá an ninh mạng ngay trong quý tới.

Bài học rút ra từ ba lỗ hổng này khá rõ ràng: an ninh không chỉ nằm ở việc có bật tính năng hay không, mà còn ở việc tính năng đó có thực sự được thực thi trong mã nguồn. Cả ba lỗi đều không hề ngăn tiến trình bắt tay hoàn tất — đó mới là điều khiến chúng khó phát hiện và nguy hiểm.

Mã tái tạo lỗi được công bố tại kho GitHub của FoxIO, và người dùng nên theo dõi các bản tin bảo mật chính thức của GoAhead để cập nhật thông tin vá lỗi.