Как я нашел свою первую уязвимость?

в 11:16, , рубрики: cms, hacking, url, безопасность веб-приложений, информационная безопасность

Предисловие

Всем привет. Мне 20 лет. Еще недавно я учился в лицее и готовился поступать в медицинский ВУЗ, а сейчас я — фулстэк разработчик в одной американской компании. На самом деле я очень рад, что с медициной у меня не вышло — программирование было моим хобби, а сейчас я могу им заниматься постоянно. Сейчас я хотел бы написать скорее не об успехе в IT. Прямо сейчас я хочу поговорить о том, как я прочитал пару книг по уязвимостям (для защиты своих проектов) и мне удалось применить эти знания на практике.

Дисклеймер

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

Как все начиналось

Был вполне обычный день. Я выполнил несколько задач на работе и заварил себе чашку кофе. За одно решил прочитать одну статью про деплой приложения на AWS, которую некогда репостнул себе в вк (кстати, статью я так и не прочитал). В колонку справа от статьи выведено несколько других статей и партнерский баннер на хостинг-провайдера.

image

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

Если сравнить промокод, который находится в поле для ввода и в адресной строке — увидим что они полностью совпадают.

image

Что мы с этим можем сделать?

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

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

image

Следущий шаг — смотрим HTML-код. ПКМ по полю для ввода -> Просмотр кода элемента.

image

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

image

Результат: только что мы нашли xss-уязвимость на сайте хостинг-провайдера.

И что дальше?

Думаю стоит пойти глубже. Ссылка — как-то мелко и не интересно. Мы же хотим это все рассказать владельцам сервиса и, в идеале, получить вознаграждение (компания, кстати, не имеет bug bounty, а значит все это не оплачивается, но тогда я еще об этом не знал). Попробуем разместить блок, застиллизовать его и вставить изображение. Что для этого нужно? все то же — менять url.

Думаю описывать html и css не стоит, поэтому я просто положу тут то, что вышло. Хабр блокирует часть тегов, другие отбрасывает — не могу выложить код ссылки сюда.

image

Выложу сюда ссылку. Не знаю работает ли она в данный момент, но при выкладывании поста работала. Кому надо — вытащит ссылку и распарсит.

Вознаграждение

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

Как можно использовать эту уязвимость?

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

Что забыли сделать разработчики:

Все просто — валидировать пользовательский ввод. SQL-Inj там не проходит — сервис висит на вордпрессе, а он в свою очередь, обрабатывает входящие строки.

Поэтому мы можем:

  1. Сверять с базой промокод при рендере страницы

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

  2. Прогонять через регулярку входной промокод

    /[A-Z0-9]/g — вполне достаточно для валидации значений и защиты от уязвимости. Причем это работает быстрее чем запрос к базе, а эффект не хуже — XSS снята.

Заключение

Владельцы сервиса были уведомлены за 48 часов + 2 дня до этого я вел переговоры по электронной почте и LinkedIn с теми, кто хоть как-то относится к разработке. Все разговоры приходили к: «Скажите нам пожалуйста как вы это сделали, но за уязвимости мы, конечно же, платить не будем.». Так же добавлю, что точно таким же образом сайт принимает сторонние js-скрипты: как через сторонний источник, так и прямым написанием кода, однако во втором случае Google Chrome автоматически обнаруживает xss и рендерит страницу ошибки вместо страницы сервиса.

Надеюсь каждый программист будет валидировать все входные данные и не будет забывать про querystring. А так же уверен что статья была поможет кому-то заблаговременно заметить + исправить эту проблему у себя.

Большое спасибо за внимание.

Автор: EgorVolokitin

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js