Pull to refresh
«Лаборатория Касперского»
Ловим вирусы, исследуем угрозы, спасаем мир

Security Week 40: уязвимости в CMS Drupal и не только

Reading time5 min
Views3.7K
На прошлой неделе разработчики CMS Drupal закрыли (новость, подробнее у них на сайте) сразу две критические уязвимости. Обе проблемы затрагивают Drupal версий 7.x и 8.x. Наиболее серьезная уязвимость была обнаружена во встроенной системе отправки e-mail (DefaultMailSystem::mail()). Можно задействовать ее таким образом, что при обработке сообщения появляется возможность выполнения произвольного кода. Виной тому, как обычно, отсутствие должной проверки ряда переменных.

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

Такие новости обычно не попадают в дайджест: ну нашли, ну закрыли, молодцы! Но как минимум раз в год стоит посмотреть на самые популярные системы управления сайтом и понять в перспективе, как там обстоят дела с безопасностью. Есть ли фрагментация версий CMS, похожая, например, на фрагментацию платформы Android? Так ли все плохо с безопасностью, как, например, в индустрии тех IoT-устройств, которые вроде и вовсе не IoT-устройства, а роутеры и камеры? Давайте посмотрим.

Для начала нужно понять, куда смотреть. Достаточно подробную информацию об использовании той или иной CMS дает сайт Web Technology Surveys. Авторы ресурса регулярно сканируют 10 миллионов наиболее посещаемых сайтов в Интернете (по рейтингу сервиса Alexa) и анализируют используемые системы управления контентом. Общие результаты исследования можно посмотреть на этой странице, вот график оттуда:


Ну, во-первых, информацию о CMS для 46,1% сайтов получить не удалось, точнее, там не используется ни одна из систем, которые данный сервис может надежно идентифицировать. Среди тех сайтов, где CMS была определена, безусловным лидером является Wordpress, этакий Android CMS-рынка. Второе и третье места со значительным отставанием занимают Joomla и Drupal, а дальше в Top10 идут в основном сервисы, предлагающие создание готового сайта на собственной платформе, — для тех, кому надо попроще и побыстрее. Совокупно Joomla, Drupal и Wordpress установлены на 68,8% сайтов с известной CMS, или 37,2% вообще всех сайтов из исследуемых 10 миллионов.

Налицо фрагментация уже на уровне выбора CMS: явным лидером является Wordpress, но и он установлен только на трети онлайновых ресурсов, а половина сайтов вообще работает непонятно на чем. Возможно, там хмурый админ до сих пор олдскульно закачивает статические HTML через FTP. Выводы из этого многообразия сделать трудно: с одной стороны, фрагментация усложняет жизнь атакующим, с другой — никто толком не знает, как обстоят дела с безопасностью примерно половины Интернета. В криптографии самописные алгоритмы шифрования давно приравнены к остро заточенным граблям. Должно ли в веб-менеджменте быть по-другому?

Посмотрим на распределение версий для трех самых популярных CMS. Вот распределение для Wordpress. w3techs обновляют свои отчеты ежедневно, так что информация ожидается самая свежая.


Как-то скучно даже. Посмотрим на детализацию актуальной версии 4.х:


Чуть больше 70% веб-сайтов на Wordpress используют (на дату публикации) самую современную версию (без учета регулярных обновлений основного релиза). Это, конечно, более приятное распределение, чем у Android, где актуальную версию 8.х используют 19,2% устройств, но и не так много, как хотелось бы.

А есть чего опасаться? Посмотрим в историю версий Wordpress. Версия 4.9 была выпущена 15 ноября 2017 года, то есть уже почти год Wordpress 4.8 и более рание версии являются устаревшими. С момента выпуска версии 4.9 как минимум четыре обновления CMS были направлены на исправление уязвимостей. Насколько серьезен риск каждой из них — предмет для более детального исследования, хотя совсем уж критических багов за прошедший год не наблюдалось. Тем не менее, июльский релиз 4.9.7 закрывает уязвимость, при некоторых условиях позволяющую удалять файлы за пределами папки Uploads.

Посмотрим, как дела у героя прошлой недели — CMS Drupal.


Такие дела. Последнюю версию Drupal 8.x используют 11,8% сайтов из тех, что вообще пользуются Drupal. Наиболее популярным является предыдущий (справедливости ради отметим — поддерживаемый) релиз 7.х. Детализацию по конкретным релизам в рамках основной ветви w3techs не дает, так что предположим, что все уже обновились (это, конечно, смелое предположение). В любом случае почти 10% сайтов на Drupal используют неподдерживаемые версии 4.х–6.х.

Ситуация для CMS Joomla следующая:


Актуальная версия Joomla 3.8.13 была выпущена совсем недавно — 9 октября. Можно посмотреть, какая доля сайтов обновилась на самую последнюю версию за такой короткий срок.


14,1% от всех пользователей ветви 3.8. Или 5,8% всех пользователей Joomla — это те, кто успел обновить сайт до самой последней версии за 13 дней. Какие последствия бывают, если не обновлять CMS вовремя? Переключусь обратно на примеры для Wordpress, так как это и самая популярная, и самая взламываемая система управления веб-контентом. Так вот (внезапно), сообщения о практическом угоне сайтов для вредоносной активности в большинстве своем упоминают не основной код Wordpress, а его плагины.

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

И дело не только в плагинах. Неоднократно в качестве работающего метода атаки на сайты Wordpress упоминается брутфорс пароля (например, здесь и тут). И эта проблема тоже находится за пределами возможностей разработчиков Wordpress. Затруднить брутфорс и не использовать простейшие пароли — задача администратора и пользователей сайтов, а не разработчиков.

Что бывает, когда сайт успешно взламывают? Выше я ссылаюсь на новость про установку майнеров, хотя чаще всего на сайтах появляются классические вредоносные скрипты. Показательный случай произошел летом этого года: в июле была взломана торговая площадка CoinDash, причем прямо в ходе сбора средств в рамках ICO. Как именно взломали сайт — не сообщается, это не обязательно могла быть уязвимость в Wordpress. Но результат очевиден: в первой фазе сбора средств от привилегированных участников на сайте просто подменили номер кошелька для перевода средств, в результате чего 7,7 миллиона долларов в криптовалютном эквиваленте ушли к злоумышленникам. На Reddit по этому поводу есть интересная дискуссия: не надежнее ли будет в ответственных случаях делать статичную страницу? Ох, не уверен, что надежнее.

По результатам этого мини-исследования возникает понятный вопрос: а так ли обязательно обновлять код CMS, если критические уязвимости бывают не всегда, взлом сайтов часто производится через плагины, а то и вовсе через брутфорс паролей? Как и в случае с роутерами, реальную пользу приносит комплекс мер: обновление CMS, пересмотр списка установленных плагинов и регулярное обновление действительно необходимых, изменение URL админки, сильные пароли, многофакторная аутентификация, да и просто аудит пользователей. Безопасность веб-сайта (да и чего угодно) — это процесс, а не результат.

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

Disclaimer: Мнения, изложенные в этом дайджесте, могут не всегда совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.
Tags:
Hubs:
Total votes 13: ↑13 and ↓0+13
Comments2

Articles

Information

Website
www.kaspersky.ru
Registered
Founded
Employees
5,001–10,000 employees
Location
Россия