Комментарии 18
Дайте угадаю, в пачке мест в битлокере есть что-то типа useKey() { memcpy(); decrypt(); memset(); }, благодаря чему ключ остаётся в памяти... Как сказал бы @Andrey2008, "надо было пользоваться PVS-Studio" :D
Очень может быть :) Ссылка для тех, кто не знает, про что речь :) Этого очень много везде.
Если убрать хиханьки, то что вы предлагаете? Во время работы Windows ключ остаётся в памяти, потому что его нельзя оттуда убирать. Вы же как-то должны шифровать данные, которые пишутся на диск.
Ключ таки должен быть эфимерным и жить в памяти минимальное время, чтобы поиск его превращался в поиск иголки в стоге сена.
Так же говорили про power glitch, что с ней ничего нельзя сделать, питание может пропасть в любой момент и так далее. Ничего, архитектура и структура кристаллов с защитой от ГП все шире и шире употребляется, и это очень даже не дорого.
По моему опыту, максимального успеха можно добиться, перезагружая систему, когда Windows ещё загружается, но не достигла экрана логина
Я правильно понимаю, что когда Bitlocker настроен на использование внешнего ключа на флэшке, а не только TPM, и этот ключ атакующему недоступен, - описанная в статье методика имеет не особо большие шансы сработать?
По идее симметричный ключ, используемый на лету для фактической шифровки-дешифровки, должен существовать в памяти вне зависимости от того, кто его порождал или что использовалось для дешифровки его с диска.
Если само шифрование каждого сектора не происходит где-то в отдельном чипе.
Но если для формирования ключа нужен внешний фактор (ключевой файл, ПИН-код), то он будет существовать в памяти только после первой перезагрузки. И, таким образом, у атакующего (а) всего одна попытка и (б) эту попытку нельзя осуществить в тот самый удобный момент, который назван в статье.
Кроме того, если про существование внешнего фактора атакующему неизвестно заранее, он вообще может упустить этот свой единственный шанс.
Ну и в довершение - если для загрузки с внешнего носителя нам надо сначала обойти пароль на BIOS и/или Secure Boot - то пока мы с этим возимся, память точно очистится, а второго шанса у нас нет.
(Ключ на флешке | пароль пользователя | TPM) - в дальнейшем условимся называть это ключом пользователя - не используются для непосредственного шифрования данных на диске (по ряду причин, одна из которых - при любой необходимости изменить пароль, пришлось бы перешифровывать всё содержимое).
Вместо этого при шифровании диска/раздела сначала генерируется невидимый для пользователя (в VC его можно посмотреть, но зачем?) стойкий ключ (условимся называть его ключом шифрования данных), им шифруются данные на накопителе, а уже этот ключ шифрования данных шифруется ключом пользователя.
Когда вы вводите ключ пользователя, он расшифровывает ключ шифрования данных и стирается из памяти (за исключением отдельных случаев*, когда разработчик допустил ошибку - я всё хочу перевести эту статью, но, боюсь, не осилю). Ключ шифрования данных дальше используется для расшифровки имеющихся данных и для шифрования того, что будет записано на накопитель в ходе сеанса. Поэтому он висит в памяти. Соответственно, появляется соблазн принудительно перезагрузить и поискать в памяти, что там могло остаться - совершить cold-boot attack.
Оффтоп
Ситуация осложняется тем, что ключи, которыми майки подписываю свои загрузчики и загрузчики третьих сторон (линуксовые загрузчики и, например, прошивки видеокарт) для работы Secure Boot в следующем году отметят своё 15-летие и протухнут. Так что нас всех ждёт обновление ключей (и отзыв старых, т.к. это единственная возможность закрыть описанную уязвимость с даунгрейдом загрузчика), сопряжённое с надеждой, что прошивки материнских плат реализованы на должном уровне и корректно это обновление ключей переживут. Что, разумеется, не так (и нас ждёт немало высеров в интернете вида "я сбросил настройки мамки на дефолт и теперь Windows больше не запускается, во всём виноват клятый Былгейтц!!1" и "майки запретили загружать Windows 8 и Windows 10 эта загавор!!!1").
А если вы человек впечатлительный, то не заглядывайте в то, что у вашей мат. платы "из коробки" зашито в db и KEK, потому что вендор вашей мамки мог иметь весьма специфичное представление о том, чего там должно быть (например, Asus пихает туда старый отозванный ключ Ubuntu, чтобы старые убунты могли грузиться, хотя разработчики Ubuntu неоднократно просили этого не делать). Для себя я уже давно пришёл к тому, что зачищаю то, что там навертел вендор, и загоняю ключи, рекомендованные Microsoft.
По этому поводу нужна отдельная статья, которая тоже ждёт своего героя.
По моему опыту, максимального успеха можно добиться, перезагружая систему, когда Windows ещё загружается, но не достигла экрана логина
Поясните, пожалуйста, почему так. Извлекаются ключи, которые система оставила в памяти в момент их получения? Или они остаются в процессе работы системы (условно через час и более после запуска)? Если первое, то дополнительный pin до запуска системы защищает от подобного? Иначе даже с pin опасно оставлять windows заблокированным на уровне учетной записи, нужно полностью выключать, когда отходишь.
Ключ остаётся в памяти в процессе работы системы, чтобы можно было что-то писать на диск (т.к. новые и изменённые данные нужно шифровать при записи).
PIN вам не поможет, т.к. атака заключается в "перезагружаем принудительно и тут же каким-то образом копаемся в памяти". Тем не менее, без PIN, ключевого файла (т.е. если разблокировка полностью полагается лишь на TPM) или без отзыва старого сертификата Microsoft вы уязвимы к другой атаке.
Таким образом, да, либо выключать компьютер, либо в прошивке мамки установить пароль на запуск (не только на вход в настройки прошивки), обычно это называется как-то наподобие "Security Password: System". Хотя и этот способ не даёт 100% гарантии.
Как уже выше упомянули этот способ бесполезен если UEFI залочен паролем (нужно доп. включить защиту от сбрасывания). В таком случае загрузиться с USB флешки не получится, secure boot отключить тоже
Единственное что остается это сделать дамп подключившись параллельно к ОЗУ на аппаратном уровне. Но не уверен, есть ли рабочие примеры
ps. в реальности будут использовать паяльник
ps. в реальности будут использовать паяльник
На 1 случай использования паяльника - 1000 случаев "изъяли, увезли, потом отдали в экспертно-криминалистическую лабораторию, вытягивайте там данные как хотите, не вытянете ничего - ну и фиг с ним". И поэтому программа-минимум, которой в большинстве случаев достаточно для обычного бизнеса, - защититься от такого сценария. Эксперты вполне могут инструментами типа описанных в статье владеть, а также чудо-чемоданчиками от Cellebrite и его импортозаместителей... но прямо упарываться с индивидуальным подходом, разборкой/пайкой/заморозкой тоже в 99% случаев никак не мотивированы.
Но и тогда атакующий сможет, например погрузить оперативную память в жидкий азот (чтобы содержимое не стёрлось при пропаже питания), доставить её в лабораторию и покопаться в ней. Ему не надо будет вообще ниоткуда грузиться.
Впрочем, если вы персона такого уровня, что к вам могут применяться такие атаки, то, скорее всего, у вас есть собственная спецслужба, которая вас охраняет, а в паспорте у вас записано что-то наподобие "Дональд Джонович Трамп".
У меня Bitlocker взял в заложники диск и не хочет отдавать.
Ключ от битлокера есть на распечатке, идентификатор совпадает с тем, что запрашивает комп. Но НИ ХУ Я не работает! Пишет, что ключ неверный.
Может кто знает как решить проблему? Способ из статьи подойдёт?
Обходим BitLocker и вытягиваем из памяти ключи в Windows 11