InvoicePlane không thu hồi quyền quản trị sau khi hạ cấp vai trò

InvoicePlane là một ứng dụng mã nguồn mở tự lưu trữ dùng để quản lý hóa đơn, khách hàng và các khoản thanh toán. Trước 1.7.2, InvoicePlane không thu hồi được đặc quyền quản trị sau khi hạ cấp vai trò vì Admin_Controller tin cậy ảnh chụp user_type được lưu trong session hiện có thay vì xác thực lại ip_users.user_type. Khi một quản trị viên hạ cấp tài khoản khác, session đang hoạt động của tài khoản đích vẫn tiếp tục cấp quyền cho các yêu cầu quản trị. Người dùng bị hạ cấp có thể sử dụng Users::form() để đặt user_type trở lại 1, khôi phục vai trò trong cơ sở dữ liệu và khiến việc leo thang đặc quyền trở nên lâu dài. Lỗ hổng này được khắc phục trong 1.7.2.

• Bản ghi chuẩn hóa xác định InvoicePlane bị ảnh hưởng ở các phiên bản < 1.7.2.
• Advisory của dự án xác định cụ thể 1.7.2-rc-2 là phiên bản bị ảnh hưởng và 1.7.2 là phiên bản đã được vá.
• Bằng chứng hiện có không xác định trạng thái của các nhánh phát hành song song hoặc các phiên bản mới hơn ngoài bản phát hành đã được nêu là đã vá. Không nên suy ra rằng mọi nhánh sau đó đều không bị ảnh hưởng.

InvoicePlane lưu user_type của người dùng vào session khi đăng nhập, sau đó Admin_Controller dùng giá trị trong session để quyết định quyền truy cập quản trị thay vì xác thực lại ip_users.user_type trong cơ sở dữ liệu ở mỗi request.

Khi quản trị viên Y hạ cấp quản trị viên X, vai trò trong cơ sở dữ liệu được đổi nhưng session đang hoạt động của X không bị hủy hoặc cập nhật. Logic cập nhật session chỉ xử lý trường hợp tài khoản đang được sửa chính là tài khoản hiện đang đăng nhập, vì vậy session của X vẫn mang trạng thái quản trị và tiếp tục vượt qua kiểm tra của Admin_Controller.

Session còn hiệu lực cho phép người dùng đã bị hạ cấp gọi các chức năng quản trị, bao gồm chức năng quản lý người dùng. Trong Users::form(), controller đưa lại trường user_type từ dữ liệu HTTP vào bản ghi ngay cả khi trường này được bảo vệ ở tầng model. Do đó, người dùng có session quản trị cũ có thể đặt user_type của chính mình trở lại 1; giá trị này được ghi vào cơ sở dữ liệu và làm cho việc khôi phục quyền trở nên lâu dài.

Advisory của dự án mô tả phạm vi đã kiểm thử là InvoicePlane trên CodeIgniter 3 với files session driver. Bản ghi công khai không xác nhận rằng mọi cấu hình session hoặc mọi thay đổi tùy biến authorization bên ngoài phạm vi này đều có hành vi giống nhau.

Lỗ hổng có thể bị khai thác qua mạng và không yêu cầu user interaction. Điều kiện chính là tài khoản mục tiêu phải có session quản trị đang hoạt động, sau đó một quản trị viên khác hạ cấp tài khoản đó nhưng không làm mất session hiện hữu.

Sau khi bị hạ cấp, người dùng mục tiêu có thể tiếp tục gửi các request quản trị bằng session cũ. Advisory của dự án cung cấp reproduction evidence và proof of concept cho việc giữ lại quyền quản trị, sửa tài khoản người dùng khác và khôi phục user_type của chính tài khoản mục tiêu.

Bản ghi chuẩn hóa đánh dấu public exploit là có, nhưng không xác định liệu đã có khai thác thực tế trong môi trường sản xuất hay chưa. Con đường này cần quyền quản trị ban đầu hoặc khả năng sử dụng một session quản trị đã được cấp trước đó, không phải một tài khoản khách chưa xác thực.

Lỗi làm phá vỡ việc thu hồi quyền tại thời điểm tài khoản bị hạ cấp. Session cũ vẫn được xử lý như session của quản trị viên, vì vậy người dùng mục tiêu có thể tiếp tục thực hiện các thao tác quản trị trong phạm vi của ứng dụng.

Tác động đã được advisory xác nhận gồm giữ quyền truy cập quản trị, sửa các tài khoản khác và đặt lại user_type của chính tài khoản về 1, từ đó ghi lại quyền quản trị vào cơ sở dữ liệu. Điều này tạo ra privilege escalation kéo dài thay vì chỉ là một lần truy cập sai quyền trong session.

Ảnh hưởng trực tiếp được xác định trong phạm vi InvoicePlane và các chức năng quản trị của nó. Bản ghi không thiết lập rằng lỗ hổng tự nó cho phép truy cập hệ thống máy chủ, mở rộng sang tenant khác hoặc gây ảnh hưởng ngoài ứng dụng.

• Việc hạ cấp tài khoản quản trị không tạo ra ranh giới thu hồi quyền đáng tin cậy, làm suy yếu quy trình phân quyền và offboarding.
• Một người dùng lẽ ra chỉ còn quyền thấp hơn vẫn có thể duy trì quyền quản trị trong ứng dụng thông qua session cũ.
• Người dùng đó có thể sửa các tài khoản khác và khôi phục quyền của chính mình trong cơ sở dữ liệu, khiến trạng thái đặc quyền tồn tại sau khi session được làm mới.
• Tùy theo các chức năng quản trị được triển khai và dữ liệu mà tài khoản có thể truy cập, sự cố có thể dẫn đến thay đổi trái phép đối với tài khoản, hóa đơn, khách hàng, thanh toán hoặc cấu hình ứng dụng.
• Bằng chứng được cung cấp tập trung vào quyền quản trị trong chính ứng dụng InvoicePlane; không có cơ sở để kết luận về ảnh hưởng sang hệ thống bên ngoài.

1. Nâng cấp InvoicePlane lên 1.7.2, là phiên bản được advisory của dự án xác định là đã vá. Không nên coi một phiên bản hoặc nhánh khác là an toàn nếu chưa có xác nhận riêng.
2. Nếu chưa thể nâng cấp, sửa lớp authorization để xác thực lại ip_users.user_type ở mỗi request quản trị hoặc sử dụng cơ chế role cache phía máy chủ có invalidation đáng tin cậy khi vai trò thay đổi.
3. Khi một tài khoản bị thay đổi vai trò, hủy hoặc buộc xoay vòng toàn bộ session đang hoạt động của tài khoản đó để thay đổi có hiệu lực ngay.
4. Không đưa lại trường được bảo vệ như user_type trực tiếp từ dữ liệu request. Việc thay đổi role nên đi qua một luồng quản trị rõ ràng, được kiểm tra quyền và ghi audit.
5. Trong khi khắc phục, rà soát các tài khoản đã bị hạ quyền và buộc đăng nhập lại. Có thể giảm thời gian sống của session và xoay vòng session identifier như biện pháp giảm thời gian tồn tại của session lỗi, nhưng các biện pháp này không thay thế việc sửa kiểm tra authorization.

• Kiểm kê các triển khai InvoicePlane và xác định những bản cài đặt thuộc phạm vi trước bản phát hành đã được vá. Đối chiếu cả mã nguồn thực tế với phiên bản được khai báo trong inventory.
• Kiểm tra các thay đổi ip_users.user_type đối với tài khoản đang có session hoạt động, đặc biệt những trường hợp tài khoản bị hạ từ quản trị viên xuống người dùng hoặc khách nhưng vẫn phát sinh request quản trị.
• Nếu ứng dụng có audit log, tương quan các sự kiện hạ cấp vai trò với request tới các chức năng do Admin_Controller bảo vệ và với hoạt động trong controller Users.
• Rà soát các request tới Users::form() có thay đổi trường user_type, nhất là khi giá trị trong cơ sở dữ liệu của tài khoản vừa bị hạ cấp lại trở thành 1.
• Kiểm tra mã nguồn hoặc cấu hình để xác nhận authorization quản trị có đọc lại ip_users.user_type hay chỉ tin cậy giá trị user_type trong session.
• Trong quá trình điều tra, buộc đăng xuất hoặc vô hiệu hóa session của các tài khoản vừa bị hạ quyền. Việc không thấy log liên quan không chứng minh rằng session cũ chưa bị lạm dụng.