Госдеп заметил атаку иранских хакеров только после предупреждения от Facebook

Госдеп заметил атаку иранских хакеров только после предупреждения от Facebook

В 2015 году несколько крупных федеральных учреждений США пострадали от рук хакеров, стоит хотя бы вспомнить атаки на Службу управления персоналом США и Налоговое управление. Но, похоже, печальный опыт коллег не натолкнул сотрудников Госдепартамента США на какие-либо выводы.

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

В целом, в такой тактике нет ничего удивительного. Летом 2014 года иранские киберпреступники вообще создали поддельный новостной сайт Newsonair.org, потратив на его разработку и поддержание три года. Потом, представляясь журналистами ресурса, хакеры скомпрометировали аккаунты госслужащих США в социальных сетях.

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

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

New York Times пишет, что на этот раз иранские киберпреступники, судя по всему, нацеливались на младший персонал Госдепартамента США, чтобы в последствии добраться до более значимых правительственных чинов.

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