The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обход полнодискового шифрования в Linux через непрерывное нажатие клавиши Enter, opennews (??), 02-Сен-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


206. "Обход использующего TPM шифрования диска в Linux через непре..."  +/
Сообщение от Аноним (206), 03-Сен-23, 05:10 
>> Systemd, получив управление после неудачных попыток ручной разблокировки, не сможет получить доступ к файловым системам на зашифрованных дисках, предложит перейти в режим восстановления после сбоя и предоставит доступ к командной оболочке с правами root в окружении загрузочного ram-диска.

А при испорченном (контролируемо) диске мы тоже получим режим восстановления с рутом? Уже неплохо, плюс восстановим (с флешки) повреждённое и инициируем штатный процесс автоматической разблокировки зашифрованных дисков, вот и данные.

Ответить | Правка | Наверх | Cообщить модератору

230. "Обход использующего TPM шифрования диска в Linux через непре..."  +/
Сообщение от пох. (?), 03-Сен-23, 10:34 
> А при испорченном (контролируемо) диске мы тоже получим режим восстановления с рутом?

_якобы_ наши средства шифрования не позволяют диск испортить контролируемо (если ты уже не рут еще до перезагрузки). Реализация вполне может быть как обычно.

Я еще не забыл историю ранних дней линукса, когда у них des оказался xor'ом. Причем это было видно просто если посмотреть hexdump - но кто бы мог подумать и было ли чем, сказали же ж вам - des, чего на него смотреть-то.

> Уже неплохо, плюс восстановим (с флешки) повреждённое и инициируем штатный процесс

С флэшки не получится, если это не кого надо флэшка.

С штатного загрузчика подписанного своим ключом - не должно получаться без запроса пароля, но сам видишь, получается, даже без необходимости что-то там портить.

Ответить | Правка | Наверх | Cообщить модератору

261. "Обход использующего TPM шифрования диска в Linux через непре..."  +/
Сообщение от Аноним (206), 03-Сен-23, 17:34 
Я имел в виду немного другое: т.к. у нас подключается USB-брелок, то физический доступ к устройству у нас есть. Вытаскиваем зашифрованный диск, вставляем в другой комп, вычитываем мегабайт-другой с начала и конца диска на флешку и зануляем эти области на диске. Ставим диск назад. Запускаемся. После автоматической расшифровки на занулённых блоках выдаётся мусор. Т.е. мусор получается на областях MBR/GPT и на начальной области первой партиции (а можно и не трогать MBR/GPT, а попортить только начальные/важные области всех партиций). Далее непонятно, как отреагирует systemd на подобное, но, судя по приведённой цитате, похоже даст рута для восстановления. Если это так, то подключаем флешку (доступ к USB-порту у нас есть), с неё перенесём исходное содержимое занулённых блоков обратно на диск и инициируем штатный процесс автоматической разблокировки зашифрованных дисков. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору

315. "Обход использующего TPM шифрования диска в Linux через непре..."  +/
Сообщение от пох. (?), 05-Сен-23, 23:03 
> Я имел в виду немного другое: т.к. у нас подключается USB-брелок, то
> физический доступ к устройству у нас есть. Вытаскиваем зашифрованный диск

дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть диск из сервера в стойке?
И сам сервер вырубить на пару часиков пока ты этой фигней занимаешься (прямо под камерами).

> Далее непонятно, как отреагирует systemd на подобное, но, судя по приведённой

понятно - там нет никакого race condition, поэтому он либо опознает luks заголовок, и спросит у тебя пароль, либо не опознает и просто выпадет в осадок - без шансов для тебя воспользоваться содержимым tpm.

> цитате, похоже даст рута для восстановления. Если это так, то подключаем

даст да не того рута.

> флешку (доступ к USB-порту у нас есть), с неё перенесём исходное
> содержимое занулённых блоков обратно на диск и инициируем штатный процесс автоматической
> разблокировки зашифрованных дисков. Как-то так.

штатный в этот момент уже не получится.

И в любом случае это уже совсем не то же самое что микроскопическая хрень сунутая в usb порт
(причем всунуть могут заранее, и хрен ты ее увидишь даже при непосредственном доступе к стойке, а сработать оно может и через год)


Ответить | Правка | Наверх | Cообщить модератору

318. "Обход использующего TPM шифрования диска в Linux через непре..."  +/
Сообщение от Аноним (206), 06-Сен-23, 05:39 
>> дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть диск из сервера в стойке? И сам сервер вырубить на пару часиков пока ты этой фигней занимаешься (прямо под камерами).
>> -----
>> И в любом случае это уже совсем не то же самое что микроскопическая хрень сунутая в usb порт (причем всунуть могут заранее, и хрен ты ее увидишь даже при непосредственном доступе к стойке, а сработать оно может и через год)

Вариант с мелкой "флешкой" конечно удобней, безусловно, просто описание уязвимости создало впечатление, что может пройти и более дубовый способ без всяких спец. устройств и гонок. Ну а возможность вытворять с железом всякое может быть вполне и легальной.

>> понятно - там нет никакого race condition, поэтому он либо опознает luks заголовок, и спросит у тебя пароль, либо не опознает и просто выпадет в осадок - без шансов для тебя воспользоваться содержимым tpm.

Заголовки luks можно не трогать (они описаны и идут до данных), а портить сами данные. Пусть расшифровываются. Получим битую файловую систему с которой далее не получится работать.

>> даст да не того рута.
>> -----
>> штатный в этот момент уже не получится

"Systemd, ..., не сможет получить доступ к файловым системам на зашифрованных дисках, предложит перейти в режим восстановления после сбоя и предоставит доступ к командной оболочке с правами root в окружении загрузочного ram-диска."

А чем текущее состояние отличается от описанного в уязвимости? Вроде, такое же, и там всё работало.

Ответить | Правка | Наверх | Cообщить модератору

316. "Обход использующего TPM шифрования диска в Linux через непре..."  +/
Сообщение от пох. (?), 05-Сен-23, 23:03 
> Я имел в виду немного другое: т.к. у нас подключается USB-брелок, то
> физический доступ к устройству у нас есть. Вытаскиваем зашифрованный диск

дружище, ты хорошо понимаешь разницу между - пихнуть мелкую флэшку - и вынуть диск из сервера в стойке?
И сам сервер вырубить на пару часиков пока ты этой фигней занимаешься (прямо под камерами).

> Далее непонятно, как отреагирует systemd на подобное, но, судя по приведённой

понятно - там нет никакого race condition, поэтому он либо опознает luks заголовок, и спросит у тебя пароль, либо не опознает и просто выпадет в осадок - без шансов для тебя воспользоваться содержимым tpm.

> цитате, похоже даст рута для восстановления. Если это так, то подключаем

даст да не того рута.

> флешку (доступ к USB-порту у нас есть), с неё перенесём исходное
> содержимое занулённых блоков обратно на диск и инициируем штатный процесс автоматической
> разблокировки зашифрованных дисков. Как-то так.

штатный в этот момент уже не получится.

И в любом случае это уже совсем не то же самое что микроскопическая хрень сунутая в usb порт
(причем всунуть могут заранее, и хрен ты ее увидишь даже при непосредственном доступе к стойке, а сработать оно может и через год)


Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру