Что такое bios атака

Обновлено: 06.01.2025

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

Продолжая начатую тему, рассмотрим и более тяжелый случай – искажение
содержимого микросхемы BIOS. После такой атаки, материнская плата требует
ремонта, а точнее – восстановления содержимого микросхемы BIOS.

Как известно, авторы вирусов начали использовать эту уязвимость еще около 10
лет назад, практически сразу после того, как в качестве носителя BIOS стали
применяться микросхемы электрически перепрограммируемых ПЗУ (Flash ROM). В
сложившейся ситуации, минимизация угрозы стала заботой не только авторов
антивирусных программ, но и разработчиков аппаратного обеспечения, в частности,
материнских плат. Отметим, что полностью исключить опасность несанкционированной
модификации BIOS невозможно, так как для этого пришлось бы отказаться от
"законной" возможности его обновления.

В предлагаемом материале, на уровне ассемблера и программирования
конфигурационных регистров, рассматривается процесс программного доступа к
функциям микросхемы Flash ROM, а также системные ресурсы, управляющие таким
доступом и защищающие BIOS от несанкционированного искажения.

При таком глубоком исследовании, нам потребуется работать с регистрами,
которые в каждом чипсете реализованы по-разному. Разумеется, в одной статье
невозможно описать архитектуру всех чипсетов. Поэтому, для того, чтобы разговор
был предметным, остановимся на одном из вариантов: в качестве примера рассмотрим
платформу на чипсете Intel 815, детально описанном в 2, использующую
микросхему BIOS SST 49LF004A, детально описанную в [18]. Перечислим все действия
программы, выполняемые при стирании сектора и записи данных в микросхему Flash
ROM для такой платформы. Протокол доступа к микросхеме Flash ROM, описанный
ниже, используется как программами обновления BIOS, так и вредоносными
программами, цель которых – искажение или стирание содержимого микросхемы BIOS.

В приложении к статье содержатся исходные тексты программы, осуществляющей
доступ к функциям микросхемы Flash ROM.

Как это делается

1) Микросхема BIOS подключена к "южному мосту" чипсета посредством
интерфейса LPC (Low Pin Count), детально описанного в [1]. Для доступа к
содержимому BIOS на предмет чтения и записи, а также передачи управляющих команд
и контроля текущего состояния микросхемы Flash ROM, используется 16-мегабайтный
диапазон FF000000h-FFFFFFFFh в адресном пространстве памяти. Чтобы программные
обращения к указанному диапазону транслировались в физические циклы чтения и
записи на интерфейсе LPC, конфигурационные регистры "южного моста" чипсета
должны быть установлены следующим образом.

В 16-битном регистре BIOS_CNTL (его координаты в конфигурационном
пространстве Bus=0, Device=1Fh, Function=0, Register=4Eh-4Fh) бит 0 нужно
установить в "1". Это снимает блокировку циклов записи и разрешает их трансляцию
на интерфейс LPC.

2) Микросхема SST 49LF004A, используемая в качестве носителя BIOS,
имеет объем 512 Кбайт и разделена на 8 блоков по 64 Кбайт. Каждый блок имеет
свой регистр защиты записи (Block Locking Register). Например, для блока 0,
расположенного по адресам FFF80000h-FFF8FFFFh, адрес регистра Block Locking
Register равен FFB80002h. Для разрешения стирания и записи блока, бит 0 этого
регистра должен быть установлен в "0". Адреса регистров защиты записи для
каждого блока и другие подробности содержаться в [18]. Манипуляции с регистрами
микросхемы Flash ROM, расположенными в пространстве памяти, выполняются с
помощью стандартных инструкций архитектуры x86, обеспечивающих чтение и запись
ячеек памяти, например MOV. Вопросы организации регистров, отображенных на
память (Memory-mapped I/O) детально рассмотрены в ранее опубликованной статье
"Устройства системной поддержки. Исследовательская работа №
7,
8 и
9".

3) Для запуска операции стирания блока или сектора требуется выполнить
последовательность из шести циклов записи заданных байтов по заданным адресам.
Последовательности приведены в [18] а также в исходном тексте программы,
прилагаемом к статье. Использование многоцикловых последовательностей для
запуска операций стирания и записи, снижает вероятность случайного искажения
содержимого Flash в результате программного сбоя.

4) Для запуска операции записи байта требуется выполнить
последовательность из четырех циклов записи заданных байтов по заданным адресам.
Отметим, что перед выполнением записи, для сектора, в который выполняется
запись, необходимо выполнить стирание.

