Госучреждениям и промышленности России угрожают буткиты для BIOS

Госучреждениям и промышленности России угрожают буткиты для BIOS

Госучреждениям и промышленности России угрожают буткиты для BIOS

До недавних пор бытовало мнение, что зловреды, внедряемые на стадии запуска BIOS/UEFI, практически не встречаются в дикой природе — из-за высокой стоимости разработки. Проведенное в Positive Technologies исследование опровергло этот миф: на самом деле каждый второй из известных буткитов засветился в целевых атаках.

Буткит — это по сути руткит, только запускается он до загрузки ОС и большинства антивирусных программ. Основная задача буткита — помочь другому вредоносу внедриться в обход защиты и прочно утвердиться в системе. Из-за сложности кода за его разработку хакеры, по данным PT, готовы платить до $5 тыс., за исходники — $ 10 тыс., а за буткит для UEFI — до $2 млн.

Эксперты проанализировали 39 семейств вредоносных программ этого класса, обнаруженных в период с 2005 года по 2021-й. Около трети из них составили PoC-разработки, остальные (27 семейств) использовались в кибератаках, в том числе APT-группами, такими как Careto, Winnti (APT41), FIN1 и APT28, она же Fancy Bear. Примеры массового распространения буткитов: Rovnix, Adushka (в PDF-отчете AhnLab за сентябрь 2012 именуется как Adusca), Android-зловред Oldboot.

Для доставки буткита злоумышленники могут использовать целевые имейл-рассылки, скрытую загрузку с сайтов (drive-by) или помощь других вредоносов. Исследование также показало, что три четверти буткитов были заточены под BIOS (некоторые также поддерживали режим UEFI). Подавляющее большинство зловредов поражали только MBR, некоторые — VBR (загрузочный сектор логического диска) или IPL (начальный загрузчик программы). Более универсальные коды поддерживали все три способа внедрения.

 

«Среди проанализированных нами буткитов 76% были разработаны под устаревший и небезопасный BIOS, — комментирует аналитик из Positive Technologies Яна Юракова. — Intel еще в 2020 году остановила поддержку BIOS, но некоторые компании не могут быстро обновить ИТ-инфраструктуру либо используют гипервизоры, в которых по умолчанию рекомендовано использовать BIOS. Из-за этого буткиты для заражения BIOS до сих пор не теряют своей актуальности. По нашей оценке, в России с такой проблемой чаще сталкиваются госучреждения и промышленность».

Начиная с 2020 года все буткиты, всплывшие в реальных атаках, были ориентированы на UEFI, в том числе MosaicRegressor, Trickboot, FinSpy/FinFisher, ESPEcter, MoonBounce, CosmicStrand. Иногда подобные функции добавляются к вредоносным программам — примером тому шифровальщики Satana и Petya, многофункциональный троян Trickbot.

Возможные варианты заражения прошивки UEFI, согласно PT:

  • атака на цепочку поставок;
  • физический доступ к устройству;
  • использование ошибок в конфигурации или механизме обновления;
  • удаленный способ, с предварительным повышением привилегий в системе до уровня ядра.

Росту популярности буткитов в среде киберкриминала, по мнению экспертов, способствует регулярное выявление уязвимостей в прошивках. В прошлом году в профильной базе американского института стандартов (NIST – NVD) появилось 18 записей об уязвимости UEFI; в 2020 году их было меньше — 12, в 2019-м — всего пять.

Предотвратить подобные заражения, по мнению PT, помогут следующие меры:

  • мониторинг потенциально опасных операции в системе (получение прямого доступа к жесткому диску, установка драйвера, чтение прошивки);
  • включение режима Secure Boot для UEFI;
  • запрет на загрузку ОС с недоверенных носителей;
  • проверка надежности каналов поставки перед каждым обновлением ОС и прошивки;
  • в случае с Android — соблюдение основных правил безопасности (не приобретать устройства в сомнительных магазинах, не загружать прошивки из ненадежных источников),

Обнаружить факт заражения буткитом поможет контроль целостности загрузочных записей и прошивок — с этой целью рекомендуется использовать решение класса Sandbox, способное обеспечить режим анализа с перезагрузкой системы.

С полной версией отчета можно ознакомиться на сайте ИБ-компании.

Критическая уязвимость в TLP позволяет обойти защиту Linux

В популярной утилите TLP, которую многие владельцы ноутбуков на Linux используют для управления энергопотреблением, обнаружили критическую уязвимость. Причём проблема нашлась во время обычной проверки пакета командой SUSE Security Team и располагается во вполне штатном коде.

Брешь получила идентификатор CVE-2025-67859 и затрагивает версию TLP 1.9.0, где появился новый profiles daemon.

Этот демон работает с root-правами и управляет профилями питания через D-Bus. Задумка хорошая, но реализация подвела: в механизме аутентификации Polkit нашлась логическая ошибка, которая фактически позволяет обойти проверку прав.

Как объясняют исследователи, демон должен был строго проверять, кто именно отправляет команды. Но из-за ошибки любой локальный пользователь мог взаимодействовать с ним без должной аутентификации — а значит, менять системные настройки питания от имени root.

На этом сюрпризы не закончились. В ходе анализа специалисты SUSE нашли ещё несколько проблем, уже связанных с исчерпанием ресурсов. В частности, механизм profile hold, который позволяет временно «зафиксировать» профиль питания, оказался совершенно без валидации. Локальный пользователь мог создавать неограниченное количество таких блокировок, причём без прав администратора.

В итоге это открывает прямую дорогу к DoS-атаке: демон начинает захлёбываться от бесконечных записей в структуре данных, куда попадают числа, строки с причиной и идентификаторы приложений — всё это полностью контролируется клиентом.

Любопытно, что SUSE вспомнила похожую историю с демоном управления питанием в GNOME: аналогичную проблему находили ещё несколько лет назад. Отдельно исследователи отметили вопросы к механизму «куки», которыми отслеживаются profile hold. Формально речь шла о предсказуемости значений, но в сочетании с отсутствием лимитов это лишь расширяло поверхность атаки.

К счастью, реакция была быстрой. SUSE сообщила об уязвимостях разработчикам ещё в декабре, и в версии TLP 1.9.1 проблема уже закрыта. В частности, число одновременных profile hold теперь жёстко ограничено числом 16, что убирает риск истощения ресурсов.

RSS: Новости на портале Anti-Malware.ru