Экспромт хорош тогда, когда хорошо подготовлен

Подразделения 82-й воздушно-десантной дивизии армии США, а точнее Task Force Devil, развёрнутые сейчас на Ближнем Востоке, получили приказ от командования использовать на своих, выданных правительством, защищённых телефонах, приложения Signal и Wickr для внутренней официальной коммуникации.

Речь идёт о зоне боевых действий, где противник может использовать разные средства радиоперехвата для чтения текстовых сообщений, для отслеживания скоплений телефонов — с целью получения информации о режиме дня, сменах дежурств, расписании совещаний и т.п. — резкие изменения в которых являются признаком начинающихся операций.

Мессенджеры Signal и Wickr рекомендованы только для бытовых разговоров, планирования дежурств и совещаний и т.д.; оперативное планирование боевых действий на этих платформах не проводится — уточняет spokesman 82-й воздушно-десантной дивизии, майор Richard Foote.

NSA и DoD отказываются что-либо комментировать на официальный запрос газеты Military Times.

https://www.militarytimes.com/flashpoints/2020/01/23/deployed-82nd-airborne-unit-told-to-use-these-encrypted-messaging-apps-on-government-cellphones/

Обращаю внимание читателей на отсутствие в этом списке WhatsApp, Viber, Skype, Facebook Messenger и Telegram.

С июня 2018 года в браузере Mozilla Firefox существует возможность включить шифрование DNS-запросов, т.е. резолвинг доменных имён по протоколу https (DNS-over-HTTPS, DoH). Для этого нужно задать network.trr.mode=2 в about:config.

Эту фичу уже включили вручную (opt-in) 70 тысяч юзеров, у них всё работает нормально, поэтому в ближайшее время Mozilla планирует включить эту фичу по умолчанию, сначала для пользователей из США, а затем для всего мира, не считая Британии.

DoH-резолвинг доменных имён по умолчанию идёт через CloudFlare, что вызвало критику и оправдания со стороны Mozilla.

Учитывая этот опыт, компания Google, которая тоже планирует внедрить DoH в своём браузере, решила реализовать поддержку нескольких DoH-провайдеров (нужный будет выбираться автоматически, в зависимости от IP-адреса классического DNS-резолвера, который сейчас задан в системных настройках или был получен через DHCP; таким образом, насколько это возможно, DNS-провайдер не изменится, только добавится шифрование). Впрочем, у всех этих компаний privacy policy не лучше, чем у CloudFlare.

Крупным интернет-провайдерам затея с DoH не нравится, т.к. они теряют возможность составлять списки посещаемых пользователями сайтов, и далее продавать эти данные маркетинговым агентствам и другим заинтересованным лицам. Так, например, американский провайдер Comcast недавно активизировал своих лоббистов в Конгрессе с целью противодействия усилиям компаний Mozilla и Google по внедрению в их браузеры функции DoH-клиента.

Владельцы роутеров с прошивкой на основе OpenWRT уже сейчас могут установить прокси-сервер DNS-to-DoH, который будет обрабатывать DNS-запросы на LAN-интерфейсе и делать DoH-запросы через WAN-интерфейс. Таким образом, можно уже сейчас добавить DoH для всех legacy-устройств в локальной сети, выполняющихся на них программ и операционных систем.

В популярный блокировщик рекламы PiHole тоже недавно была добавлена поддержка DoH на бэкэнде. Кстати, чтобы PiHole и ей подобные могли по-прежнему видеть DNS-запросы на фронтэнде, даже после перехода на DoH по умолчанию, в Firefox добавлен workaround: так называемый canary domain "use-application-dns.net", при возврате ответа NXDOMAIN на который происходит отключение браузерного DoH-клиента (хотя Mozilla обещает это убрать, если заметит злоупотребления со стороны интернет-провайдеров). Google Chrome не планирует делать поддержку этого или любого другого canary domain, т.к. PiHole и прочие блокировщики рекламы вредят основному бизнесу корпорации.

А ещё недавно поддержка DoH была добавлена в curl, популярную библиотеку и консольный HTTP-клиент.

Почему победил DoH, а не DoT? Потому что враждебно настроенным провайдерам тривиально просто фильтровать исходящий трафик на 853-й TCP-порт.

Но провайдеры могут так же тривиально просто фильтровать IP-адреса 1.1.1.1 и 1.0.0.1? Могут, но компании CloudFlare технически ничего не мешает включить DoH-резолвер на всех своих IP-адресах.

А как же DNSSEC? Подписи в DNS-ответах прекрасны, но их наличие никак не мешает провайдеру по-прежнему подглядывать за пользователями (вести логи DNS-запросов и DNS-ответов); а когда провайдеру понадобится что-то заспуфить, он может запросто начать блокировать DNSSEC и тем самым форсировать downgrade клиентов на обычный нешифрованный DNS. На принцип Net Neutrality многие провайдеры давно забили, а вот https они уже не смогут, просто так, взять и отключить (слишком поздно, на него приходится 90% трафика), поэтому инкапсуляция DNS-трафика в https — как раз то, что нужно.

Но доменные имена посещаемых сайтов провайдеры по-прежнему могут извлекать из поля SNI, которое передаётся открытым текстом в начале любой https-сессии? Могут, но DPI-оборудование для stateful-анализа https встречается реже и стоит дороже, чем оборудование для простого анализа UDP-трафика на 53-м порту, а стандарт eSNI, предусматривающий шифрование этого поля, уже на подходе. В Firefox'е уже сейчас можно включить экспериментальную поддержку eSNI. Поле eSNI на клиентской стороне шифруется ключами, получаемыми через DNS, поэтому фича eSNI зависит от фичи DoH (во избежание MitM-атак на эти ключи, их подмены путём перехвата DNS на стороне провайдера). В компании Google пока думают: они хотят передавать ключ для eSNI-шифрования не через TXT-запись для поддомена "_esni", а через ESNI-запись (запись нового типа) в апексе, т.е. для всего домена. Из-за разногласий вокруг этих технических деталей между Google и Mozilla/CloudFlare стандартизация eSNI в IETF пока притормозилась, а вместе с ней и реализация поддержки eSNI в SSL-библиотеках и HTTP-серверах. Скорее всего, владельцам доменов первое время нужно будет делать и TXT-запись в _esni-поддомене, и ESNI-запись в апексе.

Как может быть решена "проблема курицы и яйца" для поля eSNI в https-сессиях к DoH-резолверам? ESNI-ключи для DoH-резолверов станут ещё одной квази-константой интернета, так же как IP-адреса DoH-резолверов, IP-адреса корневых DNS-серверов или TLS Trusted Root.

После массового внедрения eSNI и DoH, провайдеры смогут по-прежнему осуществлять фильтрацию сайтов по IP-адресам? Смогут, но со стороны крупных облачных сервисов, таких как CloudFlare, AWS, GCP, Azure и Akamai может последовать ответ в виде domain fronting.

А что, если особо упоротые провайдеры начнут блокировать полные блоки IP-адресов облачных сервисов? Об этом ещё рано думать, но недавно в Нумерационном Совете NRO RIR обсуждалась идея отозвать ранее распределённые номера автономных систем (AS) у крупных российских провайдеров (по причине нарушения связности интернета). Пока эту идею отложили, но в случае таких вопиющих нарушений к ней могут вернуться. Для любого провайдера, отзыв AS-номера влечёт невозможность BGP-маршрутизации, т.е. фактически означает принудительное отключение провайдера и всех его пользователей от всего остального интернета.

Вообще, весь этот движ за privacy заметно активизировался после попытки Казахстана пошалить с TLS Trusted Root. Очевидная цель в краткосрочной перспективе — прикрыть слишком явные дыры в безопасности, которыми пока что активно пользуются различные бантустаны; а долгосрочная цель — поставить бантустаны перед выбором: или вы играете по нашим правилам, или убираетесь вон из нашего интернета к чёртовой бабушке и создаёте свои отдельные недо-интернеты с известными достоинствами, если у вас на это хватит денег и мозгов. Особенно весело будет наблюдать за этими потугами в условиях работающего Starlink.

UPD (2020-09-22): В России планируют запретить DNS over TLS на законодательном уровне.

В винде (всех версий, начиная от XP) нашлась локально эксплуатируемая уязвимость, которая позволяет любому процессу повысить свои привилегии в системе до максимальных ("NT AUTHORITY\SYSTEM"):

https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html
https://bugs.chromium.org/p/project-zero/issues/detail?id=1859
https://news.ycombinator.com/item?id=20685951
https://github.com/taviso/ctftool

