Rate this post

Phần này minh họa các ví dụ về các cuộc tấn công tận dụng các tính năng cụ thể của giao thức HTTP, bằng cách khai thác các điểm yếu của ứng dụng web hoặc đặc thù theo cách các tác nhân khác nhau diễn giải thông điệp HTTP. Phần này sẽ phân tích hai cuộc tấn công khác nhau nhắm vào các tiêu đề HTTP cụ thể:

  • HTTP splitting
  • HTTP smuggling

Cuộc tấn công đầu tiên khai thác sự thiếu lọc giá trị đầu vào cho phép kẻ xâm nhập chèn các ký tự CR và LF vào tiêu đề của phản hồi ứng dụng và ‘tách’ câu trả lời đó thành hai thông báo HTTP khác nhau. Mục tiêu của cuộc tấn công có thể khác nhau, từ nhiễm độc bộ nhớ cache cross site scripting.

Các bài viết liên quan:

Trong cuộc tấn công thứ hai, kẻ tấn công khai thác thực tế rằng một số thông điệp HTTP được tạo đặc biệt có thể được phân tích cú pháp và diễn giải theo những cách khác nhau tùy thuộc vào tác nhân nhận chúng. Việc nhập lậu HTTP yêu cầu một số kiến ​​thức về các tác nhân khác nhau đang xử lý các thông báo HTTP (máy chủ web, proxy, tường lửa) và do đó sẽ chỉ được đưa vào phần kiểm tra hộp xám.

Mục tiêu kiểm tra

Đánh giá xem ứng dụng có dễ bị chia tách hay không, xác định những cuộc tấn công có thể xảy ra.

Đánh giá xem chuỗi thông tin liên lạc có dễ bị buôn lậu hay không, xác định xem có thể thực hiện được những cuộc tấn công nào không.

Làm thế nào để kiểm tra

Blackbox testing

HTTP splitting

Một số ứng dụng web sử dụng một phần đầu vào của người dùng để tạo giá trị của một số tiêu đề trong phản hồi của họ. Ví dụ đơn giản nhất được cung cấp bởi chuyển hướng trong đó URL mục tiêu phụ thuộc vào một số giá trị do người dùng gửi. Ví dụ, giả sử người dùng được yêu cầu chọn xem họ thích giao diện web tiêu chuẩn hay nâng cao. Lựa chọn sẽ được chuyển dưới dạng một tham số sẽ được sử dụng trong tiêu đề phản hồi để kích hoạt chuyển hướng đến trang tương ứng.

Cụ thể hơn, nếu tham số ‘interface’ có giá trị ‘advanced’, ứng dụng sẽ trả lời như sau:

HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
<snip>

Khi nhận được thông báo này, trình duyệt sẽ đưa người dùng đến trang được chỉ định trong tiêu đề Vị trí. Tuy nhiên, nếu ứng dụng không lọc đầu vào của người dùng, có thể chèn vào tham số ‘giao diện’ chuỗi% 0d% 0a, đại diện cho chuỗi CRLF được sử dụng để phân tách các dòng khác nhau. Tại thời điểm này, người kiểm tra sẽ có thể kích hoạt một phản hồi sẽ được hiểu là hai phản hồi khác nhau bởi bất kỳ ai tình cờ phân tích cú pháp nó, ví dụ như một bộ đệm web nằm giữa chúng tôi và ứng dụng. Điều này có thể bị kẻ tấn công lợi dụng để đầu độc bộ nhớ cache web này để nó cung cấp nội dung sai trong tất cả các yêu cầu tiếp theo.

Giả sử trong ví dụ trước, người kiểm tra chuyển dữ liệu sau làm tham số giao diện:

advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>

Do đó, câu trả lời từ ứng dụng dễ bị tấn công sẽ như sau:

HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35

<html>Sorry,%20System%20Down</html>
<other data>

Bộ nhớ cache web sẽ thấy hai phản hồi khác nhau, vì vậy nếu kẻ tấn công gửi, ngay sau yêu cầu đầu tiên, yêu cầu thứ hai yêu cầu /index.html, bộ nhớ cache web sẽ khớp yêu cầu này với phản hồi thứ hai và lưu vào bộ nhớ cache nội dung của nó, để tất cả các yêu cầu tiếp theo được chuyển hướng đến nạn nhân.com/index.html đi qua bộ đệm web đó sẽ nhận được thông báo “hệ thống ngừng hoạt động”. Bằng cách này, kẻ tấn công sẽ có thể khử bề mặt trang web một cách hiệu quả đối với tất cả người dùng sử dụng bộ đệm ẩn web đó (toàn bộ Internet, nếu bộ đệm ẩn web là proxy ngược cho ứng dụng web).

