Роскомнадзор официально запросил у Facebook информацию о хранении данных

Роскомнадзор официально запросил у Facebook информацию о хранении данных

Роскомнадзор официально запросил у Facebook информацию о хранении данных

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

Все началось с официального обращения Ассоциации профессиональных пользователей социальных сетей и мессенджеров (АППСИМ), чьи представители связались с Роскомнадзором, прося проверить Facebook на предмет утечки данных россиян.

Газета «Ъ» передала слова директора АППСИМ Владимира Зыкова, который описал ситуацию следующим образом:

«Доступ к данным Facebook предоставляла, чтобы производители могли интегрировать сервисы социальной сети прямо в телефон или планшет. Благодаря этому пользователи могли видеть у себя в контактах друзей с Facebook или получать уведомления о поставленных их записям лайках».

Несмотря на то, что Роскомнадзор не в первый раз интересуется способами хранения данных россиян, которые использует Facebook, эксперты в этой области полагают, что социальной платформе не стоит бояться каких-либо юридических последствий.

Пожалуй, единственный способ давления на зарубежную соцсеть — угроза блокировкой ее работы на территории России. Тем более что подобные предупреждения звучали из уст главы ведомства.

Напомним истоки всей ситуации — в начале июня стало известно, что Facebook предоставляет производителям смартфонов доступ к личным данным пользователей. Соответствующие соглашения компания заключила с 60 вендорами.

Стало известно, что компания за последние десять лет заключала договоренности, согласно которым передавала личные данные пользователей сторонним компаниям. Некоторые из этих договоренностей действуют и поныне.

Отмечается, что среди получающих доступ к персональным данным могли быть такие крупные компании, как Microsoft, Apple, Samsung и Amazon.

Расширения 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