Security Week 41: вредоносный код в UEFI

    Эксперты «Лаборатории Касперского» опубликовали интересное исследование, посвященное вредоносному коду MosaicRegressor. Код использует предположительно киберкриминальная группа с китайскими корнями, он интересен тем, что содержит модули для заражения компьютера через UEFI. Подобные буткиты по-прежнему считаются одними из наиболее сложных видов вредоносного ПО. В случае успешного заражения они позволяют повторно заражать операционную систему даже после переустановки.



    В данном случае было обнаружено несколько образов UEFI с уже встроенным вредоносным кодом. Этот код имеет единственную функцию — добавляет содержащийся внутри файл в папку автозагрузки ОС Windows. Дальнейшая атака развивается по типичному кибершпионскому сценарию, с кражей документов и отправкой иных данных на командные серверы. Еще один неожиданный нюанс данного исследования: вредоносный код в UEFI использует исходники, ранее попавшие в открытый доступ в результате взлома инфраструктуры компании Hacking Team.



    В зараженных образах UEFI были обнаружены четыре модуля, как показано на скриншоте выше. Два выполняют сервисные функции, в том числе отвечают за запуск вредоносного кода в нужный момент (прямо перед загрузкой операционной системы). Еще один представляет собой драйвер для файловой системы NTFS. Основной вредоносный модуль содержит в себе файл IntelUpdate.exe, который прописывается на SSD или жесткий диск в директорию автозапуска Windows.



    Два сервисных модуля и драйвер, судя по всему, позаимствованы из кода Vector-EDK. Это буткит, исходные коды которого попали в открытый доступ после масштабной утечки данных из компании Hacking Team. Эта организация, занимающаяся разработкой методов атаки на компьютерные системы по заказу государственных органов, сама подверглась взлому в 2015 году, в результате чего в открытый доступ попала как внутренняя переписка, так и обширная база знаний.

    К сожалению, идентифицировать метод заражения UEFI исследователям не удалось. Среди нескольких десятков жертв MosaicRegressor всего два пострадавших компьютера имели видоизмененный базовый загрузчик. Если опираться на ту же утечку из Hacking Team, то там предлагается заражение вручную, путем подключения к компьютеру USB-флешки, с которой загружается UEFI «с довеском». Удаленный патч UEFI исключать нельзя, но для этого понадобилось бы взломать процесс загрузки и инсталляции обновлений.

    Устанавливаемый на атакованные компьютеры шпионский модуль подключается к командному центру и скачивает необходимые для дальнейшей работы модули. Например, один из механизмов забирает недавно открытые документы, пакует их в архив с паролем и отправляет организаторам. Еще один интересный момент: для связи используются как традиционные методы коммуникации с управляющими серверами, так и работа через публичный почтовый сервис по протоколу POP3S/SMTP/IMAPS. Через почту происходит как загрузка модулей, так и отправка данных организаторам атаки.

    Что еще произошло


    The Register напоминает об окончании поддержки производителем почтового сервера Microsoft Exchange 2010. Авторы статьи отмечают, что из сети на данный момент доступны 139 тысяч серверов, обновления безопасности для которых скоро прекратятся. А Threatpost пишет о том, что обнаруженная в январе уязвимость в панели управления Microsoft Exchange (версий 2013–2019) до сих пор не закрыта на 61% серверов.

    В ПО HP Device Manager для управления тонкими клиентами этой компании обнаружен бэкдор, а точнее, сервисный аккаунт, забытый разработчиком.

    Несмотря на усилия Google, варианты вредоносного ПО Joker продолжают время от времени проходить верификацию магазина приложений Google Play. Зловред, как правило, подписывает жертв на платные услуги без их ведома.
    «Лаборатория Касперского»
    Ловим вирусы, исследуем угрозы, спасаем мир

    Комментарии 24

      +4
      Спасибо за статью, но в атакующих несколько разочарован, те же морды — те же ряды, ничего нового под луной. Про механизм заражения — абсолютное большинство прошивок на основе AMI Aptio4 и AptioV (т.е. почти все AMI-based UEFI реализации) имеют серьезную ошибку в настройке системы защиты прошивки от перезаписи: скрывают настройку, позволяющую отключить ее, из BIOS Setup, но при этом не удяляют ее ни из кода, ни из переменной Setup, ни из IFR-структур. В итоге обойти ее, зная модель ноутбука (и, иногда, версию его прошивки) можно однократной записью в переменную Setup из EFI shell (только искать нужно не CFG Lock, а BIOS Lock). После перезагрузки из того же шелла при помощи подходящей версии Flash Programming Tool можно прошить уже модифицированную как угодно прошивку, и она запуститься, если BootGuard отключен или неверно настроен.
        +1
        Я не спец в UEFI, но с самого начала относился к этой новинке с подозрением: слишком уж она всё усложняет и заставляет полностью менять инструментарий для работы с загрузчиками. Ну вот, так и вышло — нововведение, рекламируемое как «панацея от атак при загрузке» продержалось всего несколько лет.
        И что теперь — опять всё кардинально переделывать? Может, рано отказались от BIOS и MBR?
          +6
          Она даёт «потенциально больше возможностей для защиты», а так что то дырявое что то. Каждый по своему провинился.
          PS Старый «биос» был 16 битным, его нужно выпилить хотяб потому, чтоб выкинуть из чипов поддержку старого «реального» режима.
            +1
            Поддержку в итоге так и не выкинули до сих пор, потому что Интел уже раз обожглись на молоке (Itanium) и теперь так усиленно дуют на воду, что непонятно, когда уже наступит эта долгожданная дата, когда эти дурацкие «способы адресации и форматы команд» наконец уйдут в историю. CPU IO-порты никак не могут выкинуть, хотя там уже настоящих почти не осталось, все эмулируется прошивкой, PIC со статическим IRQ routing'ом, которым никто не пользуется толком уже лет 10, и прочее вот это все. Понятно, что оно нужно для всякой промышленной автоматизации и прочих EnI-вещей, но из процессоров для обычного ПК и сервера весь этот чемодан без ручки можно было выкинуть еще лет пять назад без особого вреда. В итоге Интел обещала перестать поддерживать слой совместимости с BIOS (CSM) в конце этого года, надеемся-ждем, но прогноз мой лично неутешительный — еще пару лет полуживого забавлять придется, как минимум.
              0
              PS Старый «биос» был 16 битным, его нужно выпилить хотяб потому, чтоб выкинуть из чипов поддержку старого «реального» режима.

              а как нам тогда в DOS грузиться???? :-o Или, прощай, ДОС?

                +2
                Пора уже закопать стюардессу. =)
                  0

                  Я понимаю, что это наверное сарказм, но всё же скажу, что для доса в наше время надо использовать DOSBox, либо собрать себе ретрокомп (это если хочется прям тру экспиреенса).
                  На современных машинах в досе делать нечего, кроме как биос порошивать (рекурсия какая-то). Большинство старых игр и софта всё равно работать нормально не будет.

                    0

                    Биос уже сто лет в обед шьётся в two-phase (минимум) из операционных систем типа Windows. А особо отличившиеся Биосы имеют даже встроенную утилиту обновления

                      0
                      Я может излишне старомоден, но стараюсь не прошивать биос из мультизадачных ОС. К тому же что бы прошить из винды её надо сначала установить. А на свежесобранной машине логичнее обновить и настроить биос до установки ОС.
                      Но на самом деле да — все более менее свежие матери имеют встроенную функцию обновления. А на самых свежих и вовсе даже если обновлять из доса, то прошивка куда-то заливается, потом происходит перезагрузка в графическую оболочку и непосредственно прошивка происходит в ней.
                      Ну так собственно я же это и имел в виду, что DOS на современных машинах не нужен, толку с него практического нет никакого и можно уже отказаться и не тянуть за собой этот слой совместимости.
                        0
                        Я может излишне старомоден, но стараюсь не прошивать биос из мультизадачных ОС

                        рисков ПОЧТИ нет. Я же не просто так про 2phase сказал. Логика в том, что в винде СНАЧАЛА происходит загрузка прошивки в некий блок оперативной памяти или в "секретное" хранилище в самой флэш-памяти (через некий системный драйвер) и уже потом — сама фактическая прошивка. Понятно, что если рубануть питание (=отсутствие ИБП и прочее), то все может стать очень плохо, но это же справедливо и при прошивке из ДОСа.

                          0
                          Я понимаю, это больше дело привычки и того факта, что прошивка происходит когда на компе ещё нет ОС (как я выше и написал).
                          И опять же как я выше написал — на последних матерях такая друхпроходная прошивка происходит и при обновлении из доса.
                          Но впрочем просто как интересный факт — когда только стали появляться биосы с встроенной утилитой обновления (а это где-то вторая половина нулевых), то иногда при скачивании свежего биоса была пометка, что ни в коем случае не обновлять через встроенную утилиту, а только через досовскую тулзу. Но это давно было, много лет пожалуй таких пометок я не встречал.
                    +1
                    Кстати да, только под дос можно ковырять без трудностей прошивки железок. Биос видеокарты поменять или над сетевухой поиздеваться…
                      +1
                      Уже под линуксом всё больше и больше плюшек появляется.
                  +2
                  Усложнение железа под прошивкой скрыто от простого пользователя слоями поверх слоев обратной совместимости, и потому очень многие по-прежнему уверены, что интерфейс BIOS Interrupt Call — это отлично, а загрузка через MBR — лучший способ загрузки, несмотря на то, что там вообще нет никакого способа защититься от загрузочных вирусов, кроме крайне легко обходимой защиты от редактирования этой самой MBR.

                  Делать из вот этой статьи про собранный китайцами на коленке из утекших исходников 2015 года руткит, найденный позже на машинах с AMI AptioV производителя второго эшелона, вывод о том, что UEFI сломан весь вообще, и надо все переделывать — это как-то обескураживает даже. Знали бы вы насколько BIOS сломан был, и каким сломанным он стал к его закату…

                  Прошивка любая подобная будет с багами, потому что у тех тайваньских ОЕМов второго эшелона и так уже маржинальность 10% (т.е. вкладывать какие-то деньги в безопасность, или вообще во что-либо, что напрямую не влияет на продажи — это для них верная смерть от рук конкурентов, которые не вкладывают ничего). И виноват тут не BIOS, не UEFI, не coreboot, и не U-boot, это все малозначительные детали реализации. Виновато простейшее управление рисками, т.е. пока такие атаки находят одну за пару лет, как не пару десятков тысяч в день, чинить прошивку будут стараться только всякие странные граждане вроде меня, а ОЕМу как было пофиг на нее, так и будет дальше — денег он от ее разломанности в плане безопасности пока что не теряет, а потому тратить на нее какие-либо ресурсы для него не имеет смысла.
                  0

                  Если на компе прошить БИОС до установки ОС, можно удалить заразу?
                  Или это может прописывать себя в новую прошивку?

                    0
                    Если на компе прошить БИОС до установки ОС, можно удалить заразу?

                    что значит прошить до установки ОС? На программаторе, что ли? Или через какой-нибудь сервисный режим (не знаю есть ли он у x86 платформы, в отличие от других платформ)? Ну, так вирусы не только в БИОСе живут. Не слышал про заражение ME или фирмваря чипсет, но уверен, что это тоже возможно.

                      0
                      Если у вас есть образ биоса без этой заразы, и она(зараза) не блокирует/перехватывает его обновление — то можно. Ну а если зараза ещё и boot guard врубила на максималках на своих ключах, то увы, прийдётся либо кушать кактус(терпеть троян/переходить на линукс), либо посетить компьютерный магазин с целью покупки новой материнки.
                        0

                        Ну вы даете!, я спрашиваю про этот вредоносный код в этой теме,
                        а не жалуюсь на свои проблемы :)

                          +1
                          Вредоносный код в этой теме тупой как пробка, и скорее всего, вставлен в прошивку вручную (точнее инструментом вроде UEFITool). Обновление прошивки на новую версию, или даже на ту же версию, удалит этот вредоносный код без следа.
                            0

                            По мне это вообще все извращения. Я вот одного не понимаю, если предположим разделить spi микросхему физически на две части с read memory, write memory, в первой храним прошивку, во второй данных и настройки, любые манипуляции с первой только с помощью физического нажатия на кнопку или перемещения тумблера какие вообще на это могут быть атаки.

                              +1
                              Если разделить микросхему физически на две части, получится две микросхемы вдвое меньшего объема. Это увеличивает BoM cost проекта на $100k+ вот прямо тут, потому что производство массовое (200к+ штук), а два чипа поменьше стоят на 50 центов дороже одного чипа побольше. Плюс пайка, плюс тестирование, плюс дополнительный прогон через refurbishing station всех плат, на которых вышел из строя только один чип из двух, итого ~$120k и небольшое снижение механической надежности. Любой штатный оптимизатор BoM cost вам за эти «лишние» 120к лицо обглодает, фигурально выражаясь, и будет по своему прав.

                              Физические атаки на перемещение тумблера будут примерно те же, что и на перешивку на программаторе — evil maid, т.е. оставил ноут в номере отеля, вышел в бар за пивом, а тебе в прошивку уже подсадил трояна условный Моссад. Вот эта атака из статьи именно на прошивку (если она вообще реальная, а не ПЕАР) — она именно таким образом и провернута, скорее всего, или похожим очень.

                              Более того, необходимость двигать тумблер сразу же лишает возможности автоматического обновления прошивки, а т.к. там десяток мегабайт кода (после распаковки), который из крупных кусков кода на С и Ассемблере разных производителей низкооплачиваемые азиатские инженеры собрали на скотч и отборный мат, то в таком коде неизбежны баги, и их очень хочется починить таким образом, чтобы пользователю для этого ничего делать не пришлось. Именно для этого у нас сейчас обновления прошивки ставятся через ESRT прямо из Windows Update и Linux Vendor Firmware Service так же, как и обновления драйверов и остального софта. Просто прошивка современного ПК и сервера — давно уже намного более software, чем firmware, там сетевой стек от FreeBSD, драйверы для FAT32 и NTFS, и OpenGL в BIOS Setup. А сделаешь тумблер — и все, никаких тебе автоматических обновлений, потому что у пользователя лапки, и никакие тумблеры он переключать не будет, потому что боится, потому что сложно, и потому что «лошадь в ванне с огурцами.жпг».

                              И тумблер WE/RO, и резервирование, и несколько микросхем физически — все это делается давно и успешно на промышленной электронике, обслуживаемой профессионалами за деньги. А тут у нас домашняя электроника, которую пользователь боится больше, чем она его, и потому все подобные начинания будут немедленно зарезаны отделом дизайна и отделом маркетинга у всех компаний, ориентирующихся не на энтузиастов. Для остальных есть ребята типа Purism и system76, у которых там и прошивки все открытые, и тумблер они могут поставить легко, если их убедить в том, что с тумблером их целевая аудитория энтузиастов купит больше их продукции.
                                +1

                                Purism — речь про https://puri.sm/products/librem-14/ и прочие модели?


                                Disabled and neutralized the Intel Management engine
                                Less binary blob firmware and disabled manufacturer backdoors
                                Write-protected BIOS and EC chips using hardware switches
                                Detect software and hardware tampering with PureBoot and the Librem Key

                                кстати, выделил жирным

                    0

                    А если загрузиться с WinРЕ, затем обновить BIOS (UEFI) и только потом установить систему, поможет это справиться с уязвимостью?

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое