Signal K Server vá lỗi đường dẫn có thể dẫn tới chiếm quyền máy chủ

Một máy chủ Signal K thường đứng giữa cảm biến, ứng dụng hàng hải và người quản trị từ xa. Nếu API tài nguyên cho phép thoát khỏi thư mục lưu trữ, kẻ tấn công không chỉ đọc dữ liệu mà còn có thể chạm tới tệp cấu hình bảo mật. GitHub rà soát ngày 30/10/2026 một cảnh báo mức nghiêm trọng: bản Signal K Server cũ có thể bị chiếm quyền nếu lộ khóa ký JWT.

Lỗ hổng path traversal hoạt động ở mức nào?

Path traversal là lỗi xử lý đường dẫn cho phép chuỗi như thư mục cha thoát khỏi vùng mà ứng dụng dự kiến. Cảnh báo GHSA-4xm8-rg9h-jhq2 mô tả API resources và applicationData có thể đọc, ghi hoặc xóa tệp ngoài thư mục gốc. Bài này không đưa chuỗi khai thác; mục tiêu là giúp quản trị viên xác định phiên bản và khóa cần thay.

Tệp đáng lo nhất là security.json, nơi có thể chứa bí mật ký JWT. JWT là thẻ xác thực được máy chủ ký để chứng minh quyền của người dùng. Nếu lấy được bí mật, kẻ tấn công có thể tạo thẻ quản trị giả và đi tiếp tới chức năng thực thi mã. Với cấu hình allow_readonly=true, nguồn cảnh báo cho biết truy cập không xác thực cũng có thể dẫn tới tác động đầy đủ.

Cảnh báo được dự án công bố ngày 18/10/2026 và GitHub rà soát, cập nhật ngày 30/10/2026. Cần phân biệt ngày sự kiện ban đầu với ngày cơ sở dữ liệu hoàn tất rà soát. Nguồn không xác nhận mọi máy chủ Signal K đã bị khai thác.

Máy chủ nào cần ưu tiên?

Ưu tiên cao nhất là instance mở trực tiếp ra Internet, dùng bản trước 2.34.0, bật truy cập chỉ đọc không cần đăng nhập hoặc cho phép ghi dữ liệu ứng dụng. Instance trong mạng tàu hoặc mạng IoT vẫn có rủi ro từ thiết bị đã bị xâm nhập và tài khoản quyền thấp.

Chạy Signal K trong container không tự loại bỏ lỗi. Nếu container gắn thư mục cấu hình của máy chủ, dùng người dùng root hoặc có quyền điều khiển Docker, việc ghi tệp có thể vượt xa dữ liệu ứng dụng. Ngược lại, hệ thống tệp chỉ đọc và phân tách volume giúp giới hạn thiệt hại nhưng vẫn phải nâng cấp.

Checklist xử lý sự cố và nâng cấp

1. Xác định phiên bản signalk-server và @signalk/resources-provider; lập danh sách instance mở Internet hoặc mạng dùng chung.
2. Sao lưu cấu hình cần thiết theo cách không ghi đè bằng chứng; ghi hash và thời điểm nếu nghi có truy cập trái phép.
3. Nâng signalk-server lên 2.34.0 và resources-provider lên 1.5.3 hoặc mới hơn, rồi khởi động lại dịch vụ.
4. Luân chuyển bí mật ký JWT và buộc các phiên đăng nhập cũ hết hiệu lực. Chỉ nâng phiên bản không thu hồi token giả đã được tạo.
5. Đổi khóa API, mật khẩu hoặc thông tin xác thực khác lưu gần security.json nếu có dấu hiệu tệp đã bị đọc.
6. Rà log API tài nguyên, thay đổi tệp, tiến trình lạ và kết nối mạng bất thường; cô lập máy nếu có bằng chứng xâm nhập.
7. Tắt allow_readonly khi không thật sự cần, đặt xác thực phía trước và giới hạn truy cập quản trị theo VPN hoặc danh sách mạng.

Giảm bề mặt tấn công sau khi vá

Chạy tiến trình bằng người dùng riêng không có shell, chỉ gắn đúng thư mục dữ liệu và không đưa socket Docker vào container. Tách mạng cảm biến khỏi mạng quản trị; cổng quản trị nên đi qua VPN hoặc cổng xác thực có giới hạn tốc độ. Sao lưu security.json phải được mã hóa và hạn chế người đọc như một khóa bí mật, không coi là tệp cấu hình thông thường.

Nếu Signal K chỉ phục vụ cục bộ, hãy ràng buộc cổng vào địa chỉ nội bộ và dùng firewall chặn Internet. Khi cần truy cập từ xa, ưu tiên VPN thay vì mở cổng trực tiếp. Theo dõi kiểm tra toàn vẹn tệp sẽ giúp phát hiện thay đổi ngoài quy trình triển khai.

Nguồn tra cứu

Hành động cho người quản trị Signal K

Hãy chuẩn bị phiên bản hai thành phần, trạng thái allow_readonly, cách mở cổng, quyền container và thời gian lưu log. Nếu cần rà phương án tách mạng hoặc chuyển instance sang môi trường cô lập, gửi các thông tin đó qua trang Cloud VPS để trao đổi mục tiêu kỹ thuật; việc đầu tiên vẫn là vá, đổi khóa và điều tra dấu hiệu xâm nhập.