MLflow bị SSRF qua webhook không cần xác thực, có thể lộ dịch vụ nội bộ và cloud metadata

MLflow là một nền tảng kỹ thuật AI mã nguồn mở dành cho agent, mô hình ngôn ngữ lớn và mô hình machine learning. Trước phiên bản 3.15.0, endpoint POST /api/2.0/mlflow/webhooks/{id}/test không cần xác thực gọi _validate_webhook_url() trong mlflow/utils/validation.py chỉ đối với URL ban đầu, trong khi mlflow/webhooks/delivery.py theo redirect và phân giải lại hostname mà không ghim địa chỉ đã được kiểm tra, cho phép kẻ tấn công truy cập các dịch vụ nội bộ hoặc cloud metadata và nhận response_status cùng response_body. Vấn đề này được sửa trong phiên bản 3.15.0.

• Package mlflow: bản ghi CNA chuẩn hóa xác định các phiên bản < 3.15.0 là bị ảnh hưởng.
• Phạm vi triển khai được mô tả rõ nhất là MLflow Tracking Server tự quản lý có model-registry webhooks API và SQL store; cấu hình mlflow server mặc định với SQLite được advisory nêu là đáp ứng điều kiện này.
• Bản ghi CNA và phần mô tả sửa lỗi xác định 3.15.0 là phiên bản sửa lỗi.
• Trang advisory hiện tại đồng thời hiển thị <= 3.13.0 trong nhãn affected versions và không có patched-version entry, trong khi phần nội dung vẫn nói lỗi được sửa bằng thay đổi phát hành trong 3.15.0. Vì vậy, tài liệu public có mâu thuẫn về các bản phát hành nằm giữa ranh giới <= 3.13.0 và < 3.15.0; nên xử lý theo hướng thận trọng và nâng cấp lên 3.15.0.

MLflow thực hiện kiểm tra URL webhook trong mlflow/utils/validation.py bằng cách phân giải hostname và từ chối các địa chỉ IP không public, nhưng địa chỉ đã kiểm tra không được ghim vào kết nối thực tế. Trong mlflow/webhooks/delivery.py, yêu cầu HTTP tiếp tục phân giải hostname độc lập và mặc định vẫn theo redirect, vì vậy redirect target không được kiểm tra lại. Kẻ tấn công có thể dùng một endpoint HTTPS public vượt qua kiểm tra ban đầu rồi chuyển hướng MLflow tới địa chỉ loopback, mạng nội bộ hoặc dịch vụ cloud metadata; DNS rebinding cũng tạo ra khoảng thời gian TOCTOU giữa lúc kiểm tra và lúc kết nối. Endpoint POST /api/2.0/mlflow/webhooks/{id}/test trả lại response_status và response_body của upstream, biến đường đi này thành full-read SSRF. Luồng delivery theo sự kiện sử dụng cùng cơ chế outbound và có thể tạo SSRF không phản hồi nội dung; redirect 307 hoặc 308 còn có thể giữ nguyên method và body POST, tạo khả năng blind write tới dịch vụ nội bộ. Điều kiện tiếp cận cụ thể phụ thuộc vào việc MLflow Tracking Server có thể bị truy cập hay không, có SQL store hỗ trợ webhook hay không và lớp authentication hoặc reverse proxy được cấu hình như thế nào.

Đây là lỗ hổng có thể khai thác qua mạng đối với MLflow Tracking Server. Trên cấu hình mặc định được advisory mô tả, model-registry webhook API không yêu cầu xác thực, và endpoint /api/2.0/mlflow/webhooks/{id}/test có thể được gọi mà không cần user interaction. Kẻ tấn công cần máy chủ MLflow có thể truy cập được và cần kiểm soát một hostname hoặc endpoint public dùng để vượt qua bước kiểm tra URL ban đầu, sau đó khai thác redirect hoặc DNS rebinding. Bản ghi chuẩn hóa đánh dấu lỗ hổng là đã bị khai thác và có public exploit. Bản ghi không nêu tên chiến dịch, nạn nhân hoặc sự cố cụ thể nào.

