На прошедшей недавно конференции Black Hat Europe исследователи Positive Technologies Марк Ермолов и Максим Горячий рассказали об уязвимости в Intel Management Engine 11, которая открывает злоумышленникам доступ к большей части данных и процессов на устройстве. Такой уровень доступа означает также, что любой эксплуатирующий эту уязвимость злоумышленник, обойдя традиционную защиту на основе ПО, сможет проводить атаки даже при выключенном компьютере. Сегодня мы публикуем в нашем блоге подробности проведенного исследования. 1. Введение Intel Management Engine — это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Именно через PCH проходит почти все общение процессора с внешними устройствами, следовательно Intel ME имеет доступ практически ко всем данным на компьютере и возможность исполнения стороннего кода позволяет полностью скомпрометировать платформу. Такие безграничные возможности привлекают исследователей не первый год, но сейчас интерес к технологии Intel ME значительно вырос. Одной из причин этого является переход данной подсистемы на новую аппаратную (x86) и программную (доработанный MINIX в качестве операционной системы) архитектуру. Применение платформы x86 позволяет использовать всю мощь средств анализа бинарного кода, что ранее было затруднительно, так как до 11-й версии использовалось ядро с малораспространенной системой команд — ARC. К сожалению, анализ Intel ME 11-й версии был затруднен тем, что исполняемые модули упакованы кодом Хаффмана с неизвестными таблицами. Но нашей исследовательской группе удалось их восстановить (утилиту для распаковки образов можно найти на нашей странице в GitHub [2]). После распаковки исполняемых модулей мы приступили к изучению программной и аппаратной «начинки» Intel ME. Нашу усилия были вознаграждены, и в итоге мы получили полный контроль над всей платформой. 1.1. Обзор Intel Management Engine 11 Детальное описание внутреннего устройства Intel ME и его компонентов можно найти в работах: [1], [3], [4]. Отметим, что, начиная с 2015 года в PCH было интегрировано процессорное ядро LMT набором команд х86. Такое ядро применяется в SOC Quark.

LMT2 IdCode ядра ME C Intel Management Engine связано большое количество современных технологий Intel — Intel Active Management Technology, Intel Platform Trust Technology (fTPM), Intel Software Guard Extensions, Intel Protected Audio Video Path. Также ME является root of trust для технологий технологии Intel Boot Guard, которая не позволяет злоумышленнику внедрять свой код в UEFI. Основное назначение МЕ – начальная инициализация платформы, и запуск основного процессора. ME так же обладает практически безграничными возможности доступа к данным, которые обрабатываются на компьютере МЕ может перехватывать и модифицировать сетевые пакеты, изображение на видеокарте, имеет полный доступ к USB устройствам. Такие возможности означат, что, если злоумышленник получит возможность выполнять свой код внутри МЕ это будет означать новую эру зловредного программного обеспечения, которое невозможно обнаружить современными средствами защиты. Но к счастью за все 17 лет истории этой технологии было найдено всего 3 уязвимости (публично). 1.2. Публично известные уязвимости в Intel ME 1.2.1. Ring-3 Rootkits Первая публичная уязвимость в Intel ME была найдена в 2009 году Alexander Tereshkin и Rafal Wojtczuk представили доклад на Black Hat Introducing Ring-3 Rootkits. Атака производилась через инъекцию кода в специализированную область памяти UMA, в которую МЕ выгружает неиспользованный в данный момент страницы памяти. После оглашения результатов исследования Intel внедрил защиту UMA – теперь эта область шифруется AES-ом и для каждой страницы МЕ хранит ее контрольную сумму, которая проверяется при «возвращении» страницы в основную память МЕ. 1.2.2. Zero-Touch Provisioning В 2010 году Vassilios Ververis представил атаку на реализацию МЕ в GM45. Используя режим конфигурирования «zero touch», он смог обойти авторизацию AMT. 1.2.3. Silent Bob is Silent В мае 2017 году была опубликована уязвимость в системе авторизации AMT (CVE-2017-5689), которая позволяла неавторизованному пользователю получить полный доступ к основной системе на материнских платах с поддержкой технологии vPro. Таким образом, до сегодняшнего времени была найдена только одна уязвимость (Ring-3 rootkits), которая позволяет выполнять произвольный код внутри Intel ME. 2. Векторы атак Практически все данные, которые использует ME в своей работе либо явно, либо косвенно подписаны Intel. Но МЕ все-таки предоставляет некоторые возможности для взаимодействия с пользователем: Локальный управляющий интерфейс — HECI Сеть (только для vPro) Память хоста (UMA) SPI флеш Внутренняя файловая система 2.1. HECI HECI – представляет собой отдельное PCI-устройство, которое представляет собой кольцевой буфер и служит для обмена сообщениями между основной системой и ME. Приложения, расположенные внутри МЕ, могут регистрировать свои обработчики для HECI. Это увеличивает количество потенциальных проблем безопасности (CVE-2017-5711). 2.2. Сеть (только vPro) AMТ представляет собой один большой модуль, в который интегрировано огромное количество различных сетевых протоколов различного уровня, данный модуль содержит в себе большое количество legacy-кода, но присутствует только на системах бизнес-сегмента. 2.3. Аппаратная атака на SPI-интерфейс В процессе изучения МЕ у нас возникла идея обойти проверку подписи с помощью эмулятора SPI-флеш. Это специализированное устройство, которое выглядело бы для PCH как обычная SPI-flash но при разных обращениях оно отправляет разные данные. Таким образом если вначлае контролируется подпись данных, а потом они перечитываются то можно провести атаку и внедрить свой код во внутрь МЕ. Найти таких ошибок в прошивке нам не удалось, данные вначале вычитываются, затем проверяется подпись. При повторных обращениях контролируется их идентичность тем данным, которые были получены при первом чтении. 2.4. Внутренняя файловая система Intel Management Engine использует SPI flash в качестве основного файлового хранилища с собственной файловой системой. C одной стороны файловая система имеет достаточно сложную структуру [6], с другой многие привилегированные процессы хранят именно здесь свои конфигурационные фалы. Исходя из чего, файловая система показалась нам наиболее перспективным местом для воздействия на ME. Следующим шагом в поиске уязвимости был выбор бинарного модуля. 2.5. Выбор модуля для анализа В операционной системе МЕ реализована похожая на применяемую в Unix модель разграничения и контроля доступа, с той разницей, что в качестве субъектов системы выступают процессы. Для каждого процесса статически задаются его идентификатор пользователя, группы, список доступного оборудования и разрешенные системные вызовы.

