Конкурс: Встречаем 2020 статьями по инфобезу.
Вступление
В данной статье хотел бы рассказать о том, как я искал уязвимости в web приложении. Речь пойдёт о довольно не популярной уязвимости - Denial of Service. Эксплуатируя уязвимости данного типа можно "парализовать" сервер, не позволяя ему обрабатывать запросы клиентов.
Всё началось с того, что около месяца назад я получил приглашение приватной компании на одной из Bug Bounty платформ. Меня это заинтересовало, так как программа была довольно свежая, в скоупе был всего один домен, но с другой стороны, это позволяет посмотреть весь функционал за несколько дней и двигаться дальше.
Web приложение
После нескольких часов поиска интересного функционала, я понял, что будет не так просто найти хоть что-то в этом приложении - для авторизации оно использовало Wordpress, а в качестве прокси - Cloudflare. Бесплатного функционала было немного, а само приложение использовалось для управления сайтами на Wordpress.
Первым делом я решил проверить настройки аккаунта, здесь было больше всего шанса что-то найти, но, как я потом понял, я ошибался. Для изменения настроек использовалось API, но проблема была в том, что для каждого аккаунта эндпоинты были разными:
Это сразу исключило большинство типов уязвимостей, таких как IDOR. Единственное, что я нашёл на тот момент - неправильную конфигурацию CORS, но применение этому я найти не смог.
Уязвимость
Во время теста меня заинтересовал функционал добавления API токенов, при создании тебе отправлялось значение, похожее на хеш. С помощью специально подготовленного python скрипта я пытался вызвать Race Condition в надежде увидеть что-то необычное, но ничего изменить не удалось и токены отправлялись корректно. Поставив скрипт в цикл я пошёл проверять другой функционал.
Спустя весь день я не нашёл ничего интересного, и собирался заканчивать. Последний раз взглянув на вкладки Burp Suite, я решил сделать запрос к API, который возвращает все существующие токены. К моему удивлению после минуты ожидания я увидел ошибку 504 Gateway Timeout. Это произошло из-за того, что поставленный мною скрипт создал слишком много токенов, а сервер не имел никаких инструкций на этот счёт и пытался обработать запрос. Я сразу понял, что это может привести к DoS. Немного изменив прошлый скрипт, я сделал 100 одновременных запросов к этому API эндпоинту со своего приватного сервера. Во время этого с ноутбука я делал запросы к сайту, после 10 секунд задержки я решил отменить всё запросы, так как наносить вред мне не хотелось. В итоге сервер не был способен обрабатывать запросы в течение 13 секунд.
Крайне не рекомендуется делать PoC для DoS при этичном хакинге, только при необходимости и с согласия компании.
Другие возможности вызвать Denial of Service
После этого я решил задержаться ещё на пару дней с этой программой. И нашёл ещё две потенциальные уязвимости подобного рода:
1. Запрос с очень большим заголовком вызывал 504 Gateway Timeout с минутой ожидания:
2. Повторный запрос к одноразовому коду аутентификации вызывал эту же ошибку:
Приведу ещё немного сторонних примеров, чтобы побольше осветить эту тему:
1. Сайт позволяет изменять размер изображения,
2. Есть возможность изменять цвет используя hex, в таком случае можно попробовать вызвать reDoS, то есть DoS с regex, указав неправильный цвет по типу #000...(много нулей)00abcdfe -
Заключение
На самом деле вызвать такую уязвимостей не так и сложно, нужно только заставить сервер делать что-то тратя очень много вычислительных ресурсов.
На этом всё. Эта статья не задумывалась как полное руководство по Server Side DoS, но надеюсь, что она помогла вам разобраться в этом типе уязвимостей.
Вступление
В данной статье хотел бы рассказать о том, как я искал уязвимости в web приложении. Речь пойдёт о довольно не популярной уязвимости - Denial of Service. Эксплуатируя уязвимости данного типа можно "парализовать" сервер, не позволяя ему обрабатывать запросы клиентов.
Всё началось с того, что около месяца назад я получил приглашение приватной компании на одной из Bug Bounty платформ. Меня это заинтересовало, так как программа была довольно свежая, в скоупе был всего один домен, но с другой стороны, это позволяет посмотреть весь функционал за несколько дней и двигаться дальше.
Web приложение
После нескольких часов поиска интересного функционала, я понял, что будет не так просто найти хоть что-то в этом приложении - для авторизации оно использовало Wordpress, а в качестве прокси - Cloudflare. Бесплатного функционала было немного, а само приложение использовалось для управления сайтами на Wordpress.
Первым делом я решил проверить настройки аккаунта, здесь было больше всего шанса что-то найти, но, как я потом понял, я ошибался. Для изменения настроек использовалось API, но проблема была в том, что для каждого аккаунта эндпоинты были разными:
Это сразу исключило большинство типов уязвимостей, таких как IDOR. Единственное, что я нашёл на тот момент - неправильную конфигурацию CORS, но применение этому я найти не смог.
Уязвимость
Во время теста меня заинтересовал функционал добавления API токенов, при создании тебе отправлялось значение, похожее на хеш. С помощью специально подготовленного python скрипта я пытался вызвать Race Condition в надежде увидеть что-то необычное, но ничего изменить не удалось и токены отправлялись корректно. Поставив скрипт в цикл я пошёл проверять другой функционал.
Спустя весь день я не нашёл ничего интересного, и собирался заканчивать. Последний раз взглянув на вкладки Burp Suite, я решил сделать запрос к API, который возвращает все существующие токены. К моему удивлению после минуты ожидания я увидел ошибку 504 Gateway Timeout. Это произошло из-за того, что поставленный мною скрипт создал слишком много токенов, а сервер не имел никаких инструкций на этот счёт и пытался обработать запрос. Я сразу понял, что это может привести к DoS. Немного изменив прошлый скрипт, я сделал 100 одновременных запросов к этому API эндпоинту со своего приватного сервера. Во время этого с ноутбука я делал запросы к сайту, после 10 секунд задержки я решил отменить всё запросы, так как наносить вред мне не хотелось. В итоге сервер не был способен обрабатывать запросы в течение 13 секунд.
Крайне не рекомендуется делать PoC для DoS при этичном хакинге, только при необходимости и с согласия компании.
Другие возможности вызвать Denial of Service
После этого я решил задержаться ещё на пару дней с этой программой. И нашёл ещё две потенциальные уязвимости подобного рода:
1. Запрос с очень большим заголовком вызывал 504 Gateway Timeout с минутой ожидания:
1. Сайт позволяет изменять размер изображения,
example.com/image?x=100&y=100 - в таком cлучае мы можем попробовать изменить x и y до больших значений, что вызовет DoS -
Ссылка скрыта от гостей
.2. Есть возможность изменять цвет используя hex, в таком случае можно попробовать вызвать reDoS, то есть DoS с regex, указав неправильный цвет по типу #000...(много нулей)00abcdfe -
Ссылка скрыта от гостей
.Заключение
На самом деле вызвать такую уязвимостей не так и сложно, нужно только заставить сервер делать что-то тратя очень много вычислительных ресурсов.
На этом всё. Эта статья не задумывалась как полное руководство по Server Side DoS, но надеюсь, что она помогла вам разобраться в этом типе уязвимостей.
Последнее редактирование:
