Bypass PKCE trong OpenIdentityPlatform OpenAM cho phép đổi authorization code bị chặn

Open Access Management (OpenAM) là một giải pháp quản lý truy cập. Trước phiên bản 16.1.1, AuthorizationCodeGrantTypeHandler chỉ yêu cầu code_verifier khi thiết lập codeVerifierEnforced ở cấp realm được bật, ngay cả khi một authorization code lưu trữ code_challenge. Vì thiết lập này mặc định bị tắt, attacker chặn được authorization code được bảo vệ bằng PKCE có thể bỏ qua code_verifier và đổi code, trong khi một verifier sai được cung cấp rõ ràng vẫn bị từ chối. Public client bị ảnh hưởng trực tiếp, còn việc khai thác confidential-client cần thêm client authentication material hoặc một redemption context khác. Vấn đề này được sửa trong phiên bản 16.1.1.

OpenIdentityPlatform OpenAM Community Edition và artifact Maven org.openidentityplatform.openam:openam-oauth2 được xác định như sau:

• Bản ghi chuẩn hóa đánh dấu các phiên bản < 16.1.1 là bị ảnh hưởng.
• Advisory của CNA nêu cụ thể các phiên bản <=16.0.6 là bị ảnh hưởng và xác định 16.1.1 là phiên bản đã sửa.
• Bằng chứng hiện có chưa giải quyết được trạng thái của các phiên bản 16.0.7 đến 16.1.0; không nên mặc định coi các phiên bản trung gian này là an toàn.
• Các triển khai dùng cấu hình OAuth2 Provider mặc định trong nhánh bị ảnh hưởng được advisory xác định là có khả năng bị tác động, đặc biệt khi yêu cầu verifier ở cấp realm bị tắt.

OpenIdentityPlatform OpenAM xử lý authorization-code grant trong thành phần openam-oauth2, với logic chính nằm trong AuthorizationCodeGrantTypeHandler. Khi authorization endpoint phát hành một authorization code kèm code_challenge, code này phải được ràng buộc với code_verifier tương ứng tại token endpoint. Trong phiên bản bị ảnh hưởng, handler chỉ bắt buộc code_verifier khi thiết lập realm-wide codeVerifierEnforced được bật; nếu thiết lập này tắt, việc kiểm tra có thể bị bỏ qua khi người gọi không gửi tham số code_verifier. Một code_verifier sai rõ ràng vẫn bị từ chối, vì vậy lỗi nằm ở nhánh thiếu tham số chứ không phải ở việc chấp nhận mọi verifier. Kẻ tấn công cần có được hoặc chặn authorization code trước khi code được đổi lấy token; với public client, không cần thêm client authentication material, còn confidential client cần material xác thực client hoặc một redemption context khác. Bản sửa đổi kiểm tra xem authorization code có lưu code_challenge hay không, luôn yêu cầu verifier trong trường hợp đó và chỉ xác thực verifier khi code thực sự được phát hành cùng challenge.

Lỗi có thể bị khai thác qua network tại luồng đổi authorization code lấy token. Hồ sơ chuẩn hóa mô tả yêu cầu đặc quyền trước bằng không và không yêu cầu user interaction, nhưng attacker phải đạt được precondition quan trọng là chặn hoặc thu được một authorization code được bảo vệ bằng PKCE. Public client bị ảnh hưởng trực tiếp vì không cần client authentication material để đổi code; với confidential client, attacker còn cần client authentication material hoặc một context có thể thực hiện việc đổi code. Độ phức tạp thực tế cao do yêu cầu chặn authorization code. Bản ghi không xác lập việc khai thác đã được quan sát và không chỉ ra public exploit; advisory được kiểm tra cũng không nêu chiến dịch, nạn nhân hoặc chỉ báo khai thác cụ thể.

Kết quả kỹ thuật là PKCE không còn bảo đảm rằng bên đổi authorization code phải biết bí mật code_verifier gắn với code đó. Điều này có thể tạo token với quyền của authorization code và dẫn đến truy cập trái phép vào các tài nguyên mà token được cấp phép sử dụng.

• Public client có đường khai thác trực tiếp hơn vì không có yêu cầu client authentication material bổ sung.
• Confidential client vẫn có rào cản bổ sung là client authentication material hoặc một redemption context có thể hoàn tất việc đổi code.
• Lỗi không mô tả khả năng thực thi mã, chiếm quyền quản trị OpenAM hoặc gây mất tính sẵn sàng; tác động được chứng minh hiện tại tập trung vào authorization bypass và token issuance.

Lỗi có thể dẫn đến việc phát hành token cho một bên không biết code_verifier ban đầu.

• Với public client, attacker chặn được authorization code có thể nhận token và sử dụng quyền được cấp cho code đó.
• Với confidential client, tác động đòi hỏi thêm client authentication material hoặc một redemption context khác, nên điều kiện khai thác chặt chẽ hơn.
• Token bị phát hành trái phép có thể cho phép truy cập hoặc thay đổi dữ liệu trong phạm vi scope và quyền mà authorization code đại diện.
• Bằng chứng hiện có mô tả bypass trong quy trình cấp token, nhưng không xác lập việc thay đổi cấu hình OpenAM, thực thi mã tùy ý hoặc làm gián đoạn dịch vụ.

1. Nâng cấp OpenAM lên phiên bản đã sửa 16.1.1. Đây là phiên bản được advisory của CNA xác định là đã vá lỗi.
2. Nếu chưa thể nâng cấp ngay, bật thiết lập realm-wide codeVerifierEnforced để buộc authorization-code grant yêu cầu code_verifier. Đây chỉ nên được xem là biện pháp giảm thiểu tạm thời, vì bằng chứng hiện có không thay thế việc triển khai bản sửa chính thức.
3. Kiểm tra các client và realm đang dùng PKCE, sau đó xác nhận trong môi trường kiểm thử rằng code có code_challenge luôn bị từ chối khi thiếu verifier tương ứng.
4. Nếu có dấu hiệu authorization code đã bị đổi trái phép, thực hiện quy trình phản ứng sự cố hiện hành của tổ chức, bao gồm rà soát token và phiên liên quan. Bản ghi không cung cấp chỉ báo cụ thể để xác định một token bị lạm dụng.

1. Kiểm kê các triển khai OpenAM và xác định artifact Maven org.openidentityplatform.openam:openam-oauth2, đồng thời ghi nhận chính xác nhánh phiên bản đang chạy.
2. Kiểm tra cấu hình OAuth2 Provider theo từng realm, đặc biệt là codeVerifierEnforced và thuộc tính ssoadm forgerock-oauth2-provider-code-verifier-enforced. Thiết lập này giúp nhận diện cấu hình có khả năng làm lộ nhánh lỗi, nhưng chỉ kiểm tra cấu hình không đủ để chứng minh an toàn.
3. Nếu telemetry lưu được sự hiện diện của tham số, rà soát các authorization-code exchange trong đó authorization code được phát hành cùng code_challenge nhưng yêu cầu tại token endpoint không có code_verifier. Việc không có log phù hợp không chứng minh rằng hệ thống không bị khai thác.
4. Trong môi trường kiểm thử, xác nhận rằng authorization code có code_challenge không thể được đổi thành token khi thiếu code_verifier tương ứng. Không nên chỉ kiểm tra trường hợp gửi verifier sai, vì advisory xác định nhánh thiếu tham số mới là nhánh bypass.