Часть II

Позвольте мне рассказать вам историю (думаю, я начну все свои посты в блоге с этого, учитывая, как долго они всегда заканчиваются).

Некоторое время я работал над воспроизведением уязвимости Intel, о которой компания PT Research рассказала на выставке BlackHat Europe 2017, мне удалось выполнить о чем рассказывалось, и поэтому мне захотелось поделиться своим путешествием и опытом со всеми, в надежде, что это поможет другим взять управление своих машин под контроль (а не наоборот).

Во-первых, для тех, кто не знает, компания Positive Technologies (именуемая здесь 'PT Research', 'PT Security' или просто 'PT') выпустила на BlackHat 2017 информацию о способе запуска неподписанного кода в Движке Управления Intel (Intel Management Engine). А для тех, кто не знает, Intel ME представляет собой «безопасный» процессор, который работает на каждом чипе Intel (с 2006 года) и который, как предполагается, имеет полный доступ к нашим системам. Вы можете прочитать больше об этом здесь и здесь, но описание, которое я прочитал, и которое понравилось мне больше всего, это - FAQ Libreboot (хоть оно, все таки, немного устарело).

Что такоеIntel Management Engine или Движок Управления Intel?

Подводя итог, ME (Management Engine) - это второй процессор, встроенный в каждый PCH (чипсет материнской платы), который работает с максимально возможными привилегиями, имеет свою собственную прошивку с подписью Intel и заботится о многих вещах, о которых вы не знаете. Главным из них является AMT (Intel Active Management Technologies), которая позволяет системному администратору удаленно получать доступ, управлять, обновлять, форматировать и т.д. компьютер по сети, и это даже если компьютер выключен. Это называется управлением "вне диапазона", потому что мы не можем управлять при помощи программных обеспечений, запущенными на главном процессоре (например, teamviewer/skype remote desktop или что-то в этом роде), но управлять можно, даже если вся ваша операционная система повреждена, или на ней есть вирус, или машина фактически выключена.

Это довольно страшно. Intel сделала это, потому что когда вы системный администратор в компании, которая имеет тысячи компьютеров, или университет, или даже небольшой бизнес с дюжиной компьютеров к примеру, и вы хотите обновить их все до более новых версий из-за размышлений безопасности, то вы можете сделать все это сразу, не вставая из своего кресла, и вам не нужно будет проходить через все здание, и вставлять USB ключ, и включать те машины, которые были выключены, и т.д... Настоящий вопрос, однако, заключается в том, почему для потребителей не доступна возможность отключить ME? Как обычному пользователю, мне не нужна эта возможность для удаленного управления машиной, поэтому я хочу ее отключить, но не могу. Это привело к появлению множества FUD (страх, неопределенность и сомнения), окружающих ME как способ для Intel контролировать мир!



Главный Исполнительный Директор Intel

Я хотел выяснить, что являлось правдой, а что нет, когда я углублялся в реверс инжинеринг и тыкал в МЕ. У ME действительно есть законная и обоснованная функция, но сейчас он делает гораздо больше, так как он заботится об инициализации аппаратуры, загрузке основного процессора, контроле регистров часов, управлении DRM для Audio/Video, программном TPM и многом другом. Эти дополнительные задачи предположительно являются причиной, по которой он не может быть отключен для потребительских продуктов. К сожалению, это также означает, что вы должны доверять и верить, что Intel не делает ничего вредоносного (или не позволяет другим делать что-то вредоносное по их некомпетентности). Дело не в том, что я считаю Intel злой корпорацией, которая внедряет малвари в каждый компьютер, а в том, что я просто не доверяю им. Я начал изучать МЕ, пытаясь заставить его выполнить мой код, используя эксплойт, и взял на себя миссию заставить МЕ контролировать и шпионить за моими USB-устройствами. Это началось, когда я ещё работал с Purism, но даже после того, как я ушёл из этой компании, я продолжал работать над этим, снова и снова. Чуть больше года назад, я наконец-то достиг достаточного прогресса, который, как мне кажется, заслуживает того, чтобы написать что-нибудь об этом. Особенно с тех пор, как я "оживил" этот блог парой постов о реверс-инжинеринге в прошлом месяце.

Прежде всего, Intel Management Engine (IME) или Management Engine (ME) или CSME (Converged Security and Management Engine) или просто CSE (Converged Security Engine), а иногда его называют TXE (Trusted eXecution Engine) или SPS (Server Platform Services), раньше его вообще называли Intel Management BIOS Extension (IMEBx). Да, это конечно может сбить с толку... особенно если учесть, что "ME" может относиться как к самому ядру процессора Management Engine, так и к прошивке Management Engine, которые зачастую неотличимы друг от друга. Я не смотрел ни на IMEBx (он старый), ни на SPS (серверы мне безразличны), но думаю, что можно с уверенностью сказать, что 'CSE' и 'CSME' - это аппаратные ядра, а 'TXE' и 'ME' - это их прошивки, соответственно. Я не уверен, что это правда, поскольку я слышал, что 'CSME' также относится к микропрограммному обеспечению, а не только к аппаратному, но в основном все эти термины взаимозаменяемы, и я видел, как в документах Intel их использовали без задней мысли.

Могу уверенно сказать, что CSE и CSME - это одно и то же, одно и то же аппаратное обеспечение, так как, насколько я вижу, их прошивки практически одинаковы. CSE используется для "маломощных/дешевых" платформ, таких как Celeron/Apollolake, например (приставки, нетбуки, дешевые и маломощные ноутбуки и т.д.), в то время как CSME используется для "настольных/ноутбучных" высокопроизводительных процессоров, таких как Skylake, Kabylake, CoffeLake и т.д... Основное различие между ними заключается в том, что CSE не включает AMT (функцию удаленного администрирования), в то время как CSME включает ее. CSE запускает прошивку TXE, которая точно такая же, как и прошивка ME, но опять же без функций AMT. Очевидно, что я не могу попытаться запустить прошивку ME на Apollolake с CSE, потому что каждая версия будет работать только для одной платформы (аппаратная инициализация/регистрация специфична для каждой платформы). Поэтому, глядя на их код, я могу с уверенностью сказать, что они практически идентичны. Хоть один делает больше, чем другой, но это тот же самый код, та же самая базовая архитектура и функционирование. TXE/CSE, вероятно, просто дешевле для Intel, потому что у них меньше возможностей для тестирования/контроля качества перед выпуском.

В этом посте я буду говорить и о CSE, и о CSME, потому что PT Research выпустила их эксплойт, поэтому мы попробуем запустить свой собственный код на платформе Apollolake (запустив TXE на CSE). И что же я сделал, так это «поиграл» с этим, а также портировал его для работы на платформе Skylake (запустив ME на CSME).

Понимание CSE для дальнейшей эксплуатации CSME эксплойта.

Первое, что я хочу объяснить, так это как запустить свой собственный код на CSE (TXE v3.0). Это будет довольно долго, поэтому я думаю, что разобью эту статью на 3 поста: «Понимание эксплойта CSE», «Портирование эксплойта на CSME», «как «побаловаться» с контроллером USB через ME».

Вы уже можете обратиться к презентации Positive Technologies, которую провели Mark Ermolov и Maxim Goryachy на BlackHat Eruope 2017. Их слайды можно скачать здесь, а презентацию - здесь. Здесь объясняется все (в основном), что вам нужно сделать. Затем вы можете взглянуть на их Proof of Concept релиз эксплойта на github для систем Apollolake.

Прежде чем вы пойдёте дальше, этот абзац не будет похож на мои предыдущие посты, которые пытаются объяснить вещи на базовом уровне (и этот уровень будет повышаться, чем дальше вы будете читать). Это будет быстро с технической точки зрения, и прежде чем вы продолжите, вы должны прочитать и понять эксплойт, как это объясняется в презентации PT, ссылки на которую приведены выше. Если вы не можете следовать ему, то вы просто заблудитесь. И так как я предполагаю, вы с ним ознакомились и все поняли.

Вот краткое изложение эксплойта, который PT рассказывали в своей презентации :

• Прошивка ME состоит из нескольких "разделов", одним из которых является раздел 'MFS' (ME File System), который содержит различные конфигурационные файлы.
  
• Хоть большинство разделов подписаны и не могут быть изменены, так как содержат код, раздел MFS не является таковым, и поэтому может быть изменён нами, смертными. В нём есть дополнительные ограничения, которые делают некоторые файлы не модифицируемыми пользователем.
  
