16.11 // Инфицирование загрузчика для обхода шифрованных файловых систем
Месяц назад, 16 октября, Joanna Rutkowska опубликовала практическую демонстрацию атаки на системы с полнодисковым шифрованием, которая была известна и ранее, но не была публично продемонстрирована. В качестве демонстрации был использован компьютер, диск которого зашифрован с помощью Truecrypt (несложно создать версии и против других программ шифрования).
Атака "злонамеренной уборщицы" практически выглядит так: в отсутствие свидетелей злоумышленник загружает компьютер жертвы с USB-флэшки, которая в течении максимум пары минут производит все необходимые операции по инфицированию загрузчика. Инфицированный загрузчик перехватывает пароль, введённый пользователем на расшифровку операционной системы и может сохранить его в другой части диска или переслать по сети.
После похищения пароля загрузчик можно вернуть в исходное состояние, чтобы замести следы вторжения (если потратить немного больше времени, то можно скопировать и всё содержимое винчестера в зашифрованном виде, так что если его владелец и сменит пароль позднее — это будет уже неактуально, так как пароль к старой версии содержимого уже будет получен).
Атака похожа на ранее продемонстрированную Stoned boot attack, отличаясь лишь тем, на каком этапе работы системы внедряется троян.
Также есть сходство с атаками с холодной перезагрузкой или использованием аппаратных перехватчиков паролей.
По комментариям PGP corp полной защиты от атак такого рода не существует.
Использование технологии "Trusted computing" опирается на проприетарные решения и доверие к закрытым аппаратным решениям от корпораций. Кроме того, как считает Joanna Rutkowska, в экстремальном случае высокооснащённый противник (АНБ) может подменить процессор и платы памяти.
Если отбросить вмешательство в аппаратную часть, то относительно простым решением может быть использование двухфакторной аутентификации — использование собственного загрузчика с USB-флэшки или компакт-диска, которые противник не может подменить. Эти загрузчики могут проверять хэш незашифрованной части диска или полностью загружать операционную систему.
Однако, следует помнить об общем принципе — невозможно быть уверенным в надёжности защиты при дальнейшей работе пользователя с зашифрованной информацией на компьютере после того как противник имел к нему физический доступ.
Как отмечает в комментариях в своём блоге Брюс Шнайер — многие пользователи вероятно ошибочно оценивают уровень защиты, предоставляемый средствами шифрования, фактически он сводится к защите информации при конфискации или похищения компьютера или носителей данных, но не защищает против активных атак.
Источник: Joanna Rutkowska Invisible Things Blog
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 105 документов: 20 редакций: 3
комментариев: 11558 документов: 1036 редакций: 4118
Если загрузчик PGP нормально отнесётся к таким манипуляциям, то почему бы и нет. Только, опять же, это оградит от вмешательства в код загрузчика и его подмены, но не от атак на БИОС и аппаратную составляющую.
...и прочие улавливатели побочных излучений.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 105 документов: 20 редакций: 3
согласен. но планка (стоимость взлома) все-таки поднимется.
Интересно, а можно ли имея загрузчик на внешнем носителе встроить в него проверку целостности биоса? Типа, прочитать его бинарный код, взять от него хэш и сравнить его с хэшем девственного биоса?
правда тут же возникает вопрос: "где гарантии того, что в день нуль биос не содержал закладок"? Но даже при отсутствии гарантий мероприятие будет полезным, т.к. позволит бороться хотя бы с одной ветвью угрозы – модификацией биоса после дня нуль.
Где гарантии того, что мы прочитали действительно код BIOS, а не то, что нам хочет показать хитрый руткит?. И где гарантии того, что код проверки целостности не был изменен BIOS'ом так, чтобы вражеский BIOS проходил проверку.
комментариев: 105 документов: 20 редакций: 3
гарантий нет, действительно, по крайней мере на первый взгляд
код проверки по условиям игры находится на внешнем носителе и м.б. вообще защищен от перезаписи. Поэтому можно говорить только об изменении кода программы проверки, загруженной в ОЗУ для выполнения.
Но это выглядит сложновато, ведь программ проверки целостности биоса м.б. много, и злостный биос должен уметь производить анализ исполняемого кода, обнаруживать признаки анализатора целостности (по сигнатурам или эвристически, как антивирус видимо) и уметь динамически его же править, причем так чтобы пользователь ничего не заметил.
Кроме того, хороший загрузчик (или воображаемый загрузчик-валидатор биоса), и это отмечалось и на сайте Рутковска, должен уметь контролировать целостность самого себя. Ведь Skype это делает, и давольно эффективно! Нужно перенять опыт...
видится и другое возможное решение: нужна доверенная аппаратная платформа для хранения и исполнения кода загрузчика-валидатора. Например что-то типа того же криптографического брелка Aladdin. Своя память, свой процессор. Никакой виртуализации. Можно вообще образ биоса хранить там и при каждой загрузке ПК переписывать его с брелка на машину.
все равно останется угроза аппаратных закладок конечно. это похоже тот самый лом... или нет?
Я это и имел ввиду.
На процессорах с поддержкой аппаратной виртуализации это не проблема, на более старых будем использовать динамическую трансляцию кода их исходников qemu. Это что касается обхода проверок чтением ОЗУ. Ну а чтение flash через порты эмулируется легко и непринужденно через SMM/VMX.
Написание такого руткита – это уровень хорошего программиста-системщика, бюджет проекта $10-$30к, в зависимости от числа поддерживаемых чипсетов и типов процессоров.
И проверять ему придется свой BIOS, потому как доступ к памяти компа возможен только через CPU.
Ой ли? А кто будет решать можно или нельзя запускать эту конкретную прошивку? Ясен пень, что не пользователь. Вы доверяете корпорациям, основная цель которых – получение прибыли?
Админ будет решать. Так же, как сейчас он решает какой софт должен иметь какие права в ОС.