Когда-то давно, в начале 2014 года, я назвал состояние безопасности большинства реализаций UEFI "полумифическим". С тех пор минуло полтора года, дело осторожно двигается с мертвой точки, но до сих пор очень многие производители ПК для конечного пользователя не обращают на эту самую безопасность почти никакого внимания — «пипл хавает».В этой статье речь пойдет о модели угроз и векторах атаки на UEFI, а также о защитах от перезаписи содержимого микросхемы BIOS — самой разрушительной по возможным последствиям атаки.
Если вам интересно, как устроена защита UEFI и какие именно уязвимости в ней так и остаются неисправленными на большинстве современных систем — добро пожаловать под кат.
Часть нулевая. Введение
Безопасностью UEFI-совместимых прошивок я интересуюсь довольно давно, и уже почти 2 года занимаюсь ей профессионально. Поводом к написанию этой статьи послужило практически полное отсутствие в русскоязычной части интернета какой-либо информации по безопасности UEFI, кроме переводов статей известных англоязычных исследователей, выполненных слабо знакомыми с предметом людьми. Пробел это надо понемногу восполнять, т.к. иначе он заполняется разного рода лозунгами вроде «SecureBoot против свободного ПО», «UEFI — порождение дьявола» и тому подобное. Прошу заранее прощения за язык — когда долго не говоришь и не пишешь на русском, перестаешь на нем думать, и потому конструкции могут получаться весьма странные.
Модель угроз
Прежде чем говорить о защите и уязвимостях, поговорим немного о модели угроз.Ни одна защита не может защитить от всего сразу. К примеру, защиту прошивки от поражающего действия ядерного взрыва или от сбоев при работе в открытом космосе, я в этой статье рассматривать не буду, хотя с удовольствием почитал бы подобную статью от специалистов в соответствующей области.
Уровни доступа
Определим для атакующего несколько уровней доступа и посмотрим, что и насколько успешно «среднестатистическая» реализация UEFI может противопоставить ему:— атакующий первого уровня имеет физический доступ к системе, способен загружать любые ОС, изменять настройки UEFI, прошивать свой код UEFI вместо оригинального на программаторе, переставлять джамперы на мат. плате, замыкать выводы микросхем и т.п.
— атакующий второго уровня имеет физический доступ к системе, но программатора у него нет.
— атакующий третьего уровня имеет удаленный доступ к системе в режиме администратора.
Остальные случаи рассматривать не будем, т.к. от более могущественного атакующего, способного менять сидящие на шарах чипы, в UEFI защищаться практически нечем, а более слабых, без прав администратора, остановит ОС.
Векторы атаки
Теперь определим основные векторы и последствия успешно совершенной атаки, в порядке уменьшения опасности:1. Хранилище основной прошивки (в 95% современных систем — 1-2 микросхемы NOR-flash с интерфейсом SPI)
Суть атаки — вставляем свой код в прошивку, удаляем части имеющегося, воруем, убиваем, молчим про гусей.Последствия атаки варьируются от получения полного контроля над прошивкой, аппаратурой и ОС в лучшем случае, до DoS в худшем. Физический атакующий может устроить DoS в любом случае (с размаху отверткой в плату — вот тебе и DoS), поэтому подробнее на DoS для атакующих первого и второго уровней останавливаться не буду.
2. Код в SMM
Суть — получаем доступ к особо привилегированному режиму процессора, из которого нам доступна на чтение и запись вся физическая память и много другого вкусного.Последствия — в лучшем случае доступ к хранилищу прошивки, и далее смотри пункт 1, в худшем — обход механизмов защиты ОС и гипервизора (которые, впрочем, можно было обойти и на уровне ОС, но из SMM это может быть намного проще).
3. Хранилище прошивки PCI-устройств
Суть — вставляем свой код в прошивку какого-либо PCI-устройства (она же Option ROM), к примеру, сетевой карты или контролера Thunderbolt, UEFI выполняет этот код при инициализации устройства, ..., профит.Последствия — в лучшем случае смотри пункт 1, в худшем — почти то же самое, только стартуем значительно позже, и потому некоторые вещи уже настроены и заблокированы.
4. Переменные в NVRAM
Суть — получаем возможность изменять настройки UEFI, в том числе скрытые.Последствия — в лучшем случае можно поотключать все защиты и сразу перейти к пункту 1, в худшем — снова DoS (пишем мусор в NVRAM, перезагружаемся, смотрим, что получилось).
5. SecureBoot
Суть — получаем возможность загрузить любую нужную ОС, в том числе UEFI Shell.Последствия — в лучшем случае получается загрузить UEFI Shell и сразу оказаться в пункте 4, в худшем — заменить стандартный загрузчик ОС на модифицированный, закрепившись таким образом в ОС, пока бдительный пользователь не включит SecureBoot обратно.
Часть первая. Защиты от записи в хранилище основной прошивки
1. Аппаратная верификация прошивки или её части перед выполнением любого кода
Самые серьезные технологии в нашем списке, которые, будучи правильно реализованными, защищают прошивку от атакующих всех трех уровней — Intel BootGuard и AMD Hardware-Validated Boot. Существенно отличаясь в деталях, они выполняют одинаковую задачу: проверяют целостность небольшой части прошивки, которая подписана ЭЦП производителя материнской платы, а хэш ключа прошит в чипсет. Если проверка прошла успешно, прошивка стартует, если же нет — все зависит от настроек. Обе технологии предоставляют «аппаратный корень доверия» для последующих стадий загрузки, и прошивка может выстроить цепочку доверия, в которой чипсет проверяет bootstrap-код, этот код проверяет том PEI, тот в свою очередь — том DXE, а в DXE уже включается SecureBoot и проверяет подпись загрузчика ОС. Любое изменение защищенных таким образом частей прошивки приводит, чаще всего, к банальному DoS.Обратная сторона такой защиты — невозможность модификации прошивки даже легитимным пользователем системы, сложности ремонта материнской платы при отказе чипсета или SoC'а (и хорошо, если меняем на чистый, а не на использованный с другим хэшем, в первом случае можно попробовать удалить драйверы для Verified Boot из образа, а во втором не поможет уже ничего).
Поддерживаются эти технологии начиная с Intel Haswell и AMD Trinity, и работающих атак на них я пока не знаю, но сейчас они используются на двух с половиной моделях корпоративных ноутбуков и я бы предпочел, чтобы ситуация сильно не менялась, ведь именно возможность модификации прошивки и ОС отличает твое устройство от чужого.
О том, как проверить конкретную систему на наличие какой-либо вариации Verified Boot — напишу в следующий раз, после того, как получу от Intel и AMD разрешение на публикацию.
Атакующие первого уровня могут расслабиться и получать удовольствие — кроме аппаратной верификации им не может помешать никакая из последующих защит. Именно поэтому я говорил и буду говорить: программатор и SOIC-клипса — маст-хэв для любого серьезного исследователя прошивок.
2. Хранилище только для чтения с аппаратным переключателем
В стародавние до-UEFI-шные времена на многих материнских платах устанавливался джампер, защищающий микросхему с BIOS'ом от случайной или злонамеренной прошивки. Сложностей с реализацией такой защиты практически не возникало, т.к. все содержимое BIOS Setup хранилось в отдельно в CMOS SRAM и, кроме случаев обновления прошивки, ничего писать было просто не нужно. Затем кто-то в Intel принял решение, что в CMOS места мало, и потому нужно взять микросхему поёмче и побыстрее, и все настройки писать туда, чего месту зря пропадать. В результате этого «гениального» решения (и цепочки последующих, такого же уровня гениальности) в одной микросхеме оказалось все: собственно UEFI, часть прошивки встроенной сетевой карты (GbE), большая часть прошивки чипсета (ME), прошивка EC и черт знает что еще, и каждый из трех владельцев микросхемы (CPU, ME и GbE) получил право писать в нее не только при обновлении, а вообще в любой момент. Чтобы как-то упорядочить возникший бардак, Intel добавила в начало микросхемы Flash Descriptor, в котором явно прописаны права доступа трех владельцев к каждому региону (подробнее о дескрипторе и форматах я уже писал), но это не сильно помогло. Единственный официально поддерживаемый способ отделить мух от котлет и RW от RO — установка двух микросхем SPI, первая отдается под Descriptor, ME, GbE и NVRAM, а вторая — под оставшуюся часть UEFI, после чего нога #WP второго чипа садится джампером на землю, защищая его от записи аппаратно.Проблем у такой защиты несколько:
— два чипа чуть менее чем вдвое дороже одного и любой закупщик мечтает сэкономить на них миллион-другой долларов на массовом производстве, поэтому плату с двумя чипами днем с огнем не найти.
— для прошивки обязателен физический доступ, т.к. вывод #WP на GPIO губит всю безопасность на корню.
— испортить содержимое RW-микросхемы все равно можно даже не имея физического доступа.
К сожалению, реализаций подобной защиты на имеющихся на массовом рынке системах с UEFI я пока не видел. Раньше — были, а теперь остались только на Chromebook, но там прошивка основана на coreboot. Я не знаю, как именно там реализована аппаратная защита от прошивки при условии, что там тот же самый ME, что и везде…
3. PR-регистры чипсета
Если аппаратно микросхему SPI защитить от записи не получилось, можно защитить ее силами чипсета. Все современные чипсеты имеют как минимум 4 регистра PR, предназначенных для защиты от чтения и/или записи блока физической памяти, а т.к. микросхема SPI всегда отображается на «дно» первых 4 Гб физической памяти (т.е. последний байт микросхемы SPI всегда находится по физическому адресу 0xFFFFFFFF), но можно защитить всю прошивку или ее часть.Защита подобного рода тоже не обходится без проблем:
— ее нужно правильно реализовать, не забыв, что при перезагрузке значения регистров тоже сбрасываются, и их нужно восстанавливать.
— нужно не забыть установить (и восстановить после перезагрузки) lock на их конфигурацию, иначе вредоносный код их может банально сбросить.
— защита не может быть отключена, т.е. обновление прошивки из ОС без перезагрузки становится невозможным.
— и, конечно, NVRAM и другие RW-области защитить таким способом не получится.
В отличие от предыдущего пункта, систем с PR'ами на рынке море, и почти на всех защита реализована неграмотно или неполно.
4.1. SMM_BWP и SpiRomProtect
Вновь похожие друг на друга защиты от Intel и AMD соответственно, которые не позволяют запись в микросхему SPI из любого режима процессора, кроме SMM. Для обновления прошивки используется специальный SMI-обработчик, который должен выполнять проверку целостности и подписи новой прошивки, и только после успешной проверки выполнять прошивку.Защита эта достаточно простая в реализации и потому есть практически на любом UEFI, но иногда она отключена по умолчанию. Большой плюс — независимость кода прошивальщика от архитектуры.
Есть и недостатки:
— кода в SMM много, и любая уязвимость в нем дает полный доступ к прошивке.
— от багов в реализации самого прошивальщика тоже никто не застрахован.
— если защита управляется переменной в NVRAM (очень много систем, где это так), то она практически бесполезна, ибо может быть просто отключена атакующим, способным загрузить UEFI Shell.
Посмотрев на вышеперечисленные недостатки, ребята из Intel решили исправить их, где-то примерно в Ivy Bridge придумали следующую защиту, а именно…
4.2. Intel BIOS Guard, в девичестве PFAT
Справедливо рассудив, что кода в SMM слишком много, а IBV никак не могут написать свои прошивальщики так, чтобы в них не зияло дыр, Intel решили, что нужно идти глубже, и добавили еще один привилегированный режим исполнения, специальную область памяти ACRAM, недоступную из других режимов, в которую можно загрузить только подписанный Intel'овской ЭЦП прошивальщик, и только ему будет доступна запись в микросхему SPI. Все три проблемы из пункта 4.1 удалось успешно решить, но при этом, конечно, добавили новых:— отвратительно высокая сложность во всем. Скрипты на собственном DSL, подписи на каждый чих, раздельное обновление компонентов и прочий ад и Гондурас.
— образ для обновления невозможно прошить на программаторе, и для восстановления такой прошивки приходится буквально собирать ее из кусков, непрерывно матерясь.
— ну и vendor lock-in, конечно.
Некоторые отважные производители используют PFAT и у них он даже работает, но я попробовал и могу сказать — ни за какие коврижки, лучше я сделаю аудит кода SMM еще пару раз, чем это.
Про атаки на PFAT я ничего не знаю, но тут скорее всего работает правило неуловимого Джо.
5. BLE и BIOS_WE
Давным-давно, когда SMM_BWP еще не было, а у процессора было одно ядро, защита от записи в SPI-чип у Intel была организована так: есть бит BIOS_WE, который нужно уставить, чтобы чипсет позволил отправить команду на запись. Бит доступен любому коду, поэтому рядом с ним есть другой бит — BLE. Если он установлен, то установка BIOS_WE генерирует SMI, а BIOS регистрирует обработчик этого SMI, который это самый BIOS_WE сбрасывает. Софт видит, что бит сбросился и перестает пытаться писать — защита, все, нельзя. Если же прошивать из SMM, то при установке BIOS_WE прерывания не происходит (мы и так уже в SMM), и можно шить.В итоге вся защита построена на том, что BIOS добавит обработчик и SMI будет сгенерирован, поэтому для успешной атаки достаточно было забытого бита SmiLock, чтобы можно было отключить источник этого SMI и спокойно шить все, что угодно. Затем SmiLock перестали забывать и некоторые IBV даже были уверены, что защита надежная, пока на 31С3 Rafal Wojtczuk и Corey Kallenberg не показали, что на многоядерных процессорах механизм BLE/BIOS_WE уязвим к race condition, и толку от него практически ноль, т.к. атака занимает меньше 10 минут и успешна всегда.
Тем не менее, до сих пор попадаются системы, защищенные только и исключительно BLE. Это печально.
6. Отсутствующая
Хрестоматийный пример «пирожка без никто». Некоторые производители материнских плат для десктопов, не будем показывать пальцем, до сих пор не защищают прошивку от перезаписи вообще. Ваша система — вы и заморачивайтесь, никакой иллюзии безопасности мы вам не даем, только голый BIOS, только хардкор. Вести себя таким образом с каждым днем становится труднее, ведь с одной стороны давит Intel с рекомендациями, а с другой — Microsoft с HSTI, но пока справляются. Безумству храбрых, и все такое.Заключение
С защитами от прошивки более или менее разобрались, в следующей части поговорим об SMM и атаках на него.
Буду рад любым вопросам и комментариям. Спасибо за внимание.
Комментарии (51)
maseal
16.09.2015 14:32Буквально на днях прилетело для ноута обновление BIOS, где основным изменением был заявлен фикс SMM «Incursion» Attack. А до UEFI обновления на BIOS почти никогда не ставил.
CodeRush
16.09.2015 14:46+3Об этой атаке я планирую рассказать либо в следующей части, либо через одну, там нужны подробности, чтобы понять, в чем состоит уязвимость и почему ее нужно закрыть. Если не хотите ждать историю в моем изложении на русском — вот слайды с презентации наших ребят из Intel ATR на ReCon 2015, там все расписано в подробностях.
d_olex
16.09.2015 14:54+2Насколько я знаю, BootGuard сейчас используется в новых синкпадах, HP и Dell-ах, другими словами, если ты решишь купить себе приличный не-Apple ноутбук — то он там с большой вероятностью будет :) По мне это в целом хорошая, годная технология при условии что вендор не будет тупить с обновлениями безопасности: обычным потребителям патчить firmware не нужно, а для всяких параноиков, open source энтузиастов и прочих хардкорщиков — x86 это при любых раскладах днище, т.к. ME который интел сейчас всюду пихает силой является штукой куда более страшной чем хардверно верифицируемый биос.
CodeRush
16.09.2015 15:25Я не видел пока этих новых машин, но на тех, что видел, BootGuard был очень забавно настроен — сами модули присуствуют, но ни verifed boot, ни measured boot не включены, и в итоге система только выглядит защищенной. Буду обновлять железо — надо будет посмотреть.
Про МЕ — добавить мне почти нечего. Последний х86-процессор для ноутбука без PSP — eKabini, все более новые тоже имеют на борту аналог ME, который отключить еще сложнее и данных по нему еще меньше. Да и сама архитектура — далеко не мечта параноика.
d_olex
16.09.2015 15:04+2Еще интересное по поводу того кто лох а кто молодец: знакомые из Intel и MITRE говорят что если смотреть по ноутбукам — то лучше всего в плане безопасности firmware у Lenovo, а хуже всего — у Apple. С моим опытом реверс-инженеринга и эксплойтинга биосов это мнение в целом совпадает. Из моих собственных открытий — матплаты от самой Intel в плане безопасности firmware откровенные среднячки, хотя ожидал что там как-то получше все будет.
CodeRush
16.09.2015 15:39+1По моим ощущениям примерно так и есть, только вот у платформ Phoenix и Insyde, которые используют лидеры (т.е. Dell, Lenovo и HP), свои недостатки имеются, и NVRAM как разваливался, так и разваливается…
Про Apple мне сказать нечего — не интересовался, но на вид из UEFITool'а — кошмарно, think different во все поля, SecureBoot'а нет, OROMы вредоносные поют и пляшут.
Про платы Intel — она у тебя старая просто, сейчас уже очень мало кто выпускает обновления безопасности для «неактуальных» платформ — это банально дорого, т.к. все тестировать по новой.
CodeRush
16.09.2015 15:55+1Ты напиши, кстати, чего-нибудь из своего опыта, а то с этой странной кармической системой тебе даже плюс поставить невозможно.
d_olex
16.09.2015 16:14+2Писать пока что особо нечего, нужно какой-то новый ресерч сделать, все интересное что было в рабочих заметках про UEFI и SMM — я уже в бложике опубликовал.
Собрал себе недавно AMD-шный ящик что бы разобраться с тамошними механизмами защиты биоса и всякими трастзонами со SMU firmware заодно — думаю что буду в эту сторону копать.CodeRush
16.09.2015 17:11+2Сразу могу сказать почти наверняка — они там либо отключены, либо отсутствуют, мне их пришлось искать и включать специально. Всякие TrustZone и PSP — адский темные лес, документация на них в зачаточном состоянии, даже та, что под NDA, и нужно оно все это двум с половиной анонимам.
xvilka
16.09.2015 17:26+1По SMU есть вот такая штука :) github.com/zamaudio/smutool
Поддержка LM32 в radare2 будет на днях.CodeRush
16.09.2015 17:32+1Отлично, спасибо за ссылку. Я не планирую погружаться в код SMU, т.к. лучшее его состояние для меня — «работает, управляет питанием, жрать не просит». Понятно, что там тоже могут быть закладки и хотелось бы получить исходники, но пока AMD его просто так не отдает.
JerleShannara
16.09.2015 15:10+5Немного ясности про ножку #WP на SPI флешках. Она не совсем защита от записи, каковой была во времена параллельных/FWH/LPC флешек.
Разъясню подробнее:
1) SPI флешка разделена аппаратно на регионы, каждый из которых можно заблокировать на запись
2) У неё имеются свои регистры конфигурации
3) Каждый регион имеет свой бит защиты
4) Регистр, в котором лежат эти биты имеет свой собственный бит защиты
5) Пока бит защиты регистра не взведён, защиту регионов можно спокойно изменять, как только он взводится — попытки снятия бит защиты регионов становятся бесполезными.
Про бит защиты регистра битов защиты регионов флешки (масло маслянное получилось)
1) Будучи взведённым этот бит запрещает модификацию регистра защиты
2) Будучи взведённым он запрещает модификацию самого себя
Кажется, что всё отлично, блокируй регионы, далее взводи этот бит и усё хоккей. А вот и индейская народная изба фигвам:
Та самая ножка #WP какраз влияет на второй пункт, если на ней находится земля — всё окей, перевод бита защиты регистров запрещён, но если подать питание, то бит спокойно можно будет перезаписать нулём.
Почему это надо упомянуть — если реализовать защиту «классическим»(ну как во времена Pentium 2/3) путём, забив на программную часть защиты самой флешки, то никакой защиты мы не получим, регионы то не заблокированы, заблокирована только возможность сброса бита защиты регистров, который мы и не взвели.
П.С. Это именно регистры самой флешки, к чипсету они никакого отношения не имеют.
П.П.С. Действительно для продукции SST, Macronix, Winbond, с другими не работал, но у этой тройки даже адреса все совпадали, видать всё стандартно.CodeRush
16.09.2015 15:32+2Все верно, два чая этому господину. Я опустил эти подробности, и вот почему: БИОС, подготовленный для RO, при запуске проверяет биты SRP0-1 и BP0-2 в регистре STATUS и если первые оба сброшены (т.е. #WP не работает), то он ставит все BP (защитив таким образом всю прошивку целиком) и SRP0 (чтобы сбросить их можно было только установкой 1 на #WP). В итоге «незащищенным» такой БИОС, при условии #WP=0, остается ровно до инициализации драйвера SPI, а до этого ничего писать все равно невозможно.
CodeRush
16.09.2015 16:08+5Предложу то же самое, что и d_olex'у — напиши что-нибудь из своего опыта, а то хочу поставить плюс в карму — и не могу.
Уважаемое НЛО, я все понимаю, но ситуация, когда карму можно только понизить — отвратительна, и мотивирует она не на написание постов, а на игнорирование Хабра. Сделайте с этим что-нибудь, пожалуйста.
mark_ablov
16.09.2015 18:36+2Я еще и удивлён что твой пост тут, а не на GeekTimes ;)
CodeRush
16.09.2015 18:42+1Тамошнюю аудиторию такие посты только испугают зазря. :)
grossws
16.09.2015 18:44+2Но при этом низкоуровневое не-PC старательно уносят туда, к сожалению.
CodeRush
16.09.2015 18:47+3Я тоже этого не понимаю совершенно. Сейчас все программное, черт возьми, декодер кодов операций в x86 программный уже лет десять, и давно уже невозможно отделить железо от софта, но нет, все хоть немного железное — на ГТ, к обзорам часов и браслетов.
Ivan_83
16.09.2015 20:35Я считаю что все эти защиты не нужны:
— хватило бы по старинке джампера на плате
— ОС должна сама разделять: кому можно писать в БИОС а кому нельзя.
— должна быть возможность аудита кода/бинарников биос.
Вот эта вся истерия вокруг защиты биосов она всецело из за дырявости ОС.
Если мы не доверяем ОС, и считаем что она что то сделает с БИОС, то на кой хер вообще её ставить, будто кроме БИОС в системе ничего ценного нет и закрепится больше негде.
И такой случай прекрасно решается через аппаратный джампер.
Меня больше беспокоит то что ремонтопригодность уменьшается, уменьшается количество доступных крутилок, вводятся белые списки железок, отключаются фичи типа AES-NI в угоду маркетингу — всё через запрещение модификации БИОС.
Вот это всё меня куда больше задевает, чем возможность что кто то в теории может что то сделать с БИОС без моего ведома. Опять же аппаратный джампер решил бы эту проблему.
Проблема физического доступа не решается ни разу никакими вшитыми в кремний ключами, хотя бы потому что всегда можно различные аппаратные сниферы и прочие аппаратные закладки.CodeRush
16.09.2015 21:00Джампер можно реализовать, и прямо в статье написано, как именно, но этого никто не делает — в текущих условиях это дорого и мало кому нужно.
Если вас защита задевает — покупайте продукты без нее, их море. Только вот доверять ОС, которая, в основном, написана вполне средними программистами 10+ лет назад на С или С++ — решительно невозможно.
Проблема защиты от физического доступа — административная, а не системная, и ключи в кремнии решают не проблему «злой хакер Семен сменил все чипы, и таким образом отключил защиту», а «измененный злым хакером Семеном образ БИОСа не запустился вообще»
Если говорить про аппаратные закладки и т.п., то единственный выход — свободное железо. OpenRISC, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.
d_olex
16.09.2015 23:04+2Если мы не доверяем ОС, и считаем что она что то сделает с БИОС, то на кой хер вообще её ставить
Security history абсолютно всех без исключения ОС имеющих распространение в настоящий момент неадекватна совершенно, как можно доверять тому, в чем каждый год находят десятки и сотни критических уязвимостей и проблем безопасности?
Alexeyslav
17.09.2015 10:20Проблема в том что у нас раньше был SRAM для настроек и отдельно чип EEPROM для кода биосА, запрещаешь запись во второй аппаратно и ништяк. Но… маркетологи решили зачем нам две микросхемы давайте удешевим и поставим одну! И понеслось… в одном чипе теперь хранятся и программные коды и переменные настройки. Теперь получается что поставить защиту чисто на чип уже нельзя — код мы защитим но и сделаем невозможным запись настроек. Дальше защита пошла уже программная — устанавливаются биты защиты от записи для отдельных областей памяти чипа… но это уже не то что механический джампер на плате.
navion
16.09.2015 22:35Некоторые производители материнских плат для десктопов
Зато Intel выпускает обновления даже для снятых с производства Desktop Boards.
egyp7
17.09.2015 15:02+1CodeRush спасибо за содержательную статью. Сложный материал подан весьма просто, а шутки(понравилось про DoS с отвётверткой) в тексте делают его более выразительней. Странно что никто в коментариях не вспомнил про EDK vector от Hacking Team — uefi бэкдор-прошивку на базе tianocore. В любом случае будет интересно прочитать продолжение.
PS.: надеюсь в следующей статье вы затронете несколько паблик векторов в PoC, которые доступны в настоящее время :)CodeRush
17.09.2015 15:19+3Затрону, конечно, но не сразу, сначала надо рассказать, что атакуют, а потом уже — как.
Про бэкдор 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.
TheDaemon
18.09.2015 23:19Спасибо, отличная статья :)
Только, по-моему EC — это Embedded Controller, а не Environmental Controller (например мы используем какой-то Nuvoton, типа NPCE791E)
Это честно не реклама, просто рассказываю про технику вопросаКстати, для более серьезных применений, есть специальные мамки, например:
www.kraftway.ru/products/6/tonkie-klienty/kraftway-credo-vv25/#characteristics (есть и другие, даже планшет и сервер :) )
Если приглядеться в данной мамке есть АПМДЗ «Криптон-витязь» (детище фирмы Анкад). Это микроконтроллер, который управляет всеми питаниями материнки, аутентфицирует пользователей и т.д, а еще он мониторит линии SPI и позволяет разрешать/запрещать запись с гранулярностью 32 бита.
А еще у него две SPI флешки и он может сначала подставлять свою, полностью защищенную от записи, в которой есть все для аутентификации (CoreBoot + Qt) после которой происходит перезагрузка и подставляется настоящий UEFI. Поэтому он может сделать любую политику разрешения/запрета записи любых регионов флешки.CodeRush
18.09.2015 23:35Я использую старую расшифровку аббревиатуры EC, т.к. сейчас слово embedded уже настолько везде, что практически потеряло значение. А так — сразу понятно, чем занимается EC — температуры меряет и вентиляторами управляет.
TheDaemon
18.09.2015 23:46Кстати, его прошивка далеко не всегда в той же флешке, что и UEFI. Бывают с собственной флешкой. А еще он много чего может кроме измерений температуры, например DMA куда-нибудь через LPC, так что довольно опасная для атак штука.
CodeRush
18.09.2015 23:51+1Намного лучше, когда он с собственной флешкой, т.к. в таком случае через него невозможна атака на ее содержимое. Я знаю, что EC — та еще гадость в смысле безопасности, но крипточип с закрытой прошивкой, как в вашем примере выше, тоже не очень-то располагает к безграничному доверию. Мы используем в качестве BMC обычный ARM Cortex M4 производства Texas Instruments, подключенный через LPC, и прошивку для него мы написали сами, поэтому я уверен, что в ней нет ни бэкдоров, ни каких-то посторонних возможностей.
TheDaemon
18.09.2015 23:57Все правильно. Мы тоже написали сами и поэтому ей верим, а заказчики верят, потому что нашу прошивку сертифицровали в ФСБ, где ее исследовали на закладки и уязвимости в течение полу года, а заказчики верят ФСБ. Но, конечно, каждый конкретный пользователь сам для себя решает кому верить, а кому нет. Если что, прошивку этого чипа можно также как UEFI слить через программатор (или даже через USB, если есть права, но мы же не верим тому, какой вариант себя она выдаст) и исследовать :)
CodeRush
19.09.2015 00:09Это хорошо, что прошивку можно слить и исследовать, а то обычно залочат фьюзами и все. Если клиенты доверяют — это хорошо. Нам тоже доверяют пока, но у нас BMC никаких функций безопасности не выполняет, таким было требование большинства клиентов в самом начале, чтобы не допустить side channel атак через него.
JerleShannara
21.09.2015 04:46Про вашу «не рекламу» — стёба ради допроситесь к крафтвею на экскурсию, интересно просто, какое число «разработчиков биоса, которые у них трудятся» они вам скажут.
П.С. На сегодняшний день только один АПМДЗ умеет в UEFI, все остальные работают только в CSM-е. Что это означает для устройства защиты я пожалуй говорить не буду, а то на ум приходит только слово из пяти букв, начинающееся на х.
П.П.С. На всяких новых электрониках всё, что показывал крафтвей шло без анкада.TheDaemon
21.09.2015 10:13Я лично знаком с большинством разработчиков Крафтвея, там есть очень грамотные ребята. Они не скрывают, что на самом деле они не разрабатывают целиком биос, они только допиливают AMI'шный и пишут модули под него. А также они провели сертификацию этого биоса в ФСБ, что довольно дорогостоящий и длительный процесс.
Только один — это какой? У Анкада таких минимум два :) (правда только один сертифицирован, второй в процессе)
На всех выставках Крафтвей действительно позиционирует мамки как будто Анкад тут не при чем. В политику я стараюсь не лезть, но меня это тоже неприятно удивляет.CodeRush
21.09.2015 10:29+1Скрывать факт работы с IBV глупо — тайна продержится до первого дампа. :)
Насчет сертификации в ФСБ — там же BLOB'ов штук десять как минимум, CSM16, куча расширений к нему, OROM'ы, драйвер PXE, драйвер SATA, драйвер ФС FAT и т.п., неужели пришлось у AMI исходники покупать, или прямо бинарем и сертифицировали? Я не очень разбираюсь во всей этой кухне (и не очень хочу, если честно), но со стороны кажется, что в «сертификации в ФСБ» больше бумажной работы, чем инженерной.TheDaemon
21.09.2015 10:371) Да, куплены исходники всего, так что Крафтвей хорошо вложился в это дело.
2) У ФСБ методика исследований строится на бинарниках, а исходники используются только как помощь. Там действительно множество спецов, копаются в бинарниках и пишут документацию. Поэтому сертификация UEFI стоит больших денег и занимает минимум год.egyp7
21.09.2015 15:44Странный вопрос, но все же задам. Зачем ФСБ собственно ковыряться в бинарях когда на руках есть сорсы?
Можно ведь собрать из сорсов билд и задиффать к примеру с оригиналом, посмотреть что изменилось.
Это по теме трудозатрат(временных и денежных издержек) было сказано в первую очередь.JerleShannara
21.09.2015 18:04А как ФСБ получит все исходники скажем на новый интеловский сервер?
egyp7
22.09.2015 09:56Вероятно ваше замечание право, однако выше речь шла о том, что исходники используются как помощь при реверсе бинарей, т.е предположительно они существуют.
Слышал также что после инцидента со Stuxnet многие спецслужбы стали более внимательно относиться к иностранному оборудованию(для особоважных объектов страны) и ПО для него. Для ПО обычно требуют сорсы под NDA, для железа вероятно тоже(требуют помимо даташита исходный код для железа(Verilog/HDL/VHDL/SystemC/и т.п)). Возможно я где то не прав, если что поправьте.TheDaemon
22.09.2015 11:02+3На то есть несколько причин, некоторые технические, некоторые исторические:
1) Действительно, не всегда бывают исходники.
2) Часто исходники собираются компилятором, от которого нет исходников или который никто не исследовал.
3) Существует множество способов спрятать закладку в исходниках так, чтобы при простом их чтении ее было очень сложно найти, например, использовать особенности оптимизатора или архитектуры.
4) В плане поиска сложных закладок или дырок динамический анализ гораздо круче статического, а он, как правило, работает с бинарниками.
Отличия статического и динамического анализаЕсли упрощенно, то статический анализ — это «ничего обо всем», а динамический — это «все ни о чем», т.е. в статическом анализе сложно обеспечить глубину анализа, зато он покрывает исходник целиком, а в динамическом анализе сложно обеспечить покрытие, но он позволяет обнаруживать очень сложные закладки/баги/дырки. Статический анализ, обычно, работает с исходником, а динамический с бинарником (часто != всегда).
JerleShannara
21.09.2015 14:12А у анкада они все CSMные. А тот, что умеет в UEFI, сделан не анкадом =)
Грамотные ребята там есть, это я не спорю, но когда тебе заявляют, что у них одним биосом занимаются 50 профессионалов именно по БИОСу, начинаешь думать, как они умудрились всех БИОСников по стране к себе заманить?TheDaemon
21.09.2015 15:43Ваша информация не соответствует действительности.
Дело в том, что я работаю в Анкаде и лично занимаюсь разработкой этих замков. Сейчас мы сосредоточились на том, что делаем интегрированные в матери замки, которые позволяют противостоять гораздо большему набору угроз. И они работают без CSM'а. Вся оболочка у них выполнена в виде модулей UEFI.
Все сертифицированные нами PCI'ные замки действительно CSM'ные. На то есть причины, связанные с безопасностью, и эта статья отлично описывает одну из них. Технически, PCI замок без CSM'а у нас давно есть, другое дело, что он никому не нужен и поэтому мы его не стремимся сертифицировать и выводить на рынок.
Неужели вы думаете, что это требует серьезных телодвижений? Единственное, что нужно, чтобы интегрированный на мамку замок стал PCI'ным — добавить UEFI'шный OptionROM.
Про 50 разработчиков я ни разу от них не слышал, так что ничего ответить на это не могу. Может быть человек не правильно понял ваш вопрос или вы его ответ?JerleShannara
21.09.2015 17:5550 разработчиков было сказано на вопрос «а сколько спецов у вас на разработку вашего защищенного бивиса идёт».
Про апмдз — МАКСИМ-М1. Сертификат есть, умеет в UEFI и обычный режим. Что мешает в новой версии замка сделать оптром для UEFI — я не знаю. Насчёт никому не нужен — пардоньте, сейчас купить что-либо не UEFI уже нереально, и те, кому нужен ампдз (а мы с вами понимаем, кому оно надо, если сертификат) уже просто никуда не денутся от этого, а запускать защиту через эмуляцию — это извращение, причём полное.TheDaemon
21.09.2015 19:14Я вам могу ответить, почему нам не очень интересно тратить деньги на сертификацию PCI'ных замков.
1) Для их эксплуатации требуется материнка и UEFI, исследованные в ФСБ, а их выбор (если говорить о современных платформах) сильно ограничен. Поэтому большинству заказчиков все равно покупать только замок или замок + материнку. Но интегрированное решение обеспечивает значительно больший уровень безопасности. В контексте данной статьи отличный пример — защита SPI флешки.
2) Многие переходят на тонкие клиенты, а чем меньше в них плат, тем они «тоньше».
3) Многим интересны мобильные платформы, т.е. ноутбуки и планшеты (да, их мы тоже разработали).
Как только найдется заказчик, которому потребуется сколько-нибудь крупная партия именно PCI'ных замков с поддержкой UEFI мы получим сертификат и будем им торговать.
datacompboy
Не хватает сводной таблицы в итоге.
Исследование омномном, спасибо!
CodeRush
Пожалуйста, спасибо, что читаете.
Таблица сводная будет после того, как я опишу все защиты и атаки, которые имею право описывать.
Godless
Простите, не могу не спросить. А много того, что НЕ можете описывать?
CodeRush
Нет. Некоторые атаки обнаружены всего пару недель назад, и потому пока не могут быть опубликованы, т.к. для 99% пораженных систем еще не вышли обновления.
Godless
А, ну если только в этом ключе, тогда все понятно. Спасибо.