Привет! Вероятно, тебе когда-нибудь попадались веб-приложения, построенные на «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С-Битрикс» без методички.

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

Напоследок хочу кинуть инфографику: