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

Краткий обзор

Данная статья продемонстрирует, что аппаратные бэкдоры постоянного действия являются практичными. Мы создали демонстрационный прототип вредоносного ПО для архитектуры Intel - Rakshasa¹, который может заражать более сотни различных моделей материнских плат. В результате действий Rakshasa отключается атрибут NX и удаляются связанные с SMM [1] исправления BIOS и прошивок UEFI [2],[3] или PCI[4], что приводит к перманентному снижению безопасности зараженного компьютера даже после стирания его жестких дисков и переустановки операционной системы. Мы также продемонстрируем, что существующие методы атаки MBR вроде буткитов и брутфорса/обмана программ предзагрузочной аутентификации могут быть встроены в Rakshasa меньшим количеством усилий. Более того, Rakshasa построен на базе свободного ПО, в том числе Coreboot [5], Seabios [6] и iPXE [7], а, значит, большая часть его исходного кода является открытой и невредоносной, что затрудняет обнаружение ее участия в подрывной деятельности. В финальной части мы продемонстрируем, что установка закладок в BIOS или в прошивки PCI с целью получения возможности тихой загрузки удаленных начинок через http-соединение является практичной и убивает всякую надежду обнаружить заражение с помощью существующих инструментов программно-технической экспертизы и антивирусов. Посредством данной статьи мы надеемся повысить осведомленность индустрии об опасностях, связанных со стандартом PCI, особенно касающихся использования прошивок с закрытым исходным кодом, поставляющихся с каждым компьютером, их целостности и истинного предназначения. Мы также надеемся, что приведенная информация позволит улучшить установившуюся практику в компаниях, занимающихся программно-технической экспертизой, путем включения в план работ проверки упомянутых прошивок.

1 Введение

В недавнем [8] отчете американо-китайской комиссии по экономике и безопасности "Занимая информационную высоту: возможности Китая по проведению компьютерных сетевых операций и кибершпионажу", выполненном Northrop Grumman Corp, говорится: "Эта тесная связь между некоторыми крупнейшими китайскими и мировыми производителями телекоммуникационного оборудования создает потенциальный вектор для спонсируемых или направляемых правительством вторжений в цепочки поставок микроэлектронного обеспечения военному и гражданскому правительству США и ключевым отраслям американской промышленности вроде оборонной и телекоммуникационной, хотя открытых доказательств подобной связи не существует". Другими словами, с тех пор, как Китай стал де-факто крупнейшим производителем IT-оборудования в мире, он получил возможность устанавливать закладки в любой компьютер. Это же может сделать любой участник цепи поставок. Мы полагаем, что это эвфемизм: в данном документе мы продемонстрируем практичность установки подобных закладок с помощью существующего ПО с открытым кодом, понизив тем самым планку данной атаки с уровня государства или, по меньшей мере, крупных корпораций до уровня любого эксперта по 16-битному ассемблеру, а также покажем, что удаленная установка такой закладки осуществима на практике.

2 Работы, связанные с данной

Первый известный вирус, Brain, был предположительно создан в Пакистане в начале 80-х годов. Он заражал Главную Загрузочную Запись (MBR) первого загрузочного жесткого диска, что позволяло ему выполняться на раннем этапе, и распространялся через гибкие диски. Данный вектор атаки в течение 80-х и 90-х годов, пока Интернет еще не стал по-настоящему массовым явлением, был использован буквально тысячами вирусов. Затем вирусы переселились в пространство пользователя, чтобы использовать в качестве вектора распространения доступ в Интернет.

Раннее выполнение долгое время считалось лучшим способом получения наивысших привилегий на IBM PC. В 2009 году на конференции Cansecwest Анибал Сако и Альфредо Ортега [9] продемонстрировали способ применения патча к Phoenix-Award BIOS для встраивания вредоносных возможностей (модификации файла shadow в UNIX-подобных системах или применения патчей к исполняемым файлам Windows). В 2007 году Джон Хисман [10] показал, что заражение загрузчика EFI (Extensible Firmware Interface) приведет к тем же результатам. Однако, Сако и Ортега были нацелены на определенный тип BIOS, а с атакой Хисмана можно бороться путем переустановки загрузчика.

Эксплуатационные модификации файловой системы заметны и оставляют очевидную улику для программно-технической экспертизы: очевидно, что простое вычисление контрольной суммы от всех существующих в файловой системе файлов до и после заражения позволит обнаружить модификацию. Поэтому исследователи в области безопасности разработали способы контролирования ядра, не воздействующие на файловую систему. Примечательными примерами таких способов являются BootRoot [11] Дерека Соудера и Райана Пермеха, vbootkit Кумара и Кумара [12], способный выполнять роль буткита для ядра Windows 7, буткит Stoned [13] и коммерческий буткит Kon-boot Петра Бани [14], способный контролировать все существующие 32- и 64-битные ядра ОС семейства NT от Windows XP до Windows 2008 R2 и Windows 7. Данные атаки работают за счет загрузки с альтернативного носителя информации вроде дискеты или usb-диска или за счет замещения существующей MBR (с переносом ее первого сектора в память, эмулируя прерывание 0x19). Запуск буткита с альтернативного носителя не оставляет улик для программно-технической экспертизы. Также стоит отметить, что буткит Stoned позволяет работать с ядром Windows даже при наличии шифрования инструментами вроде TrueCrypt [15].