Об аппаратной защите BIOS и ее эффективности

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

1) Регистр BIOS_CNTL, рассмотренный выше входит в состав "южного
моста" чипсета, его бит 0 управляет блокировкой циклов записи, адресованных
микросхеме BIOS. Бит 1 того же регистра (это бит BLE, BIOS Lock Enable)
позволяет установить режим, при котором попытка снять защиту записи будет
перехватываться BIOS, а точнее, при попытке установить бит 0 в "1" будет
генерироваться прерывание SMI (System Management Interrupt) с передачей
управления специальной процедуре, входящей в состав BIOS. Причем, если BIOS при
старте установит такой режим перехвата, программно выключить его чипсет не
позволяет, этот режим будет выключен только после аппаратного сброса (по сигналу
RESET). Подробности в [3].

К сожалению, разработчики BIOS обычно не используют этот механизм,
предоставляемый чипсетом. Во всех материнских платах, исследованных автором, бит
BLE (бит 1 регистра BIOS_CNTL) установлен в "0", поэтому, попытки снятия защиты
записи не перехватываются.

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

2) Регистры защиты записи Block Locking Register, также рассмотренные
выше, входят в состав микросхемы Flash ROM SST 49LF004A. Здесь также
предусмотрен бит защиты записи (бит 0) и бит, установка которого в "1" позволяет
запретить снятие защиты записи (бит 1). Если биты 0 и 1 установлены в "1",
микросхему BIOS программно вывести из состояния защиты записи невозможно, это
произойдет только при аппаратном сбросе (по сигналу RESET). Подробности в [18].

К сожалению, и этот механизм обычно не используется разработчиками BIOS, а
ведь его применение могло бы существенно улучшить защищенность. Во всех платах,
исследованных автором, бит 1 в регистрах защиты блоков микросхем Flash ROM
установлен в "0", то есть снятие защиты записи разрешено.

3) Третий уровень защиты, состоит в том, что для запуска операций
стирания и перезаписи микросхемы BIOS, требуется своеобразный пароль, а именно,
передача многоцикловых "ключевых" последовательностей со строго определенными
адресами и данными. Так как у всех микросхем одного типа пароль одинаковый и его
можно узнать из документации на микросхему, например 4, 18, такая мера
может защитить только от случайного искажения содержимого BIOS при программном
сбое и записи беспорядочных данных. Вредоносная программа, прочитав
идентификаторы ROM Vendor ID и ROM Device ID, может распознать тип микросхемы
BIOS и сформировать требуемые ключевые последовательности в соответствии с
документацией на данную микросхему.

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

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

Источники информации

14) PCI BIOS Specification. Revision 2.1.
15) PCI Local Bus Specification. Revision 3.0.
16) PCI-to-PCI Bridge Architecture Specification. Revision 1.1.

17) 2 Megabit (256K x 8) Multi-Purpose Flash SST39SF020 Data Sheet.
18) 2 Mbit / 4 Mbit Firmware Hub SST49LF002A / SST49LF004A Data Sheet.
19) 2 Mbit LPC Flash SST49LF020 Data Sheet.
20) 1 Mbit SPI Serial Flash SST25VF010 Data Sheet.
21) 2 Mbit / 4 Mbit SPI Serial Flash SST25VF020 / SST25VF040 Data Sheet.

22) W49V002FA 256K x 8 CMOS Flash Memory with FWH Interface Data Sheet.
23) W49V002A 256K x 8 CMOS Flash Memory with LPC Interface Data Sheet.

24) MX28F1000P 1M-BIT [128K x 8] CMOS Flash Memory Data Sheet.

25) SPI EEPROM Interface Specification. Part Number 223-0017-004 Revision H.

26) SPI Interface Specification. Technical Note 15.

Книги

27) В.Л. Григорьев. Микропроцессор i486. Архитектура и программирование.
Москва ТОО “ГРАНАЛ” 1993.
28) 2B ProGroup: В.А. Вегнер, А.Ю. Крутяков, В.В. Серегин, В.А. Сидоров, А.В.
Спесивцев. Аппаратура персональных компьютеров и ее программирование. IBM PC/XT/AT
и PS/2. Москва “Радио и связь” 1995.

Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI "полумифическим". С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».
В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.

Часть нулевая. Введение

Модель угроз

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

Уровни доступа

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

Векторы атаки

Теперь определим основные векторы и последствия успешно совершенной атаки, в порядке уменьшения опасности:

1. Хранилище основной прошивки (в 95% современных систем — 1-2 микросхемы NOR-flash с интерфейсом SPI )

Суть атаки — вставляем свой код в прошивку, удаляем части имеющегося, воруем, убиваем, молчим про гусей.
Последствия атаки варьируются от получения полного контроля над прошивкой, аппаратурой и ОС в лучшем случае, до DoS в худшем. Физический атакующий может устроить DoS в любом случае (с размаху отверткой в плату — вот тебе и DoS), поэтому подробнее на DoS для атакующих первого и второго уровней останавливаться не буду.

2. Код в SMM

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

3. Хранилище прошивки PCI-устройств

Суть — вставляем свой код в прошивку какого-либо PCI-устройства (она же Option ROM), к примеру, сетевой карты или контролера Thunderbolt, UEFI выполняет этот код при инициализации устройства, . профит.
Последствия — в лучшем случае смотри пункт 1, в худшем — почти то же самое, только стартуем значительно позже, и потому некоторые вещи уже настроены и заблокированы.

4. Переменные в NVRAM

Суть — получаем возможность изменять настройки UEFI, в том числе скрытые.
Последствия — в лучшем случае можно поотключать все защиты и сразу перейти к пункту 1, в худшем — снова DoS (пишем мусор в NVRAM, перезагружаемся, смотрим, что получилось).

5. SecureBoot

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

Часть первая. Защиты от записи в хранилище основной прошивки

1. Аппаратная верификация прошивки или её части перед выполнением любого кода

2. Хранилище только для чтения с аппаратным переключателем

3. PR -регистры чипсета

Если аппаратно микросхему SPI защитить от записи не получилось, можно защитить ее силами чипсета. Все современные чипсеты имеют как минимум 4 регистра PR, предназначенных для защиты от чтения и/или записи блока физической памяти, а т.к. микросхема SPI всегда отображается на «дно» первых 4 Гб физической памяти (т.е. последний байт микросхемы SPI всегда находится по физическому адресу 0xFFFFFFFF), но можно защитить всю прошивку или ее часть.
Защита подобного рода тоже не обходится без проблем:
— ее нужно правильно реализовать, не забыв, что при перезагрузке значения регистров тоже сбрасываются, и их нужно восстанавливать.
— нужно не забыть установить (и восстановить после перезагрузки) lock на их конфигурацию, иначе вредоносный код их может банально сбросить.
— защита не может быть отключена, т.е. обновление прошивки из ОС без перезагрузки становится невозможным.
— и, конечно, NVRAM и другие RW-области защитить таким способом не получится.
В отличие от предыдущего пункта, систем с PR'ами на рынке море, и почти на всех защита реализована неграмотно или неполно.

4.1. SMM_BWP и SpiRomProtect

4.2. Intel BIOS Guard, в девичестве PFAT

5. BLE и BIOS_WE

6. Отсутствующая

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

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

Часть вторая. SMM

Немножечко ликбеза

Аппаратное SMI

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

Системные SMI

Программные SMI

Программные SMI генерируются чаще всего либо прошивкой, либо драйверами, но ничего не мешает атакующему с правами администратора в ОС (точнее, необходимы права на исполнение инструкции out) тоже генерировать их.
Программное SMI генерируется при записи в CPU IO-порт APM_CNT (чаще всего это порт 0xB2), в качестве параметра в регистре AL передается его номер. Таким образом, максимальное количество различных обработчиков программных SMI в системе — 256, но реально их от 0-5 на специализированных системах, подготовленных для работы с RTOS, до 15-20 на системах с кучей разного железа, которым надо управлять без вмешательства ОС.

Как реализован SMM

Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG (т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет. Имя сегменту досталось за то, что он находится по фиксированным физическим адресам 0xA0000 — 0xBFFFF. Вторая область с фиксированными адресами — HSEG (т.е. «высокий сегмент»), раньше находилась на 0xFEDA0000 — 0xFEDBFFFF, но на современных системах не используется, т.к. имеется гораздо более удобный сегмент с настраиваемыми адресом и размером — TSEG (т.е. «топовый сегмент»), в котором и находятся сейчас 99% кода, исполняемого в SMM, а в ASEG остается только небольшая заглушка для совместимости.
При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений.
Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история).
При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS'ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.

Атаки на SMM и защита от них

Забытый D_LOCK

Код в SMRAM не появляется там самостоятельно, сначала саму SMRAM нужно настроить, инициализировать физическую память, настроить TSEG так, чтобы все обработчики туда влезли, скопировать туда код SMM-диспетчера и обработчиков, настроить там таблицы дескрипторов — в общем, навести строгий уставной порядок, после чего обязательно снять бит D_OPEN, чтобы никто больше там ничего не испортил, и установить бит D_LOCK, чтобы D_OPEN нельзя было поставить назад. На некоторых старых системах установить D_LOCK забывали, и там SMM был отрыт всем ветрам, но во времена UEFI этого уже не происходит, так что этот вектор атаки ушел в историю.

SMM cache poisoning

Еще одна историческая атака — отравление кэша SMRAM, которую в 2009 году опубликовали Rafal Wojtczuk и Joanna Rutkowska. Суть атаки коротко — меняем тип памяти для региона SMRAM на Write-Back, организуем запись в регион SMRAM своего кода, запись в память не происходит, но при этом наш код остается в кэше второго уровня, после чего генерируем программное SMI и процессор читает данные не из SMRAM, а из кэша, и выполняет наш вредоносный код. Проблема решилась радикально — производители CPU запретили ставить режим WB на SMRAM, и потому системе с UEFI этой уязвимости не подвержены.

SMM call-out, она же SMM incursion attack

Но достаточно истории, перейдем к «современным» атакам. Начнем, пожалуй, с той самой SMM Incursion Attack, о которой тов. maseal упомянул в комментарии к первой части. Я специально поставил слово «современные» в кавычки, ибо этой атаке — сто лет в обед, впервые о ней сообщали еще в 2008 году как проблему тогдашних BIOS'ов, но в 2015 ее вновь переоткрыли Corey Kallenberg и Xeno Kovah. Атака простая как мычание — если обработчик SMI вызывает какой-либо код, находящийся вне SMRAM, то атакующий с правами на запись в физическую память может подменить вызываемый код на свой, и выполнить его таким образом в режиме SMM. А т.к. разработчики UEFI привыкли к доступности EFI Runtime-сервисов, то эти самые сервисы стабильно вызывались из обработчиков SMI на каждый чих (чаще всего это были вызовы GetVariable, SetVariable и ResetSystem). Уязвимости оказалось подвержено столько систем, что проще сказать, где их не было. По моей грубой оценке, если ваш UEFI старше мая-июня 2015 года по build date, в нем гарантированно имеется пара уязвимых к этой атаке обработчиков SMI. Вычистить систему от таких глючных обработчиков достаточно сложно, и т.к. раньше такое поведение вообще не считалось уязвимостью («какой дурак полезет сервисы хукать то?!») и о том, что так делать нельзя, не было известно простым IBV 'шным кодерам — даже сейчас периодически приходят обновления для runtime-драйверов, подверженные этой проблеме. Все очень грустно, в общем.
Для защиты от вызова внешнего по отношению к SMRAM кода инженеры Intel добавили специальный MSR_SMM_FEATURE_CONTROL, после установки определенного бита в котором вызов такого кода генерирует немаскируемое и невосстановимое MCE , но есть такой MSR только в Haswell и более новых CPU, да и включается эта возможность только на время отладки прошивки, иначе за непонятные зависания на ровном месте пользователи могут к дверям отдела R&D прийти с вилами и дубьем — большинству нужно, чтобы работало и сейчас, а эта ваша безопасность вся — overhyped. Для обладателей более старых систем и систем на базе процессоров AMD инженеры Phoenix нашли по своему гениальное решение — использовать NX-бит, настроив память для SMM-кода таким образом, чтобы вызов кода вне SMRAM заканчивался Page Fault'ом, который затем можно обработать, а не висеть намертво на MCE. Каюсь, я у себя пока еще это решение не внедрил, но когда дойдут руки — обязательно это сделаю.
Простому же пользователю от этой атаки можно защититься только не допуская исполнение непонятного кода от рута, но это, к сожалению, на современных ОС практически нереально — вариантов локального повышения прав как было море, так и остается, сколько таких 0day-эксплоитов на руках и в обороте, сказать невозможно. Остается только процитировать вышеупомянутого Xeno Kovah:

DMA attack

SMM cross-buffer attack

Представленная специалистами из Intel ATR атака на обработчики SMI, которые принимают в качестве параметра указатель и размер буфера, и производят запись в него. Атакующий может передать указатель и размер таким образом, чтобы буфер пересекал границу RAM-SMRAM, а т.к. обработчик SMI имеет доступ к SMRAM, то он перепишет какую-то часть данных вначале SMRAM. При удачном стечении обстоятельств (т.е. приблизительно после 500 часов отладки минимум) обработчик может переписать служебные структуры диспетчера SMM или других обработчиков нужным атакующему образом, и он получит возможность выполнения произвольного SMM-кода. Атака адски сложная и целевая, но вполне возможная, поэтому с начала 2015 года все обработчики SMI, принимающие указатели на буфер, обязаны валидировать его перед использованием. На более старых системах атака будет работать, но вероятность того, что именно вас через нее взломают — невелика.

Заключение

Ну вот, теперь разобрались более или менее и с SMM, в следующей части поговорим об атаках на S3 BootScript.
Спасибо за внимание, безопасных вам прошивок.

Статья основана на исследовании Андрея Малышева, руководителя европейского филиала «Элкомсофт».

Что такое TPM и почему он мешает расшифровать диск

Trusted Platform Module (TPM) — технология безопасности, представленная в виде дополнительного чипа, распаянного или установленного на материнской плате компьютера. Несмотря на то что официально устройства с TPM в Россию не поставляются, так как содержат несертифицированные средства шифрования, технология присутствует в большинстве ноутбуков. Чип TPM либо распаян на материнской плате (но не активирован в BIOS), либо, что случается гораздо чаще, присутствует в «виртуальном» виде благодаря использованию платформы Intel PTT (Intel Platform Trust Technology).

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

Если рассматривать модуль TPM в качестве аппаратного «довеска», то он состоит из криптографического процессора и встроенной памяти небольшого объема. При этом криптографический сопроцессор не используется для шифрования данных — как, например, это сделала Apple с чипом T2.

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

Разумеется, как самой операционной системе, так и ее компонентам и приложениям доступны интерфейсы для работы с TPM и ключами шифрования — что тем не менее не означает полной бесконтрольности.

Почему одни диски, зашифрованные BitLocker, можно взломать методом перебора, в то время как другие, точно такие же, нельзя? Мешает то, что пароль в таких дисках не используется вовсе, — перебирать‑то, собственно, нечего. Ключ шифрования хранится в аппаратном модуле TPM, и именно этот модуль будет решать, выдать ключ по запросу, отказать в доступе или вовсе заблокировать чип, заставив расшифровывать контейнер другим способом. (В скобках замечу, что «другой способ» — это резервный ключ, так называемый ключ восстановления доступа, он всегда сохраняется при создании тома или на диске, или в облаке Microsoft, или в Active Directory. Зашифрованный этим ключом ключ шифрования диска также сохраняется в заголовке тома BitLocker.)

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

Если хочешь — можешь почитать, где взять ключ восстановления доступа. Я же продолжу рассказ о модулях TPM.

Архитектура защиты

С точки зрения пользователя, защита, которую обеспечивает модуль TPM, не только совершенно прозрачна, но и абсолютно незаметна. Я много раз слышал о случаях, когда владелец устройства утверждал, что никакого шифрования нет, — при этом системный раздел был зашифрован BitLocker. И если порой в утверждениях пользователей можно было усомниться, то в остальных случаях их слова подозрений не вызывали. Как правило, речь идет о функции шифрования устройств BitLocker Device Encryption, описанной в статье «Общие сведения о функции шифрования устройств BitLocker в Windows 10». Если не вдаваться в детали, Windows (независимо от редакции — функция поддерживается даже в Windows 10 Home) автоматически зашифрует системный раздел в фоновом режиме при выполнении нескольких условий:

В устройстве присутствует и активирован чип TPM или технология Intel PTT.
Устройство поддерживает Modern Standby.
Пользователь с правами администратора вошел в систему через учетную запись Microsoft Account или использовал для входа учетную запись домена.
Система автоматически создаст ключ восстановления BitLocker и загрузит его в Microsoft Account пользователя или Active Directory.

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

Итак, ты вошел в систему с правами администратора, использовав учетную запись Microsoft Account. Системный диск был зашифрован, но ты этого даже не заметил. Через какое‑то время ты перезагрузил систему. Изменилось ли что‑нибудь в процессе загрузки? С точки зрения пользователя — ровным счетом ничего: компьютер загрузился, Windows вывела запрос пароля. К этому моменту зашифрованный BitLocker диск уже разблокирован, но ты даже не прикасался к компьютеру. С какой стороны это называется защитой?

А вот с какой. При проектировании архитектуры защиты разработчики Windows использовали модель угроз, призванную предотвратить следующие события:

Таким образом, если тебе известен пароль входа в систему — ты не испытаешь никаких неудобств от того, что диск зашифрован. А вот если пароля у тебя нет, то тебе не удастся даже запустить перебор: база данных SAM хранится на зашифрованном диске, и доступа к ней у тебя не будет до тех пор, пока ты не справишься с шифрованием. Для параноиков доступны варианты усиленной защиты: например, на системный раздел можно дополнительно установить PIN-код, сохранить ключ на USB-накопителе или использовать сразу оба способа. В разделе, посвященном противодействию атакам, как раз и упоминается этот способ.

Как устроена защита

В BitLocker используется симметричное шифрование диска. По умолчанию — алгоритм AES с ключом длиной 128 бит. В свежих сборках Windows 10 применяется режим XTS; более старые версии ОС и первый релиз Windows 10 используют режим CBC.

Как именно выполняется шифрование: средствами центрального процессора (с использованием команд AES-NI) или контроллера диска, — вопрос сложный. До недавнего времени Windows отдавала предпочтение механизмам шифрования, встроенным в контроллер диска или SSD, однако обнаруженная исследователями в целом ряде моделей уязвимость в реализации подобных механизмов заставила Microsoft отказаться от этой практики и реализовать шифрование силами центрального процессора. Впрочем, это касается только вновь создаваемых томов; уже зашифрованные диски будут продолжать использовать тот механизм, который был использован при их создании.

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

Расшифровать паролем, если раздел зашифрован именно таким образом.
Расшифровать ключом восстановления (Recovery Key).
Извлечь непосредственно из модуля TPM.

О парольных атаках я писал уже достаточно; извлечение ключа восстановления — интересная тема, заслуживающая отдельной статьи. Сейчас нас интересует исключительно третий вариант — извлечение ключа из модуля TPM.

Загрузка

Модуль TPM или технология Intel PTT используется в том числе для аппаратного контроля «доверенной загрузки» (Trusted boot). Цель «доверенной загрузки» — убедиться, что загружена именно та операционная система и именно в той конфигурации, которая использовалась при создании ключей. Для этого применяется технология, напоминающая блокчейн. Строится своеобразная «цепочка доверия» — последовательность блоков с информацией об этапах загрузки, выстроенная в хронологическом порядке. Так же как и в блокчейне, информацию в цепочке нельзя изменить — только добавить. «Цепочка доверия» сохраняется в регистрах PCR (Platform Configuration Register).

Для начала рассмотрим работу механизма «доверенной загрузки» и роль модуля TPM без шифрования. Во время загрузки выполняются следующие операции.

При включении компьютера управление получает первый доверенный модуль SRTM (Static root of trust for measures), который находится в области ROM, защищенной от записи. Важный момент: SRTM по определению статичен и защищен от изменений. Уязвимость в этом модуле может поставить под угрозу всю систему безопасности, как это произошло в случае с найденной в загрузчиках Apple уязвимостью checkm8. Подробно об SRTM и другой технологии — DRTM можно узнать из ответа на Stack Exchange «How does the TPM perform integrity measurements on a system?».
SRTM делает первую запись в цепочке: в регистр PCR0 записывается контрольная сумма программного кода BIOS. Если в системе прописался руткит, цепочка доверенной загрузки будет прервана (см. «Как система Windows Defender System Guard защищает Windows 10 от руткитов»).
Теперь управление получает доверенный UEFI BIOS, который формирует дальнейшие компоненты цепочки. При этом анализируется множество параметров: таблицы MBR, загрузчика bootloader и других. В цепочку добавляется очередная контрольная сумма, в создании которой используется информация из предыдущего регистра PCR. Нарушение любого из компонентов приводит к изменению содержимого регистров PCR и прерыванию доверенной загрузки.
Управление передается загрузчику (bootloader), который считывает и запускает код из MBR диска. При этом в цепочку загрузки добавляется еще несколько записей.
Запускается ядро операционной системы, которое добавляет очередные элементы в цепочку.
Загружается операционная система. В результате на выходе — набор данных в регистрах PCR, однозначно описывающий весь процесс загрузки. От модификации содержимое регистров PCR защищается на аппаратном уровне модулем TPM.

Отлично, система загрузилась, содержимое регистров PCR указывает на доверенный статус загрузки. Теперь добавим шифрование.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Читайте также: