Intel ME. Как избежать восстания машин?



    В прошлый раз мы рассказали об Intel Management Engine (ME) — подсистеме, которая встроена во все современные компьютерные платформы (десктопы, лэптопы, серверы, планшеты) с чипсетами компании Intel. Эта технология многими воспринимается как аппаратная «закладка», и на то есть причины. Достаточно сказать, что Intel ME является единственной средой исполнения, которая:
    • работает даже тогда, когда компьютер выключен (но электропитание подаётся);
    • имеет доступ ко всему содержимому оперативной памяти компьютера;
    • имеет внеполосный доступ к сетевому интерфейсу.


    Ошарашенный присутствием такого компонента в компьютере, пользователь (получается, что именно «пользователь», а не «владелец») наверняка задавался вопросом: можно ли выключить Intel ME?

    Эта статья целиком посвящена этому вопросу.



    Введение



    Напомним, что основным компонентом Intel ME является встроенный в чипсет микроконтроллер с кастомной архитектурой. Известна лишь базовая модель, это 32-х разрядный ARCtangent-A4 (ME 1.x — 5.x), ARCtangent-A5 (ME 6.x — 10.x), SPARC (TXE) или x86 (ME 11.x — ...).

    Начиная с 6-й версии, ME-контроллер встраивают во все чипсеты Intel.


    [рисунок взят отсюда]

    Загрузчик его прошивки хранится во внутренней ROM и недоступен для анализа. Сама прошивка располагается в регионе ME во внешней SPI флэш-памяти (т.е. в той же памяти, где хранится BIOS). Структура этой прошивки такова, что весь исполнимый код разбит на модули, которые хранятся в сжатом виде (либо кастомной реализацией алгоритма Хаффмана, либо LZMA). Эти кодовые модули криптографически защищены от модификаций.

    Если есть желание поревёрсить прошивку, рекомендуем воспользоваться этими двумя инструментами для изучения её структуры и распаковки кодовых модулей.

    Итак, рассматриваемая подсистема является аппаратно-программной основой для различных системных функций (некоторые раньше реализовывали в BIOS) и технологий Intel. Их имплементация включается в состав прошивки Intel ME. Одной из таких технологий, использующих несколько особых привилегий Intel ME, является Active Management Technology (AMT).


    Контроль за состоянием AMT



    AMT – технология удалённого администрирования компьютерных систем, для которых заявлена официальная поддержка Intel vPro (это бренд, объединяющий несколько технологий, в том числе, AMT). Речь идёт о системах с чипсетами линейки Q (например, Q57 или Q170).

    Учитывая высокую стоимость таких платформ, вряд ли кто-то случайно приобретёт компьютер с AMT для того, чтобы принципиально этой технологией не пользоваться. Тем не менее, если под рукой именно такой продукт, и есть необходимость убедиться, что AMT на текущий момент выключена, следует воспользоваться утилитой ACUwizard:


    [рисунок взят отсюда]

    или средством Intel Management and Security Status (входит в состав ПО Intel ME для vPro-платформ, можно обнаружить в трее):






    Наконец, чтобы защитить компьютеры в своей сети от несанкционированного управления извне, необходимо настроить внешний файрвол на фильтрацию AMT-запросов по признакам. Явным признаком AMT-запроса может являться порт, к которому происходит обращение:
    • 5900 – AMT VNC-сервер без шифрования;
    • 16992 – AMT веб-сервер по протоколу HTTP;
    • 16993 – AMT веб-сервер по протоколу HTTPS;
    • 16994 – AMT redirection для SOL, IDE-R, KVM без шифрования;
    • 16995 – AMT redirection для SOL, IDE-R, KVM с TLS.


    В продуктах, не относящихся к разряду vPro-платформ AMT включить нельзя, однако в состав прошивки Intel ME входят сетевые драйверы:



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

    Поэтому проблему стоит решать основательно – пытаться выключить подсистему Intel ME.


    Выключение Intel ME при помощи утилит из Intel System Tool Kit



    Вендорам материнских плат компания Intel предоставляет:
    1. Прошивку Intel ME в бинарном виде;
    2. Модули MEBx для BIOS;
    3. ПО Intel ME для ОС;
    4. Intel System Tool Kit (STK) — комплект программных средств и документации для сборки образов SPI флэш-памяти, применения этих образов и получении информации о текущем состоянии Intel ME.


    Несмотря на то, что этот комплект распространяется по NDA (судя по меткам «Intel Confidential» в прилагаемых документах), многие вендоры забывают его вырезать из архива с ПО Intel ME, который передаётся пользователям. А ещё не закрывают свои ftp-серверы от внешнего доступа. В результате, утекших версий STK очень много. Здесь можно слить комплект для любой версии Intel ME.

    Важно, чтобы major и minor version (первая и вторая цифры) используемого STK совпадала с версией Intel ME целевой системы, информацию о которой можно получить, например, воспользовавшись ME analyzer:



    Проверять текущее состояние Intel ME можно при помощи утилиты MEinfo, которая через Management Engine Interface (MEI) получает информацию о работе этой подсистемы:



    Напомним, что MEI является интерфейсом для связи основного CPU с подсистемой Intel ME и представляет собой набор регистров в конфигурационном пространстве PCI и в MMIO. Команды этого интерфейса не документированы, как и сам протокол.


    Flash Image Tool



    На старых платформах (Intel ME версии 5.x и ниже) выключить данную подсистему можно, воспользовавшись Flash Image Tool (утилита из STK, предназначенная для сборки образов SPI флэш-памяти из отдельно взятых регионов BIOS, ME, GbE). При сборке задаются параметры, которые прописываются в этих регионах и в регионе Flash Descriptors. В последнем есть один очень интересный флаг, «ME disable»:



    Таким образом, для выключения Intel ME на целевой компьютерной системе, в её SPI флэш-память следует записать (программатором) новый образ с выставленным флагом «ME disable».

    Работает ли этот способ, нам неизвестно. Но звучит правдоподобно, учитывая, что ME-контроллер в тех версиях интегрировался только в чипсеты линейки Q, т.е. был не обязательным компонентом для всех платформ.


    Flash Programming Tool



    Начиная с Intel ME 9 версии, в утилиту Flash Programming Tool, предназначенную для программирования SPI флэш-памяти компьютерных платформ, была добавлена возможность временно выключать Intel ME:



    Выключение выполняется отправкой команды в MEI. После отработки Intel ME не подаёт «признаков жизни», не отвечает даже MEI:



    Согласно документации, в таком состоянии подсистема Intel ME находится до следующего запуска компьютера или перезагрузки.

    На vPro-платформах возможность отправки этой команды есть и в более ранних версиях. Для этого необходимо воспользоваться разделом конфигурирования ME/AMT в BIOS, где должна быть опция «Intel ME disable»:


    [рисунок взят отсюда]

    Нельзя говорить о том, что этот способ позволяет полностью отключить Intel ME, хотя бы потому, что до момента принятия команды на отключение ME-контроллер успеет загрузиться, а значит, выполнить некоторую часть кода прошивки.
    Несмотря на то, что Intel ME не подаёт «признаков жизни» после этой операции, неизвестно, может ли эту подсистему заново включить какой-нибудь сигнал извне. Также неясно, насколько Intel ME выключена.


    Принудительное выключение Intel ME



    В интересах исключения возможности исполнения ME-контроллером кода прошивки, логично попробовать ограничить ему доступ к ней. А что? Нет кода – нет проблемы.

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


    1. Вырезать (обнулить) ME регион из SPI флэш-памяти.

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

    Отказ компьютерной системы грузиться без прошивки Intel ME можно объяснить важностью ME-контроллера в процессе инициализации аппаратной составляющей. А 30-минутный таймаут наводит на мысль о WDT (Watch Dog Timer).


    2. Включить не дескрипторный режим SPI флэш-памяти, т.е. «по старинке» когда в ней содержался только BIOS. Для этого требуется сделать одно из двух:
    • стереть первые 0x20 байт в ней (таким образом повредив сигнатуру 0x0FF0A55A, которая определяет режим работы флэш-памяти);
    • выставить джампер HDA_SDO (если он есть).


    Таким образом, ME-контроллер не получит доступ к своему региону, и, следовательно, не будет исполнять прошивку.

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


    3. Известно, что прошивка Intel ME распаковывается в выделенную и скрытую от основного CPU область оперативной памяти – ME UMA. Выделение и блокировку этой области осуществляет BIOS во время конфигурирования карты памяти. Тогда почему бы не вырезать эти фрагменты кода из BIOS, чтобы данная область не выделялась. Тогда прошивка ME не будет распаковываться и исполняться.

    Проведённые эксперименты показали, что такой способ тоже не годится, и система не запускается. К тому же, у ME-контроллера есть внутренняя SRAM, которая используется при недоступности ME UMA. Поэтому часть прошивки всё равно будет исполняться.


    Вывод



    Мы рассказали о предполагаемых и требующих развития способах выключения Intel ME:
    • отключение при каждом старте командой в MEI или отключение флагом в регионе flash descriptors (в зависимости от версии);
    • ограничение доступа ME-контроллеру к своей прошивке либо перевод компьютерный платформы в manufacturing mode.
    • препятствование нормальной работе ME-контроллера не обеспечивая его runtime-памятью.


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

    Вероятно, это связано с тем, что, отключая Intel ME, мы нейтрализуем важный компонент в архитектуре компьютерной системы. Например, без ME некому будет решать важные системные задачи вроде ACPI или ICC (которые когда-то реализовывались в BIOS). Чтобы заставить платформу стабильно работать без ME, как минимум, необходимо вернуть реализацию этих технологий в BIOS.

    Так или иначе, вопрос о том, как отключить Intel ME без потери работоспособности компьютерной системы, остаётся открытым.
    Метки:
    Digital Security 113,19
    Безопасность как искусство
    Поделиться публикацией
    Комментарии 56
    • +2
      Достаточно сказать, что Intel ME является единственной средой исполнения, которая имеет внеполосный доступ к сетевому интерфейсу

      вероятно, это справедливо при использовании mac из состава pch. или это и для pci-e сетевых справедливо?
      на большинстве consumer платформ второй вариант, ибо phy от intel стоит больше pci-e mac+phy от того же relatek
      • 0
        Всё верно.
        • 0
          А что им (Intel-у или производителю мат.платы) мешает в состав прошивки включить драйвера от сетевой карты Realtek, раз уж заранее известно, что она будет на борту?
          • +5
            Я думаю, что это зависит не от прошивки, а от аппаратной логики. Собственный MAC контроллер в чипсете позволяет ME иметь внеполосный доступ к физическому сетевому интерфейсу. Если же, MAC не свой (например, вставлена PCI-E карта), то таких привилегий у ME не будет.
            Могу, конечно, заблуждаться.
      • 0
        Кроме повышения безопасности, какие негативные моменты с точки зрения функционала вызовет отключение данной системы. Такие фишки как WOL, включение по нажатию клавиши, я так понимаю работать не будут?
        • +7
          Хороший вопрос. Да, не будут функционировать некоторые ACPI функции (которые повесили на ME), управление кулерами, ICC (управление частостами и разгон), программный TPM 2.0 и некоторые прикладные технологии Intel (в духе IPT) работать не будут. Точнее можно сказать для конкретной модели ПК, изучив состав кодовых модулей в прошивке Intel ME.

          Всё, что жизненно необходимо компьютерной системе требуется реализовать в BIOS.

          На всякий случай отмечу: обработкой function-кнопок на ноутах (уровень яркости экрана, громкость, подсветка, тачпад и прочее) занимается ACPI Embedded Controller (EC), а не ME. Следовательно, эта функциональность не пропадёт.
          • +13
            Не будет оверклокинга и управления частотой пользователем (ICC), могут быть проблемы с воспроизведением защищенного DRM контента (PAVP), перестанут работать выполняемые МЕ Java-апплеты (DAL, они очень редки и в живой природе практически не встречаются), в общем, всего того, что использует интерфейс HECI. Есть еще некоторые другие, более серьезные, но NDA не позволяет говорить о них ничего конкретного.
            Одно могу сказать — проблем с отключенным МЕ прилично и бороться с ними непросто, но пока это единственный способ иметь ReadOnly-прошивку, которая требуется банковской сфере, операторам игровых автоматов, промышленным автоматизаторами другим клиентам, которым требуется железная гарантия отсутсвия любых изменений в ПО системы.
            • +2
              Исходя из практики использования IT систем, можно сказать что вариант отключения ME подходит только для закрытых систем, то есть систем создаваемых с 0 и с конечным перечнем фирменного софта, рассчитанного на отсутствие ME.

              Для компаний-потребителей, тех же Банков, такой вариант мало подойдет, поскольку затраты на минимизацию риска (отключение ME, доработку систем на то чтобы они работали в новых условиях) превысят ожидаемый ущерб от атак связанных с использованием уязвимостей ME. Статистики по взломам через ME пока нет. Данное утверждение поясню на примере — падение метеорита в Датацентр реально — ущерб потеря ДЦ, вероятность реализации риска ~ 0. Ожидаемый ущерб ~ 0.

              В тоже время вопрос, какие варианты минимизации негативного влияния ME на безопасность вы можете предложить, не занимаясь отключением ME.
              • +4
                Лучший способ — избегать использования систем с МЕ (и PSP), других хороших способов защититься от МЕ, имеющего доступ к внутренней шине DMI и собственный DMA-контролер с обходом IOMMU просто нет.
                Уже не раз писал, но повторюсь: цель информационной безопасности не в закрытии уязвимостей, а в том, чтобы сделать получение несанкционированного доступа к информации дороже самой информации. Если у вас совершенно секретные данные — делайте себе процессоры сами, на своих фабриках и со своей архитектурой. Не имеете возможности или желания — придется доверять компаниям Intel и/или AMD, стратегическим партнерам АНБ. Можно еще надеяться на успех проектов вроде LowRISC/OpenRISC, но, как показывает случай Сноудена (сильно ускоривший внедрение повсеместного E2E-шифрования), пока в ME/PSP не найдут заяющую дыру, деньги в открытое железо никто вкладывать не будет и ситуация с ME сильно не изменится.
                • 0
                  Способ-то, положим, простой: не выставлять сетевой интерфейс компьютера в открытую сеть.
                  • 0
                    Не втыкать внешних устройств, не иметь поключенных к сети ПК в радиусе AirGap'а, а лучше и совсем не включать. От APT уровня StuxNet поможет только последнее.
                    • 0
                      Контролируемую зону не я изобрёл :)
                      • +1
                        Да я не спорю, только вот «кто будет контролировать контролеров»?
                        Мой опыт показывает, что административный способ решения проблем безопасности — далеко не самый лучший, если вам больше повезло — это здорово.
                        Известная картинка
                        In this corner, we have Dave!
                        • 0
                          С этим утверждением не спорю.
                  • +1
                    А у Amd есть закладки вроде intel me?
                    • +3
                      Есть, но пока еще не во всех чипсетах, а только в SoC. Это PSP, который является ядром ARM с TrustZone и используется для HVB, реализации программного TPM 2.0, ускорения криптографических операций, а в последних поколениях Falcon SoC он уже и память тренирует, и S3 resume выполняет, так что платформа теперь без PSP фактически неработоспособна. При этом его прошивка зашифрована и подписана ключем AMD, что там в ней происходит — не знает практически никто, в том числе и потому, что машин AMD на рынке кот наплакал, и заниматься их реверсом почти никому не интересно.
                      Про PSP я, кстати, уже писал, почитайте, если интересно.
                      • 0
                        О, вы об этом уже писали. Не успел ещё все ваши статьи изучить. Спасибо.
                        Походу нам нужен свой процессор, и лучше на экспорт, чтобы уже они не знали, что в нём заложено =)
                      • +1
                        У них есть AMD Platform Security Processor (PDF-презентация).
                  • 0
                    могут быть проблемы с воспроизведением защищенного DRM контента

                    вероятно, только при использовании интегрированного видео
                    ещё, вероятно, с iommu возникнут проблемы на платформах, где оно есть
                • +1
                  Правильно ли я понимаю, что проекты вроде https://libreboot.org/ или https://www.coreboot.org/ ни в коей мере не влияют на работоспособность ME?
                  • +3
                    Цель проекта LibreBoot — полностью свободная прошивка без сторонних бинарных компонентов, поэтому с чипсетами новее 5 серии он не совместмим. Проект CoreBoot использует сторонние компоненты вроде ME firmware или VBIOS, поэтому на работоспособность ME практически не влияет. Я пишу «практически» потому, что для инициализации интерфейса HECI используются UEFI DXE-драйверы, которые в CereBoot нужно еще портировать, чтобы с ME можно было общаться из ОС.
                  • 0
                    А можно ли МЕ как-то использовать во благо на Н чипсетах? Например, обновить BIOS, включить/выключить компьютер, изменить настройки BIOS и пр.
                    • +1
                      Например, обновить BIOS, ..., изменить настройки BIOS

                      Это как раз может FPT, упомянутый в статье.
                      • 0
                        Понятно, буду копать. Странно, что чипсет Н61, должна быть прошивка 7.0, а на самом деле там 8.1, хотя я её точно никогда не обновлял, и драйвера стоят последние доступные 7.0, но со всем этим хозяйством нормально работают утилиты для чипсетов *7*…
                        • 0
                          Прошивки 7.x и 8.x совместимы в плане апдейта. Вроде это единственный случай, когда можно обновить прошивку Intel ME на версию следующей major version.

                          У них одинаковые открытые ключи RSA, которые используются для верификации кода в прошивке (подробнее про защиту от модификаций прошивки Intel ME можно прочитать в моей предыдущей статье).

                          Поэтому, вероятно, у вас платформа какой-нибудь последней ревизии, и вендор начал пихать туда ME firmware поновее. А может вы обновляли BIOS, и в образ входила новая версия ME firmware.
                          • +1
                            Совместимы они только для чипсетов седьмой серии начиная со степпинга B3, поэтому просто так обновлять 7.x на 8.x не стоит — не всегда срабатывает. Если производитель уже обновил за вас — молодец, значит, сам чипсет и platform support code готовы работать с версиями 8.x, а если нет — рисковать не стоит.
                      • 0
                        Я так полагаю, использование сетевых адаптеров (занять usb или pci-e слот), особенно с какими-нибудь экзотическими чипсетами, значительно понизит вероятность утечки информации или удаленного управления компьютером?
                        p.s. как страшно жить… что по поводу ARM SoC? Там правда тоже блобов предостаточно, но если закрыть глаза про экзотическую периферию и видеоускоритель, на открытом коде вполне рабочее.
                        • 0
                          А можно ли, наоборот, включить vPro там где он заблокирован? Есть Lenovo t420s, процессор i5-2520m и чипсет qm67, vPro наличествует, но не работает. Когда-то к нам везли ноутбуки у которых был заблокирован по законодательным причинам AES (!!!) и модуль TPM, возможно, что vPro не работает по причине как-то связанной с блокировкой TPM. Очень уж хочется попробовать этот самый mei.
                        • +1
                          Полный реверс-инженеринг, очевидно. И гигантский посыл ненависти интелу.
                          • +1
                            И главное не забывать что Intel это стратегический партнер АНБ
                            • 0
                              У меня пара вопросов. Наверное это скорее в отношении серверов. Если поставить машину за файрволом, и фильтровать все что идет к/от МЕ, то это снимет угрозу?
                              И более интересный вопрос. Если вообще не пользоваться Ethernet, то не врубится ли на борде какой-нибудь вай-фай или блютус? Никто не проверял МЕ(чипсет) на предмет собственного встроенного беспроводного интерфейса?
                              А то ведь если очень надо какой-то закрытой компании, то можно не пользоваться обычного рода сетями, а эмулировать на ПЛИС+PCI что-то вроде проприетарной сети, а серверы брать обычные на x86/AMD64. И тогда встает вопрос об отстутствии «чего-то еще сетевого» на матери.
                              • +1
                                Могу сказать что с 100 серии появилась встроенная поддержка NFC в Intel ME — http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-series-chipset-datasheet-vol-1.pdf 40 страница
                                • +1
                                  Размещение компьютера с ME за файервол, на котором настроена фильтрация запросов к ME по признакам (список портов которые я привёл, это лишь один из признаков, поэтому чтобы выявить все признаки, нужно хорошенько покопать в эту сторону) минимизирует attack surface по сети через Ethernet. Не более и не менее.

                                  У ME есть и другая периферия (немного подробнее, в моей предыдущей статье).

                                  И да, вы правильно мыслите, есть ещё доступ к WiFi, начиная с версии 2.5 (правда там своя специфика, в частности определённая модель сетевой карты). Но эта возможность развивалась.

                                  К тому же, как отмечено в комментарии выше, с недавних пор появилась поддержка NFC. Единственное, добавлю, что поддержка определённой модели NFC-адаптера появилась кажется в 8 или 9 серии чипсетов. А 100 серии возможность была расширена.
                                  • 0
                                    Для доступа к Wi-Fi, как я понимаю, он физически должен быть либо в составе матери, либо отдельной карточкой. И это видно и понятно. На серьезных серверных бордах его просто нет.
                                    Но вот с NFC — это просто волшебно. :) Интересно, как это обосновывается с точки зрения удаленного администрирования?? :) Там же максимальное расстояние для связи всего несколько см… Ну хорошо… до 20см. И где базируется этот самый NFC? Там же в чипсете? У меня только единственная мысль, что возможно ME через него слушает эфир? И не факт, что только в пределах своих 13,56 МГц. Какой-то достаточно мощный сигнал. Ну и ждет какую-то сигнатуру, как спусковой крючок для темных делишек.

                                    Кстати, а эта область UMA ME доступна из режима SMM? А то ведь можно ее таким образом пофиксить. Конечно уже после загрузки, но какая разница когда…
                                    • +1
                                      Не доступна. Область эта для CPU выглядит как замапленная на несуществующее PCI-устройство, сплошные 0xFF, которые не получается переписать. Стартует ME значительно раньше процессора по power sequence, и вообще может сделать все свои темные дела до reset vector'а, так что никакие фиксы со стороны кода, выполняемого на CPU, не помогут.
                                      • 0
                                        Про Wi-Fi вы верно написали.
                                        NFC, насколько я могу судить, является частью технологии Intel IPT (Identity Protrection Technology). Посмотрите здесь.

                                        Область ME UMA, после инициализации BIOS-ом, залочивания и сообщения о DRAM init done через MEI к ME-контроллеру (и только после этого ME-контроллер начнёт её использовать) недоступна CPU ни в каких-режимах.
                                        • 0
                                          OK. Но если BIOS выделил и залочил UMA для ME, то какой режим для этого использовался? Почему нельзя зайти в тот же режим и разлочить эту область? Есть ли что-то вообще почитать, как UMA выделяется?
                                          По сути, не важно что там делал ME до загрузки. По-моему, важно его хотя бы после деактивировать.
                                          И есть ли где-то дизасемблированный код ME для последних ревизий, когда он уже на x86? Интересно посмотреть, что он там вообще делает.
                                          • 0
                                            Самый обычный режим, после блокировки, эта память не должна быть доступна CPU в любом случае. Почитать нет, есть только поревёрсить — начать следует с ранних этапов работы BIOS.

                                            Чтобы поревёрсить код ME пользуйтесь программками для распаковки кодовых модулей из прошивки Intel ME (ссылки в статье, во введении) + дизассемблер, разумеется.
                                        • 0
                                          Возможно этого расстояния будет достаточно для общения с другими устройствами внутри системного блока. Таким способом можно будет пробросить Ethernet любому другому устройству внутри системника через NFC. Например, добавили новый SSD или просто флешку воткнули… Этакий Plug&Play через NFC+Ethernet в Интернет, например.
                                        • +1
                                          При этом фаерволл должен быть на железке гарантированно без ME. Ану как МЕ, имея внеполосный доступ ко всем гнездам эзернета, увидя запросы своих братьев сам пробрасывает их дальше? Этакий не контролируемый ботнет. Есть повод задуматься.
                                      • 0
                                        А как ME получает ip адрес? Обычным образом просится к открытому dhcp? И mac адрес у него свой собственный или совпадает с основным?
                                        • 0
                                          ME получает IP-адрес либо через DHCP, либо можно задать статический (это регулируется настройками AMT в меню MEBx, на компьютерах, где есть поддержка vPro). Что касается MAC адреса, то у ME MAC адрес свой (как и MAC контроллер), отличающийся на единицу от основного MAC адреса.
                                        • +1
                                          Подскажите, а есть ли PoC-exploit демонстрирующий возможность злонамеренного использования ME?
                                          Без этого очень сложено обосновать IT и бизнесу необходимость выполнения подобных защитных мер.
                                          • 0
                                            Единственные открыто доступные описание и PoC для исполнения кода на Intel ME применяемы только на чипсете Q35.

                                            Здесь Intel ME используется для циклической записи в разные участки оперативной памяти компьютера обычной текстовой строки.

                                            Если хотите поэкспериментаровать с этим PoC, лучше найти где-нибудь МП Intel DQ35JO/DQ35JOE или DQ35MP/DQ35MPE.
                                            • 0
                                              Ещё вспомнил про этих ребят. Они этот PoC, на который я привёл ссылку выше развили и сделали кейлоггер, управляемый командами по сети.

                                            • 0
                                              Интересно, как отключать это на Apple, что-то не видел программ обновления флэша на них, отличного от заводского и чтобы еще с настройками.
                                              А уж после обновления на 10.11, 3rd party программам стало еще сложнее.
                                              • 0
                                                А это вообще есть на Apple? По крайней мере, не замечал, чтобы у меня в эппловской сети регистрировались какие-то посторонние mac адреса.
                                                • 0
                                                  Intel ME есть в абсолютно всех выпускаемых на данный момент чипсетах/SoC от Intel.
                                                  Так что, продукция Apple, на которой используются чипсеты и процессоры Intel, — не исключение.

                                                  Если, AMT (хотя я не видел, чтобы у Apple девайсов была оф. поддержка Intel vPro) не включена, по идее ME не должен лезть в сеть. По идее.
                                                  • 0
                                                    да, мне нужно больше спать :)
                                                    Мой вопрос должен был прозвучать как: есть ли подобные инструменты под OSX? чтобы выключить что то в чипсете, перенастроить его. Из того, что я знаю об этой платформе — скорее всего ничего такого нет, что оставляет мне очередную возможность позлорадствовать на тему…
                                                    • 0
                                                      Apple никаких инструментов для работы с МЕ из OSX не предоставляет, а больше и некому. Насколько я успел понять, у Apple есть доступ к исходному коду ME, и потому на их системах прошивка сильно обрезана и не публикует интерфейс HECI, а то и вообще отключается после начальной инициализации, но тестовой машины у меня нет, так что судить не берусь.
                                              • +4
                                                Интересно, что мешает внешнему файрволу реализованному на аналогичном аппаратном обеспечении по-братски пропустить AMT-запрос?
                                                • 0
                                                  Ничего не мешает. Но никто ж не заставляет реализовывать внешний файрвол на аналогичном аппаратном обеспечении. Слава богу, в этом-то деле альтернатив хватает.
                                                  • 0
                                                    А есть ли информация о том, что «дружественные» запросы пропускаются? А если пропускаются, то анализируются ли данные для проверки того, что это реально запрос «друга», а не червя который эксплуатирует запасной вход заложенный самими создателями?
                                                • +1
                                                  А под линукс утилит управления ME/AMT нет?
                                                  • 0
                                                    Насчёт стандартных утилит/драйверов для ОС: у Windows они входят в комплект ПО Intel ME, предоставляемый компанией Intel или распространяемый вендором компьютерой системы. Для Linux точно ответить не смогу, но, проведя аналогию, предполагаю, что они есть в драйверах от Intel.

                                                    Специальных утилит для Linux от Intel для работы с AMT (например, ACUwizard, который я упоминал в статье) я не знаю, но, на крайняк, есть Intel AMT SDK.

                                                    Linux-версий утилит из System Tool Kit (для работы с образами флеш-памяти и с подсистемой Intel ME) нет, но, почти для всех утилит рядом лежат DOS-версии. Замечу, что не имеющие DOS-версий утилиты не используют интерфейс HECI, просто работая с образами прошивок, поэтому их можно запустить на виртуалке.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое