Что такое bios атака
Заражение микросхемы BIOS в компьютере до сих пор считалось чем-то из области фантастики. Именно BIOS (Basic Input/Output System) отвечает за сохранение конфигурации системы в неизменном виде, а также за исполнение базовых функций ввода и вывода информации. Тем не менее, два аргентинских специалиста, Альфредо Ортега (Alfredo Ortega) и Анибал Сакко (Anibal Sacco) из компании Core Security Technologies показали на конференции по информационной безопасности CanSecWest успешное введение в BIOS специальной программы для удаленного управления, или руткита (rootkit). В частности, им удалось на глазах зрителей заразить компьютеры с операционными системами Windows и OpenBSD, а также виртуальную машину OpenBSD на платформе VMware Player.
Хотя для заражения BIOS по методу Ортеги и Сакко необходимо заранее скомпрометировать машину или иметь физический доступ к машине, последствия такого заражения оказались просто ужасными – даже после полного стирания информации на жестком диске, перепрошивки BIOS и переустановки операционной системы при следующей перезагрузке машина вновь оказывается заражена. Подробнее об атаке на BIOS можно прочитать в блоге ThreatPost.
У меня на материнке перемычка есть, запрещающая перезапись :)
> Или нашли какую-нить одну материнку, потыкались и побежали на конференцию?
Для этой чумы достаточно одной марки. Только есть подозрение, что на всех аналогичных тоже сработает.
Насколько помню: основная проблема вирусов сидящих в mbr/boot является защищенный режим ОС. Как они это обошли, интересно? На ум приходят только фантастика с VM, да всякие транслируемые блоки типа DSDT.
> Скоро руткиты будут в микрокод процессора внедрять
А Вы уверены, что их там нет с завода (например, для отслеживания нелицензионного содержимого)? :(((
>> даже после полного стирания информации на жестком диске, перепрошивки BIOS и переустановки операционной системы при следующей перезагрузке машина вновь оказывается заражена
> И где же вирус в таком случае прячется? В блоке питания?
При перепрошивке ОС загружается или нет? Так вот, вирус активируется в ОЗУ и после прошивки восстанавливается во флэш-памяти.
Мораль: материнки, в которых микросхема БИОС впаяна намертво, а не вставлена в кроватку, опасны, ибо в стандартном программаторе (которому вирусы пофиг, всё сотрёт) их не перешьёшь -- или надо срочно добывать приспопобы, позволяющие программатору работать с микросхемами прямо на материнке, ибо перепай -- операция несколько рискованная.
> При перепрошивке ОС загружается или нет? Так вот, вирус активируется в ОЗУ и после прошивки восстанавливается во флэш-памяти.
> даже после полного стирания информации на жестком диске, перепрошивки BIOS и переустановки операционной системы при следующей перезагрузке машина вновь оказывается заражена
Ну, если шить из зараженной операционной системы, то возможно. Но какой идиот так будет делать? ИМХО даже из "здоровой" - глупо. Шить (если не программатором) средствами самой БИОС, есть защищенный от записи участок флэш, в котором и хранится этот монитор, или загрузив с защищенного от записи носителя ДОС ( если угодно - Линукс с лайвсиди).
Биосм в оперативке висит, при перепрошивке у тебя только микросхемка гакается, а оперативка со старым, зараженным не отключается и руткит свободно пишет себя в новый биос. Так-то. К.О.
> И где же вирус в таком случае прячется? В блоке питания?
Ужас, нужно не допускать никого к своим "железкам", а то мало ли монитор или хуже того, мышь заразят.
А ещё при физическом доступе к машине можно сломать пополам материнскую плату.
>Да я сносил, а они (вирусы) в шлейфах сидят! А потом опять размножаются!
Продам, освященные патриком, провода и шлейфы для компьютера, не подверженные заразе, 100 баксов/метр.
>А ваще, вспомним чернобыль - очень веселый вирус, кстати.
+1, он у меня был первым и последним вирем, вот только начиная с июня, а дальше я его почикал, оставив себе копию :)
>> Скоро руткиты будут в микрокод процессора внедрять
>А Вы уверены, что их там нет с завода (например, для отслеживания нелицензионного содержимого)? :(((
Закладки в железе могут быть внедрены отнюдь не для столь мирных целей, а целей контроля военными штатов инфраструктуры врага, которому поставляется в огромных кол-вах железо, если вдруг начнутся боевые действия. Пропиетарное ПО тоже может их содержать.
> То уязвимости в процессорах, то заражение биоса.. Что дальше?
Рак северного моста. Прийдётся покупать антивирусные наклейки на корпус.
> А ещё при физическом доступе к машине можно сломать пополам материнскую плату.
Сломанная пополам материнка не может рассылать спам.
> но патч биоса лишь позволяет работать руткиту, а не сам является руткитом.
>перепрошивка биоса из под дос при условии отформатированного винта не даст вирусу далее работать.
При загрузке ЛЮБОЙ (. ) ОС вначале вызывается загрузочный блок биоса, который считывает с диска загрузочный сектор и передаёт ему управление. Это так в тех компьютерах, в которых есть БИОС. (В IBM PC XT было НЕПРОГРАММИРУЕМОЕ СХЕМНОЕ решение, считывавшее загрузочный блок с диска и передававшее ему управление. Во всех последующих аппаратах был БИОС.) Так вот, руткит активируется ДО СЧИТЫВАНИЯ загрузочной информации с диска -- и садится в память. Всё, машина заражена.
> Насколько помню: основная проблема вирусов сидящих в mbr/boot является защищенный режим ОС. Как они это обошли, интересно? На ум приходят только фантастика с VM, да всякие транслируемые блоки типа DSDT.
Ничего фантастического. Никто не мешает перехватывать обращения к диску и патчить ядро, вставляя переходы на свой код, который сидит в резидентной памяти. Для примера под winnt смотреть bootkit, очень понятный и грамотный код.
ЗЫ Догадайтесь у каких устройст есть документрованная команда download microcode? Если кто не догадался, тут недавно вирус был, он на эти девайсы просто пароль ставил. Кстати тоже фича стандарта, и все устройства это поддерживают =)
Забавно. Если бы я отвечал за безопасность, то ногти бы уже сгрыз по локоть из-за отсутствия отечественной базы по разработке и производству вычислительной и офисной техники.
> И где же вирус в таком случае прячется? В блоке питания?
В памяти. И тут же восстановит себя в прошивке
после её перешивания - перезагрузиться просто не
успеешь.
> а биос обнулить достав батарейку не?
Это обнуляет не биос, а cmos nvram с настройками
биос-сетапа.
Это реально жопа. Особенно учитывая то, что биос может быть заражен прямо у производителя.
Ботнет прямо из магазина.
> И где же вирус в таком случае прячется? В блоке питания? В памяти. И тут же восстановит себя в прошивке после её перешивания - перезагрузиться просто не успеешь.
А разве "обычный" бутовый вирус не так же работает? И ничего, лечится.
> А разве "обычный" бутовый вирус не так же работает? И ничего,
> лечится.
Немного не так. Код биоса может сидеть в shadow ram, доступ
к которой на запись запрещён средствами чипсета (в отличии
от запрета записи на уровне защиты страниц, которую антивирь
мог бы обойти). Бутовый вирус в shadow ram не залез бы.
Кроме того, биосовый вирус может и в smm memory сидеть,
где его и по чтению сложно обнаружить будет.
Одним словом, раздолья тут гораздо больше, а антивирус отдыхает.
Наверное, разработчики антивирусов тоже будут пытаться что-то
придумать, но в данной ситуации им не позавидовать. Если вирусу
удалось спуститься на уровень ниже, заручившись аппаратной
защитой, то на какое-то время разрабы антивирусов будут в
глубоком ауте, куда им, в общем то, и дорога. :)
Когда-то давно, в начале 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 , но пока справляются. Безумству храбрых, и все такое.
Заключение
С защитами от прошивки более или менее разобрались, в следующей части поговорим об SMM и атаках на него.
Буду рад любым вопросам и комментариям. Спасибо за внимание.
Продолжаем начатый в прошлом посте разговор о безопасности 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.
Спасибо за внимание, безопасных вам прошивок.
P.S.
Не могу не поблагодарить тов. d_olex за его статьи об SMM и атаках на него — раз и два. Для интересующихся темой и умеющих читать по-английски — обе обязательны к прочтению.
Недавно аналитики ESET обнаружили первый в истории руткит для UEFI. Это новый и очень опасный тип вредоносных программ, который атакует компьютер до запуска Windows. В этом случае не поможет ни переустановка ОС, ни замена жесткого диска.
Ранее теоретические возможности руткитов для UEFI обсуждались только на конференциях по информационной безопасности. Сегодня киберпреступники используют их в реальных атаках.
Поэтому в новой версии ESET NOD32 для домашних пользователей мы усовершенствовали модуль «Сканер UEFI». Например, теперь пользователь может запустить «Сканер UEFI» вручную прямо в интерфейсе антивируса.
Однако большинство пользователей слабо представляют, что такое UEFI, чем он отличается от 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, так что у пользователей остается возможность работать на устаревших ОС остается (прим. ред. — это небезопасно!)
Новый стандарт позволяет избежать ограничений BIOS. UEFI может загружать ОС с дисков, объем которых превышает 2,2 Тб. Фактический предел для них составляет 9,4 зеттабайт . Это примерно в три раза превышает предполагаемый объем всех данных в Интернете.
UEFI поддерживает 32-битный или 64-битный режимы, а его адресное пространство больше, чем у BIOS – что значительно ускоряет загрузку. Кроме того, экран настройки UEFI обладает более гибким функционалом с поддержкой мыши и пользовательским интерфейсом.
Поддержка Secure Boot позволяет проверить, что загрузку ОС не изменила вредоносная программа. UEFI позволяет проводить удаленную настройку и отладку. BIOS так не умеет.
По сути, UEFI — самостоятельная операционная система, работающая поверх прошивки ПК. Она может храниться во флэш-памяти на материнской плате или загружаться из других источников (жесткий диск и другие носители).
Материнские платы с UEFI от разных производителей будут иметь разный интерфейс и функционал. Все зависит от конкретной модели, но базовые настройки будут одинаковыми для любого компьютера.
Как открыть настройки UEFI?
Для обычных пользователей переход от BIOS к UEFI прошел незаметно. Новый ПК будет просто быстрее загружаться при включении. Однако если вам понадобился доступ UEFI, то он будет отличаться в зависимости от операционной системы.
Windows 8
- Нажмите Win + C
- Настройки — Изменить настройки ПК
- В разделе «Настройки ПК» выберите «Общие»
- В разделе «Расширенный пуск» щелкните «Перезагрузить»
- После перезагрузки появится меню загрузки Windows 8
- В меню загрузки выберите «Поиск неисправности» — «Расширенные настройки» — «Настройка прошивки UEFI»
- Для перезагрузки системы и входа в UEFI нажмите «Перезагрузка»
Windows 10
В Win 10 в UEFI можно попытаться зайти по старинке:
- Нажмите и удерживайте кнопку питания 5 секунд
- Как только на экране появится логотип, быстро нажимайте F2 или DEL (на некоторых моделях ноутбуков клавиши могут быть другими)
Доступ из операционной системы:
- В поле поиска введите «Параметры»
- Настройки — Обновление и безопасность — Восстановление
- В разделе «Особые варианты загрузки» нажмите «Перезагрузить сейчас»
- Система перезагрузится и покажет меню загрузки Windows 10
- Устранение неполадок — Дополнительные параметры — Параметры UEFI
- Для перезагрузки системы и входа в UEFI нажмите «Перезагрузка»
Чтобы включить или отключить (чего мы делать не рекомендуем!) модуль «Сканер UEFI»:
Расширенные параметры (F5) — Модуль обнаружения — Процессы сканирования вредоносных программ
Расширенные параметры (F5) — Модуль обнаружения — Защита файловой системы в режиме реального времени
В конце октября мне довелось побывать еще на одной конференции в латинской Америке. На этот раз в Аргентине на EKOparty в Буэнос-Айресе. Это была юбилейная десятая конференция и ребятам удалось организовать грандиозный эвент на 2000 человек. Мне уже во второй довелось побывать на этой конференции, и она мне запомнилась в первую очередь высоким качеством докладов, из которых довольно много на различные низкоуровневые темы.
На этой конференции мы вместе с Юрием Булыгиным представляли исследования нашей команды Intel Advanced Threat Research (ATR) . В состав которой я в хожу с момента ее основания в начале этого года. Итак, первый наш доклад "BIOS and Secure Boot Attacks Uncovered" был логическим продолжением исследования безопасности современных BIOS, которое было представлено ранее на конференции Defcon в этом году.
Но мы не остановились на одном докладе и представили еще одно наше новое исследование "BERserk: New RSA Signature Forgery Attack", связанное с классом уязвимостей позволяющей подделать цифровую подпись, которая сформирована с использованием алгоритма RSA.
Что приятно, оба наших доклада собрали полный зал, а это примерно около 1500 человек, что очень впечатляет, когда лицезреешь эту толпу со сцены.
Кстати, на стенде компании Core Security был обнаружен крайне занимательный девайс для каких-то шаманских методов криптоанализа:
Еще один забавный факт, это то что октябрь, как правило, является началом весны в Аргентине и стоит довольно приятная теплая погода, а кругом все расцветает.
EKOparty мне очень нравится, как конференция, а еще и сам Буэнос-Айрес довольно колоритный город в котором есть на что посмотреть. Но углубляться в достопримечательности этого города я не буду, лишь отмечу, что посетить его хотя бы раз в жизни точно стоит ;)
Один хакер может причинить столько же вреда, сколько 10 000 солдат! Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!
Читайте также: