Введение

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

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

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

Итак, начнём.

Проблемы

Что может быть проще, чем менеджер паролей? Это всего лишь тривиальное хранилище ключей и значений. И в самом деле, обычно великолепно работают самые простейшие реализации этой концепции. Хорошими примерами простых и безопасных менеджеров паролей являются keepass и keepassx, или даже pass, если вы нерд.

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

Плохой совет

Я часто говорю, что фраза «пользуйтесь менеджером паролей» — это плохой совет, ведь людям сложно понять разницу между компетентной и наивной реализациями. В прессе делают обзоры удобства пользования и простоты программ, но по ним невозможно оценить безопасность. Так как же делать выбор пользователям? Поэтому я считаю, что совет «пользуйтесь менеджером паролей» настолько общий, что представляет опасность.

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

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

Поверхность атаки

Самая интересная для меня тема — это то, как удалённые злоумышленники могут взаимодействовать с менеджером паролей пользователя.

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

Обычно я сталкиваюсь с двумя распространёнными проблемами. Первое — это то, что надёжные элементы интерфейса пользователя инъектируются в потенциально опасные веб-сайты. Второе — различные компоненты взаимодействуют по веб-каналам (например, WebSockets, postMessage и т.д.) без адекватной взаимной авторизации.

Давайте сначала обсудим элементы интерфейса пользователя.

Враждебные окружения

Большинство онлайн-менеджеров паролей использует скрипты контента, то есть код на Javascript, вставляемый в каждый посещаемый пользователем сайт. Писать скрипты контента очень легко, однако очень сложно сделать их устойчивыми к изменениям. И это проблема, потому что они будут хоститься во враждебных окружениях.

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

Chrome против контента

Интерфейс браузера состоит из двух основных компонентов — из chrome (как ни странно, это понятие никак не связано с Google Chrome) и из области контента. Компонент chrome содержит такие элементы, как адресная панель, вкладки и кнопка «Назад». Этим компонентам можно доверять, и веб-сайты не могут их модифицировать. С другой стороны, всё, что находится внутри области контента, может управляться веб-сайтом, а поэтому этому компоненту нельзя доверять.

Большинство менеджеров паролей размывают это различие, отрисовывая свой UI в области контента. Такую систему просто невозможно реализовать надёжно, и чтобы доказать это, достаточно тривиального демо.

Фреймы

Допустим, но мы уже привыкли, что разные части области контента могут иметь разные привилегии; по сути, так работают iframe. Однако это не делает их безопасными: вероятно, вы знаете о X-Frame-Options — это заголовок, позволяющий веб-сайтам отказаться от разделения на фреймы. Большинство веб-сайтов, озабоченных своей безопасностью, так и поступает, потому что нападающие легко могут обмануть пользователя, заставив его взаимодействовать с фреймами непредусмотренным образом.

Такое поведение иногда называют redress-атаками или clickjacking. Подробный анализ этой атаки приведён в Browser Security Handbook.

Если redress-атаки вызывают такие проблемы, что все заботящиеся о защите сайты отключают фреймы, то должны ли программы, задача которых заключается в защите паролей, тоже от них отказаться? Это вопрос с подвохом — они не могут этого сделать!

Краткая иллюстрация

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

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

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


Интерфейс пользователя Nordpass

Обычно веб-сайты могут взаимодействовать с этим UI, и быстрая проверка подтвердила, что в данном случае это так. Похоже, что я могу и стилизовать эти элементы, поэтому возможен тривиальный redress.


Тестируем redress интерфейса

Эта проблема свойственна онлайн-менеджерам паролей — никогда нельзя сказать точно, взаимодействуешь ли ты с веб-сайтом, или с менеджером паролей. Давайте создадим небольшое демо.

Во пример, если у вас установлен Nordpass, то можете проверить его самостоятельно (прошу прощения за ужасный дизайн).


Это фундаментальная и нерешаемая проблема подобных систем.

Я обнаружил в работе этих элементов UI множество реальных уязвимостей, подверженных эксплойтам. Тривиальных, например, таких, или таких. Иногда пользователю даже необязательно взаимодействовать с сайтом.

Обмен данными между процессами

Мы уже выяснили, что один компонент онлайн-менеджеров паролей нужно инъецировать в потенциально враждебное окружение. Как эти компоненты взаимодействуют друг с другом?

Наивным решением было бы простое использование XHR или WebSockets с локальной конечной точкой HTTP. Оно кажется привлекательным для разработчиков, ведь это нативный способ обмена данными в вебе. Проблема этого решения в том, что очень сложно отличить скрипт контента и враждебный скрипт, работающий на той же странице, но в другом мире.

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

Песочницы

Ещё одна моя претензия к онлайн-менеджерам паролей заключается в том, что они снижают эффективность песочниц браузера. Современные браузеры используют sandbox-архитектуру для изоляции компонентов, которые могут плохо себя вести.

Проблема в том, что при помощи расширений онлайн-менеджеры паролей, по сути, инъецируют в эти процессы песочниц привилегированные компоненты. Задача песочниц — изолировать друг от друга потенциально скомпрометированные компоненты, но если вы засовываете все свои самые ценные секреты внутрь песочницы, то какой в этом вообще смысл?

Меня беспокоит то, что люди не понимают, на какие компромиссы им приходится идти.

Заявления разработчиков

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

• «Никто, кроме вас, и даже мы, не имеет доступа к вашим паролям».
• «Мы обеспечиваем приватность, безопасность и сокрытие вашей информации (даже от нас)».
• «Ваши данные защищены таким образом, что просматривать их и управлять ими можете только вы. Наши сотрудники этого делать не могут».
• и т.д., и т.п.

Все эти заявления — полная чушь. Нападающий (или инсайдер-злоумышленник), получивший контроль над сетью разработчика, может изменить код, передаваемый в браузер, и этот код, очевидно, имеет доступ к вашим паролям. И это не преувеличение, изменение контента веб-сайтов (например, defacement) настолько распространено, что стало практически спортом.

В реальности вам приходится полагаться на разработчика в том, что он будет поддерживать инфраструктуру и обеспечивать её безопасность. Существование шифрования («банковского уровня» или ниже) ничего не изменит.

Возможно, вы скажете, что это не особая проблема, ведь вы уже доверились разработчикам, установив их ПО. Хорошо, но ведь эти заявления стали основным посылом маркетинга, то есть разработчики считают, что для пользователей это важно. Я считаю, что эти заявления искажают истину, чтобы заглушить закономерные сомнения пользователей.

Другие заявления

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

• Шифрование ввода защищает всё, что вы набираете, от считывания киберпреступниками. М-м-м, ну ладно.
• Многие из сборок .NET […] обфусцированы, поэтому даже с помощью дизассемблера пользователи не смогут просматривать критически важные части методов/функций/классов. О, мне определённо стало спокойней.
• и т.д., и т.п.

Заключение

Если вы хотите пользоваться онлайн-менеджером паролей, то рекомендую использовать тот, который уже встроен в ваш браузер. Он обеспечивает такую же функциональность и позволяет обойти фундаментальные проблемы расширений.

Я пользуюсь Chrome, но и другие популярные браузеры типа Edge или Firefox, тоже сгодятся. Они могут изолировать свой надёжный UI от веб-сайтов, не разрушают модель «песочной» защиты, над ними работают специалисты по безопасности мирового уровня, и они просты в работе.

Без сомнений, многим из тех, кто прочитает статью, не понравится мой совет. Могу только сказать, что я уже слышал все аргументы, но остаюсь при своих выводах.

---

На правах рекламы

Аренда VDS любых масштабов — это про наши облачные серверы! Они бесплатно защищены от DDoS-атак, скорость интернет-канала — 500 Мегабит, остальные параметры тарифа вы можете сконфигурировать самостоятельно в пару кликов. Предоставляем возможность автоматически установить удобную панель управления VestaCP или HestiaCP для размещения сайтов. Поспешите заказать!

Подписывайтесь на наш чат в Telegram.