Rapid Reset gây từ chối dịch vụ trên sản phẩm Siemens và các triển khai HTTP/2

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

Giới thiệu chung

Dữ liệu gốc

Giao thức HTTP/2 cho phép từ chối dịch vụ (tiêu thụ tài nguyên máy chủ) vì việc hủy yêu cầu có thể nhanh chóng đặt lại nhiều stream, như đã bị khai thác trong thực tế từ tháng 8 đến tháng 10 năm 2023.

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

  • Giao thức HTTP/2 phiên bản 2.0 được đánh dấu bị ảnh hưởng.
  • Siemens: bản ghi liệt kê SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP firmware, SIMATIC S7-1500 CPU 1518-4 PN/DP MFP firmware, SIPLUS S7-1500 CPU 1518-4 PN/DP MFP firmware, RUGGEDCOM APE1808 firmware, SINEC NMS, SINEC INS và ST7 SCADACONNECT. Dữ liệu affected bổ sung dùng các ranh giới 0 < * cho RUGGEDCOM APE1808, V3.1.5 < * cho các dòng CPU được nêu và 0 < V3.0 cho SINEC NMS. SINEC INS 1.0 cùng các biến thể service pack được đánh dấu affected. Ký hiệu ranh giới được giữ nguyên vì bản ghi không cung cấp cách diễn giải vendor đầy đủ cho từng dòng.
  • Envoy: các phiên bản 1.24.10, 1.25.9, 1.26.4 và 1.27.0 được đánh dấu affected.
  • F5 BIG-IP: bản ghi đánh dấu affected cho Access Policy Manager, Advanced Firewall Manager, Advanced Web Application Firewall, Analytics, Application Acceleration Manager, Application Security Manager, Application Visibility and Reporting, Carrier-Grade NAT, DDoS Hybrid Defender, Domain Name System, Fraud Protection Service, Global Traffic Manager, Link Controller và Local Traffic Manager. Các mục này bao gồm các entry không có ranh giới phiên bản và entry 17.1.0.
  • nghttp2, Netty, Eclipse Jetty, Caddy, Go, http2 và networking của Go được đánh dấu affected nhưng bản ghi chuẩn hóa không cung cấp ranh giới phiên bản đầy đủ cho các mục này.

Chi tiết kỹ thuật

HTTP/2 cho phép client hủy từng stream bằng frame RST_STREAM mà không cần đóng kết nối. Trong tấn công Rapid Reset, client gửi request rồi lập tức gửi RST_STREAM; server hoặc reverse proxy có thể đã cấp phát cấu trúc stream, phân tích header, giải nén header, định tuyến URL hoặc chuyển request tới backend trước khi việc hủy được xử lý. Việc lặp lại nhanh chóng cho phép tạo stream mới mà không vượt giới hạn số stream đang mở, trong khi công việc xử lý ở phía server vẫn tích lũy và có thể vượt xa chi phí của kẻ tấn công. Điều kiện khai thác là một dịch vụ có thể nhận HTTP/2 từ mạng không tin cậy; bản ghi cho biết không cần xác thực và không cần tương tác người dùng. Chi tiết triển khai và mức tiêu thụ tài nguyên khác nhau theo từng sản phẩm, nên không nên giả định mọi sản phẩm dùng cùng một đường mã.

Khả năng khai thác

Lỗ hổng có thể bị khai thác từ xa qua mạng HTTP/2, không yêu cầu xác thực, không yêu cầu tương tác người dùng và có độ phức tạp thấp. Mô tả bản ghi cho biết kỹ thuật này đã bị khai thác trong thực tế từ tháng 8 đến tháng 10 năm 2023. Bản ghi cũng đánh dấu trạng thái đã bị khai thác và có public exploit. Bằng chứng hiện có không nêu một chiến dịch, nạn nhân hoặc nhóm tấn công cụ thể. Kết quả được mô tả là từ chối dịch vụ và tiêu thụ tài nguyên, không phải truy cập dữ liệu hoặc thay đổi dữ liệu.

Tác động kỹ thuật

  • Tác động chính là mất tính sẵn sàng do server phải xử lý nhiều request đã bị hủy và tiêu tốn tài nguyên cho mỗi stream.
  • Kết nối HTTP/2 vẫn có thể được giữ mở trong khi attacker liên tục tạo và hủy stream, cho phép một kết nối tạo ra lượng công việc lớn hơn mức giới hạn stream đang mở thông thường.
  • Hệ quả thực tế có thể gồm CPU hoặc bộ nhớ tăng cao, backlog request, độ trễ tăng, lỗi dịch vụ và ngắt kết nối; nếu có reverse proxy, tải có thể lan tới backend.
  • Bản ghi mô tả không có tác động đến tính bí mật hoặc tính toàn vẹn, và không thiết lập khả năng nâng quyền, thực thi mã hoặc truy cập dữ liệu.
  • Mức độ ảnh hưởng phụ thuộc vào việc sản phẩm có nhận HTTP/2 từ mạng không tin cậy, cách xử lý request bị hủy và khả năng áp dụng giới hạn hoặc đóng kết nối.

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

  • Có thể gây tăng CPU, bộ nhớ, số lượng công việc đang xử lý và hàng đợi request trên server hoặc reverse proxy.
  • Dịch vụ web, API, gateway, proxy hoặc giao diện quản trị có thể bị tăng độ trễ, đóng kết nối, lỗi request hoặc mất khả dụng.
  • Nếu một thành phần HTTP/2 chuyển request tới backend trước khi nhận biết việc hủy, tải xử lý có thể lan sang hệ thống phía sau và làm suy giảm nhiều tầng dịch vụ.
  • Với các sản phẩm công nghiệp bị ảnh hưởng, việc mất khả dụng của giao diện quản trị hoặc giám sát là hậu quả có thể xảy ra nếu giao diện đó nhận HTTP/2 từ mạng không tin cậy.
  • Bằng chứng không xác lập việc lộ dữ liệu, sửa đổi dữ liệu, chiếm quyền hoặc một kịch bản xâm nhập cụ thể.

Cách khắc phục

  1. Cập nhật từng sản phẩm hoặc dependency bằng bản sửa chính thức của vendor, ưu tiên các endpoint HTTP/2 công khai và các thiết bị hoặc gateway ở biên mạng. Không dùng bản sửa của một dự án để suy ra rằng nhánh hoặc sản phẩm song song đã an toàn.
  2. Với nghttp2, bản phát hành v1.57.0 được nguồn dự án ghi rõ là sửa vấn đề này. Với Envoy, Netty, Go, Caddy, Eclipse Jetty, F5 và Siemens, hãy dùng bản cập nhật vendor có chứa biện pháp chống Rapid Reset; bản ghi cung cấp không đủ fixed release cụ thể cho từng nhánh.
  3. Nếu chưa thể cập nhật, đặt dịch vụ sau lớp DDoS mitigation hoặc HTTP/2-aware proxy có khả năng phát hiện và giới hạn hành vi reset bất thường, đồng thời đóng các kết nối lạm dụng khi vendor hỗ trợ cơ chế đó. Đây là biện pháp giảm thiểu tạm thời, không thay thế cập nhật.
  4. Giảm khả năng tiếp cận từ mạng không tin cậy đối với listener HTTP/2 bị ảnh hưởng. Nếu không có bản vá hoặc biện pháp giảm thiểu được vendor hỗ trợ, cân nhắc loại bỏ sản phẩm khỏi luồng lưu lượng không tin cậy theo hướng dẫn của vendor.
  5. Sau khi cập nhật, kiểm tra lại phiên bản thực tế của binary, image, firmware và dependency đóng gói, rồi kiểm thử tải HTTP/2 để xác nhận cơ chế giới hạn reset không làm gián đoạn request hợp lệ.

Cách phát hiện

  1. Kiểm kê mọi web server, reverse proxy, gateway, load balancer, giao diện quản trị công nghiệp và thư viện nhận HTTP/2, bao gồm cả dependency lồng nhau.
  2. Đối chiếu vendor, sản phẩm và nhánh phát hành với danh sách bị ảnh hưởng; không coi việc một thư viện hoặc nhánh đã được sửa là bằng chứng cho các nhánh song song.
  3. Kiểm tra telemetry HTTP/2 để tìm các đợt tăng bất thường của frame RST_STREAM từ client, mẫu tạo rồi hủy stream liên tục, stream churn cao hoặc nhiều kết nối bị đóng do hành vi lạm dụng.
  4. Đối chiếu các đợt stream reset với CPU, bộ nhớ, hàng đợi request, độ trễ, lỗi 5xx và công việc phát sinh ở backend. Đây là dấu hiệu vận hành cần điều tra, không phải IOC độc lập.
  5. Evidence được cung cấp không xác lập một IOC dùng chung cho mọi sản phẩm. Việc không thấy các dấu hiệu trên không chứng minh hệ thống an toàn.
Nguồn (193)
mitre (CNA)
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.