Lỗi phân quyền không đúng trong BerriAI LiteLLM Secret Resolution

Một lỗ hổng đã được phát hiện trong BerriAI LiteLLM đến và bao gồm phiên bản 1.94.0. Lỗ hổng này ảnh hưởng đến hàm get_secret của tệp secret_managers/main.py thuộc thành phần Secret Resolution. Việc thao túng tham số api_key dẫn đến phân quyền không đúng. Cuộc tấn công có thể được khởi tạo từ xa. Exploit đã được công khai và có thể được sử dụng. Vendor đã được liên hệ từ sớm về việc công bố này nhưng hoàn toàn không phản hồi.

• BerriAI LiteLLM: record chuẩn hóa mô tả các phiên bản đến 1.94.0 là bị ảnh hưởng.
• Danh sách affected version có cấu trúc trong record chỉ đánh dấu rõ 1.0 đến 1.19 là affected, trong khi entry CNA của VulDB liệt kê các phiên bản từ 1.0 đến 1.94.0. Do hai biểu diễn này không hoàn toàn giống nhau, nên xem LiteLLM đến 1.94.0 là có khả năng bị ảnh hưởng cho đến khi có hướng dẫn theo từng branch từ vendor.
• Thành phần bị ảnh hưởng là Secret Resolution, cụ thể là hàm get_secret trong secret_managers/main.py và tham số api_key.
• Record không cung cấp fixed release hoặc solution chính thức.

Lỗi nằm trong hàm get_secret của tệp secret_managers/main.py, thuộc thành phần Secret Resolution của BerriAI LiteLLM. Theo dữ liệu CNA, việc thao túng tham số api_key với giá trị đầu vào chưa được mô tả dẫn đến kiểm tra phân quyền không đúng. Lỗ hổng có thể được tiếp cận từ xa; metadata tấn công cho biết cần một mức đặc quyền thấp, không cần tương tác người dùng và độ phức tạp thấp. Bằng chứng hiện có không xác định endpoint, schema request, secret backend, ranh giới phân quyền cụ thể hoặc dữ liệu chính xác được trả về. Việc lộ secret của user hoặc service khác là hậu quả có thể xảy ra, nhưng vẫn là suy luận từ vai trò của thành phần Secret Resolution chứ chưa phải một exploit trace được xác nhận.

Có thể khai thác từ xa. Metadata tấn công được cung cấp cho biết attacker cần đặc quyền thấp, không cần user interaction và thao tác có độ phức tạp thấp; cơ chế xác thực cụ thể chưa được mô tả. VulDB cho biết technical details và public proof of concept hoặc exploit đã được công khai. Record không xác nhận việc khai thác đang diễn ra ngoài thực tế, không nêu campaign cụ thể và không cung cấp payload, endpoint hay indicator cụ thể.

Kết quả kỹ thuật chính là truy cập trái phép vào kết quả hoặc thao tác của Secret Resolution vốn phải được bảo vệ bởi kiểm tra phân quyền. Tùy credential được trả về kiểm soát service nào, tác động có thể liên quan đến tính bí mật, toàn vẹn và khả dụng của các service kết nối, phù hợp với metadata tác động được cung cấp. Hậu quả đối với tổ chức có thể gồm phải rotate credential, sử dụng API trái phép, phát sinh chi phí và lộ dữ liệu đi qua các service đó. Bằng chứng hiện có không cho thấy việc chiếm quyền máy chủ, không xác nhận privilege escalation vượt ra ngoài ranh giới phân quyền bị lỗi và không xác định phạm vi secret cụ thể bị truy cập.

Nếu khai thác thành công, attacker có thể lấy hoặc sử dụng secret vượt ra ngoài ranh giới cấp quyền dự kiến của request. Vì LiteLLM làm trung gian cho các request tới model và API, credential bị lộ có thể dẫn đến việc sử dụng trái phép các service kết nối, phát sinh chi phí bất thường hoặc truy cập dữ liệu được xử lý bằng credential đó. Record chưa xác định một vụ xâm phạm đã xảy ra, loại secret nào bị lộ hoặc mọi deployment có sử dụng đường code vulnerable hay không. Việc exploit đã được công khai làm tăng mức độ ưu tiên đối với các instance LiteLLM phơi nhiễm trên Internet.

1. Nếu đang triển khai BerriAI LiteLLM đến 1.94.0, hãy coi deployment đó là có khả năng bị ảnh hưởng. Chưa có fixed release được xác nhận, vì vậy không nên tự giả định rằng branch mới hơn hoặc branch song song đã an toàn.
2. Hạn chế truy cập mạng tới LiteLLM bằng firewall hoặc reverse proxy, chỉ cho phép các nguồn tin cậy truy cập service trong thời gian chờ hướng dẫn hoặc bản sửa chính thức.
3. Rà soát lịch sử truy cập API key và secret. Nếu nghi ngờ có truy cập trái phép hoặc credential bị lộ, hãy rotate các credential liên quan và kiểm tra các service phụ thuộc.
4. Theo dõi các mẫu sử dụng API key bất thường và đối chiếu với user, service và nguồn request dự kiến. Đây là biện pháp phòng ngừa, không thay thế cho bản sửa lỗi và không dựa trên một IOC cụ thể đã được xác nhận.

1. Kiểm kê các deployment BerriAI LiteLLM và xác định phiên bản, mức độ phơi nhiễm mạng, cùng việc Secret Resolution có được bật hay không.
2. Kiểm tra sự hiện diện của hàm get_secret trong secret_managers/main.py và xác định liệu logic này có thể được gọi qua một service từ xa hay không.
3. Rà soát application log và reverse-proxy telemetry, nếu có, để tìm request bất thường tới chức năng phân giải secret hoặc giá trị api_key không phù hợp với mô hình sử dụng thông thường. Đây là biện pháp giám sát phòng ngừa, không phải IOC được vendor xác nhận.
4. Đối chiếu việc sử dụng API key và secret với các service, user và thời điểm dự kiến; nếu phát hiện truy cập bất thường, xử lý secret liên quan như có khả năng bị lộ.
5. Không có log field, signature hoặc indicator cụ thể nào được xác nhận; việc không thấy log phù hợp không chứng minh deployment an toàn.