Ngoài ra, kẻ tấn công có thể chuyển cho những người dùng đó một đoạn mã JavaScript gắn một cuộc tấn công tập lệnh trên nhiều trang web, ví dụ: để đánh cắp cookie. Lưu ý rằng mặc dù lỗ hổng bảo mật nằm trong ứng dụng, nhưng mục tiêu ở đây là người dùng của nó. Do đó, để tìm kiếm lỗ hổng này, người kiểm tra cần xác định tất cả đầu vào do người dùng kiểm soát có ảnh hưởng đến một hoặc nhiều tiêu đề trong phản hồi và kiểm tra xem họ có thể đưa chuỗi CR + LF vào đó thành công hay không.

Các tiêu đề có nhiều khả năng là ứng cử viên cho cuộc tấn công này là:

  • Location
  • Set-Cookie

Cần lưu ý rằng việc khai thác thành công lỗ hổng này trong một kịch bản thế giới thực có thể khá phức tạp, vì một số yếu tố phải được tính đến:

  • Người kiểm tra bút phải đặt đúng tiêu đề trong phản hồi giả để nó được lưu vào bộ nhớ đệm thành công (ví dụ: tiêu đề Được sửa đổi lần cuối với ngày được đặt trong tương lai). Họ cũng có thể phải hủy các phiên bản đã lưu trong bộ nhớ cache trước đó của máy nhắn tin mục tiêu, bằng cách đưa ra yêu cầu sơ bộ với Pragma: no-cache trong tiêu đề yêu cầu
  • Ứng dụng, trong khi không lọc chuỗi CR + LF, có thể lọc các ký tự cần thiết cho một cuộc tấn công thành công (ví dụ: <và>). Trong trường hợp này, người thử nghiệm có thể thử sử dụng các mã hóa khác (ví dụ: UTF-7)
  • Một số mục tiêu (ví dụ: ASP) sẽ mã hóa URL phần đường dẫn của tiêu đề Vị trí (ví dụ: www.victim.com/redirect.asp), làm cho chuỗi CRLF trở nên vô dụng. Tuy nhiên, chúng không mã hóa được phần truy vấn (ví dụ:? Interface = advanced), có nghĩa là dấu chấm hỏi ở đầu là đủ để bỏ qua bộ lọc này

Để có thảo luận chi tiết hơn về cuộc tấn công này và thông tin khác về các kịch bản và ứng dụng có thể xảy ra, hãy kiểm tra các tài liệu tham khảo ở cuối phần này.

Gray Box testing

HTTP splitting

Việc khai thác thành công HTTP Splitting được giúp đỡ rất nhiều khi biết một số thông tin chi tiết về ứng dụng web và mục tiêu tấn công. Ví dụ: các mục tiêu khác nhau có thể sử dụng các phương pháp khác nhau để quyết định khi nào thông báo HTTP đầu tiên kết thúc và khi nào thông báo thứ hai bắt đầu. Một số sẽ sử dụng các ranh giới tin nhắn, như trong ví dụ trước. Các mục tiêu khác sẽ giả định rằng các thông điệp khác nhau sẽ được thực hiện bởi các gói tin khác nhau. Những người khác sẽ phân bổ cho mỗi tin nhắn một số đoạn có độ dài xác định trước: trong trường hợp này, tin nhắn thứ hai sẽ phải bắt đầu chính xác ở phần đầu của một đoạn và điều này sẽ yêu cầu người kiểm tra sử dụng đệm giữa hai tin nhắn. Điều này có thể gây ra một số rắc rối khi tham số dễ bị tấn công được gửi trong URL, vì một URL rất dài có thể bị cắt bớt hoặc bị lọc. Một tình huống hộp xám có thể giúp kẻ tấn công tìm ra cách giải quyết: ví dụ: một số máy chủ ứng dụng sẽ cho phép gửi yêu cầu bằng POST thay vì GET.

HTTP Smuggling

Như đã đề cập trong phần giới thiệu, HTTP Smuggling tận dụng các cách khác nhau mà một thông điệp HTTP được chế tạo đặc biệt có thể được phân tích cú pháp và diễn giải bởi các tác nhân khác nhau (trình duyệt, bộ đệm web, tường lửa ứng dụng). Kiểu tấn công tương đối mới này lần đầu tiên được phát hiện bởi Chaim Linhart, Amit Klein, Ronen Heled và Steve Orrin vào năm 2005. Có một số ứng dụng có thể xảy ra và chúng tôi sẽ phân tích một trong những cách ngoạn mục nhất: vượt tường lửa ứng dụng. Tham khảo whitepaper ban đầu (được liên kết ở cuối trang này) để biết thêm thông tin chi tiết và các tình huống khác.

