Доброго времени суток, уважаемые читатели блога Мои тараканы!

Взлом сайта

Хочу разочаровать тех, кого заинтриговал заголовок статьи — о том, как взломать сайт, писать я не буду. Данным постом хочу начать рубрику, посвящённую безопасности сайтов на WordPress (и не только). Что делать для того чтобы сайт не взломали. И что делать, если ваш сайт уже взломан.

На днях готовил статью об ускорении сайта на Вордпресс. При сканировании своего блога на наличие «медленных» запросов обнаружил десять замечаний по PHP, на которые нужно обратить внимание. Девять из них находились в файле funtion.php в функции, которой раньше там не было.

Я начал искать в интернете, что представляет собой этот загадочный код.

Признаки

Изначально по запросу я находил сообщения с форумов, в которых владельцы сайтов на WordPress жаловались на то, что при активации шаблона скачанного из интернета возникала фатальная ошибка: Fatal error: Cannot redeclare _verify_isactivate_widgets() (previously declared in /domains/site.ru/public_html/wp-content/themes/galegale/functions.php

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

Но то, что у этих веб-мастеров, перестал работать сайт — это скорее плюс, чем минус — они сразу узнали о том, что на сайте есть проблемы.

Копнув глубже, всплывала иная ситуация. У некоторых пользователей WordPress, на сайте появлялись скрытые ссылки в теле статьи. И обнаружить их было нелегко. Если админ был залогинен, то в публичной части они ему не отображались вообще. Их можно было увидеть, если разлогиниться в админке сайта. И то, «увидеть» — это громко сказано, правильней будет — «найти», потому что анкором ссылки становилась точка в статье.

В административной части сайта так же не всё так просто. В редакторе ссылка также не отображалась. Визуально её можно было увидеть только при переключении в режим отображения кода. Она устанавливалась на первую точку или после тега --more--, так же с анкором в виде точки. Удаление точки ни к чему не приводило — ссылка перемещалась на следующую. В случае с тегом --more--такая же история — при повторном его добавлении ссылка появлялась снова.

С чем имеем дело

Виновником всех проблем был вирус, прописанный в виде PHP функции в конце файла functions.php. Начинался он у всех так:

<php
function _verifyactivate_widgets()

или

<php
function _verify_activate_widgets()

И далее около 200 строк кода. Примечательно, что эта функция появляется в functions.php всех тем установленных на вашем сайте, даже стандартных. И если вы скачаете к себе на компьютер стандартный шаблон , например, twentyten, и сравните functions.php скачанной темы и темы имеющейся у вас на сайте, то убедитесь что этой функции в локальном (находящемся на компьютере) файле нет. Если вы обнаружили у себя что-то подобное, знайте — ваш сайт взломали.

Как я понял, код, о котором идёт речь — это червь. Вот что я нашел о нем на одном из форумов:

Функция _verify_isactivate_widget () сначала читает свой собственный файл, затем с помощью функции get_allwidgetcont () находит файлы functions.php в каталогах других тем и дописывает себя в них. Помимо процитированного фрагмента могут быть сопутствующие функции, которые вставляют скрытые ссылки и т.д.

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

Лечение

На самом деле, лечение очень простое. Нужно удалить код из файлов functions.php всех установленных тем на вашем сайте. Удалить темы, скачанные из ненадежных источников. А в оставшихся темах в functions.php удаляем всё что начинается с

<php
function _verifyactivate_widgets()

и до конца файла.

Не мешало бы сменить пароли от WordPress, ftp, и, на всякий случай, от админки хостинга (мало ли что было спрятано в теле червя).

И в следующий раз, когда будете устанавливать новую тему, убедитесь в отсутствии в ней вредоносного кода.

Мой случай

Предполагаю, что, конкретно в моем случае — было спрятано изображение белого цвета размером 1 пиксель закодированное через Base64. И размещалось оно, так же, как и в приведённых мною примерах, в районе тега more.

В его наличии на сайте воочию я убедится, не успел — после лечения самостоятельное внедрение инфицированного кода вызывало фатальную ошибку. Но о его наличии я могу судить по этому участку кода:

if(!$no_more && strpos($text, <img src="data:image/gif; base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-more="more" data-wp-more-text="" class="wp-more-tag mce-wp-more" title="Тег «Далее»" data-mce-resize="false" data-mce-placeholder="1" />)) {
133
            $text=explode(<img src="data:image/gif; base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-more="more" data-wp-more-text="" class="wp-more-tag mce-wp-more" title="Тег «Далее»" data-mce-resize="false" data-mce-placeholder="1" />

Если пропустить R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 через декодер Base64 — мы получим такой текст: GIF89a ? ??????????!? ????,???? ? ?? D?;. Но если установить чтобы декодер выдавал на выходе файл — мы получим GIF файл, переформатированный в формат dat. Браузер всё декодирует и выдает готовый результат — то самое изображение в один пиксель.

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

Небольшая справка:

Base64 — это позиционная система счисления с основанием 64. Система Base64 используется в электронной почте, как правило, при передаче бинарных данных (файлы, картинки). Для кодирования используются символы английского алфавита (A-Z, a-z) и цифры (0-9), что в сумме составляет 62 знака, а для остальных двух знаков используются различные символы, в зависимости от разновидности Base64.

Источник.

DAT — общий формат для хранения данных различными приложениями. Как правило, файл DAT можно открыть только программой, которая создала этот файл. Данные могут храниться как в текстовом, так и в двоичном виде. Текстовые файлы DAT можно просмотреть в любом текстовом редакторе. Примеры программ, которые создают и используют файлы DAT: Microsoft Visual Studio, Corel WordPerfect, Nero ShowTime, Nullsoft Winamp, SoftVelocity Clarion, Ontrack EasyRecovery, Runtime GetDataBack, программное обеспечение MapInfo.

Источник.


Вывод

Как я заметил, о функции _verify_isactivate_widget () (точнее об использовании её для взлома сайта) известно довольно давно. Заразить сайт, подобным образом, проще простого. Но вот почему в блогосфере я не встречал ни одного поста на эту тему, мне не понятно. Более того, то, что я находил по _verify_isactivate_widget () — это были сообщения с буржуйских форумов. То ли у нас хакеры не применяют подобные практики, то ли веб-мастера не знают о существовании подобной заразы.

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

На этой минорной ноте прощаюсь с вами. Подписывайтесь на обновления блога в Twitter , RSSили по почте!

С уважением, Мышак Пётр!

Похожие записи:

Понравилась статья? Расскажи друзьям, автор очень старался:
16 комментариев на:
“Как взломать сайт? Инфицированный файл functions.php темы WordPress”
  • Денис говорит:

    Мне тоже приходилось «лечить» блог от взлома, правда причиной стала не тема, а уязвимость WP в апреле этого года при выходе новой версии. Баг-фикс выпустили практически на следующий день, но видно этого времени было достаточно хакерам. По логам сервера в те дни как раз была массированная атака.

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

    Будет интересно почитать о способах защиты от взлома в новой рубрике!

    • Пётр говорит:

      Мне помнится, много лет назад, я читал одну статью о вирусах, не у тебя ли она была в блоге?

      • Пётр говорит:

        Сейчас проверил по поиску — ничего не нашел, но уверен что у тебя такая статья была... Или я ошибаюсь?

      • Денис говорит:

        Про вирусы не было, про плагин TAC рассказывал)

  • Сергей говорит:

    Все рано или поздно сталкиваются с подобными проблемами, иногда проще всего восстановить все из бекапа. Так что, Петр, тебе тема на следующий раз — бекапы сайтов — плагины, модули, автономные программы

    Жду

  • Сергей говорит:

    Ссылка на сайт-пример битая — не хватает одного слеша после http:/

  • Надежда говорит:

    Сразу побежала, проверила. Меня тоже один раз взламывали, я даже не поняла как и что. Просто восстановила прежнее состояние за предыдущий день и все пароли поменяла. А заметила так — объем папки content стал увеличиваться на 20 мб в час. Что было — не знаю.

  • Тимур говорит:

    Всем привет

    Как я понял, это все касается только вордпресс. Например у меня на блогспот сайт находиться. Меня гул кампания охраняет. Так что, мне не о чем беспокоиться.

    • Пётр говорит:

      Взломать можно любой сайт. Здесь описан один из способов взлома. Он относится к сайтам на WordPress. Для блогспота применяются другие технологии.

      • Тимур говорит:

        С блогспотом немного сложнее,потому что аккаунт (при желании,а так все вебмастера делают)привязан к телефону (только кодом).А вордпресс нет такого,может и есть но мне незнакомо (например у меня на вп нет такого).

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

        • Пётр говорит:

          Никто не запрещает поставить на WordPress двухуровневую аутентификацию.

          • Пётр говорит:

            Просто никто этого не делает, вообще вопросу безопасности начинающие вебмастера мало уделяют внимания. Думают: да кому мой сайт сдался...

  • Сергей говорит:

    Уж не думал, что придется лечиться от данной проблемы. Хоть и писал ранее, что бекап рулит, но и понимание проблемы имеет свои плюсы. Т.ч. твой пост помог понять, что я правильно определил вирь на сайте.

Добавить комментарий

Перед комментированием ознакомтесь с правилами комментирования
  • Все комментарии проходят ручнуюю модерацию, поэтому большая прозьба - НЕ СПАМИТЬ!!!
  • Подписывайтесь нормальными именами, а не "регистрация в Москве" или "Кондиционеры не дорого".
  • Ссылки на коммерческие сайты будут удалятся.
  • Оставляйте ссылку на главную страницу.
  • Оставляйте комментарии длинной не менее 100 символов. Исключения - диалоги и ответы на заданные вопросы.
Внимание! Один раз в неделю блог прходит проверку на наличие битых ссылок. Если ваш сайт в это время не был доступен, ссылка на него будет удалена!
За собой оставляю право редактировать и удалять комментарии, даже если они удовлетворяют вышепреведённый свод правил.