Самый обычный режим, после блокировки, эта память не должна быть доступна CPU в любом случае. Почитать нет, есть только поревёрсить — начать следует с ранних этапов работы BIOS.
Чтобы поревёрсить код ME пользуйтесь программками для распаковки кодовых модулей из прошивки Intel ME (ссылки в статье, во введении) + дизассемблер, разумеется.
Про Wi-Fi вы верно написали.
NFC, насколько я могу судить, является частью технологии Intel IPT (Identity Protrection Technology). Посмотрите здесь.
Область ME UMA, после инициализации BIOS-ом, залочивания и сообщения о DRAM init done через MEI к ME-контроллеру (и только после этого ME-контроллер начнёт её использовать) недоступна CPU ни в каких-режимах.
ME получает IP-адрес либо через DHCP, либо можно задать статический (это регулируется настройками AMT в меню MEBx, на компьютерах, где есть поддержка vPro). Что касается MAC адреса, то у ME MAC адрес свой (как и MAC контроллер), отличающийся на единицу от основного MAC адреса.
Размещение компьютера с ME за файервол, на котором настроена фильтрация запросов к ME по признакам (список портов которые я привёл, это лишь один из признаков, поэтому чтобы выявить все признаки, нужно хорошенько покопать в эту сторону) минимизирует attack surface по сети через Ethernet. Не более и не менее.
И да, вы правильно мыслите, есть ещё доступ к WiFi, начиная с версии 2.5 (правда там своя специфика, в частности определённая модель сетевой карты). Но эта возможность развивалась.
К тому же, как отмечено в комментарии выше, с недавних пор появилась поддержка NFC. Единственное, добавлю, что поддержка определённой модели NFC-адаптера появилась кажется в 8 или 9 серии чипсетов. А 100 серии возможность была расширена.
Прошивки 7.x и 8.x совместимы в плане апдейта. Вроде это единственный случай, когда можно обновить прошивку Intel ME на версию следующей major version.
У них одинаковые открытые ключи RSA, которые используются для верификации кода в прошивке (подробнее про защиту от модификаций прошивки Intel ME можно прочитать в моей предыдущей статье).
Поэтому, вероятно, у вас платформа какой-нибудь последней ревизии, и вендор начал пихать туда ME firmware поновее. А может вы обновляли BIOS, и в образ входила новая версия ME firmware.
Я думаю, что это зависит не от прошивки, а от аппаратной логики. Собственный MAC контроллер в чипсете позволяет ME иметь внеполосный доступ к физическому сетевому интерфейсу. Если же, MAC не свой (например, вставлена PCI-E карта), то таких привилегий у ME не будет.
Могу, конечно, заблуждаться.
Хороший вопрос. Да, не будут функционировать некоторые ACPI функции (которые повесили на ME), управление кулерами, ICC (управление частостами и разгон), программный TPM 2.0 и некоторые прикладные технологии Intel (в духе IPT) работать не будут. Точнее можно сказать для конкретной модели ПК, изучив состав кодовых модулей в прошивке Intel ME.
Всё, что жизненно необходимо компьютерной системе требуется реализовать в BIOS.
На всякий случай отмечу: обработкой function-кнопок на ноутах (уровень яркости экрана, громкость, подсветка, тачпад и прочее) занимается ACPI Embedded Controller (EC), а не ME. Следовательно, эта функциональность не пропадёт.
Есть ещё варианты платформ, которые подойдут в случае, если не волнует обратная совместимость с x86: Power8, Talos, Novena.
Очень интересный проект Purism.
Добавлю, что у многих vPro- и не-vPro материнок абсолютно одинаковые регионы ME)
Например, на плате с чипсетами Qx и Hx.
Таким образом, реализация той же AMT присутствует даже там, где нет шильдика vPro. Но на не-vPro платформе не хватает другого важного компонента: инциализируещего AMT кода из MEBx.
Спасибо. Не совсем, хотя на первый взгляд, очень похоже, особенно в ранних версиях.
Во-первых, поддержку спефикации IPMI может реализовывать (причём и аппаратную, и программную часть) не только Intel, а ещё ряд вендоров. Например, у HP есть iLO, у Dell — iDRAC. В случае с ME происходит lock in на вендора.
Но правильнее, на мой взгляд, сравнивать IPMI с возможностями AMT. Хотя технологии преследуют разные цели:
AMT — полный «захват» управления над удалённым компьютером для дминистрирования. Говоря простым языком: ОС переустановить, от вирусов вылечить, файрвол настроить, настройки в BIOS setup поменять и прочее;
IPMI — стандарт подчинения серверами ряду команд для удобства управления (причём даже не столько управления сколько мониторинга за состоянием: крутятся вентиляторы, ничего не отвалилось/сожглось и т.п.).
Во-вторых, разница в архитектуре существенная. BMC — это, прежде всего, отдельная микросхема (рядом которой есть ещё одна одтельная микросхема которая хранит BMC firmware) не наделённая такими возможностями как ME (доступ к содержимому оперативной памяти, видеопотоку… ).
Хотя, в самых первых версиях у Intel подсистема ME использовалась в качестве BMC в серверных платформах. Это был ICH Intel 631xESB / 632xESB (ESB2), если не ошибаюсь.
Говоря о разнице, хочется отметить, что ничего не мешает этим технологиям (ME и BMC) сосуществовать вместе на одной серверной платформе. Так много где, в тех же цисках (с чипсетами Intel, разумеется).
По сети облом: умные люди обычно создают отдельный влан
Конечно, наличие правильно настроенного VLAN-а усложнит атаку на коммутатор по сети. Но не исключит, если «взять» сначала узел, имеющий туда (во влан) прямой доступ.
К тому же, коммутаторы могут смотреть не только во влан, а еще и на другие узлы (полевые устройства, например). Я упомянул этот atack surface. Кстати, подобный класс атак на АСУ ТП рассматривался нашей компанией.
И вы правильно отметили о возможности найти RCE:
долго копаться и перешить вот так на лету влив нужный код в ОЗУ
Как я уже говорил механизмов защиты от эсплуатации бинарных уязвимостей в изученных прошивках нет, а это только облегчает задачу. И копаться уже не так долго, как могло бы быть.
Тем не менее, вланы и механизмы защиты не помогут, если новый свитч уже придёт «протрояненным». Или его обновят на малварную прошивку через COM-порт. Оба случая подразумевают физический доступ:
Подписывание прошивки — фигня.
С одной стороны кому будет оч нужно может либо физически перепаять флеху с памятью
Аутентификация через ком порт тоже нафиг не сдалась: если есть физ доступ значит можно всё.
Как раз не фигня. В следующей статье я опишу пример, где физический доступ не даёт прав «можно всё», а именно:
прошивку перешить не получится, точнее получится (и то, только аппаратными средствами), только работать ничего не будет :)
перепайка будет не рентабельна, не говоря уже о том, что это вообще едва применимо в полевых условиях. Возвращаясь к обсуждаемому примеру, проще уж свитч подменить :)
влив нужный код в ОЗУ и далее уже во флеш
И опять же, наличие контроля подлинности и механизма защиты флэш-памяти хотя бы исключили возможность закрепления на свитче (в случае эксплуатации бинарной уязвимости).
Про расчёт только на выполнение основных задач я согласен:
Мозг у свича мягко говоря никакой
Железо, действительно, не огонь. При том, что эти коммутаторы, по сравнению с обычными, стоят ощутимо дороже. За что переплата? По факту – за старое hardware и firmware в якобы ударопрочном пластиковом корпусе с креплением под DIN-рейку, которое отламывается на раз-два (это я о Hirschmann, у Phoenix Contact корпус металлический). Ну и за поддержку специфических для промышленных сетей протоколов.
Вендоры всё таки позиционируют эту продукцию как девайсы повышенной надёжности. Хотелось бы чтобы они были надежными во всех смыслах (не только в плане эксплуатации, но и в плане безопасности). Потому, что импакт от компрометации промышленного оборудования может быть очень серьёзным.
Чтобы поревёрсить код ME пользуйтесь программками для распаковки кодовых модулей из прошивки Intel ME (ссылки в статье, во введении) + дизассемблер, разумеется.
NFC, насколько я могу судить, является частью технологии Intel IPT (Identity Protrection Technology). Посмотрите здесь.
Область ME UMA, после инициализации BIOS-ом, залочивания и сообщения о DRAM init done через MEI к ME-контроллеру (и только после этого ME-контроллер начнёт её использовать) недоступна CPU ни в каких-режимах.
Здесь Intel ME используется для циклической записи в разные участки оперативной памяти компьютера обычной текстовой строки.
Если хотите поэкспериментаровать с этим PoC, лучше найти где-нибудь МП Intel DQ35JO/DQ35JOE или DQ35MP/DQ35MPE.
У ME есть и другая периферия (немного подробнее, в моей предыдущей статье).
И да, вы правильно мыслите, есть ещё доступ к WiFi, начиная с версии 2.5 (правда там своя специфика, в частности определённая модель сетевой карты). Но эта возможность развивалась.
К тому же, как отмечено в комментарии выше, с недавних пор появилась поддержка NFC. Единственное, добавлю, что поддержка определённой модели NFC-адаптера появилась кажется в 8 или 9 серии чипсетов. А 100 серии возможность была расширена.
У них одинаковые открытые ключи RSA, которые используются для верификации кода в прошивке (подробнее про защиту от модификаций прошивки Intel ME можно прочитать в моей предыдущей статье).
Поэтому, вероятно, у вас платформа какой-нибудь последней ревизии, и вендор начал пихать туда ME firmware поновее. А может вы обновляли BIOS, и в образ входила новая версия ME firmware.
Могу, конечно, заблуждаться.
Всё, что жизненно необходимо компьютерной системе требуется реализовать в BIOS.
На всякий случай отмечу: обработкой function-кнопок на ноутах (уровень яркости экрана, громкость, подсветка, тачпад и прочее) занимается ACPI Embedded Controller (EC), а не ME. Следовательно, эта функциональность не пропадёт.
Очень интересный проект Purism.
По последней ссылке найдёте целый сайт посвящённый всяким гайдам по AMT. Много инструкций можно найти там.
Да, мысли правильные) вполне возможно, что есть. Такую технологию спецслужбам оставить без внимания — не верю.
Её не нужно настраивать, она сама по себе работает)
Если вы про другое, то, пожалуйста, конкретизируйте вопрос.
ME v1.0 был интегрирован именно в южный мост чипсета. Я думаю, авторы этой картинки (не я рисовал) хотели показать связь через SMBus.
Хотя могу заблуждаться.
Например, на плате с чипсетами Qx и Hx.
Таким образом, реализация той же AMT присутствует даже там, где нет шильдика vPro. Но на не-vPro платформе не хватает другого важного компонента: инциализируещего AMT кода из MEBx.
Во-первых, поддержку спефикации IPMI может реализовывать (причём и аппаратную, и программную часть) не только Intel, а ещё ряд вендоров. Например, у HP есть iLO, у Dell — iDRAC. В случае с ME происходит lock in на вендора.
Но правильнее, на мой взгляд, сравнивать IPMI с возможностями AMT. Хотя технологии преследуют разные цели:
Во-вторых, разница в архитектуре существенная. BMC — это, прежде всего, отдельная микросхема (рядом которой есть ещё одна одтельная микросхема которая хранит BMC firmware) не наделённая такими возможностями как ME (доступ к содержимому оперативной памяти, видеопотоку… ).
Хотя, в самых первых версиях у Intel подсистема ME использовалась в качестве BMC в серверных платформах. Это был ICH Intel 631xESB / 632xESB (ESB2), если не ошибаюсь.
Говоря о разнице, хочется отметить, что ничего не мешает этим технологиям (ME и BMC) сосуществовать вместе на одной серверной платформе. Так много где, в тех же цисках (с чипсетами Intel, разумеется).
Конечно, наличие правильно настроенного VLAN-а усложнит атаку на коммутатор по сети. Но не исключит, если «взять» сначала узел, имеющий туда (во влан) прямой доступ.
К тому же, коммутаторы могут смотреть не только во влан, а еще и на другие узлы (полевые устройства, например). Я упомянул этот atack surface. Кстати, подобный класс атак на АСУ ТП рассматривался нашей компанией.
И вы правильно отметили о возможности найти RCE:
Как я уже говорил механизмов защиты от эсплуатации бинарных уязвимостей в изученных прошивках нет, а это только облегчает задачу. И копаться уже не так долго, как могло бы быть.
Тем не менее, вланы и механизмы защиты не помогут, если новый свитч уже придёт «протрояненным». Или его обновят на малварную прошивку через COM-порт. Оба случая подразумевают физический доступ:
Как раз не фигня. В следующей статье я опишу пример, где физический доступ не даёт прав «можно всё», а именно:
И опять же, наличие контроля подлинности и механизма защиты флэш-памяти хотя бы исключили возможность закрепления на свитче (в случае эксплуатации бинарной уязвимости).
Про расчёт только на выполнение основных задач я согласен:
Железо, действительно, не огонь. При том, что эти коммутаторы, по сравнению с обычными, стоят ощутимо дороже. За что переплата? По факту – за старое hardware и firmware в якобы ударопрочном пластиковом корпусе с креплением под DIN-рейку, которое отламывается на раз-два (это я о Hirschmann, у Phoenix Contact корпус металлический). Ну и за поддержку специфических для промышленных сетей протоколов.
Вендоры всё таки позиционируют эту продукцию как девайсы повышенной надёжности. Хотелось бы чтобы они были надежными во всех смыслах (не только в плане эксплуатации, но и в плане безопасности). Потому, что импакт от компрометации промышленного оборудования может быть очень серьёзным.