web

Что такое CRLF инъекция, примеры использования. Уроки хакинга, глава 4.

CRLF, или Carriage Return Line Feed, относится к тому типу уязвимостей, которые происходят, когда юзер вставляет CRLF в приложение. Символы CRLF означают конец строки для множества интернет-протоколов, включая HTML, и выглядят как %0D%0A, что декодируется в rn. Они могут быть использованы для обозначения переноса строк и в сочетании с заголовками HTTP-запросов и ответов могут приводить к различным уязвимостям, включая HTTP Request Smuggling и HTTP Response Splitting.

Содержание скрыть

1 1. Twitter HTTP Response Splitting

1.1 Выводы

2 2. Разделение ответа на v.shopify.com

2.1 Выводы

3 Итоги

Если говорить о HTTP Request Smuggling, это обычно происходит когда HTTP-запрос проходит через сервер, который обрабатывает его и передает другому серверу, как прокси или файрволл. Этот тип уязвимости может привести к:

Отравлению кэша, ситуации, в которой атакующий может изменять записи в кэше и отдавать вредоносные страницы (например, содержащие javascript) вместо корректных
Обходу файрволла, ситуации, в которой запрос может быть создан таким образом, чтобы обойти проверки безопасности, обычно, включает в себя CRLF и чрезмерно большие тела запросов
Кражу запроса, ситуации, в которой атакующий может украсть HttpOnly cookies и информации о HTTP аутентификации. Это похоже на XSS, но не требует взаимодействия между клиентом и хакером

Хотя эти уязвимости существуют, их трудно обнаружить. Я описываю их здесь, чтобы вы могли понять, насколько опасной может быть Request Smuggling (кража запроса).

Зная о HTTP Response Splitting, хакеры могут устанавливать произвольные заголовки ответа, контролировать тело ответа или разделять ответ полностью, предоставляя два ответа вместо одного, как показано в примере #2 разделение ответа на v.shopify.com (если вам нужно напоминание о заголовках HTTP запросов и ответов, перелистните на главу “Фоновые знания”).

[ad name=»Responbl»]

1. Twitter HTTP Response Splitting

Сложность: Высокая
Url: https://twitter.com/i/safety/report_story
Ссылка на отчет: https://hackerone.com/reports/520427 Дата отчета: 21 апреля 2015
Выплаченное вознаграждение: $3,500
Описание:

В апреле 2015 был сообщено, что в Twitter найдена уязвимость, позволяющая хакерам устанавливать произвольные cookie, добавляя дополнительную информацию в запрос к Twitter.

По существу, после создания запроса к указанному выше URL (легаси-url Twitter, позволявший людям жаловаться на рекламу), Twitter возвращал cookie для параметра reported_tweet_id. Однако, судя по отчету, валидация Twitter, подтверждающая, что id твита был числом, была несовершенна.

Хотя Twitter валидирует этот символ новой строки, 0x0a, не позволяя его отправить, валидация может быть обойдена кодированием символов в кодировку UTF-8. Twitter произведет

обратную кодировку символов в unicode, таким образом, делая фильтр бесполезным. Вот пример:

1 %E5%E98%8A => U+560A => 0A

Это важно, поскольку символы новой строки интерпретируются сервером буквально, создавая новую строку, которую сервер читает и исполняет, в данном случае, возвращая новые cookie.

CLRF-атака может быть еще более опасной, если система подвержена XSS-атакам (смотрите раздел Cross Site Scripting). В этом случае, поскольку фильтры Twitter пройдены, пользователю можно будет вернуть новый ответ, включающий XSSатаку. Вот URL:

  https://twitter.com/login?redirect_after_login=https://
  twitter.com:21/%E5%98%8A%E5%98%8Dcontent-type:text/html
  %E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%
  E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%
  98%BE

Обратите внимание на добавленное %E5%E98%8A. Если мы заменим эти символы настоящими переносами строк, вот как будет выглядеть заголовок:

  https://twitter.com/login?redirect_after_login=https://
  twitter.com:21/
  content-type:text/html
  location:%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5
  %98%BE

Как видите, переносы в ссылке позволяют создать новый заголовок, который вернется с исполняемым Javascript-кодом svg/onload=alert(innerHTML). С этим кодом злоумышленник может украсть у ничего не подозревающей жертвы сессию Twitter.

Выводы

Хороший белый хакер сочетает в себе наблюдательность и навыки. В этом случае автор отчета, @filedescriptor, знал о предыдущем баге Firefox, связанном с необрабатываемой кодировкой. Это знание привело к тестированию подобной кодировки в Twitter для получения возможности вставки новых строк.

Когда вы ищете уязвимости, всегда помните, что важно думать иначе и отправлять закодированные значения, чтобы увидеть, как сайт обрабатывает введенные вами данные.

[ad name=»Responbl»]

2. Разделение ответа на v.shopify.com

Сложность: Средняя
Url: v.shopify.com/last_shop?x.myshopify.com
Ссылка на отчет: https://hackerone.com/reports/1064278 Дата отчета: 22 декабря 2015
Выплаченное вознаграждение: $500
Описание:

Shopify имеет некоторую неявную функциональность, которая установит в ваш браузер cookie, указывающие на дату вашего последнего входа. Это осуществляется через эндпоинт /last_shop?SITENAME.shopify.com

В декабре 2015 было обнаружено, что Shopify не валидирует передаваемый в запрос параметр shop. В результате, с использованием Burp Suite, белый хакер смог изменить запрос, вставив %0d%0a и сгенерировав заголовок, который был возвращен пользователю. Вот скриншот:

Вредоносный код в этом случае выглядел так:

%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20O2K%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%23
019%0d%0a%0d%0a<html>deface</html>

В этом случае %20 является пробелом, а %0d%0a CRLF. В результате, браузер получал два заголовка и рендерил второй, что могло привести ко множеству уязвимостей, включая XSS.

Выводы

Замечайте случаи, когда сайт принимает ваш ввод и использует его как часть возвращаемых заголовков. В этом случае Shopify создавал cookie со значением last_shop. Это хороший сигнал, что можно попробовать обнаружить уязвимость к CRLF-инъекции.

[ad name=»Responbl»]

Итоги

Хороший хакинг сочетание навыков и наблюдательности. Очень полезно знать, как для обнаружения уязвимости могут быть использованы закодированные символы. %0D%0A может быть использовано для тестирования серверов и определения, подвержены ли они CRLF-инъекциям. Если это так, двигайтесь дальше и попробуйте сочетать уязвимость с XSS-инъекцией (описана в главе 7).

С другой стороны, если сервер не отвечает на %0D%0A, подумайте о том, как вы можете закодировать эти символы еще раз и протестируйте сервер, чтобы увидеть, будет ли он декодировать дважды закодированные символы, как это сделал @filedescriptor.

Подмечайте случаи, когда сайт использует отправленные значения для возвращения какого-либо заголовка, например, для создания cookie.

Оглавление:

Базовые знания о HTTP протоколе. Глава 1

Что такое HTML иньекция. Уроки хакинга. Глава 2.

Что такое HPP (HTTP Parameter Pollution) атака? Уроки хакинга. Глава 3

Что такое CRLF инъекция, примеры использования. Уроки хакинга, Глава 4.

Уязвимости в логике приложений. Уроки хакинга. Глава 6

Уязвимости в логике работы приложений. Примеры.

Что такое XSS атака (Cross Site Scripting Attacks). Уроки хакинга. Глава 7.

SQL иньекции. Виды и примеры использования. Уроки хакинга. Глава 8.

Уязвимости Открытого Перенаправления. Уроки хакинга. Глава 9

Click to rate this post!

[Total: 10 Average: 4.2]

cryptoworld

Специалист в области кибер-безопасности. Работал в ведущих компаниях занимающихся защитой и аналитикой компьютерных угроз. Цель данного блога - простым языком рассказать о сложных моментах защиты IT инфраструктур и сетей.