Меня очень заинтересовало недавнее открытие UEFI rootkit Lojax исследователями ESET. Но после некоторого анализа я был удивлен простотой методов доставки / заражения, используемых этим руткитом. По сути, все методы, используемые Lojax, уже известны в течение многих лет из прошлых открытий и презентаций исследователей BIOS. Кроме того, в Lojax есть несколько общих приемов с руткитом HackingTeam rkloader (анализатор NTFS, метод внедрения FS с отслеживанием EFI_EVENT_GROUP_READY_TO_BOOT). В этом посте я хочу больше сосредоточиться на темах, связанных с методами эксплуатации прошивки UEFI из ОС (особенно MS Win10).
Многие люди думают об использовании BIOS как о чем-то очень сложном, но многие производители думают о безопасности встроенного ПО иначе. Иногда это создает очень легкие цели. Например, иногда они просто оставляют SPI-флеш-память открытой при записи или неправильно аутентифицируют обновления BIOS. За последние два года эта картина значительно изменилась в положительную сторону. Но не все производители одинаковы. Чтобы понять этот тип атак, нам нужно больше думать о тактике атакующих для постоянных схем заражения из операционной системы. Что нужно сделать злоумышленнику, чтобы иметь возможность изменять флэш-память SPI? Я визуализировал необходимые шаги для возможного удаленного сценария:
Этап 1 - Пользовательский режим: эксплойт на стороне клиента, такой как удаленное выполнение кода (RCE) веб-браузера, удаляет вредоносный установщик в систему. Затем установщик использует другой эксплойт для повышения своих привилегий до LOCALSYSTEM и продолжает выполнение с новыми привилегиями.
Этап 2 - Уровень ядра: Программа установки обходит политики подписывания кода для выполнения своего кода в режиме ядра. Полезная нагрузка режима ядра (драйвер) запускает эксплойт для получения привилегий для SMM.
Этап 3 - Режим управления системой (SMM): шелл-код SMM успешно выполняется, а привилегии повышены до SMM. Полезная нагрузка SMM отключает защиту модификаций флэш-памяти SPI.
Этап 4 - SPI Flash: все защиты SPI flash отключены, а флэш-память открыта для произвольной записи. Затем руткит / имплант устанавливается в микропрограмму на флэш-чип SPI. Наивысший уровень настойчивости в системе достигнут.
Эта общая схема заражения возникла у меня в голове некоторое время назад, когда я работал над исследованием “UEFI Firmware Rootkits: Myths and Reality” , представленным в прошлом году. В рутките Lojax использовался законный и подписанный драйвер (RWEverything) для атаки на BIOS со стороны ОС. Практически такой же подход используется для PoC с UEFI Ransomware на MS Win10 (со всеми обновлениями, установленными на момент презентации). Основным отличием является драйвер (инструмент обновления прошивки AMI), используемый для связи с прошивкой UEFI.
Основная проблема с поставщиками обновлений прошивки UEFI, которые используют тот же подход для доставки обновления, что и руткит UEFI, будут использоваться для атаки на BIOS. В недавнем обновлении (RS5) для Win10 некоторые драйверы были заблокированы проверками целостности кода (HVCI на основе подхода черного списка), включая RWEverything. Но трудно заблокировать все законные инструменты обновления BIOS. Я не верю, что это возможно без альтернативных способов доставки обновлений.
RWEverything не является инструментом взлома. На самом деле это очень полезный инструмент для оценки аппаратного обеспечения, случайно обнаруженный задолго до того, как был обнаружен Lojax, в направлении двойного использования. Многие исследователи BIOS использовали этот драйвер для разработки PoC вплоть до 2014 года. Кроме того, в 2016 году Дмитрий Олексюк выпустил свой PoC code для RwDrv.sys на github. Средство Intel chipsec также использует методы в своем драйвере для сбора информации о конфигурации аппаратного / микропрограммного обеспечения. Давайте углубимся в причины, которые на самом деле делают этот драйвер опасным и интересным с точки зрения злоумышленника.
Все эти драйверы используют легальную функцию режима ядра MmMapIoSpace (), чтобы иметь доступ RW к физическому пространству памяти, и встроенные функции компилятора __outbyte () или __inbyte () для записи / чтения в аппаратные порты (или могут также использоваться непосредственно как инструкции сборки в или вне). В качестве примера, этой функции достаточно, чтобы иметь доступ для чтения к области памяти, где хранится конфигурация битов защиты BIOS (BLE, BIOS_WP…). Для вызова обработчика SMI для использования уязвимости злоумышленнику необходим доступ для записи в физическую память для сопоставления входных параметров и шелл-кода для обработчика SMI и записи в аппаратный порт для вызова обработчика SMI.
В этом посте в любом месте, где упоминается обработчик SMI, я говорил о программных обработчиках SMI, которые вызывают через порт ввода-вывода APMC 0xB2. Разработчики BIOS пытаются сократить количество доступных обработчиков SMI, но для совместимости многие из них все еще активны.
Большинство инструментов обновления BIOS от распространенных поставщиков используют приложение пользовательского режима как часть, в которой вся логика, созданная для процесса обновления, и драйвер режима ядра в качестве прокси для работы с физическим пространством памяти, пишут MSR, вызывают SMI. Но любое другое стороннее приложение может вручную загрузить этот драйвер и использовать таким же образом.
Например, средство обновления Lenovo Thinkpad BIOS использует драйвер tpnflhlp.sys, который является прокси-сервером, как описано выше. Прекрасный пример подписанного драйвера двойного назначения для создания атаки, как это сделал Lojax с RWEverything. Кроме того, он содержит функциональные возможности аппаратного порта R / W. Отлично работает на MS Win10 v1809 (проверено на одном из моих последних ноутбуков Lenovo).
Другой пример AMI Firmware Update Tool (AFU), где подписанный amifldrv64.sys выглядит даже хуже с точки зрения двойного использования. В нем реализован другой тип обработчиков SMI, где параметры принимаются от ACPI. Все обвиняют RW во всем, как в инструменте swissknife для руткитов прошивки, но AFU выглядит для меня более опасно. Также протестирован на Win10 с последними обновлениями и работает отлично.
Я демонстрирую эти два примера только для описания проблемы, которую трудно решить без архитектурных изменений и единого процесса обновления BIOS, поддерживаемого ОС. Определенно, черный список не поможет, а только создаст ощущение псевдобезопасности. В настоящее время я вижу, как все больше поставщиков оборудования начинают концентрироваться на безопасности встроенного программного обеспечения, но больше внимания, необходимого для всей экосистемы, включают и инструменты обновления BIOS.
(c) Alex Matrosov
Переводчик статьи - https://xss.pro/members/177895/
Многие люди думают об использовании BIOS как о чем-то очень сложном, но многие производители думают о безопасности встроенного ПО иначе. Иногда это создает очень легкие цели. Например, иногда они просто оставляют SPI-флеш-память открытой при записи или неправильно аутентифицируют обновления BIOS. За последние два года эта картина значительно изменилась в положительную сторону. Но не все производители одинаковы. Чтобы понять этот тип атак, нам нужно больше думать о тактике атакующих для постоянных схем заражения из операционной системы. Что нужно сделать злоумышленнику, чтобы иметь возможность изменять флэш-память SPI? Я визуализировал необходимые шаги для возможного удаленного сценария:
Этап 1 - Пользовательский режим: эксплойт на стороне клиента, такой как удаленное выполнение кода (RCE) веб-браузера, удаляет вредоносный установщик в систему. Затем установщик использует другой эксплойт для повышения своих привилегий до LOCALSYSTEM и продолжает выполнение с новыми привилегиями.
Этап 2 - Уровень ядра: Программа установки обходит политики подписывания кода для выполнения своего кода в режиме ядра. Полезная нагрузка режима ядра (драйвер) запускает эксплойт для получения привилегий для SMM.
Этап 3 - Режим управления системой (SMM): шелл-код SMM успешно выполняется, а привилегии повышены до SMM. Полезная нагрузка SMM отключает защиту модификаций флэш-памяти SPI.
Этап 4 - SPI Flash: все защиты SPI flash отключены, а флэш-память открыта для произвольной записи. Затем руткит / имплант устанавливается в микропрограмму на флэш-чип SPI. Наивысший уровень настойчивости в системе достигнут.
Эта общая схема заражения возникла у меня в голове некоторое время назад, когда я работал над исследованием “UEFI Firmware Rootkits: Myths and Reality” , представленным в прошлом году. В рутките Lojax использовался законный и подписанный драйвер (RWEverything) для атаки на BIOS со стороны ОС. Практически такой же подход используется для PoC с UEFI Ransomware на MS Win10 (со всеми обновлениями, установленными на момент презентации). Основным отличием является драйвер (инструмент обновления прошивки AMI), используемый для связи с прошивкой UEFI.
Основная проблема с поставщиками обновлений прошивки UEFI, которые используют тот же подход для доставки обновления, что и руткит UEFI, будут использоваться для атаки на BIOS. В недавнем обновлении (RS5) для Win10 некоторые драйверы были заблокированы проверками целостности кода (HVCI на основе подхода черного списка), включая RWEverything. Но трудно заблокировать все законные инструменты обновления BIOS. Я не верю, что это возможно без альтернативных способов доставки обновлений.
RWEverything не является инструментом взлома. На самом деле это очень полезный инструмент для оценки аппаратного обеспечения, случайно обнаруженный задолго до того, как был обнаружен Lojax, в направлении двойного использования. Многие исследователи BIOS использовали этот драйвер для разработки PoC вплоть до 2014 года. Кроме того, в 2016 году Дмитрий Олексюк выпустил свой PoC code для RwDrv.sys на github. Средство Intel chipsec также использует методы в своем драйвере для сбора информации о конфигурации аппаратного / микропрограммного обеспечения. Давайте углубимся в причины, которые на самом деле делают этот драйвер опасным и интересным с точки зрения злоумышленника.
Все эти драйверы используют легальную функцию режима ядра MmMapIoSpace (), чтобы иметь доступ RW к физическому пространству памяти, и встроенные функции компилятора __outbyte () или __inbyte () для записи / чтения в аппаратные порты (или могут также использоваться непосредственно как инструкции сборки в или вне). В качестве примера, этой функции достаточно, чтобы иметь доступ для чтения к области памяти, где хранится конфигурация битов защиты BIOS (BLE, BIOS_WP…). Для вызова обработчика SMI для использования уязвимости злоумышленнику необходим доступ для записи в физическую память для сопоставления входных параметров и шелл-кода для обработчика SMI и записи в аппаратный порт для вызова обработчика SMI.
В этом посте в любом месте, где упоминается обработчик SMI, я говорил о программных обработчиках SMI, которые вызывают через порт ввода-вывода APMC 0xB2. Разработчики BIOS пытаются сократить количество доступных обработчиков SMI, но для совместимости многие из них все еще активны.
Большинство инструментов обновления BIOS от распространенных поставщиков используют приложение пользовательского режима как часть, в которой вся логика, созданная для процесса обновления, и драйвер режима ядра в качестве прокси для работы с физическим пространством памяти, пишут MSR, вызывают SMI. Но любое другое стороннее приложение может вручную загрузить этот драйвер и использовать таким же образом.
Например, средство обновления Lenovo Thinkpad BIOS использует драйвер tpnflhlp.sys, который является прокси-сервером, как описано выше. Прекрасный пример подписанного драйвера двойного назначения для создания атаки, как это сделал Lojax с RWEverything. Кроме того, он содержит функциональные возможности аппаратного порта R / W. Отлично работает на MS Win10 v1809 (проверено на одном из моих последних ноутбуков Lenovo).
Другой пример AMI Firmware Update Tool (AFU), где подписанный amifldrv64.sys выглядит даже хуже с точки зрения двойного использования. В нем реализован другой тип обработчиков SMI, где параметры принимаются от ACPI. Все обвиняют RW во всем, как в инструменте swissknife для руткитов прошивки, но AFU выглядит для меня более опасно. Также протестирован на Win10 с последними обновлениями и работает отлично.
Я демонстрирую эти два примера только для описания проблемы, которую трудно решить без архитектурных изменений и единого процесса обновления BIOS, поддерживаемого ОС. Определенно, черный список не поможет, а только создаст ощущение псевдобезопасности. В настоящее время я вижу, как все больше поставщиков оборудования начинают концентрироваться на безопасности встроенного программного обеспечения, но больше внимания, необходимого для всей экосистемы, включают и инструменты обновления BIOS.
(c) Alex Matrosov
Переводчик статьи - https://xss.pro/members/177895/
Последнее редактирование модератором:
