Менеджер паролей в internet Explorer и Firefox - Долгопрудный, 2008 - Московский физико-технический институт (ГУ)

Страница создана Павел Ильинский
 
ПРОДОЛЖИТЬ ЧТЕНИЕ
Менеджер паролей в internet Explorer и Firefox - Долгопрудный, 2008 - Московский физико-технический институт (ГУ)
Московский физико-технический институт (ГУ)

                Кафедра Радиотехники

Менеджер паролей в internet Explorer и
                      Firefox

                              Эссе по курсу "Защита информации"

                              Макаров Артем, гр. 417

                     Долгопрудный, 2008.
Менеджер паролей в internet Explorer и Firefox - Долгопрудный, 2008 - Московский физико-технический институт (ГУ)
1. Причина использования менеджеров паролей
Необходимость использования менеджеров паролей связана непосредственно со
сложностью запоминания многочисленных логинов и паролей для различных Web сайтов.
Естественно, менеджеры паролей могут увеличить уровень безопасности, поскольку они
позволяют использовать большое количество различных идентификаторов и паролей.
Таким образом пользователь может сгенерировать много имен пользователей и, таким
образом, усложнить процесс угадывания для атакующего.
Ключевым моментом здесь является то, что пользователь должен доверять приложению
выполнение его роли (безопасное хранение, обработка и перенаправление данных
авторизованному узлу). Менеджеры паролей не являются панацеей, хотя они усиливают
безопасность и повышают планку для атакующего путем использования интерфейса
пользователя для обработки окружений, требующих аутентификацию.

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

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

2.1 Место хранения
2.1.1 Internet Explorer 6 и 7
В Internet Explorer (версии с 4 по 6) AutoComplete хранит данные web форм в следующих
ветках реестра:
Зашифрованные имена пользователей и пароли:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\SPW

Web адреса:
HKEY_LOCAL_MACHINE\Software\MicrosoftProtected Storage System Provider\
Криптографические симметричные ключи:
HKEY_CURRENT_USER\Software\Microsoft\ Protected Storage System Provider\Data\\

ВInternet Explorer 7 AutoComplete хранит также данные в реестре, но немного в других
ключах:
Зашифрованные имена пользователей и пароли:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

Данные создаются в реестре, только после того, как пользователь сохранит свои данные
(логин и пароль) для Web сайта. Акроним SPW является сокращением от SavedPassWords.

2.1.2 Firefox 1.5 и 2.0
В Firefox ссылки, имена пользователей и пароли хранятся в файле signons.txt:
Зашифрованные имена пользователей и пароли в Windows хранятся в:
%userprofile%\Application Data\Mozilla\Firefox Profiles\xxxxxxxx.default\signons.txt
Где %userprofile% - переменная окружения в Windows,в которой хранится путь к
домашней директории пользователя.
Зашифрованные имена пользователей и пароли на Linux системе хранятся в:
~/.mozilla/firefox/xxxxxxxx.default/signons.txt
Где xxxxxxxx – генерируется случайным образом при установке Firefox. Файл signons.txt
создается первый раз при сохранении данных для Web сайта. Последующие логины и
пароли для различных сайтов добавляются в этот файл. Для менеджера паролей не имеет
значения, доступен сайт по HTTP или HTTPS. Ссылки не шифруются, поскольку они
используются как ключи для поиска данных. Когда менеджеру паролей браузера
необходимо автоматически заполнить web форму данными для определенного сайта,
менеджер ищет соответствующий URL в файле signons.txt, если URL найден, происходит
автоматическое заполнение данных.

2.2 Хранилище и механизмы доступа
2.2.1 Internet Explorer 6 и 7

Структура хранилища: Реестр
Формат данных: Двоичный, хранится в виде пары шестнадцатеричных значений в типе
данных REG_BINARY
Шифрование: TripleDES
Доступ: Protected Storage API (для IE 4-6); Data Protection API (для IE 7)
Требования к доступу: Авторизованный пользователь
Временное хранилище: Симметричные ключи, обнуляемые в памяти после
использования.

Internet Explorer версии 4-6 используют Protected Storage System Provider (PStore) для
хранении и доступа к важной информации пользователя, включая имена пользователя и
пароли, введенные в Web формы в IE. PStore, согласно MSDN, является API для
безопасного хранения данных. Согласно недавней публикации Microsoft Press:
«… служба Protected Storage, не считается более безопасным методом хранения данных.
Одним из существенных Windows приложений, которое все еще используют PStore,
является Microsoft Internet Explorer, которые хранит данные Auto-Complete, включая
имена и пароли пользователей для авторизации на web сайта».

Данные PStore шифруются с помощью TripleDES и хранятся в двоичном формате.
Незашифрованные данные не могут быть доступны непосредственно через реестр. Хотя
безопасность данных и доступ к ним логически завязан на данных учетной записи
пользователя в Windows. Как только пользователь войдет в систему, любое приложение,
запущенное в контексте пользователя, сможет получить доступ к незашифрованным
PStore данным, используя корректные функции API. Хотя, различные учетные записи
пользователей в Windows не могут заполучить PStore данные друг друга.

PStore используется не только в Microsoft Internet Explorer, он также используется в
различных приложениях Microsoft, таких как Outlook и MSN Explorer. Эти приложения
также уязвимы. Известно множество Spyware приложений, которые использовали легко
программируемые API для получения неавторизованного доступа к данным.

Internet Explorer 7 использует Data Protection Application Programming Interface (DPAPI), но
все же, данные все еще могут быть доступны через API вызовы внешний приложений.
Криптографическая защита AutoComplete в Internet Explorer 7 изображена ниже:

EK - Encryption Key
RK - Record Key
CRC - Cyclical Redundancy Check
Hash - Secure Hash Algorithm (SHA)
Хранение данных:
EK: URL
RK: Hash(EncryptionKey)
C: CRC(Record Key)
V: {data}EK
Хранилище (C, V) индексируется RK в реестре, удаляется EK
Получение данных:
EK: URL
RK: Hash(EK)
Происходит поиск RK в реестре, если обнаруживается сходство с V, содержащем
зашифрованные данные
data: {V}EK

URL требуется для получения данных (data), поскольку он используется для создания
ключа шифрования (EK).

2.2.1.1 Основы организации доступа в Internet Explorer
AutoComplete работает в IE с той предпосылкой, что учетная запись пользователя в
Windows имеет полный логический доступ к базе данных паролей. По этому, если
неавторизованный пользователь получает логический доступ к компьютеру, и
пользователь вошел под своей учетной записью, или эта учетная запись не защищена
паролем, атакующий сможет получить привилегии учетной записи и неправомерно
воспользоваться паролями. Логический доступ может быть получен с помощью
физического присутствия (сесть за компьютер) или удаленно с помощью клиента
удаленного управления компьютером (VNC, Remote Desktop и т.д.)

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

2.2.2 Firefox 0/7-1.5 и 2.0

Структура хранилища: Текстовый файл (signons.txt)
Формат данных: ASCII, используя Base64 кодирование (кроме URL и полей)
URL (обычный текст, например www.gmail.com)
Field name (обычный текст, например username, email, userid и т.д..)
Зашифрованное и Base64 кодированное значение вышеописанной информации
Field name (например, password, pass,и т.д..)
Зашифрованное и Base64 кодированное значение вышеописанной информации
...и т.д.... (Может быть много данных для одного URL)
.
(Каждая запись заканчивается точкой)
Шифрование: TripleDES (CBC mode)
Доступ: Network Security Services (NSS) API
Требования к доступу: Авторизованный пользователь и Master Password (если
установлен)
Дополнительные файлы: Сертификаты сохранены как certN.db, база данных частных
ключей как keyN.db и Security Modules сохранены как secmod.db. Напомним, что место
расположения файлов было описано в секции 3.1.
Firefox использует Network Security Services API для проведения криптографических
операций. Поскольку это относится к менеджеру паролей, Firefox использует Public Key
Cryptography Standard (PKCS) #11, который определяет API для аппаратных и
программных модулей сторонних производителей. Также используется PKCS#5 для
шифрования паролей. У Firefox также есть опция для использования альтернативного
модуля для хранения паролей, совместимого со стандартом Federal Information Processing
Standard (FIPS) 140-1. Master Password используется совместно с salt (находится в файле
keyN.db) для получения Master Key. Затем Master Key используется для дешифрования
имен пользователей, паролей, сохраненных в менеджере паролей.

NSS API имеет несколько функций, которые позволяют Firefox или подобным
приложениям получить доступ к базе данных паролей. Установка пароля обрабатывается
(PK11_SetPasswordFunc), декодируя Base64 данные (NSSBase64_DecodeBuffer) и
дешифруя (PK11SDR_Decrypt), что позволяет соответствующим приложениям получить
доступ к именам пользователей и соответствующим паролям. Безопасность всей системы
зависит от криптографической стойкости Master Password (созданного пользователем) и
доступности файла key3.db (который содержит salt), хранимого в пользовательском
профиле.
Модуль безопасности FIPS 140-1 может быть включен следующим образом:
Firefox 1.5 на Windows:
Tools -> Options -> Advanced -> Security Devices -> NSS Internal FIPS PKCS #11
Firefox 2.0 на Windows:
Tools -> Options -> Advanced -> Encryption -> Security Devices -> NSS Internal FIPS
PKCS #11

 3. Атаки на менеджеры паролей
3.1 Независимые JavaScript атаки
В этой секции будут рассмотрены 2 JavaScript атаки: стандартная атаки, и с
использованием технологии Ajax.

 3.1.1 Стандартная JavaScript атака
Предположение: Атакующий имеет логический доступ к пользовательскому интерфейсу
Результат атаки: Атакующий может зайти на сайт, для которого был ранее сохранен
логин и 1) получить доступ, 2) использовать JavaScript для получения имени пользователя
и пароля.
Сопутствующее повреждение: Использование расшифрованных паролей для доступа к
менеджеру паролей или любого другого приложения или Web сайта, использующего
идентичный пароль.
С помощью JavScript и DOM можно получить доступ к сохраненному паролю. Когда
пользователь посещает сайт, для которого сохранены личные данные, пароль обычно
скрыт за звездочками (*) или кружками (●).
Атакующий может либо использовать JavaScript, встроенный в HTML страницу, либо
выполнить сценарий после загрузки страницы, что позволит злоумышленнику получить
имя пользователя и пароль.
Рис. 2 JavaScript Document Object Model (переходящая в объект пароль)

JavaScript легко доступен online. Он может быть вставлен в HTML, или запущен как
букмарклет. Букмарклет – маленькая JavaScript программа, которая может быть сохранена
как URL и запущена локально на Web странице после ее загрузки.

Используя программную логику, атакующий проходит по всем парольным элементам (как
показано на рис. 2) модели DOM и получает доступ к значениям соответствующих
элементов. Любой человек или приложение, использующее Web клиент (IE или Firefox),
может нажать на ссылку и скомпрометировать пароль.

