Исследователи из университета Радбоуд (Нидерланды) рассказали об уязвимостях в системе защиты некоторых твердотельных накопителях. Они позволяют взломщику обходить функцию шифрования данных диском и получать доступ к информации на диске без необходимости знать пароль доступа.
Правда, озвученная проблема касается лишь тех моделей SSD, которые поддерживают аппаратное шифрование благодаря наличию встроенного чипа, который отделен от основного модуля.
Такие устройства так и называют — SSD со встроенным аппаратным шифрованием. Они стали очень популярными в течение последних нескольких лет, поскольку считается, что шифрование содержимого диска закрывает доступ к данным для злоумышленников. Тем не менее, есть один способ обойти защиту — киберпреступники могут красть пароли доступа посредством манипуляций с содержимым RAM.
Но и это еще не все, проблема в том, что есть способ получить доступ к данным вообще без пароля — для этого необходимо использовать уязвимость в прошивке SED. Уязвимости такого рода затрагивают спецификации "ATA security" и "TCG Opal".
Главная проблема в том, что кроме паролей доступа, которые задают владельцы SSD, есть еще и мастер-пароль, который задается на фабрике. Если изменить этот пароль, то уязвимость, о которой идет речь выше, ликвидируется, если нет, SSD и его данные открыты для злоумышленников — конечно, тех из них, которые точно знают, что делать.
Но есть и еще загвоздка: дело в том, что в результате недоработки производителей таких устройств пароль шифрования, выбранный пользователем и ключ шифрования DEK не связаны криптографически. Другими словами, злоумышленник может узнать значение DEK (нужные данные спрятаны внутри SED-чипа) и затем использовать его для расшифровки данных без необходимости знать заданный пользователем пароль.
«Отсутствие криптографической связки — это катастрофа. Из-за недоработки пользовательские данные защищены слабо. Данные, которые хранятся на диске, могут быть без труда восстановлены и скопированы», — говорит один из исследователей, обнаруживших проблему. Результаты исследований и свои выводы эксперты опубликовали в виде статьи (скачать можно здесь).
К сожалению, ученым удалось обследовать небольшое число твердотельных накопителей, их модели обозначены ниже. Тем не менее, уязвимыми оказались все изученные устройства.
Исследователи изучили как внешние, так и встроенные SSD с поддержкой аппаратного шифрования. По их мнению, взлому подвержен гораздо более обширный спектр таких устройств. Исследование было завершено еще в апреле этого года, до настоящего момента ученые вместе с полицией Нидерландов старались известить всех производителей изученных устройств о проблеме.
Сообщается, что такие компании, как Crucial (Micron) and Samsung выпустили обновление прошивки твердотельных накопителей, решив, таким образом, проблему. Правда, этого может оказаться мало.
Дело в том, что исследователи стали углублять свою работу, проводя изучение безопасности пользовательских данных разных систем. Наиболее подвержены опасности пользователи Windows, поскольку в этой ОС некоторые сервисы усугубляют проблему. Так, проблемой можно назвать Windows BitLocker, софтварную систему шифрования данных на диске, работающем в среде Windows OS.
Как только BitLocker обнаруживает SSD с поддержкой аппаратного шифрования, сервис отключается, и данные не шифруются посредством Windows, ОС «надеется» на аппаратную поддержку. Так что пользователи, которые до настоящего момента работают с SSD Сrucial и Samsung и не обновили прошивку своих накопителей, фактически держат свои данные открытыми для всех.
Хорошие новости в том, что BitLocker все же можно заставить работать в этом случае, для этого необходимо изменить некоторые параметры настройки Group Policy. Но в этом случае нужно отформатировать накопитель и начать работать с ним с нуля.
Зато в этом случае защита является двойной и особых проблем, по сути, нет. По мнению исследователей, обнаруживших проблему, корень ее находится в спецификациях, созданных разработчиками аппаратного шифрования.
Комментарии (33)
dartraiden
06.11.2018 20:41+1BitLocker требует от накопителя не упомянутого в статье Opal, а eDrive, стандарта, продвигаемого Microsoft.
Например, NVME-накопители Samsung поддерживают Opal, но BitLocker на них использует программное шифрование, поскольку спецификацию eDrive, насколько мне известно, Microsoft не адаптировала к NVME.
Впрочем, добиться работы накопителей с поддержкой Opal в среде Windows возможно (но BitLocker в этом участия не принимает).
legolegs
06.11.2018 23:02+2Главная проблема в том, что кроме паролей доступа, которые задают владельцы SSD, есть еще и мастер-пароль, который задается на фабрике
В принципе не понимаю, как можно доверять устройствам, у которых есть какой-то «мастер-пароль, задаваемый на фабрике». Это же абсурд.SergeyMax
07.11.2018 08:41Вы наверное немного перепутали. Мастер-пароль присутствует в спецификации ATA Security. Раньше (и сейчас) эта фича была не для шифрования диска, а скорее как аналог пароля на биос, так, от любопытных глаз. В спецификации TCG Opal конечно мастер-пароля уже нет.
simplix
07.11.2018 10:42Но что-то там всё-таки можно напортачить, раз в таблице статьи Crucial не прошли проверку TCG Opal (3 колонка).
dartraiden
08.11.2018 00:13-1У тех, кто некорректно реализовал Opal, пароль, вводимый пользователем, не связан с ключом шифрования, насколько я понимаю.
Если сильно упрощённо:
При нормальной реализации пароль используется для расшифровки ключа, а уже ключом расшифровывается содержимое накопителя. Таким образом, не зная пароль (хранящийся в мозгах пользователя), не получится заполучить ключ шифрования (если пароль хороший, стойкий).
А у Crucial ключ шифрования никак не связан с паролем, который вводит пользователь. Решение о том, правильный ли введён пароль, принимает не бесстрастная «криптография» (как было бы, если бы ключ был сгенерирован на основе пароля), а контроллер. Таким образом, этот этап можно обойти, вскрыв контроллер и «вытащив» из него ничем не защищённый ключ + зашифрованные данные. И спокойно расшифровать их этим ключом.
Защита получается намного слабее. В первом случае её не сможет вскрыть условное ФБР (если не выбьет из пользователя пароль), а во втором случае — сможет, без всякого взаимодействия с пользователем.
SergeyMax
07.11.2018 01:10+2Кому лень читать отчёт, рассказываю в двух словах, что сделали пацаны. Подключились через JTAG к контроллеру, поправили в его ОЗУ процедуру, проверяющую пароли, так, чтобы подходил любой пароль. Так как задаваемый пользователем пароль никак не связан с ключом шифрования диска (DEK), то такая модификация процедуры аутентификации делает данные на диске доступными через обычный интерфейс.
saboteur_kiev
07.11.2018 01:28+2То, что пароль никак не связан с шифрованием — это баг в голове у тех, кто принял решение реализовать шифрование диска таким способом.
roscomtheend
07.11.2018 09:13Всё просто — пользователь не сможет сменить пароль при таком раскладе. Тут и иллюзия безопасности (шифровано же) и удобство (можно сменить пароль, не перешифровывая диск).
Konachan700
07.11.2018 09:26Сможет, cryptsetup же может. Генерируем мастер-ключ, его шифруем паролем пользователя и храним. Захотелось сменить пароль — просто ввели старый пароль, мастер-ключ расшифровался, ввели новый пароль,… ПРОФИТ.
Это просто халтура, сделали по принципу «и так сойдет». Да и то, что на продовой железке не выключен наглухо jtag, тоже лютый баг.SvSh123
07.11.2018 10:16А теперь представим, что все сделано как надо. Что в таком случае будет, если юзер — та-да-а! — забыл пароль?
GennPen
07.11.2018 10:32Дается допустим 5 попыток, если все неправильные — генерируется новый мастер-ключ, старые данные по сути перестают быть доступными и стираются.
SvSh123
07.11.2018 12:30Вопрос в том, что главней — данные пользователя, или конфиденциальность. В первом случае это неудачное решение.
GennPen
07.11.2018 12:43По уму шифрование диска — это конфиденциальность. Если пользователю важны данные — нужно делать бекапы, а не возможность их восстановления с «зашифрованного» диска.
SvSh123
07.11.2018 13:44Впрочем, да, «простому смертному юзверю» шифрованный диск и не нужен.
Tangeman
07.11.2018 18:01Впрочем, да, «простому смертному юзверю» шифрованный диск и не нужен.
Простые смертные, у которых на компах куча личной инфы (плюс возможно пароли к сайтам-банкам-etc) вряд-ли будут рады, если всё это будет легко доступно вору, который украл комп. Точно также родители вряд-ли будут рады если их развитые детки покопаются в их компах (или наоборот).
Так что, всё же, шифрование диска имеет смысл и для «простых смертных», или, говоря другими словами — если на компе есть хоть один файл, утечка которого нежелательна (хотя и не смертельна) — то это уже достаточное основание для шифрования.SvSh123
08.11.2018 09:00Может быть. Лично я предпочитаю держать личную инфу на внешних носителях, а пароли — записывать. Ну да, флэшку или блокнот тоже можно украсть, но для этого нужно, чтобы кого-то интересовала именно моя личная информация. Сами по себе эти вещи ценности не имеют.
Lofer
07.11.2018 12:47Вопрос в том, что главней — данные пользователя, или конфиденциальность
Это уже проблема выбора пользователя — пусть в настройках выбирает.
MahMahoritos
07.11.2018 11:16Я не разработчик, но разве в этом случае пользователь не обязан отказаться от шифрования, если считает свою забывчивость слишком значительной? Мне казалось, что достижение конфиденциальности неотрывно от возникающего риска полной утери данных в случаях амнезии/склероза и т.д.
legolegs
07.11.2018 11:24Юзер восстановит данные из бекапов. (бекапов, ха-ха-ха)
saboteur_kiev
09.11.2018 01:40А в чем проблема? Сделать бэкап сейчас можно одной кнопкой. И восстановить тоже одной кнопкой. Оставаясь юзером.
MahMahoritos
09.11.2018 06:14Дело не в сложности реализации, а в том, что обычно люди (причем и простые юзеры и даже админы иногда) вообще не думают о бэкапах в принципе. Отчасти поэтому облака так популярны — пользователь зачастую вообще не думает, что его данные хранятся где-то вне устройства, и испытывает огромную радость, когда устройство умирает, а данные оказываются целыми. Хотя вроде бы что сложного в том, чтобы вечером подключать телефон, например, к компу и сливать копии данных.
saboteur_kiev
09.11.2018 01:38А что будет если юзер — та-да-а и сам удалит свои файлы, или уронит диск или сделает еще какую-нибудь глупость?
Пусть запишет пароль на бумажке и положит в сейф. Пусть делает периодически бэкапы на другой диск, который сдает в банковскую ячейку.
Собственно зачем покупать и пользоваться КОММЕРЧЕСКИМ продуктом для шифрования, если он будет предоставлять всего лишь иллюзию безопасности?
roscomtheend
07.11.2018 17:52Согласен со способом, JTAG не отключали примерно те же люди, потому не удивительно.
vitaliy2
07.11.2018 21:55Оно не шифровано. Чтобы было шифровано, сами данные должны быть изменены. И если производитель говорит «шифровано», а на самом деле нет, это наглый обман, и за это должна быть серьёзная ответственность.
roscomtheend
09.11.2018 16:37По идее да, но что там в договоре «обещаем шифрование, но ничего не гарантиуем, посколько ПО».
saboteur_kiev
09.11.2018 01:36Если пользователю нужна лишь иллюзия безопасности, зачем ему вообще шифровать диск? Пусть просто пароль на вход в систему поставит и достаточно.
GennPen
07.11.2018 08:24Если к диску можно просто так подключиться по JTAG и править в ОЗУ процедуры, то даже если DEK зависит от пароля, то можно отключить максимальное кол-во попыток и брутфорсом подобрать пароль. Я правильно понимаю? Это же бред какой то получается, защита от дурака.
imm
07.11.2018 09:53вот ведь молодцы, независимое от пароля шифрование реализовали, это даже веселее, чем парольные хэши без соли.
xor ещё можно для «шифрования» использовать, эффект примерно тот же.
simplix
07.11.2018 10:53ATA-пароли и не позиционировались как надёжное средство защиты, сама спецификация очень древняя. Другое дело TCG Opal, там при правильной реализации можно на что-то рассчитывать. Но всё равно мы как потребители не можем проверить, есть ли там аппаратные закладки, поэтому самым надёжным будет софтовое шифрование с открытыми исходниками.
orion76
Хм… по-моему это не баг, а фича… очень гуманная фича.