С момента появления интерфейса защиты данных DPAPI в Windows 2000 методика сбора цифровых доказательств при работе с веб-браузерами оставалась неизменной: изолировать компьютер, создать побитную копию накопителя, извлечь данные и расшифровать, используя пароль от учётной записи. В те времена пароля пользователя Windows было достаточно для расшифровки данных, но сегодня этот подход устарел. С внедрением технологии App-Bound Encryption компании Google и Microsoft закрыли возможность расшифровки данных из браузеров, даже если в распоряжении эксперта есть образ диска, а пароль от учётной записи известен. Для доступа к сохранённым в браузере паролям нужно действовать быстро — и однозначно перед тем, как обесточить компьютер.

Как веб-браузеры защищают пароли

До недавнего времени стандартом защиты в браузерах на основе Chromium являлся Windows Data Protection API (DPAPI). Этот интерфейс использовался в Chrome, Edge и многих других браузерах на движке Chromium. С его помощью шифровались базы данных SQLite, в которых хранятся учётные данные (пары логин и пароль) и файлы cookie. Работа DPAPI строится на простом принципе привязки к пользователю (шифрование «User-Bound» — чуть ниже мы увидим, в чём отличие от современного подхода). Операционная система шифрует данные, используя ключи, производные от учётных данных пользователя — его системной учётной записи для входа в Windows. Если эксперт авторизован в системе под учётной записью пользователя или если пароль от его учётной записи известен, расшифровка базы данных не представляет особых сложностей.

В рамках этой модели было достаточно снять образ диска и узнать системный пароль пользователя, чтобы расшифровать сохранённые в браузере пароли. Если пароль неизвестен, то данные оставались зашифрованными; просто сбросить или изменить пароль от учётной записи при помощи, к примеру, Elcomsoft System Recovery в данном случае недостаточно. Поскольку DPAPI привязывает данные к учётной записи, пароль необходимо было узнать, подобрать или восстановить при помощи атаки — например, в Elcomsoft Distributed Password Recovery. Отдельно отметим, что системные пароли Windows до сих пор являются наименее защищёнными, а скорость их перебора остаётся чрезвычайно высокой.

Итак, если пароль к учётной записи Windows известен или на компьютер проникало зловредное ПО, то извлечь сохранённые пароли не представляло проблемы. Это — очевидная дыра в безопасности: любое вредоносное ПО, запущенное от имени пользователя, могло беспрепятственно выгрузить чувствительные данные, даже не имея прав администратора.

App-Bound Encryption: привязка ключа к процессу, а не пользователю

Google закрыла эту уязвимость в июле 2024 года с выходом Chrome 127, представив App-Bound Encryption — механизм, изначально защищавший файлы cookie, но архитектурно рассчитанный и на пароли и другие чувствительные данные. Microsoft Edge (версии 127+) немедленно последовал этому примеру, так как использует движок Chromium. Новая модель безопасности смещает защиту с учётных данных пользователя на привязку к самому приложению — его исполняемому файлу, подписанному цифровой подписью.

Для работы с ключами шифрования Chrome использует привилегированную вспомогательную службу Elevation Service, работающую с правами SYSTEM. Когда браузеру требуется расшифровать ключ базы данных, он отправляет запрос этой службе. Служба проверяет, исходит ли запрос от легитимного, подписанного файла chrome.exe. Поскольку процесс доступа к ключам управляется системной службой, которая производит проверку процесса, сторонние утилиты (как зловредное ПО, так и криминалистические программы), даже запущенные от имени пользователя, не могут получить ключ шифрования. Запрос будет отклонён, так как утилита не является верифицированным исполняемым файлом браузера.

С точки зрения криминалистики внедрение App-Bound Encryption означает, что старый подход работать перестал. Утилиты, рассчитанные на DPAPI, при работе с профилями Chrome 127+ получат массив зашифрованных данных.

Новая модель безопасности защищает сразу от двух сценариев атак. Во-первых, блокируется доступ к зашифрованным данным, которые хранятся на образе диска. Во-вторых, она защищает от сторонних процессов, запущенных от имени пользователя, но не являющихся браузером. И даже подмена исполняемого файла мало что даст: перед тем, как выдать ключ шифрования, защита проверит цифровую подпись файла, который запрашивает ключ.

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

На сегодня браузеры для Windows можно разделить на две категории. Chrome, Edge и ряд других браузеров на базе Chromium используют App-Bound Encryption. В то же время Mozilla Firefox применяет собственную систему шифрования (NSS/Network Security Services) с опциональным мастер-паролем (Primary Password).

Образ диска или анализ авторизованной сессии?

Перед экспертом стоит непростой выбор: действовать по старинке, с выключением компьютера, извлечением накопителей и последующим снятием образа, или попробовать извлечь данные «здесь и сейчас»? Если полагаться исключительно на традиционный подход, то извлечь сохранённые в современных браузерах пароли вам не удастся. Даже при наличии пароля от учётной записи пользователя расшифровать ключи с защитой App-Bound Encryption в режиме оффлайн невозможно, поскольку требуемая системная служба и верифицированный процесс браузера не запущены.

Для Firefox или старых версий Chromium анализ дисковых образов по-прежнему эффективен. Но для большинства современных объектов начальный этап исследования должен производиться на работающей системе. Потребуется обновить и арсенал используемого криминалистического ПО: старые версии, работающие через DPAPI, не смогут запросить ключ расшифровки и получить доступ к данным.

Сохранённые пароли и Elcomsoft Quick Triage

До недавнего времени единственным практичным методом обхода App-Bound Encryption была инъекция кода. Именно этот способ до сих пор используется некоторыми сторонними инструментами (например, xaitax). Этот подход предполагает запуск приложения браузера (часто в приостановленном режиме) и внедрение кода в его адресное пространство для имитации доверенного процесса. Несмотря на эффективность данного метода, его использование является компромиссом из-за инвазивного вмешательства в работу ПО. Существующие альтернативные методы, как правило, слишком трудоёмки для экспресс-анализа.

В Elcomsoft Quick Triage мы использовали другой подход, не требующий инвазивного вмешательства в адресное пространство запущенного процесса. Наш инструмент использует новый механизм обхода, способный расшифровать ключ App-Bound без запуска оригинального веб-браузера и без инъекции кода. Наша реализация работает так же просто и надёжно, как и методы на основе инъекций, но значительно «чище» с точки зрения криминалистики, позволяя экспертам извлекать и расшифровывать данные без рисков, связанных с манипуляцией процессами на работающей системе.

Заключение

Технология App-Bound Encryption — относительно недавнее нововведение в методах защиты паролей, сохранённых в браузерах на основе движка Chromium. Наш продукт Elcomsoft Quick Triage позволяет обойти защиту, извлечь и расшифровать защищённые пароли — но для этого необходимо запустить продукт на компьютере подозреваемого в рамках предварительного анализа.

Ссылки:

• xaitax/Chrome-App-Bound-Encryption-Decryption
• Bypassing “app-bound” encryption implemented by Google Chrome | Devoteam