• Файл в разделе MFS под названием "/home/bup/ct" используется для инициализации конфигурации концентратора трассировки (Trace Hub Configuration) ME и может модифицироваться пользователем.
  
• Процесс ME BUP (Hardware Bring-UP) считывает весь файл "/home/bup/ct" в буфер размером 808, не проверяя, подойдет ли этот файл: здесь мы можем наблюдать эксплойт переполнения буфера.
  
• Есть security-cookie/stack-guard, который защищает МЕ от переполнения буфера, делая его просто бесполезным.
  
• В самом низу стека (первые его 0x18 байт) находится структура TLS (Thread Local Storage), которая содержит указатель на контекст syslib.
  
• Файл "/home/bup/ct" считывается фрагментами по 64 байта и копируется в общий блок памяти
  
• Запись в блок общей памяти (с функцией sys_write_shared_mem) заставляет его читать адрес назначения из дескриптора блока общей памяти, находящегося в контекстной структуре syslib.
  
• Перезапись стека до самого конца. Перезаписывание контекста syslib, указывая его на пользовательский блок общей памяти, который имеет адрес назначения, указывающий на адрес возврата memcpy, позволяет нам контролировать, куда мы хотим вернуть функцию, таким образом, что бы обходить защиту от копирования/стек-гарда безопасности, которая находится на месте.
  
• Используя как эксплойт переполнения буфера, так и эксплойт TLS/syslib-context/shared-memory, мы можем контролировать код, который выполняется с помощью ROPs : запуская наш собственный неподписанный код.

Используя еще одну презентацию от Positive Technologies, на этот раз на 34-м Chaos Communication Congress, можно пронаблюдать наборы микросхем Intel, которые поддерживают JTAG, которые, в свою очередь позволит полностью отладить всё что нам нужно. Для того, чтобы мы могли использовать JTAG само ядро ME, нам потребуется разблокировка уровня 'RED'. Взгляните на эту небольшую таблицу, взятую из еще одной презентации Positive Technologies (BlackHat Asia 2019).



Все, что нам нужно, чтобы включить RED разблокировку, это установить значение 3 в регистре DfX Aggregator. Это довольно легко можно провернуть, как только у нас появится наш собственный код, запущенный на ME. Тогда мы сможем создать ROP цепь, которая может быть использована для включения DCI и режим RED Разблокировки и даст нам доступ к ME JTAG, для управления другим ПК через USB.

Что-то, чего вы, возможно, сначала не поняли (а я не понял, пока не углубился), так это то, что эксплойт, объясненный в презентации BlackHat Europe 2017, сильно отличается от того, который был выпущен в качестве PoC. Переполнение буфера при чтении файла "/home/bup/ct" так же само, но это простая часть (трудно найти, но просто использовать: запишите файл размером более 808 байт). Не знаю почему, не спрашивайте, я тоже не смог найти ответ, но они решили выпустить PoC для Apollolake (TXE 3.x), а не для Skylake (ME 11.x), несмотря на то, что их презентация была о том, как использовать его на Skylake. Я решил, что если я хочу перенести их эксплойт на Skylake, то сначала мне нужно понять, как он работает на Apollolake, а потом просто найти подходящие смещения для моей версии ME на Skylake, верно?... Нет! На самом деле мне потребовалось много времени, чтобы понять, что они делают, и что это другой эксплойт. В презентации говорили о том, как они перезаписывают TLS с помощью syslib контекста, чтобы взять общий адрес назначения памяти, и чтобы в дальнейшем они могли контролировать memcpy для перезаписи адреса возврата их функции и обойти stack guard security cookie.

Проблема этого метода заключается в том, что он требует два действия, первый – перезапись контекста TLS/syslib, а второй – выполнение операции memcpy, которая позволит выполнить эксплойт. На skylake, это не проблема, файл "/home/bup/ct" читается фрагментами по 64 байта, поэтому вы перезаписываете syslib контекст одним фрагментом, а затем перезаписываете свой адрес возврата со следующим фрагментом. На Apollololake, к сожалению, не используется чтение фрагментов. Так как это упрощённая прошивка, MFS (ME File System) на прошивке отличается, и я полагаю, что файл считывается сразу. Что означает, что эксплойт в презентации не может быть использован. Так... что же они делают?

Эксплойт TXE

Если вы будете следовать инструкциям в репозитории IntelTXE-PoC, то увидите, что весь эксплойт TXE хранится в файле "/home/bup/ct" (Trace Hub Configuration), который генерируется скриптом me_exp_bxtp.py. Это файл, который вы генерируете, и, конфигурируя ME с помощью инструментов Intel, устанавливая CT-файл в поле "Конфигурация трассировочного концентратора", позволяет выполнить эксплойт. Но что именно он делает? Что в этом файле? Скрипт, который его генерирует, к сожалению, имеет несколько таинственных чисел, на понимание их происхождения у меня ушло много времени. Давайте взглянем на них:

Python:


Итак, согласно презентации BlackHat, при вызове bup_read_mfs_file, происходит фрагментарное чтение файла MFS, а при вызовеsys_write_shared_memory, выполняется наш эксплойт, но из стека, который я разместил и проанализировал выше. Но это не совсем то, что происходит, потому что я могу увидеть поврежденный стек (переписанный последующими вызовами), который доказывает, что bup_read_mfs_file вернулся до того, как произошло выполнение эксплойта, а затем, после реверсинга кода, я заметил, что фрагментарное чтение не происходит. И теперь это объясняет, почему всё не так, как в презентации. Так что эксплойт должен происходить между вызовом bup_dfs_read_file и окончания bup_init_trace_hub, так как security cookie (stack guard) уничтожается при переполнении буфера, поэтому мы не можем позволить bup_init_trace_hub вернуть его... Если посмотреть, что происходит вbup_init_trace_hub после вызова bup_dfs_read_file, то мы увидим это :

C++:


Контекст systracer находится в положении syslib_ctx + 0x200, и если мы еще раз посмотрим, что делает эксплойт от PT, то он устанавливаетsyslib_ctx в положение 0x55a58, так что модифицированные данные (systracer) находятся в положении 0x55c58, что является адресом возврата самой функции bup_init_trace_hub_set_systracer. Вот как на самом деле выглядит стек, если мы проследим за всеми push/pop/call/ret от точки входа до момента, когда выполняется эксплойт:

Код:


Таким образом, видно, что модифицируемое значение является 0x55c58, которое в соответствии со стеком является адресом возврата bup_init_trace_hub_set_systracer, если посмотреть на дамп стека раньше, то видно также, что значение 0x55c68 равно 7, как и ожидалось (за счет *(uint32_t *)(systracer + 0x10) = seg1;). Если мы можем контролировать возвращаемое значение нашей собственной функции, то мы контролируем то, что мы выполняем.

Единственное, что может контролироваться нашим возвращаемым значением - это биты 0, 1, 6, 7, 8 и 9. Биты 0 и 1 всегда устанавливаются на 1, биты 6, 7 и 8 зависят от значения, сохраненного в сегменте 0xBF со смещением 0x10, а бит 9 зависит от значения, сохраненным в сегменте 0xBF со смещением 0xE0. К счастью, оба эти значения в сегменте 0xBF могут быть установлены через заголовок файла конфигурации tracehub (цикл в конце bup_init_trace_hub).

Заголовок файла ct имеет такой формат:

C++:


При этом заголовок файла ct устанавливается эксплойтом в:

Код:


Мы можем увидеть, что он имеет 2 записи, которые устанавливают 0xBF:E0 в 0x5F000000 и 0xBF:10 в 0x000888.

При установке этих значений функция bup_init_trace_hub_set_systracer, вызываемая в bup_init_trace_hub, перезапишет свой собственный адрес возврата при смещении 0x55C58 от 0x4995B до 0x49BDB, что заставляет ее «перепрыгнуть» в середину sub_49BB6 со стеком/ регситром ebp bup_init_trace_hub, таким образом, когда эта функция вернётся, она вернётся по адресу, сохранённому в смещении retaddr bup_init_trace_hub, которое равно 0x55FB8. Обратите внимание, что функция sub_49BB6 не проверяет стек на наличие security cookie, и точка, в которую мы «перепрыгиваем», заставляет ее вызывать несколько функций, которые просто возвращаются с ошибкой, потому что их параметры неправильные.