javascript:(
function(){
         var s,F,j,f,i;
         s = "";
         F = document.forms;
         for(j=0; j

Рис. 3 Код JavaScript для компрометации пароля.

3.1.2 Сбор паролей Ajax
Предположение: Атакующий имеет доступ к Web прокси, который является прозрачным,
или сконфигурирован для Web клиента.
Результат атаки: Атакующий способен вставить, удалить или изменить содержимое Web
страницы, включая JavaScript, что позволяет собирать имена пользователей и пароли с
любого сайта, использующего HTTP соединение.
Сопутствующее повреждение: Потенциально один и тот же логин и пароль может
использоваться для доступа к компьютеру и/или других приложений и Web сайтов.
В сценарии, изображенном на Рис.4, пользователь открывает Web браузер и желает
получить доступ к банковским данным на удаленном сервере. Пользователь запрашивает
главную страницу своего провайдера (например, American Express). Сервер компании
отвечает, но данные в ответе модифицируются при прохождении через прокси сервер.
Прокси сервера обычно используются для сокрытия IP адреса пользователя, фильтрации
содержимого и т.д.; они устанавливаются между клиентом и сервером и, как правило, с
четкой целью.

Рис. 4 Сбор паролей Ajax

Если атакующий контролирует прокси, он может внедрять JavaScript, который отсылает
имя пользователя и пароль через асинхронный запрос серверу (XMLHttpRequest). Имя
пользователя и пароль могут быть получены с помощью сценария, упомянутого выше
(менеджер паролей автоматически заполняет поля формы), или с помощью таймингового
механизма, который ожидает определенный период времени (например 5 секунд),
позволяя пользователю ввести данные, и затем запускается код JavaScript, который
отсылает данные атакующему. Иллюстрация на Рис. 4 показывает, как браузер получает
XML файл, содержащий данные для входа (bobpassword). Сервер проигнорирует запрос,
поскольку он некорректен, но атакующий уже получил необходимые для него данные.

Важно дифференцировать процесс, который аутентифицирует пользователя на сервере и
отдает злонамеренный код, который только отправляет имя пользователя и пароль
атакующему. На некоторых сайтах имя пользователя и пароль вводятся до создания SSL
подключения. Ключевым в этой атаку является то, что если SSL соединение было
установлено до ввода личных данных, прокси сервер не может просмотреть
зашифрованный трафик. Тем не менее, некоторые известные сайты, использующие SSL
шифрование (Yahoo, AMEX и другие) создают SSL подключение только после загрузки
страницы для ввода личных данных. Они уязвимы для этого типа атаки. Варианты этой
атаки будут развиваться и скоро возникнет несколько векторов атаки.

Давайте сравним различный функционал безопасности менеджеров паролей в двух самых
популярных браузерах:

Функционал                  Internet Explorer 7         Firefox 2.0
Хранилище имен              Да                          Да
пользователей, паролей и
ссылок
Доступ к паролю с помощью Да                               Да
JavaScript
Доступ к паролю с помощью Да                               Да
другого ПО
Защита паролем (не                                         Да
привязанным к учетной
записи системного
пользователя)
Запрос пароля перед началом                                Да
сессии для использования
сохраненных паролей для
сайтов
Легко экспортируемые имена                                 Да
пользователей и пароли
Шифрование данных           Да                             Да
Кодирование данных                                         Да
Опция менеджера паролей                                    Да
для отображения пароля в
открытом виде

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

3.2. Уязвимость в реализации менеджера паролей Firefox 2.0. (реверсивный
межсайтовый скриптинг).

В версии менеджера паролей Firefox 2.0 от ноября 2006 года содержится уязвимость,
которая позволяет, при нажатии специально сформированной ссылки, передать личные
данные пользователя текущего сайта на произвольный URL. Уязвимость, далее RCSR
(Reverse Cross Site Request), состоит в том, что браузер не контролирует URL, на который
отправляются личные данные пользователя через Web формы. Для успешного проведения
атаки пользователю необходимо ранее посетить сайт и сохранить свои личные данные в
менеджере паролей. Эта тактика кражи информации была осуществлена на MySpace.com
и обнаружена CIS. Наиболее уязвимы сайты общественной сети, которые позволяют
пользователям размещать личные данные в чистом HTML формате.

RCSR мощнее чем атака описанная ранее, поскольку XMLHttpRequest не пропускает
запросы за пределы текущего домена. К тому же ссылка (действие, позволяющее отправку
данных формы) может появиться в форме вложенного видео, вебкаста или возможно
игры, что делает ее более скрытой.

4. Литература.

http://www.securityfocus.com/infocus/1882

http://www.securityfocus.com/infocus/1883/

http://wikipedia.org

www.useram.net/
Вы также можете почитать