Security Week 18: Дыра во всех системах с Intel Core, Apple отобрала сертификат у троянца, рансомварь заполонила планету

    То, о чем так долго говорили большевики безопасники, свершилось. Свершилось почти десять лет назад, а сейчас об этом стало широко известно: в микропрограмме Intel Management Engine обнаружилась уязвимость. В оповещении от Intel указаны версии от 6.0 до 11.6, а, это, на минуточку, все версии, начиная с 2008 года, с платформ для процессоров Intel Core первого поколения.

    Тем, кто хорошо знает, что умеет 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: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
    «Лаборатория Касперского»
    Ловим вирусы, исследуем угрозы, спасаем мир

    Comments 65

      0
      И похоже «дыры» сработали.
      «Совпадение? Не думаю» (с) цифра…
          0

          Там есть ссылка на тулзу 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…?

            +1
            Нет, grsecurity не помешает эксплуатировать ME, т.к. ME — это уровень Ring -3, а grsec — Ring 0
            МЕ работает на самом низком уровне, и на защиту грсека ему накласть.
              0

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

                +2
                grsec помешал добраться утилите intelmetool до IO портов. Но до уязвимости в AMT можно добраться напрямик, минуя любую ОС, т.к. у AMT своя ОС и уязвимость именно там и работает она по сети в режиме OOB(out of band), т.е. в операционке вы даже этих сетевых пакетов не увидите. Почитайте про АМТ, а также про IPMI и BMC, чтобы понимать, что тут даже операционка не нужна, и комп может быть выключен (питание подключено).
                  –1

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


                  Доступ через I/O порты, похоже, заблокирован Grsecurity.
                  Прямой доступ через физическую память тоже заблокирован Grsecurity (/dev/mem).
                  Запись в /dev/cpu/*/msr тоже заблокирована Grsecurity.
                  Остаётся доступ через сеть, когда IPMI/BMC читают и перехватывают пакеты на уровне сетевой карты ещё до того, как их увидит OS (если OS вообще запущена в этот момент).
                  Есть ещё какие-то варианты помимо вышеупомянутых?


                  Что касается варианта с доступом через сетевые пакеты — насколько я понимаю, в десктопных материнках, в которых нет IPMI/BMC, это работать не должно (WakeOnLan я обычно в BIOS отключаю, не знаю, имеет ли это отношение к данной ситуации).


                  Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.

                  Вот, собственно, то, что мне интересно: работает ли вышеупомянутый "локальный" способ эксплуатации при наличии Grsecurity, и если работает — то через что. Раз возможности удалённо эксплуатировать вроде бы нет, то не похоже, чтобы отправка/инжектирование специально сформированного сетевого пакета давала доступ к ME. А все остальные локальные способы вроде бы заблокированы Grsecurity.

                    +2
                    Если у чипсета вашей материнки нету AMT, то я бы не переживал, но на всякие случай очистил бы МЕ по максимуму mecleaner-ом
                      0

                      AMT это на уровне чипсета. ОС о них знает мелочь, контроля она не имеет.

                        –1

                        Безусловно. Тем не менее, чтобы обычное приложение из юзер-спейса как-то достучалось до AMT, эксплуатировало уязвимость и в результате этого ускользнуло из под контроля OS, ему нужно сначала сделать что-то (напр. писать в I/O порты). В этот момент приложение ещё находится под контролем OS, и ему, теоретически, можно помешать — смотря каким образом реализовано взаимодействие с AMT (о чём я и спрашивал, собственно).


                        В случае удалённой эксплуатации помешать невозможно, потому что пришедший по сети пакет будет сначала обработан AMT, до того как его сможет увидеть OS. А вот в случае локальной эксплуатации, судя по всему, доступ к AMT реализуется через I/O порты, доступ к которым для приложений в юзер-спейсе полностью контролируется OS, так что тот же Grsecurity вполне в состоянии защитить систему.

                          0
                          Обычному приложению к Вам на ПК попасть не надо. Этот взлом происходит удаленно, без доступа к ring0+ ВООБЩЕ.

                          Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).

                          Учитывая говнокачество Intel RMM и ME я не удивлен этой дырой, вопрос был как быстро ее найдут. Все IPMI уязвимы ибо пишут их бангладешские говнокодеры, качество когда просто ужасно, если их смотреть. Хуже чем домашние рутеры. Тот же Supermicro посмотрите — это пи**ец.
                            +1
                            Локально или удаленно имеется ввиду то что если AMT настроено на интернет, то оно будет оттуда взломано, если оно не настроено, то взлом возможен из локальной сети (т.к. AMT по умолчанию стоит на DHCP и через него соединяется).


                            А можно поподробней или ссылку на документацию? Просто я склоняюсь к мнению powerman, что удаленная эксплуатация подразумевает настроенный и открытый доступ по сети, не важно локальной или глобальной, а локально — использование интерфейса в ОС.
                              0
                              Вот что я нашел в документации 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 активирован, что дает возможность удаленной эксплуатации. Но если его отключить, то исходя из описания уязвимости — все равно возможна локальная эксплуатация.
                                0

                                Прочтите сам PoC:


                                https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf


                                Грубо говоря коннект к HTTP самого AMT.


                                AMT включен по умолчанию везде в системах с ним.


                                Локально взлом возможен через DHCP коннект к компьютеру: то есть локально поднять дхцп демона и по выданному ип зайти без пароля в AMT.


                                В принципе методов взлома тонна т.к. доступен HTTP

                                  0
                                  Спасибо, читал.
                                  Почитайте бюллетень, в котором указано, что
                                  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 в сети?
                                    0

                                    Ок, АМТ не может быть "выключенным" в принципе, насколько я понял.
                                    Он всегда включен, однако порт можно отключить, если ПОЛНОСТЬЮ сбросить все в ноль.


                                    A full unprovisioning returns Intel AMT to its factory default state.


                                    Unprovisioned система значит настройки АМТ не введены и пароль дефолтный для системы.


                                    Полный сброс производится через Factory reset AMT и это приводит к доступности по DHCP only или же через меню Ctrl+P или какое вендор даст.


                                    Старые и новые AMT имеют разницу, поэтому от этого зависит.

                                      0
                                      Приводил документацию выше
                                      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, скорее всего используя ту же уязвимость (пустой пароль)
                                        0

                                        Собственно


                                        Полный сброс производится через Factory reset AMT и это приводит к доступности по DHCP only или же через меню Ctrl+P или какое вендор даст.

                                        Как я и написал.


                                        Некоторые вендоры сбрасывают в DHCP, некоторые только в доступность через CTRL+P Некоторые вообще отключают. Зависит от вендора и версии AMT.

              +1
              Правда, Intel в своем оповещении указывает, что уязвимости нет на обычных консьюмерских системах, и оно вроде бы похоже на правду – там как бы нет AMT, ISM и SBT. Но мы же понимаем, что консьюмерский продукт по большому счету отличается от корпоративного настроечками в прошивке. Так и в этом случае: как уже успели выяснить исследователи, эксплуатировать дыру можно и на консьюмерском чипсете, только не удаленно, а локально. То есть, например, какая-нибудь малварь из юзерспейса вполне способна получить неограниченную власть над системой.
              Для вот этого утверждения можете указать источник?
                0
                К примеру, тут:
                Potential Security Impact:
                Remote escalation of privilege on provisioned systems or local escalation of privilege on unprovisioned systems.
                  0
                  Демерьян писал: https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
                    –1

                    Тон там немного истеричный (хоть и не без причины), но в целом очень интересно было почитать, спасибо. Насчёт "любая система выпущенная за последние 10 лет" — у меня (десктопная) материнка 5-ти летней давности на Intel® Z68 Express Chipset, и судя по спеке интела там ME нет вообще.


                    В следующей статье разбирается как раз этот вопрос — если в спеке интела сказано что ME/AMT нет, то нет ли его на самом деле, или физически в железе он всё-таки есть, просто не активен. Я, конечно, не стал бы исключать такой вариант, но по-моему эта проблема несколько раздута. Возможность удалённо эксплуатировать громадное количество систем отправив им сетевой пакет, вне зависимости от OS этих систем и даже того, включены ли они — это одно. Теоретическая (на данный момент) возможность взломать текущую OS конкретной системы с целью прошить заточенную под материнку конкретно этой системы нестандартную прошивку, которая активирует "как бы отсутствующий" в железе AMT, с целью его эксплуатировать — это уже перебор, господа! Я уже молчу о том, что такой подход будет "применим" всегда и к любой системе — кто помешает после обновления/удаления ME использовать этот подход чтобы сначала вернуть старую уязвимую прошивку а потом захватить AMT?


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

                      +4
                      ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше. Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен. Другое дело, что этот чипсет не имеет оф. поддержки Intel vPro (Intel AMT), а значит эта технология (AMT) скорее всего выключена, и уязвимость (о которой идёт речь) удалённо проэксплуатировать не выйдет.
                        –1
                        ME есть в любом чипсете Intel начиная с 5 серии (2010 год) и выше.

                        Даже SemiAccurate не утверждает этого наверняка. Вы более информированы на этот счёт? Есть пруфы или данное утверждение базируется на глубокой внутренней уверенности?


                        Z68 — это чипсет 6-й серии, ME там есть, и, уверен, он активен.

                        Не совсем понял, как может быть "активен" ME, если судя по официальной спеке Intel ME отсутствует на этом чипсете и даже по Вашим словам AMT выключена. Как можно проверить, что ME есть и даже активен?

                          +1
                          Драйвер «Intel® Management Engine Interface» для какого-то устройства ведь ставится. А если есть «Interface», то логично предположить что и «Management Engine» существует.
                            –1

                            Я не знаю, что на материнки с этим чипсетом ставится под винду, у меня линух и таких драйверов нет. Но даже если он ставится — не факт, что он реально работает, а не отвечает "no such device" на любые запросы.

                              +1
                              ID следующие: VEN_8086&DEV_1E3A, VEN_8086&DEV_1CBA, VEN_8086&DEV_1C3A, VEN_8086&DEV_1DBA — посмотрите вывод lspci, скорее всего что-то из списка у вас будет. Если никакого устройства нет, то зачем в принципе делать какой-то интерфейс?
                                –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

                                В общем, странно всё это. Что-то вроде формально есть, но работать — не работает.

                                  0
                                  MEinfo есть под DOS.
                                  И вам нужна правильная версия: т.к. чипсет Z68, то ME firmware у вас должно быть версии 7.x, следовательно, использовать нужно MEinfo из комплекта 7-й версии.
                                    –4

                                    И чем мне это поможет? Ставить ради этого dosbox, который всё-равно не получит доступ к портам из-за grsecurity?

                            +1
                            Насчёт интегрированности ME во все чипсеты начиная с 2010 года — вообще это давно известный факт, скачайте прошивку к своей материнской плате и проверьте наличие ME региона в ней (который содержит прошивку Intel ME). Надеюсь вам этого будет достаточно.

                            Чтобы убедиться в том, что ваш Intel ME живет и функционирует нормально, юзайте утилиту MEinfo.
                              +1
                              И, мне сдаётся, вы путаете понятия Intel ME и Intel AMT. Первое — подсистема, основным компонентом которой является микроконтроллер, интегированный в наши чипсеты. Это подсистема являетя программно-аппаратной поддержкой для технологий компании Intel, в т.ч. Intel AMT, которая имплементирована в виде нескольких кодовых модулей, входящих в состав прошивки Intel ME. Другими словами, Intel ME — движок, основа. Intel AMT — лишь часть прошивки Intel ME.
                                0
                                если судя по официальной спеке Intel ME отсутствует на этом чипсете

                                И что за спецификацию на чипсет вы там читаете, если в даташите на этот чипсет есть описание регистров MEI (Management Engine Interface) в конфигурационном пространстве PCI?
                                  0

                                  Я там выше приводил ссылку на описание чипсета, и там сказано:


                                  Intel® vPro™ Technology: No
                                  Intel® ME Firmware Version: No
                                    +1
                                    Intel® ME Firmware Version: No

                                    Это неточность. В моём распоряжении есть мат. плата на чипсете Intel H67, для которого тоже сказано, что ME firmware version: no, однако MEinfo говорит об обратном.

                                    Данное поле, кстати, отсутствут в описаниях на ark.intel для чипсетов 7 серии и далее.
                        +13
                        Ждать цикла статей «Как запустить свой код в МЕ»?
                          0
                          и вот уже в мае готов патч

                          А где его взять то? Вот у меня плата Intel DQ87PG — на странице загрузки из нового за последние полтора года только сообщение об окончании поддержки. Поиск по номеру прошивки выдаёт только длинные списки уязвимых продуктов и ссылки на PDF Intel рассказывающий как отключить AMT и службы в Windows.
                            +1
                            Скорее всего Intel выпустили пропатченный региона ME, который должны включить в прошивки производители плат. Но лучше дождаться подробного разбора от flothrone или CodeRush, а не перепечатки новостей.
                              0
                              HP, к примеру, не заморачивается никаким включением и просто выкладывает оригинальные файлы прошивок прямо от Intel, отдельно прикладывая Intel'овкские же утилиты для прошивки — разве что упаковывая это всё SFX-архивы. Но подозреваю что для старых продуктов они даже выкладыванием файлов заниматься не будет — выложили инструкцию по отключению части функционала и хватит.
                                +2
                                Технические подробности найденной в коде Intel AMT уязвимости (CVE-2017-5689) уже опубликованы.
                                  +11
                                  Уязвимость настолько простая и глупая, что ее полный разбор влезает в половину твита:
                                    0
                                    А можно теперь сначала и поподробнее? Это строка кода, в которой находится уязвимость? Что не так с этим strncmp?
                                    В комментариях к твиту тоже нет пояснения. А вообще — да, пора уже бросать древный опасный неудобный С и писать всё на С++. Банальный std::string избавляет от необходимости держать в голове кучу фигни, и едва ли добавляет оверхед.
                                      0
                                      Если длина user_input равна 0 (пустая строка), то strncmp вернёт 0 (равенство строк)… красота.
                                      А если очень длинная, то и AV схлопотать можно (теоретически).
                                        0
                                        Действительно. Спасибо за объяснение.
                                  +1
                                  Вот неплохой набор ссылок по теме. Intel обещает выложить обновление не позднее 17-го мая для всех уязвимых плат (начиная с Q57).
                                    0
                                    Забавен тот факт, что более старые семейства плат никто уже не будет обновлять, что, в целом, неудивительно.
                                      0
                                      Уязвимости подвержена ME 6.x и выше, которая появилась в 57-й серии чипсетов.
                                    0
                                    Сегодня успешно скачал и обновил прошивку. Качал, правда, с Fujitsu, но всё работает нормально.
                                    +1

                                    Ну вот и придется кому-то обновлять парк машин.

                                      +4
                                      Тут бы AMD подсуетиться и предложить всем участвовать в компании «живи с чистой материнкой!»
                                        0
                                        А Вы не знаете как технология AMD TrustZone работает? А то может получиться шило на мыло.
                                          0
                                          Ну вот, промахнулся с ответом.
                                            0
                                            TrustZone — это технология ARM, а не AMD.
                                            0
                                            Ахах) Поддерживаю!
                                            –1
                                            Во-первых, я и не писал, что им можно верить, я писал, что им бы подсуетиться с рекламой.

                                            Во-вторых, там же написано — TrustZone, т.е. верить, они считают, можно. Нехорошо не доверять AMD, она не столько раз клиентов оставляла неудовлетворенными, чтобы в этот раз отвергнуть её. Шутка.

                                            Ну а в третьих, несмотря на «волшебные» свойства ME, я бы поостерегся верить слухам: например, лично мне фраза «По слухам, даже шифрование диска ME обходит без напряга» кажется немного желтоватой. Хотя бы тем, что при шифровании данных на диске средствами ОС (драйвером работы с диском) прямой железный (т.е. мимо ОС) доступ к диску будет бесполезен, он даст только кучку защифрованных данных. Если же ME умеет ходить на диск через драйвера ОС, то не такая ME и неподконтрольная становится, в т.ч. и для проверки ее действий со стороны антивируса. А уж если данные на диске зашифрованы на уровне контроллера диска самим диском, то какая польза от ME?

                                            В общем, доверяй, но проверяй. Тем более это читаем в блоге Касперского, которому кипишь на рынке безопасности, в общем-то, на руку (никаких обвинений, просто подумалось).
                                              +3
                                              Ну шифрование она может обойти, если прочитает ключ из памяти, сохранит его где-нить в nvram-е и потом если будет проводиться расследование, то данные будут легко расшифрованы.
                                                0

                                                Вот как раз когда данные зашифрованы контроллером диска — для ME видим поток незашифрованных данных.

                                                0
                                                и снести из системы соответствующие утилиты Intel
                                                Интересно, какие это утилиты?

                                                Я недавно заинтересовался классифицировать все запускаемые на компьютере процессы и внезапно обнаружил, что у NVIDIA и Intel есть своя телеметрия (в частности, от Intel непонятно как в планировщик задач прописался «C:\Program Files (x86)\Intel\Telemetry 2.0\lrio.exe»)
                                                  +8
                                                  Любопытно заметить, что весьма эпичный реверс всей телеметрии с Windows и Windows-приложений проделали сотрудники компании Yota. Можно ставить забавный эксперимент: запускать смартфонный тариф в модеме и отключать службы и процессы до тех пор, пока не начнет наконец выскакивать синее окно жадности «вы используете тариф не там где нужно».

                                                  Среди прочего, NVIDIA телеметрия мне тоже попадалась. Еще, как ни странно, у более-менее новых видеокарт одновременно с драйверами ставятся приложения, которые как бы между делом шлют тонны статистики на сервера.
                                                    +3
                                                    может наоборот, перестанет выскакивать?
                                                      0
                                                      Да, вы правы. Немного неточно сформулировал, но суть вы уловили правильно.
                                                    +1
                                                    В официальном PDF предлагают удалять
                                                    Intel® Management and Security Application Local Management Service (LMS)
                                                    , запуском «sc delete LMS».
                                                    –1
                                                    Слышал про то, как Джоанна Рутковска эксплуатировала какую-то аппаратную уязвимость, так там был такой прикол, что злоумышленнику в любом случае оставалась возможность выполнить сброс к заводским установкам — то есть даже если на уязвимое железо установить обновление, закрывающее уязвимость, то злоумышленник мог вызвать откат к заводской версии прошивки, и всё равно использовать уязвимость!
                                                    Поэтому вполне вероятно, что и здесь просто установкой обновлений не отделаешься.
                                                      +6
                                                      Пожалуйста, не вставляйте больше гифки в статьи. Это очень отвлекает.
                                                      • UFO just landed and posted this here

                                                        Only users with full accounts can post comments. Log in, please.