Виртуальная шпиономания

Виртуальная шпиономания

Я не являюсь профессионалом в области информационной безопасности, моя область интересов это высокопроизводительные вычислительные комплексы. В тему ИБ я пришел совершенно случайно, и именно об этом пойдет дальше речь. Думаю, эта невыдуманная история гораздо лучше осветит проблемы связанные с аппаратурой виртуализации, нежели сухое изложение фактов.

Еще до официального анонса новых процессоров Intel с поддержкой аппаратной виртуализации (это было в начале 2007года) я задумал использовать эту аппаратуру для создания на базе нескольких серверов единой вычислительной системы, которая для Операционной системы и прикладных программ представлялась единой вычислительной установкой выполненной по SMP архитектуре. Для этого требовалось написать компактный Гипервизор с нестандартным функционалом, главной особенностью которого было не разделение ресурсов единой вычислительной установки между разными ОС, а наоборот, объединение ресурсов нескольких вычислительных машин в единый комплекс, который бы управлялся одной ОС. Причем эта ОС даже не должна была догадываться, что имеет дело с несколькими серверами, а не с единой системой. Аппаратура виртуализации предоставляла такую возможность, не смотря на то, что изначально для этого не предназначалась. Собственно и до сего момента никто не создал таких систем, в которых аппаратура виртуализации применяется для высокопроизводительных вычислений, а уж тогда я был первопроходцем этой темы.

Гипервизор для этой задачи, конечно, писался с «нуля», использовал потенциал оборудования достаточно нестандартными методами, и принципиальным было запустить ОС на уже виртуализированной платформе, чтобы с первых команд загрузчика ОС все работало в виртуальной среде. Для этого пришлось виртуализировать все режимы работы процессора, начиная с реальной модели его работы и запускать виртуализацию сразу после инициализации платформы и до загрузки ОС.

Поскольку система виртуализации для этой цели получалась нестандартной, и выглядела как полностью автономный, компактный программный модуль (размер кода не более 40-60кбайт), язык как-то не поворачивался его называть «Гипервизор», и я стал применять для его названия термин «Гипердрайвер», поскольку он более точно передавал суть его функционального предназначения.

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

Макет был собран, Гипердрайвер написан, все заработало, как и было задумано. Нужно сказать, что на тот момент аппаратура виртуализации было очень «сырой» и возникало множество ситуаций, когда она отказывалась работать так, как написано в документации. Приходилось разбираться буквально с каждой ассемблерной командой в коде, а сами команды для аппаратуры виртуализации писать в машинных кодах, поскольку на тот момент не было компиляторов с поддержкой команд виртуализации.

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

Начал разбираться, и понял, что вся моя система виснет при выполнении команд аппаратной виртуализации, было такое впечатление, что они или совсем не работали, либо работали как-то не стандартно. Причем зависание происходило только во время работы аппараты виртуализации в реальном режиме, если же моя система запускалась из защищенного режима, после загрузки ОС, то все было нормально.

Профессионалы знают, что в первых ревизиях аппаратуры виртуализации Intel не поддерживала работы процессора в реальном режиме. Для этого требовался дополнительный слой эмуляции виртуального х86, достаточно большого объема. Поскольку Гипердрайвер запускался до загрузки операционной системы, чтобы она полностью поверила в новую виртуальную конфигурацию, то небольшой кусок загрузочного кода ОС выполнялся в реальном режиме работы процессора. Именно на обработчиках эмуляции реального режима в Гипердрайвере система висла с немедленной перезагрузкой.

Документация у Intel по виртуализации странная, написана путано и со многими белыми пятнами, потому, первое что пришло на ум – где то ошибся, что то не понял, о чем-то забыл. Проверил все до байтиков и битиков в своем коде, никаких ошибок не нашел, поэтому стал грешить уже не на себя, а на коллег «из-за бугра».

Первым делом заменил процессоры – эффект нулевой, на материнских платах в то время аппаратуры виртуализации не было, кроме как в БИОС, где она инициализировалась во время включения сервера, поэтому начал сравнивать на материнских платах (однотипных с семплами) БИОСЫ – все совпадало до байта и номера самого БИОС.

