Frappe: Sai khác phản hồi trong yêu cầu tải dữ liệu cá nhân cho phép dò người dùng

Frappe là một full-stack web application framework. Trước các phiên bản 15.115.0 và 16.27.0, public request-data web form và lớp PersonalDataDownloadRequest trong frappe/website/doctype/personal_data_download_request/personal_data_download_request.py trả về các response shape có thể phân biệt đối với địa chỉ email đã đăng ký và chưa đăng ký, bao gồm trường user_name và hành vi persistence. Kẻ tấn công từ xa có thể so sánh các phản hồi để dò tìm người dùng đã đăng ký. Vấn đề này được sửa trong các phiên bản 15.115.0 và 16.27.0.

Frappe Framework bị ảnh hưởng trong các nhánh sau:

• Nhánh 15: các phiên bản < 15.115.0 bị ảnh hưởng. Phiên bản 15.115.0 là bản đã sửa theo thông tin CNA và advisory của nhà phát triển.
• Nhánh 16: các phiên bản >= 16.0.0-beta.1, < 16.27.0 bị ảnh hưởng. Phiên bản 16.27.0 là bản đã sửa.
• Hồ sơ không xác nhận trạng thái của các nhánh hoặc bản phát hành song song ngoài các phạm vi trên. PR sửa lỗi chính được backport riêng vào các nhánh version-15-hotfix và version-16-hotfix.

Frappe xử lý email do người gửi cung cấp qua public request-data web form và lớp PersonalDataDownloadRequest trong frappe/website/doctype/personal_data_download_request/personal_data_download_request.py. Trước khi được sửa, yêu cầu với email đã đăng ký và email chưa đăng ký tạo ra các response shape có thể phân biệt, trong đó khác biệt liên quan đến trường user_name và hành vi persistence. Kẻ tấn công từ xa không cần xác thực có thể gửi các địa chỉ email và so sánh phản hồi để suy ra địa chỉ nào gắn với một tài khoản Frappe. Đây là lỗi CWE-204, Observable Response Discrepancy. Bản vá giữ cho phản hồi không phụ thuộc vào trạng thái đăng ký, loại bỏ user_name khỏi biểu diễn phản hồi và xử lý trường hợp người dùng không tồn tại mà không tạo bản ghi cơ sở dữ liệu thực; chi tiết triển khai ngoài các thay đổi này chưa được xác nhận đầy đủ.

Lỗ hổng có thể bị khai thác qua mạng thông qua public request-data web form. Theo dữ liệu được cung cấp, kẻ tấn công không cần quyền truy cập trước, không cần người dùng tương tác và không cần điều kiện phức tạp đặc biệt. Việc khai thác ở mức khái niệm là gửi các email khác nhau rồi so sánh cấu trúc hoặc nội dung phản hồi, nhưng entry này không cung cấp payload hay chuỗi khai thác cụ thể. Bản ghi được cung cấp không xác định public exploit và không xác nhận việc lỗ hổng đã bị khai thác thực tế.

Kết quả kỹ thuật trực tiếp là một người dùng từ xa có thể suy ra sự tồn tại của tài khoản bằng cách quan sát sự khác nhau giữa các phản hồi của cùng một chức năng. Khả năng này làm giảm tính bảo mật của danh sách người dùng và có thể tiết lộ thêm thông tin phản hồi liên quan đến user_name hoặc trạng thái persistence trước khi bản vá được áp dụng. Lỗ hổng không được mô tả là cho phép sửa dữ liệu, đọc toàn bộ dữ liệu cá nhân, nâng quyền hoặc làm gián đoạn dịch vụ. Tuy nhiên, thông tin tài khoản bị lộ có thể làm tăng hiệu quả của các cuộc tấn công nhắm mục tiêu ở bước sau.

Tác động trực tiếp là làm lộ thông tin liệu một địa chỉ email có tương ứng với tài khoản trên hệ thống Frappe hay không. Đây là rò rỉ thông tin nhận dạng tài khoản, có thể hỗ trợ việc lập danh sách mục tiêu cho phishing, credential stuffing hoặc các hoạt động dò tìm khác, nhưng các hậu quả tiếp theo này là khả năng có thể xảy ra chứ không được xác nhận trong hồ sơ. Bản ghi không thiết lập việc thay đổi dữ liệu, gián đoạn dịch vụ hoặc chiếm quyền tài khoản. Tổ chức nên ưu tiên các site công khai có bật chức năng request-data và có dữ liệu người dùng nhạy cảm.

1. Nâng cấp nhánh 15 lên phiên bản 15.115.0 hoặc nhánh 16 lên phiên bản 16.27.0, tùy theo nhánh đang được triển khai. Không nên suy rộng một bản sửa của nhánh này thành trạng thái không bị ảnh hưởng của mọi nhánh khác.
2. Xác nhận sau cập nhật rằng bản package thực tế và mã nguồn đang chạy tương ứng với bản đã sửa, đặc biệt trong các triển khai sử dụng hotfix hoặc bản build nội bộ.
3. Advisory của Frappe nêu rõ không có workaround; vì vậy không nên xem việc che giấu form hoặc các biện pháp giám sát là biện pháp thay thế cho cập nhật. Nếu chưa thể cập nhật ngay, hạn chế tạm thời khả năng truy cập công khai tới chức năng request-data chỉ khi điều đó phù hợp với yêu cầu vận hành, đồng thời coi đây là biện pháp giảm phơi nhiễm tạm thời chứ không phải bản sửa đã được xác nhận.
4. Sau khi cập nhật, kiểm thử rằng phản hồi cho email đã đăng ký và chưa đăng ký có cấu trúc tương đương, trường user_name không còn tạo ra khác biệt quan sát được và yêu cầu đối với người dùng không tồn tại không tạo persistence không mong muốn.

1. Kiểm kê các triển khai Frappe có public request-data web form và xác định phiên bản framework đang chạy.
2. Kiểm tra nhánh phiên bản và đối chiếu với các ranh giới bị ảnh hưởng trong affected_summary, bao gồm cả các bản cài đặt beta hoặc hotfix của nhánh 16.
3. Rà soát log ứng dụng hoặc reverse proxy để tìm các chuỗi gửi yêu cầu lặp lại tới form công khai với nhiều địa chỉ email. Đây là biện pháp giám sát phòng ngừa, không phải indicator of compromise đã được xác nhận.
4. Nếu còn dữ liệu lịch sử, kiểm tra xem các phản hồi của form có từng thể hiện khác biệt theo trạng thái đăng ký hay không. Việc không thấy log hoặc không thấy khác biệt trong log không chứng minh hệ thống an toàn.
5. Sau khi cập nhật, thực hiện kiểm thử parity có kiểm soát bằng các địa chỉ test được ủy quyền và xác nhận rằng hai loại đầu vào không còn tạo response shape có thể phân biệt.