Author Topic: Создание USB-загрузчика / "Evil Maid" Attack / перенос 100MB раздела  (Read 6594 times)

Poiuyzxcvb

  • Newbie
  • *
  • Posts: 8
не всё ли равно, что там на диске останется, когда утечка уже произошла?

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

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

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


Очевидно, что под этапом "похищение пароля" здесь подразумевается повторный доступ к физическому диску, в случае, когда инфицированный загрузчик перехватывает пароль, введённый пользователем и сохраняет его в другой части диска.

Если вам нужно полное стирание

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

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

На все это потребуется достаточно много времени, поэтому перед этими процедурами, очевидно, сначала нужно как можно быстрее обезопасить сохранность данных и воспользоваться простой и быстрой процедурой - непосредственным удалением/затиранием инфицированной области, где находится сохраненный вредоносом перехваченный пароль, а также сам вредонос. В этом и вопрос, как это сделать?
« Last Edit: November 18, 2015, 07:28:45 am by Poiuyzxcvb »

alkoro

  • Sr. Member
  • ****
  • Posts: 418
Quote
быстрой процедурой - непосредственным удалением/затиранием инфицированной области, где находится сохраненный вредоносом перехваченный пароль
Невозможно, не согласиться, но вы уверены, что это быстрая процедура? Я имею в виду, что стереть вредонос - это дело долей секунды, а вот проанализировать, какими способом и куда (в какое место жесткого диска, а может и вовсе не диска) произошла утечка информации (копии паролей), написать спец. утилитку для вытирания? Ну нереально же (быстро). Вы же заранее не знаете, как будет реализовано похищение. Вопрос чисто практический, если за вами была негласная слежка с целью собрать компромат, чтобы потом прийти с понятыми и узаконить обнаруженную информацию - универсальное быстрое решение в случае обнаружения утечки одно - это полное уничтожение (улик). Вы сомневаетесь, что такой сценарий невозможен в нашем правовом %НазваниеГосударства%, борящимся с терроризмом, наркобаронами, неплательщиками налогов, коррупционерами и педофилами? У меня лично нет сомнений.
Остальное - академический интерес, требующий времени, которого у вас не будет в случае сценария вмешательства со стороны госорганов.
А если рассматривать то же самое со стороны действий конкурентов (промышленный шпионаж) - то тут конечно, можно расслабиться, и начать проводить расследование утечки, вытереть вредонос. Следующий шпион применит что то другое.
Правда, если вы будете знать только про факт утечки, но не про заказчика, то опять же быстрым выходом будет уничтожение.

Вы не можете полностью контролировать ситуацию для такого типа атаки только программными средствами, раз уж разговор зашел так глубоко. Вам нужно абсолютно надежное решение - но его не существует, раннее я описывал векторы атак вплоть то гипервизоров в BIOS. В обычной жизни обычного законопослушного предприятия или обывателя достаточно иметь свою загрузочную флешку и о модификации бесполезного HDD-загрузчика можно забыть.

Poiuyzxcvb

  • Newbie
  • *
  • Posts: 8
Вы же заранее не знаете, как будет реализовано похищение.

Предполагалось, в теме рассматривается конкретный вариант - "Evil Maid" Attack и защита при помощи MBR-загрузчика на UBS-флешке. Модификация BIOS, внедрение закладок/подмена физических частей компьютера и другие варианты атак не рассматривались, в FAQ, на который ссылается мой первый пост, они описываются, как не решенные проблемы безопасности, также и вы об этом уже высказались, как об отдельных атаках.

Давайте я еще раз попробую объяснить. Из того, что вы помогли прояснить, вытекают несколько вариантов атаки при использовании USB-загрузчика, которые можно предотвратить во время их проведения.

Варианты атак:

1. Злоумышленник путем наблюдения (скрытая камера или личное присутствие/осведомитель) узнает уникальную фразу, появляющуюся при вводе пароля, изменяет параметры BIOS на загрузку с диска, средствами вредоноса прослушивает пароль и оставляет его храниться на незашифрованной области диска до повторного доступа к нему, чтобы получить доступ к заранее скопированной с диска информации.

Я понимаю, что наличие видеонаблюдения со стороны злоумышленника поднимает другие вопросы, но предлагаю отталкиваться именно от таких действий злоумышленника, не акцентируясь на этом.

2. Злоумышленник получает доступ к USB-загрузчику, узнает уникальную фразу, появляющуюся при вводе пароля и выполняет дальнейшие действия из пункта 1.

3. Злоумышленник получает доступ к USB-загрузчику и модифицирует его. Здесь есть два варианта развития атаки:
а) прослушанный пароль записывается на USB-загрузчик;
б) прослушанный пароль записывается на незашифрованные области диска.

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

Предотвращение данных атак:

1. Физическое уничтожение USB-загрузчика.
2. Полное затирание незашифрованной области диска, где может располагаться прослушанный пароль.

Первый пункт не является проблемой. Также, если будет успешно выполнен второй пункт, далее без спешки можно будет перенести информацию на чистый диск и провести вайп на подвергшемся атаке диске.

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

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

По поводу надежного затирания, также снова встает вопрос SSD - даже в несколько циклов перезаписи удалить информацию безвозвратно может быть невозможно. Упомянутый вами параметр Disable TRIM on encrypted SSD disks может решить данный вопрос или он будет работать только если запущена зашифрованная система, установленная на подвергшийся атаке диск, где был использован данный параметр при шифровании? Или при использовании диска с другого компьютера этот параметр будет актуален? Если он будет актуален, будет ли это значит, что перезапись/затирание будет осуществляться, как на HDD?

Когда зашифрованный диск монтируется или подключается с другой системы, незашифрованные области остаются неактивными, т.е. не представляют опасности? Также, например, если злоумышленник модифицирует незашифрованные области обычного (не системного) зашифрованного физического диска, при его монтировании существует ли вероятность риска и компроментации паролей, как системного физического диска, так и данного подключаемого физического диска?
« Last Edit: November 18, 2015, 12:38:24 pm by Poiuyzxcvb »

alkoro

  • Sr. Member
  • ****
  • Posts: 418
Quote
встает вопрос SSD - даже в несколько циклов перезаписи удалить информацию безвозвратно может быть невозможно. Упомянутый вами параметр Disable TRIM on encrypted SSD disks может решить данный вопрос или он будет работать только если запущена зашифрованная система, установленная на подвергшийся атаке диск, где был использован данный параметр при шифровании?
Естественно параметр DC влияет только на работу DC в той системе, где это будет настроено и только к разделам, шифруемым DC. Чтобы полностью обновить все секторы SSD, нужно либо установить носитель в заведомо старую систему, которая не знает про SSD, или отключить SSD программно, и сделать wipe по всей поверхности.

Quote
Однако, насколько я понимаю, (полное) затирание незашифрованной области диска все же является проблемой? Ранее вы говорили о возможности стереть стандартный MBR-загрузчик, который расположен на определенных секторах. Это значит, что есть фиксированные области диска, которые используются под нешифруемый "раздел". Длина этой области не определена достаточно четко и оставшееся место, не занятое MBR-загрузчиком/таблицей, может варьироваться - из-за этого вопрос затирания этих областей становится невозможным?
А в чем проблема? Используемые области диска чётко прописаны в таблице разделов (MBR), ничего сложного в смысле реализации некоего софта, который будет затирать оставшееся место (если таковое будет обнаружено) нет. И ещё вот такой момент - злоумышленник может быть совсем плохим, и оставить возможность записи прямо по живому, совершенно не заботясь о том, используется кем то выбранное место или нет.

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

Quote
Также, например, если злоумышленник модифицирует незашифрованные области обычного (не системного) зашифрованного физического диска, при его монтировании существует ли вероятность риска и компроментации паролей, как системного физического диска, так и данного подключаемого физического диска?
Почему при монтировании в системе Windows должен выполняться код загрузчика MBR с монтируемого устройства? Мы же рассматриваем ситуацию, когда вредоносный код стартует при запуске системы, и он видимо, завершает свою работу во время старта Windows? или я опять что то не понял?