Http Request smuggling (Часть 2)

Существуют еще несколько обнаруженных нами ошибок обработки. В большинстве случаев пара прокси/кеш/файрвол -сервер и веб-сайт может быть атакована, используя один или несколько методов HRS, но обычно для какой-то конкретной пары программ подходит только часть методов.

Ниже мы приведем список ошибок (и техник их использования), используемых для HRS, вместе с парами устройств, которые им подвержены. Заметьте, что это неполные результаты (т.к. для многих техник мы не протестировали все возможные пары программ). Это означает, что вероятно существует гораздо больше пар программ, уязвимых HRS, чем мы приведем ниже.

1. Двойной заголовок Content-Length

В данном случае ошибка очевидна - атакующий отсылает запрос с двумя заголовками Content-Length. Если кеш сервер и веб-сервер используют разные заголовки, тогда возможна HRS.

Техника hrs (Content-Length) №1

Кеш сервер использует последний заголовок Content-Length, а веб-сервер использует первый заголовок (примеры №1, №4 и №5). Следующие из исследованных кеш серверов используют последний заголовок Content-Length:

• Microsoft ISA/2000

• Sun Microsystems SunONE 3.6 SP4

Следующие из исследованных веб-серверов используют первый заголовок Content-Length:

• Jakarta Tomcat 5.0.19 (Coyote/1.1)

• Tomcat 4.1.24 (Coyote/1.0)

• Sun Microsystems SunONE web server 6.1 SP1

Все 6 комбинаций кеш серверов и веб-серверов были протестированы, и все показали уязвимость к HRS. Особый интерес вызывает комбинация прокси сервера Sun Microsystems SunONE 3.6 SP4 и веб-сервера того же поставщика - SunONE web server 6.1 SP1.

Техника hrs (Content-Length) №2

Как вариант техники №1, в случае, когда атака forward smuggling не проходит, возможна атака backward smuggling. Она возможна в случае использования популярного коммерческого кеш-приложения (чье название мы не будем раскрывать, а обозначим за PCCA) и Jakarta Tomcat 5.0.19 (Coyote/1.1). PCCA обрабатывает последний заголовок Content-Length и направляет запросы (с телом) веб-серверу, используя отдельные соединения, таким образом, делая технику №1 бесполезной. Единственным путем, которым можно обойти это препятствие, является отправка запроса без тела, то есть нужно отправить второй заголовок Content-Length со значением “0″. Веб-сервер (который использует значение второго заголовка Content-Length) решит, что этот запрос не закончен, и мы получим блокировку. Тем не менее, некоторые серверы, а именно IIS/6.0 и Tomcat пошлют ответ при запросе статичного ресурса (например: /index.html) до того, как получат полностью тело запроса. Это можно использовать для проведения backward smuggling, что мы и собираемся продемонстрировать на примере PCCA и Tomcat. Атакующему необходимо отправить первый запрос (на произвольную статичную страницу) с двумя заголовками “Content-Length”. Первый заголовок должен иметь значение длины второго запроса. Второй заголовок первого запроса должен иметь значение “0″. Второй запрос - это запрос, который определяет ресурс, чей URL будет использован для прикрытия. А третий запрос определяет ресурс, чей контент необходимо получить. В этом случае контент ресурса, определенного в третьем запросе, будет закеширован под URL ресурса, определенном во втором запросе.

Вот пример атаки (используются PCCA и Tomcat):

1 GET http://SITE/static_foobar.html HTTP/1.0 2 Content-Length: 71 3 Content-Length: 0 4 Connection: Keep-Alive 5 6 GET http://SITE/page_to_poison.html HTTP/1.0 7 Host: SITE 8 Connection: Keep-Alive 9 GET /poison.html HTTP/1.0 10

PCCA использует последний заголовок Content-Length (cтрока 3) и, следовательно, передает серверу строки 1-5. Tomcat же обрабатывает запрос, используя первый заголовок Content-Length (строка 2), и поэтому ожидает еще 71 байт. Однако, так как запрос отправлен на статичную страницу (/static_foobar.html), Tomcat также немедленно возвратит ее обратно PCCA. PCCA отправляет этот ответ атакующему и отсылает следующий запрос, полученный им из входящего потока - в данном случае, строки 6-10 (запрос на /page_to_poison.html). Получив его, Tomcat использует 71 байт (строки 6-8, но не забудьте, что PCCA отбросит http://SITE из 6 строки при отправлении запроса серверу) и поэтому видит второй запрос в виде строк 9-10. Следовательно, Tomcat отправит контент страницы/poison.html. PCCA рассмотрит это как ответ на страницу page_to_poison.html. И в результате атака успешно проведена.