Стоит упомянуть, что внутренние принципы работы любого буткита одинаковы: перехват прерывания 0x13 (обращение к диску) путем изменения таблицы векторов прерываний (IVT), установка своего обработчика прерываний, эмуляция прерывания 0x19 путем загрузки первого сектора первого загрузочного диска по адресу 0x0000:0x7c00 и передача выполнения загруженному сектору. Первый сектор в свою очередь нормально загружает операционную систему, однако, специальный обработчик прерывания будет перехватывать любое чтение сектора диска и, как только ядро главной операционной системы будет полностью распаковано в памяти, применит патч к нескольким аккуратно выбранным участкам памяти, чтобы модифицировать ядро на лету. Свободно доступные начинки позволяют накладывать заплатки на NT-ядро так, чтобы оно принимало любой пароль для любой пользовательской записи или позволяло загружать неподписанные модули ядра, которые могут эффективно выполнять любые операции в нулевом кольце после полной загрузки операционной системы (позволять повышение локальных привилегий, удаленное управление и т. д.).

Основной вклад нашей работы в состоит следующем:

• Осуществляется ромкит не одной, а сотен различных материнских плат, что на два порядка превосходит существующие исследования
• Любой существующий буткит может быть встроен в наш ромкит без какой-либо модификации
• Использование маршрутизируемых IP-пакетов для обновления ромкита, выполнение удаленных начинок и опциональная атака локальной сети через стеки Ethernet или Wi-Fi
Механизм, делающий ботнет устойчивым к получению правоохранительными органами контроля над DNS-серверами, который использует протокол HTTPS, асимметричную криптографию, а также механизм репликации, практически исключающий возможность отключения ботнета
• Долговременное снижение уровня безопасности любой будущей (неизвестной на текущей момент) операционной системы, установленной на зараженном компьютере, в то время как существующие буткиты предполагают использование ОС на базе ядер GNU/Linux или NT
• Инфекция остается даже при перезаписи ROM BIOS за счет заражения множества прошивок PCI (например, прошивки CDROM) вредоносными сетевыми прошивками, способными обновлять содержимое любого другого PCI ROM удаленно (например, перезаразить BIOS главный PCI ROM сети) при сохранении первоначальной функциональности
• В ядрах NT отключается рандомизация адресного пространства (ASLR) [16] и атрибут NX², а любая уязвимость в последующих версиях ОС Windows на зараженной машине становится тривиально эксплуатируемой
• Механизм заражения позволяет инициатору при обнаружении закладки дать альтернативное объяснение и достаточно легко отрицать свою причастность, поэтому может использоваться на государственном уровне для глобальной установки закладок

3 Обзор архитектуры IBM PC и ее проблем

Архитектура IBM PC была разработана приблизительно в 1981 году. С тех пор она эволюционировала: старая шина ISA (Industry Standard Architecture) [17] была замещена более быстрой PCI (Peripheral Component Interconnect) в 1996, а затем еще более быстрой PCI Express (раскрученной Intel в 2004 году и часто обозначаемой как PCI-E или PCIe)[18]. Однако, базовая структура не изменилось, а CPU все так же запускается в режиме совместимости 8086 (то есть, 16-битном режиме реальных адресов) даже на самых свежих материнских платах. Стоит отметить, что Windows 95 имела открытые общие сетевые ресурсы (netbios), то есть, в то время Microsoft не предвидела бурного развития Интернет, а потому разрабатывала операционную систему для использования преимущественно в локальных сетях. Стоит ли говорить, что в 1981 IBM также не могла предвидеть развитие Интернет. Общее устройство компьютера IBM PC представлено на рисунке 1. Двигаясь снизу вверх, мы сначала видим Super I/O, к которому присоединяются старые устройства ISA (медленные устройства) вроде клавиатуры, мыши и дисководов. Super I/O соединен с Южным мостом (South Bridge) через шину LPC. Южный мост отвечает за подключение более быстрых периферийных устройств (до 2133 Мб/с для PCI-X 2.0), обычно совместимых со стандартом PCI. Примерами таких устройств могут быть сетевые (Ethernet), звуковые карты и старые видеокарты. Южный мост, в свою очередь, соединен через внутреннюю шину с Северным мостом, который отвечает за подключение гораздо более быстрых устройств, обычно совместимых со стандартом PCIe и передающих данные со скоростью до 16 Гб/с (в третьей версии стандарта). Примеры подобных устройств - новые 3D видеокарты, гигабитные Ethernet-карты или корпоративные хранилища (SAS). Северный мост может содержать CPU и, в любом случае, имеет с процессором высокоскоростное соединение через Переднюю шину (FSB). Каждый слой архитектуры содержит чипы Прямого Доступа к Памяти (DMA), которые контролируются блоком управления памятью для операций ввода/вывода (IOMMU) [19] по соображениям безопасности и скорости.

