Dolibarr bị bypass phân quyền, cho phép đọc tệp tùy ý chưa xác thực

Dolibarr 23.0.4 trước 24.0.1 chứa lỗ hổng bypass phân quyền, cho phép kẻ tấn công chưa xác thực đọc các tệp tùy ý thông qua các endpoint lưu trữ tài liệu bằng cách cung cấp giá trị tham số hashp được tạo thủ công. Kẻ tấn công có thể gửi một yêu cầu với hashp=shared để bỏ qua việc xác thực token nhưng vẫn thỏa điều kiện phân quyền trong htdocs/document.php và htdocs/viewimage.php, từ đó truy cập log ứng dụng, tài liệu nghiệp vụ đã tải lên, các bản sao lưu cơ sở dữ liệu chứa password hash và các tệp thuộc những entity multicompany khác.

• Dolibarr: Các phiên bản từ 23.0.4 đến trước 24.0.1 được xác định là bị ảnh hưởng.
• Dolibarr 24.0.1: Đây là phiên bản phát hành chính xác được liên kết với bản sửa cho nhánh bị nêu. Không được suy ra từ đó rằng mọi nhánh phát hành song song hoặc mọi phiên bản phát hành sau đó đã được xác minh.
• Nhánh 22.0: Một pull request của Dolibarr cho biết bản sửa trong 24.0.1 đã xử lý document.php và viewimage.php nhưng bỏ sót website/wrapper.php; bản sửa bổ sung sau đó đã được merge vào nhánh 22.0. Tài liệu trả về không nêu phiên bản phát hành 22.x cụ thể chứa bản sửa và không xác lập toàn bộ ranh giới phiên bản bị ảnh hưởng của nhánh này.

Nguyên nhân là lỗi CWE-863: Incorrect Authorization trong các endpoint lưu trữ tài liệu của Dolibarr. Khi tham số hashp có giá trị shared, yêu cầu có thể bỏ qua bước kiểm tra token nhưng vẫn thỏa điều kiện phân quyền do giá trị tham số không rỗng, khiến kiểm tra quyền truy cập tài liệu thông thường không còn được áp dụng đúng. Các thành phần bị nêu trong advisory là htdocs/document.php và htdocs/viewimage.php; các tệp có thể bị đọc gồm log ứng dụng, tài liệu nghiệp vụ, bản sao lưu cơ sở dữ liệu chứa password hash và tệp thuộc các entity multicompany khác. Kẻ tấn công chỉ cần khả năng gửi yêu cầu mạng đến Dolibarr, không cần xác thực hoặc tương tác của người dùng. Bản sửa được liên kết với Dolibarr 24.0.1 bổ sung xử lý từ chối giá trị hashp=shared; tài liệu follow-up của Dolibarr cho biết bản sửa ban đầu còn bỏ sót website/wrapper.php, sau đó đã có bản backport vào nhánh 22.0. Phạm vi chính xác của mọi nhánh phát hành khác ngoài các nhánh được nêu vẫn chưa được xác nhận.

Lỗ hổng có thể bị khai thác từ xa qua mạng, không yêu cầu xác thực, không yêu cầu người dùng tương tác và được mô tả là có độ phức tạp thấp. Chuỗi xử lý yêu cầu sử dụng giá trị hashp=shared để vượt qua kiểm tra token và đọc dữ liệu qua các endpoint tài liệu. Advisory của VulnCheck cho biết lỗ hổng nằm trong VulnCheck KEV database. Tuy nhiên, bản ghi chuẩn được cung cấp để lại known_exploited ở trạng thái chưa xác định và đánh dấu public_exploit là false; một catalog riêng được lưu trữ trên GCVE có ghi nhận một báo cáo khai thác thành công từ Previdian, nhưng đây là thông tin tình báo bên ngoài CNA và chưa nên xem là xác nhận độc lập về khai thác thực tế. Không có chiến dịch, nạn nhân hoặc IOC cụ thể nào được xác định trong các tài liệu đã xem xét.

Lỗ hổng tạo ra quyền đọc tệp từ xa mà không cần tài khoản, với phạm vi ảnh hưởng bao gồm kho tài liệu được phục vụ bởi các endpoint bị lỗi. Kết quả kỹ thuật chính là mất tính bí mật của log, tài liệu nghiệp vụ, bản sao lưu cơ sở dữ liệu và dữ liệu thuộc entity khác; không có quyền ghi hoặc gây gián đoạn dịch vụ được xác lập trong bản ghi. Password hash trong bản sao lưu có thể tạo điều kiện cho việc đoán mật khẩu ngoại tuyến nếu mật khẩu yếu hoặc được tái sử dụng, nhưng khả năng này phụ thuộc vào nội dung bản sao lưu và chính sách xác thực. Trong môi trường multicompany, việc đọc tệp của entity khác có thể mở rộng phạm vi sự cố vượt ra ngoài một đơn vị kinh doanh. Tổ chức có thể phải điều tra rò rỉ dữ liệu, thay đổi thông tin xác thực và đánh giá nghĩa vụ tuân thủ nếu dữ liệu cá nhân hoặc bí mật kinh doanh bị truy cập.

• Rò rỉ dữ liệu: Kẻ tấn công có thể đọc log ứng dụng, tài liệu nghiệp vụ đã tải lên, bản sao lưu cơ sở dữ liệu chứa password hash và tệp của các entity multicompany khác.
• Rủi ro đối với dữ liệu kinh doanh: Tài liệu bị lộ có thể chứa thông tin khách hàng, hợp đồng, hồ sơ giao dịch hoặc dữ liệu nội bộ, tùy theo cách triển khai và nội dung kho tài liệu.
• Rủi ro xác thực: Nếu bản sao lưu chứa password hash bị truy cập, tổ chức có thể phải đánh giá việc thay đổi thông tin xác thực và điều tra khả năng sử dụng lại mật khẩu ở các hệ thống khác.
• Phạm vi xử lý sự cố: Việc xác định tệp đã bị đọc, đánh giá nghĩa vụ thông báo và bảo toàn log có thể cần được thực hiện như một sự cố rò rỉ dữ liệu.

Bản ghi mô tả quyền đọc dữ liệu; không có bằng chứng trong các nguồn đã xem xét cho thấy lỗ hổng này trực tiếp cho phép sửa đổi dữ liệu hoặc gây gián đoạn dịch vụ.

1. Nâng cấp các triển khai nằm trong phạm vi từ 23.0.4 đến trước 24.0.1 lên 24.0.1, là phiên bản được advisory và kho mã nguồn liên kết với bản sửa cho nhánh này.
2. Nếu đang sử dụng nhánh 22.0, xác minh rằng bản backport xử lý website/wrapper.php đã được đưa vào bản phát hành hoặc mã nguồn đang chạy. Không có phiên bản 22.x cụ thể được xác nhận trong tài liệu đã xem xét, vì vậy không nên đánh dấu nhánh này an toàn chỉ dựa trên số phiên bản.
3. Kiểm tra các thay đổi cục bộ, gói phân phối và wrapper triển khai để bảo đảm cả document.php, viewimage.php và website/wrapper.php đều có logic từ chối hashp=shared và không còn ép quyền truy cập chỉ vì tham số hashp không rỗng.
4. Nếu hệ thống có thể đã bị truy cập trước khi vá, bảo toàn log, xác định các tệp nhạy cảm có thể bị đọc và đánh giá việc thay đổi thông tin xác thực xuất hiện trong bản sao lưu bị phơi nhiễm.
5. Không có biện pháp giảm nhẹ tạm thời cụ thể nào từ vendor được xác nhận trong tài liệu đã xem xét. Các biện pháp hạn chế truy cập mạng chỉ nên được xem là kiểm soát bù trừ trong lúc triển khai bản sửa, không thay thế cho việc nâng cấp.

1. Kiểm kê các phiên bản Dolibarr đang chạy, bao gồm phiên bản ứng dụng, nhánh bảo trì và module website nếu được bật.
2. Xác định các hệ thống có thể truy cập từ mạng đến document.php, viewimage.php hoặc website/wrapper.php, đặc biệt các hệ thống lưu log, tài liệu nghiệp vụ, bản sao lưu cơ sở dữ liệu hoặc dữ liệu multicompany.
3. Rà soát access log và log của reverse proxy cho các yêu cầu chứa hashp=shared kết hợp với các endpoint nêu trên. Đây là mẫu phát hiện phòng ngừa dựa trên cơ chế được mô tả, không phải IOC đã được xác nhận.
4. Kiểm tra các phản hồi thành công và lịch sử tải xuống liên quan đến tài liệu, log hoặc bản sao lưu trong thời gian phiên bản dễ bị ảnh hưởng được triển khai.
5. Nếu phát hiện bản sao lưu hoặc tệp nhạy cảm có thể đã bị đọc, xác định dữ liệu liên quan và đánh giá việc thay đổi các thông tin xác thực được lưu trong đó. Không thấy log phù hợp không chứng minh rằng hệ thống chưa bị truy cập.