- 28,322
- 46
- 8 Ноя 2022
11 файлов, о которых забыла Microsoft, держали открытой дверь в самое ядро компьютера.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/676;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Механизм Secure Boot должен блокировать вредоносный код ещё до запуска Windows или Linux. Однако исследователи ESET обнаружили, что защиту можно было обходить почти всё время её существования с помощью старых загрузочных файлов, которые Microsoft продолжала считать доверенными. Некоторые из них оставались действительными больше десяти лет после появления известных уязвимостей.
Проблема затрагивала специальные компоненты под названием shim. Их создали, чтобы распространить Secure Boot на Linux и служебные программы, которые запускаются до операционной системы. Microsoft подписывала такие файлы своей цифровой подписью, после чего прошивка компьютера разрешала им работать во время загрузки.
Исследователи нашли 11 уязвимых образов shim. Самый ранний из известных файлов появился ещё в 2013 году, спустя год после запуска Secure Boot. Уязвимости в этих компонентах давно были известны, однако Microsoft не внесла их в списки отзыва. В результате компьютер продолжал доверять старым версиям, хотя злоумышленники могли использовать их для запуска неподписанного или вредоносного кода.
Для атаки не требовалась новая уязвимость или сложная техника. Достаточно было получить копию одного из устаревших, но всё ещё действующих shim-файлов и понимать общую схему загрузки UEFI. После запуска такого компонента атакующий мог нарушить цепочку проверки подписей и установить вредоносную программу на раннем этапе включения компьютера.
Опасность распространялась как на Linux, так и на Windows. Shim изначально предназначался прежде всего для Linux, однако прошивка UEFI не привязывает доверенный загрузочный файл к конкретной операционной системе. Если компонент имеет действительную подпись Microsoft, его можно запустить и на компьютере с Windows.
После обхода Secure Boot злоумышленник получает возможность установить буткит. Так называют вредоносную программу, которая запускается до операционной системы и вмешивается в загрузку компьютера. Подобное ПО трудно обнаружить обычным антивирусом, поскольку оно начинает работать раньше большинства защитных средств.
Буткит может сохраняться после переустановки Windows или Linux и даже после замены основного накопителя, если вредоносный код записан в прошивку или отдельный системный раздел. Атакующий получает устойчивый доступ к устройству и может подменять компоненты системы, отключать средства защиты или загружать дополнительное вредоносное ПО.
Secure Boot появился в 2012 году именно для защиты от подобных атак. Механизм проверяет цифровую подпись каждого компонента, который запускается при включении компьютера. Если файл не подписан доверенным сертификатом или ранее был отозван, прошивка должна остановить загрузку.
За прошедшие годы специалисты обнаружили несколько реальных буткитов, включая LoJax, MosaicRegressor, CosmicStrand и BlackLotus . Некоторые из них связывали с государственными группировками, другие продавались на подпольных форумах. Большинству таких атак требуется физический доступ к устройству, хотя отдельные цепочки заражения позволяют установить буткит удалённо после получения высоких привилегий в системе.
Защита от кратковременного физического доступа входит в число задач Secure Boot. Например, злоумышленник может ненадолго получить выключенный ноутбук, загрузить уязвимый компонент с внешнего носителя и установить вредоносный код до возвращения устройства владельцу.
Список, подготовленный CERT, включает shim-файлы, связанные с Red Hat, openSUSE, Oracle и сторонними программами. Среди них оказался компонент финской компании PC-Doctor, который использовался в системе проведения государственных экзаменов. Часть файлов выпустили до появления современных механизмов отзыва, другие содержали ошибки в собственном коде или разрешали запуск уязвимых компонентов второго этапа загрузки.
В Windows главным источником доверия служит загрузчик Microsoft, подписанный основным сертификатом компании. Каждый следующий компонент должен пройти проверку перед запуском. Linux использует другую схему, поскольку Microsoft не может подписывать отдельно все загрузчики, ядра и служебные программы каждого дистрибутива.
Shim решает проблему с помощью дополнительного уровня доверия. Microsoft подписывает небольшой универсальный загрузчик, а внутрь него разработчик Linux или производитель программы помещает собственный сертификат. После запуска shim уже сам проверяет остальные компоненты системы.
Подобная конструкция позволяет разработчикам обновлять Linux без постоянного обращения к Microsoft за подписью каждого файла. Одновременно она создаёт дополнительную точку риска. Если уязвимый shim остаётся доверенным, его встроенный сертификат может разрешить запуск других небезопасных компонентов.
Microsoft отвечает за отзыв скомпрометированных shim-файлов. После обнаружения уязвимости компания должна добавить цифровой отпечаток компонента или его сертификат в специальный список запретов. В случае 11 найденных образов этого не произошло, а некоторые версии оставались действительными больше десяти лет.
Компания отозвала их только в июньском пакете обновлений после того, как ESET передала информацию Microsoft и специалистам CERT. Причины столь долгой задержки пока не раскрыты.
Управление доверенными компонентами Secure Boot устроено сложно. Прошивка использует две основные базы данных. В db хранятся разрешённые сертификаты и цифровые отпечатки файлов, а dbx содержит сведения о компонентах, которым доверять больше нельзя.
Перед запуском система проверяет оба списка. Файл должен иметь подпись из разрешённой базы и одновременно отсутствовать среди отозванных компонентов. Если уязвимый загрузчик остаётся в db и не попадает в dbx, компьютер продолжает считать его безопасным.
Прямое добавление каждого небезопасного Linux-компонента в dbx оказалось непрактичным. Для базы отвели всего 32 КБ, а количество загрузчиков, ядер и служебных файлов постоянно растёт. Поэтому разработчики создали дополнительные механизмы отзыва по версиям.
Один из них называется Secure Boot Advanced Targeting, или SBAT. Вместо цифрового отпечатка отдельного файла система хранит название компонента и номер его поколения. После исправления уязвимости разработчик повышает номер версии, а политика Secure Boot запрещает запуск всех предыдущих поколений.
Похожий принцип использует показатель Security Version Number, сокращённо SVN. Оба механизма позволяют отозвать сразу целую группу уязвимых сборок, не заполняя ограниченную базу длинным перечнем хешей.
Каждый совместимый компонент содержит подписанные метаданные с названием и номером поколения. Во время загрузки shim сравнивает сведения с минимально допустимой версией. Если номер ниже установленного порога, файл не запускается.
Проверка распространяется и на сам shim. Теоретически обновлённая политика может заставить устаревший загрузчик отклонить собственный запуск. Затем та же процедура применяется к каждому следующему файлу в цепочке.
Проблема заключалась в том, что часть найденных компонентов появилась раньше SBAT и других современных защитных механизмов. Некоторые shim-файлы не проверяли списки запрета Machine Owner Key, известные как MOK deny list. Другие разрешали запуск программ с давно известными уязвимостями.
Например, shim Oracle доверял вторичному компоненту, уязвимому для атаки CVE-2015-5381. По оценке ESET, воспользоваться ошибкой мог даже специалист без большого опыта. Отдельные файлы содержали собственные дефекты, которые позволяли обойти проверку загрузочной цепочки.
Истечение срока действия сертификата Microsoft тоже не решало проблему автоматически. UEFI продолжает доверять ранее подписанным файлам, пока они не внесены в список отзыва. Поэтому окончание срока сертификата, которым подписали старые shim-компоненты, само по себе не блокировало их запуск.
После установки июньских обновлений Microsoft уязвимые файлы должны перестать работать на затронутых устройствах с Windows. Компьютеры Windows 11 класса Secured-core, вероятно, не подвергались атаке при настройках по умолчанию благодаря дополнительным средствам защиты.
Пользователям Linux необходимо проверить рекомендации своего дистрибутива и сведения в Linux Vendor Firmware Service. Состояние базы отзыва можно также проверить с помощью сценария uefi-dbx-audit. Одного обновления операционной системы может оказаться недостаточно, если производитель ещё не распространил новую политику Secure Boot для конкретного устройства.
История с уязвимыми shim-файлами показывает слабое место всей модели. Надёжность Secure Boot зависит не только от криптографии, но и от постоянного учёта тысяч подписанных компонентов. Один забытый загрузчик может сохранить доверие на годы и открыть путь для кода, который защита должна была остановить.
Microsoft фактически выступает центральным доверенным участником экосистемы UEFI. Компания подписывает компоненты разных производителей и отвечает за своевременный отзыв небезопасных версий. Чем больше становится загрузчиков, сертификатов и дополнительных механизмов проверки, тем сложнее контролировать всю цепочку.
Исследователи пока не сообщили о реальных атаках с применением найденных 11 shim-файлов. Однако готовые компоненты находились в открытом доступе, а для обхода не требовались новые эксплойты. На протяжении многих лет злоумышленнику могло хватить старого подписанного файла и сравнительно простого сценария запуска.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/676;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Механизм Secure Boot должен блокировать вредоносный код ещё до запуска Windows или Linux. Однако исследователи ESET обнаружили, что защиту можно было обходить почти всё время её существования с помощью старых загрузочных файлов, которые Microsoft продолжала считать доверенными. Некоторые из них оставались действительными больше десяти лет после появления известных уязвимостей.
Проблема затрагивала специальные компоненты под названием shim. Их создали, чтобы распространить Secure Boot на Linux и служебные программы, которые запускаются до операционной системы. Microsoft подписывала такие файлы своей цифровой подписью, после чего прошивка компьютера разрешала им работать во время загрузки.
Исследователи нашли 11 уязвимых образов shim. Самый ранний из известных файлов появился ещё в 2013 году, спустя год после запуска Secure Boot. Уязвимости в этих компонентах давно были известны, однако Microsoft не внесла их в списки отзыва. В результате компьютер продолжал доверять старым версиям, хотя злоумышленники могли использовать их для запуска неподписанного или вредоносного кода.
Для атаки не требовалась новая уязвимость или сложная техника. Достаточно было получить копию одного из устаревших, но всё ещё действующих shim-файлов и понимать общую схему загрузки UEFI. После запуска такого компонента атакующий мог нарушить цепочку проверки подписей и установить вредоносную программу на раннем этапе включения компьютера.
Опасность распространялась как на Linux, так и на Windows. Shim изначально предназначался прежде всего для Linux, однако прошивка UEFI не привязывает доверенный загрузочный файл к конкретной операционной системе. Если компонент имеет действительную подпись Microsoft, его можно запустить и на компьютере с Windows.
После обхода Secure Boot злоумышленник получает возможность установить буткит. Так называют вредоносную программу, которая запускается до операционной системы и вмешивается в загрузку компьютера. Подобное ПО трудно обнаружить обычным антивирусом, поскольку оно начинает работать раньше большинства защитных средств.
Буткит может сохраняться после переустановки Windows или Linux и даже после замены основного накопителя, если вредоносный код записан в прошивку или отдельный системный раздел. Атакующий получает устойчивый доступ к устройству и может подменять компоненты системы, отключать средства защиты или загружать дополнительное вредоносное ПО.
Secure Boot появился в 2012 году именно для защиты от подобных атак. Механизм проверяет цифровую подпись каждого компонента, который запускается при включении компьютера. Если файл не подписан доверенным сертификатом или ранее был отозван, прошивка должна остановить загрузку.
За прошедшие годы специалисты обнаружили несколько реальных буткитов, включая LoJax, MosaicRegressor, CosmicStrand и BlackLotus . Некоторые из них связывали с государственными группировками, другие продавались на подпольных форумах. Большинству таких атак требуется физический доступ к устройству, хотя отдельные цепочки заражения позволяют установить буткит удалённо после получения высоких привилегий в системе.
Защита от кратковременного физического доступа входит в число задач Secure Boot. Например, злоумышленник может ненадолго получить выключенный ноутбук, загрузить уязвимый компонент с внешнего носителя и установить вредоносный код до возвращения устройства владельцу.
Список, подготовленный CERT, включает shim-файлы, связанные с Red Hat, openSUSE, Oracle и сторонними программами. Среди них оказался компонент финской компании PC-Doctor, который использовался в системе проведения государственных экзаменов. Часть файлов выпустили до появления современных механизмов отзыва, другие содержали ошибки в собственном коде или разрешали запуск уязвимых компонентов второго этапа загрузки.
В Windows главным источником доверия служит загрузчик Microsoft, подписанный основным сертификатом компании. Каждый следующий компонент должен пройти проверку перед запуском. Linux использует другую схему, поскольку Microsoft не может подписывать отдельно все загрузчики, ядра и служебные программы каждого дистрибутива.
Shim решает проблему с помощью дополнительного уровня доверия. Microsoft подписывает небольшой универсальный загрузчик, а внутрь него разработчик Linux или производитель программы помещает собственный сертификат. После запуска shim уже сам проверяет остальные компоненты системы.
Подобная конструкция позволяет разработчикам обновлять Linux без постоянного обращения к Microsoft за подписью каждого файла. Одновременно она создаёт дополнительную точку риска. Если уязвимый shim остаётся доверенным, его встроенный сертификат может разрешить запуск других небезопасных компонентов.
Microsoft отвечает за отзыв скомпрометированных shim-файлов. После обнаружения уязвимости компания должна добавить цифровой отпечаток компонента или его сертификат в специальный список запретов. В случае 11 найденных образов этого не произошло, а некоторые версии оставались действительными больше десяти лет.
Компания отозвала их только в июньском пакете обновлений после того, как ESET передала информацию Microsoft и специалистам CERT. Причины столь долгой задержки пока не раскрыты.
Управление доверенными компонентами Secure Boot устроено сложно. Прошивка использует две основные базы данных. В db хранятся разрешённые сертификаты и цифровые отпечатки файлов, а dbx содержит сведения о компонентах, которым доверять больше нельзя.
Перед запуском система проверяет оба списка. Файл должен иметь подпись из разрешённой базы и одновременно отсутствовать среди отозванных компонентов. Если уязвимый загрузчик остаётся в db и не попадает в dbx, компьютер продолжает считать его безопасным.
Прямое добавление каждого небезопасного Linux-компонента в dbx оказалось непрактичным. Для базы отвели всего 32 КБ, а количество загрузчиков, ядер и служебных файлов постоянно растёт. Поэтому разработчики создали дополнительные механизмы отзыва по версиям.
Один из них называется Secure Boot Advanced Targeting, или SBAT. Вместо цифрового отпечатка отдельного файла система хранит название компонента и номер его поколения. После исправления уязвимости разработчик повышает номер версии, а политика Secure Boot запрещает запуск всех предыдущих поколений.
Похожий принцип использует показатель Security Version Number, сокращённо SVN. Оба механизма позволяют отозвать сразу целую группу уязвимых сборок, не заполняя ограниченную базу длинным перечнем хешей.
Каждый совместимый компонент содержит подписанные метаданные с названием и номером поколения. Во время загрузки shim сравнивает сведения с минимально допустимой версией. Если номер ниже установленного порога, файл не запускается.
Проверка распространяется и на сам shim. Теоретически обновлённая политика может заставить устаревший загрузчик отклонить собственный запуск. Затем та же процедура применяется к каждому следующему файлу в цепочке.
Проблема заключалась в том, что часть найденных компонентов появилась раньше SBAT и других современных защитных механизмов. Некоторые shim-файлы не проверяли списки запрета Machine Owner Key, известные как MOK deny list. Другие разрешали запуск программ с давно известными уязвимостями.
Например, shim Oracle доверял вторичному компоненту, уязвимому для атаки CVE-2015-5381. По оценке ESET, воспользоваться ошибкой мог даже специалист без большого опыта. Отдельные файлы содержали собственные дефекты, которые позволяли обойти проверку загрузочной цепочки.
Истечение срока действия сертификата Microsoft тоже не решало проблему автоматически. UEFI продолжает доверять ранее подписанным файлам, пока они не внесены в список отзыва. Поэтому окончание срока сертификата, которым подписали старые shim-компоненты, само по себе не блокировало их запуск.
После установки июньских обновлений Microsoft уязвимые файлы должны перестать работать на затронутых устройствах с Windows. Компьютеры Windows 11 класса Secured-core, вероятно, не подвергались атаке при настройках по умолчанию благодаря дополнительным средствам защиты.
Пользователям Linux необходимо проверить рекомендации своего дистрибутива и сведения в Linux Vendor Firmware Service. Состояние базы отзыва можно также проверить с помощью сценария uefi-dbx-audit. Одного обновления операционной системы может оказаться недостаточно, если производитель ещё не распространил новую политику Secure Boot для конкретного устройства.
История с уязвимыми shim-файлами показывает слабое место всей модели. Надёжность Secure Boot зависит не только от криптографии, но и от постоянного учёта тысяч подписанных компонентов. Один забытый загрузчик может сохранить доверие на годы и открыть путь для кода, который защита должна была остановить.
Microsoft фактически выступает центральным доверенным участником экосистемы UEFI. Компания подписывает компоненты разных производителей и отвечает за своевременный отзыв небезопасных версий. Чем больше становится загрузчиков, сертификатов и дополнительных механизмов проверки, тем сложнее контролировать всю цепочку.
Исследователи пока не сообщили о реальных атаках с применением найденных 11 shim-файлов. Однако готовые компоненты находились в открытом доступе, а для обхода не требовались новые эксплойты. На протяжении многих лет злоумышленнику могло хватить старого подписанного файла и сравнительно простого сценария запуска.
- Источник новости
- www.securitylab.ru