Рисунок 1: Обзор архитектуры IBM PC

Поскольку периферийные устройства иногда нуждаются в обновлении, они контролируются встроенными прошивками: ISA-устройства хранят прошивки на в ромах ISA, а PCI-устройства - в ромах расширения. Хотя конечные пользователи едва ли знают о существовании этих прошивок, прошивки могут обновляться, как правило, через проприетарные инструменты, ориентированные на конкретного вендора. Для защиты от тривиальной установки закладок, некоторые карты снабжены физическим переключателем, положение которого необходимо изменить вручную, чтобы разрешить перезапись прошивки.

Другой важной прошивкой является прошивка BIOS, которая хранится в материнской плате. Она отвечает за обнаружение оборудования вроде RAM и периферийных устройств во время загрузки, инициализацию Таблицы Векторов Прерываний (IVT) и загружает Главную Загрузочную Запись (MBR) первого загрузочного диска с помощью прерывания 0x19. При загрузке в режиме совместимости с 8086 загрузчик ОС может загружать ядро, полагаясь только на IVT. Ядро обычно быстро переключается в защищенный режим и больше не обращается к IVT, используя из защищенного режима в качестве интерфейсов к оборудованию драйвера устройств. Прошивка BIOS также может быть обновлена, и, на самом деле, распространенной практикой является исправление аппаратных багов путем передачи процессору из BIOS подписанных обновлений микрокода. Наконец, BIOS обычно активирует бит управляющих регистров, запрещающий переводить процессор в режим системного управления (SSM), чтобы предотвратить класс атак, открытый Лоиком Дюфлотом [1] и реализованный BSDaemon [20]. Некоторые производители, особенно HP, стали подписывать свои версии прошивок BIOS, чтобы избежать мошеннических обновлений BIOS. В любом случае, атакующий с физическим доступом к BIOS или периферии может заменить прошивки, не полагаясь на операционную систему и используя для записи прошивок, например, самодостаточные аппаратные инструменты, основанные на FGPA-чипах.

Одна из проблем дизайна данной архитектуры заключается в доверии периферийных устройств одного слоя друг другу. Например, прошивка PCI CDROM может полностью контролировать сетевую карту PCI. Аналогично, прошивка ISA может контролировать другое ISA устройство. Это поведение невозможно изменить: так работает IBM PC.

Также стоит отметить, что Доверяемый Платформенный Модуль (Trusted Platform Module, TPM) [21] обычно соединен с Южным Мостом, и потому находится далеко от процессора. Более того, это пассивный компонент, то есть, программа может использовать или не использовать его, и процессор не может вынудить программу использовать данный модуль. Как мы увидим далее, это серьезная слабость архитектуры в целом.

Как можно ожидать, прошивки, встроенные в BIOS или в устройства PCI (ромы расширения PCI) зависят от производителя и совершенно не стандартизованы. Цель данной статьи - объяснить, как в общем случае модифицировать эти прошивки для создания бэкдоров, которые не могут быть обнаружены из пространства пользователя после того, как ядро было загружено в RAM, а процессор переведен в защищенный режим. Поскольку прошивка BIOS, строго говоря, - первая программа, запускаемая на компьютере, и поскольку она получает ранний контроль над каждым ромом расширения PCI на ранней стадии загрузки (до перехода в защищенный режим), любая вредоносная процедура, запускаемая на данной стадии, имеет полный доступ к аппаратным ресурсам. В частности, стоит напомнить, что реальный режим не позволяет реализовать многозадачность, то есть, подобные вредоносные процедуры имеют стопроцентный доступ к ресурсам машины.

4 Разработка совершенного бэкдора: план работ

Автор данной статьи обычно не тратит время на написание вредоносных программ. Напротив, он тратит значительную часть его жизни на их изучение и реверсирование. Однако, чтобы доказать наши утверждения, давайте притворимся, что мы действительно хотим разработать правильный бэкдор, пригодный для использования в реальных условиях. Мы также считаем, что большинство вредоносных, предполагающих обмен информацией программ (если не все они), новости о которых исходят от основных производителей антивирусов и подхватываются подобострастными средствами массовой информации, явно окутаны пеленой страха, неуверенности и сомнения (FUD³). Вместо споров о том, были ли Flame и Stuxnet написаны любителями или национальными правительствами, давайте посмотрим, как атакующий может без особых затрат создать бэкдор высшего уровня. Это также может послужить хорошим примером того, как производитель оборудования может разработать подходящий бэкдор с похожими намерениями. Прежде всего мы хотели бы, чтобы наш бэкдор присутствовал на зараженной системе постоянно. Он должен сохраняться не только после перезагрузки, но и в случае, если пользователь компьютера заменил всю операционную систему и, возможно, часть оборудования (жесткий диск или сетевую карту, например), перезаписал BIOS или любую другую прошивку на материнской плате или периферии. Чтобы достичь этой цели, нам понадобится обеспечить отсутствие единой точки отказа, то есть, внести некоторую избыточность.

