Dolibarr User REST API bị lỗi phân quyền, làm lộ dữ liệu lương

Dolibarr trước 24.0.0 chứa lỗ hổng SQL injection trong users REST API, cho phép kẻ tấn công đã xác thực với quyền đọc người dùng trích xuất dữ liệu nhạy cảm bằng cách ghép các tham số filter chưa được làm sạch vào các mệnh đề SQL WHERE mà không hạn chế cột. Kẻ tấn công có thể thực hiện tìm kiếm nhị phân trên các trường số và lặp tiền tố LIKE trên các trường chuỗi để khôi phục các con số về lương và các verifier mật khẩu bị loại khỏi các phản hồi API thông thường, trong khi các thông báo lỗi thô từ cơ sở dữ liệu tại cùng endpoint cho phép liệt kê tên cột.

• Dolibarr dolibarr: mọi phiên bản semver nhỏ hơn 24.0.0 được ghi nhận là affected.
• Bản ghi không chỉ ra nhánh song song hoặc bản phân phối riêng nào ngoài phạm vi trên đã được xác minh là không bị ảnh hưởng.
• 24.0.0 được các nguồn kỹ thuật và bản sửa lỗi liên kết với việc khắc phục vấn đề; trạng thái của các nhánh phát hành khác không nên được suy ra chỉ từ việc có bản sửa này.

Dolibarr User REST API kiểm tra quyền user-read để cho phép liệt kê người dùng, nhưng không áp dụng cùng quyết định phân quyền khi xử lý các trường do tham số filter chỉ định. Route Users::index() chuyển filter tới forgeSQLFromUniversalSearchCriteria(), còn dolForgeSQLCriteriaCallback() chỉ làm sạch cú pháp tên cột mà không kiểm tra người gọi có quyền tham chiếu cột đó hay không. Vì vậy, một tài khoản được phép đọc danh sách người dùng có thể dùng kết quả có dòng hoặc rỗng làm boolean oracle để suy ra các trường số, và dùng so khớp tiền tố để khôi phục từng phần các trường chuỗi bị loại khỏi response thông thường. Các trường được nêu trong phân tích gồm salary, salaryextra, thm, tjm và giá trị verifier mật khẩu đã được biến đổi; lỗi cơ sở dữ liệu trả về trực tiếp còn có thể tiết lộ tên cột. Mô tả của CNA gọi đây là SQL injection, nhưng phân tích kỹ thuật cho biết bộ lọc loại bỏ các ký tự cần cho việc chèn SQL tùy ý; lỗi cốt lõi được xác nhận là thiếu phân quyền theo cột, không phải khả năng phá vỡ cấu trúc câu SQL.

Lỗ hổng có thể khai thác qua mạng bằng các request REST đã xác thực, không cần tương tác của người dùng và không cần quyền quản trị. Kẻ tấn công cần ít nhất quyền đọc danh sách người dùng, được thể hiện bởi quyền user->user->lire. Phân tích công khai cho biết kỹ thuật này đã được chứng minh trong một môi trường Dolibarr cô lập bằng các request GET đã xác thực; không có bằng chứng trong dữ liệu hiện có về việc khai thác trên các hệ thống triển khai thực tế. Hồ sơ ghi nhận có public exploit, nhưng không xác nhận chiến dịch, nạn nhân hoặc việc lạm dụng ngoài môi trường thử nghiệm.

Lỗ hổng làm mở rộng quyền đọc theo cách gián tiếp: tài khoản chỉ được phép liệt kê người dùng có thể kiểm tra các điều kiện trên cột mà tài khoản không được phép xem. Kết quả là dữ liệu lương, các mức chi phí và một số giá trị verifier mật khẩu có thể được tái dựng từng phần hoặc toàn bộ bằng nhiều câu hỏi filter. Phạm vi ảnh hưởng chủ yếu là tính bí mật của dữ liệu trong phạm vi cơ sở dữ liệu mà endpoint truy vấn; hồ sơ không cho thấy khả năng sửa đổi dữ liệu hoặc làm gián đoạn dịch vụ. Phân tích công khai cũng không thiết lập rằng verifier bị lộ có thể dùng trực tiếp để đăng nhập hoặc rằng tài khoản đã bị chiếm. Việc trả lỗi database thô còn làm tăng khả năng trinh sát schema.

• Dữ liệu lương và các mức chi phí nhân sự có thể bị tiết lộ cho tài khoản chỉ cần quyền đọc danh sách người dùng, làm tăng rủi ro về quyền riêng tư, cạnh tranh và tuân thủ.
• Việc suy ra nhiều bản ghi có thể làm lộ cấu trúc chi phí của lực lượng lao động, không chỉ một trường trong một tài khoản.
• Verifier mật khẩu hoặc giá trị mật khẩu đã biến đổi có thể bị thu thập dù không được trả về trong response thông thường. Phân tích công khai cho biết giá trị này không trực tiếp là credential đăng nhập dùng được, nhưng việc lộ dữ liệu xác thực vẫn cần được đánh giá trong điều tra.
• Thông báo lỗi cơ sở dữ liệu có thể tiết lộ tên cột và hỗ trợ lập bản đồ schema của ứng dụng.
• Bằng chứng hiện có không xác nhận sửa đổi dữ liệu, gián đoạn dịch vụ, chiếm quyền tài khoản hoặc một vụ xâm nhập cụ thể.

1. Nâng cấp Dolibarr lên 24.0.0, là bản phát hành được ghi nhận có bản sửa cho lỗi này.
2. Trước khi nâng cấp, tạm thời loại bỏ quyền user->user->lire khỏi các tài khoản, token và integration account không thực sự cần đọc danh sách người dùng; đây là biện pháp giảm thiểu tạm thời, không thay thế bản sửa.
3. Hạn chế khả năng truy cập User REST API từ các mạng, ứng dụng tích hợp hoặc tài khoản không cần thiết trong thời gian xử lý nâng cấp.
4. Sau khi cập nhật, xác nhận filter của endpoint áp dụng allowlist cột và kiểm tra phân quyền cho các trường lương cũng như các trường credential bị loại khỏi response. Không chỉ dựa vào việc sanitizer làm sạch ký tự SQL.
5. Rà soát log và dữ liệu truy cập trong thời gian phiên bản bị ảnh hưởng đang hoạt động. Nếu phát hiện truy vấn bất thường hoặc dữ liệu verifier đã bị thu thập, thực hiện quy trình ứng phó và đánh giá credential theo chính sách tổ chức; bằng chứng hiện có không yêu cầu khẳng định rằng đã xảy ra chiếm quyền tài khoản.

• Kiểm kê các máy chủ chạy Dolibarr và xác định phiên bản trước bản sửa lỗi; ưu tiên các hệ thống có bật User REST API.
• Liệt kê tài khoản, token và integration account có quyền user->user->lire, đặc biệt các tài khoản không cần quyền truy cập dữ liệu nhân sự nhưng vẫn có thể gọi API người dùng.
• Rà soát access log của User REST API để tìm các request đã xác thực sử dụng filter trên các trường nhạy cảm như salary, salaryextra, thm, tjm hoặc các trường credential không xuất hiện trong response bình thường.
• Kiểm tra application log và database log đối với các lỗi SQL thô hoặc lỗi tên cột phát sinh từ cùng endpoint; đây là dấu hiệu cần điều tra, không phải IOC riêng biệt đã được xác nhận.
• Đối chiếu việc API loại bỏ các trường lương và verifier khỏi response với các kết quả filter bất thường. Không thấy log hoặc không thấy trường trong response không chứng minh hệ thống an toàn.