Бортовой журнал. Удаление вредоносного кода Joomla Проверка joomla на вредоносный код

Часто можно увидеть в сети: сайт работал нормально и вдруг начал работать, как дворник с похмелья, хостер пишет гневные письма, поисковики обходят сайт стороной, а браузеры блокируют предупреждением «Имеется информация, что этот сайт атакует компьютеры!»

Откуда же берутся вирусы?

Самая распространённая на сегодня причина — это использование quickstart (quickstart это установочный архив, позволяющий в несколько минут развернуть точную копию сайта, со всеми расширениями), как правило, скачанного с варезных ресурсов; квикстарта, купленного у разработчика, разумеется, можно не бояться. Очень удобно, не нужно мучатся с дизайном, установкой расширений, настройкой сайта. Правда, зачастую вместе с сайтом можно получить набор скриптов, дающих контроль над вашим ресурсом, таких как рассылка спама, «раздача» вирусов или размещение невидимых ссылок на сторонние ресурсы (черный SEO).

Для чего варезные ресурсы включают backdoor (от англ. back door — «чёрный ход») в архив? Как правило, варезные ресурсы живут за счет отчислений за каждое скачивание от файлообменников, а те, в свою очередь, показом рекламы и платными подписками, позволяющими увеличить скорость загрузки, которая для простых пользователей обычно ограничена. Но многим этого кажется мало, тем более когда есть возможность управлять сотнями и даже тысячами сайтов. Если уж хотите использовать quickstart, то купите его у разработчика, тем более его стоимость в среднем составляет 30-50 долларов, что, в общем, недорого даже при нынешнем курсе.

На второе место можно поставить взлом CMS через уязвимости, причем с защищённостью движков все в порядке, причина банальна - пользователи не устанавливают обновления. Кто-то боится, что после обновления «слетит» сайт, кому-то просто лень, или студия разработала сайт и передала его заказчику. Заказчик поручил вести сайт одному из сотрудников, и тот исправно наполняет его по инструкции, а обновление в его функции не входит…

Так одной из возможных причин утечки «Панамского архива» специалисты называют устаревшие CMS - Drupal, содержавший на момент взлома не менее 25 уязвимостей, и WordPress 4.1 с уязвимым плагином.

Ищем черный ход

Во-первых, антивирус ищет вредоносы именно для ПК, сколько бы Вы не размещали на своем компьютере backdoor на php, заразить его (ПК) не удастся.

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

Можно пойти разными путями.

Первый вариант

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

Ставим чистую Joomla (или другую CMS), устанавливаем шаблон, все компоненты, модули, плагины, что стояли на вашем сайте. Переносим все изображения со старого сайта, директория images, предварительно проверив, чтобы в ней не оставалось никаких файлов, кроме изображений, в том числе и во внутренних директориях. В случае если у вас установлен компонент K2, то изображения будут находиться в директории media/k2/items/cache/.

Внимание! Не лишним будет проверить наличие изображений с явно рандомным названием, как i2495mg.gif, обычно в таких изображениях прячется исполняемый код.

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

Подключаем базу со старого сайта

Экспортируем базу. Заходим на хостинге в phpmyadmin, выбираем в столбце слева нужную базу и переходим во вкладку «Экспорт». Нажимаем «Выделить все», можно поставить сжатие zip, и в самом низу страницы нажимаем «Ок». Сохраняем базу на свой ПК. Заходим в phpmyadmin, создаем новую базу, переходим в нее, открываем вкладку импорт и указываем путь к скачанному дампу. Теперь осталось подправить configuration.php, который находится в корне каталога, открываем его любым редактором. Например, Notepad++.

public $db = "base"; - вместо base указываем свое имя базы;

public $user = "root"; - если вы не меняли имя пользователя на локальном сервере, то оставляем как есть;

public $password = ""; - на локальном сервере обычно стоит пустой пароль, тоже оставляем.

Сохраняем изменения, проверяем работу сайта.

Второй вариант

