✔Друпалгеддон-2. Подробно разбираем новую уязвимость в Drupal - «Новости»

Содержание статьи

• Детали

Вот и?настал час второго «Друпалгеддона»! Это новая версия наделавшей в свое время много шума критической уязвимости в одной из самых популярных CMS. Найденная брешь позволяет абсолютно любому незарегистрированному пользователю всего одним запросом выполнять любые команды на целевой системе.

Проблему обостряет то, что под угрозой оказались все наиболее актуальные версии приложения веток 7.х и 8.х, вплоть до 8.5.0. Сложно даже представить, сколько потенциально уязвимых целей доступно в данный момент злоумышленникам.

INFO

Уязвимость получила?идентификатор CVE-2018-7600 и высочайший статус опасности.

Разработчики выпустили патч еще 28 марта 2018 года, однако до 12 апреля в паблике не наблюдалось ссылок на работающий PoC или деталей проблемы. Стоит отдать разработчикам должное за патч, который был очень лаконичным и не давал?прямого ответа на вопрос, в каком месте стоит искать проблему.

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

Воспроизводим уязвимую систему

Протестировать уязвимость несложно. Само приложение очень просто устанавливается, а кроме?того, у Drupal имеется официальный репозиторий на Docker Hub, и развернуть контейнер с нужной версией CMS можно буквально в пару команд.

Развернем сначала копию MySQL, хотя можно и без него, Drupal поддерживает работу с SQLite.

$ docker run -d -e MYSQL_USER="drupal" -e MYSQL_PASSWORD="Q0b6EFCVW4" -e MYSQL_DATABASE="drupal" --rm --name=mysql --hostname=mysql mysql/mysql-server
[/code]

Теперь сам контейнер с CMS. Я решил использовать последнюю уязвимую версию — 8.5.0.

$ docker run -d --rm -p80:80 -p9000:9000 --link=mysql --name=drupalvh --hostname=drupalvh drupal:8.5.0
[/code]

Дальше открываем в браузере адрес твоего?докера и переходим к установке.

Откидываемся на спинку кресла и ждем завершения инсталляции.

Наслаждаемся готовым к исследованию приложением. Если хочешь возиться с отладкой, как я, то можно установить Xdebug. Делается это тоже?буквально парой команд.

$ pecl install xdebug
$ echo "zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so" > /usr/local/etc/php/conf.d/php-xdebug.ini
$ echo "xdebug.remote_enable=1"  /usr/local/etc/php/conf.d/php-xdebug.ini
$ echo "xdebug.remote_host=192.168.99.1"  /usr/local/etc/php/conf.d/php-xdebug.ini
[/code]

Не забудь поменять IP-адрес 192.168.99.1 на свой. Дальше перезагружаем конфиги Apache.

$ service apache2 reload
[/code]

В качестве отладчика я использую JetBrains PhpStorm.

Для начала обратимся к патчу, который исправляет уязвимость.

Здорово, не правда ли? Разработчики просто добавили фильтрацию всех отправляемых юзером?данных.

И все же кое-какой свет на уязвимость это исправление может пролить. Посмотрим на сам код процедуры, которая отвечает за проверку. Данные передаются в метод sanitize, который вызывает stripDangerousValues.