Что если я скажу, что в вашей любимой системе на кристале или материнской плате с чипсетом Intel может быть заложен скрытый бэкдор? Если вы опытный специалист по безопасности, то скорее всего скажете: "Я знаю", потому что возможность такого канала освещается уже достаточно давно: с тех пор, как была анонсирована загадчная вещь-в-себе, известная как Intel ME. Если же так случилось, что вы никогда не слышали ни о Intel ME, ни о Intel CS(M)E, садитесь в удобное кресло и присоединяйтесь к волшебному миру технологий Intel. Для тех, кто действительно является страшным аналитиком безопасности, вот краткий список тем, которые освещаются в статье:

• Что такое Intel ME и для чего он нужен

• Известные проблемы безопасности Intel ME

• Очевидное желание организовать утечку данных через Ethernet, и почему это не так просто, как может показаться

• MITM-атака на хост-контроллер (XHCI) Intel SoC

• PoC на утечку данных через USB

Так что же такое Intel ME?

Простыми словами, Intel Management Engine (Intel ME) - это часть программного и аппаратного обеспечения, встроенного в SoC и чипсеты Intel для обеспечения специальных возможностей управления (например, удаленного управления с помощью Intel AMT) и реализации нескольких технологий безопасности. По сути, это отдельный полноценный x86-процессор на материнской плате или SoC, способный самостоятельно взаимодействовать с внешним миром. Он включается сразу после подачи питания на материнскую плату и работает даже при незапущенном процессоре.

В Интернете можно встретить определенное количество названий, относящихся к Intel ME, поэтому уделим немного времени этому вопросы, чтобы прояснить о чем каждое из них. Аппаратная часть Intel ME широко известна как Intel Converged Security (and Management) Engine - Intel CS(M)E (точное название зависит от версии Intel SoC или чипсета). По сути, это название процессора в контроллере PCH вашей материнской платы. Программная часть Intel ME называется либо Intel TXE, либо Intel ME (Intel TXE для Intel CSE, а Intel ME для Intel CSME). Она реализована в виде микроядра MINIX, загружаемого Intel CSME из микросхемы Flash BIOS.

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

Positive Technologies прорубает окно в Intel

Одними из самых значимых среди достижений в этой области смогли похвастяться Positive Technologies - компания-разработчик систем кибербезопасности из России. Несколько их исследователей потратили годы на изучение и описание архитектуры Intel ME. В ходе этого удивительного путешествия им удалось расшифровать конфигурационные файлы Intel ME в комплекте с отладочным ПО, описать файловую систему Intel ME, модифицировать отладочное ПО для обеспечения поддержки Intel ME и, наконец, взломать Intel ME.

На Black Hat Europe 2017 Positive Technologies было представлено описание INTEL-SA-0086 - уязвимости в Intel ME, позволяющей получить высокопривилегированный отладочный доступ к Intel ME. Максим Горячий и Марк Ермолов представили демонстрацию получения такого доступа на платформе Skylake и модификации с его помощью видеопотока на каждом этапе загрузки. Честно говоря, весьма впечатляюще.

Позже они выпустили PoC для платформы Apollake с инструкциями для получения доступа уровня разработчика к Intel ME. Довольно интересно, почему PT продемонстрировала PoC для Skylake на Black Hat, но позже выпустила PoC только для Apollolake. Думаю, что мем выше хорошо объясняет ситуацию.

Positive technologies опубликовала много информации об Intel ME, описание которой потребует отдельной статьи. Подводя итог, Positive Techonologies позволила сообществу самостоятельно взглянуть на Intel ME поближе. И за это им большое спасибо.

Продолжение работы независимыми исследователями

Ситуация с различиями в PoC, представленными Positive Technologies на Black Hat Europe и на GitHub, привлекла внимание Youness Alaoui (он же KaKaRoTo). Он задался целью повторить PoC для Skylake и позже опубликовал серию статей в своем блоге, описывающих процесс модификации PoC для Skylake. Ему пришлось проделать огромную работу, включая тщательное изучение спецификации чипсетов Intel, дизассемблирование ROM Intel ME, брутфорс адресного пространства и многое другое.

В последней статье цикла он описывает идею, как реализовать невидимый кейлоггер с помощью Intel ME. Поскольку Intel ME имеет полный доступ к хост-контроллеру чипсета (XHCI), отвечающему за подключение USB-устройств, можно реализовать MITM-атаку с помощью Intel ME. Это позволило бы отслеживать все USB транзакции между платформой и любым из USB-устройств, включая клавиатуру.

Несмотря на то, что kakaroto очень четко описал идею MITM-атаки, он не нашел времени для ее окончательной реализации. Он реализовал основные интерфейсы, позволяющие получить доступ к XHCI с помощью python и перехватить контроль над XHCI у операционной системы, но дальше этого дело не продвинулось.

Моя очередь действовать

Я пришел к своему научному руководителю с просьбой дать тему для дипломной работы, и он предложил мне продолжить исследование Intel ME. Нам потребовалось некоторое время, чтобы повторить PoC, представленный Positive Technologies. Спасибо научному руководителю: Если бы не он, я мог бы остаться на стадии повторения PoC до самого конца года.

Бакалаврская работа требует решения инженерной задачи, поэтому мы решили создать канал передачи данных через Ethernet-соединение. Для этого необходимо получить доступ к Ethernet контроллеру (GbE), что мне в итоге не удалось сделать на моей плате (GB-BPCE-3350). Позже я обнаружил заметку в спецификации Intel для Intel Celeron Series N о том, что Sideband channel, канал через который KaKaRoTo осуществил доступ к XHCI, не имеет доступа к устройствам с других шин, кроме нулевой. К сожалению, GbE на GB-BPCE-3350 расположен на отдельной шине (под номером 2), из-за чего, по всей видимости, мне не удалось получить доступ к GbE.

Тем не менее, задача уже была поставлена, поэтому пути назад не было. Таким образом, было решено поменять среду передачи данных на USB, и организовать утечку именно через этот канал.

Хватит слов, давайте к делу

Как я уже говорил, KaKaRoTo реализовал только базовые структуры данных и интерфейсы для взаимодействия с регистрами хост-контроллера (HC). Поэтому я был обречен реализовывать USB-стек начиная с самого низкого уровня.

Чтобы сделать задачу выполнимой в течение одного семестра, мне пришлось срезать пару углов. Для этого сделаем пару предположений о USB-стеке, который необходимо реализовать:

1. Не нужно получать никаких данных от подключенного USB-устройства, только отправлять на него. Это позволяет нам перенести из драйверов только те функции, которые связаны с операциями записи.

2. Можно спокойно игнорировать систему прерываний. Это позволяет переносить только те функции, которые используются в режиме "опрашивания" стека USB.

Таким образом, диаграмма ниже иллюстрирует реализованный мной стек USB. Драйверы XHCI и USB сильно вдохновлены реализацией coreboot/libpayload и являются почти дословным переводом ее на язык python. Роль приемника утечки данных играет Arduino Nano, поэтому мне пришлось реализовать драйвер CH341. Он также сильно вдохновлен, на этот раз реализацией ядра Linux. Исходный код следующего USB стека доступен в моем форке библиотеки KaKaRoTo.

Используя интерфейсы, предоставляемые этим стеком USB, можно инициализировать структуру XHCI, перехватить управление хост-контроллером у ОС, опросить подключенные устройства и инициализировать их драйверы. Чтобы не быть голословным, ниже представлен пример работы с данным стэком.

Перехват контроллера хоста

Дисклеймер: Получение доступа к Intel ME с помощью Intel-SA-0086 (по сути, повторение PoC от Positive Technologies) я оставил в стороне. Исчерпывающие инструкции, касающиеся этой темы, можно найти в репозитории Positive Technologies.

Прежде всего, импортируем библиотеку ipclib, как указано в README. В случае, если все сделано верно, это должно закончиться инициализацией глобальной переменной xhci, которая будет обрабатывать все данные, связанные с контроллером хоста.

Итак, мы запустили консоль python и успешно импортировали ipclib. Что дальше? Перехватим управление хост-контроллером у ОС. Это можно сделать с помощью методов глобального объекта xhci, который уже содержит инициализированные константы, связанные с контроллером хоста. Используем xhci.setup() для передачи управления, как показано на рисунке ниже.

На скриншотах, представленных kakaroto, можно заметить существенную разницу с выводом на картинке. DCI соединение обрывается сразу после выдачи запроса на сброс контроллера хоста. Попытавшись разобраться в этом вопросе, я не пришел не нашел никакого другого объяснения этой разнице в поведении, кроме как разница в реализации протокола DCI в Linux и Windows версиях Intel System Studio. Тем не менее, прерывания соединения, к счастью, не затрагивает структуры памяти, поэтому остается только подождать пару секунд, пока DCI соединение автоматически восстановится. Это делается автоматически моей реализацией xhci.setup().

Если перехеват контроллера завершился успешно, то на команду NOOP, отправленную контроллеру хоста, должен появиться ответ SUCCESS, как показано на рисунке.

Опрос подключенных устройств

Следующим шагом будет опрос подключенных устройств. Для этого метод xhci.setup() также инициализирует структуру xhci.roothub, которая просто является драйвером для корневого концентратора (Root Hub) контроллера хоста. Используя его методы, можно проверять состояние портов RH, подключать и отключать устройства и многое другое. xhci.roothub.poll() опрашивает все порты с 0 по 31 контроллера хоста и ищет любые изменения. Если он находит подключенное устройство, то устройство подключается в соответствии с спецификацией XHCI.

Вкратце, подключение устройства требует определенных последовательных вызовов для перехода устройства из состояния Disabled в состояние Configured. Ниже представлена иллюстрация из спецификации XHCI, которая описывает процесс перевода слота в сконфигурированное состояние.

Процесс перевода слота в состояние Configured с помощью реализованных мной интерфейсов представлен на скриншотах ниже.

На самом деле, здесь есть небольшой обман. Несмотря на то, что я перевел код этапа конфигурации на python, у меня не было достаточно времени, чтобы протестировать его должным образом. Поэтому я заменил его на хардкод, который конфигурирует конечные точки, специфичные именно для моего Arduino Nano. У меня есть ишью в репозитории ipclib, которая ссылается именно на эту проблему. Это может помочь кому-то заметить хардкод внутри, но я думаю, что я никогда не исправлю его, поскольку моя работа над этим проектом окончена.

Инициализация драйвера подключенного устройства

Последним шагом будет загрузка драйвера, специфичного для данного устройства. Как я уже упоминал ранее, Arduino Nano, которая выступает в роли приемника утечки данных, использует контроллер CH341 для соединения с ПК по протоколу USB Serial, поэтому именно драйвер CH341 мне пришлось реализовать. Реализация также представлена на моем форке репозитория ipclib.

Я достаточно ленив, поэтому загрузка драйвера также осуществляется вручную (вместо того, чтобы автоматически определить драйвер по VID и PID). Процесс загрузки драйвера CH341 показан на рисунке ниже.

Поздравляю, это все. Теперь можно отправлять дампы памяти или любую другую интересующую вас системную информацию. Например, я разработал свой небольшой протокол, который передает дампы памяти. Результат его работы можно наблюдать на скриншотах ниже.

Заключение

Кто-то может сказать, что в этой статье не представлено никаких новых уязвимостей или возможностей Intel ME. И это на 100% правда. Суть в том, что исследование безопасности никогда не было моей целью. Я скорее простой инженер, который хотел решить интересную инженерную задачу.

Учитывая это, статья представляет простой и краткий обзор исследования, связанного с Intel ME, описывает то, что уже было сделано на практике в открытом доступе, и расширяет работу, реализуя скромный USB-стек, способный передавать информацию через USB-канал. Тем не менее, MITM-атака, описанная kakaroto, еще не реализована.

Реализация USB-утечки была не единственной задачей, которую я пытался решить, поэтому у меня есть еще немного информации об архитектуре Intel SoC и воспроизведении PT PoC. Я надеюсь сделать это в следующей статье цикла. К этому моменту, я надеюсь, вы нашли эту статью достаточно интересной. Спасибо за уделенное внимание. <3