neex/http2smuglОбнаруживает и эксплуатирует уязвимости контрабанды HTTP-запросов при преобразовании HTTP/2 в HTTP/1.1, используя автоматизированные методы контрабанды заголовков для выявления несоответствий анализа бэкенда.
Этот инструмент помогает обнаруживать и эксплуатировать HTTP-контрабанду запросов (HTTP request smuggling) в случаях, когда она может быть достигнута через преобразование HTTP/2 -> HTTP/1.1 фронтальным сервером.
Схема выглядит следующим образом:
Атакующий хочет найти такой запрос, который бэкенд увидит как два отдельных запроса.
Если соединение frontend<->backend по HTTP/1.1 использует keep-alive, фронтальный сервер может отправлять запросы от других пользователей по тому же соединению. Если мы сможем «отравить» соединение частичным запросом, который идет после легитимного, мы сможем перехватить запрос другого пользователя.
Другие возможные сценарии включают обход защиты фронтального сервера и перезапись данных, отравление кэша (cache poisoning) или обман кэша (cache deception).
Для получения дополнительной информации об HTTP-контрабанде запросов обратитесь к Portswigger Web Security Academy.
В HTTP/2 имена и значения всех HTTP-заголовков являются бинарными. Это означает, что технически они могут содержать дополнительные пробелы или даже символы новой строки.
RFC7540#10.3 гласит, что реализации, преобразующие HTTP/2-запросы в HTTP/1, должны учитывать ограничения на набор символов, возникающие при таком преобразовании; большинство реализаций действительно их отклоняют. Несмотря на это, мы надеемся найти такие, которые допускают такие заголовки. Они исказят преобразованный HTTP/1.1-запрос, отправляемый бэкенду.
Другой момент: некоторые недавние исправления, связанные с HTTP-контрабандой запросов, могут быть реализованы только для парсеров HTTP/1.1.
В целом, мы надеемся, что существуют реализации HTTP/2, которые не очень осведомлены о последних исследованиях по HTTP-контрабанде в HTTP/1.1 и не включают соответствующих мер защиты.
Удивительно, но да!
Мне удалось обнаружить возможность протащить заголовок с пробелом через Cloudflare, открыв дверь для контрабанды Cloudflare<->клиент (в случае, если программное обеспечение клиента Cloudflare принимает и обрезает имена заголовков). Вот блог-пост.
Есть также еще один отчет по баг-баунти, который пока не опубликован. Он использует тот факт, что пользовательское ПО не отфильтровывает символы новой строки в заголовках HTTP/2, и контрабанда происходит на 100% (я вижу запросы других пользователей).
Однако я понимаю, что такие типы уязвимостей должны быть удручающе редки: в отличие от HTTP/1.1, реализаций HTTP/2 не так много, и большинство из них созданы с учетом безопасности, поэтому отклоняют подозрительные или недопустимые заголовки.
Инструмент имеет подкоманду, которая пытается автоматически определить, уязвима ли цель для атаки HTTP-контрабанды. Алгоритм, лежащий в основе этой функции, описан в данном разделе.
Для выполнения атаки HTTP-контрабанды нам фактически нужно сначала «протащить» один заголовок (либо Content-Length, либо Transfer-Encoding). Это означает, что нам нужно отправить заголовок, который а) контролирует, где заканчивается тело запроса, и б) не обрабатывается фронтальным сервером, но обрабатывается бэкендом.
Обычно это достигается путем модификации заголовка: добавление пробелов или табуляции в конце его имени, замена значения на полуэквивалентное и т.д.
Основная идея алгоритма обнаружения уязвимости — определить, обрабатывает ли сервер протащенный заголовок так, как если бы он был Content-Length или Transfer-Encoding. Это делается путем отправки нескольких запросов: одни с допустимыми, другие с недопустимыми значениями для этого заголовка. Затем мы пытаемся определить, есть ли способ отличить ответы этих двух групп.
Вот почему в выводе инструмента нет слов «уязвим/неуязвим»: он просто сообщает, может ли он различить ответы, пришедшие на запросы из этих двух групп.
Инструмент считает два набора HTTP-ответов различимыми, если выполняется хотя бы одно из следующих двух условий:
Таймауты обрабатываются как уникальное значение кода состояния, не равное никакому другому; таким образом, инструмент превосходит классическую схему «обнаружение по времени».
Рассмотрим пример. Предположим, мы пытаемся протащить заголовок transfer-encoding, заменив дефис на подчеркивание.
Если окажется, что сервер отвечает статусом 400 каждый раз, когда мы отправляем transfer_encoding:zalupa, и зависает при transfer_encoding:chunked, мы можем сказать, что сервер, вероятно, обрабатывает этот заголовок как значение для transfer encoding. Теоретически это может быть либо фронтальный сервер, либо бэкенд.
Первый случай неинтересен, так как мы в любом случае могли бы отправить непротащенную версию заголовка, а второй — это то, что мы ищем. Поскольку все происходит через HTTP/2, первого случая в большинстве случаев можно избежать: HTTP/2-сервер определяет конец тела запроса другим способом, не связанным с заголовками запроса, и никогда не ожидает, что тело будет в формате chunked HTTP/1.1 (с шестнадцатеричными длинами фрагментов).
Конкретные вариации методов обнаружения:
Мы отправляем протащенную версию Transfer-Encoding: chunked (например, transfer_encoding:chunked) и разные тела: допустимое — 0\r\n\r\n, недопустимое — 999\r\n.
В случае, если ответы различаются, мы можем быть уверены, что бэкенд получает и обрабатывает протащенный заголовок. У фронтального сервера нет причин делать это: HTTP/2 не использует отправленный нами формат chunked, поэтому он был бы недопустим.
Мы ожидаем, что бэкенд зависнет (то есть запрос приведет к таймауту) для недопустимых запросов, так как он ждет поступления дополнительных данных.
Это самый надежный вариант обнаружения: если сервер зависает при чтении тела, что-то, вероятно, пошло не так, поскольку в HTTP/2-запросе нет использования передачи с разбиением на фрагменты HTTP/1.1.
Мы снова отправляем протащенную версию Transfer-Encoding и разные тела: 0\r\n\r\n как допустимое тело и X\r\n\r\n как недопустимое.
Случай тот же, что и выше, но вместо чтения тела мы ожидаем, что бэкенд хотя бы проверит его.
Мы отправляем протащенную версию заголовка Content-Length со значениями 1 и -1.
Оба значения недопустимы с точки зрения фронтального сервера: в HTTP/2 существует другой механизм определения длины тела, и в обоих случаях тело запроса фактически не отправляется. Если ответы различаются, мы предполагаем, что заголовки анализировал именно бэкенд.
Этот метод наименее надежен: фронтальный сервер может выдавать разные ошибки, когда Content-Length имеет недопустимое значение и когда оно не соответствует фактической длине.
Отправляя несколько пар допустимых/недопустимых запросов, мы можем снизить вероятность случайных ложных срабатываний. С другой стороны, мы можем остановиться раньше, если увидим, что нет никакой возможности разделить ответы на «допустимые» и «недопустимые» запросы.
Инструмент пытается применить несколько техник контрабанды, модифицируя заголовок различными способами. Ни одна из них не является новой и одновременно неочевидной.
Чтобы протащить заголовок, мы добавляем к нему пробел. Это самый распространенный и классический метод. Мы надеемся, что заголовок не обрабатывается фронтальным сервером, но отправляется как есть бэкенду, который удаляет пробел.
