Введение
Руткиты - это вредоносные программы, которые проникают в самые глубокие уголки операционной системы. Хотя на бумаге они могут показаться привлекательными для злоумышленников, их создание сопряжено со значительными техническими трудностями, а малейшая ошибка в программировании способна полностью вывести из строя компьютер жертвы. Одним из основных преимуществ вредоносных программ, вложенных в такие низкие уровни операционной системы, является то, что их крайне сложно обнаружить, а в случае с руткитами для прошивки они гарантируют, что компьютер останется в зараженном состоянии, даже если операционная система будет переустановлена или пользователь полностью заменит жесткий диск.
В этом отчете мы представляем руткит для прошивки UEFI, который мы назвали CosmicStrand.
Пострадавшие устройства
Хотя нам не удалось выяснить, как изначально были заражены компьютеры жертв, анализ их аппаратного обеспечения проливает свет на устройства, которые может заразить CosmicStrand. Руткит находится в образах прошивок материнских плат Gigabyte или ASUS, и мы заметили, что все эти образы относятся к конструкциям, использующим чипсет H81. Это говорит о том, что может существовать общая уязвимость, которая позволила злоумышленникам внедрить свой руткит в образ прошивки.
В этих образах микропрограмм были внесены изменения в драйвер CSMCORE DXE, точка входа которого была исправлена для перенаправления на код, добавленный в раздел .reloc. Этот код, выполняемый во время запуска системы, запускает длинную цепочку выполнения, которая приводит к загрузке и установке вредоносного компонента внутри Windows.
Глядя на различные образы прошивок, которые нам удалось получить, мы предполагаем, что модификации могли быть выполнены с помощью автоматического патчера. Если это так, то, следовательно, злоумышленники имели предварительный доступ к компьютеру жертвы, чтобы извлечь, изменить и перезаписать прошивку материнской платы. Это могло быть достигнуто с помощью уже установленного на компьютере вредоносного имплантата-предшественника или физического доступа (т.е. по сценарию атаки "злой служанки"). Первоначальный отчет Qihoo указывает на то, что покупатель мог получить материнскую плату с обратной прошивкой после размещения заказа у продавца подержанных товаров. Мы не смогли подтвердить эту информацию.
Обзор процесса заражения
Прежде чем перейти к рассмотрению различных компонентов, составляющих этот руткит, мы хотели бы дать общее представление о том, чего он пытается достичь. Целью этой цепочки выполнения является внедрение имплантата на уровне ядра в систему Windows при каждой загрузке, начиная с зараженного компонента UEFI.
Авторы вредоносных программ UEFI сталкиваются с уникальной технической проблемой: их имплантат начинает работать на столь ранних этапах процесса загрузки, что операционная система (в данном случае Windows) еще даже не загружена в память, а к тому времени, когда она загрузится, контекст выполнения UEFI уже завершится. Найти способ передать вредоносный код на всех этапах запуска - вот основная задача, которую решает руткит.
Рабочий процесс заключается в последовательной установке хуков* , позволяющих вредоносному коду сохраняться до окончания запуска ОС. При этом выполняются следующие шаги:
- Первоначально зараженная прошивка загружает всю цепочку.
- Вредоносная программа устанавливает вредоносный хук в менеджере загрузки, что позволяет ей модифицировать загрузчик ядра Windows до его выполнения.
- Подделывая загрузчик ОС, злоумышленники могут установить еще один крючок в одной из функций ядра Windows.
- Когда эта функция впоследствии вызывается во время обычной процедуры запуска ОС, вредоносная программа в последний раз берет под контроль поток выполнения.
- Она размещает шеллкод в памяти и связывается с сервером C2 для получения фактической вредоносной полезной нагрузки для запуска на машине жертвы.
Эти шаги представлены на следующем графике:
Имплантат UEFI - подробный анализ
MD5 DDFE44F87FAC7DAEEB1B681DEA3300E9
SHA1 9A7291FC90F56D8C46CC78397A6F36BB23C60F66
SHA256 951F74882C1873BFE56E0BFF225E3CD5D8964AF4F7334182BC1BF0EC9E987A0A
Время ссылки Среда, 12.08.2015 12:17:57 UTC
Тип файла EFI Boot Service DXE Driver
Размер файла 96.84 КБ
GUID A062CF1F-8473-4AA3-8793-600BC4FFE9A8 (CSMCORE)
Определив, чего пытается добиться вредоносный имплант, мы можем теперь более подробно рассмотреть, как выполняется каждый из этих шагов.
1) Вся цепочка выполнения начинается с драйвера EFI. По всей видимости, это исправленная версия легитимного драйвера под названием CSMCORE (предназначенного для загрузки машины в устаревшем режиме через MBR), в котором злоумышленники изменили указатель на функцию службы загрузки HandleProtocol. Каждый раз, когда вызывается эта функция, выполнение перенаправляется на предоставленный злоумышленниками код, который пытается определить, какой компонент ее вызвал (он ищет конкретный компонент для заражения - efi). Изучая аргументы функции, а также байты, расположенные по адресу возврата, CosmicStrand может определить, какой именно "вызов" он ищет.
2) Этот конкретный момент выполнения был выбран потому, что на этом этапе менеджер загрузки загружен в память, но еще не запущен. CosmicStrand использует этот шанс для исправления ряда байт в Archpx64TransferTo64BitApplicationAsm.
3) Позже эта функция вызывается во время обычного процесса запуска ОС, также в стратегически важный момент: к этому времени загрузчик ОС Windows также присутствует в памяти и может быть модифицирован.
4) При запуске Archpx64TransferTo64BitApplicationAsm находит функцию из загрузчика ОС (OslArchTransferToKernel) путем поиска определенного шаблона байтов. Затем CosmicStrand добавляет крючок в самом конце.
5) OslArchTransferToKernel вызывается непосредственно перед передачей исполнения от загрузчика Windows к ядру Windows, что делает его традиционной точкой захвата для руткитов такого рода.
6) Прежде чем ядро Windows успевает запуститься, CosmicStrand устанавливает еще один крючок в ZwCreateSection Вредоносный код копируется[2] в образ ntoskrnl.exe в памяти, и первые байты ZwCreateSection перезаписываются для перенаправления на него. Отметим, что злоумышленники постарались разместить вредоносный код в свободном пространстве секции .text файла ntoskrnl.exe, что делает это перенаправление гораздо менее заметным в глазах возможных продуктов безопасности.
На этом этапе CosmicStrand также пытается отключить PatchGuard, механизм безопасности, введенный для предотвращения модификации ключевых структур ядра Windows в памяти. Для этого он находит функцию KiFilterFiberContext от ntoskrnl.exe[3] и модифицирует ее таким образом, что она возвращается, не выполнив никакой работы. Стоит отметить, что локализация этой функции, также достигнутая путем поиска жестко закодированных шаблонов, является очень исчерпывающей и даже содержит шаблоны, соответствующие релизу Redstone 1 от августа 2016 года.
7) Затем запускается ядро Windows, которое при нормальном выполнении вызывает функцию ZwCreateSection. Когда это происходит, CosmicStrand снова получает контроль над выполнением и восстанавливает исходный код перед запуском более вредоносного кода.
8) Основная задача хука ZwCreateSection - собрать адреса API-функций, предоставляемых ядром, и создать своего рода таблицу импорта для следующего компонента. Используя разрешенные функции, он также выделяет буфер в адресном пространстве ядра, куда помещает шеллкод, прежде чем вызвать его.
Ядро шеллкода
Все описанные до сих пор шаги служили лишь цели распространения выполнения кода от UEFI вниз к ядру Windows. Этот шеллкод является первым действительно вредоносным компонентом в цепочке. Он устанавливает процедуру уведомления о потоке, которая вызывается каждый раз, когда создается новый поток. CosmicStrand ждет, пока один из них не появится в winlogon.exe, а затем выполняет обратный вызов в этом высокопривилегированном контексте.
Там CosmicStrand спит в течение 10 минут и проверяет интернет-соединение зараженной машины. CosmicStrand не полагается на высокоуровневые функции API для генерации сетевого трафика, а взаимодействует непосредственно с интерфейсом транспортного устройства: он генерирует необходимые IRP (пакеты запросов ввода-вывода) и передает их сетевому стеку, отправляя IOCTLs объекту устройства TCP или UDP. DNS-запросы выполняются таким же образом, используя либо DNS-сервер Google (8.8.8[.]8), либо собственный (222.222.67[.]208).
CosmicStrand получает конечную полезную нагрузку, отправляя специально созданный UDP (предпочтительно) или TCP-пакет на свой C2-сервер update.bokts[.]com. Ожидается, что ответ придет в виде одного или нескольких пакетов, содержащих фрагменты по 528 байт и имеющих следующую структуру:
Различные чанки собираются в серию байтов, которые отображаются в пространство ядра и интерпретируются как шеллкод. К сожалению, нам не удалось получить копию данных, поступающих с сервера C2 (сервер управления). Однако мы нашли образец пользовательского режима в памяти на одной из зараженных машин, который мы смогли изучить, и считаем, что он связан с CosmicStrand. Этот образец представляет собой исполняемый файл, который запускает командные строки для создания пользователя ("aaaabbbb") на машине жертвы и добавления его в группу локальных администраторов.
Из этого можно сделать вывод, что shell-коды, полученные с сервера C2, могут быть проводниками для поставляемых злоумышленником исполняемых файлов, и вполне вероятно, что их существует гораздо больше.
Старые варианты CosmicStrand
В ходе нашего расследования мы также обнаружили более старые версии этого руткита. Они имеют одинаковый процесс развертывания, а их незначительные отличия касаются шеллкода ядра.
- Он пытается перехватить все exe вместо конкретного winlogon.exe.
- C2, с которым связываются для получения дополнительного шеллкода для запуска, отличается.
- Старый вариант выдавал отладочные сообщения каждый раз, когда в системе создавался новый процесс.
На основе анализа инфраструктуры, используемой для двух вариантов, мы предполагаем, что более старый вариант использовался в период с конца 2016 года до середины 2017 года, а текущий вариант был активен в 2020 году.
Инфраструктура
Нам известно о двух C2-серверах, по одному для каждого варианта. Согласно пассивным данным DNS, доступным для них, эти домены имели длительный срок службы и разрешались в IP-адреса в ограниченные периоды времени, за пределами которых руткит был бы неработоспособен. Поэтому интересно отметить, что, хотя злоумышленники решили установить чрезвычайно стойкий имплант, фактическая эксплуатация машин-жертв могла продолжаться не более нескольких месяцев. Однако возможно, что эти домены периодически активировались на очень короткое время, и эта информация не была бы зарегистрирована пассивными системами DNS.
Внимательные читатели заметят трехлетний разрыв между периодами активности этих двух доменов. Возможно, в течение этого времени злоумышленники контролировали машины жертв с помощью компонентов пользовательского режима, развернутых через CosmicStrand, или (что более вероятно) где-то существуют другие варианты и C2-серверы, которые мы еще не обнаружили.
Жертвы
Нам удалось обнаружить жертв CosmicStrand в Китае, Вьетнаме, Иране и России.
Выводы
CosmicStrand - это сложный руткит для прошивки UEFI, который позволяет своим владельцам добиться очень длительной стойкости: в течение всего срока службы компьютера, и в то же время чрезвычайно скрытен. Судя по всему, он используется в течение нескольких лет, и все же остается много загадок. Сколько еще имплантатов и серверов C2 могут все еще ускользать от нас?
В любом случае, обнаруженные на сегодняшний день многочисленные руткиты свидетельствуют о наличии "слепого пятна" в нашей индустрии, которое необходимо устранить как можно скорее.
Самым поразительным аспектом этого отчета является то, что этот имплант UEFI, похоже, использовался в дикой природе с конца 2016 года - задолго до того, как атаки на UEFI начали публично описываться. Это открытие заставляет задать последний вопрос: если злоумышленники использовали это тогда, то что они используют сегодня?
* Хук - это модификация нормального хода выполнения программы. Его цель - выполнить дополнительный код, предоставленный злоумышленником, до или после данной функции.