Конечно, бэкдор должен быть как можно более скрытым. Очевидно, что он не должен обнаруживаться никаким из существующих антивирусов. Он также должен быть портируемым: в идеале мы хотели бы, чтобы он был полностью независим от операционной системы. Поскольку значительная часть IT-бюджета компаний тратится на дорогие (и довольно неэффективные⁴) средства обнаружения атак вроде систем предотвращения и обнаружения вторжений и файрволов, наш бэкдор должен уметь так или иначе нарушать сетевой периметр крупных компаний.

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

Наконец, если мы хотим сделать бэкдор уровня национального правительства, он должен подчиняться двум золотым правилам, используемым спецслужбами всего мира: наличие альтернативного объяснения (plausible deniability) и возможность отрицания причастности (non attribution). Первое означает наличие альтернативного объяснения в случае обнаружения бэкдора, несмотря на все наши усилия, направленные на максимальное его сокрытие. Имея альтернативное правдоподобное объяснение наличия бэкдора в системе, национальное правительство может отрицать причастность к злонамеренным действиям и расценивать своих критиков, как приверженцев теории заговора. Отрицание причастности - это тоже важная возможность, не позволяющая связывать бэкдор с каким либо лицом или государством. Это в духе национальных правительств - говорить "Это не мы! Это все Китай".

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

5 Детали реализации: Rakshasa

Четыре ограничения: низкая стоимость разработки, обилие возможностей (вроде сетевого стека), трудность обнаружения и анонимный характер определяют единственную подходящую базу реализации: свободное ПО с открытым кодом. На самом деле, использование в качестве базы узкоспециализированного кода, до сих пор характерное для практически всех вредоносных программ, является плохой идеей, поскольку предоставляет антивирусам широкий простор для детектирования, часто позволяет установить причастность автора, если код используется несколькими вредоносными программами, и совершенно несравнимо по цене с открытым ПО. Напротив, использование невредоносного свободного ПО с открытым кодом в качестве ядра бэкдора дает малую вероятность обнаружения антивирусом, анонимный характер (исходный код доступен всем через Интернет) и минимальные затраты. Кроме того, этот подход дает автору вредоносного ПО бесплатную поддержку со стороны сообщества.

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

Rakshasa включает в себя специальную версию Coreboot для бэкенда BIOS, специальную начинку BIOS SeaBIOS, набор ромов расширения PCI (драйвер SVGA и специальный ром iPXE), а также активный буткит, получаемый по сети.

Coreboot сам по себе не является полноценным BIOS: он отвечает лишь за обнаружение имеющегося на машине оборудования, выполнение теста POST и передачу управления "начинке BIOS". Эта начинка в свою очередь отвечает за установку Таблицы Векторов Прерываний, которая позволяет операционной системе взаимодействовать с ранее обнаруженным оборудованием. В нашей конфигурации Coreboot и SeaBIOS были тривиальным образом изменены, чтобы ничего не выводить на экран, хотя теоретически Coreboot может отображать определенную пользователем заставку во время загрузки, замещающую изображение, отображаемое исходным BIOS (как правило, логотип производителя). SeaBIOS был выбран за его простоту, однако существуют и альтернативные начинки BIOS с открытым исходным кодом, которые также могут отображать меню и дурачить продвинутых пользователей, которые хотели бы изменить настройки BIOS. Другие начинки BIOS также содержат расширения EFI/UEFI, которые делают наш метод полностью применимым к средам UEFI⁶.

Coreboot имеет модульную архитектуру, которая позволяет встроить в него практический любой ром PCI, то есть, мы можем вставлять в чип BIOS произвольный код. Мы решили обойтись минимумом, добавив видео-драйвер и вредоносную iPXE-прошивку сетевой карты (также измененную, чтобы ничего не выводить в процессе работы). Эта PCI-прошивка реализует расширение исходного стандарта PXE [22]: вместо того, чтобы полагаться лишь на протокол DHCP для получения IP-адреса и адреса TFTP-сервера, с которого загружается операционная система, она может использовать множество протоколов на основании пользовательского файла конфигурации, встроенного в прошивку. iPXE содержит рабочие стеки для протоколов канального уровня Ethernet, Wi-Fi и даже WiMAX, полный стек IPv(4/6)/ICMP и реализует все сетевые стеки верхних уровней, о которых только может мечтать разработчик вредоносных программ: от UDP и TCP до DHCP, DNS, HTTP, HTTPS и (T)FTP.

