Phân Tích Chuyên Sâu CVE-2026-42208: Lỗ Hổng Pre-Auth SQL Injection Nghiêm Trọng Trên LiteLLM AI Gateway

1. Bối Cảnh Lỗ Hổng và Tầm Ảnh Hưởng

LiteLLM hoạt động như một lớp trung gian (proxy) đứng trước hàng trăm mô hình AI (OpenAI, Anthropic, Gemini, v.v.), có nhiệm vụ định tuyến yêu cầu, theo dõi chi phí và kiểm soát giới hạn tỷ lệ (rate limit). Để làm được điều này, LiteLLM quản lý một cơ sở dữ liệu (thường là PostgreSQL) chứa toàn bộ các khóa API gốc, cấu hình môi trường và token ảo của người dùng cuối.

Việc CVE-2026-42208 cho phép kẻ tấn công thực thi truy vấn SQL tự do đồng nghĩa với việc toàn bộ các bí mật (secrets) này bị phơi bày. Kẻ tấn công không chỉ có thể trộm khóa API để sử dụng lậu các mô hình AI đắt tiền, mà còn có thể sửa đổi cấu trúc dữ liệu để chèn backdoor hoặc leo thang đặc quyền vào hạ tầng đám mây nội bộ.

2. Phân Tích Nguyên Nhân Gốc Rễ (Root Cause Analysis)

Trọng tâm của lỗ hổng nằm ở quy trình xác thực (Authentication) khi LiteLLM xử lý các API request gửi đến proxy. Lỗi xuất hiện trong logic kiểm tra token tại hàm xác minh khóa nội bộ:

• Khi một request đến (ví dụ gửi vào endpoint /v1/chat/completions), hệ thống sẽ trích xuất giá trị từ header Authorization: Bearer <token>.
• Thay vì sử dụng các truy vấn tham số hóa (Parameterized Queries) chuẩn mực, các phiên bản LiteLLM bị ảnh hưởng lại tiến hành nối chuỗi trực tiếp (string concatenation) giá trị token do người dùng cung cấp vào thẳng câu lệnh truy vấn SQL.
• Cơ chế này mở ra cánh cửa cho kẻ tấn công chèn các ký tự đặc biệt (như dấu nháy đơn ') để thoát khỏi cấu trúc SQL nguyên bản và tiêm vào các mệnh đề độc hại.

3. Kịch Bản Khai Thác Bằng Time-Based Blind SQLi

Do máy chủ proxy LiteLLM luôn trả về cùng một định dạng JSON báo lỗi HTTP 401 khi xác thực thất bại, kẻ tấn công không thể đọc trực tiếp kết quả truy vấn SQL trên màn hình (In-band SQLi). Thay vào đó, kỹ thuật Time-Based Blind SQLi được sử dụng để trích xuất dữ liệu từng byte một.

POST /v1/chat/completions HTTP/1.1
Host: litellm-proxy.target.com
Content-Type: application/json
# Tiêm payload SQL trực tiếp vào Authorization header
Authorization: Bearer invalid_key' OR (SELECT 1 FROM (SELECT pg_sleep(5))x) AND '1'='1

{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "Hello"}]
}

Phân tích Payload: Nếu cơ sở dữ liệu xử lý payload trên và bị đình trệ đúng 5 giây trước khi trả về phản hồi HTTP 401, kẻ tấn công sẽ xác nhận lỗ hổng tồn tại. Từ đó, chúng có thể tự động hóa việc rò rỉ bảng LiteLLM_VerificationToken thông qua các phép toán logic kết hợp độ trễ.

4. Phương Pháp Threat Hunting & Rà Quét Dấu Hiệu Thỏa Hiệp

Việc phát hiện CVE-2026-42208 đòi hỏi sự kết hợp giữa giám sát biên (WAF) và phân tích log cơ sở dữ liệu:

1. Phân tích Log HTTP: Tìm kiếm các header Authorization có độ dài bất thường hoặc chứa các hàm đặc trưng của PostgreSQL như pg_sleep, version(), current_database(), hay các ký tự comment --.
2. Giám sát Database (PostgreSQL): Sử dụng pg_stat_statements để rà soát lịch sử các truy vấn tốn thời gian thực thi dài bất thường (Slow Queries) hoặc có cú pháp chèn ép logic lạ xuất phát từ nền tảng LiteLLM.
3. Dấu hiệu mạng (Network IoC): Các cuộc tấn công thực tế thường sử dụng các công cụ tự động từ những địa chỉ IP bị gắn cờ độc hại cố tình quét endpoint /chat/.

5. Ứng Dụng Thực Chiến Vào Hệ Thống Lab Đào Tạo

Đối với công tác đào tạo an toàn thông tin, CVE-2026-42208 là một case-study hoàn hảo về lỗ hổng bảo mật trong các ứng dụng AI hiện đại để học viên có thể mổ xẻ thực tế. Việc đóng gói lỗ hổng này vào một Docker container và triển khai lên các nền tảng thực hành nội bộ (Cyber Range) sẽ mang lại giá trị rất lớn.

Học viên có thể trực tiếp quan sát luồng giao tiếp giữa ứng dụng proxy và database, thực hành kỹ năng trích xuất dữ liệu bằng sqlmap trong môi trường mù (Blind SQLi), và sau đó đóng vai Blue Team để viết các tập luật (rules) phòng vệ ngay trên tường lửa ứng dụng web (WAF).

6. Giải Pháp Khắc Phục (Remediation)