Bypass denylist phân biệt hoa thường trong Dolibarr làm lộ password hash

Dolibarr 24.0.0 trước 24.0.1 chứa lỗ hổng bypass denylist phân biệt chữ hoa và chữ thường trong tham số truy vấn API sqlfilters, cho phép kẻ tấn công đã xác thực khôi phục các trường cơ sở dữ liệu được bảo vệ bằng cách cung cấp các biến thể viết hoa của tên trường được denylist bảo vệ. Kẻ tấn công có thể khai thác việc phân giải tên cột không phân biệt chữ hoa và chữ thường của cơ sở dữ liệu đối lập với kiểm tra denylist phân biệt chữ hoa và chữ thường trong core library để sử dụng các predicate so khớp tiền tố như một boolean oracle và trích xuất đầy đủ password hash của bất kỳ tài khoản người dùng nào, bao gồm cả quản trị viên.

• Dolibarr: bản 24.0.0 được đánh dấu affected với điều kiện phiên bản nhỏ hơn 24.0.1 theo semver.
• Bản ghi đặt trạng thái mặc định là unaffected bên ngoài phạm vi affected nêu trên.
• 24.0.1 là bản phát hành được liên kết với bản vá và là mục tiêu nâng cấp được hỗ trợ bởi bằng chứng hiện có. Trạng thái của các nhánh song song hoặc các nhánh mới hơn không được xác nhận riêng trong dữ liệu đã kiểm tra.

Lỗi nằm ở tham số truy vấn API sqlfilters, nơi các predicate trên tên trường được xử lý bởi core library. Kiểm tra denylist trong thư viện phân biệt chữ hoa và chữ thường, trong khi quá trình phân giải tên cột của cơ sở dữ liệu lại không phân biệt chữ hoa và chữ thường. Vì vậy, biến thể viết hoa của tên trường bị bảo vệ có thể vượt qua kiểm tra denylist nhưng vẫn được ánh xạ tới cột nhạy cảm. Predicate so khớp tiền tố có thể được dùng như một boolean oracle để suy luận và thu hồi password hash đầy đủ của các tài khoản, bao gồm tài khoản quản trị. Khai thác cần quyền xác thực qua mạng; bằng chứng hiện có không xác định endpoint cụ thể, vai trò tối thiểu chính xác, engine cơ sở dữ liệu hoặc mọi cấu hình triển khai có expose API này hay không.

• Kẻ tấn công cần có tài khoản đã xác thực và truy cập mạng tới giao diện API bị ảnh hưởng.
• Bản ghi mô tả độ phức tạp khai thác thấp và không yêu cầu người dùng khác tương tác.
• Lỗi cho phép đọc dữ liệu qua các truy vấn được tạo bởi kẻ tấn công, nhưng không được mô tả là trực tiếp sửa dữ liệu hoặc làm gián đoạn dịch vụ.
• Bản ghi chuẩn đánh dấu public_exploit là false và không đánh dấu lỗ hổng đã bị khai thác. Điều này không chứng minh rằng không có khai thác chưa được báo cáo hoặc khai thác trong môi trường riêng.

Lỗ hổng cho phép tài khoản đã xác thực đọc các trường cơ sở dữ liệu vốn bị denylist bảo vệ và có thể thu hồi password hash đầy đủ của bất kỳ người dùng nào, kể cả quản trị viên. Tác động trực tiếp được mô tả là mất tính bí mật trong hệ thống bị ảnh hưởng; không có bằng chứng cho thấy lỗi này trực tiếp làm thay đổi dữ liệu hoặc làm mất khả dụng. Việc có được hash có thể dẫn tới cracking ngoại tuyến hoặc lạm dụng thông tin xác thực ở hệ thống khác nếu người dùng tái sử dụng mật khẩu, nhưng kết quả đó phụ thuộc vào chính sách mật khẩu và không được xác nhận trong bản ghi. Lỗi không tự động cấp quyền quản trị, dù việc lộ hash của tài khoản quản trị làm tăng rủi ro chiếm quyền nếu thông tin xác thực bị khôi phục hoặc tái sử dụng.

• Kẻ tấn công đã xác thực có thể thu hồi các trường cơ sở dữ liệu bị bảo vệ, bao gồm password hash của tài khoản người dùng và quản trị viên.
• Việc mất bí mật của password hash có thể tạo rủi ro tiếp diễn do offline cracking hoặc tái sử dụng mật khẩu, tùy thuộc độ mạnh và mức độ dùng lại mật khẩu. Đây là hậu quả có thể xảy ra, không phải sự kiện xâm nhập đã được xác nhận.
• Lỗ hổng không được mô tả là cho phép sửa dữ liệu hoặc gây mất khả dụng, nhưng việc lộ thông tin xác thực có thể làm tăng rủi ro truy cập trái phép vào các hệ thống khác nếu thông tin được tái sử dụng.
• Do yêu cầu xác thực ban đầu, phạm vi phơi lộ phụ thuộc vào các tài khoản có thể truy cập API và dữ liệu mà API trả về trong từng triển khai.

1. Nâng cấp Dolibarr lên bản 24.0.1, là bản phát hành được liên kết với thay đổi sửa lỗi kiểm tra tên operand không phân biệt chữ hoa và chữ thường.
2. Xác minh sau nâng cấp rằng mã đã chứa thay đổi bảo vệ denylist trong core library, đồng thời khởi động lại hoặc triển khai lại các thành phần ứng dụng theo quy trình vận hành của tổ chức.
3. Kiểm kê các tài khoản đã xác thực có thể truy cập API và đánh giá log truy vấn trong thời gian hệ thống còn nằm trong phạm vi affected.
4. Vì password hash có thể đã bị đọc, cân nhắc buộc đổi mật khẩu cho tài khoản người dùng, ưu tiên tài khoản quản trị, và rà soát việc tái sử dụng mật khẩu. Đây là biện pháp phòng ngừa dựa trên tác động dữ liệu, không phải yêu cầu khôi phục được nêu trong advisory.
5. Nếu chưa thể nâng cấp, bản ghi hiện không cung cấp một mitigation tạm thời cụ thể. Không nên coi việc chỉ hạn chế tên trường ở lớp ứng dụng hoặc lọc chữ hoa ở proxy là biện pháp thay thế đã được xác nhận.

• Kiểm kê các triển khai Dolibarr và xác định phiên bản đang chạy, đặc biệt các hệ thống có bật hoặc expose API hỗ trợ tham số sqlfilters.
• Xác nhận các máy chủ đã được nâng cấp lên bản sửa lỗi được nêu trong phần remediation, thay vì chỉ kiểm tra trạng thái của source tree hoặc package cache.
• Rà soát log reverse proxy, web server và ứng dụng để tìm các yêu cầu xác thực lặp lại tới API có sqlfilters, tên trường viết hoa bất thường hoặc các predicate so khớp tiền tố lặp theo chuỗi ký tự. Đây là biện pháp rà soát phòng ngừa, không phải IOC đã được xác nhận.
• Kiểm tra các tài khoản có quyền thấp đã thực hiện số lượng lớn truy vấn đọc dữ liệu nhạy cảm trong khoảng thời gian bất thường.
• Nếu phát hiện dấu hiệu truy vấn phù hợp, bảo toàn log và đánh giá password hash của mọi tài khoản có thể đã bị đọc như dữ liệu đã phơi lộ.