Технически Coreboot мог бы встроить в BIOS ROM полнофункциональный бэкдор. Но, поскольку мы хотели бы заложить в Rakshasa возможности обновления и не оставить на машине следов присутствия вредоносного кода (чтобы сбить с толку программно-технического эксперта в случае обнаружения или, по крайней мере, подозрения), мы воздержимся от использования этой возможности: мы будем каждый раз загружать нашу вредоносную начинку по сети.

Вместо нормального запуска операционной системы, мы используем iPXE для удаленной загрузки буткита, который, в свою очередь, путем эмуляции прерывания 0x19 прозрачно загрузит загрузчик с первого загрузочного диска, на лету применит патч к ядру ОС и, в конечном итоге, тихо загрузит ядро операционной системы, как того и ожидает пользователь.

6 Внутреннее устройство Rakshasa

Rakshasa обычно может устанавливаться двумя путями. Первый, требующий физического доступа к машине, - перезапись прошивки BIOS. Это можно сделать либо путем использования специализированного физического флешера (обычно изготовленного из FPGA)⁷ или универсального флешера прошивок (например, через USB или CD-ROM. Можно также использовать PXE). Эта операция в любом случае занимает меньше минуты.

Второй метод установки осуществляется после вторжения и не требует физического доступа к оборудованию: как только атакующий получает удаленный доступ к компьютеру от имени суперпользователя, он может использовать все тот же универсальный флешер для замены исходного BIOS на Rakshasa. Если операционная система - не Linux, можно просто использовать MBR при следующей перезагрузке. Для достижения избыточности и отсутствия единой точки отказа, прошивка сетевой карты также заменяется вредоносной прошивкой iPXE.

Дополнительно модифицированной версией iPXE можно заменить еще одну PCI-прошивку (как правило, прошивку CD-ROM). К сожалению, при этом невозможно поддерживать функциональность этого второго устройства (хотя теоретического ограничения тут нет - это лишь проблема реализации). Если BIOS попытается загрузиться с этого второго устройства, результат будет прежним: компьютер на самом деле станет загружаться через iPXE, то есть, из сети.

iPXE может выполнять некоторые действия в случае неудачного выполнения других действий. Чтобы максимизировать вероятность работоспособности в любой среде, мы настроили iPXE так, что сначала она пытается соединиться с Интернет через Wi-Fi. Некоторое количество распространенных SSID и даже шифров может быть указано на этапе компиляции. Обычно мы пытаемся загрузиться из сети с определенным атакующим SSID-ом, либо из сети с точкой доступа, защищенной по протоколу WEP. В случае неудачи, мы пытаемся соединиться с публичной сетью, имеющей SSID (берущийся из короткого списка), обычно ассоциируемый с открытыми точками Wi-Fi доступа. Главное преимущество использования Wi-FI - обход любой сетевой фильтрации или механизмов обнаружения в корпоративных средах. На самом деле, даже если Rakshasa использовался бы в большой организации, чей доступ в Интернет обычно осуществляется через аутентифицирующий прокси-сервер, даже если в сети этой организации находилась бы IDS или IPS, даже если бы имела место должная сегрегация DNS, простой факт использования зашифрованного Wi-Fi в качестве канального уровня полностью прорвал бы периметр сети и сделал бы все эти дорогие устройства бесполезными.

Если после манипуляций с Wi-Fi Rakshasa все еще не смог выйти в Интернет, он попытается получить IP-адрес по DHCP через Ethernet. Если же и это ему не удастся, он выберет подходящий статический IP. Для незаметности скорость имеет критическое значение, поэтому некоторые варианты подключения к Интернет могут быть пропущены за счет модификации файла настроек на этапе компиляции.

Если Rakshasa так и не получил хотя бы доступа к локальной сети, он просто загрузит операционную систему по умолчанию, чтобы остаться незамеченным.

На данном этапе Rakshasa может сделать несколько вещей. Если ему удалось получить лишь доступ в Ethernet-сеть, он может попытаться атаковать хосты, достижимые по локальной сети, используя любой простокол, работающий поверх IPv4/IPv6 или ICMP. Набор возможных атак регулируется файлом конфигурации iPXE и может включать: поиск хостов через icmp, сканирование tcp/dns портов, фарминг маршрутизаторов (по http/https), эксплуатирование сетевых демонов или сетевых стеков (ping of death, атаки ipv6, рассылка широковещательного трафика, DDoS и т. д.). Можно, например, попытаться изменить настройки ADSL-роутера, касающиеся открытых портов. Все это не особенно умно и незаметно, так что данная возможность упомянута лишь для полноты картины. По существу, выполнение подобных действий противоречит принятому нами принципу "альтернативного объяснения", поскольку на машину вместе с бэкдором встраивается и вредоносный код.

