Уязвимость крылась на хостинге

Начало «Вирус Troj/JSRedir-LR  и его разновидности»

Между тем Яндекс продолжает банить сайты за мобильный редирект, вирус прописывается в самых разных местах, поражая все известные и даже самописные ЦМС.

Поражаются как высокопосещаемые проекты, так и сайты с несколькими униками в сутки. При этом не помогают такие усиленные меры безопасности как установка входа в панель управления хостинга по IP, вход в админпанель сайта по IP-адресу,  использование файла  дополнительной конфигурации веб-сервера Apache (и подобных ему серверов) .htaccess, установка различных плагинов безопасности, таких как  Better WP Security. Не помогали также смена путей к административным папкам, смена их названий, запрет папок на запись, запрет на загрузку аватаров, файлов  php, js, а также запрет на их выполнение.

Сайты продолжали заражаться и показывать следующие симптомы: в начало каждого (или 1-2) .js-файлов  дописывался вредоносный код, содержащий iframe. При этом вредоносный код первоначально добавлялся только к  .js-файлам и таким образом исполнялся у всех посетителей данной страницы (возможно, уже тут шла проверка по юзер-агенту).

Вот некоторые способы борьбы со зловредами, которые были предложены в тот период времени:

«Уже день вирус обходит сайт стороной. Добавил в папку скриптов такой .htaccess:

order deny,allow

deny from all

order allow,deny

allow from all

order deny,allow

allow from all

»

Также было предложено такое решение — ставить на мониторинг в host-tracker-е конкретные файлы, которые видоизменяются вирусом.

Например, указать путь к сайту с конкретным местоположением сайта вида seo-semki.ru/script/file.js и ключевое слово  iframe.

При изменении заданного файла приходит смс на телефон и письмо на электронную почту. Минус данного способа очевиден  — если вирус каждый раз будет создавать новые файлы, не затрагивая указанный файл, то вы ничего так и не узнаете.

Использование SSH

 

Если есть доступ по SSH, то можно выполнить поиск файлов за последние три дня (в случае с cPanel):

find ./public_html/* -mtime -3 -print

Поиск по включению (выполнять в папке с файлами сайта):

find . -print0 -name «*.js» | xargs -0 grep -l «+ expiresDate; }, 5000);}};»

или просто

find . -print0 -name \*.js | xargs -0 grep -i iframe

Также можно попытаться  найти все зараженные файлы командой

find . -name «*.js»|while read i;do cat «$i»|grep -H —label=»$i» -n «= document.createElement(‘iframe’);i»;done

Сравнение файлов. Сохраняем утром  контрольную сумму файлов с расширением .txt в текстовый файл

find . -type f -name «*.js» -exec md5sum {} \; > sum-js1.txt

вечером создаём второй текстовый файл

find . -type f -name «*.js» -exec md5sum {} \; > sum-js2.txt

и делаем сравнение двух контрольных сумм:

diff -u sum-js1.txt sum-js2.txt.

Но потом хакер сменил тактику и стал действовать следующим образом:

В произвольную  папку, имеющую права на запись, заливается некий файл .php (как пример тот же  sysmetvpn.php, о котором будет подробно написано ниже), который  имеет произвольное имя. Затем  данный  php-файл  используется для загрузки js-файла, который записывается в случайную папку либо сразу дописывает к уже имеющимся js-скриптам сайта постороннюю вставку вида:

Впоследствии вирус, возможно, периодически проверял наличие данных файлов, а также их содержимого, как  php, так и джаваскриптов. В случае изменения вышеуказанных файлов или прав на них, троянская программа заново создавал эти же файлы, но уже с другими именами и в других местах, также меняя переменные в них.

[original:seo-semki.ru]

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

Да, и потом кроме файлов .php  и .js создавался/заливался файл с расширением swf, содержащий в себе код вирусной программы.

Теперь что касается советов поменять права на папки, т. е. установить такие права, которые не позволят злоумышленникам прописать/исполнить вредоносный код (обычно на исполнение и запись) и одновременно не создадут никаких проблем в работе сайта.

Обычно советуют устанавливать права 444 и сначала это действительно помогало. Но уже в скором времени ситуация изменилась: «меняю права на файлы на 444, на папки на 555, но они продолжают сбрасываться на 755». «После удаления файлы появляются снова, смена прав с  644 на 444, и папок с 755 на 555 уже не помогает, вирус научился изменять и их».

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

Кроме того, в директориях хакнутых  сайтов стали появляться подозрительные файлы со следующим содержимым:

Еще пример кода:

И ещё:

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

Можно также дополнить, что факты взлома не зависели и  от панели управления хостингом, хотя вроде бы первоначально и появилась информация о том, что вредоносный код заливают, используя cpanel и папку  tmp.

Пример такого лога из  cpanel-и:

Но позже эта инфа не подтвердилась, поскольку с одинаковым успехом были сломаны и cpanel, и ispmanager и directadmin.

Теперь что касается движка сайта, то есть та система управления контентом (ЦМС), на которой работали все взломанные сайты. Это был не Вордпресс и не Дле, волна взломов которого прокатилось также не так давно. Тогда также было вскрыто большое количество веб-ресурсов, но тогда злоумышленник просто видоизменял файл  хтачес, дописывая туда мобильный редирект. Сливая таким образом трафик на вап-партнерки, хакер рассчитывал неплохо поживиться. Подробно об этом я писал в статье про взлом dle-сайтов.

Но в этом случае дела обстояли совершенно по-другому.

В равной степени были поражены сайты  не только на  CMS WordPress (Вордпресс) и DLE, но также все другие популярные цмски, в том числе и платные — CMS Joomla 1.5 (Джумла), движок интернет-магазина Опенкарт (opencart/octore), Drupal 6 , vBulletin (Буллетин), включая  последние версии VBulletin 4.2.X.

Были также затронуты и самописные движки чуть ли не с одними статическими файлами, цитата «у меня очень простой сайт, писал его сам и все файлы знаю наизусть. И все равно вирус проникал на сайт. Яндекс наложил метку и опустил в поиске. Проблема решилась сменой хостинга».

И как вы думаете, если взлом произошел при наличии всех  вышеперечисленных условий, однако даже такие меры предосторожности не смогли предотвратить его, то что же тогда остается?

Вот подсказки с тематических  форумов:

«Не могу найти вирус, предполагаю, что он использует дыру в сервере», «думаю на соседей или софт, по-другому зараза инклюдиться никак не может…», «Проблема у хостера или в его настройках, возможно кривой софт позволяет совершать такие действия», «перерыли все файлы, включая движок и плагины — ничего нет,  шелл никак себя не выдает, думаем на хостера либо его ПО».

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

Как доказательство, слова одного из участников форума сёрчинжинс, поставившего файлы на мониторинг. «Сегодня стали приходить смски одна за одной, о том, что сайт то падает, то подымается, из чего можно сделать вывод,  как только вирус попадает на сайт, хостер начинает его лечить».

А что говорят в самих хостингах по данному вопросу? Естественно, всё отрицают — ломают всех и всегда, дело в кривых настройках/файлах/руках, настройках хостинга и далее в том же духе. И что биллинг постоянно обновляется, и что у них нет доступа к клиентским данным, и что авторизация на сервере происходит от пользователя с ограниченными правами. Но как говорится, факты – вещь упрямая.  Поскольку, как уже было замечено выше, проблема решалась лишь сменой хостинга (естественно, в том случае, если переезд осуществлялся не к такому же аналогичному хостеру из списка ниже).

И только один хостер из всего списка, hostland.ru, признал свою вину, за что ему конечно отдельное спасибо. Вот только сообщение это, судя по всему, так и осталось незамеченным широкой публике.

«Совершенно верно, проблема была на нашей стороне. Был скомпрометирован один из веб-серверов, уязвленный модуль уже изолировали. Почему это произошло, непонятно. В течение дня будет выполнено обновление всего серверного ПО, а конфигурационные файлы перезалиты из репозитория».

А вот анонимное признание еще одного  представителя хостинга, оставшегося неназванным:

«Это проблема хостера и только его. Решается она за пару минут, сами вы ничего сделать не сможете. Все данные уходят из панели биллинга,  панель управления хостингом тут не причем.

Проблема могла решиться  критическим обновлением по безопасности, если оно затрагивало данную уязвимость. Помогала смена паролей, внимание, администратора сервера, Эта ситуация также исключала брутфорс (подбор паролей), поскольку у администраторов серверов были логин — пароли состоящие из  нескольких десятков знаков цифр-букв в верхнем и нижнем регистре».

[original:seо-sеmki.ru]

Также интересен следующий нюанс: кто-то отметил, что заражение происходит с правами администратора сервера, при этом все сайты, хотя и имели различные ip-адреса и располагались у разных хостинг-провайдеров, находились в одном дата-центре  в Германии, а именно у  Hetzner Online AG,  линк —  ru.hetzner.com.

А вот и обещанный выше  список:

Были скомпрометированы следующие хостинги (я рассортировал их по странам, чтобы вы видели реальную картину). Итак, это белорусские хостинг-провайдеры:

active.by

besthost.by

Несколько российских провайдеров:

vps-server.ru

hostland.ru

jino.ru (упоминается несколько раз)

Но львиная доля всех подобных случаев приходит на украинские хостинги:

ukraine.com.ua

hosting-service.org.ua

ohoster.ru (упоминается несколько раз, также украинский хостинг, хотя находится в доменной зоне .ру)

hostpro.ua  (по сообщениям техподдержки Яндекса, большое количество взломанных сайтов располагалось на серверах именно этого хостинг-провайдера)

hostlife.net (без сомнения лидер по количеству взломанных сайтов).

Типичное сообщение того времени:

«Могу только сказать, что сайты с IP 195.16.88.137 точно заражены.

IP:   195.16.88.137

Хост:   sr26.hostlife.net

Город:   Донецк»

Как видите, сервер sr26 принадлежит именно компании Хостлайф.

Так какую же все-таки уязвимость использовал вирус?

Я склоняюсь к мысли, что вот такую, описанную на securitylab.ru/analytics/437269.php, ну или похожую. Там описывается версия SSH-демона для Linux. Почему именно Линукс, а не Виндоус? Да потому что именно эта ОС обычно установлена на серверах хостинг-провайдеров и плюс веб-сервера Apache (Апач). Данный демон подменял содержимое веб-страниц, показываемых скомпрометированным веб-сервером. Зловред был нацелен на хищение приватных данных при использовании кредитных карт в банковских операциях. Там также применялся скрытый iframe для установки банковского трояна Win32/Zbot, более известного как Zeus.

Вредоносный модуль для веб-сервера Apache, названный Linux/Chapro.A, содержит в себе бекдор, позволяющий без труда попадать на скомпрометированный сервер.  Но самое главное, что этот модуль содержит специальную защиту, затрудняющую его обнаружение.

Например, он проверял user agent браузера  и если определял их как web-краулеры (пауки) или неуязвимые для его набора эксплойтов, то скрывал от них вредоносное содержимое (айфрейм). А также оставлял на зараженной машине свои cookie (куки) и хранил список всех таких IP-адресов, поэтому повторно одному и тому же пользователю вредоносный код никогда не показывался два раза. И, наконец,  Linux/Chapro.A  проверял все активные SSH-сессии на Linux-системе, определяя их ай-пи-адреса. И всем тем, кто имел IP-адрес  из этих SSH-подключений, вредоносный код не показывался. Таким образом, модуль скрывал код от всех тех, кто мог работать на пораженном веб-сервере (разработчики, сисадмины и так далее).

Так не поэтому ли администраторы серверов всё время твердили одно и тоже, что проблема в кривых скриптах, старых версиях плугинов и ЦМС, но никак не в настройках их веб-серверов (естественно, Апач)?

IP-адреса, с которых действовал взломщик (взломщики)

 

Теперь насчёт ip-адресов, с которых действовали злоумышленники.

По многочисленным сообщениям с форумов можно судить о большом количестве адресов, с которых шло заражение сайтов. Были указаны такие страны как Австрия, США, Россия, Китай, Франция, Польша, Италия и другие. Это говорит о том, что либо взломщики активно использовали прокси, либо о том, что их было несколько человек, либо о том, что данную уязвимость эксплуатировали разные люди.

Вот для примера несколько таких реальных ай-пи-адресов, с которых происходил взлом и заражение сайтов:

IP 37.187.56.98 — сеть французского дата-центра  Ovh Sas

37.186.0.0/16 — подсеть Ascus Telecom Gmbh, Вена, Австрия

178.33.69.67 — (упоминается  много раз),  Польша

212.124.113.110 —  Швейцария

110.85.101.152 – Китай (China, Fujian, Fuzhou)

188.123.253.138  —  Россия (Russia,  Moscow City,  Moscow Akado — Stolitsa Jsc). Тут надо отметить, что большое количество IP было именно из Москвы.

А вот ещё один любопытный IP, с которого якобы произошёл взлом, по крайней мере, так утверждает некто  konservator с сёрча:

37.140.141.2, но как говорится, доверяй, но проверяй, я проверил, кому принадлежит этот ip: spider-37-140-141-2.yandex.com, то есть поисковый бот Яндекса. Как видим, явная ложь, поскольку данный бот никак не мог участвовать  во взломе.

А вот ещё один ай-пи:

65.19.138.34 – США (USA,  California,  Fremont) и кусочек лога:

65.19.138.34 — — [03/Sep/2013:15:31:41 +0300] «GET /index.php?format=feed&type=rss HTTP/1.1» 200 4742 «-» «Feedly/1.0 (+http://www.feedly.com/fetcher.html; like FeedFetcher-Google)»

Видим указание на сервис Google-а, но на форумах утверждают, что это фэйк гугл-бота.

И наконец, такой IP-адрес:

89.248.238.142 — Россия 23 Customer Network For Co,  большое количество взломов, пик пришёл на конец августа —  начало сентября при помощи файла sysmetvpn.php.  Что же это за файл, который я уже упоминал в начале статьи и обещал рассказать позже?

Файл sysmetvpn.php

 

Еще один загадочный файл, при помощи которого происходил взлом и который засветился во многих логах.  Вот типичные упоминания об этом файле:

«Если раньше sysmetvpn.php просто удаляли, то теперь просто меняют права на него, а далее уже .js-скрипты как и ранее…»

«Сисадмины сказали, что заражение идет через файлы sysmetvpn.php, которые временно создаются в папках сайта, а после удаляются. Поставил права 444, но и это не помогло. Файл создаётся и меняется под учетной записью администратора».

«Поменял права на папки, вирус снова вписался. В логах светится IP 89.248.238.136, идет обращение к /sysmetvpn.php, а после запрос GET /templates/themes/jquery.js. Яндекс помог найти код, хостер не чешется».

Пример логов:

89.248.238.101 — — [04/Sep/2013:15:17:30 +0200] «GET /sysmetvpn.php HTTP/1.1» 500 261 «» «Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/21.0.1»

89.248.238.101 — — [04/Sep/2013:15:17:31 +0200] «POST /sysmetvpn.php HTTP/1.1» 200 331 «» «Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/21.0.1″

89.248.238.142 — — [04/Sep/2013:15:17:36 +0200] \»GET /js/jq.js HTTP/1.1\» 200 2970 \»\» \»Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/21.0.1\»

Как видим, сначала запрос к  /sysmetvpn.php даёт 500-ую ошибку, потом статус 200, то есть всё ОК, и сразу следует GET-запрос к  джаваскрипту, находящемуся в директории /js/jq.js.

Вот еще один любопытный  кусочек логов:

212.124.113.110 — — [14/Dec/2013:00:03:10 +0300] «GET /uploads/posts/2010-01/krisha.swf  HTTP/1.0» 200 301 «-» «Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3»

212.124.113.110 — — [14/Dec/2013:02:19:43 +0300] «GET /uploads/posts/2012-01/bigcat.swf  HTTP/1.0» 200 301 «-» «Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3»

212.124.113.110 — — [14/Dec/2013:04:45:12 +0300] «GET /uploads/posts/2012-06/qqqqq.swf  HTTP/1.0» 200 301 «-» «Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3»

212.124.113.110 — — [14/Dec/2013:04:16:00 +0300] «GET /forum/css.php?userid=88403&cssuid=0&d=1386720000&td=ltr&styleid=0&sheet=userprofile.css HTTP/1.0» 200 2175 «-» «Zend_Http_Client»

212.124.113.110 — — [14/Dec/2013:04:16:39 +0300] «GET /forum/showthread.php?t=1251&page=19& HTTP/1.0» 200 27744 «-» «Zend_Http_Client»

Посмотрите на названия файлов, это флешки krisha.swf,  bigcat.swf,  qqqqq.swf , загруженные в папку аплоадс. Помните, я уже писал про то, как вирус создаёт swf-объекты в папках с картинками, присваивая себе их имена и меняя только расширение? Флешки эти потом удаляются.

Затем следуют запросы к сайту через Зенд-клиент.

Читать далее «Как защитить сайт от взлома»