ФБР не смогло взломать iPhone журналистки из-за Lockdown Mode

ФБР не смогло взломать iPhone журналистки из-за Lockdown Mode

ФБР не смогло взломать iPhone журналистки из-за Lockdown Mode

ФБР столкнулось с неожиданным препятствием при расследовании утечки конфиденциальных данных: Lockdown Mode на iPhone журналистки Washington Post фактически заблокировал доступ к содержимому устройства. Поводом для изъятия девайса стало расследование в отношении подрядчика Пентагона, которого подозревают в незаконной передаче внутренних материалов журналистам.

Как следует из материалов суда (PDF), агенты изъяли технику у репортёра Ханны Натансен 14 января во время обыска в её доме в Вирджинии. Среди изъятого — служебный iPhone 13, рабочий и личный MacBook Pro, внешний диск, диктофон и умные часы Garmin.

Однако с iPhone у следователей ничего не вышло. Устройство было включено и стояло на зарядке, но на экране отображался Lockdown Mode — специальная функция Apple для защиты от целевых атак. По данным ФБР, специалисты Computer Analysis Response Team не смогли извлечь данные с телефона. В итоге агентство ограничилось анализом сим-карты, который дал лишь номер телефона.

Lockdown Mode появился в экосистеме Apple в 2022 году и предназначен для журналистов, правозащитников, политиков. Он резко ограничивает работу вложений, браузерных функций, FaceTime, обмена фото и других механизмов, которые могут использоваться для атак.

С ноутбуками ситуация оказалась другой. ФБР получило доступ к рабочему MacBook Pro, когда Натансен по требованию агентов приложила палец к сканеру отпечатков. Власти утверждают, что ордер позволял использовать биометрию. При этом личный MacBook остался недоступен — он был выключен и защищён паролем.

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

Washington Post и сама журналистка требуют вернуть изъятые устройства, считая обыск нарушением прав. Минюст, в свою очередь, настаивает, что речь идёт о законном изъятии доказательств и что альтернативы вроде точечного запроса данных слишком рискованны.

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