Истинно так. Intel уже портратила на продвижение IoT сольдный маркетинговый бюджет, но на выходе пока только такой же маркетинговый буллшит. Существующие решения M2M никуда не денутся (там в индустрии за подключение машин к глобальной сети без надлежащей изоляции просто увольняют), а весь этот Internet of Trash обязательно приведет к тому, что у обыкновенного пользователя вместо пары уязвимых устройств появится пара десятков. Вывод простой — голосуем ногами, пусть весь этот IoT просто проходит мимо.
Пожалуйста, спасибо, что читаете.
Если с этой части начинать, мои тексты никто читать не станет — все разбегутся читать первосточники, там ведь картинки и PDFки, а у меня тут текст голимый и шутки несмешные. ;)
Это возможно и теоритически, и практически, но некоторые производители сознательно прячут эти настройки от пользователя, не желая описывать их в документации, либо специально блокируя возможность смены ключей, как это сделано на смартфонах и планшетах Microsoft.
Я постараюсь рассказать подробнее о настройке SecureBoot в отдельно посте, прошу только подождать немного.
Попробуйте переключить все опции Launch… Option ROM в UEFI Only, перезагрузиться и отключить CSM — должно сработать. Обычно CSM не дает отключить себя если VBIOS загружен, но нармальные реализации UEFI предупреждают об этом сообщением при попытке отключить CSM.
Пожалуйста, спасибо, что читаете.
Насколько — не могу сказать точно, мало опыта использования coreboot, но заведомо меньше, т.к. кодовая база намного компактнее и никто не пытается добавить в прошивку все, до чего руки дотянулись и компилятор смог собрать. Будет время — попробую разобраться получше.
Подходящая платформа для параноика сильно зависит от степени паранойи, кому-то достаточно ARM без TrustZone (хотя их таких пойди еще найди теперь), кому-то можно посоветовать OpenRISC (только вот всего 2,5 процессора ровно одной маленькой компании — это очень грустно), кто-то может посмотреть в сторону отечественных решений или китайских MIPSов (это если вам свои бэкдоры милее чужих).
Пропустил, каюсь. Их исправили еще пару лет назад и я давно про них не слышал, вот и забыл.
Для тех, кто не в курсе: суть атаки в том, что обновление и PK и KEK, и db с dbx возможно не только из BIOS Setup, но и из ОС, и в правильной реализации для обновления PK и KEK нужен текущий PKpriv, а для обновления db и dbx — KEKpriv. На некоторых старых реализациях при проверке подписи этих обновленных ключей можно было организовать переполнение буфера ии получить доступ к NVRAM, а дальше просто заменить или удалить PK. Проблему нашли и исправили достаточно быстро, еще в 2012 году, и с тех пор о ней больше не слышно. Прошу прощения, что я про нее забыл.
Ситуация такая в основном потому, что SecureBoot по прежнему очень редко используется, от этого он недостаточно протестирован и потому кривые реализации продолжают быть кривыми — просто никто не знает о том, что они кривые. При этом SecureBoot — единственная нормальная защита от вредоносных OROMов и загрузчиков, и без него на любой системе можно загрузить UEFI Shell и натворить кучу неприятных дел.
Вместо распространения вестей о том, что SecureBoot — это злодейское изобретение MS для ограничения свободы пользователя, нужно распространять знания о том, как им пользоваться правильно, как сгенерировать свои собственные PK и KEK, как удалить предустановленные, как подписать собственный загручик и так далее. Я напишу об этом статью после окончания этого цикла.
Появятся, конечно, рано или поздно, так или иначе.
Но на данный момент "юзерленд по прежнему в полной Ж", а разработка вирусов для Windows стоит дешевле и окупается быстрее, чем разработка руткитов для UEFI.
Главное, что о безопасности задумались вообще, а то ведь 10 лет до этого сидели с открытой на запись микросхемой и не парились совсем, а теперь вот то одну уязвимость закроют, то другую.
Не вернут, и дело точно не в работе, скорее в том, что решения. принятые более 10 лет назад, изменить будет не так просто. Кто о безопасности NVRAM уже задумался — у тех есть и его резервное копирование, и защита от разрушения, и восстановлние после сбоя, и возможность преноса в отдельную микросхему, но массовому рынку это все просто не нужно — «работает, и слава Богу».
Исследуют, но такие косяки обычно исправляют молча, т.к. IBV не дают разрешение на публикацию деталей уязвимости. Самое смешное, что скрываться в данном случае не только вредно со всех точек зрения, кроме маркетинговой, но и совершенно бессмысленно — о том, что какая-то уязвимость исправлена, можно узнать банально исследуя разницу между двумя версиями прошивки. Причем делать это можно не только вручную, но и автоматически, благодаря проекту Тедди Рида Subzero.io.
Про другое. Понятно, что розеткусы не следует использовать для подключения мощных нагрузок, вроде чайников или микроволновок, но я сейчас про отсутсвие защитного зануления (оно же «заземление», если по простому). Без заземления на всем подряд будет скапливаться статический заряд, и рано ли поздно статикой начнет бить людей (это неприятно, но не смертельно) и технику (а она от этого, бывает, ломается, причем внезапно).
Больно смотреть на эти розеткусы без защитного зануления.
После того, как закончите с ремонтом, пройдитесь по офису с вот таким прибором, с большой вероятностью узнаете много нового про электрический потенциал на корпусах ваших железок и на вас самих.
Про это однажды была статья в журнале Хакер, вот она. И речь в ней, как раз, об Intel'овских процессорах и китайских материнских платах для них с изменной прошивкой толи МЕ, толи BMC, толи EC — в общем, одного из набортных контролеров.
Я вполне допуская ненулевую вероятность такой атаки, но стоить она будет весьма недешево, особенно с учетом того, что надо у Intel ключи стащить. Скорее всего, автор статьи зацепил краем глаза какую-то операцию спецслужб США.
Если бояться подобного рода атак, то единственный вариант защиты — открытое железо. И то никто не гаратирует, что на фабрике в него не добавят еще какой-нибудь скрытый контролер, чтобы управлять всем, так что проще всего расслабиться и попытаться получить удовольствие.
Цель ИБ — не предотвратить любые виды атак, а сделать так, чтобы стоимость атаки была выше стоимости обрабатываемой информации. Короче, если вы обрабатываете сверхсекретные сведения — делайте себе для этого процессоры сами. А если вы обрабатываете фотографии котиков — просто не парьтесь и все.
Скрывать факт работы с IBV глупо — тайна продержится до первого дампа. :)
Насчет сертификации в ФСБ — там же BLOB'ов штук десять как минимум, CSM16, куча расширений к нему, OROM'ы, драйвер PXE, драйвер SATA, драйвер ФС FAT и т.п., неужели пришлось у AMI исходники покупать, или прямо бинарем и сертифицировали? Я не очень разбираюсь во всей этой кухне (и не очень хочу, если честно), но со стороны кажется, что в «сертификации в ФСБ» больше бумажной работы, чем инженерной.
Есть такая технология, называется verified boot, и работает она практически так, как вы описали, я о ней писал в первой статье этого цикла.
Если китайцы умудрились подставить свой код в ME — снимаю перед ними шляпу. Да, в таком случае они имеют возможность выполнить любой код еще до ResetVector'а, и никакими защитами прошивки, кроме переписывания региона МЕ на заведомо чистый, от такого не защититься. Я пока не слышал об успешных атаках на последние версии МЕ, но это не значит, что их не было. Исследованием прошивок внутренних контролеров сейчас занимается буквально 2,5 человека (Игорь Скочинский из HexRays сразу на ум приходит, ребята из LegbaCore и Invisible things Lab, и все считай), поэтому идут они медленно и накопать каких-то адски серьезных уязвимостей пока не получилось.
Раньше было просто потому, что тему не затрагивали. Где-то был джампер Read-only, но в основном был полный доступ на запись прямо из ОС.
Я не думаю, что у обычного пользователя уже засела куча троянов, т.к. технология относительно новая и в хакерской среде пока не очень популярная, но если ничего не делать, то трояны там обязательно засядут. Сначала они будут примитивные донельзя, как нашумевший недавно HT rkloader, но потом начнется гонка вооружений и атакующее прошивку ПО быстро вылезет из своей PoC-песочницы. Именно поэтому важно исправить обнаруженные уязвимости сейчас, а там, где нельзя исправить — сообщить об этом.
Очень многие, в том числе и признанные специалисты по ИБ, сомневаются в опасности атак на UEFI, считая их слишком дорогими и слишком целевыми, чтобы быть сколько-нибудь опасными для обычного пользователя. То же самое в свое время говорили про любые новые классы атак, пока их не вепонизировали и не добавили в Metasploit. А для UEFI, ноги 80% которого растут из открытого кода проекта TianoCore, сделать это будет весьма несложно. Вот тут ребята из LegbaCore рассказывают подробнее.
Если с этой части начинать, мои тексты никто читать не станет — все разбегутся читать первосточники, там ведь картинки и PDFки, а у меня тут текст голимый и шутки несмешные. ;)
Я постараюсь рассказать подробнее о настройке SecureBoot в отдельно посте, прошу только подождать немного.
Насколько — не могу сказать точно, мало опыта использования coreboot, но заведомо меньше, т.к. кодовая база намного компактнее и никто не пытается добавить в прошивку все, до чего руки дотянулись и компилятор смог собрать. Будет время — попробую разобраться получше.
Подходящая платформа для параноика сильно зависит от степени паранойи, кому-то достаточно ARM без TrustZone (хотя их таких пойди еще найди теперь), кому-то можно посоветовать OpenRISC (только вот всего 2,5 процессора ровно одной маленькой компании — это очень грустно), кто-то может посмотреть в сторону отечественных решений или китайских MIPSов (это если вам свои бэкдоры милее чужих).
Для тех, кто не в курсе: суть атаки в том, что обновление и PK и KEK, и db с dbx возможно не только из BIOS Setup, но и из ОС, и в правильной реализации для обновления PK и KEK нужен текущий PKpriv, а для обновления db и dbx — KEKpriv. На некоторых старых реализациях при проверке подписи этих обновленных ключей можно было организовать переполнение буфера ии получить доступ к NVRAM, а дальше просто заменить или удалить PK. Проблему нашли и исправили достаточно быстро, еще в 2012 году, и с тех пор о ней больше не слышно. Прошу прощения, что я про нее забыл.
Вместо распространения вестей о том, что SecureBoot — это злодейское изобретение MS для ограничения свободы пользователя, нужно распространять знания о том, как им пользоваться правильно, как сгенерировать свои собственные PK и KEK, как удалить предустановленные, как подписать собственный загручик и так далее. Я напишу об этом статью после окончания этого цикла.
Но на данный момент "юзерленд по прежнему в полной Ж", а разработка вирусов для Windows стоит дешевле и окупается быстрее, чем разработка руткитов для UEFI.
Главное, что о безопасности задумались вообще, а то ведь 10 лет до этого сидели с открытой на запись микросхемой и не парились совсем, а теперь вот то одну уязвимость закроют, то другую.
Исследуют, но такие косяки обычно исправляют молча, т.к. IBV не дают разрешение на публикацию деталей уязвимости. Самое смешное, что скрываться в данном случае не только вредно со всех точек зрения, кроме маркетинговой, но и совершенно бессмысленно — о том, что какая-то уязвимость исправлена, можно узнать банально исследуя разницу между двумя версиями прошивки. Причем делать это можно не только вручную, но и автоматически, благодаря проекту Тедди Рида Subzero.io.
После того, как закончите с ремонтом, пройдитесь по офису с вот таким прибором, с большой вероятностью узнаете много нового про электрический потенциал на корпусах ваших железок и на вас самих.
Я вполне допуская ненулевую вероятность такой атаки, но стоить она будет весьма недешево, особенно с учетом того, что надо у Intel ключи стащить. Скорее всего, автор статьи зацепил краем глаза какую-то операцию спецслужб США.
Если бояться подобного рода атак, то единственный вариант защиты — открытое железо. И то никто не гаратирует, что на фабрике в него не добавят еще какой-нибудь скрытый контролер, чтобы управлять всем, так что проще всего расслабиться и попытаться получить удовольствие.
Цель ИБ — не предотвратить любые виды атак, а сделать так, чтобы стоимость атаки была выше стоимости обрабатываемой информации. Короче, если вы обрабатываете сверхсекретные сведения — делайте себе для этого процессоры сами. А если вы обрабатываете фотографии котиков — просто не парьтесь и все.
Насчет сертификации в ФСБ — там же BLOB'ов штук десять как минимум, CSM16, куча расширений к нему, OROM'ы, драйвер PXE, драйвер SATA, драйвер ФС FAT и т.п., неужели пришлось у AMI исходники покупать, или прямо бинарем и сертифицировали? Я не очень разбираюсь во всей этой кухне (и не очень хочу, если честно), но со стороны кажется, что в «сертификации в ФСБ» больше бумажной работы, чем инженерной.
Если китайцы умудрились подставить свой код в ME — снимаю перед ними шляпу. Да, в таком случае они имеют возможность выполнить любой код еще до ResetVector'а, и никакими защитами прошивки, кроме переписывания региона МЕ на заведомо чистый, от такого не защититься. Я пока не слышал об успешных атаках на последние версии МЕ, но это не значит, что их не было. Исследованием прошивок внутренних контролеров сейчас занимается буквально 2,5 человека (Игорь Скочинский из HexRays сразу на ум приходит, ребята из LegbaCore и Invisible things Lab, и все считай), поэтому идут они медленно и накопать каких-то адски серьезных уязвимостей пока не получилось.
Я не думаю, что у обычного пользователя уже засела куча троянов, т.к. технология относительно новая и в хакерской среде пока не очень популярная, но если ничего не делать, то трояны там обязательно засядут. Сначала они будут примитивные донельзя, как нашумевший недавно HT rkloader, но потом начнется гонка вооружений и атакующее прошивку ПО быстро вылезет из своей PoC-песочницы. Именно поэтому важно исправить обнаруженные уязвимости сейчас, а там, где нельзя исправить — сообщить об этом.
Очень многие, в том числе и признанные специалисты по ИБ, сомневаются в опасности атак на UEFI, считая их слишком дорогими и слишком целевыми, чтобы быть сколько-нибудь опасными для обычного пользователя. То же самое в свое время говорили про любые новые классы атак, пока их не вепонизировали и не добавили в Metasploit. А для UEFI, ноги 80% которого растут из открытого кода проекта TianoCore, сделать это будет весьма несложно. Вот тут ребята из LegbaCore рассказывают подробнее.