Я впал в ступор и уже не зная что делать, применил последнее средство – «метод тыка». Чего только я не делал, уже не думая, а просто комбинируя, и в конце концов, тупо переписал заново БИОСЫ в материнские платы, скачав их с официального сайта Intel, после чего все заработало…

Моему удивлению не было предела,- номер БИОС тот же самый, образы БИОС совпадают побайтно, но по какой то причине серийные материнские платы не хотели работать, пока в них не зальешь такой же БИОС, но с сайта Intel. Значит причина все-таки в материнских платах? Но единственное их отличие было в маркировке: на семплах было написано Assembled Canada, а на серийных платах Assembled China.

Эта ситуация могла поставить в тупик любого, но только не специалиста в области виртуализации, главный принцип которого «не верь глазам своим». Стало ясно, - платы из Китая содержали дополнительные программные модули, прошитые в БИОС, которые были не видны для стандартных программ их анализа. Эти невидимые программные модули похоже тоже работали с аппаратурой виртуализации и соответственно имели возможность скрыть истинное содержимое БИОС. Стала понятна и причина зависаний моего Гипердрайвера на этих платах из Китая, – две программные системы одновременно работали с одной и той же аппаратурой виртуализации, не предназначенной для разделения ее ресурсов.

Захотелось разобраться с этим зловредным БИОС, причем без всякой задней мысли о «закладках», «бекдорах», «недокументированных возможностях», был просто академический интерес и не более того.

Нужно сказать, что вместе с внедрением аппаратуры виртуализации Intel радикально обновила чипсет, он получил номер 5000х и выпускается в нескольких модификациях до сих пор. Южный мост этого чипсета631xESB/632xESB I/O Controller Hub , к которому подключены флеш-микросхемы с БИОС практически в неизменном виде выпускается с 2007года до настоящего времени и является базовым чипом для практически всех серверов в двух-сокетном исполнении. Скачиваю даташит на южный мост, читаю и просто «обалдеваю» от прочитанного. Оказывается, к этому новому южному мосту подключается ТРИ микросхемы флеш-памяти, первая – это стандартный БИОС, вторая флеш-микросхема предназначена для программ процессора сетевого контроллера, третья микросхема флеш-памяти предназначена для интегрированного в южный мост блока ВМС.

Блок менеджмента системы (ВМС) – это средство удаленного управления и мониторинга вычислительной установки. Он незаменим для администрирования в больших серверных комнатах, где из-за шума, температуры и сквозняков находится долго просто невозможно.

То что блоки ВМС имеют собственный процессор и соответственно флеш-память для его программ, это конечно не новость, но до сих пор это была внешняя опция, и располагалась она на отдельной платке подключаемой к материнской плате – хочешь ставь, - хочешь не ставь. Сейчас же Intel все это внедрила в южный мост, более того подключила этот блок к системной шине, более того не стала использовать выделенный сетевой канал (как предусмотрено стандартом IPMI описывающем функции блока ВМС) для работы сервисной сети, а туннелировала весь сервисный сетевой трафик в основные сетевые адаптеры.

Читаю документацию далее,- оказывается, программы на флеш-микросхеме блока ВМС зашифрованы, и для их распаковки используется специальный аппаратный криптографический модуль, также интегрированный в южный мост. Такого в блоках ВМС я ранее не встречал, чтобы не быть голословным привожу выдержку из документации фирмы Intel на это южный мост:

The features of the Intel® 631xESB/632xESB I/O Controller Hub’s internal BMC

include:

• ARC4 processor working at 62.5 MHz speed

• 16Kbyte I-Cache and 16Kbyte D-Cache support for expansion bus accesses

• 256 Kbytes of internal SRAM with dual port (one for code accesses and one for all

other accesses) – zero wait states.

• 192 Kbytes ROM including, pass through, ASF, IDE redirection and COM redirection

code – zero wait states.

• Interface to both LAN ports of Intel® 631xESB/632xESB I/O Controller Hub

allowing direct connection to the net and access to all LAN registers.

• An expansion bus, allowing connection to:

