На прошлой неделе компания BINARLY сообщила об утечке приватного ключа компании American Megatrends, который используется во множестве ноутбуков, компьютеров и серверов компаний Acer, Dell, GIGABYTE и Supermicro. Исследование BINARLY широко цитировалось в прессе (статья в издании Ars Technica, новость на сайте BleepingComputer, новость на Хабре), а сами первооткрыватели опубликовали подробный отчет. Разобраться в отчете, впрочем, нелегко, так как речь идет не о единичном случае утечки ключей для Secure Boot, а скорее о фундаментальном недосмотре ряда производителей, начало которому было положено еще в 2012 году.
Самое свежее событие в этом таймлайне относится к 2023 году: в январе компания BINARLY обнаружила публичный репозиторий на GitHub, в котором содержался один приватный ключ, в терминах экосистемы Secure Boot известный как Platform Key. Ключ был опубликован на GitHub в декабре 2022 года. Он был зашифрован, но при этом использовался четырехзначный пароль, который легко взломать. Этот ключ играет важную роль в обеспечении безопасности механизма Secure Boot. Потенциальный злоумышленник может с помощью Platform Key сгенерировать так называемый Key Exchange Key, а уже с его помощью подписать вредоносный компонент, который будет выполнен при загрузке компьютера. В итоге возникает риск серьезной компрометации системы, причем вредоносное ПО будет способно пережить полную переустановку ОС. Для реализации атаки потребуется физический доступ к ПК или серверу либо права администратора в системе. Второе вполне достижимо, а физический доступ открывает возможность реализации атаки класса supply chain: когда целая партия компьютеров «модифицируется» в пути от производителя к заказчику. Но самое важное, что это, скорее всего, не единственный приватный ключ, который можно считать скомпрометированным.
Как показано на скриншоте выше, утекший Platform Key снабжен интересным идентификатором в поле Issuer: DO NOT TRUST — AMI Test PK. Компания American Megatrends поставляет клиентам референсный код прошивок UEFI, содержащих механизм Secure Boot. Этот код использует тестовые ключи. Поставщик референсных прошивок ожидает, что производитель устройств поменяет тестовые ключи на свои собственные в финальных версиях UEFI. По данным издания Ars Technica, рекомендуется использование уникального ключа Platform Key для отдельной продуктовой линейки устройств или хотя бы для отдельного производителя. Вместо этого сразу несколько вендоров оставили в финальных прошивках тестовые ключи, предоставленные AMI. Именно поэтому в списке подверженных устройств оказались материнские платы, ноутбуки, десктопы и серверы разных производителей.
Следующим этапом исследования BINARLY стало сканирование большой базы прошивок UEFI для разных устройств на предмет обнаружения тестовых ключей, где в поле Issuer имеется строка «DO NOT TRUST» или «DO NOT SHIP». Таких ключей было обнаружено 22, соответственно, только один из них попал в открытый доступ через случайную утечку на GitHub (его можно идентифицировать по серийному номеру 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4). Это не значит, что устройства, использующие другие Platform Key, находятся в безопасности. Они распространялись в течение нескольких лет среди множества клиентов American Megatrends. Поскольку по природе своей ключи были «тестовыми», к ним, скорее всего, не применялись особые меры защиты. Есть ненулевая вероятность, что и другие ключи были или будут случайно опубликованы в общем доступе и что доступ к этим приватным ключам имеет большое количество людей в разных компаниях.
Помимо изначально пострадавших Acer, Dell, GIGABYTE и Supermicro, сканирование прошивок выявило наличие тестовых Platform Key в устройствах AOPEN, Fujitsu, Lenovo и HP. Список устройств, в прошивках которых были найдены тестовые ключи, выложен здесь. Этот список основан на тестировании большой базы прошивок, но может быть неполным. В нем более 800 устройств, из них более 200 содержат тот единственный ключ, который гарантированно утек в общий доступ. Для проверки прошивки других устройств BINARLY разработала публичный сервис по поиску небезопасных ключей, для проверки туда надо загрузить прошивку от вашего устройства. Значительную часть списка составляют материнские платы GIGABYTE, из устройств Lenovo представлено небольшое количество настольных ПК. Среди устройств Dell представлены как настольные ПК, так и ноутбуки, включая игровую серию Alienware.
Вернемся к таймлайну событий. Первое публичное упоминание использования тестовых Platform Key относится к 2016 году: тогда такой ключ был обнаружен в прошивке некоторых настольных ПК Lenovo. Ключ, попавший в конце 2022 года в открытый доступ на GitHub, используется в устройствах разных производителей начиная с 2018 года. Все 22 тестовых ключа используются начиная с 2012 года, а самые свежие прошивки реальных устройств с ними же датированы июнем 2024 года. По данным BINARLY, в их базе данных 10% прошивок используют тестовые ключи, либо 8%, если брать только прошивки, выпущенные за последние 4 года, — эти устройства с высокой вероятностью эксплуатируются и сегодня.
Свежее исследование BINARLY вновь выявляет фундаментальную проблему в реализации защитного механизма Secure Boot. Secure Boot изначально создавался как решение, предотвращающее запуск неавторизованного кода во время загрузки компьютера. Это разумный метод защиты в теории, на практике имеющий целый комплекс проблем. Утечка ключей, использование тестовых ключей в конечных устройствах — это организационная проблема. Есть и технические трудности: например, ранее мы писали о предыдущем исследовании BINARLY, в котором был показан метод атаки через подмену логотипа, демонстрируемого пользователю при включении ПК. Налицо трудности с контролем механизма безопасности, в разработке которого участвует широкий круг организаций. Вряд ли стоит ожидать массовой эксплуатации проблем в Secure Boot, но потенциал для таргетированных атак имеется, как это было показано в прошлом году на примере буткита BlackLotus. Особенность утечки тестового ключа (пока единственного) добавляет новые краски в теоретическую модель угроз: потенциальным злоумышленникам больше не надо эксплуатировать уязвимости в Secure Boot. На ограниченном числе устройств достаточно подкинуть подписанный по всем правилам вредоносный код.
На прошлой неделе были обнародованы новые детали инцидента с защитным решением CrowdStrike, о котором мы подробно рассказывали в предыдущем дайджесте. Компания CrowdStrike обновила техническое описание инцидента. Проблемный апдейт, разосланный клиентам, прошел внутренние процедуры тестирования. При этом он содержал информацию, обработка которой драйвером, работающим с наивысшими привилегиями, привела к сбою. Среди мер по предупреждению таких инцидентов в будущем упоминается как улучшение методов тестирования, так и постепенная рассылка обновлений клиентам, чтобы можно было определить сбой, когда он затрагивает крайне малую часть клиентских систем. Технический разбор инцидента также опубликовала компания Microsoft. Денежная оценка ущерба, нанесенного ошибкой в обновлении CrowdStrike Falcon, варьируется от одного до пяти с лишним миллиардов долларов.
«Лаборатория Касперского» поделилась собственным взглядом на защиту обновлений программного обеспечения от сбоев, в котором также упоминается поэтапное распространение обновлений, начиная с тестирования во внутренней сети компании, как один из методов защиты от ошибок.
Еще одна публикация экспертов «Лаборатории Касперского» разбирает новый инцидент с известным кибершпионским ПО Mandrake, которое снова смогло попасть в составе нескольких приложений в магазин Google Play.
На прошлой неделе также широко обсуждался инцидент в компании KnowBe4, о котором они сами подробно рассказали у себя в блоге. К ним успешно смог устроиться на удаленную работу «хакер из Северной Кореи». Аноним, использующий украденные персональные данные жителя США, а также сгенерированные нейросетью фото (и возможно, видео), прошел все раунды собеседования, а его странности обнаружились лишь после отправки рабочего ноутбука: на устройство попытались загрузить вредоносное ПО.
Самое свежее событие в этом таймлайне относится к 2023 году: в январе компания BINARLY обнаружила публичный репозиторий на GitHub, в котором содержался один приватный ключ, в терминах экосистемы Secure Boot известный как Platform Key. Ключ был опубликован на GitHub в декабре 2022 года. Он был зашифрован, но при этом использовался четырехзначный пароль, который легко взломать. Этот ключ играет важную роль в обеспечении безопасности механизма Secure Boot. Потенциальный злоумышленник может с помощью Platform Key сгенерировать так называемый Key Exchange Key, а уже с его помощью подписать вредоносный компонент, который будет выполнен при загрузке компьютера. В итоге возникает риск серьезной компрометации системы, причем вредоносное ПО будет способно пережить полную переустановку ОС. Для реализации атаки потребуется физический доступ к ПК или серверу либо права администратора в системе. Второе вполне достижимо, а физический доступ открывает возможность реализации атаки класса supply chain: когда целая партия компьютеров «модифицируется» в пути от производителя к заказчику. Но самое важное, что это, скорее всего, не единственный приватный ключ, который можно считать скомпрометированным.
Как показано на скриншоте выше, утекший Platform Key снабжен интересным идентификатором в поле Issuer: DO NOT TRUST — AMI Test PK. Компания American Megatrends поставляет клиентам референсный код прошивок UEFI, содержащих механизм Secure Boot. Этот код использует тестовые ключи. Поставщик референсных прошивок ожидает, что производитель устройств поменяет тестовые ключи на свои собственные в финальных версиях UEFI. По данным издания Ars Technica, рекомендуется использование уникального ключа Platform Key для отдельной продуктовой линейки устройств или хотя бы для отдельного производителя. Вместо этого сразу несколько вендоров оставили в финальных прошивках тестовые ключи, предоставленные AMI. Именно поэтому в списке подверженных устройств оказались материнские платы, ноутбуки, десктопы и серверы разных производителей.
Следующим этапом исследования BINARLY стало сканирование большой базы прошивок UEFI для разных устройств на предмет обнаружения тестовых ключей, где в поле Issuer имеется строка «DO NOT TRUST» или «DO NOT SHIP». Таких ключей было обнаружено 22, соответственно, только один из них попал в открытый доступ через случайную утечку на GitHub (его можно идентифицировать по серийному номеру 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4). Это не значит, что устройства, использующие другие Platform Key, находятся в безопасности. Они распространялись в течение нескольких лет среди множества клиентов American Megatrends. Поскольку по природе своей ключи были «тестовыми», к ним, скорее всего, не применялись особые меры защиты. Есть ненулевая вероятность, что и другие ключи были или будут случайно опубликованы в общем доступе и что доступ к этим приватным ключам имеет большое количество людей в разных компаниях.
Помимо изначально пострадавших Acer, Dell, GIGABYTE и Supermicro, сканирование прошивок выявило наличие тестовых Platform Key в устройствах AOPEN, Fujitsu, Lenovo и HP. Список устройств, в прошивках которых были найдены тестовые ключи, выложен здесь. Этот список основан на тестировании большой базы прошивок, но может быть неполным. В нем более 800 устройств, из них более 200 содержат тот единственный ключ, который гарантированно утек в общий доступ. Для проверки прошивки других устройств BINARLY разработала публичный сервис по поиску небезопасных ключей, для проверки туда надо загрузить прошивку от вашего устройства. Значительную часть списка составляют материнские платы GIGABYTE, из устройств Lenovo представлено небольшое количество настольных ПК. Среди устройств Dell представлены как настольные ПК, так и ноутбуки, включая игровую серию Alienware.
Вернемся к таймлайну событий. Первое публичное упоминание использования тестовых Platform Key относится к 2016 году: тогда такой ключ был обнаружен в прошивке некоторых настольных ПК Lenovo. Ключ, попавший в конце 2022 года в открытый доступ на GitHub, используется в устройствах разных производителей начиная с 2018 года. Все 22 тестовых ключа используются начиная с 2012 года, а самые свежие прошивки реальных устройств с ними же датированы июнем 2024 года. По данным BINARLY, в их базе данных 10% прошивок используют тестовые ключи, либо 8%, если брать только прошивки, выпущенные за последние 4 года, — эти устройства с высокой вероятностью эксплуатируются и сегодня.
Свежее исследование BINARLY вновь выявляет фундаментальную проблему в реализации защитного механизма Secure Boot. Secure Boot изначально создавался как решение, предотвращающее запуск неавторизованного кода во время загрузки компьютера. Это разумный метод защиты в теории, на практике имеющий целый комплекс проблем. Утечка ключей, использование тестовых ключей в конечных устройствах — это организационная проблема. Есть и технические трудности: например, ранее мы писали о предыдущем исследовании BINARLY, в котором был показан метод атаки через подмену логотипа, демонстрируемого пользователю при включении ПК. Налицо трудности с контролем механизма безопасности, в разработке которого участвует широкий круг организаций. Вряд ли стоит ожидать массовой эксплуатации проблем в Secure Boot, но потенциал для таргетированных атак имеется, как это было показано в прошлом году на примере буткита BlackLotus. Особенность утечки тестового ключа (пока единственного) добавляет новые краски в теоретическую модель угроз: потенциальным злоумышленникам больше не надо эксплуатировать уязвимости в Secure Boot. На ограниченном числе устройств достаточно подкинуть подписанный по всем правилам вредоносный код.
Что еще произошло
На прошлой неделе были обнародованы новые детали инцидента с защитным решением CrowdStrike, о котором мы подробно рассказывали в предыдущем дайджесте. Компания CrowdStrike обновила техническое описание инцидента. Проблемный апдейт, разосланный клиентам, прошел внутренние процедуры тестирования. При этом он содержал информацию, обработка которой драйвером, работающим с наивысшими привилегиями, привела к сбою. Среди мер по предупреждению таких инцидентов в будущем упоминается как улучшение методов тестирования, так и постепенная рассылка обновлений клиентам, чтобы можно было определить сбой, когда он затрагивает крайне малую часть клиентских систем. Технический разбор инцидента также опубликовала компания Microsoft. Денежная оценка ущерба, нанесенного ошибкой в обновлении CrowdStrike Falcon, варьируется от одного до пяти с лишним миллиардов долларов.
«Лаборатория Касперского» поделилась собственным взглядом на защиту обновлений программного обеспечения от сбоев, в котором также упоминается поэтапное распространение обновлений, начиная с тестирования во внутренней сети компании, как один из методов защиты от ошибок.
Еще одна публикация экспертов «Лаборатории Касперского» разбирает новый инцидент с известным кибершпионским ПО Mandrake, которое снова смогло попасть в составе нескольких приложений в магазин Google Play.
На прошлой неделе также широко обсуждался инцидент в компании KnowBe4, о котором они сами подробно рассказали у себя в блоге. К ним успешно смог устроиться на удаленную работу «хакер из Северной Кореи». Аноним, использующий украденные персональные данные жителя США, а также сгенерированные нейросетью фото (и возможно, видео), прошел все раунды собеседования, а его странности обнаружились лишь после отправки рабочего ноутбука: на устройство попытались загрузить вредоносное ПО.