Сквозное шифрование Zoom уже повсеместно доступно всем пользователям

Сквозное шифрование Zoom уже повсеместно доступно всем пользователям

Сквозное шифрование Zoom уже повсеместно доступно всем пользователям

Подписчикам сервиса видеоконференций Zoom открыли доступ к опции сквозного шифрования (end-to-end encryption, E2EE). Воспользоваться ею могут владельцы и платных, и бесплатных аккаунтов. В последнем случае пользователю придется по SMS подтвердить свой номер телефона и указать корректную платёжную информацию в настройках аккаунта.

Поддержка E2EE введена в клиентах Zoom версии 5.4.0 для Windows и macOS, соответствующем приложении для Android и в Zoom Rooms. Пользователям iOS-приложения Zoom придется ждать, когда в магазине Apple одобрят апдейт.

Нововведение запущено как ознакомительная техническая версия; отзывы будут приниматься в течение 30 дней. Активировать E2EE можно из десктопного приложения — на уровне аккаунта, группы или отдельного пользователя. Администратор учетной записи также имеет возможность заблокировать такую защиту на уровне группы или аккаунта.

При реализации E2EE разработчики использовали тот же метод шифрования, который по умолчанию защищает все встречи на платформе Zoom, — AES в режиме GCM с 256-битным ключом. Использование новой опции возможно лишь в тех случаях, когда в конференции участвуют не более 200 человек.

Кроме того, следует учитывать, что при включении E2EE перестанут работать некоторые Zoom-функции — запись в облако, текстовая расшифровка речи, голосование, возможность подавать реплики. Нововведение исключает использование участниками телефонной связи, Lync, Skype, протоколов SIP и H.323, а также локальных настроек.

Пользователей новой опции просят в течение месяца присылать отзывы. После их обработки Zoom перейдет к следующему этапу внедрения E2EE: разработчики займутся в числе прочего совершенствованием идентификации пользователей и реализацией механизма единого входа (SSO, Single Sign-On), который планируется ввести в строй в будущем году.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

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

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

В Google подтвердили возможность подобной атаки по стороннему каналу, но заявили, что решить проблему нереально.

RSS: Новости на портале Anti-Malware.ru