После более подробной беседы, выяснилось:
- Аккаунт хостинга, на котором был расположен сайт, ранее был блокирован за рассылку спама.
- По словам клиента проблема решилась, когда он обратился к предыдущим разработчикам, они восстановили доступ и все снова стало работать как раньше.
- Какие именно манипуляции проводили разработчики он не знает, так как хостинг зарегистрирован не на него, а на какого то его друга, который и посоветовал ему этих ребят.
- Сайт снова не работает, но связаться с кем либо из тех кто устранял проблему в прошлый раз, на данный момент, он не может.
Нам стало интересно, что же там такое происходит с сайтом, что он уже второй раз выходит из строя. Мы попросили клиента связаться со своим другом, на которого оформлен хостинг и узнать у него доступы к панели управления, а сами связались со службой технической поддержки хостинга, для уточнения причин неработоспособности сайта.
Для тех кто зашел прочитать непосредственно про взлом, можете смело жмакать сюда. Ну а для тех кому интересна вся история целиком, как все было обнаружено, читайте полностью.
После ответа службы поддержки стало ясно, что доступ к панели управления заблокирован, как и сам аккаунт, за распространение спам писем и получить доступ к нему возможно только по предоставлению данных для входа и IP к которому будет привязан временный доступ.
Да, все верно, те же грабли. Разница в этот раз была лишь в том, что по словам друга, который согласился предоставить данные от хостинга, сайта на аккаунте больше нет и восстановить ничего не выйдет. Так ему сказали те самые разработчики, которые очень "эффективно" решили проблему в прошлый раз.
Немного порассуждав, мы решили попытать счастья и постараться восстановить сайт из бэкапов, которые должны были храниться у хостинг провайдера. Предоставили всю необходимую информацию и IP адрес, с которого будет производиться вход. Зашли в аккаунт и первым делом решили посмотреть историю запросов к службе поддержки, по предыдущему случаю блокировки.
Переписка оказалась небольшой и нам удалось выяснить, что:
- Был подобран пароль к админке сайта.
- Через модуль установки плагинов, был вшит скрипт рассылки спам писем.
- Никаких профилактических работ ребята не предпринимали, а попросту решили восстановить сайт из бэкапа, при этом не трогая базу данных и не меняя пароля к ней и админке сайта.
- По прошествии какого то времени аккаунт снова был заблокирован, по причине того, что они не устранили скрипт.
Проверив фалы в корневом каталоге, мы обнаружили, что сайт существует и никто его не удалял, как нам сообщил ранее друг клиента. Более того, последний вход в аккаунт был произведен как раз после предыдущего инцидента взлома. Больше в аккаунт никто не заходил.
Мы создали новый запрос в техподдержку, с просьбой уточнить, в каких именно файлах был обнаружен вредоносный скрипт, для того, что бы иметь хоть какое то представление, что искать.
Как же производили взлом и рассылку
Получив ответ службы поддержки, мы нашли нужный файл и увидели там это:
Пройдясь по всем файлам сайта, было обнаружено такое же содержимое еще в 74 файлах шаблона. Проанализировав код, проверив все пути, мы поняли, что:
- После взлома админки сайта, по средствам установки плагина, был внедрен вредоносный скрипт
- Через переменную $_POST на адрес сайта посылался запрос содержащий исполнительный код, который выполнялся во всех файлах, в которых была данная строка, а в данном случае таких фалов было 74.
- После выполнения скрипта, с аккаунта производилась рассылка спам писем, адреса которых хранились во все той же базе данных сайта, в отдельной таблице, которую предыдущие разработчики не удосужились проверить.
- Так же, в базе данных была обнаружена еще одна таблица, не относящаяся к сайту, в которой хранился зашифрованный base64 код, который не только выполнял восстановление удаленных вредоносных строк во всех файлах, но и занимался более интересными вещами (об этом чуть ниже).
- Горе гении, которые якобы выполняли очистку в прошлый раз, видимо не захотели углубляться в проблему и выполнять тяжелую работу по очистке всех файлов вручную, дабы избежать повторного заражения. Либо же они имели непосредственное отношение к данному скрипту (так как очистка сайта от вирусов, по прайсу, указанному на их сайте, стоила не маленькую сумму).
Мы почистили все файлы, очистили базу данных, сменили все доступы от сайта и хостинга, а так же сообщили техподдержке о том, что проблема устранена. Аккаунт был разблокирован и сайт снова стал доступен.
О скрипте, найденном в базе данных взломанного сайта
Скрипт, который был зашифрован в кодировке base64 и хранился в базе данных в виде текста, не только выполнял функцию восстановления всех удаленных строк вредоносного кода, но и являлся скриптом брутфорса.
Основная функция которую он выполнял, заключалась в посыле POST и GET запросов, на адреса админок различных сайтов, с логинами и паролями, так же хранимыми в одной из таблиц базы данных. После успешно выполненной операции по подбору, он записывал правильную пару логин: пароль в еще одну таблицу, доступ к которой можно было получить обратившись с правильным запросом к одному их 74 зараженных файлов, прямо из окна браузера.
Такими манипуляциями злоумышленники не только ускоряли процесс сбора паролей, но и увеличивали базу сайтов, с которых велась спам рассылка и выполнялся подбор паролей к другим сайтам.
Такой цикл может продолжаться бесконечно. Если один из владельцев сайта находит вирус и удаляет его, то это небольшая потеря для злоумышленников, потому как в их распоряжении огромная база таких вот лазеек, которая увеличивается с каждым днем.
P.S.: для тех кто желает видеть скрипт. Скриншоты и примеры вредоносного скрипта небыли выложены по причине того, что всегда найдутся личности, использующие пример кода как основу для своих детищ, а я не хочу являться причиной создания и распространения очередного вредоносного скрипта.
Комментарии (24)
demimurych
06.12.2017 14:41очередных горе разработчиков
посоветовал ему этих ребят
те самые разработчики, которые очень «эффективно»
профилактических работ ребята не предпринимали
которую предыдущие разработчики не удосужились проверить
Горе гении, которые якобы выполняли очистку в прошлый раз
Еще бы пару раз сказать про «ребят горе гениев» и было бы совсем чудесно.
aleteyya
06.12.2017 15:31Здравствуйте! Для начинающих статья полезна, но не решает проблемы.
Я начинаю узнавать эту сферу с нуля и попробовала создать свой сайт, теперь не могу избавиться от этой заразы-спама. Может кто знает что надо делать, что бы устранить это постоянный взлом? И что мне стоит прочитать что бы улучшить безопасность?
Спасибо
KIBIs
06.12.2017 19:54Не раз обращались с аналогичными проблемами с сайтами на движках WP и Joomla. Обычно это случается из за использования варезных плагинов или чаще всего шаблонов в случае с WP. В одном случае был целый сервер у одного клиента, который был взломан а вместе с ним десяток сайтов на WP. Причем «взломщики» не стеснялись оставлять файлы с ссылками на свой форум. Последний раз это были «хакеры» из Турции что подтвердждали файлы с текстами на турецком и множественными запросами с турецких IP. Обычно в таких случаях использую давно зарекомендававший себя AI-Bolit, естественно ручного поиска это не отменяет. Главное найти общий почерк, сигнатуру и искать по аналоги по всем файлам на хостинге. В то же время очень много встречалось файлов у которых владельцом был root (взломанный) и права 777, названия схожие с системными папками движка но отличающимися некоторомы символами или цифрами в конце. Так как лечение проводил на территории клиента, решил скачать вче файлы на локальный компьютер и проводить лечение всех и сразу. На компе стоял антивирус NOD32 который при копировании файлов ругался на вирусы. Это стало еще дополнительным инструментом обнаружения и почти все файлы с внедренными скриптами в их теле были обнаружены. Оставшуюся часть скриптов внедренных и в системные файлы движка выявлял find и grep-ом в терминале. Так как файлов было очень много, во время лечения на сервере сайтов на каждом домене, через какое то время происходил повторный взлом раннее вылеченных сайтов. Поэтому лучше все лечить локально и все и сразу загружать на хостинг. После выявления и устранения отдельных файлов со скриптами и инъекций скриптов в системные файлы, были обновлены движки WP и плагины на которые имелись обновления (все они были довольно устаревшими). После лечения и обновления на каждом сайте с движком WP был установлен и настроен ninja firewall, который умеет защищать и мониторить изменения в файлах на сайтах и блокировать брутфорс и множественные частые запросы с IP. Естественно IP собранные из логов были забанены тоже. Были сменены все доступы и по возможности логины. Совместно с саппортом их сервера были приведены в порядок владельцы и права на все папки и файлы. Повторного заражения на данный момент (прошло более 10 месяцев) нет.
P. S. Как показал анализ IP, не все они были турецкими, были и немецкие и российские IP адреса множества хостинг провайдеров где вероятнее всего были размещены ранее взломанные сайты, через которых взламывались следующие сайты и сайты клиента в том числе.
JohnnyBlack
06.12.2017 15:34+1Для тех кто считает статью плохой и ставит минусы: пишите пожалуйста в комментарии почему вы так решили.
Минус не ставил, но поясню, что с моей точки зрения тут «не так».
После прочтения материала сложилось впечатление, что что для вас подобный обыденный случай был ошеломляющей победой, о чём вы и решили рассказать всему миру. Это уже второй ваш материал с броским заголовком и скучным текстом внутри, где вы описываете вещи в духе «он мне такой..., а я ему это..., а он мне опять такой...». Термины типа «взлом», «анализ кода», «уязвимости», «злоумышленник» и пр., по идее, должны прибавить «вес» статье, но по факту вызывают лишь лёгкое недоумение. Почему? Потому что нет никаких примеров кода (картинка с eval не в счёт — это такой баян, что даже говорить об этом смешно), не описаны способы автоматизации выявления/лечения, нет никаких советов по практической защите проектов — в общем, нет ничего полезного даже для новичка в этом вопросе. Могли бы хотя бы поискать подобные материалы тут, поинтересоваться, кто и как подавал информацию читателям, почитать отзывы, кто и на что внимание обращал. А у вас это всё больше похоже на самолюбование с колкостями в адрес тех других, что пытались решить проблему до вас. Причём это уже вторая ваша статья, где описывается «лох-клиент», «предыдущие лохи-разработчики» и вы в роли героев. И опять создаётся впечатление предвзятости и каких-то недоговорок.
Ну и ещё пара моментов:
<...> сами связались со службой технической поддержки хостинга, для уточнения причин неработоспособности сайта.
А сами, то есть без техподдержки, вы не могли определить неисправность?
Через модуль установки плагинов, был вшит скрипт рассылки спам писем.
Речь опять про WP, отсюда вопрос: куда именно был добавлен скрипт?
Мы создали новый запрос в техподдержку, с просьбой уточнить, в каких именно файлах был обнаружен вредоносный скрипт, для того, что бы иметь хоть какое то представление, что искать.
Сами не могли разобраться? Техподдержка если что-то такое и может обнаружить, то далеко не всё и не всегда. Это так, для справки. И если у вас в компании/студии нет спецов с большим опытом по данным вопросам, то вы и сами рискуете стать героями чьей-то аналогичной статьи и получить звание «горе-разработчиков».
У WP есть ряд серьёзнейших слабых мест, но если вас пассивно ломанули, то предположу два момента: пароль был в духе «qwedsa123» и защиты не было от слова «совсем». Так что, как и в предыдущей статье, вина не в стороннем сервисе и не на WP, а вина на владельце ресурса.
aleteyya
06.12.2017 16:34Добрый день. Нашла способ простого фикса, во первых прочитать тщательно письмо от тех поддержки, там написано, что делало проблему. Потом я решила поставить плагин скан на наличие ошибок — Wordfence. Все по полочкам разложил и помог понять где были ошибки. Они были в корневых файлах типа config.php
Далее обновить вордПресс до последней версии и с ним все плагины и темы и сменить доступы к сайту и можно и к базам.michael_vostrikov
06.12.2017 18:01Можно в git всё положить, сразу будет видно какие файлы изменены, и вернуть к исходному состоянию можно одной командой.
PavelBelyaev
06.12.2017 22:24Был такой опыт, сперва мониторил почтарь, дальше post запросы грепал на все ссылки, заканчивающиеся на .php, т.к. ЧПУ обычно без расширений. Дальше искал php там, где их не должно быть, дальше понял, что вирус вписывается в виде открывающего <? и кучи пробелов, т.е. прячется за пределами экрана, дальше eval и base64 искал, потом нашел кучу файлов php, которые без подозрительного кода, но инклудят что-то вроде jpeg текстовых, потом запретил прямой доступ к папкам с либами, ибо точка входа index.php, дальше забанил все php по маске в прямом доступе из сервера. Потом еще махинации с правами доступа к php, в итоге система не может меняться, а аплоад не может исполняться по прямой ссылке. Всё это у одних знакомых на серваке, прошёл год и всё чисто. Обновлять чужие джумлы с кучей кастома не хотелось.
AKYLA
06.12.2017 23:15Вроде как не ново, ещё три года назад как минимум была куча сайтов таким образом заражена, да и сегодня тоже довольно много подобных и сложнее случаев, когда кусок вредоносного скрипта, очень короткий и так просто себя не выдаёт, вот тогда это головная боль. А чистить не всегда нужно руками, но главное внимательно.
Spectre
07.12.2017 01:49Статья о лечении адского заражения, которое (лечение) на фрилансе стоит 50$ и занимает 20-30 минут времени
Bel0g0r Автор
Для тех кто считает статью плохой и ставит минусы: пишите пожалуйста в комментарии почему вы так решили. Потому как по времени, максимум что Вы прочитать успели, был заголовок и пара строк текста ниже.
timelle
Возможно, кому-то показался предвзятым тон статьи, а кому-то — очевидной причина спама. Но действительно если даешь негативную оценку, то дай свой фидбек по материалу, чтобы автор мог учесть в будущем.
michael_vostrikov
Статья опубликована в 01:36, ваш комментарий в 01:46. Вы считаете, что люди не могут за 10 минут 80 предложений прочитать?
И на данный момент у статьи всего 2 минуса. Почему это вас так задевает?
ozonar
437 слов за 10 минут это 44 слова в минуту, в третьем классе быстрее читают. Прочитать статью за 2 минуты — не проблема.
michael_vostrikov
Что-то тут не сходится. Он сказал, что не может связаться, но потом вы попросили его это сделать.
И тут не сходится. Друг ему сказал, что сайта больше нет, но он якобы не может понять, почему сайт не работает.
Простите, что? Спам это по определению нежелательные письма. Даже если бы они "удосужились проверить", то что они должны были обнаружить? Какие-то почтовые адреса, пользователи которых не хотят получать спам? Почему это должно было их насторожить?
А нафиг вы вообще написали про это на технический сайт? Покрасоваться какие вы клёвые?
Bel0g0r Автор
Начну по порядку.
1. Связаться он не мог не с другом, а с теми ребятами которые делали сайт.
2. Узнал он о том что сайта якобы нет, уже после того как пришел к нам, и позвонил своему товарищу.
3. Адреса хранились в отдельной таблице, не имеющей отношения к WP и сайту вообще. Насторожить должно было то, что таблицы не имели префиксов как минимум и содержали только email адреса.
4. Если вы считаете, что в статье про реальный случай взлома, обязательно должен быть код или скриншоты того как это все произошло, то Вам на форумы тех кто этим промышляет.
lostpassword
michael_vostrikov
1, 2. Ну ок, поправили статью.
3. Ну и что? Ну email'ы какие-то. Что они должны были сделать, таблицу удалить? А если сломается что-нибудь, отвечать потом?
4. Собственно, мой вопрос остается в силе. Зачем вы написали об этом на сайт технических специалистов?
Я раз 10 за последние несколько месяцев такое делал. Потому что у начальника сайт компании на ВордПрессе. Только я не пишу об этом статьи, потому что и так все знают, что ВордПресс дырявая штука.
redfs
Хотя минусов я не ставил да и не могу я этого делать, но попробую сформулировать причину, почему мне не понравилась статья.
Проблемы, описанные вами, уже лет 10 как довольно будничные и не представляют какой-либо теоретической ценности. Профессионалы решают их «по щелчку» и без всякого интереса — ибо набили оскомину.
Вы даже не представляли, что искать? Это многое объясняет. Но мне искренне жаль техподдержку. Вы ведь прочитали предыдущую переписку, об этом было написано в первом письме от них.
А вообще, это предложение как раз и характеризует мое отношение к вашей статье.
Вы подаете материал, как свою победу в маленькой войне, а на самом деле решили курсовую работу. Победа — это хорошо, но мне странно наблюдать за студентом, решившим задачу, уничижительно отзывающегося о других студентах, которые с задачей не справились.
KIBIs
Не минусовал, но соглашусь с большинством, что было бы хорошо, если в статье было больше технических деталей, не полного листинга но хоть части этих скриптов чтобы иметь представление. Так же не хватает описания решений и инструментов которыми вы пользовались. Новичкам бы это пригодилось.