Взломали сайт Shop-script v 300-309. Решение!
Добрый день! С учетом участившихся случаев взлома сайтов на старой системе, решил написать статью как это делается и как это вылечить.
Если вас взломали, привели сайт в не рабочий вид и прислали письмо, не отвечайте на него!
Начнем с того как вас взломали.
1. Подбор пароля от INSTALLER
В старых системах был дополнительный интерфейс о котором часто даже владельцы сайтов не знали www.site.ru/installer/, если вы заранее предостерегались и удалили папку installer или поставили туда .htpassw (HTTP авторизацию), есть второй путь www.site.ru/published/wbsadmin/html/scripts/wbsadmin.php Отличие этого интерфейса, это возможность редактировать ваши файлы на сервере, просматривать конфигурацию базы данных(пароли), а также пароли главного пользователя и суперпользователя administrator (о нем будет отдельно написано). Часто при создании сайтов вебмастера, устанавливающие систему, ставили простые пароли, чтобы быстро заходить для отладки при переносе и тд... Соответственно логин admin и пароль - admin, 1234, qwerty, 54321, 123123, qawsed, qazxc и тд.. Таких паролей около 700, называются "самые частые пароли". Взломщик подобрал пароль и изменил один из файлов на веб-шелл, через который получил полный доступ к вашей файловой системе.
2. Парсинг открытого файла паролей от INSTALLER (.wbs_protect)
Все тот же installer, пароли от которого хранятся в специальной закрытой от доступа из интернета. Файл с паролем находится по адресу www.site.ru/temp/.wbs_protect. Файл содержит сериализованный массив данных учетной записи входа в installer: логин в md5, пароль в md5 и их объединение в md5. Иногда в процессе эксплуатации, намерено или по неосторожности, удаляют или изменяют файл .htaccess в этой же папке, что приводит к открытию файла к чтению из интернета. Взломщик, прочитав файл зачастую может расшифровать пароль и логин для входа, После чего, проникнув в installer, он может дальше делать что хочет.
Также помимо файла паролей от installer, там бывает еще и файл данных подключения к базе данных, он доступен по адресу /temp/scdb/.settings.__ТУТ_ВАШ_КЛЮЧ_БД__. Ключ БД Легко определить открыв исходный код страницы.
3. Подбор пароля записи administrator
Учетная запись administrator имеет доступ к интерфейсу админ панели по адресу site.ru/published/login.php с правами управления пользователями (Команда). Эта учетная запись создается автоматически при установке системы, далее она больше нигде не указана и не видна, пароль от нее можно также сменить в installer. Часто о ней никто не знает, даже те кто устанавливает систему, потому что при установке предлагается создать основную учетную запись, напр. admin, а к ней создается еще и administrator. С учетом халатности некоторых вебмастеров, кодга они ставят систему для теста, они ставят простой пароль для первой учетной записи, дальше конечно они пароль меняют, но пароль записи administrator остается, так как он меняется в инсталлере. Логи попыток авторизации можете увидеть в файле /dblist/wbs.log(пример ниже). При подборе пароля взломщик создавал свою учетную запись и заливал файл, про учетные записи (п. 4).
При попытках подбора примерно так выглядит (это с одного из моих сайтов, запросы каждую секунду):
[2016-12-31 16:35:46] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:47] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:47] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:48] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:48] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:49] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:49] DB60476M 31.28.24.115 administrator web 0 1 [2016-12-31 16:35:49] DB60476M 31.28.24.115 administrator web 0 1
4. Подбор Учетной записи
Наверно многие привыкли называть свои учетные записи admin, Admin или ADMIN. Так вот если помимо такого логина вам еще и лень придумывать и запоминать сложный пароль, вы в группе риска. Описывать подбор пароля уже не буду, и так все ясно. Получив доступ к вашей учетной записи, взломщику надо еще получить доступ к файловой системе..... описывать не буду, чтобы не начали пытаться использовать.... В общем, загрузив или изменив файлик на сервере, взломщик также получит доступ к файлам сервера.
5. У вас стоит NULLED система (самое частое)
Если вебмастер установил вам Вебасист бесплатный,в большинстве случаев это значит он скачан с форума. Раньше специально выкладывали платные системы управления в доступ. Так вот в большинстве из них были добавлены файлы(back door), через которые потом можно было получить доступ к сайту или добавлен код в движок, который срабатывал при определенных запросах. Если у вас Вебасист бесплатный, платить придется простоем бизнеса....
Как восстановить работу взломанного сайта! Решение!
1. Запросите резервные копии файлов и базы данных на вашем хостинге за дату, когда ваш сайт еще работал. Скачайте их на компьютер, Будет как точка восстановления.
2. Смените все пароли от FTP и пароль к самой базе данных и запишите их, дальше пригодятся.
3. Если у вас на хостинге есть функция восстановления из резервной копии, воспользуйтесь ей, восстановите файлы и базу данных через нее. Если такой функции нет, вам придется по FTP удалить все файлы в папке домена, и загрузить их из скачанного архива(который точка восстановления) на сервер в папку файлов домена, затем вам необходимо зайти в вашу базу данных и также обносить до точки восстановления, а то мало ли там уже успели что-то запихнуть чтобы потом использовать для доступа. Лучше конечно восстанавливать через хостинг, у них и быстрее и надежнее.
4. После того как вы восстановили файлы и базу данных, ваш сайт должен заработать.
5. Дальше вам надо зайти в INSTALLER (адреса выше писались). Если у вас по этому адресу форма авторизации, вы должны удалить на сервере файл в папке temp/.wbs_protect, после чего обновить страницу.
Попав на главную страницу INSTALLERa, вы должны первым делом создать логин и пароль для входа в INSTALLER. Надеюсь вы создадите не admin admin!
6. Зайдите на страницу Настройки и выберите подпункт меню "MySQL-сервер". Там в строке ввода "Хост MySQL:*" введите адрес для подключения к серверу mysql, обычно locahost, но может быть и другой.
7. Перейдите на вкладку "База данных", Там введите данные для подключения к базе данных: пользователь базы данных, пароль пользователя и имя самой базы данных, все это узнать можно у вас в хостинге.
9. Выберите пункт верхнего меню "Диагностика" и подпункт "Сброс кеша". Очистите кеш!
10. Также можете зайти в пункт "Информация о системе", посмотреть все ли работает как надо, зеленые галочки должны стоять везде, или почти везде!
11. Попробуйте зайти на сайт. Если он работает - хорошо, если нет, значит что-то напутали с настройками подключения к базе данных.
12. Проверьте наличие файла /temp/.htaccess, в нем должна быть строка "Deny from all" - запретить для всех. если нет файла или строки, создайте и запишите, затем попробуйте запросить файл www.site.ru/temp/.wbs_protect через браузер, он должен выдать ошибку : 403 нет доступа.
13. Зайдите под учетной записью administrator и смените всем пароли!
13. Проверьте файлы сервера на наличие лишних файлов( веб-шеллов ), проверьте, код всех файлов на наличие небезопасных функций.
P.S. Если взлом повториться, вам придется чистить файлы от вредоносного кода, так как пароли везде были изменены, остается только уязвимость в файлах системы или может оказаться, что вас взломали через ваш другой сайт, например на Joomla....
30 ответов
Супер!
Не поленились.
Я бы, после того как сайт был восстановлен, рекомендовал бы обновить его до последней (309) версии.
При возможности конечно. Если были доработки по сайту - то не получится. Но многие работают без доработок. И, если есть возможность, тем у кого 309 версия всё равно сделать обновление из инсталлера. (т.к., вероятнее всего, файлы скрипта на модификацию проверит только 1 из 100).
И FTP на хостинге лучше вообще отключать и включать только по необходимости.
Через FTP редко ломают, в основном по заказу или когда логин равен паролю(через файл .passwd). Без проверки файлов нет смысла восстанавливать, доступ останется у взломщика. Если на хостинге несколько доменов, то и на других доменах наверняка уже есть шеллы или измененные файлы!
Для проверки могу посоветовать скрипт Айболит (https://revisium.com/ai/) явные угрозы определяет.
По FTP редко ломают тех, кто не сохраняет логины и пароли к FTP в клиентах (Total Commander, FileZilla).
Но все же ленивые. Потом сохраненные пароли воруют вирусы и потом как повезет. Я видел неоднократно.
Шикарная статья, в раскладкой по пунктам!
Спасибо! Старался чтобы было понятно всем, а не программистам!
Для инфо.
Кроме Айболита есть полезные штуки:
У техподдержки Вебасиста был скрипт verifyss.php который считал MD5 суммы всех файлов скрипта и сверял их с тем, что сохранено в контрольном файле .webasyst.md5
Кроме него был еще filesearch.php который от Rat. Там можно было дату модификации файла проверить, еще что-то (сейчас уже не помню, давно не пользовался им).
Вероятно у техподдержки сейчас что-нибудь новое есть. Эти я брал много лет назад.
Сюда бы выложить их!
Я уточню в техподдержке не будут ли они против по каким-то причинам и нет ли обновленной версии.
Разве что на взломанных сайтах начнут менять проверочные файлы с хешами...
я так делал, подделывал отчеты айболита, чтобы файлы не распознавались!
Файл с хэшами можно взять из инсталляшки и заменить на оригинальный (или сравнить с оригиналом).
Лучше самому генерировать, когда допустим модуль какой-то прикрутил, перегенерировал, скрипт не особо там сложный!
Для рядового пользователя нет этого скрипта, чтобы он мог взять и пользоваться.
И у Shop-Script 7 нет файла с контрольными хешами.
Кстати - не плохая идея для плагина. Можете написать.
Чтобы генерил файл хешей, позволял его скачать, потом, при необходимости, загрузить и сравнить текущие хеши файлов с контрольными. Будет полезная штука. Может будут покупать.
у меня то есть такой скрипт, но не думаю что он как плагин пойдет...
Файл есть. Но такой файл есть далеко не у всех сторонних разработок — он еще не стал обязательным.
Владислав, у Shop-Script 7 в файле .files.md5 хеши только для файлов инсталляционного архива. После у становки в нем смысла уже нет.
Проверить целостность файлов установленного магазина не получится, нет контрольных сумм.
для каждого приложения/плагина/темы отдельные файлы. например в директории wa-apps/site/
Точно, там для каждого приложения есть.
Выходит - нет инструмента для проверки только.
Ну и нет инструмента что бы сгенерировать общий файл с хешами для последующих проверок. Шелл же не только в wa-apps/ может быть, но логичнее его в wa-data/public/ положить, там нет возможности проверить.
Можно также затереть htaccess и положить в wa-sourses! Да куда угодно, если под апачем сайт.
Жди через год!
Через год? Да Вы, батенька, неисправимый оптимист... :)
На счет "Через год" я уже, кажется, демонстрировал:
https://support.webasyst.ru/6899/uvedomleniya-s-fo...
Улыбнуло!)
Дополнительные рекомендации по закрытию ошибок.
1. В файле published/sitemap.php
Заменить if($section){ if(!preg_match('/^[a-zA-Z_-]+$/',$app_id)){ На if($section){ if(!preg_match('/^[a-zA-Z_-]+$/',$section)){2. В корневом .htaccess добавить правила
RewriteEngine On RewriteCond %{REQUEST_URI} sitemap.php RewriteCond %{QUERY_STRING} \.\. RewriteRule .* - [F]Объясните пожалуйста не специалисту, что это даёт?
ИМХО, Дает, не на долго, ощущение защищенности, которое позволяет не тратить деньги на покупку лицензий и переход на актуальный Shop-Script 8.
Снова кого-то взломали, у меня новый клиент, но я не стал браться, времени нет.... Предложите бесплатный переход на новый SS старых уже не так много, а подписка позже окупит все. Среди шеллов всего около ста сайтов осталось.
У тех, кто остался на старом, как правило, уже столько всего дописано и переделано на сайте, что они при всем желании не могут перейти на SS 8 без серьезных расходов на то, чтобы теперь все это в новом дописать. Я с несколькими сталкивался.
Знаю, но иногда проще с нуля начать, большинство костылей в старой системе можно заменить плагинами.