Пример статических правил для процесса Таким образом не каждый процесс в системе может загружать модули на исполнение. Причем, контроль целостности и привилегии устанавливает запускающий его процесс. Он может поднять свои привилегии, задав новому процессу высокие права доступа. Одним из процессов с возможностью порождать новые является – BUP (BringUP). В процессе реверс-инжиниринга этого модуля, в функции инициализации устройства Trace Hab мы нашли переполнение стекового буфера. Файл «/home/bup/ct» не имел подписи, и мог быть интегрирован в прошивку МЕ через сервисную программу – Flash Image Tool. Это давало возможность вызвать переполнение буфера внутри процесса BUP с помощью файла инициализации BUP большого размера. Но поэксплуатировать ее можно было только после обхода защиты от переполнения стекового буфера.

Переполнение буфера в стеке 2.6. Обход защиты от переполнения буфера В ME реализован классический способ защиты от переполнения буфера в стеке – стековая канарейка. Реализован данный механизм следующим образом: Для каждого процесса в момент его создания из аппаратного генератора случайных чисел в специальную область (доступную только для чтения) копируется 32-битное значение; В прологе функции — это значение копируется над адресом возврата в стеке, тем самым защищая его; В эпилоге функции происходит сравнение сохранённого значения с эталонным. Если оно не совпадает генерируется программное прерывание int 81h завершающие процесс. Таким образом, для эксплуатации необходимо либо предугадать значение канарейки, либо перехватить управление до того, как будет произведена проверка ее целостности. Дальнейшее изучение показало, что любой сбой в генераторе случайных чисел расценивается ME как неустранимый сбои и приводит к ее неработоспособности. Изучая функции, которые вызываются после переполнения и до проверки целостности нами было обнаружено, что функция, которую мы назвали bup_dfs_read_file косвенно вызывает memcpy. Она в свою очередь использует в качестве значения целевого адреса, данные полученные из некоторой структуры, которую мы назвали TLS (Th read Local Storage). Стоит отметить, что функции bup для чтения и записи файлов, используют сервисы системной библиотеки для работы с общей памятью (shared memory). Используя его, функции чтeния и записи, получают и записывают информацию. Но никто кроме BUP эти данные не использует, поэтому использование этого механизма может показаться сомнительными. Мы считаем, что это связано с тем, что часть кода BUP, который взаимодействует с MFS скопирован из другого модуля – драйвера файловой системы, где использование общую память оправдано.

Вызов функции memcpy

Получение адреса из TLS Как выяснилось позже, при переполнении буфера эта область TLS может быть перезаписана функцией чтения файла, что позволяет обойти защиту от переполнения буфера. 2.7. Thread Local Storage Все обращение к структуре TLS происходит через сегментный регистр gs сама же структура имеет следующий вид:

Структура TLS

Получение полей TLS Сегмент, на который указывает gs, не доступен на запись, но сама структура TLS расположена на дне стека (!!!), что позволяет изменять ее в обход ограничения. Таким образом, при переполнении буфера мы можем перезаписать указатель на TLS и формировать структуру SYSLIB_CTX. А алгоритм работы алгоритм работы функции bup_dfs_read_file, используя этот трюк, позволяет получить arbitrary write. 2.8. Использование реализации функции чтения для получения arbitrary write primitive Функция bup_dfs_read_file считывает данные с SPI-flsh блоками по 64 байта, что позволяет вначале перезаписать указатель на SYSLIB_CTX а TLS. На следующей итерации функция sys_write_shared_mem извлекает адрес, который мы сформировали и передает его в memcpy в качестве целевого адресса. Это позволяет получить примитив записи внутри процесса BUP.

Итеративное чтение файла внутри bup_dfs_read_file Отсутствие ASLR позволяет перезаписать адрес возврата функцией memcpy и перехватить управление. Тут так же поджидает неприятность для атакующего – стек не является исполняемым. Но пользуясь тем, что BUP умеет создавать новые процессы и сам проверяет подпись для запускаемых модулей, мы можем с помощью возвратно-ориентированного программирования (Return Oriented Programming — ROP) создать новый процесс с заданными правами. 2.9. Возможные векторы эксплуатации Для успешной эксплуатации данной уязвимости необходим доступ на запись в MFS или целиком в Intel ME регион. Производителям оборудования должны блокировать доступ к региону с ME, но к сожалению, это делают далеко не все [8]. В случае, если на системе присутствует такая ошибка конфигурации – это автоматически делает ее уязвимой. В Intel ME предусмотрена штатная возможность обеспечивать доступ на запись к МЕ региону через отправку специального сообщения HMR-FPO по HECI из BIOS [9]. Атакующий может послать такое сообщение используя уязвимость в BIOS или DMA-атаку. В случае физического доступа к атакуемой машине атакующий всегда может переписать на свой образ (через SPI-программатор или используя специальную перемычку), что приводит к полному взлому платформы. Одним из самых насущных вопросов является вопрос о возможности удаленной эксплуатации. Нам кажется, что такая возможность есть, если выполнены следующие условия: Атакуется платформа с активированным AMT. Атакующий знает пароль администратора AMT или использует уязвимость для обхода авторизации. BIOS не имеет пароля (или он известен злоумышленнику). BIOS имеет опцию, позволяющую открывать доступ на запись в ME регион. Выполнение этих условий позволяет атакующему получить доступ к ME региону удалённо. Отметим так же, что ROM не контролирует версию Intel ME при запуске, что делает возможным обновлением на старую версию, содержащую уязвимость. 2.10. Обзор уязвимостей CVE-2017-5705,6,7 Найденной уязвимости был присвоен номер INTEL-SA-00086 (CVE-2017-5705, CVE-2017-5706, CVE-2017-5707). Приведем небольшую выдержку из его описания: CVSSv3 Vectors: 8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H Affected products: 6th, 7th & 8th Generation Intel Core Processor Family Intel Xeon Processor E3-1200 v5 & v6 Product Family Intel Xeon Processor Scalable Family Intel Xeon Processor W Family Intel Atom C3000 Processor Family Apollo Lake Intel Atom Processor E3900 series Apollo Lake Intel Pentium Celeron N and J series Processors 2.11. Disclosure Timeline June 27, 2017 — Bug reported to Intel PSIRT June 28, 2017 — Intel started initial investigation July 5, 2017 — Intel requested proof-of-concept July 6, 2017 — Additional information sent to Intel PSIRT July 17, 2017 — Intel acknowledged the vulnerability July 28, 2017 — Bounty payment received November 20, 2017 — Intel published SA-00086 security advisory 3. Заключение Таким образом, нами была найдена уязвимость Intel ME, которая позволяет выполнять произвольный код. Это ставит под угрозу все технологии такие технологии как Intel Protected Audio Video Path (PAVP), Intel Platform Trust Technology (PTT или fTPM), Intel BootGuard, Intel Software Guard Extention (SGX) и многие другие. Эксплуатируя найденную нами уязвимость в модуле bup, нам удалось включить механизм, называемый PCH red unlock, который открывает полный доступ ко всем устройствам PCH, для использование их через DFx chain, иначе говоря с помощью JTAG. Одним из таких устройств и является само ядро ME. Это дало возможность отлаживать код, выполняемый на ME, читать память всех процессов и ядра, а так же, управлять всеми устройствами внутри PCH. Мы насчитали в совокупности порядка 50 внутренних устройств, полный доступ к которым имеет только ME, а основной процессор только к весьма ограниченному их подмножеству. Мы не утверждаем, что в нашем исследовании нет ошибок или оно является исчерпывающим. Тем не менее, мы надеемся, что оно поможет другим исследователям, интересующимся безопасностью и «начинкой» Intel ME. Авторы: Марк Ермолов и Максим Горячий Список литературы [1] Dmitry Sklyarov, Intel ME: The Way of the Static Analysis, Troopers 2017. [2] Intel ME 11.x Firmware Images Unpacker. [3] Xiaoyu Ruan, Platform Embedded Security Technology Revealed. [4] Igor Skochinsky, Intel ME Secrets. Hidden code in your chipset and how to discover what exactly it does, RECON 2014. [5] Alexander Tereshkin, Rafal Wojtczuk, Introducing Ring-3 Rootkits, Black Hat USA, 2009. [6] Dmitry Sklyarov, Intel ME: flash file system explained, Black Hat Europe, London, 2017. [8] Alex Matrosov, Who Watch BIOS Watchers?. [9] Марк Ермолов, Максим Горячий, «Как стать единоличным владельцем собственного компьютера», PHDays VI. #советыдлякомпьютера