Lỗi phân tích query_string trong OpenSearch cho phép gây từ chối dịch vụ

Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp

Lỗ hổng CVE-2025-9624 là gì?

Lỗ hổng CVE-2025-9624 là lỗ hổng Uncontrolled Recursion ảnh hưởng tới OpenSearch (phiên bản bị ảnh hưởng: 3.0.0 – < 3.3.0 và 1.0.0 – < 2.19.4). Lỗ hổng này được xếp hạng ở mức Cao, với điểm CVSS 8.3. Lỗ hổng này đã có mã hoặc bằng chứng khai thác công khai, nhưng điều đó chưa xác nhận việc khai thác trong thực tế.

Giới thiệu chung

Dữ liệu gốc

Một lỗ hổng trong OpenSearch cho phép kẻ tấn công gây Từ chối dịch vụ (DoS) bằng cách gửi các đầu vào query_string phức tạp. Vấn đề này ảnh hưởng đến mọi phiên bản OpenSearch trong khoảng từ 3.0.0 đến < 3.3.0 và OpenSearch < 2.19.4.

Sản phẩm và phạm vi ảnh hưởng

  • OpenSearch: bị ảnh hưởng từ 3.0.0 đến trước 3.3.0.
  • OpenSearch: theo dữ liệu affected chuẩn hóa, bị ảnh hưởng từ 1.0.0 đến trước 2.19.4. Trang CNA diễn đạt nhánh này là các phiên bản < 2.19.4.
  • Gói liên quan: GitHub Advisory Database xác định gói Maven org.opensearch:opensearch-common.
  • Bản sửa lỗi: CNA và các release note được cung cấp xác định 3.3.0 và 2.19.4 là các bản sửa tương ứng cho hai nhánh.
  • Không có bằng chứng được cung cấp để kết luận các nhánh song song hoặc các phiên bản khác ngoài các phạm vi trên là bị ảnh hưởng hay không bị ảnh hưởng.

Chi tiết kỹ thuật

OpenSearch phân tích đầu vào query_string thành cây truy vấn gồm các nhóm Boolean lồng nhau và các phép hợp không phải Boolean. Giới hạn indices.query.bool.max_clause_count chỉ được áp dụng cho từng nút BooleanQuery, không giới hạn tổng số nút trong toàn bộ cây truy vấn. Ngoài ra, các cấu trúc DisjunctionMaxQuery được tạo trong quá trình xử lý nhiều trường không bị giới hạn bởi giới hạn mệnh đề Boolean tương ứng. Vì vậy, đầu vào do kẻ tấn công kiểm soát có thể giữ số mệnh đề của từng nút dưới ngưỡng nhưng vẫn làm tăng rất lớn kích thước cây, dẫn đến tiêu thụ quá mức CPU và heap. Các đường xử lý liên quan gồm QueryStringQueryParser, MultiMatchQuery, SearchService và cơ chế giới hạn của Lucene. Điều kiện tiếp cận cụ thể phụ thuộc vào việc triển khai có cho client không tin cậy gửi truy vấn query_string hay không; hồ sơ hiện có không xác định chi tiết cấu hình xác thực của từng triển khai.

Khả năng khai thác

  • Khả năng tiếp cận: Lỗ hổng có thể bị khai thác từ xa qua mạng khi client có thể gửi truy vấn query_string đến OpenSearch.
  • Điều kiện: Tài liệu CNA mô tả việc gửi các truy vấn phức tạp với nhóm lồng nhau và phép hợp nhiều trường. Không cần tương tác của người dùng khác được ghi nhận trong dữ liệu chấm điểm được cung cấp.
  • Xác thực: Các dữ liệu chấm điểm không thống nhất về yêu cầu đặc quyền: một bản ghi yêu cầu đặc quyền thấp, trong khi bản ghi khác ghi nhận không yêu cầu đặc quyền. CNA mô tả điều kiện tổng quát là client không tin cậy có thể gửi truy vấn.
  • Độ phức tạp: Dữ liệu được cung cấp mô tả độ phức tạp khai thác thấp.
  • Tình trạng công khai: Bản ghi chuẩn hóa đánh dấu có public exploit, nhưng trang CNA ghi Exploit available là No. Tuy vậy, CNA công khai các mẫu PoC và một minh chứng trong đó OpenSearch kết thúc với mã 137. Điều này xác nhận có tài liệu kỹ thuật công khai, nhưng không xác nhận việc khai thác đang diễn ra ngoài thực tế.

Tác động kỹ thuật

Khi bị kích hoạt, lỗi có thể làm cây truy vấn tăng kích thước vượt xa giới hạn dự kiến, dẫn đến bão hòa CPU và tiêu thụ heap quá mức. Kết quả kỹ thuật chính là suy giảm hoặc mất tính sẵn sàng của OpenSearch và các chức năng phụ thuộc vào nó. Dữ liệu chấm điểm được cung cấp không ghi nhận tác động đến tính bí mật hoặc tính toàn vẹn, nhưng tác động đến dịch vụ có thể lan sang các ứng dụng dùng OpenSearch nếu tài nguyên chung bị cạn kiệt. Mức đặc quyền cần thiết chưa được xác định nhất quán giữa các bản ghi, nên phạm vi client có thể khai thác cần được đánh giá theo cấu hình thực tế.

Tác động đến tổ chức

  • Sẵn sàng dịch vụ: Một yêu cầu được tạo đặc biệt có thể làm OpenSearch sử dụng nhiều CPU và heap, khiến các truy vấn hợp lệ bị chậm hoặc thất bại.
  • Ảnh hưởng vận hành: Nếu tài nguyên bị cạn kiệt, node hoặc dịch vụ OpenSearch có thể bị gián đoạn, khởi động lại hoặc cần can thiệp vận hành. Đây là hậu quả có thể xảy ra, không phải kết quả được bảo đảm cho mọi cấu hình.
  • Hệ thống phụ thuộc: Các ứng dụng dựa vào OpenSearch cho tìm kiếm, phân tích hoặc truy xuất dữ liệu có thể bị ảnh hưởng về thời gian đáp ứng và tính sẵn sàng.
  • Phạm vi tác động: Dữ liệu được cung cấp tập trung vào tính sẵn sàng và không ghi nhận tác động trực tiếp đến tính bí mật hoặc tính toàn vẹn.

Cách khắc phục

  1. Nâng cấp các triển khai thuộc nhánh từ 3.0.0 đến trước 3.3.0 lên 3.3.0.
  2. Nâng cấp các triển khai thuộc nhánh từ 1.0.0 đến trước 2.19.4 lên 2.19.4.
  3. Kiểm tra cả runtime node, image hoặc package manager và dependency tree để bảo đảm mọi thành phần OpenSearch thực tế đã được nâng cấp, không chỉ máy quản trị hoặc một node riêng lẻ.
  4. Nếu chưa thể nâng cấp ngay, hạn chế tạm thời khả năng để client không tin cậy gửi các truy vấn query_string phức tạp và theo dõi sát mức sử dụng CPU, heap cùng trạng thái dịch vụ. Đây chỉ là biện pháp giảm rủi ro tạm thời; nguồn được cung cấp không xác nhận một workaround độc lập thay thế cho nâng cấp.

Cách phát hiện

  1. Lập danh sách toàn bộ node OpenSearch, image container, gói Maven và bản phân phối được triển khai; đối chiếu từng bản với các nhánh bị ảnh hưởng và bản sửa lỗi trong hồ sơ.
  2. Xác định các endpoint, ứng dụng hoặc tenant cho phép client gửi truy vấn query_string, đặc biệt khi nguồn gửi không hoàn toàn tin cậy.
  3. Rà soát audit log và request log để tìm các yêu cầu query_string bất thường về độ dài, số lượng nhóm lồng nhau hoặc số lượng phép hợp nhiều trường. Đây là biện pháp phát hiện phòng ngừa, không phải IOC được CNA xác nhận.
  4. Đối chiếu các yêu cầu bất thường với hiện tượng CPU tăng cao, heap pressure, lỗi truy vấn, thời gian phản hồi tăng hoặc tiến trình OpenSearch kết thúc với mã 137. Các dấu hiệu này chỉ là chỉ báo vận hành được mô tả trong tài liệu, không phải bằng chứng duy nhất để kết luận bị khai thác.
  5. Sau khi nâng cấp, kiểm tra lại phiên bản thực tế trên mọi node và dependency tree của các gói Java liên quan. Việc không thấy dấu hiệu trên không chứng minh hệ thống an toàn.
Nguồn (13)
Tìm hiểu thêm

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.