Новая программа «Элкомсофта» ворует ключи программ BitLocker, PGP и TrueCrypt из оперативки


Компания «Элкомсофт» выпустила программу Elcomsoft Forensic Disk Decryptor, которая предназначена для криминалистической экспертизы криптоконтейнеров BitLocker, PGP и TrueCrypt. Поддерживаются как фиксированные, так и портативные носители, включая PGP в режиме шифрования всего диска, а также съёмные диски, защищённые с помощью BitLocker To Go. С помощью Elcomsoft Forensic Disk Decryptor можно как полностью расшифровать содержимое защищённого тома, так и работать в реальном времени с подключением зашифрованных томов и расшифровкой выбранных данных «на лету».

Программа извлекает ключи шифрования тремя методами:

1. Из дампа оперативной памяти. Все ключи извлекаются единовременно, даже если в системе присутствуют более, чем один криптоконтейнер. Дамп оперативной памяти может быть создан с помощью соответствующих криминалистических продуктов, например, MoonSols Windows Memory Toolkit. Зашифрованные тома в момент снятия слепка должны быть подключены; в противном случае ключ расшифровки извлечь не удастся. Подробное описание этой технологии (и полный список коммерческих и бесплатных программ см. здесь.

2. Анализ файла гибернации (исследуемый компьютер выключен). Защищённые тома должны быть подключены перед выключением компьютера. Если криптоконтейнер был размонтирован перед созданием файла гибернации, извлечь из него ключи будет невозможно.

3. Атакой через порт FireWire, если у вас не хватает прав для снятия дампа памяти или запуска программ на анализируемом компьютере. Для проведения атаки через порт FireWire требуется дополнительный компьютер с установленным бесплатным продуктом (например, Inception). Такая атака даёт практически стопроцентный результат, но опять же, зашифрованные тома должны быть подключены в момент анализа.

http://www.xakep.ru/post/59849/

Комментарии
— SATtva (21/12/2012 11:55)   
В этом есть какая-то новость?
— unknown (21/12/2012 12:00)   
Анализ файла гибернации (исследуемый компьютер выключен). Защищённые тома должны быть подключены перед выключением компьютера.

Т.е. в Windows он не шифруется? Причём не абы как, а так, как положено шифровать именно своп для гибернации?
Гость (21/12/2012 13:17)   
Зашифрованные тома в момент снятия слепка должны быть подключены
может я чего то не понимаю, но зачем такие сложности, если есть доступ к компу в котором тома подключены? копируем содержимое томов и идем анализировать. по пункту 3 такая же байда.
Гость (21/12/2012 13:19)   
Анализ файла гибернации
если не изменяет память, то когда выводишь комп из гипернации, например TrueCrypt, запрашивает пароль при полнодисковом шифровании.
— SATtva (21/12/2012 13:24, исправлен 21/12/2012 13:24)   
может я чего то не понимаю, но зачем такие сложности, если есть доступ к компу в котором тома подключены? копируем содержимое томов и идем анализировать.

В каких-то ситуациях для целей судебно-экспертного анализа это может не подойти.

Гость (21/12/2012 15:51)   
Я вот тоже не понимаю смысла в данной программе..
Проще сделать свой LiveUSB (на Linux ессн), настроить Tor+i2p, зашифровать полностью, и там хранить контейнеры. и все. в случае чего – выдергиваем флешку и вопросы отпадают.
— ntldr_влом_логиниться (21/12/2012 17:21)   
Это действительно плохая новость, т.к. появление общедоступного софта превращает атаки на память из редкой экзотики в повседневную практику. Обучить пользоваться этим софтом можно любого мусора, а значит пора придумывать контрмеры.

DiskCryptor пока не поддерживается этой прогой от елкомсофта, но это дело времени. Концептуальной программной защиты я не вижу, поэтому задумываюсь об мерах "security through obscurity". Идея такова: сделать закрытую и защищенную от анализа версию DiskCryptor которая использует обфускацию участков памяти хранящих ключи и пароли, обфускацию ioctl интерфейсов драйвера и обфускацию загрузчика. Кроме того, каждый билд скачиваемый пользователем должен обладать уникальной схемой обфускации (схемы обфускации генерируются автоматически), а набор мер по обфускации должен меняться с каждым релизом. Всё это делает автоматическое излечение ключей практически невозможным, каждый билд должен будет индивидуально ковырять опытный реверсер.
Как вам такая мысль?
— unknown (21/12/2012 17:48, исправлен 21/12/2012 18:00)   

А что плохого то? Включенный компьютер не является зашифрованным.
В Linux в саму утилиту вставлена штатная опция показать все ключи шифрования из памяти, жалко что ли?


Для обфускации существует конечно White-Box Cryptography, но оно вроде как успешно ломается.

— sentaus (21/12/2012 17:59)   
DiskCryptor пока не поддерживается этой прогой от елкомсофта, но это дело времени. Концептуальной программной защиты я не вижу, поэтому задумываюсь об мерах "security through obscurity".

Я думаю, рано или поздно задолбаетесь. :) Не стоит ввязываться в битву брони и снаряда.
Гость (21/12/2012 18:13)   
Если
Не стоит ввязываться
, то никакой битвы и не будет.
Гость (21/12/2012 18:48)   
Лучше больше полагаться на превентивные меры защиты: не держать смонтированными контейнеры в то время, когда доступ к ПК может получить форензик злоумышленник, не использовать ноутбуки с поддержкой firewire и прочих вредных портов и т.д.
Гость (21/12/2012 20:33)   
не держать смонтированными контейнеры
так вот это самое очевидное. ключевой вопрос – каким образом и почему злоумышленник получает доступ к компу? можно оставить ключи в замке зажигания машины и спрашивать кто виноват что тачку угнали.
— unknown (21/12/2012 20:45)   
показывает в Linux таблицу ключей всех открытых зашифрованных разделов. И это полезная опция для пользователя. Если злоумышленник может этой опцией воспользоваться, то пользователь уже проиграл где-то до этого. Вытащить ключи можно и ручным разбором дампов памяти.

Считывание ключей из памяти штатной утилитой позволяет организовывать в Linux иерархическое шифрование, в т.ч. и безопасный гибернейт с шифрованием. Так, у пользователя корень может быть на одном физическом разделе (томе), /home на другом, а своп на третьем. Что-то он хочет иметь на обычном винчестере, что-то на SSD, что-то на рейде, какую-то мелочь на съёмном (например для переноса информации между компьютерами). Всё это может быть прописано в /etc/crypttab как производные от соответствующих ключей. Чаще всего от корневого ключа, так чтобы при входе в систему пользователю достаточно было один раз ввести пароль и всё это иерархически расшифровалось.
Гость (21/12/2012 22:16)   
при входе в систему пользователю достаточно было один раз ввести пароль и
и сразу рут? Зачем иеарархическое расшифрование? С тем же успехом можно все разделы посадить на один шифровальный ключ. Наоборот, каждый modus operandi требует своей информации, и нужно подключать/отключать нужные разделы на лету по мере надобности. Монтировать по умолчанию всё — плохой метод.
— unknown (21/12/2012 23:09, исправлен 21/12/2012 23:13)   
при входе в систему пользователю достаточно было один раз ввести пароль и
и сразу рут?

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


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


С тем же успехом можно все разделы посадить на один шифровальный ключ.

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


нужно подключать/отключать нужные разделы на лету по мере надобности

Если сочетать оба подхода при наличии меанизма того, как это можно просто делать, то это только повысит безопасность системы.


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

Гость (21/12/2012 23:31)   
Можно шифровать корень одной пассфразой, а каждый нужный /home/username — другой, своей пассфразой. При загрузке разумно вводить пассфразу только на корень, а дальше, уже залогинившись, подключать тех юзеров, чьи разделы нужны — как-то так я себе это представляю. А автоматически монтировать и подключать все разделы, да ещё и после ввода только одной пассфразы... — нет, это не для меня :)
— unknown (22/12/2012 00:07)   
А кто сказал, что монтируются все разделы? А разделов не 1024, из них a — автомонтируются, b — по запросу, c — скрытых, d — висят на рейдах, e — на сетевых носителях, f на внешних, которые подключаются только при монтировании каких-то других и т.д. И из них не сделаны цепочки, петли, кольца, графы и деревья :)
Гость (22/12/2012 00:27)   
и дать гармонично существовать
хочется уточнить )) лени и беспечности?
Гость (23/12/2012 14:54)   
Волнует вопрос – если fireware отключен в биосе, а экран блокируется на время отсутствия, то кроме холодной перезагрузки опасаться нечего? Имеется в виду одноразовая попытка. Предварительная подготовка к атаке путём установки клавиатурных кейлогеров или скрытых видеокамер не рассматривается, т.к. относится к физической защите помещения.

Считывание ключей из памяти штатной утилитой позволяет организовывать в Linux иерархическое шифрование

Не могли бы развернуть мысль в плане практической реализации? В моём представлении: есть мастер-ключ, защищённый паролем и хранящийся в файле. Ключ для конкретного устройства получается расшифровкой мастер-ключа с добавленим в него искажения, зависящего от устройства. Например, исключающее ИЛИ (XOR) серийного номера устройства с мастер-ключом. Серийные номера удобны тем, что изображены на корпусе и поэтому их не нужно запоминать. Для каждого устройства получается свой ключ шифрования. С целью автоматизации действий создаётся скрипт, который извлекает ключ из памяти (dmsetup --showkeys), модифицирует в соответствии с серийным номером, создаёт виртуальное устройство /dev/mapper/name и монтирует его. Можно реализовать автомонтирование шифрованных устройств добавлением этого скрипта в правила udev. При таком подходе все устройства равноправны, и неясно как обеспечить их иерархию.
— unknown (23/12/2012 19:17)   
В /lib/cryptsetup/scripts загляните. В частности в decrypt_derived. Можно целую статью написать, как эти хитрости использовать, да всё пока руки не доходят. Если любопытно, можете нагуглить материал по теме.
Гость (23/12/2012 23:45)   