Затем Rakshasa обычно пытается соединиться через Интернет с определенным хостом по протоколу https (скажем, google.com, потому что он вряд ли вызовет тревогу, даже если соединение сделано через ethernet). Если ему это удается, Rakshasa считает, что имеет полный доступ в Интернет. В противном случае (который может иметь место, если зараженный компьютер не имеер Wi-Fi карты, и сеть сегрегируется аутентифицирующим файрволом), Rakshasa может попытаться выйти в Интернет по TCP поверх DNS (которого хватит, если сеть не имеет должной DNS-сегрегации между локальной сетью и внешним миром) или TCP поверх ICMP (почему бы и нет!).

Как проницательный читатель уже мог заметить, предел возможностей практически отсутствует: улучшение способностей Rakshasa сводится к добавлению нескольких строк текста в его файл iPXE-конфигурации и, в худшем случае, наложению небольшой заплатки на сетевой стек для каких-нибудь экзотических протоколов⁸. Даже если попытка получить доступ к Интернет часто оказывается неудачной, это на самом деле не является проблемой: проводящегося время от времени подключения к открытой Wi-Fi сети в аэропорту или к домашней сети будет достаточно для обновления Rakshasa.

Как только получен доступ в Интернет (даже если это происходит лишь время от времени), Rakshasa загрузит буткит из заданного местоположения в Интернет, например, файл с названием "foobar.pdf" из определенного блога по протоколу https или "data.dat" с некоторого FTP-сервера и т. д. Стоит упомянуть, что здесь опять же возможно несколько попыток, что дает большую устойчивость к выключению главного C&C-сервера (выполненного в виде простого блога? )по предписанию властей. Устойчивость также увеличивается за счет наличия списка из нескольких доменных имен или IP-адресов и, возможно, служб (хотя взаимодействие через https вероятно является самым надежным вариантом, и в оставшейся части документа он будет считаться единственной опцией), с которых можно загрузить буткит.

И последний (но не по значимости) момент: iPXE может соединять в цепочку конфигурационные файлы, скачанные из Интернет. Учитывая это, понятно, что Rakshasa не нужно содержать ни одной ссылки на буткит (поэтому код, хранящийся в компьютере, не содержит ни одной вредоносной строки, и у антивируса нет поводов считать его опасным⁹).

Стоит отметить, что, если удаленный буткит когда-нибудь будет замещен флешером BIOS, Rakshasa может быть обновлен удаленно! Перезапись прошивок PCI немного сложнее: прежде всего, необходимые инструменты сильно зависят от производителя. Чтобы заменить прошивку PCI на определенной сетевой карте, удаленному веб-сайту, действующему как C&C-сервер (Command and Control - сервер управления и контроля), понадобится узнать производителя карты. К счастью, iPXE позволяет отсылать MAC-адрес Ethernet-карты как параметр URL¹⁰. Из MAC-адреса простой php-скрипт, помещенный на C&C-сервер, может вытащить значение OUI (первые 24 бита) и, таким образом, вычислить производителя. На основании этой информации C&C-сайт может вернуть инструмент для перезаписи и прошивку, подходящую для конкретного устройства в форме загружаемой GNU/Linux среды, которая после завершения всех действий эмулирует прерывание 0x19 и загружает ОС. Вторая проблема исходит из факта, что некоторые PCI-устройства снабжены физическим переключателем, который должен быть передвинут вручную прежде, чем обновление прошивки станет возможным. По сути же, это небольшая проблема, поскольку ромы расширения PCI могут помещаться напрямую в Coreboot и будут иметь больший приоритет, чем те, что физически присутствуют на устройстве.

Наконец, тот же механизм может быть использован для удаленного снятия заражения путем восстанвления прежнего BIOS вместо выполнения обычного обновления Rakshasa.

7 Встроенные возможности Rakshasa

Архитектура Rakshasa позволяет использовать вместе с ним любой бэкдор без какой-либо модификации путем простого изменения вредоносной начинки, загружаемой с C&C-блога (не требуя от компьютера с бэкдором никакой настройки).

Активная начинка Rakshasa сначала запускается как главная операционная система (из 16-битного реального режима), и может делать все, что и обычная ОС. В частности, он может выполнить любую операцию из арсенала современных буткитов вроде наложения заплатки на процедуру аутентификации Windows, позволяющую локальный вход с произвольным паролем. Та же процедура используется для аутентификации в Windows по протоколу удаленного рабочего стола, то есть, этого может быть достаточно для получения удаленного контроля над компьютером. Другие техники буткитов также показали свою применимость. Пример - внедрение неподписанного драйвера ядра, который в свою очередь запускает произвольный процесс (внедренный буткитом) с привилегиями SYSTEM в пространстве пользователя, не прикасаясь к файловой системе (на самом деле этого более чем достаточно для удаленного получения полного контроля над компьютером: обратный meterpreter через HTTPS, возможно после внедрения в веб-браузер DLL для обхода ограничений межсетевого экрана на уровне ОС, и получение учетных данных конечного прокси-сервера из реестра или с помощью внутреннего API Windows - также практичный поход, и для выполнения всех этих действий существует код в открытом доступе).

За помощью в демонстрации работы Rakshasa мы обратились к Петру Бане, который любезно согласился сделать специальную версию его великолепного коммерческого буткита Kon-boot, отличающуюся тихой загрузкой (убрать 16-битную графику, которая, хоть и выглядит впечатляюще, но совсем не способствует скрытости бэкдора). Kon-boot - очень продвинутый буткит, способный изменять процедуру аутентификации любой системы Windows - от XP до 7 и 2008, как 32, так и 64-битные версии.

Если ОС является разновидностью Windows, мы можем отключить ASLR путем изменения зерна рандомизации на выбранное нами значение¹¹. Мы также можем удалить бит NX в записях таблицы страниц прямо из RAM¹². Комбинация этих двух действий сделает исполняемыми данные (т. е. data, bss, heap, stack) в адресном пространстве любого процесса, а отображение адресного пространства полностью предсказуемым. Другими словами, эксплуатация любой будущей уязвимости данной операционной системы становится тривиальной. Это эквивалентно удалению большинства улушений безопасности, введенных Microsoft за последние 10 лет.

Но этого недостаточно: мы хотели бы атаковать другие (возможно еще неизвестные на момент установки бэкдора) операционные системы универсальным способом. Поскольку мы, по существу, контролируем не просто вредоносную начинку, но весь процесс загрузки с момента выполнения первого бита BIOS ROM, мы можем гораздо больше. В частности, мы можем удалить из Coreboot обновления микрокода процессора. Именно BIOS занимается применением этих обновлений: если мы удалим микрокоды, тогда баги процессора и потенциальные уязвимости, обычно исправляемые на данном уровне, останутся эксплуатируемыми.

Мы также можем удалить средства защиты от SSM, что будет иметь те же последствия, как если бы мы сделали операционную систему уязвимой к универсальному локальному эксплоиту [20].

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

8 Как построить ботнет базе BIOS: BIOS-ботнеты

Кто-то может утверждать, что самым слабым компонентом архитектуры является блог, используемый в качестве C&C. Пришло время развеять заблуждения, касающиеся безопасности ботнетов: если производители могут выпускать обновления безопасности, а Microsoft, похоже, по большей части этим и занимается последние 10 лет, не существует никаких причин, по которым разработчики вредоносного ПО не могут делать того же.

Безусловно, самый уязвимый компонент архитектуры современных ботнетов - доступность их C&C-сервера. Всякий раз, когда правоохранительные органы обнаруживают, что некоторое доменное имя принадлежит C&C, они, как правило, берут DNS-сервер под свой контроль, перенаправляют DNS на контролируемый ими IP-адрес и рассылают всем хостам, подключающимся к этому адресу, команду выключения.

Помешать правоохранительным органам (или кому-либо еще) рассылать ботнету команды выключения относительно просто: достаточно подписывать команды с помощью сильного асимметричного алгоритма. Обновления Rakshasa также могут иметь цифровую подпись, которая предотвратит модификацию обновлений посторонними. Таким образом осуществляется контроль целостности.

Единственная оставшаяся проблема - это доступность C&C (хотя бы частичная и непостоянная: строго говоря, нам необязательно обновлять наш бэкдор при каждой перезагрузке). Тривиальный способ для решения этой проблемы - ротативный C&C, то есть, каждый раз случайно выбираемый Rakshasa из всего диапазона IP-адресов¹³. Бэкдор в этом случае будет обновляться реже, но C&C нельзя будет просто выключить.

Наконец, встраивание в бэкдор клиентских SSL-сертификатов не даст обнаружить C&C-хосты путем сканирования Интернет на предмет определенных файлов. Стоит упомянуть, что Coreboot может использовать его собственный встроенный образ CMOS, позволяя тем самым хранить в NVRAM CMOS криптографические ключи (стираемые при отключении питания). Сочетание такой возможности вместе с использованием характеристик оборудования (как правило, MAC-адреса) для восстановления ключей дешифрования при каждой перезагрузке позволяет создать бэкдор, который крайне сложно извлечь из оборудования (например, его нельзя просто скопировать в виртуальную машину для анализа). Мы полагаем, что BIOSBotnet обладающий такой архитектурой, практически невозможно отключить.

9 Почему шифрование (даже с аппаратной поддержкой) не решает проблемы

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

Прежде всего, технология полного шифрования диска (Full Disk Encryption, FDE), как выяснилось, содержит множество изъянов реализации [23][24] и зачастую может быть атакована "грубой силой" [25]. Столь же просто было показать, что она не спасает от буткитов, если не связана с TPM [13]. Мы кратко опишем вариант атаки "evil maid" [26], применимый к сценарию, в котором Rakshasa нужно обойти данное средство безопасности. Для начала отметим, что TPM - пассивный чип, поэтому Rakshasa может загрузить удаленную ОС в тихом режиме, несмотря на присутствие TPM.

