То, о чем так долго говорили Тем, кто хорошо знает, что умеет ME, уже страшно. Оно может читать и писать в любую область оперативной памяти и накопителей, подсматривать за происходящем на экране, посылать и получать из сети всякое, игнорируя работающий в системе файрволл, и все это, не оставляя в логах никаких следов. По слухам, даже шифрование диска ME обходит без напряга. Нечеловечески полезная штука.
Ежу понятно, что встраивая в материнки легитимный аппаратный бэкдор, надо по-максимуму закрутить гайки в системе безопасности, что Intel и сделала. Код iME, например, зашифрован 2048-битным ключом. Но как обычно, что-то пошло не так, и теперь прогрессивная общественность доподлинно узнала о возможности удаленно захватывать доступ к функциям управления ME. Под угрозой машины, в которых реализованы технологии AMT, ISM и SBT. Ну то есть вообще все на интеловских чипсетах под Intel Core.
Правда, Intel в своем оповещении указывает, что уязвимости нет на обычных консьюмерских системах, и оно вроде бы похоже на правду – там как бы нет AMT, ISM и SBT. Но мы же понимаем, что консьюмерский продукт по большому счету отличается от корпоративного настроечками в прошивке. Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.
Люди в теме тут же начали вспоминать, что кое-кто намекал на наличие дыр в ME еще в прошлом году. Дамьен Заммит ругался на то, что безопасность ME основана на закрытости кода, что для рукастых аналитиков не является неразрешимой проблемой. А Чарли Демерьян из SemiAccurate вообще заявил, что исследователи давно уже тыкали этими уязвимостями в Intel. Прослышав об этом, Threatpost задал Intel закономерный вопрос – что, мол, это было, – но Уильям Мосс из Intel ни в чем не сознался. По его словам, компания узнала обо всем лишь в марте, и вот уже в мае готов патч. Чего ж еще вы хотите от Intel, неблагодарные?!Патч – дело хорошее. Но мы же понимаем, что кроме плат производства самой Intel, есть еще огромное множество плат других производителей на их чипсетах. За них Intel не отвечает – скинули им патч и забыли. А вот закроют ли дыру в своих прошивках эти самые сторонние производители, и когда, это вопрос. Пока же предлагается отключить технологии удаленного управления в CMOS Setup и снести из системы соответствующие утилиты Intel. Ну ок.
Apple отозвала сертификат у троянца для OS X
Новость. На прошлой неделе Check Point поймала нового интересного троянца для Маков – OSX/Dok. Он занимается прослушкой траффика и умеет полностью контролировать все коммуникации на зараженной машине, включая шифрованные каналы. Делается это незамысловато – браузеру подсовывается прокси, контролируемый злоумышленниками, и весь траффик идет через него. Предварительно троянец устанавливает в системе свой корневой сертификат, так что браузер верит сертификату прокси-сервера, и определить, что HTTPS-траффик перехватывается, становится затруднительно.
Распространяется OSX/Dok посредством фишинга, жертвам приходят письма с zip-файлом, который на самом деле исполняемый файл. Если наивный пользователь Мака кликнет по файлу, троянец копируется в /User/Shared и показывает сообщение, что архив поврежден, отстаньте. Потом находит в загрузочном меню AppStore и встает на его место. После перезагрузки системы показывает окно с оповещением об обновлении системы и требует пароль. Пока жертва пароль не введет – ничего сделать на компьютере не сможет. А когда введет, Док получает права администратора.Творить все это безобразие, и оставаться необнаруженным, троянцу позволяет легитимная цифровая подпись разработчика Apple, то ли украденная, то ли полученная специально для темных дел. С точки зрения средств безопасности, он был настоящим честным троянцем, Apple approved. Ну, теперь-то Apple отозвала сертификат и, Док больше не сможет нас обманывать.
Большая часть зловредов – троянцы-вымогатели
Новость. Исследование. Verizon Enterpise ежегодно выпускает исследование по различным киберинцидентам, которые компания расследует за год. В прошлом году им пришлось иметь дело с 40 тысячами инцидентов, из которых 1935 – различные взломы. Выводы весьма тревожат: атаки рансомварью разного вида выросли на 50%, солидный вклад внесли Петя с Мишей.
Кибервымогатели стали работать тоньше. Если раньше типичный криптолокер с грацией 1-й конармии вламывался на машину и шифровал все, что шифруется (и чаще всего был посылаем подальше, так как на машине ничего ценного не было), то теперь он сидит тихо и ищет действительно важные данные. Для этого они освоили бесфайловые техники атаки, и даже вспомнили старые добрые макросы для MSWord.
Основной проблемой безопасности Verizon считает недостаточно распространение двухфакторной аутентификации. В большинстве случаев хакерам достаточно брутфорса и фишинга, чтобы сделать с жертвой все, что они захотят.
Древности
«Tequila»
Резидентный неопасный «стелс»-«призрак»-вирус. Стандартно поражает EXE-файлы при их запуске и MBR винчестера при запуске зараженного файла. Первоначальный MBR-сектор и свое продолжение сохраняет в последних секторах логического диска C:, уменьшая в Partition Table его (диска) размер.
Оперативную память инфицирует только при загрузке с зараженной MBR. Перехватывает int 13h, 1Ch, 21h. В зависимости от своих внутренних счетчиков выводит на экран разноцветную картинку, напоминающую летящий самолет, и фразу: «Execute: mov ax, FE03 / int 21. Key to go on!» если выполнить рекомендуемое действие, то на экране появится текст:
Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 107.
Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Комментарии (65)
dartraiden
05.05.2017 20:24+3
powerman
06.05.2017 04:29Там есть ссылка на тулзу intelmetool, которая должна показать текущее состояние ME. Я попробовал у себя запустить, но ничего не вышло:
kern.alert: grsec: denied use of iopl() by /home/powerman/tmp/coreboot/util/intelmetool/intelmetool[intelmetool:12327] uid/euid:0/0 gid/egid:0/0, parent /bin/zsh[zsh:12020] uid/euid:0/0 gid/egid:0/0
Надо полагать, наличие Grsecurity в ядре помешает не только этой тулзе, но и попыткам эксплуатировать ME…?
KonstantinSpb
06.05.2017 13:27+1Нет, grsecurity не помешает эксплуатировать ME, т.к. ME — это уровень Ring -3, а grsec — Ring 0
МЕ работает на самом низком уровне, и на защиту грсека ему накласть.powerman
06.05.2017 14:49Безусловно, но ведь до ME сначала надо как-то добраться. И вот добраться до ME grsec помешал.
KonstantinSpb
06.05.2017 15:02+2grsec помешал добраться утилите intelmetool до IO портов. Но до уязвимости в AMT можно добраться напрямик, минуя любую ОС, т.к. у AMT своя ОС и уязвимость именно там и работает она по сети в режиме OOB(out of band), т.е. в операционке вы даже этих сетевых пакетов не увидите. Почитайте про АМТ, а также про IPMI и BMC, чтобы понимать, что тут даже операционка не нужна, и комп может быть выключен (питание подключено).
powerman
06.05.2017 16:16-1Вопросы в комментах на хабре задаются как раз тогда, когда времени и/или желания читать первоисточники нет. Я достаточно сильно интересуюсь безопасностью, но всё же не в такой степени, чтобы разбираться в таких вопросах профессионально — у меня и своя работа есть. Так что в данном случае я интересуюсь как обычный обеспокоенный пользователь этих продуктов: каким конкретно образом происходит доступ к ME на моей системе?
Доступ через I/O порты, похоже, заблокирован Grsecurity.
Прямой доступ через физическую память тоже заблокирован Grsecurity (/dev/mem).
Запись в /dev/cpu/*/msr тоже заблокирована Grsecurity.
Остаётся доступ через сеть, когда IPMI/BMC читают и перехватывают пакеты на уровне сетевой карты ещё до того, как их увидит OS (если OS вообще запущена в этот момент).
Есть ещё какие-то варианты помимо вышеупомянутых?
Что касается варианта с доступом через сетевые пакеты — насколько я понимаю, в десктопных материнках, в которых нет IPMI/BMC, это работать не должно (WakeOnLan я обычно в BIOS отключаю, не знаю, имеет ли это отношение к данной ситуации).
Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.
Вот, собственно, то, что мне интересно: работает ли вышеупомянутый "локальный" способ эксплуатации при наличии Grsecurity, и если работает — то через что. Раз возможности удалённо эксплуатировать вроде бы нет, то не похоже, чтобы отправка/инжектирование специально сформированного сетевого пакета давала доступ к ME. А все остальные локальные способы вроде бы заблокированы Grsecurity.
KonstantinSpb
06.05.2017 16:28+2Если у чипсета вашей материнки нету AMT, то я бы не переживал, но на всякие случай очистил бы МЕ по максимуму mecleaner-ом
equand
06.05.2017 19:31AMT это на уровне чипсета. ОС о них знает мелочь, контроля она не имеет.
powerman
06.05.2017 20:13-1Безусловно. Тем не менее, чтобы обычное приложение из юзер-спейса как-то достучалось до AMT, эксплуатировало уязвимость и в результате этого ускользнуло из под контроля OS, ему нужно сначала сделать что-то (напр. писать в I/O порты). В этот момент приложение ещё находится под контролем OS, и ему, теоретически, можно помешать — смотря каким образом реализовано взаимодействие с AMT (о чём я и спрашивал, собственно).
В случае удалённой эксплуатации помешать невозможно, потому что пришедший по сети пакет будет сначала обработан AMT, до того как его сможет увидеть OS. А вот в случае локальной эксплуатации, судя по всему, доступ к AMT реализуется через I/O порты, доступ к которым для приложений в юзер-спейсе полностью контролируется OS, так что тот же Grsecurity вполне в состоянии защитить систему.
equand
07.05.2017 15:17Обычному приложению к Вам на ПК попасть не надо. Этот взлом происходит удаленно, без доступа к ring0+ ВООБЩЕ.
Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).
Учитывая говнокачество Intel RMM и ME я не удивлен этой дырой, вопрос был как быстро ее найдут. Все IPMI уязвимы ибо пишут их бангладешские говнокодеры, качество когда просто ужасно, если их смотреть. Хуже чем домашние рутеры. Тот же Supermicro посмотрите — это пиздец.
willyd
07.05.2017 15:54+1Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).
А можно поподробней или ссылку на документацию? Просто я склоняюсь к мнению powerman, что удаленная эксплуатация подразумевает настроенный и открытый доступ по сети, не важно локальной или глобальной, а локально — использование интерфейса в ОС.
willyd
07.05.2017 16:16Вот что я нашел в документации HP.
http://h10032.www1.hp.com/ctg/Manual/c03975296 или http://h10032.www1.hp.com/ctg/Manual/c02958196.pdf
From the Intel AMT Configuration menu (shown in Figure 5), select Manageability Feature Selection.
This option allows Intel AMT to be enabled (recommended) or disabled. By default, HP systems are set to enable Intel
AMT.
Note that disabling Manageability Feature Selection also disables all remote management capabilities and unprovisions
any Intel AMT settings.
То есть по умолчанию AMT активирован, что дает возможность удаленной эксплуатации. Но если его отключить, то исходя из описания уязвимости — все равно возможна локальная эксплуатация.equand
07.05.2017 17:58Прочтите сам PoC:
https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf
Грубо говоря коннект к HTTP самого AMT.
AMT включен по умолчанию везде в системах с ним.
Локально взлом возможен через DHCP коннект к компьютеру: то есть локально поднять дхцп демона и по выданному ип зайти без пароля в AMT.
В принципе методов взлома тонна т.к. доступен HTTP
willyd
07.05.2017 20:41Спасибо, читал.
Почитайте бюллетень, в котором указано, чтоAn unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs: Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology (SBT).
Исходя из терминологи, «provisioned system» — система с включенным AMT, «unprovisioned system» — с выключенным.
Если он выключен — то как он подхватит адрес по DHCP?
И по вашей же логике — я должен его всегда видеть в DHCP-клиентах на роутере. Но я этого не вижу.
Или для него нужны какие-то специфическиt опции в DHCP?
Все что вы описываете — это удаленная атака, так как она проводиться через сеть. Чем отличается локальный DHCP от DHCP в сети?equand
07.05.2017 21:03Ок, АМТ не может быть "выключенным" в принципе, насколько я понял.
Он всегда включен, однако порт можно отключить, если ПОЛНОСТЬЮ сбросить все в ноль.
A full unprovisioning returns Intel AMT to its factory default state.
Unprovisioned система значит настройки АМТ не введены и пароль дефолтный для системы.
Полный сброс производится через Factory reset AMT и это приводит к доступности по DHCP only или же через меню Ctrl+P или какое вендор даст.
Старые и новые AMT имеют разницу, поэтому от этого зависит.
willyd
07.05.2017 21:35Приводил документацию выше
Note that disabling Manageability Feature Selection also disables all remote management capabilities and unprovisions
any Intel AMT settings.
То есть, вроде как можно отключить и unprovision эквивалентно disable.
https://software.intel.com/en-us/forums/intel-business-client-software-development/topic/297931
(in fact, most systems will not even show the MEBx prompt if Intel AMT is disabled at the BIOS
Я не смог попасть в MEBx. Хотя биос был сброшен по дефолту и ATM настройки я не трогал. Я не вижу левых девайсов на DHCP.
Но вижу два девайса HECI:
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04) Subsystem: Hewlett-Packard Company Device 198f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 50 Region 0: Memory at d0739000 (64-bit, non-prefetchable) [size=32] Capabilities: <access denied> Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04) (prog-if 02 [16550]) Subsystem: Hewlett-Packard Company Device 198f Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin D routed to IRQ 19 Region 0: I/O ports at 30b0 [size=8] Region 1: Memory at d073f000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: serial
Насколько я понимаю, при возможности доступа к HECI девайсам, возможно получить доступ к AMT и ME, скорее всего используя ту же уязвимость (пустой пароль)equand
08.05.2017 12:51Собственно
Полный сброс производится через Factory reset AMT и это приводит к доступности по DHCP only или же через меню Ctrl+P или какое вендор даст.
Как я и написал.
Некоторые вендоры сбрасывают в DHCP, некоторые только в доступность через CTRL+P Некоторые вообще отключают. Зависит от вендора и версии AMT.
lostmsu
05.05.2017 20:43+1Правда, Intel в своем оповещении указывает, что уязвимости нет на обычных консьюмерских системах, и оно вроде бы похоже на правду – там как бы нет AMT, ISM и SBT. Но мы же понимаем, что консьюмерский продукт по большому счету отличается от корпоративного настроечками в прошивке. Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.
Для вот этого утверждения можете указать источник?
Kaspersky_Lab
06.05.2017 10:11Демерьян писал: https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
powerman
06.05.2017 20:44-1Тон там немного истеричный (хоть и не без причины), но в целом очень интересно было почитать, спасибо. Насчёт "любая система выпущенная за последние 10 лет" — у меня (десктопная) материнка 5-ти летней давности на Intel® Z68 Express Chipset, и судя по спеке интела там ME нет вообще.
В следующей статье разбирается как раз этот вопрос — если в спеке интела сказано что ME/AMT нет, то нет ли его на самом деле, или физически в железе он всё-таки есть, просто не активен. Я, конечно, не стал бы исключать такой вариант, но по-моему эта проблема несколько раздута. Возможность удалённо эксплуатировать громадное количество систем отправив им сетевой пакет, вне зависимости от OS этих систем и даже того, включены ли они — это одно. Теоретическая (на данный момент) возможность взломать текущую OS конкретной системы с целью прошить заточенную под материнку конкретно этой системы нестандартную прошивку, которая активирует "как бы отсутствующий" в железе AMT, с целью его эксплуатировать — это уже перебор, господа! Я уже молчу о том, что такой подход будет "применим" всегда и к любой системе — кто помешает после обновления/удаления ME использовать этот подход чтобы сначала вернуть старую уязвимую прошивку а потом захватить AMT?
В общем, проблема была бы понятнее и нагляднее, если бы вокруг неё было меньше восторженной истерии.
flothrone
06.05.2017 21:36+4ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше. Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен. Другое дело, что этот чипсет не имеет оф. поддержки Intel vPro (Intel AMT), а значит эта технология (AMT) скорее всего выключена, и уязвимость (о которой идёт речь) удалённо проэксплуатировать не выйдет.
powerman
06.05.2017 23:13-1ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше.
Даже SemiAccurate не утверждает этого наверняка. Вы более информированы на этот счёт? Есть пруфы или данное утверждение базируется на глубокой внутренней уверенности?
Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен.
Не совсем понял, как может быть "активен" ME, если судя по официальной спеке Intel ME отсутствует на этом чипсете и даже по Вашим словам AMT выключена. Как можно проверить, что ME есть и даже активен?
Taciturn
06.05.2017 23:20+1Драйвер «Intel® Management Engine Interface» для какого-то устройства ведь ставится. А если есть «Interface», то логично предположить что и «Management Engine» существует.
powerman
06.05.2017 23:42-1Я не знаю, что на материнки с этим чипсетом ставится под винду, у меня линух и таких драйверов нет. Но даже если он ставится — не факт, что он реально работает, а не отвечает "no such device" на любые запросы.
Taciturn
06.05.2017 23:49+1ID следующие: VEN_8086&DEV_1E3A, VEN_8086&DEV_1CBA, VEN_8086&DEV_1C3A, VEN_8086&DEV_1DBA — посмотрите вывод lspci, скорее всего что-то из списка у вас будет. Если никакого устройства нет, то зачем в принципе делать какой-то интерфейс?
powerman
07.05.2017 00:11-1Действительно, в ядре есть драйвер "Intel Management Engine Interface" и созданное им устройство
/dev/mei0.
Устройств с указанными ID я не вижу, но есть вот это:
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: Gigabyte Technology Co., Ltd 6 Series/C200 Series Chipset Family MEI Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 25 Region 0: Memory at f6607000 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 41c1 Kernel driver in use: mei_me
Упомянутая flothrone тулза MEInfo есть только под винду. Но я нашёл /usr/src/linux/Documentation/misc-devices/mei/mei-amt-version.c — теоретически она должна сказать активен ли AMT и показать его версию. Практически же она во-первых пытается работать с /dev/mei вместо /dev/mei0 (но это я поправил) и во-вторых выдаёт ошибку при попытке вызвать первый же ioctl после открытия /dev/mei0:
# ./mei-amt-version Error: IOCTL_MEI_CONNECT_CLIENT receive message. err=-1
В общем, странно всё это. Что-то вроде формально есть, но работать — не работает.
flothrone
07.05.2017 15:49MEinfo есть под DOS.
И вам нужна правильная версия: т.к. чипсет Z68, то ME firmware у вас должно быть версии 7.x, следовательно, использовать нужно MEinfo из комплекта 7-й версии.powerman
07.05.2017 16:06-4И чем мне это поможет? Ставить ради этого dosbox, который всё-равно не получит доступ к портам из-за grsecurity?
flothrone
06.05.2017 23:54+1Насчёт интегрированности ME во все чипсеты начиная с 2010 года — вообще это давно известный факт, скачайте прошивку к своей материнской плате и проверьте наличие ME региона в ней (который содержит прошивку Intel ME). Надеюсь вам этого будет достаточно.
Чтобы убедиться в том, что ваш Intel ME живет и функционирует нормально, юзайте утилиту MEinfo.
flothrone
06.05.2017 23:58+1И, мне сдаётся, вы путаете понятия Intel ME и Intel AMT. Первое — подсистема, основным компонентом которой является микроконтроллер, интегированный в наши чипсеты. Это подсистема являетя программно-аппаратной поддержкой для технологий компании Intel, в т.ч. Intel AMT, которая имплементирована в виде нескольких кодовых модулей, входящих в состав прошивки Intel ME. Другими словами, Intel ME — движок, основа. Intel AMT — лишь часть прошивки Intel ME.
flothrone
07.05.2017 00:05если судя по официальной спеке Intel ME отсутствует на этом чипсете
И что за спецификацию на чипсет вы там читаете, если в даташите на этот чипсет есть описание регистров MEI (Management Engine Interface) в конфигурационном пространстве PCI?powerman
07.05.2017 00:15Я там выше приводил ссылку на описание чипсета, и там сказано:
Intel® vPro™ Technology: No
Intel® ME Firmware Version: Noflothrone
07.05.2017 01:39+1Intel® ME Firmware Version: No
Это неточность. В моём распоряжении есть мат. плата на чипсете Intel H67, для которого тоже сказано, что ME firmware version: no, однако MEinfo говорит об обратном.
Данное поле, кстати, отсутствут в описаниях на ark.intel для чипсетов 7 серии и далее.
Taciturn
05.05.2017 20:57и вот уже в мае готов патч
А где его взять то? Вот у меня плата Intel DQ87PG — на странице загрузки из нового за последние полтора года только сообщение об окончании поддержки. Поиск по номеру прошивки выдаёт только длинные списки уязвимых продуктов и ссылки на PDF Intel рассказывающий как отключить AMT и службы в Windows.
navion
05.05.2017 23:50+1Скорее всего Intel выпустили пропатченный региона ME, который должны включить в прошивки производители плат. Но лучше дождаться подробного разбора от flothrone или CodeRush, а не перепечатки новостей.
Taciturn
05.05.2017 23:58HP, к примеру, не заморачивается никаким включением и просто выкладывает оригинальные файлы прошивок прямо от Intel, отдельно прикладывая Intel'овкские же утилиты для прошивки — разве что упаковывая это всё SFX-архивы. Но подозреваю что для старых продуктов они даже выкладыванием файлов заниматься не будет — выложили инструкцию по отключению части функционала и хватит.
flothrone
06.05.2017 02:12+2Технические подробности найденной в коде Intel AMT уязвимости (CVE-2017-5689) уже опубликованы.
CodeRush
06.05.2017 03:50+11Уязвимость настолько простая и глупая, что ее полный разбор влезает в половину твита:
VioletGiraffe
07.05.2017 09:53А можно теперь сначала и поподробнее? Это строка кода, в которой находится уязвимость? Что не так с этим strncmp?
В комментариях к твиту тоже нет пояснения. А вообще — да, пора уже бросать древный опасный неудобный С и писать всё на С++. Банальный std::string избавляет от необходимости держать в голове кучу фигни, и едва ли добавляет оверхед.to_climb
07.05.2017 10:32Если длина user_input равна 0 (пустая строка), то strncmp вернёт 0 (равенство строк)… красота.
А если очень длинная, то и AV схлопотать можно (теоретически).
dmitry_ch
06.05.2017 11:38+4Тут бы AMD подсуетиться и предложить всем участвовать в компании «живи с чистой материнкой!»
dmitry_ch
06.05.2017 15:13-1Во-первых, я и не писал, что им можно верить, я писал, что им бы подсуетиться с рекламой.
Во-вторых, там же написано — TrustZone, т.е. верить, они считают, можно. Нехорошо не доверять AMD, она не столько раз клиентов оставляла неудовлетворенными, чтобы в этот раз отвергнуть её. Шутка.
Ну а в третьих, несмотря на «волшебные» свойства ME, я бы поостерегся верить слухам: например, лично мне фраза «По слухам, даже шифрование диска ME обходит без напряга» кажется немного желтоватой. Хотя бы тем, что при шифровании данных на диске средствами ОС (драйвером работы с диском) прямой железный (т.е. мимо ОС) доступ к диску будет бесполезен, он даст только кучку защифрованных данных. Если же ME умеет ходить на диск через драйвера ОС, то не такая ME и неподконтрольная становится, в т.ч. и для проверки ее действий со стороны антивируса. А уж если данные на диске зашифрованы на уровне контроллера диска самим диском, то какая польза от ME?
В общем, доверяй, но проверяй. Тем более это читаем в блоге Касперского, которому кипишь на рынке безопасности, в общем-то, на руку (никаких обвинений, просто подумалось).KonstantinSpb
06.05.2017 16:14+3Ну шифрование она может обойти, если прочитает ключ из памяти, сохранит его где-нить в nvram-е и потом если будет проводиться расследование, то данные будут легко расшифрованы.
mayorovp
06.05.2017 17:28Вот как раз когда данные зашифрованы контроллером диска — для ME видим поток незашифрованных данных.
qw1
06.05.2017 15:45и снести из системы соответствующие утилиты Intel
Интересно, какие это утилиты?
Я недавно заинтересовался классифицировать все запускаемые на компьютере процессы и внезапно обнаружил, что у NVIDIA и Intel есть своя телеметрия (в частности, от Intel непонятно как в планировщик задач прописался «C:\Program Files (x86)\Intel\Telemetry 2.0\lrio.exe»)Dageron
06.05.2017 16:00+8Любопытно заметить, что весьма эпичный реверс всей телеметрии с Windows и Windows-приложений проделали сотрудники компании Yota. Можно ставить забавный эксперимент: запускать смартфонный тариф в модеме и отключать службы и процессы до тех пор, пока не начнет наконец выскакивать синее окно жадности «вы используете тариф не там где нужно».
Среди прочего, NVIDIA телеметрия мне тоже попадалась. Еще, как ни странно, у более-менее новых видеокарт одновременно с драйверами ставятся приложения, которые как бы между делом шлют тонны статистики на сервера.
Taciturn
06.05.2017 22:58+1В официальном PDF предлагают удалять
Intel® Management and Security Application Local Management Service (LMS)
, запуском «sc delete LMS».
Arqwer
07.05.2017 10:29-1Слышал про то, как Джоанна Рутковска эксплуатировала какую-то аппаратную уязвимость, так там был такой прикол, что злоумышленнику в любом случае оставалась возможность выполнить сброс к заводским установкам — то есть даже если на уязвимое железо установить обновление, закрывающее уязвимость, то злоумышленник мог вызвать откат к заводской версии прошивки, и всё равно использовать уязвимость!
Поэтому вполне вероятно, что и здесь просто установкой обновлений не отделаешься.
swmicro
09.05.2017 10:03в микропрограмме Intel Management Engine обнаружилась уязвимость.
Уязвимость не в ME, а в AMT.
AlexandrDP
И похоже «дыры» сработали.
«Совпадение? Не думаю» (с) цифра…