Lỗ hổng chèn mã cho phép thực thi lệnh từ xa trong Horilla HR

Horilla là phần mềm HR và CRM. Trước phiên bản 2.0.0, HorillaListView.export_data trong horilla_views/generic/cbv/views.py chấp nhận tham số POST columns do người dùng đã xác thực kiểm soát, lấy field_tuple[1], chèn giá trị đó vào dynamic_fn_str dưới dạng mã nguồn Python, rồi truyền định nghĩa hàm được tạo vào exec(). Một chuỗi được tạo thủ công nhưng vẫn hợp lệ đối với ast.literal_eval có thể chèn cú pháp Python vào một đối số mặc định được đánh giá trong khi định nghĩa hàm, cho phép thực thi các lệnh hệ điều hành tùy ý với quyền của tiến trình ứng dụng, bao gồm quyền root trong Docker image được phát hành kèm sản phẩm. Vấn đề này được sửa trong phiên bản 2.0.0.

• Advisory của CNA/nhà cung cấp xác định các bản Horilla HR <= 1.6.1 bị ảnh hưởng.
• Advisory xác định bản 2.0.0 là bản đã được sửa.
• Normalized record lại đánh dấu mọi phiên bản < 2.0.0 là bị ảnh hưởng.
• Hai ranh giới này không hoàn toàn thống nhất. Vì vậy, trạng thái của các phiên bản sau 1.6.1 nhưng trước 2.0.0 chưa được evidence hiện có giải quyết rõ ràng và không nên được coi là an toàn nếu chưa có xác nhận bổ sung.

HorillaListView.export_data xử lý tham số POST columns do người dùng đã xác thực kiểm soát trong chức năng xuất dữ liệu danh sách. Giá trị này được phân tích bằng ast.literal_eval, sau đó một phần tử trong field_tuple được chèn trực tiếp vào chuỗi mã Python dynamic_fn_str. Chuỗi hàm được tạo động được truyền cho exec(), vì vậy dữ liệu đầu vào có thể thay đổi cú pháp của định nghĩa hàm thay vì chỉ cung cấp tên cột. Một biểu thức được chèn vào đối số mặc định của hàm sẽ được đánh giá ngay khi định nghĩa hàm được thực thi, cho phép chạy lệnh hệ điều hành với quyền của tiến trình ứng dụng. Điều kiện khai thác được xác nhận là có tài khoản Horilla đã đăng nhập; advisory cho biết tài khoản thông thường không cần quyền staff hoặc superuser cũng có thể khai thác. Chi tiết triển khai của cơ chế thay thế hoàn toàn trong mọi nhánh chưa được xác nhận ngoài thông tin rằng bản sửa loại bỏ việc xây dựng các phương thức dehydrate từ tên cột do người dùng cung cấp.

Lỗ hổng có thể bị khai thác qua mạng thông qua trình xử lý xuất dữ liệu list-view.

• Kẻ tấn công cần có tài khoản Horilla đã xác thực, nhưng advisory cho biết tài khoản người dùng thông thường với quyền thấp là đủ.
• Không cần người dùng khác tương tác, và dữ liệu cho thấy độ phức tạp khai thác thấp.
• Advisory của nhà cung cấp là công khai và có phần tái hiện kỹ thuật, nhưng record được cung cấp không xác nhận việc khai thác trong thực tế hoặc một public exploit được theo dõi riêng.
• Không có thông tin được xác nhận về chiến dịch, nạn nhân, chỉ báo xâm nhập hoặc ransomware liên quan.

Khai thác thành công cho phép thực thi lệnh hệ điều hành trong môi trường tiến trình Horilla với quyền của tiến trình ứng dụng. Trong Docker image được phát hành kèm sản phẩm, quyền này được advisory mô tả là root, nên tác động bên trong container có thể bao gồm toàn quyền đọc, thay đổi hoặc xóa tài nguyên mà container truy cập được. Từ góc độ tổ chức, điều này có thể ảnh hưởng đến tính bảo mật của dữ liệu HR và CRM, tính toàn vẹn của cấu hình và tính sẵn sàng của dịch vụ. Mức độ ảnh hưởng đến máy chủ hoặc các hệ thống khác phụ thuộc vào cấu hình triển khai và chưa được evidence xác nhận. Lỗ hổng yêu cầu xác thực, vì vậy không phải là truy cập ẩn danh trực tiếp.

Một người dùng Horilla đã xác thực có thể biến chức năng xuất list-view thành khả năng thực thi lệnh trên môi trường máy chủ của ứng dụng. Điều này có thể cho phép đọc dữ liệu HR và CRM mà tiến trình ứng dụng có quyền truy cập, thay đổi trạng thái ứng dụng hoặc làm gián đoạn dịch vụ.

Nếu triển khai bằng Docker image được phát hành kèm theo sản phẩm, advisory cho biết tiến trình container chạy mặc định với quyền root, làm tăng mức độ ảnh hưởng bên trong container. Ảnh hưởng ra ngoài container phụ thuộc vào cấu hình triển khai, volume, secret và quyền của container, nhưng record không cung cấp đủ thông tin để xác nhận phạm vi đó. Không nên suy ra rằng đã xảy ra rò rỉ dữ liệu hoặc xâm nhập thực tế chỉ từ sự tồn tại của lỗ hổng.

1. Nâng cấp Horilla HR lên bản 2.0.0, là bản mà advisory của CNA/nhà cung cấp xác định đã sửa lỗ hổng.
2. Sau khi nâng cấp, xác minh mã đang chạy không còn xây dựng các phương thức dehydrate từ tên cột do người dùng cung cấp và không còn truyền mã được tạo từ dữ liệu đó vào exec().
3. Nếu chưa thể nâng cấp, coi các hệ thống thuộc phạm vi phiên bản chưa được giải quyết là có nguy cơ và áp dụng biện pháp hạn chế quyền truy cập vào ứng dụng và chức năng xuất dữ liệu như một biện pháp giảm thiểu tạm thời. Evidence hiện có không ghi nhận một workaround chính thức nào khác từ nhà cung cấp.
4. Không suy ra rằng các bản sau 1.6.1 và trước 2.0.0 đã an toàn chỉ vì advisory xác nhận bản 2.0.0 được sửa; cần xác nhận riêng phạm vi của các nhánh đó.

1. Kiểm kê các triển khai Horilla HR và xác định phiên bản đang chạy, bao gồm các bản cài đặt từ mã nguồn và các container Docker.
2. Kiểm tra mã của horilla_views/generic/cbv/views.py, đặc biệt là HorillaListView.export_data, để xác định liệu columns còn được dùng trong việc tạo mã Python động và truyền vào exec() hay không.
3. Rà soát log ứng dụng đối với các yêu cầu xuất list-view từ tài khoản có quyền thấp, các giá trị columns bất thường và hoạt động xuất dữ liệu không phù hợp với hành vi thông thường.
4. Như một biện pháp giám sát thận trọng, đối chiếu các sự kiện xuất dữ liệu với việc tiến trình ứng dụng tạo tiến trình con hoặc thực thi lệnh hệ điều hành. Đây không phải là IOC đã được xác nhận.
5. Evidence được cung cấp không nêu một log event hoặc IOC cụ thể có thể dùng để khẳng định an toàn khi không thấy dấu hiệu bất thường.