Уязвимости BIOS

Введение

Уязвимость – недостаток в компьютерной системе, использование которого, приводить к нарушению целостности системы и некорректной работе. Уязвимости появляются в результате ошибок программирования, недостатков, которые допускались при проектировании системы, ненадежных паролей и вредоносных программ. Уязвимости имеются во всех основных операционных системах, включая Microsoft Windows, Mac OS, UNIX и OpenVMS [7].

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

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

• методы и средства организационно-правовой защиты инфор­мации;
• методы и средства инженерно-технической защиты информации;
• криптографические методы и средства защиты информации;
• программно-аппаратные методы и средства защиты информации.

Что такое BIOS. Основные понятия.

Процесс загрузки компьютера и состав компонентов, задей­ствованных в этом процессе, определяется архитектурой системы. Применительно к большинству компьютеров загрузку можно представить в виде совокупности этапов, показанных на рисунке 1. [6]

Рисунок 1. Последовательность загрузки компьютера

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

Основное назначение BIOS состоит в:

• обеспечении инициализации и тестирования на низком уровне аппаратных компонентов компьютера, включая центральный процессор, динамическую оперативную память и др.;
• передаче управления загрузчику операционной системы (ОС).

Все начальные загрузчики операционных систем обращаются к базовой системе ввода-вывода (BIOS) с тем, чтобы провести первоначальную инициализацию установленного оборудования и контрольное тестирование его работоспособности, а также получить сведения о том, каким образом выполнять дальнейшую загрузку ОС. Поскольку BIOS - это самый нижний уровень программного обеспечения, предназначенного для конфигурирования и управления оборудованием компьютера, в нем содержится код для взаимодействия со средствами ввода-вывода, дисковыми накопителями, коммуника­ционными портами и другими устройствами, что с точки зрения информационной безопасности можно рассматривать как серьезную уязвимость системы [5].

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

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

1. Средства доверенной загрузки BIOS

BIOS выступает одним из ключевых элементов в создании надежно защищенного ПК. Важным для обеспечения информационной безопас­ности системы является сохранение целостности BIOS и компонентов, загружаемых после BIOS. Необходимо обеспечить доверенную загрузку ОС, в рамках которой, помимо сохранения целостности ОС, выполня­ются, как правило, процедуры контроля устройств, с которых загружается ОС, а также процедуры идентификации и аутентификации пользователя [6].

Вредоносное программное обеспечение, внедренное в микро­программу, имеет прямой доступ к аппаратному обеспечению и может использовать технологию виртуализации для компрометации системы без ведома пользователя и незаметно для операционной системы. Кроме того, известны атаки, направленные на внедрение вредоносного ПО в чип системной платы, что в случае успеха означает невозможность устранения последствий даже после переустановки операционной системы или замены жесткого диска [1].

Технология доверительной загрузки призвана решить эту проблему путем запуска ОС только после проведения ряда контрольных процедур: авторизации пользователя для разграничения прав на модификацию системы; проверки целостности технических и программных средств защищаемого компьютера, в том числе исполняемых файлов и фай­лов настроек безопасности; предотвращения загрузки ОС с внешних устройств посредством их физического отключения до завершения процедур авторизации и контроля. Как предполагается, данная процедура будет гарантировать, что проведена санкционированная загрузка ОС и компьютер работает в штатном защищенном режиме.

В соответствии с требованием УПД.17 приказов ФСТЭК России № 17 от 11.02.2013 г., № 21 от 18.02.2013 г. и № 31 от 14.03.2014 г., доверенная загрузка должна обеспечивать:

• блокирование попыток несанкционированной загрузки нештат­ной операционной системы (среды) или недоступность информационных ресурсов для чтения или модификации в случае загрузки нештатной операционной системы;
• контроль доступа пользователей к процессу загрузки операцион­ной системы;
• контроль целостности программного обеспечения и аппаратных компонентов средств вычислительной техники.

В соответствии с Информационным сообщением ФСТЭК России № 240/24405 от 06.02.2014 г. «Об утверждении Требований к средствам доверенной загрузки», а также собственно Приказом ФСТЭК России № 119 от 27.09.2013 г., рассматриваемый класс средств защиты инфор­мации подразделяется на три типа [1]:

1.1. Средства доверенной загрузки уровня базовой системы ввода-вывода

