Уязвимость HTTP Response Splitting в vBulletin

Оглавление (нажмите, чтобы открыть):

Как устранить уязвимость разделения ответов HTTP с помощью ESAPI

после того, как последние запуски findbugs (FB) запущены, он жалуется на уязвимость: уязвимость безопасности — HTTP-ответ. Следующий код запускает его:

В основном параметр http ‘referrer’ содержит URL-адрес, к которому при нажатии кнопки возврата в нашем приложении браузер возвращается. Он добавляется к URL-адресу в качестве параметра. После небольшого исследования я знаю, что мне нужно дезинфицировать URL-адрес реферера. После немного большего количества исследований я нашел проект esapi, который, похоже, предлагает такую ​​функциональность:

Однако я не понял, как обнаружить, например. jscript-код или другой материал, который не относится к URL-адресу реферера. Итак, как я могу достичь этого с помощью esapi?

однако это не работает. Мне нужна функция, которая приводит к:

Или достаточно ли вызвать следующее утверждение?

HTTP Response Splitting

На сайте исправляю дыры, но осталась самая такая, которую, увы, исправить не получается

HTTP Response Splitting (прикрепленная фотография)
На фотографии по сути показывается где уязвимость, а в чем она заключается все понять не могу
Собственно сам код:

09.12.2015, 21:31

File_get_contents failed to open stream: HTTP request failed! HTTP/1.1 505
Ребята подскажите пожалуйста. Использую фреймворк Yii. Пишу небольшой парсер. Все вроде бы.

Таймаут от браузера (а именно, network.http.response.timeout)
При разработке столкнулись с проблемой — продукт коммерческий — есть страницы, которые возвращают.

Response — в фреймворках
Здравствуйте, хотел бы чтобы вы помогли мне разобраться с ответом приложения Response, мне нужно.

Лекция #3. Уязвимости (Часть_1)

Всем привет , я снова с вами , сегодня поговорим про уязвимости , эта лекция будет разделена на 2-3 части , так, что терпим 😀 Быстренько пробежимся по типам уязвимостей , подробнее вы можете изучить их с помощью гугла (google.com)

1. HTML

Инъекции Hypertext Markup Language (HTML), также иногда называемые виртуальным дефейсом.

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

Другими словами, такая уязвимость вызывается получением некорректного HTML, как правило, через форму ввода, а затем рендер этого HTML на странице.

Это отдельный тип уязвимости, который следует отличать от инъекции Javascript, VBscript и прочих.

Поскольку HTML является языком, используемым для определения структуры веб-страницы, если злоумышленник может внедрить HTML, он может полностью изменить то, что отображает браузер.

Иногда результатом этого может стать полное изменение внешнего вида страницы или, в других случаях, создание формы для обмана пользователей.

Например, если вы можете внедрить HTML, вы можете добавить тег “‘ ‘ на страницы, прося пользователя заново ввести его логин и пароль.

2. HTTP Parameter Pollution (HPP)

HTTP Parameter Pollution, или HPP, происходит, когда сайт принимает пользовательский ввод и использует его для создания запроса к другой системе без валидации этого ввода.

Это может пройзойти одним из двух способов, через сервер (или бэкенд) и через клиентскую сторону.

Silverlightfox приводит прекрасный пример серверной HPPатаки на StackExchange — предположим, у нас есть следующий сайт, https://www.example.com/transferMoney.php, который через метод POST принимает следующие параметры:

amount=1000&fromAccount=12345

Когда приложение обрабатывает этот запрос, оно создает собственный POST запрос к другому компоненту в бэкенде системы, который, в свою очередь, выполняет транзакцию с

фиксированным параметром toAccount.

• Отдельный URL бэкенда: https://backend.example/doTransfer.php

• Отдельные параметры для бэкенда: toAccount=9876&amount=100

Теперь, если бэкенд, получая дублирующиеся параметры, принимает только последний параметр, можно предположить, что хакер сможет изменить POST-запрос к сайту для отправки следующего параметра toAccount:

amount=1000&fromAccount=12345&toAccount=99999

Сайт, уязвимый к HPP атаке передаст запрос бэкенду в таком виде:

toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999

В этом случае второй параметр toAccount, отправленный злоумышленником, перезапишет запрос к бэкенду и позволит перевести деньги на предоставленный хакером счет (99999) вместо счета, установленного системой (9876).

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

Но также это может быть более полезным для хакера, если он может сгенерировать ссылку с другого сайта и обмануть пользователей, заставив их ненамеренно отправить вредный запрос с дополнительными параметрами, добавленными хакером.

С другой стороны, HPP на клиентской стороне включает инъекцию дополнительных параметров в ссылки и другие src атрибуты.

Позаимствуем пример с OWASP и предположим, что у нас есть следующий код:

Это принимает значение для par из UTL, убеждается, что оно

безопасное и создает из него ссылку. Если хакер отправит:

https://host/page.php?par=123%26action=edit

то полученная в результате ссылка будет выглядеть так:

Это может заставить приложение к выполнению действия редактирования вместо просмотра.

И серверная и клиентская HPP зависят от того, какая технология используется на бэкенде и как она действует, получая несколько параметров с одинаковыми именами.

Например, PHP/Apache используют последний переданный параметр из нескольких с одинаковыми именами, Apache Tomcat использует первый параметр, ASP/ISS используют все параметры, и так далее.

В результате, нет одного гарантированного способа для отправки нескольких параметров с одинаковыми именами и обнаружение HPP потребует некоторых экспериментов, чтобы узнать, как работает тестируемый вами сайт.

3. CRLF

CRLF, или Carriage Return Line Feed, относится к тому типу уязвимостей, которые происходят, когда юзер вставляет CRLF в приложение.

Символы CRLF означают конец строки для множества интернет-протоколов, включая HTML, и выглядят как %0D%0A, что декодируется в \r\n.

Они могут быть использованы для обозначения переноса строк и в сочетании с заголовками HTTP-запросов и ответов могут приводить к различным уязвимостям, включая HTTP Request Smuggling и HTTP Response Splitting.

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

Этот тип уязвимости может привести к:

• Отравлению кэша, ситуации, в которой атакующий может изменять записи в кэше и отдавать вредоносные страницы (например, содержащие javascript) вместо корректных

• Обходу файрволла, ситуации, в которой запрос может быть создан таким образом, чтобы обойти проверки безопасности, обычно, включает в себя CRLF и чрезмерно большие тела запросов

• Кражу запроса, ситуации, в которой атакующий может украсть HttpOnly cookies и информации о HTTP аутентификации. Это похоже на XSS, но не требует взаимодействия между клиентом и хакером

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

Зная о HTTP Response Splitting, хакеры могут устанавливать произвольные заголовки ответа, контролировать тело ответа или разделять ответ полностью, предоставляя два ответа вместо одного.

На этом пока всё , 2ая часть выйдет 20го числа , так-что ждём , а пока изучаем подробнее все эти типы уязвисостей , удачи вам

Уязвимости веб-приложений

Перечислим некоторые из наиболее часто встречающихся проблем:

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

Межсайтовый скриптинг (XSS)

Межсайтовый скриптинг (Cross Site Scripting или XSS) — это возможность вставки («инъекции») HTML-кода в уязвимую страницу. Инъекция кода осуществляется через все доступные способы ввода информации. Любое веб-приложение, которое выводит какую-либо информацию, полученную от пользователя, может быть подвержено атакам этого класса. Возможность успешного проведения такой атаки возникает в результате отсутствия фильтрации значений переменных, полученных от пользователя, на наличие скриптов (JavaScript, VBScript) или опасных HTML-тегов. Данный вид атаки может использоваться злоумышленником для перехвата значений cookie различных пользователей (в том числе и администраторов), пользовательских сессий, а так же в некоторых случаях позволяет обойти механизм аутентификации или если поддерживается SSI (Server Side Include), то выполнить произвольную команду на стороне сервера.

Мастер Йода рекомендует:  Состаривание молодых

HTTP Response Splitting

Ошибки HTTP Response Splitting свойственны большинству веб-приложений и являются следствием невозможности правильно обработать пользовательский ввод. Удаленный атакующий может послать специальный HTTP-запрос, который заставит веб-сервер сформировать определенный выходной поток, который примется жертвой за целых два HTTP-ответа (вместо правильного одного). В данном случае только первый HTTP-ответ, который является поддельным, будет обрабатываться жертвой. HTTP Response Splitting позволяет проводить целый ряд атак, таких как отравление веб кэша, подмену страниц, «cross-user defacement», кража пользовательской информации и межсайтовый скриптинг.

SQL-инъекция

«SQL-инъекция» — способ нападения на базу данных в обход межсетевой защиты. В этом методе, параметры, передаваемые к базе данных через веб-приложения, изменяются таким образом, чтобы изменить выполняемый SQL-запрос. Например, добавляя различные символы к параметру, можно выполнить дополнительный запрос совместно с первым.

Нападение может использоваться для следующих целей:

1. Получить доступ к данным, которые обычно недоступны, или получить данные конфигурации системы, которые могут использоваться для дальнейших нападений. Например, измененный запрос может возвратить хешированные пароли пользователей, которые впоследствии могут быть расшифрованы методом перебора.

2. Получить доступ к компьютерам организации через компьютер, на котором находится база данных. Это можно реализовать, используя процедуры базы данных и расширения 3GL языка, которые позволяют, например, запускать различные приложения.

Code injection

Если веб-приложение неправильно обрабатывает динамически подключаемые файлы или пути к файлам, то появляется возможность выполнить произвольный код (PHP, ASP и другие) на стороне сервера или получить содержимое произвольного файла. Успешно проведенная атака, позволяет злоумышленнику обойти механизм аутентификации, выполнять команды на сервере, читать содержимое файлов, записывать произвольные данные в файл и т.д.

CRLF Injection and HTTP Response Splitting Vulnerability

In this post, we discusses how HTTP Response Splitting vulnerabilities can be exploited via CRLF injection attacks, and how to prevent this in your web app.

Join the DZone community and get the full member experience.

What Is CRLF?

When a browser sends a request to a web server, the web server answers back with a response containing both the HTTP headers and the actual website content. The HTTP headers and the HTML response (the website content) are separated by a specific combination of special characters, namely a carriage return and a line feed. They are also known as CRLF.

The server knows when a new header begins and another one ends with CRLF, which can also tell a web application or user that a new line begins in a file or in a text block.

What Is the CRLF Injection Vulnerability?

In a CRLF injection vulnerability attack, the attacker inserts carriage return, linefeeds both of the characters into the user input to trick the server, web application or the user into thinking that an object is terminated and another one has started.

CRLF Injection in Web Applications

In web applications, a CRLF injection can have severe impacts, depending on what the application does with single items. Impacts can range from information disclosure to code execution. For example, it is also possible to manipulate log files in an admin panel as explained in the below example.

An Example of CRLF Injection in a Log File

Imagine a log file in an admin panel with the pattern IP — Time — Visited Path. Therefore, entries appear like:

123.123.123.123 — 08:15 — /index.php?page=home

If an attacker is able to insert the CRLF characters into the query he is able to fake those log entries and change them into:

%0d and %0a is the URL encoded form of CR and LF. Therefore, the log entries would look like this after the attacker inserted those characters and the application displays it:

IP — Time — Visited Path
123.123.123.123 — 08:15 — /index.php?page=home&
127.0.0.1 — 08:15 — /index.php?page=home&restrictedaction=edit

Therefore, by exploiting a CRLF injection vulnerability, the attacker can fake entries in the log file to obfuscate his own malicious actions. For example, imagine a scenario where the attacker has the admin password and executed the restrictedaction parameter, which can only be used by an admin.

The problem is that if the administrator notices that an unknown IP used the restrictedaction parameter, they will notice that something is wrong. However, since it now looks like the command was issued by the localhost (and, therefore, probably by someone who has access to the server, like an admin) it does not look suspicious.

The whole part of the query beginning with %0d%0a will be handled by the server as one parameter. After tha,t there is another & with the parameter restrictedaction which will be parsed by the server as another parameter. Effectively, this would be the same query as:

HTTP Response Splitting

Description

Since the header of an HTTP response and its body are separated by CRLF characters, an attacker can try to inject those. A combination of CRLFCRLF will tell the browser that the header ends and the body begins. That means that he is now able to write data inside the response body where the HTML code is stored. This can lead to a Cross-Site Scripting vulnerability.

An Example of HTTP Response Splitting Leading to XSS

Imagine an application that sets a custom header, for example:

The value of the header is set via a GET parameter called «name.» If no URL encoding is in place and the value is directly reflected inside the header it might be possible for an attacker to insert the above-mentioned combination of CRLFCRLF to tell the browser that the request body begins. That way he is able to insert data such as XSS payload, for example:

The above will display an alert window in the context of the attacked domain.

HTTP Header Injection

Description

By exploiting a CRLF injection an attacker can also insert HTTP headers which could be used to defeat security mechanisms such as a browser’s XSS filter or the same-origin-policy. This allows the attacker to gain sensitive information like CSRF tokens. He can also set cookies which could be exploited by logging the victim in the attacker’s account or by exploiting otherwise unexploitable cross-site scripting (XSS) vulnerabilities.

An Example of HTTP Header Injection to Extract Sensitive Data

If an attacker inserts the headers that would activate CORS (Cross-Origin Resource Sharing), they can use JavaScript to access resources that are otherwise protected by SOP (Same Origin Policy) which prevents sites from different origins to access each other.

Impacts of the CRLF Injection Vulnerability

The impact of CRLF injections vary and also include all the impacts of Cross-Site Scripting to information disclosure. It can also deactivate certain security restrictions like XSS Filters and the Same Origin Policy in the victim’s browsers, leaving them susceptible to malicious attacks.

How to Prevent CRLF/HTTP Header Injections in Web Applications

The best prevention technique is to not let users supply input directly inside response headers. If that is not possible, you should always use a function to encode the CR and LF special characters. It is also advised to update your programming language to a version that does not allow CR and LF to be injected into functions that set headers.

Как устранить уязвимость разделения ответов HTTP с помощью ESAPI

после того, как последние запуски findbugs (FB) запущены, он жалуется на уязвимость: уязвимость безопасности — HTTP-ответ. Следующий код запускает его:

Мастер Йода рекомендует:  Переполнение буфера и раскрытие данных в MySQL

В основном параметр http ‘referrer’ содержит URL-адрес, к которому при нажатии кнопки возврата в нашем приложении браузер возвращается. Он добавляется к URL-адресу в качестве параметра. После небольшого исследования я знаю, что мне нужно дезинфицировать URL-адрес реферера. После немного большего количества исследований я нашел проект esapi, который, похоже, предлагает такую ​​функциональность:

Однако я не понял, как обнаружить, например. jscript-код или другой материал, который не относится к URL-адресу реферера. Итак, как я могу достичь этого с помощью esapi?

однако это не работает. Мне нужна функция, которая приводит к:

Или достаточно ли вызвать следующее утверждение?

Защищен ли PHP от уязвимостей «HTTP Response Splitting»?

Но, оказывается, PHP автоматически выполняет кодировку:

Означает ли это, что невозможно воспроизвести расщепление ответа HTTP в PHP?

1 ответ

От ссылка Статья в Википедии:

[. ] Хотя разделение ответов не является специфичным для PHP, интерпретатор PHP содержит защиту от атаки с версии 4.4.2 и 5.1.2. [1]

header и setcookie содержат смягчения против разделения ответа/заголовка. Это невозможно.

Как я могу исправить уязвимость моего кода?

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

Тест на уязвимость сообщил: HTTP Response Splitting,
Я не очень понимаю, что это значит (HTTP Response Splitting) и как это исправить.

В то время как полный код, как следует:

Я предполагаю, что следующая строка имеет проблему, но я не знаю, как еще это исправить:

Решение

Разделение HTTP-ответов происходит, когда:

Данные поступают в веб-приложение через ненадежный источник, чаще всего через HTTP-запрос.

Данные включаются в заголовок ответа HTTP, отправляемого веб-пользователю без проверки на наличие вредоносных символов.

Атака разбиения ответа HTTP: злоумышленник передает вредоносные данные уязвимому приложению, и приложение включает данные в заголовок ответа HTTP.

Санация: — Пользовательский ввод, содержащий CR (возврат каретки) и LF (перевод строки), должен быть отфильтрован соответствующим образом. Некоторые языки также принимают «\ r» и «\ n», что может вызвать проблемы. Тем не менее, соответствующие совершить этот header () теперь полностью отклоняет любые возвраты каретки и переводы строк, независимо от их положения. В заключение, эксплойты с разделением ответов с помощью этого конкретного метода сегодня должны быть устаревшими. Поэтому в вашем случае не нужно беспокоиться о разделении HTTP-ответов.
Тем не менее, вы можете предварительно обработать пользовательский ввод перед передачей его в header ()
для символов ‘\ r’ и ‘\ n’.

Делаем свободное ПО безопасней: баги и фиксы InstantCMS

Этой статьёй мы начинаем серию материалов, посвященных поиску уязвимостей в популярных системах с открытым кодом. Ошибки в OpenSSL и glibc показали, что тысячи глаз [1] , имеющих доступ к коду, — не гарантия безопасности open source. Конечно, и закрытый код не становится безопаснее от самого факта закрытости. Просто при наличии правильных инструментов доступность исходного кода позволяет выявить гораздо больше уязвимостей, чем при тестировании методом «чёрного ящика». Вопрос лишь в том, кто этим воспользуется раньше – разработчики или злоумышленники.

Последние два года в ходе разработки системы анализа исходных кодов PT Application Inspector мы проверяли на стендах и «в поле» сотни бесплатных и коммерческих, открытых и проприетарных приложений. В ходе этих тестов было найдено значительное число уязвимостей нулевого дня. Часть этих проблем была закрыта и известна по последним докладам о безопасности SCADA [2] , часть ожидает своей погибели в ходе ответственного разглашения.

Воспользуемся же открытостью open source и покажем, как выявляются и анализируются уязвимости в исходном коде. В роли первого подопытного выступает бесплатная система управления сообществами InstantCMS, работающая на PHP и MySQL. На базе данного конструктора создано немало [3] социальных сетей, сайтов знакомств, онлайн-клубов, городских порталов и государственных ресурсов.

В настоящее время разработчик InstantCMS устранил все обнаруженные нами уязвимости. В этой статье мы рассмотрим ошибки той версии, которая была актуальна на момент тестирования — в ней было найдено несколько десятков багов разной степени риска. Ниже описаны самые интересные.

В: Что такое PT Application Inspector?
О: Система анализа исходного кода: ptsecurity.ru/appsecurity/application-inspector [4]

В: Почему вы не пишете про систему ХХХ?
О: Она либо ещё не проверялась, либо её уязвимости ещё устраняются разработчиками. Пишите нам в комментариях или на почту, поставим в очередь.

В: Что вы делаете с уязвимостями?
О: Отправляем информацию производителям ПО и помогаем устранить ошибки. Полный список обнаруженных уязвимостей: ptsecurity.ru/lab/advisory [5]

В любой CMS есть хотя бы одна XSS

Исследуя код InstantCMS, наш анализатор сообщил о возможности проведения атаки XSS (межсайтовое выполнение сценариев) вот в таком формате:

Рис. 1.1. Сообщение о наличии XSS-уязвимости

В сообщении приводится полное имя скрипта, номер строки и непосредственно сам код, содержащий уязвимость. Эта информация важна для разработчика: теперь он может найти ошибку, которая стала причиной этой уязвимости.

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

Рис 1.2. Подробная информация о найденной XSS

Очевидно, что условие истинно только тогда, когда в запросе будет передан конкретный параметр:

Проверим, как это работает на практике. Отправляем на сервер эксплойт и получаем ответ:

Рис 1.3. Запрос и ответ сервера

Как видим, ответ сервера в HTML-странице содержит именно тот JavaScript-код, который мы отправляли в эксплойте.
Итак, мы убедились, что уязвимость существует. Самое время покопаться в коде и найти ошибку программиста. Воспользуемся информацией из Application Inspector, а именно — полным именем скрипта, номером строки и самим кодом, содержащим уязвимость (см. рис. 1.2).

Проанализировав исходный код, получаем такую картину:

Функция print_textinputs_var () объявлена в верхней части этого же скрипта и как раз содержит известную нам строку номер 27, в которой происходит вызов опасной функции “echo”:

Анализ показал, что код в строке 17 содержит недостаток — нефильтрованный параметр $_POST[‘textinputs’] — который и стал причиной уязвимости в строке 27. А это, в свою очередь, сделало XSS-атаку возможной.

Чего можно добиться с помощью XSS? Как минимум инвайта [8] на Хабре 🙂 А если звезды сойдутся — получить в свое распоряжение cookies администратора сайта, а следовательно, и доступ в админскую панель.

Уязвимость HTTP Response Splitting

В ходе дальнейшего сканирования была обнаружена возможность провести атаку, основанную на расщеплении HTTP-ответа сервера (HTTP Response Splitting):

Рис 2.1. Отчет Application Inspector (справа — уязвимость в деталях)

Сгенерирован классический тестовый эксплойт, добавляющий дополнительный заголовок путем внедрения символов «перевод строки» и «возврат каретки». Эксплуатация возможна, если приложение работает на PHP версии ниже 5.1.2 (в более поздних версиях в интерпретатор встроена защита от таких атак).

Рис. 2.2. Граф потока выполнения демонстрирует наличие уязвимости

Результат анализа позволяет найти причину возникшей уязвимости и выработать рекомендации по ее устранению. Система PT AI указала, что вызов опасной функции произошел на 32-й строке файла set.php. Открыв исходный код, мы действительно видим, что в означенную строку попадает параметр, принимаемый без всякой фильтрации из POST-запроса в 15-й строке того же файла.

Рис 2.3. Программный код, содержащий уязвимость

Бывают случаи, когда разбор причин возникновения уязвимости является значительно более трудоемким, однако в данном случае и причины возникновения уязвимости, и пути ее устранения очевидны. Программисту необходимо добавить дополнительные проверки при присвоении значения переменной $back.

Уязвимость Open Redirect

В результате сканирования была обнаружена возможность провести атаку, классифицируемую как Open Redirect — открытое перенаправление:

Рис 3.1. Отчет о наличии Open Redirect, с подробной информацией

Воспользуемся автоматически сгенерированным запросом-эксплойтом: отправим его на сервер-стенд и проанализируем ответ.

Рис 3.2. Запрос-эксплойт для проверки уязвимости Open Redirect и ответ на него

Как мы видим, в исследуемой CMS действительно имеет место открытое перенаправление: ответом на запрос стала страница стороннего ресурса, переданная в векторе атаки. Попробуем разобраться в причинах. Отчет говорит о том, что точкой выхода атаки является строка 32 файла set.php. Откроем программный код:

Рис 3.3. Уязвимый участок программного кода

В 32-й строке формируется заголовок location со значением из переменной $back. В свою очередь, переменная $back принимает свое значение из массива $_POST в 15-й строке того же файла без всяких дополнительных проверок. Таким образом становится ясна причина уязвимости — передача нефильтрованного параметра в 15-й строке файла set.php. Для устранения ошибки необходимы дополнительные проверки для переменной $back.

Мастер Йода рекомендует:  Лучший видеокурс из 10 уроков IP сети шаг за шагом

Чем опасна эта уязвимость? Прежде всего — возможностью практически незаметно для пользователя перенаправить его на зараженную страницу, а затем, так же незаметно, вернуть обратно.

Сплитинг и редирект в свежей PHP и Internet Explorer

Сплитинг с использованием последовательности символов %0D%0A работает на версиях PHP ниже 5.1.2, однако в некоторых ситуациях он возможен, даже если на сервере используется современная версия PHP.
Подходящие условия возникают, если клиентом является браузер Internet Explorer: он понимает последовательности %0A%20 или %0D%0A%20 как разделитель, а другие браузеры считают новую строку, начинающуюся с пробела, продолжением предыдущего заголовка. Такое поведение IE и недостаточная фильтрация в функции header() в PHP делают сплитинг возможным. Баг в header() исправлен недавно (bugs.php.net/bug.php? >[12] ) и скоро попадет в релизы.

Примеры внедрения заголовка и содержимого в IE — ниже, адрес для проверки: molnar.es/php-header/test.php.

Проверить внедрение заголовков и открытое перенаправление на уязвимом сценарии (InstantCMS set.php в IE) можно и с помощью AI. Возьмем информацию из двух эксплойтов, полученных AI (адрес, метод, нефильтруемый параметр) для демонстрации такого вектора атаки на примере ptsecurity.com. Сделаем форму, которая посылает нужный вектор на нужный адрес, и посмотрим, работает ли атака. Как видим, да: на рис. 4.4 видно и адрес скрипта (set.php), и редирект (302-й статус и потом загрузку ptsecurity.com) и сплитинг (заголовок custom header).

Теперь по шагам:

1. Создаем страницу с формой:

2. Заходим на страницу в IE и отправляем запрос.

Результат выполнения запроса:

На рис. 4.4 видно, что помимо перенаправления был установлен заголовок Custom-Header со значением Test.

SQL Injection

Рассмотрим еще один пример уязвимости, обнаруженной при помощи AI. Согласно результатам сканирования, в InstantCMS возможно внедрение SQL-кода (SQL Injection), да еще и в различных вариантах.

Рис. 5.1. Фрагмент отчета PT AI. Однотипные SQL-инъекции — и подробная информация об одной из них

Помимо определения уязвимого фрагмента кода и родительской уязвимости в приложении, PT AI выдает необходимые условия для проведения атаки.

На рис. 5.1 видно, что для эксплуатации SQL Injection требуются несколько условий, одно из которых — наличие в сессии вектора атаки. Это признак межмодульных уязвимостей (Second Order SQL Injection, хранимых XSS). У таких багов данные попадают в уязвимую функцию не сразу из переменных от точек входа, а из каких-то промежуточных хранилищ — базы, сессий и т. п., где они до этого каким-то образом оказались.

Эксплуатация межмодульных уязвимостей происходит в несколько этапов. Например, для хранимой XSS данные одним запросом заносятся в СУБД, а вторым запросом — извлекаются оттуда и чем-то выводятся на страницу.

Рис. 5.2. Схема эксплуатации хранимых XSS

Продемонстрируем эксплуатацию найденной уязвимости Second Order SQL Injection в условиях, которые позволяют злоумышленнику изменять значения переменных в сессии. Возьмем простейший пример — виртуальный хостинг [18] с общим хранилищем сессий. У хостинга [18] есть ошибка конфигурации — значение директивы PHP session.save_path, которое по умолчанию равно /tmp (подробности [19] ).

Если на сервере крутятся несколько сайтов, один из которых подконтролен злоумышленнику, мы можем атаковать соседний ресурс, функционирующий на базе InstantCMS, обладая минимальными правами.

Для этого необходимо:

1. Создать файл сессий с вектором для SQL Injection.

2. Сделать запрос с cookie, соответствующим файлу сессии из п. 1, к странице InstantCMS, при генерации которой вектор из сессии попадет в SQL-запрос.

Пример PHP-скрипта, генерирующего файл:

Атака проходит в два этапа:

Сначала запускается скрипт, который создает файл с вектором и выводит значение для cookie сессии.

Рис. 5.3. Пример файла с вектором для SQL Injection в InstantCMS

Затем отправляется следующий запрос на сайт с InstantCMS:

Ответ сервера будет получен примерно через 5 секунд для вектора с sleep(5), что подтвердит наличие SQL Injection.

Стоит подчеркнуть еще пару моментов:

  • Описанный сценарий атаки не сработал бы в случае, если бы в коде InstantCMS разработчики устанавливали значение session.save_path, которое бы отличалось от значения для сайта атакующего, и права на директорию с сессиями не давали получать список файлов, читать, изменять их и создавать свои.
  • Иногда встречаются баги с инъекцией в сессию (1 [20] , 2 [21] ) — как в самом PHP, так и в коде приложений.

Уязвимость SQL Injection позволяет провернуть множество нехороших фокусов, от чтения содержимого таблиц БД до заливки на сервер веб-шелла, это наиболее опасный вид атаки [22] среди рассмотренных в данной статье. Об ошибках управления сессиями можно почитать в презентации на ZeroNights, где показывали похожий случай ошибки управления сессиями применительно к CMS.

На этом с InstantCMS — все. Исследование уязвимостей в других системах с открытым кодом мы продолжим в следующих материалах.

Уязвимость HTTP Response Splitting в vBulletin

2. Заходим на страницу в IE и отправляем запрос.

Результат выполнения запроса:

На рис. 4.4 видно, что помимо перенаправления был установлен заголовок Custom-Header со значением Test.

Рассмотрим еще один пример уязвимости, обнаруженной при помощи AI. Согласно результатам сканирования, в InstantCMS возможно внедрение SQL-кода (SQL Injection), да еще и в различных вариантах.

Рис. 5.1. Фрагмент отчета PT AI. Однотипные SQL-инъекции — и подробная информация об одной из них

Помимо определения уязвимого фрагмента кода и родительской уязвимости в приложении, PT AI выдает необходимые условия для проведения атаки.

На рис. 5.1 видно, что для эксплуатации SQL Injection требуются несколько условий, одно из которых — наличие в сессии вектора атаки. Это признак межмодульных уязвимостей (Second Order SQL Injection, хранимых XSS). У таких багов данные попадают в уязвимую функцию не сразу из переменных от точек входа, а из каких-то промежуточных хранилищ — базы, сессий и т. п., где они до этого каким-то образом оказались.

Эксплуатация межмодульных уязвимостей происходит в несколько этапов. Например, для хранимой XSS данные одним запросом заносятся в СУБД, а вторым запросом — извлекаются оттуда и чем-то выводятся на страницу.

Рис. 5.2. Схема эксплуатации хранимых XSS

Продемонстрируем эксплуатацию найденной уязвимости Second Order SQL Injection в условиях, которые позволяют злоумышленнику изменять значения переменных в сессии. Возьмем простейший пример — виртуальный хостинг с общим хранилищем сессий. У хостинга есть ошибка конфигурации — значение директивы PHP session.save_path, которое по умолчанию равно /tmp (подробности).

Если на сервере крутятся несколько сайтов, один из которых подконтролен злоумышленнику, мы можем атаковать соседний ресурс, функционирующий на базе InstantCMS, обладая минимальными правами.

Для этого необходимо:

1. Создать файл сессий с вектором для SQL Injection.

2. Сделать запрос с cookie, соответствующим файлу сессии из п. 1, к странице InstantCMS, при генерации которой вектор из сессии попадет в SQL-запрос.

Пример PHP-скрипта, генерирующего файл:

Атака проходит в два этапа:

Сначала запускается скрипт, который создает файл с вектором и выводит значение для cookie сессии.

Рис. 5.3. Пример файла с вектором для SQL Injection в InstantCMS

Затем отправляется следующий запрос на сайт с InstantCMS:

GET /admin/index.php HTTP/1.1
Host: victim
Cookie: PHPSESS > Connection: close

Ответ сервера будет получен примерно через 5 секунд для вектора с sleep(5), что подтвердит наличие SQL Injection.

Стоит подчеркнуть еще пару моментов:

Описанный сценарий атаки не сработал бы в случае, если бы в коде InstantCMS разработчики устанавливали значение session.save_path, которое бы отличалось от значения для сайта атакующего, и права на директорию с сессиями не давали получать список файлов, читать, изменять их и создавать свои.
Иногда встречаются баги с инъекцией в сессию (1, 2) — как в самом PHP, так и в коде приложений.

Уязвимость SQL Injection позволяет провернуть множество нехороших фокусов, от чтения содержимого таблиц БД до заливки на сервер веб-шелла, это наиболее опасный вид атаки среди рассмотренных в данной статье. Об ошибках управления сессиями можно почитать в [forbidden link] на ZeroNights, где показывали похожий случай ошибки управления сессиями применительно к CMS.

На этом с InstantCMS — все. Исследование уязвимостей в других системах с открытым кодом мы продолжим в следующих материалах.

Добавить комментарий