Linux/Cdorked.A — серьезная угроза для серверов

Пока обыватели клеймят позором винду, Adobe и Oracle, специалисты отмечают увеличение вредоносных программ, предназначенных для компьютеров под управлением Linux. В первую очередь злоумышленников интересуют веб-серверы. Как и почему они создают серверную малварь, ты узнаешь из этой статьи.

Зачем заражают веб-серверы?

Прежде чем углубиться в технические дебри, нужно разобраться, а зачем вообще злоумышленникам заражать веб-сервер. В большинстве своем веб-серверы заражают, чтобы перенаправлять посетителей сайта на связку с эксплойтами. В самых простых случаях изменяют веб-контент на скомпрометированном сервере, к примеру в одну из страниц сайта добавляют вредоносный код. Данный подход имеет ряд недостатков для злоумышленников. Во-первых, модификацию веб-контента на сервере легко обнаружить, к тому же для этих целей существуют специальные инструменты. Во-вторых, сервер начинает раздавать измененный контент всем посетителям сайта без какой-либо фильтрации, в том числе различным конторам, которые могут отметить сайт как вредоносный. Злоумышленники хотят оставаться незамеченными как можно дольше, именно поэтому начала появляться новая хитроумная малварь под ОС Linux.

Linux/Cdorked.A

Впервые это вредоносное ПО обнаружили и исследовали специалисты ESET совместно с компанией Sucuri в апреле 2013 года. Первоначально были обнаружены вредоносные веб-серверы на базе Apache, позднее выявлены случаи компрометации серверов на базе lighttpd и nginx. Основное предназначение Linux/Cdorked.A — перенаправлять трафик на вредоносные сайты. Так, один из обнаруженных серверов перенаправлял пользователей на широко известный набор эксплойтов Blackhole.

Linux/Cdorked.A представляет собой бинарный ELF-файл веб-сервера, однако помимо обычной функциональности в него добавлена функциональность бэкдора. Злоумышленники подменяют легальный бинарный файл на файл с бэкдором. В большинстве случаев для того, чтобы перезаписать бинарный файл веб-сервера, необходимы root-права, но способ проникновения на сервер и метод получения root-доступа злоумышленниками нам пока точно неизвестен. Возможно, для каждого сервера использовалась своя тактика, была ли это брешь в cPanel или же обычная компрометация логина и пароля — сказать трудно. Достоверно известно, что Linux/Cdorked.A не имеет механизмов самораспространения, а также не использует уязвимости в серверном ПО.

Анализ

Мы будем исследовать 64-битный бинарный ELF-файл от веб-сервера Apache. В файле присутствуют отладочные символы, что несколько облегчает задачу исследования. Правда, ненамного, так как функции, которые непосредственно принадлежат бэкдору, носят несодержательные имена вроде ob87E874aD44B47B8544955.

Первое, что придется побороть, — это шифрованные строки. Видимо, авторы решили скрыть подозрительные строки от любопытных глаз. К счастью, шифр не такой сложный, всего лишь XOR-операция с ключом-константой. С ним легко справится такой мощный инструмент, как IDAPython. Вот такой скрипт мы сделали для его расшифровки:

Рекомендуем почитать:

Xakep #299. Sysmon

• Содержание выпуска
• Подписка на «Хакер»-60%

# -*- coding: cp1251 -*- from idaapi import * from idautils import *  def decrypt_str(offset, size): # данный ключ "вшит" в программу key = (0x27, 0xA4, 0xE2, 0xDA, 0xDA, 0xF1, 0x83, 0xB5, 0x1E, 0x3D, 0xA7, 0xF6, 0xC9, 0xE6, 0x23, 0x9C, 0xDF, 0xC8, 0xA2, 0xE5, 0xA, 0x60, 0xE0, 0x5F)  string = bytearray(size) for i in range(size): b0 = Byte(offset + i) ^ key[i % len(key)] string[i] = b0 & 0xFF return str(string)  def main(): # По адресам 0x043B8FE - 0x43BCE0 идет # перечисление указателей на зашифрованные строки code_offset = 0x043B8FE  # По данному адресу хранятся длины строк xlen = 0x76B480 strings = []  #запускаем цикл, работающий до первой строки с нулевой длиной while(Byte(xlen)): # ищем инструкцию вида "lea rax, offset string" while (GetMnem(code_offset) != 'lea' or  GetOpType(code_offset, 0) != idaapi.o_reg or  GetOpType(code_offset, 1) != idaapi.o_mem): code_offset = NextHead(code_offset)  # найденный адрес и длину строки # передаем для расшифровки str = decrypt_str(GetOperandValue(code_offset, 1), Byte(xlen)) strings.append(str) code_offset = NextHead(code_offset) xlen += 1  # теперь у нас есть все строки # нам нужно найти места, где они используются func = LocByName('decrypt_strings')  # перебираем все вызовы for addr in CodeRefsTo(func, True): # ищем инструкцию вида "mov edi, ID" # где ID будет номером нашей строки while (GetMnem(addr) != 'mov' or  GetOpType(addr, 0) != idaapi.o_reg or  GetOperandValue(addr, 0) != 7): addr = PrevHead(addr)  # в комментарий пишем расшифрованную строку MakeComm(addr, strings[GetOperandValue(addr, 1)])  if __name__ == '__main__': main()

Устройство и управление

По результатам вскрытия мы установили, что бэкдором можно управлять двумя методами. Первый метод — это reverse shell, который активируется, если злоумышленник пошлет GET-запрос по HTTP-протоколу со специальным путем. В нашем случае этот путь должен быть /favicon.iso (именно iso, а не ico!). В качестве параметров должна быть зашифрованная строка «GET_BACK;HOST;PORT», где HOST и PORT — IP-адрес и порт, которые будут использованы для подключения reverse shell. Бэкдор использует IP-адрес из заголовков X-Forwarded-For или "X-Real-IP для вычисления XOR-ключа, который будет использован для расшифровки строки параметров. Строка с параметрами должна быть переведена в hex-формат.

Все время, пока шелл используется злоумышленником, HTTP-соединение будет активно. Однако бэкдор не записывает запросы к /favicon.iso в лог-файл работы веб-сервера. После того как злоумышленник закончит работу, произойдет редирект на http://google.com/.

Второй метод позволяет управлять конфигурацией бэкдора. Для этого злоумышленнику необходимо отправить POST-запрос по HTTP-протоколу к специальному URL. Передаваемый в запросе параметр содержит команду для выполнения бэкдором, зашифрованную таким же методом, как и в случае с reverse shell. При этом запрос должен содержать Cookie со значением «SECID=». Для ответа бэкдор использует параметр Etag в HTTP-заголовке.

Бэкдор поддерживает следующие команды:

• L1, D1 — добавить/удалить список URL, используемых для перенаправления;
• L2, D2 — добавить/удалить диапазоны IP-адресов для черного списка;
• L3, D3 — добавить/удалить User-Agent для белого списка;
• L4, D4 — добавить/удалить User-Agent для черного списка;
• L6, D6 — добавить/удалить IP-адреса для черного списка;
• L7, D7 — добавить страницы в список исключенных или удалить из него;
• L8, D8 — добавить/удалить диапазоны IP-адресов для белого списка;
• L9, D9 — добавить/удалить шаблоны Accept-Language для черного списка;
• LA, DA — добавить страницы в белый список или удалить из него;
• ST — передать статистику работы сервера;
• DU — очистить список IP-адресов перенаправленных клиентов;
• T1 — передать штамп времени.

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

Интересно, что в процессе работы малварь не создает никаких дополнительных файлов, которые бы могли свидетельствовать о наличии подозрительной активности. Всю конфигурацию бэкдор хранит в специальном участке shared memory размером в 6 Мб. Доступ к этому участку имеют все дочерние процессы веб-сервера, а также другие процессы в системе. Наши специалисты разработали инструмент, позволяющий сдампить конфигурацию Linux/Cdorked.A всех вариантов, включая версии для nginx и lighttpd: goo.gl/5iL5E.

С помощью администраторов одного из зараженных серверов, а также с помощью компании Sucuri нам удалось получить дамп региона shared memory, в котором хранится конфигурация бэкдора. Как видно из конфига, пользователь перенаправляется, только если он использует Internet Explorer или Firefox, а также, как ни странно, iPhone или iPad.

Для того чтобы бэкдор перенаправил посетителя веб-сайта, в HTTP-запросе должны присутствовать следующие поля: Accept-Language, Accept-Encoding, Referrer, User-agent. Для того чтобы не перенаправлять пользователя по нескольку раз, бэкдор устанавливает Cookie вида: GIDID=6745609876567 ; path=/; expires=Friday, 31-Dec–2030 23:59:59 GMT. Чтобы скрыть свою активность от администраторов веб-сайта, бэкдор также устанавливает Cookie в случае, если параметр Referrer содержит одну из следующих комбинаций: adm, webmaster, submit, stat, mrtg, webmin, cpanel, memb, bucks, bill, host, secur, support.

Заключение

Мы проанализировали один из сложных и интересных бэкдоров. И тем самым еще раз убедились, что наличие малвари под ОС Linux не миф, а жестокая реальность.