Первая группа средств - уровня BIOS - это, как правило, многокомпонентные программные средства, один из модулей которых встраивается непосредственно в микропрограмму материнской платы. Примерами таких средств доверенной загрузки являются «МДЗ-Эшелон» компании НПО «Эшелон» и Altell Trust производства компании Altell. Для функционирования таких средств не требуется установка плат PCI/PCI-E, что существенно упрощает и ускоряет ввод СЗИ в эксплуатацию.

1.2. Средства доверенной загрузки уровня платы расширения

Средства доверенной загрузки уровня платы расширения всегда программно-аппаратные. Это самый широкий сегмент рынка средств доверенной загрузки. В качестве примера можно привести ПАК «Соболь» компании «Код Безопасности», Максим-М1 НПО «РусБИТех», АПМДЗ «Щит-ЭЦП» Концерна «Системпром» и др.

1.3. Средства доверенной загрузки уровня загрузочной записи

Наконец, механизм функционирования средств доверенной загрузки уровня загрузочной записи основан на модификации boot-секторов логических разделов жестких дисков. Содержимое загрузочных секторов шифруются, что позволяет скрыть информацию о логических разделах при несанкционированной загрузке компьютера. Примером может служить Trusted Boot Loader компании «Код Безопасности».

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

СДЗ является элементом системы защиты информации и приме­няется на компьютере совместно с другими средствами защиты информации от несанкционированного доступа.

На протяжении многих лет и до настоящего времени СДЗ разрабатывались и совершенствовались в условиях использования совместно с «традиционными» BIOS. Это обстоятельство определяло их архитектуру и принципы функционирования. В частности, при использовании «традиционного» BIOS обоснованной является реали­зация принципа, согласно которому СДЗ начинает свою работу после выполнения системного BIOS и далее обеспечивает выполнение заданного набора требований доверия безопасности; при этом прини­мается, что код самого BIOS механизмами СДЗ проверять не нужно, поскольку, атаки, связанные с подменой системного BIOS на практике по сути не реализуются. Но в том случае, если угроза подмены системного BIOS при использовании в информационной системе некоей организации все же признается актуальной, следует в установленном порядке проверить микропрограмму BIOS на наличие уязвимостей, позволяющих осуществить такую подмену. Данная проверка практически реализуема, поскольку общая архитектура и принципы функционирования «традиционного» BIOS хорошо известны, объем микропрограммного кода и набор функций весьма ограничен, а на выработку подходов к проведению различных исследований в распо­ряжении сообщества специалистов имелся не один десяток лет [6].

Блокирование уязвимостей BIOS составляет актуальную задачу, поскольку, очевидно, для потенциального нарушителя всегда пред­почтительнее скомпрометировать тот компонент, который загружается раньше прочих — получение контроля на более раннем этапе позволяет распространить влияние и на последующие элементы, такие как код режима управления системой (System Management Mode, SMM), загрузчик, гипервизор, ОС.

Если успешные атаки на программы, исполняемые в пользова­тельском режиме, позволяют нарушителю добиться преимуществ хотя и очень существенных, но всё-таки ограниченных областью действия атакованной программы, то вредоносный код, записанный в BIOS, может позволить получить полный контроль над системой [8].

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

• атаки на BIOS, заключающиеся в подмене исходного кода BIOS вредоносным кодом BIOS, внедренным нарушителем;
• атаки на загрузчик, заключающиеся в установке подконтроль­ного нарушителю так называемого «буткита» (bootkit, разновидность «руткита» (rootkit), который исполняется в режиме ядра), «инфици­рующего» загрузчик. При этом «буткит» может использоваться для организации утечки чувствительной информации, обрабатываемой в процессе загрузки, такой как пароли шифрования информации на жестком диске.

Атаки на BIOS, заключающиеся в подмене исходного кода BIOS вредоносным кодом BIOS

Подмена микропрограммы BIOS вредоносным программным обеспечением в общем случае представляет опасную угрозу, которая может быть частью сложной атаки на информационную систему органи­зации, направленной на достижение длительного отказа в обслуживании (если BIOS в результате атаки подвергается разрушению) или обеспе­чение долгосрочного функционирования вредоносного кода в составе системы (если в результате атаки производится «инфицирование» BIOS) [6].