Уязвимость связана с IME/CTF (переключение раскладки клавиатуры) и её не так-то просто исправить, потому что это не ошибка кодирования, а ошибка проектирования протокола CTF (который связывает специальный серверный процесс ctfmon.exe с каждым GUI-приложением, куда можно что-нибудь ввести, и следовательно, где можно переключить раскладку клавиатуры). В протоколе CTF предусмотрена передача сообщений, которые содержат такие поля как ProcessId, ThreadId и Hwnd, однако какая-либо валидация этих полей в контексте серверного процесса не произодится (можно ссылаться на чужие процессы, потоки и окна). Также в контексте CTF-сервера есть уязвимости типа вызова функции из таблицы указателей по индексу (без проверки границ), множество удобных гаджетов, а протокол маршаллинга CTF-сообщений спроектирован насколько безнадёжно, что предоставляет способ узнать значение стекового указателя в контексте CTF-сервера (!), чем на корню подрывает виндово-десяточный ASLR.

Эксплуатация уязвимости выглядит довольно внушительно: сначала непривилегированный атакующий процесс своими действиями провоцирует поднятие окна подтверждения UAC; далее встроенный в винду системный процесс consent.exe, выполняющийся от имени встроенной учётной записи "NT AUTHORITY\SYSTEM", рисует то самое UAC-окно; а затем, в обход UIPI, consent.exe просто подвергается атаке через дырки в CTF-протоколе, и в контексте этого процесса происходит выполнение произвольного кода; песенка спета.

Это реально жесть. Microsoft'у теперь такое джва года чинить. Скорее всего, вся IME/CTF-подсистема в винде будет выброшена нахрен и переписана с нуля, с соответствующими последствиями для совместимости.

Недавно в виндовом DHCP-клиенте была обнаружена узвимость CVE-2019-0547 (удалённое исполнение кода, актуально только для Windows 10 1803+). Михаил Цветков из Positive Technologies, пытаясь воспроизвести эту узвимость, случайно наткнулся на новую уязвимость нулевого дня в том же DHCP-клиенте, причём новая уязвимость также относится к классу RCE. Она уже получила отдельный номер CVE-2019-0726.

http://blog.ptsecurity.com/2019/05/dhcp-security-in-windows-10-analyzing.html

Обзор аппаратной ломалки последних айфонов за тридцать килобаксов, для law enforcement и всякой другой гэбни:

https://blog.malwarebytes.com/security-world/2018/03/graykey-iphone-unlocker-poses-serious-security-concerns/

Довольно внушительно, перебирает около миллиона PIN-кодов за 30 секунд.

Хвалёный Apple'овский криптографический сопроцессор / TPM / TrustedZone / доверенный гипервизор / или-как-ещё-называется-то-говно-что-они-там-наворотили оказался, как и предполагалось, пустышкой. Security through obscurity.

Пользуясь случаем, хочу напомнить ещё раз: безопасность полнодискового шифрования проистекает из одновременного выполнения трёх требований: длинный пароль, обширный алфавит, и равномерное распределение символов. Возможно или нет с практической точки зрения соблюсти на телефонах эти три требования одновременно — вопрос открытый.

В течении долгого времени идея микроядерной архитектуры ОС (где в пространстве ядра находится только заглушка для обмена сообщениями, а вся традиционная ядерная функциональность вынесена в отдельные процессы) критиковалась из-за сниженной производительности. Дескать, слишком долго это — тратить время на memcpy() параметров и результатов каждого системного вызова, лучше когда вся ядерная память всегда "под рукой". "Все эти ваши L4, Hurd и Minix страшно далеки от народа, Unix и Windows NT во все поля, дёшево и быстро" — говорили они.

Хотя если много-много запросов загнать в преаллоцированный кольцевой буфер, а потом обслужить их все "одним махом", как это делается в паравиртуальных драйверах virtio, или в netmap, или в RIO API, или в DPDK/SPDK, то можно даже получить выигрыш по производительности (теряем время на копировании, экономим на переключении контекста).

Та же идея относительно "асинхронных системных вызовов" рассматривалась в статье FlexSC: Flexible System Call Scheduling with Exception-Less System Calls авторам которой удалось получить прирост производительности на 116% для MySQL и 40% для Apache. Кстати, очень хорошая статья, на которую следует посмотреть свежим взглядом, учитывая опыт нынешнего "Интелпокалипсиса".

Из-за уязвимостей Meltdown и Spectre, мы одним большим прыжком приблизились к миру операционных систем, где привилегированный системный код выполняется на выделенных ядрах процессора, а пользовательский код — на всех остальных ядрах процессора. А в микроядре остаётся только обмен сообщениями и переключение задач.