— External Flash PROM. Up to 16 Mbytes as code memory over the Expansion

Bus

— External SRAM up to 32 Mbytes over the Expansion Bus.

— External SDRAM 16Mbyte or 32 Mbytes (256 Mbits) over the Expansion Bus.

• Support for PLD in expansion bus that implements a Flash I/F.

• Cryptographic module, supporting AES and RC4 encryption algorithms and SHA1

and MD5 authentication algorithms.

• 3 KCS functions, two of can be controlled by the BIOS, and residing on LPC bus, the

3rd implemented over PCI Express function (KCS is an interface between host

software and BMC for more details see the IPMI specification).

• BT (Block transfer) function over PCI Express (BT is an interface between software

and BMC in IPMI specification, see the IPMI specification).

• IDE function over PCI Express for IDE redirection.

• USB Rev1.1 function over PCI Express for USB re-direction implementing UHCI

interface.

• RS232 UART

• Eight General Propose input/output pins (GPIO).

• Fan controller pins (tradeoff with GPIO) support for Fan control and tachometer.

• Host memory DMA access – can be used for IDE redirection, USB redirection or any

other purpose.

• Three SMBus and two FML/SMBus ports.

• Connection of the COM redirection to LPC also

• ARC debugging interface by way of JTAG.

• Flexible filters for LAN. 8 VLAN filters.

• SOL function either trough PCI_E or LPC (mutually exclusive).

• Generation of NMI/SMI by way of SERIRQ.

• Timers for periodic interrupts, real time clock and watchdog mechanisms

• IPMI/KCS interface (SMS)

• KTFC redirect

• Full BMC implementation, meaning a standalone microcontroller with independent

I/Os and memory (detail descriptions in Section 5.5)

• Secured mechanism for loadable Regulated FW

• 3 KCS ports, one in PCI space, 2 in LPC bus

• KT function made accessible from LPC bus

• USB redirection module, implemented with UHCI standard, residing on PCI Express

as device 5

• BT module, residing on PCI Express as device 7

Я, человек далекий (на тот момент) от темы информационной безопасности и то знал, что применение иностранных криптографических средств с длиной ключа более 40бит ЗАПРЕЩЕНО на территории России законодательно, а тут – пожалуйста - в каждом сервере Intel криптомодуль с неизвестными ключами длиной 256бит - прямое нарушение законодательства… Более того, этим неизвестным ключом зашифрованы программы, зашитые в микросхемах материнской платы на этапе производства.

Захотелось разобраться с законами, поскольку тут я полный профан, то полез в Интернет и вижу :

1. Использование на территории России средств криптографии и установок, содержащих в своем составе такие средства, возможен только на основании лицензии (Указ Президента Российской Федерации от 3 апреля 1995 г.).

2. Выдача лицензий возможна только для криптографических средств использующих Российские алгоритмы (постановление Правительства № 608, Система сертификации СКЗИ РОСС. RU. 0001.03000. пункт 3.2.4.).

3. Все иные криптографические средства согласно Положению о порядке ввоза на таможенную территорию, не имеющие Российского сертификата, должны ввозиться в отключенном производителем состоянии.

Выходит, что блоки ВМС в России на серверах Intel, имеющих в своем составе чипсет 5000х, должны быть отключены. Но это «курам на смех», эти блоки не только не отключены, но наоборот, всегда работоспособны, даже если сама вычислительная установка выключена (для функционирования ВМС достаточно подачи дежурного напряжения, т.е. вставленной в сеть шнура питания сервера).

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

После ознакомления с документацией я насторожился, а обнаружив, что работоспособность Гипердрайвера восстанавливается после перепрошивки флеш-микросхемы блока ВМС даже не удивился.

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

Сумма фактов настораживала и наводила на параноидальные мысли в стиле шпионских детективов. А факты однозначно говорили о следующем:

В новых серийных серверных платах Intel на чипсете 5000 имелись программы, прошитые в Флеш-памяти блока ВМС и исполняемые на центральном процессоре, причем эти программы работали с использованием аппаратуры виртуализации центрального процессора.

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

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

