Механизмы управления паролями в IE и Firefox. Часть первая.

Mikhael Felker, Securityfocus.com
Перевод SecurityLab.ru

 

1. Введение
В данной статье мы попытаемся проанализировать механизмы безопасности, риски, атаки и методы защиты двух самых распространенных систем управления паролями для Web браузеров Internet Explorer и Firefox. В данной статье рассматриваются браузеры IE6 и 7 и Firefox 1.5 и 2.0. Внимание будет уделено следующим областям:
Механизмы хранения паролей: Средства безопасного хранения имен пользователей и паролей на локальной файловой системе с помощью шифрования данных (часть первая).
Атаки на менеджеры паролей: Методы компрометации или обхода средств защиты (частично первая часть, продолжение во второй части).
Некорректное восприятие безопасности: Использование менеджеров паролей пользователями без учета факторов риска (вторая часть)
Удобство использования: Функционал, расширяющий или уменьшающий использование функционала безопасности (вторая часть)
Контрмеры: Действия, направленные на уменьшения риска для пользователей и корпораций

Internet Explorer и Firefox вместе занимают 95% рынка браузеров. AutoComplete и Password manager являются средствами хранения имен пользователей, паролей, ссылок в браузерах Internet Explorer и Firefox соответственно.

У каждого браузера есть функционал, который помогает пользователю запоминать различные имена и пароли для аутентификации на Web сайтах. Например, при посещении сайта http://www.gmail.com оба браузера спросят, не желает ли пользователь сохранить логин и пароль. При следующем посещении сайта данные будут заполнены в форму автоматически.

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

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

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

3. Механизмы хранения паролей

Ниже описаны места и механизмы хранения паролей. Эти данные используются для изучения векторов атак, рассмотренных в 4 секции (первая и вторая части данной статьи).

3.1 Место хранения
3.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\<user name or logon name>
Криптографические симметричные ключи:
HKEY_CURRENT_USER\Software\Microsoft\ Protected Storage System Provider\<retrieved user SID>Data\<data GUID>\

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

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

3.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 найден, происходит автоматическое заполнение данных.

3.2 Хранилище и механизмы доступа
3.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).

 

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

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

3.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

 

4. Атаки на менеджеры паролей
В этой секции мы рассмотрим несколько атак на менеджеры пролей. В этой части статьи мы обсудим только 2 атаки.

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

Рис. 1 Дерево атаки на Firefox Password Manager

Доступ к базе данных позволяет атакующему заполучить все ссылки, имена пользователей и пароли, используемые для аутентификации на сайтах. Использование скомпрометированного менеджера паролей может позволить злоумышленнику получить доступ к чему угодно – от email до страховки целевого пользователя, банковских счетов или даже корпоративным внутренним данным. Дополнительная цель (не указанная в дереве) – получить доступ к определенному Web сайту. Часто значительно проще съесть кусок пирога (один логин) чем весь (полная компрометация).
Система управления паролями состоит из приложения и элементов пользователя. Для компрометации базы данных пролей или определенного логина следует атаковать самый слабый элемент в системе. В данном случае слабым звеном является пользователь, не рассматривая криптографические атаки или реализации ПО. Атаки основываются на взаимодействии пользователя и менеджера паролей, или менеджера паролей и Web браузера.

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

 

4.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 для компрометации пароля.

4.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 сайту.

Заключение к первой части

В первой части этой статьи была сделана попытка описать механизмы хранения паролей в Internet Explorer и Firefox, и, затем, были продемонстрированы две JavaScript атаки на браузеры.

Во второй части речь пойдет о большем количестве атак, начиная с Reverse Cross-Site Request атаки, обнаруженной в реализации менеджера паролей в Firefox. Также будут обсуждаться коммерческие продукты по восстановлению паролей и злонамеренное ПО, направленное на кражу паролей в IE и Firefox.