Потому что KPTI патчи, сбрасывающие CR3+TLB на каждом системном вызове (всё-таки Линус Торвальдс прав, FUCKWIT или UASS звучит лучше) с их налогом на производительность в 50% — это временная затычка. Потому что retpoline-патчи для clang, способные "отучить" процессор от предсказания ветвлений ценой снижения производительности генерируемого кода в тех же 2 раза — это временная затычка. Потому что готовящиеся сейчас обновления микрокода для всех поддерживаемых процессоров с целью сброса статистики для предсказания ветвлений, который (сброс) должен выполняться при каждом пересечении границы ядро/юзерспейс — это временная затычка.

Intel, AMD, ARM и все остальные не переделают выпущенные за последние 20 лет процессоры и никогда не откажутся от кэшей, опережающего исполнения и предсказания ветвлений. Не может быть так, чтобы следующее поколение Xeon'ов и Epyc'ов работало со скоростью Pentium II. Meltdown и Spectre — это только цветочки, потому что идея творческого совмещения branch prediction poisoning, speculative execution и cache timing attacks прочно завладеет умами security-исследователей на ближайшее десятилетие. А это значит, что единственный выход — это разнести "хороший" и "плохой" код по разным ядрам (cores), чтобы микроархитектурные утечки (состояние кэша, статистика для предсказания ветвлений) между "хорошим" и "плохим" кодом были невозможны.

Микроядерная архитектура операционных систем победила монолитную и монолитную-с-модулями. Уже сейчас ясно, что цена "KPTI + retpoline + бестолково частых сбросов branch prediction статистики через микрокод" превышает цену микроядерного IPC.

Оказывается, в Windows 8.1 и Windows 10 у файлов и папок появился новый аттрибут, который мешает их модификации даже из-под учётной записи SYSTEM. Он предназначен для защиты приложений, установленных из магазина.

Физически этот аттрибут хранится в дескрипторе безопасности. Дескриптор безопасности (SDDL) ещё со времён Windows NT 4.0 традиционно состоит из владельца, группы, DACL и SACL. При этом DACL и SACL традиционно являются списками ACE-записей (Access Control Entry). Но в Windows 8.1 и Windows 10 в SACL появилась новая разновидность ACE-записей:

Type 0x14 (SYSTEM_PROCESS_TRUST_LABEL_ACE_TYPE)
Flags 0x03
Size 0x0018
Payload a9011f00010200000000001300020000
( https://wimlib.net/forums/viewtopic.php?f=1&t=261 )

Традиционный для Windows NT способ замены дескриптора безопасности файлового объекта (получить элевацию до прав локального админа; назначить процессу все привилегии в сфере backup/restore; для всех объектов в иерархии от корневой папки до файла: открыть с FILE_FLAG_BACKUP_SEMANTICS, принять владение объектом, задать объекту новый дескриптор безопасности) не работает: всё равно ACE-запись типа 0x14 остаётся в SACL дескриптора безопасности.

Эта ACE-запись типа 0x14 в SACL не всегда блокирует доступ к объекту, она действует совместно с ACE-записью типа 0x9 (ACCESS_ALLOWED_CALLBACK_ACE_TYPE, "XA") в DACL. Насколько я понимаю, ACE-запись типа 0x14 в SACL иерархически наследуется всеми объектами от корневой папки тома, и снять её можно только форматированием тома; и лишь комбинация ACE-записи типа 0x14 в SACL и ACE-записи типа 0x9 в DACL обеспечивает необходимую защиту.

Вот PowerShell, показывающий дескриптор безопасности за вычетом SACL:



Защита обеспечивается ядром или драйвером файловой системы, поэтому такие файлы нельзя изменить даже из среды Windows PE, хотя можно изменить в предыдущих версиях Windows, которые ещё не знают об ACE-записях типа 0x14 (например, в Windows XP/Vista/7/8) или в Linux/MacOS/FreeBSD (через драйвер ntfs-3g, который игнорирует дескрипторы безопасности).

Оказывается, Intel Management Engine, о котором было в предыдущих сериях, может быть отключён.

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

Эти машинночитаемые XML-файлы схем настроек ME-контроллера примечательны тем, что они упоминают некую опционально включаемую фичу под названием HAP (High Assurance Platform). Достаточно одного запроса в Гугл, чтобы понять, что эта самая аббревиатура HAP как-то связана с программой по созданию высокодоверенной платформы, которую курирует U.S. National Security Agency.

Ребята, которые всё это раскопали, первым делом с помощью SPI-программатора для флеш-памяти (напомню, у основного процессора и ME-контроллера общая флеш-память) установили соответствующий бит, чтобы посмотреть, что из этого будет. После загрузки платформы, интеловская утилита MEInfo начала показывать странный статус "контроллер ME был отключён альтернативным способом", а дальнейшая проверка показала, что устройство перестало отвечать на команды и запросы операционной системы. При этом платформа стартует нормально и нормально работает (то есть не перезагружается по watchdog-таймеру спустя 30 минут, как при "грубом" отключении Intel ME путём удаления его разделов из флеш-памяти).

http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

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

UPD (2017-10-11): Гентушники написали пошаговое руководство по полному выковыриванию Intel ME из прошивки материнской платы: https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Disabling_the_Intel_Management_Engine

Игру Dishonored 2 таки взломали, красавчики :)

