Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Взлом WordPress Первые Тревожные Сигналы






Взлом WordPress и как с этим бороться.

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


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

Взлом WordPress Первые Тревожные Сигналы

Несмотря на то что WordPress развивается уже достаточно давно и код все время анализируется, уязвимости в движке находят постоянно, и можно предположить, что продолжат находить и в будущем. Нужно отдать должное разработчикам: они оперативно реагируют на все сообщения и устраняют проблемы, а простота обновления позволяет администраторам легко обезопасить свой ресурс. Хотя анализ показывает, что далеко не все спешат обновляться. Но вот основные проблемы безопасности WP не в самом движке.

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

Итак, имеем несколько сай тов на WP разного назначения, размещенных в VDS. Стандартная связка PHP5 + Apache 2 + MySQL. ОС Ubuntu 14.04.3 LTS. Также были установлены панель управления хостингом Vesta Control Panel и phpMyAdmin. Последним, впрочем, никто не пользовался, и, по-моему, о его существовании даже не знали, хотя журналы показали, что и то и другое тоже пытались взломать. На момент атаки движок блога, активные плагины и Vesta были обновлены до актуального состояния. Используемые темы в большинстве взяты из бесплатного каталога и подогнаны под свои условия. Бэкап SQL делался еженедельно, бэкап фай лов — очень давно. Все это работало до поры до времени.

Первый сигнал поступил от MySQL. VDS, до этого не сильно нагруженный, перестал тянуть. В результате сервер баз данных просто отвалился, а вместе с ним и прекратили отвечать сай ты. При этом количество посетителей на счетчике вписывалось в стандартную посещаемость. Перезапуск восстановил работу, но нагрузка, показанная htop, была очень высокой.

Следующий сигнал поступил от поисковых систем. Причем сообщения и, очевидно, алгоритмы работы у Яндекса и Google отличаются и по-разному полезны. Яндекс сообщил, что на сай те обнаружен вредоносный контент, в панели веб-мастера сай т был помечен соответствующим значком, указан предполагаемый тип (троян JS), и в поиске выводилась информация о том, что ресурс может навредить. Сразу скажу, что код, который раздражал Яндекс, был най ден в фай ле заголовков почти всех тем в фай ле header.php, и после того, как он был убран, все сай ты в течение одного-трех дней были признаны чистыми. Хотя в это время битва еще продолжалась.

Google прислал сообщение спустя шесть часов после Яндекса, но отметил, что на сай те обнаружен «взломанный контент», в панели можно было просмотреть список подозрительных фай лов (на момент получения письма большинство было най дено и удалено). Информация сама по себе интересна, так как в ней указаны новые фай лы, оставленные хакером, на которые нет прямых ссылок на сай те. Такие фай лы, скорее всего, однозначно нужно будет удалять. Гугл в сообщении предлагает ссылку на «Инструмент для восстановления взломанных сай тов», позволяющий просмотреть, как выглядит сай т, и рекомендации.

После удаления фай лов необходимо вручную отправить на перепроверку те сай ты, у которых при использовании site: в строке поиска показывает «Возможно, этот сай т был взломан». Позже Гугл убрал отметку об опасности части сай тов и начал выдавать сообщение о том, что на сай тах появилось большое количество ошибок. Проблема 404 возникла либо из-за некорректно внедренного кода, когда часть URL не работала, либо из-за того, что код ссылался на вредоносный фай л, который уже был най ден и удален.

Забегая вперед, скажу о результате. Атака шла с нескольких IP и массированно началась за три дня до взлома. Обнаружилось большое количество лишних фай лов с расширением php, которые были разбросаны по всем каталогам, плюс каталог gopni3d с кучей HTML-фай лов внутри. Здесь и шелл, и бэкдор-загрузчик, и дорвей, и рассыльщик спама. Внедрен PHPи JS-код в тему header.php и некоторые фай лы WP, включая wp-config.php. Изменен фай л.htaccess. В WP появились две дополнительные учетные записи с правами администратора. Каталог SMTP-сервера /var/spool/exim4/input был завален большим количеством спам-писем.

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






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.