InvoicePlane thiếu phân quyền object-level, cho phép hạ quyền Primary Administrator

InvoicePlane là một ứng dụng mã nguồn mở self-hosted dùng để quản lý hóa đơn, khách hàng và các khoản thanh toán. Trong phiên bản 1.7.2, Users::form() không thực hiện kiểm tra phân quyền ở cấp object đối với user_id = 1. Một Secondary Administrator (user_type = 1, user_id!= 1) có thể ghi đè user_type của Primary Administrator thành 2 (Guest / chỉ đọc), làm mất quyền của tài khoản root và khóa chủ sở hữu hợp pháp khỏi instance. Tại thời điểm công bố, chưa có bản vá nào được cung cấp công khai.

• InvoicePlane InvoicePlane 1.7.2: phiên bản được xác nhận bị ảnh hưởng.
• Bản ghi và advisory không liệt kê phiên bản đã được vá; trạng thái của các phiên bản khác không được xác lập trong bằng chứng hiện có.
• Điều kiện triển khai đáng chú ý là instance có tài khoản Secondary Administrator có thể truy cập chức năng quản lý người dùng.

InvoicePlane's Users::form() nhận ID của bản ghi đích từ route nhưng không kiểm tra actor có được phép sửa object đó hay không. Hàm chỉ phân biệt chỉnh sửa tài khoản của chính mình với chỉnh sửa tài khoản khác; đối với chỉnh sửa không phải self-edit, giá trị user_type được gửi lên có thể được gán cho tài khoản đích, bao gồm Primary Administrator. Đường dẫn này có thể được tiếp cận bởi một Secondary Administrator đã xác thực thông qua giao diện quản lý người dùng hoặc HTTP request tương ứng; không cần trạng thái unauthenticated hay CSRF bypass bổ sung. Khi role thay đổi, invalidate_user_sessions($id) hủy các session của tài khoản bị tác động, làm tình trạng khóa quyền truy cập nghiêm trọng hơn. Cơ chế bảo vệ mass-assignment trong model không khắc phục được lỗi vì controller vẫn gán user_type một cách rõ ràng; cách triển khai và việc ghi log ở từng môi trường chưa được xác định.

Lỗi có thể bị khai thác qua mạng từ giao diện quản lý người dùng hoặc HTTP request tương ứng. Điều kiện bắt buộc là attacker phải có tài khoản Secondary Administrator hợp lệ (user_type = 1, user_id != 1); không có đường khai thác unauthenticated được mô tả. Không cần victim interaction, CSRF bypass bổ sung hoặc quyền cao hơn quyền đã có của Secondary Administrator. user_id = 1 là định danh cố định của Primary Administrator và có thể được xác định từ danh sách người dùng chuẩn. Advisory công khai có thông tin tái hiện lỗi, nhưng bằng chứng hiện có không xác định việc khai thác thực tế trong các chiến dịch hay sự cố cụ thể.

Lỗi cho phép một tài khoản đã có quyền Secondary Administrator thay đổi thuộc tính quyền của Primary Administrator, nhưng không cho thấy attacker nhận thêm quyền từ một tài khoản vốn đã quản trị. Hậu quả kỹ thuật là user_type của tài khoản user_id = 1 bị hạ xuống 2, Primary Administrator mất khả năng thực hiện các chức năng quản trị và các session hiện tại có thể bị hủy. Instance có thể bị khóa quyền quản trị đối với chủ sở hữu hợp pháp, trong khi Secondary Administrator trở thành administrator hiệu dụng duy nhất. Không có bằng chứng trực tiếp về ảnh hưởng đến tính bí mật của dữ liệu; trạng thái của dữ liệu nghiệp vụ ngoài quyền truy cập quản trị chưa được xác định.

Một Secondary Administrator có thể phá vỡ ranh giới tin cậy giữa các tài khoản quản trị bằng cách hạ quyền tài khoản gốc. Primary Administrator có thể bị thu hồi session và mất quyền sử dụng các chức năng quản trị, khiến instance nằm dưới quyền kiểm soát hiệu dụng của attacker hoặc các Secondary Administrator còn lại. Việc khôi phục có thể cần truy cập trực tiếp vào cơ sở dữ liệu vì chủ sở hữu không còn khả năng sửa lỗi qua giao diện ứng dụng. Bằng chứng hiện có không xác nhận việc lộ dữ liệu hoặc sửa đổi dữ liệu hóa đơn, khách hàng hay thanh toán; tác động được xác nhận tập trung vào quyền quản trị và khả năng tiếp tục vận hành.

1. Triển khai một object-level authorization guard toàn cục ở đầu Users::form(), trước validation, db_array(), phép gán user_type, thao tác lưu và cả nhánh hiển thị GET. Guard phải từ chối mọi thao tác trên user_id = 1 nếu actor không phải chính Primary Administrator, trả về 403.
2. Không chỉ bảo vệ riêng password, email hoặc role. Guard phải bao phủ mọi mutation của tài khoản user_id = 1, bao gồm các field hiện tại và field được thêm trong tương lai.
3. Kiểm thử sau thay đổi: request GET và POST tới tài khoản user_id = 1 từ Secondary Administrator phải bị từ chối; ip_users.user_type của tài khoản này phải vẫn là 1; Primary Administrator vẫn phải chỉnh sửa được hồ sơ của chính mình.
4. Bản ghi hiện không cung cấp bản vá phát hành công khai cụ thể. Trong thời gian chưa triển khai được guard, xem việc hạn chế quyền và phạm vi truy cập của các tài khoản Secondary Administrator là biện pháp giảm rủi ro tạm thời, không phải bản sửa lỗi hoàn chỉnh.

1. Kiểm kê các instance InvoicePlane và xác định những instance chạy phiên bản bị ảnh hưởng.
2. Kiểm tra bảng ip_users để xác nhận tài khoản user_id = 1 vẫn giữ user_type = 1, đồng thời lập danh sách các Secondary Administrator có user_type = 1 và user_id != 1.
3. Rà soát log ứng dụng hoặc reverse proxy, nếu có, đối với các request đến /users/form/1 do Secondary Administrator thực hiện; đối chiếu với request có thay đổi user_type thành 2 và việc hủy session của Primary Administrator. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận.
4. Kiểm tra các dấu hiệu vận hành như Primary Administrator bất ngờ bị đăng xuất hoặc mất quyền quản trị đồng thời với thay đổi role.
5. Sau khi triển khai guard, xác minh rằng Secondary Administrator nhận 403 khi truy cập hoặc gửi thay đổi tới tài khoản user_id = 1, dữ liệu role vẫn là user_type = 1, còn Primary Administrator vẫn chỉnh sửa được hồ sơ của chính mình. Không thấy log phù hợp không chứng minh instance an toàn.