DeepSeek Harness cho phép một kẻ tấn công trong môi trường sandbox thực thi các lệnh tùy ý chỉ bằng cách thay đổi HTTP Host header thành 127.0.0.1, đạt mức điểm 9.4 trên thang đo CVSS. Lỗ hổng này cho thấy một quyết định tin tưởng sai lầm duy nhất có thể biến một rào cản bảo vệ thành một cửa sau (backdoor) mở toang.
Lỗ hổng đã lọt qua như thế nào
Đoạn mã bị lỗi nằm trong một hàm duy nhất thực hiện đọc header Host của yêu cầu và nếu giá trị này bằng với địa chỉ loopback, nó sẽ coi yêu cầu đó đến từ chính máy cục bộ.
Một kẻ tấn công có khả năng thực thi mã bên trong sandbox không cần đến một payload phức tạp. Chỉ bằng cách gửi một yêu cầu HTTP với Host: 127.0.0.1, backend sẽ tin rằng lệnh gọi này bắt nguồn từ chính máy chủ và bỏ qua tất cả các cảnh báo bảo mật, kiểm tra giới hạn tốc độ (rate-limit) và các bước xác thực lệnh. Kết quả là: thực thi lệnh không giới hạn mà không cần thêm bất kỳ tương tác nào khác.
Tại sao việc tin tưởng các header lại nguy hiểm
Header là các chuỗi văn bản thuần túy do bên gọi cung cấp. Cho dù trường đó được đặt tên là Host, X-Forwarded-For, hay bất kỳ tên tùy chỉnh nào, phía client đều có thể đặt nó thành bất kỳ giá trị nào chúng muốn. Nguồn thông tin đáng tin cậy duy nhất về nguồn gốc thực sự của một kết nối là lớp truyền tải (transport layer) – địa chỉ IP nguồn của socket mà hệ điều hành ghi lại khi quá trình bắt tay TCP (TCP handshake) hoàn tất.
Khi một ứng dụng quyết định tin tưởng một header mà không xác nhận rằng nó được chèn vào bởi một proxy đã biết và được cấu hình chính xác, nó đã trao chìa khóa vương quốc vào tay kẻ tấn công. Lỗ hổng của DeepSeek Harness là một ví dụ điển hình cho sai lầm này.
Tác động thực tế: ví dụ về shell.online
Dự án mã nguồn mở shell.online, một dịch vụ cung cấp terminal trên nền web, gần đây đã ghi nhận một sai lầm tương tự. Nó sử dụng một cờ cấu hình gọi là TRUST_PROXY:
- TRUST_PROXY = 0 – ứng dụng bỏ qua header X-Forwarded-For và dựa vào địa chỉ từ xa của socket. Điều này ngăn chặn client giả mạo địa chỉ IP để lách luật giới hạn tốc độ hoặc giả danh người dùng đáng tin cậy.
- TRUST_PROXY = 1 – ứng dụng tin tưởng header X-Forwarded-For là danh tính của client. Nếu dịch vụ không nằm sau một proxy thực thụ có nhiệm vụ làm sạch (sanitise) header này, kẻ tấn công có thể cung cấp một địa chỉ IP mới trong mỗi yêu cầu, từ đó vô hiệu hóa hiệu quả mọi cơ chế giới hạn tốc độ theo từng IP.
Lỗi của DeepSeek phản ánh đúng kịch bản này: mã nguồn đã tin tưởng Host như thể nó được thiết lập bởi một proxy, trong khi dịch vụ thực tế có thể được truy cập trực tiếp.
Các nhà phát triển cần làm gì ngay bây giờ
- Kiểm tra (Audit) mọi nơi bạn đọc các header do client cung cấp. Xác định những header nào bạn coi là có thẩm quyền (ví dụ: Host, X-Forwarded-For, X-Real-IP) và xác minh rằng một proxy đáng tin cậy chắc chắn sẽ ghi đè chúng trước khi chúng đến được ứng dụng của bạn.
- Gắn các quyết định bảo mật với địa chỉ socket bất cứ khi nào có thể. Sử dụng IP nguồn do hệ điều hành cung cấp để thực hiện xác thực, giới hạn tốc độ và kiểm tra kiểm soát truy cập.
- Chỉ bật các cờ tin tưởng proxy (proxy-trust flags) khi có một reverse proxy được cấu hình chính xác đứng trước dịch vụ. Nếu bạn chạy ứng dụng trực tiếp, hãy giữ các cờ đó ở trạng thái tắt.
- Tài liệu hóa sơ đồ triển khai (deployment topology) bắt buộc trong tệp README hoặc hướng dẫn triển khai của dự án, để những người dùng tự triển khai (self-host) biết về yêu cầu tin tưởng proxy.
- Sử dụng các công cụ phân tích tĩnh (static-analysis) hoặc kiểm tra mã nguồn (code-review) để cảnh báo việc sử dụng trực tiếp các header cho các quyết định bảo mật mà không có logic xác thực proxy đi kèm.
Những điều cần lưu ý tiếp theo
Các cộng đồng cung cấp các dịch vụ web tự triển khai (self-hosted) có khả năng sẽ xem xét lại các thiết lập tin tưởng proxy của chính họ sau sự cố này.
Bài học cốt lõi rất rõ ràng: đừng bao giờ để một đoạn văn bản mà bất kỳ ai trên internet cũng có thể viết được quyết định trạng thái bảo mật của hệ thống bạn. Hãy tin tưởng lớp mạng (network layer), chứ không phải lớp yêu cầu (request layer).