Lỗi bypass xác thực giữa các issuer trong Apache APISIX

Lỗ hổng Xác thực không đúng trong Apache APISIX. Trên một route sử dụng plugin openid-connect với remote introspection tới một authorization server phục vụ nhiều issuer, một token được introspect là active đối với một issuer có thể được chấp nhận trên route bị giới hạn cho issuer khác. Vấn đề này ảnh hưởng đến Apache APISIX: từ 3.12.0 đến 3.18.0. Người dùng được khuyến nghị nâng cấp lên phiên bản 3.19.0, phiên bản đã khắc phục vấn đề.

• Apache Software Foundation Apache APISIX: bị ảnh hưởng từ 3.12.0 đến 3.18.0 theo semver.
• Bản ghi khuyến nghị sử dụng 3.19.0, được xác định là bản sửa lỗi.
• default_status được ghi nhận là unaffected ngoài khoảng bị ảnh hưởng đã nêu, nhưng bản ghi không cung cấp phân tích riêng cho các nhánh song song hoặc bản dựng do bên thứ ba đóng gói.

Đây là lỗi CWE-287 trong plugin openid-connect của Apache APISIX khi sử dụng remote introspection. Điều kiện liên quan là authorization server phục vụ nhiều issuer, trong khi route được giới hạn cho một issuer cụ thể. Một token được introspect là active đối với một issuer có thể vẫn được chấp nhận trên route dành cho issuer khác. Hành vi này cho thấy kết quả introspection chưa được ràng buộc đúng với giới hạn issuer của route trước khi request được chấp nhận. Vector đánh giá được cung cấp mô tả khả năng truy cập qua mạng, yêu cầu quyền hạn thấp, độ phức tạp thấp và không cần user interaction, nhưng vẫn có điều kiện cấu hình trước. Bản ghi không xác định vị trí triển khai chính xác, configuration key hoặc các trường request và response cụ thể gây ra lỗi.

Đường khai thác có thể tiếp cận qua mạng thông qua route được bảo vệ bởi plugin bị ảnh hưởng. Metadata đánh giá được cung cấp mô tả yêu cầu quyền hạn thấp, độ phức tạp thấp và không cần user interaction. Điều kiện cần là remote introspection được sử dụng với authorization server có nhiều issuer, cùng một token đang active cho issuer khác với issuer mà route yêu cầu. Bản ghi được cung cấp không xác định public exploit, còn dữ liệu SSVC đi kèm ghi nhận trạng thái exploitation là none; thông tin này không chứng minh rằng việc khai thác là không thể xảy ra.

Khai thác thành công có thể vượt qua kiểm tra xác thực dựa trên issuer tại ranh giới của route. Điều này có thể cho phép một token thuộc ngữ cảnh issuer này truy cập route được thiết kế cho issuer khác, làm sai lệch phạm vi quyền mà hệ thống xác thực dự kiến áp dụng. Tác động tiếp theo phụ thuộc vào quyền của route và các thao tác mà backend cho phép, có thể ảnh hưởng đến phân tách tenant hoặc kiểm soát truy cập nghiệp vụ. Bằng chứng hiện có không mô tả arbitrary code execution, chiếm quyền máy chủ Apache APISIX hoặc gián đoạn dịch vụ.

Lỗi có thể làm suy yếu ranh giới tin cậy giữa các issuer hoặc tenant được bảo vệ bởi cùng một authorization server. Một token hợp lệ trong ngữ cảnh của issuer này có khả năng được dùng để vượt qua lớp kiểm tra issuer của route thuộc issuer khác. Tác động vận hành phụ thuộc vào quyền mà route và backend cấp cho request đã được chấp nhận, nên có thể bao gồm truy cập trái phép vào chức năng hoặc dữ liệu được bảo vệ. Bản ghi không nêu một nạn nhân, chiến dịch hoặc sự cố xâm phạm cụ thể.

1. Nâng cấp Apache APISIX lên 3.19.0, là bản mà Apache xác định đã sửa lỗi.
2. Trước khi triển khai bản sửa, kiểm kê các route dùng plugin openid-connect, remote introspection và authorization server có nhiều issuer để xác định đầy đủ phạm vi phơi nhiễm.
3. Sau khi nâng cấp, thực hiện kiểm thử có kiểm soát để xác nhận token active cho một issuer bị từ chối trên route chỉ dành cho issuer khác.
4. Nếu chưa thể nâng cấp, không nên giả định rằng thay đổi cấu hình hiện tại là một workaround đủ an toàn; bằng chứng được cung cấp không ghi nhận biện pháp giảm thiểu chính thức. Hãy yêu cầu hướng dẫn từ nhà cung cấp và hạn chế việc phụ thuộc vào route bị ảnh hưởng cho đến khi triển khai được bản sửa.
5. Với các bản Apache APISIX do bên thứ ba đóng gói, xác minh rằng gói thực tế đã bao gồm bản sửa tương ứng thay vì chỉ dựa vào nhãn phiên bản.

1. Kiểm kê các triển khai Apache APISIX và xác định những triển khai sử dụng plugin openid-connect với remote introspection.
2. Lập danh sách authorization server, issuer, route restriction và quan hệ giữa từng route với issuer được phép.
3. Trong môi trường kiểm thử có kiểm soát, xác nhận rằng token được introspect là active cho một issuer sẽ bị từ chối khi gửi tới route chỉ dành cho issuer khác.
4. Rà soát log xác thực và request để tìm các request đã được chấp nhận khi issuer của token không khớp với issuer mà route yêu cầu. Đây là biện pháp giám sát phòng ngừa, không phải IOC đã được xác nhận.
5. Đối chiếu phiên bản đang triển khai với khoảng phiên bản bị ảnh hưởng. Không thấy log phù hợp không chứng minh hệ thống an toàn.