какую ситуацию можно предотвратить создав пароль uefi
О безопасности UEFI, части нулевая и первая
Часть нулевая. Введение
Модель угроз
Прежде чем говорить о защите и уязвимостях, поговорим немного о модели угроз.
Ни одна защита не может защитить от всего сразу. К примеру, защиту прошивки от поражающего действия ядерного взрыва или от сбоев при работе в открытом космосе, я в этой статье рассматривать не буду, хотя с удовольствием почитал бы подобную статью от специалистов в соответствующей области.
Уровни доступа
Определим для атакующего несколько уровней доступа и посмотрим, что и насколько успешно «среднестатистическая» реализация UEFI может противопоставить ему:
— атакующий первого уровня имеет физический доступ к системе, способен загружать любые ОС, изменять настройки UEFI, прошивать свой код UEFI вместо оригинального на программаторе, переставлять джамперы на мат. плате, замыкать выводы микросхем и т.п.
— атакующий второго уровня имеет физический доступ к системе, но программатора у него нет.
— атакующий третьего уровня имеет удаленный доступ к системе в режиме администратора.
Остальные случаи рассматривать не будем, т.к. от более могущественного атакующего, способного менять сидящие на шарах чипы, в UEFI защищаться практически нечем, а более слабых, без прав администратора, остановит ОС.
Векторы атаки
Теперь определим основные векторы и последствия успешно совершенной атаки, в порядке уменьшения опасности:
1. Хранилище основной прошивки (в 95% современных систем — 1-2 микросхемы NOR-flash с интерфейсом SPI )
Суть атаки — вставляем свой код в прошивку, удаляем части имеющегося, воруем, убиваем, молчим про гусей.
Последствия атаки варьируются от получения полного контроля над прошивкой, аппаратурой и ОС в лучшем случае, до DoS в худшем. Физический атакующий может устроить DoS в любом случае (с размаху отверткой в плату — вот тебе и DoS), поэтому подробнее на DoS для атакующих первого и второго уровней останавливаться не буду.
2. Код в SMM
Суть — получаем доступ к особо привилегированному режиму процессора, из которого нам доступна на чтение и запись вся физическая память и много другого вкусного.
Последствия — в лучшем случае доступ к хранилищу прошивки, и далее смотри пункт 1, в худшем — обход механизмов защиты ОС и гипервизора (которые, впрочем, можно было обойти и на уровне ОС, но из SMM это может быть намного проще).
3. Хранилище прошивки PCI-устройств
4. Переменные в NVRAM
Суть — получаем возможность изменять настройки UEFI, в том числе скрытые.
Последствия — в лучшем случае можно поотключать все защиты и сразу перейти к пункту 1, в худшем — снова DoS (пишем мусор в NVRAM, перезагружаемся, смотрим, что получилось).
5. SecureBoot
Суть — получаем возможность загрузить любую нужную ОС, в том числе UEFI Shell.
Последствия — в лучшем случае получается загрузить UEFI Shell и сразу оказаться в пункте 4, в худшем — заменить стандартный загрузчик ОС на модифицированный, закрепившись таким образом в ОС, пока бдительный пользователь не включит SecureBoot обратно.
Часть первая. Защиты от записи в хранилище основной прошивки
1. Аппаратная верификация прошивки или её части перед выполнением любого кода
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, что и везде…
Если аппаратно микросхему 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
Давным-давно, когда 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. Отсутствующая
О безопасности UEFI, часть пятая
После небольшого перерыва продолжаем разговор о безопасности UEFI. В этот раз речь пойдет о технологии SecureBoot, ее преимуществах и недостатках, об атаках на нее и защите от них.
Впервые о SecureBoot речь зашла в стандарте UEFI 2.2 в 2011 году, но окончательно все аспекты были реализованы в версии 2.3.1C в начале 2012 года. Основным разработчиком технологии была Microsoft, которая сразу же заявила, что для получения сертификата Windows 8 Ready для своей еще не выпущенной новой ОС требуется реализация и включение SecureBoot по умолчанию на всех новых ПК. Это заявление вызвало волну резкой критики со стороны сторонников свободного ПО, которая успешно докатилась и до Хабра.
Если вам интересно, чем именно закончилось противостояние MS и сообщества, как SecureBoot выглядит после почти 4 лет взросления, и какие атаки на него все еще возможны — добро пожаловать под кат.
Стоп, чуть не забыл: по доброй традиции, набор ссылок на предыдущие части, для тех, кто умудрился их пропустить.
Часть пятая. SecureBoot
Это что вообще?
Не думаю, что после десятка статей на Хабре стоит рассказывать о SecureBoot слишком уж подробно — это уже было сделано не раз и без меня. Тем не менее, совсем ничего не рассказать было бы преступлением против незнакомого с темой читателя, поэтому пройдемся по верхам, а желающих знать все и досконально привычно отправим в спецификацию.
SecureBoot — это программная технология, при помощи которой UEFI-совместимая прошивка может проверить подлинность исполняемых ей внешних компонентов (загрузчиков, драйверов и UEFI OptionROM’ов). Эти исполняемые компоненты должны быть подписаны ЭЦП, которая проверяется во время загрузки и в случае ее полного отсутствия, повреждения, отсутствия в списке доверенных (db) или присутствия в списке запрещенных (dbx) запуск соответствующего компонента не происходит (иногда это поведение настраивается, что тоже может сыграть злую шутку, но об этом позже). В качестве алгоритма ЭЦП в данный момент стандартом рекомендуется комбинация из RSA2048 и SHA256, которые и используются почти на всех виденных мной в живую системах.
Немного о ключах
SecureBoot использует следующую иерархию ключей:
В зависимости от необходимого уровня безопасности, PK может быть сгенерирован следующим образом:
Кто тут в цари первый?
В большинстве конфигураций SecureBoot по умолчанию PK предоставляется производителем мат. платы, в KEK лежит единственный сертификат Microsoft Corporation KEK CA 2011, а в db обязательно присутствует сертификат Microsoft Windows Production CA 2011, но иногда к нему добавляют сертификат Canonical и сертификат производителя платформы, которым подписаны разного рода утилиты для обновления прошивки и вот это все. Хранилище dbx на большинстве систем пустое, но не так давно MS внесли в него несколько записей и теперь требуют их наличия на новых системах для получения сертификата Windows 10 Ready. Получается, что с точки зрения SecureBoot в конфигурации по умолчанию, вашей системой владеет производитель мат. платы, а единственный ее авторизованный пользователь — Microsoft. К счастью (и по большей части благодаря давлению сообщества СПО) эта печальная картина на подавляющем большинстве систем для x86 может быть разрушена удалением стандартных ключей и добавлением собственных из BIOS Setup, но про это я планирую написать отдельно.
Несовместимость с CSM
Атаки на SecureBoot
О векторах
Для начала следует понять, какие именно части SecureBoot могут быть атакованы и чем грозит успешная атака:
Собственно атаки
Отключение SecureBoot удалением PK
Если у атакующего имеется доступ на запись в хранилище NVRAM, что нередко случается у любителей защитить микросхему SPI лишь при помощи пары PR-регистров, то текущий PK можно банально удалить, что автоматически отключит SecureBoot, переведя его в режим установки новых ключей.
Отключение SecureBoot правкой CurrentMode
Эта атака — комбинация из атаки на NVRAM и реализацию. На некоторых системах текущий режим SecureBoot управляется записью в переменной Setup, и если она неожиданно для всех имеет флаг RT, то атакующий может отключить SecureBoot просто записав в Setup ноль по нужному смещению, которое, в свою очередь, легко можно найти анализом дампа IFR. Атака тупая как валенок, но до сих пор имеется куча систем, которые ей подвержены.
Обход SecureBoot правкой ExecutionPolicy
Вариация предыдущей атаки, но отключается на этот раз не сам SecureBoot, а запрет на продолжение загрузки при несовпадении или отсутствии ЭЦП. Тоже требует флага RT на переменной Setup и встречается чуть реже, чем предыдущий вариант, но зато позволяет обойти SecureBoot тихо, не отключая его.
Обход SecureBoot повреждением NVRAM
На некоторых системах для обхода SecureBoot достаточно немного испортить NVRAM (к примеру, заполнив хранилище под завязку), чтобы отключить либо обойти SecureBoot. Встречается такое поведение редко, но атака настолько простая, что есть смысл опробовать ее на любой системе. В крайнем случае, вместо обхода SecureBoot может получиться DoS, если драйвер NVRAM совсем плохой.
Обход SecureBoot при помощи PCI(e)-устройства
Теоретически, запуск UEFI OptionROM’ов из PCI-устройств при включенном SecureBoot не должен происходить, если соответствующий OROM не прошел верификацию, но на практике огромно количество систем доверяет PCI-устройствам безоговорочно и запускает оттуда все без каких-либо проверок. Примеров подобного поведения много, а любые системы без SecureBoot подвержены такой атаке автоматически, именно поэтому вынос PCI(e) на внешние разъемы, вроде Thunderbolt, Firewire, PCMCIA, ExpressCard и т.п. — преступление против безопасности платформы, даже без учета того, что любое PCI-устройство может инициировать DMA с любым регионом физической памяти, кроме SMRAM (и то только если производитель платформы не забыл установить защиту) и утащить у ОС и пользователя все их секреты.
Обход SecureBoot преобразованием загрузчика из PE в TE
Обход SecureBoot загрузкой с внешнего носителя
Это даже не совсем атака, а скорее непонимание некоторых пользователей, что SecureBoot вообще не защищает от подмены загрузчика, и физически присутствующий атакующий может загрузить систему со своего носителя. Иногда от этого пытаются защититься паролем на BIOS и меню выбора загрузочного устройства, но добрые разработчики из MS позволяют выбрать его и из Windows, для чего достаточно зажать Shift и выбрать действие «перезагрузка» на экране входа в систему, а затем выбрать в появившемся меню нужно загрузочное устройство. Дорогим товарищам из MS — мое большое спасибо.
Эксплуатация подписанных загрузчиков для обхода защиты UEFI Secure Boot
Введение
Большинство материнских плат поставляется только с ключами Microsoft в качестве доверенных, из-за чего создатели загрузочного ПО вынуждены обращаться в Microsoft за подписью загрузчиков, проходить процедуру аудита, и обосновывать необходимость глобальной подписи их файла, если они хотят, чтобы диск или флешка запускались без необходимости отключения Secure Boot или добавления их ключа вручную на каждом компьютере.
Подписывать загрузчики у Microsoft приходится разработчикам дистрибутивов Linux, гипервизоров, загрузочных дисков антивирусов и программ для восстановления компьютера.
Мне хотелось сделать загрузочную флешку с различным ПО для восстановления компьютера, которая бы грузилась без отключения Secure Boot. Посмотрим, как это можно реализовать.
Подписанные загрузчики загрузчиков
Действия, необходимые при первом запуске недоверенной программы через shim.
Все современные популярные дистрибутивы Linux используют shim, из-за поддержки сертификатов, которая позволяет легко обновлять следующий загрузчик без необходимости взаимодействия с пользователем. Как правило, shim используется для запуска GRUB2 — наиболее популярного бутлоадера в Linux.
GRUB2
Так или иначе, воспользоваться подписанным GRUB из какого-то дистрибутива Linux не получится. Для создания универсальной загрузочной флешки, которая бы не требовала добавление ключей каждого загружаемого файла в доверенные, есть два пути:
Итого, архитектура флешки получилась следующая:
Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.
Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.
Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.
Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.
Подписанные загрузчики
Мне было интересно, можно ли как-то обойти необходимость добавления ключа через shim при первом запуске. Может, есть какие-то подписанные загрузчики, которые позволяют делать больше, чем рассчитывали авторы?
Как оказалось — такие загрузчики есть. Один из них используется в Kaspersky Rescue Disk 18 — загрузочном диске с антивирусным ПО. GRUB с диска позволяет загружать модули (команда insmod), а модули в GRUB — обычный исполняемый код. Пред-загрузчик у диска собственный.
Так появился Silent UEFIinSecureBoot Disk. Получившаяся архитектура диска выглядит следующим образом:
Заключение
Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.
Как восстановить или установить пароль BIOS или UEFI для компьютеров с Windows
Если вы долгое время использовали Windows, я уверен, что вы знаете пароль BIOS или UEFI. Эта блокировка паролем гарантирует, что вам нужно ввести установленный пароль даже до загрузки компьютера Windows. Тем не менее, самая большая проблема с BIOS или паролем UEFI заключается в том, что нет такой опции восстановления, как учетная запись Microsoft. В этом руководстве мы расскажем, как восстановить или установить пароль BIOS или UEFI для компьютеров с Windows.
Шаги включают в себя:
Пароли BIOS или UEFI хранятся на аппаратном уровне. Поэтому, если производитель не хочет или не настроил выход для восстановления пароля, его невозможно восстановить. Иногда они настолько строги, что единственный способ справиться – позвонить в службу поддержки клиентов. Помните, что любой компьютер Windows с этой блокировкой не может быть разблокирован при попытке переустановить Windows.
Восстановить или сбросить пароль BIOS или UEFI
Временно удалить батарею CMOS
Каждая материнская плата поставляется с батареей CMOS. Это помогает системе сохранять тактовую частоту, следить за тем, чтобы настройки BIOS не терялись при выключении компьютера. Поэтому, когда компьютер включается, батарея CMOS обеспечивает доступность информации для загрузки компьютера.
Тем не менее, если вы временно удалите батарею CMOS примерно на 30 секунд или минуту, настройки будут потеряны. Некоторые материнские платы построены так, что вынимая батарею надолго, сбрасывает все. Это включает в себя пароль для BIOS/UEFI.
Очистить неизвестные пароли BIOS/UEFI с помощью веб-сайта bios-pw
Если вышеуказанный шаг не работает, вы можете использовать этот сайт BIOS Password, чтобы очистить его. Следуй этим шагам:
Позвоните в отдел обслуживания клиентов
Если ни один из методов не работает для вас, лучше всего позвонить в отдел обслуживания клиентов и принять их предложения. Они могут помочь вам в вызове, используя метку обслуживания, или могут предложить вам посетить Сервисный центр и решить эту проблему.
Установить пароль BIOS или UEFI
Установка пароля в BIOS или UEFI на самом деле не рекомендуется, но если вы решили, вот как вы можете это сделать. Тем не менее, интерфейс BIOS или UEFI варьируется от OEM к OEM. Так что ищите что-то связанное с БЕЗОПАСНОСТЬЮ или ПАРОЛЕМ. У вас будут варианты, похожие на
Некоторые производители предлагают микро контроль, где вам нужно будет ввести пароль BIOS. Например, вы получаете возможность пропустить обычный перезапуск или при выборе загрузочного устройства. Хотя вам может потребоваться ввести его для автоматической перезагрузки или при включении компьютера и т. Д.
Если вы хотите удалить пароль, найдите опцию удаления пароля в том же разделе. Вы получите приглашение, в котором вы можете ввести установленный пароль один раз. Если это правильно, он удалит пароль BIOS.
Как только вы закончите, убедитесь, что сохранили и выйдите из BIOS. Перезагрузите компьютер и посмотрите, правильно ли применены настройки.
Наконец, будьте очень осторожны с блокировками BIOS/UEFI. Вместо этого лучше использовать учетную запись Microsoft для блокировки компьютера.
Просто о сложном. Что такое UEFI и как его защитить?
Недавно аналитики ESET обнаружили первый в истории руткит для UEFI. Это новый и очень опасный тип вредоносных программ, который атакует компьютер до запуска Windows. В этом случае не поможет ни переустановка ОС, ни замена жесткого диска.
Ранее теоретические возможности руткитов для UEFI обсуждались только на конференциях по информационной безопасности. Сегодня киберпреступники используют их в реальных атаках.
Поэтому в новой версии ESET NOD32 для домашних пользователей мы усовершенствовали модуль «Сканер UEFI». Например, теперь пользователь может запустить «Сканер UEFI» вручную прямо в интерфейсе антивируса.
Однако большинство пользователей слабо представляют, что такое UEFI, чем он отличается от BIOS и зачем их защищать. Попробуем разобраться!
Коротко: в чем разница между BIOS и UEFI
BIOS — базовая система ввода-вывода (англ. Basic Input/Output System), которая хранится в материнской плате компьютера. BIOS начинает работу сразу при включении ПК, система запускает аппаратные компоненты и программу для загрузки Windows или другой операционной системы.
BIOS был разработан в далеком 1975 году, когда никто не мог и представить жесткий диск на 2 Тб. Сегодня это обычный объем памяти для домашнего компьютера. BIOS не поддерживает жесткие диски такого объема — это одна из причин, по его постепенно вытесняет UEFI.
Новые компьютеры используют UEFI — универсальный интерфейс расширяемой прошивки (англ. Unified Extensible Firmware Interface), но его все равно по старинке называют «биос», чтобы не путать пользователей лишний раз. UEFI — это современное решение, которое поддерживает жесткие диски большего объема, быстрее загружается, имеет понятный графический интерфейс и поддерживает управление мышью!
Зачем нужен BIOS?
BIOS используется загрузки ОС, проверки работоспособности «железа» и настройки ПК. Например, для изменения конфигурации жесткого диска, порядка загрузки ОС (с жесткого диска, флешки или другого носителя) и установки системного времени. Эти настройки сохранятся в памяти материнской платы.
Кроме того, BIOS проводит POST — самотестирование после включения (англ. Power-On Self Test) для проверки конфигурации оборудования. Если что-то не в порядке, выводится сообщение об ошибке или звуковой сигнал. Когда компьютер не включается и слышится «писк» из 8-битной игры — это работа BIOS. Чтобы понять, что именно сломалось, нужно найти инструкцию к материнской плате, которая объяснит значение того или иного звукового сигнала.
Почему BIOS устарел?
Со времени своего создания BIOS почти не развивался качественно. Выходили отдельные дополнения и расширения. Например, ACPI — усовершенствованный интерфейс управления конфигурацией и питанием (англ. Advanced Configuration and Power Interface).
Этот интерфейс упрощал установку BIOS и управление питанием, а также переходом в спящий режим. Однако этого было недостаточно, BIOS безнадежно застрял во временах MS-DOS. Например, BIOS может загружаться только с дисков объемом менее 2,1 Тб. Кроме того, у него есть проблемы с одновременной инициализацией нескольких аппаратных устройств, что приводит к замедлению загрузки на компьютерах с современными комплектующими.
В 1998 году компания Intel впервые задумалась о замене BIOS и начала работу над Extensible Firmware Interface (EFI) для недооцененной серии 64-разрядных процессоров Itanium. Для распространения нового интерфейса требовалась широкая поддержка всей отрасли. Apple выбрали EFI для Mac еще в 2006 году, но другие производители не последовали их примеру.
UEFI к нам приходит
Как открыть настройки UEFI?
Для обычных пользователей переход от BIOS к UEFI прошел незаметно. Новый ПК будет просто быстрее загружаться при включении. Однако если вам понадобился доступ UEFI, то он будет отличаться в зависимости от операционной системы.
Windows 8
Windows 10
В Win 10 в UEFI можно попытаться зайти по старинке:
Доступ из операционной системы:
Чтобы включить или отключить (чего мы делать не рекомендуем!) модуль «Сканер UEFI»:
Расширенные параметры (F5) — Модуль обнаружения — Процессы сканирования вредоносных программ
Расширенные параметры (F5) — Модуль обнаружения — Защита файловой системы в режиме реального времени