Однако что касается практической стороны вопроса, следует отметить, что атаки на так называемый «традиционный» BIOS (Legacy BIOS), как правило, связаны с низким уровнем мотивации нарушителя к их реализации — в силу слабого уровня стандартизации «тради­ционного» BIOS. Попытка разработать и внедрить вредоносный код, который мог бы использовать одновременно уязвимости, например, систем HP, Dell и IBM, обычно рассматривается нарушителем как неэффективная, потому что эти системы работают по-разному и реализовать универсальный механизм атаки весьма затруднительно. Иными словами, «эксплойты» для «традиционных» BIOS отличаются высоким уровнем зависимости от системы — как от версии BIOS, так и частного случая реализации аппаратных компонентов, таких как чипсет материнской платы.

Атаки на загрузчик, заключающиеся в установке подконтрольного нарушителю так называемого «буткита»

Подавляющая часть существующего вредоносного кода испол­няется на уровне ядра ОС и более высоких уровнях, так, чтобы существовала возможность использовать его на максимально широком множестве систем. В силу указанного обстоятельства известны лишь немногие практические реализации атак на уровне «традиционного» BIOS. В качестве характерного примера можно привести лишь вирус «Чернобыль», обнаруженный в 1998 году. Для современных компью­теров этот вирус неактуален, поскольку они не содержат уязвимостей, которые «Чернобылем» использовались [6].

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

В 2006 году появился прототип руткита под названием IceLord, производивший заражение BIOS корректно, т.е. после его внедрения работоспособность оборудования сохранялась [1].

В 2011 году стало известно о рабочем рутките Mebromi, способном модифицировать BIOS. Mebromi имеет механизмы сокрытия от тради­ционных антивирусов, и избавиться от него невозможно даже после замены жесткого диска. Согласно отчетам компании ESET по угрозам и трендам, буткиты стали одним из ключевых технических трендов 2012 года.

Буткит имеет общее с загрузочным вирусом, однако содержит компоненты, которые внедряются в операционную систему еще до ее загрузки. На начальном этапе своей работы буткит заменяет ориги­нальный загрузчик и ожидает перезагрузки компьютера. Основная задача буткита – перехватит прерывание INT 13h, при помощи которого файловые компоненты операционной системы считываются с диска в память, чтобы подменить файлы операционной системы на свои ком­поненты. Таким образом, буткит может оставаться незамеченным для любой прикладной системы, запущенной в модифицированной им ОС.

2. UEFI BIOS

Между тем, интенсивно осуществляемый в настоящее время пере­ход от реализации «традиционного» BIOS к реализации, основанной на едином расширяемом микропрограммном интерфейсе (Unified Extensible Firmware Interface, UEFI), наряду с получением ряда функциональных преимуществ, в контексте обеспечения информационной безопасности характеризуется снижением для нарушителя сложности задачи внедрения вредоносного кода на уровне BIOS.

Современная базовая система ввода-вывода (BIOS) давно перестала быть простейшей микропрограммой, главной целью которой является инициализация и тестирование на низком уровне аппаратных компонентов компьютера для дальнейшей передачи управления загрузчику операционной системы (ОС). С момента введения единого расширяемого микропрограммного интерфейса (Unified Extensible Firmware Interface, UEFI) BIOS приобретает черты упрощенной современ­ной операционной системы со своими фазами загрузки и механизмами обеспечения безопасности, включая реализацию различных крипто­графических функций [9].

Кроме всего прочего, спецификация UEFI определяет возможность загрузки компьютера по сети с помощью протокола удаленной загрузки (preboot execution Environment, PXE) и доступа к загрузочным образам, хранящимся в сетях хранения данных (storage area network, SAN).

Процесс загрузки компьютера, использующего UEFI, формально представляется таким же, как и в случае с «традиционным» BIOS. Разница заключается в том, что код UEFI запускается, как правило, в современном 64-битном защищенном режиме работы процессора, тогда как код микропрограммы BIOS исполняется в 16-битном реальном режиме работы процессора. Однако в отличие от фактически неизменной по своему функциональному содержимому микропрограммы BIOS, система UEFI в сущности представляет собой программируемый интерфейс с довольно широким набором возможностей, совокупность которых придает ему черты самостоятельной операционной системы, пусть и облегченной. Основанием для подобной характеристики явля­ется то, что спецификация UEFI определяет, в частности, следующие элементы [8]:

• сервисы. В UEFI допускается два типа сервисов: загрузочные (boot services) и среды выполнения (runtime services). Первые функционируют только до загрузки ОС компьютера и обеспечивают взаимодействие с графическими и текстовыми терминалами, шинами и т. д., а сервисы среды выполнения доступны даже из ОС компьютера;
• драйверы устройств. В UEFI реализуется платформонезави­симая среда драйверов — EFI Byte Code (EBC). Взаимодействие ОС с драйверами устройств, как правило, осуществляется через EBC, что позволяет ОС компьютера использовать UEFI для базовой поддержки графических и коммуникационных функций до загрузки драйверов, установленных в ОС. Некоторые архитектурно-зависимые (non-EBC) драйверы имеют интерфейсы для использования ОС напрямую;
• приложения. Независимо от загружаемой ОС программа UEFI поддерживает возможность запуска отдельных приложений, которые могут разрабатываться и устанавливаться по усмотрению производителей компьютеров. К числу таких приложений относится, например, оболочка UEFI (UEFI shell). Оболочка может быть загружена еще до запуска ОС компьютера и использоваться для выполнения различных приложений: утилит по установке и настройке операционных систем, файловых менеджеров, утилит для просмотра файлов и др. Команды оболочки также позволяют копировать или перемещать файлы и каталоги в поддерживаемых файловых системах, загружать и выгружать драйверы. Оболочка поддерживает командную строку и командные файлы, аналогичные командам и пакетным файлам DOS.

В случае использования UEFI BIOS все его интерфейсы стандартизированы. Из этого следует то, что, в отличие от случая, когда используется «традиционный» BIOS, реализация атак на UEFI BIOS не состоит в сильной зависимости от архитектуры системы. В свою очередь, это означает, что сообщество больше не имеет права считать, что атаки на BIOS не реализуются на практике, что у нарушителя отсутствует для этого мотивация. Вследствие использования многими BIOS одного и того же кода обнаружены уязвимости, актуальные для 80% исследованных компьютеров, включая модели Dell, Lenovo и HP; при этом уязвимости было столь легко обнаружить, что удалось даже написать скрипт для автоматизации этого процесса, с помощью которого было выявлено множество уязвимостей.

Кроме того, UEFI BIOS имеет несоизмеримо более богатый набор функциональных возможностей состав которых может существенно отличаться в различных системах в зависимости от предпочтений произ­водителя. Это означает, во-первых, что проверить UEFI BIOS теми же методами, что использовались при проверке «традиционного» BIOS, не удастся, а во-вторых, усложнение и расширение его функциональ­ности неизбежно влечет за собою увеличение «площади поверхности» для проведения разнообразных атак.

На практике в информационных системах организаций процедура обновления «традиционного» BIOS представляла собой весьма редкое явление или же вообще не производилась. Очевидно, в случае с UEFI BIOS ее придется производить (локально и (или) через сеть) значительно чаще, что, в свою очередь, открывает новый класс уязвимостей для системного BIOS.

Таким образом, можно констатировать, что принципы обеспечения доверенной загрузки систем с UEFI BIOS должны принципиально отличаться от тех, что на протяжении многих лет применялись для систем на основе «традиционного» BIOS. Эти различия, по-видимому, обусловливают необходимость выработки нового подхода как для установления требований безопасности, которым должно удовлетворять соответствующее СДЗ, так и нового подхода к формированию со стороны регулятора заключения о соответствии продукта предъявленным к нему требованиям безопасности информации [8].

UEFI также позволяет расширять прошивку платформы, загружая исполняемые образы – драйверы или приложения. Исполняемые образы представляют собой класс файлов, определенных спецификацией UEFI, которые содержат исполняемый код. Загруженные образы полу­чают доступ к сервисам, которые также определены спецификацией UEFI (boot services, runtime services). Исполняемые образы могут быть загружены в память, как встроенным менеджером загрузки, так и другими исполняемыми образами. Данная возможность позволяет расширять функционал базовой системы ввода-вывода, однако, она создает новые векторы атак в случае неконтролируемого встраивания драйверов.

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

Внедрение в BIOS дает возможность распространить влияние вредоносного кода на все последующие этапы загрузки. Под угрозой оказываются код управления системой (System Management Mode, SMM), существующие средства защиты, загрузчики, гипервизор и операционная система (ОС). Учитывая, что BIOS запускается с высоким уровнем привилегий на одном из первых этапов загрузки ЭВМ, вредоносный код, исполняемый на уровне BIOS, очень сложно детекти­ровать и устранить на последующих этапах. Для понимания способов инъекций вредоносного кода в UEFI и защиты от них, необходимо ознакомиться со всеми фазами загрузки и возможностями инъекции кода в каждую из них [10].

Согласно спецификации UEFI система проходит следующие этапы загрузки:

• Security (Sec)
• Pre EFI Initialization (PEI)
• Driver Execution Environment (DXE)
• Boot Dev Select (BDS)

Внедрение в фазу Security невозможно из-за проприетарности (частное ПО с закрытым кодом) данной стадии. В данной фазе подготавливается временная память, адрес и размер которой передаются в фазу PEI. Помимо этого в фазу PEI передается адрес и размер стека, состояние платформы, адрес и размер BFV (Boot Firmware Volume) [10].

Основной функциональной возможностью UEFI стал механизм SecureBoot, осуществляющий проверку загружаемых компонентов ОС криптографическими методами – при помощи механизма цифровой под­писи, закрытый ключ которой прошивается в чипы системных плат [10].

В фазе PEI инициализируется RAM для запуска фазы DXE. В фазу DXE передается информация об обнаруженных устройствах для корректной инициализации каждого из устройств. Фаза PEI состоит из ядра и модулей PEIM, осуществляющих первичную инициализацию устройств. Список PEIM может быть расширен путем добавления собственных модулей. Ядро PEI обходит все тома прошивки в поиске всех PEI модулей и запускает их. Порядок запуска модулей не случаен и определяется диспетчером PEI. Модули могут иметь зависимости от других модулей, поэтому сперва запускаются модули, не имеющие зависимостей, затем модули, зависящие от них по цепочке [10].

Код DXE состоит из ядра (DXE Core), диспетчера и драйверов. Ядро инициализирует и запускает службы UEFI. Диспетчер осуществляет поиск всех DXE-драйверов и передачу управления каждому из них. Данные драйверы могут содержать зависимости от других компонентов. Каждый DXE-модуль может осуществлять загрузку и запуск испол­няемых образов, одним из которых может выступать загрузчик ОС. После исполнения драйверов осуществляется поиск загрузчика ОС [10].

Таким образом, инъекция драйвера как в фазу PEI, так и в DXE может нарушить процесс загрузки ОС, запустив исполняемый образ в UEFI. Рассмотрим практический способ влияния на процесс загрузки на примере инъекции вредоносного DXE-драйвера с использованием утилиты UEFI Tool и программатора. UEFI Tool позволяет считывать и редактировать бинарный файл прошивки (BFV), расширяя его испол­няемым кодом и различными данными. В качестве примера приведем сценарий встраивания и функционирования вредоносного драйвера в одной из фаз [10].

Стоит отметить, что такой драйвер может иметь как примитивный вид, так и представлять собой многофункциональный программный компонент. Для простоты понимания можно ввести допущение, что загружаемый исполняемый образ расположен в корне одной из файловых систем. Данное допущение не уменьшает значимости данного вектора атаки на BIOS, так как исполняемый образ может быть загружен в систему в режиме выполнения самим драйвером, содержащего вредоносный код. Получив список всех файловых систем, драйвер осуществит проверку наличия необходимого образа и, в случае успеха, загрузит код в память и передаст ему управление. Стоит заметить, что для поиска исполняемого образа в коде драйвера могут использоваться протоколы. Как было сказано выше, порядок получения управления различными драйверами строго не определен, а это значит, что на момент выполнения используемые протоколы могут быть еще не доступны для использования. Для обеспечения доступности используемых протоколов необходимо использовать секцию [Depex]. В данной секции указывается список протоколов, использование которых необходимо разрабаты­ваемому драйверу. Эта секция обеспечит получение драйвером управ­ления только тогда, когда системные службы или другие драйверы предоставят доступ к использованию необходимых протоколов, указанных в этой секции [10].

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

Рассмотренный способ влияния на процесс загрузки подтверждает необходимость проверки каждого из DXE-драйверов, получающих управление, так как каждый из них может содержать потенциально вредоносный код. Доверенную загрузку можно нарушить не только инъекцией DXE-драйверов, но и PEI-драйверов. Разработка драйверов PEI (как для вирусов, так и для средств защиты) сложнее, так как недоступна проинициализированная память, протоколы и системные службы. Однако, процедура инъекции PEI-драйвера в один из томов прошивки системы ничем не отличается.

Для обеспечения защиты от неконтролируемого встраивания драйверов программными средствами необходимо обеспечить гаранти­рованное получение управления средствами защиты при каждом старте ЭВМ до запуска модулей PEI и DXE и невозможность осуществить загрузку ОС в обход средств защиты.

Гарантированное получение управления до запуска модулей можно обеспечить только в случае функционирования средства защиты на уровне PEI Core или SEC. Учитывая проприетарность кода фазы SEC, внедрение компонента защиты в PEI Core представляется правильным. Невозможность осуществить загрузку ОС в обход средств защиты можно обеспечить исключительно путем сертификации BIOS и опломбирования корпуса ЭВМ. Однако, имея сертифицированный BIOS и опломбированный корпус, можно смело утверждать, что компонент безопасности, реализованный в виде DXE-драйвера, получит управление и не позволит нарушить доверенную загрузку, проведя процедуру аутентификации и контроля целостности.

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

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

Появление хорошо унифицированного UEFI упростило разработку, как легального программного обеспечения, так и вредоносного. В конце 2014 года на 31-м Всемирном конгрессе хакеров Рафаил Войчук и Кори Каленберг продемонстрировали атаку на UEFI, получившую назва­ние Speed Race, связанную с уязвимостью в реализации UEFI. Среди аппаратных платформ, имеющих уязвимость, оказались ноутбуки Dell Latitude и HP EliteBook. В июле 2015 года после скандальной утечки исходных кодов шпионского ПО, разработанного итальянской компанией Hacking Team, стало известно о первом UEFI-рутките. Сотрудники Hacking Team разработали вредоносное ПО специально для UEFI фирмы Insyde, которые очень популярны в ноутбуках, однако данное ПО успешно функционирует и на платформах с AMI BIOS. Особенность вредоносного ПО, как и руткита Mebromi, в том, что ни переустановка ОС, ни форматирование жесткого диска, ни даже его замена, не помогут избавить компьютер от его воздействия. Таким образом, мы видим, что развитие вредоносного ПО происходит достаточно динамичными темпами, поэтому технологию SecureBoot стоит рассматривать только как возможную меру из состава целого комплекса механизмов для обеспечения безопасной загрузки, но не как панацею [3].

3. Доверенная загрузка виртуальных сред

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

Обратимся к вопросу безопасности виртуальных сред и рассмотрим некоторые типовые действия злоумышленника и угрозы, к которым они ведут:

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

Таким образом, с одной стороны, гипервизор, выполняющий функ­ции монитора виртуальных машин, повышает сервисные возможности компьютера и снижает его эксплуатационные расходы. Но, с другой стороны, гипервизор можно негласно внедрить как программную закладку с бесконтрольными возможностями, несущими угрозу инфор­мационной безопасности [3].

Cуть угрозы «тонкого гипервизора», которая имеет образное название Blue Pill заключается в захвате запущенного экземпляра операционной системы (захват производится при запуске ОС) «тонким» гипервизором и виртуализацией им остальной части компьютера. Основная операционная система будет все еще поддерживать сущест­вующие в ней ссылки на все устройства и файлы, но почти все, включая аппаратные прерывания, запросы данных и даже системное время будут перехватываться гипервизором, который будет отсылать фальшивые ответы. Ввиду существования угроз виртуальной среды, подобных описанной ранее, требование доверенной загрузки в ука­занных выше приказах ФСТЭК относятся не только к физическому оборудованию, но и к среде виртуализации [3]:

• в информационной системе должна обеспечиваться доверенная загрузка серверов виртуализации, виртуальных машин (контейнеров) и серверов управления виртуализацией в соответствии с мерой защиты «Обеспечение доверенной загрузки средств вычислительной техники».
• доверенная загрузка должна обеспечивать блокирование попыток несанкционированной загрузки гипервизора, хостовой и гостевых операционных систем.
• доверенная загрузка гипервизоров обеспечивается с исполь­зованием средств доверенной загрузки, функционирующих на серверах виртуализации.
• доверенная загрузка виртуальных машин (контейнеров) обеспе­чивается с использованием многокомпонентных средств доверенной загрузки, отдельные компоненты которых функционируют в гипер­визорах.

Заключение

Многообразие вредоносного программного обеспечения, функ­ционирующего на уровне BIOS/ UEFI, свидетельствует о серьезной необходимости защиты от них. Кроме того, злоумышленник может нанести вред системе и без использования вредоносного программного обеспечения (например, загрузившись с внешнего носителя). Разрешать доступ только для авторизованных пользователей, контролировать целостность разделов и файлов, осуществлять доверенную загрузку - задача средств доверенной загрузки.

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