10 Шагов от Поиска Уязвимости до Удаления Вредоносного Кода (ВИРУСА) с сайта WordPress. Wordpress уязвимости
Уязвимости WordPress и как с ними бороться
WordPress – это одна из самых популярных CMS, с помощью которой сделаны миллионы сайтов по всему миру. Кроме того, разработчики предоставляют открытый код CMS, и любой желающий может его просмотреть и изменить. Множество программистов, редактируя что-либо, могут натыкаться на какие-то уязвимости WordPress или недоработки, а после написать об этом разработчикам. Но не все предпочитают докладывать о найденных уязвимостях и ждать пока разработчики выпустят очередное обновление. Эти люди используют баги во вред другим вебмастерам, которые используют WordPress.
Если найти какую-то дыру в безопасности такой популярной CMS, то можно взломать огромную кучу сайтов и распространять там спам или рекламу. Конечно, не любой случай взлома вашего сайта — это баг в системе. Скорее всего, вы сами совершили какой-то промах, например, установили вирусное ПО или использовали простейший пароль.
Способы обезопасить себя от взлома
- Скройте данные о том, какая версия WordPress у вас установлена. Если вы уже давно не обновлялись, то стоит обязательно скрыть данные об этом, ведь старые версии имеют уже давно найденные уязвимости и баги, которых нет в последних обновлениях. Узнав, что вы используете WordPress годичной давности, у злоумышленника появляется гораздо больше шансов взломать ваш ресурс. Например, установите плагин HideMyWP – к сожалению, он платный, но зато скрывает все следы использования WordPress.
- Кардинально измените правила для входа на сайт. Основные уязвимости WordPress в легкой и привычной для всех структуре и изменить ее будет отличным решением. Стоит изменить адрес стандартной страницы входа на свой сайт. Если на ваш сайт еще можно зайти просто приписав к адресу главной страницы «wp-login» или «wp-admin», то обязательно исправьте это. Можно установить бесплатный плагин WP Cerber, в котором есть множество разных настроек по защите своего сайта — это изменение адреса страницы входа, ограничение на количество попыток, блокировка отдельных IP адресов и возможность добавления капчи в форму отправки комментариев.
- Используйте большие и сложные пароли. Обычно попытки получить доступ к сайту хакеры совершают не вручную, а с помощью специальных скриптов и простые пароли вроде «qwerty» или «123456» – это очень легкий способ заразить свой сайт вирусами. Вам также будет интересно узнать о том, как можно хранить пароли, чтобы не забыть их. Об этом мы рассказали тут.
Какими страшными бы не были уязвимости WordPress, но почти всегда ресурсы взламывают из-за пользовательских ошибок.
Если вы нашли ошибку, то выделите её и нажмите клавиши Shift + Enter или нажмите сюда, чтобы проинформировать нас.
Также по этой теме:
wpuroki.ru
Уязвимости нулевого дня в Wordpress и Vanilla Forums позволяют удаленно взламывать сайты
Изображение: Andrew Abogado, CC BY 2.0
Исследователь информационной безопасности Давид Голунски (Dawid Golunski) опубликовал данные о критических уязвимостях в WordPress — они позволяют осуществлять удаленное выполнение shell-команд и сброс пароля администратора через подмену заголовка Host. Кроме того, исследователь рассказал о двух аналогичных критических уязвимостях в открытом продукте Vanilla Forums.
Уязвимость WordPress
Обнаруженная Голунски уязвимость (CVE-2017-8295) затрагивает все версии WordPress, включая сборку 4.7.4. По словам исследователя, он неоднократно передавал информацию о проблемах безопасности разработчикам продукта, однако они до сих пор не выпустили официальное исправление.Атака подробно описана в специальном бюллетене безопасности, опубликованном Голунски. Ее суть заключается в использовании логической ошибки в механизме восстановления пароля Wordpress. Когда пользователь запрашивает такую смену, WordPress генерирует уникальный секретный код и отправляет его на email, который хранится в базе.
При отправке этого сообщения для получения имени хоста сервера используется переменная SERVER_NAME — это нужно, чтобы установить значения в поля From/Return-Path. В поле «From» хранится адрес отправителя, а в «Return-Path» — адрес, на который должны доставляться сообщения 'bounce-back', они генерируются в случае сбоя отправки.
По словам Голунски, злоумышленник может отправить специальный HTTP-запрос с предустановленным значением hostname (например, attacker-mxserver.com) и одновременно инициировать процесс сброса пароля для какого-либо пользователя — к примеру, администратора сайта.
Поскольку имя хоста в HTTP-запросе — это домен, контролирующийся атакующим, поля From и Return-Path в письме для сброса пароля будут изменены таким образом, что в них будет включен почтовый адрес, связанный с доменом хакера — например, [email protected] вместо [email protected].
Письмо с кодом для сброса пароля будет все равно отправлено на адрес жертвы, однако при определенных условиях получить его сможет и атакующий.
- Если жертва ответит на письмо, то ответ уже будет отправлен на адрес взломщика (теперь он хранится в поле From), а в истории переписки сохранится ссылка на сброс пароля.
- Если по какой-то причине доставка письма жертве не удастся, то сообщение о сбое будет автоматически перенаправлено на адрес злоумышленника (он указан в Return-Path).
- Другой возможный сценарий — для того, чтобы первоначальное сообщение не было доставлено жертве, злоумышленник может провести DDoS-атаку на email-сервер целевого пользователя или отправить на его адрес большое количество писем, добившись того, что почтовый адрес больше не сможет принимать сообщения. Таким образом произойдет сбой доставки, и сообщение об это будет доставлено атакующему.
Поскольку официального патча для закрытия уязвимости не существует, администраторов сайтов на WordPress рекомендуется обновить конфигурацию, активировав опцию UseCanonicalName — это позволит установить статическое значение SERVER_NAME и сделает проведение атаки невозможным.
Что не так с Vanilla Forums
Спустя неделю после обнаружения ошибки безопасности в WordPress, Голунски также опубликовал информацию о двух критических уязвимостях в популярном open source софте Vanilla Forums. Первая из них (CVE-2016-10033) открывает возможность удаленного исполнения кода, а вторая (CVE-2016-10073) аналогична уязвимости в WordPress и позволяет проводить атаки по перехвату сообщений для сброса пароля. Для обеих ошибок в данный момент отсутствует патч. Уязвима в том числе последняя версия Vanilla Forums 2.3, исследователь уверен в том, что предыдущие версии также уязвимы.
По мнению Голунски, возможность удаленного выполнения shell-команд появилась в Vanilla Forums из-за того, что разработчики продукта до сих пор используют уязвимую версию популярной open source-библиотеки для отправки email-писем PHPMailer. Исследователь обнаружил уязвимости в январе 2017 года и передал информацию разработчикам, ошибки не были исправлены и спустя примерно пять месяцев Голунски опубликовал информацию о них. Аналогичная уязвимость была ранее обнаружена исследователем в Wordpress.
В прошлом году исследователь отчитывался об обнаружении критической уязвимости (CVE-2016-10033) в библиотеке PHPMailer, которая позволяла осуществлять удаленное исполнение shell-команд в контексте веб-сервера — это приводит к компрометации атакуемого веб-приложения. Голунски также подготовил видео, из которого становится понятно, что для атаки на Vanilla Forums подходит старый эксплоит для PHPMailer.
Исследователь отмечает, что уязвимость может быть эксплуатирована даже в том случае, если Vanilla Forums установлен на веб-сервере Apache с несколькими включенными vhosts, а сам атакуемый софт не является виртуальным хостом по умолчанию.
До тех пор пока разработчики Vanilla Forums не выпустили обновление, Голунски рекомендует администраторам сайтов, которые используют этот софт, установить в качестве email-адреса отправителя заранее заданное статическое значение — это заблокирует использование заголовков Host.
Для предотвращения атак с использованием описанных уязвимостей WordPress и Vanilla Forums эксперты Positive Technologies рекомендуют использовать специализированные инструменты защиты — в частности, защитный экран уровня приложений PT Application Firewall позволяет отражать попытки эксплуатации этих ошибок безопасности.
что дальше? / Блог компании Positive Technologies / Хабр
Если вы часто читаете IT-новости, то наверняка уже устали от страшилок об очередной уязвимости, которая нашлась в популярной OS / СУБД / CMS / кофеварке. Поэтому данный пост посвящен не самой уязвимости, а наблюдению за тем, как люди регируют на неё.
Однако сначала — несколько слов о «виновнице торжества». Критическая уязвимость популярном блоговом движке WordPress была найдена в сентябре финскими специалистами из компании с весёлым названием Klikki Oy. Используя эту дыру, хакер может вести в качестве комментария к блогу специальный код, который будет выполнен в браузере администратора сайта при чтении комментариев. Атака позволяет скрытно перехватить управление сайтом и делать разные неприятные вещи под админским доступом.
Вот как легко это выглядит на практике. Заходим в блог на WordPress и вводим нехороший комментарий:
Далее мы видим, как специально сформированный комментарий позволяет обойти проверку и провести XSS-атаку:
После захвата админских полномочий злоумышленник может запускать свои коды на сервере, где хостится атакованный блог – то есть развивать атаку по более широкому фронту. Тут самое время вспомнить, что буквально недавно 800 тыс. кредиток было украдено банковским трояном, который распространялся через сайты на WordPress.
Данная уязвимость касается всех версий WordPress от 3.0 и выше. Проблема решается обновлением движка до версии 4, где такой проблемы нет.
Ну а теперь собственно о реакции. Финские эксперты по безопасности, обнаружившие уязвимость, сообщили о ней вендору 26 сентября. На момент написания этой статьи, то есть два месяца спустя после обнаружения, обновилось не более 16% пользователей WordPress (см. диаграмму на заглавной картинке поста). Из чего финские эксперты делают вывод, что все остальные 84%, то есть несколько десятков миллионов пользователей данного движка во всем мире, остаются потенциальными жертвами.
На самом деле жертв будет конечно меньше, потому что есть небольшое дополнительное условие для эксплуатации – нужна возможность комментирования постов или страниц (по умолчанию доступно без авторизации). Однако нас тут интересует именно время жизни уязвимости, и в данном случае это можно наблюдать в реальном времени — следить за статистикой обновления WordPress можно здесь. Хотя вы наверняка и так уже поняли смысл этих цифр: пока гром не грянет, мужик не перекрестится.
Мы также следим за попытками злоумышленников эксплуатировать эту уязвимость «в дикой природе». Для этого применяется сеть выявления атак на приложения на основе PT Application Firewall. Механизм выявления атак, основанный на анализе аномалий, в данном случае отработал прекрасно, и нам даже не пришлось добавлять сигнатуры. Иными словами, PT AF выявлял этот «0 day» с самого начала:
На данный момент попытки эксплуатации описанной уязвимости уже встречаются. Их пока нельзя назвать массовыми – но если у вас старый WordPress, стоит всё-таки обновиться.
habr.com
DoS-уязвимость в WordPress позволяет «уронить» практически любой сайт, и патча для нее нет
Независимый израильский ИБ-специалист Барак Тавайли (Barak Tawily) обнаружил и подробно описал в своем блоге критическую DoS-уязвимость в WordPress CMS. Баг получил идентификатор CVE-2018-6389 и представляет опасность для всех версий WordPress, вышедших за последние девять лет (включая наиболее свежий релиз 4.9.2).
В своей статье специалист объясняет, что проблема связана с работой load-scripts.php, который используется для обработки пользовательских запросов. Исходно load-scripts.php был создан для удобства администраторов сайтов, чтобы те могли улучшить производительность своих ресурсов, объединив несколько файлов JavaScript воедино. При этом разработчики WordPress не сочли нужным защитить эту функциональность какой-либо аутентификацией, чтобы скрипт мог работать и без логина. Фактически, load-scripts.php оказался доступен любому желающему.
В зависимости от установленных модулей и плагинов, load-scripts.php выборочно подгружает различные файлы JavaScript, чьи имена перечисляются через запятую после параметра «load». То есть URL должен выглядеть следующим образом:
https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load=editor,common,user-profile,media-widgets,media-gallery
Так, во время загрузки сайта, load-scripts.php пытается отыскать каждый из перечисленных в URL файлов JavaScript, чтобы «отдать» их браузеру пользователя в виде одного файла.
Тавайли обнаружил, что атакующий может заставить load-scripts.php загрузить все возможные файлы JavaScript вообще, просто перечислив их в URL. Из-за этого атакуемый сайт может начать работать значительно медленнее, поглощая все больше и больше мощностей сервера. Разумеется, при помощи одного такого запроса злоумышленнику не удастся спровоцировать отказ в обслуживании, однако исследователь создал proof-of-concept эксплоит: простой скрипт doser.py, написанный на Python. Скрипт отправляет множество подобных запросов целевому URL. Примерно после 500 запроса средний сайт, работающий на VPS-сервере, перестает отвечать вовсе, «отдавая» лишь ошибки 502, 503 и 504.
Специалист отмечает, что с одного компьютера вряд ли удастся «положить» работающий под управлением WordPress сайт, расположенный на мощном, отдельном сервере, однако если в распоряжении атакующего есть широкий канал или несколько ботов, атака сработает и против такого ресурса, причем окажется менее затратной для злоумышленника, нежели обычный DDoS.
Видеодемонстрацию атаки можно увидеть ниже.
Хотя DoS-уязвимости не подпадают под bug bounty программу WordPress, Тавайли все же сообщил о проблеме разработчикам через платформу HackerOne. К сожалению, создатели WordPress не сочли обнаруженную уязвимость достаточно серьезной и сообщили, что решать такие проблемы нужно на уровне сервера или сети, но не на уровне приложений. То есть патча для этого бага не существует.
В ответ на это Барак Тавайли опубликовал на GitHub собственный форк WordPress, в котором уязвимость устранена. Также исследователь выложил в открытый доступ bash-скрипт, который позволяет исправить проблему в уже существующих установках WordPress.
xakep.ru
10 Шагов от Поиска Уязвимости до Удаления Вредоносного Кода (ВИРУСА) с сайта WordPress | Уроки Wordpress, Рекламе, SEO, SMM и Интернет-Маркетинге БЕСПЛАТНО
Очистка взломанного сайта WordPress — непростая задача. И теперь, когда Google и Яндекс применяют карантины (запреты на просмотр сайтов), чтобы предотвратить повторное нарушение правил распространения вредоносных программ, тщательная очистка взломанного сайта становиться важнее, чем когда-либо.
Вредоносный код на сайте Яндекс и сайт содержит нежелательное ПО Google
Как это выглядит в жизни:
Пример предупреждения обнаружения вредонсного кода / вируса Яндекса 
Пример предупреждения обнаружения вредонсного кода / вируса Google Я настоятельно рекомендую воспользоваться услугами профессионалов для очистки сайта. Здесь Вы можете заказать, как диагностику сайта на наличие вирусов, так и воспользоваться услугами специалистов в области WordPress.
Советы по поиску уязвимостей и вредоносного кода на сайте WordPress
Если вы всё же решились очистить сайт самостоятельно, выполните следующие действия:
Шаг 1. Резервное копирование файлов и баз данных сайта.
- Резервное копирование полной версии сайта, если у вас есть возможность использовать функцию создания моментальной копии сайта на вашем хостинге . Это будет самая полная резервная копия всего вашего сервера. Однако он может быть довольно большим, поэтому будьте готовы к тому, что загрузка займет некоторое время.
- Используйте плагин для резервного копирования WordPress, если вы можете войти в админ панель сайта.
- Если вы не можете войти на сайт, хакеры могут скомпрометировать базу данных, в этом случае вы можете воспользоваться услугами профессионалов, упомянутых выше.Сделайте отдельную дополнительную резервную копию базы данных, используя эти шаги.
- Если вы можете войти в систему, также используйте «Инструменты»> «Экспорт» для экспорта XML-файла всего вашего контента.
Некоторые сайты могут быть довольно большими. Сам файл uploads может быть более 1GB. Папка wp-content является самой важной папкой на вашем сервере, так как она содержит все ваши загрузки. Если вы не можете запустить плагин резервного копирования, и ваш хостинг не имеет функции «моментального резервного копирования», вы можете использовать File Manager хостинга, чтобы сделать zip-архив вашей папки wp-content, а затем загрузить этот zip-файл.
Если у вас несколько версий WordPress на сервере, вам нужно создать резервную копию каждого из них.
Обратите внимание на файл .htaccess: создайте резервную копию вашего файла .htaccess и загрузите его. Это невидимый файл, поэтому вы можете видеть его только в Диспетчере файлов веб-хостинга. Переименуйте этот файл, для этого удалите точку в начале, чтобы вы могли видеть его на своем компьютере, иначе он будет невидим и на вашем компьютере. Затем загрузите его. Возможно, вам понадобится резервное копирование файла .htaccess, если он содержит код, который вам нужно будет скопировать обратно на ваш очищенный сайт. Некоторые хостинги используют .htaccess для определения используемой вами версии PHP, поэтому сайт не будет работать без этого. Некоторые люди делают 301-редиректы (переадресацию страниц) SEO используя свой файл .htaccess.
Шаг 2. Загрузите и изучите резервные файлы
После резервного копирования сайта загрузите резервную копию на свой компьютер, дважды щелкните zip-файл, чтобы открыть его.
Анализ уязвимостей сайта
Вам следует увидеть:
- Все файлы Ядра WordPress. Вы можете загрузить WordPress с WordPress.org и проверить файлы в загрузке и сопоставить их с вашими. Вам не понадобятся эти файлы, но вы можете использовать их для дальнейшего расследования взлома.
- Файл wp-config.php. Является одним из важных, поскольку он содержит имя пользователя и пароль для вашей базы данных WordPress, которые мы будем использовать в процессе восстановления.
- .htaccess. Этот файл может быть не видим на Вашем компьютере. Единственный способ — это просмотреть свою резервную папку с помощью FTP-программы (например, FileZilla), открыть файл модно через любое приложения для редактирования кода (например, Sublime).
- Папка содержимого wp. В папке wp-content вы должны увидеть как минимум три папки: themes, uploads и plugins. Проанализируйте эти папки. Вы видите свою тему, плагины и загруженные изображения? Если это так, то это хороший знак того, что у вас есть хорошая резервная копия вашего сайта. Обычно это единственная критически важная папка, необходимая для восстановления вашего сайта (в дополнение к базе данных).
- База данных. У вас должен быть файл SQL, являющийся экспортом вашей базы данных. Для экспорта используйте встроенное приложение для работы с базами данный, например PHPmyAdmin или другое. Мы не собираемся удалять базу данных в этом процессе, но хорошо иметь резервную копию.
Шаг 3: Удалите все файлы в папке public_html
После того, как вы подтвердили, что у вас есть полная и полная резервная копия вашего сайта, удалите все файлы в вашей папке public_html (за исключением папки cgi-bin и любых связанных с сервером папок, которые явно не были подвержены взлому файлов), используя диспетчер файлов веб-хоста. Я рекомендую File Manager, потому что это намного быстрее, чем удаление файлов по FTP. Не забудьте просмотреть невидимые файлы, чтобы удалить все взломанные файлы .htaccess.
Если у вас есть другие сайты, которые вы размещаете на одной учетной записи, то можете предположить, что все они были подвержены заражению. Перекрестное распространение вредоносного кода — распространенная проблема. Вы должны почистить ВСЕ свои сайты, чтобы все они были работоспособны, загрузите резервные копии и выполните следующие шаги для каждого из них. Проведите проверку и очистку каждого сайта тщательно. Учитывайте тот факт, что входе очистки файлов остается вероятность повторного заражения, т.к. некоторые коды, которые были внесены на ваш сайт могут генерировать свои скрипты в произвольных файлах, в том числе и в тех, в которых вы уже удалили вредоносный код. Поэтому, отнеситесь к этому процессу, как процессу лечения чумы. 🙂
Шаг 4: Переустановите WordPress
Используя установщик CMS в панели управления веб-хостинга, переустановите WordPress в каталог public_html, если это было исходное местоположение установки WordPress или в подкаталог, если WordPress был установлен в дополнительном домене. Если такой установщик отсутствует, то установите WordPress через FTP, классическим способом.
Используя резервную копию вашего сайта, отредактируйте файл wp-config.php на хостинге, чтобы изменить учетные данные базы данных на данные вашего прежнего сайта. Это позволит подключить только что установленную версию WordPress к старой базе данных. Я не рекомендую повторно загружать старый файл wp-config.php, поскольку новый будет иметь новые шифры для входа в систему и, безусловно, не будет содержать никакого взломанного кода.
Шаг 5: Сброс паролей и перманентных ссылок
Войдите на свой сайт и сбросьте все имена пользователей и пароли. Если вы видите каких-либо пользователей, которых вы не знаеете (т.е. их не было ранее), ваша база данных была подвержена взлому, и вам необходимо обратиться к специалисту, чтобы убедиться, что в вашей базе данных не осталось нежелательного кода.
В админ панели WordPress откройте «Настройки»> «Постоянная ссылка» и нажмите «Сохранить изменения». Это восстановит ваш файл .htaccess, поэтому URL-адреса вашего сайта снова будут работать.
Обязательно поменяйте все пароли FTP и хостинга учетной записи.
Шаг 6: Переустановите плагины
Переустановите все свои плагины из репозитория WordPress или свежие загрузки от разработчика платных плагинов . Не устанавливайте старые плагины. Не устанавливайте плагины, которые больше не поддерживаются.
Шаг 7: Переустановка тем
Переустановите свою тему из новой загрузки. Если вы настроили свои файлы тем, используйте свои резервные файлы и скопируйте изменения в новую копию темы. Не загружайте старую тему, так как вы можете не распознать, какие файлы были взломаны.
Шаг 8: Загрузка изображений из резервной копии
Сейчас сложная часть. Вам нужно вернуть ваши старые файлы изображений обратно в новую папку wp-content> uploads на сервере. Тем не менее, вы не хотите копировать взломанные файлы в процессе. Вам нужно будет тщательно изучить каждую папку в месяц / месяц в своей резервной копии и просмотреть каждую папку и убедиться, что в ней находяться ТОЛЬКО файлы изображений, а также файлы PHP или Файлы JavaScript или все, что вы не загрузили в свою медиа-библиотеку. Это утомительно. Как только вы проверите и убедитесь в отсутствии инородных файлов в каждой папке года / папке месяца, вы можете загрузить их на сервер с помощью FTP.
Шаг 9: Сканирование компьютера
Просканируйте собственный компьютер на наличие вирусов, троянов и вредоносных программ.
Шаг 10: Установка и запуск плагинов безопасности
Установите и активируйте плагин Shield WordPress Security от iControlWP. Проверьте все настройки.
Поиск уязвимостей, сканирование и проверка на вирусы на сайте WordPress онлайн
Запустите Anti-Malware Security and Brute-Force Firewall и тщательно просмотрите сайт. Сканируйте сайт с Sitecheck Sucuri, чтобы убедиться, что вы ничего не упустили. Вам не нужны два плагины защиты, поэтому отключите плагин Anti-Malware после проверки и после того, как убедитесь, что ваш сайт не содержит вредоносного кода. Shield уведомит вас в будущем, если какие-либо файлы ядра изменились.
Поиск причины взлома
Как только вы определили тип взлома, с которым вы столкнулись, вы можете более легко сузить, почему это произошло. Во многих случаях ИСТОЧНИКОМ ЗАРАЖЕНИЯ может выступать Ваш собственный компьютер.
У меня был один клиент, сайт которого был заражен расширением браузера, которое она случайно установила на своем компьютере. Она по сути заразила свой собственный сайт, производя загрузку JavaScript-кода в свой Visual Editor каждый раз, когда редактировала страницу на сайте! Этот код был невидим в Visual Editor (хотя он был виден на вкладке «Текст»), и даже если бы я его очистил, она снова взломала себя при следующем редактировании. Поиск Google по некоторому тексту, который я нашел в введенном коде, привел меня к статье на веб-сайте Сукури, которая помогла мне разобраться, почему произошел взлом и заставить клиента почистить свой компьютер от шпионского ПО.
Кроме того, если вы переустановите тот же плагин или тему, которые уже были уязвимы ранее, а причина/источник взлома так и не выяснен, тогда ваш сайт с большой долей вероятности будет быстро взломан повторно. Поэтому знание причины заражения — это важный аспект, который позволит вам не повторить тех же ошибок после всех усилий, которые вы предприняли, чтобы очистить ваш сайт от вирусов.
Если вы хотите углубиться в причину взлома, выполните следующие действия:
- Осмотрите свою резервную копию для взломанных файлов. Они будут иметь странные имена и выделяться из других файлов в вашей WordPress или могут иметь даты редактирования последние в списке. Если вы откроете эти файлы в редакторе кода, например Dreamweaver, TextWrangler, BBEdit, Sublime, Coda и т. д., Вы можете заметить довольно быстро с помощью цветового кодирования кода или огромного количества кода, что-то аномальное (специалисту сразу броситься в глаза такой кусок кода). Смотрите скриншоты ниже.
- Выполняйте поиск Google по определенным фразам, включенным файлам в коде или именам самих файлов на хостинге. Иногда это может быть просто имя класса div, которое вы находите в взломанном коде, как на взломанном сайте моего клиента.
- Изучите журналы Raw Access на хостинге cPanel, чтобы узнать, к каким файлам обращались хакеры (посмотрите инструкции POST в файлах журналов). Это будет ключом к тому, что именно было подвержено заражению и когда. Вы можете найти IP-адрес, доступ к этим файлам, чтобы узнать, откуда появился хакер.
- Большинство хаков вызваны старыми плагинами и темами, поэтому найдите плагины, которые вы использовали на взломанном сайте, и посмотрите, был ли сайт взломан из-за более старой версии Gravity Forms, Revolution Slider, скрипта timthumb.php в теме или плагине и т. д. Многие сайты взломаны с помощью распространенных известных уязвимостей, которые хакеры и ищят среди сайтов WordPress.
- Поиск в базе данных для скрытых пользователей admin и другого потенциального взломанного контента. Sucuri имеет отличные советы о том, как сканировать вашу базу данных для скрытого вредоносного кода. Если вы попытаетесь изменить свою базу данных, сначала создайте ее резервную копию!
Взломанный файл .htaccess 
Вирус в HTML 
Взлом php-файла темы 
Взлом index файла Защита WordPress от вирусов
Настройте уведомления Google Search Console и Яндекс Вебмастер для своевременного реагирования в дальнейшем.
Также, вы можете использовать функцию Shield WordPress Security Plugin Audit Trail для отслеживания любых изменений в файлах или доступа к сайту.
Все вышеописанные советы не являются панацеей от всех заражений, они служат лишь руководством к действию при заражении сайта вирусом. Если данные советы не помогли, то рекомендую обратиться к специалистам, которые проведут профессиональную диагностику и смогут более точно выявить причину заражения и принять соответствующие меры для ее устранения. Также, следует учесть, что бывают случаи, когда зараженный сайт уже не подлежит полному восстановлению по причине заражения и удаления важных частей кода и файлов, которые отвечают за работоспособность сайта.
Поэтому, лучшее средство для защиты от вирусов не устанавливать взломанные плагины/шаблоны и РЕГУЛЯРНОЕ СОЗДАНИЕ РЕЗЕРВНЫХ КОПИЙ вашего сайта для возможности отката в случаи беды 😉
Задавайте Ваши вопросы в комментариях, также здесь можно указывать проблемы с которыми Вы столкнулись в процессе диагностики сайта.
ВСЕХ БЛАГ!
readanduse.com
Список уязвимостей WordPress
Список уязвимостей WordPress
Опубликовал admin
февраля 9, 2015
Совсем недавно я наткнулся на список уязвимостей WordPress, который обновляется каждый день. Может и чаще, но точной информации не нашел. Но зато я нашел уязвимости, которые были добавлены в этот же день. Кроме того, что можно посмотреть дырки актуальные для конкретной версии, так же существует мониторинг уязвимостей плагинов и тем.
Самое главное, что он обновляется. Ведь большинство подобных сайтов лишены такой фишки и я не вижу особого смысла в их существование. Сам сайт носит гордое название WPScan Vulnerability Database и выглядит подобным образом.
Все предельно просто, но тут и не нужно что-то еще. Есть поиск, который так же облегчает жизнь. Вот пример уязвимостей плагинов WordPress:
Это расшифровка картинки:
2015-02-09 Users Ultra <= 1.4.35 - SQL Injection2015-02-04 FancyBox for WordPress <= 3.0.2 - Stored Cross-Site Scripting (XSS)2015-02-03 UpdraftPlus <= 1.9.50 - Privilege Escalation2015-02-02 Revive Old Post <= 6.9.0 - Privilege Escalation2015-02-02 WordPress Calls to Action <= 2.2.7 - Stored XSS2015-02-02 WP Ultimate CSV Importer <= 3.6.74 - Database Table Export2015-02-02 WordPress Video Player <= 1.5.4 - Reflected Cross-Site Scripting (XSS)
Как вы видите, уже сегодня опубликована информация про уязвимость Users Ultra <= 1.4.35 — SQL Injection. Очень полезный сервис.
Ссылка на сайт WPScan Vulnerability Database:
https://wpvulndb.com/
Еще по теме:
https://github.com/dionach/CMSmapсканер уязвимостей для популярных CMS WordPress, Joomla, Drupal.
П.С.: Обновляйте WordPress почаще и следите за информацией об уязвимостях.
Метки: WordPress, Уязвимость Если Вам понравилась статья Список уязвимостей WordPress, то пожалуйста, прокомментируйте ее или подпишитесь на фид и получайте будущие публикации по RSS. Поделитесь ссылкой на статью с друзьями при помощи социальных кнопок ниже.zaan.ru
Убираем уязвимости в Wordpress. Часть вторая.
]]>]]>
Дата последнего редактирования:
20.01.2015
.
В позапрошлой записи я рассказывал про удаление уязвимостей в All in One SEO Pack. После этого я подумал, нет ли похожих уязвимостей в других плагинах? Не зря ко мне пришли эти мысли, уязвимости есть, причем не только в плагинах, но и в файлах самого движка!
Какие уязвимости?
Уязвимостью здесь я буду называть вывод информации о установленной версии движка или плагина, так как это может значительно упростить взлом блога. Рассмотрим код страницы http://site.com/feed/.
Но такую картинку мы увидим только после удаления уязвимости. А сейчас, если Вы посмотрите исходный код своего фида, то увидите там Вашу версию WordPress.Когда я заметил эту проблему, начал внимательно просматривать все файлы, где в названии бы употреблялось «rss» или «feed», и был очень удивлен, там не было необходимого для исправления кода! Пришлось скачать все файлы сайта на компьютер и сделать поиск с помощью Notepad++ по всем файлам. Вот так я и обнаружил этот код в файле site.ru/wp-includes/general-template.php, начиная со строки 2227.
Вторая уязвимость находится в популярном плагине «Google XML Sitemaps».
Здесь мне удалось намного быстрее определить файл с уязвимостью: site.ru/wp-content/plugins/google-sitemap-generator/sitemap-core.php, начиная со строки 1684.
Как решить проблемы?
1. Страница Feed. В файле general-template.png заменяем выражения ' . get_bloginfo_rss( 'version' ) . ' и ' . get_bloginfo( 'version' ) . '. Я, например, заменил на 100500, но поля с ссылками я сделал чуть-чуть другими, дабы не было битых ссылок (может плохо сказаться на отношении ПС к сайту).Видим в итоге.
Теперь смотрим исходный код страницы фида. Если все сделали строго по инструкции, уязвимость должна исчезнуть.
2. Sitemap.xml. В файле sitemap-core.php заменяем . get_bloginfo('version') . " и " . $this->GetVersion() . ", опять же, на произвольные значения.Итог должен быть примерно таким.
Клип к социальной сети Google+. Если есть желание там общаться, пишите в комментариях, отправлю инвайт.
Партнерки рунета.
]]>]]> Теги: wordpress, плагины, уязвимости.partnerki-runeta.ru
