TL;DR

Мы обнаружили, описали и сделали POC для нового типа уязвимости, в той или иной форме присутствующего во всех браузерах. Такой тип атак использует пулы‎ ограниченных общих ресурсов для создания сторонних каналов (aka side-channel). Трекеры могут использовать такие каналы для слежки за пользователями и обхода других мер защиты приватности в браузерах. 

Опираясь на уже существующие исследования (например, XSLeaks и статью XSinator), которые изучали схожие вопросы, мы установили, что pool-party атаки мощнее, практичнее и распространённее, чем считалось раньше, и что все браузеры уязвимы.

Что ещё хуже, мы обнаружили, что подобные атаки могут отследить разные профили пользователей в браузерах на основе Gecko, включая Tor. Злоумышленники, атакующие такие браузеры, могут провязать действия в приватном режиме с действиями в обычных окнах, соотнося инкогнито-действия пользователя с его истинной‎ идентичностью.

Мы уже сделали фикс для этой проблемы, и в ближайшее время обновим наш браузер. Мы также работаем с представителями других браузеров для повсеместной починки этой беды. Ниже вы можете ознакомиться с результатами нашей работы, а ещё больше деталей доступно в препринте нашей статьи. В нём мы показываем практическую реализацию атаки на Webkit и Chromium-браузеры при помощи вебсокетов и на Gecko при помощи АПИ server-side events.

Бэкграунд: секционирование для приватности

Следуя требованиям пользователей и законодательства, браузеры усливают меры по защите конфиденциальности пользователей. Один из важных механизмов защиты конфиденциальности – это т.н. «секционирование»‎, при котором браузеры не позволяют трекерам следить за вами на разных сайтах, выдавая каждому сайту его собственный уникальный набор ресурсов (отдельное хранилище для кук, отдельный localStorage, отдельный кэш и т. д.).

Секционирование защищает пользователей от самых распространённых форм слежки, не позволяя скритам на одном сайте понять, что вы – тот же самый пользователь на другом сайте. Даже если и на site-a.example, и на site-b.example есть трекающий скрипт от tracker.example, секционирование не даст трекеру tracker.example понять, что один и тот же человек посетил оба сайта, и сделать межсайтовую провязку. 

К сожалению, секционирование – это не универсальный рецепт от всех бед. Существует множество способов навредить конфиденциальности пользователя, от которых секционирование не спасёт, например: фингерпринтинг, синхронизация кук по идентификаторам пользователя, отслеживание IP и т.д. Тем не менее, секционирование – это полезный и важный инструмент защиты конфиденциальности в сети.

Секционирование в разных браузерах

Секционирование полезно, и конфиденциальные браузеры по-разному его применяют. Таблица выше показывает, как различные браузеры используют эти защиты. Хранилище DOM означает те API, которые сайты используют для хранения значений (куки, localStorage, idexedDB). Сетевое состояние означает широкий список других способов, которыми сайты могут хранить значения в браузере, даже если они не предназначены для приложений (в основном, разного рода браузерный кэши). ✅ означает инструменты, доступные всем пользователям браузера по умолчанию, ❌ означает недоступные в браузере инструменты, а ????означает инструменты, которые или отключены по умолчанию, или на сегодня включены только для небольшого процента пользователей (отдельно подчеркнём титаническую работу, проделанную командой Chromium – несмотря на то, что инструменты секционирования отключены по умолчанию для большинства пользователей Chrome и Edge, они хороши). Обратите внимание на блестящий ресурс privacytests.org – это обзор текущей реализации секционирования в популярных браузерах.

Прочитать детали о секционировании хранилищ DOM в нашем браузере можно по ссылке (скоро на русском).

Проблема: рассматриваемые атаки сильнее секционирования 

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

Сам по себе такой тип атак не нов (о нём говорилось здесь и здесь), но наша работа выявила три новых важных компонента:

• Во-первых, предыдущие исследования недооценивали масштаб проблемы: это не частные случаи, на самом деле, браузеры просто кишат проблемами этой категории.

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

• В-третьих, эти атаки – не из области теории. Они вполне практичны и могут быть легко применены на практике для подрыва конфиденциальности.

Атаки подобного типа могут быть осуществлены в любом браузере, и их можно проводить по-разному. Любые массивы или лимиты ресурсов, существующие за рамками одного сайта, могут быть использованы в качестве трекингового вектора. Какие возможности браузера могут быть уязвимы? Вебсокеты, серверные события, лимиты на DNS-запросы, глобальные ограничения на одновременные HTTP запросы через прокси, а также ограничения вокруг Web Speech API – и это ещё и не весь список. Любое АПИ может быть использовано трекерами для межсайтовой слежки, если выполняются следующие условия:

1. Ресурс ограничен: сайты могут запрашивать ресурсы из пула до определённого предела, после которого сайты не могут больше запрашивать ресурсы.

2. Ресурс не разделён: разные сайты используют ресурсы из одного пула.

3. Сайты могут отправить запрос в пул ресурсов, чтобы выяснить, исчерпан ли пул, или же какие-то ресурсы всё ещё есть.

4. Сайты могут потреблять ресурсы из пула без ограничений (пока пул не израсходован).

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

Решение: как защититься от таких атак 

Защита от подобных атак – неблагодарное дело. В конечном итоге у компьютеров есть лишь ограниченный набор ресурсов, которыми они могут делиться с сайтами. Это ограниченный объём памяти, дискового пространства и т.д., так что целеустремлённые негодяи всегда смогут воспользоваться этими ограничениями для проведения атак. За исключением случаев, когда браузер решит автоматически закрыть страницу, когда сайт ведут себя странно, та или иная форма подобной атаки будет возможна.

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

Мы уже подготовили первый защитный патч, и скоро покатим обновления. Мы также продолжим работать с другими производителями браузеров (Apple, Google, Mozilla) для создания полноценный защиты от подобных атак.