Lỗ hổng cho phép một request tới MLflow khiến máy chủ thực hiện HTTP request tới địa chỉ nội bộ, loopback hoặc cloud metadata thay cho kẻ tấn công. Với endpoint /test, response_status và response_body được phản hồi lại, nên kết quả có thể là đọc dữ liệu từ tài nguyên mà máy chủ MLflow nhìn thấy nhưng client bên ngoài không nhìn thấy. Tác động có thể bao gồm lộ secret, cloud credential, thông tin dịch vụ nội bộ và khả năng do thám mạng; mức độ thực tế phụ thuộc vào quyền mạng và credential của máy chủ. Redirect 307 hoặc 308 còn có thể chuyển tiếp POST tới dịch vụ nội bộ, tạo tác động toàn vẹn tùy theo endpoint đích. Bản ghi không thiết lập một tác động availability cụ thể hoặc xác nhận rằng một tổ chức cụ thể đã bị xâm nhập.

• Rò rỉ dữ liệu: response body từ dịch vụ nội bộ, API quản trị hoặc cloud metadata có thể bị trả lại cho kẻ tấn công thông qua webhook test.
• Rủi ro thông tin xác thực: nếu máy chủ có quyền truy cập cloud metadata, dữ liệu phản hồi có thể bao gồm credential hoặc token gắn với workload đó.
• Mở rộng phạm vi truy cập: MLflow server trở thành điểm trung gian để truy cập các tài nguyên không public mà kẻ tấn công không thể kết nối trực tiếp.
• Tác động tới tính toàn vẹn: các redirect bảo toàn POST có thể gửi dữ liệu do kẻ tấn công kiểm soát tới một số dịch vụ nội bộ, nhưng tác động cụ thể phụ thuộc vào endpoint đích và quyền của máy chủ.
• Bằng chứng hiện có không xác nhận một vụ xâm nhập, nạn nhân hoặc tổn thất kinh doanh cụ thể nào.

1. Nâng cấp package mlflow lên 3.15.0, là phiên bản được bản ghi CNA và phần mô tả sửa lỗi xác định là đã xử lý vấn đề. Bản sửa thêm SSRFProtectedHTTPAdapter, kiểm tra peer IP của socket tại thời điểm kết nối trước khi thực hiện TLS hoặc trao đổi HTTP, bao phủ cả redirect target.
2. Nếu chưa thể nâng cấp, giới hạn truy cập mạng tới MLflow Tracking Server và bảo vệ các webhook endpoint bằng authentication hoặc reverse proxy có kiểm soát. Đây là biện pháp giảm thiểu tạm thời, không phải bản sửa được vendor xác nhận.
3. Hạn chế egress từ MLflow server tới mạng private, loopback, link-local và cloud metadata theo mô hình cần thiết tối thiểu. Xác nhận rằng các policy này không bị vô hiệu hóa bởi cấu hình cho phép private webhook IP.
4. Rà soát log truy cập và kết nối outbound để xác định webhook test bất thường hoặc truy cập tới tài nguyên nội bộ; nếu có khả năng metadata đã bị đọc, điều tra và thay thế credential hoặc token có thể đã được máy chủ sử dụng.
5. Do advisory hiện tại hiển thị ranh giới affected không nhất quán, không nên coi nhãn <= 3.13.0 là bằng chứng rằng mọi bản phát hành trước 3.15.0 đều an toàn.

• Kiểm kê các MLflow Tracking Server tự quản lý, package đang cài đặt và cấu hình webhook; đối chiếu với ranh giới phiên bản trong affected_summary.
• Xác định các máy chủ dùng model-registry webhooks, SQL store và endpoint POST /api/2.0/mlflow/webhooks/{id}/test; kiểm tra xem authentication có thực sự bao phủ các endpoint này hay không.
• Rà soát access log và audit log để tìm các yêu cầu không xác thực tới /api/2.0/mlflow/webhooks hoặc /api/2.0/mlflow/webhooks/{id}/test, đặc biệt là hoạt động tạo webhook rồi kiểm thử ngay sau đó.
• Kiểm tra egress telemetry từ MLflow server tới địa chỉ loopback, mạng private, link-local hoặc cloud metadata. Đây là kiểm tra phát hiện và điều tra mang tính phòng ngừa, không phải IOC riêng đã được xác nhận cho lỗ hổng này.
• Nếu máy chủ có thể truy cập từ mạng không tin cậy, xem xét các response của webhook test và các kết nối outbound bất thường trong cùng khoảng thời gian; việc không thấy log không chứng minh hệ thống an toàn.