Если у вас достаточно опыта, то можно включить просмотр исходного кода и посмотреть, присутствует ли «чужие» ссылки, далее посмотреть, например через firebug, откуда они берутся. Как правило, они зашифрованы и, как правило, алгоритмом base64.

Если опыта не хватает, то можно воспользоваться онлайн-сервисом, самый простой вариант - в кабинете вебмастера Яндекс или Гугл либо веб-сканер https://rescan.pro/ . Я больше склоняюсь к ручному просмотру кода страницы, хотя, конечно, стоит признать, что всевозможные скрипты и сканеры заметно ускоряют работу.

Пример по поиску «левых»​ ссылок

Для примера я взял квикстарт с одного из варезных ресурсов. Нажимаем Ctrl+F5 для просмотра исходного кода, даже при беглом просмотре сразу находим:

Переключаем в административной панели шаблон сайта на стандартный, ссылки исчезли, значит, код прописан в варезном шаблоне, там и будем искать.

Открываем Notepad++, нажимаем Ctrl+F, переходим во вкладку «Найти в файлах», указываем директорию шаблона, а в строке поиска искомое, в данном случае "sa_wqngs". Нажимаем «Найти все». Поиск находит два совпадения.

Удаляем строки, обновляем страницу, строки с ссылками не исчезли, а поскольку я раньше не нашел прямых ссылок, значит, код зашифрован.

Запускаем новый поиск, теперь по «base64» и видим в коде шаблона:

Удаляем строки 174, 184, 186 (код комментировать не буду, кто хочет, может найти описание в сети). Снова обновляем страницу с исходным кодом, ссылки исчезли. Также проходим все результаты поиска с «base64», к слову, подобных вставок в шаблоне нашлось с десяток. Тут хорошо помогает сортировка по времени, так если большинство файлов шаблона датированы, предположим, 1 мая 2014 года, то файлы, изменённые, скажем, восемь месяцев спустя по меньшей мере подозрительны.

Для чего обновлять сайт?

В наше время «злобные хакеры» не ломают сайты вручную, если, конечно, это не крупный портал или база конфиденциальной информации. Взломы давно поставлены на конвейер. Для этого написаны боты (скрипты), которые перебирают в сети все сайты на популярных CMS, после чего пытаются применить библиотеку уязвимостей, удачное внедрение отправляется в отчет. Соответственно, как только появляется новая уязвимость, она сразу же добавляется в библиотеку.

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

Используем сканер

Конечно, вручную не всегда удается найти некоторые «сюрпризы», так, возможно, вы вовремя не обновили систему или расширения, и на сайт был установлен backdoor... Сейчас существует множество сканеров, один из них AI-Bolit. К тому же он бесплатен для некоммерческого использования.

Используем его для «экспериментального» сайта, где я искал «лишние» ссылки. Как им пользоваться, хорошо документировано на официальном ресурсе, поэтому не буду дублировать информацию.

По результатам экспресс-проверки я получил сообщение о двух уязвимостях. Первая сообщала об устаревшей версии движка, это, в общем, я и так знал.

Вторая говорила об уязвимости в administrator/components/com_k2/lib/elfinder/elFinder.class.php - AFU: elFinder. Возможно, причина в том, что компонент тоже устарел.

На всякий случай я скачал последнюю версию компонента с официального сайта и сравнил версию, на который жаловался сканер, со свежескачанной. Для этого удобно использовать плагин для Notepad++, Compare. Как и предполагалось, отличие состояло только в версиях.

Сидим в засаде

На этом проверку можно было бы и завершить, но на всякий случай я решил почувствовать себя параноиком. Один из верных способов - посмотреть, какие пакеты ваш сайт засылает в сеть. Ставим Wireshark , он также хорошо задокументирован на сайте разработчика. Переходим по страницам сайта, действительно, сайт обращается к сети, но тут ничего страшного. Идет подгрузка шрифтов с Google Fonts, видео с YouTube…

Занавес

Этот материал, конечно, не подробная инструкция по «лечению» сайтов, а лишь небольшое руководство к действию. Дорогу осилит идущий...

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

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