Этот адрес 0x55FB8, содержащий retaddr, находится на позиции 0x338 в ct-файле (0x56000 - 0x55FB8 = 0x48 байт из конца файла размером 0x380), который содержит:

Адрес 0x16e1a находится в середине существующей инструкции, но он будет интерпретирован как pop esp, за которой последует ret. При этом в указатель стека выводится следующее значение 0x55c98 и возвращается к нему. Если вы помните, я говорил, что буфер ct сохраняется в 0x55C80 (что также видно из анализа стека выше), поэтому адрес 0x55C98 находится со смещением 0x18 в файле CT (который находится сразу после заголовка и тех 2 записей, которые устанавливают значения в сегменте 0xBF), где мы находим актуальные гаджеты ROP, которые включают DCI, устанавливают RED разблокировку, а затем входим в бесконечный цикл.

Если мы взглянем еще раз на python скрипт, который генерирует CT файл для эксплойта, то теперь мы можем понять все, что он делает:

Python:


Единственное оставшееся таинственное число находится в переменной data_tail, которая является структурой TLS. Значение 0x03000300 - это просто идентификатор потока.

Rops

Последняя версия эксплойта, который позволяет вызывать процессор, просто добавляет гаджеты ROP, необходимые для продолжения инициализации bup точно так же, как это было бы сделано, сразу после возврата bup_init_trace_hub (путем сброса контекста syslib в нужное значение, а затем восстановления стека и регистров и возврата в bup_run_scripts).

ROPs довольно просты, они делают две вещи : Сначала они включают интерфейс DCI, затем устанавливают значение DfX-агрегатора на 3 (что включает RED-разблокировку для JTAG), после чего входят в бесконечный цикл.

C++:


Долгое время я задавался вопросом "что это за sideband mapping" и "что это за значения 0x706a8 и 0x70684". Я объясню это в следующем посте блога (в ближайшие пару дней), но вкратце, это приводит к тому, что сегмент 0x19F сопоставляется с частными реестрами конфигурации (PCR) DCI и Private Configuration Registers (PCRs) DfX Aggregator devices. Таким образом, сначала вы сопоставляете сегмент 0x19F с PCR устройства DCI, затем включаете DCI, устанавливая флаги на 1, затем сопоставляете сегмент 0x19F с устройством DfX-agg, а после всего этого устанавливаете регистр значения в его PCR со смещением от 0x8400 до 3 (red).

Установив только эти два значения, вы включаете DCI и RED разблокировку, и эксплойт работает. Поздравляем, теперь вы можете играть с вашим CSE устройством через JTAG.

Заключение

В файле CT есть 4 вещи :

• Header: который устанавливает различные значения в сегменте 0xBF для работы системного анализатора
  
• Big ROPs: которые выполняют пользовательский код, который мы хотим включить DCI и RED разблокировки
  
• Маленькие ROPs: Маленький заголовок при смещении 0x338, который делает поп-эсп; повторите, чтобы вернуть нас к первому большому ROP'у.
  
• TLS: модифицированный заголовок TLS, который указывает контекст syslib на 0x55A58, таким образом, смещение systracer указывает на обратный адрес функции, которая его устанавливает.

Новый TLS имеет новый syslib-контекст, который указывает смещение systracer на адрес возврата функции bup_init_trace_hub_set_systracer, которая модифицирует его, используя значения в заголовке ct-файла, чтобы перейти к смещению 0x49BDB в sub_49BB6 таким образом, чтобы при возвращении этой функции, он перейдет на маленький ROP, который заменит ESP на адрес большой ROPs, а затем выполнит их и включит DCI, JTAG и продолжит инициализировать процесс в зависимости от версии используемого эксплойта.

Да... это было очень весело. Так что, этот эксплойт не совсем тот же самый, что и эксплойт Skylake. Эксплойт Skylake на самом деле довольно сложен для понимания, потому что он включает в себя больше переменных. Полагаю, это и есть причина, по которой PT не выпустил его.

В следующем посте я объясню, как я портировал этот эксплойт на ME 11.x, используя информацию, предоставленную Positive Technologies, и объясню, как портировать на него вашу собственную версию ME, используя то, что я написал в качестве базы.

Спасибо за внимание!