|
Цитата:
Позвольте мне рассказать вам историю (думаю, я начну все свои посты в блоге с этого, учитывая, как долго они всегда заканчиваются). Некоторое время я работал над воспроизведением уязвимости 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 контролировать мир! https://forum.antichat.xyz/attachmen...7804172090.png Главный Исполнительный Директор 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 рассказывали в своей презентации :
https://forum.antichat.xyz/attachmen...7804336894.png Все, что нам нужно, чтобы включить 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: Код:
STACK_BASEC++: Код:
voidКод: Код:
TXE STACK - bup_entry:Единственное, что может контролироваться нашим возвращаемым значением - это биты 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++: Код:
structКод: Код:
00 00 00 00 00 00 02 00 e0 00 00 02 00 00 00 5fПри установке этих значений функция 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), который содержит: Код:
1a 6e 01 00 98 5c 05 00Если мы взглянем еще раз на python скрипт, который генерирует CT файл для эксплойта, то теперь мы можем понять все, что он делает: Python: Код:
STACK_BASERops Последняя версия эксплойта, который позволяет вызывать процессор, просто добавляет гаджеты ROP, необходимые для продолжения инициализации bup точно так же, как это было бы сделано, сразу после возврата bup_init_trace_hub (путем сброса контекста syslib в нужное значение, а затем восстановления стека и регистров и возврата в bup_run_scripts). ROPs довольно просты, они делают две вещи : Сначала они включают интерфейс DCI, затем устанавливают значение DfX-агрегатора на 3 (что включает RED-разблокировку для JTAG), после чего входят в бесконечный цикл. C++: Код:
// Enable DCIУстановив только эти два значения, вы включаете DCI и RED разблокировку, и эксплойт работает. Поздравляем, теперь вы можете играть с вашим CSE устройством через JTAG. Заключение В файле CT есть 4 вещи :
Да... это было очень весело. Так что, этот эксплойт не совсем тот же самый, что и эксплойт Skylake. Эксплойт Skylake на самом деле довольно сложен для понимания, потому что он включает в себя больше переменных. Полагаю, это и есть причина, по которой PT не выпустил его. В следующем посте я объясню, как я портировал этот эксплойт на ME 11.x, используя информацию, предоставленную Positive Technologies, и объясню, как портировать на него вашу собственную версию ME, используя то, что я написал в качестве базы. Спасибо за внимание! |
Если такие чипсеты который работает с максимально возможными привилегиями без ведома пользователя. Тогда нужно рассказывать как создавать ПО для выявления таких уязвимостей 0-дня. А не экслуатировать ими.
|
| Время: 09:00 |