Привет! Вероятно, тебе когда-нибудь попадались веб-приложения, построенные на «1С-Битрикс: Управление сайтом», и ты задавался вопросом: как это ломать? Вроде бы прошелся по всем известной методичке, но все равно пусто. На прошлой работе я намучился ломать такие сайты, и вследствие выживания в дикой природе «Битрикса» у меня появились свои векторы атак. Я с тобой ими поделюсь — let’s go!
0x00 | Начало
Для начала познакомимся с тем, как появляются самописные скрипты. Когда ты разворачиваешь «Битрикс», предлагается выбрать шаблон под тематику сайта.
На основе этого автоматически загружаются подходящие PHP-скрипты для функционирования тех или иных механизмов.
Но иногда того, что подгрузил «Битрикс», мало. Следовательно, приходится писать PHP-скрипт на основе API «Битрикса» либо без него, именно так создаются самописные скрипты. И периодически приходится обращаться к скрипту через AJAX. Однако разработчик мог допустить уязвимость в коде или написать скрипт для какой-нибудь системной аналитики веб-приложения, поэтому приходится искать такие скрипты. Теперь разберемся, как их искать.
0x01 | Поиск самописных скриптов
AJAX. Иногда используется архитектура SPA (single-page application), когда с основной страницы по одному клику может выскочить, к примеру, форма подписки на рассылку. В таком случае достаточно порыться в коде элемента и найти ajax. Искать можно по словам типа ajax, $.get, $.post, XMLHttpRequest. Далее можно заметить, что в JS-скрипте есть PHP-файл, к которому идет ajax, увидеть, какие параметры query string ему передаются и через какой HTTP-метод.
Фаззинг. Достаточно запустить какой-нибудь ffuf, wfuzz, dirsearch с расширением файла php, inc и найти самописный скрипт.
JS-скрипты. Покопавшись в панели разработчика или отрыв скрипт с фаззинга, можно открыть их в браузере и поискать слова типа .php, .inc, .inc.php, точно так же в них — ajax.
Proxy. Отловить самописные скрипты можно через проксирование трафика, как пример — погулять по сайту и потом открыть Logger в Burp Suite.
0x02 | Что делать дальше
Атака mass assignment
Программные фреймворки и скрипты иногда позволяют разработчикам автоматически привязывать параметры HTTP-запроса к переменным кода или к объектам, чтобы упростить использование такого фреймворка или скрипта. Но иногда это может причинить вред. Мы можем добавить параметры, которые разработчик не предполагал, что, в свою очередь, создаст или перезапишет объекты в коде. Это называется mass assignment
Проще говоря, просто делаем фаззинг на параметры.
После того как ты нашел несколько скриптов, поищем в них параметры.
Это можно сделать двумя способами: поискать параметры в найденном AJAX и с использованием утилит, например paramspider, x8, Param Miner.
0x03 | Атакуем
Когда ты составил список самописных скриптов и определился, какие параметры query string они принимают, можно протестировать сайт на ряд уязвимостей в зависимости от функциональности скрипта.
К примеру, если это подписка на рассылку, значит, он будет ожидать email-адрес — оттуда и можно построить вектор атаки и проверить на XSS таким пейлоадом: mail(<script>alert(0)</script>)@gmail.com
Кейс
В ходе анализа защищенности сайта — про который мне нельзя говорить :( — был обнаружен самописный скрипт через AJAX.
Этот скрипт отвечал за покупку билета, принимая такие данные от пользователя, как номер, почта и т. д. В результате все это накапливалось в переменной "stringData" и отправлялось с помощью метода POST.
Переменные, нужные для хранения пользовательской информации, также воспринимались скриптом как параметр.
В совокупности запрос выглядел так: /include/send-ticket.php?user_name=lolkek
Первое, что пришло мне на ум, — кинуть XSS-пейлоад, но не через метод POST, а через GET. В результате это сработало, и я получил reflected XSS.
Тестировать можно и на другие уязвимости — все, к сожалению, по этому сайту раскрыть не смогу. Обращай внимание на то, что делает скрипт и какие параметры принимает. Не стесняйся также подставлять другие параметры, данные и играть с методами HTTP.
0x04 | Заключение
Мы научились атаковать сайты на «1С-Битрикс» без методички.
Разница в том, что с помощью методички атакуют сам фреймворк, а информация из этой статьи позволяет ловить разработчиков на ошибке. В результате можно найти уязвимость или даже скрипт, с которого — поймать какие-нибудь системные логи.
Напоследок хочу кинуть инфографику:
