XSS phản chiếu trong xử lý lỗi xác thực OIDC/JWT của OpenBao

OpenBao là một hệ thống quản lý secrets dựa trên danh tính, mã nguồn mở. Trước phiên bản 2.5.2, các cài đặt OpenBao đã bật phương thức xác thực OIDC/JWT và được cấu hình một role với callback_mode=direct dễ bị XSS thông qua tham số error_description trên trang xác thực thất bại. Điều này cho phép kẻ tấn công truy cập token được nạn nhân sử dụng trong Web UI. Tham số error_description đã được thay thế bằng một thông báo lỗi tĩnh trong v2.5.2. Có thể giảm thiểu lỗ hổng bằng cách xóa mọi role có callback_mode được đặt thành direct.

• OpenBao: bị ảnh hưởng ở các phiên bản < 2.5.2 theo bản ghi chuẩn hóa; advisory của nhà phát triển diễn đạt cùng phạm vi là <=2.5.1.
• Điều kiện cấu hình: phương thức xác thực OIDC/JWT phải được bật và phải có role với callback_mode=direct.
• Bản đã sửa: 2.5.2, trong đó error_description được thay bằng thông báo lỗi tĩnh.
• Bằng chứng hiện có không xác nhận trạng thái của các nhánh OpenBao song song hoặc các bản dựng phân phối khác ngoài các ranh giới nêu trên.

OpenBao phản chiếu dữ liệu từ tham số error_description vào trang HTML được hiển thị sau một lần xác thực OIDC/JWT thất bại mà không trung hòa phù hợp. Phạm vi phơi nhiễm yêu cầu phương thức xác thực OIDC/JWT được bật và một role được cấu hình với callback_mode=direct. Kẻ tấn công có thể kiểm soát giá trị lỗi thông qua một URL được tạo đặc biệt; để hoàn tất việc khai thác, nạn nhân phải truy cập URL đó trong trình duyệt. Khi mã XSS chạy trong ngữ cảnh Web UI, kẻ tấn công có thể lấy token được sử dụng bởi nạn nhân trong Web UI và thực hiện các thao tác theo quyền của token đó. Bản sửa đổi thay thế việc hiển thị error_description bằng thông báo lỗi tĩnh, đồng thời xử lý an toàn hơn các nội dung lỗi trong luồng OIDC/JWT. Chi tiết về payload phía trình duyệt và mọi endpoint cụ thể được dùng trong một cuộc tấn công thực tế không được xác lập trong bằng chứng hiện có.

Lỗ hổng có thể được tiếp cận qua mạng trong luồng xác thực Web UI và không yêu cầu kẻ tấn công có quyền trước trong hệ thống. Điều kiện triển khai là phương thức OIDC/JWT phải được bật và phải tồn tại role dùng callback_mode=direct. Người dùng nạn nhân phải truy cập một URL được tạo đặc biệt, vì vậy đây là luồng khai thác yêu cầu user interaction. Bằng chứng được cung cấp không nêu tên chiến dịch, nạn nhân hoặc public exploit cụ thể; trạng thái đó không chứng minh rằng chưa từng có khai thác ngoài thực tế.

Lỗi cho phép mã XSS chạy trong trình duyệt của người dùng khi trang lỗi xác thực phản chiếu dữ liệu từ error_description. Kết quả trực tiếp được nhà cung cấp mô tả là kẻ tấn công có thể truy cập token dùng trong Web UI. Với token có quyền cao, điều này có thể dẫn đến đọc hoặc thay đổi secrets, thu hồi token, xoay vòng application secret và làm gián đoạn các ứng dụng phụ thuộc vào chúng. Lỗ hổng không tự nó chứng minh quyền quản trị trên mọi hệ thống, vì phạm vi hành động phụ thuộc vào quyền của token bị lấy cắp. Bằng chứng hiện có không xác lập việc thực thi mã tùy ý trên máy chủ OpenBao.

Nếu bị khai thác, token Web UI của nạn nhân có thể bị truy cập trái phép. Tùy quyền được cấp cho token, kẻ tấn công có thể đọc các database credential, API key hoặc certificate mà người dùng được phép xem, đồng thời có thể sửa, ghi đè hoặc xóa secrets và quản lý token thay mặt người dùng. Điều này có thể dẫn đến mất bí mật, thay đổi cấu hình hoặc gián đoạn các dịch vụ phụ thuộc vào secrets. Tác động thực tế bị giới hạn bởi quyền của token bị đánh cắp và bằng chứng hiện có không cho thấy một vụ xâm phạm cụ thể.

1. Nâng cấp OpenBao lên 2.5.2, bản đã thay thế việc hiển thị error_description bằng thông báo lỗi tĩnh.
2. Nếu chưa thể nâng cấp, rà soát cấu hình OIDC/JWT và xóa hoặc vô hiệu hóa mọi role có callback_mode=direct.
3. Xác minh bản thực tế đang chạy, bao gồm bản đóng gói hoặc container, đã chứa bản sửa trước khi khôi phục cấu hình dễ bị ảnh hưởng.
4. Nếu có khả năng token Web UI đã bị truy cập qua luồng xác thực bị ảnh hưởng, thực hiện biện pháp phòng ngừa phù hợp như thu hồi session hoặc token liên quan và xoay vòng secrets mà các token đó có quyền truy cập.

1. Kiểm kê các bản OpenBao đang chạy và đối chiếu phiên bản triển khai với ranh giới bị ảnh hưởng và bản đã sửa.
2. Kiểm tra cấu hình auth để xác định phương thức OIDC/JWT đang bật và rà soát mọi role có callback_mode=direct.
3. Rà soát server logs quanh các lần xác thực OIDC/JWT thất bại, đặc biệt các giá trị bất thường của error_description hoặc error_uri, nếu hệ thống có ghi nhận các trường này. Đây là kiểm tra phòng ngừa, không phải IOC đã được xác nhận.
4. Rà soát audit logs để tìm việc sử dụng bất thường các Web UI session hoặc token của người dùng sau các lần xác thực thất bại. Việc không thấy sự kiện đáng ngờ không chứng minh rằng token chưa bị lộ.