Linux/Cdorked.A: хроники нового Apache-бэкдора

На прошлой неделе коллеги из Sucuri прислали нам модифицированную версию веб-сервера Apache, который перенаправлял некоторые, адресованные к нему запросы, на набор эксплойтов Blackhole Exploit Kit. Проведенный экспертами нашей антивирусной лаборатории анализ показал, что эта Linux-угроза, получившая название Linux/Cdorked.A, предназначена для перенаправления трафика на вредоносные сайты. Информация Sucuri об этом инциденте.

В процессе анализа мы пришли к выводу, что Linux/Cdorked.A представляет из себя наиболее сложный Linux-бэкдор из всех, что мы видели прежде. С помощью нашей облачной технологии ESET Live Grid мы получили статистику о сотнях скомпрометированных веб-серверов. В отличии от других подобных угроз, бэкдор не оставляет каких-либо следов своей деятельности на жестком диске скомпрометированного хоста, что заметно усложняет его обнаружение. Вместо этого, он хранит всю используемую им информацию в памяти, без привлечения жесткого диска. Кроме этого, злоумышленники используют обфусцированные HTTP-запросы для передачи служебной информации вредоносному коду, которые не фиксируются в лог-файле работы Apache. Таким образом следы взаимодействия вредоносного кода с C&C сервером также отсутствуют.

Бинарный файл Linux/Cdorked содержит все важные строки в зашифрованном виде, при этом используется известная схема XOR со статическим ключом. Версия Linux/Cdorked, которую мы анализировали содержит около 70 таких строк, при этом использовался ключ, указанный ниже на скриншоте (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F).

Рис. Код расшифровки строк.

Рис. Ключ для расшифровки.

Как упоминалось выше, бэкдор не использует файлы на диске для служебных целей. Вместо этого, он выделяет около 6 MB общей памяти (shared memory) для хранения своих данных и информации о конфигурации. Этот блок памяти, называемый POSIX Shared Memory, используется всеми дочерними процессами Apache, также к нему может получить доступ любой другой процесс в системе, поскольку авторы вредоносного кода не ограничивают его использование с использованием прав доступа. На скриншоте ниже показаны права доступа к этому региону общей памяти (чтение и запись для всех).

Рис. Получение доступа к блоку общей памяти.

Существует два способа, с помощью которых атакующий может контролировать поведение скомпрометированного сервера: через обратное подключение с использованием командной строки и с помощью специальных команд. Оба этих способа активируются через HTTP-запросы. Первый метод с использованием командной строки вызывается через GET запрос HTTP протокола. Он исполняется, когда происходит запрос специального пути, при этом строка имеет определенный формат и содержит имя хоста и порт для соединения. Клиентский IP-адрес используется как ключ для расшифровки передаваемой строки, т. е. 4-байтовый XOR-ключ. Дополнительно, IP-адрес, указанный в заголовках пакетов X-Настоящий_IP или X-Перенаправленный_на будет замещать клиентский IP как ключ для расшифровки. Это означает, что мы можем изготовить заголовок для X-Настоящий_IP, который будет выступать как ключ "\x00\x00\x00\x00". Строка запроса должна быть в hex-формате перед отправкой.

Рис. Пример исполнения команды.

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

Скомпрометированный веб-сервер осуществляет перенаправление клиента на вредоносные веб-страницы, для этого код бэкдора добавляет закодированную в формате base64 строку запроса, которая содержит информацию об оригинальном URL и был ли запрос адресован к js-файлу, для того, чтобы сервер смог предоставить правильную полезную нагрузку.

Пример такой строки:

hxxp://dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw==

В расшифрованном виде мы видим следующие параметры:

js=1&nvcbimuf=ccvckqju&time=1304161827-360453650&src=232&surl=www.infectedserver.com&sport=80&key=13D90950&suri=/forum/wcf/js/3rdParty/protoaculous.1.8.2.min.js

Параметр «surl» указывает на скомпрометированный (зараженный) хост, а «suri» указывает на оригинальный запрос.

После перенаправления, для браузера клиента устанавливаются cookie, так что в дальнейшем, исключено его повторное перенаправление. Также этот cookie устанавливается в том случае, если запрашивается веб-страница, похожая на страницу администрирования сервера. Вредоносный код проверяет такие аргументы как URL, имя сервера, поле referrer на совпадение следующих строк: "*adm*", "*webmaster*", "*submit*", "*stat*", "*mrtg*", "*webmin*", "*cpanel*", "*memb*", "*bucks*", "*bill*", "*host*", "*secur*", "*support*". Возможно такие проверки делаются для того, чтобы избежать отправки вредоносного содержимого администраторам веб-сайта, таким образом факт компрометации обнаружить будет сложнее. Скриншот ниже показывает часть кода, ответственную за обработку cookie.

Для успешного перенаправления вредоносный код так же проверяет некоторые другие аргументы запроса, например, проверяется наличие полей Accept-Language, Accept-Encoding, Referrer.

Нами были обнаружены 23 команды, которые Linux/Cdorked.A может отправить на сервер через POST-запрос HTTP с использованием специально сформированного URL. Запрос должен содержать поле cookie, которое начинается с маркера "SECID=". Строка запроса должна иметь два hex-байта, которые представляют собой значения, зашифрованные с помощью клиентского IP-адреса. Параметр SECID также используется как аргумент в некоторых других командах. Мы считаем, что URL-адреса, которые используются бекдором для перенаправления посетителей используют именно этот метод. Информация об этих адресах будет храниться в зашифрованном виде, с использованием общей памяти. Также очевидно, что условия для перенаправления устанавливаются следующим образом: белый список user agent-ов, для которых редиректы могут быть заранее настроены и черный список IP-адресов, для которых перенаправление не осуществляется.

Полный список команд, которые поддерживает бэкдор «DU», «ST», «T1», «L1», «D1», «L2», «D2», «L3», «D3», «L4», «D4», «L5», «D5», «L6», «D6», «L7», «D7», «L8», «D8», «L9», «D9», «LA», «DA».

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

Как упоминалось ранее, права доступа на блок общей памяти позволяют получить к нему доступ любому работающему в системе процессу. Мы разработали бесплатный инструмент (dump_cdorked_config.py), который поможет системным администраторам проверить наличие такого блока памяти и сохранить его в файл. Наши специалисты также рекомендуют использовать инструмент debsums для Debian и Ubuntu систем, а также команду “rpm –verify” для RPM-based Linux систем, которые позволят проверить целостность модулей вашего Apache сервера. Проверка на наличие блока общей памяти является рекомендованным способом убедиться в том, что вы не заражены. Наша антивирусная лаборатория заинтересована в получении таких дампов памяти для дальнейшего анализа.

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