Как узнать что сайт стал жертвой атаки, в ходе которой на него попал вредоносный код? Первое и самое простое - сайт перестал работать или выглядит не так, как должен выглядеть "здоровый" ресурс. Это может проявиться в появлении нежелательного контента или исчезновении Вашего, страницы не загружаются или загружаются с ошибками. К тому же, если Ваш сайт добавлен в Яндекс или Google веб-мастер, Вы с большой вероятностью получите уведомление от этих систем о вредоносном коде. В некоторых случаях об уязвимости Вы можете узнать от своего браузера (скриншот из Google Chrome).

Крайне нежелательно в таких случаях пытаться открывать страницу дальше.

Ищем вредоносный код на сайте

Разбираться в мотивах человека, который установил на Ваш сайт вредоносный код, а тем более искать его, мы не будем. Наша основная цель - это найти "плохой" код и удалить его. Для начала необходимо просканировать ресурс, чтобы обнаружить все "зараженные" страницы. Это позволяет сузить круг поиска. К примеру, вредоносный код мог быть помещен в виде Javascript скрипта на какую-нибудь отдельную страницу, скажем в содержимое поста или комментарий к нему. В таком случае проблема может быть решена через админку сайта удалением такого кода из содержимого/комментария. В противном случае, приходиться искать его в исходном коде Вашего ресурса.

Для сканирования сайта на предмет уязвимостей можно воспользоваться https://sitecheck.sucuri.net В итоге можно увидеть следующее:

Как видно из скриншота, "плохой" скрипт обнаружен на нескольких страницах сайта, поэтому придется поискать его в исходном коде.

Получить доступ к исходному коду сайта можно несколькими путями:

Самый простой способ - через админку сайта. В Wordpress например, "Внешний вид" -> "Редактор". Такой способ не совсем удобен из-за отсутствия поиска по содержимому файлов, поэтому приходится очень тщательно просматривать их все по отдельности и искать "плохой" скрипт.

Многие блоги, корпоративные ресурсы, интернет-магазины расположены на серверах, к которым можно получить доступ через панель управления хостингом. Зачастую такой панелью является cPanel. Для получения доступа необходимо знать логин и пароль. Они обычно высылаются при покупке хостинга лицу, совершающему сделку. После входа в панель управления можно просмотреть абсолютно все исходные файлы через "Диспетчер файлов" и попытаться найти те, которые содержат обнаруженный вредоносный скрипт.

Самый удобный способ - через FTP-клиент. Если Вы "общаетесь" со своим ресурсом с помощью FTP-клиента, то без труда сможете запустить поиск по содержимому исходных файлов.

Не пытаетесь найти вредоносный код в исходных файлах Вашего сайта, подставив его в поиск полностью. Выделите его уникальную часть, как например googleleadservices.cn в нашем случае, и повторите поиск несколько раз.

Удаление вредоносного кода

После обнаружения вредоносного кода его просто необходимо удалить. В нашем случае сайт работал под Joomla, а "плохой" скрипт был вставлен в index.php в корневой директории. Именно поэтому уязвимость была обнаружена сразу на нескольких страницах, так как данный index.php используется при построении всех страниц ресурса.

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

Профилактика

Всегда лучше предупредить, чем лечить, поэтому я рекомендую:

Использовать "хорошие" пароли для все пользователей сайта (длинные, с цифрами, заглавными и прописными буквами).

Серьезно относиться и фильтровать контент, который генерируется на сайте не Вами (гостевые посты, комментарии).

Не ждать уведомлений, а периодически сканировать сайт на наличие уязвимостей.

Своевременно обновлять систему управления сайтом (Wordpress, Joomla, Drupal, ...).

С вопросами и замечаниями прошу в комментарии.

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

Выполнять работу по удалению вредоносных скриптов и проводить анализ причин взлома должен специалист с соответствующими знаниями и опытом :

