26.07 // Явные пароли в оперативной памяти повсеместны
Недавнее исследование принстонской группы дало всем понять, что оперативная память компьютера не может считаться совершенно надёжным хранилищем секретных данных: состояние ОЗУ не настолько чувствительно к поддержанию напряжения, как считалось ранее, и противник с физическим доступом к машине способен извлечь содержимое памяти в исходном виде даже после "холодной" перезагрузки. Независимый специалист по инфобезопасности Шерри Давыдофф рассмотрел, насколько надёжны распространённые средства шифрования, контроля доступа и обычные программы перед подобным вектором атаки.
Главный предмет поиска в данном случае представляли пароли (а не криптоключи), используемые повсеместно: для получения доступа к почтовому ящику с помощью Thunderbird, подключения к IM-аккаунту через Pidgin, шифрования файлов или дисковых разделов с помощью GnuPG и TrueCrypt, удалённого входа в систему по SSH. Исследование проводилось в среде GNU/Linux (дистрибутив Ubuntu) с отключенным свопом. Давыдофф снимал дамп памяти после использования перечисленных программ, изучал его в поисках паролей, определял оффсет, по которому размещается тот или иной пароль, или последовательности байтов (сигнатуры), так же указывающие на расположенный рядом пароль. Полученные сведения затем использовались для извлечения паролей из второй тестовой системы.
Как оказалось, большинство обычных приложений держат используемые пароли в виде открытого простого текста в памяти своего процесса. Это закономерно, например, для Thunderbird для автоматической проверки почтового ящика. В других случаях это менее понятно: так, пароль от учётной записи пользователя остаётся в памяти оконного менеджера (в данном случае, gdm) даже после успешной аутентификации.
Средства безопасности, разработанные с учётом специфических атак, предпринимают более активные меры, дабы не сохранять пароли в памяти, но, к сожалению, в некоторых случаях не спасает и это. Пароль SSH не был найден в памяти процесса, однако, оказался в общем дампе памяти системы. То же самое касается пароля администратора (root), вводимого в su.
Парольная фраза от ключа GnuPG не была обнаружена ни в памяти процесса, ни в дампе памяти системы. К сожалению [для целей исследования], система безопасности ядра Linux не даёт доступ через устройство /dev/mem к зоне ОЗУ ZONE_HIGHMEM (верхняя половина памяти), поэтому образ мог быть снят только ZONE_NORMAL. Возможно, какие-то пароли могли бы быть найдены в ZONE_HIGHMEM; в то же время, не исключено, что превентивные меры GnuPG по блокированию и нулификации критических данных в памяти не дают им остаться там дольше, чем следует. Как бы то ни было, использование даже сверхзащищённого приложения в небезопасной среде чревато утечками: открытый текст сообщения, расшифрованного с помощью GnuPG, так и остался в памяти терминала Gnome.
Наиболее интересна ситуация в паролями от криптоконтейнеров TrueCrypt 5.1. Когда пользователь вводит пароль, программа позволяет сохранить его в кэше, чтобы избежать последующих запросов. Автор исследования подчёркивает, что кэширование не использовалось. Тем не менее, в памяти процесса TC удалось без труда обнаружить как пароль, так и полный путь и имя файла криптоконтейнера. Более того, область, содержащую пароль, предваряет фиксированная сигнатура (и даже счётчик длины пароля), позволяющая безошибочно опознать его в любой ситуации. Почему пароль сохраняется в памяти, даже когда пользователь явно просит этого не делать, — непонятно.
Атаки на явные пароли (с применением методов "холодной" перезагрузки или снятия дампа привилегированным пользователем) позволяют взломщику не только получить доступ к данным непосредственно на атакованной системе, но и составить словарь паролей для взлома иных систем, используемых тем же лицом. Использование в системе своп-раздела ещё более усугубляет ситуацию: в нём могут обитать пароли, проходившие через ОЗУ месяцы назад.
В числе рекомендаций для разработчиков, желающих избежать подобных проблем в своих программах, приводится более тщательный анализ собственного кода и кода всех общих библиотек и методов операционной системы, используемых приложением, а также обфускация паролей в памяти, дабы затруднить их выявление по простым текстовым подстрокам.
Источник: http://philosecurity.org/resea.....ext-passwords-linux/
А в UNIX подобное ожидается? И что значит "реализовано"? Если диск шируется, то к нему идёт постоянный доступ во время работы, а, значит, ключ всегда хранится в оперативной памяти и информация может быть получена атакой холодной перезагрузки. Произносились слова о том, что теоретиески можно и не писать ключ в оперативку, а работать с диском, но это будет дико тормозить. Насчёт же идеи что разрядка даже одного бита приводит к невозможности восстановить ключ – не совсем ясно, разве подобная реализация хранения ключа не будет вызывать ужаснейшие тормоза которе обессмыслят её применение?
Яркий пример ещё – смена дизайна сайта www.netbsd.org. Ранее он бл примерно таким же как и у openbsd, заходишь – и сразу интуитивно понятно: где и что находится. В новых же веяниях главные страницы часто пишут информацию которая по сути рекламная, и мало кому нужна, и даже не пишут кнопки login (а спрашивают пароль когда пользователь пытается осуществить операцию требующую авторизации – видимо, не все понимаю что такое login, даже ангглоязычные). Порядочный пользователь когда приходит на такой сайт долго матерится.
Сайты, продающие компьютерную технику в том же репертуаре: комп для офиса, комп для развлечений, комп залёненький, комп для ушастых блондинок. А реально юзеру, например, нужен комп HP, да с полными спеками на железо, да что проверить, будет ли поддерживваться его UNIX... в общем ппц товарисчи :(
Будет ещё один каспаров. Ещё рассказывали про известного математика во франции, которого так уважал король, что даже давал ему порулить государством пока не понял что это ни к чему хорошему не приведёт. Опыт показывает, что нельзя быть асом во всём, и если человек вроде бы знает всё – реально это означает "всё помаленьку, но ничего конкретно".
комментариев: 9796 документов: 488 редакций: 5664
Сначала думали, что нужен жидкий азот, криостат, сложное лабораторное оборудование.
Оказалось, что азот не так сложен в применении (а можно обойтись баллончиками с фреоном из хозмага), криостат не нужен, спецоборудование не обязательно, дампы памяти можно снимать сразу на месте.
Думали, что найти ключ в повреждённых дампах памяти будет сложно, оказалось легко по остаткам развёрнутого ключевого расписания. Можно восстановить ключ по подключам раундов (для некоторых шифров). Даже восстанавливать сам ключ необязательно, достаточно собрать подключи раундов и по ним провести ускоренный криптоанализ.
Ну скептики подумали, что дескать это сложно, особых знаний требует. А тут выясняется, что всё ещё проще – в большинстве случаев можно отыскать пароль, а не ключ.
Попытка хранить ключ в виде кодированного массива, в котром потеря бита мешает восстановлению всей информации в чём-то была непрактична.
Оффтопик, но согласен. Ко многим его современным идеям, несвязанным с криптографией отношусь скептически.
Да и в целом, посмотрите его список работ, представленных на всех криптоконференциях за все годы и сделайте выводы о его роли в академической науке.
В большинстве списков он просто отсутствует или редко встречается.
Это формальность и само по себе ничего не значит, но вот его E05 статистика.
Сравниваем с C06 Шамиром.
Формальный рейтинг ищите в общем списке.
Да у Шнайера куча работ, непризнанных на конференциях, но они пересекаются с исследованиями его соавторов и часто вторичны.
Шнайер авторитет конечно, но не Шамир и не Райвист. Вовремя выпустил хорошую книжку, кое-что полезное изобрёл сам, но дальше нашёл себе комманду хороших соавторов. Просто многие его считают каим-то гуру криптографии (даже сам по привычке часто на него ссылаюсь), хотя он просто хорошо себя раскрутил за пределами академических кругов.
На www.debian.org хотели сделать привлекательный дизайн. Дескать обычный отпугивает новичков. Даже назвали его словом sexy. Удалось отстоять старый дизайн, но тенденция более чем заметна, маркетинговое сознание проникает всюду.
Хорошее понятие встретилось на одном западном форуме, описывающее тенденции современной рыночной экономики – "parasitic marketing".
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Нет, грамотной популяризации криптографии и ИБ до сих пор не хватает.
В этом его большая заслуга (не в том что не хватает :), а в том что он как раз почти один много что делает в этом направлении) .
А то, что написано в самом первом комментарии про VirtualLock, так это вроде к Win относится, а никак не к Убунте, на которой вышеуказанный в статье товарищ искал cleartext password. Там так и написано:
Развейте сомнения...
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
ntldr, ау!
ps
Деление крипто на стойкое/нестойкое не абсолютно, а зависит от модели атаки, да к тому-же математически строго не доказано (то есть в некотором смысле тоже через "неясность" :), поэтому "служить принципам", отказываясь даже от простейших защит от нецеленаправленных атак, на практике мне кажется несколько неуместным.
Хотя, как "путеводная звезда" это, может быть, и неплохо.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 371 документов: 19 редакций: 20
Согласен. Учту в следующей версии.
Возможность затирания разделов запланирована на ближайшие версии, но позиционируется как средство для уничтожения уже не нужной информации вместе с файловой системой, а не как защита от атак с изъятием вашего оборудования.
Вирусов ни в какой форме и ни для каких целей в моей программе не будет. Если вам сильно надо – код открыт, добавляйте на свой страх и риск, ответственность за это несете только вы сами.
DiskCryptor не антивирусная программа, и бороться с вредоносным ПО не входит в его обязанности.
Не надо никаких вирусов в вашей программе – сделайте просто возможность по тревожной кнопке затирать загрузочный блок (а не весь раздел) данными пользователя, какие он укажет, т.е. из указанного пользователем файла (чтобы тревожная кнопка срабатывала быстрее, подгружать их в память желательно заранее). Например это может быть просто стандартный загрузчик, что тоже позволит скрыть факт использования DC, но придётся (в отличии от случая с вирусом) объяснять причину наличия большого массива случайных данных.
Замечательно! В качестве параметров разрешите указывать <начало, длина, файл с паттерном для затирки>. И в документации ни слова о загрузочном блоке в этом аспекте!
Осталось придумать легенду, чтобы это можно было бы повесить на тревожную кнопку. Например, можно предложить "макро горячие клавиши" – с возможностью назначать последовательность функций на одну кнопку. Таким образом и документация будет, так сказать, "стегофицирована" и получится "весма правдоподобное отрицание". :)