Bỏ qua tường lửa ứng dụng

Có một số sản phẩm cho phép quản trị hệ thống phát hiện và chặn một yêu cầu web thù địch tùy thuộc vào một số mẫu độc hại đã biết được nhúng trong yêu cầu. Ví dụ: hãy xem xét cuộc tấn công truyền qua thư mục Unicode cũ, khét tiếng chống lại máy chủ IIS, trong đó kẻ tấn công có thể phá mã gốc www bằng cách đưa ra một yêu cầu như:

http: //target/scripts/..%c1%1c../winnt/system32/cmd.exe? / c + <command_to_execute>

Tất nhiên, khá dễ dàng để phát hiện và lọc cuộc tấn công này bởi sự hiện diện của các chuỗi như “..” và “cmd.exe” trong URL. Tuy nhiên, IIS 5.0 khá kén chọn các yêu cầu POST có nội dung lên đến 48K byte và cắt bớt tất cả nội dung vượt quá giới hạn này khi tiêu đề Content-Type khác với application / x-www-form-urlencoded. Người kiểm tra bút có thể tận dụng điều này bằng cách tạo ra một yêu cầu rất lớn, có cấu trúc như sau:

POST /target.asp HTTP/1.1        <-- Request #1
Host: target
Connection: Keep-Alive
Content-Length: 49225
<CRLF>
<49152 bytes of garbage>
POST /target.asp HTTP/1.0        <-- Request #2
Connection: Keep-Alive
Content-Length: 33
<CRLF>
POST /target.asp HTTP/1.0        <-- Request #3
xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0   <-- Request #4
Connection: Keep-Alive
<CRLF>

Điều xảy ra ở đây là Yêu cầu số 1 được tạo bởi 49223 byte, bao gồm cả các dòng của Yêu cầu số 2. Do đó, tường lửa (hoặc bất kỳ tác nhân nào khác bên cạnh IIS 5.0) sẽ thấy Yêu cầu số 1, sẽ không thấy Yêu cầu số 2 (dữ liệu của nó sẽ chỉ là một phần của số 1), sẽ thấy Yêu cầu số 3 và bỏ lỡ Yêu cầu số 4 (vì POST sẽ chỉ là một phần của tiêu đề giả xxxx).

Bây giờ, điều gì sẽ xảy ra với IIS 5.0? Nó sẽ ngừng phân tích cú pháp Yêu cầu số 1 ngay sau 49152 byte rác (vì nó sẽ đạt đến giới hạn 48K = 49152 byte) và do đó sẽ phân tích cú pháp Yêu cầu số 2 như một yêu cầu mới, riêng biệt. Yêu cầu số 2 tuyên bố rằng nội dung của nó là 33 byte, bao gồm mọi thứ cho đến “xxxx:”, khiến IIS bỏ lỡ Yêu cầu số 3 (được hiểu là một phần của Yêu cầu số 2) nhưng lại phát hiện Yêu cầu số 4, vì BÀI ĐĂNG của nó bắt đầu ngay sau byte thứ 33 hoặc Yêu cầu số 2. Nó hơi phức tạp một chút, nhưng điểm mấu chốt là URL tấn công sẽ không bị tường lửa phát hiện (nó sẽ được hiểu là phần thân của một yêu cầu trước đó) nhưng sẽ được phân tích cú pháp chính xác (và thực thi) bởi IIS.

Trong trường hợp nói trên, kỹ thuật này khai thác một lỗi của máy chủ web, có những tình huống khác mà chúng ta có thể tận dụng các cách khác nhau mà các thiết bị hỗ trợ HTTP khác nhau phân tích cú pháp các thông báo không tuân thủ 1005 RFC. Ví dụ: giao thức HTTP chỉ cho phép một tiêu đề Độ dài Nội dung, nhưng không chỉ định cách xử lý một thông báo có hai phiên bản của tiêu đề này. Một số triển khai sẽ sử dụng cái đầu tiên trong khi những cái khác sẽ thích cái thứ hai, ở đường cho các cuộc tấn công HTTP Smuggling. Một ví dụ khác là việc sử dụng tiêu đề Độ dài Nội dung trong thông báo GET.

Lưu ý rằng HTTP Smuggling * không * khai thác bất kỳ lỗ hổng nào trong ứng dụng web mục tiêu. Do đó, có thể hơi phức tạp, trong một cuộc thử nghiệm bằng bút, để thuyết phục khách hàng rằng dù thế nào cũng nên tìm kiếm một biện pháp đối phó.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now