• Для удаления вредоносных скриптов необходимо знание языка программирования PHP , а также знание «изнутри» популярных CMS (Joomla, WordPress и т. п.) и расширений для них. Эти знания требуются, чтобы отличить скрипты непосредственно CMS и ее расширений от посторонних файлов, а также чтобы при встрече с сомнительными скриптами иметь возможность однозначно определить, какие действия они выполняют.
• Для анализа причин взлома требуется опыт администрирования сервера . Это необходимо для анализа состояния файлов на аккаунте, времени их изменения, а также для сопоставления этих данных с журналами сервера для определения, какие именно действия злоумышленника привели к взлому сайтов.

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

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

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

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

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

Сразу после обнаружения взлома сайта необходимо полностью заблокировать к нему доступ посетителей . Это, во-первых, помешает злоумышленнику вести вредоносную деятельность на сайте, а во-вторых, не позволит ему препятствовать проведению восстановительных работ. Этот шаг очень важен, так как удаление вредоносных скриптов и устранение причины взлома не происходит одномоментно — как правило, на это требуется несколько часов. Если сайт останется доступным извне, злоумышленник сможет произвести повторную загрузку скриптов в тот раздел сайта, который уже был очищен. При этом злоумышленник может использовать различные IP-адреса для подключения, поэтому запрет доступа только для списка IP-адресов не даст результата. Чтобы гарантированно очистить сайт от найденных вредоносных скриптов, необходимо полностью закрыть для злоумышленника возможность обращения к сайту, что можно сделать только с помощью полной блокировки сайта для любых посетителей. Обратитесь в службу технической поддержки хостинга, на котором размещается ваш сайт, чтобы произвести блокировку.

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

После блокировки сайта и проверки на вирусы необходимо изменить все пароли доступа к аккаунту: доступы через FTP, через SSH, а также доступы к панели управления хостингом. Если злоумышленник получал доступ к файлам аккаунта одним из этих способов, после смены паролей он больше не сможет сделать это.

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

Теперь проникновение на сайт извне невозможно и можно приступать к его восстановлению.

Перед дальнейшими действиями удалите все существующие файлы сайта , чтобы среди них гарантированно не осталось вредоносных скриптов, или скриптов CMS, в которые злоумышленник внедрил вредоносный код. Этот шаг также важен, так как при восстановлении сайта из резервной копии не всегда удаляются файлы, которые существовали до восстановления. Если после восстановления из резервной копии на сайте останутся старые вредоносные скрипты, злоумышленник сможет повторно проникнуть на сайт. Избежать этого можно, удалив все файлы сайта перед проведением восстановления.

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

После восстановления из резервной копии обновите используемые версии системы управления сайтом (CMS) и ее расширений до последних. Это необходимо, чтобы исключить присутствие на сайте известных уязвимостей, через которые он может быть взломан. Как правило, обновление можно произвести через раздел администрирования CMS. Для получения полных инструкций по обновлению CMS необходимо обратиться на сайт разработчика системы. Важно обновить не только саму CMS, но и все ее расширения, так как часто взлом происходит через уязвимость, присутствующую в одном из расширений CMS (например, плагины, темы оформления, виджеты и пр.). В этот момент еще нельзя снимать блокировку сайта для посетителей, так как он может быть еще уязвим. Чтобы получить доступ к сайту для обновления, обратитесь в техническую поддержку хостинга, на котором размещается ваш сайт, и попросите разрешить доступ к сайту только с IP-адреса вашего компьютера. Узнать ваш IP-адрес вы можете, например, на inet.yandex.ru .

После обновления системы управления сайтом и ее расширений зайдите в раздел администрирования сайта и измените пароль доступа администратора к нему. Убедитесь, что среди пользователей сайта нет других пользователей с административными привилегиями (они могли быть добавлены злоумышленником), а если таковые обнаружатся — удалите их.

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

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

Чтобы защитить сайт от повторных взломов в будущем необходимо придерживаться следующих рекомендаций:

Следите за обновлениями CMS и расширений для нее на сайтах разработчиков и своевременно производите их обновление до последних версий. Если в комментарии об обновлении присутствует информация о том, что оно устраняет какую-либо уязвимость, установите это обновление как можно быстрее.

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

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

Не сохраняйте в программах для подключения к сайту пароли от FTP и SSH, а также не сохраняйте в браузере пароль доступа в административный радел сайта и в панель управления хостингом.

Время от времени (например, раз в три месяца) изменяйте пароли доступа к сайту и к аккаунту хостинга.

Если на компьютере, с которого производилась работа с сайтом, были обнаружены вирусы, измените пароли доступа к сайту и аккаунту хостинга как можно быстрее. Изменять необходимо все пароли: пароли доступа по FTP, SSH, пароль от административной панели сайта, а также пароль от панели управления хостингом.

Не предоставляйте доступ к сайту третьим лицам, если вы не уверены, что они также будут следовать приведенным рекомендациям.

Сначала у него было 4 torjan-инфицированных js файла и некоторый вредоносный код. Я очистил эти файлы. Но теперь я не могу найти этот javascript include.

Вы можете посмотреть, просмотрев источник страницы.

Он включается в конце каждого. Он хранит страницу при загрузке, а сканер обнаруживает ее как вредоносный код.

То, что я пробовал до сих пор.

1) Измененный шаблон 2) Попробуйте отключить все компоненты. 3) попытайтесь отключить все компоненты. 4) попытался отключить все плагины. 5) загрузил полный сайт и выполнил поиск этого кода на полном сайте. Но не смог найти.

Но он все еще был там. Можете ли вы дать мне несколько предложений?

4 ответа

Вредоносный код присутствует на странице, даже если javascript отключен - это говорит нам, что он не написан там document.write в других js файлах.

Когда мы посещаем сайт с настройками tmpl = component & no_html = 1, которые подавляют вывод шаблона и отправляют только компонентный вывод, код все еще присутствует: http://ziggymonster.com/?tmpl=component&no_html=1

Это будет довольно сильно указывать на то, что код добавляется в конец основного файла Joomla index.php в корень вашего сайта. Альтернативно, файл component.php в вашей собственной папке шаблона или в папке /templates/system/может быть жизнеспособным кандидатом.

Очистка сайта на месте рискованна - но это может быть сделано с правильными знаниями, опытом и правильными инструментами. Я бы посоветовал найти опытного эксперта по безопасности Joomla, чтобы сделать это, или пересоздать файлы сайта: установить новую Joomla в абсолютно чистой папке (лучше было бы использовать локальный сервер), установить все свои расширения, а затем удалить свою живую сайта и загружать файлы в ваше веб-пространство, привязывая файлы к исходной базе данных.

Конечно, возврат к резервной копии с нескольких дней назад был бы лучшим вариантом - у вас есть резервные копии да?

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

Если вам нравится ssh, вы можете использовать эту команду:

Find . -type f -iname "*.php" -exec grep -l "mail(\|eval(\|sockopen\|socket_client" {} \;

Которая ищет файлы php (рекурсивно из текущего каталога), содержащие опасный код. PHP-функции почтовых ящиков представляют интерес для хакеров, но для этого существуют функции eval и api. Я запускаю эту команду на своем сервере один раз в день, и в прошлом он обнаруживал вредоносные скрипты.

самый быстрый способ удалить все виды вредоносного кода - подключиться через ssh, открыть каталог сайта yous и запустить запрос типа:

find. "*.*" -exec replace "HERE_IS_BAD_CODE" "" -- {} \;

вы также можете фильтровать типы файлов для поиска, изменяя. на *.php или *.html

disclamer: вы должны быть ОЧЕНЬ ОЧЕНЬ осторожны с ssh

Чтобы быть уверенным, вам нужно перестроить свой сайт. Резервное копирование базы данных и файлов, а затем удалите ВСЕ файлы из docroot и повторно загрузите их из свежих копий (Joomla с http://www.joomla.org/ , расширения со своих сайтов и т.д.). Затем вы повторно загрузите свою медиа-папку и любой пользовательский код (шаблон и т.д.).

Если вы не очень техничны, вам нужно будет установить Joomla и расширения, а затем удалить базу данных и configuration.php и повторно загрузить старый файл configuration.php и базу данных. В противном случае вам придется самостоятельно распаковывать расширения.

По крайней мере, я бы рекомендовал загрузить новую копию ядра Joomla (вам нужно будет удалить каталог "установка" сразу после этого). Это довольно безопасно, так как дистрибутив не перезаписывает вашу конфигурацию.php. Конечно, если вы взломали ядро Joomla (Bad Idea), вам нужно будет повторно применить свои пользовательские хаки.

Также было бы неплохо рассмотреть ваши меры безопасности - нужно ли менять свои пароли? Все ли ваши файлы должны быть доступны для записи на веб-сервере?

Если у вас есть доступ к сайту по SSH, вы можете найти файлы с инжектированным кодом выполнением следующих команд:

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot #grep -lr --include=*.php "strrev(" /pathWebroot

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

Вот пример листинга: ./components/com_wrapper/wrapper.php ./components/com_wrapper/controller.php ./components/com_wrapper/router.php ./components/com_wrapper/views/wrapper/view.html.php ./components/com_banners/models/banner.php ./components/com_banners/models/banners.php ./components/com_banners/controller.php ./components/com_banners/router.php ./components/com_finder/views/search/view.html.php ./components/com_finder/helpers/route.php ./components/com_finder/helpers/html/filter.php ./components/com_finder/helpers/html/query.php ./components/com_finder/controllers/suggestions.json.php ./components/com_jshopping/tables/productfiles.php ./components/com_jshopping/tables/statictext.php ./components/com_jshopping/tables/country.php ./components/com_jshopping/tables/productlabel.php ./components/com_jshopping/tables/shippingext.php .... ./administrator/components/com_jshopping/controllers/orderstatus.php ./administrator/components/com_jshopping/controllers/shippingsprices.php ./administrator/components/com_jshopping/controllers/vendors.php ./administrator/components/com_jshopping/controllers/productlabels.php ./administrator/components/com_jshopping/controllers/categories.php ./administrator/components/com_cache/cache.php ./administrator/components/com_cache/models/cache.php ./administrator/components/com_cache/controller.php ./administrator/components/com_cache/views/purge/view.html.php ./administrator/components/com_cache/views/cache/view.html.php ./administrator/components/com_cache/helpers/cache.php ./administrator/components/com_content/tables/featured.php

Итого 1606 вхождений. Это практически все PHP файлы. Удалять инжектированный код вручную бесполезно. На это уйдет слишком много времени. Обнаружен и новый файл images/post.php для исполнения любого кода.

Удаление вредоносного кода из зараженных файлов

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

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

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot | xargs sed -i.bak "s/eval(base64_decode[^;]*;//" #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//"

Команды удалят все вхождения подобного вредоносного кода из файлов и сделает их резервные копии с расширением.bak. Это позволит вам только выиграть время для осуществления полного восстановления сайта, но не избавит вас от последующих атак. Следует понимать, что высока вероятность наличия файлов, типа images/post.php описанного выше, для исполнения любого кода и старые дыры в установленных расширениях.

Сторонние расширения

Если вас не лишили административной панели сайта, вы можете посмотреть установленные компоненты, модули, плагины и шаблоны. Если доступа нет, необходимо просмотреть содержимое сайта подключившись по FTP или SSH.

Смотрим список модулей #ls ./modules index.html mod_banners mod_login mod_users_latest mod_articles_archive mod_breadcrumbs mod_menu mod_weblinks mod_articles_categories mod_custom mod_random_image mod_whosonline mod_articles_category mod_feed mod_related_items mod_wrapper mod_articles_latest mod_finder mod_search mod_articles_news mod_footer mod_stats mod_articles_popular mod_languages mod_syndicate #ls ./administrator/modules index.html mod_latest mod_menu mod_quickicon mod_title mod_custom mod_logged mod_multilangstatus mod_status mod_toolbar mod_feed mod_login mod_popular mod_submenu mod_version

Используются только стандартные модули Joomla

Смотрим список компонентов #ls ./components com_banners com_finder com_media com_search com_wrapper com_contact com_jshopping com_newsfeeds com_users index.html com_content com_mailto com_phocapdf com_weblinks #ls ./administrator/components com_admin com_config com_installer com_media com_phocapdf com_users com_banners com_contact com_joomlaupdate com_menus com_plugins com_weblinks com_cache com_content com_jshopping com_messages com_redirect index.html com_categories com_cpanel com_languages com_modules com_search com_checkin com_finder com_login com_newsfeeds com_templates

Кроме стандартных компонентов используются com_jshopping и com_phocapdf .

Смотрим список плагинов #ls ./plugins authentication content editors-xtd finder phocapdf search user captcha editors extension index.html quickicon system

Кроме того, необходимо просмотреть содержимое всех этих папок. Они представляют собою группы плагинов.

#ls ./plugins/authentication gmail index.html joomla ldap #ls ./plugins/captcha index.html recaptcha #ls ./plugins/content emailcloak geshi joomla pagebreak rokbox finder index.html loadmodule pagenavigation vote #ls ./plugins/editors codemirror index.html none tinymce #ls ./plugins/editors-xtd article image index.html pagebreak readmore #ls ./plugins/extension index.html joomla #ls ./plugins/finder categories contacts content index.html newsfeeds weblinks #ls ./plugins/quickicon extensionupdate index.html joomlaupdate #ls ./plugins/search categories contacts content index.html newsfeeds weblinks #ls ./plugins/system cache highlight languagecode log p3p remember sef debug index.html languagefilter logout redirect rokbox #ls ./plugins/user contactcreator index.html joomla profile

Кроме стандартных плагинов используется плагин phocapdf .

Смотрим список шаблонов #ls ./templates atomic beez_20 beez5 index.html system templ1

Кроме стандартных шаблонов используется templ1 .

Восстановление зараженного сайта

• Скачиваем дистрибутив последнего релиза, распаковываем архив в директорию будущего сайта и удаляем из нее директорию installation.
• Переименовываем файл htaccess.txt в.htaccess. Если в нем использовались директивы записанные вами , перенесите их из зараженной копии.
• Копируем файл configuration.php из зараженной копии, предварительно просмотрев на отсутствие в нем инжектированного кода.

Сторонние расширения

• Находим используемые сторонние компоненты Phoca PDF, JoomShopping, плагин "Phoca PDF Content Plugin", скачиваем.
• Распаковываем и копируем файлы, предварительно создав структуру директорий как у зараженной копии. Не забываем про файлы локализации.

Немного сложнее обстоит дело с шаблоном. Шаблон сгенерирован специальным программным обеспечением и найти его не представляется возможным. Придется "выковыривать из него все ненужное".

К счастью, в шаблоне присутствует 21 PHP файл и весь инжектированный код был удален командой #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//"

Собственные файлы

• Создайте каталоги, в которых вы держали изображения, документы и прочие файлы и скопируйте их.

Сайт должен начать работать сразу, как только вы замените старое содержимое новым.

Зайдите в административную панель сайта, замените имя пользователя и пароль доступа к CMS и посмотрите, не заменен ли e-mail SuperUsers (злоумышленник может воспользоваться функцией восстановления забытого пароля). Никогда не используйте стандартное имя пользователя admin . Внимательно посмотрите права всех пользователей. Не исключена возможность заведения злоумышленником еще одного администратора.

Замените имя пользователя, пароль к базе данных MySQL, если используется стандартный префикс таблиц базы данных jos_ необходимо его заменить другим, это предотвратит вероятность атаки SQL инъекциями.

По окончанию восстановительных работ установите плагин BotsGo404.

Если эта статья показалась вам полезной, пожалуйста, проголосуйте за нее. Это поможет другим быстрее найти эту статью из множества других менее полезных. (17 Голосов)