Защищена с помощью Denuvo, выпущена ещё в ноябре прошлого года, Game of the Year в нескольких номинациях, один из лидеров продаж в Steam, дорогая ($60), до сих пор взломать никому не удавалось. Как и многие другие игры последних лет, защищённые с помощью Denuvo, это был крепкий орешек, ведь в основе технологии защиты Denuvo лежит VMProtect.

Однако новая группа под названием SteamPunks (да-да, это дебютный их релиз на крэкерской сцене) всех сделала с особым цинизмом — выпустила не просто патч или лоадер, а целый генератор ключей. :D Никогда не думал, что Dishonored 2 взломают таким способом — скорее, были предположения, что кто-то выпустит хитрый лоадер режима ядра, который захватывает хост в гипервизор и виртуализирует инструкцию CPUID вместе с перехватом доступа к серийному номеру жёсткого диска и MAC-адресу сетевой карты, которые дают вклад в HWID. Ну а далее все будут сидеть на едином ключе, как в старые добрые времена Windows 98 :)

Но кейген? "SteamPunks absolutely delivered" — пишут англоязычные сайты, и они чертовски правы. Неужто Стимпанки подобрали приватную часть мастер-ключа? Наверное, это как-то связано с дефектами генератора псевдослучайных чисел, которым был сгенерирован мастер-ключ. Мало энтропии в засевочном числе или что-то подобное. Более 15 назад похожая история была с ASProtect (см. стр 89/83 этой книги).

Бывает ещё такой случай, когда крэк основан на связке патча и кейгена. Это когда программа использует асимметричную криптографию для проверки лицензий, но её авторы не потрудились обеспечить защиту от пропатчивания публичного ключа. Соответственно самым простым решением для крэкеров является выпуск новой пары ключей и замена публичного ключа в программе патчем для EXEшника, а на основе приватного — изготовление кейгена. Явно не наш случай, защита от наглого пропатчивания публичного ключа есть. Хотя бывают вариации этого подхода, когда вместо патча применяется лоадер с WriteProcessMemory; или код для динамического пропатчивания публичного ключа в секции данных EXEшника внедряется в какую-то второстепенную DLLку в комплекте с игрой.

Во всём этом невозможно так сходу разобраться, потому что к радости разработчиков Dishonored 2 и крэкеров из конкурирующих групп, кейген защищён от реверс-инжиниринга. VMProtect'ом, разумеется. Чем же ещё. LOL.

На днях в прошивке Intel Management Engine нашёлся баг, который позволяет обойти аутентификацию в их корпоративных решениях для удалённого управления серверами и рабочими станциями. Короче говоря, можно удалённо рулить сервером или ноутбуком без предоставления пароля/ключа, если в публичный интернет открыты TCP-порты 16992/16993.

• Security Advisory от Intel
• инсайдерский слив днём раньше
• статья на ArsTechica

Intel ME известен корпоративным пользователям под большим набором маркетинговых имён (AMT, ISM, SBT, IPMI, vPro) и представляет собой выделенный 32-битный сопроцессор, позволяющий, к примеру, удалённо войти в BIOS или удалённо пробросить ISO-образ с последующей переустановкой операционной системы. С аппаратной точки зрения, Intel ME является посредником между сетевым интерфейсом и процессором, и к тому же имеет прямой доступ ко всей оперативной памяти системы: https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

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

1) Intel ME присутствует даже в чипсетах сугубо клиентских материнских плат и ноутбуков, и даже там он постоянно включён, и отключить его никак нельзя (в системе с неактивным Intel ME сработает watchdog timer чипсета через 30 минут после загрузки, или около того). Plausible deniability от Intel сводится к технологии Intel Anti-Theft, и к управлению вентиляторами. Conspiracy theory сводится к тому, что даже на клиентских системах есть пароли и AES-ключи, которые можно собирать из оперативной памяти. Или от процессора, который выполняет AES-NI инструкции, и, в принципе, знает ключи.

