О безопасности UEFI, части нулевая и первая
Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI «полумифическим». С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».
В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.
Часть нулевая. Введение
Безопасностью UEFI -совместимых прошивок я интересуюсь довольно давно, и уже почти 2 года занимаюсь ей профессионально. Поводом к написанию этой статьи послужило практически полное отсутствие в русскоязычной части интернета какой-либо информации по безопасности UEFI, кроме переводов статей известных англоязычных исследователей, выполненных слабо знакомыми с предметом людьми. Пробел это надо понемногу восполнять, т.к. иначе он заполняется разного рода лозунгами вроде «SecureBoot против свободного ПО», «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. Аппаратная верификация прошивки или её части перед выполнением любого кода
Самые серьезные технологии в нашем списке, которые, будучи правильно реализованными, защищают прошивку от атакующих всех трех уровней — Intel BootGuard и AMD Hardware-Validated Boot. Существенно отличаясь в деталях, они выполняют одинаковую задачу: проверяют целостность небольшой части прошивки, которая подписана ЭЦП производителя материнской платы, а хэш ключа прошит в чипсет. Если проверка прошла успешно, прошивка стартует, если же нет — все зависит от настроек. Обе технологии предоставляют «аппаратный корень доверия» для последующих стадий загрузки, и прошивка может выстроить цепочку доверия, в которой чипсет проверяет bootstrap-код, этот код проверяет том PEI , тот в свою очередь — том DXE , а в DXE уже включается SecureBoot и проверяет подпись загрузчика ОС. Любое изменение защищенных таким образом частей прошивки приводит, чаще всего, к банальному DoS.
Обратная сторона такой защиты — невозможность модификации прошивки даже легитимным пользователем системы, сложности ремонта материнской платы при отказе чипсета или SoC ‘а (и хорошо, если меняем на чистый, а не на использованный с другим хэшем, в первом случае можно попробовать удалить драйверы для Verified Boot из образа, а во втором не поможет уже ничего).
Поддерживаются эти технологии начиная с Intel Haswell и AMD Trinity, и работающих атак на них я пока не знаю, но сейчас они используются на двух с половиной моделях корпоративных ноутбуков и я бы предпочел, чтобы ситуация сильно не менялась, ведь именно возможность модификации прошивки и ОС отличает твое устройство от чужого.
О том, как проверить конкретную систему на наличие какой-либо вариации Verified Boot — напишу в следующий раз, после того, как получу от Intel и AMD разрешение на публикацию.
Атакующие первого уровня могут расслабиться и получать удовольствие — кроме аппаратной верификации им не может помешать никакая из последующих защит. Именно поэтому я говорил и буду говорить: программатор и SOIC-клипса — маст-хэв для любого серьезного исследователя прошивок.
2. Хранилище только для чтения с аппаратным переключателем
В стародавние до-UEFI-шные времена на многих материнских платах устанавливался джампер, защищающий микросхему с BIOS’ом от случайной или злонамеренной прошивки. Сложностей с реализацией такой защиты практически не возникало, т.к. все содержимое BIOS Setup хранилось в отдельно в CMOS SRAM и, кроме случаев обновления прошивки, ничего писать было просто не нужно. Затем кто-то в Intel принял решение, что в CMOS места мало, и потому нужно взять микросхему поёмче и побыстрее, и все настройки писать туда, чего месту зря пропадать. В результате этого «гениального» решения (и цепочки последующих, такого же уровня гениальности) в одной микросхеме оказалось все: собственно UEFI, часть прошивки встроенной сетевой карты ( GbE ), большая часть прошивки чипсета ( ME ), прошивка EC и черт знает что еще, и каждый из трех владельцев микросхемы (CPU, ME и GbE) получил право писать в нее не только при обновлении, а вообще в любой момент. Чтобы как-то упорядочить возникший бардак, Intel добавила в начало микросхемы Flash Descriptor, в котором явно прописаны права доступа трех владельцев к каждому региону (подробнее о дескрипторе и форматах я уже писал), но это не сильно помогло. Единственный официально поддерживаемый способ отделить мух от котлет и RW от RO — установка двух микросхем SPI, первая отдается под Descriptor, ME, GbE и NVRAM, а вторая — под оставшуюся часть UEFI, после чего нога #WP второго чипа садится джампером на землю, защищая его от записи аппаратно.
Проблем у такой защиты несколько:
— два чипа чуть менее чем вдвое дороже одного и любой закупщик мечтает сэкономить на них миллион-другой долларов на массовом производстве, поэтому плату с двумя чипами днем с огнем не найти.
— для прошивки обязателен физический доступ, т.к. вывод #WP на GPIO губит всю безопасность на корню.
— испортить содержимое RW-микросхемы все равно можно даже не имея физического доступа.
К сожалению, реализаций подобной защиты на имеющихся на массовом рынке системах с UEFI я пока не видел. Раньше — были, а теперь остались только на Chromebook, но там прошивка основана на coreboot. Я не знаю, как именно там реализована аппаратная защита от прошивки при условии, что там тот же самый ME, что и везде…
3. PR -регистры чипсета
Если аппаратно микросхему SPI защитить от записи не получилось, можно защитить ее силами чипсета. Все современные чипсеты имеют как минимум 4 регистра PR, предназначенных для защиты от чтения и/или записи блока физической памяти, а т.к. микросхема SPI всегда отображается на «дно» первых 4 Гб физической памяти (т.е. последний байт микросхемы SPI всегда находится по физическому адресу 0xFFFFFFFF), но можно защитить всю прошивку или ее часть.
Защита подобного рода тоже не обходится без проблем:
— ее нужно правильно реализовать, не забыв, что при перезагрузке значения регистров тоже сбрасываются, и их нужно восстанавливать.
— нужно не забыть установить (и восстановить после перезагрузки) lock на их конфигурацию, иначе вредоносный код их может банально сбросить.
— защита не может быть отключена, т.е. обновление прошивки из ОС без перезагрузки становится невозможным.
— и, конечно, NVRAM и другие RW-области защитить таким способом не получится.
В отличие от предыдущего пункта, систем с PR’ами на рынке море, и почти на всех защита реализована неграмотно или неполно.
4.1. SMM_BWP и SpiRomProtect
Вновь похожие друг на друга защиты от Intel и AMD соответственно, которые не позволяют запись в микросхему SPI из любого режима процессора, кроме SMM. Для обновления прошивки используется специальный SMI -обработчик, который должен выполнять проверку целостности и подписи новой прошивки, и только после успешной проверки выполнять прошивку.
Защита эта достаточно простая в реализации и потому есть практически на любом UEFI, но иногда она отключена по умолчанию. Большой плюс — независимость кода прошивальщика от архитектуры.
Есть и недостатки:
— кода в SMM много, и любая уязвимость в нем дает полный доступ к прошивке.
— от багов в реализации самого прошивальщика тоже никто не застрахован.
— если защита управляется переменной в NVRAM (очень много систем, где это так), то она практически бесполезна, ибо может быть просто отключена атакующим, способным загрузить UEFI Shell.
Посмотрев на вышеперечисленные недостатки, ребята из Intel решили исправить их, где-то примерно в Ivy Bridge придумали следующую защиту, а именно…
4.2. Intel BIOS Guard, в девичестве PFAT
Справедливо рассудив, что кода в SMM слишком много, а IBV никак не могут написать свои прошивальщики так, чтобы в них не зияло дыр, Intel решили, что нужно идти глубже, и добавили еще один привилегированный режим исполнения, специальную область памяти ACRAM, недоступную из других режимов, в которую можно загрузить только подписанный Intel’овской ЭЦП прошивальщик, и только ему будет доступна запись в микросхему SPI. Все три проблемы из пункта 4.1 удалось успешно решить, но при этом, конечно, добавили новых:
— отвратительно высокая сложность во всем. Скрипты на собственном DSL , подписи на каждый чих, раздельное обновление компонентов и прочий ад и Гондурас.
— образ для обновления невозможно прошить на программаторе, и для восстановления такой прошивки приходится буквально собирать ее из кусков, непрерывно матерясь.
— ну и vendor lock-in, конечно.
Некоторые отважные производители используют PFAT и у них он даже работает, но я попробовал и могу сказать — ни за какие коврижки, лучше я сделаю аудит кода SMM еще пару раз, чем это.
Про атаки на PFAT я ничего не знаю, но тут скорее всего работает правило неуловимого Джо.
5. BLE и BIOS_WE
Давным-давно, когда SMM_BWP еще не было, а у процессора было одно ядро, защита от записи в SPI-чип у Intel была организована так: есть бит BIOS_WE, который нужно уставить, чтобы чипсет позволил отправить команду на запись. Бит доступен любому коду, поэтому рядом с ним есть другой бит — BLE. Если он установлен, то установка BIOS_WE генерирует SMI, а BIOS регистрирует обработчик этого SMI, который это самый BIOS_WE сбрасывает. Софт видит, что бит сбросился и перестает пытаться писать — защита, все, нельзя. Если же прошивать из SMM, то при установке BIOS_WE прерывания не происходит (мы и так уже в SMM), и можно шить.
В итоге вся защита построена на том, что BIOS добавит обработчик и SMI будет сгенерирован, поэтому для успешной атаки достаточно было забытого бита SmiLock, чтобы можно было отключить источник этого SMI и спокойно шить все, что угодно. Затем SmiLock перестали забывать и некоторые IBV даже были уверены, что защита надежная, пока на 31С3 Rafal Wojtczuk и Corey Kallenberg не показали, что на многоядерных процессорах механизм BLE/BIOS_WE уязвим к race condition, и толку от него практически ноль, т.к. атака занимает меньше 10 минут и успешна всегда.
Тем не менее, до сих пор попадаются системы, защищенные только и исключительно BLE. Это печально.
6. Отсутствующая
Хрестоматийный пример «пирожка без никто». Некоторые производители материнских плат для десктопов, не будем показывать пальцем, до сих пор не защищают прошивку от перезаписи вообще. Ваша система — вы и заморачивайтесь, никакой иллюзии безопасности мы вам не даем, только голый BIOS, только хардкор. Вести себя таким образом с каждым днем становится труднее, ведь с одной стороны давит Intel с рекомендациями, а с другой — Microsoft с HSTI , но пока справляются. Безумству храбрых, и все такое.
Заключение
С защитами от прошивки более или менее разобрались, в следующей части поговорим об SMM и атаках на него.
Буду рад любым вопросам и комментариям. Спасибо за внимание.
Что делает защита встроенная в bios
Устройство с защитой на уровне UEFI – это устройство со встроенным на уровне BIOS программным обеспечением Антивирус Касперского для UEFI. Встроенная защита обеспечивает безопасность устройства еще с начала запуска системы, в то время как защита устройств, не имеющих встроенного ПО, начинает действовать только после запуска программы безопасности. Kaspersky Security Center поддерживает управление такими устройствами.
Чтобы изменить параметры подключения устройств с защитой на уровне UEFI:
- В дереве консоли выберите узел с именем нужного вам Сервера администрирования.
- В контекстном меню Сервера администрирования выберите пункт Свойства .
- В окне свойств Сервера администрирования выберите раздел Параметры подключения к Серверу → Дополнительные порты .
- В разделе Дополнительные порты измените необходимые вам параметры:
- Открыть порт для устройств с защитой на уровне UEFI и устройств с KasperskyOS
Устройства с защитой на уровне UEFI могут подключаться к Серверу администрирования.
Если выбран вариант Открыть порт для устройств с защитой на уровне UEFI и устройств с KasperskyOS , можно изменить номер порта. По умолчанию установлен порт 13294.
Защита устройства в разделе «Безопасность Windows»
Приложение «Безопасность Windows» предоставляет встроенные функции безопасности, чтобы защитить ваше устройство от атак вредоносных программ.
Чтобы получить доступ к описанным ниже функциям, нажмите в Windows кнопку Пуск, введите текст безопасность windows, выберите это приложение в списке результатов, затем выберите Безопасность устройства.
Примечания: Элементы, отображаемые на странице Безопасность устройства, зависят от того, что поддерживается вашим оборудованием.
- Дополнительные сведения о системе «Безопасность Windows» см. в разделе Защита с помощью панели «Безопасность Windows».
- Для получения дополнительной информации о брандмауэре Microsoft Defender см. раздел Включение и отключение брандмауэра Защитника Windows.
- Инструкции по работе с паролем см. в разделе Изменение или сброс пароля для Windows.
Изоляция ядра
Изоляция ядра обеспечивает дополнительную защиту от вредоносных программ и других атак, изолируя процессы компьютера от операционной системы и устройства. Выберите ссылку Сведения об изоляции ядра, чтобы включить, отключить или изменить параметры изоляции ядра.
Целостность памяти
Целостность памяти — это функция изоляции ядра. Включив параметр Целостность памяти, вы сможете запретить вредоносному коду доступ к процессам с высоким уровнем безопасности в случае атаки.
Дополнительные сведения об изоляции ядра и целостности памяти см. в статье Изоляция ядра.
Обработчик безопасности
Обработчик безопасности реализует дополнительное шифрование для вашего устройства.
Сведения об обработчике безопасности
Здесь вы найдете сведения о производителе и номерах версий обработчика безопасности, а также информацию о состоянии обработчика безопасности. Выберите ссылку Устранение неполадок обработчика безопасности для получения дополнительных сведений и параметров.
Примечание. Если на этом экране не отображается запись «Обработчик безопасности», скорее всего, у вашего устройства нет необходимого оборудования TPM (доверенный платформенный модуль) для этой функции или оно не включено в UEFI (единый интерфейс EFI). Обратитесь к производителю устройства, чтобы узнать, поддерживает ли ваше устройство TPM (доверенный платформенный модуль), и, если да, то как включить его.
Если обработчик безопасности работает неправильно, перейдите по ссылке Устранение неполадок обработчика безопасности, чтобы увидеть сообщения об ошибках и получить доступ к расширенным параметрам. Дополнительные сведения см. в следующем разделе: Устранение неполадок обработчика безопасности.
Безопасная загрузка
Безопасная загрузка предотвращает загрузку сложного и опасного типа вредоносных программ, rootkit, при запуске устройства. Пакеты программ rootkit используют такие же разрешения, как и операционная система, и запускаются раньше нее, что позволяет им полностью скрыть себя. Зачастую программы rootkit входят в набор вредоносных программ, которые могут обходить процедуры входа, записывать пароли и нажатые клавиши, перемещать конфиденциальные файлы и получать криптографические данные.
Может потребоваться отключить безопасную загрузку для работы некоторых графических плат, оборудования или операционных систем ПК, например Linux или предыдущих версий Windows. Дополнительные сведения см. в разделе Отключение и повторное включение безопасной загрузки.
Аппаратные возможности обеспечения безопасности
В нижней части экрана «Безопасность устройства» отображается одно из следующих сообщений с указанием возможностей защиты вашего устройства.
Устройство соответствует требованиям для стандартной безопасности оборудования
Это означает, что устройство поддерживает целостности памяти и изоляцию ядра, а также:
- TPM 2.0 (или обработчик безопасности);
- включена безопасная загрузка;
- DEP;
- UEFI MAT.
Устройство соответствует требованиям для усиленной безопасности оборудования
Это означает, что в дополнение к стандартным требованиям к безопасности оборудования, на устройстве также включена функция целостности памяти.
На вашем устройстве включены все функции защищенного компьютера
Примечание: До Windows 20H2 в этом сообщении говорилось: «Ваше устройство превышает требования к усиленной аппаратной безопасности».
Это означает, что в дополнение к обеспечению соответствия требованиям к усиленной безопасности оборудования, на устройстве также включена функция защиты режима управления системой (SMM).
Стандартная безопасность оборудования не поддерживается
Это означает, что устройство не соответствует по крайней мере одному из стандартных требований к безопасности оборудования.
Улучшенная аппаратная безопасность
Если уровень системы безопасности устройства вас не устраивает, может потребоваться включить определенные аппаратные функции (такие как безопасная загрузка, если она поддерживается) или изменить параметры в BIOS вашей системы. Обратитесь к изготовителю оборудования, чтобы узнать, какие функции поддерживаются вашим оборудованием и как их активировать.
Программно-технические методы обнаружения вирусов.
Основным средством борьбы с вирусами были и остаются антивирусные программы. Безусловно, их можно использовать, не имея представления о том, как они устроены. Однако без понимания принципов устройства антивирусов, знания типов вирусов и способов их распространения нельзя организовать надежную защиту компьютера. Практически все антивирусные программы обеспечивают автоматическое восстановление зараженных программ и загрузочных секторов (конечно, если это возможно).
Сегодня используется несколько основных методик обнаружения и защиты от вирусов:
1.Сканирование.
Самая простая методика поиска вирусов заключается в том, что антивируснаяпрограмма последовательно просматривает проверяемые файлы в поиске сигнатур известных вирусов. Под сигнатурой понимается уникальная последовательность байтов, принадлежащая вирусу и не встречающаяся в других программах.
Антивирусные сканеры способны найти только уже известные вирусы, для которых определена сигнатура. Применение простых программ-сканеров не защищает компьютер от проникновения новых вирусов. Для шифрующихся и полиморфных вирусов, способных полностью изменять свой код при заражении новой программы или загрузочного сектора, невозможно выделить сигнатуру, поэтому антивирусные
сканеры их не обнаруживают.
2. Эвристический анализ.
Эвристический анализ позволяет обнаруживать неизвестные ранее вирусы, причем для этого не надо собирать данные о файловой системе (как этого требует, например, рассмотренный ниже метод обнаружения изменений).
Антивирусные программы, реализующие метод эвристического анализа, проверяют программы и загрузочные секторы дисков и дискет, пытаясь обнаружить в них код, характерный для вирусов. Эвристический анализатор может обнаружить, например,что проверяемая программа устанавливает резидентный модуль в памяти или записывает данные в исполнимый файл программы. Практически все современные антивирусные программы реализуют собственные методы эвристического анализа. В качестве примера такой программы назовем сканер McAffee VirusScan.
Обнаружив зараженный файл, антивирус обычно выводит сообщение на экране монитора и делает запись в собственном или системном журнале. В зависимости от настроек, антивирус может также направлять сообщение об обнаруженном вирусе администратору сети. Если это возможно, антивирус вылечивает файл, восстанавливая его содержимое. В противном случае предлагается только одна возможность — удалить зараженный
файл и восстановить его из резервной копии.
3. Антивирусные мониторы.
Существует целый класс антивирусных программ, которые постоянно находятся в памяти компьютера и отслеживают все подозрительные действия, выполняемые другими программами. Такие программы носят название антивирусных мониторов, или сторожей.
Монитор автоматически проверяет все запускаемые программы, создаваемые, открываемые и сохраняемые документы, файлы программ и документов, полученные через Интернет или скопированные на жесткий диск с дискеты либо компакт диска. Антивирусный монитор сообщит пользователю, если какая-либо программа> попытается выполнить потенциально опасное действие.
Пример такой программы — сторож Spider Guard, который входит в комплект сканера Doctor Web, разработанного Игорем Даниловым (http://www.drweb.ru),
4. Обнаружение изменений.
Заражая компьютер, вирус изменяет содержимое жесткого диска: например, дописывает свой код в файл программы или документа, добавляет вызов программы-вируса в файл AUTOEXEC.BAT, изменяет загрузочный сектор, создает файл-спутник. Однако «бестелесные» вирусы, обитающие не на диске, а в памяти процессов ОС, таких изменений не делают.
Антивирусные программы, называемые ревизорами диска, не выполняют поиск вирусов по сигнатурам. Они запоминают предварительно характеристики всех областей диска, которые могут подвергнуться нападению, а затем периодически проверяют их (отсюда и название — программы-ревизоры). Ревизор может найти изменения, сделанные как известным, так и неизвестным вирусом.
Вместе с ADinf применяется лечащий модуль ADinf Cure Module (ADinfExt), который использует собранную ранее информацию о файлах для их восстановления после поражения неизвестными вирусами. В состав ревизора AVP Inspector также входит лечащий модуль, способный удалять вирусы.
5. Защита, встроенная в BIOS компьютера.
В системные платы компьютеров тоже встраивают простейшие средства защиты от вирусов. Эти средства позволяют контролировать все обращения к главной загрузочной записи жестких дисков, а также к загрузочным секторам дисков и дискет. Если какая-либо программа пытается изменить содержимое загрузочных секторов, срабатывает защита, и пользователь получает соответствующее предупреждение. Однако эта защита не очень надежна. Существуют вирусы (например, Tchechen.1912 и 1914), которые пытаются отключить антивирусный контроль BIOS, изменяя некоторые ячейки в энергонезависимой памяти (CMOS-памяти) компьютера.
- Войдите на сайт для отправки комментариев