Ее и на современных роутрах часто нет.
В энтерпрайзной среде почему-то считается, что проблемы безопасности прошивок — 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, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.
Я тоже этого не понимаю совершенно. Сейчас все программное, черт возьми, декодер кодов операций в x86 программный уже лет десять, и давно уже невозможно отделить железо от софта, но нет, все хоть немного железное — на ГТ, к обзорам часов и браслетов.
Отлично, спасибо за ссылку. Я не планирую погружаться в код SMU, т.к. лучшее его состояние для меня — «работает, управляет питанием, жрать не просит». Понятно, что там тоже могут быть закладки и хотелось бы получить исходники, но пока AMD его просто так не отдает.
Сразу могу сказать почти наверняка — они там либо отключены, либо отсутствуют, мне их пришлось искать и включать специально. Всякие TrustZone и PSP — адский темные лес, документация на них в зачаточном состоянии, даже та, что под NDA, и нужно оно все это двум с половиной анонимам.
Предложу то же самое, что и d_olex'у — напиши что-нибудь из своего опыта, а то хочу поставить плюс в карму — и не могу.
Уважаемое НЛО, я все понимаю, но ситуация, когда карму можно только понизить — отвратительна, и мотивирует она не на написание постов, а на игнорирование Хабра. Сделайте с этим что-нибудь, пожалуйста.
По моим ощущениям примерно так и есть, только вот у платформ Phoenix и Insyde, которые используют лидеры (т.е. Dell, Lenovo и HP), свои недостатки имеются, и NVRAM как разваливался, так и разваливается…
Про Apple мне сказать нечего — не интересовался, но на вид из UEFITool'а — кошмарно, think different во все поля, SecureBoot'а нет, OROMы вредоносные поют и пляшут.
Про платы Intel — она у тебя старая просто, сейчас уже очень мало кто выпускает обновления безопасности для «неактуальных» платформ — это банально дорого, т.к. все тестировать по новой.
Все верно, два чая этому господину. Я опустил эти подробности, и вот почему: БИОС, подготовленный для RO, при запуске проверяет биты SRP0-1 и BP0-2 в регистре STATUS и если первые оба сброшены (т.е. #WP не работает), то он ставит все BP (защитив таким образом всю прошивку целиком) и SRP0 (чтобы сбросить их можно было только установкой 1 на #WP). В итоге «незащищенным» такой БИОС, при условии #WP=0, остается ровно до инициализации драйвера SPI, а до этого ничего писать все равно невозможно.
Я не видел пока этих новых машин, но на тех, что видел, BootGuard был очень забавно настроен — сами модули присуствуют, но ни verifed boot, ни measured boot не включены, и в итоге система только выглядит защищенной. Буду обновлять железо — надо будет посмотреть.
Про МЕ — добавить мне почти нечего. Последний х86-процессор для ноутбука без PSP — eKabini, все более новые тоже имеют на борту аналог ME, который отключить еще сложнее и данных по нему еще меньше. Да и сама архитектура — далеко не мечта параноика.
Об этой атаке я планирую рассказать либо в следующей части, либо через одну, там нужны подробности, чтобы понять, в чем состоит уязвимость и почему ее нужно закрыть. Если не хотите ждать историю в моем изложении на русском — вот слайды с презентации наших ребят из Intel ATR на ReCon 2015, там все расписано в подробностях.
Все это здорово, но простому энтузиасту недоступно.
Стоитмость XDP3 — около 3 тыс. долларов, лицензия на год использования System Studio — еще две, а в результате получаем отладочную платформу, которая не нужна даже при разработке прошивки и bare-metal OS, ибо там хватает Port80h-кодера и одного UART'а.
Если из статьи слить воду и убрать «Сомалийские острова», ее можно сократить примерно втрое.
Кому действительно нужно писать свой парсер PE32 — обратите внимание на открытую реализацию в radare2.
Там будет слишком специфично для конкретного процессора даже внутри одной архитектуры. Вот тут есть немного, но почти без деталей, плюс в память отображается далеко не все, очень многое по прежнему реализовано только через CPU IO и PCI IO.
Добавлю к написанному там, что 0xC0000000 — это TOLUD = 3Gb, популярное значение по умолчанию, но иногда его дают перенастроить через BIOS Setup.
Такую аппаратную защиту можно сделать и сейчас, ничего не мешает, только вот спроса на нее практически нет — никому снова нет дела до безопасности прошивки, а две микросхемы SPI (чтобы разделить изменяемые части вроде регионов GbE, ME и NVRAM от собственно региона BIOS) ставить дороже, чем одну. Более того, система с RO-прошивкой все равно подвержена эксплуатации через уязвимости в S3 и SMM, только приподит она не к персистентности, а «всего лишь» к повышению привелегий до уровня SMM-кода, что тоже весьма неплохо.
Что дейсвтительно надо сделать, так это, во-первых, планомерно уменьшать attack surface путем выкидывания из прошивки всего лишнего (а не добавления всего отдаленно показавшего нужным, как происходит сейчас), а во-вторых — проводить аудит, проверять и перепровеять прошивку перед выпуском. И если со вторым еще более-менее неплохо стало в последнее время (Chipsec, LUV, FWTS, HSTI, вот это все), то с первым у EFI и всей индустрии большие проблемы, которые никто не спешит решать.
Все это возможно только потому, что производители оборудования для конечного пользователя не видят никакой необходимости заботиться о безопасности своих EFI-совместимых прошивок, в результате ошибки, обнаруженные пару лет назад, на большинстве систем так и не исправлены, а о новых и говорить нечего. К примеру, представленная на 31C3 в декабре 2014 атака на S3 BootScript (а именно ее использует упомянутый в статье червь) все еще работает на подавляющем большинстве систем с EFI/UEFI.
По настоящему безопасностью UEFI займутся только тогда, когда атаки на него выйдут из PoC-песочницы (момент уже очень близок), либо когда Intel и MS перестанут сертифицировать продукты, не проходящие валидацию Chipsec'ом и тестирование HSTI. Пока не произошло ни то, ни другое, поэтому нужно либо пользоваться системами тех, кому «не пофиг», вроде Dell или HP, либо брать безопасность в свои руки и все патчить самостоятельно. Про второй вариант я попробую рассказать на конференции ZeroNights 2015, если доклад одобрят.
Если обновление будет Win 7 Home на Win 10 Home (то самое «бесплатное»), но BitLocker и не появится, т.к. в Win 10 Home его по прежнему нет.
На самом деле, использовать его все равно смысла нет (если это не корпоративная политика), т.к. криптография с закрытым кодом порочна по сути, а если уж совсем невмоготу — есть TCnext и другие проекты. Более того, если не использовать для вкхода в систему Microsoft Account, то ключ не отправляется автоматически, а предоставляется выбор из трех вариантов: отправить в OneDrive, сохранить на диске или распечатать на принтере, что уже намного лучше.
В энтерпрайзной среде почему-то считается, что проблемы безопасности прошивок — overhyped, и потому не стоят внимания. Тот факт, что прошивку подавляющего большинства железок, кроме совсем уж экзотических, можно банально слить программатором и дизассемблировать в radare2, а потом залить куда-нибудь в свободное место шеллкод и собрать обратно — это давно уже не ракетная наука, до людей, принимающих решения просто не доходит. И не будет доходить, пока модуль по внедрению не добавят в Metasploit, но и тогда, возможно, они скажут, что надо лучше защищать сервера от физического доступа и такие бэкдоры — единичный случай и капля в море.
Гром не грянет — мужик не перекрестится, традиционно.
Про бэкдор HT не вспомнили по причине его примитивности. Понятно, что задачу свою он выполняет, но лучше, чем ThrDev, я о нем, наверное, не скажу.
Если вас защита задевает — покупайте продукты без нее, их море. Только вот доверять ОС, которая, в основном, написана вполне средними программистами 10+ лет назад на С или С++ — решительно невозможно.
Проблема защиты от физического доступа — административная, а не системная, и ключи в кремнии решают не проблему «злой хакер Семен сменил все чипы, и таким образом отключил защиту», а «измененный злым хакером Семеном образ БИОСа не запустился вообще»
Если говорить про аппаратные закладки и т.п., то единственный выход — свободное железо. OpenRISC, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.
Уважаемое НЛО, я все понимаю, но ситуация, когда карму можно только понизить — отвратительна, и мотивирует она не на написание постов, а на игнорирование Хабра. Сделайте с этим что-нибудь, пожалуйста.
Про Apple мне сказать нечего — не интересовался, но на вид из UEFITool'а — кошмарно, think different во все поля, SecureBoot'а нет, OROMы вредоносные поют и пляшут.
Про платы Intel — она у тебя старая просто, сейчас уже очень мало кто выпускает обновления безопасности для «неактуальных» платформ — это банально дорого, т.к. все тестировать по новой.
Про МЕ — добавить мне почти нечего. Последний х86-процессор для ноутбука без PSP — eKabini, все более новые тоже имеют на борту аналог ME, который отключить еще сложнее и данных по нему еще меньше. Да и сама архитектура — далеко не мечта параноика.
Таблица сводная будет после того, как я опишу все защиты и атаки, которые имею право описывать.
Стоитмость XDP3 — около 3 тыс. долларов, лицензия на год использования System Studio — еще две, а в результате получаем отладочную платформу, которая не нужна даже при разработке прошивки и bare-metal OS, ибо там хватает Port80h-кодера и одного UART'а.
Кому действительно нужно писать свой парсер PE32 — обратите внимание на открытую реализацию в radare2.
Вот тут есть немного, но почти без деталей, плюс в память отображается далеко не все, очень многое по прежнему реализовано только через CPU IO и PCI IO.
Добавлю к написанному там, что 0xC0000000 — это TOLUD = 3Gb, популярное значение по умолчанию, но иногда его дают перенастроить через BIOS Setup.
Что дейсвтительно надо сделать, так это, во-первых, планомерно уменьшать attack surface путем выкидывания из прошивки всего лишнего (а не добавления всего отдаленно показавшего нужным, как происходит сейчас), а во-вторых — проводить аудит, проверять и перепровеять прошивку перед выпуском. И если со вторым еще более-менее неплохо стало в последнее время (Chipsec, LUV, FWTS, HSTI, вот это все), то с первым у EFI и всей индустрии большие проблемы, которые никто не спешит решать.
По настоящему безопасностью UEFI займутся только тогда, когда атаки на него выйдут из PoC-песочницы (момент уже очень близок), либо когда Intel и MS перестанут сертифицировать продукты, не проходящие валидацию Chipsec'ом и тестирование HSTI. Пока не произошло ни то, ни другое, поэтому нужно либо пользоваться системами тех, кому «не пофиг», вроде Dell или HP, либо брать безопасность в свои руки и все патчить самостоятельно. Про второй вариант я попробую рассказать на конференции ZeroNights 2015, если доклад одобрят.
На самом деле, использовать его все равно смысла нет (если это не корпоративная политика), т.к. криптография с закрытым кодом порочна по сути, а если уж совсем невмоготу — есть TCnext и другие проекты. Более того, если не использовать для вкхода в систему Microsoft Account, то ключ не отправляется автоматически, а предоставляется выбор из трех вариантов: отправить в OneDrive, сохранить на диске или распечатать на принтере, что уже намного лучше.