Server-Side Template Injection cho phép thực thi mã từ xa trong open-metadata OpenMetadata

OpenMetadata là một nền tảng siêu dữ liệu hợp nhất. Các phiên bản từ 1.5.0 đến 1.11.3 dễ bị thực thi mã từ xa thông qua Server-Side Template Injection (SSTI) trong các mẫu email FreeMarker. Kẻ tấn công phải có đặc quyền quản trị để khai thác lỗ hổng. Phiên bản 1.11.4 có bản vá.

• Theo bản ghi CNA được cung cấp, OpenMetadata từ phiên bản 1.5.0 đến 1.11.3 bị ảnh hưởng.
• GitHub advisory xác định package Maven org.open-metadata:platform bị ảnh hưởng ở các phiên bản <= 1.11.3.
• Phiên bản 1.11.4 được xác định là đã có bản vá.
• Sự khác biệt giữa cận dưới 1.5.0 trong bản ghi CNA và cách ghi <= 1.11.3 trong GitHub advisory chưa xác định trạng thái của các phiên bản OpenMetadata cũ hơn cận dưới được nêu trong bản ghi CNA. Các triển khai ngoài phạm vi 1.5.0 đến 1.11.3 cần được đối chiếu thêm với lịch sử phiên bản và chính sách hỗ trợ của nhà cung cấp.

Lỗ hổng nằm trong thành phần openmetadata-service, cụ thể là DefaultTemplateProvider, nơi nội dung email template được lấy từ document repository và đưa vào FreeMarker để xử lý. Nội dung do người dùng kiểm soát được truyền vào một cấu hình FreeMarker không áp dụng đầy đủ các giới hạn an toàn, khiến các phần tử template đặc biệt có thể được diễn giải thay vì chỉ được xem như văn bản. Advisory xác định các biện pháp bảo vệ còn thiếu gồm resolver an toàn cho ?new, vô hiệu hóa built-in ?api, và kiểm tra đầu vào.

Luồng khai thác được mô tả ở mức cao như sau:

1. Kẻ tấn công đã có quyền quản trị thay đổi một email template thông qua thao tác cập nhật tài liệu, chẳng hạn PATCH /api/v1/docStore/{templateId}.
2. Template đã thay đổi được lưu trong document store.
3. Một luồng gửi email hoặc test email kích hoạt việc render template.
4. FreeMarker xử lý nội dung template và mã có thể được thực thi trong quyền của tiến trình OpenMetadata.

Các luồng kích hoạt được advisory nêu gồm thay đổi mật khẩu, mời người dùng, thông báo hoạt động tài khoản và test email khi SMTP được cấu hình. Bằng chứng hiện có không xác định đầy đủ mọi cấu hình triển khai cần thiết ngoài quyền quản trị, khả năng sửa email template và một luồng render template.

Lỗ hổng có thể bị khai thác qua mạng thông qua giao diện OpenMetadata. Kẻ tấn công phải có đặc quyền quản trị để sửa nội dung email template; việc chiếm được tài khoản quản trị nằm ngoài bản thân lỗ hổng nhưng là điều kiện khai thác quan trọng. Dữ liệu chấm điểm được cung cấp mô tả độ phức tạp khai thác là thấp và không yêu cầu người dùng khác tương tác.

GitHub advisory của OpenMetadata có chứa proof of concept công khai cho việc kích hoạt SSTI và RCE. Bản ghi được cung cấp đánh dấu public exploit là có, nhưng bằng chứng đã xem không xác lập việc lỗ hổng đã bị khai thác ngoài thực tế.

Khai thác thành công dẫn đến thực thi mã tùy ý trong ngữ cảnh tiến trình OpenMetadata, nên tác động trực tiếp có thể bao gồm mất tính bí mật, toàn vẹn và khả dụng của ứng dụng. Kẻ tấn công có thể truy cập hoặc sửa đổi dữ liệu mà tài khoản chạy dịch vụ được phép truy cập, và có thể đọc secrets trong môi trường nếu chúng nằm trong phạm vi quyền đó. Việc ảnh hưởng đến hệ điều hành, database, container hoặc các hệ thống kết nối là khả năng có thể xảy ra, không phải kết quả được đảm bảo cho mọi cấu hình. Quyền quản trị là điều kiện tiên quyết, vì vậy việc bảo vệ tài khoản quản trị và kiểm tra thay đổi EmailTemplate là phần quan trọng của việc giảm rủi ro.

Nếu khai thác thành công, kẻ tấn công có thể thực thi mã trong ngữ cảnh máy chủ OpenMetadata và có khả năng:

• Đọc hoặc thay đổi metadata, schema information, data lineage và các dữ liệu khác mà tiến trình ứng dụng có quyền truy cập.
• Tiếp cận database credentials, API keys, JWT signing keys hoặc cloud credentials nếu các bí mật này hiện diện trong môi trường mà tiến trình có thể đọc.
• Làm gián đoạn dịch vụ hoặc sửa đổi dữ liệu ứng dụng, tùy theo quyền của tài khoản chạy OpenMetadata.
• Tạo rủi ro lan sang các data source hoặc môi trường kết nối với OpenMetadata, nhưng mức độ ảnh hưởng phụ thuộc vào quyền mạng, secret và quyền hệ điều hành của từng triển khai.

Điều kiện giới hạn quan trọng là kẻ tấn công phải có quyền quản trị OpenMetadata trước khi có thể sửa email template.

1. Nâng cấp OpenMetadata lên phiên bản 1.11.4, là phiên bản được bản ghi và GitHub advisory xác định có bản vá.
2. Nếu chưa thể nâng cấp ngay, áp dụng biện pháp hardening được advisory mô tả cho DefaultTemplateProvider: sử dụng FreeMarker configuration có sandbox, đặt TemplateClassResolver.SAFER_RESOLVER, vô hiệu hóa ?api, tắt chế độ classic compatibility và giới hạn template loading bằng StringTemplateLoader. Đây là biện pháp code-level cần được kiểm thử trong môi trường staging trước khi triển khai.
3. Rà soát và khôi phục các email template về nội dung tin cậy, tập trung vào những template đã bị tài khoản quản trị thay đổi bất thường.
4. Kiểm tra các tài khoản quản trị và audit trail để xác định việc sửa template trái phép. Nếu có dấu hiệu compromise, xử lý sự cố và thay thế các credentials hoặc secrets mà tiến trình OpenMetadata có thể đã truy cập.
5. Hạn chế quyền của tài khoản chạy OpenMetadata và quyền truy cập mạng của workload theo nguyên tắc least privilege. Đây là biện pháp giảm tác động tiềm ẩn, không thay thế việc nâng cấp.

Ưu tiên kiểm tra theo các bước sau:

1. Lập danh sách các phiên bản OpenMetadata đang chạy và đối chiếu với phạm vi bị ảnh hưởng trong affected_summary.
2. Xác định các triển khai có sử dụng openmetadata-service, DefaultTemplateProvider và FreeMarker email templates.
3. Rà soát audit log của OpenMetadata đối với các thay đổi email template hoặc tài liệu thuộc loại EmailTemplate, đặc biệt các thay đổi do tài khoản quản trị thực hiện.
4. Đối chiếu thời điểm thay đổi template với hoạt động gửi email, test email và các luồng thông báo tài khoản. Nếu SMTP được bật, kiểm tra thêm log của mail infrastructure.
5. Rà soát telemetry của máy chủ, container hoặc tiến trình OpenMetadata để tìm hoạt động thực thi lệnh, truy cập tệp bất thường hoặc kết nối đi ra không giải thích được. Đây là biện pháp giám sát phòng ngừa, không phải các IOC đã được advisory xác nhận.

Không nên coi việc không thấy log bất thường là bằng chứng hệ thống an toàn, vì bản ghi không xác định đầy đủ cơ chế logging của từng triển khai.