Lỗ hổng timing trong openbao OpenBao có thể làm lộ recovery token đặc quyền

OpenBao là hệ thống mã nguồn mở để quản lý secrets dựa trên identity. Trước phiên bản 2.6.0, đường dẫn handleLogicalRecovery của OpenBao trong http/logical.go đã so sánh recovery token có đặc quyền rất cao bằng phép so sánh chuỗi thông thường. Kẻ tấn công từ xa không cần xác thực, nếu có thể gửi lặp lại các yêu cầu recovery mode và đo thời gian phản hồi, có thể suy ra recovery token. Token thu được sau đó có thể cấp quyền cho các thao tác recovery mode để đọc hoặc sửa đổi dữ liệu OpenBao. Vấn đề này được khắc phục ở phiên bản 2.6.0.

• openbao OpenBao: các phiên bản < 2.6.0 được xác định là bị ảnh hưởng.
• OpenBao 2.6.0 được xác định là phiên bản đã sửa lỗi, với thay đổi dùng phép so sánh token constant-time trong recovery mode.
• Bằng chứng hiện có không đưa ra trạng thái riêng cho các dòng sản phẩm khác hoặc các bản build downstream ngoài ranh giới nêu trên.

Thành phần dễ bị lỗi là handleLogicalRecovery trong http/logical.go. OpenBao so sánh recovery token đặc quyền bằng phép so sánh chuỗi thông thường thay vì phép so sánh có thời gian thực thi không phụ thuộc vào mức độ khớp. Kẻ tấn công kiểm soát các yêu cầu recovery mode và có thể gửi chúng lặp lại để đo sai khác trong thời gian phản hồi. Từ tín hiệu timing này, kẻ tấn công có thể suy ra recovery token duy nhất bảo vệ các thao tác API của recovery mode. Điều kiện khai thác là có khả năng truy cập qua mạng đến recovery mode; không cần xác thực trước, nhưng cần nhiều phép đo và các điều kiện triển khai phù hợp. Bằng chứng hiện có không cho biết số lượng yêu cầu cần thiết, mức nhiễu mạng chấp nhận được, hoặc mọi cấu hình triển khai có làm recovery mode lộ ra mạng không tin cậy hay không.

Lỗ hổng có thể bị tiếp cận qua mạng và không yêu cầu quyền trước hoặc tương tác của người dùng. Kẻ tấn công vẫn phải gửi nhiều yêu cầu recovery mode và đo thời gian phản hồi, vì vậy đây không phải là khai thác một lần với độ phức tạp thấp. Bản ghi được cung cấp đánh dấu chưa có public exploit và không cung cấp trạng thái known exploited; điều này không chứng minh rằng lỗ hổng chưa từng bị khai thác. Bằng chứng hiện có không nêu mã khai thác, chiến dịch, nạn nhân hoặc IOC cụ thể.

Kẻ tấn công lấy được recovery token có thể thực hiện các thao tác recovery mode mà token đó bảo vệ, bao gồm đọc hoặc sửa đổi dữ liệu OpenBao. Vì recovery mode là chế độ có đặc quyền rất cao, việc chiếm token có thể vượt qua các kiểm soát truy cập thông thường áp dụng cho các thao tác ở chế độ này. Tác động trực tiếp đã được hỗ trợ là mất tính bí mật và tính toàn vẹn của dữ liệu do OpenBao quản lý. Bằng chứng không xác nhận việc chiếm các hệ thống downstream, quyền truy cập hệ điều hành, hoặc một thao tác làm mất tính sẵn sàng cụ thể.

Việc suy ra recovery token có thể cho phép truy cập trái phép vào các thao tác recovery mode đặc quyền cao. Hậu quả đã được xác nhận gồm khả năng đọc dữ liệu OpenBao, có thể dẫn đến lộ secrets hoặc dữ liệu vận hành do OpenBao quản lý. Kẻ tấn công cũng có thể sửa đổi dữ liệu thông qua các thao tác recovery mode được token cho phép, ảnh hưởng đến tính toàn vẹn của cấu hình hoặc dữ liệu lưu trữ. Bằng chứng không nêu nạn nhân, vụ rò rỉ cụ thể, dịch vụ phụ thuộc bị ảnh hưởng hoặc một kịch bản gián đoạn dịch vụ cụ thể.

1. Nâng cấp OpenBao lên đúng phiên bản 2.6.0, là phiên bản được advisory và release của vendor xác định đã sửa lỗi.
2. Nếu chưa thể nâng cấp ngay, hạn chế khả năng truy cập recovery-mode request handling từ mạng không tin cậy, chỉ cho phép các mạng quản trị đáng tin cậy khi kiến trúc triển khai hỗ trợ. Đây là biện pháp giảm phơi nhiễm dựa trên điều kiện tấn công mạng, không phải workaround được vendor xác nhận.
3. Kiểm tra xem recovery mode của các instance bị ảnh hưởng có từng có thể truy cập từ nguồn không tin cậy hay không. Nếu có dấu hiệu timing probing hoặc token bị lộ, xử lý recovery token và dữ liệu liên quan theo quy trình incident response của tổ chức.
4. Không nên coi việc không có log hoặc IOC đã biết là bằng chứng loại trừ phơi nhiễm, vì nguồn công khai không cung cấp một bộ chỉ dấu hoàn chỉnh.

1. Kiểm kê mọi máy chủ và image đang chạy OpenBao, sau đó đối chiếu phiên bản với ranh giới bị ảnh hưởng trong phần affected summary.
2. Xác định các triển khai đang chạy hoặc cho phép recovery mode, đồng thời kiểm tra recovery-mode request handling có thể được truy cập từ mạng không tin cậy hay không.
3. Rà soát network telemetry và request telemetry hiện có để tìm các chuỗi yêu cầu recovery mode lặp lại từ nguồn chưa xác thực, đặc biệt khi có dấu hiệu đo thời gian phản hồi. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được vendor xác nhận.
4. Nếu phát hiện mẫu truy cập đáng ngờ, điều tra các thao tác recovery mode và việc đọc hoặc sửa đổi dữ liệu xảy ra sau đó. Không có log event cụ thể nào được công bố, và việc không thấy log phù hợp không chứng minh hệ thống an toàn.