Я сообщил руководству Крафтвей об обнаруженных чудесах в прошивках флеш-памяти блока ВМС и сомнительной с точки зрения законодательства ситуации с новыми чипсетами Intel, на что получил вполне ожидаемый ответ в стиле «не мути»,- мешаешь бизнесу, и на этом пришлось угомонился, поскольку против работодателей особо не попрешь.

Руки были связаны, но, «мысли – мои скакуны» не давали покоя, было непонятно, зачем все эти сложности. Кроме того, был профессиональный интерес – как это сделано.

Если ты имеешь возможность разместить собственное ПО на процессоре блока ВМС, зачем тебе все эти сложности с центральным процессором? Разумной причиной могло быть только одно, решаемая задача требовала контролировать текущий вычислительный контекст на центральном процессоре. Очевидно, что уследить за обрабатываемой информацией на основной вычислительной системе, используя только периферийный низкоскоростной процессор с частотой 60мГц невозможно.

Таким образом, похоже, задача этой нелегальной системы – съем информации обрабатываемой на основной вычислительной установке, это обеспечивалось средствами аппаратуры виртуализации. Дистанционное управление всей нелегальной системой конечно логично было выполнять на процессоре блока ВМС, поскольку он имел собственный независимый доступ к сетевым адаптерам размещенным на материнской плате, имел собственные МАС и IP адреса.

Второй вопрос «как это сделано?» имел более академический характер, поскольку кто-то умудрился создать Гипервизор который умел разделять ресурсы аппаратуры виртуализации с другим Гипервизором и делал это корректно для всех режимов, кроме реального режима работы ЦП. Сейчас такими системами уже никого не удивишь, но тогда, пять лет назад, это воспринималось как чудо, кроме того скорость эмуляции вводила в ступор,- программно эмулировать Хост без значительных и видимых потерь быстродействия невозможно…

Для пояснения придется углубиться немного в теорию.

В архитектурах систем виртуализации Intel и AMD не предполагается наличие на платформе нескольких Гипервизоров одновременно, но возможна другая ситуация, когда запущенный первым Гипервизор эмулирует для последующих Гипервизоров работу на реальном оборудовании виртуализации. В этом случае все далее запущенные Гипервизоры работают в эмулируемой среде Хоста, такую ситуацию я называю «правом первой ночи».

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

Режим эмуляции организовать не сложно, только возникает маленькая проблема -быстродействие такой эмуляции. Основной структурой, с которой работает аппаратура виртуализации, является VMCB (VMCS) блок, к нему происходит множество обращений во время работы программ Хоста, каждое такое обращение требует выхода в корневой Хост, а это потери на уровне 0,4-0,7 микросекунд на каждый выход. Скрыть такую программную эмуляцию хоста для системы виртуализации Intel практически невозможно, слишком много команд виртуализации придется не выполнять на реальном оборудовании, а эмулировать программно через выходы в корневой Хост.

Немного о различиях архитектур виртуализации. Системы аппаратной виртуализации от Intel и AMD абсолютно не похожи друг на друга, конечно общая концепция схожа, но конкретные реализации совершенно разные.

Главное архитектурное отличие этих систем в режиме работы хоста, Хост в системе AMD работает с отключенной аппаратурой виртуализации, т.е. его программы выполняются на реальном процессоре.

Вот как это можно изобразить схематически:

Виртуализация вторичного Хоста в системах от AMD требует виртуализации единственно команды VMRUN (других команд попросту нет, за малым и специфическим исключением). С управляющим VMCB блоком в архитектуре AMD работа происходит через обычные команды обращения к оперативной памяти, это позволяет контролировать только выполнение команд VMRUN вторичным Хостом и, если надо, то перед реальным входом в режим задачи подправить VMCB блок. Удлинение цикла обработки события в два раза еще терпимо, и на платформе AMD такая эмуляция жизнеспособна.

В системе виртуализации Intel все гораздо сложнее, для доступа к VMCB блоку используются специальные команды VMREAD, VMLOAD, которые нужно обязательно виртуализировать. Обычно обработчики Хоста десятки, если не сотни раз обращаются к полям VMCB блока, и каждый раз эти операции нужно эмулировать – пробовал, скорость падает на порядок, это заметно и неэффективно. Стало ясно, что для эмуляции неизвестные коллеги использовали другой, более эффективный механизм. Какой – похоже, некоторые подсказки содержала документация на систему виртуализации Intel.

Хост у Intel сам является виртуальной средой, такой же по сути, как среда выполнения задачи, просто они управляются разными VMСB контрольными блоками.

Схематически это выглядит приблизительно так:

Кроме того, в документации описана концепция «дуального монитора», для случая виртуализации SMM режима (режима Системного Менеджмента), когда фактически активны сразу два хоста и следовательно два VMСB блока, причем Хост режима Системного Менеджмента контролирует основной Хост как Задачу, но только в точках вызова прерываний Системного менеджмента.

Эта сумма косвенных фактов говорит о гипотетической возможности наличия в аппаратуре виртуализации Intel механизма контроля множественных вторичных Хостов, управляемых корневым Хостом. Прямого описания этого механизма, конечно, нет, но он вполне возможен в архитектуре Intel. Кроме того, у меня на руках была система, которая именно так и работала, другого объяснения практически незаметной работы корневого гипервизора у меня и до сих пор нет.

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

Недокументированные возможности в ЦП это отдельная тема, о ней мало говорят, но иногда происходят утечки в публичный доступ, примером такой утечки может служить недавняя история с недокументированными возможностями блока трассировки процессоров AMD. Ни с того ни с сего (типа случайно наткнулись) выяснилось, что функции брекпоинтов можно было существенно расширить, предварительно записав нужные значения в нужные MSR, да еще при этом при выполнении команд обращения к этим MSR нужно указать в регистре EDI конкретный ключ доступа.

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

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

Находясь все оставшееся время работы в Крафтвее (примерно полгода) в роли пассивного наблюдателя, я тем не менее регулярно запускал свою систему на новых серийных партиях материнских плат из Китая и новых семплах. На семплах все продолжало стабильно работать. На платах из Китая продолжались чудеса, но все новые и новые. Было похоже, что коллеги из-за рубежа активно улучшали работу своего корневого Гипервизора. В последних подозрительных партиях, которые я наблюдал, ситуация практически нормализовалась, т.е. первый запуск моего Гипердрайвера приводил к перезагрузке системы во время старта ОС, но все последующие запуски Гипердрайвера и затем запуски ОС проходили без «сучка и задоринки». Наконец случилось давно ожидаемое,- пришла новая партия серийных материнских плат, где вообще зависаний моего Гипердрайвера не было. Я уже начал сомневаться в своих «параноидальных» предположениях, но новый случай опять меня укрепил в подозрениях.

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

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

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

Удивлению не было предела,- первая мысль, что-то «накосячил» с серийной платой, поскольку ну никакого отношения новые выходы в Хост к материнской плате не имели, это чисто процессорная функция. Перепроверяю себя, переставляя семпловый процессор на серийную плату и, все опять перестает работать. Значит ничего я не «накосячил», каким-то образом на работоспособность новых возможностей аппаратуры виртуализации процессора влияет материнская плата.

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

Уже зная как бороться с этой напастью, я заливаю прошивку для блока ВМС с сайта Intel на серийную плату, включаюсь уверенный, что сразу все заработает, и снова «выпадаю в осадок»,- зависания остались. Это уже новая вводная, раньше я с таким не сталкивался.

Если придерживаться моей теории, то нелегальный Гипервизор обнаглел, до такой степени, что уже был уверен в своей неуязвимости. Видимо его авторы посчитали, что этап обкатки их детище прошло, и механизм маскировки неотлаженного ПО под сбой БИОС больше не нужен.

Была включена функция защиты кода инициализации от перезаписи во флеш-памяти и закладка стала практически неудалимой.

Уверенности в своей правоте не было, нужны были контрольные эксперименты, тогда в 2007 году все было вновь, все было неопознано и неизведанно в теме аппаратной виртуализации. Пришлось изобретать собственный метод детектирования наличия аппаратного Гипервизора, правда в последующем оказалось, что был изобретен велосипед, но честно говорю, не претендуя на первенство, что метод придумал сам, хотя сейчас и кажется что это очевидное решение.

Данный метод контроля наличия Гипервизора сейчас широко известен, контролируется время выполнения системных команд, выполнение которых под управление аппаратной виртуализации требует обязательной эмуляции в Хосте Гипервизора. Для контроля времени выполнения такой команды используется какой-либо таймер, желательно независимый и неожиданный для того, чтобы его значения не подкручивал Хост (это он умеет делать даже автоматически для системного таймера).

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

Время выполнения на этом скриншоте,- это некоторое условное значение, приблизительно соответствующее такту процессора.

Затем тот же тест запустил на серийной материнской плате и понял что мои предположения, как бы они не выглядели «параноидально» полностью верны, циклы выполнения команд существенно удлинились. Вот фотография экрана с результатами теста на этой плате.

Таким образом, по крайней мере, себя я убедил,- в флеш-памяти блока ВМС серверных плат из Китая выпускаемых под лейблом Intel имеется установленный на этапе производства недекларированный программный модуль, работающий как хост Гипервизора.

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

Работа в Крафтвее к этому времени завершилась и я начал новый проект в фирме связанной с системами информационной безопасности.

Руководитель этой фирмы, с которым я поделился своими «открытиями» принял мои слова и демонстрацию результатов тестов всерьез. Было решено выйти с этой темой на руководство Центра Защиты Информации и СпецСвязи ФСБ. Эта структура в составе ФСБ , является главным защитником информационной безопасности страны, регулирует деятельность остальных государственных и коммерческих организаций занимающихся защитой информации. Она также регламентирует меры по защите информации для ГосСтруктур и коммерческих фирм, обрабатывающих секретную и конфиденциальную информацию.

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

Встреча состоялась, я рассказал и показал все что удалось выяснить, затем продемонстрировал наличие нелегального программного модуля на примерах плат из Канады и Китая. Кстати в первый раз услышал и профессиональный термин обозначающий такие модули: - «Закладка». Когда разговор зашел про ВМС в глазах у коллег из Центра появилось непонимание. Пришлось проводить некий ликбез. По ходу выяснилось, что они даже не подозревали о существовании специального микропроцессора в южном мосте с выходом на сетевой адаптер и наличии в блоке ВМС же криптографического модуля нарушающего Российское законодательство.

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

Дальнейшие расспросы ни к чему не привели, все упиралось в секретность, типа мы умные и суперграмотные, но вам об этом знать не положено… И именно в их технической грамотности я засомневался, поскольку большую часть того, что я рассказывал и показывал они просто не поняли. Расстались на том, что они доложат своему начальству, а уж он примет решение о дальнейших шагах.

Чуть позже, я узнал этот «секретный метод» обнаружения программ Хоста. Совершенно случайно, во время переговоров на фирме-лицензиате Центра (уполномоченной проводить проверки БИОС на наличие в нем закладок). Технические специалисты этой фирмы, проводящие исследования БИОС рассказали, что программные модули БИОС использующие аппаратуру виртуализации ищутся по сигнатурам команд виртуализации.

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

Не являясь специалистом в области информационной безопасности, всегда думал, что в этой сфере работают люди досконально разбирающиеся в аппаратуре, программировании и сетевых технологиях, оказалось что я ошибался. Более «дремучей» в плане компьютерной грамотности публики, нежели в среде так называемых специалистов по ИБ я не встречал, не знаю, как и от чего эта публика может нас защитить, наверно только от еще менее грамотных Хакеров, которых в последнее время развелось на всяких там эксплойтах великое множество.

Результат первой встречи оставил неприятный осадок, поэтому я ожидал продолжения с мрачными настроением. Продолжение последовало приблизительно через месяц-полтора, нас пригласили уже в сам Центр Защиты Информации и СпецСвязи для доклада и демонстрации обнаруженной нами закладки.

Аудитория собравшаяся нас послушать состояла на этот раз не из рядовых сотрудников, во встрече приняли участие руководители и ведущие специалисты (так они по крайней мере представились). Встреча превратилась в лекцию, меня внимательно слушали, практически три часа, было видно, то что я им рассказываю и показываю для них абсолютно новая информация. Рассказал им о новых уязвимостях платформы х86, показал закладку, показал, как ее детектировать, было много вопросов,- ответил и на вопросы. В конце нас поблагодарили, сказали, что тему нужно развивать в рамках специальных НИР, на этом и расстались.

Первоначальная эйфория улетучилась когда по неофициальным каналам до нас дошла информация, что нам не захотели поверить, и на пальцах объяснили неразумным, почему…, это не охлаждало мое желание все-таки доказать свою правоту, а только разжигало во мне «баранью» упертость.

Как мне тогда казалось, решение лежало на поверхности: - самому написать такой программный модуль закладки. Во флеш-память ВМС мне закладку не поместить, но в основной БИОС гипервизор запихнуть смогу. Оснащу его модулем собственной безопасности для маскировки присутствия в памяти и на флеш-микросхеме, заблокирую запись в сектора флеш-микросхемы где будет размещен код закладки, что сделает его абсолютно неудалимым без выпаивания БИОС и перепрограммировании на внешнем программатора.

Оставалось только определиться в «зловредной» функцией, которую следовало ему выполнять, опять задумался. Вспомнилось утверждение одного из специалистов Центра Защиты Информации и СпецСвязи ФСБ о том, что им не страшны закладки, поскольку их системы отключены от глобальной сети. Но информация как-то должна попадать в эти защищенные локальные сети из внешнего мира, хотя бы через одноразовые оптические диски. Решение стало очевидным,- будем в закладке средствами Гипердрайвера анализировать входящий информационный поток, и реализуем так сказать оружие «судного дня», когда закладка используется только для уничтожения вычислительной системы по внешней команде. А команду будем передавать через входной информационный поток, стеганографически, благо эти методы хорошо разработаны, у всех наслуху.

Просканировать информационный поток скрытно, без потери быстродействия, это как раз задача, которая «по зубам» только аппаратуре виртуализации. В какой точке сканировать тоже понятно, на буферах ввода/вывода дисковых систем и сетевого адаптера, для аппаратуры виртуализации сканирование буферов ввода\вывода плевая задача.

Сказано,- сделано, такой Гипердрайвер был прописан в БИОС материнской платы, имел размер около 20Кбайт, был оснащен функцией защиты от обнаружения, блокировал попытки его перезаписи при обновлении БИОС и выполнял единственную функцию,- обнулял флеш-микросхему БИОС при поступлении команды на уничтожение.

Сама команда для простоты реализации была зашита в текстовом файле формата DOC в тегах настойки, не отображаемых на экране.

Когда все было готово, руководство фирмы опять вышло на Центр Защиты Информации и СпецСвязи ФСБ с предложением посмотреть работу нашей собственной закладки и убедиться в реальности угроз со стороны технологии виртуализации.

Но слушать и смотреть в деле на работу нашей закладки Центр не захотел, с самого верха (так и не узнал с какого) поступила команда с нами больше не общаться, не мутить их тихую заводь с устоявшимися бизнес партнерами и незыблемым авторитетом.

Не захотели слушать нас главные борцы за информационную безопасность. Тогда уже практически ни на что не надеясь, фактически для отчистки совести, попытались встревожить и озаботить потребителей систем информационной безопасности. Были активированы контакты с ГазПромом с целью показать им уровень и потенциал современных угроз для их распределенных систем управления технологическими процессами. Удалось организовать встречу с руководством «Службы корпоративной защиты» и «Управления комплексных систем безопасности» этой уважаемой естественной монополии. Специально для них была подготовлена новая версия закладки с упрощенным командным интерфейсом для лучшей наглядности. Для активации закладки следовало загрузить на компьютер текстовый файл с встречающимися в тексте двумя словами «Газпром» и «стоп», было неважно, как они расположены, лишь бы были в одном файле.

После этого компьютер умирал, но не сразу, была сделана задержка в 5 минут, естественно можно было сделать задержку и на сутки, но тогда бы не уложились во время отведенное для д