WordPress: SQL Injection qua author__not_in trong WP_Query

WordPress 6.8.x trước 6.8.6, 6.9.x trước 6.9.5 và 7.0.x trước 7.0.2 không sanitise đúng cách tham số author__not_in của WP_Query, điều này có thể cho phép SQL Injection khi plugin hoặc theme truyền dữ liệu không tin cậy vào tham số này.

• WordPress 6.8.x: Các bản từ 6.8.0 đến 6.8.5 bị ảnh hưởng. Bản sửa lỗi là 6.8.6.
• WordPress 6.9.x: Các bản từ 6.9.0 đến 6.9.4 bị ảnh hưởng. Bản sửa lỗi là 6.9.5.
• WordPress 7.0.x: Các bản từ 7.0.0 đến 7.0.1 bị ảnh hưởng. Bản sửa lỗi là 7.0.2.
• WordPress cho biết các bản trước 6.8 không bị ảnh hưởng.
• Advisory của nhà cung cấp cũng cho biết 7.1 beta2 đã có bản sửa cho nhánh beta, nhưng bản ghi được cung cấp không xác định đầy đủ phạm vi các bản beta bị ảnh hưởng.

Thành phần bị ảnh hưởng là cơ chế xử lý author__not_in của WP_Query trong WordPress. Lỗi xảy ra do tham số này không được sanitise đầy đủ khi plugin hoặc theme truyền dữ liệu không tin cậy vào WP_Query. Kẻ tấn công cần tiếp cận được một luồng xử lý của plugin hoặc theme có nhận hoặc tạo đầu vào do kẻ tấn công kiểm soát rồi chuyển đầu vào đó cho WP_Query; bản ghi không xác định một endpoint core duy nhất luôn có thể khai thác. Điều kiện này tạo ra khả năng SQL Injection. Advisory của WordPress cho biết trên một số nhánh phát hành mới hơn, lỗi này có thể kết hợp với một lỗi riêng liên quan đến nhầm lẫn route của REST API batch để dẫn đến Remote Code Execution; hậu quả đó phụ thuộc vào lỗi thứ hai và không nên được xem là kết quả chắc chắn của SQL Injection trong mọi triển khai. Bản ghi được cung cấp và advisory của nhà cung cấp không mô tả đầy đủ code path dễ bị lỗi hoặc cách câu truy vấn được tạo ra.

• Khả năng tiếp cận: Có thể bị tác động qua mạng khi một request đến được code path của plugin hoặc theme có truyền đầu vào không tin cậy vào tham số này.
• Xác thực và tương tác: Bản ghi cho biết không yêu cầu đặc quyền và không cần người dùng tương tác.
• Độ phức tạp: Được đánh giá là cao, vì việc khai thác cần một luồng xử lý phù hợp để dữ liệu không tin cậy đến được WP_Query.
• Trạng thái khai thác: Bản ghi chuẩn hóa đánh dấu lỗ hổng là đã bị khai thác và có public exploit. Bản ghi không cung cấp thông tin cụ thể về chiến dịch, nạn nhân hoặc IOC.

Kết quả kỹ thuật là khả năng thực hiện SQL Injection thông qua xử lý WP_Query, với tác động đến tính bảo mật của dữ liệu cơ sở dữ liệu được bản ghi đánh giá ở mức cao. Bản ghi không ghi nhận tác động đến tính toàn vẹn hoặc tính sẵn sàng đối với lỗi này. Lỗi có thể được tiếp cận qua mạng, không yêu cầu đặc quyền hoặc tương tác của người dùng, nhưng cần một luồng đầu vào phù hợp nên độ phức tạp khai thác được đánh giá là cao. Trên các nhánh đồng thời có lỗi REST API batch riêng, advisory của WordPress cho biết hai lỗi có thể được kết hợp để dẫn đến Remote Code Execution; đây là hậu quả phụ thuộc điều kiện và không phải kết quả chắc chắn trong mọi triển khai.

• Rò rỉ dữ liệu: SQL Injection có thể cho phép đọc dữ liệu được lưu trong cơ sở dữ liệu WordPress, tùy thuộc vào code path có thể tiếp cận và quyền của tài khoản cơ sở dữ liệu.
• Rủi ro vận hành: Dữ liệu bị lộ có thể hỗ trợ các hành động xâm nhập tiếp theo, nhưng bằng chứng hiện có không xác nhận một vụ xâm phạm cụ thể hoặc một hành động hậu khai thác cụ thể.
• Khả năng leo thang: Advisory của WordPress cho biết lỗi này có thể kết hợp với một lỗi riêng của REST API batch để dẫn đến Remote Code Execution trên một số nhánh phát hành. Đây là kịch bản kết hợp, không phải kết quả được xác nhận cho mọi hệ thống chỉ chứa lỗi SQL Injection.

1. Nâng cấp WordPress core: Cài đặt đúng bản sửa lỗi tương ứng với nhánh đang sử dụng: 6.8.6 cho nhánh 6.8.x, 6.9.5 cho nhánh 6.9.x hoặc 7.0.2 cho nhánh 7.0.x. Không suy diễn rằng một bản sửa của nhánh này tự động xác nhận trạng thái của mọi nhánh khác.
2. Nếu đang dùng nhánh beta, chuyển sang 7.1 beta2 hoặc bản phát hành beta mới hơn chỉ khi trạng thái của bản đó đã được xác minh theo hướng dẫn của WordPress.
3. Kiểm tra các plugin và theme có truyền dữ liệu không tin cậy vào author__not_in, đồng thời cập nhật hoặc sửa chúng theo hướng dẫn của nhà cung cấp. Không coi việc thay đổi plugin hoặc theme là bản sửa cho WordPress core nếu chưa được kiểm thử.
4. Bản ghi cung cấp không nêu workaround đã được xác nhận. Nếu chưa thể cập nhật, cần áp dụng quy trình giảm phơi nhiễm và điều tra khai thác trong môi trường của tổ chức, nhưng không xem đó là biện pháp thay thế cho bản cập nhật core.

1. Kiểm kê các bản WordPress đang chạy và đối chiếu với các nhánh bị ảnh hưởng cùng bản sửa lỗi được nêu trong affected_summary.
2. Tìm trong mã nguồn plugin và theme các điểm sử dụng author__not_in, sau đó truy vết xem dữ liệu từ request hoặc nguồn không tin cậy có được truyền vào WP_Query hay không.
3. Xác định các endpoint hoặc chức năng công khai có thể kích hoạt những code path này, đặc biệt nơi plugin hoặc theme nhận tham số do người dùng cung cấp.
4. Rà soát web server, application và database logs để tìm các request bất thường hoặc dấu hiệu SQL Injection nhắm vào các chức năng liên quan. Đâ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. Nếu có nghi ngờ bị khai thác, bảo toàn log và dữ liệu liên quan để điều tra; không coi việc không thấy log bất thường là bằng chứng hệ thống an toàn.