Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
HTTP Request smugglin2.docx
Скачиваний:
8
Добавлен:
08.07.2019
Размер:
34.7 Кб
Скачать

B. Вариант атаки, требующий дополнительной вставки:

Squid (мы проверили Squid 2.4stable7, 2.5stable4 и 2.5stable5 для NT) воспринимает CRLF SP CRLF как продолжение заголовка. Однако Squid также проверяет HTTP заголовок на наличие символа “:” (иначе, запрос полностью отвергается). Следовательно, строка, которая сразу же следует за CRLF SP CRLF, должна содержать двоеточие. Однако IIS/5.0 проверяет наличие символа “:” после CRLF SP CRLF и, если таковой находится, IIS/5.0 считает, что это строка является строкой заголовка (т.е. IIS/5.0 не заканчивает секцию заголовков). Поэтому в этом методе в строку добавляются произвольные данные (6000 байт), следующие за символом “:”. Тем самым, заставляя Squid рассматривать ее как строку заголовка, а IIS/5.0 рассматривает ее как новый запрос.

Например:

1 GET http://SITE/static_foobar.asp HTTP/1.0 2 Foo: bar 3 [SP] 4 GET /poison.html?AAAAA … [6000 times]… AAAA: HTTP/1.0 5 Connection: Keep-Alive 6 7 GET http://SITE/page_to_poison.html HTTP/1.0 8

Squid отправляет строки 1-6 веб-серверу (IIS) как простой запрос. Запомните, что строка 4 является правильным заголовком для Squid, так как она содержит символ двоеточие. IIS рассматривает полученные данные как два запроса. Строки 1-3 как первый запрос, заканчивающийся последовательностью CRLF SP CRLF (в интерпретации ISS, несколько тысяч байт справа от CRLF SP CRLF не содержат символ двоеточие). Этот запрос обрабатывается IIS, и ответ возвращается Squid. Затем Squid отправляет строки 7-8, но IIS отсылает обратно ответ на строки 4-6. Следовательно, Squid получает контент /poison.html на запрос с URL /page_to_poison.html.

Но есть несколько тонких моментов:

  • Последовательности запросов этой атаки должен предшествовать запрос на произвольный ресурс с заголовком Connection:Keep-Alive. Этот заголовок укажет IIS, что соединение устойчивое. Бесполезно будет добавлять этот заголовок к первому запросу (например, между 1 и 2 строками), потому что Squid переупорядочивает заголовки и отсылает заголовок Connection среди последних (т.е. после 4 строки). В этом случае IIS увидит первый запрос при новом TCP соединении без заголовка Connection:Keep-Alive и решит, что соединение неустойчивое. А это прервет атаку.

  • Присутствуют также некоторые ограничения в последовательности. Squid увидит второй ответ IIS только после отправки того, что он интерпретировал как второй запрос (строки 7-8). Следовательно, эта атака нуждается в повторении несколько раз, пока событие не произойдет в необходимой последовательности.

6. Преждевременное завершение запросов, чья длина тела превышает 48 kb

Как ясно из заголовка, IIS/5.0 в некоторых случаях ведет себя очень интересно. Так, запрос с большим (>48KB) телом (например, POST с корректным телом и заголовком Content-Length, показывающим длину этого тела), но без заголовка Content-Type будет воспринят как запрос, чей размер тела равен 48 KB (49152). После 49152 байт IIS/5.0 прервет запрос и начнет обрабатывать новый запрос. Это позволяет очень легко провести атаку, так как такое поведение нестандартно и не соответствует RFC.

Мы проведем атаку отравления кеша Squid (2.5stable5 для NT), Apache 2.0.45 и ISA/2000. Мы также обойдем защиту FW-1.

Пример атаки (отравление кеша):

1 POST http://SITE/dynamic_foobar.asp HTTP/1.1 2 Host: SITE 3 Connection: keep-alive 4 Content-Length: 49181 5 6 AAAAA … AAAA[49150 times] 7 GET /poison.html HTTP/1.0 8 9 GET http://SITE/page_to_poison.html HTTP/1.1 10 Host: SITE 11

Кеш сервер отправит веб-серверу строки 1-8. Заметьте, что значение Content-Length (строка 4) включает как раз необходимую подстановку в строке 6 (49150 байт), плюс CRLF в конце 6 строки, плюс 7 и 8 строки (каждая с CRLF). IIS/5.0 прочитает строки 1-6 как первый запрос (тело завершится после 49152 байта и как раз попадет на начало 7 строки), затем перейдет ко второму запросу (строки 7-8). Затем он отправит ответ на первый запрос кеш серверу. После этого кеш сервер отправит второй запрос (/page_to_poison.html) - строки 9-11. IIS/5.0 обработает второй запрос (строки 7-8) и отправит обратно контент /poison.html. Кеш сервер получит контент /poison.html на запрос на/page_to_poison.html.

Пример (обход защиты FW-1):

1 POST /dynamic_page1.asp HTTP/1.1 2 Host: SITE 3 Connection: keep-alive 4 Content-Length: 49230 5 6 AAAAA … AAAA[49150 times] 7 POST /dynamic_page2.asp HTTP/1.0 8 Connection: Keep-Alive 9 Content-Length: 35 10 11 POST /dynamic_page3 HTTP/1.0 12 Bla: GET /malicious_url HTTP/1.0 13 14 GET /some_page HTTP/1.0 15

FW-1 отправит первый запрос (строки 1-10) IIS/5.0. Сервер прочитает строки 1-6 как первый полный запрос. Затем он отправит ответ обратно FW-1. Далее он прочитает строки 7-10 как второй неполный запрос (тело еще не передано).

FW-1 вернет ответ от IIS обратно атакующему и отправит строки 11-13 в качестве второго запроса. Заметьте, что злонамеренные данные в 12 строке являются частью HTTP заголовка (так их воспримет FW-1), и поэтому они не приведут к срабатыванию механизмов обнаружения/защиты у FW-1.

IIS/5.0 получит строку 11 и первые 5 байт 12 строки как тело второго запроса и ответит на второй запрос. FW-1 получит этот ответ и отошлет третий запрос IIS/5.0 - строки 11-15. IIS/5.0 отправит ответ на третий запрос (строки 12-13), который является результатом запроса на /malicious_url.

Заключение: Мы увидели, что многие пары программ (прокси/файрвол сервера и веб-сервера) являются уязвимыми. Уязвимыми являются следующие пары:

  • PCCA

    • IIS/5.0

    • Tomcat 5.0.19 (probably with Tomcat 4.1.x as well)

  • Squid 2.5stable4 (Unix) и Squid 2.5stable5 для NT

    • IIS/5.0

    • WebLogic 8.1 SP1

  • Apache 2.0.45

    • IIS/5.0

    • IS/6.0

    • Apache 1.3.29

    • Apache 2.0.45

    • WebSphere 5.1 и 5.0

    • WebLogic 8.1 SP1

    • Oracle9iAS web server 9.0.2

    • SunONE web server 6.1 SP4

  • ISA/2000

    • IIS/5.0

    • Tomcat 5.0.19

    • Tomcat 4.1.24

    • SunONE web server 6.1 SP4

  • DeleGate 8.9.2

    • IIS/6.0

    • Tomcat 5.0.19

    • Tomcat 4.1.24

    • SunONE web server 6.1 SP4

  • Oracle9iAS cache server 9.0.2

    • WebLogic 8.1 SP1

  • SunONE proxy server 3.6 SP4

    • Tomcat 5.0.19

    • Tomcat 4.1.24

    • SunONE web server 6.1 SP4

  • FW-1 Web Intelligence kernel 55W beta

    • IIS/5.0

Это частичный список. Многие пары мы не протестировали. Также существуют множество других веб- и кеш серверов, которые мы не изучили. Также очень вероятно, что существуют еще множество подобных техник.

Защита Вашего сайта от HRS

Как сайт может защитить себя от HRS? Установка программного файрвола может помочь, но как мы показали на примере FW-1, защиты некоторых файрволов могут быть обойдены (узнайте у поставщика вашего файрвола, защищают ли его продукты от подобных атак).

Другое решение - это использовать те веб-сервера, которые используют очень точные парсеры HTTP, как, например, Apache (он подвержен лишь некоторым видам HRS только тогда, когда используется и как веб-сервер, и как кеш сервер).

Другие не очень практичные методы - это использовать SSL соединения (https вместо http), завершать клиентскую сессию после каждого запроса или сделать все страницы некешируемыми (для защиты от отравления кеша).

Так для некоторых продуктов, упомянутых выше, мы можем дать специальные патчи и конфигурационную информацию:

Squid

Для устранения описанных выше уязвимостей в Squid выпущены патчи, которые распространяются среди поставщиков продуктов Squid.

http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE7-header_parsing http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE7-response_splitting http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE8-relaxed_header_parser

Рекомендованная версия: Squid-2.5.STABLE9.

Также советуем отключить для Squid устойчивые соединения:

client_persistent_connection off server_persistent_connection off

Завершение

Единственным способом полностью обезопаситься от HRS - это сделать так, чтобы все HTTP устройства точно придерживались процесса обработки HTTP. Но, к сожалению, это вряд ли произойдет в ближайшем будущем.

Ссылки

[1] A. Klein, “Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics.” Sanctum White Paper, March 2004.http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf [2] 3APA3A, “Bypassing Content Filtering Whitepaper,” February 2002 (original paper date. The paper was last revised August 2004). http://www.security.nnov.ru/advisories/content.asp [3] Rain Forest Puppy, “A look at whisker’s anti-IDS tactics,” December 1999.http://www.ussrback.com/docs/papers/IDS/whiskerids.html [4] J. Gettys, R. Fielding, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext Transfer Protocol - HTTP/1.1.” RFC 2616, June 1999. http://www.w3.org/Protocols/rfc2616/rfc2616 [5] J. Grossman, “Cross Site Tracing (XST).” WhiteHat Security White Paper, January 2003.http://www.cgisecurity.net/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf [6] P. Watkins, “Cross Site Request Forgeries (CSRF),” BugTraq posting, June 2001.http://www.securityfocus.com/archive/1/191390 [7] “CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests.” February 2000.http://www.cert.org/advisories/CA-2000-02.html [8] A. Klein, “Cross Site Scripting Explained.” Sanctum White Paper, May 2002.http://crypto.stanford.edu/cs155/CSS.pdf

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]