Давайте сперва предположим, что TPM отсутствует. Тогда Rakshasa может обнаружить, что первый загрузочный жесткий диск зашифрован, и вместо скачивания буткита загрузить небольшую операционную систему, маскирующуюся под приглашение входа FDE, затем подождать, пока пользователь введет свои учетные данные, сохранить пароль в CMOS и, возможно, передать его C&C-серверу. Как только пароль стал известен, Rakshasa может отключить прерывание 0x10 (видео), сэмулировать прерывание 0x19, чтобы перезагрузить реальный загрузчик, после чего симитировать ввод с клавиатуры [23] в 16-битном режиме путем прямого программирования микроконтроллеров PIC, встроенных в клавиатуру и материнскую плату, и в итоге позволить системе нормально загрузиться.

Давайте теперь предположим, что TPM присутствует. Если бэкдор на машину был установлен до того, как конфигурация была "опечатана" TPM (типичный случай - бэкдор был установлен производителем или кем-либо из цепочки поставок перед доставкой), атака не меняется. На самом деле, удаление бэкдора после установки TPM изменит содержимое регистра TPM при загрузке, в результате чего жесткий диск вообще не будет расшифрован. Так что, бэкдор фактически защищен от фальсификации!

10 Заключение

В данной небольшой статье мы выделили некоторые проблемы, присутствующие в современных PC из-за плохого наследия и слабой архитектуры безопасности. Так как PC были разработаны еще в начале 80-х годов, их архитектура не учитывает сегодняшнего характера использования компьютеров, она больше сосредоточена на возможности взаимодействия основных периферийных устройств, а не на сегрегации и безопасности. К сожалению, это невозможно исправить простым путем: чтобы сделать компьютеры неуязвимыми к аппаратным бэкдорам, требуются радикальные модификации архитектуры, которые приведут к отсутствию обратной совместимости. Стоит отметить, что даже самые современные технологии вроде TPM и полного дискового шифрования не могут предотвратить установку бэкдора кем-либо в цепочке поставок. Мы надеемся, что данная статья поможет увеличить осведомленность сообщества специалистов по безопасности и убедить тех, кто принимает решения, тратить больше на проверку целостности оборудования и программ, а не на серебрянные пули, которые за последние 30 лет доказали свою несостоятельность. В частности, хорошей идеей (но не достаточным решением) было бы включение в программу аудита безопасности проверки прошивок ромов PCI и BIOS перед использованием и в ходе программно-технической экспертизы.

11 Благодарности

Мы хотели бы поблагодарить: Флорентина Деметреску, члена проекта Coreboot, без которого данное исследование так бы и не началось- Петра Баню за любезное предоставление специальной версии Kon-Boot, которая помогла нам в демонстрации- французскую и австралийскую команды Toucan System: я бы не провел данное исследование без их постоянной моральной и технической поддержки.

Ссылки

1. Duflot, L.: Seurity issues related to pentium system management mode, CanSecWest (2006)
2. Intel: Extensiblefirmware interface specifications v1.10 (2003)
3. Intel: Unified extensiblefirmware interface specifications (2005)
4. PCI-SIG: Peripheral component interconnect specifications lb3 v0.2.6 (2004)
5. Coreboot: (Coreboot - formerly linuxbios)
6. Coreboot: (Seabios - opensource implementation of a 16bit x86 bios)
7. iPXE: (ipxe - open source bootfirmware)
8. Northrop-Grumman-Corp: Occupying the information high ground: Chinese capabilities for computer network operations and cyber espionage(2012)
9. Saco, A., Ortega, A.: Persistant bios infection, CanSecWest (2009)
10. Heasman, J.: Firmware rootkits and the threat to the enterprise, Blakhat USA (2007)
11. Soeder, D., Permeh, R.: Bootroot, Blackhat USA (2005)
12. Kumar, Kumar: Bootkit 2.0: Attacking windows 7 via boot sectors, HackinTheBox (2010)
13. Kleissner, P.: Stoned bootkit, Blackhat USA (2009)
14. Bania, P.: Kon-boot (2008)
15. Roux, P. L.: (Truecrypt - free open-source on-the-fly disk encryption software)
16. PaX: (Address space layout randomization)
17. IBM: (Connector bus isa (industry standard architecture))
18. PCI-SIG: Pci express base r3.0 v1.0 (2010)
19. AMD: (I/o virtualization technology (iommu) specification revision 1.26)
20. BSDaemon-Coideloko-D0nAnd0n: System management mode hack using smm for "other purposes". (Phrack magazine)
21. Trusted-Computing-Group: (Trusted platform module specifications)
22. Intel: (The preboot execution environment specification v2.1)
23. Brossard, J.: Bypassing preboot authentication passwords by instrumenting the bios keyboard buffer, Defcon (2008)
24. Brossard, J.: Bios information leakage. (2005)
25. Brossard, J.: Bruteforcing preboot authentication passwords, h2hc conference (2009)
26. Rutkowska, J.: Evil maid goes after truecrypt! (2009)