Есть такая технология, называется verified boot, и работает она практически так, как вы описали, я о ней писал в первой статье этого цикла.
Если китайцы умудрились подставить свой код в ME — снимаю перед ними шляпу. Да, в таком случае они имеют возможность выполнить любой код еще до ResetVector'а, и никакими защитами прошивки, кроме переписывания региона МЕ на заведомо чистый, от такого не защититься. Я пока не слышал об успешных атаках на последние версии МЕ, но это не значит, что их не было. Исследованием прошивок внутренних контролеров сейчас занимается буквально 2,5 человека (Игорь Скочинский из HexRays сразу на ум приходит, ребята из LegbaCore и Invisible things Lab, и все считай), поэтому идут они медленно и накопать каких-то адски серьезных уязвимостей пока не получилось.
Раньше было просто потому, что тему не затрагивали. Где-то был джампер Read-only, но в основном был полный доступ на запись прямо из ОС.
Я не думаю, что у обычного пользователя уже засела куча троянов, т.к. технология относительно новая и в хакерской среде пока не очень популярная, но если ничего не делать, то трояны там обязательно засядут. Сначала они будут примитивные донельзя, как нашумевший недавно HT rkloader, но потом начнется гонка вооружений и атакующее прошивку ПО быстро вылезет из своей PoC-песочницы. Именно поэтому важно исправить обнаруженные уязвимости сейчас, а там, где нельзя исправить — сообщить об этом.
Очень многие, в том числе и признанные специалисты по ИБ, сомневаются в опасности атак на UEFI, считая их слишком дорогими и слишком целевыми, чтобы быть сколько-нибудь опасными для обычного пользователя. То же самое в свое время говорили про любые новые классы атак, пока их не вепонизировали и не добавили в Metasploit. А для UEFI, ноги 80% которого растут из открытого кода проекта TianoCore, сделать это будет весьма несложно. Вот тут ребята из LegbaCore рассказывают подробнее.
Ну как сказать… Записать свой код в прошивку, получив возможность переживать переустановку системы и смену всего оборудования, кроме материнской платы. Записать свой код в SMM и прятаться там от любых средств защиты уровня ОС, а самому творить с ними непотребное. Возможностей то масса, я их уже в предыдущих постах описывал.
В общем, с незакрытыми уязвимостями в прошивке от LPE до греха — один шаг.
Хорошее дополнение, спасибо.
Я просто в последнее время работаю с системами на AMD, и этот момент совершенно вылетел из головы. У AMD TSEG задается двумя MSR — TSegBase и TsegMask, и потому такой проблемы там не возникает.
Именно так, сами делаем модули и сами к ним БИОСы пишем (понятно, что не с нуля, но тем не менее), поэтому можем обойтись и без IOMMU, но никогда ведь не знаешь, какой 0day найдут послезавтра…
Про механизм этот я в тексте упомянул. Я не вникал в реализацию IOMMU на процессорах Intel, но на AMD можно выделить определенные области под DMA Remap еще в прошивке и залочить их намертво до перезагрузки.
Честно сказать — глубоко в этом направлении не копал, поэтому ничего утверждать не буду.
Это хорошо, что прошивку можно слить и исследовать, а то обычно залочат фьюзами и все. Если клиенты доверяют — это хорошо. Нам тоже доверяют пока, но у нас BMC никаких функций безопасности не выполняет, таким было требование большинства клиентов в самом начале, чтобы не допустить side channel атак через него.
Правильно понимаете, а я банально забыл про это упомянуть, каюсь. Реального использования IOMMU для защиты от DMA-атак я не видел пока, но думаю, что еще увижу, а если чипсеты AMD, которые мы сейчас используем, окажутся ей подвержены, то придется реализовавывать защиту самому.
Намного лучше, когда он с собственной флешкой, т.к. в таком случае через него невозможна атака на ее содержимое. Я знаю, что EC — та еще гадость в смысле безопасности, но крипточип с закрытой прошивкой, как в вашем примере выше, тоже не очень-то располагает к безграничному доверию. Мы используем в качестве BMC обычный ARM Cortex M4 производства Texas Instruments, подключенный через LPC, и прошивку для него мы написали сами, поэтому я уверен, что в ней нет ни бэкдоров, ни каких-то посторонних возможностей.
Я использую старую расшифровку аббревиатуры EC, т.к. сейчас слово embedded уже настолько везде, что практически потеряло значение. А так — сразу понятно, чем занимается EC — температуры меряет и вентиляторами управляет.
Потому что за 0 на графике взято минимальное значение.
Если строить от 0 — будет сплошная зеленая полоса от 0 до минимума, которая не добавляет никакой информации вообще.
Нет. Некоторые атаки обнаружены всего пару недель назад, и потому пока не могут быть опубликованы, т.к. для 99% пораженных систем еще не вышли обновления.
Ее и на современных роутрах часто нет.
В энтерпрайзной среде почему-то считается, что проблемы безопасности прошивок — overhyped, и потому не стоят внимания. Тот факт, что прошивку подавляющего большинства железок, кроме совсем уж экзотических, можно банально слить программатором и дизассемблировать в radare2, а потом залить куда-нибудь в свободное место шеллкод и собрать обратно — это давно уже не ракетная наука, до людей, принимающих решения просто не доходит. И не будет доходить, пока модуль по внедрению не добавят в Metasploit, но и тогда, возможно, они скажут, что надо лучше защищать сервера от физического доступа и такие бэкдоры — единичный случай и капля в море.
Гром не грянет — мужик не перекрестится, традиционно.
Затрону, конечно, но не сразу, сначала надо рассказать, что атакуют, а потом уже — как.
Про бэкдор HT не вспомнили по причине его примитивности. Понятно, что задачу свою он выполняет, но лучше, чем ThrDev, я о нем, наверное, не скажу.
Hacking Team's EFI «rootkit» makes me sad. It's like buying a Bugatti Veyron and replacing the engine with a box of dildos.
Джампер можно реализовать, и прямо в статье написано, как именно, но этого никто не делает — в текущих условиях это дорого и мало кому нужно.
Если вас защита задевает — покупайте продукты без нее, их море. Только вот доверять ОС, которая, в основном, написана вполне средними программистами 10+ лет назад на С или С++ — решительно невозможно.
Проблема защиты от физического доступа — административная, а не системная, и ключи в кремнии решают не проблему «злой хакер Семен сменил все чипы, и таким образом отключил защиту», а «измененный злым хакером Семеном образ БИОСа не запустился вообще»
Если говорить про аппаратные закладки и т.п., то единственный выход — свободное железо. OpenRISC, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.
Если китайцы умудрились подставить свой код в ME — снимаю перед ними шляпу. Да, в таком случае они имеют возможность выполнить любой код еще до ResetVector'а, и никакими защитами прошивки, кроме переписывания региона МЕ на заведомо чистый, от такого не защититься. Я пока не слышал об успешных атаках на последние версии МЕ, но это не значит, что их не было. Исследованием прошивок внутренних контролеров сейчас занимается буквально 2,5 человека (Игорь Скочинский из HexRays сразу на ум приходит, ребята из LegbaCore и Invisible things Lab, и все считай), поэтому идут они медленно и накопать каких-то адски серьезных уязвимостей пока не получилось.
Я не думаю, что у обычного пользователя уже засела куча троянов, т.к. технология относительно новая и в хакерской среде пока не очень популярная, но если ничего не делать, то трояны там обязательно засядут. Сначала они будут примитивные донельзя, как нашумевший недавно HT rkloader, но потом начнется гонка вооружений и атакующее прошивку ПО быстро вылезет из своей PoC-песочницы. Именно поэтому важно исправить обнаруженные уязвимости сейчас, а там, где нельзя исправить — сообщить об этом.
Очень многие, в том числе и признанные специалисты по ИБ, сомневаются в опасности атак на UEFI, считая их слишком дорогими и слишком целевыми, чтобы быть сколько-нибудь опасными для обычного пользователя. То же самое в свое время говорили про любые новые классы атак, пока их не вепонизировали и не добавили в Metasploit. А для UEFI, ноги 80% которого растут из открытого кода проекта TianoCore, сделать это будет весьма несложно. Вот тут ребята из LegbaCore рассказывают подробнее.
В общем, с незакрытыми уязвимостями в прошивке от LPE до греха — один шаг.
Я просто в последнее время работаю с системами на AMD, и этот момент совершенно вылетел из головы. У AMD TSEG задается двумя MSR — TSegBase и TsegMask, и потому такой проблемы там не возникает.
Честно сказать — глубоко в этом направлении не копал, поэтому ничего утверждать не буду.
Если строить от 0 — будет сплошная зеленая полоса от 0 до минимума, которая не добавляет никакой информации вообще.
В энтерпрайзной среде почему-то считается, что проблемы безопасности прошивок — overhyped, и потому не стоят внимания. Тот факт, что прошивку подавляющего большинства железок, кроме совсем уж экзотических, можно банально слить программатором и дизассемблировать в radare2, а потом залить куда-нибудь в свободное место шеллкод и собрать обратно — это давно уже не ракетная наука, до людей, принимающих решения просто не доходит. И не будет доходить, пока модуль по внедрению не добавят в Metasploit, но и тогда, возможно, они скажут, что надо лучше защищать сервера от физического доступа и такие бэкдоры — единичный случай и капля в море.
Гром не грянет — мужик не перекрестится, традиционно.
Про бэкдор HT не вспомнили по причине его примитивности. Понятно, что задачу свою он выполняет, но лучше, чем ThrDev, я о нем, наверное, не скажу.
Если вас защита задевает — покупайте продукты без нее, их море. Только вот доверять ОС, которая, в основном, написана вполне средними программистами 10+ лет назад на С или С++ — решительно невозможно.
Проблема защиты от физического доступа — административная, а не системная, и ключи в кремнии решают не проблему «злой хакер Семен сменил все чипы, и таким образом отключил защиту», а «измененный злым хакером Семеном образ БИОСа не запустился вообще»
Если говорить про аппаратные закладки и т.п., то единственный выход — свободное железо. OpenRISC, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.