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

Среда, 15 Янв 2014 18:48

вирусы лезут к вам на сайт

Начало «Вирус 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-объекты в папках с картинками, присваивая себе их имена и меняя только расширение? Флешки эти потом удаляются.

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

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

    Подпишитесь на комментарии, чтобы не пропустить
    важный ответ:



подписка на rss RSS - подписка
    подписка twitter Twitter - подписка

Вы можете оставить отзыв или трекбек со своего сайта.

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

  1. Вирус Troj/JSRedir-LR и его разновидности | SEO-semki пишет:

    16 Янв 2014 в 20:06

    […] Читать далее «Уязвимость крылась на хостинге» […]

  2. Как защитить сайт от взлома | SEO-semki пишет:

    16 Янв 2014 в 20:51

    […] Начало «Уязвимость крылась на хостинге» […]

  3. Настя пишет:

    22 Янв 2014 в 15:01

    А на форуме forum.searchengines.ru WapGraf сказал, что такого не может быть. Я имею в виду,что хостер может быть виноват. Может быть потому, что он сам хостер? (Evrohoster.ru)

    [Ответить]

    seo Reply:

    Ну конечно, конечно, о чём речь ;-)

    [Ответить]

    Scarabey Reply:

    Тогда надо бежать с такого хостера и как можно быстрее

    [Ответить]

  4. Под ударом магазины опенкарт (ocStore) | SEO-semki пишет:

    28 Янв 2014 в 17:19

    […] Об этом я подробно писал в статье «Уязвимость крылась на хостинге». […]

  5. bendar пишет:

    04 Фев 2014 в 16:13

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

    [Ответить]

  6. Одмин пишет:

    05 Фев 2014 в 17:31

    Я как админ который вычищал эту фигню «ad.nwindscore» могу точно утверждать, что проблема не в ssh. Например у меня на всех серверах 22 порт закрыт через iptables, доступ есть только с 4-х ip, авторизация только по ключу. Я склоняюсь к версии что это либо уязвимость апача либо панели управления сервером. В апаче я более-менее уверен, а вот в панели управления сервером сомневаюсь. Это была ispmanager, а как известно она бежит под рутом. Для меня всегда было загадкой зачем панели запускаются от рута, им же нужно только конфиги менять и демоны перезапускать, зачем им рут хз и с судо вполне могли бы себя нормально чувствовать. При этом судом хоть порезать можно было бы права на доступы к папкам и все такое.

    [Ответить]

    seo Reply:

    А как тогда объяснить тот факт, что вирус поражал не только хостинги с установленной панелью ispmanager, но и с другими, например, c-panel?
    Там выше пример логов был, а у вас ничего в логах подозрительного не было, например, упоминания такого файла: sysmetvpn.php?
    ПС. Я кстати читал ваш рассказ, особенно понравилось про forum.searchengines.ru и сопливого пользователя ;)

    [Ответить]

  7. Илья пишет:

    09 Фев 2014 в 19:19

    Читал что это бекдор изза регулярного выражения preg_*() с модификатором /e, который при обработке данных позволяет выполнять любой php код. Вот только не понял как это происходит на практике, где они тут увидели модификатор /e или я что-то не понимаю?

    [Ответить]

  8. Выбираем виртуальный хостинг | SEO-semki пишет:

    10 Фев 2014 в 10:59

    […] банально сломаться – полететь жесткий диск, его могут атаковать вирусы или черви (отнюдь не дождевые), он может банально не […]

  9. buber пишет:

    11 Фев 2014 в 18:26

    С хостерами всё понятно, а кто у какого регистратора домены регистрирует?

    [Ответить]

    seo Reply:

    У разных, я сейчас у реселлеров r01.ru регистрирую.

    [Ответить]

  10. Selin пишет:

    12 Фев 2014 в 13:34

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

    [Ответить]

    seo Reply:

    Ну мне кажется, что при удаленной работе само место проживания имеет второстепенное значение ;)

    [Ответить]

  11. Сергей пишет:

    12 Фев 2014 в 22:40

    Как человек связанный с хостингом могу сказать, что у нас проблема крылась в БИЛЛИНГЕ. Судя по затронутым в статье хостерам, биллинг у нас общий. Хацкер получает доступ к биллингу, биллинги хранят root пароли управляемых серверов

    [Ответить]

    seo Reply:

    Далее хацкер используя пароль рута проникает на сервер, а затем и на сайты пользователей, правильно?
    В таком случае в логах панелей должны были оставаться какие-либо записи?

    [Ответить]

  12. Ошибка POP3 is available only with SSL or TLS connection enabled | SEO-semki пишет:

    25 Сен 2014 в 20:45

    […] ничего страшного в этом нет, ваш сайт не взломали, партнерка не кинула, а хостер не канул в небытие. […]

Ваш отзыв

https://seo-semki.ru/icons/wpml_bye.gif 
https://seo-semki.ru/icons/wpml_good.gif 
https://seo-semki.ru/icons/wpml_negative.gif 
https://seo-semki.ru/icons/wpml_scratch.gif 
https://seo-semki.ru/icons/wpml_wacko.gif 
https://seo-semki.ru/icons/wpml_yahoo.gif 
https://seo-semki.ru/icons/wpml_cool.gif 
https://seo-semki.ru/icons/wpml_heart.gif 
https://seo-semki.ru/icons/wpml_rose.gif 
https://seo-semki.ru/icons/wpml_smile.gif 
https://seo-semki.ru/icons/wpml_whistle3.gif 
https://seo-semki.ru/icons/wpml_yes.gif 
https://seo-semki.ru/icons/wpml_cry.gif 
https://seo-semki.ru/icons/wpml_mail.gif 
https://seo-semki.ru/icons/wpml_sad.gif 
https://seo-semki.ru/icons/wpml_unsure.gif 
https://seo-semki.ru/icons/wpml_wink.gif