Путь к полному захвату управления начался с простой проблемы

Путь к полному захвату управления начался с простой проблемы

Изображение: recraft

Несколько векторов атаки, собранных вместе, позволяли полностью перехватить управление платформой Reezonly LMS. С деталями — пентестер «Кросс технолоджис» Тимофей Катков.

Кратко

Мы выявили в коде платформы для управления обучением три уязвимости:

  • Недостатки процедуры авторизации, которые позволяли провести тайминг-атаку (BDU:2025-12424);
  • Непринятие мер по защите структуры веб-страницы, открывавшее возможность для XSS-атак (BDU:2025-12423);
  • Ошибки разграничения доступа (BDU:2025-12425).

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

Разработчики платформы Reezonly сообщили, что в настоящее время уязвимости устранены. Согласно данным на портале ФСТЭК, чтобы минимизировать риски, пользователям рекомендовано обновить систему.

Мы выявили уязвимости в рамках проекта по внешнему анализу защищенности. Анализ подразумевает, что команда ищет в инфраструктуре заказчика максимум незащищенных точек. Reezonly LMS была одной из составляющих инфраструктуры.

Неустойчивость к тайминг-атакам

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

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

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

Уязвимость к XSS-атакам

Далее мы выяснили, что на соседнем виртуальном хосте располагалась административная панель сайта. Ее наличие означало, что можно повысить привилегии пользователя за счёт атаки на браузер администратора. Мы попробовали провести XSS-атаку.

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

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

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

Ошибки разграничения доступа

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

Наше внимание привлекло неожиданное поведение сервера при OPTIONS-запросах. В отличие от GET/POST-запросов, которые в основном возвращали **403 Forbidden**, запросы OPTIONS возвращали структурированный ответ и позволяли выполнять действия, требующие административного уровня доступа.

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

Опасная комбинация

Стало понятно, что довольно типичный захват профиля открывает перед злоумышленниками два независимых пути к захвату административного интерфейса системы и всех его функций:

  • Использование XSS внутри административного интерфейса. Здесь пришлось бы подождать, пока администратор удалит «зараженного» пользователя с вредоносным именем, после чего выполнить JavaScript-код в его браузере и увести его токен.
  • Некорректная обработка OPTIONS-запросов. Этот путь не требовал ожидания и позволял эксплуатировать некорректное разграничение доступа в API для прямого изменения роли.

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

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

Рекомендации по защите

Разработчики Reezonly LMS сообщили нам, что на данный момент все уязвимости устранены. По официальной информации из Банка угроз ИБ ФСТЭК, чтобы минимизировать риски, пользователям рекомендовано обновить систему.

Более подробное описание уязвимостей и рекомендации по их устранению — в описаниях:

  • Недостатки процедуры авторизации, которые позволяли провести тайминг-атаку — BDU:2025-12424;
  • Непринятие мер по защите структуры веб-страницы, открывавшее возможность для XSS-атак — BDU:2025-12423;
  • Ошибки разграничения доступа — BDU:2025-12425.
Кросс технолоджис
Автор: Кросс технолоджис
Мы — интегратор решений и поставщик сервисов для информационной безопасности. Защищаем цифровые активы бизнеса с 2011 года.
Комментарии: