Александр Колесников (вирусный аналитик в международной компании) приглашает на мастер-класс «Основы технологий, необходимые для понимания уязвимостей. Классификация OWASP TOP 10», который пройдёт в рамках профессионального курса . А также Александр поделился статьёй для начинающих bug hunter-ов, где рассматривает TOP 10 Уязвимостей 2020 года, которые были найдены платформой HackerOne.  Идея заключается в следующем — подготовить лабораторный стенд для изучения уязвимостей, находящихся в данном топе. О том, как запустить и найти пример приложения с уязвимостью, можно почитать вот здесь. Задания будут решены до момента использования уязвимости, которая заложена в приложение, последний шаг оставим за читателями. Информацию по топу уязвимостей можно найти здесь. Приведу ниже статистику по выплатам для каждой из уязвимостей:          Напрашивается сравнение с очень популярным списком — OWASP TOP 10. Но надо учитывать, что последний раз обновление в OWASP TOP 10 вносились в 2017 году. На данный момент ведется сбор информации для обновления списка. Итак, проведем сравнительный анализ данных рейтингов: В списке OWASP представлены множества уязвимостей, тогда как в списке HackerOne содержатся конкретные уязвимости. Объединим все уязвимости из списка HackerOne в типы:  Injection Broken Authentication Sensitive Data Exposure Security Misconfiguration Получается, что для создания подходящей лаборатории для исследований достаточно найти 3 уязвимых приложения. Injection — метод эксплуатации уязвимостей, позволяющий добавить в обрабатываемые приложением данные свои команды для исполнения. Это может привести к различным последствиям от получения доступа ко всем ресурсам приложения до выполнения кода на стороне сервера. Тестовое приложение текущего раздела будет содержать уязвимость, которая позволяет инжектить собственный python код в код приложения. В качестве тестового рассмотрим приложение, которое было использовано на соревновании «Real World CTF». Приложение предоставляет пользователю информацию о книгах.          Попробуем выяснить, какая структура у данного приложения. Отправим любой HTTP запрос с помощью BurpSuite Community, получим следующее:  Форма логина и страница admin представляет собой одну и ту же страницу — «Login». Стандартные тесты на типичные уязвимости для этой формы не принесли результата, также не подошли стандартные пароли. Вероятно, это не является вектором для атаки. Обратимся к подсказке, которую оставили создатели уязвимого приложения. Подсказка заключается в исходном коде приложения. Скачать его можно по адресу «source.zip». Таким образом, у нас есть полностью работоспособное приложение, которое можно использовать для локального исследования и поиска уязвимостей/недочетов, которые допущены при его написании.  Нас интересуют только файлы, которые содержат код: После анализа исходного кода становится ясно, что приложение использует фреймворк для создания веб-приложений Flask. Известно, что этот фреймворк может запускать приложение в 2х режимах - debug и release. В debug версии стандартный порт - 5000. Проверим, используется ли этот порт на сервере: Похоже, что запущен еще один вариант приложения. Возможно, это может быть полезно для проверки версий атак на приложение. Поищем уязвимые части исходного кода. Файл, который представляет наибольший интерес:  .\views\user.py Уязвимость находится в отрезке кода, который представлен выше на скриншоте. Проблема данного кода заключается в том, что декоратор @login_required указан в неверной последовательности, из-за чего его использование бессмысленно. Любой пользователь приложения может использовать код, который вызывается через обращение к /admin/system/change_name/. Так же есть кусок кода, который так же может быть интересен: В исходнике используется часть Lua кода для работы с Redis. Данные инициализируются прямо из токена, который отправляет на сервер пользователь. Атака на приложение может быть проведена через Redis. Данные из токена в дальнейшем будут отправлены на обработку модулю python — pickle. Это можно использовать для инжекта кода. Уязвимость заключается в том, что в технологическом стеке приложения может быть использована неверная конфигурация или может содержаться общеизвестная уязвимость, для которой не был применен патч. Security misconfiguration может быть использована для получения чувствительной информации из веб приложения — конфиги, исходники и т.д. Снова будем использовать задание из соревнования «Real World CTF». Приложение представляет собой простой загрузчик файлов и может быть использовано для загрузки картинок из любого источника: Проверим интерфейс на возможность чтения локальных файлов, к примеру, file:///etc/passwd. Этот прием нам поможет выяснить есть ли уязвимость из заголовка в этом задании. Результат можно увидеть ниже: Задание подразумевает возможность заставить сервер выполнять команды, которые мы ему сообщаем, благодаря добытой с помощью эксплуатации уязвимости информации. Поэтому следующим шагом нам будет полезно узнать, как именно приложение запущено на сервере. С помощью команды file:///proc/self/cmdline можно получить строку запуска приложения: Приложение работает с использованием uwsgi-сервера и может использовать соответствующий протокол для трансляции данных от сервера к приложению и наоборот. Сервер работает через сокет 8000. Рабочая директория приложения - «/usr/src/rwctf». Для завершения атаки достаточно научиться создавать команды для uwsgi, с помощью которых можно будет управлять сервером.  Broken Authentication - уязвимость, которая может быть использована для доступа к ресурсам приложения в обход системы разграничения доступа. Sensitive Data Exposure - уязвимость, которая может быть использована для доступа к чувствительным данным приложения. Это могут быть конфигурации приложения, логины и пароли от сторонних сервисов и т.д. Следующее приложение, которое будет изучено, собрало максимальное количество уязвимостей из искомого списка. Данное Приложение было использовано на соревновании «35с3 CTF». Оно предоставляет минимальный интерфейс для регистрации пользователей и получения доступа к закрытой  части. Это выглядит следующим образом: Поля ввода не принимают ничего, кроме корректной последовательности данных. Попробуем проверить, насколько безошибочно настроен сервер для обработки данных. Запустим инструмент dirbuster, чтобы найти список директорий, которые относятся к приложению. В итоге была найдена директория uploads, которая возвращает HTTP код 403. Модифицируем путь c помощью специальных символов файловой системы. Для этого просто добавим символ перехода в директорию на уровень выше: /uploads../: Похоже, что мы одновременно нашли все уязвимости. Нам не нужно вводить логин и пароль для доступа к данным приложения. Мы имеем полный доступ к исходному приложения. Теперь необходимо найти способ выполнить свои команды на сервере. Здесь можно использовать подход из первого задания. Содержимое данной статьи может быть использовано в качестве лабораторной работы для тех, кто только начинает путь поиска уязвимостей в веб-приложениях. С их помощью можно получить базовые практические навыки тестирования веб-приложений и приобрести первый самостоятельный опыт в данной сфере. Disclamer: Все использованные приложения принадлежат их авторам. Информацию по топу уязвимостей можно найти здесь. Интересно развиваться в данном направлении? Узнайте больше о профессиональной программе «Безопасность веб-приложений», приходите на День Открытых Дверей и запишитесь на бесплатный демо-урок «Основы технологий, необходимые для понимания уязвимостей. Классификация OWASP TOP 10».  CRM/Email-маркетолог