АНБ США перехватывало данные Google и Yahoo на уровне датацентров

АНБ США перехватывало данные Google и Yahoo на уровне датацентров

Газета The Washington Post сегодня опубликовала новые материалы, полученные изданием от Эдварда Сноудена. Согласно последним сведениям, Агентство Национальной Безопасности США получило доступ в датацентры компаний Yahoo и Google, так как спецслужбе удалось подключиться к магистральному коммутационному оборудованию в датацентрах и прослушивать интернет-трафик.

Согласно последним материалам, еще 9 января 2013 года АНБ отправляло «миллионы» записей ежесуточно. Все они снимались с коммутационного оборудования, отвечавшего за связь между разными датацентрами Google и Yahoo. Данные стекались в штаб-квартиру АНБ в Форт-Миде (Мериленд, США). За последние 30 дней января сборщики информации в АНБ обработали около 180 млн записей различного порядка - от метаданных, таких как отчеты о получении и отправке писем, до самих электронные письма, тексты, аудио и видео, сообщает cybersecurity.ru.

Отметим, что новые подробности о прослушивании трафика Google и Yahoo выходят, когда Конгресс США обсуждает сложившуюся практику сбора данных в США и обещает ее кардинальным образом пересмотреть. Напомним, что Сноуден передает данные о деятельности АНБ с июня этого года.

Согласно последним данным, АНБ применяло специальный программный эксплоит Muscular, который был разработан в сотрудничестве с британской разведкой GCHQ. The Washington Post сообщает, что АНБ c британскими коллегами перехватывали данные между датацентрами большими объемами, внедряя свои модули на волоконно-оптические линии сваязи. Газета пишет, что официальные представители АНБ и Белого Дома в Вашингтоне отказались от комментариев.

В пресс-службе Google заявили, что они «обеспокоены обвинениями в правительственном перехвате трафика между датацентрами». Также газета отмечает, что в АНБ были выделены достаточно большие ресурсы на мониторинг трафика Google и Yahoo.

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