2) Встроенное программное обеспечение для Intel ME хранится в флеш-памяти в сжатом и зашифрованном виде, а выделенный для Intel ME регион в ОЗУ — прозрачно шифруется самим сопроцессором (хотя и программно недоступен для центрального процессора), так что даже охлаждение планок памяти жидким азотом и чтение на другой системе не позволит заглянуть внутрь. Plausible deniability от Intel сводится к наличию DRM-технологий (Protected Audio/Video Path) на этой платформе, а также к тому, что она может быть содержать программную реализацию TPM (Trusted Platform Module). Conspiracy theory сводится к тому, что код, собирающий всякие интересные артефакты из ОЗУ, должен быть защищён от любопытных глаз исследователей.

3) Intel ME имеет доступ к фреймбуферу (видит и может менять то, что отображается пользователю на экране). Для этой функции ему порой нужна поддержка со стороны ОС (если видеокарта не встроенная, а дискретная). Plausible deniability от Intel: Active Management Technology (удалённое управление), а также Protected Transaction Display (ввод PIN-кода для интернет-банка мышиными кликами по рандомизированной экранной PIN-клавиатуре, так чтобы хостовый CPU и вирусы, выполняющиеся на нём, не знали цифр, которые отображаются на экране). Также нужно для DRM (показывать дешифрованное видео прямо на экран, в обход CPU). Conspiracy theory: подглядывание за пользователем.

4) Intel ME и сетевой контроллер остаются включёнными даже тогда, когда основной процессор выключен (режим питания soft-off). Plausible deniability от Intel сводится к технологии Wake-on-LAN. Conspiracy theory сводится к тому, что пока компьютер "как бы выключен", этот сопроцессор может спокойно передавать "куда следует" секретики, собранные за день.

5) Intel ME включается в разрыв между сетевым контроллером и процессором. Plausible deniability от Intel сводится к технологии System Defense (низкоуровневой неотключаемый файерволл для дебилов, которые снесут или отключат файерволл в ОС и нахватаются вирусов), а также всё к тому же AMT и vPro. Также существует технология Intel EEE (Energy Efficient Ethernet), которая позволяет, например, открыть слушающий TCP сокет и отправить CPU спать до появления первого клиентского подключения. Conspiracy theory сводится к тому, что таким способом собранные данные можно сливать не "в наглую" (например, передавая трафик на неизвестный IP-адрес, который кто-то запишет wireshark'ом или tcpdump'ом и устроит скандал) а похитрее (например, в виде колебаний задержек при отправке исходящих пакетов, которые можно измерить на оборудовании вашего интернет-провайдера). При этом, можно предположить, что колебания задержек входящих пакетов на исходящих TCP-сессиях могут быть использованы для встречной передачи команд контроллеру Intel ME.

Подытожим:

1) Я не до такой степени параноик, чтобы менять встроенную прошивку на coreboot, рискуя превратить материнскую плату в бесполезный кусок текстолита; к тому же я не уверен, что это как-то поможет. Однако я не пользуюсь встроенными сетевыми контроллерами от Intel с 2015 года, чего и вам советую. Выбирайте дискретную сетевую карту поэкзотичнее, прошивка Intel ME — это примерно 2 мегабайта, а ведь там ещё должен поместиться весь этот SSL, VNC-сервер, DRM, файерволл и предполагаемый шпионский хлам (а также урезанная версия Java). Да и попытка пообщаться с сетевой картой требует перепрограммирования регистров её контроллера и контроллера DMA, что не останется незамеченным для CPU. Ну разве когда CPU в режиме soft-off, но тогда и сетевая карта в soft-off.

2) Сам факт нахождения первых уязвимостей в Intel ME позволяет предположить, что кто-то всерьёз заинтересовался этим вопросом, возможно расшифровал прошивку Intel ME. Способы есть. Вполне естественно, что люди интересуются, ведь если кто-то заложил в платформу такие вкусняшки — не пропадать же им втуне. Да и в конечном итоге неважно, написан ли соответствующий софт или нет; важно лишь, что железо позволяет.

Обсуждение на Hacker News:
https://news.ycombinator.com/item?id=14241241

Update от 2017-08-29: существует способ отключить Intel ME:
https://waqur.dreamwidth.org/130735.html