20 декабря 2011 в 21:30

Хранение паролей в Chrome из песочницы


Здравствуйте!

Не так давно у меня возникла идея о создании своей личной программы для бэкапа паролей Google Chrome. Да, в интернете очень много подобных программ, но результат паранойи (что пароли сливаются на чей то сервер «про запас»), да и желание узнать, чем дышит любимый браузер — перевесили чашу весов.



Рассказывать буду на основе ОС Windows 7.

Начну с того — где хранится файл с паролями. Этот файл — "Login Data" в папке "C:\Users\SomeUser\AppData\Local\Google\Chrome\User Data\Default\".


Это база данных SQLite.



В ней есть 14 колонок. Нас же интересуют только 3: origin_url (ссылка на сам сайт), username_value (логин), password_value(пароль). Среди других колонок есть так же: страница авторизации, название элемента ввода для логина и пароля и другие. Все данные незашифровыванны(видно на скрине), кроме поля password_value.
В поле с паролем находится байтовый массив. Выглядит он следующим образом.



Способ шифрования выбран очень удобный для разработчиков. Они использовали Data Protection Application Programming Interface (отличная статья (как оказалось позже и единственная), которая описывает принципы работы этой системы), который использует Windows.
Подробнее информация в ссылке, тем более эта система шифрования заслуживает отдельной темы. Вкратце скажу, что эта система работает в одном из 2 режимов.

  1. С использованием машинного ключа.
    Ключ уникален для текущей системы. Но он позволяет разным программам работать с зашифрованными данными без передачи ключа друг — другу, но исключая утечку данных за пределы машины, а точнее пользователя.
  2. С использованием ключа пользователя.
    Без комментариев.

Так же стоит отметить, что эту систему безопасности использует всем известный IE версии 7 и старше. Защита в ней устроена ещё на порядок выше, чем у Google Chrome. Там используется вдобавок ещё и энтропия, а в качестве хранилища — используется реестр. Разработчики Microsoft'а приятно удивили.

В конце статьи есть исходный код программы. Основные её моменты мы сейчас разберем.

Итак — начнем!


Нам будет необходимо считать байты поля с паролем, так как хранится пароль именно в байтовом массиве. Для этого я использовал System.Data.SQLite Interop Library версии 1.0.65.0 (есть в архиве).
В проекте использован класс DPAPI, который был найден в интернете. На момент создания проекта не было цели написания статьи, так что автор класса утерян, но снимаю перед ним шляпу — работа проделана серьезная.

Объявим нужные нам объекты и переменные:



Далее мы заполняем DataTable DB базой данных из нашего файла:



Теперь осталось только вытащить нужную информацию из неё и записать в файл. На этом этапе файл уже не используется — работа ведется только с объектом DataTable:



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

Если есть вопросы — с удовольствием отвечу. Большое спасибо за внимание!

Исходники программы

P.S. Если у Вас 64-битная операционная система, то Вам следует заменить файл библиотеки на тот, что находится в корневой папке архива. Я не гарантирую, что данная программа будет работать на Windows XP, или других ОС. Так как проверялось только на Windows 7.

+33
117603
112
RCAPDART 13,5 G+

Комментарии (16)

+1
skive #
Отлично! Было бы неплохо тоже самое еще и для Firefox :)
0
RCAPDART #
Спасибо! Насчет FF. Особо не возился с ним. Насколько я знаю — там используется алгоритм Triple-DES, а ключ находится в файле key3.db. Ну а пароли в signons.sqlite. Можно поковыряться в принципе. =)
0
Tird #
+1
xrays72 #
>> Этот файл — «Login Data» в папке «C:\Users\SomeUser\AppData\Local\Google\Chrome\User Data\Default\»
Я бы лучше использовал путь "%appdata%\..\Local\Google\Chrome\User Data\Default\Login Data"
0
RCAPDART #
Буду иметь в виду. Спасибо. Подобную терминологию знаю, но что то пока не привык на практике применять.

PS Если кому нужно — месторасположение этой папки ("%appdata%\..\Local") в C# можно узнать так:

string way_local = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
–1
navion #
Тогда уж "%LocalAppData%\..\".
+1
IDY #
Спасибо за статью.
А вот решение есть уже готовое www.nirsoft.net/utils/chromepass.html — позволяет сохранить пароли, например в текстовый файлик.
+1
RCAPDART #
Пожалуйста =). Решение то есть, но хочется самому, свое.
+1
masterclass #
Выходит, что любая программа может подключится к базе SQLite, в которой хранятся пароли, расшифровать их (так как ключ един) и передать на сервер злоумышленника. В чем же заключается тогда безопасность?

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

Или ошибки все же нету, и единственная защита это фаервол?
+2
RCAPDART #
Вся прелесть DPAPI в том, что ключ слишком сложен, чтобы его подобрать, а алгоритм шифрования, на сколько мне известно, без дыр.
Вы правы — любая программа может прочитать БД с паролями. И расшифровать может. Но только, если эта программа выполняется на компьютере, где Хром создал этот файл. Если же у Вас просто украдут файл, то смогут прочитать только логины и сайты, где Вы регистрировались. Но пароли Ваши они получить не смогут.
Идеальной защиты нет. Просто будьте осторожны в плане того — что Вы запускаете — тогда проблем не будет.

Для заметки — FireFox, в отличии от Хрома, не привязан так к машине. Как и Opera. Но у FF и Opera есть возможность ставить мастер-ключ, тогда придется злоумышленнику подбирать его (при сложном ключе — это практически невозможно). Но мастер ключ может быть украден у Вас кейлогером. Так что опять же повторюсь — запускайте приложения из проверенных источников.
0
Agent_Smith #
Все таки это печально, я думал гугл лучше подходит к безопасности. В настройках синхронизации можно указать мастер пароль, я так понял он участвует только в момент синхронизации, а для локального хранения не используется.
+1
RCAPDART #
Честно сказать — здесь использована неплохая схема защиты. Достаточная, чтобы сохранить пароли в целости и сохранности при аккуратном пользованием компьютером.

Да — тот пароль он является ключом для синхронизации паролей. Чтобы Вы, сев за новый компьютер, введя свой gmail и пароль, а затем мастер-пароль — получили пароли и другие данные на новый браузер.

Ну а какую систему безопасности Вы хотите видеть? Чтобы что то зашифровать — нужен ключ, если ключа нет, то имея алгоритм, которым шифровали БЕЗ ключа можно спокойно узнать исходный текст на любом другом компьютере с подобной программой. Ключ может хранится в компьютере, а может получаться извне (например ввод мастер-ключа с клавиатуры, или USB-ключи). Не знаю как дела обстоят с USB ключами, но ввод ключа с клавиатуры можно перехватить кейлогером (как я писал выше), а можно и просто подсмотреть.

Гугл хорошо подошел к безопасности. Тут сама структура работы Windows не дает шанса убрать возможность таких бэкапов. Если бы каждой программе отводилось бы личное пространство памяти, в которое никто, кроме неё, не имел бы доступа, то тогда такой топорный метод не прокатил бы, но наверняка нашелся бы другой метод…
+1
anclrej #
А какой механизм реализован в расширении LastPass по сравнению с Хромовским?
+1
RCAPDART #
Честно — до Вас я ещё не слышал об этом расширении :)
Так что, как минимум, спасибо за информацию. Разгребу немного сессию и постараюсь узнать как, в каком виде и чем шифрует LastPass. На первый взгляд поверхностный — там TDES и мастер ключ. Но DES может быть и разным там… Сам DES может работать в 4 режимах и ещё и TDES может в 3 режимах. Так что надо будет ещё покрутить их комбинации. Ведь если выйти за рамки стандарта — это уже серьезный шаг к защите. Даже если этот шаг за рамки — мизерный, который никак не повлияет на криптостойкость в общем. Главное — он вышел из стандарта. И уже нельзя просто нагуглить «TDES» любому школьнику, вставить криптотекст, ключ и получить результат.
Ещё раз спасибо за подброшенную информацию. Обязательно подробно рассмотрю и постараюсь написать топик, ну или тут отвечу на Ваш комментарий, если мало чего найду.
0
wrewolf #
В fox круче, до сих пор. Можно перенести папку профиля на другую машину, и фф даже не заметит что поменялся компьютер. Все сайты включая google, facebook, vk будут думать что вы в системе. Ну и соответственно все пароли в открытом виде выдаст.

А еще лирическое отступление если у жертвы был а настроена синхронизация через фф то отныне ваши фф будут синхронно обновляться. Т.е. вы будет получать доступ к новым данным.
0
RCAPDART #
Ну смотря что понимать под понятием «круче».
Круче будет пользователю, которого не интересует информационная безопасность, а интересует исключительно удобство пользования. Купил ноутбук, скопировал со стационарного папку — всё.
Круче злоумышленнику, который вшив в очередной keygen/crack тупой скрипт архивирования в архив папки профиля и отправки её на ftp/mail.
Если всё же хочется безопасности — стоит использовать браузеры с мастер-ключами (это уже добавит дополнительную сложность злоумышленнику. Скорее придется использовать кейлогер, а это значит, что полностью автоматизировать процесс, к примеру, сбора и продажи аккаунтов вконтакте, уже не получится — придется смотреть логи кейлогера и искать в нем пароль и вскрывать им зашифрованный контейнер), либо отказаться от использования функции хранения паролей и записывать их на бумажку :P

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.