Unknown ранее что-то писал про «иерархическое расшифровывание» в его стиле, но гуглится только /comment48104[link1]. Возможно, был ещё один подобный комент на эту тему.
Гость (24/12/2012 20:41)   
В целом понятно – для шифрования нижних в иерархии устройств генерируется новый ключ, а паролем случит ключ родительского устройства. Возможные недостатки:

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

2. Управление такой иерархией специфично для Дебиана. На моей системе нет скриптов /lib/cryptsetup/scripts, нет их и в tgz-архиве последней версии cryptsetup-1.5.1.

3. Не ясна практическая необходимость в создании иерархии. Возможно она имеет смысл в многопользовательской системе, а для одного пользователя – зачем? В принципе иерархию можно создать и в описанном выше способе, добавив необратимость при создании ключей для нижележащих устройств с помощью хеширования: HASH(key XOR serial-number). Хотя в силу неизвестных широкой публике ньюансов, хеш ключа может оказаться слабее ключа. Всё-таки ключ – это чистая энтропия, а хеш – применение некой математической функции, с не вполне очевидными последствиями для случайности. Но аналогочное можно сказать и о шифровании ключа тем же самым ключом, используемым при выходе из режима hibernation. Интуитивно понятно что такая нелинейность может создать почву для атак.
— unknown (25/12/2012 09:42, исправлен 25/12/2012 10:30)   
Управление такой иерархией специфично для Дебиана. На моей системе нет скриптов /lib/cryptsetup/scripts

Это верно, но нет проблем внедрить. Хотя в другом дистре какой-нибудь шибко умный автосборщик рамдиска может всё попортить. Правда это скорее всего приведёт не к утечке, а к необходимости восстанавливаться вручную после неудачной загрузки.


Не ясна практическая необходимость в создании иерархии.

  1. Своп для гибернейта на другом (отличном от корневого) физическом разделе, чтобы к нему не вводить пароль при загрузке (ввели один раз пароль от корня и всё). Возможность быстрого перетирания текущего ключа в слоте свопа без прекращения его работы (!) на ключе в памяти до отключения компа (если гибернейт больше не нужен и нужно быстро очистить накопленные там данные).
  2. Обмен информацией на шифрованной флэшке между двумя доверенными компами Sneakernet[link2]. Серийник флэшки может считываться автоматически через udev (это для удобства её автоопределения в fstab/crypttab), а пароль на монтирование вводить ввобще не надо, если один из открытых на компе разделов совпадает с паролем для слота шифрованной флэшки. Если что-то не подойдёт и не сработает, флэшка просто не откроется, уязвимости и утечки здесь нет.

В отличие от предложенных вами методов при этом не требуется сохранения никаких ключевых файлов на файловой системе носителя, которые трудно удалять, в отличие от простого и надёжного затирания заголовков LUKS-слотов при необходимости.


Этот метод не хуже и не лучше, он другой и даёт дополнительные фичи, не всегда возможно нужные.



Эта проблема является уязвимостью режима шифрования LRW и пока наиболее успешно решена в режиме шифрования XTS.

Гость (25/12/2012 12:23)   
wwwSneakernet.
пояснение[link3]
— unknown (25/12/2012 12:35, исправлен 25/12/2012 12:36)   

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

— SATtva (25/12/2012 22:14, исправлен 25/12/2012 22:15)   

А жёлтая пресса, тем временем, жжот напалмом:


Российские разработчики расшифровали криптоконтейнеры BitLocker, PGP и TrueCrypt[link4]

Разработанный экспертами продукт под названием Elcomsoft Forensic Disk Decryptor позволяет снять защиту с криптоконтейнеров мгновенно. Специалистам компании Elcomsoft удалось взломать защиту криптоконтейнеров BitLocker, PGP и TrueCrypt. Всю информацию, которая хранится в зашифрованных томах данных, можно проанализировать посредством криминалистического анализа.
Гость (26/12/2012 00:31)   

Ага:
Все три криптоконтейнеры
Криптоконтейнера (проверочное: она моя) — это что-то типа капоэйры? Что тут взять с прикошмарских контор.

Ссылки
[link1] https://www.pgpru.com/comment48104

[link2] https://en.wikipedia.org/wiki/Sneakernet

[link3] http://www.dvakompa.com/forum/sneakernet.html

[link4] http://www.securitylab.ru/news/435544.php