От Dos До Rce: О Неуловимом Векторе Атаки

Привет читатели блога Компания ДетАкт ! Меня зовут Омар Ганиев, многие знают меня под прозвищем «Бечед».

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

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



DoS на RCE или 0-day в WordPress

Еще в 2017 году, во время соревнований CTF в Японии, мы с товарищами по команде из LC↯BC сидели в холле отеля посреди ночи и решали задачи.

Пытаясь решить одну из них, я заметил интересное поведение в Wordpress: при многопоточных попытках подбора пароля (/wp-login) сервер через некоторое время начинал давать неполные ответы, а после нескольких десятков запросов возвращался ответ 302 и перенаправлен на страницу установки блога (/wp-admin/install.php).

В ту ночь такое поведение осталось загадкой, но позже нам удалось выяснить, что сайт размещался на виртуальном хостинге, и существовало ограничение на количество запросов к MySQL (MAX_QUERIES_PER_HOUR).

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

Более того, Wordpress проверяет статус установки блога, запрашивая некоторые таблицы из базы данных, и оказывается, что блог не установлен.

Запросов на проверку несколько десятков, и все они должны вернуть ошибку, чтобы функция is_blog_installed вернула false.

От DoS до RCE: о неуловимом векторе атаки

Уязвимый исходный код функции is_blog_installed Это порождает идею для атаки: а что, если звезды сложатся так, что мы сможем отключить базу данных ровно на время работы функции is_blog_installed, а затем тут же вернуть ее к жизни? В этом случае мы можем перейти к процедуре установки блога, и там одним из первых действий является добавление в базу данных нового пользователя с правами администратора.

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

К.

?.

) из админки! Суть уязвимости в том, что код Wordpress не проверял, какую ошибку вернул сервер MySQL, поэтому считалось, что таблица не существует, даже если на ответ на DESCRIBE просто не поступил ответ, или ответ содержал ошибка о превышении лимита запросов.

Основные этапы атаки схематически можно изобразить следующим образом:

От DoS до RCE: о неуловимом векторе атаки

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

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

В итоге, отложив исследование, я вернулся к нему только в 2019 году и решил сообщить о Wordpress: уязвимость была исправлена только через год и получила номер CVE-2020-28037 .



DoS для обхода или как обойти WAF

Помимо анализа безопасности, мы иногда проводим DDoS-тестирование приложений.

Часто приложения защищены фаерволами, что создает интересные эффекты.

Одна из основных проблем классовых решений ВАФ это производительность.

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

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

К чему это приводит? Если инфраструктура настроена таким образом, что межсетевой экран находится «в разрыве», то вся система рушится.

Если фаервол стоит сбоку, то сайт продолжает быть доступен, но фаервол уже не работает! Это означает, что злоумышленники могут свободно искать и использовать уязвимости в приложении, не будучи заблокированными WAF. О каких нагрузках речь? На практике все очень сильно зависит от конфигурации, но даже самый простой HTTP-флуд может обрушить топовый WAF со скоростью атаки около 300 Мбит/сек.



От DoS до RCE: о неуловимом векторе атаки

Журнал проверки WAF во время DDoS-атаки Конечно, наиболее уязвимыми являются «коробочные» решения, которые физически не имеют возможности масштабирования и ограничены мощностью одного устройства.



DoS Админу или как обойти авторизацию

DoS-уязвимости часто проявляются самым неожиданным образом.

Так, во время тестирования одного приложения мы получили от заказчика описание Swagger API. Для начала мы провели стресс-тест и с помощью скрипта отправили оттуда все примеры запросов через Burp Suite. Просматривая историю запросов в Burp, мы заметили аномалию: один из запросов к административному интерфейсу вернул ответ 200 OK. Когда мы попытались повторить это, мы, как и ожидалось, получили ответ 401 Not Authorized. В какой-то момент мы поняли, что аномалия может быть связана с нагрузкой, и решили попробовать ещё раз.

После многократной отправки одного и того же запроса мы внезапно начали получать хороший ответ! На скриншоте видно, что после 140 запросов сервер «сдался» и впустил нас в админку, как в анекдотах про китайских хакеров и пароль «Мао Цзэдун».



От DoS до RCE: о неуловимом векторе атаки

Обход авторизации через DoS Интересно, что в ответе отображается заголовок «DoSFilter: задержано»: это признак использования сервлета DoSFilter на сервере Jetty. Как можно предположить и что подтвердилось в ходе общения с заказчиком, для авторизации в API использовался отдельный сервис.

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



DoS на что угодно

Невыполнение обслуживания какой-либо части системы может привести к множеству неожиданных последствий.

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

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Проводили ли вы DDoS-тестирование своих ресурсов? 27,4% Да 20 64,38% Нет 47 8,22% Остальные 6 Проголосовали 73 пользователя.

14 пользователей воздержались.

В опросе могут участвовать только зарегистрированные пользователи.

Войти , Пожалуйста.

Ну что, пентесты проводили? 50% Да 32 43,75% Нет 28 6,25% Остальные 4 Проголосовали 64 пользователя.

13 пользователей воздержались.

Теги: #информационная безопасность #rce #ddos #уязвимость #программирование #DOS #wordpress #pentest #exploit #exploit #jetty

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.